<テーマ> 新たな価値観への経営視点の転換
<講 師> 匠BusinessPlace 代表取締役社長 萩本順三
2011年9月13日（火）16:00～19:00 / 於：市ヶ谷・アーク情報システム
第19回目となる研究会で講師を務めたのは、匠BusinessPlace代表取締役社長の萩本順三氏。萩本氏はオブジェクト指向技術にいち早く着目し、それを軸にしたITコンサルティングを展開する豆蔵の創設メンバーの一人。日本のソフト開発技術を引っ張ってきた人物の一人でもある。ナビゲータの田口潤氏は「経営とITが密接に関わる時代において、ITの構想や企画はどうあるべきか、ベンダー任せではなく、エンドユーザーへのヒアリングをまとめるだけでもない、新たなアプローチが必要だ。そうしたことを追求してきた萩本氏の講演をもとに全員で議論したい。そして新たな知見を得ていきたい。それが本研究会の目的だ」と前置きし、萩本氏の講演が始まった。萩本氏の講演内容は以下の通り。
簡単に私のプロフィールを説明する。経理マンとして社会人のスタートを切り、IT業界に入ったのは27歳のとき。そこでシステムの設計という分野に深く入り込み、方法論やソフトウェア工学について勉強した。オブジェクト指向技術を使った開発に携わっていくうちに、欧米発の方法論もそのままでは使えないことを理解し、使えるものを作ろうと考えた。その一つが「要求開発方法論」である。
現在、私は匠Lab（2008年7月設立）と匠BusinessPlace（09年7月設立）の代表取締役を務めている。両社のロゴには「匠」という漢字と「IT」という文字を組み合わせたものを使っている。ITという道具を使いこなす匠を育てる意味を込めた。匠BusinessPlaceは、IT企業を改革して新しいITビジネスを展開する人材を発掘する。それらの人材と共にユーザー企業にフェローや顧問として入り、企業改革や企業経営コンサルティングを実践していくというビジネスを展開している。
■製品開発にも応用できる要求開発方法論とは何か
まず「要求開発方法論」の基本的な考え方から説明する。要求開発4象限の図を見てほしい。これは要求開発の本質を理解してもらうためにつくった図だ。
これまでのITビジネス、あるいはIT企業ではお客様が要求していること、必要としていること、つまりニーズをきちんと捉えて、それを基に開発しなさいと言ってきた。その関係は、4象限図の下段（システム）を観ればわかる通り、システム要求がWhatでシステム開発がHowである。
しかしシステム要求は、業務オペレーション（やり方）があるから出されるもの。その関係は業務オペレーションがWhatで、システム要求がHowとなる。そして業務はビジネス戦略に則って行われる。つまり、業務オペレーションがHowでビジネス戦略がWhatとなる。このような関係を明示したのが、この4象限図である。
先述したように、IT企業ではお客さまのニーズを聞いてそれを取りまとめることから始まる。その場合、ユーザー部門の誰かから聞いたことを要求として捉えて、要件定義を進めていく。このとき業務フローも存在するが、多くはAsIs（現状）をまとめただけだったり、逆に絵に描いた餅でしかないToBe（あるべき姿）だったりする。戦略性がまったく感じられないことも多い。手作業をITに置き換える業務効率化や省力化ならそれでも何とかなる。
しかし今日の複雑な事業環境においてITの本当の価値を出すには、ビジネス戦略と業務オペレーションをきちんとデザインしなければならない。それを手助けしてバリューを出していこうというのが、私たち、匠BusinessPlaceの基本的な考え方であり、その方法論が要求開発である。つまり要求開発とは、戦略とオペレーションを決めた上で、そこにどうITを活用していくかを決めていくための考え方である。その目標はビジネス戦略と業務オペレーションをプロジェクト化することとも言える。
余談になるが、要求開発はITだけではなく、製品開発にも応用できる。製品開発においても、ビジネス戦略の策定者（オーナー）と製品戦略やプロモーション戦略を担当している会社や人、開発会社が違っていたりする場合がある。そういう状況下ではなかなかいい製品が生まれにくくなる。それを解決するには、ビジネス戦略を担うオーナー、製品戦略やプロモーションの担当者、製品の開発担当者が集まって、What（ビジネス戦略）にとって最も価値の高い「How」を見つけ出すことが必要だ。
つまり要求とは「すでにそこに存在するものではなく、開発するもの」である。
■ 「コタツの形成」で戦略的な価値を考える
オーナー、営業や企画担当者、開発担当者というそれぞれ立場の違う人たちが、一つの場で何をすべきかについて話し合いをする中で、だんだん考え方が接近していく。オーナーはあるべき論から現場を考慮した意見に変わり、開発担当者や営業、企画担当者は自分たちのやり方のままでは、問題があることに気づく。全体最適な形でまとめていこうとする。
このように壁を壊して合意形成の場を作ることで、正しい要求が開発できる。これを「コタツモデル」と呼んでいる。コタツモデルは戦略的視点と業務問題解決の視点、この2つの視点を持つ。戦略的視点とは自分たちの方向性、将来の価値を考えること。業務問題解決の視点とは、今抱えている問題をどう解決するか、つまり現在の価値を考えること。その2つの視点で考える習慣をつけるためにも、まずは「コタツの形成」が必要になる。
開発工程において、上流、中流、下流という言葉が使われるが、要求開発ではできるだけなるべく早い段階である上流でHowを手探りし、結果を予測することが求められる。企画段階から製品の価値や実現可能性を探り（Howの手探り）、企画段階から技術面からの製品価値の向上を即し（Howからの突き上げ）、技術的試行錯誤を早い段階で繰り返し、価値向上を図る（Howのチューニング）を行い、価値の高いものからプロジェクトに採用していこうということである。
Howばかりに関心があるように見えるが、そうではない。Howを業務的に説明できるか、戦略的に説明できるかということを行ったり来たりしながらデザインしていくことで、最も価値の高い要求が生まれてくる。これは究極のビジネスリスクマネジメントにもなり、プロジェクトマネジメントとして目指すべき姿である。
匠Thinkとは、要求開発の中で創り出された重要な言葉を通して教育を行う体系である。そこで重視しているのは、「戦略と実現の線上にしか価値は存在しない」「制御可能で制御価値の高いものから手をつけること」の2点である。
「戦略と実現の線上にしか価値は存在しない」とはどういうことか。戦略に価値があると思っているのは妄想でしかない。戦略と実現方法がセットとなり、その線上に価値が生まれる。だから手探りして最も価値が高い戦略と、それを実現する方法の組み合わせを考えていく。こういったことを当社ではIT企業とユーザー企業にも実感してもらえるよう、一緒に取り組んでいる。
私が最初に作った方法論は「オブジェクト方法論Drop」である。この方法論では構造と機能モデルを作ることはできたが、業務モデルを作るところまでは整理できなかった。そこでビジネスのアイデアをITにつなげるため、業務と戦略という領域の見える化に着手した。それが要求開発方法論である。
これにより戦略の実現性に対する覚悟を持ち、戦略に合意してプロジェクトを進めていけるようになった。しかしそうなると、それを実現して得られる価値は何かということを考えるようになった。例えばすばらしいビジネスのアイデアをもっている人がいる。そういう人のアイデアの実現性をもたせるには、価値の領域をどう実感させるかというテクニックが必要になる。そこで作ったのが匠メソッド方法論である。価値の領域で必要になるのは描く力、無から価値をデザインしていく力である。形がはっきりしないものをエンジニアリングしていくことに恐れを感じるだろうが、要求や戦略は価値を描かない限り、いいものはできない。
■提携的な業務処理でも戦略的な視点から価値を考えられるのか
ここで講演の前半が終了。ここまでの萩本氏の話について、以下のような質疑応答がなされた。
田口氏 例えば会計システムや人事システムなどの定型的な業務を処理するシステムの場合でも、先の4象限図に当てはめることができるのか。システムの属性によって当てはまる、当てはまらないがあるのか。
萩本氏 確かに当てはまりやすい、当てはまりにくいということはある。しかし会計処理に携わっているのはしょせん人。つまり私たちの最終目的はシステム開発をすることではなく、人間系のシステムを作ること。人事システムであれば、人事の価値とは何かについて改めて考えてもらうことができる。そういった意味では当てはまると考えている。
田口氏 会計でも月次決算で数字をまとめるためのシステムだったら、価値はいらないけど、リアルタイムで会計処理をして経営陣にその日の売上および利益を見えるようにし、次の手を打てるようなシステムにするというのであれば価値まで考えることが必要になると？
萩本氏 価値まで考えるという意識を持つことによって、人は仕事の生き甲斐ややりがいを感じることができる。今、やっている仕事はどういう価値があるのか、一度、考えてもらうと、慣習的な業務であるかどうかがわかる。これは開発業務も同じ。開発ドキュメントが慣習化し、価値がないこともある。自分たちが携わっている開発業務の価値はなんだろう、考えることによって、ドキュメントの洗練につながる。
山田氏 経理担当者においても、自分たちの業務が戦略と関連あるという意識を持てと言うことなのか。
萩本氏 社員1人ひとりが戦略的な思考を持てるようになると企業力が上がる。
田口氏 そういう教育がなされていないし、そういうビジネス習慣もない。要求開発の方法論で、そういう体制を改革していこうということなのか。
萩本氏 その通りだ。例えばIT企業は元請けのベンダーから仕事をもらっているから、お客さんの業務を見える化することはできないという。しかし、それは今の価値でしかない。今の価値のままビジネスを慣習化すると、将来のビジネスは破綻する。今から将来の価値を描き、自分たちがどうやってそれに近づいていくか、その力が問われている。だから戦術のコタツモデルが重要になる。とはいえ、多くの人は問題解決の視点にとらわれてしまいがちになる。戦略的視点と業務問題解決の視点の2つをいかに身につけるか、ここは大きな問題だ。
池邊氏 戦略と一口に言っても、会計戦略そのものを作っていくイノベーション的なものもあれば、すでに方針がありそれを実現してくための戦略もある。戦略的視点とはイノベーション的な戦略を指しているのか。
萩本氏 会計に対する専門的な戦略をターゲットにしてもいいし、そうではないものもある。いずれのみということではない。
谷口氏 要求開発4象限の図で、HowとWhatだけに絞っているのは意味があるのか。
萩本氏 意味がある。一般的にはWhatやWhyというところで物事を決め、Howがどうやるかを決めるという流れをたどる。しかし私はWhatとHowがつながったときに価値が出ると考えている。WhyやWhoを出さなかった理由の一つは、複雑になるのを防ぐためと言うこともあるが、それらは別の次元で考えていくことである。
■価値とは、課題とは
ここから萩本氏によるレクチャの後半に入る。
先ほどから頻出している言葉、「価値」とは何なのか。例えば私たちのビジネスの例で言うと、私たちの会社匠ビジネスプレイスをはじめ、お客様、IT企業、ビジネスを展開している企業、エンドユーザーなど、それぞれのところに価値が存在しており、それぞれのステークホルダーが価値を実感している。ビジネスモデルはこれらの価値のバランスである。
例えばIT企業であれば、ユーザー企業の価値を意識しながら、自分たちのビジネス戦略にも有効でかつ儲けられるバランスの良い仕組みを考える。そのようなすべてのステークホルダーが価値を共感できるような仕組みを作る手法が、匠ビジネスエクスペリエンスである。さらに現在、ビジネス企画をする際に、価値のバランスがうまく取れているかシミュレーションできる手法の作成に着手している。
とはいえ、各ステークホルダーが抱いている価値観はさまざまである。ではどうすればその様々な価値観をイメージできるようになるのか。例えば「現状のクルマは問題だ」という悩みがあったとする。この悩みを解決するには「クルマを修理する」という課題を挙げることができる。
とはいえ、この課題を達成したところで、不満足だったものを元の状態に戻しただけなので、満足度レベルは上がらない。しかし更に発展させ、「高性能な車」や「頑丈なクルマ」「低燃費なクルマ」「クルマなしの生活」という課題を達成すればどうなるか。「楽しさ第一」という価値観をもっている人であれば、「高性能なクルマ」になると満足度も向上するだろう。
「環境にやさしい」という価値観の人であれば、「低燃費のクルマ」はうれしいはずだ。つまり価値観によって、問題・課題も変わる。組織における価値観は経営ビジョン、経営・業務戦略、社員の思いなどによって形成される。価値につなげるためにも、問題に気づく組織にすることが大切だ。
■今のままでは5年後、IT企業は生き残れない
すこし前までは数億円以上の中・大規模な案件が多かった。しかし経済環境の変化や技術革新、例えばPCの低価格化、モバイル環境、クラウド環境の登場などにより、案件は小型化し、しかし一方で相互に連携している。だからコーディネートの必要性が生じる。このときITの観点ではなく、ビジネスの観点でコーディネートしないといけない。
それに合わせ、IT企業は従来のピラミッド型・集中管理の組織から、変化対応型・自立分散組織へと変化していかねばならない。その小さな分散組織それぞれが、マネジメント機能やリーダー機能、メンバー機能持つ。そういう組織になるには、社員1人ひとりが自ら考え、勇気を持って行動することが求められる。いわゆる現場力だが、その現場力を戦略につなげる方法論を持たないと、疲弊するだけだ。
日本企業は一般に現場力が強いが、戦略につながらないのが弱点となっている。その弱点を克服し、戦略につなげるノウハウを身につければ再生できる。
例を挙げよう。私たちのお客様である某ユーザ企業では要求開発とアジャイル開発を組み合わせた方法で、当社のメンバーとともに、システム開発に取り組んでいる。ビジネス価値を検証し、早くリリースした方が価値のあるシステムをアジャイル(Agile)に作っていく。そのメソッドとして用意しているのがビジネスアジャイル手法だが、手法としてはまだまだ未熟。それをどんどん改訂して使えるようにしたいと考えている。
とはいえ、現在のITのプロジェクトは4象限図で展開されており、キャリアパスもそれを基に構築されている。しかし今後、IT開発は、ビジネス企画とIT開発を並行に進めるような仕組みになると考えている。だからこそ、先述したように1人ひとりが自ら考え、勇気をもって行動することが求められる。
勇気を持つには、まずは学ぶこと。そして行動すること。そうすると自信がつく。さらに学ぶと、夢（将来ビジョン）とそれを追求する覚悟ができる。そして会社を担う自信が生まれ、やがて社会や業界を担う自信と思いへといたる。「才能とはでっかい志と、情熱の持続と努力により形成される」わけだ。
私が方法論の開発などに取り組むようになった背景には、オブジェクト指向を学んでいくうちに出合ったフェルデナン・ド・ソシュール（記号論の基礎を固め、構造主義思想に影響を与えたスイスの言語学者）の学問による。彼の学問は認知の領域。オブジェクト指向もモノをどう認知するかという技術である。そこで私はオブジェクト指向の言葉を、機能レイア、メカニズムレイア、コンセプトレイア、目的レイアに分類していった。こういう視点（思考の秩序棚）を設定してまとめると、分かりやすい。これは1997年に発行した「最新オブジェクト指向応用実践」で「思考の秩序棚」紹介をした。
最近、それに「理念レイア」をプラスした。現在、次のような秩序棚を設けて視点を切り替え、物事を考えるように習慣づけている。参考にしてほしい。
●理念レイア・・その目的と自己の理念との関係
●価値レイア・・その目的の価値は
●目的レイア・・そのコンセプトの主たる目的は
●コンセプトレイア・・そのメカニズムはどのようなコンセプトで作られているか
●メカニズムレイア・・事実・用語間のメカニズム
●クラスレイア・・具体的な事実・用語
■講演後は質疑応答
質問 4象限図の中に業務オペレーションかかれてあったが、業務オペレーションはシステム要求との兼ね合いで決まってくるものではないのか。
萩本氏 そういう場合もあるが、ここでいう業務オペレーションとは、業務モデルのこと。しかし業務モデルと書くとユーザー企業にはうまく伝わらない。業務を進めるやり方ということを説明するために、あえて業務オペレーションという言葉を使っている。
山田氏 IT企業は上流に行かないと生き残れないということか。
萩本氏 そう思う。少し遠回りになるが説明しよう。開発現場で「アジャイル開発は上のものがわからないから使えない」という話を聞くことがある。しかしそれはアジャイル開発の有効性とビジネス戦略とのつなぎをうまく説明できていないから。お客さまのやりたいことはあいまいなことがほとんど。そのあいまいな要望をベンダーが自分なりに解釈して開発を進めてしまう。ビジネスからITが離れてしまう。
一方、欧米の場合、日本のような間に入るベンダーいない。ユーザー企業の中にアーキテクトがいるため、ビジネスとITは非常に近い関係にある。そういう環境の中でアジャイル開発するのと、日本のようにユーザー企業とは異なるベンダーがアジャイルしている環境は根本的に違う。Howの手探りをして本当に会社の中でどう使うかを考えるには、ビジネス領域まで踏み込むことが求められる。
田口氏 上流の提案でお金を取れるのは一部のコンサルファームに限られるのでは？必然性は分かるが、現実問題としてできるのか。
萩本氏 現実にできるかどうかはさておき、これまでのように専門用語の提案に流され、不良財産を作ってしまい、このままではいけないと考えているユーザー企業は多い。そういったユーザー企業、またこのままではいけないと感じているIT企業と一緒に、要求開発にチャレンジしているところだ。
片貝氏 ITに携わる人たちは業務の現場を知らない。ビジネスとは何かを知らないでシステムを作っている。私は1週間でもいいから業務の現場を経験してみることが大事なのではと考えている。そうすれば目的意識をもって作れるんじゃないかと思う。
萩本氏 そういう経験も大切だと思う。ITは目に見えるものではない。ITエンジニアは見えないものを見える化するテクニックをもっている。それをビジネスに応用すればいい。しかし多くのITエンジニアは、「業務知識がないからわからない」という先入観があるため、応用することを考えない。私たちはなるべく若手のエンジニアをコンサルティングの現場に同行させ、自分たちのテクニックが応用できるという感覚を持ってもらうようにしている。
池邊氏 IT部門の人が戦略的視点で語ろうとしても、お客さまの企業、製品の背景、例えば競合会社がどんなものを出してくる、将来の技術革新がどうなっていくか……などいろいろ把握できないので難しいのではないか。どこまでのステークホルダーを考えて、提案するのか。
萩本氏 そのあたりのことはお客様が知っている。それを見える化するのが私たちの役割。見える化をすべてできるわけではないが、お客様が選択と集中するために必要な見える化の方法を共に考え、支援していく。
谷口氏 ビジネス戦略を検討するときのコタツモデルのメンバーは、経営トップやCIOなども入るのか。
萩本氏 小さな企業であればトップが入ることも多い。コタツモデルでのミーティングは毎週など、開催頻度が高いので、経営トップは報告会のときに入り、アドバイスをしてもらうことが多い。コタツモデルの概念は戦略的な視点で見える化したモノをトップに承認してもらうことである。
谷口氏 価値はどんとん変わっていく。トップの話を聞かないとその企業が狙うビジネス戦略とが見えないと思う。そのあたりはどうするのか。
萩本氏 価値をシミュレーションする。エンドユーザーが企業の中管理部門の人だったり、経営者だったりする製品があったりすると、現在の価値と将来の価値をデザインする。現在の経営トップがこの製品を使ってうれしい価値は何か。さらに、本来はどういう価値を求めているのか、もう一歩踏み込む。つまりお客さまの視点で価値をデザインすること。このときに重要なのは、自分たちが持っているシーズをどう価値転換できるかである。
田口氏 今のITの仕事の進め方は、数十年かけて構築されてきたもの。萩本氏の試みは、それを大きく変えようというものだと思う。だがイナーシャ(慣性)は大きくて、なかなか変えられないのでは。
萩本氏 技術が変わっているように、IT業界も自然と変わると思う。そうでなければIT企業やITエンジニアの価値はなくなり、3Kがどんどん進行してしまう。
桐山氏 当社もいろんな危機感を持っており、萩本氏の話に感銘を受け、方法論の勉強会を開催している。会社の目指している方向性もわかり、参加したメンバーの意識は変わりつつある。
萩本氏 要求開発などの方法論を根付かせ、意識を変えるには、3年ぐらいかかる。また技術、人、心の3つがバランスよく強くならないとこの活動はうまくいかない。
石田氏 私はネット通販のコンサルをやっている。ネットの広告、Webの制作会社も同じ状態になっている。今日の話を参考にしたい。
質疑応答がいつも以上に活発に行われた今回の講演。最後に田口ナビゲータは「またぜひ、萩本氏、あるいは氏とともに仕事をしている企業に来てもらってディスカッションしたい」と語り、会を締めた。
レポート；中村仁美
