答えは自ずから知っていると、前回書いた。知っているにもかかわらず、世間の「普通」の人々はこれを引き出すことができないでいる。
例えば、プロジェクト。
誰も最初から失敗すると思って、プロジェクトをスタートするわけではない。にもかかわらず、なぜこうまで成功率が低いのか。なぜソフトウェアのプロジェクトというのはこれほど失敗するのだろう。調査によると、1994年のプロジェクトの成功率は16％、2009年でも32％。私がこの業界に入って気付いたのは、ソフトウェアのプロジェクトにまるでミサイルの打ち上げのように大きなお金と工数をつぎ込んで、そして爆発してしまう、ということ。
こうしたことがあちこちで起きている。
ほかの業界、例えば化学業界の人に、化学工場が爆発しないようにどうプロジェクトを進めているかを聞いたところ、プロジェクトには2種類あるという。将来が予測できるプロジェクトのプロセスと、予測できないプロジェクトのプロセスだ。
ソフトウェアの開発では、開発中に要件が変わるものである（つまり将来が予測できない）。しかし、なぜか要件が変わらない前提で作り始める。
これが失敗の原因であり、開発プロセスの大きな変化を必要としている。そこで、日本の製造業にデミング博士の論文が与えた影響や、シリコンバレーの起業家たちのチーム構成、ゼロックスの研究所やアラン・ケイ氏の研究、野中-竹内論文などを研究した。
（重要なテクノロジーは10名以下のチームで作られた 〜 Innovation Sprint 2011（後編））
この講演者のジェフ・サザーランドは、この原因を、予測できないものを予測できるかのように扱うことにあるとするのであります。そしてこれを、「スクラム」と呼ぶ手法を適用することで、解決できると言うのであります。
またしても重要な言葉が、ここにも登場するのであります。野中さんの論文によると、NASAはスペースシャトルの開発をウォーターフォール形式で行い、打ち上げまで10年かかった。
このように1つ1つのプロセスがサイロになり、そのあいだをドキュメントでつなごうとすると失敗する。
それを富士ゼロックスではオーバーラップさせ、ホンダではすべてをいちどにやろうとした。チームのメンバー全員がプロジェクトの内容を理解することが成功につながるということだ。
（重要なテクノロジーは10名以下のチームで作られた 〜 Innovation Sprint 2011（後編））
ビジネスモデルを始めとしたあらゆるプロジェクトでは、常に予測できないことの連続であります。これにどう対処するかに、最初から正解はない。チームのメンバー一人一人が考えるしかないのであります。いま直面する問題がプロジェクトにとっていかなる意味を持つのか、当事者として自分自身の問題としてひたすら考える。チームのメンバー全員がプロジェクトの内容を理解することが成功につながる
このとき、チームのメンバー全員が、プロジェクトでいま何が起きているか、すべての情報を共有しプロジェクトの内容を理解する方法が、PCS。
詳しい説明はこちらのエントリーを見ていただくとして、サザーランド氏の手法はこれ。
「スプリントのバックログのリスト」とは、PCSのP項目。「バーンダウンチャート」の説明はこちらがわかりやすい。もちろんプロジェクトの進捗に関するレポートは必要だ。スプリントのバックログのリストとバーンダウンチャートを使う。ガントチャートは先が読めないときにはほとんど意味がないので使わない。
まさにPCSの未解決項目をプロットすれば、このバーンダウンチャートになる。
いつのまにか技法の話になってしまいましたが、ことの本質の話に戻って、話を整理すると、ポイントは一つ。
要するに、「自分自身の問題」であります。
こちらは、プログラマの問題。「IT技術者に求めるのはユーザとしての経験」こそ、グーグルの技術者に決定的に欠けていることなんであります。
（2010年最後はグーグルが色褪せて見える週末テニス）
こちらは、起業家の問題。解くべき最良の問題は、自分が個人的に抱えている問題であると思える。
（オッカムの剃刀をビジネスモデルに適用する週末テニス）
「予知能力」の問題も、すべて一緒。
違いは、どのレベルで自分自身の問題とできるかどうかだけ。
自分自身の問題として身体をおくことにより、問題と身体が同化し、問題の本質が見えてくる。やがて、自ずと進むべき道も見えてくるのであります。
と言うことで、続きはまた次回に。 KAI