やわらかテック

興味のあること。業務を通して得られた発見。個人的に試してみたことをアウトプットしています🍵

あなたのチームに悪者はいない。だから対話が必要なんだ

チームの人数がだんだんと増えてきてポジションが明確化されて来た今、「対話が必要だ...」と思わされる日々を過ごしています。 何年も前に「ポジションは役割に過ぎない」という記事が話題になりました。当時、ポジションというのは上下関係を構築するものだと思っていたのですが、記事の通りポジションは役割でしかなく、人と人の間に上下関係を構築するものではないという学びがありました。

logmi.jp

ポジションの明確化による副作用

しかし、ポジションが明確化されてくると上下関係に近いものが生まれます。
開発組織においてよく発生するのが発注者と受注者という関係です。テックリードや技術責任者が技術決定や設計を行い、機能開発についての大枠を決定した後、エンジニアが実装を担当するというのはよく耳にする話です。

このやり方のメリットは、一部の限定的な高い技術力を持ったメンバーで意思決定ができるため、コミュニケーションコストが少なく、意思決定の精度が高いという点です。デメリットは一部のメンバーで意思決定を行なってしまうため、参加していないメンバーへ経緯や背景が共有されないことが多く部外者感、まさに発注者と受注者という関係性になる可能性が高いという点です。

じゃあ、どちらかが良いのかというと一概には言えませんが、僕は意思決定には少なからず参加する・意見を取り入れるべきだと考えています。

www.okb-shelf.work

対立の発生

ポジションの明確化によって関係性が生まれてくると、それぞれが自分の責任を全うすれば良いだけなので、お互いが何をしているのか知る必要がなくなっていきます。そうすると、次第に分離化が進んでいき対立が生まれます。

対立が生まれることが必ずしも悪いことではないのですが、対立があるとカイゼン活動が上手くいかなくなります。
エンジニアが見ているものと、テックリード・技術責任者が見ているものが異なるからです。そんな状態で出てくる案は「あいつらが悪い...」と心の中で一方的に決めつけたものになってしまいます。

例: コードレビュー

  • エンジニア: コードレビューを依頼したのに全然、コードレビューをしてもらえない
  • テックリード・技術責任者: 設計やMTGで忙しく、コードレビューまで手が回らない

コードレビューを受ける側で出せる案なんて何もないよ

もっとコードのクオリティを上げてレビューの回数を減らしてほしい

お互いの状況を知るためには

先ほどのコードレビューの例から考えてみましょう。
コードレビューを依頼する側のエンジニアは「なんでコードレビューしてくれないんだ!」と思う一方、テックリードや技術責任者は「忙しい!どんだけコードレビュー依頼くるんだよ!」と思うことでしょう。しかし、なぜコードレビューの待ち時間が発生しているのかを両者の視点から理解している人はいなかったりします。

それぞれが自分の取り巻く環境や忙しさに必死になってしまっているだけで誰も組織を悪くしようと思って動いていません。しかし、お互いの状況を知らずに物事を進めてしまうために何もかもが空回ってしまいます。
あなたのチームに悪者はいません。だからこそ対話が必要なのです。

テックリード・技術責任者が時間に追われているということが分かれば、コードレビューのフローを検討し直したり、レビュー数を減らして1つ1つの実装のクオリティを上げるためにペアプロやモブプロを導入したりと、今までとは違った案が出てくるはずです。そのためには急がば回れ、対話が必要なのです。

www.okb-shelf.work

勇気ある一歩を待っている

「最近、チームのメンバーと話していないなぁ...」と心当たりのある方もいるのではないでしょうか。
さらにポジションが明確化されているチームは赤信号です。そのようなチームでは誰かから話し出すという文化が形骸化している可能性が高いので最初に「話しませんか」と言うのは、とても勇気がいることでしょう。

僕も偉そうなことは言える立場ではありませんが、先日「達人プログラマー」を読んでいたところ、冒頭の章で以下の言葉が紹介されていました。

あなたには現状を打破する力がある
達人プログラマー 第2版 1 あなたの人生より

あなたが動かなければ誰も動きませんし、現状が変わることはありません。
共に声をあげていきましょう。僕も頑張ります。