こんにちは、ソフトウェアエンジニアのくるです。
「話が転がるのを待つ」話。
仕事をしている途中、意思決定の場面が無限にあるなと感じます。
小さいものならコードレビューでapproveをつけるとき。自分は良いと思った、という決定。
大きいものならアーキテクチャの設計とか。なかなか引き返せない意思決定もあります。
そういう、エンジニアリングにおける「決定」という作業には、周りの人と合意をとったり、共有をもって初めて決まるといった性質を感じます。
自分の中で一人で完結しない意思決定というのは、他の人にも納得をしてもらったり、形式的に記録を残しておく、みたいな所作をよくやります。
今回はそういう業務仕草の話。
自分はエンジニアリングをする際、ある程度正解というものを突き詰めながら進めるタイプです。
もちろん技術の移り変わりはあるし、世界というstateは日々変化するので、エンジニアリングにおいて絶対的な正解というのはないでしょう。
ただ、ソフトウェアを開発する上で、現状の情報から決めれるベターな解決策、みたいなものは存在していると思っています。今時点での暫定的正解、みたいなものですね。
正解と呼ぶのは些か言葉が強いので自分はよくtobeと呼んでいます。
別に後から見たときに間違っていても良い、でも今時点では全員が納得できるtobeを目指す。こういう姿勢が好きです。
正解というよりは、皆で話してこれを暫定的な「正解」とする。という立て付けかな。
tobeを描いた上で後から状況が変化し、その意思決定そのものが技術的負債になることは大いにあると思っています。
そして、それはそれで良いこと、と自分は思いながら日々エンジニアリングをしています。
tobeを描かずなんとなくで決められたことは誰の意思も存在せず、より苦しい技術的負債になっていることの方が多いかな、と自分はよく感じます。
tobeを描くというのもスキルの1つだと思うので、そういう意味でもあらゆるアウトプットに対して、自分の中でのtobeは持ち続けていたいな、というのをポリシーとして感じます。
このtobeを描いたり決める場面においては色々なシチュエーションがあるなと感じます。身近なチーム内だったり、あまり面識がないチーム間のやりとりだったり、各マネージャーが集まった場など。
例えば、ある開発チーム内なら意見がズレたときには最終的な意思決定はマネージャーだったりテックリードだったり、何かロールがある人が下すという手段はとれるでしょう。その中では相対的に良い決定を出来る人がロールについてることが多いと思いますし、普段から一緒に仕事をしているメンバーならコンテキストの共有も多く、スラスラと話が決まることも多いのかなと思います。
一方で難しいのが、チームを跨いだり、マネージャー同士などで取り決める意思決定です。
基本的には人の集まりの中で誰かしらにロールが決まっていることで、意見を集約する作業はスムーズになると感じます。
しかし、そういったロールにおける濃淡がない関係性や、関係値が薄いときにも意思決定をしていかなければならない状況というのは多々あります。
そしてこういう場面において、意見が割れてしまったときなどに意思決定のコストは跳ね上がるなと感じます。
エンジニアリング自体、こだわりの出る事柄と感じるところは多いので、議論を始めるとなかなか着地が出来ず意思決定が宙に浮くこともしばしば。
やっと本題に来ましたが
こういうときに、話が転がるのを待つほうがいいときもあるなと感じる話。
自分は割と議論を進めるのが好きで、拙くてもtobeを発言することが多いタイプと自認しています。
エンジニアリング歴を重ねるにつれ、tobeの精度も少しずつ良くなっているのかな、という自負もあり、ある程度組織内でエンジニアリングにおける方向性みたいなものの理想形を自分の中で持って話をすることが多いです。
上述したものとは異なる、いわゆる「待たない」タイプですね。
特に議論が変な方向に転びそうなときは、割とすぐ口を出すタイプです。明らかなマイナスが生まれる意思決定というのは見過ごせない。
でもそういうときに議論をしてもなかなか期待通りの着地をしない時があります。人間の意見は分かれるものです。
向こうから見れば僕がなかなか折れてくれない人になっている。
そういうときに昔は割と折れずに頑張ってしまう事が多かったのですが、最近は折れてもいいか。と思い引くことが増えました。
これは丸くなったからというよりは、意思決定の通し方を学んだという感じです。
折れてしまうともちろん議論としては自分が望んでいない意思決定にはなってしまうのですが、それが決まった後でも、結局話が途中で頓挫し、自分が最初言っていた案に戻ってくるという場面が割とあるなと感じることが増えました。
この議論の巻き戻りは、数週間で収まるときや、1年後とかだったりすることもあります。人の意思が変わるには色々なタイミングや流れがあるので、そのスパンは様々。
ただ、自分が良いと思っている方向性に関して、途中変な寄り道をしても、結局は話を戻せることもあるなあという感じです。
もちろん戻せないこともあります。
逆に自分がそもそも間違っているときも。
でも長いスパンで見て、自分の意思決定と最終的な流れが同じベクトルに向くかどうか、が大事だなと感じます。
最初の頃は割と結論を急ぎたいタイプでしたが、周りを巻き込んでtobeに持って行くには遠回りも必要だな、という感じです。これはちょっと偉そうな感じですがそう捉えることも大事みたいなモチベーションの話ですね。
自分のベクトルと、組織のベクトルの内積が大きくなってきて、自分の意思決定の打率が上がると、説得力とか信頼にも繋がるのかなと感じます。こういったものは目に見えない蓄積値があるなと。
打率を上げることで上述した「待つ」回数も減り、最初の提案の通りやすさも上がるのかなと感じます。
業務仕草すぎて辛いのですが、人間同士でエンジニアリングをやる以上自分は避けれないなと思っているのと、よりよいエンジニアリングをするために自分の打率をあげることは大事かなと思うようになりました。
もちろん、自分のエンジニアリングの方向性が良いだろうという「うぬぼれ」が前提なので、打ったら点を取れるパワーや技術は欠かせないのですが。
あと、常にtobeが見えすぎて話を通しすぎると、割と正しいとしてもワンマンな状態に近づいてしまうこともあり、人間社会では少し見栄えが悪いのかなと思うときがあります。
意思決定パワーは大事な場面で発揮して、軌道修正しやすい小さい課題は少し見守る、とかも最近感じます。意思決定介在バランシング。
そんな感じで、「話が転がるのを待つ」話でした。
コミュニケーションは難しすぎる。
ソフトスキルの話永遠にしてたけど、でもやっぱそもそもはいい意思決定を出来るハードスキルが大事かな(元も子もない)
終わり。
