それ、誰のためにつくってるの？
本日は、順番に読み解いてきた人月の神話の”最後の章”「第15章：もう1つの顔」を解説します。（16章~19章は、連載の前半で解説しています）
連載記事一覧は、コチラの最下段から
文書作成の”実践”を解説する
なんか、こう、頭に入ってこない文章なのですが（僕の頭が悪いのかもしれませんが）、本章のテーマはこの一文に集約されていると思います。
数年にわたって私は、優れた文書の必要性と正当性についてソフトウェアエンジニアリングの授業で講義し、これを熱心かつ雄弁に勧めてきた。しかし成果は上がらなかった。適切な文書作成の方法は学習しても、実践しようという熱意がないために失敗したのだろうと私は推測した。そこで、（中略）実際にどのように実践するのかを示した。これはずっとうまくいっている。というわけで、ここからは優れた文書の作成の「しかた」をあまり熱心に勧めたり集中して説明したりはしないことにする。
僕の理解のために、端的にまとめると、
- 文書は必要だと講義してきた→成果は上がらない
- 理由は”文書作成”の知識ではなく、”実践の熱意”が無いのだろう→その通りだった
- ”実践”してみせた→うまくいった
- だから、本章では”文書の作成方法”はもう述べない（”実践”してみせる）
ということになります（よね？）。
「システム」は誰のためか？
さて、ここでいう「文書」ですが、これまでに議論されてきた「文書」とは位置づけが大きく異なります。本章のタイトルが「もう1つの顔」が指し示すように、これまでは「作り手の側からみた文書」の話をしていましたが、この章では「使い手（ユーザー）の側からみた文書」のお話となります。
これは、至極当然な話で、システムとは作り手のためにあるのではなく、使い手のためにあるのです。如何にしてうまくつくりあげるか、は非常に重要ですが、しっかり使ってもらうこと、がより重要なのは言うまでもありません。
「動かないシステム・動かないコンピュータ」という表現は、大きな問題として取り上げられていますが、それよりも頻度高く、日常的に起こっている問題は「使われないシステム」です。コチラの記事でも解説しましたが、システムは所詮システムですし、ツールは所詮ツールです。それ以上でも以下でもありません。それを使って、なんらかの結果につなげていくのは人間の仕事です。（関連記事：OUTPUTとOUTCOME）
ユーザーのための文書は、目的から始めよ
では、そんな「ユーザーのためのシステム、のための文書」はどのようにあるべきなのでしょうか。引用します。
各利用者にはプログラムの散文的な記述が必要だ。ほとんどの文書は概要の説明が十分でない時点で落第である。樹木についての説明があり、樹皮や葉の注釈もあるのだが、森の地図が無い。役立つ散文的記述を核には、遠くに立ってみてからゆっくり近づくことだ。
そうなのです。システム文書に限らず、多くの文書は「目的」を語りません。いきなり、個別事象を語り始めるのです。なぜそんなことになるのか？ 多くの場合、人は「自分の考えた順番」と「人に説明するのに適した順番」が異なるということに気づいていないからです。大抵の人は、いろんな個別具体的な物事をしっかりと理解してから、全体を組み立てます。しかし、人に説明するときには、全体を説明してから枝葉に落ちていくことが重要です。（どうしても個別具体的なことから話を始めたいのならば、自分が考えたのと同じだけの時間をかけて、共に悩み、共に苦しんで、同じ全体像に至るように手順を踏むしかありません。まぁ、それが必要な場合も時にはありますけどね。）
これは、第3章や、第4章などで、口酸っぱく語られてきた「コンセプトの完全性」、あるいは13章の「トップダウンデザイン」に相通ずる話です。システムが、どういう思想の下に、何を実現するためにつくられているのかを利用者は理解すべきです。
もちろん、現実的には、裏側に隠された部分への理解は不要で、表に見える部分だけ理解すればよいでしょう。しかし、それでも「GUIは何を目的として設計されたのか」であるとか「iPhoneはどういう使われ方を想定し、どういう価値を提供するために生み出されたのか」であるとかを理解してもらうことは、ユーザーにとっても、作り手にとっても、時間を使う価値があると言えます。
もっと高度な”利用”も想定しよう
とはいえ、目的だけが書いてあればよいわけではなく、そのほかにも実行環境や、入出力フォーマットなどが記載されるべきとブルックス氏は説きます。それらも重要ですが（まぁ、現在のGUI主流の世界においては、実行環境が書いてあれば十分なのかもしれませんが）、その先にある「更なる高度な利用者」も想定するべきだと、本書は続けます。
使用方法の説明には、正常に実行されていることがどうしたらわかるか、ということについての記述が補足されていなければならない。これはつまりテストケースのことだ。
出荷されるプログラムのコピー全てに、オリジナルの正しいコピーだということを利用者に保障するため、（中略）何らかの簡単なテストケースが含まれていなければならない。
現代において、多くのユーザーは「正常に実行されているかどうか」を検証することはないでしょうが、本来的には、上記のようなテストケースがあってしかるべきでしょうね。
プログラムを改良したり修正したりするには、これまでより相当多くの情報が必要になる。（中略）必要なのは、今度は内部構造についての明白で要領を得た概要なのだ。
さらに、プログラムを修正するような、やや特殊な使い方をする場合には、より詳細な情報が必要になります。
これも、別にシステム文書に限った話ではありません。例えば、戦略コンサルティングの資料は「読めばわかる」資料になっている必要があります。良くある誤解として「字が多い資料はダメだ」というお話がありますが、それはケースバイケースです。戦略コンサルティングプロジェクトのパワーポイント資料は、字が細かく、たくさん書きこまれていることが非常に多いです。（関連記事：文字が多いパワーポイントは本当にダメなのか）
なぜ、そんなに細かいのか。理由は2つです。ひとつめは、「直接説明を聞いていない人が読んでも、何が書いてあるのかを理解できなければいけないから」です。まさに、文書としての役割の基本ですね。（これは、第6章の解説でも述べたとおりです。）ふたつめは、「その戦略・施策を実行する際に、しっかりと共感し、自ら動こうと思ってもらわないといけないから」です。多くの場合、施策を考える人と、施策を実行する人は別です。戦略コンサルタントは施策を考える人と共に考えますが、実行する人は検討経緯などを知りません。その状況で「書いてあることを理解する」だけでは不十分で、「やろうと思う」ことが肝心なのです。そうすると、「経緯」「理由」「データの裏付け」などが、きちんと書き込まれていることが重要です。つまり、現場の担当者が”自分なりに具体化し、実行する”ための材料を揃えておくわけです。
このように「文書」は、どのような場合であっても、それを読む人のことを慮って記述することが求められるのです。
読み解き、これにて終了。
以上をもって、人月の神話の読み解きは終了です。第0回を含めると、22回連載の長丁場となってしまいましたが、お付き合いいただきましてありがとうございました。
次回、総まとめとして本書「人月の神話」の現代における価値に関する私見を述べさせていただいて、連載完結とさせていただきたいと思います。
連載記事一覧は、コチラの最下段から
