#Book [[📒エンジニアリングマネージャーのしごと]] ## 14.1 コミュニケーションが[[🗃️ソフトウェア]]の設計を決める - [[🗃️コンウェイの法則]] ## 14.2 ギルドでサイロを壊す ## 14.3 トークの文化を奨励する - [[🗃️チーム]]の人がローテーションで話すための定期的な[[🗃️LT(ライトニングトーク)]]の枠を作る ## 14.4 問題を学習の機会に変える ### 5why - システム障害が起きた時の原因を5回のなぜで問題を深掘りする - なぜアプリケーションがダウンしたのか？ - APIがリクエストに応答しなくなったから - なぜ？ - 本番環境はテスト環境よりも同時リクエストが多く、スレッドセーフではないデータ構造を使っていた - なぜ？ - 開発中に考えられていなかった - なぜ？ - 自動テストは高不可じのシナリオをカバーしていない。 - 5Whyを実行するときは、質問と答えや結果を誰かが確実に記録するようにする ### マネジメントバグ - ソフトウェアのチケットのように[[🗃️マネジメント]]に関するバグもチケットで管理するようにする - 💭これちょっと考えていたアイディアだ。 - 方法 - 誰でも問題の説明を書いた「マネジメントバグ」のチケットを上げられる - チケットを取り上げ、ワークフローに入れる。ワークフローは[[🗃️カンバン]]が管理しやすい。 - チケットが完了になったら、問題と行われたアクションのまとめを書く。 - 完了したチケットを誰でも見える共有フォルダーに置く - 💭[[🗃️Github Disccusions]]使ってもいいかも ## よくある問題を解決するツール ### このコードはなぜこうなっているのか？ - [[🗃️ADR(Architecture Decision Record)]] - 決定を下したタイミング - ADRのステータス - 決定へと導いた現在の状況、ビジネス上の優先順位 - 決定そのもの(結果何をするのか) - 変更による影響 ### チームは時間と共に改善しているか？ - ヘルスチェック - 年に数回行い、その結果を記録することで、チームは時間と共にどんな傾向を示しているかを把握できる - ヘルスチェックの実施方法 - チームメンバーが様々な観点から現状を議論するためのワークショップを実施する - 結果をグラフにしてまとめる - チームの状況を改善するために、データを積極的に活用する - Spotifyモデル(ひどい、どちらでもない、 素晴らしい) - コードをリリースするのは簡単か？ - 現在のプロセスは最適なものか？ - コードベースの健全性 - チームが届けた価値 - 物事を終わらせる速度 - チームのミッションの明確さ - どれくらい楽しいか？ - チームは新しいことを学習しているか？ - チームは必要なサポートを得られているのか？ - 自分たちは駒なのかプレイヤーなのか？ - 四半期ごとでにできると良いだろう。 - 他チームにもやってもらって、比較できると良いだろう。 - 💭[[🗃️SPACE]]的なやつなのかな。 ### 誰に責任があるのか？ - 明確なオーナーがいないせいで、大事なことが見落とされることがある。 - Appleでは、この問題に対処するために、直接責任者([[🗃️DRI(Directry Responsible Individuals)]])という概念を使った。 - 💭誰が責任を負うのかは明確にしておくことで、スムーズにコミュニケーションできるケースはありそう。責任者という言葉が強くて、チームには提案し辛い。 章 デュアルラダー