(theme)-(myname).md として書く私が 発想法（Creative Thinking Methods） と呼ぶ営みがあります。手法としてはブレインストーミング、ツールとしては Miro が有名ですが、まずアイデアをたくさん出して、それを整理しつつも、さらに出していって、最後には本質や結論を導く――そのような営みです。
現代は VUCA であり、変化が激しくて正解もない時代です。そんな時代だからこそ、自分は何ができるのか、何をするべきなのか、何がしたいのか、今何をして何を捨てるべきなのかといったことを自分で考えねばなりません。考えるためには情報が必要で、人間の頭だけでは扱える情報量は限られています。だからこそ発想法が役に立ちます。
また、エンジニアの皆さんは普段設計をしたり、チームのビジョンや戦略を検討したりするのに苦戦しているかと思います。ただのコミュニケーションでは歯が立ちません。ここでも発想法が重要になってきます。
まずは情報です。とにかく各自が持つ情報――知識も、制約も、アイデアや意見も、何でもたくさん出すのです。話はそれからです。逆を言えば、出しさえすれば、あとは整理と取捨選択の問題ですからどうとでもなります。
このような営みを体系的に行うのが発想法です。エンジニアにも、いいえ、創造的なエンジニアだからこそ重要なスキルです。
このジャンルの鉄板は、アナログにはホワイトボードや付箋、デジタルには Miro です。
しかしエンジニアにとっては、どちらもやりづらいものです。エンジニアは聞いたり話したりすることよりも、読み書きの方がはるかに慣れています。また、情報はプレーンテキストで残さないと、あとで利活用しづらいことも知っています。
というわけで、エンジニアの皆さんにも合った手法を今回開発しました！
GitHub を使って、プレーンテキストベースで、各自のローカル環境で発想法を行う手法をご紹介します。
三つのフェーズに分かれます。
発散フェーズでは、各自の意見を集めます。n 人いるなら n 人分の意見が集まるはずです。この時点では整理や選択は行わず、各自に任せます。たくさんの意見が出ると思います。
収束フェーズでは、発散フェーズで出した意見を整理していきます。似た意見を固めたり、構造化したりします。無理に綺麗に整える必要はなくて、皆にとって理解しやすい整理ができればそれでいいです。ベストエフォートで構いません。また、この段階で、さらに意見が思いつくことも多いので、引き続き出しても構いません（つまり 発散フェーズと行き来します ）。
最後、蒸留フェーズでは何らかの本質または結論を出します。文書 1 ページ未満の文章で書きます。行動を伴わせたいならタスクリストも書きましょう。
*view* を追加してください(theme)-(myname).md として書いてくださいview を含めてください（つまりバージョン管理の対象外にします）つまり、リポジトリには (theme)-james.md、(theme)-mary.md のようなファイルが並んでいくことになります。テーマ、もっというとお題に対する各自の意見が存在しています。
ファイル名として分かれているので、Conflict の恐れはなく、git pull でガンガン取り込んでください。それをローカルで眺めつつ、さらに思いついた意見を追加していきます。
たとえば James が「ミーティングの頻度について」を議論したくて、meeting_frequency_james.md をつくります。他の人、たとえば Mary は、pull したときにこのファイルが取り込まれます。James の内容を見て、意見があれば meeting_frequency_mary.md をつくって push します。
このようにしてお題ごとの意見が貯まっていくので、スクリプトなり生成 AI なりに頼ってビューをつくりましょう。たとえば James は単純なマージスクリプトをつくって、meeting_frequency_view.md を生成させています。Mary は Cline を使って meeting_frequency_summarize_view.md をつくっています。いずれにせよ、ファイル名に view の文字が入っているのでバージョン管理はされません。
今回は割愛します。本記事では、最も重要な発散フェーズに絞って解説したかったからです。
収束フェーズのやり方は様々です。最近ですと、Claude Code でも Codex でも何でもいいですが、AI エージェントに任せて収束してもらったものをインプットにして、人間がミーティングをして蒸留するのが潮流だと思います。
一方で、私のようなナレジャーは、まさに収束や蒸留を生業としていますから、時間をかけて（もちろん生成AIの力も借りて）つくりこんでいきます。プロジェクトや仕事にもよりますが、100 時間以上かけることもあります。
いずれにせよ、発散フェーズによって情報が出揃っているので、どうとでもなるわけです。最も重要なのは発散フェーズであり、各自が出し切った意見の集まりなのです！
GitHub を用いた発想法、特に発散フェーズのやり方をご紹介しました。また発想法そのものの概要と意義も解説しました。
発想法はエンジニアの間でも軽視されており、これができないせいで苦戦をする人をよく見かけます。特にエンジニアリングマネージャーやスタッフエンジニアといった上位職の人は、これができるかどうかで全然違います。私は必須のスキルとさえ考えます。ぜひ練習して、ものにしてください！
それではまた。