「システム開発地図」でトレーサビリティーを導入しよう！ 第1回：もう迷わないシステム開発（2/5 ページ）

[今田忠博, 近藤正裕，ITmedia]

システム開発には地図が必要

　何も考えずに作業する人が何十人いても混乱するだけで効率は上がりません^（注1）。また、全体のつながり・各自の役割を考えずに複数人での協調作業を行うことはできません。

　「つながりを意識する」ということは、各作業の細かいつながりを意識するレベルと、全体を俯瞰して、大きな固まりのつながりを意識するレベルがあります。地図でいうと、詳細地図と広域地図のようなイメージです。まさに、開発にもこういった視点が必要なのではないでしょうか。

　開発においても、目的地（全体の方向性）と、迷う場所での道しるべを決めておき、事前に道順を確認しておくことが大切です。各地域に詳しいガイド（専門家）やチームリーダーがいれば、なおいいでしょう。

　開発の際によりどころにするものとして、大まかに全体を見渡したり、ときには詳細に調べたりする利用方法は、前述した通り、地図に似ています。では、システム開発の地図は、どうやって表現すれば分かりやすいでしょうか。

• 地図を見れば現在地と目的地が分かる！
• 全体を俯瞰したり、詳細に調べたりできる
• 複数人で共通の認識として語り合える
• 地図があって読み方を知っていれば、目的地にたどり着ける

　そこで、システム開発地図の登場です。まず、システム開発地図の全体像をお見せしましょう。

システム開発地図（詳細を閲覧できるPDFを用意しました。豆蔵のサイトからダウンロードできます）

　システム開発地図は、開発プロセスを表すというより、全体を地図のように把握することを目的としたインフォグラフィックです。システム要件定義の成果物を中心として、業務分析および設計・実装における成果物をどのようにつなぐのかを俯瞰した地図になっています。成果物は、抽象的な箱やドキュメント名ではなく、実際にUMLのモデルやユースケース記述などが詳細に描き込まれています。これらは、ある企業の在庫管理業務をモデル化し、実装するところまでを詳細にトレース可能です。具体例で成果物のつながりや変換の様子を追うことができますので、抽象的なガイドやプロセス定義よりも直観的に捉えやすいという特徴があります。

---

注1：　何も考えずにできる作業は、どんどん自動化され、そんな人に払うコストは削減されていきます。自分の担当範囲の前後までを意識した仕事をしましょう。

コラム:　システム開発地図とアジャイル開発

　システム開発地図を見ると、見るからにたくさんドキュメントを作る印象を受けるため、これはヘビーウェイトなウォーターフォールプロセスの話だと受け取る人が多いかもしれません。では、アジャイルプロセスではこの地図に表されているような内容は無関係でしょうか？

　アジャイルでは、開発から本番稼働までのリードタイムを最少にして、頻繁にリリースし、ビジネスに適用することで仮説検証を繰り返し、プロダクトを改善していきます。ウォーターフォール型開発では、数カ月から数年というスパンで要件定義、設計、実装・テストと推移していくのに対し、アジャイル型開発は、最短距離で保守フェーズに突入し、追加・変更を繰り返すスタイルです。保守フェーズは文字通り保守的なのが従来型の開発で、保守フェーズに入ってからが勝負なのがアジャイルといえるでしょう。保守フェーズというより変革フェーズとでもいうべきでしょうか。

　そのためアジャイルでは、「包括的なドキュメントよりは動作するソフトウェア、プロセスやツールよりも個人と対話」に価値を置きます（アジャイルマニフェスト）。要件定義はユーザーストーリーとプロトタイピングによる画面モックが中心となり、主要成果物はコード（とそれがデプロイされた実行環境）です。

　要件定義、設計、実装という流れは同じですが、設計と実装を同じ人がやることが多く、要件から実装までの期間が短いこともあり、設計要素の引継やトレーサビリティーはおのずと取りやすくなっているという側面があります。ホワイトボードに書かれた手書きのモデルでも設計を伝えることができ、すぐに実装に反映させることができます。

　アジャイル開発をシステム開発地図にマッピングすると、地図自体がコンパクトになり、トレースすべき成果物が少なくなりそうです。アジャイル用のシステム開発地図を描いてみると、顧客・開発メンバー間の合意が取りやすくなるのではないでしょうか。