取引所の[Binance](/wiki/Binance)が運営している手数料が安い[暗号通貨](/wiki/暗号通貨)で、[スマートコントラクト](/wiki/スマートコントラクト)ができるので[DApp](/wiki/DApp)開発に有用。

Binance Smart Chain

世界トップの検索サービスを軸に様々なサービスを展開している企業。

もしくはそのサービスの名前。

[Googleのソフトウェアエンジニアリング](/wiki/Googleのソフトウェアエンジニアリング)だったり[SRE](/wiki/SRE)だったりエンジニア界隈に影響を与えることが多すぎる

Google

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/見積もり)

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


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

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

見積もり

カーボンを使ったヒーターのこと。
電気代が[ハロゲンヒーター](/wiki/ハロゲンヒーター)より安く、遠赤外線が2倍出るため電力効率に優れる。

カーボンヒーター


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

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

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

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

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


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

ビヨンセルール


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

通信、整合性、調整についてそれぞれ2パターンあり、組み合わせると合計8パターンのサーガ (アーキテクチャの大別) がある。

| パターン名       | 通信  | 整合性   | 調整         | 結合度   | 複雑さ   | 応答性/可用性 | スケーラビリティ |  
|-------------|-----|-------|------------|-------|-------|---------|----------|  
| エピックサーガ     | 同期  | アトミック | オーケストレーション | とても高い | 低い    | 低い      | とても低い    |  
| 伝言ゲームサーガ    | 同期  | アトミック | コレオグラフィ    | 高い    | 高い    | 低い      | 低い       |  
| おとぎ話サーガ     | 同期  | 結果整合性 | オーケストレーション | 高い    | とても低い | 中程度     | 高い       |  
| 時間旅行サーガ     | 同期  | 結果整合性 | コレオグラフィ    | 中程度   | 低い    | 中程度     | 低い       |  
| ファンタジーサーガ   | 非同期 | アトミック | オーケストレーション | 高い    | 高い    | 低い      | 低い       |  
| ホラーストーリーサーガ | 非同期 | アトミック | コレオグラフィ    | 中程度   | とても高い | 低い      | 中程度      |  
| パラレルサーガ     | 非同期 | 結果整合性 | オーケストレーション | 低い    | 低い    | 高い      | 高い       |  
| アンソロジーサーガ   | 非同期 | 結果整合性 | コレオグラフィ    | とても低い | 高い    | 高い      | とても高い    |

トランザクショナルサーガ

[万能チューリングマシン](/wiki/万能チューリングマシン)と同じ計算能力を持つこと。

チューリング完全


アプリ開発とかでチュートリアル的にスライドが何枚か出てくるやつのこと

語源は知らない

ウォークスルー


そのコンポーネントに障害が発生したらその障害がシステム全体に波及してしまう様なコンポーネントのこと。

Single Point Of Failureで略してSPOFとも言う。

システムを[グラフ理論](/wiki/グラフ理論)の[連結グラフ](/wiki/連結グラフ)だと思うと、単一障害点は[切断点](/wiki/切断点)であり、システム全体の[連結度](/wiki/連結度)は1である。

単一障害点


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

アーキテクチャ量子の定義  
  
> アーキテクチャ量子とは、高度な機能的凝集、高度な静的結合、同期／非同期による動的結合を持つ、独立してデプロイが可能なアーティファクトを指す。アーキテクチャ量子の一般的な例には、あるワークフロー内の整ったマイクロサービスなどがある。  
  
これはすなわち、データベースを共有しているアプリケーションは全て1つのアーキテクチャ量子である。  

アーキテクチャ量子


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



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


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

[アーキテクチャデシジョンレコード](/wiki/アーキテクチャデシジョンレコード)

[アーキテクチャ量子](/wiki/アーキテクチャ量子)

[アーキテクチャの分解に関するトレードオフ](/wiki/アーキテクチャの分解に関するトレードオフ)

[分散データアクセスに関するトレードオフ](/wiki/分散データアクセスに関するトレードオフ)

[業務データの分解に関するトレードオフ](/wiki/業務データの分解に関するトレードオフ)

[サービスの粒度に関するトレードオフ](/wiki/サービスの粒度に関するトレードオフ)

[トランザクショナルサーガ](/wiki/トランザクショナルサーガ)

[コントラクトに関するトレードオフ](/wiki/コントラクトに関するトレードオフ)

ソフトウェアアーキテクチャ・ハードパーツ


[グラフ理論](/wiki/グラフ理論)における[グラフ](/wiki/グラフ)の定義から、[辺](/wiki/辺)の集合ではない方の集合。

頂点

開発と運用を分けずに一緒にバランスをとっていい感じにしていこうぜというもの。
具体的な方法論としては<a href="/wiki/CI">CI</a>や<a href="/wiki/CD">CD</a>など。
実装として<a href="/wiki/SRE">SRE</a>がある。

DevOps