プロセス改善のアプローチや考え方をトイレとアレに例えてみる

「改善したい」という話は、「開発生産性を高めたい」と同じぐらいありふれた言葉。人類は10年前も同じことを言っていた気がします。いったいどこからはじめるか？どうはじめるか？これまでの経験を元に、トイレに例えて考えてみます。

トイレをいつ作るか？

ちょっとお下品ですいませんが、こんな話を聞いたことがあります。元々は、島田紳助さんが言ってた気がします。

トイレを作ってからう○こをするか？う○こをしてからトイレを作るか？

トイレからのう○この場合、はじめに立派なトイレを作っても、ニーズを超えた機能が実装されて使われなかったりするわけです。どのぐらいの加減で作るかが難しいところ。ただ、仕組みを先に用意してからやれるのが賢い感じ。先回りして考える力が求められます。

う○こからトイレの場合、事象がもう起こっているので、最低限のニーズは考えやすいです。ただ、一度試しに何かをやると、後でキレイにする時間をとれないことが多いもの。

（ここまで書いていてちょっと連呼するのが恥ずかしくなったので、トイレをニワトリ、う○こを卵に書き換えます）

これをアジャイル開発のコンテキストに置き換えると、ニワトリ卵の場合で、ニワトリに時間がかかるのはウォーターフォールに見えます。必要なニワトリ機能を漸進的に小さく作っていくならアジャイル開発。一方で、卵ニワトリは、やってみてから考えながら進むので、リーンスタートアップでしょうか。

どちらがどうか？はプロダクトやそのプロダクトのステージに準じます。超高機能ニワトリを作るならニワトリ卵。前に事例があるのであればニワトリ卵。ニーズを探りながらやるなら卵ニワトリ。はじめはある程度、ニワトリ卵しておいて、ローンチしたら卵ニワトリにシフトとかもありえそう。

（置き換えたらわかりにくくなった気がしたので戻します）

でも、「そうやったらそうなるって、う○こする前からある程度はわかってたでしょ」ってときが多いので、性格的にはできるだけ先にトイレを作りたいタイプです。わかっていたのに炎上とかはできるだけ事前に防ぎたいもの。

それぞれのプロダクトや現場に適した方法を選び、実践するのが改善のポイントであり、必要なスキルです。「方法を選べる」に加え、それぞれの方法にい経験が裏付けられているとステキですね。

そして、トイレう○この場合（戻った！）、作り過ぎると当初の目的を失ってしまいがちで、う○こトイレの場合、あとあと手をつけにくい。こういった特徴を理解して、それぞれのアプローチを試していく必要があります。

また、トイレう○こはトップダウン、う○こトイレはボトムアップともとれる気がしました。どちらにせよ、何も考えずに「やってみよう！」ではじめてしまうと、悪い方向に進んでしまいがちなので、ある程度の方向性や意味合いは、当事者間で認識合わせしたたほうが良さそうです。