• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

要求開発アライアンスのビジネス・モデリング道場

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

2007/02/15 ITpro

 今回と次回は,ビジネス戦略と要求について2回に分けて書いてみます。

 まず図1を見てください。この図の下のほうに,システムの要求はWhatで設計はHowと書かれています。そうですね,よく新人のころ,要求(何)が決まらないと,設計(どうする)は考えてはならないと手痛く教えられたものです。

図1●ビジネスからシステム開発につなげる表と裏
図1●ビジネスからシステム開発につなげる表と裏

 しかし,要求は実はHowという側面もあります。要求の根拠はビジネス・オペレーションだからです。ビジネス・オペレーションがWhatで,要求がHowという見方が重要です。

 さらに言うと,ビジネス戦略がWhatで,ビジネス・オペレーションがHowという見方ができます。このことが企業の中で理解されていないと,価値のないシステムを作り上げてしまいます。

▲ビジネス・オペレーションがWhatで,要求がHowという見方をおこたると
→現状の業務にあわせて一人のユーザーから言われたとおりに要求を定義してしまう
(その業務は,改善しなくていいんですか?)

◎ビジネス・オペレーションがWhatで,要求がHowという見方を要求開発チームが理解していると
→現状の業務について問題点を整理して,問題改善や効率化などを加える中で要求を作り出すことができる

▲ビジネス戦略がWhatで,ビジネス・オペレーションがHowという見方をおこたると
→ビジネス・オペレーションのビジネス価値について,何も検討しないうちにシステム要求を出してしまう
(もっと他に重要なビジネス課題があるのではないですか?)

◎ビジネス戦略がWhatで,ビジネス・オペレーションがHowという見方を要求開発チームが理解していると
→ビジネス戦略上最も価値の高いビジネス・オペレーションをターゲットとして,そこからシステム要求を出す

 さて,このビジネス戦略からビジネス・オペレーション,そして要求(ビジネスとIT)までを,要求開発ではどのようにうまくつないでいくのでしょうか。

 要求開発では,このためにコタツモデルというメタファを大切にしています。コタツモデルとは,ビジネスオーナー(トップ),業務担当者,IT担当者という3種の役割を持った人達を集めた要求開発チームのことです。そしてこの3つの役割を持つ人達がコタツに入って議論しながら要求を開発するというわけです。

 実際には,トップは月1回程度,要求開発の報告会に参加して戦略面・戦術面・開発プランなどの説明を受け,その中で承認をします。コタツモデルは,戦略の見える化から,スコープ(範囲)とリソース(やれる人,期間,金)のバランスを取りながら要求開発プロジェクトとしてのゴールの策定を行い,ビジネス・オペレーションの見える化,要求の発見(開発)につなげていきます。

 私はいつも「要求開発方法論は調味料でしかありません。要求開発に最も大切なのは,コタツモデルという場をいかにして作り上げるかなのです」という話をします。そのため要求開発として最初に行うべき重要なミッションは,要求開発チーム(コタツモデル)の形成です(図2)。そして,要求開発チームのモチベーションを常に高めた状態でプロジェクトを進めていくことが最も重要なのです。

図2●コタツモデル
図2●コタツモデル

 コタツモデルで行うこと,それは,ビジネス戦略,ビジネス・オペレーション,要求の関係を見える化することです。そして取捨選択することが重要となります。ここでは,この取捨選択のことをトリアージ*1といいましょう。

*1 トリアージ(triage)は,要求を戦略的に取捨選択すること。もともとは医学用語で,有限のリソース(医師や医薬品など)を最大限に活用し,各患者の病状や状況に合わせて,より多くの傷病者の治療をするために優先順位を決定することを指す。

 トリアージとは,ビジネス戦略を見える化し,その戦略の中から,ここ数年最も重要な戦略を選択することです。ビジネス戦略を見える化して,トリアージ可能にすることが重要です。

 ビジネス戦略が見える化されトリアージされると,その戦略(What)を実現するためのビジネス・オペレーション(How)の候補を決めることができます。そして,ビジネス・オペレーション(What)の候補が決まると,要求(How)の候補が決まります。

 このようにビジネス戦略→ビジネス・オペレーション→要求という関係をトレーサブル(追跡可能)にすることで,システム要求の根拠がビジネス・オペレーションとして理解でき,ビジネス・オペレーションの根拠がビジネス戦略として理解できるようになります。

 要求開発では,ビジネス戦略をBSC(balanced scorecard)戦略マップなどで見える化します。その見える化された戦略の中で,要求開発のゴールとして,どのビジネス戦略を対象とした活動とするのかをトリアージするのです。

 トリアージは,実現リスクが少なく,プロジェクトとしてコントロール可能な戦略を選ぶことです。これは戦略の中で最も重要です。図3を見てください。この図では戦略がトリアージされると,その戦略を実現するためのビジネス・オペレーションが選ばれ,そのビジネス・オペレーションを実現するための要求が選ばれることを示しています。

図3●戦略のトリアージ
図3●戦略のトリアージ

 もっと細かく正確にこの話しを展開すると,ビジネス戦略を実現するビジネス・オペレーションには,いくつかの方法がありますし,ビジネス戦略を実現するための要求もいくつかの方法があるでしょう。また,ビジネス戦略をトリアージすると,そのトリアージされた戦略に基づいて,重要なビジネス・オペレーションにスポットライトが当たるというのが正しい表現なのかもしれません。

 そして,スポットライトが当てられたビジネス・オペレーションのあるべき姿を分析する過程の中から,システム要求の候補が発見されていくのです。つまり,戦略によって分析対象の絞込みを行うことで分析作業の効率化を行うのです。これは要求開発が最も大切にしている分析作業の最適化なのです。

 しかし,図3では話を簡単にするために,1対1の関係で説明してあります。この図で選択されているビジネス戦略を,もし異なるものに変更した場合,ビジネス・オペレーションも変更されるでしょうし,要求も変わる可能性があるわけです。

 実際には,ビジネス戦略などは企業の状況やビジネス環境の変化に追従して,変化していきます。よって,ビジネス戦略から要求までをトレーサブル(追跡可能)にしておき,変更する必要性が生じた場合でも,このような図の中で変化を見える化することが重要です。

 このようなトレーサブルな世界を作り出すには,どうしても洗練されたツールが必要になりますが,いまのところありません。要求開発アライアンスの平鍋健児理事(チェンジビジョン社長)にはぜひ取り組んでいただきたいツールだと個人的には思っています。

 ところで,なぜ一度見える化された戦略をトリアージしなければならないのでしょうか? それは,ビジネス戦略は,賞味期限がある生ものだからです。ビジネス戦略に賞味期限があるとするならば,ビジネス戦略の実現としてのビジネス・オペレーションや要求も賞味期限のある生ものです。

 ビジネス戦略が生ものであるという意識は重要です。そういう意識を持って,できるだけ早く実現することが大切なのです。それゆえ,いま最も必要な戦略をトリアージして,それに対するビジネス・オペレーションおよび(システム化が必要であれば)システム化要求を出す必要があるのです。それを図4で簡単に説明してみましょう。

図4●ビジネス戦略には賞味期限があるのでトリアージが重要
図4●ビジネス戦略には賞味期限があるのでトリアージが重要

 まず2007年3月にビジネス戦略として10個の課題が見える化されたとしましょう。そして,その中で最も重要で,できるだけ実現しなければならないものに優先順位を付け,その結果,戦略3つがトリアージされたとします。すると,その3つの戦略を実現するためのビジネス・オペレーションと要求が整理され,システム開発が行われます。

 その結果,1年後の2008年3月には,3つの戦略が実現され,次のビジネス戦略をトリアージします。ここで重要なのは,1年前のビジネス戦略が1年後にはもう不必要になっている可能性があるということです。したがって,1年前のビジネス戦略から,いま生きているビジネス戦略を引き継ぎ,それ以外に新たなビジネス戦略を候補として列挙します。

 そして,図4では2つの戦略がトリアージされ7カ月(2008年10月)で実現されています。ビジネススピードが増せば増すほど,トリアージされる戦略は少なくなり,実現スピードも高速になっていくでしょう。

 ここで考えてください。もしも2007年3月に,見える化された戦略すべてに基づき,ビジネス・オペレーションと要求が作り出され開発計画が立てられたとしたら,開発が終わるのは2年~3年後になるでしょう。そして,そのころには,最初に必要だと思われたビジネス戦略が不必要となり,価値のないシステムを使うということになってしまいます。

 このようにビジネス戦略をトリアージする理由は,戦略が生ものであるため,新鮮なうちに(短期間で)料理することでビジネス価値を高めなければならないからです。

 これをどんどん進めていくと,将来においては,前々回に紹介したように(図5),継続的ビジネス価値創発の連鎖の中で要求開発とシステム開発がスパイラルに回るといった状況へとつながるでしょう。

図5●継続的ビジネス価値創発の連鎖
図5●継続的ビジネス価値創発の連鎖

 将来はさておき,短期間で必要なビジネス戦略の実現を行い,ビジネス・オペレーションと要求を発見しシステム開発につなげつつ,次のビジネス戦略の実現を行っていくためにも,このような活動を見える化する必要性が理解できると思います。

 今回は,これでおしまいです。次回は,この続きで私が見ている戦略と要求の摩訶不思議な関係について,話を深めていきます。

(萩本 順三=要求開発アライアンス理事)

■変更履歴
本文を一部修正しました。JR福知山線脱線事故でトリアージが使われていた事実を,この記事を書いた後に知りながら,記事中に不適切な表現を残しておりました。ある方からの指摘により,不適切な表現に気が付き,訂正した次第です。情報発信者として,このような事がないよう十分気をつけたいと思います。萩本 順三 [2008/06/02 17:06]

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る