読者です 読者をやめる 読者になる 読者になる

【アーキテクチャ アンチパターン】Design By Committee

どんな問題?

背景

  • ソフト設計は会議で作られると言っても過言ではない.
    • 変数が多いため,すべての仕様を明らかにして比較するのは不可能
    • もし設計ができたとしてもテストはできない

症状と問題

  • 設計書が下記の特徴を備えている
    • 複雑
    • 大規模
    • 読みにくい
    • 一貫性がない
    • わけがわからない

  • 会議が上手くいかない
    • よく議論されない
    • 進行が遅い
    • 真剣に会話しているがシングルスレッドで,他の大部分の人の存在が意味をなさない

  • 周りの環境が変わる
    • 政治的都合により会議の内容が陳腐化する
    • 決断を迫られるなど

  • 設計に優先順位がない
    • どの要素が重要なのか
    • プロトタイプでなにができていないといけないのか

  • アーキテクトや開発者が設計に対して衝突している

  • 設計開発が予算超過する

どんなときに起きる?

  • アーキテクトがいないとき
  • ソフト開発プロセスが決まってないとき
  • 会議のプロセスが悪いとき
    • ファシリテータがいない
    • うるさい人が勝つ
  • 皆で幸せになろうとして,全員の意見を取り入れるとき
  • 5人以上の会議で決議がとられるとき
  • 優先度が決まっていないとき
  • 関心事が明確に整理されていないとき

どう解決する?

会議のプロセスを見直すことが有効.
そのためには,下記のことをやるとよい

  1. 時間を気にして会議する
    • コメントを25語程度にする.詳細は要求されたら行う
  2. 「なぜ会議しているのか」「どんな結果が欲しいのか」を明確にしておく
  3. 個人個人の役割を明確にする
    • Owner
    • Facilitator
    • Architect
    • Developer
    • Tester
    • Domain expert

会議には3種類ある.

  1. divergent(ブレスト)
  2. convergent(選択や決議)
  3. information sharing(情報共有)
Spitwads

会議を成功させるプロセスとしてSpitwadsという手続きがある.

  1. 質問をする
    • 誤解を減らすため
  2. 参加者は意見を簡潔にメモする
  3. Toss spitwads(意見やアイデアを書いた紙を一箇所にあつめる)
  4. 集められた紙がランダムに参加者に戻される
  5. 共通理解へ達する.
    • お互いに確認して誤解をなくす
  6. 重複を削除する
  7. 優先順位をつける
  8. 会議する