こんにちは、豆蔵で要求開発を担当している上山(うえやま)です。
連載第2回の今回は、要求開発方法論(Openthology)の概要についてとりあげます。
要求開発方法論(Openthology)は、システム開発を開始するまでに行うべきことを規定した超上流工程向けの方法論です。

要求開発プロジェクトを進めるにあたって、どのような組織で作業を進めるべきか(組織)、どのような順番でどのような作業を行うのか(プロセス)、どういう観点で調査・分析・設計・検証を行うのか(手法)、そこで作成する成果物にはどのようなものがあるのか(成果物)という内容で構成されています。

要求開発プロセスのオーバービュー

要求開発プロセスのオーバービューを以下に示します。

図1:要求開発プロセスのオーバービュー図1:要求開発プロセスのオーバービュー

要求開発は、経営分析とシステム開発の間に位置し、経営戦略をインプットに、ビジネス要求からシステム要求を導く活動です。要求開発は、「準備」「立案」「デザイン」「シフト」の4つのフェーズで構成されます。

「準備フェーズ」は、要求開発プロジェクトを開始するにあたっての準備を行うフェーズです。戦略および課題・要求の把握、プロジェクトゴールの設定等を行います。
「立案フェーズ」は、現状業務の分析を行うフェーズです。モデルにより業務を可視化します。
「デザインフェーズ」では、立案フェーズで作成したモデルを用いて、業務のあるべき姿を設計します。
「シフトフェーズ」は、システム開発への橋渡しを行うフェーズです。

要求開発方法論(Openthology)の構造

要求開発方法論(Openthology)では、ビジネス戦略、ビジネスオペレーション、システムの関係を以下のモデルで表現しています。

図2:Openthologyの構造図2:Openthologyの構造

ここでは、最上位に「ビジネス戦略」があり、戦略を支える「ビジネスオペレーション」と、そのビジネスオペレーションを支える「システム」があることを示しています。

要求開発では、ビジネスを「サービス構造」「プロセス構造」「情報構造」の3つの側面から捉えます。
「サービス構造」を中心におき、サービス構造の動的な側面を「プロセス構造」で、サービス構造の静的な側面を「情報構造」で表現します。

サービス構造
対象の事業体が外部に提供するサービスのことで、ビジネス・ユースケースに相当します。
プロセス構造
サービスを実現する作業とリソースの関係及び作業間の相互作用を表現したものです。
情報構造
サービスを構成するモノや概念を表したものです。業務の流れに依存しない業務概念を表現することができます。

要求開発では、この構造の関係に沿ってモデルを用いて段階的に詳細化していきます。モデルにより業務を可視化することで、口頭や文書で伝えるよりも曖昧さが減り、ステークホルダーに情報を解り易く的確に伝えられます。

要求開発方法論(Openthology)の構造に対する代表的なモデルを以下に示します。

図3:Openthologyの構造とモデルの対応図3:Openthologyの構造とモデルの対応

要求開発方法論(Openthology)は、プラッガブル(差し替え自由)な方法論を志向しています。活動や検討の枠組が規定されており、詳細な部分は適切なものをプラグインして使用するという形になっています。要求開発方法論(Openthology)では使用するモデルまで規定していませんので、同等の内容が表現できるものであれば、図3で例示したモデル以外を使用しても構いません。

目的(What)と手段(How)の連鎖が重要

要求開発方法論(Openthology)の構造からも解るように、要求開発では、ビジネス戦略と整合性のとれたシステム要求の導出を目的としています。ビジネス戦略からシステムまで、目的(What)と手段(How)の連鎖により追跡可能(Traceable)とすることで、システムへの根拠のない要求の排除ができます。

図4:目的(What)と手段(How)の連鎖
図4:目的(What)と手段(How)の連鎖

図4では、ビジネス戦略を実現する手段として、ビジネスオペレーションが存在し、そのビジネスオペレーションを実現する手段として、システム要求が存在することを示しています。 システム要求から、その要求の目的を遡ることで、ビジネス戦略におけるシステムの存在価値を論理的に説明することが可能になります。

要求開発の具体的な進め方

企業の中長期的なIT戦略策定や、システム再構築時のRFP作成など、要求開発の適用ケースは様々です。
各ケースによりアプローチ方法は異なります。

今回の連載でとりあげるシステム開発を前提とした要求開発では、本来の目的や業務との整合性を確保することが重要です。
このケースにおける、要求開発の各フェーズの作業概要と成果物を以下に示します。

図5:具体的な進め方
図5:具体的な進め方

「準備フェーズ」では、先ず「プロジェクト定義書」「ステークホルダーリスト」「要求分析ツリー」によりプロジェクト発足時に与えられている情報を整理し全体構造を把握します。次に「ゴール記述書」によりプロジェクトゴールを設定していきます。
「立案フェーズ」では、「ビジネスユースケース」「業務フロー」「概念モデル」により業務を可視化します。
「デザインフェーズ」では、立案フェーズで作成したモデル上で課題を特定し、それを解決する業務のあるべき姿(To-Beモデル)を設計します。
「シフトフェーズ」では、システム開発への橋渡しを行う為に、システム開発に必要な情報を過不足なく文書化していきます。システム開発を自社で行うのか、外部に委託するのかによって作成する成果物は異なります。代表的なものとして、RFP(提案依頼書)、RFI(情報提供依頼書)があげられます。

次回以降は、家具販売会社を例に小売業の要求開発プロジェクトをとりあげ、具体的な要求開発の進め方について説明します。