筆者は2014年のWEB+DB PRESSでの特集
いろいろなサイクル
サイクル型のモデルの中で一番有名なのはPDCAサイクルでしょう。これは
最近有名になったのは2011年に提唱されたリーンスタートアップのモデルでしょう。これは
筆者が
これらはすべてサイクルを回して物事を改善していくモデルです。サイクルを回すことで1を2に、
ブレインストーミングで唯一厳密に行わねばならないこと
アイデアを出す方法として有名なものに、
ブレストはワイワイと口頭で議論をするものだ、
たとえばWikipediaなどでは
逆に、
1986年に日本人によって書かれた本でもアイデアを記録することが解説されており
人間の記憶はブレストで出たアイデアをすぐに忘れてしまいます。なので思い付いたらすぐに記録をすることが大事です。
他人と同時にはしゃべれない
Osbornによるブレストの提案はデータに基づくものではありませんでした。彼がブレストを提案してから、
- 1人がしゃべっている間ほかの人はしゃべれない
- 「他人からどう思われるだろう」
という恐怖が発言を委縮させる - みんなでやると自分が案を出さなくてもよいという気持ちが起こる
この論文の著者は「音声ではなくチャットなどの電子的コミュニケーション手法を使えば、上記の問題を軽減できるのでは」というもので、実際、12人のグループでは個別にやるよりも電子的コミュニケーションを行ったほうが効率が良いという結果が出ました[7]。
出す前に入れる
ブレストなどでたくさんの情報を書き出したあとは、KJ法でまとめることがよく行われています。これはフィールドワークなどで収集した情報を個別の紙に書き、その紙を机の上に広げ、関係のありそうなものを近くに集め束ね表札を付け、これを繰り返すことでもともとの膨大な断片的情報に構造を作り出していく手法です。
このKJ法を考案した川喜田二郎は、『発想法』[8]をベースに多くの人にKJ法を教えた結果、個々の現場での観察と記録が鋭いかどうかがKJ法の死活を決める、と考えました[9]。
「アイデアを出す」と言うと、ついつい頭から外に出すことをイメージしがちです。しかしそれでは、今あなたが持っている「思い込み」に基づいて考えることになります。それを避けるには、解決したい問題に関係あるかもしれないことを頭の外から収集するフェーズが必要です。
川喜田二郎は、実験科学的に仮説を検証するフェーズの前に、「野外科学」という情報を収集し仮説を立てるフィールドワーク的なフェーズが必要と主張しました[10]。KJ法はその野外科学の方法論です。収集した情報を、一度に思考のまな板に乗せることができる「小さなグループ」にすることで、そこから新しいアイデアが生まれる、という方法です[11]。
小チームから大チームへ
川喜田二郎がKJ法の解説で強調したことの一つに「小さなグループから大きなグループへ」というボトムアップな流れがあります。
「これらの情報をこういう分類で仕分けよう」と先にカテゴリを決めて、そのカテゴリに合わせて情報を分類してはいけません。なぜかと言うと、それではせっかく集めた情報を無視して「自分の脳内の思い込みに基づく枠組み」を作り、集めた情報をその枠にはめ込んでいるだけになるからです。それでは、思い込みの枠を壊すような発想は生まれてきません[12]。
量にフォーカス
Osbornは「判断力はアイデアを殺すことがある」と述べ、殺される前に紙に書くことが重要だと考えました。川喜田二郎は、ある情報がテーマと関係あるかどうかはあとから明らかになるものなので、情報収集の段階では「関係あるかもしれない」ものを何でも収集すべきだ、と述べました。ブレストやKJ法のアイデア書き出 しの段階で、アイデアの質を求めるのは間違いです。
また「良いアイデアを出す」というゴールは、努力をしてもゴールに近付いたかどうかがわかりにくいです。これではマラソンでどこにゴールがあるかわからないようなもので、モチベーションを保つのが難しくなってしまいます。なのでまずは「アイデアを100個書く」などの量で測れるゴールを設定するべきです。これならば、1枚書くたびにゴールに向けて1歩進みます。あとどれくらい進めばゴールインなのかも明確です。
完璧主義はアウトプットの邪魔
この「とにかく100個アイデアを書く」という課題で、最初の1個が書けないで長時間悩んでしまう人もいます。最初から質の高いものを書こうとするとこうなりがちです。
重要なのは、最初のリリースでの完成度ではありません。すばやくフィードバックを得て改善することです。Thomas Edisonは「発明とは一時に完全な形で現れるものだと思っている人が多いが、そんなものではないのだ」と語っています[13]。
今やろうとしていることは「0→1」です。改善のサイクルを回してより良いものにしていく作業は、0→1が終わったあとにやることです。このフェーズではまずは質を度外視し、とにかく数をたくさん出すことを目指すのです。
リスクを恐れずリリースしよう
前回と関連する話ですが、失敗のリスクを恐れてアイデアをアウトプットしなければ、それに対するフィードバックは得られません。学びを得たければ恐れずに進むことが必要です。成功しても失敗しても学びがありますが、アウトプットしなかった人には学びはないのです。
リーンスタートアップは、顧客がいるかどうかもわからないサービスの完成度を上げることに時間を使うことを批判しました。そうではなく、顧客がいるかどうかを検証するための最小限の製品をリリースし、そこからすばやく学ぶことを重視しました。
リーンスタートアップはベンチャーの経営に関する手法ですが、エンジニア個人の経営についても似た構図があるでしょう。速やかに学ぶためには、すばやいリリースが必要なのです。