筆者は2014年のWEB+DB PRESSでの特集「エンジニアの学び方」で，学びのプロセスは「知識収集」「⁠抽象化」「⁠応用」の3つのフェーズを繰り返すサイクルだ，と解説しました（注1⁠）⁠。しかし，サイクルには始まりも終わりもなく，「⁠最初の一歩は何か？」という質問には答えていません。今回は，サイクルを始めるための最初の一歩について，いろいろなサイクルを例に考えます。

いろいろなサイクル

サイクル型のモデルの中で一番有名なのはPDCAサイクルでしょう。これは「計画」（⁠Plan）を「実行」（⁠Do）し，その結果を「チェック」（⁠Check）して結果を「修正」（⁠Adjust）する，というモデルです（注2⁠）⁠。これの元ネタは，科学における仮説検証のサイクルです。仮説を立て，実験を行い，その実験結果を見て仮説を修正する，というサイクルです。

最近有名になったのは2011年に提唱されたリーンスタートアップのモデルでしょう。これは「お金を払ってくれる顧客がいる」という仮説を検証するために，アイデアを「構築」して製品を作り，製品を「計測」してデータを作り，データを「学習」して新しいアイデアを作る，というサイクルです（注3⁠）⁠。

筆者が「エンジニアの学び方」で解説したのは，時間をかけて「知識」を収集し，収集した知識を「抽象化」して応用可能なモデルを作り，そのモデルを「応用」することでモデルが正しいかどうかが検証され，次にどういう知識を収集すればよいかの指針，やる気，時間などが手に入る，というモデルでした。

これらはすべてサイクルを回して物事を改善していくモデルです。サイクルを回すことで1を2に，2を3にと改善していって，1→100を起こす方法です。なので「そのサイクルを開始する最初の一歩は何か？」という共通の問題があります。計画はどうやって作るのか？ 仮説は？ アイデアは？ 0→1をどうやるかは，これらのモデルでは解説されていません。どうすればよいのでしょうか？

注1）

詳しくはWEB+DB PRESS Vol.80の特別企画「エンジニアの学び方」を参照してください。gihyo.jpでも公開しています。

注2）

少し細かいことを言うと，1950年代にPDCAサイクルを提案したWilliam Edwards DemingはPlan-Do-Check-Act Cycleと呼んでいました。その後，彼はPlan-Do-Study-Act Cycleと名前を変えています。一方で，リーン開発についての多くの著書があるPascal DennisはPlan-Do-Check-Adjust Cycleと呼んでいます。筆者は歴史や規格ではなくこの概念自体を教える場合にはAdjustのほうがわかりやすいだろうと考えています。

注3）

Ash Maurya著／角征典訳『Running Lean─⁠─実践リーンスタートアップ』オライリー・ジャパン，2012年，p.13

ブレインストーミングで唯一厳密に行わねばならないこと

アイデアを出す方法として有名なものに，ブレインストーミング（ブレスト）があります。

ブレストはワイワイと口頭で議論をするものだ，という誤解も多いように思います。しかし，ブレストの考案者Alex Osbornは，唯一厳密に行わねばならないことは，すべてのアイデアを記録することだ，と述べています（注4⁠）⁠。

たとえばWikipediaなどでは「ブレインストーミングの4原則」というルールを守らなければいけないと説明されていますが，Osbornはアイデアの記録だけが唯一厳密に行わねばならないことだと述べていることを考えると，ルールとしてとらえるのはかなりニュアンスが違うように思います。

逆に，ブレストは常に非公式のものであるべきだから，この原則は（ルールとしてではなく）リーダーが自分の言葉で述べるべきだ，ということを書いています（注5⁠）⁠。

1986年に日本人によって書かれた本でもアイデアを記録することが解説されており（注6⁠）⁠，以降30年の間になぜか忘れられてしまったようです。

人間の記憶はブレストで出たアイデアをすぐに忘れてしまいます。なので思い付いたらすぐに記録をすることが大事です。

注4）

「厳密に正式に行なわねばならない唯一の事柄は，提出されたすべてのアイディアの記録である。」Alex Osborn著／豊田晃訳『新装版　創造力を生かす─⁠─アイディアを得る38の方法』創元社，2008年，p.273

注5）

『新装版　創造力を生かす』p.272

注6）

「何でも思いついたものを言って行く。記録係が，片端からそれをメモする。」外山滋比古著『思考の整理学』筑摩書房，1986年，p.168

他人と同時にはしゃべれない

Osbornによるブレストの提案はデータに基づくものではありませんでした。彼がブレストを提案してから，多くの研究者によってブレストに効果があるかどうかの研究が行われました。いろいろな研究が一貫して「音声でやりとりしながらやるより，その人数が一人一人バラバラにアイデア出しをしたほうが効率が良い」という結果を出し，その原因として次のようなものが挙げられました。

1. 1人がしゃべっている間ほかの人はしゃべれない
2. 「他人からどう思われるだろう」という恐怖が発言を委縮させる
3. みんなでやると自分が案を出さなくてもよいという気持ちが起こる

この論文の著者は「音声ではなくチャットなどの電子的コミュニケーション手法を使えば，上記の問題を軽減できるのでは」というもので，実際，12人のグループでは個別にやるよりも電子的コミュニケーションを行ったほうが効率が良いという結果が出ました（注7）。

注7）

Dennis, Alan R., and Joseph S. Valacich."Computer Brainstorms: More Heads Are Better Than One," Journal of Applied Psychology, 78.4, 1993.

出す前に入れる

ブレストなどでたくさんの情報を書き出したあとは，KJ法でまとめることがよく行われています。これはフィールドワークなどで収集した情報を個別の紙に書き，その紙を机の上に広げ，関係のありそうなものを近くに集め束ね表札を付け，これを繰り返すことでもともとの膨大な断片的情報に構造を作り出していく手法です。

このKJ法を考案した川喜田二郎は，『発想法』（注8）をベースに多くの人にKJ法を教えた結果，個々の現場での観察と記録が鋭いかどうかがKJ法の死活を決める，と考えました（注9）。

「アイデアを出す」と言うと，ついつい頭から外に出すことをイメージしがちです。しかしそれでは，今あなたが持っている「思い込み」に基づいて考えることになります。それを避けるには，解決したい問題に関係あるかもしれないことを頭の外から収集するフェーズが必要です。

川喜田二郎は，実験科学的に仮説を検証するフェーズの前に，「野外科学」という情報を収集し仮説を立てるフィールドワーク的なフェーズが必要と主張しました（注10）。KJ法はその野外科学の方法論です。収集した情報を，一度に思考のまな板に乗せることができる「小さなグループ」にすることで，そこから新しいアイデアが生まれる，という方法です（注11）。

注8）

川喜田二郎著『発想法─⁠─創造性開発のために』中央公論新社，1967年

注9）

川喜田二郎著『⁠「⁠知」の探検学─⁠─取材から創造へ』講談社，1977年，p.24

注10）

『発想法』p.16

注11）

『発想法』p.105

小チームから大チームへ

川喜田二郎がKJ法の解説で強調したことの一つに「小さなグループから大きなグループへ」というボトムアップな流れがあります。

「これらの情報をこういう分類で仕分けよう」と先にカテゴリを決めて，そのカテゴリに合わせて情報を分類してはいけません。なぜかと言うと，それではせっかく集めた情報を無視して「自分の脳内の思い込みに基づく枠組み」を作り，集めた情報をその枠にはめ込んでいるだけになるからです。それでは，思い込みの枠を壊すような発想は生まれてきません（注12）。

注12）

『発想法』p.77

量にフォーカス

Osbornは「判断力はアイデアを殺すことがある」と述べ，殺される前に紙に書くことが重要だと考えました。川喜田二郎は，ある情報がテーマと関係あるかどうかはあとから明らかになるものなので，情報収集の段階では「関係あるかもしれない」ものを何でも収集すべきだ，と述べました。ブレストやKJ法のアイデア書き出 しの段階で，アイデアの質を求めるのは間違いです。

また「良いアイデアを出す」というゴールは，努力をしてもゴールに近付いたかどうかがわかりにくいです。これではマラソンでどこにゴールがあるかわからないようなもので，モチベーションを保つのが難しくなってしまいます。なのでまずは「アイデアを100個書く」などの量で測れるゴールを設定するべきです。これならば，1枚書くたびにゴールに向けて1歩進みます。あとどれくらい進めばゴールインなのかも明確です。

完璧主義はアウトプットの邪魔

この「とにかく100個アイデアを書く」という課題で，最初の1個が書けないで長時間悩んでしまう人もいます。最初から質の高いものを書こうとするとこうなりがちです。

重要なのは，最初のリリースでの完成度ではありません。すばやくフィードバックを得て改善することです。Thomas Edisonは「発明とは一時に完全な形で現れるものだと思っている人が多いが，そんなものではないのだ」と語っています（注13）。

今やろうとしていることは「0→1」です。改善のサイクルを回してより良いものにしていく作業は，0→1が終わったあとにやることです。このフェーズではまずは質を度外視し，とにかく数をたくさん出すことを目指すのです。

注13）

『新装版　創造力を生かす』p.256

リスクを恐れずリリースしよう

前回と関連する話ですが，失敗のリスクを恐れてアイデアをアウトプットしなければ，それに対するフィードバックは得られません。学びを得たければ恐れずに進むことが必要です。成功しても失敗しても学びがありますが，アウトプットしなかった人には学びはないのです。

リーンスタートアップは，顧客がいるかどうかもわからないサービスの完成度を上げることに時間を使うことを批判しました。そうではなく，顧客がいるかどうかを検証するための最小限の製品をリリースし，そこからすばやく学ぶことを重視しました。

リーンスタートアップはベンチャーの経営に関する手法ですが，エンジニア個人の経営についても似た構図があるでしょう。速やかに学ぶためには，すばやいリリースが必要なのです。