Team Geek そのに
実は翻訳なさった角さんからご献本頂いてたり。非常に良い出会いに感謝です。誠にありがとうございます。
この本、エンジニアが書いた本の典型みたいで極限まで無駄な情報が省いてあるように見えます。
- ミッションステートメントとしてこの本の目的が簡潔に述べられている
- 曰く、_本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。_とのこと
- はじめに、の章でも目的が簡潔に述べられている
- 曰く、_優れたソフトウェアを書きたい? 本書は君のための本だ_
- そして「はじめに」の章の最後で_プログラマとして成功する_ためにどうすべきか、という事が書いてあります
最初にどうあるべきか、を簡潔に申し述べた後にそれを踏まえて必要な事項が簡潔に列挙されていきます。
本題に入る前に
この書籍、管理レイヤとか経営レイヤとか営業レイヤにいらっしゃる方々に、と思っていたのですがおそらくこれは間違いです。上にも書いた通り、この書籍は_プログラマとして成功する_ためにこれを読む Geek がどうするべきかが書いてある、という意味ではこれは若い方々に是非目を通すべきものだな、と今は強く思っています。
1 章以降
ポイント列挙しつつ纏めることができるのかどうか。
- 1 章ではこの本の theme が挙げられています
- ソフトウェア開発の社会的危機って日本だけに顕著な問題ではないのか (絶句
- 1 章のテーマは開発はチームスポーツである、という事
- エンジニアリングチームで成功するためにどうあらねばならないか
- HRT と postmortem
- 2 章ではチームが成功の文化を作りかた、が書いてあります
- これ、色々と苦労した記憶あり
- ミッションステートメント
- 3 章ではエンジニアリングリーダーシップについて理解せよ、とあります
これら、組織の中の人達の面倒を見てた経験上、非常に大切なポイントが適切に、かつ簡潔に列挙されている事が分かります。
そして 4 章以降はチーム外部とのやりとりにフォーカスが当てられていきます。
- 4 章ではチームの文化を破壊するアウトサイダーからチームを守る方法
- 5 章では組織的操作について
- 6 章ではユーザーエンゲージメントの 3 つのフェーズの調査について
そして付録 1 のエピローグにおける止めも素晴しい。もう年だけど、プログラマとして成功したいな、と再び思ってしまいました。頑張ろう。
そして以下に諸々材料を追記します。
メイル
「3 つの箇条書きと行動要請」のテクニック、も以前サツ上がりの上司を持っていた時分にかなり厳しく指導された記憶があります。そして大切なのが_メールには HRT を込めること_でしょうね。
チーム運営のベストプラクティス
- ミッションステートメントを決める
- メールでの議論マナーを設定
- 履歴を文書化
- 効果的なコラボレーション
- バグ修正・テスト・リリースに関する明確なポリシーや手続きの定義
- 参入障壁を低く
- 合意ベースの決定を信頼
- 衝突解消のプロセスも定義
ミーティングのルール
2 章でミーティングを開くときの 5 つのルールが列挙されている。
- 絶対に必要な人だけを呼ぶ
- アジェンダを作ってミーティング開始時に配布する
- ミーティングのゴールを達成したら時間前でも終了する
- ミーティングを順調に進める
- ミーティングの開始時間を強制的に中断される時間 (お昼安みや就業時間) の前に設定する
postmortem について
- 過ちから学ぶには失敗を文書化
- 以下の事項が含まれるべき
- 概要
- イベントのタイムライン (調査開始から解決に至るまで)
- イベントの根本原因
- 影響と損害の評価
- すぐに問題を解決するための行動一式
- 再発を防止するための行動一式
- 学習した教訓
これ、障害報告書ですね。わははは。
レビュ下書き
上記を見つつ再読しつつ検討の方向。
