開発プロセスの目指すべきところ - 超ウィザード級ハッカーのたのしみ

プロジェクト・マネジャーをしているわけでもないのに、開発プロセスについて誰よりも考えていると思います。残念ながら私の考えを試してみて実証する機会がないので、私の考えが正しいかは分かりません。しかし、実績ができたら開発プロセスの指南だけで十分飯の種になるのではないかと思ったりするほどです*1。

「正しい」開発プロセスなんてないと思っていますが、開発プロセスはこういうものを目指すべきなのだという考えは持っています。

開発者が製品を良くしようと思ってすることが現実に製品を優れたものにする。
開発者がすることはすべて製品を良くすると信じられることである。
開発者は作業を妨げなく行うことができる。

この３点が実現できれば開発プロセスは理想的なものになるのではないかと思っています。

製品を良くしようという思いを持たない開発者はいません。もしいるなら辞めてもらうしかないでしょう。むしろ怪しいのはマネージャーです。彼らは考えなければならないことが多い：納期、品質、売上、予算、人事、保身、etc。製品自体のことなんて考える余裕がなく、一切興味がない人もいるでしょう。それでいて三現主義とか泥臭いとか言う人は私は見下します。*2

開発者はみな製品を良くしようと思っているかもしれませんが、良いと思っていることは一般に同じではないです。そこは合わせないといけない。これが合わせられたら、開発プロセスなんて些細なことのようにも思います。どんなやり方をしてもきっと上手くいく。グチャグチャのなかでもそれなりにまともなものが出来上がるでしょう。方向さえ揃えば人間は勝手に動き出すものです。

とはいっても６割ぐらい方向を揃えるのが普通なら限界でしょう。人によって温度差もありますし、志向も違います。また、グチャグチャのなか行うと納期だとか予算だとかの壁にぶつかってしまいます。そうなったらプロジェクト・マネジャーが仕事をする必要があります。

プロジェクト・マネジメントには２つ考え方があると思っています：

人間を計算機とみなして並列計算をプログラミングすること
人間の感情を認めて気持よく働ける環境を用意すること

。私はどちらも必要なことだと思っています。

複数人で一つの処理を行うのであるから、プロジェクトというのは並列計算です。良くも悪くも人間は自然界にあるものなので、数理法則からは逃れることができません。アローダイアグラムを書いて、クリティカル・パスを見つけて、そこのボトルネックを解消するというようなことをする必要があります。また、人がするプロジェクトの場合は計算機と比べて同期コストが非常に高いという特徴があります。個人的には同期さえ上手く取れれば大抵の問題は解決されるのではないかと考えています。

人間のプログラミングとしてしてのプロジェクトマネジメントは、機械に対するプログラミングより単純です。全体像が分かっていて、個々の作業にリアリティを持てれば、プログラミング自体はそこまで難しいことではないと思います。もちろん、全体像が知ること、個々の作業にリアリティを感じることが難しいのですが、これは経験の問題です。全体像が分からないとアローダイアグラムがかけないし、個々の作業にリアリティを感じていなければパスに要する時間感覚がつかめないものです。

プロジェクトマネジメント手法はこの人間のプログラミングという観点が多いように思っています。麻雀でいうところのデジタル麻雀みたいなものです。冷酷な感じもしますが、マネジメントとは冷酷なものです。私もこういうオペレーションリサーチ的な合理主義な考えは好きです。最初に上げた３点のうち最後の「開発者は作業を妨げなく行うことができる」を実現するにはこういう数理的考え方が必要です。

私はかつてはこの考え方一辺倒でした。しかし、最近人間は感情あるものなので、気持ちよさも重視しなければならないのかと考え始めました。アナログな考え方です。開発者は多少の温度差はあれど誰しもモチベーションや誇りをもって仕事に取り組もうとしています。そういう内側から湧き出る気持ちを妨げないようにしたら、生産性は驚くほど向上するのではないかという仮説を持っています。

それについては今度書こうと思います。