大仰なタイトルだが、以下「アジャイル開発とスクラム」を読んでいて腑に落ちる?エピソードがあったので、引用とそれについて、私の実体験と所感を記したい。
"被災地では、1つ痛い教訓がありました。最初は、私も開発者も毎週現地に行っていたんです。それこそ屋根もない青空の下で、その場でお客様に試してもらっては、意見を聞きながらその場でコードを直す、みたいなことをしていました。それがある時点から、もっと製品としてきちんと作りこもうということになり、開発メンバーは静岡の開発拠点に戻ったんです。そうしたらそれ移行、現場から要求したことと上がってくるものが大きく食い違うようになってしまい、しかも私自身がそのことに二ヶ月くらい気が付かなかった。そこで、なぜそんなことが起こったのかを全員でとことん議論した結果、例えばボタン1つにしてもそれが何のためについているのかを、開発陣が誰も理解していなかったことがわかったのです。私としては、要求をすべてドキュメントに書いているつもりでしたが、実はこのドキュメントに書くこと自体が問題だったのです。」
僕の書いたドキュメントを開発チームのリーダーに渡すだけでは、まったくお客様の意図が伝わっていなかったのです。やはり実際に現場にスタッフを入れて各人の想像力を働かせないと、お客さまのニーズに沿ったものはできないと痛感しました。" 「アジャイル開発とスクラム」 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント Kindle for iPhone版 No1856ページ より
私が携わる開発はウォーターフォール型の開発で必ず、要件定義書、詳細設計書なるものを書く。もう何が何でもこのドキュメントを書く。それがたとえ、白板と口頭の説明で10分で済むことでも。
そして、このドキュメントを作る過程で削ぎ落とされる情報があることを自覚したい。
上に引用したエピソードにもあるように、定義書、設計書としてドキュメント化すると、文章にする過程で、口頭で話せば数秒、数分で済むような背景やお客様の意図、設計者の意図が、文章にまとめられるがために、脱落してしまうことがままある。もちろん、設計し、実装者に説明する際に口頭で補われることもあるが、それは口頭で補われるのであって、ドキュメントには表現されていないのだ。(その内容を書けばいいじゃんという指摘もあると思うが、文章量が増えたり、面倒臭がられて、往々にしてドキュメントに反映されなかったりする)そして、この口頭の説明による意図がそのときに実装者には引き継がれても、その後の工程には引き継がれないことが多い。
ドキュメント化は、それを読む相手に簡潔に要点を伝えるために、耐え難いほどの文章量にはならないような文章の書き方や図の表現となるが、本当にそのドキュメントが目的とすることーつまりドキュメントによって文章表現された機能が製品の機能としてユーザーにとって望むものであり、使われるものであることーを達成しようとすると、ドキュメントだけでは表現しきれないものだということは、色々矛盾することがあるとはいえ、意識しておきたい。
面と向かった他者との対話でさえ伝わりきらないことが多々ある。文字に符号化され、文章、図という形をとったドキュメントではその意図は伝わりきらないというのは、前提としておくべきなのだろう。