ハンモック駆動開発のススメ
今あえてコンピューターから離れることの価値
AIによってエンジニアの生産性はかつてないほど高まっています。
筆者も最近はCline等を利用してプログラミングに勤しんでいますが、自身で手を動かす機会が格段に減り、優雅にコーヒーを片手にディスプレイを眺めることが増えて隔世の感があります。
既に方々で言われていることですが、ほとんどあらゆる作業にAIが介在するようになって何かを実現するためのコストが劇的に下がる中で、どんな問題を解決するか考えることの価値が相対的に上がっているように思います。
そこで思い出したのが、かつてClojureの開発者Rich Hickey氏が行ったハンモック駆動開発(Hammock Driven Development)についての講演です。
内容を端的に言うと、重要な問題を解決するためのTipsがまとまったものと言えます。
この講演は2010年のものですが、私自身今でも非常に影響を受けていますし、今その内容はより重要度を増していると思うので、その内容について重要箇所を抜粋しつつ簡単に紹介しようと思います。
内容の翻訳、掲載及び画像の利用にあたってRich Hickey氏にコンタクトしたところ快諾いただけました。ありがとうございます。
「ハンモック」という言葉が使われている背景には、重要な問題について本当に集中して考えるためにはコンピュータから離れて誰にも邪魔されない環境に身を置く必要がある、というRich Hickey氏の考え方があります。詳細については後に触れます。
講演の主旨は以下のようなところです。
- 開発の目的は機能を作ることではなく、問題を解決すること
- 解決すべき問題を特定することはおざなりになりがち。逃げずに明確に特定すること
- 特定した問題を解決するスキル、テクニックは実践によって身に付く
- 実践のためには脳の二種類のモード(「覚醒した意識(Waking Mind)」、「背景の意識(Background Mind)」)を使うことが重要
- 実践を繰り返すことで未知の問題にも自信を持って取り組めるようになる
- 一方で、どれだけ徹底的に実践しても前提となる事実を見落としたり要件が変わったりすることはある。その時は変に構えずにただ考え直せば良い
本人はいかなる類の科学でもないと言っていますが、脳科学、心理学的にも興味深いテーマだと思います。
これはAI時代を生きる自分自身に向けたポエムでもありますが、読者の方がAI時代のプログラマがどうあるべきか考える一助となれば幸いです。
集中して考えること、自信を持つこと
何かについて、誰にも邪魔されずに1時間考えたことはありますか？1日は？1ヶ月、一年ならどうでしょう？もしそれらができるなら、それは本当にかけがえのない時間だと思います。
もう一つ質問したいのは、新しく挑戦する際に自信を持って臨めたのはいつが最後だったか、ということです。その種のことに自信を持つためには何が必要だと思いますか？
Bugs(バグ)
- バグのコストが最も安く済むのは設計段階で気付けた場合
- ソフトウェアの問題の多くは誤解が原因
- テストや型システムでは誤解に由来する問題に対処できないし、そもそものアイディアが間違っている場合にそれを教えてくれない
最も安くバグを修正できるのは、ソフトウェアの設計段階です。…これ、みなさんやってます？（うん、という声が聞こえましたね）私がここで強く主張したいのは、ソフトウェアの「大きな問題」の多くは「誤解」が原因だということ。実装上の不具合ではなく、そもそも正しく問題を理解していないまま突っ走るから起きる。仕様を勘違いして実装してしまい、その後にどれだけプラクティスを駆使しても、誤解したまま進めばうまくいきません。テストや型システムは、実装面のバグ検出には有用ですが、「そもそも発想やアイデアが間違っている」といった問題までは指摘してくれません。
Analysis and Design(分析と設計)
- 手を動かす前に問題を特定することと考えたソリューションが問題を解決するか評価する
実装前の段階(=分析と設計)に十分に時間をかけないと最終的な品質に悪影響が出ます。
分析と設計は二つの事柄を指します。解こうとしている問題を特定することと、考え出したソリューションがその問題を解決するかを評価することです。それこそが本質です。私たちは問題を解くべきなのです。機能(feature)を作るべきではないのです。
Solve Problem(問題を解く)
- 機能リストを完成させる ≠ 問題を解く
プログラミング、ソフトウェアを書くことは機能(feature)リストを完成させることではない。特にユーザーが欲しがる機能は、彼らがどんなに自分たちにとって良いと思っても必ずしも良いアイディアとは限りません。問題を深く掘り下げて理解し、最善のソリューションを見極めた上で、ユーザーが求めていることと擦り合わせる必要があります。
問題を回避するのは我々エンジニアが得意とするところですが、、それは問題を解決することとは違います。我々は問題を解決することに真正面から取り組むべきなのです。今日私がお話ししたいのは問題解決に様々なテクニック、スキルがあるということです。そして、まずすべきなのは自分が取り組んでいる問題を理解し、認識し、特定して、どこかに書き留めて議論するように努めることです。
Problem Solving is a Skill(問題解決はスキル)
問題解決は間違いなくスキルです。この話を聞いて、世の中には問題解決が得意な人がいるからこの種の仕事は彼らに任せようとは思わないでほしいのです。問題解決スキルは実践によって身につけることができます。Polyaが1945年に「How to Solve It」(邦題: 「いかにして問題を解くか」)という素晴らしい本を書いていて、数学の問題を解くためのテクニックとそれらをいかに実践して身につけるかについて書かれています。素晴らしい本で、偉大な洞察に満ちています。
Practice(実践)
- 問題解決スキルは実践によって向上させられる
問題解決はスキルであり、実践によって向上させられるものです。取り組む価値はあります。人間は実践することで上達するからです。それが何であれ関係ありません。全く見込みがなさそうに見えたことでも実践し続けた結果上達した素晴らしい例はたくさんあります。もしあなたが問題解決について本気で実践すれば必ず上達するでしょう。もし特定の方法論Xについて実践すればXについて上達するでしょう。どこにレバレッジがあると思いますか？Xが何であれ構いません。あなたが望むXを見つけてください。それを上達させたいですか？あるいはもっと一般的な問題解決スキルを向上させたいですか？
State the Problem(問題を明確にする)
- 見過ごされがちだが、どんな問題を解決するか明確に言語化することが重要
まず最初に必要なのは、「自分はこの問題を解決しようとしている。問題は○○で、だから○○だ」ということを実際に口に出して言うことです。私は、これを誰も言わないまま作られたソフトウェアをたくさん見てきました。誰も問題を言語化せずに、システムだけが出来上がって、いったい何の問題を解決しようとしているのかが誰もわからない、という状態です。
もし問題を解決していないとすれば、私にはなぜ私たちがここにいるのかまったくわかりません。私たちは絶対に問題解決をしているべきなのです。そのためには、解決すべき問題を列挙しなければなりません。そして、これは後でも触れますが、精神的な観点からも、それを声に出すことが本当に大切です。問題を解決しようとしている人間として、声に出して言ってみる。グループの誰かと話し合って、「私たちはこれを解決する必要がある。問題は○○なんだ」と話をするのです。愚痴でもいいし、ただ話すだけでもいいし、それを書き留めてもいい。たとえば、初めて会った人の名前を覚えるために、その名前を繰り返して言うのと同じようなものです。これこそが問題解決の最初の種なのです。つまり、問題を明言することが大事なのです。
Understand the Problem(問題を理解する)
- 解こうとしている問題に関するファクトを集める
- まだわかっていないことがなんなのか理解する
- ある問題についての解決策は大抵他の誰かが考えている。無駄な努力をしないために既知のソリューションを調べる
「この問題があって、NoSQLデータベースが必要だと思うんです」と言われたら何かが抜け落ちてるような気になりますよね？この言い回しには「なぜそれが必要か」という観点が抜け落ちています。その問題のどんな特性が我々を特定の解決策に導いているのでしょうか？私はここにこそソフトウェア開発における興味深い仕事が存在していると思います。
最初のステップとして、自分がやろうとしていることについてどんな事実を把握しているでしょうか？必ず何かしらのファクトがあるはずです。顧客からの要求かもしれませんし他の何かかもしれません。文脈としてこのシステムはこのマシン上で動かす必要があって、これぐらい稼働させる必要があって、消費電力はこれ以上はダメで、1000万人のユーザーをサポートする必要がある、といったことです。
自分にはこれがわかっていない、という事柄もあるはずです。こいつのインプットにするデータをどこからとってくるんだろう？システムのメインデータソースが利用できないときに何をすべきだろう？といったことです。もちろん、自分が何がわからないかがわからないというケースもありえます。これらは仕方のないことですが、もしわからないことがあるのであれば、それらについて一度考えてみるべきです。もう一つ重要なのは、よくある話として多くの人が「Xについてのすごく良いアイディアがあるから試してみるといいよ」と、さも自分だけがその問題に直面したことがあるかのように語る場合があるということです。しかし実際にはそんなことは滅多にないのです。同じ問題を解決しようとした事例を探してください。他に何か知っていることはありませんか？それらがどういうふうに解決されたのか何か情報を得られませんか？なぜなら、問題に対する他の解決策を見るのが最も素早く状況を理解し、その問題における既知の最善のソリューションを超えるための近道だからです。あなたのすべきことはそこからインクリメンタルに歩みを進めることです。でも、もしこれまでの前任者の歩みを無視するのであれば、自分でゼロから始めることになります。絶対に問題の周辺についてリサーチすべきです。
Be Discerning(見る目を養う)
- 自分の取り組んでいること、特に解決策について批判的になる
- 欠陥を見つけたらなるべく早い段階で解消する
- トレードオフがないソリューションは滅多にない
- わかっていないことがあるならそれを明らかにするための問いを立てる
他にすべきなのは判断力を鍛えることです。批判的である必要があります。我々はコミュニティの中にいて、「素晴らしい」、「すごいことになるぞ」といった言葉を1日に50回は聞きます。ですが全てが素晴らしいということはありません。他人のしていることに対して素晴らしくないというのは難しいので、まずは自分が取り組んでいることに目を向けましょう。
特に、問題の解決策を見つけようとしている時は自分の解決策に欠陥がないか探してみてください。このことだけで一つの講演が成り立つぐらいです。それは技術的な誤りかもしれないし、ロジックの誤りかもしれません。センスや判断、抽象化の誤りといったことがあり得ます。問題がなんであれなるべく早い段階で解消するように努めてください。
また、「こうしよう」、「NoSQLを使おう」、「いいね、10個も特徴がある、素晴らしい」といった形で自分の取り組んでいることの良い面について盛り上がるのは簡単です。ですがトレードオフを考えるべきです。トレードオフが存在しないソリューションは滅多にありません。
他に重要なのは、先ほどもお伝えした「自分が何を知らないか」という点です。知らないとわかっていることがあるならそれを明らかにするために立てるべき問いがあるはずです。我々は全てを知っているわけではないので何かを利用する場合には何かしらの疑問符が付くはずです。それらを書き残してください。全く疑問符がつかなければ何かを見落としているかもしれません。
More Input, Better Output(インプットを増やせばアウトプットの品質が高まる)
- 多角的なインプットがアウトプットの品質を高める
- 論文などは仮に一部しか理解できなくても発想を広げるのに大いに役立つ
- 他のアイディアを調べる時は徹底的に批判的になるべき。そこから見つかるインプットもある
他のこととして、私たちは誰も、生まれつきソフトウェアの書き方を知っているわけではないということがあります。SQLの書き方やWebの特性、プロトコルについてなどを生まれながらに知っている人はいません。とりわけ、今まで取り組んだことのない領域で問題を解決しようとしている場合、十分なインプットがなければソリューションを考え出す能力はかなり制限されてしまいます。様々な情報を行ったり来たりしながら「ああ、このアイディアとあのアイディアは関連してる。それなら、こういうアプローチも取れるかもしれない」と考えられるようにするには多角的なインプットが必要になります。
もし「今やっていることだけをとりあえず考えて、来週までに完成させる」といったごく狭い視野でしか考えないのであれば、意思決定をするための十分なインプットを集めることはできません。なので自分が取り組んでいる分野について広範にも、極めて専門的にもインプットを集めることが重要です。全く同じ問題に取り組んでいる人がいないか、他の特徴的な問題はないかといった具合にです。関連する論文を探して読んでみるのも良いと思います。ACM(Association for Computer Machinery)のようなところで論文を探してみると本当に面白い発見があります。「こういうことができるハッシュコードはないだろうか」と思ったら「〇〇が可能なハッシュコード」といった形で検索してみます。もし関連する論文が見つかったら読んでみてください。仮にごく一部しか理解できなかったとしても問題を考える力をつける上で役立つはずです。
それから、他の人には言わないとしても他の解決策を調べる際には徹底的に批判的になるべきです。既存のアイディアを徹底的にこき下ろすことでベストなアイディアが見つかるなんてことが、どれだけ多いかわかりません。少なくともあなたの頭の中だけでも良いのでアイディアを解体してみてください。解体することでその人が問題に取り組んだときに書き留めなkったポイントが明らかになります。
Tradeoffs(トレードオフ)
- ある問題についての解決策は少なくとも二つ用意して、それらの良い面、悪い面を理解する
誰もが設計とはトレードオフの問題だ、と言います。誰もが知っていることだと思います。トレードオフについての話をする時、人は自分のソフトウェアの良くない(suck)部分について語りがちです。このトレードオフを飲まないと行けなかったんだ、と。これは本来のトレードオフの意味するところとは違いますよね？
「トレードオフを考慮した」と言うためには少なくとも二つの解決策を用意して、それらの良い点、悪い点を理解する必要があります。是非そうすることをおすすめします。そしてその過程で明らかになった事をどこかに書き留めておくと良いと思います。
Focus(集中)
- 深く集中するためにはコンピューターから離れる必要がある
実践面についてもう少し話しましょう。この作業を進める上で重要なのは集中力を維持することです。
設計をする際には極度の集中力が求められると私は思います。ハンモックには面白い側面がいくつかあります。一つはハンモックに寝そべって目を閉じていると他の人はあなたが眠っているかもしれないと思って邪魔をしてきません。これはとても良い点だと思います。
一方でコンピューターは集中を妨げる最悪の要因です。我々のような人間にとっては特にです。考えようとしていることとは別のことが気になってしまいます。集中しようと思うならなんとしてもコンピューターから離れるべきです。コンピュータのー前に座りながら集中することは不可能に近いからです。
強く集中しようと思うなら犠牲にしなければいけないものもあります。ボールを落とす、つまり電話を折り返すことを忘れたりメールの返信を忘れたりカンファレンスの資料を空港で作ったり、といったことです。でもそれはそういうものなんです(That's just the game)。
とはいえ、大切に思う人がいるならその人にはこのプロセスについて説明しておきましょう。集中している間、自分がかなり遠くに行ってしまっているように見えるかもしれないが、それは相手を疎かにしているのではなくこの種の作業をするときに避けて通れないことなんだと伝えておくんです。
ほとんどの人は一日中、あるいは一週間まるまるこの種の集中状態を続ける時間は取れないと思います。集中する時間を取ろうとするならしっかりそれを設定しましょう。子供がtime-outするように。プログラマーにもこの種の集中のための時間が必要です。ハンモックに寝そべって誰からも話しかけられないようにする時間が。
Waking Mind(覚醒した意識)
- 問題解決には「覚醒した意識」と「背景の意識」が関係している
- 「覚醒した意識」は分析的、批判的、戦術的な思考に非常に長けている
- 局所最適を見つけることには非常に長けているが、全体最適を見つけることは得意とはいえない
- 問題をうまく解決するには「背景の意識」もうまく使うことが必要
私個人としてはこのプロセスには「覚醒した意識」と「背景の意識」の二つが関係していると思っています。様々な本などにも書かれていることです。私自身はそれらを読んだわけではありませんが、私の個人的な経験とも合致しているように思います。
「覚醒した意識」は批判的な作業に非常に長けています。極めて分析的で、戦術的に考えるのが得意です。「今すぐ決断しないといけない。ライオンが追いかけてきているから左にジャンプしよう」といった具体にです。我々はその種の判断が本当に得意です。それが我々を目の前の情報を処理し短期間での意思決定を可能にして我々を生きながらえさせる「覚醒した意識」です。
ですが、問題を始めて見た際に、コンピュータの画面を見つめたり、誰かと10分ほど会話しただけで素晴らしい決断が下せるのか、というと私は違うと思います。私には無理です。全く無理だと思います。この「覚醒した意識」は「左と右の選択肢がある、まずは右に行って高く登ろう、その次は左」といった具体に局所最適を探すことには非常に長けています。ですが、今たどっている道から外れてもっと高く登れる山を探す、といったことは得意とは言えません。
あなたの脳をフルに使って問題を上手く解決しようと思うなら、起きている間に「背景の意識」にタスクを与えることが極めて重要になると思います。何かを深く考えて、「背景の意識」のための仕事を作り出すのです。これこそが、ハンモックに寝そべることや、起きている間にリストを作ることや色々な作業を行うことの狙いです。これらによって残り半分の脳に仕事を割り当てることができます。また、「覚醒した意識」は「背景の意識」が思いついたアイディアを批判的に検証できるという利点があります。「起きた時には最高のアイディアだと思ったけど、こういう特徴が見えてきたぞ。あまり良いアイディアとは言えなさそうだ」といった形です。
Background Mind(背景の意識)
- 「背景の意識」は情報の統合や戦略的思考に長けている
- ソフトウェアの適切な抽象化などを行いたいのであればこのための時間を確保する
「背景の意識」について話しましょう。眠っている時の意識がこれとイコールだとは言いませんが、睡眠時の意識は「背景の意識」の典型的な例です。起きている間でも「背景の意識」にアクセスすることはできますが、難しいです。「背景の意識」は物事のつながりを作り出すのが得意です。例えば、泥で小屋を作ったとしたらひどい雨が降れば壊れてしまう、といったことです。この種のことは細かく筋道を立てて考えずとも「背景の意識」が様々なコンポーネントが持つ側面を理解して、つながりを見つけて統合することによって結論を導いてくれます。あなたが瞬発的に良い判断をしていると思った時でも、実際は「背景の意識」が先に組み立てていたものを表に出しているだけだったりします。「背景の意識」は情報を統合することや戦略的な思考が得意なんです。
マークが言及した抽象化などは、まさにソフトウェアの戦略についての話です。まだ詳細な戦術的なレベルでの意思決定が難しい状況で広い視野から正しい判断を下す必要があるような状況です。
それがどう使われるか全くわからない段階で、ある機能をプログラミング言語に組み込むというのはどういうことなのでしょう。これは、より戦略的(strategic)な発想が必要になる作業です。プログラミング言語を構築する際に「この言語ではHTTPリクエストをどう扱うのだろう？」と最初から具体的に考えるわけではありません。それよりもむしろ、マークがHTTPリクエストについて戦術的(tactical)な意思決定をするときに使える仕組みを提供したいわけです。それこそが戦略的な思考です。
我々の「背景の意識」はこの種の戦略的な発想に長けています。もし抽象化を行いたいのであれば、この戦略的思考を行うための時間を確保しなければいけません。「背景の意識」は抽象化を行い、類推するのです。ほとんどの非自明な問題は「背景の意識」によって解決されると思います。その場その場で良い決断を下すことはもちろん可能ですが、本当に難しい問題を解決したいのであれば、残りの半分の脳を働かせる必要があります。そして、これは単に私が言っているというだけではありません。
Scientific American Said(サイエンティフィックアメリカン曰く)
- 起きている間に問題を軽く考えた程度で、「背景の意識」が問題を解決してくれることはない
- 「背景の意識」が重要だと捉えるまで「覚醒した意識」で徹底的に考える必要がある
Scientific American曰く、人間は睡眠中に日中の情報を処理しているというのは極めて明白です。睡眠は記憶を強化してくれますし、さらに重要なのは、情報の整理をしてくれる点です。私は先ほど、問題についての要求分析をしたり様々な調査をしたり、他のソリューションを研究したり批判的に検証したりして多くのインプットを取り入れよう、とお伝えしました。これらの情報のうち何が重要で何がそうでないか、我々はいつ判断するのでしょうか？寝ている間です。人間は進化によってこの問題を解決できるようになったわけですから、利用しないわけにはいきません。
そして一番重要なのが、隠れた関係性を見出して取り組んでいた問題を解決する、という点です。ただ、誰かが「こんな問題があってね」と言ってきたとして、あなたはその問題について10分ほど考えて「OK、映画でも見て、適当にぶらぶらしてくるよ」と言ってその後眠りに落ちたとして問題は解決できるでしょうか？そういうことにはなりません。その場合、あなたは起きている間にその問題について、寝ている間のあなたの意識が重要だと捉えるほど集中して考えてはいませんよね。ここで「背景の意識」にタスクを与えるという話に戻ってきます。起きている間に解決したい問題についてあなたの「背景の意識」にとってのアジェンダとなるように集中して考える必要があります。これが秘訣なんです。
例えば原始人が「食料をどうやって手に入れようか？あの辺でヘラジカを見かけたな。水辺のあたりにもいた気がするぞ」と考えた翌朝「よし、水辺に狩りをしよう」と思いつくとします。その結論は「覚醒した意識」が分析した結果のように見えるかもしれません。しかしこれは論理的な推論というよりも「背景の意識」が並列に動作した結果によるところなのです。この仕組みがとても重要なわけです。
Loading it Up(ロード中)
- 人間のワーキングメモリーには限界がある(7±2)
- 事前に書き出しておくなど外部記憶を活用すれば、問題について必要な情報を漏れなく考慮できる
- インプットを完全に遮断して今まで得た情報について考えを巡らせることが「背景の意識」にタスクを与えるために極めて重要
問題があります。我々が作るソフトウェアへの要求は時を経るごとにより複雑なものになってきています。しかし私たちのワーキングメモリーの限界は7±2程度と言われています。なのに我々が解くべき問題はそれよりはるかに大きい。頭の中で全体を同時に把握できないとしたら、どうやって9個以上のコンポーネントで構成される問題に取り組めば良いのでしょうか？
私がおすすめしたいのは問題に関するすべての情報を書き出すことです。これまでにお話してきたプロセスの中であなたは問題についてかなりの情報を書きとどめているはずです。問題が一体どんなもので、それに関連してどんな事実、制約があって、どんな環境で動作するかと言ったことを自身に問いかけ、書き留めてきたと思います。「別のソリューションはこの部分は素晴らしいけどこっちは微妙だな、無いほうがいい」といった形で、です。そうやって大量のアジェンダをあなたの「背景の意識」に与えているのです。
これらの問題を脳内に再びロードするとき、あなたは調査(survey)をする必要があるわけですが、ここに前もって全てを書き出しておくことのポイントがあります。もしあなたが問題をどのように解決したいかといったことを含む全てを事前に書き出していれば、すぐにロードができて問題について様々な角度で考え始めることができます。
例えるなら、同時にいくつのボールをジャグリングできるか？というようなものです。7+2ぐらいなら可能かもしれません。でも、例えばアシスタントがいて、時々ジャグリングしているボールを取り出す代わりに別の色のボールを渡してくれるとしたら、あなたは同時に20個の異なる色のボールをジャグリングできることになります。
まさにそういうことをするわけです。その時々で任意の7つの方を頭の中に取り込むようなイメージです。場合によっては図を描きたくなるかもしれませんが、UMLを使う必要はありません。これは特定のメソッド論ではないです。何度も繰り返しやってみてください。そして再びコンピューターから離れましょう。もう一つの極めて重要なことが、どこかに座ってインプットを完全に遮断して目を閉じるが、寝ることはしない、という状態です。
目を閉じて何かを考える時どんなものが見えるでしょうか？奇妙な話で、中にはかなり鮮明に視覚的なものをイメージする人もいますが、それは厳密な意味で視覚的なものではないと思います。私に関して言えば...わかりません。うまく説明できませんが、あまり写実的じゃないイメージです。でもそれをする必要があるんです。あなたの脳を「入力待ち状態」から抜け出させるためです。何かのリストを見ている時あなたは「入力待ち状態」になっていますが、インプットを遮断して頭の中で何かをじっくり考えて整理しているときには、記憶を呼び起こして活用するモードに切り替わるのです。
先ほどお話したように例えば20個の要素を繰り返し見て、関連するインプットについても様々考えた後に目を閉じてそれらを思い出して考えようとすると、かなり大きな問題であっても、一度にひとつずつかもしれませんがその様々な部分を頭の中に呼び出しては戻すという形で考えられるようになります。
この種の実践は本当に重要です。なぜかはわかりませんが、この作業が確実に記憶の定着を促し、「背景の意識」にとって重要なアジェンダを作り出してくれるからです。我々はこれを「こころの目」と呼ぶことにします。
Wait for it...(待つ)
- 最良のアイディアを思いついたと思っても「背景の意識」のために一晩寝かせる
- 大きな問題についてはそれでも十分でない場合がある
- 複数のタスクがある場合は、1日の内でのマルチタスクはできるだけ避けてもう少し長いスパンで扱うようにする
- 行き詰まったら固執せず単に他のタスクに切り替える
ここまできたらもうケーキはオーブンの中にあります。あとは待つだけです。とても良い状態です。ただ、私が一つ言いたいのは少なくとも一晩は待つことが重要だということです。仲間内で「これは最高だ」と盛り上がっていても、とにかく一晩寝かせる。重要な意思決定なら尚更です。今朝目が覚めたときに何か重要な問題の解決策を思いついたという方はいらっしゃるでしょうか？ほら、そういうことなんです(訳注: 会場で手があがったと思われる)。これは科学です。科学が作用しているんです。もしあなたがこのことについて考えなければどんなことが起きると思いますか？「今日は本当によく働いた。仕事は終わりにしてリラックスしよう」といった具合に考えてしまうと思います。でも、私が今日話していることを信じるとすれば、実は寝ている間にも非常に重要なプロセスが進行しているわけです。なので時々は脳が別の役割を担えるようにしてあげる必要があります。このことを無視していると最良の結果は得られないと思います。
残念ながら一晩では足りない場合もあります。特に本当に優れた抽象化を見つけたり、いくつかの制約を同時に満たす必要があるような大きな問題については長い時間がかかります。そういうものです。もちろん誰でも締め切りがありますし、私の言ったことが当てはまらないことも多いと思います。でも私は、長い時間をとって問題を考えられるのは大きなチャンスだと思っています。その方がより良い回答を導けるからです。
とはいっても、「えー、3ヶ月考えさせてください」なんていってもほとんどのマネージャーは納得しないと思います。1日の内に複数の仕事を行うのではなく、もう少し長いスパンで複数のタスクを扱えば良いのです。基本的に1日1つのことに取り組むとしても、仮に3つプロジェクトがあるのであれば1つのプロジェクトを(脳内に)ロードしたら三日間続けるといったやり方も可能です。
問題が解決せず新しい可能性も見つけらず行き詰まったとしたら、別のプロジェクトに切り替えて数日作業してみてください。何かをロードするためには1時間から1日ほど必要です。それを終えたら少なくともその日残りを使うか三日間なりを使えば良い。行き詰まったとしてもその問題に固執しないでください。単に切り替えれば良いのです(Don't stay stuck. Switch)。あるいはそれについてのインプットをもっと集めたり、人に話してみるのも良いでしょう。とにかく頭を刺激し続ける必要があります。立ち止まらないようにしましょう。
Wake up Working(起きて働く)
- 「背景の意識」は直近取り組んでいたこととは別のタスクを解決してくれることがある
- 単に切り替えて利用するようにする
ついにケーキが焼きあがる瞬間がきます。朝目覚めたら素晴らしいアイディアや問題の解決策を思いついています。微妙なことに、今取り組んでいることとは別の問題についてのアイディアが浮かんでいることもあります。三つのプロジェクトに取り組んでいて、今取り組んでいるのはプロジェクトCなのに、Aについてのアイディアが思い浮かんでいた、といった具合です。それでも良いと思います。単に切り替えて利用しましょう。少なくとも書き留めてください。仮にその日に実行できないとしても「背景の意識」が生み出した結果を記録しておいてください。とても役に立つことになるので。
Try it(試す)
- 少ないコード量で実現できるアイディアは良いアイディアである可能性が高い
- ここまでのプロセスを実践することで新しい問題に取り組む際の自信が深まる
最後に、素晴らしいと思ったアイディアを検証するために、更なる分析か実際にコードを書くかすることが必要になります。最終的には我々皆がコードを書く必要がありますし、それは楽しいものです。Stuが私の設計メモを見て、「絶望の文書(document of despair)」とか何とか読んでいました。「これもダメ、あれもだめ」、「ここが怪しい」といった具合です。でもそういうものなんだと思います。ネガティブなことばかり書いてありますが、それはある問題を解決する時のチャレンジがどこにあるかということなんです。絶望しているわけではなく、「ここにチャレンジがあって、取り組める」とむしろ前向きなわけです。実際にそのアイディアを試す時にはとにかくたくさんのタイピングが必要な状況を避けるべきです。答え(となるコード)が小さいというのはそれが良いアイディアである可能性を示す、最も重要な特徴の一つだからです。
このプロセス全体を実践することで、これらが実際に役に立つと理解してそれを自信に繋げてほしいと思っています。
つまり「これは取り組んだことがなかったけど、集中して考えて一晩寝かせて出てきた解決策はすごく良い感じだ。よし、やってみよう」という形です。「こういう前提だと思ってたけど、そうじゃなかったこういう特性があると思ってたけど、違った」といった形で自分のしてきたことを捉え直して新たな発見をすることも重要です。私はウォーターフォールモデルを推奨しているわけではありません。何かを試して見て、場合によっては戻る、それで良いと思います。ただ、依存しないようにしてください。あまり良い例えが出てきませんが、「テスト駆動歯科治療」とかそんな感じのものです。あり得ないですよね。
You Will Be Wrong(人は間違う)
- 前提となる事実は変わる
- 重要な事実を見落とすこともあれば、要件が変わることもある
- 頑なになったり誰かに申し訳なく思ったりする必要はない。単にやり直せばいい
最後に、あなたは必ず間違います。私も頻繁に間違います。でも、それはそういうものです。あなたはもっと良いアイディアを思いつきますし、それはエキサイティングなことだと思います。過去にどんなアイディアを思いついていたとしても、いずれはもっと良いアイディアが浮かぶという事実は若干気が滅入ることだと思います。自分が最高のものではない何かを生み出してしまったと理解することになるからです。でもそれは我々が前進していて、このプロセスがまだ機能しているということでもあるのです。だからあなたはより良いアイディアを思いつくんです。
加えて、(前提となる)事実は変わります。理由は二つあります。一つは初期の段階で見落としていた事実に気づくケース。もう一つは要件が変わるケースです。これはみんな知っていますよね。事実は変わります。そういう時には頑なにならないでください。もう一度やり直してあなたの出した答えがその新しいコンテキストの中でまだ妥当であるか確認してください。もしそうでないなら、考え方を変えてください。謝る必要はありません。人は時に間違うものです。論理的な誤りや捉え違いをします。でもそれで良いんです。もし私が皆さんに強く勧めることがあるとすれば「恐れないこと」、特に「間違うことを恐れないこと」です。
終わりに
コードを書くことだけがプログラマの仕事ではないと思います。むしろ「どんな問題をどうやって解くか」考え抜くというところが我々が提供する価値の中心であるはずです。
その中で特定のツールの使い方ではなく、考え方、頭の使い方のようなところにフォーカスを当ててみるのも面白いのではないかと思いハンモック駆動開発について紹介してみました。
本記事が、読者の方々がAI時代をより楽しく過ごすための一助となれば幸いです。
(補足)ハンモック駆動開発に関連する脳科学、心理学的知見
出典
Step Away from the Computer or, Hammock-driven Development by Rich Hichey
Discussion