システム開発は旅――。複数の企業や部署が関わり、それぞれ異なる役割を果たしながら要件定義や設計、実装・テストといった工程が進んでいく様子を表した例えである。上流工程と下流工程、発注側と受注側が互いにプロジェクトの全体像を把握して共通認識を持つ。そんな開発は理想である。

 システム開発を手掛ける豆蔵の近藤正裕主幹コンサルタントと今田忠博シニアコンサルタントらが考案した「システム開発地図」は、この共通認識を生む助けになる“すごい設計書”だ。近藤氏らはユーザーへのヒアリング以降、この地図を使って開発の見通しを良くしている。「難しいプロジェクトの旅でも迷わない、道しるべのような地図」(近藤氏)と、その位置付けを表現する。

成果物の種類や関連、担当を明確化

 システム開発地図は、プロジェクトで実施すべき作業ごとに成果物を整理し、それぞれ担当者を明確にしたドキュメントだ(図1)。利点は複数の企業や部署が関わる成果物を可視化できること。各作業の配下には多くの成果物がひも付けられる。成果物の追跡可能性を確保し、成果物同士の関係を分かりやすく表現した。作業や成果物の詳細度にもよるが、おおむねA1用紙からA4用紙1枚に収まる。

図1●システム開発地図
図1●システム開発地図
(出所:豆蔵)

 新規プロジェクトだけでなく、保守プロジェクトでも活用できる。この場合、プログラムを修正した際の影響がどこまで及ぶかがひと目で分かる。今田氏は「思わぬ影響を恐れてシステムに手を入れられない状況を回避できる。本来修正すべきでない部分を修正するリスクも避けられる」と説明する。

 図1の例はウォーターフォール型の開発プロセスを想定しているが、短い期間で開発を繰り返すアジャイル型でも構わない。「アジャイルでは反復するなかで記述レベルを詳細化していく。スピード感を持って柔軟に変更していくプロジェクトに向いている」(近藤氏)という。

 システム開発地図は成果物一覧や作業一覧(WBS:Work Breakdown Structure)といった管理系のドキュメントに似ているがそうではない。位置付けはあくまで設計書だ。その証拠に、システム開発地図の表記はUML(統一モデリング言語)である。また「レシピ」と呼ぶ形で、成果物を開発していく上で利用すべき開発手順やAPI(アプリケーション・プログラミング・インタフェース)なども示している。利用の場面は設計以降が中心である。