第19回：プログラムを書いても、動くとは限らない｜本気で読み解く”人月の神話”（第13章「全体と部分」）

「動く」を担保するには「思想」が重要

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

今回は、「第13章：全体と部分」を読み解きます。本章では、コードのカタマリを、きちんと機能を果たすシステムとして成立させるための重要なステップである「デバッグ」について語られます。

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

全体＝システム、部分＝コンポーネント

本章のタイトル「全体と部分」の、「全体」は統合されたシステム全体をさします。そして「部分」はそれを構成する個別のコンポーネントです。

そして、その「全体」と「部分」それぞれで、どのように「デバッグ」を行っていくべきかについて述べられるわけですが、細かい部分はビジネス側の住人にはあまり関係が無いので、割愛したいと思います。（興味のある方は、ぜひ、書籍をお読みください。）

細かなデバッグのノウハウの前に、非常に重要なことがあります。それは、「デバッグの思想」です。本章は、3つの節に分かれていますが、その1節目が「バグを取り除くデザイン」つまり、デバッグの思想ですね。2つ目は「コンポーネントのデバッグ」すなわち部分のデバッグであり、3つ目は「システムデバッグ」すなわち全体のデバッグです。今回は、この1節目について読み解いていきます。

デバッグは、そもそもの思想が大切

デバッグのための思想として、4つの手法が述べられます。

• バグ検査ができる定義にする
• 仕様書をテストする
• トップダウンデザイン
• 構造化プログラミング

簡潔に解説すると

• バグ検査ができる定義にする：コンポーネントをつくる人々の「前提」を揃えることが重要。慎重に機能を定義し、それに沿って細かく仕様書を作ることが大前提。
• 仕様書をテストする：しかし、仕様書そのものが間違っていてはどうしようもない。外部のテストグループが「仕様書をテストする」という手順を踏むべき。これにより、都合の良い解釈の余地を潰しこめる。
• トップダウンデザイン：デザインを一連の洗練していくステップと捉える。大まかな定義からはじめて、細かいステップに分割していく。個別のモジュールを洗練していく作業を進める中で、トップレベルへの変更の要否を見極めて、システム全体を洗練させる。
• 構造化プログラミング：DO-WHILEとIF-THEN-ELSEで記述する。GOTO文の”無節操な”使用は悪であることを理解する。但し、重要なのは個別の分岐文の書き方の問題ではなく、制御構造全体として考えること。

4つ目の構造化プログラミングは、まぁ置いておくとして、最初の3つは”ビジネス領域”においても非常に示唆深いです。

全体整合性を持って、実効性を担保せよ

では、この3つの「デバッグの思想」の実現手法を、ビジネス領域に転用して考えてみましょう。

1．バグ検査ができる定義にする

まず、「バグ検査ができる定義にする」ですが、ビジネスにおいても、”前提を揃える”ことは非常に大切です。

要約すれば、製品に対するコンセプトの完全性こそが、製品を使いやすくするばかりでなく、構築を容易にしてバグから逃れやすくもするのである。

何らかの戦略を立てる、もしくは、新たなビジネスモデルを企画する、という際に、この「前提」決まっていることが重要です。

良くある失敗として「個別のKPIが先に決まっていて、大上段の目的・目標が定まっていない」であるとか、「個別の戦術が先にあり、それが”制約”になってしまっている」であるとか、そもそも「”やる”ということは決まっているが、なんのためにやるのかはよくわかっていない」というようなことがあります。

この状況だと、前提が揃っていないわけですから、個別の戦術や施策の間での整合性をとることは不可能です。そもそもの「コンセプトの策定と浸透」が大切だと言えます。

2．仕様書をテストする

続いて、「仕様書をテストする」です。ビジネスにおいては、想定している状況が、本当に正しいのか？を考える、ということになります。

これも、実ビジネスではおろそかにされがちです。いわゆる「仮説検証」とはコレにあたりますが、「仮説＝思い付き」という誤解があるためか、いまひとつビジネスの現場に浸透していません。何かを実現するためには、まず、仮説（こういうことになるのではないか？）を立てて、そのために必要な条件（反対にいえば、何が足りなければ、その仮説は成立しないのか）を洗い出し、その条件が実際にその通りになるのかを確認していく作業が必要です。これは「仕様書が正しいかどうかをチェックする」のと同じです。

戦略を立てて、その戦略の実効性を（机上であるとしても）考えてみることで「やってみて失敗した」という場合に、何が間違っていたのかを理解し、次につなぐことができます。しかし、戦略の実効性を検証しないまま走り出すと、戦略そのものの考え方が間違っていたのか、前提条件が間違っていたのか、実行の方法間違っていたのかを理解することはできないでしょう。

3．トップダウンデザイン

最後に、「トップダウンデザイン」です。ビジネスに当てはめると、先ほど述べた「バグ検査ができる定義」の話と裏表の話と言えます。

まず、そもそも何をしたいのか？何のために行うのか？を明確にするのがスタートです。そして、その理想形を実現するために、どういう作業（＝タスク）が必要なのかを考えていくことになります。それらの作業は、それぞれに「実行可能かどうか」「実行のためには、どんな障壁を超えなければならないのか」という視点で、”洗練”されていく必要があります。

一方、この個別の障壁を洗い出していく中で、クリティカルな壁にぶつかることもあります。これに対する対処法も「トップダウンデザイン」に記載されている方法で対応できます。

ステップごとの洗練というプロセスは、予想外に混乱した詳細に直面した場合、後戻りしたり、トップレベルを破棄し、全く最初からやり直すことをしないという意味ではない。実際、そういうことはしょっちゅう起こるものだ。しかしこうすれば、ひどいデザインを廃棄してやり直すべきタイミングと理由をはるかに理解しやすくなる。多くの貧弱なシステムは、まずい基本デザインを化粧品で塗り固めて救い上げようとした結果の産物だ。トップダウンのデザインでは、こうした誘惑も少なくできる。

つまり、戦略を実行計画に落とし込む過程で、仮説検証を行っていくことになるわけですね。

鍵は、戦略仮説の立案・検証だ

この「デバッグの思想」をビジネス領域に転用した結果は、以下の流れにまとめることができます。

• まず、全体の方向性（戦略、ミッション）を決める　＝バグ検査ができる定義にする
• その戦略を実行するための必要な要素・条件を洗い出し、それらがあれば本当に「戦略」が達成可能かを考える　＝仕様書をテストする
• 続いて、その方向性を実行計画に落とし込みむ。その際、常に「これは実行可能か」を念頭に置きながら詳細化・具体化を進める　＝トップダウンデザイン
• 当然ながら、本来の目的である「戦略」との方向性に差異が無いことを、常に確認しながら進める　＝バグ検査ができる定義にする
• 万が一、実行可能ではない・障壁が高い、あるいは、目指す戦略と乖離してしまう、という事があった場合は、そのレベルのやり直しをすべきか、あるいは、上位の階層まで立ち返って方向性を変更すべきかを検討する　＝トップダウンデザイン

要するに、「最初に戦略（の仮説）を持つこと」「その仮説を、常に検証すること（戦略レベルでも、実行施策のレベルでも）」が大切なのです。そして、そのためには、本章で説かれているように、「バグ検査ができる定義、即ち、そもそもの狙い・コンセプトが明確に定められていること」必須になります。

これまで、様々な戦略コンサルティングプロジェクトに携わってきましたが、往々にして「何のためにやるのかが定まっていない」という状況に出会います。これは、日々のやるべきことの延長線上に戦略（のようなもの）を定義しようとしてしまうことが原因です。戦略とは本来”勝ち”の定義であり、戦術はその”勝ち”を実現するために何をするかを考えることを意味します。にもかかわらず、日々のやるべきこと＝戦術を積み上げて、戦略（のようなもの）を作り上げるのは「自分が到達できると自信をもって言えるものをゴールに据える」というお手盛りなゴール設定と言えるでしょう。絶対に避けるべきです。

当然ながら、システムそのものも「何を成し遂げたいのかという戦略」という達成すべき目的があって初めて「何を作るのか」が決まるわけです。（関連記事：上流（ビジネス）と下流（システム）の切り分け）

僕が、本書「人月の神話」はシステム開発のみならず普遍的に使える教訓に満ち溢れていると感じているのは、本初の題材であるシステム開発が、そもそも戦略を実現するための一要素だからなのかもしれません。

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