一流エンジニアの考え方を知る。牛尾 剛著「世界一流エンジニアの思考法」を読んで。
今年、エンジニアとしての自分に最も影響を与えた本が決まりました。
牛尾 剛著「世界一流エンジニアの思考法」です。
この本はマイクロソフトでエンジニアとして活躍されている牛尾 剛氏が、アメリカで一流のエンジニアと働く中で学んだ思考法(マインドセット)について書いている本です。
この本の何が凄いかって著者の牛尾氏は「自身の強みでは”無い”分野」「マイクロソフト」「44歳という年齢」で転職をされています。周囲から強みだと評価される分野があるにも関わらず、それ以外の分野で自分より周りが強い環境に飛び込む勇気。純粋に凄いことだと思いますし、紹介文でこれを知った時には「この本は絶対おもしろい！」とワクワクしました。
本記事では「第1章 世界一流エンジニアは何が違うのだろう？—生産性の高さの秘密」より、即実践できる内容を3つ書いています。
1. 思いつきによる試行錯誤をしない
単に思いつきでいろいろなパターンを試して正解を探しているだけなので、とても時間がかかる上、新しい知識を何も学んでいない。
障害、バグ発生時の調査の際にあれこれ手を動かしながら調べないようにしよう、という話です。
想定通りの動きをしないときに「コードを変える→動かす→コードを変える→動かす…」を繰り返して解決しないまま時間を浪費した、ということがこれに該当します。エンジニアであれば誰もが一度はやったことがあるのではないでしょうか。
本書では「思いつきによる行動は時間の無駄遣いになる」と書かれています。
思いつきによる行動は時間とエネルギーの浪費であり、生産性の低下に繋がる。そして思いつきで行動しているだけなので解決したとしても原因を理解できていないから頭に残らない。頭に残らないから似たような事象が起きても対応できず、応用も効かない、という負のスパイラルになります。
必要なのは「まず事実を一つ見つける。仮説を立てる。証明するための行動を取る」とあります。ここでの事実とはログやエラーメッセージが該当すると僕は解釈しました。「エラーメッセージに全て書いてある」は基本だと思いますが、思いつきでは無く事実をベースに行動することが改めて重要であると感じました。
2. 理解に時間をかける
圧倒的に試行錯誤が減って問題を一直線に解決できるようになってきたのだ。
どんなに頭のいい人でも理解には時間がかかるもの。
かからないように見えるのは理解に時間をかけて、それを積み重ねてきているから。コードを読むときにもロジックだけでなく、意図とアーキテクチャを理解することに努める。
この「どんなに出来る人でも理解には時間がかかるもの」という内容は自分にとっては救いの言葉であり、激励の言葉でした。最近、出来る人と自分の差は何にあるんだろうと悶々としていましたが、それを言語化してくれたのがこの言葉でした。何かを学んだり、調べたりする際にはこの言葉を思い出し、繰り返して理解に努めたいと思います。
3. 小さなドキュメントを実装前に書く
ドキュメントはコードを書く前に書くんだ。だって、コードを書いた後にドキュメントだけ書くなんて退屈だろ？
実際に牛尾氏のドキュメントには以下を項目として書いているとあります。
項目
・スコープ：ドキュメントの範囲
・バックグラウンド：なぜするか？の背景
・プログレム：解決したい問題
・プロポーザル：どういうデザインにするか？その理由。2-10ページ程度
ぜひとも取り入れたい！と思った内容でした。
実装をしていて仕様の考慮漏れに気づくということがたまにあります。すぐに対応できるものであれば良いのですが、他の機能に影響するものであったり、他メンバーに確認する必要があるものだったりすると実装に待ちが発生してしまったり、スケジュールに影響したりということになります。何よりスムーズに実装したいというのもあります。
僕が前職でいたSIerはウォーターフォールでの開発だったため、実装前に仕様を固め、仕様についてのドキュメントを必ず作成していました。ExcelやWordで仕様のおおまかな説明を書いたドキュメントを作り、OKが出たらさらに仕様の詳細を書いたドキュメントを作り、OKが出たらそれを元に実装を行う…ということをしていました。ただ、これだと必要な工程や内容のボリュームが大きすぎて手間も時間もかかりすぎる、というデメリットを感じていました。
ここでこの「小さなドキュメント」ですが、このくらいのボリュームであればメモ帳でもGithubでも、テキストベースで作ることができるので気軽に作成することができそうです。
【実践】小さなドキュメントを実装前に書く
そこで早速やってみました。
今携わっているプロジェクトでは施策の内容(背景/目的/解決したいこと)をチケットという単位でまとめています。開発時はそのチケットの内容を元にして実装を進めていくのですが、このチケットに紐づく開発チケットを作成して、簡潔なドキュメントをこの開発チケットの中に記載するようにしました。
背景や解決したい課題は施策チケットに記載されているので、開発チケットには以下のような内容を書くことにしました。
小さなドキュメント
・施策チケット内の実装に関わる内容
・機能をどのように作るか
・実装するクラス名/関数名/変数名
・ユーザーの条件
・判定方法 など
やってみて良かったこと
まず、開発チケットの通りに実装をすれば良いのでかなりスムーズに手を動かすことができてとても気持ちがいいです。
これまでは「考える→手を動かす→考える→手を動かす…」で実装していたため、途中で作業を中断すると考えていたことを忘れてしまったり、どこまで実装したか分からなくなることがありました。メッセージの通知やミーティングが入るなんてことは日常茶飯事ですもんね。これが「考える→手を動かす」のようにシンプルになるので途中で中断しても開発チケットを見ればどこまでやったかは一目瞭然になり、再開もスムーズになりました。何より一番楽しい実装を一気にできるので気持ちが良いです。
次に、仕様の確認が必要な内容を事前に挙げることができるという良い点もありました。
これまでは実装をしながら疑問が出た時点で都度、確認をしていたため実装の手を止める、検討に時間がかかる内容をスケジュールの後半で確認してしまう、ということがありました。これが実装前に一通り確認した上で進められるので仕様漏れが今のところありません。また、施策を考えるメンバーにとっても施策チケットを作成したすぐ後なので施策の内容を思い出す、という余計なエネルギーを使わないというのもメリットとしてありました。質問を受ける側も一度に質問が来た方が考えやすいと思います。
本書では、ドキュメントを事前に作るメリットとして「ドキュメントをシェアするだけで機能の説明になる」というのが書かれていますが、僕の場合は「施策チケット+開発チケット」でその役割を果たしたいと考えて開発チケットを書いています。今のところ良い感じなので引き続きやっていきたいと思います。
おわりに
僕自身、今年転職をして周りの方が強い環境で働き始めました。
仕事をする中で感じていた
「自分ならではの価値を出せていないのではないか」
「あと数年でこの人のような発想ができるようになるのだろうか」
といった不安を感じ、悶々とすることもありました。周りが強い環境に身を置くというのは成長には必要だと思う一方で、自分の出来なさと向き合わざるを得ない怖さもあると思います。環境に差はありますが、似たような境遇で活躍されている牛尾氏から何かヒントをもらうことができるのではないか。そう考え、本書を読み始めました。
すぐ真似できる具体的な行動もあれば、それらを抽象化した思考法についても書かれています。真似できることは即実践、思考法は取り入れて行動に落とし込んでいきたいと思います。
最近出版された書籍(2023年10月)だけあって、リモートワークやAI、COCOAアプリのようなタイムリーな話題もあり、読み物としても大変面白かったです。エンジニアとして日々働いている方の悩みを解決してくれるヒントが何かしらあると思うので、ぜひ手に取って読んでみてください。
それでは！
関連記事
▼「思いつきによる行動」の記事
▼「理解」についての記事
読んでくださりありがとうございます。 これからもnoteで発信していくのでよろしくお願いします！