書籍「時短の科学」に生産性向上の手段を学ぶ
「時短の科学」という書籍には生産性に対する疑問の答えが書かれている
世間では生産性向上や DX がお題目のように唱えられている。ソフトウェアエンジニアとしての業務効率化にあたり、自分は何から始めれば良いか考えるために「時短の科学」を読んでみた。この本では接客を中心とするサービス業を題材に、生産性とは何かを定義し、それを向上させた手段とその結果どのようにビジネスがうまく回り始めたのか、様々な事例が紹介されている。
これまで製造業の分野で議論されていた生産性の向上について、製造業と違ってサービス業では銀の弾丸（魔法の杖）がないとされてきた。サービス業では顧客の要求が多様であるため、一律にこれをすれば生産性がアップするという方法が編み出されていなかったからだ。
それでも何か方法はあるのではないかとフィールドワークを経て著者が帰納的に導き出された法則が現場のエピソードともに紹介されている。
接客のサービス業と開発のIT業界とは働き方が異なるものの、ソフトウェアエンジニアの観点から、この書籍で何か活かせることはないかと考えながら読んでみた。結果、もちろんホテルや旅館、飲食店の事例をそのまま当てはめることはできないものの、いくつもの現場を見てきた著者が抽出した法則は、エンジニアの働き方にも役に立つところがあると思い記事を書くことにした。
一言で書くと、この書籍は「生産性」に対する議論の土台を提供している。これを読んだあとは「生産性ってなんだろう」「向上といってもどうすれば良いのだろう」という疑問に答えることができるだろう。
「生産性向上」を宣言しても仕事は楽にならない
本記事は書評ではないので、満遍なく書籍の内容を紹介するものではない。だが、書籍内で役に立つと思ったことを抜き出して紹介していきたい。
その際、本書の「著者が赴いた現場の多数の事例を引用しながら、アルバイトをしたことがある人なら誰でも頷くような身近な困り事を仕組みで解決していく」という重要な持ち味が抜け落ちてしまうことはご了承願いたい。
そもそも生産性とは労働生産性であり、これは「労働生産性 = 付加価値 / 労働投入量」と定義されている。このため、労働時間の削減、つまり人を減らしたり残業を削れば、数式上は生産性が向上したといえる。あるいは、同じ人員で労働時間を増やさず売上を伸ばすことができた場合、これも生産性の向上だ。
しかし、現実問題として「生産性を向上させよう」と宣言しても１週間かかっていた仕事が3日で完成するわけではないし、同じ仕事をしているままでは売り上げは伸びない。
世間では「生産性向上」がただの効率アップと勘違いされている
では、同じ仕事を終えるにあたり、作業時間を短縮すれば良いのではないかという考えもある。しかし、これこそが罠なのだ。本書ではこれは生産性の向上ではなく「効率アップ」と分類されている。
効率アップについて、書籍内では「店員さんがお客さんに水を出すスピードを上げる」という例があげられてる。これをパソコンを使った業務に当てはめると、「ショートカットキーをたくさん覚えてマウスクリックの回数を減らす」というようにも言えるだろう。3秒かかった作業が1秒になるというのだ。
これは効率アップであって生産性向上ではない（なお、ショートカットキーを暗記すること自体を否定するものではない）。
世間でいう生産性の向上の議論を見ても確かに後者の域を超えないように思うこともある。確かにこちらの方があれこれ悩まずに済むし、今日からすぐにでも実践できる。しかし、これこそが生産性の勘違いという罠だ。
生産性向上とは、今の仕事を分類し、無駄をなくして仕事に集中すること
結論から書くと、生産性の向上とは無駄をやめることだ。そこで本書では業務を以下のような３つのタイプに分類している。
- 顧客満足に繋がらず、従業員もやめたいと思っている無駄
- 顧客満足に繋がらないが、必要な作業
- 顧客満足度の向上につながる仕事
以下ではそれぞれ無駄、作業、仕事と呼ぶ。先ほど挙げた例を引き合いに出すと、もし店員が水を直接お客さんに出さないことが顧客満足度の低下に繋がらないとすれば、店員が水を出すスピードを上げるのではなくセルフサービス用にドリンクサーバーを用意すれば良い。するとお客さんは自分が水を求めるタイミングで非同期に水を汲みに行ける。
もしセルフサービスが顧客満足度の低下に繋がるなら、それは無駄ではなくて顧客満足度の向上に繋がる仕事だという発見があったと言うことで元に戻せば良い。
もう一つ別の事例を挙げると、書籍内では「旅館で部屋用の浴衣のサイズを各部屋ごとにS・M・Lと置いていたが事前の準備が大変だった。それをチェックイン時に係が宿泊客の背格好を見て、浴衣のサイズを判断して渡すようにした」という改善例が紹介されていた。
業務フローの改善を決めた人物は「顧客から不満の声が上がるなら元に戻す。しかし、2週間ほど様子を見て何もクレームがなければ新しいやり方を採用する」と考えて現場で実行。クレームは1件もなかったそうだ。エラーが出たらロールバックするのと同じ考えだ。あるいは、カナリアリリースのように一部の宿泊客にだけ試してみても良いかもしれない。
顧客に受け入れられなかったら元に戻す
カナリアリリースといえば、料理人も実はこの方法を採用していると聞く。コース料理の中の一皿を新しい料理と入れ替え、しばらく様子を見る。ウェイターに感想を伺わせるか、それが無理なら厨房に下がってきた皿に料理が残されているか、完食されているかを見て採用するか判断するというのだ。エンジニアリングと思わぬところに共通点があって面白い。
閑話休題。生産性の向上とは、つまり無駄をなくして、作業を減らし、仕事に集中することだ。自分は社会人1年目で経理に配属されたのだが、紙の請求書を1枚1枚めくりながら電卓を叩くスピードが早くなったら周りから褒められたことを思い出す。今ならバクラク請求書を使えばOCRで読み取るだけで済む。これこそが業務フローの改善による生産性の向上だ。
さて、短期で怠惰、そして傲慢なエンジニアなら無駄をなくして作業を減らす、ということは容易に想像できるだろう。さらに現場でも日々実践しているはずだ。しかし、本書でも紹介されている顧客満足を向上させる仕事に集中するということを実践できている現場は少ないのではないだろうか。
仕事に集中すると顧客の満足度が上がる
仕事とは、顧客満足度の向上に繋がることだ。それは接客業だとお客さんに直接ありがとうと感謝されるようなことを指す。しかし、こと IT 業界においては「このシステム使いづらい」「機能が足りない」「バグが出てます」と恨まれることはあってもユーザーから直接感謝されることはほとんどない。間接的にはもちろんあるが、その辺りがサービス業と異なるところだ。
一方、エンジニアの仕事では「顧客の課題を解決する」「ユーザーと向き合う」ということが一番重要なのは異論がないだろう。つまり顧客と向き合い続けなければいけないのだ。サービス開発をする仕事に携わっている方であれば、これはエンジニアでもデザイナーでもプロダクトマネージャーでも同じである。だが、なかなかこれを文字通り実践するのは難しいのも現実だ。
「偉い人が求めるから」「Aさんが絶対あった方がいいというから」「競合には既にあるから」ある機能を実装したいという要望は顧客から一歩遠い。そうではなく、あくまでユーザー起点で施策を打っていく。この辺りはリーンスタートアップで説かれていることと同じだ。開発の無駄がなくなる結果、生産性が向上するのだ。
好循環のサイクルを回す
ユーザーは面倒なジョブを片付けてくれたことに対してお金を払う（ジョブ理論）。無駄をなくして顧客満足度が向上する仕事に集中した結果、かつてのモーレツ社員のように労働時間を増やさなくても売上が向上する。しかも、開発チームは作ったものを顧客が喜んで使ってくれることがわかる。すると、またユーザーが求める（＝喜ぶ）ものを作って出す。こうして弾み車が回っていく（弾み車の法則）。実際、本書でも「現場には好循環と悪循環しかない」と喝破されている。
だからこそ、施策を立てる人にこそ一番ユーザーの声を聞いてほしいし、エンジニアも「この施策はユーザーの要望からきたものですか」と問うても良いと考えている。それが無理なら仮説でもいいのだが、その仮説の根拠をできるだけ確固たるものにしておきたい。ここでも推測より計測である。
ユーザーはおそらくこんな課題を抱えているだろう、という推測をやめる。まずは実際に課題を聞く。お問い合わせや改善要望を読む。施策を考える前にこの一手間を加えることで、これから数ヶ月取り組むであろう業務、機能がユーザーが求めていない無駄なものではなく、顧客満足度の向上に繋がる仕事に変貌していく。
顧客の満足度向上が仕事に対するモチベーションを向上に繋がる
会社生活において給料アップや突然のボーナス、上司・同僚からの賞賛も嬉しいものだが、自分が行った仕事に対するお客さんの感謝が「またユーザーのためになることをしよう」というモチベーション向上に繋がる。
これは2020年の出来事だが、自分は今でも Twitter で自社で開発していたプロダクトに対する不満を書いていた有料ユーザーの方にチームでアポをとってユーザーインタビューをしたことを覚えている。要望を聞いてこちらの立場・考えを説明し、1ヶ月かけてある機能を実装した。
その後、再度リモートでのインタビューをしたところ、大変好評頂き、インタビュー後に Twitter で「新機能がとても良い」とプロダクトを宣伝してくださった。この出来事を通してリモート環境下ながらチームの一体感が増した上に、顧客の課題を解決することの実感を得た。これが本当の「仕事」だったのだ。
「顧客の声を聞く」という難しさに向き合う
ただし、現場の開発者としてはUXリサーチやユーザーインタビューで実際にプロダクトを触ってもらって声を聞くことにハードルがあることは認識している。今のプロダクトのフェーズ、ユーザーのプロダクトを使っている度合い、リモートなら画面共有の抵抗などちょっと思いつくだけでもハードルに枚挙に暇がない。
そして、そのハードルを超えて話を聞けたとしても、実はそれだけでは何を開発すればいいかわからないというのもまた現実だ。ある要望は開発者側からは一見無駄に思えたり、開発に時間がかかりすぎたり、その要望に応じても他のユーザーは喜んでくれるかわからない。だが、この難しい現実と向き合い始めた時、五里を覆っていた霧が少しだけ晴れ始めるのである。
最後に。書籍内に「うちの店はいつも人手不足だという嘆きは、仕事の生産性が低いと言っていることと同じ」という厳しい指摘がある。IT業界では人材不足が常に叫ばれているが、さて、これをどう捉えたらいいものか。この「時短の科学」に解決のヒントが書かれているかもしれない。
なお、本文中に少し触れたように、本書の教訓は エッセンシャル思考 と リーンスタートアップ で補えるかもしれないが、本書の中でも触れられているように戦略より戦術、知識ばかりの頭でっかちになるより徹底して実行することが重要と説かれている。本書では日本のサービス業における生産性向上の豊富な事例が紹介されているため、より身近に感じることができることが上記の2冊と趣を異にするところだろう。
Happy Coding 🎉
