目次
変化する前提で、つくるのだ。
今回は、パイロットシステムを”捨てる前提”でつくるべし、という思想が語られる「第11章：１つは捨石にするつもりで」を読み解きます。
連載記事一覧は、コチラの最下段から
1つめで成功する、なんてありえない
本章で語られるのは、「まず、パイロットシステムをつくり、そして廃棄せよ」という思想です。
これは、大規模システム開発においては必須の考え方であると説かれます。その必要性は、大規模プラントを作る際のやり方を例にとって説明されます。
化学工学技術者は、研究所ではうまくいく工程でも、工場となると一足飛びには実施できない、ということをずっと前からわかっていた。量的なスケールアップと過酷な実環境での運用経験を積むために、パイロットプラントという中間段階が必要なのだ。例えば、研究所での水の脱塩工程は、地域の水道システムで1日あたり200万ガロンの処理に対応するべく、パイロットプラントで1日あたり1万ガロンの処理能力がテストされる。
プログラミングシステム製作者にも、こうした教訓が与えられる機会はあったのだが、いまだ理解されていないようだ。
失敗できないからこそ、小規模で「ちゃんと動くかどうか確認する」ことが重要なわけですね。
19章では、違う話をしますよ！
が、以前ご紹介した19章では、違う話が出てきます。それは「捨石にする、ってのは誤りでした」というお話です。
19章では、本章（11章）での話は「ウォーターフォール型開発を前提にして、その課題を如何に克服するか」という視点で語っていたものの、その後の開発環境の変化などに鑑みて、漸増的（インクリメンタル）な開発こそが、開発成功の鍵だろう、と結論付けられます。
ウォーターフォール型開発の最大の課題は、「アーキテクト」→「インプリ」という順序が”絶対のルール”だということです。そのため、インプリが完了し、ユーザーがシステムに触れて最初の感想を述べる頃には、再構築なんてできないところまできちゃってる、わけです。
変化すること、を前提に考えよう
本章で主張されたパイロット・システムをつくり、捨てるというプロセスは、この「再構築を多少なりとも実現しよう」という思想を、ウォーターフォール型開発の中に組み込んでいたわけです。
一方、19章では、稼働するもの＝プロトタイプをつくり、それに対して徐々に機能追加していくことで「再構築したい」となった時点で、その追加中のコンポーネントに対して変更してしまえばよいではないか、と語られます。
つまり、「変化する前提で、どうやって変化を受け入れるか」という思想は変わっておらず、そのやり方（HOW）が変わっただけ、と理解するべきだと言えます。
変化に対応できる組織構造を用意する
このような「変化」に対応するために、組織構造を検討することが有効だと、ブルックス氏は述べます。
僕の古巣でもあるIBMの組織構造が例として引用されていました。（役職の名称は、僕の解釈で書き直しています）
障害は社会学的なものだ。これに打ち勝つには日頃の警戒が必要である。まず、マネージャーは往々にして年長者のことを「畏れ多くて」、実際のプログラミング作業に使ってはならないと考える。次に、管理という仕事がより高い権威を伴っている場合がある。（中略）IBMのように、昇格に関しては（中略）二重の機構を持っているところもある。対応する職位は理論上同格とされる。
この組織図のポイントは、「管理者」が「開発者」と対等である（＝決して、開発者が上ではない）と本人達にも周囲にも理解させることだとブルックス氏は説きます。
そして、組織図の中での「横移動」は、決して「昇格・昇進」ではないと理解させることが大切です。また、管理（マネジメント）側の上位職階プロジェクトマネジャーと、開発（テクノロジー）側の上位職階シニアプログラマは、能力的にも同等であるべきで、必要に応じて交換可能であることが理想です。
メンテナンスも変化だ
以上で、開発フェーズの話は終わりですが、本章では、リリース後のメンテナンスフェーズの「変化への対応」についても語られます。これがまた、一筋縄ではいきません。
プログラムメンテナンスの基本的問題は、欠陥の修正が実質的には別の欠陥を生み出す可能性（20~50%）を秘めていることだ。だから、この過程は全体として、2歩前進しては1歩下がるとなる。
「何かを直していたハズなのに、実は、新たなバグを仕込んでいる可能性がある」わけですね。また、それどころか・・・
モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース場号に対し指数的に増加する（中略）。もとのデザインの欠陥に対する修正がどんどん減少していき、その分ますます多くの労力が前回の修正によって発生した欠陥の修正に費やされるようになる。（中略）やがて、修正を加えても改善にはつながらなくなってしまう。1歩前進することで、どこかが1歩後退してしまうからだ。
より、混沌とした状況を目指して突き進んでいる可能性まである、と述べられます。いやはや。
尚、これについては、特に解決策は提示されません。それは、プログラミングというものの本来的な性質によるものだからです。
システムプログラムの作成は、エントロピーを減らす過程だから、本来準安定的なものである。他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行っても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
ビジネスだって同じだよね
今回のメインテーマである「変化するのが当たり前」という価値観は、ビジネスの世界でも同じです。絶対的に不変のものというのは、世の中に殆どありません。大抵の物事は、簡単に変化します。それに文句を言っていても進歩はありませんので、変化に対応していくことが求められます。
スタートアップ界隈で、読んでいない人はいないであろう名著「リーン・スタートアップ」は、（11章ではなく）19章と同じやり方での製品開発を推奨していますし、製品開発だけではなくビジネスそのもののピボットに関しても同じ文脈で語られます。
物事が変化する、ということを考え方の軸に据えると、戦い方も変化するわけですね。
そこで、今回のタイトルに用いた「その場に留まりたければ、走り続けなくてはならない」という言葉を思い出してください。この言葉を、皆様ご存知でしょうか？これは、鏡の国のアリスにでてくる赤の女王のセリフです。
It takes all the running you can do, to keep in the same place.
色々な解釈ができる言葉ですが、今回ご紹介したシステム開発における課題や、ビジネス運営の考え方と照らし合わせると、なかなか趣深いと思いませんか？
というところで11章の読み解きは以上です。次回は、12章：切れ味のいい道具 をご紹介します。
連載記事一覧は、コチラの最下段から
