はじめに
ソフトウェアアーキテクチャの基礎 22章は「効果的なチームにする」です.
チームリーダーを始めてから2年ちょっと経ちました.
ソフトウェアアーキテクチャという文脈ですが,
効果的なチームを目指せるように, この書籍の内容を活かしていきたいと思います.
ポイントをまとめて, 思ったことを書ければと思います.
書籍
効果的なチームにする
チーム境界
- ソフトウェアアーキテクトの役割の1つは, 開発者がアーキテクチャを実装する際の制約をつくり伝えること
- 境界はきつくもできるし, ゆるくもできる
- きつすぎても, ゆるすぎてもフラストレーションを生む
- 効果的なソフトウェアアーキテクトは, 適切なレベルのガイダンスや制約を提供することで境界を適切な状態に保つ
きつすぎても, ゆるすぎてもフラストレーションを生む
きつすぎてフラストレーションを生むのはイメージしやすいが,
ゆるすぎてもフラストレーションを生むのはなるほどと思った.
確かにアーキテクチャなど決める際に,
制約がないと意見がぶつかったりしやすくなるのかなとイメージした.
人数が増えると尚更多くなりそうと感じた.
アーキテクトのパーソナリティ
- 3つの基本的なパーソナリティのタイプがある
- コントロールフリークアーキテクト : きつい境界を生み出す
- アームチェアアーキテクト : ゆるい境界を生み出す
- 効果的なアーキテクト : チームに適切な制約と境界を生み出す
- 開発チームの効果的なリーダーになるには「技」が求められる。たとえば、チームと緊密に協力し合い、チームから敬意を得られていなくてはならない
本書にある通り,
「開発者からアーキテクトに転身したばかりのときに起きやすい」
というのは理解できるので,
私も注意したい.
どうやって管理するのか
効果的なソフトウェアアーキテクトがどの程度コントロールフリークであるべきで, どの程度アームチェアアーキテクトであるべきかを知るには主に5つの要因がある
- チームの親しさ
- チームメンバーがお互いのことをよく知っている→コントロールの必要性は低
- チームメンバーがお互いのことをよく知っていない→コントロールの必要性は高
- チームサイズ
- チームが大きい→多くのコントロールが必要になる
- チームが小さい→多くのコントロールは不要になる
- 全体的な経験
- ジュニア開発者が多いチーム→多くのコントロールとメンタリングが必要となる
- シニア開発者が多いチーム→多くのコントロールとメンタリングは不要となる
- プロジェクトの複雑さ
- 非常に複雑なプロジェクト→コントロールが必要
- 簡単なプロジェクト→コントロールがあまり必要ではない
- プロジェクトの期間
- 期間が短い→コントロールは不要
- 期間が長い→コントロールは必要
これらの要因を用いて,
アーキテクトがどの程度チームをコントロールすべきか決定するために,
各要因を20ポイントの固定スケールで考えるとよい
※ +になるとコントロールフリークアーキテクト, -になるとアームチェアアーキテクト
私の所属チームと担当プロジェクトであててみる.
| 要因 | 値 | レーティング | パーソナリティ |
|---|---|---|---|
| チームの親しみやすさ | お互いをよく知っている | -20 | アームチェアアーキテクト |
| チームのサイズ | 小さい(5名) | -20 | アームチェアアーキテクト |
| 全体的な経験 | 全員が経験者 | -20 | アームチェアアーキテクト |
| プロジェクトの複雑さ | そこそこ複雑 | +20 | コントロールフリーク |
| プロジェクトの期間 | 1年半くらい | +20 | コントロールフリーク |
| 合計 | -20 | アームチェアアーキテクト |
アームチェアアーキテクトになりそうかなと思ったが予想通りだった.
こうやって数値化して表現できるのは非常に良いと感じた.
今後もプロジェクトを始める際には行い,
フェーズが変わってきた際にも実施していきたい.
チームの警告サイン
最も効果的な開発チームの規模を考える際には以下の3つの要素が関わってくるという考え方
- プロセスロス : プロジェクトに人を増やすほどプロジェクトにかかる時間が増える
- 多元的無知 : 内心では否定しているが同意してしまう現象
- 責任の分散 : チームの規模が大きくなるとコミュニケーションに悪影響を及ぼす
プロセスロス : プロジェクトに人を増やすほどプロジェクトにかかる時間が増える
プロセスロスを無くして生産性を上げていく.
どこにプロセスロスがあるのか定期的に観察していく.
今はプロセスロスがなくても, 今後発生していくかもしれない.
反対はプロセスゲインというらしく,
下記に詳しく記載があった.
参考 : https://jinjibu.jp/keyword/detl/1151/
多元的無知 : 内心では否定しているが同意してしまう現象
これはめちゃくちゃありそうだなと感じた.
多元的無知の発生を検知して相手に確認するには正直経験が必要だと思うが,
自分自身が多元的無知に陥っていないか, 問いかけてみるのは良さそうと思った.
責任の分散 : チームの規模が大きくなるとコミュニケーションに悪影響を及ぼす
振り返りの際などで, 定期的に確認することが必要だなと感じた.
フェーズが変わった際やチームメンバーの入れ替えが生じた際には,
すごく重要な確認ポイントになるとも感じた.
チェックリストの活用
- チェックリストは有効で, 対処されていることを網羅的に確認する優れた手段
- チームを効果的にするにはチェックリストをいつ活用し, いつ活用しないかを知ることが重要
- 何でもかんでもチェックリストにしすぎない
- プロセス内の必要なステップをすべて把握しながらできるだけ小さなチェックリストを作成すること
注意しながらチェックリストを作るのはもちろんだが,
チェックリスト自体のアップデートが大事だなと感じた.
作ってそのまま, となっているチェックリストは多いのではと感じている.
ガイダンスの提供
- 設計指針を用いてガイダンスを提供することでチームを効果的にできる
- 技術的な根拠とビジネス上の根拠の両方を要求することが, ビジネス上の根拠を示す必要性を開発チームに認識させる強力なテクニック
- 開発チームが決定できることとできないことを図で説明するのは設計指針を伝えるもう1つの効果的なテクニック
どちらのテクニックも参考になる.
できることできないことを図で表すことで混乱も減らせるし,
納得した上で物事を進められると思った.
まとめ
観点が増えたと感じました。
全体的に言えることとして,
何か初めるときに意識するのは勿論だが,
定期的な見直しをすることにより効果を持続&最大化できるんだなと思いました。
今回学んだことを活かしてチーム開発を良いものにしていけたらと思います。