第7回：「プログラムを書く」と「システムを作る」は別物だ｜本気で読み解く”人月の神話”（第1章「タールの沼」）

「システム製品」として納品するのは、死ぬほど大変

人月の神話【20周年増訂 新装版】

前回までは、16章以降の「全体概要」および「情報UPDATE」を読み解いてきましたが、今回からは、しっかりと「本編」に踏み込んでいきたいと思います。宜しくお願いします。

連載記事一覧は、コチラの最下段から

プログラムを「システム」「製品」にするのは大変なこと

プログラムをつくる、というと、ハリウッド映画などにでてくるような”天才プログラマー”がちゃちゃちゃっと作ってしまえば早そうに感じますよね。本書でも、それは一つの真実である、と述べます。

しかし、たいへん残念なことに、「プログラム」をつくることと「システム」をつくること、あるいは、「製品」をつくることは、絶望的なまでに別物です。

上図は、本書の内容を、ほぼそのまま転記しました。言葉でも解説しておきます。

• プログラムを作る（左上）ことに比べて、プラグラム製品を作る（左下）ために投下すべきコストは3倍になる。【縦移動】
• プログラムを作る（左上）ことに比べて、プログラミングシステムを作る（右上）ために投下すべきコストも、3倍になる。【横移動】
• よって、プログラムを作る（左上）ことに比べて、プログラミングシステム製品を作る(右下）ために投下すべきコストは、3×3＝9倍となる。【縦＋横移動】

このうち【縦移動】は、「だれでもテスト・修正・拡張が可能なプログラム」を作ることを意味し、「多くの稼働環境で、多くのデータの組み合わせに対して使用することができる」ということが求められます。そのために、プログラムそのものが”一般的な作り方”で書かれていることが求められたり、プログラムのテストが”高い信頼性”を担保できるレベルまで実行されていなければならなかったり、さらには、十分な”文書”が添付されている必要があったりしますので、「3倍のコストがかかる」わけです。

一方、【横移動】は、そのプログラムが”単体”としての役割から、”コンポーネント”としての役割に脱皮することを意味します。そうすると、他のコンポーネントとの関係性の中で機能する必要があります。これは、「すべての入出力が的確に定義されたインターフェースを持つ構文（シンタックス）およびコマンドの語義（背マンティクス）に準拠するように書かれていなければならない」ということであり、また「メモリスペースや入出力装置、コンピュータ時間といったリソース（資源）を定められた量だけ使用するようにデザインされていなければならない」ということです。そうすると、他のコンポーネントとの結合テスト・統合テストが求められますので、これもまた「3倍のコストがかかる」こととなります。

右下の「プログラミングシステム製品」は、その両方を行わなければならないわけですので、まぁ、9倍のコストが必要というのも納得できます。

この、残酷なほどにコストがかかる「プログラミングシステム製品」の開発こそが、踏み出す方向を一歩間違っただけで、二度と身動きの取れない”タールの沼”です。決して、普通の「プログラムを作る」ということがタールの沼なわけじゃありませんので、そこのところは、ぜひ誤解なきよう！

プログラミングって楽しいの？苦しいの？

続く後半では、プログラミングという行為そのものの、楽しさと苦しさについて解説されます。まずは、ザックリ纏めたものをご覧いただきましょう。

「喜び」については、まぁ、上図の内容をご一読いただければ良いかなと思います。ここでは「苦しみ」の方に着目しておきましょう。

• システムは、完璧につくらないと動きません。「一字一句間違ってはいけない」ということは、創作活動には適さない特性です。
• 目的やリソースは、多くの場合、”誰か”に勝手に決められています。これもまた、創作するという楽しみとは相反する制約です。
• バグを潰しこむという作業も「単純労働」で、しかも、「永遠に終わらない作業」です。これは、ひとつめの「間違ってはいけない」というのと根源的には同じ問題ですが、「一見動いていてもダメ」というものを検知して潰しこむのは、なかなか精神的につかれる仕事です。
• 最後に、そこまでして作りこんでも、完成したときには「時代遅れになっている（と感じる）」というのは、非常に悲しい現実です。（システム開発のご経験が無い方は、車やパソコンを買った時にも「買った直後から、時代遅れ感」がでてくることを想像していただくと、イメージしやすいかなと思います。）

尚、この「作る苦しみ」は、自分が使うプログラムを書くときには、さして問題になりません。本稿の前半で述べた「システム」「製品」あるいは「システム製品」を作る際に、顕著に表れてきます。そして、それこそが、システム開発を「タールの沼」に変えてしまう最大の元凶なのかもしれませんね。

さて、次回は、不朽の名作である本書のタイトルと同じことばを章題に持つ「第二章：人月の神話」を解説します。どうぞお楽しみに。

連載記事一覧は、コチラの最下段から