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

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

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

小島 富治雄
2006/05/17
Page1 Page2 Page3 Page4

 
登場人物:
師匠:ナジャイラ師(マスター)(♂)
NAgiler(ナジャイラー=.NETにおけるアジャイル開発の実践者)。なぞの多い人物。ちょっと偉そう。だが、実は弟子思い。
弟子:点網 滝(てんもう たき)(♀)
.NET開発者。ウォーターフォール型の開発を行っているが、アジャイル開発を明るく真摯な態度で学ぼうとしている。

※ご注意 ……本稿に登場する人物、会社、団体などはすべてフィクションであり、実在の人物、会社、団体などとは一切関係ありません。登場人物の役柄はストーリー上の設定であり、筆者や読者を代表するものでもありません。あくまでもフィクションとしてお読みください。

■■プロローグ■■

前回:アジャイル開発ではドキュメントを書かないって本当? ――より良いコミュニケーションを実践するコツ――
姉妹連載:NAgileで始める実践アジャイル開発

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

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

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

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

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

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

 

 

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

 

 

……そうか。

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

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

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

 

 

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

 

 

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

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

 

 

……はい。

■■ドキュメントを書くことが重要?■■

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

ドキュメントを書くことは重要だ。

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

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

【参考】「守・破・離」の原則

 人や本などから何かを学び、1人立ちしていくまでに、「守」「破」「離」という段階を進んでいくといわれている。

  1. 「守」……最初は教わった型を守り、型のとおりにやる

  2. 「破」……教わった型どおりでなく、自分なりに型を破り、改善していく

  3. 「離」……最後には型を離れて独自のやり方を作り出し、行う

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

   

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

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

仕様書駆動型のソフトウェア開発のプロセス:

  1. 要求分析を行う

  2. 要求分析に基づき仕様書を作成する

  3. 完成した仕様書どおりのものを作る

   
これは特にウォーターフォール型開発に多い。
   
師匠相変わらず、ウォーターフォール嫌いですね。
   

そう思うか……。

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

  1. 十分な要求分析を行い、

  2. 精度の高い仕様書を作成し、

  3. その仕様書から、できるだけ精度の高い見積もりを作成して、

  4. そのとおりに作れば、うまく行くはず

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

仕様書駆動型のソフトウェア開発の思考プロセス:

  1. まず何を作らなければならないか、十分に顧客からヒアリングをして仕様をきちんと決めよう。できる限り顧客の要望に合致した詳細な仕様書を作ろう。この時点で顧客とのコミュニケーションが大切だ

  2. 完成した仕様書に関して、十分に顧客と合意を取ろう

  3. 仕様書を個々の開発要員が十分に理解し、詳細な見積もりを作ろう

  4. つまり、仕様書とそれに関する作業の精度をあらかじめできる限り高くして、そのとおりに作るようにしよう。そうすれば全体としての精度が上がる

  5. これでうまくいくはず。もし、うまくいかなかったとしたら、それは仕様書の精度が不十分であったか、または、開発者の見積もりが甘かったせいだ

   

これは、

「仕様書の精度を上げれば、プロジェクトの精度も上がる」

という考え方だ。

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

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

「なぜ顧客のいうことを詳細に聞いて、そのとおりに作ったのに、顧客は仕様を変えたがるのだろう?」

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

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

「ソフトウェアはまだ影も形もありませんが、どんなソフトウェアが欲しいのか、そのすべてを述べてください。数カ月後にソフトウェアの形が見えてきたときにも、新たな要望を何も付け加えなくても済むくらいに」

   

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

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

   
ええと……はい。聞いたことだけはあります。
   

以下のようなものだ。

【参考】暗黙知と形式知

  • 暗黙知:個人が体験によって得た知識で、個人の頭の中にありうまく表現されていないもの

  • 形式知:第3者に理解できるように表現された知識

   

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

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

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

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

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

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

【まとめ】
 

 INDEX
  開発をもっと楽にするNAgileの基本思想
  第2回 伝わるコミュニケーションとは
  1.ドキュメントを書くことが重要?
    2.ブロードバンド・コミュニケーション
    3.和のコミュニケーション
    4.創造的コミュニケーション
 
インデックス・ページヘ  「開発をもっと楽にするNAgileの基本思想」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間