ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門：プロジェクト成功確率向上の近道とは？（1）（1/2 ページ）

ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は「Joelの機能仕様書」のポイントを解説する。

[寺田英雄，株式会社オープンストリーム CTO]

連載目次

はじめに

　本連載では、ITシステム開発がビジネスに貢献していくために必要な、最も基本的な条件である“システム開発の成功”につながるいくつかのポイントを紹介します。

　筆者は、さまざまなコンピューターシステム開発に長年携わってきたソフトウェア技術者ですが、この連載では、あえて技術的ではない話題を中心に述べます。というのも、技術論だけではシステム開発が成功する条件としては不十分ですし、すでにたくさんの優れた技術論が各方面で展開されています。あらためてそこ に何かを付け加えるよりも、別の観点の話題を取り上げた方が面白いのではないかと考えたためです。

　主な内容は、ドキュメンテーションに関する話題と、開発生産性に関する話題を予定しています。

　本連載の対象読者は、主に利用者からの依頼を受けてシステム開発を行うエンジニアやマネージャーの方々です。内製・受託は問いませんが、システムの開発側と利用側が別々の組織・主体となっている体制の下で、開発側として仕事をしている人を想定しています。また、そうした開発者と一緒に仕事をする人にも参考になると思います。

ITシステム開発の問題点

　ITシステムの開発の成功率については諸説あります。例えばIPA SEC（情報処理推進機構 ソフトウェア高信頼化センター）が発行している『ソフトウェア開発データ白書2014-2015』によれば、開発規模や内容により多少のばらつきはありますが、おおむね成功率は70％程度となっています。つまり、30％程度のプロジェクトが失敗していることになります（ちなみに筆者が所属している会社では、失敗率はこれよりずっと低いです。念のため）。

　この白書では、失敗の原因については語られていませんが、筆者は「その原因の多くは、ソフトウェア技術以外の所にある」と実感しています。インフラ・DB設計やプログラミングなどの、いわゆる純粋に技術的な問題“だけ”が原因で失敗している例はあまり見たことがありません。技術的な問題による失敗が少ないのは、おそらくプロジェクトに着手するかどうかを判断する最初の段階で、その開発チームの技術力に見合わないプロジェクトは断念する場合が多いためでしょう。

　むしろ失敗の原因として一番多いと感じるのが、コミュニケーションの問題です。技術やその他の要因と複合している場合もありますが、問題のあるプロジェクトの多くでコミュニケーションの失敗が起こっています。特に深刻な問題に陥っているプロジェクトでは、プロジェクトの関係者の（利用側メンバー、開発側メンバーなど）が行っているコミュニケーションにもほぼ間違いなく深刻な問題が起きていると言っていいでしょう。

コミュニケーションの失敗とは

　ここで、念のため明確にしておきましょう。本稿におけるコミュニケーションの失敗とは、「システムの利用側が欲しいと思っていたシステム仕様（要求仕様）が、開発側が実現したシステム仕様（実現仕様）と合致しないこと」を意味します。システム開発では、会議、立ち話、電話、メール、チャット、SNS、契約書、仕様書……など、さまざまなスタイルでコミュニケーションが行われますが、もしそれらがうまくいかなければ最終結果として要求仕様と実現仕様の不一致が起こるからです。

　このことを非常に分かりやすく示した風刺漫画（？）が数年前に流行したことがあります（図1）。なかなかうまく核心を突いていて、思わず笑って（苦笑して）しまうのですが、現実のプロジェクトでこんなことが起こったら、確実に大問題になってしまうでしょう。

図1　コミュニケーションの失敗は仕様の不一致として現れる（「顧客が本当に必要だったものとは - ニコニコ大百科」より引用）

コミュニケーションの失敗を防ぐには？

　では、具体的な方法として、こうしたコミュニケーションの失敗を防いでいくにはどうしたらよいのでしょうか。筆者の持論は「ドキュメントを柱にしたコミュニケーションが最も効果的な方法である」というものです。

　「何だ、ドキュメントか……」と思われる方がいるかもしれません。確かに、「ドキュメントを柱にしたコミュニケーション」は何ら新しい提案ではありません。しかし、ドキュメントは定期的に見直しておくべき重要な課題です。IT技術者は、ともすれば華々しい最新技術にばかり目を奪われがちですが、どのような最新技術を使おうとも、人間同士が協働して作り上げるソフトウェア開発では、正確なコミュニケーションが不可欠であり、そのための道具としてドキュメントより優れたものが現状存在しません。

　また、「コミュニケーションといえば会話が大事じゃないの？」と思われるかもしれません。確かに、会話はコミュニケーションの基本ですが、システム開発のような複雑な集団活動を目的にしている場合は、会話だけがコミュニケーションの手段となるのは危険過ぎます。会話の結果をドキュメントとして文字に“定着”させない限り、大勢の人たちが誤解なく情報を共有することは不可能だからです。またトータルコストとして考えた場合も、ドキュメント不在のコミュニケーションは無駄なコストを招きます。

どんなドキュメントが必要か

　本連載では、開発側が作成すべきドキュメントのうち、実際に役に立ち、開発者を助けてくれる実践的ツールとしてのドキュメントについて述べていきます。

　なお本連載では、受託開発などにおいて顧客との契約で定められた「納品物となるドキュメント」の話は扱わないことにします。納品用のドキュメントは書式・体裁や分量などが指定されていたり、“本音”を書きにくかったりするので、本連載で説明したいドキュメントとは主旨が異なることが多いためです（もちろん顧客と合意できるなら、本連載で紹介するようなドキュメントを納品するのも当然アリです）。

　筆者がお勧めしたいドキュメントは以下の3種類です。

1. Joelの機能仕様書
2. Design Doc
3. 議事録

　この3つを使いこなせるようになれば、開発に失敗する確率は非常に小さくなると思います。ぜひともマスターしてほしいドキュメントです。

　というわけで、本連載ではこの3つのドキュメントについて、順番に説明していきたいと思います。まずは1．の「Joelの機能仕様書」から見ていきましょう。

実用的な仕様書の必要性

　アジャイル推進派の人たちや、その他の新しいソフトウェア工学を提唱する人たちにたびたび批判されているように、古典的な完全主義的な仕様書は、（一部の例外を除いて）現代では「無意味になった」と言えるでしょう。

　完全主義的な仕様とは、あらゆる詳細な項目を完全に網羅し、論理的に矛盾のない形で表現した“分厚い”ドキュメントのことです。このような完全主義の仕様書は、「これさえ見れば全てが分かる」という意味で理想的なものですが、作成やメンテナンスに莫大な費用と時間がかかるため、現代のビジネススピードの中で扱うのはかなり難しいでしょう。

　しかし、完全主義が困難だからといって、仕様書軽視主義になるのも間違っています。

　仕様書を書かなくても何とかなるのは、よほど特殊な場合、例えば既知のシステムの焼き直しができる場合などだけです。普通のシステム開発では何かしら新たな課題や要素が含まれています。そうした場合に仕様書を書かずにいきなりコーディングしてはいけません。それは（後述の例のように）、確実に生産性を低下させるだけではなく、品質や性能が劣るコードを生み出すことになります。

　従って、私たちは、完全主義でも軽視主義でもない実用的で本当に役に立つ仕様書の書き方を手に入れる必要があります。そのような仕様書として筆者がお勧めしたいのが、ジョエル・スポルスキ氏流の機能仕様書です。（以下、「Joelの機能仕様書」と表記することにします。）