2016/07/19

越境社内DNSでAkamai化が逆効果になる事象を発見した

まさかこんな影響があるとは思わなかった…

サンフランシスコにある私のオフィスから、San Francisco Chronicleという新聞社のWebサイトへのtraceroute結果


ある日のこと、オフィスで仕事をしていて「どうもWebサイトが開くの遅いよな、ウチのオフィス…」とボンヤリ考えていました。

遅いけれども、別に開かないわけじゃない。ちゃんとWebサイトは表示される。でも、画像がちょっとずつ表示されたり(スパっ、と出るのではなく、がっががっ、と出る、と言えば伝わりますでしょうか)、リンクをクリックしてから一瞬、時間にして1.5秒くらいブラウザが考え込んでから次のページのロードが始まったり、といった具合です。

最初は「Wi-Fiが混雑してるんだろうな、どうせ」と思っていましたが、有線LANにしても同じく遅い。これは何かがおかしいぞ、ということで調べてみることにしました。


まずはPingとTracerouteだよね


ネットワークエンジニアとしては、PingとTraceroute。最近はPingに応答しないWebサーバーも増えてきているので、インターネット上のHTTPを調べる時はいきなりTracerouteで途中の経路まで調べるのが私の中で常態化しています。

とりあえず遅いと感じたのが、私の地元にある地方紙新聞のSan Francisco Chronicle。さすがに地方紙だから地元にあるだろう、と思ってTracerouteしてみたら…。


その結果が、冒頭にも掲出したコチラ。

私のオフィスからwww.sfchronicle.comにtracerouteした結果(再掲)

異常が出ていること、お分かりでしょうか?

11ホップ目で、なんと日本のkddi.ne.jpを通っていて、その直前と直後で100ミリ秒(=0.1秒)のレイテンシ差が出ています。

そして最終到達点はAkamai。最初はなんでこんなことになるのか分からなかったのですが、この画像をFacebookにシェアしたところ、友人の一人から「AkamaiのDNSが日本のサーバーのIPを返している、ということだ」とのご指摘。

このご指摘でピンと来ました。これ、原因はウチの社内DNSです。


どういうことか、というと…


セキュリティ的に詳しく書けないので相当模式化していますが、ざっくり絵にするとウチのネットワーク構成はこんな感じです。

今回のケースを説明するための模式図

まず右下が私のオフィスがあるネットワーク。社内ではWindows中心で、Active Directoryによるドメイン管理を行っています。

一方で私のオフィスはまだ規模が小さいため、ドメインコントローラーは日本にあるものを使っています(図の左下)。そして日米間はIPSec VPNで常時結ばれていて、100~300ミリ秒くらいのレイテンシはあるものの安定して日米間接続は稼働しています(図の中央下)。

Windowsドメインでの運用のためには、クライアントPCにDHCPで配布するDNSサーバーはドメコンにする必要があります。このため、すべてのDNS名前解決クエリは日米間VPNを通って日本から解決されます。

これを示しているのが以下の図。

クライアントPCからHTTPアクセスする際のDNS名前解決の模式図

名前解決で普通にアメリカのIPアドレスが帰ってくれば、HTTPリクエストは日米間VPNを通らず、普通に米国側のインターネットアクセスラインから出ていきます。実際、Google関連サービスなんかは(おそらく)その経路。

※GoogleへのTracerouteは経路上のホスト名が出てこず、すべてIPアドレスなので推測しかできないのですが、レイテンシが100ミリ秒以下とあまり大きくないことからまず間違いないです。


一方で、わざわざTracerouteが日本へ抜けているということは、DNS名前解決クエリで戻ってきたIPアドレス(つまりHTTPリクエストを送る先)のサーバーが日本にあるということ。


ここは推測ですが、Akamai化されているWebサーバーのDNSエントリはCNAMEで定義されていて、実態はAkamaiのキャッシュサーバー群に向いている。そしてAkamaiのゾーンオーソリティは、DNSクエリの発信元IPアドレスを元に、そのクエリ発信元にネットワーク的に最も近いキャッシュサーバーのIPアドレスを返しているのではないかというのが私の仮説です。


実際、Akamai社は全世界に20万台を超えるキャッシュサーバーを持っており、そのどれにクライアントからアクセスさせるかがAkamaiの技術のキモであるはず。そのくらいのことはやっていてもおかしくありません。


つまり、Akamai化されているWebサイトへのアクセスは、現状だと全て日本のキャッシュサーバーにデータを取りに行ってしまう。せっかくSan Francisco ChronicleやAppleが見る人にAkamaiで高速化を提供してくれているのに、こちら側のLAN構成によりそれが逆効果になってしまっている、という現象です。


Akamaiの仕様にツベコベいってもしょうがないし、そもそもわざわざ日本のDNSを見に行っているこっちの構成の方がイレギュラーなので、これはまぁ仕方ない。


とはいえWindowsドメインを運用するためには、少なくとも動的DNSを米国側に立てる必要がある。BINDとかで立てても良いが、どうせならドメコンを立てた方が耐障害性も高くなるので好ましい。


解決策は、と言うと…


要するに、こういう構成にする必要があるってこと。

ドメコンを米国側に立てた構成

そしてDNSクエリを模式化した絵がこちら。

米国のドメコンを通じた名前解決の流れ


米国にあるドメコンからAkamaiに対する名前解決クエリが飛ぶので、Akamai DNSが返してくるDNSの期待値は米国にあるAkamaiサーバーのIP。それが返ってくれば、HTTPリクエストもわざわざ日米間トンネルを通ることなく、直接インターネットに出ていくはず。


ドメコン立てるのもカンタンではないので、まだこの構成は試せていませんが、追って対策後についてもブログ記事にまとめてみようと思います。


しかしまぁ、なんというか。


インターネットもずいぶんと複雑化したものですね。AkamaiのようなCDNやらWAPやらIDSやら、セキュリティを高めたり利便性を高めたりするために色々なレイヤーが重なり合って、インターネットが持つ「シンプルさ」はとうの昔に捨て去られた、ということを改めて実感した次第です。


…とはいえ、ドメコンをわざわざ太平洋越しに見に行くようにした私の設計もちょっとどうかとは思いますけどね…。だって運用する時間もなければドメコン立てるような規模でもないんだもん…。







2016/07/10

経営論連載Vol.3 - Coinの失敗事例に学ぶ、ビジネス論文の使い方

わりとセオリー通りに見えるんだけれど


クレジットカード、デビットカード、ポイントカードなど複数のカードを1枚にまとめられる製品として
大きな話題を集めたCoin。
出典:Coin社Webサイト Press kit より

2013年11月、ある起業家がCoinというクラウドファンディングプロジェクトを立ち上げました。Yコンビネーター(シリコンバレーでは有名な、最近は日本でも有名なベンチャーキャピタル兼インキュベーション組織)を含む多数の投資家から資金を集め、かつクラウドファンディングプロジェクトでは350,000オーダー、1700万ドル (日本円で約20億円!)もの資金を集めたとされています(出典:recodeの記事内で350,000オーダーが集められたと語られており、当時プレオーダーは1件$50だった)。


しかしながら、現在同社はフィットネストラッカーのFitbit社に買収され、かつ現行製品であるCoin 2.0は売り切れ。さらに後継製品の開発は行わないと明言されているため、これは明確に「失敗」です。


アイデア、プロトタイプ、テスト、製品化。

豊富な資金、成功請負インキュベーター。


経営論連載の最終回は、典型的なシリコンバレーの成功要件を備えているように見えるこのCoinプロジェクトの失敗例を紐解きつつ、デザイン思考のような「ビジネス的な考え方」「方法論」の使い方に踏み込んでみようと思います。

他の連載は以下からどうぞ。

なお本稿の執筆にあたり、サンフランシスコと東京を拠点とするブランド&マーケティングエージェンシー Btrax のCEO、Brandon Hill氏のブログから着想を得ました。ここにお礼申し上げます。


Coin社が失敗した理由


同社の失敗理由は様々語られていますが(前述のBrandonのブログが分かりやすいです)、私は「品質の低さ」が最大の要因だったと思います。

本稿の執筆にあたって英語のCoinレビューを数件読みました。いずれも、クレジットカード端末がCoinを認識せず、それで支払えなかった体験を深刻な問題として指摘しています。

Coinは、クレジットカードなどにあるいわゆる磁気ストライプの情報をスマートフォンで読み取り、Coin本体に登録。ユーザーがどのカードを選ぶかによって、Coin自身の磁気ストライプの情報を書き換えます。

この磁気ストライプ書き換えが、どうやら安定しなかった模様。カードを読み取っても認識しないケースが多数報告されていました。


でも、ちょっと待ってください。シリコンバレー的には「クイックに失敗し、すぐに学んで作り直す」ことが良しとされています。
まず作ってみる。デザイン思考の中でもそれが説かれています。


デザイン思考の5つのプロセス


ではなぜ、Coinの失敗は成功の母になれなかったのでしょうか?



失敗することに失敗した


これは私の推論ですが、端的に言うと「Coinは失敗することに失敗した」のだと思います。
後戻りできないところまで言ってからの失敗は、クイックな失敗とは言えません。

Recodeの記事に、Coin社CEOであるKanishk Parashar氏への電話インタビューがありましたので引用します。和訳は私によるものです。

“A big part of doing mass production is stabilizing each unit so it performs as well as we want. When you build tens of thousands, you get some variability,” he said. “With us, you’re holding the thinnest wearable ever made so it kind of tests limits of those tolerances. Over time, as we figure things out, we’ll make that variability smaller and smaller.”

「ひとつひとつの製品を望むとおりに稼働させるべく、製品を安定させることが量産段階における大きな課題でした。何万個も製造すれば、多少のバラツキは出てきてしまいます。我々の製品はかつてないほど薄く作られているためちょっとしたことでもうまく動作しません。こうしたことが分かってくるにつれて、バラツキをどんどん小さくしていけると思っています」

He said the company was making hardware updates at least every two months, which means customers who received their card first may have a card that doesn’t work quite as well as those in the back of the line. The company is producing about 10,000 cards a week.

彼は、2ケ月に1回はハードウェアに修正をかけていると言っていました。それはつまり、Coinを一番最初に受け取った人は、もっと後に受け取った人ほどは上手く動作しない可能性があるということです。Coin社は、週に1万枚のカードを製造しています。

As for the bum card reader, Parashar believes “issues will subside as we improve the UX on how to use it.” He said a user interface upgrade was coming sometime this month.

Coinを認識しないクレジットカードリーダーについては、Parasharは「Coinの使い方を改善すれば、その問題は沈静化すると考えています」と語り、間もなくCoinのUIが変更になると語りました。

What’s clear beyond my experience is that the demand for Coin overwhelmed the startup. The company had been planning for tens of thousands of orders, Parashar says. Instead, the company has received around 350,000. That meant the initial plan to manufacture the cards in a facility in the U.S. went out the window when it was clear the volume that plant could produce would not be enough. That was an unexpected complication and a big reason for the year-long delay on shipping.

私の知る限りにおいて一つ明確に言えることは、Coinに対しての需要がベンチャー企業に対しては高すぎたと言えるでしょう。Coin社は数万個の受注を想定していましたが、一方で受注は何と約35万個。これはつまり、米国で想定していたCoinの製造設備の能力を超えていて、別の方法を探さなければならないことを意味します。これは想定外で、1年以上にもわたって出荷を遅らせる要因となりました。

What’s not clear is why Coin kept accepting preorders when it was clear they were already unable to keep up. I asked Parashar this in a phone interview and there was a long pause on the other end of the line before he answered.

では、なぜCoin社は自社の能力を超えるオーダーを受け付けてしまったのでしょうか?私はこの質問を電話インタビューの中でParasharに聞いたところ、彼は電話の向こうで長い沈黙の後にこう語りました。

“That’s going back and trying to have 20/20 hindsight,” he said, finally. “That’s a hard one to answer.”

「振り返ってみれば、当然のことかもしれないが…いや、難しい質問です」

“It’s been way, way harder than we imagined,” he added.

さらに、彼はこう付け加えました。「我々が想定していたより、ずっと…ずっと難しかった」


このインタビューから、好調なプレオーダー受注に気を良くし、資金さえあれば製造は何とかなる…という気の緩みがあったように私には思えます。確かに後から言うことはたやすいけれども、きっとParasherはその時、上手く行く未来しか見えていなかったのではないでしょうか。いや完全な憶測ですが。


たられば論にあまり意味はありませんが、仮にプレオーダーをキャパ一杯の100,000に絞っていたら?
かつ、先行数千人の「リテラシーの高い」テストユーザーに先行配布し、資金に余裕があるうちに生産ラインの方針転換を判断出来ていたら?


これが私が「失敗することに失敗した」と感じる理由です。


私が少額支援しているZNAPSは、プロトタイプをごく限られた(1000人程度の)支援者に使わせ、その結果品質が十分に出ていないことを悟り、作り直しのプロセスに入っています。
(私が2016年3月にブログ記事にしています)


シリコンバレー的な成功の方程式に乗っていても、デザイン思考的な考え方に基づいた事業開発をしていても、失敗するときは失敗する。それらのセオリー通りにやったとて、成功は保証されていないのがビジネスというものなんだろう、と思います。


つまり、私がここで言いたいのは…


本連載のキッカケを作ってくれた、あるコンサルタントは現在米国の大学に留学中で、間もなく論文をまとめようとされています。私も昔、ビジネススクールの教授が書いた論文はいくつか読みました。

しかし、ビジネス論文に関しては、実際に事業を行う中でその実用性を感じることはあまりありません。むしろ、そうした考え方は「そのまま使っても意味がない」とさえ感じます。デザイン思考のような便利な考え方でさえ、実務にはさほど役に立たない。


一方で、ビジネス論文にあるような「考え方」を知っているのと知らないのとでは、失敗の確率が大きく違うとは思います。


例えば、プロトタイプの重要性を理解していないプロジェクトリーダーの元でいくらプロトタイプの重要性を説いても、時間ばかりかかってしまう。しかし、プロトタイプの重要性を全員が分かっているチームでは、おそらくデザイン思考の考え方は受け入れられ、「プロジェクトの進め方に関する議論」という、やや非生産的なことに時間を使ってしまうことはないでしょう。


ビジネス論文を読み、学ぶことそのものが無駄だと言う意図はありません。しかし、それを学んだとて、使い方を誤ってはならないな、と感じる次第です。

例えばチーム内の共通認識を作るために、みんなで学んだり。

類似の事例の失敗事例を扱った論文を読んでおくことで、自らの仕事への戒めとしたり。


そういった使い方をしなければならないのだろうな、と、ビジネス論文について感じた次第であります。


2016/07/08

経営論連載Vol.2 - デザイン思考の5プロセスから見る日本のWebデザインの限界

Webデザイナーと名乗るからには


デザイン思考の5つのプロセス。和訳は筆者による。
出展:An Introduction to Design Thinking PROCESS GUIDE

なんだかんだ、私がWeb界隈のビジネスに身をおいてはや10年近く経ちました。生まれて初めてHTMLに触れたのは確か学生時代の1996年とか97年とかなので、それから20年くらい。まだCSSという規格がなかった時代に、テキストエディタ(メモ帳的なもの)でHTMLを打ち込んで自分のWebページを作ったものです。

あいにく私には絵心がなくセンスゼロだったので、制作方面では全く大成しませんでした。それゆえ、自分が仕事で関わったWeb制作はほとんど外部のWebデザイナーさんにお願いして作ってもらっています。そうして作ってきたページ数は、もう数えられませんが1,000ページは超えると思います。そして、お付き合いしてきたWebデザイナーさんも数十人になります。

その数十人の方々について「この方とはちょっと上手くやれないなー」とか「この方にはぜひ次もお願いしたい!」という感想は正直言うとありました。でも、今まではそれが何なのか、使う写真やイラストなどのクオリティ以外には何が良かった・悪かったのか、上手く言語化できませんでした。

連載Vol.2として、この違和感についてデザイン思考の5つのプロセスの観点でまとめてみようと思います。

その他の連載はこちらからご覧ください。




そもそもデザイン思考って?


デザイン思考そのものの解説はここでは控えますが、本論の入り口として、デザイン思考のビジネス応用提唱者 Tim Brown による説明を引用します。

Design thinking can be described as a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.

以下、私による意訳です。

デザイン思考とは、デザイナーの感性や手法を用いて「人々のニーズ」と「出来るのか?」「やるべきなのか?」をマッチングさせて、お客様への価値を実際に形にして提供する考え方のことです。

少々ややこしいので誤解を恐れずにさらに噛み砕くと「デザイナーのモノの考え方を応用して、ビジネスチャンスを広げるための考え方」ということかと思います。

つまり、元々は「優れたデザイナーさんのアタマの中を整理するとこういうことなんです」というものかと私は解釈しています。


それで、「デザイン」「デザイナー」って?


日本語で「デザイナー」というと、何というか、モノや絵の見た目を作る人、というイメージが強いですよね。プロダクトデザイナー、Webデザイナー、服飾デザイナー。

でも英語で「design」というと「企てる」とか「設計する」という意味合いの方が強い。それって、日本語で言うと「プランナー」みたいな感覚だと思うんです。広告プランナー、イベントプランナー、映像プランナー。

まぁ肩書きの定義は別の場で論じるとして、つまり英語で言う「Design Thinking」のDesignとは、設計する、という意味合いなのではないかと思います。なので、「設計する人の考え方を整理したものがデザイン思考」ということかな、と。


そして英語で「Web design」というと、単にWebページの見た目を作ることではなく「そのページは何を目的としていて、見ている人に何をして欲しいのかを設計してページにする」ということだと私は解釈しています。


そしてデザイン思考をWebデザインに当てはめると


以上の2つの疑問への私の解釈を踏まえて、Webデザインの領域にデザイン思考の5つのプロセスを当てはめてみると、これがずいぶんシックリ来るんです。今までの経験の「良かったWebデザイン」「悪かったWebデザイン」が言語化できるんです。


1. Empathize - 感情移入する




まず、そのページを訪れる人の気持ちになってみる。

私は、何がしたくてわざわざこのページを開いたんだろう?

その時、何に困っていたんだろう?あるいは何にも困ってなくて電車の中のヒマつぶし?

私は投資家で、その会社の財務情報を見たい?私はお客様で、とりあえず店舗の場所が知りたい?

とりあえず新しいメガネが欲しいけど、どれを買ったらいいのか分からない?


よくマーケティングの世界では「ペルソナの設定」などといいますよね。それと同じことではないかと思います。


2. Define - 問題を定める



自分は、本当は何がしたいんだろう?

ある有名な言葉があります。


「ドリルを買いたい人は、ドリルが欲しいのではない。穴が欲しいのだ」


ペルソナを設定したからといって、すぐに表層的に見た目づくりに入ってはならない、と言われているように感じます。

私はドリルを探しているけど、本当に欲しいのはドリルを使って作る椅子なのかもしれない。


私がドリルを探している理由は、壁に穴をあけて棚を据え付けたいのかもしれない。


私がお店の場所を探している理由は、カメラを修理したいたけで本当はお店には行きたくないのかもしれない。


そうやって、お客様の心の声を想像し、問題を設定する段階がDefineです。


3. Ideate - アイデアを出す



さて、お客様の心の声が見えてきたら、その解決策のアイデア出し。どうすればお客様の要望を満たせるページが出来るでしょうか?
(もしかしたらWebページじゃなくてメールマガジンが解決策かもしれないですけどね)


お店の場所を検索している人に、郵送修理サービスを提案してはどうだろう?あるいはカスタマーサポートの電話番号を表示してはどうだろう?

ドリルを検索した人に、椅子や棚などのカスタムメイドサービスを提供してはどうだろう?

この時、もはや解決策がWebページの制作ではなくなるかもしれない。でも、それでいいんじゃないかと思います。
なぜなら「Webページ作らなきゃ」という解決策の設定そのものが間違いだった、ということですから。
(とはいえ、他のEmphasizeやDefineからWebページ制作の必要性は見えてくると思いますけどね)


4. Prototype - 解を作ってみる



さて、解決策の設定が出来たら、次は作ってみること。この文脈においては作るものはWebページなので、とりあえずもうコーディングしちゃう。カンプ(Photoshopなどで作る、とりあえず画像などを貼り合わせて見た目を整えたもの)も作らない。

ちなみにデザイン思考の考え方では、模型でも紙芝居でもコンセプト動画でもいいからカタチにすることが大事、と説かれていますが、Webやスマートフォンアプリの場合は、骨組みだけでもいいから実際に動くものを作ることが大事だと思っています。

なぜなら、Webやスマートフォンアプリは「インタラクティブなもの」だから。つまり、使っていて気持ちがいいか、押しやすいところにボタンがあるか、スマートフォンの小さい画面で見て十分な大きさか、といった「人間の感性との対話」が大切だから。スマホアプリの動作概要を紙芝居でやるのは正直限界があって、本当の意味でのプロトタイプにならない。

こういう話をすると、制作する側、デザイナーさんは「いや、でも思い込みで作っても全然ダメだったら無駄手間になってしまうので」という話をされる方がいます。

私も昔アプリケーションエンジニアだったころには「いや、どういうアプリケーションがいいかはお客様じゃないと分からないから」と一歩引いてしまっていました。なので、そのお気持ちも良く分かります。


そう、ここが本論のポイント。


一歩引いてしまっているということは、デザイン思考で言うところの Emphasize が出来ていないからなのではないでしょうかね。

そのWebページなりスマートフォンアプリなりの、ユーザーさんの気持ちに共感できていないために、そういう発想になってしまう。

これが出来るWebデザイナーさんは、私が考える「よいデザインを作れる人」であったのかな、と気が付いた次第です。

※だからと言って、発注側である私が共感しなくてよい理由にはなりません、というのがVol.1のお話だったりします。


発注者も、Web制作者も、お客様の気持ちに共感してこそ、本当に価値のあるWebページが生まれるんじゃないでしょうかね。

このポイントを理解しているWebデザイナーさんは、日本にはちょっと少なかったかなー、と振り返ると思います。


5. TEST - 試してみる



…とか何とかエラそうに私が言ってみても、真の意味でお客様が欲しているものはお客様に聞かないと分からない。
もちろん制作者自身もイチお客様になり得るわけですが、統計的にはより少し多くの人に見てもらったほうがより「確からしく」なりますよね。

とりあえず動く、触れるWebページが出来上がったら、それを試してもらう。なにもお金を払って本当の一般消費者の人に来てもらう必要はありません(それが出来れば一番いいけど)。社内の別部門の人、社員の友達とかでも良い。実際に触れてもらい、そしてフィードバックをもらう。

そうやって出来上がるものが「よいデザイン」なのではないかな、とデザイン思考では説いているように思います。



総括


そういうわけで、私が日本に居た頃にWeb制作を発注していて感じていたモヤモヤ感を、デザイン思考の切り口で言葉にしてみました。願わくば、このような考え方を体得しているWebデザイナーさんが日本でも増えて、日本のWeb界隈の品質が上がっていくと良いな、と思います。

※ちなみに言うと、アメリカではこれまで2社ほどWeb制作を委託してきましたが、うち1社はデザイン思考をナチュラルに実践しておられ、もう1社はちょっと違う感じでした。このあたり、発注前にどう見極めるか、私も模索してみたいと思います。



参考文献


IDEO社 Aboutページ(英語):デザイン思考の超概略が分かりやすくまとまっています

Stanford大学 d.school によるデザイン思考のプロセス解説(英語):英語たくさんですが網羅感あり


0から1を創り出すデザイン思考 ― 新たなイノベーション創出手法(日本語):ちょっと固いけど良くまとまっています

SAP社によるデザイン思考の活用に関する動画(日本語字幕):EmpathizeとDefineのプロセスが分かりやすく紹介されています


Special Thanks


なお、私のデザイン思考に関する知識は SAP社 Palo Alto Labにお勤めの小松原 威さんから大部分を頂いております。彼の教えなくして本連載はありません。ここに改めて感謝の意を表したいと思います。





2016/07/04

経営論連載Vol.1 - デザイン思考の3要素と昔のビジネスコンサルティングの限界

昔、コンサルタントだったことがありましてね


デザイン思考の3つの要素。ちなみにこれがデザイン思考のすべてではありません


先日、ひょんなことから現役の経営コンサルタントである方と酒杯を傾けながらお話する機会がありまして。

その時に、最近いろいろシリコンバレー流の考え方をインプットしている中で、新しい事業価値の創造についてボンヤリ考えていたことが急に線でつながったので、それをまとめてみたいと思います。
(赤字部分、重要です。本論では、あくまで「新事業価値創出についてのみ」論じています。


その後、自宅のソファでふんぞり返りながら、一瞬眠りに落ちたりしながら考えると、どうも以下の三部作に分けるのがよさそうだ、と思い至りました。


今日はこのVol.1について書いてみようと思います。


少しだけ昔話:2005年頃のビジネスコンサルティング


今をさかのぼること10年以上前のこと、私の転職活動中に、とある世界的な戦略コンサルティングファームのパートナー(一般に、コンサルティングファームにおけるコンサルタントの最上位職位)の方と面接をする機会がありました。

その際に、当時の私が疑問に思っていた質問をぶつけてみました。その時のやり取りは、おおよそ以下のようなものでした。


私 「戦略コンサルタントは、顧客と利害が一致しないことが強みでもありますが、同時に弱みでもあります。弱みは、コンサル案件の結論にコンサルタントは最終的に責任を持てない。ゆえに、本当の意味で顧客の価値創造が出来ない。なぜ、コンサルタントは責任を取らないのでしょう?」


パートナー 「それはコンサルタントのすることではないからです。事業の責任はクライアントにある。コンサルタントは、あくまで第三者の立場でクライアントに価値を提供することが仕事です」


私 「でも、コンサルタントに案件を依頼するクライアントは何かしらの価値創造を求めているわけですよね?真にクライアントの価値を考えるのであれば、コンサルタントも例えば出資するなどして共同責任を負う立場にならないと、クライアントの利益という本当の価値は出ないのでは?」

最後の質問に対する答えは忘れてしまいましたが、少なくとも当時の私が納得する答えではなかったことだけ覚えています。

上記は、今でも感じているコンサルティングの限界です。現在はコンサルタントではなく、コンサルタントに仕事を依頼する側に居る身として常に念頭に置いているのが「コンサルタントは結論に責任を取るのではなく、結論に至る過程をアシストしてくれるだけだ」という点です。

※ちなみに、私は戦略コンサルタントの価値を否定しているわけではありません。私がコンサルタントの価値を見誤っていた、というだけです。

※さらにちなみに、当時の私はベンチャーキャピタルという存在を知りませんでした。自ら出資し、時には人も出してクライアント(投資先)とともに成長する、というビジネスは世の中には存在します。つまり、私はコンサルタントに対して「なぜベンチャーキャピタルのような仕事をしないのか?」という、無知な質問をしていたわけです。そりゃ不採用にもなるわな。


閑話休題。


この「私が考えたコンサルティングの限界」について、デザイン思考の3つの要素が見事に説明してくれていました。


デザイン思考とは?


デザイン思考の概論については、すでに日本語での解説も多くあるようですのでここでは割愛します。以下の参考リンクをご参照ください。

(日本語) デザイン思考を15分で学ぶページ

(英語) デザイン思考のビジネス応用提唱者デイビッド ケリーが創業したIDEO社の会社説明



デザイン思考の3つの要素


さて、ここで冒頭に掲出した画像の出番です…が、少しだけ色の場所を変えます。

デザイン思考の3つの要素、Desirability, Viability, Feasibility。


デザイン思考の考え方では、何よりまず「Desirability」、つまり「お客様はこれを欲しがるのか?」についてを最初に考えるべき、と説いています。これはこれで私も共感するところなのですが、本論においては「Viability」に色を付けます。

Desirability、つまり「顧客の悩みを解決し、顧客が対価を支払いそうか?」については第三者であるコンサルタントでもある程度判断は出来ます。市場調査、テスト販売、あるいはコンサルタント自身が消費者としてそれを求めるか?など。

Feasibilityは客観的な視点です。技術的に、物理的に、あるいは社内の資金や人材などのリソース的に見て、できるのか、できないのか。ある意味、コンサルタントが最も得意とするところではないかと思います。



しかしながらViabilityについては、第三者であるコンサルタントには判断が出来ない。


「客観的に見て、この新規事業が最もリスクが低く、かつ成功する可能性があります」


それ以上のことは言えないんです。クライアントのビジョン、事業目的をアタマでは理解したとて、そのクライアントの中の人ではない。



基本的には、コンサルタントというのは第三者。クライアントからモノ・サービスを買う顧客でもないし、株主でもないし、オーナーでもない。このViabilityを「本当の意味で」判断することはできない存在です。


これが、私が考えるビジネスコンサルティングの限界。



従って、もしあなたが、自分の会社を何とか変えたい、新しい価値を生み出したいと考えるのであれば、依頼先はコンサルタントではないように思います。

(では、どうするか? 試しにデザイン思考を使って考えてみてはいかがでしょうか)


コンサルタントの価値は、「卓越した知見と明晰な頭脳をもって、複雑怪奇な事象を解析し整理する」ことであったり、「現状最も確からしい、リスクの低い選択肢の提案」にあるのであって「新しい事業価値の創造」ではないのかな、と今になって考える次第です。


…ただ、私の「ビジネスコンサルティング」に対する知見は10年以上前のものです。もしかしたら今は変わっているのかもしれません。もしそうであれば、ぜひ一度お話を伺ってみたいものです。


総括


なんだかビジネスコンサルティングを否定する文章みたいになってしまいましたが、決して私にその意図はありません。例えばクライアントのワークスタイル改革だとか、生産性向上だとか、企業内の病の治療などには相性バツグン。それはコンサルタントが第三者であることが最も強みとして活きる領域です。


単に私がコンサルティングをしているなかで感じていたもどかしさは、このデザイン思考の3要素を使うと明確に説明できると感じた、というだけの話です。


つまり、新しい事業価値を創造したかったら、自分たちでやるしかないんだよな、ということ。


もしコンサルタントさんたちに、どうしてもその輪に入ってほしかったら、きっと利害関係を一致させるしかないんでしょうね。出資してもらうか、雇用契約を結ぶか。でもきっと、その人との関係はもはやコンサルティングじゃない。そのヒト個人と目標を共有して「自分たち」になってもらう、ということでしょうね。