Openthologyでは，準備，立案，デザイン，シフトの四つのフェーズを定義し，段階的な詳細化，モデリングなど要求開発プロジェクトの推進をガイドします。今回は，立案フェーズの「概観ビジネスモデリング」について紹介します。
筆者は，ITコンサルタントですが，ユーザー企業の情報システム部門で十数年間システムの設計・開発に携わった経験があります。企業がIT投資の対価として求めるものは，コストの削減や付加価値の創造です。
技術の進歩やインターネットの普及によりITで実現できることが広がる中，最近では，業務の効率化，コストの削減といったテーマに加え，企業の本業に近い分野で，経営戦略に直結したビジネスシステムを構築するといったテーマが増えているのを実感します。
経営戦略の実現を支えるビジネスシステムを構築する場合，企画段階におけるシステムへの要求はあいまいである場合が多いです。この場合，経営戦略の「目標」を実現するためのビジネスを検討し，その上でビジネスが期待通りの成果をあげるために，必要となるシステムを検討します。
要求開発の準備フェーズでは，要求開発プロジェクト全般の「計画と準備」を行います。経営戦略との整合性をとりながら，プロジェクトのスコープとゴールの設定をあわせて行います。
以降のフェーズでは，プロジェクトのゴール実現に向けて，分析・設計，ビジネスモデリング，合意形成などを行います。この際，着手できるところからいきなり詳細な検討を行うと，本来検討すべき課題を解決しないまま時間切れで開発に着手するなど，失敗につながってしまいます。
そこで，立案フェーズでは，ビジネスの本質レベルでの可視化を行い，検討課題の優先順位やシステム化対象領域を決定するなど，プロジェクトで注力すべき攻略点を特定します。
ビジネスの本質レベルの可視化のために，まずはゴール実現のために「要は，誰に何を提供すればよいのか！」というビジネスの「サービス構造」を明らかにします。要求開発の準備フェーズでは，プロジェクトゴール記述書を作成します。プロジェクトゴール記述書には，「何をすることで」「何が」「どうなるのか」を簡潔に記述し，目標の達成時期と目標値を明記します。
立案フェーズでは，プロジェクトゴールの記述に基づき，必要となるサービスを洗い出し，ビジネス・ユースケース図を作成するなど，ビジネスの「サービス構造」を「見える化」します（図1）。
 図1 ビジネス・ユースケース図の例 |
続いて，個々のビジネスやサービスについてその「構造」と「メカニズム」を明らかにします。ビジネスの構造とは，ビジネスを構成する要素とその要素間の関連です。概念クラス図といった静的なモデルがこれにあたります。一方，ビジネスのメカニズムは，ビジネスにおけるトリガーの連鎖です。業務フローのような動的なモデルがこれにあたります。
立案フェーズでは，ビジネスの構造とメカニズムを大枠のレベルで可視化することが重要です。なぜ，大枠で可視化することから始めるのでしょうか。
ヒトは，よくわからないものを理解する際，まずは，おおまかな構造や原理を理解し，徐々に詳細を理解します。ビジネス検討の場合も，実は同じなのです。企画から検討の初期の段階では，「要は何ができるようになればよいのか」そのためには，どんなステークホルダーが存在し，「誰が，いつ，何をすればよいのか」といったビジネスの大枠を検討し，その後に（要求開発の場合はデザイン・フェーズ）徐々に詳細を検討するのが効率的といえるでしょう。
そのため，要求開発の立案フェーズでは，ビジネスを本質レベルで可視化します。この活動を「概観ビジネスモデリング」と呼んでいます。
概観ビジネスモデリングでビジネスのあるべき姿を検討する場合，エンドユーザーである業務部門の担当者とのコミュニケーションは避けて通ることができない重要な課題となります。この際，最も留意すべきは，エンドユーザーにとっての関心事をきちんと可視化することです。
エンドユーザーの興味とは，自分の仕事は何をトリガーに発生し，自分は何に対して責任を負うのかといったことです。したがって，ユースケース図とシナリオの束を提示したりすると，冷ややかな反応がかえってきます。これらの資料では，業務の全体像を俯瞰してとらえることができないからです。
それでは，業務フローを提示しさえすれば，コミュニケーションは活性化されるのでしょうか。例えば，アクティビティ図で詳細な業務フローを多数作成し，「これはUMLといって，世界標準の表記法です。読めるようになってください。」と主張したとします。これではやはりコミュニケーションは進まないでしょう。
業務部門の担当者は，担当業務のプロであり，システムの専門家ではありません。彼らの会社人生の中で，全社業務にかかわるシステムの企画に参画し，業務設計を行う機会はそうあるものではないでしょう。ですから，UMLを覚えてもらうなどというのはナンセンスなのです。
また，いきなり詳細なフローやイレギュラーなフローを提示すると，議論が各論になり，本来検討すべき本質的な課題が見失われたりします。この段階での検討においては，要はどんなシステムができて，自分はそのシステムにどうかかわるのか。それが直感的に，わかれば十分なのです。
次回は，このような発想から考案された記述法の一つである，LFD（Lane Flow Diagram）について紹介します。
| （野田 伊佐夫＝要求開発アライアンス 執行委員長） |
