プロジェクト・標準化#1　「根深い文書主義の壁～「モノ」駆動から「コト」駆動へ～」

はじめに

豆蔵の中佐藤（なかさと）です。

普段の業務は、研修（新人研修・開発プロセス・オブジェクト指向・UML）がメインですが、最近増えてきたご相談として「アジャイル開発導入」というものがあります。

アジャイルの考え方・手法には、企業内で導入するべきものがたくさんありますので、この傾向はよいことなのですが、少々困るのが、こんなご要望：

「弊社には、ウォーターフォールの開発標準はあり、使用する文書も決まっている」
「よって、今度はアジャイル開発で作るべき文書を教えてほしい」

アジャイルの原則を基に、この誤解を解くことから始めるのが常ですが、この「文書主義」は根深いようで、この要望が出てくる背景を考えてみます。

まずは、アジャイル開発におけるドキュメントの位置づけを見直してみましょう。

アジャイル開発におけるドキュメント

ウォーターフォール開発は、要件定義・概要設計・詳細設計・実装…というように工程を分け、その工程ごとに担当者も変わり、工程（担当者）間の情報伝達の手段として、ドキュメントを作る形が基本です。各工程の作業をできるだけ完璧に行い、それを抜け漏れなく次の工程（担当者）に伝えるためにドキュメントを作る、という考え方そのものは、決して間違っていません。

しかし、ビジネスのスピード感の変化に伴い、大きなシステムを一度に作って出す、という考え方から、小さく作って素早く出す、という考え方に変化し、アジャイル開発への大きな流れができました。これに伴い、アジャイル開発では「チーム全体」というプラクティスが出てきて、ウォーターフォール開発のような明確な工程（担当者）分けをしないで、一つのチームに全員を集めて共同作業をします。

よって、アジャイル開発ではメンバー間のコミュニケーションは、コストの高い（作成工数のかかる）ドキュメントではなく、可能な限り、コストの低い口頭で行います。ドキュメントを作らないのがアジャイルの原則なのではなく、その時の状況に応じて、よりコストの低いほうを選ぶのがアジャイルの原則です。

この考え方があるからこそ、「アジャイル標準ドキュメント」のご要望は「誤解」になります。
一概に作成すればよいドキュメントはなく、その時その時の状況に応じて判断するしかありません。

・・・てなことを、説明してみるのですが、なかなか芯から納得していただけません。これは結構根深く、ヒトの志向に根差しているのでは、と最近感じています。

「モノ」駆動から「コト」駆動へ

人間誰しも、目に見える成果物を作ることで「私はこれだけ仕事をした」ということを形にしたくなる傾向があるのではないか。さらには、「『私は』仕事をキチンとやった」と言うために、成果物を完璧なものにしたくなる傾向があるのでは。
もしかしたら、従来上流工程を担当していた人ほど、この傾向は強いのではないでしょうか。

これはドキュメントというコミュニケーションの「手段」を「目的化」することにつながります。
システム開発途上のコミュニケーションの手段であるはずのドキュメントが目的化し、ドキュメントを作ることが目的になってしまう。
アジャイルマニフェストにおける「包括的なドキュメントより動くソフトウェアを」という価値は、この傾向を排除しようとしているとも言えます。

別の言い方をしてみると、アジャイルは開発を「モノ」駆動から「コト」駆動にしようとしているのではないでしょうか。
例えば、スクラムでは、スプリントプランニング／レビュー／レトロスペクティブなどのイベントを定義し、これらのイベントを繰り返すことで開発を進めます。作成物（バックログ）は定義されているものの、その内容は常に変化し、完成はありません。
（個人的には、さらにこの先に「ゴール」駆動があると考えています。）

さいごに

「手段の目的化」はいたるところで発生しており、「アジャイル標準ドキュメント」を要望する方々には、まずアジャイルの原則を理解していただくとともに、心の奥底にある「成果物完璧主義」の傾向に気づいていただく必要があるのかな、と思っています。

さて、最後にみなさまに質問です。みなさまにとって、「システム」や「ソフトウェア」は、目的ですか、それとも手段ですか。

※転載元の情報は上記執筆時点の情報です。
　上記執筆後に転載元の情報が修正されることがあります。