企業がWebビジネスの新規事業へ投資する際の成功確率を高めるための方法、とくに「ローコストを追究する必要性」と「YAGNI」について。

目次

  1. 企業の金銭感覚
  2. 新規事業投資、どこまで削れるか
  3. 新規事業のIT投資に、より多くの選択肢を残す
  4. 新規事業のリスクとコスト構造
  5. システム力に勝る「人間力」(手運用)
  6. 戦略的コスト構造を武器に
  7. 新規事業の不確実性

“You ain’t gonna need it”、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。 — YAGNI - Wikipedia

はじめに

どこまで東京?というサイトには、Webビジネスの新規事業投資において学ぶべき事があると思いますので、詳しく紹介します。結論から申し上げれば「Webビジネスの立ち上げは(極端にやれば)ここまでローコストになる」「Webビジネスにはシステム開発が必要だ、というのは思いこみに過ぎない」ということを「どこまで東京?」を例にお伝えしたいと思います。

まず「どこまで東京?」が、どんなサイトであるかについて確認しておきましょう:

「どこまで東京?」とは、みなさんの”イメージの中の東京”をあきらかにしようではないか、という何の役にも立たないプロジェクトです。(中略)実際の都境界線とは関係なく「東京ってここまでだよなー」というイメージをぼくにお伝えください。(中略)みなさんの総合意見を元にぼくが勝手な判断で、みんなの「ここまで東京」を統合し「最新の『ここまで東京』」として発表します。

「お題に対して読者が投稿し、それを編集者が面白おかしく紹介することで成立する、コール&レスポンス型メディア(コンテンツ)」という感じでしょうか。Webサイト設計者の観点からは、バカ日本地図や、ほぼ日の「オトナ語の謎。」や「言いまつがい」などを連想します。

「どこまで東京?」の画面イメージ

〔追記:2011年4月22日、@niftyデイリーポータルZに、作者本人による「どこまで東京?」の解説が掲載されました〕

企業の金銭感覚

さて、「どこまで東京?」はビジネスではないようですが、「仮に企業サイトだったら、どうなるか?」という想定で考えてみたいと思います。1

具体的にイメージするため、条件を付け加えてみます。「どこまで東京?」がキャンペーンサイトではなく「事業」として運営されると仮定します。運営企業は地図出版社で、マネタイズ(収益化)の手段を「書籍化」である……などとしておきましょうか。

さて、多くの企業は「どこまで東京?」のようなサイトを作るとき、もっとお金のかかるやり方をします。だいたい、当たり前のように300~500万円くらい投資するのではないかと思います。うち大部分はサイトの開発費、とくにシステム開発費ではないでしょうか。(なお、ここでは「社内には企画担当者のみで、開発部隊が無い会社」を想定しています)

すでに「どこまで東京?」を見てしまっていると思うので、いったん忘れてください。そのうえで、同じような企画プロセスを追体験していきましょう。

こういう企画コンセプトだとします。「どこまでが『東京』なのか、というテーマには語るに十分な面白さがあり、それをネット上のユーザ参加型・投稿型メディアとして運営することで、将来の書籍化・出版事業による回収を目的として云々」という企画があったと想定してみて頂きたいのです。どういう風に物事が進みますか?

  • 「ならば地図を押し出したUIで」
  • 「ユーザが地図に一筆書きで線を引いて投稿できるシステムを採用して」
  • 「投稿を審査するための管理画面を用意して」
  • 「クチコミを期待してブログパーツを用意して」
  • 「もし大ヒットしたらサーバが落ちるので十分なネットワーク・インフラを」

といった話になり、すぐに300〜500万円くらいの投資案件になるのではないでしょうか?

しかし、私は30~50万円に抑える方法を模索したいです。10分の1。

新規事業投資、どこまで削れるか

先ほど、サイト開発費だけで300~500万円くらいの予算規模になりそうだ、と述べました。

私は30~50万円に抑えたい。

極限まで削るという思考実験です。それをやったあとで、「あれも欲しい、これも欲しい」という要件をあげていって、優先順位を付けて、フェーズを分けて、段階投資すればいい。

どうやれば最小の予算でできるか?

「どこまで東京?」と同じようなシステム構成にします。これは後知恵ではなく、実際ローコストに立ち上げたいとき、真っ先にこういう構成を思いつきます。つまり、

です。既製品かつ、なるべく安価なものに。オープンソースソフトや、無料または格安のSaaS/ASPなど。例えばブログ/CMSでいえば、Blogger、WordPress.com、TypePadなども。

要件にプライオリティがついてないと、削れません。一方で、安ければいいというものでもなく、要件を満たさない製品を選ぶと運用で苦労します。このあたりは、知っている製品・ソリューションの数、つまり引き出し・ノウハウが、ものをいうのではないかと。

なるべく削りたくない費用はデザインです。といっても、せいぜいブログテンプレートの修正ですが。

デザインは集客のROI(投資対効果)向上に寄与します。サイトのコンセプト、ターゲット(ペルソナ)に相応しいデザインにしておけば、ROIが向上するはずです。2

管理画面も作りません。必要になってから作ればいい、と考えます。もちろん、必要になった場合を想定しておきます。どういう状況で、どういうものが必要か、という要件・費用・工期を事前におさえておきます。そうすれば、いざ必要となってから、あわてず開発すればいい。このように、想定だけはしておきつつ、必要になるまで着手しないのです。

これで、300〜500万円かかるはずだったIT投資額は、30〜50万円になりました。「本来かかるはずの費用が減った」わけではありません。そんな魔法はありません。要件を最小限に絞った上で、直近のフェーズにおいて必須ではない要件を先送りしたのが「手品のタネ」です。

余談ですが、こうして削って余った予算は、テストマーケの集客費用に回すのもよいでしょう。ネタがよければニュースリリース配信だけでなんとかなる場合もありますが、外れる可能性もあり、運任せです。確実な集客のためには広告が不可欠です。そうしないと「サイトが良かったかどうか以前に、ユーザが少なすぎて検証できない」という事態があるので。仮説検証とはいえ、統計的に有意なデータを得るためには一定数の集客が必要であり、つまりは一定の集客費が必要になります。

新規事業のIT投資に、より多くの選択肢を残す

こういう提案に対して「個人サイトじゃないんだし、そんな安っぽいシステムじゃダメだろう」という方がいらっしゃるかもしれません。では、逆に質問しますが、何が不足なのでしょうか?

ここまで述べてきた方法によって、ビジネスの可能性(フィジビリティ)を十分に検証することができます。極端に小規模な実験ですが、非現実的ではありません。これで十分です。そして、小規模に実験することには、大きなメリットがあります。それは少しのお金しか使わずに、重要な仮説検証ができたということです。

「一度に500万円使う」のと「まず50万円使って、その結果を見てから追加で450万円を使う」のを比べれば、後者のほうが有利です。「同じプロジェクトに結局500万円を投じるなら一緒じゃないか」というのは、リスクや不確実性への洞察が足りないだろうと思います。もっと現実の不確実性に対して謙虚になるべきでしょう。「失敗しても50万円で済む」という選択肢(リアル・オプション)の価値は無視できません。そこで軌道修正したうえで残りの450万円を使う選択権を得られるのですから。

大事なことは「失敗の可能性を不可避のものと受け入れ、意志決定プロセスに考慮すること」です。「絶対に成功する法則」などありませんし、「当初の意図通りに成功すること」も稀です。つねに「予期せぬ失敗」や「予期せぬ成功」と対峙し、それが何を意味するのかという本質を問い続け、臨機応変に軌道修正する必要があります。ドラッカーが『イノベーションと起業家精神』で述べたとおりです。

また、絶え間ない事業の軌道修正において、ITシステムが足かせになってはいけません。事業の成功が目的であり、ITシステムは道具に過ぎない。しかし、ソフトウェアという言葉と裏腹に、いちど作ってしまったシステムはガチガチに固いもので、柔軟に変更できません。工期と費用が発生します。トップが決めた方針転換を、その日のうちに反映することはできません。

だからこそITガバナンス的にも、柔軟性を保てるSOA (Service Oriented Architecture)が有利だと思います。トータルコストで見れば、垂直統合(モノリシック・一枚岩)のアーキテクチャのほうが、ROIは高いかもしれません。しかし、それは確定論的世界観では正しくとも、現実の不確実性の前では、あまりに無防備な考え方です。多額の投資、資産、負債を、早期に固定化すべきではない、と考えます。

さて、ひとつクイズを。この世でいちばん、要件変更に対して柔軟なシステムは何でしょうか? それは「未だ実現されていないシステム」です。実装されていないソフトウェアは、あらゆる要件変更に対して柔軟です。

このことから、「何が起こるか分からない」ような事業環境におけるITガバナンスの第一原則は、「必要になるまで作らない」ことだといえます。ありもの(既製品)のパッケージやSaaS/ASPを活用すべし、という方針です。

それらの既製品にAPIが備わっていれば、SOAの考え方で拡張可能です。部品を少しずつ入れ替えて拡張していける。結果として、「一気に500万円投じたとき」と同じような構成まで発展させることも可能でしょう。違いは、「途中で計画変更する選択肢」(リアル・オプション)の有無です。

XP (Extreme Programming) というアジャイル開発方法論には「YAGNI原則」という考え方があります。「そんなもの必要にならない (YAGNI: You Aren’t Going to Need It)」というマントラ(呪文)です。これを唱えながら要件追加の誘惑に負けないように自戒しろ、ということです。もしあなたが 「いずれ必要になりそう」という誘惑に負けそうなときは、「ヤグニ(YAGNI)」と唱えてください。

私がクライアントの新規事業企画会議に参加したときには、「IT投資を遅らせるべき理由」「いかにIT投資をせずに、あるいは遅らせて、事業を立ち上げるべきか」を説得することが、けっこうあります。

ちなみに、こういうことは、ふつうベンダーやプロダクションのような開発受託業者の側からは言いません。発注する気のあるお客さんの財布の口をわざわざ自分から縛るような「愚行」だからです。

逆に、こういう利害相反のないコンサルタントを雇って「セカンド・オピニオン」を活用すれば、「アジャイル投資術」を実践しやすくなります。また、実際にシステムを作って小規模な試行錯誤を繰り返す「プロトタイピング」という開発手法も有効です。

新規事業のリスクとコスト構造

会計的な観点では、いかに「投資を固定費に」「固定費を変動費に」するか、がポイントです。同じ支出でも、投資と変動費では、性質が違います。投資は支出した瞬間に大きな金額が確定してしまう一方で、変動費には柔軟性があります3

仮に、事業が不振で撤退するとします。その場合、変動費ならば事業撤退の月から支出を止めることもできます。一方で、投資して獲得した資産は、流動性や転売価値が低くなりがちです4。結果として、事業の撤退コストは押し上げられ、精算価値を押し下げられます。

さて、「どこまで東京?」のケースを見てみましょう:

いただいた投稿を元にぼくが手作業で結果を発表するというハートフルなシステムを採用しております。いましばらくお待ちください。現在50通溜まっております。すまん。 — 投稿反映に関して - どこまで東京?

いま更新して、5人の方分をご紹介するのに1時間半かかることが分かりました。今現在、あと150通溜まっていますので、全てご紹介するのには、えーと、45時間ですか。それだけかかります。 — 嬉しい悲鳴 - どこまで東京?

まさに「嬉しい悲鳴」のようです。ドラッカーなら「予期せぬ成功」と呼ぶところです。我が社にも「ここまで急に流行ると思わなかった」という経験(エア新書、コマーシャライザーなど)があるので、体験として分かっているつもりです。

こういう「大成功」のケースを想定し、万全なシステムを作るためにシステム投資をするケースがあります。ある意味「取らぬ狸の皮算用」です。今回はそのような投資に対する懐疑的な見方を提示し、よりよい方法を提案します。

IT投資の効果指標として「コスト削減効果」を考えるのはアリですが、業務システムと違って、新規事業においてはリスクが大きい。どれくらい使われるか(=処理件数)が分かりませんから、投資前後のコスト(トータルコスト=単位コスト×処理件数)を比較するうえでも「リスク」を考慮しないといけない。

細かく分析すると、改善前の単位コストは「やってみなくても分かること」です。例えば、Googleマップというシステムはすでに存在しますので、サンプルデータを作って、実際に手作業で登録してみて、時間を計測すればいい。また、その「削減効果」もある程度までは予測可能です。

このように、「単位コスト」も「改善効果」も推定できます。しかし、肝心の「件数」が確定しません。ですから、新規事業における業務効率化投資の効果には「リスク」があります。これが、ふつうの業務システムにおけるIT投資との大きな違いです。

ここで「どこまで東京?」のケースを見て、「150も投稿が来ると分かってるんだから最初からシステムを用意しておくべきじゃないか」というのは完全に「後知恵」です。閑古鳥が鳴いていたかもしれず、その場合は投資が完全に無駄になっていたわけですから。

以上のように、新規事業の不確実性を考慮すれば、「いきなり投資しない」「必要最小限に絞る」という方針が有力だと考えます。

読者の中には「でも『予期せぬ成功』への備えが無いじゃないか」と思われる方もいらっしゃることでしょう。次は、その「備え」について述べます。それは「人間力」です。といってもウェットな浪花節の話をするつもりではありません。文字通りマンパワー(manpower)の話です。

システム力に勝る「人間力」(手運用)

誤解されるかもしれませんが「人間力」といってもウェットな話をするつもりはありません。文字通りマンパワー(manpower)の話です。本稿のここまでは「いかにシステム化を先送りするか」について述べてきました。システム化するまでは、その作業を人間がすることになります。ですから、ここではその「人的運用」について論じます。ここではWebサービスの表側(ユーザに見える部分)ではなく、裏側(管理画面・業務システム)が主題になります。

システム化せずにマンパワーで処理することのメリットは、第一に「投資を先送りできること」でした。それに加えて、「業務プロセスを試行錯誤できること」があります。業務プロセスの試行錯誤は、業務プロセスの洗練につながり、それはシステム要件の明確化になります。ですから、同じものを作っても開発費が安くなります。それについて説明します。

システム開発(SI)において「システムの品質は上流で作り込む」という考え方が普及しています。その意図は、「システム化計画や要件定義といった上流フェーズによって、全体のQCDのリスクが大きく左右される5。だから上流フェーズでリスクを減らそう」ということです。

このような「上流フェーズ重視」の必要性は、上流フェーズでの失敗について想像すれば、すぐに理解できます。実装フェーズで要件変更をすれば、多くの手戻りが発生します。それは費用の増加と、納期の遅れにつながります。ですからウォーターフォール型の開発プロセスでは、手戻りを減らすことが必要であり、そのために上流工程で完璧な要件定義を作っておくことが重要なのです。6

要件定義を固めるうえでは、業務の試行錯誤が必要です。業務システムの要件は、業務プロセスだからです。新規事業なら、まだ業務プロセスは固まっていませんから、しばらくは試行錯誤の連続になるでしょう。そして、ほとんどの新規事業は、試行錯誤のまま終わります。

幸運な新規事業だけが黒字化していきます。その過程において、業務プロセスの試行錯誤が落ち着いてきます。業務プロセスが固まってきます。それによってシステム化のための業務要件が固まりますので、その段階ならばシステム化をしても無駄がありません。要件変更の手戻りコストが減りますから、開発費が安くなります。

ちなみに、業務プロセスの試行錯誤に強いのは人間であって、システムではありません。人間は先行投資しなくても稼働します。せいぜいマニュアルくらい整備すれば実践投入できます。曖昧な記述があっても、自分で判断して「よきにはからって」くれます。システムは、こういうわけには行きません。「よきにはからう」というシステムを作ろうとすれば、非常に高くつきます。

人間はマニュアルなどのドキュメントを読んで作業することができます。業務プロセスを変えるときは、ドキュメントを書き換えれば済みます。。システムを改修する必要はありません。つまり、マンパワーで業務プロセスの試行錯誤をすることには、業務システムの設計をプロトタイピングするのと同じような意味があるわけです。

ところで、システム開発を細かいフェーズに分けることでも、同じような効果が得られます。明確に「固まってる部分」だけ、まず開発する。そして、固まっていない部分は保留する。「そのとき必要なもの」だけを速やかに開発していく。このように細かくフェーズを切ってリスク・コントロールしていけば、トータルコストが低くなります。

開発フェーズを細かく分けると、一見、開発費が膨らむような気がするでしょう。しかし、うまくやれば、開発フェーズを細かく分けることでトータルコストが下がるのです。これはウォーターフォール型の開発プロセスに慣れている人にとっては、直感に反することかもしれません。しかし、開発には本質的にリスクがあります。開発フェーズを細かく分け、無駄なものを作らないようにすれば、トータルコストは下がるのです。

以上のように、新規事業においては、「業務システムの開発前にマンパワーでこなすこと」「業務プロセスが固まってからシステム開発に着手すること」という二点が大事なのです。

戦略的コスト構造を武器に

マンパワーは、社外から調達できます。社員が手を動かす必要はありません。マニュアル化しやすいルーチンワークに限られますが、そもそもシステム化するような業務はルーチンワークでしょう。

人的運用はアウトソーシングによって変動費化でき、柔軟なコスト構造の実現にもつながります。そのうえ、この円高ですから、海外へのアウトソーシング、つまりサービス輸入によって、円高の恩恵に浴するのも有力でしょう。海外アウトソーシングのほうがシステム化投資より安い場合だって十分に考えられます7

「とはいっても、『どこまで東京?』は企業ではなく個人であって、お金がないからこそ、こんなにもローコストにできるんじゃないか」という反論が聞こえてきそうです。たしかに、そうでしょう。

では、逆に聞きますが、なぜ企業は同じように「お金のかからない方法」を取ることができないのでしょうか?

低コスト体質であることは、競争上の大きな武器になります。ベンチャー企業は「お金がないから工夫して、低コスト体質を実現する」とも言われます。ベンチャー企業の強みは「お金がないこと」にある、とさえ言えます。

このことについて、三つのイノベーション戦略論を紹介しつつ説明します。

ジェフリー・ムーア氏は『ライフサイクル イノベーション』のなかで、ビジネスのフェーズ(ライフサイクル)に応じて「コア」と「コンテキスト」への投資を適切に配分せよと説きました。コアとは、新規事業がユーザに提供すべき本質的な価値を生み出す要素、他社との差を生み出す要素のことです。「どこまで東京?」のケースなら、「投稿できること」「東京を地図で可視化して見せられること」などがコア要素となるでしょう。一方、「投稿を審査していたずらを防ぐ仕組み」などがコンテキスト要素です。

コンテキスト要素への投資は、ユーザのことを考えた結果よりも、運営会社のリスク回避、いわゆる「事なかれ主義」から出てくる場合があります。つまり「問題を事前に防止しておこう」という考え方です。事業がある程度成長すればそういう投資も必要になりますが、最初から必要なものではありません。それなのに最初からそういうコンテキスト要素を「必須」だと考えるのだとしたら、官僚主義や大企業病のおそれがあります。保守的な組織文化は、新規事業の大敵です。新規事業のダイナミズムを殺してしまうでしょう。

そもそも、「ユーザーに悪さをされたら困るので投稿審査機能は初期開発から必須だ」といった前提を疑う必要があります。「そういう悪さをしないモニターだけ選んでクローズド・テストをすること」で問題そのものが解消するのですから。そういう都合の良い「実験条件」を考えればよいのです。

クレイトン・クリステンセン教授も『イノベーションへの解』 で、新規事業の立ち上げにおいて「金を節約すること」の重要性を論じています。既存市場のローエンドや、新市場は、既存プレイヤーから無視されます。したがって、破壊的イノベーションが橋頭堡(前進拠点)を確保しやすい領域です。そこでどれだけ早く利益を達成するかが、新規事業の命運を分けます。新規事業への資金供給は、様々な理由から、突然に打ち切られることがあるからです8。早期に利益を達成するためには、コストの低さが有利です。

キム教授&モボルニュ教授も『ブルー・オーシャン戦略』において低コストの利点を論じています。ブルー・オーシャン創造のためには、まず「顧客に提供する価値」と「戦略的な価格」を定め、それを実現するための「コスト構造」を模索します。これはコスト積み上げ型の価格設定(コストが価格の目標値を定め、できるだけ高く売ろうとするもの)とは逆の戦略策定プロセスです。できるだけ安く売ろうとするために、価格がコストの目標値を定めるような戦略策定プロセスです。

戦略的な価格を達成するためには、徹底したローコスト・オペレーションが必要になります。しかし、なんでも削ればいいというものではありません。では、どこでメリ・ハリをつけるのか。それを判断するために、「戦略キャンバス」というツールと、「4つのアクション」によって市場の境界をひきなおす方法が提案されています。それによって「差別化」と「低コスト」を両立することを「バリュー・イノベーション」と呼びます。

ここで紹介した三つのイノベーション戦略論は、いずれも「低コストの優位性」を説いています。新規事業のルールは「できるだけコストをかけるな」です。投資しようとしているものが「コア」か「コンテキスト」か見極めてください。「YAGNIではないだろうか?」と自問してください。

既存事業と新規事業では、ゲームのルールがまったく違います。既存事業をうまくこなせる人も、新規事業でうまくやれるとは限りません。かえって既存事業での成功体験が邪魔になる場合さえあります。ゲームのルールが違うことを認識し、アンラーニング9する必要があります。

そのうえで、新規事業において低コストを実現すべき理由とは、「そうする必要があるから」です。お金が余っていても、低コストを実現すべきです。たとえ大企業でも、新規事業においては低コストを追求するのが「戦略的」なのです。

新規事業の不確実性

さて、ここまで「新規事業投資にはリスクがある」と論じてきましたが、正確には、「リスク」というより「不確実性」というべきかもしれません。

「あるサイトをオープンする」という事象は一度かぎりであり、二度と起こりません。ですから、厳密な意味では確率計算(記述統計)できるのかどうか疑問です。もちろん、他の類似ケースや、これまでの経験などから、主観的確率を推論することはできます(推計統計)。とはいえ、あくまで信頼性の低い推論でしかないことに注意が必要です。

これは私なりにいろいろ考えたうえでの結論です。確率計算が可能な「リスク」ではないかと思ってモンテカルロ・シミュレーションという手法の導入を検討したこともあります。しかし、あまり役立ちそうにありませんでした。それは何故だろうと考えました。私自身が関わる案件の規模は小さく、投資も少額で、サイクルも短い。ですから、新規事業のダウンサイドとアップサイドのリスクを把握するだけなら、Excelのシナリオ分析ツールを使った大雑把な分析でも十分でした。

高度なシミュレーション手法に手を出すより、むしろパラメータやシナリオの数を減らして「鋭い仮説」を立てることに注力した方がよい。それが私の結論です。それによってモデルが簡単になり、シミュレーションにリアリティが出てきます。シミュレーションと現実を結びつけて想像しやすくなります。数字だけがひと歩きしているような事業計画ではなく、生き生きとストーリーテリングできるような事業計画になります。

遠い先のことは分からないけれど、近い未来なら予測できる。間違っていたら方向修正できる。だから問題を小さく分割しよう。フィジビリティ・スタディを段階的に実施して、仮説検証していこう。これが新規事業の不確実性に対処するための、いわば「イノベーションの技法」でしょう。10

正確な未来予測は無理なので、「いかに早く間違いに気付くか」を追究しましょう。「できるだけ早く、たくさん失敗しろ」と行動原理を採用しましょう。そのためには高速な仮説検証サイクルを回す必要があります。そうでもしなければ、新規事業はビジネスではなく、ただのバクチになってしまいます。プロフェッショナルなら、運任せにせず、成功確立の高まる方法を模索すべきでしょう。

新規事業は「どうすれば、どうなるか」という因果関係がよく分からないブラックボックスです。最初は手探りから始まります。ならば仮説検証型で「ボックス」の中身を解明していくしかありません。どういうインプット(行動)によって、どういうアウトプット(結果・反応)が得られるか。ブラックボックスの振る舞いをデータとして集めることで、その特性を理解していくしかありません。

つまり、イノベーションの技法とは、実験科学的アプローチです。あるいは「経験主義」といってもいいでしょう。頭のなかで考えた新規事業企画は、ほぼ間違いなく失敗します。行動を通じてブラックボックスの中身を解明していく「経験主義的アプローチ」だけが成功への道です。

おわりに

今回は「どこまで東京?」というサイトの考察から始まり、企業がWebビジネスの新規事業へ投資する際の成功確率を高めるための方法について考察してきました。とくに「ローコストを追究する必要性」と「YAGNI (You Aren’t Going to Need It)」は覚えておいて頂ければと思います。本稿が読者の新規事業企画の参考になれば幸いです。

関連情報

本稿で述べたような「IT投資戦略」「ITガバナンス」を考えて意志決定することがCTOの第一義的な役割です。CTOの重要性と役割について書いた「チーフ・テクノロジ・オフィサ(CTO)ってチーフ・エンジニアと違うの? 」もご参照ください。

変更履歴

  1. 2009年1月27日 Zerobase Journalで公開
  2. 2015年8月17日 当ブログへの転載に際して改訂(読みやすくなるよう推敲した)
  1. このような形で「どこまで東京?」を紹介することについて、作者の大山顕氏に快諾いただきました。感謝します。 

  2. なお、デザインの良し悪しがどれほど成果の違いをもたらすか、実際に測定することができます。「CMSのデフォルトテンプレートのウェブページ」と「ちゃんとデザインしたウェブページ」をA/Bテストすればよいのです。 

  3. もちろん、税法上一括償却できるような少額の投資なら、大して問題になりません。いま問題にしているのは100万円以上の投資です。 

  4. あるビジネスモデルに特化したシステムなどの資産は、そのビジネスがダメだとしたら、無価値になる場合もあります。運が良ければ、別の用途に使ってくれる買い手が現れるかもしれませんが、その可能性は50%よりずっと低いでしょう。 

  5. 「QCD」とは Quality(品質)、Cost(費用)、Delivery(納期)の略称です。 

  6. このような「要件を完璧に想定して手戻りをなくす」ということは大変難しいので、当社ではプロトタイピング(作りながら要件定義する試行錯誤型の開発方式)を採用していますが、それはさておき、ここでは世間一般のシステム開発の話です。 

  7. 2009年の執筆時と、2015年現在では状況が違うので、少し補足しておきます。執筆当時は1ドル90円程度で、2012年に1ドル80円程度になるまで円高が続いていました。それが2015年の現在は1ドル120円程度、大幅な円安になっています。また、2009年はクラウドソーシングが普及していませんでしたが、2015年現在はランサーズやクラウドワークスがあります。 

  8. 『イノベーションへの解』のなかの第9章「良い金もあれば、悪い金もある」の議論です。 

  9. 「アンラーニング」(unlearning)とは、いったん学習したことを意識的に忘れ、学びなおすこと。 

  10. 2009年の執筆当時に「デザイン思考」という言葉は普及していませんでしたが、ここで述べた「イノベーションの技法」のマインドセットには、デザイン思考との共通点があります。