人月の神話

タールの沼

システムの開発コストは、コンポーネントの足し算ではない…と言われても、そんなでかいシステム関わったことないから、よくわからない。システムのでかさのせいでコストが異常に増大してるパターン…うーん、あったかな。多くの場合、各コンポーネントができて、それを組み合わせれば、わりと素直に動いてた気がする。もちろん組み合わせる時に多少の想定外とかはあるけど、ちゃちゃっと修正して、問題洗い出すだけでふつうに対応できてた。システムの規模がさらに大きくなって何階層にもなってたら、組み合わせた時の問題が大きくなるというのは、なんとなくなら想像できる。 ただ、そんなに巨大なシステム(数十人から数百人のプログラマがかかわるシステム)ってなんなんだろうというのは、経験してこなかったし、たぶんこれからも経験しないで終わるのかもしれない。

そもそも現在においては、巨大なシステムを部分ごと分けて作って、それから一気にくっつけてテストするという作り方をすることは、たぶんあまり普通じゃないし、それをやる必要もない。現代では、最初から動くものを作って統合した状態で少しずつ育てていくというのがあたりまえなはず。

ブルックス本の時代と現代における大きな違いのひとつは「出荷」というものに対するスタンスの違いだと思う。ブルックスの作っていたのは、ハードウェア専用に作られた、ハードウェアと一緒に出荷することが前提のOSとかコンパイラその他といったものだ。ハードウェアとソフトウェア込みでのシステム一式として納品する先とかも決まったりしていて、スケジュールを通りに出荷することがものすごく大事だったんじゃないだろうか。

ぼくが普段扱っているような、すでに稼動しているウェブシステムだと、納期という概念があまりない。もちろん、いついつまでにこれこれをリリースするみたいなことをセールスに約束してたり、新規プロダクト立ち上げのときにビジネス状の都合で奮闘するといったこともまったくないことはないけど、基本的には動いているシステムを少しずつ改善していくという作業が主になる。すると、 見積もりというものの重要性が相対的に薄れてくる。

ただ、一方で確かにタールの沼に足を取られるような経験をしたことも何度かはある。そのようなプロジェクトでは、ビジネス上の希望と、おそらく未熟な見積もりスキルの両方から決められたデッドラインがあり、チームは寄せ集めで未成熟、アーキテクトの不在、単純な技術力不足といったいくつもの要因が重なっていたように思う。単一の要因が欠けていただけで派手に転んだプロジェクトというのは見たことがない。どんなプロジェクトでもなにかしら足りないものというのはあるものだけど、ひとつやふたつなら、みんなのアイデアとか誰かのがんばりでどうにかカバーできる。ただ、破綻したプロジェクトでは、それらの数が多すぎたように思う。ひとつやふたつの問題を工夫やがんばりで解消したところで焼石に水。つまり、後から呼ばれた外野から見ると、それらは最初から成功する見込みがまったくなかったように見える。

にも関わらず、なぜそれらのプロジェクトは走り出してしまったのか。走り出す時点で、とても成功する見込みのないひどい状態にあることに気づけなかったのか。あるいは気づいていたのに止まることができなかった？これらプロジェクトの失敗理由をブルックスの理論で説明できるだろうか。ちょっと試してみよう。(ここでは、失敗=出荷までこぎつけられなかったプロジェクトという意味で使っています)

人月の神話

まず、スケジュールを立てることの難しさを述べている「人月の神話」の話はたしかに当てはまる。事実として、それらの失敗プロジェクトにおいて、開始時に立てたスケジュールは、完全に間違っていた。ただ、付け加えるならスケジュールにさえ十分な余裕があれば問題なく完成していたかと言われると、ちょっと疑わしい。そもそもコミュニケーションはうまくいっておらず、コードと製品の品質は著しく低かった。もちろんタイトなスケジュールのために品質が下がったということもあるだろうけど、それ以前の根本的な問題があった気がしてならない。

貴族政治、民主政治、そしてシステムデザイン

「コンセプトの完全性こそ、システムデザインにおいてもっとも重要な考慮点である」

この主張は、プロジェクトの失敗についてなにか重要なことを言っている気がする。失敗したプロジェクトのいくつかでは、たしかにコンセプトの完全性がなかった。それは既存のなにかの焼き直しであり、継ぎはぎ細工であった。そういえば、すでに完成されたものの焼き直しで、ソースコードも流用できるから簡単だろうと下方に難易度が見積もられていたことも共通している。

「コンセプトの完全性を得るには、デザインが一人ないしは互いに意見が同じ少人数の頭脳グループで考え出されなければならない」

これが実践できていれば、そして、その1人ないし少人数が十分に経験を詰んだプログラマであれば、プロジェクト成功の確率はかなり上がるんじゃないだろうか。継ぎはぎで成長して一貫性もくそもないシステムを１から刷新しようとしたことが、そもそも間違いだったようにも思える。それをわかっていれば、これは難易度がものすごく高いプロジェクトであることを着手前に認識できた...のかもしれない。

セカンドシステム症候群

さきほど言ったように、いくつかのプロジェクトは、既存システムの焼き直しだった。これらは「セカンドシステム症候群」であった可能性がある。というのも、どちらも、既存システムにある機能すべてを持つことを最初から前提としてしまったからだ。最初に核となる最小の動くシステムとして作成し、そこからイテレーションを経て育てていくというのが現代のソフトウェア開発における成功パターンだと思う。ところが、失敗プロジェクトでは、既存システムで実現している盛りだくさんの機能をすべて実現することを前提としてしまった。それらは一度は実現した、はっきりと形の決まっている機能であるため、再構築は容易であると見立てた。そして短いスケジュールを組んだ。ただし、再構築を行うのはオリジナルのチームとはまったく無関係どころか、別の会社だった。1度目のシステム構築を行った開発者との連絡はまともに取れず、心もとないドキュメントとソースコードだけも頼りに再実装を行う。最初から多数の機能を急いで実現しようとしているため、一個一個のコンポーネントの仕上がりもろくに検証されず、線表にしたがって最低限の動作確認だけして表面上動いているように見えたら、できていることにされて、生煮えのまま次の機能に取りかかる。もちろんろくに検証されていないので実際には一個一個の機能やコンポーネントが多数の不具合を抱えている。隠れた、あるいは見なかったことにされた不具合はどんどん蓄積していきやがて...。焼き直しだから、既存のコードがあるから簡単にできる。これらの言葉が聞こえてきたら、警戒した方がいいかもしれない。きっと、2度目だろうが何度目だろうが、システムの作り方は変えるべきじゃないのだ。いつも最小限だが完璧に動作するシステムからはじめて、成長させていくのが１番の正攻法なんだと思う。ブルックスの言うセカンドシステム症候群は、2度目のシステムで1度目以上に機能を盛り込んでしまうことへの警句だったけど、ぼくの経験からすると、1度目と同等を最初から目指している時点で危険なんだと思う。

命令を伝える

この章は、いかにしてコンセプトの完全性を達成するかについて述べている。失敗プロジェクトでは、ドキュメントがないことはなかったが、とても十分なドキュメントとは言えなかった。そしてドキュメントを書いた人とのコミュニケーションも困難だった。さらに、既存システムのコードがドキュメントの代替になると考えていた節がある。システム構築においてコードはドキュメントの代替にはならないと思う。ひとつには、コードに設計が内包されているのは事実だけど、コードは設計を伝えるには非効率的なんだと思う。コードの質が低い場合にはとくにそうだ。それから、コードを読む能力というのも人によってまちまちなのだから、ある程度の人海戦術的な局面を想定するのであれば、コード＝ドキュメントという考えはますます成り立たないだろう。まともなドキュメントなしに多人数で開発するのは、スケールしないし、精度も効率も悪すぎる。

バベルの塔は、なぜ失敗に終わったか

コミュニケーションの問題は、間違いなくあった。失敗プロジェクトにおいても、ブルックスの推奨するような進捗や問題共有のための定例会議や、日常的なチャットベースでのコミュニケーションはあった。それにも関わらず十分なコミュニケーションが行われてはいなかったように思われる。一つには、開発は会社をまたがって行われ、発注と受注という主従関係で分断されていた。互いの組織内では活発なコミュニケーションが行われていたかもしれないが、組織を横断してのコミュニケーションは限定される。また、開発側は、問題を認識していてもそれをそのまま共有する動機はなくギリギリまで組織内部で対処しようとするため、別の組織からはなかなか中で起きている問題が見えてこない。ブルックスも指摘するように、組織におけるコミュニケーションの構造は、(組織の権限構造が木構造であるのとは裏腹に)ネットワーク構造なのだけど、このネットワークのノードを繋ぐ「点線」が十分でなかったとは言えるのかもしれない。

この事例だけ見ると、複数の会社が分担して開発することがそもそもよくないとも取られかねないけど、実際には、複数の外注会社が協力して開発して、それでもきちんとシステムを作り上げられたプロジェクトももちろんある。だから、これは唯一の原因ではなく、あくまでプロジェクトが抱えていたたくさんの問題のうちのひとつなんだろうと思う。体験的には、正常にまわっていたプロジェクトでは、組織間の壁が薄く、カジュアルにやりとりが行われていたような気がする。それから、アーキテクトがきちんと全体的なタスクの状況と問題を把握できていることも重要に思える。

一つは捨て石にするつもりで

変化に備えることの重要性を述べている。失敗プロジェクトでは、実現すべき仕様は最初から変化していないため、この章の内容はあたらない。変化が要求されなくともプロジェクトは失敗する。

破局を生み出すこと

この章は、まさになにがプロジェクトの破綻を生み出すのか、どう回避すべきなのかについて説明している。失敗プロジェクトを振り返るのになにか重要な知見を与えてくれるはずだ。ブルックスはマイルストーンを持つことが必要だと言っている。もちろん失敗プロジェクトにおいてもマイルストーンは存在した。だけど、それはブルックスの言う「ナイフの刃のような鋭さをもって定義」されてはいなかった。明確なマイルストーンとは、「コーティングは90%完了した」というような感覚的なものではなく、誰でも測定できる事実であるべきということだ。だから、それはチェックリストとして、例えば「ユーザーはウェブとスマホの両方から複数の商品を出品・取消できる」とか「何万件のデータに対して1秒以内に検索が完了する」というような形で定義されるものの羅列になるんだと思う。明確でないと、遅れに気づくこともできず、マイルストーンが意味をなさなくなってしまう。また、ブルックスはクリティカル法を用いてスケジュール管理することを推奨している。失敗プロジェクトには、「ナイフのような」マイルストーンも、クリティカルパス図も存在しなかった。それらが存在していれば、スケジュールの遅延はきっともっと早くにあぶり出されていた………ん？いやいやいやそんなものは無くてもスケジュールの遅れは明明白白だった。これらの管理ツールはきちんと使えれば有効なものではあるだろうが、それだけでプロジェクトの破綻を防げたとは到底思えない。