本書を選んだ理由

エンジニアになって今年で5年目になりました。
6年目を迎える前に、改めて生産性とは何なのか、生産性を向上するための具体的な方法を学びたいと思い本書を選択しました。5年目ですが、自分を生産性が高い人間だと思えたことは悲しいことに1度もありません。いつか胸を張って生産性が高いと思えるようになりたいという願望が結構強くあります。そんな力添えになってくれるのではないかという淡い気持ちで読み始めました。

気になった点をピックアップして、自分の感想を述べていく。

・情報収集は箱をたくさん集めて並べていく作業
・モデル化・抽象化によってさらに箱を積み上げ、徐々に高みを目指すイメージ

学習したことや経験したことを1つの箱であるとイメージしてそれを積み上げていくイメージ。
私はあれこれ気になってとりあえず手をつけることが多く、好奇心が強い方の人間なんですが、だからこそ1つのことに集中することがあまりないです。なので「中途半端だな」と落ち込んでしまうことが多いです。
ただ、この箱を並べるイメージを持つと、あれこれ手を出すのも悪くはないかなと感じました。一見、関連性がないものでも横並びだったのがいつしか、「あれ？これとこれは関連性があるから...」と縦に積み上がるかもしれないからです。どこかで縦の高さを最大化する動きは必要だと思いますが。

・やる気が出ない人の65%はタスクを1つに絞れていない
・Getting Things Doneまずはすべてを集める。気になるものを一旦1つのエリアに集める。そのときには必要かどうかを考えない。集めると考えるのフェーズを分けて認知的負荷を抑える。
・不確かな時は楽観的に
・優先順位をつけることがそもそも難しい。
・タスクが大きすぎる。
・タイムボックス化
・ポモドーロ

昨年から今年の1月にかけて外部のクライアント向けの管理システムの大きな実装とリリースを行いました。
既存のシステムに新しい機能のタスク(設計からリリースまでが2ヶ月半程度)のチームリーダーを初めて任せてもらいました。ただ、ここで大きく失敗しました。そもそも設計の段階でクライアント側と弊社の営業からの要望を正確に理解して、設計に落としこめず要件漏れが発生し、開発の段階で戻り作業が何度か発生しました。また、大きなタスクを完遂するためにタスクを細かく区切りましたが、その粒度が大きく、チームメンバーにタスクを振った際にタスクに対するTODOが明確でなく、困らせてしまいました。
その反省を踏まえ、現在進行中のタスク(またリーダーを任せていただいている)では、設計の段階でなるだけ入念に、時間をかけてでもしっかりした求められるものを考え、作成した設計が本当に問題ないかをエンジニアの上長および営業側、そしてチームメンバーに確認作業を取るようにしました。タスクを細分化する際も粒度を細かく区切り1〜2日までに開発からテストまで完了できるようなスモールタスクを発行することにしました。加えて、前回失敗した原因の1つとしてコミュニケーション不足があったので、毎日終礼あるいはチャットでの報告会を実施しました。まだ進行中ですが、やるべきことをなるべく明確にし、自分含めチーム全体が迷う時間を極力減らすよう改善していっています。
それから要件定義のステップの中でFigmaを使ってワイヤーフレームを作成して、画面イメージを作成すると、視覚的にイメージできるので工数を出す際に役立っている感覚もあります。
とはいえ、作業中に要件の変更や追加が発生することも今後でてくると思います。その時には柔軟に対応できるよう変更可能でかつ堅牢な設計を組み込んでいく必要があるなと思います。場数を踏んで経験をたくさんしたいです。
ポモドーロの方法である、25分間集中して作業して休憩。は自分のスタイルに合っているかもしれないなと2週間前から少しずつ試してみて薄々感じています。

・本を読む時のボトルネックは？
・読む速度が遅い人の中には無意識に声帯を動かして「静かな音読」をしている人がいる。

まさしく自分がやっている感覚がある。特に対象の本への知識や過去の経験がない場合などに。技術書に関わらず、ビジネス書や参考書、小説にもです。例えばコーディングの際に対象の言語のドキュメントを読む場合に過去見たことがあったり似たような内容の場合は静かな音読をせず、文字をそのままダイレクトに脳に送って理解できている感覚があります。ただ、初めての時や一度は見たがしっかりと理解しないままのものは無意識に静かな音読をしています。ただ、それ自体悪いことではないのかなと個人的には思います。文字をそのままダイレクトに理解できることに越したことはないですが、しっかり時間をかけてでも理解するためには必要な過程なのかなと思っているからです。

続けられるペースを把握する。
苦しいことを続けるのは難しいです。まずは苦しみから解放される必要がある。そのためには自分の認知能力の速度の限界を認める。マラソンに例えて、自分の継続できるペースを把握せず走ると途中でペースが落ちる。ペースが遅く感じても、それを守った方が結果的には長く走ることができる。そして長く走ると徐々に体力がついてペースが上がっていく。

読書に限らず生きる上で大切なマインドセットだと感じました。ただの言い訳でしかないのですが、私自身の性格がせっかちでいかにもな関西人の特徴を持っています。そんな中、経験上いいパフォーマンスが出る時は無意識であってもその時のペースやスピード感はあまり気にしすぎず自分のペースを保っているときでした。プログラミングを組んでいるときや学生時代に長く続けたサッカーのプレー中に一種のゾーンに入ったこともあります。なにより持続可能で少しずつでいいからステップアップするマインドセットが大切なのかもしれないです。
また、AIが日々進歩している現代においては自分のペースを守り自分の頭でしっかり考えることが大切になるのではないかと思っています。認知的完結欲求(意思決定をするときに、すぐに結論を出したい欲求)というものがあるみたいです。今はChatGptなどの生成AIを使ってコーディングだけでなく様々なビジネスシーンで利用されていると思います。私も毎日使用しますし今ではなくてはならないです。ただ、本当に気をつけないと思考する回数と深さが損なわれる恐怖を感じています。なので、AIに対しのプロンプトもただわからないことを投げるのではなく、実際に人間と対話をするように受け身でなく能動的な使い方になるよう意識をしています。

見出しなどへの注目
読み始める前に目次や見出しに注目する。本文よりも見出しの方がコストがかかっている。なぜなら見出しには「階層の深さはこれでいいか？」「内容とマッチしているか？」など

エッセイを読むのが好きなのですが、今まではただ何も考えず通読していました。ただ、最近は見出しや目次からザッと見てから読み始めるようにしています。やってみて感じることは本への理解度と想像力が少し養われているんじゃないかなということです。とりあえず通読するのではなく目次などを見るとあらかじめ筆者は「こういうことを言ってくるのでは？」と勝手に想像してながら読むようになります。いざ読んでみると全然違うことが書かれていることもザラですがそれでも本を受け身でなく能動的に読んでいる感覚がありますしより没入して読めることも多くなってきました。また、世の中にある本をすべて読むのは不可能なので、自分がその本を今読むべきなのかを目次を見て少し判断するようにもなってきました。

選択肢の数が意思決定の質にもたらす影響。
選択肢が2個に比べて3個だった場合は事後的に「とても良い意思決定だった」と判断される割合が16.7倍に増えた。

例えばラーメン屋さんで何十種類もある場合よりも3種類ほどから選んで食べた時の方が満足度に違いがある感覚は確かにありますね。プログラミングを学ぶ際にもついあれこれ悩んでしまって、手をつけるのが遅くなったりそもそもやらなかったりと余計な時間と負荷をかけてしまうことが往々にしてあります。やりたいことをまずリストアップして自分の中で優先度を3つまで決めて1つずつまずは試してみるのがいいアプローチな気がしてきました。今後意識していこうと思います。

探索範囲を広くする
目についたもの、少しでも興味の湧いたものを片っ端から学んでみる。大雑把にいろんな分野をつまみ食いする。何事も経験。

エンジニアとしての仕事に必要なことだけでなくプライベートで食べたことないものを積極的に食べるなど、個人的にいろんな分野にチャレンジする方ではあるので、今後も続けたいなと思います。
何事も、大小さまざまですが、いきなりアハ体験のように「あ？！あれはもしや...」みたいな閃きみたいなものを感じることがあるので。

他人からの知識の獲得コストは安い。
まずは15分自力で解決を試みる。15分試むのは他人の時間を無駄にしないため。それでも無理なら他者を頼る。なぜなら15分頑張っても解決できなかった人がさらに時間をかけても解決できる可能性が低いから。組織を経営する側から見ても人件費の無駄遣いとなる。

これは意識しないとなと思った。難解あるいは未経験なタスクや障害の対応時につまずく場面がきてもつい、時間をたくさん使ってでも自力で解決しようとしてします癖がある。最近はポモドーロを使って25分で作業を強制的にコントロールしているので、立ち歩いたりリフレッシュの時間を少しでも設けることで、適度な休息になり、ふとしたひらめきで解決できることもある。つい闇雲に解決しようとしがちだが、15分という明確な自力で向き合う時間を決めておけば、コスト面でも解決する可能性が高まるという面でもプラスに働くなと感じた。

・掛け合わせによる差別化戦略
世界には分野Xに詳しい人はたくさんいるが、部署内で最もXに詳しければ差別化を取れている。
・ふたこぶの知識
これからの日本に求められる科学技術人材は１つの分野のみに秀でた「I型」ではなく、「T型」や「π型」といった専門性の深さと幅広い専門性を兼ね備えた人材。周辺分野やまったく異なる分野にも幅広く興味を持ち、専門性の枠にとらわれないことが大切。

エンジニア5年目にしてやっと差別化がいかに大切かがわかってきた。今後、さらに進化の激しい世の中で不確実性がどんどん高まるはず。その中でどんな戦略を持って行動するかは重要だが、それが成功に必ずしも繋がるとはいえないことを意識しないといけない。だからこそ、様々なことにアンテナをはって興味のあるものからどんどん学習していきたいと思う。決して焦らず。いつかセレンディピティといわれる思わぬ発見があるかもしれない。あくまでも自分のペースで自分の頭でよく考えて持続可能な目標をたて、少しずつ前に進んでいこうと思います。現在、仕事では主にバックエンドの作業が多い。フロントエンドは入社1~2年目で多く経験して今のフェーズに至ります。インフラ(AWS)の経験が浅いのでここを実務で積極的に関われるよう自ら行動していきたいと思います。経験を積んで自分の幅を広げていきたいと思います。

まとめ

はじめての、qiitaへの投稿となりました。
文章の質は悪い気しかしません...。ただ、今回本書を読んでアウトプットできたことは自分としてはよかったです。理解の深さが変わった気がします。
今年一年は可能な限りの読書を継続してqiitaへアウトプットすることです。
徐々に頑張っていきます。