はじめに

新卒でPdMの役職として配属され、一歩目の本としてはめちゃくちゃ難しい一冊だったので、
「新卒」が理解できた、重要だと思った部分をいくつか抜粋して記事を書いていきます。（3投稿目）

この本の特徴

この本の大前提として、
Webエンジニアとしての仕事とは「良いコードを書くこと」「悪いコードをリファクタリング」することではなく、
問題解決のために、コードのみならず、
人々の思考・組織・ビジネスの「構造」をリファクタリングするということ。
それこそがエンジニアリングの本質だということ
※リファクタリング：外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること

エンジニアの問題としての根源は「わからない」という不安にある。
しかし、その先が見えないなどの「わからない」という「不確実性」の扱い方を知れば、
「不安」が「競争力」に変わる。
エンジニアリングに必要な思考はこの「不確実性」を力に変える点。

この「不確実性」→「力」の方法を構造化して伝えている一冊。

アジャイルなチームについて

アジャイルはチームをメンタリングする技術ということ

アジャイル開発とは？

チーム全体に対して、メンタリングを行い、開発出力を向上させる方法論
ソフトウェアをどのように作るか？はアジャイルの主眼ではなく、
ソフトウェア開発を行うチームをどのように構築していくか？がアジャイルの目的になる

日本はアジャイル実践者の数が圧倒的に少ない

アジャイル開発の主流な方法論の一つである、「スクラム」を理解している人が日本には圧倒的に少ない。
つまり、アジャイル開発普及の障害にもなっている。
→メンティであるものの、今知っておけば自分が開発の障害になることなく、うまくチームのプラスになれると思う。

アジャイル開発が必要な2つの理由

ソフトウェアが大規模化・複雑化
日本の多くは製造業や宇宙開発で用いられたプロセス管理の手法をそのまま転用していた
そのため、実際に価値のあるソフトウェアの実装よりも関係調整やドキュメント化といったことに時間を使う
→大規模になれば失敗が多くなってきた
＝複雑性の管理に時間を使って、完了しないプロジェクトが増えていった。
近年、ソフトウェア開発の投資規模が大きいのにも関わらず、
完成品と顧客が求めているものの乖離が大きくなってきた（経営の大きな課題になる）
マーケットの不確実性に対応する必要性が出てきた
マーケットがプロジェクト期間中に大きく変動することが頻繁に発生するようになった。
→時間と費用をかけたにも関わらず、それが顧客のニーズに合うか最後までわからないという
事態を避けたいという企業の論理が働くようになってきた。

アジャイルな状態とは？

情報の非対称性が小さい
認知の歪みが少ない
チームより小さい限定合理性が働かない
対人リスクをとれていて心理的安全性が高い
課題、不安に向き合い不確実性の削減が効率よくできている

よくあるアジャイル開発の誤解（新卒目線で大事なこと）

アジャイルなチームとそうでないチームを比較したときに、個々のメンバーを眺めたときに、
アジャイルなチームの方が優秀なメンバーが揃っていることが多く見受けられる

→初めから優秀なメンバーが揃っているわけではないことを理解しておく

アジャイル開発は組織学習をプロセスに取り込んでいて、
チームにフォーカスし、メンバーには自立性が求められ、課題と直面できる必要がある

→すぐに優秀になれるわけではないが、
新卒の自分が問題に自律的に直面して解決していくことが、チームの成長を促すことになる。

そのために自分ができること

→おそらくチームの中で成長や仕事面で言うと周りから不確実性の高い存在になりやすいとおもう
（新卒で配属されたばかりで自分の能力や考え方がチームに浸透してないから）
そういった中で、自分ができることは

自分が不安因子となりすぎないように振り返りや学習を通して、（チームにとっての）不確実性を減らしていく
少人数の対話を重視してみる
→情報の多い対面でのコミュニケーションによって情報共有を行い、「情報の非対称性」を減らす。情報の非対称性を減らせることで、お互いの距離感を正確に測っていける
経験のみを知識に変える
→作業見積もりなどはいい加減になりがちで、正確になるとは限らない。
なので作業実績（過去の実例）を正確な数値として測る。
その後に見積もりとの差を測り続け、見積もりの精度を上げていく。

このコンセプトで、方法や目的の不確実性に向き合っていく。

この3つを行なっていくことだなと感じた。

おわりに

つづいて、4章に移ります！

【読書】新卒が「エンジニアリング組織論への招待」を読んでみた③