ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第7回は、僕がソフトウエア開発の経験や要求開発を通して少しずつ分かってきた、人間の活動における普遍的な成功パターンをテーマにします。それは、一般常識を飛び越えていかなければ見つからない面白い領域でした。僕が最初にそれを意識し始めたのは、1996年くらいに着手したオブジェクト指向方法論「Drop」を作成しているときのことです。

手順的に書けば書くほど嘘になる現実

 当時、僕は一つの壁にぶつかっていました。方法論を理論的に、分かりやすい手順として、文章や図を書けば書くほど嘘っぽくなってしまうのです。自分が考えていることを手順的に書けば書くほど、自分の頭の中では「そのようには考えていない」と思ってしまうことに悩み続けました。

 僕は、暗黙知の領域を書き示すことの壁にぶつかり始めていたのです。そして、そのような領域を、下手に形式知に変えることに罪を感じたものです。後に、ビジネスやITのさまざまな場面で、この時に感じた現象と似たような現象があり、それによって種々の問題が起こっていることを知ることになるわけです。

 その現象や問題とは何か。そして、それはどう解決すべきなのか。これが第7回の摩訶不思議な旅のテーマです。

ToBeビジネスの見える化

 まずは図1を見てください。これは、ビジネスの「AsIs」をしっかりと分析し、その次に「ToBe」ビジネスを描いていくという図です。そして、AsIsとToBeのギャップについて、どのように解決するかを検討していくという方法を説明しています。あるいは、ToBeをあるべき姿だと定義して、そこからAsIsをしっかりと分析し、ギャップ分析を行う方法もあるでしょう。

図1●従来のビジネス見える化の方法
図1●従来のビジネス見える化の方法

 このような方法は、EA(エンタープライズアーキテクチャ)をベースとしたビジネスの“見える化”などでも使われています。その特徴は、AsIsやToBeをしっかりと徹底的に分析することです。そして、この方法の問題は、多大なコストと大量で分かりづらいドキュメントを生産してしまうことです。

 これに対し、要求開発において洗練させてきた方法は、「Howの手探り」という表現で説明しているように、仮説を立てて、そこからToBeとAsIsを手探りするやり方です。

 図2を見てください。この図では、仮説として立てたToBeの戦略あるいは小さめなアイデアについて手探りをしています。

図2●要求開発によるビジネスの“見える化”の方法
図2●要求開発によるビジネスの“見える化”の方法

 ここでの手探りとは、「現状本当に問題があるのか?」というAsIsへの検証と、「本当に変更できるのか?」「変更する際のポイントは何か?」「変更した際の価値はどの程度あるのか?」というToBeへの検証を行うために、手探り的にAsIsとToBeのモデルを描いていくやり方です。そして、仮説が正しくなければ、次の仮説を立て、また手探りを始めます。

 この方法では、最小のコストで、最大の価値を得るための当たりをつけていきます。ただし、その当たりをつけるポイントはというと、実はあまり明確な答えを僕も持っていません。唯一言えることは、ビジネス戦略を見える化した際に、戦略に現れるビジネスオペレーションの課題などが、攻略ポイントになります。