[暗号通貨](/wiki/暗号通貨)のうち、法定通貨と1:1での交換ができるもののことを言う。

運営会社が保証したり、[アービトラージ](/wiki/アービトラージ)が起こる仕組みを作ってシステマチックに保証したりしている。

ステーブルコイン

[ブロックチェーン](/wiki/ブロックチェーン)を使ったアプリでdecenterlized Appの略。



DApp

[SRE](/wiki/SRE)においてService Level Agreementの略で、対外的に満たすことを約束している指標のこと。

正常応答率99%を目指そう！と内部的に言うなら[SLO](/wiki/SLO)だが、対外的に約束してしまうとSLAになる。


Site Reliability Engineeringの略で運用と開発のバランスをとって信頼性を担保していく方法論のこと。

[DevOps](/wiki/DevOps)の実装とも言われる。

[Google](/wiki/Google)が提唱したり[Googleのソフトウェアエンジニアリング](/wiki/Googleのソフトウェアエンジニアリング)で触れられたりしている。

基本的な用語
- [SLI](/wiki/SLI)
- [SLO](/wiki/SLO)
- [SLA](/wiki/SLA)
- [エラーバジェット](/wiki/エラーバジェット)
- [トイル](/wiki/トイル)
- [オンコール](/wiki/オンコール)
- [50%ルール](/wiki/50%ルール)


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

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

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

プルーフオブステーク

機械学習


[潜在変数](/wiki/潜在変数)がある空間

潜在空間


飲んだコーヒー豆を記録しておく

- [カルディリッチブレンド](/wiki/カルディリッチブレンド)
- [エイジドマンデリン](/wiki/エイジドマンデリン)
- [コスタリカエルアルコン](/wiki/コスタリカエルアルコン)
- [ホンジュラスパトリアルカ](/wiki/ホンジュラスパトリアルカ)
- [コスタリカフィデルス](/wiki/コスタリカフィデルス)
- [珈琲問屋冬のブレンド雪灯り](/wiki/珈琲問屋冬のブレンド雪灯り)
- [モカシダモG4](/wiki/モカシダモG4)
- [ニカラグアリンダビスタ農園](/wiki/ニカラグアリンダビスタ農園)
- [ブラジルショコラ](/wiki/ブラジルショコラ)
- [コロンビアスプレモ](/wiki/コロンビアスプレモ)
- [エメラルドマウンテン](/wiki/エメラルドマウンテン)
- [クリスタルマウンテン](/wiki/クリスタルマウンテン)
- [ソルデラマニャーナウォッシュド](/wiki/ソルデラマニャーナウォッシュド)
- [キリマンジャロAA](/wiki/キリマンジャロAA)

飲んだコーヒー豆リスト


[Bitcoin](/wiki/Bitcoin)の論文を公開した人物。匿名であり誰なのかはわかっていない。

サトシナカモト


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

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

見積もり


https://mickindex.sakura.ne.jp/schlick/schlick_MV_jp.html

ある命題が立てられているとき、この命題が有意味であるか無意味であるかという問いを立てるとしたならば、その命題が有意味であるための条件が問われている。
命題が有意味であるとはそれが検証可能であるということだ……という考え方が、意味の検証理論

意味の検証理論


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


メインの[暗号通貨](/wiki/暗号通貨)の[ブロックチェーン](/wiki/ブロックチェーン)と連携する目的で作られた別の[ブロックチェーン](/wiki/ブロックチェーン)のこと。

サイドチェーン


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

あんまりだった
さすがに安定している味だったが

珈琲問屋冬のブレンド雪灯り

https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A6%8B%E7%A9%8D%E3%82%8A-%E4%BA%BA%E6%9C%88%E3%81%AE%E6%9A%97%E9%BB%99%E7%9F%A5%E3%82%92%E8%A7%A3%E3%81%8D%E6%98%8E%E3%81%8B%E3%81%99-%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%96-%E3%83%9E%E3%82%B3%E3%83%8D%E3%83%AB-ebook/dp/B00KR96M6K  

[見積もり](/wiki/見積もり)

ソフトウェア見積もり_人月の暗黙知を解き明かす

<p>「そんなに好きならそいつにテスト付けときゃよかったのに」</p>


ビヨンセルール