自分で理論/ツールを作ることの大切さ

ビジネスの世界全般に言えることかも知れないが、変化と激しい競争の中で、解決策を学ぶことでは追いつかず、解決策を導く理論/ツールを自ら作ることが求められていると思う。
サービスデザインの本にも同じようなことが書かれていた時、ふと秋山真之を思い出した。

自分で立てた原理原則のみが応用がきく

司馬遼太郎が書いた「坂の上の雲」に、日露戦争の日本海海戦を勝利に導く作戦を建てた秋山真之の話がある。彼がアメリカの海軍戦略の大家であったアルフレッド・マハン大佐に会ったときのエピソードがある。

マハンは真之に、過去の戦史や軍事に関する論文を徹底的に調べ、戦いの原理を分析するようにと言った。
それから得た知識を分解し、自分で編成しなおし、自分で自分なりの原理原則をうちたてることです。自分でたてた原理原則のみが応用のきくものであり、他人から学んだだけではつまりません。

彼はこのアドバイス通り、日本の村上水軍の戦い方も研究し、日本海海戦にその知恵を活用した。
日本海海戦を完全勝利に導くという、難問を解くためにも自分で理論/ツールを作ることが役に立ったということだ。

ツールを作るツール「Spark Shadowing」

takramの渡邉康太郎氏の書かれた、This is service design thinkingの最後の章 「サービスデザイン時代に求められること」に自分で理論(サービスデザインにおけるツール)を作る方法が述べられている。

Spark Shadowingは、プロジェクトを完遂した後、そのプロセスを振り返る中で、「ブレークスルーはいつどこで生じたか?」をつぶさにトレースし、その瞬間生じた「アイデアの発火(Spark)」を再現可能な状態にする(Shadowing)試みである。

例えば、初期の社内ブレインストーミングセッションの段階で、メンバーの一人が発した顧客目線の「キーワード」をきっかけとして突然議論の方向性が定まった場面があるとする。
このような場面をプロジェクト後、注意深く振り返る。そして、それぞれのブレイクスルーはどのように生まれたのかをリバース・エンジニアリングするのだ。具体的に言うと、
・キーワードは何をきっかけに発せられたのか。
・同様のキーワードを発するためには、社内外でどのような条件を揃えるべきか。
・キーワードを発想するまでどのような思考を経たのか。
この「思考の定式化」を行うことで、発想手順を自ら再現可能な状態とするのである。

Spark Shadowingの詳細な説明は、隣の人の“アイデアの発火”をトレースする方法 – Spark Shadowing(前編)に書かれているので、是非読んでみて欲しい。
理論/ツールを作ることを数式で置き換えて表現しているところがクールでカッコイイ。

まとめ

サービスデザインにはカスタマージャーニー、ペルソナなど25個のツールがあるが、本にも書かれている通り、ツールボックスであり、マニュアルではない。
これらのツールも、必要に迫られて作られて来たことがわかるし、このツールを作るツールが、他のあらゆるツールよりも、最初に必要なツールだと思う。

Steel Wool Sparks on the Beach(credit: Photo Extremist

コメント

コメントを残す

メールアドレスが公開されることはありません。