PR

 筆者は要求開発コンサルタントとして様々な企業に営業訪問している。実際の案件につながるのは,その中のほんの数件なのであるが,営業活動の中で得られる情報は非常に多い。中でも大変有意義なのが,お客さんの悩みを聞けることである。

 例えば,ビジネス・モデリングはやったけど,その結果をどのように利用すべきかが分からないという悩みをよく耳にする。いろいろと話を聞いてみると,そもそも目的を明確にすることなくモデリングを開始してしまうのが原因のようだ。プロジェクトの中でビジネス・モデリングを実施する際の目的・計画・評価方法が不明確な段階で,いきなり細かいレベルでモデルを作ってしまうのである。

 例えばプロジェクトの開始早々,詳細なビジネス・フローを何十枚も描こうということになり,チームはいきなり全力疾走を始める。そして,そのモデルが完成したときに初めて,いったいこのモデル(ここでは業務フロー)は何のために描いたのかという議論になる。「この大量のドキュメント,せっかく作ったけど,どうするの?」---そんな現場の声が聞こえてくるような気がしないだろうか。

 このような問題は,多くのシステム開発プロジェクトで発生している。皆さんが今開発中のシステムについて考えてみてほしい。はたしてシステムを作る目的を当事者たちがしっかりと把握し,関係者間で合意して進めていると言えるだろうか。トップ・レベルでの価値や目的を整理して,システム開発の範囲を決めているだろうか。

 このような状況にプロジェクトが陥る原因は,作業の目的をきちんと定義付けていないことにある。つまりは目的志向でプロジェクトが動いていないのである。ビジネス・モデリングの場合なら,何のためにモデルを描いて可視化するのかが明確でない。モデリングすること自体が目的になってしまっては,完成した後で悩むのも当然ではないだろうか。

教訓
ビジネス・モデリングをする際には,「なぜこの図を描いているのか?」「なぜ可視化する必要があるのか」を,常に自分やチームに問いかけながら作成すべし。

制御できる個所,する価値のある個所に絞ってモデリングする

 モデリングは,問題領域の本質的な面を抽象化した図を描くことで,関係者間の共有知を増やそうという行為である。ただ,このこと自体はモデルを描く目的の最低ラインに過ぎないと私は考えている。それだけでは,ビジネス上の価値につながらないのである。

 モデリングをビジネス価値につなげるにはまず,モデリング対象を選ぶことから考える必要がある。その際のポイントは2つある。一つは「制御可能な個所」を選ぶこと,もう一つは「制御価値がある個所」を選ぶことだ。

 まずは制御可能な個所を選ぶことから説明しよう。モデリングは,問題領域を可視化する作業である。可視化するのは,問題個所を見つけて改善を加えたいからだ。であるならば,そもそも今取り上げようとしている問題領域が,モデリングを担当するメンバーで改善可能なのかどうかを先に考えておく必要がある。

 例えば,要求開発メンバーにスタッフ部門の人間が一人もいないのに,ビジネス戦略についてのビジネス・モデルを描き,そのビジネス・モデルをどうだこうだと話し合ったとしたら---。ビジネス・モデルを理解するという効果はあるかもしれないが,理解した後で改善しようと思っても,自分たちではどうすることもできないだろう。

 このような問題領域の場合,チームにスタッフ部門の人を入れておくか,会議のオブザーバとして参加してもらうのが望ましい。そして,仮説的に問題領域の改善部分を予測し,その予測された改善個所がスタッフも含めて制御可能(変更可能)であるかどうかを考えておくのである。そうしないと,「絵に描いた餅」を作ってしまい,要求開発活動の信頼を得られなくなる。これは,私が要求開発プロジェクトの課題を選ぶ際に最も意識している点である。

 制御可能であるかどうかに加えて考えるべきなのが,制御する価値があるかどうかである。つまり,問題領域に対して改革・改善の意識を持って描いた「To Be」としてのビジネス・モデルが,どの程度価値があるかということだ。これには,要求開発プロジェクトとして目指すべきゴールに照らし合わせて適切かどうかを意識するとよい。もちろん,その際には要求開発プロジェクトのゴールを決めていることが前提になる。

教訓
ビジネス・モデリングを成功させるには,問題領域の中から「制御可能な個所」と「制御価値がある個所」を選び出してモデリング戦略を立てよ。

スコープ,リソースとバランスをとりつつゴールを決める

 要求開発プロジェクトは,システム開発プロジェクトよりも前の段階で実施されるプロジェクトであるが,実際にはシステム開発プロジェクトを囲い込むようなプロジェクト・ライフサイクルとなる。要求開発メンバーは,システム開発プロジェクトの計画段階に深くかかわり,システム開発が円滑に進行しているかどうかを確認する。システム開発が完了すると,今度はビジネス的な視点でシステム開発の成果を評価する。このように,要求開発プロジェクトは,いわゆるPMO(プロジェクト・マネジメント・オフイス)の役割も果たすものである。

 さらに言えば,このPMOは要求開発プロジェクトが持つ複数プロジェクト管理機構の一部に過ぎないとも私は考えている。私の感覚では,要求開発の課題は企業における永遠の課題である,ビジネス改革・改善活動そのものであるからだ。

 と話がずいぶん大きくなってしまったが,地道に考えれば要求開発のプラニングは非常にシンプルである。それは,「スコープ」,「リソース」とのバランスをとりつつ,最終的に要求開発プロジェクトとしてのゴールを決定することから始まる。このゴールは仮説であってもよい。とにかくプロジェクトのゴールを決めることが肝心である。

 ここで言う「スコープ」は,問題領域の範囲をどこまでとするかだ。また「リソース」は,その問題領域のスコープを実現するために必要とされる人材は誰で,期間はいつまでか,である。これらの制約の基でゴールを決める。これら3つ(スコープ,リソース,ゴール)を決定する順番に決まりはない。要はバランスを取ることが重要なのだ。

 そして,そのゴールは,ビジネス戦略と深くかかわる。要求開発方法論では,BSC(バランス・スコア・カード)やトップダウン/ボトムアップ・ビジネス分析によって,ビジネス戦略を戦略地図として見える化する。

 このように戦略地図からゴールを定めていくと,ビジネス上のゴールを達成するためにどの個所をモデリングすべきかが見えてくる。また,その個所が制御可能であるかどうかは,「リソース」の人材選びで解決されているとしてよい。そして,To Beのビジネス・モデルを描く過程で要求が開発されるのである。これらは,要求開発プロセスにおける「準備フェーズ」として説明されている。

 ちなみに,このスコープ,リソース,ゴールは,安井 昌男 理事の発案で要求開発方法論に採用されたものだ。私もこのやり方によって,要求開発活動が制御しやすくなったので非常に気に入っている。

教訓:
要求開発プロジェクトのゴールは,リソース(人材)とスコープ(範囲)のバランスによって決定される。さらに,そのゴールは,ビジネス戦略におけるゴールの一部となっていなければならない。

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