それだけじゃできない詳細定義
「ここまでにA奈が説明したこと自体は間違いじゃないの。でもその後の進め方によっては問題になることがあるのよ。今までの説明は主に『ウォーターフォール型』の開発についての流れなのよ」
「うぉーたーふぉーる？」
「これについては『【楽々デブドックを書こう！】手法別開発ドキュメントの書き方』の『第3回：ウォーターフォールにおけるドキュメント作成ポイント』で解説されているので、詳しくはそちらで勉強しておくように」
「は〜い」
「この形の開発のポイントとしては、あらかじめ決定したドキュメントの内容に、常に沿った形で進めていく、ということね。つまりドキュメントそのものに不備があると、大きな手戻りが発生するの」
「（がくがくぶるぶる）」
「これに対して、あらかじめドキュメント化したものについて、開発中に柔軟に変更を加えていくのが『アジャイル』と呼ばれる開発手法なの」
「それだと手戻りがないんですか？」
「厳密に言えばあるんだけれど、それよりもドキュメントが頻繁に更新されるということが問題になるわね」
「？」
「つまり、採用した実行環境が変更されたことを、開発者の誰か1人が知らなかったとしたら？」
「それは、状況によっては手戻りが発生しますね」
「そう。だからこそ、いかにドキュメントの更新を行って、それを周知させるのかが重要になってくるのよ」
「変更があったら、そのつどドキュメントを配りなおすのではだめなんですか？」
「…開発者がみんなA奈だったら、それぞれ別々のドキュメントで作業しそうよね」
「そんな〜、といっても強く否定できません〜」
図3：ウォーターフォールとアジャイル開発の概念
（画像をクリックすると別ウィンドウに拡大図を表示します）
原本を作るか、Wikiなどで管理するのか
「でしょ？ どちらの方式でも重要なのは『頼りにするべき情報はどこにあるのかを明確にする』ことと『そこにきちんと決められた内容を記述しておくこと』の2つなの。さっき、ドキュメント作成にはマイクロソフトのオフィスを、ってA奈はいってたけれど、アジャイル開発の場合は原本の管理がちょっと難しそうね」
「じゃぁ何を使えばいいんでしょう」
「ほんとうは自分で気づいて欲しいのだけれど、例をあげてしまうとWikiやメーリングリストといったツールが使えるわ。そこで最新の決定情報が見られるようにすればいいのよ」
「そこにオフィスで作った最新データを！」
「もちろんそれでもいいわ。ただ『どこに最新の決定事項が掲載されているか』をプロジェクトに関わる全員が知っておく必要がある、ということを忘れてはいけないわね」
「は〜い、わかりました〜！ じゃぁこれでようやく開発開始〜！」
「ここまできちんと決めておけば、決まった内容に問題がない限りはデスマーチの可能性はかなり低く抑えられるわよね」
「これで、私たちの任務も完了ですね！」
「…？」
「終わり…ですよね？」
「……？」
「（がくがくぶるぶる）」
「私たちの任務が完了するのは、まだまだ早いわよ。その理由は次回に説明するから、それまで泣いていらっしゃい」
「（がくがくぶるぶる）では、次回までさようなら〜」
ナレーション「開発がスタートするにも関わらず、B乃たち開発ドキュメントの妖精の任務はまだ終わっていないのだという。『真の任務完了』とは何なのか。そしてそのために必要な開発ドキュメントとは？ その秘密は『第5回：テスト関連も忘れちゃだめドキュ！』で明かされる（って、答え出てますよ…）。では最終回も『開発☆ドキュン』でどっきゅドキュ！」
タイトルへ戻る
