ムリ、ムダ、ムラをなくす大事な3つの考え方

残業を悪とするチームを作るだけでは全く足りない - Change The Worlds
個別最適化では残業はなくならない - Change The Worlds
残業をしない会社を作るために - GoTheDistance
残業を悪とするチームを作ろう - ひがやすを blog
SIerにてエンジニアの残業を無くす方法 - ledsunの日記
残業をなくすためにすべきこと - ひがやすを blog
と色々なところで残業をしないというスタンスの事が言われてきた。gothedistanceさんは少し別の視点で、人が手作業でやっている作業をITにやらせるというアプローチだが、自分も含めて他の人はチームの成果や生産性をあげるというアプローチを取っている。自分なりの具体的なアプローチについて、以下に記載しよう。

ムリ・ムダ・ムラ

殆どの人はトヨタ生産方式で聞いたことがあると思うが、ムリとは負荷が能力を上回っている状況、ムダとは逆に負荷が能力を下回っている状況、ムラはムリとムダの両方が混在して時間によって表れる状況を指すものだ。

トヨタ生産方式では、ムダを「付加価値を高めない各種現象や結果」と定義しており、ムダなことを排除することで、生産性をあげることも、付加価値を高めることもできる様になる。
例えば、残業をなくす為に生産性をあげるということが良く言われる。プログラマーが生産性をあげる最も近道はプログラミングスキルを向上させることだ。それはコーディングする量が少なく、メンテナンスコストも低く、また自働化*1をすることに繋がる。
が、これらも

• 少ないコーディングで実装できるのに、コーディングを大量にすることはムダである
• メンテナンスをし易く作らず、メンテナンスをし難い様にするのはムダである
• 自働化をせずに、何度もテストやデプロイを手動でするのはムダである

という具合に実は本質的にはムダ取りをしているのだ。

というわけで、ムダの排除を通じて、ムリ、ムラを排除することが大事なことがご理解できたと思う。

どの様にムダを排除するのか？

ムダを排除する為の考え方が以下の3つになる。

• 対象を小さく分割する
• 優先順位を決める
• 流用できないか考える

実例と一緒に説明した方が分かり易いと思うので、個別最適化では残業はなくならない - Change The Worldsから

• ユーザからのシステムのリリース条件として、『同時に○○件の購入要求が来ても、全て××秒以内に応答が返ること』と契約書に書いてある
• しかし、リリースまで後数日なのに、条件を全く満たせていない。このままではユーザから損害賠償として、○億要求される

を例として、説明しよう。

対象を小さく分割する

まず『対象を小さく分割する』から始める。何事も大きく捉えると時間がかかるものである。そこで、まず対象を大きく捉えるのではなく分けて捉えた方が良いだろう。
上記の事例でこの考え方を説明すると、購入要求のフローは大まかに言うと、要求パラメーターのチェック→購入前処理→購入後処理→応答といったものだった。どこに時間がかかっているのかこのままでは分からないので、《要求パラメーターのチェック》、《購入前処理》、《購入後処理》の3つに分割した。そして、同時に○○件の購入要求を投げ、どこに時間がかかっているかを調査した。その結果、3つの部分でかかっている時間は同じ程度ということが分かった。

優先順位を決める

対象を小さくしていけば、いつかは問題個所を見つけることができるが、それでは時間がかかり過ぎてしまう。そこで、大事なことは何から順に対応していくかということだ。
上記の事例でこの考え方を説明すると、3つの部分に分割することができたが、何から順に調べていくかを決める必要がある。周囲の人の作業対象は《購入前処理》だった。《購入前処理》の部分は履歴や商品の親子関係を調べる部分が含まれているので、複雑な仕組みになっていた。そのため、自分以外の人は複雑な部分に時間がかかる処理ロジックがあるのではないか？と考えて調査をしていた。
そこで自分は彼らとは異なる部分を調査することにした。それは一人で調査できる量は少ないので、彼らとは異なるアプローチをした方が良いと判断したためだ。そこで彼らが一番優先度を落としていた《要求パラメーターのチェック》の部分を更に分割して原因を調査することにした。《要求パラメーターのチェック》は前半と後半の2つに分けることにした。その結果、後半部分に処理時間の殆どがかかっていることが分かった。前半と後半はチェックしているパラメータの別はあれどほぼ同じで、大きな差は後半部分にはログ出力関数を呼んでいるということだけだった。ログ出力関数を見てみると、このソースはJavaで書かれていたのだが、Log4Jではなく、自作でファイルにログを出力する処理が書いてあった。そこにはログレベル毎に分ける処理もされておらず、ログレベルを高くしても、全ての処理のログが出力される作りになっていたのだ。つまり、処理時間が長いのはI/O待ちの為だったのだ。こうして、どこの部分が問題になっているか見つけることができた。

流用できないか考える

問題の箇所を見つけても、全て作りかえていては車輪の再発明になるかもしれないし、車輪の再発明を意図していないのであれば、それは時間のムダである。そこで、大事なことは『流用できないか考える』になる。作ることはコストがかかることで、新しく作らなくても要求が満たせるならばそれを優先した方が良い。つまり、新規に開発しなくても良くないか考えるということだ。
上記の事例でこの考え方を説明すると、ここでの要求は「処理時間が短いこと」「必要なログを出力すること」になる。Javaのプロジェクトであり、Log4Jを使えばこの要求は簡単に満たすことができる。それにこの要求はこのプロジェクト固有のコアなものではなく、全てのプロジェクトで必要となるものだ。そこで、共有ライブラリに上記の要求を満たせるものがないか探した。当然の様にLog4Jを使って実装している関数があったので、それをログ関数の部分に流用することで、修正する箇所を最小限（ログ関数の中身のみで呼び出し元には影響なし）、改修の時間も最小限にした。

他への流用

今回ムダを排除する為の考え方として以下の3つをあげた。

• 対象を小さく分割する
• 優先順位を決める
• 流用できないか考える

これは別に改修の時だけ適用できるものではなく、もっと広い範囲に適用できることはすぐに分かるだろう。例えば、新規開発で一気にFacebookの様なサービスを実装しようとするのではなく、まず最初は「いいね！」ができることを目標とする（『対象を小さく分割する』）といったものになるだろう。『対象を小さく分割する』ことができても本来必要のないものを作っていてはそれはムダになってしまう。そこで、本当に必要な機能から順に実装していく必要がある（『優先順位を決める』）。そして、必要な機能だとしても流用できるのに、全て一から作っていてはコストがムダにかかってしまう。新規に開発しなくても要求が満たせるのであれば、そちらを優先した方がムダが少なくなる（『流用できないか考える』）。

さいごに

『ムリ、ムダ、ムラをなくす大事な3つの考え方』を身につけ、日々実践していくことは誰にでもできることだ。
『ムリ、ムダ、ムラをなくす大事な3つの考え方』は特別な能力がなくてはできないものではない。
でもほんの少しだけあなた自身が努力することが必要だ。

この考え方を身につけて、皆さんの現場のムダな残業が減り、皆さんの人生がより良いものになることを祈っている。

*1:誤字ではない