「ソフトウェア開発ファシリテーション」アドベントカレンダー6日目の記事です。
アイキャッチの画像を見て「これ、メテオフォール型開発の絵じゃん」と勘付かれたはいらっしゃいますでしょうか。
ご明察です。偉い人の一声でドンデン返しになるという意図は一緒ですね。
しかし、なぜそもそもドンデン返しになるのかというと、意思決定できる人のフィードバックを受けられるような構造になっていないからではないでしょうか？
どんなに着実に進んでいるように見えても、意思決定できる人がその場にいない状態はリスクです。
更に一番良いのは、意思決定できるメンバーのみでチームを構成することです。
仕様について決定できる人、設計について決定できる人のみで構成するということです。意思決定できる人がその場で決断しながら進められれば、それが一番スピーディですし、コミュニケーション齟齬による手戻りもありません。
いくら意思決定できる人がフィードバックしてくれる構造にしたところで、打ち合わせる度にお互いがいちいち持ち帰って検討していたのでは、時間がいくらあっても足りないですからね・・・。
ちなみに、意思決定できるメンバーだけでチームを構成した！と考えていても、持ち帰りが発生してしまうケースはあります。考えられる原因としては、
- このメンバーだけで意思決定できると思っていたが、実は別のところにも意思決定に必要なメンバーが存在していた（裏ボスパターン）
- 派生として組織改編により知らぬ間にレポートラインが変わっていた、というケースもあり。
- 権限はあるがとにかく不安で、その場で決めきることができない（不安を場で共有できていないパターン）
- 不安もさることながら、そもそも問題解決できる人がその場にいない、というケースもあり。
- 関連する連携システムが多く、決めきるためにも調整が必要（マイクロサービスパターン）
- 主要機能の提供で外部パートナーと協業しているため、というケースもあり。
などなど。メンバー構成だけでは解決できない問題の解消も、ソフトウェア開発のファシリテーションに求められることだと考えております。
