確認・確認・また確認!
確認・確認・また確認!
「『正しい』ということを確認しないままで開発者側で共有しても、もし違っていたらそこも手戻りになるってこと、わかったかしら?」
「はい。…今思ったんですけれど『みんなで共有』って、もしかして開発者だけでなく、依頼者もまきこんで共有することが重要なんじゃないですか?」
「もちろんその通り。よく気づいたわね。じゃぁなんで開発者から依頼者まで共有する必要があるか説明できる?」
「そうですね…。それは、問題が発生したときに『何が問題なのか』を判断する基盤として、共通の認識が必要だからだと思います」
「その他にもあるかしら?」
「うーんと、例えば開発者側が開発中に疑問を持ったとして、それがどの要求を満たしているかとか、こうすると要求通りに作れるとか、確認しやすくなりますね」
「そうね。それはすごく重要」
「ほかにも、依頼者側も進行状況や説明を聞きながら、どの要求の部分の開発が進められているのかをチェックしやすくなります」
「はい、正解。ここでもっとも重要なところは『お互いが納得してシステム開発を進められる』という基盤を作り出すことよ。そのためにこそ、要求を定義して確認書を作成し、それを承認してもらう必要があるの」
「はい! わかりました!」

図3:情報を正しく共有できていない場合の流れ
次に決めるのは開発までの地図!?
「さて、ここまでの内容をまとめると図3のようになります。今この開発現場は図3の状態を経て、今に至っているわけです」
「…かわいそう(泣)」
「もちろんそれだけじゃないのが、システム開発の怖いところよ」
「それは次に作るべきドキュメントのことですね?」
「その通り。これはあくまで『ゴールの場所』を大まかに決めたに過ぎないの。本当にゴールを決めるためには、そこにたどり着くまでの地図を作らないと」
「ではでは、C言語を使ってこういう構成で…っと」
「こら! それはまだ早いわよ!」
「(がくがくぶるぶる)」
「いきなり何々通りを右に曲がって三軒目、とか書かないように」
「はいぃ〜(泣)」
「最初にするのは、目的地に行くまでにどんな交通機関を使うか、のような大きな流れを決めることよ。何時何分の電車に乗るとか、どういうルートを通るかはもっと先なの」
「よくわかんないけど、わかりました〜」
「(※ためいき※)来週は、その点についてもっとびしびし教えますからね!」
「(がくがくぶるぶる)…わかりました」
ナレーション「よく質問に答えられたというか、まったく答えられなかったというか、難しい状況におかれてしまったA奈。ほんとに学校で何を学んできたというのだろうか! 次週『基本設計の“いろは”ドキュ』でどっきゅドキュ!」
バックナンバー
この記事の筆者
“オープンソース技術の実践活用メディア” をスローガンに、インプレスグループが運営するエンジニアのための技術解説サイト。開発の現場で役立つノウハウ記事を毎日公開しています。
2004年の開設当初からOSS(オープンソースソフトウェア)に着目、近年は特にクラウドを取り巻く技術動向に注力し、ビジネスシーンでOSSを有効活用するための情報発信を続けています。クラウドネイティブ技術に特化したビジネスセミナー「CloudNative Days」や、Think ITと読者、著者の3者をつなぐコミュニティづくりのための勉強会「Think IT+α勉強会」、Web連載記事の書籍化など、Webサイトにとどまらない統合的なメディア展開に挑戦しています。
また、エンジニアの独立・起業、移住など多様化する「働き方」「学び方」「生き方」や「ITで社会課題を解決する」等をテーマに、世の中のさまざまな取り組みにも注目し、解説記事や取材記事も積極的に公開しています。
筆者の人気記事
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。