【書評】世界一流エンジニアの思考法
本日は「世界一流エンジニアの思考法」の書評を書いていきます。
社内でのおすすめもあり読了。
マイクロソフトでエンジニアとして活躍している著者の仕事術的な本です。
読んでて感じた事を自分自身のメモとして以下書いていきます。
本の内容で気になったこと
・本質思考
└根本の理解を重んじる。そこには時間を使う。そこで時間を使っても全体で見ると生産性が上がって、効率が良くなる。アウトカムを急ぐのではなく、本質的な理解を求める。シリコンバレーのどんな天才でも時間がかかることにはかかる。
→「「何かを早くできるように急ぐ努力」がかえって本質的な理解を遠ざけてしまうのだ。」はめちゃくちゃ刺さる。
→このあたりは自分と真逆の部分。行動から入って結果うまくいかない、みたいなことが多いので心してかかりたい。
・仮説思考
└結果が出る前になんでも仮説を持つ。
・検証思考
└ログを残しながら検証することを徹底する。感覚で検証しない。
→これも自分がやりがち。
自分は全体を俯瞰してさっと考えるのが得意なので、途中計算を省略するきらいがあるが、「感覚」でこれが問題だろうと決めつけてしまったのが今回のミスで、あくまでファクトを積み重ねるべきだったのだ。
・わからないことがあったらすぐ聞く
→当たり前だけど、今自分が新規事業で 不明点が多いのでビザスク等を活用しようと思っているためこの考えもピッタリだと思った。社外の人も積極的に頼っていく必要がある。
・Be Lazy
└優先順位を決めて他の事をやらない。2:8の2だけやるイメージ。「より少ない時間で価値を最大化させる」ということを全力でおこなう。「減らすこと自体に価値がある」という発想を持とう。
1.一つだけピックする。
2.時間を固定して、できることを最大化する
3.「準備」「持ち帰り」をやめてその場で解決する
4.物理的にやることを減らす
・失敗を許容する
→Fail fast。これも社内の評価制度と紐付けると良さそう。
・KPIを決め、マイクロマネジメントは行わない。
・楽に達成できる計画で仕事をする
└中長期的に見ると社員が疲弊するなどマネジメント効率が悪い。
→営業会社とかにありがち。社員を頑張らせるようなマネジメントをしにいって社内が病むとかあった。楽に達成できる計画と戦略を作るのが経営者の仕事。
・仕事を断る
→今うちの社内でも実証中。無理に案件を受けない。
・いかに脳みその負荷を減らすか
└簡単に仕事をこなせるようにするか。簡単なレベルの仕事だけにする。
・マルチタスクにするのではなく、ひとつづつの仕事をやり切る。
└マルチタスクは生産性が最悪。
→これも自分的にめちゃ当てはまる。基本的に一回で終わらせる気で本気でやるとタスクが増えなくていい。
・1日４時間は自分だけの時間を確保する。
└物理的にブロックする。
→ 自分は午前中が1番集中できるので午前中をブロック。早速実践してみている
・記憶力が悪いのは「理解できていないから。」
└なんとなく分かった風のことは理解に繋がらない。「説明可能かどうか」が非常に重要。
・記憶定着につながるブログの書き方
①学んだことを書く。
② 1の中身が回答になるような質問を書く
(ノートを見直したときここだけを見て内容を思い出す。
③何回か学んだらサマリーを書く
※理解したら1日後、1週間後に見直すと記憶の定着につながる。
・物事をできるようになる=理解、記憶、反復を繰り返すこと
└(脳の負荷を減らす)と言う考え方を徹底する。
理解が深ければ、物事を記憶するコストも下がる。
→脳の負担を減らすという概念はあまり日本でない気がする。
自分の場合は、早起きして朝から仕事、タスクを完了させる、仕事間でリフレッシュなどを活用している。
・クイックコールを活用する
└詳しい人に聞いた方が100倍早い。
またマネジメントする側から見てもチーム全体の生産性が上がるので、そこでクイックコールに回答するほうが効率が上がる。
→これは社内に浸透させたい。
・相手の意見を否定しない
└自分の意見は伝えるけれども、あくまで「In my opinion」と言うような伝え方をする。
最終的な意思決定者はその人の判断に従えばいいし、その意思決定に対して全員がリスペクトする。
そして最後に感謝の言葉を伝える。
こういった相手の意思決定を尊重すると良いようなカルチャーを作れると様々な意見が出て来やすい。
・オリンピック選手にもコーチがいる。
└自分も他人から教わることに積極的になるべき。恥じらいを持たない。
→自分もメンターをつける。
・サーバントリーダーシップ
└リーダーはビジョンとKPIは示すが、具体的にどのように進めるかはチームに委ねると言うマネジメントの手法。
チームメンバーが主体的に意思決定していく。
各メンバーのモチベーション管理が重要。
メンタル的に病んでいたりすると成立しないので、マネージャーの役割はいかにメンバーが楽しく働けるか、モチベーション高い状況を作れるかが重要。
・生産性を上げるためには学習が必要。
そのための時間を確保する。タスクに追われない。
・脳をリフレッシュするのには別のことするのが重要。
・全ての作業を「完了」させる事が重要。
→脳の負荷がだいぶ下がる。
ブログ等の作業も、なるべくそのタイミングで完結させてしまう。そのためには一定時間をブロックする必要がある。
引用
いきなり手を動かさない。まずは、 事実（データ） を一つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動をとる。
むやみやたらに試行錯誤するのではなく、まず自分の頭のメンタルモデルを使って仮説を立て証明する。〜中略〜この一連の手順が、手当たり次第に可能性を試すことによる時間のロスを排除し、圧倒的な効率を生んでいるのだ。
試行錯誤は「悪」である
〈手を先に動かさない。まず仮説を立て、アプローチを選定してから動く〉
どんなに頭がいい人でも理解には時間がかかるものなのだ。頭のいい人が理解が早いように見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキスト（文脈） が載っているからだ。
しかし、皮肉なことに「早くできるように頑張る」ということが最終的な生産性をむしろ下げていた ように思う。 プログラミングを例にいえば、Stack Overflow（プログラミング技術に関するコミュニティサイト） で調べて、コピペに近いことをしたほうが「成果」は出る。しかしそんなやり方では毎回調べることになるし、根本を把握していないからトラブルに弱く、結局は効率が悪い。今だと、Bingなり、ChatGPTに聞くとソリューションを教えてくれるだろう。だが、「理解」して「実践可能」にしていればそんなことすらする必要はない。 理解が十分でないまま手を動かして努力しても、空回りになるだけで身につかず、あやふやの試行錯誤は取り組んだことも忘れやすく頭に残らない。 「何かを早くできるように急ぐ努力」がかえって本質的な理解を遠ざけてしまうのだ。
何が問題だったかというと、１の方法は正しかったのに、単にその後実行した子プロセスが干渉する問題のせいでそのときは動かなかった。なのに私は、「ああ、この方法ではうまくいかない」と思い込んでしまったのだ。 試してうまくいかなかったとき、ログを分析しファクトを積み重ねて原因を特定していれば、問題の要因にすぐ気づいただろう。自分は全体を俯瞰してさっと考えるのが得意なので、途中計算を省略するきらいがあるが、「感覚」でこれが問題だろうと決めつけてしまったのが今回のミスで、あくまでファクトを積み重ねるべきだった のだ。 あるとき社内でこんなアドバイスをくれた人がいた。 「お客さんの言っていることは聞くけど、信用せずファクトを検証していくのがいいよ」 〜中略〜 自分でログなどを検証して問題解決をするようにしないと「思い込み」の穴に落ちてしまう。
手を動かす前に理解を深めるもう一つの強力な方法として、デザインドキュメント（Design document） を最初に書く、というコツがある。私が日本でソフトウェア開発をしていた頃は、キングファイル何冊にもなるような「設計書」を書くことが多かったが、そうではなく、ワード数ページぐらいで設計のアイデアと大まかな仕様を書いた、すごく小さなドキュメントだ。 これは、私のメンターであるクリスから、「できるプログラマは、みんなやってるよ。もちろんたくさんじゃなくて、ワードで数枚程度のものでいいから」と勧められた方法だ。
「ドキュメントはコードを書く前に書くんだ。だって、コード書いた後にドキュメントだけ書くなんて退屈だろ？」 そうクリスに言われてショックを受けた。だってアジャイルでドキュメントをどうこうするのは大抵後で必要なときにやるものだったから。クリスはさらに、デザインドキュメントを書くのは、次の二つの利点があると説明してくれた。 ・ドキュメントを書くことで自分の頭が整理される。抜け落ちていた視点などに気づくことができる。 ・考えているときに書けば、自動的に〝ドキュメント〟になるので、それをシェアするだけですむ。後でまとめて退屈なドキュメントを書かなくてよい。
「メンタルモデルをつくるとそれができるようになる」 と教えてくれた。そして勧められたのが、ガブリエル・ワインバーグ著『超一流が実践する思考法を世界中から集めて一冊にまとめてみた。』（ＳＢクリエイティブ） だ。本書では、世界中のいろいろな分野から集められた思考のフレームワークが紹介されている。 メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論 のことだ。チームメイトは「メンタルモデル」という言葉を頻繁に使うが、頭の中で素早く情報処理をするために、何らかの脳内イメージをもっていることが非常に有効なのだ。 例えばＭＶＰ（Minimum Viable Product 実用最小限の試作品） はソフトウェアの世界では常識的な考え方だが、どんなに最良のものと思ってつくっていても試作品を世に送り出してフィードバックを受け取ってから改良を重ねる必要がある。だからそれまでは絶対に製品をつくりこまずに実用最小限のベレルに抑えた試作品にしておくべき、という考え方だ。 そうしたフレームワークは、自分の思考の偏りをなくしたり、幅を広げるきっかけになるだろう。
「なぜなぜ分析」という方法を聞いたことがないだろうか？ これはトヨタの生産現場から生まれたもので、問題を発見したら「なぜ」を５回繰り返して、根本原因をあぶり出していく手法として有名だ。 自分の業種・業態に合った思考の枠組みを学んだり、経験したりして、自分なりの脳内イメージをつくり上げることができれば、 頭の中で考えを整理したり、問題発見に至るプロセスが大幅に高速化する。「メンタルモデル」は固定的な型があるというよりは、本当に人それぞれだ。ここで挙げた例を参考に、自分の仕事に特化した形でアレンジし、思考の枠組みを時間をかけて練り上げるとよい。ホワイトカラーの仕事の場合、仕事の９割は考えることなので、この効果は相当に高いだろう。
とくに 既存システムがある場合は、あれこれ考えて調べる前に、まず「エキスパートに頼る」というのはベストプラクティス だと思う。 日本は、「ググれ、カス」という言葉があるぐらい、自分で調べてから人に聞くべきという文化だが、少なくとも私のやっているクラウドの中身をつくるような複雑なシステムの場合、どう考えても全体的効率が悪い。 仕事のパフォーマンスを上げるには、いかに「無駄なこと」をしないかに尽きる。エキスパートから情報がシェアされ、そのレベルから理解するフェーズに入れば、しっかりと肝心なことにフォーカスができる。
長年、私はどうやったら自分の「できない感」から脱却できるか、ずっと解答を探し続けてきた。ソフトウェア業界にいて、同僚たちと比べて自分は頭が悪いと思っていたし、どんなに努力して時間とお金をつぎ込んでも、なかなか「できる」感覚が得られなかった。「仕事をコントロールできている」手応えもなかった。 だが、不全感をつくり出していた根本的な要因は、頭ではなく「思考の習慣」にあった。プログラミングもギターも、「早く成果が欲しくて」、目先の結果を求めて頑張ってはかえってできなくなっていたのだ。 どんな人も、最初は難しく、理解には時間がかかる という真実──その本質的な気づきは、最後のワンピースとなって、私が人生で心から欲しかったものを与えてくれた。
「Be Lazy」（怠惰であれ） ──〜中略〜
最新の技術をもっともうまく導入するために個人とチームに必要な思考の習慣として第一に上がったものだ。これは、〜中略〜「より少ない時間で価値を最大化するという考え方」 だ。できるだけ最小の労力で楽をする方法を探ろうというマインドセットだ。
Be Lazyを達成するための習慣は、次の通りだ。
・望んでいる結果を達成するために、最低限の努力をする。
・不必要なものや付加価値のない仕事（過剰準備含む） をなくす。
・簡潔さを目指す。
・優先順位をつける。
・時間や費やした努力より、アウトプットと生産性に重点を置く。
・長時間労働しないように推奨する。
・会議は会議の時間内で効率的かつ生産的に価値を提供する。
ところが、同じ言葉に対して海外のメンバーなら、図の右側のようなイメージをもつ。「最初の１個をピックアップしてやったら他はやらない。その一つにフォーカスしよう」 という感覚だ。 こういう場面はインターナショナルチームにいると頻繁に目にして、そのたびに驚いてきた。例えば、私がエバンジェリスト時代に「バリューストリームマッピング」 という、メンバー間でプロジェクトの無駄を発見するセッションを同僚のデビッドとやったとき、彼は「リリースマネジメント」というDevOpsプラクティス（開発担当者と運用担当者が連携してスピーディーにシステム開発を行う手法） の一つしかアドバイスしなかった。メインのプラクティスだけでも７個ぐらいあるのに。
〜中略〜「DevOpsプラクティスのAutomated Testingもできていないし、他にもいろいろあるじゃない。なんで一つだけしか言わなかったの？」と尋ねたら、「だって、たくさん言ってもできるかな？ まず一番インパクトのある一つを確実にすることが大切なんだ」と言う。
我々日本人はすぐに「あれも、これも」やらないといけないと思いがちだが、「すべき」より、「実際にできるキャパ」を考えるほうが生産性には有用だ。いわゆる〈 ２－ ８の法則〉でも、 20％の仕事が 80％の価値を生むのだから、 20％をしっかりやればよくて、 １００％全部やろうとすると工数もかさむし、時間が足りない。 １００個のタスクがあったら、本当に重要なのは 20％程度なのだ。海外チームのメンバーを観察すると、 20％のタスクを終えて 80％の価値を出したら、残りの 80％はやらずに、次の 80％の価値を生む 20％の新しいタスクに取り組んでいる。
一流エンジニアたちは「いかにやることを減らすか？」に頭を使っている。一般的にたくさんの機能を速く実装することはいいことだと思われがちだが、本当は「悪」だ。なぜなら、統計によると実際はソフトウェアの機能のうち 40％ぐらいしか使われないからだ。１００％を全力でつくっても 60％は使われないし、しかもそこでバグが発生したらその都度直さないといけなくなり、コードベースが多くなるので、変更があったときにコードを読む量が増えてしまう。 つまり、Be Lazyの精神で「やることを減らす」のは大変素晴らしいことなのだ。ところが日本人の感覚からすると、全部やらないのは何となく悪いことのように感じてしまい、現行の手続きやすでに決まっているタスクを「減らす」のがとても苦手だ。しかし重要なのは、「減らすこと」自体に価値がある と、マインドをリセットすること。
例えば、私がマイクロソフトに在籍しはじめてから、すでに２回報告システムが変わっているが、その度にどんどん手続きが楽になっていっている。ミーティングも毎週だったものが不要になってきたら２週間に１回になったり、１年に４回あったレビューが少なくなったり等、業務上の負荷が減っている。
１．一つだけピックアップする
インターナショナルチームで周りを観察すると、一番実践しているプラクティスだ。私は優先順位をうまくつけるのが本当に苦手で、あれもこれも大切に見えてしまう。だから思い切って、「一番重要なのはどれか？」を考えてそれだけをやるようにした。 最終的に三つピックアップするケースでも、まず最初に一つだけピックアップしてから、あとの二つをピックアップする。残りをスルーするのは最初は恐怖だろうが、結局はユーザー側もたくさんあると理解できない。よく使う機能はせいぜい三つくらいだろう。 まず、 一番重要な「一つだけ」をピックアップする癖 をつけると、時間がないときも、少なくともポイントを外さない仕事を高速で回せるようになってくる。そうすると、案外「やらないといけない」と思っていたことをやらなくても、問題にならないことがわかってくる。 無論すべてのケースで「一つだけピックアップ」方式が通用するわけではないが、これを３回繰り返せば三つピックアップできる。重要なのは、 10 個のうち１～３個しかやらないことは決して悪ではなく、そのほうが「バリュー」として効果的なことを体感することだ。
２．時間を固定して、できることを最大化する
あれもこれも「すべき」というマインドだと、どうしても時間をだらだらと延長してしまいがちだ。海外のチームメイトを観察していると、「すべき」から時間を計算するのではなく、 時間は固定して、その中で価値を最大化する という行動をとっている。 例えばロッシェルさんと打ち合わせをするときも、「あれも、これも課題だな」と思っても、時間が延びることはまずなく、この時間でできる範囲の中で、最大限バリューが出ることにフォーカスして、「今日はこの二つだけやろう」といった思考に切り替わる。 時間が最大の制約なので、時間内に確実にできる数に絞って、最大の成果を出せることに集中する。皆さんも、なんにも準備できていないのに急に明日プレゼンをすることになったら、無理なものは諦めて、バサバサと要素を切り捨てているはずだ。きれいなドキュメントをつくる暇はなく、「やること」の数を減らし、本当に重要なことのみ時間内に伝えられるように意思決定せざるを得ない。
３．「準備」「持ち帰り」をやめてその場で解決する
インターナショナルチームを観察していると、彼らは常に「会議の場」だけで完結 する。ざっくりしたアジェンダ（検討事項） はあるが、準備に時間をかけて会議に臨むことは一切しない。議事録もその場で要点だけをノートアプリのOneNoteにとって共有される。プレゼンテーションの会議なら、「後で書き直します」みたいなことはせず、その場で資料を修正する。そうすれば終わった後に作業時間を取らなくてよく、会議の時間内に必要なことを共有できる。さらに、会議後の「宿題」や「持ち帰って検討すること」も滅多にない。必要な「意思決定」は、極力その場で行う。 つまり、会議に出たら「会議の時間内だけで完結」するよう訓練すると、非常に生産的だ。 昔、私がコンサルタントをしていたとき、ソニックガーデンの創業者・倉貫義人さんからもらった一言は忘れられない。 「牛尾さん。会議の準備をしないでくださいね、無駄だから。そうじゃなくて、 会議の時間を価値の高いものにしましょう」 倉貫さんとの会議は常に生産的で、その場ですべてを解決するスタイルだった。会議の前にも、後にも時間は不要だった。その潔さが、濃密な価値を生んでいた。
４．物理的にやることを減らす
マイクロソフトの開発チームでは「スプリントプランニング」という定例のミーティングがあり、２週間で実施するタスクの整理をマネージャと一緒に行う。日本の進捗会議といえば、何ができていてどれが遅れているという報告の場であったと思う。マネージャから、予定していた要素を外す話はまずなく、人を投入してどうやって全部やるか？ に頭を使っていた。 こちらでは、マネージャ自身が「このタスクあんまり重要じゃないから、２週間でやる必要ないね」と言って簡単にスコープ（予定していた機能） から外す。どんどん仕事が減っていくし、そのまま二度とやらなくなったタスクもある。みんなが絶対的に重要なタスクにフォーカスできるように気を配ってくれている。 物理的にできないものは頑張ってもできない。だから、自分の仕事の中で「何をやらないか」をどんどん決めていこう。計画なんてものは当初の予測であって、正解とは限らない。予測不能のことは起こるものだし、優先順位は刻一刻と変わっていくもの。仕事は「どれだけやったか？」ではなく、「どれだけ会社にインパクトを与える仕事ができたか？」のほうが重要なのだから。
・間違いを厳しく批判したり懲罰したりしない。
・失敗から学ぶ態度。
・Fail Fast（早く失敗する）。
・実験が推奨されている。
・全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される。
・非難や恐怖感のない環境。
一方、アメリカでは、失敗や間違いで怒られることが皆無だ。失敗に気づいた後に、本社に報告すると、「フィードバックをありがとう！」と大変感謝される。もっと言うと、誰がやってもうまくいくようなことを無難に実施してミスがなくても、それは評価の対象にならない。
基本的なスタンスとして、「従業員への信頼」を慣習とする多くの米国企業では、普段の業務において細かいことを言わない。最初に会社と合意したゴール、つまり大まかなＫＰＩ（重要業績評価指標） を達成していたら、途中で失敗しようが、人より不器用だろうが何だろうがとくに問題にはならない。まずはその人を信用する。
ＫＰＩが達成できなければ、１年の評価のタイミングで、給料が下がったりクビになったりする。ただそれだけの話だ。
マイクロソフトの場合は、「何ができるか」でエンジニアとしてのランクは明確に定義されており、自分のランクによって給与は決定される。給与を上げたかったら一つ上のランクの仕事をしてＫＰＩを達成する。するとマネージャがプロモート（ランク上げ） しようとノミネートしてくれる。他人との比較ではなく、自分との戦いでレベルアップしていく仕組みだ。
マネジメントは詳細まで細かく練られた計画を期待しない。
・予算と報告のプロセスは精密な結果の予測を要求しない。
私が、最初に知って衝撃を受けたのは、「納期（Deadline）」の意味が日米でまるで異なることだった。日本の場合、納期に、予定された機能がすべて搭載された製品を、予定された品質で納品することが求められる。 しかし米国では、「納期は柔軟」だ。〜中略〜多くの案件は期日通りリリースしているが、実は中身は予定よりも少ない量に変更されていることはよくある。納期を守るために、徹夜する人たちも見たことがない。日本人は納期に厳格すぎて無理をしすぎる傾向にある。だが、そこにどれほどのバリューがあるだろうか？ Ｑ（品質） Ｃ（コスト） Ｄ（納期） ＋Ｓ（スコープ） は、トレードオフの関係にある。納期を短縮したければ、品質を落とすか、お金をたくさん払うか、提供する物量（スコープ） を減らすかのいずれかだ。エンジニアリング的には予定通りＱＣＤＳをすべて達成するというのは非常に困難である。 だから、多くのマネージャは、ゆとりのあるバッファをもって、それを達成しようとするし、私もマネージャ時代は常に 30％ぐらいのバッファを残すようにしていた。それでも、ソフトウェアの場合は変更が多いので、当初の計画通りにはまずいかない。段階にもよるが、最初の段階で計画したコストの３倍になる確率も十二分にある。
最初衝撃を受けたが、さほど問題になりもしない納期とリリース機能を守るために、プログラマの生活や健康を犠牲にしてまで取り組むことは、中長期的には疲弊して生産性が低下してしまうことになるので、マネジメント的に効率が悪いのだ。 決して無理はしないほうがいい。なぜならチームの適正な生産量を超えた量を一定期間で達成した結果、組織の問題を覆い隠すことにつながるからだ。「今回できたのだから、次回もこれぐらいできるよね」と、無理が積み重なる悪循環に陥りがちだ。チームの実態が上層部や周りに伝わらず、問題点も改善されない。
１．「楽に達成できる」計画で仕事をする
日々の仕事において、他の人にお願いするケースでは（もしくは自分でやるときにも）、その人の能力でいうと、これぐらいの日数でできるという日を納期にするのではなく、プラス何日か余裕のあるスケジュールを設定しよう。 日本では「なるはやで」とか「明日までに」というオーダーで仕事を依頼されることが多いが、海外ではそうした 火急の依頼は「マネジメント能力の欠如」と見なされる
思い切って「計画通り」が良いという思考は捨ててしまったほうがいい。計画は単に「見通しをたてて、仕事を進めやすくするため」のものでしかない。そもそも納期にどれぐらいバリューがあるかを冷静に考え、自分はどの程度「価値」を定常的に創出できているかを判断基準にするとよい。そして、「価値」は状況によって頻繁に変わっていく。 なにも「たくさん物量をこなすこと＝生産性が高い」わけではない。生み出すものの「価値」にフォーカスするマインドを身につけよう。
「無理・断る」練習をする
以前ロッシェルさんと一緒にやった、ブラジル人と日本人の混成チームのワークショップで、彼女は次のような質問を投げかけた。 「もし、皆さんが仕事で忙しいときに、上司からこの仕事をやって欲しいと言われたらどうしますか？」 日本人は「わかりました」と言って残業でカバーするという回答…
本章では「Be Lazy」にはじまり、「リスクや間違いを快く受け入れる」「不確実性を受け入れる」というマインドセットの三原則について扱ってきた。総じて言えるのは、より少ない時間で価値を最大化できている集団ほど、会社内で「すべきこと」が圧倒的に少ないということ。インターナショナルチームではやるべき仕事はＫＰＩの達成だけであり、それも、無理なものが設定されているわけではなく、やり方は自由で細かい指示はなく各人の裁量に任されている。「やらされること」といえば、せいぜい月次レポートと、必須教育程度だ。
確かによくよく考えると、コードを読むのは本当に必要な部分（クラスの役割やパターン、インターフェイスの理解） で十分だ。 自分は理解するために端から端まで実装を読んでいたが、そうすると脳みそのＣＰＵをフルに消費してしまう。そして、肝心な部分に脳のリソースを使えないため、ひどく疲れる割に頭に入らないことに気づかされた。
読むことを減らして、脳に余裕を生む
この問題を仕事の難易度レベルにそって、さらに深掘りしてみよう。脳の使い方のアプローチがよりクリアになるはずだ。
レベル１：何もググらずに即座に実装できるもの。
レベル２：問題をどう解決するかはすぐに思いつくが、具体的な方法は忘れているので、ググる必要があるもの。
レベル３：自分は解法を知らないが、スパイクソリューション（課題把握のための大まかなプログラム） をしたらできそうなもの。
レベル４：自分だけでは解決が難しい、もしくはものすごく時間がかかるもの。
〜中略〜
そこでふと、 生産性とはいかに「レベル１」を増やすかではないか ──レベル２がそこそこある私の場合、レベル３や４の増加を目指すよりも、レベル２案件をレベル１に向上させたほうが生産性が高いのではという気づきを得た。 コードリーディングが遅い根本的な原因は、コードを見たときにどういう挙動をするか明確にすぐにイメージできないか、もしくは構造の把握が下手だからだ。だが、レベル１のものが増えると脳の負担は激減する。 例えばプログラマなら、プログラミングを学んだら最初に出てくるものの一つForループ（プログラムを繰り返し実行する構文） の挙動は、誰でも自信を持てているだろう。このループを見て一瞬で把握できるような理解を、他のコーディングにも広げていけばよい。すると、もっと重要で細かい部分に目が配れるようになる。
これは「自分の脳の負担を減らす」非常に合理的なアプローチだ。 レベル１の領域を増やしつつ、レベル３の仕事は素直にラーニングコースなどでさっと学んでしまうのがよいだろう。問題はレベル４がきたとき、どうしたらいいかだ。
アウトカムに集中すると一時的にはよくても、中長期の「生産性」は上がらないのだ。 例えば、ＡＩに書いてもらったり、既存のコードをコピペすればすぐにアウトカムを出せても、中身を理解していないからコントロールできてる感はないし、その後何度も調べることになり、応用が利かない。作業ばかりが続くので、自分が知らないことや、新しいことのキャッチアップなどもできない、つまり「成長していない」ということになる。 技術は地味な積み重ねにこそ真価が宿る。「何かを身につける」のは、決して即席ではできない。
ＷＩＰ（Work In Progress） とは、今手を付けている仕事のこと。つまり、「ＷＩＰ＝１」とは「今手を付けている仕事を一つに限定する」 ということだ。〜中略〜 私の場合、例えばインシデントの解決支援のための会議が毎日ある。その間、自分に関係ない話は聞き流しながら別の作業をやっていたりする。〜中略〜 ところが、ポールは会議で自分に関係ない話が続くところでも、一切ほかの作業をやらず、チャット返信すらしている様子がない。彼はその場で問題のあたりをつけたり、あたりがつかない場合も「これはほかの部署に転送しよう」「誰々さんに聞いてみよう。よしメールを書こう」と、とにかく「何かを進めよう」とする。 必ず問題をその場で解決する、もしくはステップを一つ進めているのだ。ここで学んだことは、次のポイントだ。
・30 分から１時間を割り当てたら、そのこと「のみ」に取り組む。すぐに終わらないものは、人に問い合わせるなど、物事を進めておいて、待ち状態にして、次のタスクに進む。
・一つのタスクを中断する場合、次に再開するときに、すぐにその状態に戻れるように記録したり、整理しておいたりする。
・タスクの残骸は消しておく ── 例えばブラウザのタブは、そのタスクが終わったら閉じて、必要なものは記録する（そうしないと、気移りしてしまう）。
優先順位の高い仕事には、それだけに集中する時間を意識的につくり出す必要がある。 私はある時期、組織改編にともない、技術エリアの引き継ぎが非常に多くて、同僚からの質問対応などによる中断が増え、自分のプライオリティが高いタスクの進捗が悪いと感じていた。そこで、一日の中でどのタスクにどのぐらい時間を使っているかを正確に計測してみたところ、なんとメインの仕事に 90 分しか使えていないことがわかった。 この問題をマネージャのプラグナに相談してみたら、技術イケメンたちがやっているある方法を教えてくれた。単純な話で、 毎日４時間をブロックして、Teamsもメールも一切閉じて、自分の作業だけをする。
なぜ彼らは記憶力がいいのだろう？ 〜中略〜 ふと頭に思い浮かんだのは「もしかすると、これも理解の浅さが原因じゃないだろうか？」ということだった。 つまり、私がアドリブではうまく説明できないのも、あまりディテールを覚えていないのも、実は十分に理解できていないからではないだろうか。
時間は気にせず、 自分がやったことをクリアに説明できるよう時間をかけて言語化してみる。すると、いろいろな箇所で「あれ、俺なんでこここうしたんだっけ？」〜中略〜と疑問点が湧いてきた。 〜中略〜説明のためにコードを見なおして整理して考えると、自動テストを通すことによって、動いているけど「わかっていない」部分をたくさん発見した。 また、 説明可能にするということは、構造を整理して把握して、脳のメモリに乗せる必要がある。
記憶に関するもう一つの重要な要素は、 記憶しやすくなる復習のタイミングを習慣化する という点だ。覚えたら翌日、そして１週間後に振り返るとよいだろう。 有名な「エビングハウスの忘却曲線」を踏まえてもそのほうが合理的だし、カナダのウォータールー大学の、 24 時間以内に 10 分間復習すれば記憶は１００％戻るという研究発表もある。 コーネルメソッドのメリットは、復習で思い出す練習もしやすいことだ。私はこの方法でノートを書く癖をつけて、次の日に見直して、覚えているか確認するようにした結果、仕事の記憶の解像度がくっきりと上がってきたのを実感している。
・理解 ・記憶 ・反復
まず時間をかけて基本と構造を「理解」しないと、決してコントロールできるようにはならない。頭の中で整理された状態で「記憶」しないと、何回も思い出す必要や調べなおす必要があるので、時間ばかりかかって確信が持てなくなる。最後に、整理して頭に入ったら、あとはそれをいつでも取り出せるよう「反復」に時間をかける。 これらすべてに底流するのが、 脳の負荷を減らす、という発想だ。ベーシックな理解が深いとさほどの負荷もなく記憶しやすく、しかもメンタルモデルを使ったイメージで構造的に要点を把握してしまえば圧倒的に楽だ。翌日見返すのも、記憶の定着を考えたときに結局はもっとも脳が楽だからだ。それが理解→記憶→反復の好循環を生む。
周りを観察すると、リモートワークでも生産性が高い人はほぼすべてクイックコールをよく活用していた。クイックコールとは、予定されていないビデオ通話のこと。必要なときにTeamsとかのチャットで、先方から「今クイックコールしていい？」（Can I have a quick call?） と言われるので、良ければ「いいよ！」（Sure!） と送り返す。するとコールがかかってきて１対１でコミュニケーションをとる。そこから画面を共有して一緒に作業したりもする。
〜中略〜
一人でうんうんうなるより、たとえ 10 分でもいいので、知っている人と一緒にやるだけで作業は 10 倍速くなるし、チャットと違って、新しい質問が浮かんでも瞬時に答えが返ってくる。 音声のほうが１００倍以上情報量があってインタラクティブ性があり、フィードバックが速い。
クイックコールされる側もよいことがある
クイックコールはされる側にだって大きなメリットがある。相談される側もわずかな手助けでプロジェクト全体がスムーズに進むので、結果的に自分の仕事も楽になるのだ。 大抵のクイックコールはそんなに長くかからない。オフィスにいて「ちょっとここ教えてくれない？」くらいの感覚なので数分で終わる。タイミングが悪ければ、「今ちょっと都合が悪いんだ。 11 時はどう？」（Sorry, I'm not available. Are you available at 11 am?） とか返せばよい。 自分が気軽にクイックコールを受け付けていると、困ったときに相手も簡単にクイックコールに応じてくれる。チャットにいちいちあげていると、待ち時間や往復のやり取りが発生してかえって面倒になることも多いから、双方に合理的なのだ。 〜中略〜チーム内でクイックコールが文化になると、非常に生産性が上がって楽になる。
インターナショナルチームの文化では、誰かに相談するさいのハードルが非常に低い。相談を受ける側のマインドもオープンだ。
ある技術の問い合わせが別チームから来たとき、自分がやったことのない分野だったので、私は「サンプルやドキュメントを見るとこの部分が違うよ」という指摘にとどめて返した。正直自分で調べたら絶対時間がとられると思ったから。ところがある同僚は、私が返した内容を踏まえつつ、チュートリアルに沿って「この方法でやったらちゃんとできたよ」とレポートした。
実は、この「気軽に聞ける仕組み」は、「気軽に断れる空気」とセットになっている ことが肝心なポイントだ。〜中略〜例えばハッカソンをしていて、サポートをしてくれる同僚がいるとする。彼らに助けを求めると気楽に答えてくれるが、自分がわからないと「あいつに聞いたほうがいいと思うよ」「うーん、わからないな。サポートに聞いたら？」と簡単に言う。これは、社内だからではなく、お客を相手にしていてもそんなスタンス。サポートを受けたほうも「助けてくれてありがとう」と笑顔で返して終わりだ。 これが日本だったら、一旦お客様から質問を受けたら自分がサポートに連絡して最後まで面倒を見たり、「後日回答します」と抱え込み、責任を持ったりするところだ。〜中略〜一旦助けることを引き受けたらとことんやるのが日本人の 性 だ。 それは素晴らしい美徳だが、ことソフトウェア開発の効率を考えると相当な無駄を生んでいる。 助けになれない場合は、すぐに「ごめん」でクールに済ませたほうが、聞く方も聞かれる方も気が楽 なのだ。
意見が対立しても「否定しない」
私があるアプリケーションのリリース作業を依頼され、作業していたときのこと。複数人にレビューをお願いしたうえで、もう大丈夫な段階だからマネージャには今日リリースするという話をした。レビューの中に同僚のあるコメントがあり、正直重要じゃない指摘だと思ってコメントを返していなかったが、そのままにするのは失礼だと思い本人と話をした（専門的な用語も出てくるが、気にせず会話の雰囲気だけ見てほしい）。
牛尾 このコード、コメントアウト（コード編集のさい特定の箇所を一時的に処理されないようにすること） を外してほしいと書いてあったけど、応用的なサンプルも示しておきたかったんだ。このケースでは、多くの人はそのサービスのアカウントがなくて使えないからコメントアウト扱いにして、実行時にエラーが出ないようにしているんだ。
同僚 なるほど。でも、僕の意見としては、見たとき混乱したんだよ。これコメントアウトはやめて、ディレクトリをわけたらいいんじゃない？
牛尾 （今のタイミングでそれやると、死ぬなぁ……） なるほどなぁ。今日リリースしようとしていて、その変更を入れるとほかの言語のサンプルをすべて修正、テストをしないといけないので振り出しに戻ってしまう状態なんだ。ドキュメントにはしっかり記載しているよ。
同僚 最後の最後で本当に申し訳ないんだけど、僕の意見では、混乱すると思うんだ。ただ、決めるのは君だし、僕の意見なんて全然無視していいよ。君次第さ。
牛尾 じゃあ、このPull Requestは大きいのでいったん統合作業を行ったあとに対応を考えるよ。レビューしてくれていつもありがとう。
同僚 こちらこそ！
詰まるところ、チーム全体が強くなるためには、気軽に互いの知見を交換できるコミュニケーション文化が大切だ。聞くことを恐れずに、人に頼ろう。そして自分も役に立とう。 かくいう私も元来そうしたことが不得手だったが、仕事を通してどんどん「人に頼る」ことを学んでいったように思う。私の筋トレのパーソナルコーチが、仕事にも通じるこんな名言をくれた。 「みんなコーチって初心者に必要と思っているだろ？ だけどオリンピック選手にも必ずコーチがいるんだ。誰だって人は、過去に経験がある人から学んでいくんだよ」
サーバントリーダーシップの場合、 リーダーは〈ビジョンとＫＰＩ〉は示すが、実際にどのように動くかは、チームが主体的に考えて意思決定していく。
ビジョン、戦略、ＫＰＩの三つは明確だが、誰も指示をすることはない。 日本企業と比べると、現場のメンバーがかなりの権限を与えられて、どう実行するかを各自で考えている。 他の外資系に勤めている友人に聞いても、このスタイルは増えていて、マネージャが指示するような「コマンドアンドコントロール」型の管理は今ではオールドファッションと呼ばれているそうだ。
タスクの割り振りもチームが自らやっていく。基本的にメンバー各自がやりたい仕事を「自分がやるよ」と選択していく。
〜中略〜インターナショナルチームでは基本的に、メンバーが「楽しんでいるか」が非常に重要視される。メンバーは楽しめる仕事をプロとして実施して、主体的に考えて仕事をする。そのほうが指示を受けて「やらされる」仕事より何倍も楽しいし、自分が面白さを感じてコミットする仕事は、生産性が何倍も高くなるだろう。
マネージャの存在は、日本とはかなり性質が異なる。日本のマネージャは進捗管理や課題管理をして、プログラマや開発者を指揮するイメージだが、サーバントリーダーシップ制のもとでマネージャが重視するのは、各メンバーのメンタル面だ。 「ツヨシ、仕事をエンジョイしているか？」
マネージャのダミアンが私とOne on One（一対一の面談） をするときに必ず投げかけるのが、この言葉だった。〜中略〜私の答えがノーだったら、職場をエンジョイできるようにいろいろと相談にのってサポートしてくれる。 いかにメンバーたちが幸せに働けるかに高い関心を寄せ、エンパワーしてくれるのだ（多分チームメンバーから喜ばれているか、というのもマネージャ職の一つの評価基準なのだろう）。 だから我がチームでは、「仕事がつまらない」「納得いかない」と言っているメンバーを見たことがない。マネージャが率先してメンバーそれぞれに「エンジョイしているか？」と確認することで、仕事は〝楽しんでなんぼ〟の心地よいムードが生まれているように思う。
「生産性を上げるためには学習だよ。だから、僕は仕事を定時ぐらいで切り上げる。その後で、自分のやりたいトピックを勉強したり試したりする。
「タイムボックス」制だ。 例えば、５時になったら仕事が途中でも、どんなに切りが悪くても、すぐに仕事をやめる。いつの間にか時間が過ぎてしまわないよう、５時きっかりにアラームをセットして。 絶対に時間をオーバーすることはないよう、しばらく無理矢理にでも「タイムボックス」で生活してみたらどうなったか？ まず、５時に強制終了するようにすると、就業後にランニングできるようになった。頭がすっきりとリフレッシュするのがわかるし、夜に本を読んだり、ギターを弾いたり、ゲームしたりする余裕が生まれた。以前はそうした時間にすごく罪悪感を感じたが、一番イケてる人たちの意見を信じることにしたのだ。
脳を休めたかったら、全く違うことをするのも効果的だ。私の場合、「頭を使わない手作業」が合っていて、趣味の「ギターを弾く」ことがとてもよいリフレッシュになっている。平日の夜にそういう時間をもつことに罪悪感があったが、日々 30 分～１時間程度、堂々と弾くようにした。
・発想のブレークスルーは、その仕事をしていないときに発生する。
・一日に一つのことに集中できるのは４時間。４時間過ぎて疲れたら、単に休むのではなく、違うことをするのが良い。 ・休息する（Take a rest） のは、何もしないことではなく、いつもと違うことをするのが重要。
生活習慣において、あらゆることが「未完了」だったことに気づいた。洗濯したら終わりではなく、「服をたたんで、収納して」完了だ。食事をしたら「食器を洗って、キッチンを掃除して」完了、郵便物を受け取ったら「開封して、中身を確認して、不要なものを捨てたり、処理して」完了なのだということに。 結局、さわりだけやって最後までやりきらないから、部屋が散らかっていくし、「あとでやろう」と思うからいつも気が散ってしまうし、ものが多すぎるからやるべきことも目に入らない。人生は何事につけ、一つひとつ完了しないと面倒臭さが倍増することにも気づいた。
そこで意を決して、何かをしたら必ず完了まで一息にやるように意識した。コーヒーを飲み終わったら、カップを洗ってしまうまでやる。
脳内が片づけによって整理されていったとき、ふと頭をよぎったのが、「もしかして自分はＡＤＨＤだから整理ができなかったのではなく、整理ができていないからＡＤＨＤ症状が出ていたのではないか？」ということだった。
この記事が気に入ったらサポートをしてみませんか？