アジャイル開発におけるドキュメンテーションの実際(2) ―― ドキュメントの「必要最低限」の見つけ方

●アジャイル開発の具体例

　アジャイル開発において，本当に必要なドキュメントのみを書くと，ドキュメントの量は従来よりもずっと少なくなります．しかし，ドキュメントを書かないからといって，要求分析や設計を行っていないわけではありません．では，実際にどのように要求分析や設計を実施するのでしょう？ 図3は連載第1回で従来のドキュメントの例として挙げた画面仕様書です．このユーザ・ログイン画面を題材に説明します．

図3　画面仕様書の例（今回の題材とする）

　まず，ユーザ・ストーリを考えてみましょう．ユーザ・ストーリは通常以下のような形式で表現します．

　　　<ユーザの種類>として，<目的>したい．それは<理由>だからだ．

　　　（例）"システムの管理者"として，"利用するユーザを識別"したい．それは，"利用者によって提供する機能を変えたい"からだ．

　これはあくまでも一例です．同じユーザ・ログイン機能でも，システムによって異なるユーザ・ストーリの表現になります．

　ユーザ・ストーリを見積もり可能とするためには，ストーリを達成するために必要なシステムの振る舞いを詳細化する必要があります．この詳細化は，Face To Faceのコミュニケーションを中心に，以下のようなことを決定します．

（1）情報の入出力（入力項目，結果表示など）
　入力項目は，ユーザ名，パスワード．ログイン結果を表示する．

（2）ユーザのオペレーション
　ユーザ名，パスワードの入力．ログイン・ボタンの押下．

（3）入力の制約（文字種，文字数）
　ユーザ名は英数字6～8文字．パスワードは英数字，記号で8～12文字．

（4）通常のケースの振る舞い
　ユーザがユーザ名，パスワードを入力してログイン・ボタンを押下すると，「認証に成功しました」というダイアログが表示されて，OKボタンを押下するとメニュー画面が表示される．

（5）イレギュラなケースの振る舞い（ログイン失敗など）
　認証に失敗した場合は，ログイン画面に「認証に失敗しました」と表示する．

（6）異常ケースの振る舞い（DB接続失敗など）
　データベースの接続に失敗した場合は，「データベースの接続に失敗しました．再度操作していただいても問題が解消しない場合は，システム管理者に連絡してください」と表示する．

　これらのことを話し合って共有しますが，ポイントは，それをすべてドキュメントに書く必要は必ずしもないということです．また，現時点で決められないことに対して「とりあえず今回はこうする」といった決断を共有することも大切です．

　システムの振る舞いの詳細化の後には，ソフトウェアとして，その振る舞いをどのように実現するかについて開発チームで話し合いを行います．ここでは，ホワイト・ボードでUMLのスケッチなどを使ったり，画面からスレッドを起こして，イベントをどのオブジェクトに通知するか？ といった内容を議論します．開発チームにとって，実現のための方法が自明である場合，必ずしも詳細な議論を毎回行う必要はありません．ユーザ・ストーリの実現に対して，実現方法の議論が必要な要素があるかどうかを共有することが大切です．

　このようにアジャイル開発では，粒度の小さいユーザ・ストーリごとに要求分析と設計を，Face To Faceのコミュニケーションを中心に行います．Face To Faceのコミュニケーションによる共有は，コストは小さいですが時間が経つにつれて失われる速度も速いので，鮮度が高いうちに動作するソフトウェアとして具現化するのです．このアプローチを，前述した図1や図2と同じように論理性と実装性の軸で表現すると，図4のようになります．

図4　アジャイル開発のアプローチ

＊　＊　＊

　今回は，アジャイル開発において，必要最低限のドキュメントとしてどのような情報を記載すればよいかという考え方について説明しました．開発の中で，本当にドキュメント化する必要がある情報は何かを吟味することが大切です．一方で，合意形成のためにドキュメントを作成する必要がある場面も出てきます．本来であれば，本当に必要な合意形成なのか？ もっとほかの合意形成の方法はないのか？ についても吟味する必要がありますが，チームがコントロールできる範囲外であることも多いと思います．そのような場合は，短期的にはその合意形成のために必要なドキュメントを作りつつ，長期的には合意形成のあり方そのものを問い続けることで，組織や顧客の変化を促していくことが必要です．

参考・引用*文献
（1）Kent Beck；『XPエクストリーム・プログラミング入門 ――変化を受け入れる』，ピアソンエデュケーション，2005年12月．
（2）Mike Cohn；『アジャイルな見積りと計画づくり ――価値あるソフトウェアを育てる概念と技法』，毎日コミュニケーションズ，2009年1月．
（3）Ryuzee.com；「コミットメントとは何か？」，http://www.ryuzee.com/contents/blog/4540

ほそたに・やすお