書き手だけが知っている

セミナーや人の話を聞いて新しい知識を学んだ時には、その感想とかコメントを簡単にまとめて記録に残すようにしている（ブログに載せている情報もその一例だ）。また、会議や講演のように後から情報を読み直せないものは、話の内容を延々とメモした上で、それを振り返りつつ要点をまとめるようにしている。読書の感想文、出張報告書とか、開発プロジェクト報告書なども同じで、手間と時間はかかるけど必ず文章という形で保存している。

私見だけど、他人の話でもそれを自分でノートに取ることで記憶に刻み込まれ、より理解が深まるように思う。1時間にも及ぶ話を聞いて理解するのは簡単だけど、その内容を全部覚えるのは大変だ。その直後なら話の印象が残っているのでアレコレと感想を言えても、1週間経って同じ話を出来る人はそう多くないだろう。だからこそ、話の内容をメモにとって確実に記憶へ残す手続きが必要になるのだ。自分の手を動かしてノートを取る意味は、実はそんな記憶の定着化とか、後で振り返った時に思い出すための材料としての役割に有るのだと思う。

では、話が無くて最初から文字情報が与えられた場合はどうなるか？例えば、学生時代に誰かのノートをコピーして試験に臨んだ人も多いと思うけど、ノートに書かれた事だけを読んでも、実はあまり理解できないことが多い。全く同じ内容のノートを持っているのに、授業に出てノートを取った学生はテストの点数が高くて、コピーを読んだ学生は低い点数だったりするが、講義の最中に先生が話した事を補完する意味としてノートは存在するのであり、初めからその補完情報にアクセスしても本質的な内容は分からないものなのだ。

同じことがソフトウェア開発の仕様書にも言えるのではないかと思う。仕様書を書く人は、資料を書き上げるためにいろいろ考えているし、適切な仕様を決めるために議論を行ったり、必要な情報を集めるために関連資料に目を通したり、分かりやすい記載にするために図面を入れたり、何度も推敲を重ねて一つの文書を仕上げる。だからこそ、仕様書に記載された表面的な情報だけではなく、仕様書には出てこない背景知識等も分かっており、対象となる内容に対する理解は必然的に深くなる。その一方で、仕様書を読む方は、書き手に比べると読んで考える量が少ないし、書かれた内容の裏付けを取るために自分で調査するわけでも無いし、書かれた内容に関する議論も行わないので、どうしても理解度が高くならない。そんな理解度のギャップが、生みだされるソフトウェアに影響してくると思う。（定量的な解析をした訳ではないので、あくまでも感覚的な話）

そんな訳で今回の話の結論は、「この仕様書に基づいてソフトを作れ」と要求された側の理解度は、仕様書を書いた側の理解度には及ばない、ということ。発注者の期待するシステムが出来上がってこないのは、その理解度の差が表れた結果に過ぎないと思う。仕様書に記載漏れが生じないように注意しましょう、なんて言うのは問題の対処療法に過ぎず、仕様書という資料でしか情報がやり取りされないプロジェクトの進め方そのものに、根本的な問題が有るのではないかと感じている。