ビジネス価値を高めるためのビジネス戦略トリアージと要求(2)

2007.02.22

　前回に引き続き，ビジネス戦略と要求にについて書き進めます。

　前回書いたように，ビジネス戦略をトリアージして，そのトリアージされた戦略に基づき，重要なビジネス・オペレーションにスポットライトをあてます。そしてスポットライトがあてられたビジネス・オペレーションのあるべき姿を分析する過程の中から，システム要求の候補が発見されます。

　では，こうして発見されるシステム要求の候補をどうとらえるべきでしょうか？図1を見てください。これは，一つのビジネス・オペレーションを実現するための要求は，どうにでも定義できることを意味しています。

図1●要求はどうにでも定義できる！

　例えば，図1のR1は，かなり戦略よりに定義された要求で，もしかすると現場にとってはありがた迷惑な要求かもしれません。R2は，ITのアイデアを取り入れることで戦略面と現場の問題解決を行えるようにした要求かもしれません。またR3は，現場の問題解決をするための要求ですが，これにはもしかすると戦略面での欠点があるかもしれません。

　このように要求はどうにでも定義できるのです。だからこそ，どのように定義するかをしっかりと検討する必要があります。

　現場に迷惑と思われがちな戦略的要求についても，ビジネス戦略の見える化と現場の合意さえとりつけておけば，現場からも受け入れられるでしょう。そのためには，コタツモデルで本来のビジネス戦略に合致したビジネス・オペレーションを描き，その実現方法としての要求の候補を見つけ出して，コタツモデルに参加しているメンバーの中で合意を得る必要があります。

　その際，最初から見つかっていないような微妙なアイデアが生まれます。例えばITを利用することでビジネスの価値を高めたり，オペレーションコストを極端に減らすようなアイデアです。図2(2)のように，ITアーキテクチャ（設計）側から要求とビジネス・オペレーションを発案するようなものです。このようなものは，要求と言えるのでしょうか？

図2●ビジネス要求をIT側から創発するケース

　図2の(2)は，ビジネス要求をIT側から創発しているような様相です。当たり前といえば当たり前ですが，IT化というHowが，ビジネスというWhatに影響を与えるという摩訶不思議な関係があります。ここで明確に言えることは，我々は，このような関係をしっかりと認知し，許容することが大切なのです。ITはHowなので後で考えるべきという古くさい考えは捨てましょう。ビジネス戦略におけるIT活用は積極的に活用すべきです。

　またこのような要求は，「そこにあるものではなく開発するもの」という要求開発アライアンスのキャッチがピッタリと当てはまるような要求ですね。まさに要求の開発が行われるのです。

　さて，ビジネス戦略によって狙い撃ちすべきビジネス・オペレーションが明らかになった後，ビジネス・オペレーションを見える化する作業は，要求開発においてどのように進めるのかということについて簡単に話をしましょう。

　まず，ビジネス戦略面については，要求開発の最初のフェース（準備フェーズ）で行います。準備フェーズでは，BSC（balanced scorecard）戦略マップなどによりビジネス戦略の見える化を行い，ビジネス戦略についてトリアージしていきます。

　その際，ビジネス戦略の実現をイメージしながら，スコープ（範囲）とリソース（やれる人，コスト，期間）のバランスを取りつつ，要求開発プロジェクトのゴールを決めます。このような試行錯誤の中で，ちょっと業務モデリングをしてみるというのも有効です。

　要求開発プロジェクトのゴールが決まったら，立案フェーズに移ります。立案フェーズは，トリアージされたビジネス戦略に対するビジネス・オペレーションについて攻略点を探ります。実際にはざっくりモデリングを行ったり，フロントローディング開発によってToBeビジネスの案作りをざっくり行ったりして，どこにToBeビジネスの攻略点があるのか探るのです。

　攻略点とは，どの個所に課題があり，そこに見える化・合意のために作業コストを裂くべきなのかを探ることです。すなわちモデリング戦略を策定します。図3を見てください。これはモデリング戦略の例です。

図3●AsIs優先型のモデリング

　まず，AsIs（現状）のシステム構造からTFP分割手法（要求開発で発案された概念モデル）によりざっくりと見える化します。その後，ToBe（将来）の業務についてビジネス・オペレーションとIT活用の両面で見える化（モデリング）していきます。

　その結果，ToBeビジネス・オペレーションの効果を検証できたら，次はToBeのビジネス情報構造をTFP分割手法によって表現します。そして最後に，AsIsのTFPモデルとToBeのTFPモデルのギャップを分析することで，変えるべきポイントを見つけていくのです。ToBe（将来）の業務のIT活用部分から基本的な機能要求が開発され，TFPモデルのギャップを分析の結果からあるべきシステム構造の非機能要求が見つけられます。

　図3のようなモデリング戦略はあくまで一例です。この例の特徴は，AsIs優先で，かつAsIsのWhatは省略しています。実際には，ToBeのWhatを考えるときにAsIsのWhatを思い出すようにすることで作業時間の短縮化を図るという戦略が含まれているので，AsIs業務の詳細と価値をきちんと理解している人がいなければ，この戦略はうまくいきません。

　この戦略の長所は，とりあえずざっくりとAsIsのシステム全体の鳥瞰図をTFP手法によって見える化できることです。欠点としては，ToBe業務とは関係しない，AsIsのシステムの構造を描くための時間が必要になることです。このような欠点を解消するためにも，立案フェーズで短時間ざっくりモデリングできるTFP分割手法は有効な手段なのです。

　次は，図4を見てください。これはToBe優先型モデリング戦略の例です。

図4●ToBe優先型のモデリング

　最初に，ビジネス戦略で狙いを定めたビジネス・オペレーションについて，IT活用を含めてダイレクトにToBeイメージを描きます。そして，その有効性を評価した後に，今度はToBeのHowとしての，ビジネス概念の情報構造（TFP分析）のモデル化を行いつつ，ToBe業務に関係する部分だけ，現況（AsIs）のWhatとHowを確認します。

　このような方法で，現状と将来の構造のギャップ分析をTFP分割の結果などを利用して行いますが，これについては要求開発の立案フェーズではなくデザインフェーズで行うことになるでしょう。なぜならTFP分割手法で作成されたモデルについて，もう少し詳細化されたデータモデルなどを作成していかないかぎり，正しいギャップ分析はできないからです。

　そのためにTFP分割では，詳細モデルへのトレーサビリティを確保するための工夫を凝らしています。すなわち，Plcae図，Function図，Thing図に分けることで，それぞれの図の役割ごとに，広域アーキテクチャの詳細化，アーキテクチャの詳細化，データモデルの詳細化につなげられるようにしています。これについては，また別の機会に説明したいと思います。

　要求開発では，このような流れでToBeビジネスの姿を見える化し，そこから要求を開発していくのです。

　今回は簡単にまとめるつもりでしたが，ちょっと複雑な話になってしまいました。最後に，先ほど触れた，ビジネス要求をIT側から創発しているような様相では，HowがWhatに影響を与えるという摩訶不思議な関係から要求が開発されるという部分について，もう少し深堀りしてみたいと思います。

　これは，ビジネス戦略にはIT戦略が深く絡んでいるという事実を意味します。このことを経営者や，技術者は再認識すべきではないでしょうか。

　図5は，ITはHowではなくビジネス戦略の一環であることを説明している図です。この図のように，ToBeビジネスを，図3と図4のように単にWhatとHowに分類するだけではなく，WhatとHowそれぞれにビジネスとITを表現すると，摩訶不思議なビジネス戦略と要求の構造をわかりやすく表現できるようになります。