[SRE](/wiki/SRE)において、[SLO](/wiki/SLO)と現在の[SLI](/wiki/SLI)の値の差のこと。
この分だけ品質を下げられるということなので、その余剰資産を使って新機能の開発などのリスクを取ることができる。

エラーバジェット

Continuous Deliveryの略で、本番環境までのデプロイを自動化して安定かつ高速にリリースしようぜというやつ。

[CI](/wiki/CI)とセットでCI/CDと呼ばれる。

[DevOps](/wiki/DevOps)


[機械学習](/wiki/機械学習)においては[中間層](/wiki/中間層)の変数のこととほぼ同義

中間層はだいたい入力より次元が低く、その次元で入力の特徴を捉えるようにチューニングするので、入力の特徴だけを捉えたものになる

関連：[潜在空間](/wiki/潜在空間)

潜在変数


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

無難な味で結構使いやすい
安いし

モカシダモG4


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



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


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

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

見積もり


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)

所有していないデータにサービスが読み取りアクセスするためには様々な方法があり、その間にもトレードオフがある。  
  
- サービス間通信パターン  
  - サービス間がWEB API等で通信してDBを隠蔽する  
- 列スキーマレプリケーションパターン  
  - 非正規化する  
- レプリケーションキャッシュパターン  
  - 分散キャッシュする  
- データドメインパターン  
  - 愚直に一緒にDBを見てしまう

分散データアクセスに関するトレードオフ


[頂点](/wiki/頂点)の列であり、各[頂点](/wiki/頂点)とその次の[頂点](/wiki/頂点)との間に[辺](/wiki/辺)が存在するようなもののこと。

[暗号通貨](/wiki/暗号通貨)の[L2ソリューション](/wiki/L2ソリューション)において、セカンドレイヤーで処理したいくつかのトランザクションをまとめてメインのチェーンに保存するような方式のこと。

大きく分けて以下の2つに分かれる。
- [Optimistic Rollup](/wiki/Optimistic Rollup)
- [ZK_Rollup](/wiki/ZK_Rollup)

Rollup


[ソフトウェアアーキテクチャ・ハードパーツ](/wiki/ソフトウェアアーキテクチャ・ハードパーツ)

アーキテクチャの分解には[コンポーネントベース分解](/wiki/コンポーネントベース分解)と[戦術的フォーク](/wiki/戦術的フォーク)という2種類のやり方があり、それぞれメリットとデメリットがある。

[戦術的フォーク](/wiki/戦術的フォーク)は[コンポーネントベース分解](/wiki/コンポーネントベース分解)と比べて以下のような特徴がある。

- メリット
  - 事前の分析が不要なので作業開始が早い
  - コードは抽出するより消す方が簡単 (と書かれていたが本当か？)
- デメリット
    - 不要なコードを消す努力が必要
    - ロジックは汚いまま

アーキテクチャの分解に関するトレードオフ


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

[CLEAN](/wiki/CLEAN)

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

裏切り者がいるかもしれない時に、どのように分散的に合意するかという問題。

転じて、間違う可能性のある分散システム上でどのようにデータに合意するか、という問題の基本的なバージョンと考えられる。

かの有名なLamport先生を含む3人が1980年の論文で合意問題として定式化したらしい。

https://dl.acm.org/doi/10.1145/322186.322188

最初の解決策も1982年にLamport先生たちが論文を出した。

https://dl.acm.org/doi/10.1145/357172.357176

この問題は裏切り者が1/3以上いる場合は解決出来ないことが知られている。

この合意が取れるシステムはビザンチン障害耐性 (Byzantine Fault Tolerance) があると言う。

分散システムの問題なので[暗号通貨](/wiki/暗号通貨)でもよく語られる問題である。

ビザンチン合意


モノリスからサービスベースアーキテクチャを経てマイクロサービスへ移行していくためのやり方のうちの一つで、以下の様な手法。

- まずは[リファクタリング](/wiki/リファクタリング)し、モジュールを分けていく。
- 分けられたモジュールをサービスに切り出す。

[戦術的フォーク](/wiki/戦術的フォーク)と比べて以下の様なメリットがある。

- 不要なコードは生まれない
- ロジックが綺麗になる

コンポーネントベース分解

[Ethereum](/wiki/Ethereum)の[L2ソリューション](/wiki/L2ソリューション)の一つ。

[Optimistic_Rollup](/wiki/Optimistic_Rollup)を採用したもの。

Optimism

[飲んだコーヒー豆リスト](/wiki/飲んだコーヒー豆リスト)
フルーティー感あるのであんまり
すごい嫌いとかでもない

コスタリカフィデルス

<p><a href="/wiki/%E3%82%B0%E3%83%A9%E3%83%95">グラフ</a>において、最小で何個の頂点を取り除くと<a href="/wiki/%E9%9D%9E%E9%80%A3%E7%B5%90%E3%82%B0%E3%83%A9%E3%83%95">非連結グラフ</a>になるか、という数。</p>


連結度