合意形成ゲーム、チームワークと個人プレー

チームで行動する・チームで考えるというのは大事なんだが、別にチームが揃わないと行動できない・考えられないというわけじゃないよなみたいなアレをなんか良い感じの文章にしたい

— やんく✌('ω')✌ (@yy_yank) August 10, 2023

さてこれを実際にブログにしてみようということで書いてみる。
それっぽく今回も怪文書を書いてますが、割と当たり前のこと書いてるやんって書き終わってから思うシリーズです。
適当に書いているのでめちゃくちゃですがお許しください

チームで話し合わないと意見は言えない？

チームワーク。チームでの意思決定
確かに大事だと思う。

一方で、これはチーム全員が揃わないと意思決定ができないというわけではないはず。

常々これを言っている人がいるというわけではないが
「誰々さんとまだ話してないから」とか
「誰々さんとまだ相談できていないから」ということで
チーム全体で話し合ってからじゃないと意思決定ができないみたいなことが時々起こっているのではないか。

例えばお客さんからの問い合わせや会社全体とかの広い場での議論を想像する。
「チームで相談してみてから回答します。それまでは分かりません」

これは誠実といえば誠実だが、
個々人が答えるという責任を全うしてないのかもしれないと思う時がある。

時間的余裕があるときにはそれで良いが、相手は即答を求めているかもしれない。

プログラマは、自分の発言の正しさを気にし過ぎる側面があると思う。が、硬直して正式回答を言うだけじゃなくて良い。
単に意見がほしいだけかもしれない。

スピーディーな判断の足枷にならないようにしたい。

チームでの意見の前に個人の意見を出す

例えば「個人的にはこう思います。なぜならxxでxxでxxだからです。xxが考えられます。念のため、チームとしても相談してそれが正しいかも含めて改めてご回答します」
みたいな感じで、1次回答として自分の意見を言っておくっていうのも1つの手かもしれない。

もしくは
「明らかにxxです チームにも念のため確認を取ってきますが進めてください」
と個人で責任を負ったうえで、チームと同期する。問題があった場合は訂正するというパターン。
これは自分の意見に自信を持ちチーム任せにしないということでもある。一方これが的はずれだと、スタンドプレー、無責任になってしまうので強い意志が必要。

チームで話し合わないとチームワークが悪い？

誤解を恐れずに言うと、チームで決めず勝手に進めても良い。そのあとにきちんとチームに説明し納得してもらう、もしくは自分が間違っていれば謝罪するみたいなリスクが取れるのであれば。
このあたり、自分は可逆的か不可逆的な意思決定かということと、スモールステップで常に変わり続ける(一度決定したら終わりではなく連続的である)という軸かもしれない。
そういう前提だと「ここは仮に間違っていてもいい」とか、「ここは間違っちゃいけないから相談しよう」とかという風になる。勝手に進めるのは比較的どうでもいい部分、取り返しのつく部分かもしれない

設計議論やチームでの進め方などについて

上記は一旦、仕様であったり設計であったりを決めるなどミーティングの場でのコミュニケーションをイメージして書いてみた。

次は、開発チーム内に閉じた話で書いてみる。

誰か欠けようと前には進める

例えば 設計の議論、開発の優先度、見積もりだったりするものに関しても
別に常にチームで決める必要はない。

例えば誰かを欠けていたとしてもそのメンバーで決めてしまい、後から その議論に参加できなかったメンバーに共有すればいいだけである。

その際に、根拠やどういった経緯かっていうのをしっかり 説明すればいい。
例えばそのタイミングで別の角度からの意見や、より良いアイデアが出た場合には
そちらを採用するというだけである。

全員の合意 = 良い設計？

つまり、言いたいのは。
より良い設計、チームにとって理解しやすい設計、将来に向けての正しい設計というのは
別にチーム全員が合意することとイコールではないということである。

裏を返せば、全員が合意したからと言って
全員にとって読みやすくはないし
将来に向けて 拡張性のある設計になってるかと言うとそうでもない可能性もある。

それがいつの間にか
「全員で合意したから、正しい設計のはずだ」
「全員で合意したから、その時の最善の設計のはずだ」
というある種の思考停止が働いている気がする。

チームでしっかり議論して設定を決める。プロセスは素晴らしいのだが、そのプロセスだけに偏重せず、本当に良いものになってるかというのは別で考える必要がある。

「これ全員で決めてその時はそう思ってたけど、やっぱおかしいよ」
「これはその時誰も気づけなかったけど、こっちの方がいい」
「自分たちでは考えつかないけど、他の方法があるかもしれないから詳しい人に聞いてみよう」
こういう、合意形成の罠にはまらないような思考を外す行為が必要である気がする。

問題 vs 私たち

でも、中心はチームで。
開発で起こりうる問題はチームとして考えたいし、誰かの失敗や成功もチームとして考えたい。
自分も相手もカバーし合える関係が好きではある。
ただ、前述したような個人プレーの場合はある程度個人としての責任を負う意識も大事だと思う。
要はバランス。夏はバカンス。

まとめ

総じて、チームワークとはチームで一緒になって動けばいいというだけのものではない。
チームで考えを一致させて進めるというだけでもない。それだと単に合意形成ゲームになってしまう。

個人の意見を交わし合って、あーでもないこうでもないと話した結果
最終的にはチームとしての目標に進むというのが良いチームワークではないだろうか。

目標に進む、結果を出す、そのために過程を大事にするという順番になるはず。

にわとり卵の問題のような話であって、もちろんプロセス、過程も大事だが、目的を忘れてはいけない。

自分が答える、自分が設計する、自分が責任を負う、間違いは認める

それぞれのメンバーがそう思っているチームというのは、強いチームと言える気がする。しらんけど