モデリング・DDD＃２　「関係者の役割分担をマッピング」

はじめに

前回は、業務システム開発に携わる関係者全員が、成果物やプロセスの全体を地図のように俯瞰できる「システム開発地図」をご紹介しました。
筆者らの参画したプロジェクトを思い返していくと、開発時の効率化で削減できる無駄よりも、責任者がはっきりしないことによる無駄の方が大きいということに気がつきました。そこで今回は、システム開発における関係者の役割分担について見ていきます。システム開発地図上に、関係者の役割をマッピングすることで何が浮かび上がってくるでしょうか。

システム開発地図

前回ご紹介した通り、「システム開発地図」はシステム要件定義の成果物を中心として業務分析および設計・実装における成果物をどのようにつなぐのかを俯瞰した地図です。実際の地図のように、ゴールに至るまでの道筋を大まかに俯瞰することや、注意すべきポイントを一貫した実例で詳しく見たりすることができるものでした。(図 1)

システム開発地図(955.54 KB)

業務システム開発のための役割・責任範囲

業務システムは、妥当な期間とコストで開発され、長期間運用・保守されていくべき企業の資産です。

システムを業務変化に適合させ効果的に経営をサポートしていくには、優れたアーキテクチャー構築や優秀な開発者の確保が大切なのはもちろんですが、「企画」「要件定義」「設計」「開発」「移行」「保守」といったシステムのライフサイクルを通して成果物間のトレーサビリティー(追跡可能性)が確保されることも大変重要です。

システム開発が目的の場所(当初の期待)にたどり着かない場合や、目的の場所自体が変化するような場合に、トレーサビリティーが確保されていなければ、どこに向かえばいいのか／どこまで戻ってやり直せばいいのか、ということを考えることもできません。

しかし、成果物間のトレーサビリティーを確保するというのは、簡単なことではありません。業務システム開発は、多くの人(利用者、開発者)が役割を分担しながら長い工程を進めていくものだからです。

発注者と開発者の役割分担

特に、業務システムの発注者と開発者の役割分担は不明確になりがちです。発注者は利用者の業務要件を元にシステムの外部仕様を開発者に伝える必要があります。仕様を表すには、用語集、業務フロー、概念モデル、ユースケースなどあらゆる表現方法があります。

表現された内容の正しさを判定できるのは業務を知る発注者側の人のみです。業務知識のない開発者は単独でこれらを作成できませんし、作成したとしても内容に責任を持つことはできません。そうかと言って、発注者が適切な書式や詳細度で仕様書を作成できるかというと、なかなか困難でしょう。発注者は仕様書の正しさを評価できますが、仕様書を正しく作れるわけではありません。

このような場合、開発者の支援を受けて仕様書を作成し、その後のメンテナンスは発注者側で行うというのが現実的です。表1は、共通フレーム2013*1で示されている、システム開発に関わる組織と役割の関係の例です。業務システム部門は、ベンダーの支援を受けながら、様々な役割を果たし、業務部門および経営層を支援する必要があります。

業務要件定義では業務部門が主体で情報システム部門が支援ですが、作業分野がシステム要件定義になると主体は情報システム部門で、ベンダーが要件定義書の作成支援、業務部門はレビューによる要件の妥当性確認という役割を果たしています*2。

表 1 組織と役割の関係の一例(共通フレーム2013より引用 ○:主体 □:支援)

組織

役割

経営層業務部門情報システム
部門ベンダー取得者 ○ 供給者 ○管理者 ○○企画者○○○□要件定義者(業務要件) ○□ 要件定義者(システム要件) □○□運用者(業務運用) ○□ 運用者(システム運用) □○□利用者 ○ 開発者 ○○○保守者 ○□

*1　https://www.ipa.go.jp/about/press/20130304.html
*2　これはあくまで例であり、責任主体が他部門やベンダーになる場合もあります。

システム開発地図上の責任分界

表 1は、作業分野(を担うロール)と組織をクロス表にしたものですが、具体的にどのような成果物に対し責任を持ち、他の作業分野と連携を取り、トレーサビリティーを確保するのかということに関してはもう少し具体イメージがあると良いでしょう。
具体的な成果物と責任分界の例を示すため、システム開発地図にオーバーレイしてみました(図 2)。業務分析からシステム要件定義に少し入って粗粒度のユースケースモデル作成までを発注者側領域、ユースケースの洗練化からのシステム要件定義や方式設計を準委任領域、概要設計(基本設計)から先を請負領域としています*3

図 2 システム開発地図に責任分界をオーバーレイ

発注者領域の成果物は、初期の段階では、外部業者に準委任で作成支援を依頼しても構いません。ただし、成果物に対する責任は発注者側に帰属します。業者に丸投げではなく、発注者が成果物の作成方法やメンテナンスができるように、業者とともに作業することが大切です。

発注者と受注者のコラボレーション

各領域の境界では、それぞれの担当が領域を超えないのではなく、次の図のように両者が少しずつ領域を超えて協力し、少しずつ比重を変えて意思疎通を図り、作業を引き継ぐようにします。

*3　この境界線の引き方もあくまで一例です。

図 3 領域の境界での作業分担

準委任領域に関しては、外部業者が主体で作業しても、成果物責任を負うことはありません。請負領域のように定量的に測定できる成果物基準がない状態で作業を行うためです。業務分析で導かれた業務要件をどのようにシステム要件に落とし込むか、分析手法、テクノロジー、アーキテクチャーに依存する部分ですので、(弊社のような)ITコンサルタントやSIerの支援が必要な作業分野です。準委任とはいえ、発注側からすると外部業者の成果に賭けるしかない部分ですので、業者の力量、値頃感を把握するための目利きが必要です。日頃の開発・保守業務を通して信頼できる外部業者と良好な関係を構築することも大切です。

請負契約が可能なのは、システム要件と方式が確定したあとの設計・開発部分です。この領域でも、生産性・品質が見込める業者との契約が重要です。

地図を手にしたプロジェクトという旅

地図を頼りにした旅で例えると次のようなイメージです。
「土地勘」のある人間がリーダーとして関係者を率いますが、土地が変われば土地勘のある人間も代わります。リーダー交代の際には、これまでの経緯や状況を引き継ぐために、新旧のリーダーが協力して作業に当たり、少しずつ比重を変えていきます。リーダーが決まっていなければ、無駄なく目的地にたどり着くことは難しいでしょう。

おわりに

今回は、業務システムのライフサイクルマネージメントの観点から、システム開発地図を用いて、発注者と開発者の責任分界を俯瞰してみました。
成果物のトレーサビリティーを確保するには、明確な役割を担った関係者間の合意形成スキームの確立、成果物定義、構成管理、変更管理、品質管理などの実施と絶えざる改善が必要です。システム開発地図は、関係者間の認識を共有するための豊かなイメージを提供するでしょう。
前回の記事で、「業務システムに関連する人(利用者、発注者、開発者)、開発プロセス、運用プロセスなどが、業務システムのライフサイクル全般にわたりその保全、進化に有機的に作用する体系」という意味でエコシステムという言葉を使いました。成果物のトレーサビリティー確保はエコシステムの必要条件です。トレーサビリティー確保をすべて手作業で行うのは困難なので、実際にはアプリケーションライフサイクルの各局面をサポートする開発ツールの利活用が重要です。