第3回：基本設計の“いろは”ドキュ (3/3)

要求定義もまとめてドキュメントに！

「じゃぁどうすれば良いんでしょう？」

「だから、開発ドキュメントが必要なのよ」

「？」

「要求定義の部分で触れたことだけど、要求に基づいた確認書を作って依頼者側に承認してもらう必要がある、っていったわよね？」

「はい」

「開発ドキュメントの多くは、その『確認・承認』のプロセスを円滑に進めるためのものだし、後で『話が違う』ということの発生しないために作るの。これこれこういうシステム規模で、こんなユーザインターフェースで、外部との連携の有無、納品後の運用サポートなどなど、『どんなシステムをこれから開発します』という部分をはっきりさせるために使われるのね」

「はいはい」

「『はい』は1回！」

「（がくがくぶるぶる）」

「で、はっきりさせるための資料として開発ドキュメントを書くんだけど、ここで必要なのは『開発に必要な要件』と『スケジュール』の2つに大別できるわね。場合によっては『コスト別の構成』みたいな資料もあるといいかしら」

「…難しいですね」

「それをやるのが、あなたの仕事よ」

「（がくがくぶるぶる）」

「このタイミングで作る資料は主に依頼者側に承認してもらう必要があるので、提案書のような形でまとめるとよいわね。これでいよいよシステムの本開発が進められるわ」

「そうですね！　ここからはプログラミングの妖精さんの出番ですね！」

「（※ためいき※）本当に学校に戻ってもらおうかしら」

「（がくがくぶるぶる）なんでですか〜？」

図3：要件定義でも承認は必要

「じゃぁこういうのを作ってね」のレベルにするには？

「『こんなスペックで動作する、こんなプログラムを作ってね』で、全部プログラマの人たちに丸投げするの？」

「だって、それがプログラマさんたちの仕事ですよね？」

「だれか1人がプログラミングするなら、100歩ゆずって、それでもいいかもしれないわね。でも何十人単位のプロジェクトだったとしたら、ここで作ったレベルの資料で分担も決めず、それぞれのコードの連携もわからない状況で、何ができるの？」

「でもでも…」

「少なくとも、この部分は誰が担当して、どのように開発を進めるのかといった資料は別に必要ね」

「じゃぁそれも要求定義にいれちゃえば…」

「その情報、いちいち依頼者に承認してもらわなくちゃいけないかしら？」

「…なくてもいいですね」

「そう。ここからがようやく『開発者側』のドキュメントになるのよ」

「まだまだ先は長いんですね〜」

「そうね。ここで大きな問題を生んでしまうのが、開発手法によってドキュメントの作り方がまったく違ってくることなのよ」

「そ、それってどういうことですか！？」

「開発手法別のドキュメントの作り方については、もう説明するスペースがないの。だからそれは次回ね」

「は〜い、わかりました！」

ナレーション「まだまだ先は長い、システム開発における『開発ドキュメント作成』。この長い道のりにA奈はついて行けるのか！？　そして開発手法がどのようにドキュメント作成に関わってくるというのだろうか。この続きは、次週『詳細設計はどうするドキュか？』でどっきゅドキュ！」 タイトルへ戻る