本書を読もうと思った背景

先進的なコミュニティ運営

エンジニアを目指すきっかけの1つに先進的なコミュニティ運営というものがある。

これらの事柄から 先進的であり、自分自身もその環境に飛び込み、体感したい と思った。またそのような 優秀で先進的かつ能動的で向上心がある人達と同じ空間で働きたい（関わりたい） と思った。

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

1章 ソフトウェアエンジニアリングとは何か

ソフトウェアエンジニアリング ≠ プログラミング である。

エンジニアリングは、もっと包括的な意味合いで使う。

プログラミング とは、コードを生産するもの
ソフトウェアエンジニアリングとは、生産したコードを有用性のある稼働期間中は保守にするようにプログラミングを拡張する

コーディングの2つのパターン / アップグレートのパターン

たまたま動く(寿命が短い)

• スタートアップなどが多い。
• 稼働期間が短い。
• インフラは、外部のサードパーティを使用したほうが効率が良い。
• アップグレードしない、または緊急時は変更できる技術がある.またわかる状態にする。

保守性がある(寿命が長い)

• 大企業などが多い。
• 稼働期間がほぼ無限にあるもの
• インフラは自社で作成したほうがよい
  • なぜなら、外部のツールはいつ使えなくなるかわからない。
  • 依存度が高い。
• 定期的にアップグレードできるとよい
  • アプリケーション内での自動アップデート
  • 稼働しながらアップデートできるとよい
  • ユーザーに託すのはよくない（意思決定を避ける）

保守性を持たずに実装すると，茹でガエル理論的なことが起きます。

Hyrumの法則（ハイラムの法則）

さらにわかりやすく....
APIを作成した人が想定する挙動よりもユーザーが使用する中で見つけ出した使い方の方が正しい。

繰り返し実行するタスクはスケーラブルであるべき

超線形のスケールは持続可能でない

スケーラビリティとは、機器やソフトウェア、システムなどの拡張性、拡張可能性のこと。スケーラビリティの高いことを「スケーラブルな」（scalable）と表現することもある。

例えば、タスク量に応じてエンジニアの時間が超線形的に拡大するときにスケーラブルでないという。

間違いを認める

データ駆動文化では以下のようなことが大切になる。

• 間違いを認める能力
• 必要性

開発が進むと新たなデータが入ってきて、コンテキストが変化していく、それを柔軟に変更できるか、認められるか。

• 最初に決定が行われた後に変更する能力

2章 チームでうまく仕事をするには

（前提）孤独に仕事をするときのトレードオフ

コードを隠さない

• 創造的なプロジェクトは1人で作成するという神話はない
• チームでの開発が重要になる
• みんな見せるのを怖がらない

大きな不具合や改善点に初期段階で気づける。

• バス係数

バス係数とは「プロジェクトメンバーが何人バスに轢かれたらそのプロジェクトが破たんするか」という数値です。 実際には病気で倒れたり、急用でお休みする必要が出てきたり、転職で出て行ったりということになります。 このバス係数が高い値であるほどしっかりと丈夫なプロジェクトであると考えられる。
引用 : SIBYL System

謙虚・尊敬・信頼の実践

より具体的に以下に記述していく。

• エゴを捨てる

自分が最重要人物であるかのように振る舞うのをやめる

• 批判の仕方と受け方を学ぶ

• エンジニアリングでは、個人ではなく、プロジェクトに対しての批判がほとんど
• 自分の存在と自分のコードは別
• 伝え方に気をつける
  - FBの基本 肯定してから自分の意見を伝える
• 人の評価とコーディングスキルではなく、コード自体を評価する

• 失敗を加速して、反復する

• 失敗とは前に進む1つの手段という捉え方

引用 : 心理カウンセリングのフルフィルメントさんより

• 自分の失敗をドキュメント化する
  以下が具体的な方法論
  1. 分析対象イベントの簡潔な要点
  2. 発見から調査を経て解決に至るまでの文s計対象イベントのタイムライン
  3. 分析対象イベントの主要原因
  4. 影響と損害の評価
  5. 問題を直ちに修正するための一連のアクションアイテム
  6. 分析対象イベントを再度発生するのを防ぐための一連アクションイベント
  7. 学んだ教訓

• 影響に対して寛容である

• 傾聴の大切さ
• 他者の誰かのおかげで自分の考えが変化することをポジティブに捉える
• 自分の話を聴いてもらうには，相手の話をまず聴くという心構え
• ある人が無知を認めたらそれを称賛する仕組み

• Google的である。

• 曖昧さの中にあっても成功する
• フィードバックを尊重する
• 現状に立ち向かう
• ユーザーを第一に置く
• チームを思いやる
• 正義を為す

3章 知識共有

組織での学びの文化の重要性

学びを阻むもの

• 心理的安全性の欠如
• 情報の孤立化

• 情報の断片化
• 情報の重複
• 情報のスキュー

同じことを行うのに互いに競ったり競わなかったりする

• 単一障害点（バス係数）
• 全てか無か（上級者と初心者の2分化される）
• 猿真似（コードを真似て理解しない）
• 幽霊が出る墓地（恐れて触れない場所）（割れ窓理論）

チームとのコミュニュケーションの重要性

心理的安全性

• メンター制度

• 質問しやすい
• 互いに学ぶこと
• 上記に対して寛容である

• 集団でのアンチパターンと推奨パターン

自分の知識の発展

• 質問する

• 1人で考え込まない
  『常に学び続けよ，常に質問し続けよ』

• 文脈を理解する
• 情報を発信する
• ドキュメンテーションを書く

• 読者が何かを学ぶのを手伝うのが目的である
• 別の視点から、インセンティブが適切にあるとなお良い

• 情報の輪に参加し続ける

4章 公正のためのエンジニアリング

バイアスがデフォルト状態

• バイアスがあることを認める

アルゴリズム自体がダイバーシティが低い可能性がある。
参考までに以下に詳細あり。

https://globe.asahi.com/article/12287524

• どの時点でバイアスがよりかかっているか理解する。

• 世界向けのアプリケーションは、どこかの文化にはポジティブな影響を与え、どこかの文化にはネガティブな影響を与える可能性がある。
• AIの識別段階ですらありうる。
• テクノロジー分野で見られる制度的差別は我々すべての責任であるという心構えが必要になる。
• 包括的なユーザーベースを対象に設計を行うには、多様性が重要

ステークホルダーすべてにインクルーシブに向き合う

• 万人のための開発でなく、万人で開発する
• 製品を使う際にもっとも大きな障害のあるユーザーのために設計する
• 公正であるという思い込みを捨てる

これらには、『理解した』という考えを捨てる必要がある。
継続的改善がとても大切である。