【戦略ノート238】概念的に考える

本ブログは移転しました。こちらをご覧ください

◆なぜ、日本人は画期的なアプリケーションが作れないのか

先日、「日経コンピュータ」の前編集長である谷島宣之さんと、弊社のPMstyleプラチナ会員向け会報用の対談をしたときに、モノづくりでは現物があるのでうまくいったが、ソフトウエアでは目に見える現物がないのでダメだという話になった。

今回はこの問題を議論してみたい。

ものづくりはモノから入る。つまり、現物という具体的な姿から入り、そこでいろいろとモノをいじくり回しながらアイデアを出していく。そこでのアイデアの創出はすばらしく、それが日本企業の躍進を生み出した。これがうまくいったという意味だ。

しかし、ソフトウエアの場合、目に見える現物がない。そこで、ものを概念的に捉え、概念的なレベルで設計をし、アイデアを埋め込んでいく必要がある。

マッキンゼー出身のコンサルタントで、ＳＡＰやクインタイルズ・トランスナショナル、ルイ・ヴィトンなどの日本法人の代表を務め、現在は電気自動車用充電インフラ提供をするベタープレイスの日本法人代表を務める藤井清孝さんが、「グローバルイノベーション」（朝日新聞出版、2010）という本で、興味深い指摘をしている。ちょっと長くなるが、紹介しよう。

=====
私は、ＳＡＰという基幹業務向けのソフトウェア企業の日本法人社長を６年近く務めたおかげで、ソフトウェアの開発力強化に必要なものを身をもって体験した。ソフトウェア開発で一番大切な能力は「概念設計」である。まず、いろいろなシナリオをシミュレートしながら、論理的に詰めていく力である。
（中略）
日本人には「現場にすべての答えがある」と信奉している人が多いと感じるが、これは現場を積み重ねて結論を出す「演繹(えんえき)的な思考」教育の結果だと感じる。これに対してソフトウェアの開発には、トップダウンで概念設計から入っていく「帰納的な思考」が必要であり、これは日本の教育が得意としてきた分野ではない。このようにソフトウェアの開発では、「トップダウンの概念設計」「目に見える現場が存在しない」「試行錯誤が必要」といった特徴があり、従来の日本のメーカーが得意とする分野での経験が活かしにくいのである。
=====

まさにそのとおりだと思う。概念思考スキルを身につけない限り、ソフトウエアビジネスで日本が成功できるとは思えない。

しかし、現実には、ソフトウエア開発は国を挙げて見える化の方向に向かっている。これはこれだ重要な取り組みだと思うし、否定するものではないが、結局、概念的な思考ができるようにならない限り、競争力のあるソフトウエアはできないと思うし、プロジェクトマネジメントをうまく行い、ビジネスで勝つことも難しいのではないかと思う。

◆プロジェクトマネジメントにおける概念的思考

プロジェクトマネジメントに関していえば、プロジェクトの目的設定における概念的思考スキルの欠如がもっとも気にかかるところである。例えば、情報システムの構築プロジェクトにおいて、

本プロジェクトは○○プロジェクトの構築を目的とする

という目的設定をしているケースが目につく。「これでは面白くない」と言われると、今度は現場でできることを考える。技術確立、人材育成、継続的取引といったことを目的に加える。どこまでいっても演繹的である。

そうではなくトップダウンで考えることが必要だ。一例を挙げると顧客とベンダーの間でよく使われる概念にＷｉｎ－Ｗｉｎという概念がある。この概念を使うと、このプロジェクトで顧客と自社の共通の価値になるものを探すことになる。例えば、顧客にすばらしいシステムを提供する。それが評判になり、顧客はビジネスにプラスになる。自社はその評判で別の企業から引き合いがあることだ。

これをプロジェクトの目的にすることによって、顧客も自社も共通の目的ができ、プロジェクトにコミットする理由ができる。

持てる視座にもよるが、こういう発想を演繹的に行うことはかなり難しい。概念的に考えることによって初めて実現できると言ってもよい。ここで注意しておく必要があるのは、プロジェクトにしろ、システムにしろ、本当の意味での評価は概念的なレベルでしかできないということだ。

藤井さんがいう概念設計の重要性というのはそういうことだ。ソフトウエアであれば、投資のレバレッジを設計するのが概念設計である。プロジェクトであれば、プロジェクト定義である。ここをよく認識しておく必要がある。

◆概念とフレームワーク

概念的にものを考える場合に、注意しておかなくてはならないのがフレームワークの存在である。本来、フレームワークは概念という見えないものを見える化するために作られたものである。

上で例示したＷｉｎ－Ｗｉｎなどもフレームワーク化されていることがあるが、フレームワークそのものは概念ではない。概念的な思考をするための道具に過ぎない。

ところが、フレームワークを使うこと自体を目的化する傾向がある。これも演繹的思考の一種だと思われることを認識しておく必要がある。

◆概念的なレベルでの問題解決

概念的思考という意味で、興味深いのが問題解決である。問題解決はボトムアップに概念的な思考をしている。トヨタの思考法として有名なＷＹＨを５回繰り返し、本当の問題を見つけ、その問題を解決するという方法である。

例えば、リソース配置の問題でプロジェクトのスケジュールが遅れたとする。まず、現物的にプロジェクトのスケジュール遅れという問題が発覚する。そこから、

　なぜ、スケジュールが遅れたか
　　　←○○タスクのスケジュールが遅れている
　　　　←○○タスクの担当が変わった
　　　　　←○○タスクの本来の担当が別のプロジェクトから離れなれない
　　　　　　←全体をみたリソース調整が行われていない

という展開ができる。そこで、全体をみたリソース調整ができないという問題を解決していく。

問題解決のうまくできていない人は、２層目の問題に対して、○○タスクに他のタスクの担当を回すとか、３層目の問題に対して担当者を変えるといった解決策を取っている。その問題についてはそれで解決するかもしれないが、実がその問題は再発する可能性が高くなる。トヨタのＷＨＹを５回繰り返すという手法の狙いは再発を防ぐことにある。

つまり、問題解決においては、概念的思考によってより根本的な問題に近づけ、それを解決することによって再発しにくくなるというメリットがあるのだ。