|
なお、タイトルの上に書かれた近藤さんの肩書きですが、“CBAP®”は、Certified Business Analysis Professional™の略号です。この資格試験は、カナダのIIBA® (International Institute of Business Analysis)が、ビジネスアナリシスの知識体系であるBABOK® (Business Analysis Body of Knowledge)に基づいて世界で統一的に行なっているビジネスアナリストの認定試験です。CBAPはその合格者を意味しています。この資格を持つ日本人はまだ10数人しかいない狭き門だそうです。
近藤史人氏と直接コンタクトを取りたい方は松本までご連絡下さい。近藤さんからメールをお送りするように連絡します。 （松本憲洋） １． 人工物進化と情報システムと組織マネジメント 1月2日のNHK BS1で、“2012 巻頭言特集「Ｊ．ダワー×Ｇ．マコーマック 震災後 日本と世界への眼(め)(前編)」 ジョン・ダワーとガバン・マコーマックが見つめる激動の未来▽変わるアジア太平洋世界”という番組があり、興味を持って見ました。 ジョン・ダワーという人は、現在、マサチューセッツ工科大学の教授で“Embracing Defeat”邦題：「敗北を抱きしめて」という著書でピュリッアー賞を受賞した終戦直後の日本を深く研究した日本近代史の研究者だそうです。一方で、ガバン・マコーマックは、オーストラリア国立大学で教鞭をとる東アジア研究者だそうです。この二人が、3.11後の日本についてさまざまな観点から意見を交わした番組で、とても有意義な視点をたくさんいただきました。中でも印象に残ったのは、東日本大震災は天災だが、Fukushimaは、人災であると述べていたことです。興味深いのは、3.11にいたるまでの日本を戦後の日本から捉えなおし、経済成長という柱とアメリカとの安全保障条約という柱を軸にして経済大国になった日本を見直すべき時期に来ているという視点でした。 日本は原子力爆弾で多くの人命を失った世界唯一の国でありながらアメリカとの安全保障条約に重心を置き、原子力に反対するのではなく、非核３原則を唱えながらも原子力発電には積極的に取り組んできた。原子力の兵器としての利用と平和利用とを別物として解釈してきたという発言に興味を持ちました。私自身は、90年代に日本の電力業界が規制緩和され、さまざまな業種から電力業界への進出が進み、発電、送電、配電の各電力サプライチェーンのいたるところで自由競争が起こり、さまざまな合理化が進んでいるものとばかり思っていましたが、Fukushimaの事件によって、実は大手電力会社と政府・官僚のポリティカルパワーが、規制緩和を十分には進めてこなかったということが判明し、愕然とした印象を持っています。再生可能エネルギーの十分な活用もそれらの勢力の前に進むことができない状況にあるのではないかと思っています。 一部の官僚や政治家が描く社会の姿に民衆の意見を反映させる真の民主主義が定着しなかったということは、沖縄の問題にしても同様で、沖縄の市民は日米安保条約の犠牲にならざるを得ない状況に置かれているということです。3.11をきっかけに、今まで官僚、政府主導で築いてきた壁が大きく口をあけスペースができている。そこから日本に本当の意味での民主主義が生まれる可能性があるのではないかという意見が交わされていたことに大きな希望を感じました。
この対談を聞いて感じたと同じような感覚をここ数年の企業でのコンサルティングで感じたことがあります。 ある企業で、情報システムの企画部門の方が、社内に散在する顧客情報を統合し、顧客のプロフィールに基づく効果的なマーケティング活動を行えば、もっと業績を上げられるはずとの思いから「情報活用による営業改革」を進めよう企画し、私はそれを支援する立場で関わらせていただいたことがあります。情報システム部内での検討では、顧客情報を活用して効果的なマーケティング、販売活動をすることへの合意が得られ、方向性も見出せたにもかかわらず、マーケティング部門や営業部門を巻き込んで進めようとすると、これがうまくいかない。なぜかというと、マーケティング部門も営業部門もそれぞれの立場で抱えている業務の目標があり、それを遂行することに手一杯で、少し横にそれて自分たちの仕事そのものを考え直してみる余裕がない。我々の提案自体はいいものとの評価をいただいていたので、少し立場を離れて考えてみればいいと思えることが、組織の中のある役割にはまってしまうと、そのいいと思うことが実行できないということだと思います。つまり、あるがままの状態で進むことしかできない構造ががっちりと出来上がっており、その構造の中で、構造が与える仕事を精一杯こなすことしかできない状態にあるのです。構造そのものを考え直し、変更してよりよいものにするためのムーブメントを起こすことができないのです。 このことは多くを考えさせられます。国も企業もある構造を持って活動をしています。企業や社会を動かす仕組みは、組織の構造であったり、業務ルールであったり、顧客との関係であったり、評価指標であったりさまざまなものがありますが、これらは、長い年月をかけて、さまざまな失敗や成功などの経験から人間が作り上げてきた人工物です。いったん出来上がった人工物は、状況が変わっても新しい状況に合わせて変更することができない。少し立場を離れて、遠くから眺めてみれば、おかしなことをやっていると誰でも思うようなことが、その立場の中に組み込まれてしまうと、おかしなことの中で動くしかできない状況が出来上がってしまうのです。 産業革命の初期に工場の動力が水車から電動モータに変わったとき、電動モータの配置を自由に設定できるメリットを活用して生産効率を上げられるように機械の配置が変更できたのは、水車時代に工場長をしていた人たちが引退する20年ぐらいたった後だったという話がある書籍で紹介されていました。水車の動力を伝達することを最優先して工程を作っていた時代からその必要がなくなった電動モータが導入されても電動モータのメリットを生かせる配置に工程が変更されるには、水車の経験を持った人がいなくなるまで待たなければならなかったという恐ろしい話です。さらに恐ろしいのは、これが、けして産業革命の初期の話だけではなく、現代にも続いているということです。つまり、業務プロセス、組織形態、慣習などの人間が作り出した人工物は、それ自身では進化することができない、外部環境の変化に適応した最適なものにできないということです。 人工物の最たるものが情報システムですが、巨大な情報システムになるとそれが完成する前からすでに陳腐化が始まるといわれています。私は、情報システムの構築という現場にかかわって社会人生活を30年以上送ってきましたが、こうした悩みに常に付きまとわれてきました。
ここで情報システムそのものについてすこし考えて見ましょう。現在のコンピュータの動作原理は、ノイマン型といわれているもので、携帯電話のような小さなものから「2番じゃ駄目なのですか？」という蓮舫議員の発言で有名になった世界一のスーパーコンピュータ“京”のような巨大なコンピュータにいたるまで、内蔵メモリから命令を取り出してそれを解釈して実行する逐次処理と呼ばれる仕組みで成り立っています。この仕組みを作った人は、ジョン・フォン・ノイマンというブダペスト生まれで後にナチスから逃れるため、ハンガリーからアメリカに亡命した数学者ですが、彼は、今日のほとんどのコンピュータで使われている基本原理であるストアードプログラム方式を発明しただけでなく、もっとも熱心に研究に取り組んだのがセル・オートマトンと呼ばれる分野だといわれています。 セル・オートマトンというのは、方眼紙のような細かい枡が数多く集まったもので、その枡の隣り合うもの同士がお互いの状態に反応して自らの行動を決めるルールを決めておき、そのルールを何万回も実行すると方眼紙の上に思いがけないものが出来上がるというものです。言葉だけでは何を言っているのかわからないかもしれませんが、オセロゲームを思い浮かべていただき、ある枡の中の駒の右にいる枡の駒が黒で上にいる枡の駒が白なら自分は黒になる、というような単純なルールを想像してください。こうした単純なルールを方眼紙のすべての枡の中の駒に同時に適用します。設定された初期値が１回目、2回目とルールを適用していくとそれぞれの枡の中の駒は、裏になったり表になったりして変化し、全体がどんどん変化していきます。これを何万回も繰り返し、その変化を眺めているとあたかも方眼紙の上に鳥が飛んだり、何かが固まって動いたり、生物が現れ、死んでいくように生き生きと生物が動くような現象が見えてきます。後に「自己増殖オートマトンの理論」として理論化されるものですが、この理論に基づくコンピュータを自己増殖マシンと呼びます。自己増殖マシンが目指すところは、後に「人工生命」としてさまざまな研究者が取り組む研究分野となりますが、つまるところ目指すのは、人工物が自ら進化を遂げることです。 1994年にカール・シムスというグラフィックアーティストが、「進化するバーチャル・クリーチャーズ」という作品を発表しました。スーパーコンピュータの中に遺伝子を持った仮想の生物を作成し、仮想の水という環境の中で仮想生物がどのように生き延びていくかを遺伝的アルゴリズムという方法を用いてシミュレーションしたものでした。仮想の生物たちは、それぞれの特徴を生かして、蛇のように体をくねらせて泳ぐ生物に進化したり、魚のような動物に進化したり、タコの身体を収縮させて動く生物になったり、様々な状況に適応進化したまるでカンブリアの海に存在した生物多様性の見本のような進化がコンピュータのシミュレーションによって作り出され、グラッフィックで表現されました。NHKでも放送されたので、ご覧になった方は多いかと思います。今のところこうした人工的な進化のシミュレーションは、人間が作り出した仮想の環境の中で行われているようですが、近い将来、我々人間が暮らすのと同じ自然環境の中で進化する人工生物が出てくる可能性もないわけではありません。現在のロボットが、自然環境の中で、外部環境をセンスしながら行動している現状からすれば、論理的には不可能なことではないかもしれません。 大変、難しいことであるにもかかわらず、なぜこんなことに一生懸命になる人がいるのかといえば、それは、自ら進化できない人工物というものがいかに厄介な存在であるかということに尽きると思います。保守しなくても自分で壊れたところを治してくれる機械や体のサイズに合わなくなった衣服が自分から大きさを変えて常にぴったりと体形にフィットしてくれたらどれほど楽なことか、少し薄気味悪くもありますが、そんなことを人類は夢見て人工物の開発を進めているのではないでしょうか？ しかし、今のところ、いったん作り出した人工物は、古くなり、壊れることはあっても自ら再生することはありません。一方で、自然界は人間も含んだ生物の営みによって刻々と変化し続け、片時も同じところにとどまることはありません。われわれ人間が生み出すさまざまな人工物というシステムは、この変化する状況の中で、我々生態系の変化に適応できるよう人間自身がコントロールしなければなりません。国家であれ、企業であれ、組織をマネジメントする立場に立たされた人は、常にこの厄介な問題と向き合わなければなりません。特に対象が情報システムの場合、単にシステムだけを更新すればいいということにはならず、それを活用する仕組みそのものを更新しなければ業績向上にはつながらないというところが厄介なことです。
人工物である組織のマネジメントを考える際には、現代の企業社会の特質をよく考える必要があります。日本の場合には、50年代の戦後の復興期から60年代、70年代とモノのなかった時代を通じて、電化製品や自動車に憧れて一生懸命に働き、こうした憧れのものを手に入れることを目標にして経済大国になってきました。向かうべきところが誰にでもはっきりとしていた時代で、まじめにがんばりさえすれば成功できた時代です。こうして築き上げてきた日本の企業社会の人工物は、90年のバブル崩壊というよりもそれ以前の85年のプラザ合意の時点ですでに機能しなくなっていました。主要5カ国の財務省・中央銀行総裁会議、世に言うＧ5という会議で、アメリカに輸出攻勢をかける日本の為替レートを円高に誘導することが決定されました。各国政府が介入して為替のレートを誘導するというようなことは歴史上前代未聞だったらしいですが、人為的に円高に誘導されたことにより、日本の輸出企業は大打撃を受け、それを回避するために政府・日銀がとった金融緩和政策が、豊かになりモノのあふれている日本の社会で金余り状態を招き、株・土地といった投機的な投資対象に金が流れてバブルを膨らませ、やがてそれが破裂して日本は沈みます。以来、今日まで、日本の企業社会は新たな成長パラダイムを見いだせないまま低迷期が続いています。 60年代、70年代と今日とのもっとも大きな違いは、まず、モノがあふれている成熟社会であるということ、それと、情報通信、交通の発達したグローバル社会であるということ。この二つが経済社会にもたらす意味をよく考えなければならないと思います。こうした成熟社会、複雑化した社会でのマネジメントのあり方について、ピーター・Ｍ・センゲは、以下のように著書“The FIFTH DISCIPLINE The Art & Practice of The Learning Organization”：邦題、「最強組織の法則」の中で述べています。 「世界がますます緊密に結びつき、ビジネスがさらに複雑化しダイナミックになるにつれ、仕事はますますラーニングフルになる。～中略～ トップの位置で「事態を読み」、他のみんながこの「大戦略家」の指示に従うといったやり方では、もはやとうてい対応不可能なのだ。これから本当の意味で抜きんでる組織は、あらゆるレベルのスタッフの意欲と学習能力を生かすすべを見出した組織となるだろう。」 組織の向かうべき方向がはっきりしていて、変化が予測可能な状況にあった高度成長期には、全体を考える特定の戦略家がいて、その他の現場の人たちは、自分に与えられた役割さえ果たしていればうまくいっていた。しかし、モノのあふれた成熟社会、情報通信と交通の発達したグローバル社会では、先が読めない。思いがけない変化が突然やってくる。こんな不確実性の高い状況の中で我々は、自分自身で進化することのできない人工物をどのようにマネジメントしていかなくてはならないかを考えるべき時代に来ていると思います。
ここで少し目を転じて、昨年の楽しかった出来事を思い出してみたいと思います。昨年は、おそらくほとんどの日本人にとって、つらく悲しい出来事の連続だったのではないかと思いますが、そんな暗い中で、明るい感動の光を燈してくれた出来事がありました。 “なでしこJapan”のサッカーワールドカップの優勝です。サッカーフリークの私は、澤選手が金色のカップを掲げ、金色の紙吹雪が舞う中、躍り上がって喜ぶ“なでしこJapan”の選手・監督・スタッフたちの姿を見て思わず涙が溢れてしまいました。その後もニュースや再放送で何度も“なでしこJapan”の試合や表彰式の映像が流れますが、何度でも繰り返し見ては繰り返し感動しています。男子である我々のふがいなさを思いつつも彼女たちが見せてくれた「不屈の魂」には、感動を抑えることができません。おそらく東日本や和歌山県などの災害の被災者になられた方も勇気をいただいたのではないかと思います。澤選手が、メッシと並んでFIFAのMVPを受けたなんて、日本人のサッカーファンとしては、まるで夢のような話です。 私自身も数10年にわたりサッカーの選手、監督として活動してきましたが、グランドの上で試合の展開を勝利に向けて進めるサッカーの試合運びは、まさにピーター・Ｍ・センゲの言う「最強組織の法則」のマネジメントだと思っています。 サッカーでは、まず、監督が戦略を考えますが、現場の選手がそれをよく理解していなければならなりません。なぜならグランドの上では何が起こるかわからない、まさに不確実性の非常に高い状況が展開されるからです。試合の進み具合によっては、選手が自主的に戦略を変更して行動することも時にはあります。強いチームであればあるほど、グランドの上に立つ選手は、選手お互いの特質をよく理解し、相手チームの特質も理解し、その特質に合わせて、最も勝利に近くなるような行動を選択します。つまり、全員が全体のゲームの展開を常に意識しているのです。自分のポジションに与えられた仕事だけをこなしていればいいという考えではけしてうまくいきません。監督も選手も全員が監督になった意識を持ってゲームの展開をイメージし、それでいて、自分のポジションの役割を果たす。これが芸術的なレベルにまで高められたチームが、昨年、クラブワールドカップで世界一に輝いたFCバルセロナです。バルセロナといえばサッカーを知っている人なら誰しもアルゼンチン代表のメッシを思い浮かべますが、バルセロナの強さは、単にメッシだけではありません。 チーム全体がものすごい速さで情報を共有し、まるでグランドの上の選手たちが全体でひとつの生き物のように統合された意志を持ち、一糸乱れぬ早いパスワークを展開できることにあるのではないかと思います。準決勝で対戦したアジア王者のアルサッドは、ほとんどボールを触らせてもらえない状態で試合を終え、4：0でバルセロナが圧倒的勝利を収めました。決勝戦の南米王者サントスもペレの再来といわれるほどの才能豊かなネイマールという選手を擁しながら、こちらも4：0でバルセロナの圧倒的勝利です。とにかく早い展開でボールを次々と空いている選手に回し、少しでもディフェンスに穴が見つかれば怒涛のようにゴールに詰め寄る、こんなチームと対戦すれば、誰も勝つことはできないでしょう。 バルセロナが優勝した日のちょうど5日後に、私のチームが試合をしました。草サッカーではありますが、私のチームの選手たちは、バルセロナのイメージが脳に焼きついているのか、やたらと速いテンポでダイレクトパスやヒールパスを次々とつなぎ、メッシのようにドリブルで切り込み、先が詰まったかと見ると早いテンポでパス展開して、けして弱くはない、いつもは五分五分の試合をしている対戦相手に対して、その日の試合を圧倒的勝利に導くことができました。こうなると監督は何もすることがありません。ただオー、オーと感嘆しているだけで勝ってしまいます。勝利の形の全体像をイメージし、チームで共有するということがいかに重要なことかと大変な勉強になりました。 サッカーという不確実性の高いゲームでは、トップダウンで命令を下すアメリカンフットボールのような計算されつくしたゲーム展開は不可能です。全員が勝利の方程式をイメージし、そのイメージを情報交換しながらお互いに確かめ合い、違いがあれば修正し、変化があれば修正し、それを繰り返してより勝利に近づけていきます。 サッカーの監督は、澤選手がセンターライン5メートルを過ぎたら川澄選手は右のタッチラインを走って、宮間選手が澤選手のパスを受けて、川澄選手にセンタリングを送る、といった一人一人の選手の動きを決めるような指示を出すことはできません。試合前には、個々の選手同士のコンビネーションの動きを決めておくようなこともありますが、一旦、試合が始まれば、どのような状況が展開するのかわからない不確実性の非常に高いスポーツです。よりゴールの生まれる可能性の高い状況を作り出せば、後は確率で得点を得ることしかできません。どこかでうまくいかない選手が出てくればすぐに誰かがそれをカバーし、状況が変われば瞬時にそれに反応して全員が戦略を変える。こうしたことを可能にするためにグランドの選手同士も監督も、ものすごい頻度でコミュニケーションを交わしています。 こうしたサッカーのゲームマネジメントは、非決定論的なマネジメントだと私は思っています。選手一人一人の動きを決定論的なアルゴリズムで決めることができなくて、成功の可能性の高い状況、たとえば、タッチライン沿いに足の速くてドリブルのうまい選手を配置し、ゴール前に背の高くて一対一の競り合いに強い選手を配置するといったような状況を設定して、その状況の中で左右のタッチラインの突破とセンタリングからの中央でのヘディング勝負を何度も繰り返します。すると、うまく突破できるときもあれば、相手にボールを奪われることもあるけど、何度も成功に近づくパターンを繰り返していれば、そのうちにゴールをある確率で決めることができるというタイプのマネジメントです。 こうしたマネジメントで成功を収めるには、1にも2にもコミュニケーションです。コミュニケーションを通じて、全体の成功のイメージをチーム全員で共有し、認識が間違っていたり、状況が変わったりすれば瞬時にお互いの情報交換を通じて全体のイメージを修正する。100メートル Ｘ 70メートルのサッカーコートの上でならアイコンタクトと声の掛け合いで、何とかなりますが、何万人もの従業員を擁するグローバル企業ではそういうわけには行きません。そこで重要な役割を果たすのが、情報システムの活用です。
２． BABOKについて 前置きが長くなりましたが、ここからが本題です。前のセクションで、情報システムの活用と書きましたが、情報システムの活用に関して、ここ半世紀の間に大きな本質的変化が起こっていますので、まずは、その変化から見てみましょう。 世界最初のコンピュータといわれる（否定意見もあるが）ENIACが発表された1946年以来、コンピュータは、人間がとてつもない労力を要する事務的な作業を電子化して業務を効率化することにひたすら貢献してきました。1年半ごとに半導体の集積率は倍増するという「ムーアの法則」の予言どおり、コンピュータは高集積化され、それに伴い能力も向上し、コストも下がり、かつてそれを所有することは、先進的な大企業だけの特権だったものが、現在では学生ですら個人所有できるものになっていることは皆さんご覧のとおりです。 変化が現れ始めたのは、80年代の半ばを過ぎたあたりからです。事務作業の効率化に貢献するだけの存在だったコンピュータが、知的創造性を支援するツールという側面を帯びるようになりました。きっかけは、70年代からはじまるZEROXのパロアルト研究所で行われたアラン・ケイをはじめとする一連の研究者たちの研究成果です。ここに集まった研究者たちは、コンピュータを効率化の道具ではなく、創造性を支援するツールという位置づけで考えていました。アラン・ケイの同僚で、ハイパーテキスト（今日のWorld Wide Webに見られるような関連する複数の文書を、リンクを辿って情報検索する仕組み）の考案者であるダグラス・エンゲルバートに言わせると「コンピュータは思考方法を変えるもの」なのです。2005年ごろ、私は頻繁にアラン・ケイと会って話す機会に恵まれたのですが、アラン・ケイは、在庫管理のような業務的なコンピュータの活用をコンピュータの悪用と呼んでいました。彼らにとってコンピュータとは徹底的に知的創造力を高めるためのツールでなくてはいけなかったのです。アラン・ケイの提唱したダイナブックの概念が、今日のPCの大元になっているのは皆さんご存知のとおりです。先進的な研究を展開していたにもかかわらず、PARC（ZEROXのパロアルト研究所の略称です）の研究成果が本格的に製品として世に広がったのは、80年代半ばのApple ComputerがMacintoshを世に出してからです。PARCを訪れたスチーブ・ジョブズが、PARCの開発したALTOというオブジェクト指向のワークステーションにほれ込み、Lisaの開発を指示し、後にそれがMacintoshに受け継がれたことは、ジョブズが亡くなった昨年あたりから広がった多くの報道により皆さんご存知のことかと思います。 こうした動きと関連してもうひとつ忘れてはならないのが90年代の半ばごろから活発になったインターネットの商用利用です。当時、ITにかかわっていた人たちは、インターネットが仕事に活用できるものであることを、口をすっぱくして説いて回っていました。やれ情報の共有ができるだの、会社の宣伝ができるだの、人材募集ができるだの、今では当たりまえにやっていることが、当時は、眉唾物のように見られ、まったく手付かずの未開拓分野でした。エレクトリックコマースという言葉もバズワードのようにもてはやされたり、あるいは疑問視されたり。95年のあるシンポジウムで、エレクトリックコマースは、なぜ失敗したのか（まだ始まっていないでしょう、と今なら思いますが）というテーマで、アメリカから日本に来た有識者が真剣に討論していたことを今でも鮮明に覚えています。現在、インターネットは、スパムメール、ハッカー攻撃、情報漏洩など様々な問題を抱えながらもマーケティング、販売、人材募集、情報共有、コミュニケーションなど様々な分野でなくてはならない道具となっていることは皆さんご存じのとおりです。 一方で、90年代も終わり頃になると、効率化に貢献するためのコンピュータ活用は、ほとんどの企業ですでにいきわたってしまい、コンピュータを導入するというだけで競争優位を確立することはできなくなりました。以前は、生産性を上げることにより、競争優位を産んでいたのです。ITの現場では、価値を生まなくなった金食い虫のITのコストをいかにして削減するかが盛んに議論された時代です。効率化や部門独自の競争優位を生むという目的で導入された部門単位のサーバがどんどん統合され、コンソリデーション（システム統合）によるコスト削減こそがビジネス価値の源泉であると盛んにベンダーはユーザ企業に提案しました。当時私も外資系のITベンダーにいましたが、ビジネスバリューという言葉をTCO（Total Cost of Ownership）という言葉を覆い隠す飾り言葉のようにして米国の本社の連中が使っていたのを今でもよく覚えています。 21世紀に入ってIT投資と企業の生産性に関する研究がいくつも行われるようになりました。エリック・ブリニョルフソンというMITのスローンスクールの教授が、”Intangible Assets”：邦題、「インタンジブル・アセット「IT投資と生産性」相関の原理」という著書を出版してIT投資と企業の生産性に関する調査結果を発表しています。彼が、情報技術への投資と企業の生産性との因果関係を調査したところ、図1のように右肩上がりの相関関係があることが分かりました。
しかし、彼はこの結果に疑問を持ち、次のように考えました。サンプルの全体の傾向を見れば、高いIT投資が高い生産性を生んでいるように見えるが、高いIT 投資をしても生産性の低い企業がいることや逆に低いIT 投資でも高い生産性を上げる企業がいる。そして、このばらつきを生み出しているものは何かと調査して、それは、企業の組織力であると結論づけました。そして、エリック・ブリニョルフソンはIT 投資だけでなく、組織力も同時に上げることの必要性を説いています。 同じような調査を日本では、早稲田大学大学院・商学学術院の平野雅章教授が行い「IT投資で伸びる会社、沈む会社」という著書を出版しました。平野教授の調査によれば、IT投資と企業業績には、正の因果関係があるが、ただし、そこには条件がついて、IT投資が増えるほど組織能力が企業業績に与える影響が大きく、組織能力が高くなるほどIT投資が企業業績に与える影響も大きく、さらに組織能力が低いときにIT投資を増やしても効果は低いことを説いています。さらに注目すべき点は、平野教授は組織能力を、「従業員のモチベーションが高いという側面だけでなく、普通の能力の従業員が、特に高いモチベーションを発揮しなくても普通に仕事をしていて企業全体としての好業績を実現できる」と定義しています。つまりは、好業績をあげるための業務プロセスや意思決定メカニズムなどの、ITだけではないビジネスオペレーション全体としての「仕組み」がビルトインされた組織が好業績をあげるということだと思います。
企業が、ITを導入するのは何のためか？言うまでもなく、業績を今よりも上げるためです。過去には、ITは、導入さえすれば業務を効率化し業績に貢献することができました。しかし、そのような導入はすでにいきわたっていて、コスト削減のための工夫の余地が残されているとはいえ、先進企業ではそれも終わっています。さらにITを導入しただけでは業績を向上させることはできない、組織能力を向上させなくてはならないという調査結果まで出てきています。繰り返しますが、企業が本当にやりたいことは、ITの導入ではなく、業績の向上です。では、業績を向上させるにはどうしたらいいかを真っ先に考えるべきではないでしょうか。はじめのところで書いたように自律的に進化できない人工物は、人間が更新してやらなくてはならず、とりわけ対象が情報システムの場合、単にシステムだけを更新すればいいということにはならず、それを活用する仕組みそのものを更新しなければ業績向上にはつながらないというところが厄介なこと、と述べたように業績向上を目的とするなら単に情報システムの更新を考えるだけでなく、それの活用の仕組み自体も進化させていかなくてはならないと思います。
“International Institute of Business Analysis™( IIBA®)”が策定した“A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)”は、こうした背景から生まれたものと私は受けとめています。 ビジネスアナリシスについて語るとビジネスコンサルタントの領域の話題のように受けとめられることがよくありますが、ビジネスアナリシスの概念は、もともとITの専門家であるシステムアナリストやプロジェクトマネジャの仕事から出てきたとBABOK編集委員でリーダーの一人であるBarbara Carkenordは著書の中で述べています。BABOKをよく読んでみると使われている用語が、ソフトウエア工学や要求工学の書籍に出てくる用語に非常に近いのに気づきます。このことから、ソフトウエア工学や要求工学で開発された“要求開発技術”に関する知見をビジネス分析の分野に適用しているものと、私は解釈しています。事実、BABOKの非常に重要な概念である「Requirement：要求」を定義している文章ですが、BABOKでは、下記のように定義しています。 ・A condition or capability needed by a stakeholder to solve a problem or achieve an objective. ・問題解決や目標達成のためにステークホルダーが必要とする条件または能力 これとほとんど同じ文章が、Software Engineering Standards Committee of the IEEE Computer Societyという団体が出しているIEEE Guide for Developing System Requirements Specificationsという文書の中で下記のように定義しています。 ・A condition or capability needed by a user to solve a problem or achieve an objective. ・問題解決や目標達成のためにユーザが必要とする条件または能力 お分かりだと思いますが、BABOKでは、IEEEのソフトウエア工学標準化委員会の定義している要求の定義を、UserをStakeholderに変えただけでそのまま援用しています。 これに続く2番目の定義は、 ・A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents. ・契約、規格、仕様、規制などを満たすためにソリューションやソリューションコンポーネントが満たしていなければならない条件または能力 これに相当するIEEEの定義は、 ・A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. ・契約、規格、仕様、規制などを満たすためにシステムやシステムコンポーネントが満たしていなければならない条件または能力 面白いことにこちらは、SystemをSolutionに変えただけです。 つまり、どういうことかというと、ソフトウエア工学が対象としていた「ソフトウエアという領域」をBABOKでは、「ビジネスの成功という領域」にまで拡大して、要求工学の知見を活用しようとしているのです。ならば、ビジネス全体の成功に関しては、今まで経営学や戦略系コンサルタントなどの様々な知見があるではないか、といった疑問がわきます。そのとおりです。これまでの歴史の中で開発された様々な知見を活用することをBABOKでは否定していません。ただ重要なことは、BABOKは、要求工学の知識体系をベースにしているということです。真の要求を開発し、要求を管理し、要求をリポジトリーに保存して組織の知的資産として長期的に活用して組織をラーニングフルに保ち、ソリューションの実装にあたっては、要求を満たしているかどうか、ソリューションの設計前、導入後、展開・運用の段階に入った後までそれを監査していくというのがBABOKで定義されているビジネスアナリストの活動です。日本では、BABOKを超上流の知識体系として紹介されることが多いですが、超上流という表現は、私はBABOKにはふさわしくないと思っております。単に戦略の分析を行うだけではないのです。ITエンジニアの視点から見れば、自分たちの仕事の領域と思っていた範囲よりもずっと上流のことを扱うように見えるかもしれませんが、それはエンタープライズアナリシスという一部の知識エリアだけのことであり、重要なことは、要求を満たすソリューションを確実に実装し、それが期待した成果を上げているかどうかを評価するというところにあります。これを確実にすることで、従来、分断されがちだった経営者の視点とITの実装という流れをつなぐようにします。「経営とITのかけ橋」という言い方は様々なところでうたい文句として言われますが、上流はコンサルタントの仕事、RFPからあとはPMの仕事というように役割が分断されていては、どのような方法論を持ってこようとも「かけ橋」を渡すことはできません。BABOKは、役割を分断しないで、これを繋ごうとするものです。
では、ITエンジニアの視点から非常に遠い所にある（超上流）戦略的な視点、業務の問題課題の視点での分析をどのように行えばいいか。これに関する記述は、エンタープライズアナリシスという知識エリアで定義されていますが、現在の、BABOKバージョン2.0では、「ビジネス要求」を定義するという観点から細部にまで踏み込まず、抽象度の非常に高い表現で①ビジネスニーズを定義する、②能力ギャップをアセスメントする、③ソリューションアプローチを決定する、④ソリューションスコープを定義する、⑤ビジネスケースを定義する、という5つのタスクを定義するだけにとどめています。
現在のBABOK2.0の前のバージョンは、1.6で、そこには戦略計画の策定や戦略ゴールの設定などがエンタープライズアナリシスの序章に記述されています。 2.0では、ビジネスニーズを定義するとして、現状の組織が抱える問題課題の認識とそこから来る変革の必要性の認識がスタート地点になっています。これに対し、1.6では、戦略計画を策定し、ゴールを設定し、ビジネスアーキテクチャを定義して、戦略の実行可能性を評価し、と企業の戦略レベルの検討を行うことがスタート地点になっています。ビジネスアナリシスと名乗る以上、戦略計画の策定やビジネスアーキテクチャの策定、戦略の実行可能性の検討を入れるのは、不可欠のはずではないか、と私は思い、2.0がリリースされた時点でIIBAの本部のフォーラムでクレームを述べました。2.0は、1.6よりも後退しているということをフォーラムに書き込んだ記憶があります。それに対して、BABOK2.0の編集委員でリーダーの一人であるKevin Brennanからは、「現在、世界中で行われているプロジェクトのほとんどが、戦略レベルの分析ではなく、もっと下位の分析からスタートしている、また、ビジネスアーキテクチャは、ひとによって言っていることが異なっている、このような段階にあるものをガイドとして定義することはできない」という回答が返ってきました。 実際、2.0のガイドの「はじめに」のところには、2.0が目標にしていることとして、「個別のイニシアチブのコンテキストにおけるビジネスアナリシスのプラクティスである。戦略的ビジネスアナリシスまたはエンタープライズ規模のビジネスアナリシスについては、将来において適用範囲を拡張できるように分けた」という記述があります。どういうことかというと、戦略レベルの分析をすると広範囲にわたって経営課題、業務課題が認識され、それを解決するための経営改革、あるいは業務改革の柱となるようなものがいくつも提案されます。「営業改革」とか、「顧客対応力の改善」といったようなハイレベルの括りです。西洋人はこうしたものをイニシアチブと呼びます。このイニシアチブの中にプロジェクトが複数存在するのが一般的で、イニシアチブと言わずにプログラムと呼ぶ例もあります。私が受けとめている印象でいえば、よりITに近い人は、プログラムと呼び、より業務側、あるいは経営側に近い人はイニシアチブという言い方をしているのではないかと思っております。いずれにしても現在のBABOKのバージョン2.0は、個別のイニシアチブを実践することを目標にしており、企業全体、組織全体の戦略を掘り下げるところにはフォーカスしていないということです。ITプロジェクトという観点からみると確かに戦略レベルにまでさかのぼって分析する機会はそう多くはないし、そうした機会に出会う人も少ないのが現状なので、広く世界中から参照されるべきガイドを策定するという立場からすればいたしかたないかとも思います。 ビジネスアーキテクチャに関しては、エンタープライズアーキテクチャのモデルや手法としてZachmanフレームワークやTOGAFなどが日本でも紹介されていますが、これらの手法のどれを参照するのか？アプローチはどうするのか？そもそもビジネスアーキテクチャの成果物とはなにか？どのようにそれを活用するのか、など、世間にはさまざまな知見があるにもかかわらず、これらを整理した統一的な見解があるわけではないので、IIBAでこれをまとめろということになれば、それだけで一つの国際団体を立ち上げなければならないほどの大ごとになるだろうし、これもいたしかたないのかなと思います。 しかし、現場は待ったなしで動いており、先にも述べたように、現在の企業が抱えている最も困難な問題は、成熟社会とグルーバル化する社会の中で、ますます複雑化する経営環境の不確実性に対して、どのようにしたらPセンゲの提唱するような組織全体が変化する状況に対してラーニングフルに適応進化できる「最強組織」を実現できるかという差し迫った現実です。 IIBAがビジネスアーキテクチャや戦略計画策定のグローバルスタンダートをまとめきるまで待っているとしたら、その間に数多くの企業が業績の低迷、市場からの退出を迫られることになるでしょう。ことに現在の伝統的な日本の企業は深刻な状況にあります。我々現場のビジネスアナリストとしては、これらの問題に対処していかなければなりません。 私がここ数年経験してきた事例では、組織が大きくなればなるほど、部門の壁がコミュニケーションを阻み、FCバルセロナの例にあったように組織全体の成功のイメージをチーム全員で共有することができない。多くの歴史ある企業は長い年月の間に築き上げられてきた組織の構造の中で、構造が与える仕事に応えるだけで精一杯。これは現場だけでなく、経営陣も含めてそういった状態になっていると思います。構造そのものが現在の環境にフィットしているのかどうかをチーム全体で考えなおして、新しい認識を持ち未来を築いていくといった行動に出ることができている企業は非常に少ないのではないかと思います。 そこで、私は、組織全体の成功のイメージをチーム全員で共有するための方法論としてシステム思考・システムダイナミックスを現在、様々な企業にご提案しております。
３． システム思考による要求引き出し システム思考による要求の引き出しについてご説明しますが、最初に注意事項を述べておきます。システム思考も世間にあまたある様々な手法、知識体系と同じく、ある種のツールにすぎません。ツールが紹介されるとそれを導入すればすべてが解決できると早計に考えがちですが、そのように考えてはなりません。道具だけ導入するのは、“仏作って魂入れず”の轍を踏むことになります。「本当に肝心なことは何か」を常に見失わないように「地の頭」で考え続けて導入することが大切です。
システム思考・システムダイナミックスに関するコンサルタントのホームページで紹介する閑話に「システム思考とは何か」などといった、初歩的な説明を入れるのは釈迦に説法の感もありますが、先に述べたような現代の企業の問題を解決に導く上で、システム論的な思考法がいかに重要かを再認識していただく意味で、復習のつもりで書いてみます。 システム思考は、もともとシステム論という広範なテーマの研究課題の実践的アプローチとして考案されてきたものです。 そもそものシステム論の源流は、1900年代の半ばにまで辿ることができます。1948年、Norbert Wienerは「サイバネティクス(Cybernetics)」を発表し、“すべての目標達成行動は負のフィードバックを必要としている”として制御工学の基礎を築きました。また、1950年にはLudwing von Bertalanfyが「一般システム理論（General system theory）を発表し、システム境界の外部との情報、エネルギー、物質のやり取りのない「クローズド・システム」とシステム境界の外部と内部が常にやり取りしている「オープン・システム」という考えを述べ、システム論の基礎を築きました。 システム論の考え方とは、構成要素が互いに関連し合うことによって機能する、複雑な集合体。構成要素の性質が異なるものでも、その相互作用に注目して眺める時、それ全体がひとつのシステムとして認識されるというものです。システムの例としては、太陽系や水利系のような自然システム、生命体のような生物システム、機械やプラントのような人工物のシステム、哲学体系のような抽象システム、会社活動のような経営システム、地域自治体のような社会システムなどがあげられます。
システム研究の方法論としては、大きく、2つに分かれます。 ① 還元論：全体に対する構成要素を重視する考え方 構成要素を特定し理解し、そこから全体の解にたどり着こうとする考え。 ② システム論：構成要素に注目するだけでなく、構成要素同士の関係性のネットワー クが、「全体という新たな存在をいかに発生」させ、維持するかという 視点から、構成要素の関係性のネットワークに注目する考え。
1950年代半ばにMITスローンスクールの教授だったジェイ・フォレスターが、企業経営の問題に制御工学的な技術が適用できると考えて、システム論的な因果関係のある要素同士の相互作用を定量モデル化するシステムダイナミックスを考案しました。そのフォレスターの弟子だったピーター・Ｍ・センゲは、システムダイナミックスを厳密な定量モデルではなく、大まかなシステムの構造をとらえることのできる定性モデルとして活用すれば、もっと広範なビジネス世界の現象に適用できるのではないかと考えて、システム思考を考案し、定性モデルである因果関係図（Causal Loop）を考案しました。 因果関係図（Causal Loop）は、システムを構成する要素の因果関係を定義し、要素間に働く因果作用が巡り巡って元に戻ってくるフィードバックループの存在を見つけ出すというものです。こうしたフィードバックループの存在するシステムを定義し、それが時間の経過とともにどのように変化するかを考えるのがシステム思考です。時間とともにシステムは変化しますが、その変化の方向が作用元と作用先で同じ方向になる場合、青い色の矢印で因果関係を定義するか、矢印の先に＋の記号を付けて表現します。因果関係が逆の方向に作用する場合は、赤の矢印か、矢印の先に－の記号を付けて表現します。 こうした因果関係が、時間がたてばたつほどシステムの性質を強める働きを持つものを強調ループ（Reinforce Loop）と呼び、 で表現します。逆に時間とともにシステムの性質があるときは強化されるけどある時点を過ぎると元に戻り、弱められる性質をもつものを均衡ループ（Balanced Loop）と呼び、  で表現します。 あらゆるシステムは、強調ループか均衡ループの組み合わせで成り立っているとの前提に立ち、複雑なビジネスの世界を構成する要因がどのように関係しているかを考えます。 因果関係図（Causal Loop）は、適用可能範囲が非常に広く、生態系の変化、世界人口の動態や汚染の広がりなどモデル化の対象は、多岐に及びますが、ビジネスの現場においては、ビジネス活動を構成する要因としてのビジネスアクティビティとビジネス活動によって、得られる成果であるビジネス成果を定義し、さらに成果を生み出すには顧客価値を提供できなくてはなりませんが、これをカスタマーバリューと定義します。そして外部環境分析で抽出した外部の変化要因、この４つの要因の因果関係を定義することで、ビジネスのための因果関係図（Causal Loop）を作成することができます。 因果関係図（Causal Loop）作成に当たっては、単純な世界のものであればいきなり因果関係図（Causal Loop）を書き始めても構いませんが、複雑なビジネスの状況を分析する場合には、さまざまな工夫が必要となります。 先に述べたような構造的な問題を抱えている場合、外部環境の変化に目を向けることを妨げさせる固有のメンタルモデルを破壊しなくては、組織の進化を妨げる古い構造から抜け出すことはできません。そこで、5 Forces（注1）やSEPTEmber（注2）などのフレームワークを用いた外部環境分析とVario（注3）、SWOT（注4）などのフレームワークを用いた内部環境分析などで収集した情報によって新たな認識を得て古いメンタルモデルを破壊し、そこで収集した情報をもとに定性モデルの因果関係図（Causal Loop）をチームによる共同作業として作成し、ビジネスの成り立つ構造をチーム全体で共有化します。 ビジネスアクティビティは、組織がコントロールできる対象であり、ビジネス成果は、組織が顧客に提供するカスタマーバリューという価値の対価として市場から企業が得ることのできるものです。外部の変化要因は、組織のビジネスに重大な影響を及ぼす不確定な環境要因で組織がコントロールすることのできない検討対象、この基準で整理します。こうした基準でビジネスの因果関係図（Causal Loop）を作ると、ビジネスが成功するようにフィードバックループを回すには、どこに力を入れると全体がうまく回るかが見えてきます。この力を入れるべきビジネスアクティビティをビジネスドライバーと呼びます。この成功のためのビジネスドライバーをキックするにはどうしたらいいか、現在、欠けている能力はなにか、これを考えることでBABOKの要求を抽出することができます。一つのビジネスドライバーは、単独のステークホルダーでキックできる場合もあれば、複数のステークホルダーが協力してキックしなければならない場合もあります。こうした因果関係図（Causal Loop）を前にして、さまざまな立場のステークホルダーが、お互いの立場を超えて、ビジネス全体の構造がどうなっているかを議論しながら何をどうすればビジネスが成功できるのかを議論し、共有ビジョンを深めていきます。 簡単な製造業のビジネス成功のモデルを上に示します。
非常に簡単なモデルではありますが、ごく一般的な製造業の成功の仕組みを表現しています。製造業の成功要因であるQCDを顧客に提供できれば、営業もうまくいき、受注が増え、生産も増え、資材発注が増えてコストを削減することができるという強調ループがある一方、生産が増えると仕掛品が増えるので検査工程が大変になり、相対的に製品品質を下げる力が働き、営業にブレーキをかけるという均衡ループが内側にできます。この構造の中で、うまくビジネスを成功に導くためには、受注を増やし、生産能力を上げる一方で、「品質検査の徹底」を強化する必要があります。この力のバランスをうまく維持できれば製造業のビジネスはうまく回るのですが、さらに成功を加速するには、価格競争力を高め、納期回答の精度を上げるため、「製造と販売との連携」が重要なビジネスドライバーとなります。 この作業を助けるためのツールを私は、プロセス・ステークホルダーマトリックスと呼んで使っています。 業務領域で行われるべきアクティビティをプロセスと定義して縦にならべ、その作業をする組織にいるステークホルダーを横にならべ、その交わるマトリックスの中に要求を埋めていきます。アクティビティとステークホルダーが漏れなく拾い出せれば、そこに埋める要求の見落としは、大幅に改善できるでしょう。 ある業務領域に、どのようなアクティビティがあるのかを知るためにステークホルダーにインタビューするという手がありますが、インタビューというものは「くせ者」で、常に、言った、言わないの問題を孕みます。経験豊富なBAは、ステークホルダーの言うことを鵜呑みにしているだけではいけません。要求を漏れなく抽出できるよう、議論をリードできなければなりませんが、経験の少ないBAや、そもそも業務領域そのものが未経験の場合、何らかのガイドが必要となります。 世間には、SCOR（注5）やeTOM（注6）など、様々なプロセスのモデルがあるので、分析対象となる業務領域にあったものを選択すればいいと思います。私自身は、最近は、APQC(American Productivity & Quality Center)のProcess Classification Framework（注7）というものをガイドに使っています。 APQCでは、クロスインダストリーのプロセスモデルも用意していますが、最近では業界ごとのモデルも用意しているようなのでとても便利です。 ステークホルダーの拾い出しは、組織図などをもとに行ってください。 先ほどの簡単な製造業の成功モデルの例からプロセス・ステークホルダーマトリックスにステークホルダー要求を抽出した例が、表2です。
納期回答というカスタマーバリューを作るためのアクティビティが「納期回答の処理」ですが、「納期回答の処理」というアクティビティは、営業部、出荷物流管理、製品在庫管理、生産スケジューリングという多岐にわたるステークホルダーと関係しています。 優れたマネジメントシステムが導入できていない会社では、営業が客先で「大量発注したいが、納期はいつになるか」と聞かれてそれに答えられなくて、早速社に戻って調整しますと答え、会社に戻って在庫確認すると当然在庫は足りないから、すべての受注量にこたえきれない。生産部門に問い合わせても、生産部門では、特定の顧客にだけ製品を割り当てることなどできないという返事が返る。様々な押し問答をして埒が明かないと判断した営業は、営業部長に泣きついて、営業部長は、製造部長に怒鳴り込んで、製造部長はそんな無茶な話あるかと怒鳴り返す。あんなこんなを繰り返しているうちに顧客は正確な納期回答をした競合に発注し、販売機会を逃してしまう。こんな茶番劇が、起こっているのではないでしょうか。 これを組織横断的に要求開発できる企業は、壁の上に貼った因果関係図（Causal Loop）を部門横断的に集まったステークホルダー全員が見つめながら、さまざまに議論を交わし、営業部のステークホルダー要求として、「客先で商談中に携帯端末から納期問い合わせに対応できる」と定義します。納期問い合わせを受ける出荷物流部門のステークホルダー要求は、「営業からの納期問い合わせを仮顧客発注要求として受け付ける」と定義します。製品在庫管理部門では、「仮顧客発注要求を在庫に引き当て、スケジュール調整を行い、出荷予定日を回答できる」と定義します。しかし、在庫が足りない場合、すべての受注量を満たすことはできません。その場合、足りない受注量が生産スケジュール上のアイテムに引き当てられなくてはなりません。そこで生産スケジューリング部門では「在庫引当できなかった仮顧客発注要求アイテムを生産スケジュール上のアイテムに引き当てる」というステークホルダー要求を定義します。 このようにして、因果関係図（Causal Loop）の上のカスタマーバリューを最大化するために必要なビジネスドライバーに関係するステークホルダーを集めて壁に貼った因果関係図（Causal Loop）を見ながら議論することで、部門横断的にそれぞれの立場でのビジネスドライバーへのかかわりを認識し、各々のステークホルダー要求を定義していくことができます。まさにFCバルセロナのように「グランドの上の選手が、全体でひとつの生き物のように統合された意志を持ち、一糸乱れぬ早いパスワークを展開できる」姿に似ていると思いませんか？
プロセス・ステークホルダーマトリックスに要求を定義しただけでは、まだまだハイレベルな要求でしかありません。これを実装しなくては、本当の問題解決にはならないのです。ここから先は、ハイレベルのステークホルダー要求を詳細化し、機能要求、非機能要求に落としていきます。この作業は大変な作業で、特に分析対象となる業務領域が大きくなればなるほど要求の管理は、大変なものになります。小規模なプロジェクトではExcelでの管理でも大丈夫ですが、プロジェクトが大規模な場合、BABOKでは、要求の管理にソフトウエアのツールを使うことを勧めています。 しかし、要求管理ツール（トレーサビリティマトリックス）は、従来、ソフトウエア開発における要求の開発・管理をするツールとして発展してきました。そのため現在市販されている要求管理ツールは、そのほとんどが、ソフトウエア開発に特化して作成された要件定義などのフェーズから設計、コーディング、テストの工程を支援するものになっており、超上流におけるハイレベルの要求を詳細化していくプロセスを支援するものは、ほとんど見当たりません。
上流から使用できる要求管理ツール（トレーサビリティマトリックス）の活用： ハイレベルの要求を詳細化するプロセスでは、ロジックツリーを使って詳細化することをよくやります。マインドマップ（注8）などを使うと非常に便利なのですが、厄介なのは、マインドマップを使って要求を詳細化しても、それを管理するデータベースやExcelなどに再び手で入力しなければならないことです。そこで私は、ある人にお願いして、マインドマップと要求管理ツールのデータベースを一体化したツールを開発してもらいました。これを使うとこの悩みを解消することができます。図4は、プロセス・ステークホルダーマトリックスにあった出荷物流のステークホルダー要求である「営業からの納期問い合わせを仮顧客発注要求として受け付ける」を詳細化しているところです。ピンクの色が出荷物流のステークホルダー要求で、橙色が出荷物流の機能要求になります。青は、生産スケジューリングのステークホルダー要求で、このように要求のカテゴリーごとに色を分けておくと要求が増えたときに整理しやすくなります。図5は、図4のツールの画面を右にスクロールしたもので、出荷物流の機能要求がより詳細化されているのが分かります。 よく見ると図5の右端に「顧客出荷要求の優先度を策定できる業務ルールがある」という要求が 定義されています。この要求は、ソリューション要求ですが、機能要求でも非機能要求でもありません。
トレーサビリティの管理： また一般の要求管理ツールと同様に要求の前方トレーサビリティ、後方トレーサビリティ機能を使って、要求変更のインパクト分析を行うこともできなければなりません。
図7は、前方トレーサビリティの分析をしている画面ですが、「客先で商談中に携帯端末から納期問い合わせに対応できる」という営業のステークホルダー要求が、出荷物流の「営業からの納期問い合わせを仮顧客発注要求として受け付ける」につながり、さらに「仮顧客発注要求を在庫に引き当て、スケジュール調整を行い、出荷予定日を回答できる」につながり、さらにそこから出荷物流の機能要求と生産スケジューリングのステークホルダー要求に枝分かれしてつながっていることが分かります。こうしたトレーサビリティの分析を行うことで、ある要求に変更の必要性が生じた場合、その影響の及ぶ範囲がどれぐらいになるのかを見ることができ、その影響の大きさから変更に必要なコストや時間などを見積もって、変更の可否を意思決定することができます。これと同じ分析を下位の要求や成果物から上位の要求をたどる後方トレーサビリティの分析もできなくてはなりません。 こうしたツールの上で要求を開発していくことで、ハイレベルの要求から具体的なソリューションの詳細な要求に、さらには、その要求が割り当てられる機能モジュールや仕様書などの成果物にまで一貫した関連性を管理することができます。こうすることで、経営と現場とが一体となった人工物を作ることができます。さらに一旦開発した要求は、リポジトリーとしてDBに管理され、組織の知的資産として、その後のさまざまな変化に対応する施策で参照され、これをチームで保守することで変化に適応進化できる「最強組織」を実現できます。 戦略レベルで、システム思考の因果関係図（Causal Loop）を用いて、関係するステークホルダー全員が組織活動のあるべき姿について共通イメージを持ち、そこからプロセス・ステークホルダーマトリックスを使って、ハイレベルのステークホルダー要求に落とし、ハイレベルのステークホルダー要求を上流から使用できる要求管理ツール（トレーサビリティマトリックス）を使って詳細化して、ITに必要な機能要求、非機能要求、IT以外の業務で対応すべきソリューション要求に落としていくことで、情報システムの更新と、同時にそれを活用する組織の構造自体も更新する。開発された要求は、リポジトリー管理され、これを保守することで変化に対する適応進化が可能なラーニングフルな「最強組織」ができる、と理想的なことばかり書きましたが、道具はあくまで道具、これを活用する強い意志をもたなければ、宝の持ち腐れです。頑張りましょう、とは言っても人間は弱いもの、これを運用する仕組みを導入しなければ本物にはできません。欧米の先進企業では、こうした仕組みを組織的に導入するため、Business Analysis Center of Excellenceという専任の組織を立ち上げ、ちょうどプロジェクトマネジメントにおけるPMOのように活動しているようです。早く日本の企業もこうした動きをキャッチアップしなくてはならないと思います。
以上が、システム思考とビジネスアナリシス、BABOKの関係に関する私の私見です。今回、システム思考の因果関係図（Causal Loop）というモデリングツールを使って定性モデルを作り、それをもとに要求を抽出し、BABOKの知識体系に基づいて要求開発するプロセスのご紹介をしましたが、システム思考の元となっているシステムダイナミックスをつかった定量モデルを活用するとさらに面白いことがたくさん出来ます。しかし、今回は、紙面の関係で、そこまでご紹介することはできませんでした。システムダイナミックスとビジネスアナリシスとの面白い関係については、また別の機会に譲りたいと思います。
――――――――――――――――――――――――――――
ＳＤ閑話-寄稿-３ 了
 |
