世界トップクラスの開発エンジニアたちは、複雑な巨大システムをどのように理解し、記憶しているのだろう？ 米マイクロソフトの現役エンジニア・牛尾剛さんがインターナショナルチームで学んだ「頭の使い方」の極意について解説します。

※本稿は牛尾氏の8万部突破のベストセラー『世界一流エンジニアの思考法』から一部抜粋したものです。

◆◆◆

驚くほど細かいところまで「仕組み」を理解している同僚たち

　エキスパートに気軽にものを聞ける文化は、生産性向上のための重要なファクターだ。

　社内では一緒に働いている人に、自分へのフィードバックをお願いすることができるが、技術イケメンのジョンにフィードバックをお願いしたらこんな言葉が返ってきた。

「自分や、ドメインエキスパートに対して質問するのを恐れないように ！　エンジニアがより賢くなるのはチームの幸せにつながるよ」

　どれぐらいのタイミングで質問に答えてくれるかは人によって様々だが、ジョンは大抵ものすごく早く丁寧な回答をしてくれる。困ったときによく彼に質問をしていたが、彼からするとまだまだ自分は遠慮しているらしい。

　今まで私は、ある程度調べて考えたうえで、ブロックされた場合に人に聞くという行動様式をとっていた。人に安易に聞くことへの日本人特有の抵抗感があったのかもしれない。でもこのやり方は、今から振り返るとチームの生産性の面ではあまり良くなかったようだ。

　よく考えてみれば、私たちがやっているような巨大なシステムの場合、一人の頭だけで簡単に理解できるものではない。いろいろなマイクロサービスが複雑に絡み合っているので、それらを全部知っている人など存在しない。

　しかし同僚たちは驚くほど細かいところまで仕組みを把握し、記憶している。スキップマネージャのアニルーダに「どうしてそんなに多くのことを把握できるのか？」と尋ねたら、彼は「メンタルモデルをつくるとそれができるようになる」と教えてくれた。そして勧められたのが、ガブリエル・ワインバーグ著『超一流が実践する思考法を世界中から集めて一冊にまとめてみた。』（SBクリエイティブ）だ。本書では、世界中のいろいろな分野から集められた思考のフレームワークが紹介されている。

頭の中に「メンタルモデル」をつくる

　メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論のことだ。チームメイトは「メンタルモデル」という言葉を頻繁に使うが、頭の中で素早く情報処理をするために、何らかの脳内イメージをもっていることが非常に有効なのだ。

　例えばMVP（ Minimum Viable Product 実用最小限の試作品）はソフトウェアの世界では常識的な考え方だが、どんなに最良のものと思ってつくっていても試作品を世に送り出してフィードバックを受け取ってから改良を重ねる必要がある。だからそれまでは絶対に製品をつくりこまずに実用最小限のベレルに抑えた試作品にしておくべき、という考え方だ。

　そうしたフレームワークは、自分の思考の偏りをなくしたり、幅を広げるきっかけになるだろう。

　私の場合、「システム思考」というフレームワークを独自にアレンジしたものを採用している。つまり、ソフトウェアのアーキテクチャ、クラスの構造、ソフトウェアのどういったパーツがどこにあるか、システム全体を先に把握してから、部分の状況や相互作用を考慮に入れていく。全体の関係性、フローをビジュアル図としてイメージし、各パートの関係性をあてはめていく思考法だ（図参照）。

　もともとは、新しいコードベースに挑戦するとき、変更や機能追加する限られた範囲を理解するために1週間以上費やしていた。知らなかったことを調べ、コンテキストを理解するには時間がかかる。ところが、一旦そういったものが頭に入ってシステム思考ができると、脳内でソフトウェアの動作イメージを素早くクリアに構築できるようになった。つまり、一番大変なのは、頭の中に「メンタルモデル」をつくる行為だ。

問題発見に至るプロセスが大幅に高速化

　これがあると、問題が発生したときでも、頭にソフトウェアの動作イメージを思い浮かべて、どこでなぜ問題が起こったのかを想像しやすくなり、ソフトウェアの追加や新規作成も劇的にスピードアップするのだ。

　紹介したのは、私がソフトウェアを開発・保守するときのイメージ法だが、あるいは「なぜなぜ分析」という方法を聞いたことがないだろうか？　これはトヨタの生産現場から生まれたもので、問題を発見したら「なぜ」を5回繰り返して、根本原因をあぶり出していく手法として有名だ。

　自分の業種・業態に合った思考の枠組みを学んだり、経験したりして、自分なりの脳内イメージをつくり上げることができれば、頭の中で考えを整理したり、問題発見に至るプロセスが大幅に高速化する。「メンタルモデル」は固定的な型があるというよりは、本当に人それぞれだ。ここで挙げた例を参考に、自分の仕事に特化した形でアレンジし、思考の枠組みを時間をかけて練り上げるとよい。ホワイトカラーの仕事の場合、仕事の9割は考えることなので、この効果は相当に高いだろう。

速攻でエキスパートに頼る！

　私がメンタルモデルを構築するにあたっては、ジョンのアドバイスどおり、わからないことをエキスパートに聞くのがもっとも速くて合理的だった。

　あるとき、自分が未経験の部分に関してのコード変更の必要性が生じた。いつもだったら、ある程度リポジトリ（プログラムの保管場所）を自分なりに読んでみて、ドキュメントを探すところだが、速攻でエキスパートに聞いてみた。

「この部分をこう変えたいんだけど、Pull Request とかない？」

　Pull Request とは、自分が書いたコードを誰かがレビューして、それが承認されたらその変更分が統合される仕組みのことだが、私は回答を待っている間、全く別のタスクを進めていた。自分のマネージャのプラグナから「知らないことで時間を2時間以上使ったりブロックされた場合は、それをボックスに入れて、また後で取り出すようにしたらいいよ」と言われていたから。

　つまり、一つのことで2時間以上ブロックされたなら、質問するなり相談するなりして寝かせておいて、他の仕事をやっておく方が断然生産性が高い。

　今までだったら、回答を待つ間、その作業のためのコード調査などをしていたところだが、自分でやっても無駄と考え、エキスパートの助言が来るまで他の作業をやっていた。

　数時間後に、エキスパートのグレナが回答をくれた。過去の似たPull Request を送ってくれただけではなく、この変更をする場合は、こういう場面に注意してというパーフェクトなアドバイスまでつけて。

　もし、これを自分で試行錯誤していたらどうだっただろう？　そのコードにたどり着くまで相当時間がかかるし、最初から適切な変更ができたかわからない。

「ググれ、カス」は効率が悪い

　結局私は、非常に有効なアドバイスのおかげで、全く知らない部分だったが2～3時間でPull Request をつくることができた。きちんと理解しながらやっているので、この種の変更に対する「メンタルモデル」も形成された。

　とくに既存システムがある場合は、あれこれ考えて調べる前に、まず「エキスパートに頼る」というのはベストプラクティスだと思う。

　日本は、「ググれ、カス」という言葉があるぐらい、自分で調べてから人に聞くべきという文化だが、少なくとも私のやっているクラウドの中身をつくるような複雑なシステムの場合、どう考えても全体的効率が悪い。

　仕事のパフォーマンスを上げるには、いかに「無駄なこと」をしないかに尽きる。エキスパートから情報がシェアされ、そのレベルから理解するフェーズに入れば、しっかりと肝心なことにフォーカスができる。

「思考の習慣」で、“できない感”から脱却できた

　ここまで伝えてきたことは特殊なスキルではない。誰もがアクセスできる基礎は、じっくりと時間をかければ、深く理解できる。やろうと思えばすぐにできるシンプルなことだ。

　長年、私はどうやったら自分の「できない感」から脱却できるか、ずっと解答を探し続けてきた。ソフトウェア業界にいて、同僚たちと比べて自分は頭が悪いと思っていたし、どんなに努力して時間とお金をつぎ込んでも、なかなか「できる」感覚が得られなかった。「仕事をコントロールできている」手応えもなかった。

　だが、不全感をつくり出していた根本的な要因は、頭ではなく「思考の習慣」にあった。プログラミングもギターも、「早く成果が欲しくて」、目先の結果を求めて頑張ってはかえってできなくなっていたのだ。

　どんな人も、最初は難しく、理解には時間がかかるという真実――その本質的な気づきは、最後のワンピースとなって、私が人生で心から欲しかったものを与えてくれた。

　自分が仕事をコントロールできているという感覚、何かわからないことがあっても「自分ならやれる」と思える感覚だ。半世紀以上あがいて求め続けてきたものが、アメリカで手に入るとは思いもよらなかった。

　好ましい変化はプログラミング技術以外にも訪れた。私生活においても「頭が悪いから仕方がないか」といろいろな理解をあきらめていた。でも時間をかけて理解する習慣が身についたことで、人生の様々な小さなことを「コントロールできている」感を得ることができ、「自分ならできる」という安心感も生まれてきた。

　結局のところ、シンプルな日々の積み重ねが一番強い。

　eXtreme Programming を開発した、かのケント・ベックは言った。

「私は偉大なプログラマではなく、偉大な習慣を身につけたプログラマだ」と。