敢えて定義や二項対立を避けた事による学び
こんにちは 今回は、「議論をする際に敢えて定義やワードを避けてみる」と、スムーズに話が進み、結論に至った日のことメモします。
その日、自分が所属する開発チームは開発手法について議論していました。 参加メンバーはEMとしての自分、PdM兼チームリーダーの方、PMOの方 の３名でした。
議論の振り返り
その日、アジャイル開発を採用するか、ウォーターフォール開発を採用するかという議論をする予定で、EM, PdM, PMO が集まり、話していました。 ※ PdM, PMO の方もそれぞれ開発畑を経験されている方
それぞれの立場と考えていることを振り返ると、おそらく下記でした
EMの立場や考えていたこと
- 現案件とマッチするのはアジャイル開発であり、そちらを全員の「共通認識」としたい
- その理由を説明すれば、おそらくPdMの方も納得してくれるはず。。。！！
- アジャイルとウォーターフォールの定義から認識合わせをして。。。
PdMの立場や考えていたこと（恐らく）
- 開発手法は案件とマッチしていれば割とこだわりはない
- 案件としては、スケジュールを守ることが優先度が高い
- ウォーターフォールがマッチしてるんじゃないの？
PMOの立場や考えていたこと（恐らく）
- 言葉の定義から始めずに、何がしたいか、何が必要かを揃える
- 開発的にはアジャイルがマッチしてそうだが、スケジュール観点だと。。。
という状態でして、自分はアジャイルを勉強中だったこと、過去の案件でウォーターフォールでエンジニアが火消しをして疲弊した現場を経験したこともあり、ウォーターフォールがスケジュールを組みやすい点で優れているという共有認識を改めなければ。という 一点に固執してしまっていたことを反省しております。
定義や二項対立を避け、整理していった
PMO の方がファシリを始め、会話の交通整理が始まりました
アジャイル vs ウォーターフォール ではなくて、 「自分達がどうしたいか」「何を達成しなければならないか」「何を避けたいのか」 を整理してくださいました。
その結果、PdMの方の観点と自分の観点が揃いだしました。 結局、どちらの観点もスケジュールは重きを置く必要があるが、そのためにチームを疲弊させたいわけではないという、同様のことを考えていました。 お互い達成したいことが同じだったのに、立場や観点が異なること、定義にこだわったことで議論が本質から逸れてしまっていました。
アウフヘーゲン
個人的にとても感銘を受け、MTGの後にPMOの方にその旨を伝えたところ、下記の回答が返ってきました
「ちなみに、概念と対概念を乗り越えて第3の解を導くことを哲学的にはアウフヘーベン（止揚）と言う。」
ほわぁ〜〜 と思って調べました。
https://ja.wikipedia.org/wiki/%E6%AD%A2%E6%8F%9A
正直難しくて完全に理解していないですが、議論をする際に対立構造以外もあるよねと理解しました。
もし皆さんもMTGでなーんか噛み合わないなぁと感じましたら、第3の解に目を向けてみてくださいませ。
