
[ソフトウェア見積もり_人月の暗黙知を解き明かす](/wiki/ソフトウェア見積もり_人月の暗黙知を解き明かす)の内容が書かれている。

## 第1部 見積もりの考え方  
### 第1章 見積もりとは  
  
- 「見積もり」「ターゲット」「コミットメント」の違いを意識する  
  - 見積もり：そのままの意味  
    - 「この機能の実装は何人日」  
  - ターゲット：実現したいビジネス上の目標  
    - 「何日までにこの機能を提供したい」  
  - コミットメント：機能を一定のレベルで期日までに納品するという約束  
    - 「何日までにこの機能を提供します」  
- 見積もりと計画の違いを意識する  
  - 見積もりは正確性が重要  
  - 計画は結果が重要  
  - 偉い人にターゲットを達成するための計画を聞かれているのに見積もりを単に答えてはいけない  
    - 「このプロジェクトは何人月？期限は３ヶ月なんだ」  
    - 「見積もってみたところ５ヶ月かかります」  
    - 「ふざけるな！」  
  - 開発と期日どちらが優先かどうか尋ねる  
- 良い見積もりとは偉い人の意思決定に寄与する見積もりのこと  
  
### 第2章 見積もり能力のチェック  
  
- 直感で「90％確か」な見積もりは、実際には「30%確か」  
  - なので直感で90%とか言ってはいけない  
- 見積もりなんて幅があって当然。無理に狭めようとしない  
  
### 第3章 正確な見積もりの価値  
  
- 意図的に過小に見積もることはすべきではない  
  - 過大見積もりよりも深刻な被害が起きる  
  - では過大にすれば良いかというとそうでもなく、それなりに大きくしてあとは計画とコントロールで対処せよ  
  
### 第4章 見積もり誤差はなぜ起きる？  
  
- 見積もり期間を増やしても見積もりの不確実性は上がらない  
  - プロジェクト自体があやふやなのではどんなに頑張っても上がらない  
  - 見積もり期間を増やすのではなく、要件定義や設計を固めることでしか上がらない  
- 休暇、病欠、トレーニング、ミーティング等は必ず発生する。そのためのゆとりをもたせる  
- 開発者の見積もりはすでに必ず楽観的であるので削ってはいけない  
- 見積もりに「コントロールノブ」を持たせてはいけない  
  - コントロールノブとは見積もりに入れる主観的判断のこと  
  - 見積もりの客観性と共に正確性も落ちる  
- 即興の見積もりはしない  
  - たった15分の見積もりでさえもっと正確になる  
  
## 第2部 見積もりの技法の基礎  
  
### 第7章 数えて、計算して、判断する  
  
- できるときはまず何かを数える  
- 数えられない場合にのみ計算する  
- 計算すらしないのは最終手段  
  
### 第9章 専門家の判断  
  
- タスクで分解して見積もるときは長くても2日程度の粒度にする  
  
  
## 感想  
  
「技術者の見積もりは常に楽観的」というのはその通りだと思った。  
幅がある見積もりの中で最小の部分を提出する傾向があるような気がしているし、  
実際過小に見積もる圧力があるということも書かれていた。  
  
一方で、数えるだけの方がよほど正確に見積もれるというのは不思議だった。さすがにコード行数で数えるのはどうかと思うが。  
  
過去の開発にかかった工数と関連データの保存および可視化が出来ていないと不可能な手法ではあるので、これらの重要性はかなり高い。  
  
生産性向上とか言っておいて生産性を測る指標を可視化していないなんてことがザラにある状態では正確な見積もりなんて望めないということかもしれない。

見積もり

[ブロックチェーン](/wiki/ブロックチェーン)を用いた[暗号通貨](/wiki/暗号通貨)では、最も長いチェーンが有効とされる。

したがって、その分散ネットワークの全参加者のうち51%の信頼を獲得すれば、1人で最も長いチェーンを繋げることができる。これはつまり自由に台帳に取引履歴を書き込めるということで、そうなったら[暗号通貨](/wiki/暗号通貨)は終わる。

例えば[プルーフオブワーク](/wiki/プルーフオブワーク)では51%の計算リソースが必要で、[プルーフオブステーク](/wiki/プルーフオブステーク)では51%の[暗号通貨](/wiki/暗号通貨)が必要である。

[Bitcoin](/wiki/Bitcoin)等の規模が大きいネットワークでは攻撃はかなり難しいが、規模が小さい[暗号通貨](/wiki/暗号通貨)では実際に起こっている。

実例

https://coinpost.jp/?p=175687

51%攻撃

[グラフ](/wiki/グラフ)に関する数学の理論のこと。

グラフ理論


計算モデルの一種で、同時期に提唱されていた他の計算モデルと同等の[計算可能性](/wiki/計算可能性)だった。

そのため、チャーチ＝チューリングのテーゼによってこれを計算可能であることの定義としよう、ということが提唱された。

チューリングマシン


https://www.oreilly.co.jp/books/9784873118864/

[CLEAN](/wiki/CLEAN)

レガシーコードからの脱却


鉄クロム線を石英管内にフィラメントとして設置したヒーターのこと。
値段は一番安い。
電気代が比較的高めだが、[ハロゲンヒーター](/wiki/ハロゲンヒーター)よりも少し安い。
一方で[ハロゲンヒーター](/wiki/ハロゲンヒーター)よりも暖かくない。

石英管ヒーター

大手取引所の[Binance](/wiki/Binance)が発行している[暗号通貨](/wiki/暗号通貨)。

[Binance_Smart_Chain](/wiki/Binance_Smart_Chain)という[Ethereum](/wiki/Ethereum)互換チェーンで使われる。




拡散モデル

[エンコーダーデコーダーモデル](/wiki/エンコーダーデコーダーモデル)で、ノイズを混ぜた画像からノイズ無しの画像を推論する訓練をすることで、最終的には無から画像を生成できる

モデルは[VAE](/wiki/VAE)

Diffusionモデル


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)

雑味多め、味薄め
ただし確かに超ビターコーヒーのような風味というか後味が少しある
ミルクを入れたらカフェモカっぽい風味になるかもしれない

ブラジルショコラ

以下の様にプログラミングすること

- 問題を小さな塊に分解し、それらを縫い合わせる  
- 最初に実装してしまうと全体が見えなくなる

対義語は[アウトサイドインプログラミング](/wiki/アウトサイドインプログラミング)

https://www.oreilly.co.jp/books/9784873118864/

インサイドアウトプログラミング


[ライトニングネットワーク](/wiki/ライトニングネットワーク)の[Ethereum](/wiki/Ethereum)版。

ライデンネットワーク


[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)

なんかあんまり美味しくない
ほげほげマウンテンはあんまり好きじゃ無いのかもしれない
苦味が薄めな感じ

クリスタルマウンテン


可能な限りチームメンバーに仕事を移譲し、自身はチームメンバーが円滑に仕事をすることができるように仕えるというやり方



サーバントリーダーシップ


https://www.oreilly.co.jp/books/9784873119656/

[サーバントリーダーシップ](/wiki/サーバントリーダーシップ)

[QuANTS](/wiki/QuANTS)

[ビヨンセルール](/wiki/ビヨンセルール)

Googleのソフトウェアエンジニアリング


[コンセンサスアルゴリズム](/wiki/コンセンサスアルゴリズム)の一種。

[プルーフオブワーク](/wiki/プルーフオブワーク)が計算量で信頼を得るのに対し、こちらは[暗号通貨](/wiki/暗号通貨)の保有量で信頼を得る。

その[暗号通貨](/wiki/暗号通貨)に[51%攻撃](/wiki/51%攻撃)をするためには51%の通貨が必要だが、当然クラックされた通貨は暴落するため、攻撃する経済的理由が無くなる、というのがプルーフオブステークの理屈。

プルーフオブステーク

<p>与えられた命題が真であることを、それ以外の情報を与えずに証明すること。</p>


ゼロ知識証明