はじめに

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

この本の特徴

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

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

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

不確実性マネジメント

前提知識：「エンジニアリング」は不確実性を削除すること

不確実性の詳細：
将来わからないことから生じる方法不確実性と目的不確実性
他人とのコミュニケーションの失敗や不足によって生じる通信不確実性

人は不確実なものと向き合うときに「不安」が生まれ、そのことを奥底に隠してしまう習性がある。
不確実性をマネジメントするために、
不安によって隠れた不確実な要素をリストアップして、それらを比較する必要がある。

ここからは、
新卒がチームにとっての不確実性にならないため,
自分の仕事においての不確実性をなくすために必要だろうと思ったことを
ピックアップして噛み砕いて説明していきます。

スケジュール予測の方法を知る

まず、時間の考え方から変える。「早くおわる」ということが一概に重要ではなく、
「どのくらい時間がかかりそうなのか正確に知ることができる」ことが重要。

プロジェクトマネジメントの観点でいうと、
スケジュールの不安に向き合うことができないまま、それを管理できないまま、
状況がどんどん見えなくなることが良くないということ。

→そのために、見えないスケジュールをどう可視化していくかで、現場のストレスを削減していく。

スケジュール不安の見える化

不安量の大きいタスクを分解する

個別に不安料の大きいタスクをみていくことで、
「どこが不安なのか」「何をすれば不安でなくなるのか」が見えてくる。
この基準にタスク自体を分解することで、不安量の大きいタスクと小さいタスクに分解できる。
ソフトウェア開発において、スケジュール不安の発生源になるようなものが
例として以下ようなものがある

• 使ったことのないライブラリの使用
• うまくいくかわからないアルゴリズムの使用
• 外部との連携
• 詳細仕様の未決定
• 影響範囲が読みきれない

小さいスプリントを繰り返す

アジャイルな開発方式において、
開発サイクルは「スプリント」と呼ばれる小さなタイムボックスに区切られる。
プロダクトの性質にもよるが、1週間から1ヶ月が一般的で、
開発サイクルを決めて、チーム人員を固定する。
そうすることで、同じようなタイムボックスが繰り返されていくので、
「発生した実績から将来の予測」を行いやすくする。

(例)
合計100のストーリーポイントのタスクがあったとして、
直近のスプリントでは20のストーリーポイントのタスクがあったとし、
すべてのタスクが完了するまでの時期を推定したいのであれば、
おおよそ5スプリントの期間で完了するだろうと計算できる。

このように、スプリントごとにどれだけの実績をだせたのかという
数値をチームの「ヴェロシティ（Velocity）」と呼ぶ。
今回はチームとしての開発で考えたが、
個人でもこのヴェロシティは作ることができるため、参考にしていきたい。

おわりに

5章もあるのですが、まだ汲み取れる部分が少なかったので、またの機会に書きたいと思います！