連載
開発をもっと楽にするNAgileの基本思想

第2回 伝わるコミュニケーションとは

―アジャイル開発ではドキュメントを書かないって本当？ Part II―

前回は、井坂 十蔵氏のところへ行ってもらったな。NAgileの5つの価値の中から、「コミュニケーション」の話が聞けたことと思う。

はい！ 十蔵さん、「また今度いっしょに茶ぁでもしばきまひょか」いうてはりました。

……そうか。それはよかった。

　さて。今回も引き続き「コミュニケーション」の話だ。「コミュニケーション」は、ソフトウェア開発を成功させるための鍵だからな。

　まずは、前回の井坂 十蔵氏の話を振り返るところから始めよう。

前回のタイトルは、「アジャイル開発ではドキュメントを書かないって本当？」だったな。これについて、もう一度考えてみよう。

はい！ 十蔵さん、「アジャイルでは、ソース・コードが大事でドキュメントが要らん、いうわけやない。ソース・コードも大事なドキュメントの一部というてるだけなんや」いうてはりました。

……そうか。

　もちろん、「アジャイル開発ではドキュメントを書かない」なんてことはない。アジャイル開発でも、必要なドキュメントは書く。ドキュメントは重要だ。

　だが、本当に大切なのは、コミュニケーションという価値にコミットすることだ。

　「そのドキュメントによって、コミュニケーションという価値が上がったか？」が重要だ。ドキュメントを書くこと自体が重要なのではない。

はい！ 十蔵さんも、そないいうてはりました。

……そうか。よかったな。

　……悪い。最初にいえばよかったんだが、その中途半端な関西弁やめてくれないか。調子が狂う。

……はい。

もう一度あらためてお前にいっておこう。

　きちんとしたドキュメントを書くことを試そうともせず、「アジャイルだからドキュメントは不要だ」などというべきではない。

　もちろん、不要なドキュメントというのはあるだろう。しかし、「守・破・離」の原則からいっても、最初はドキュメントをきちんと書いた方がよい。

　まずはドキュメントをちゃんと書く、ということを基本にするところから始めるのがよいだろう。

だが、すべての情報をドキュメントで表せばコミュニケーションがうまくいく、というわけでもない。

　以下で、ありがちな仕様書駆動型のソフトウェア開発プロセスを見てみよう。

そう思うか……。

　さて、上記の仕様書駆動型のソフトウェア開発のプロセスでは、

と考える場合が多い。以下のような具合だ。

これは、

という考え方だ。

　しかし、いくら詳細な仕様書を前もってたくさん書いても、なぜか「納期が近づくにつれ、仕様の変更が頻発し」、「保守されていない仕様書の山と残業と休日出勤の山が築かれる」ことが多い。そして、最後には「仕様書の不十分さ」と「見積もりの甘さ」が指摘される。だが、次回のプロジェクトも同じことの繰り返しだったりする。

　こう感じたことはないか？

　果たして、「仕様書の精度を上げて、プロジェクトの精度を上げよう」というのはよい方法なのだろうか。

　思うに、「まずは顧客の要望を聞いて詳細な仕様書を作る」というのは、顧客に以下のようなことを要求するようなものではないのか。

しかし実際には、初期の段階で顧客からこれを聞き出すのは無理なのだ。

　 このことを伝えるために、これから「暗黙知と形式知」の話をしたい。ところで、よく「知識には暗黙知と形式知の2つがある」といわれる。暗黙知と形式知という言葉を耳にしたことがあるか？

以下のようなものだ。

さて、この2つの言葉を使って先ほどの問題を表してみよう。顧客の要望をすべてドキュメントとして記述できるのか？ という問題は、すなわち、すべて形式知化できるのか？ という問題だ。

　顧客の要望をすべて形式知化するのは困難だ。考えてみてほしい。顧客は、まだシステムをまったく目にしていない時期に「どんなシステムを注文すれば自分の問題をうまく解決できるのか？」ということを、100％表現することができるだろうか？

　それは無理な話ではなかろうか。この時点の要望には、まだはっきりと文書化できないようなあいまいで漠然としたものが多く混ざっているはずだ。

　つまり、たいていの場合、顧客の要望には暗黙知の部分が多い。そのため、文書化した段階で多くの情報が抜け落ちる。従って、この部分のコミュニケーションを仕様書だけに頼ろうとしても決してうまくいかない。

　完ぺきな仕様書を作りさえすればプロジェクトは成功すると考えるべきではない。完ぺきな仕様書など、ほとんどあり得ないからだ。

　バーバルな（＝言語による）コミュニケーションだけでは限界があるのだ。言葉だけで必要なすべてのコミュニケーションを行おうと考えてはいけない。