#205 指摘ではなく提案をしよう

こんにちは。ITベンチャーエンジニアのこへいです。

チームのコミュニケーションの中で、議論が進みどんどん意思決定ができる時と、逆に議論が停滞しダラダラと時間だけが過ぎてしまう時があります。
この違いは指摘をするだけか、意見を伝え提案出来ているかの違いがあります。

◯で、どうして欲しいの？という指摘は議論が停滞する

あるpull request（自分が書いたコードを誰かがレビューして、それが承認されたらその変更分が統合される仕組み）に「このように書けばレスポンシブに出来て良くないですか？」というコメントがありました。

レスポンシブとはユーザーが使用するデバイスの画面サイズに合わせて、Webサイトのデザインやレイアウトを自動で最適化させる手法です。PC用とスマホ用で共通の実装をすることで、それぞれの実装をしなくても良いという特徴があります。
ただ、この指摘はレスポンシブにすることで何が良いのかが述べられていません。そのpull requestにはレスポンシブ対応をしない理由も書かれているのに、あえてレスポンシブを押す理由がなくては、作成者としは「なぜ？どうして欲しいの？」となってしまいます。

結局、オンラインミーティングでその指摘の理由を確認したところ、こういう時はレスポンシブが一般的と考えていたということで、大した理由もなかったのです。

意図のない無責任な指摘は相手を困らせ、時間を奪う行為です。自分も気をつけたいものです。
カジュアルな質問は歓迎します。質問をキッカケに議論が進むことや、誰かの課題を解決できるのは良いことです。

◯意見や提案で議論は進む

私のチームでは、お困りごとや相談したいことを集約するスプレッドシートがあり、書き込んでおくと、夕会という毎日夕方に行うチームの1日の振り返り会で取り上げるというルールがあります。

そのシートのフォーマットを変えたいという議題が上がってきました。
相談の中での議論を後で参照できるようにメモ欄を用意していたのですが、そのメモ欄には議論と議論中で生まれたTODOが混在しているので、TODO欄を設けようという提案でした。

運用に合わせてフォーマットを改善することにはみな賛成ということで、新しいフォーマットに修正しようとしたのですが、すでに1000行くらい溜まっているシートのため過去のやりとりが新しいフォーマットに合わなくなるという指摘が出てきました。また、指摘です。

じゃぁやっぱりフォーマット変更はやめる。。。？という雰囲気になりかけたところ、シートを分けて今後の相談事項は新しいシートの新しいフォーマットに移行するのはどう？という提案が出てきて丸く収まりました。

こういうシーンでもさっと落とし所を見つける提案が出来るとモノごとは進んでいきます。

◯相手が求めている情報をイメージする

pull requestの指摘については相手が欲しい情報のイメージを欠いた発言には改善の余地があります。
相手が求めている情報がわからない時はその先の展開を考えるのが有効かと思います。

プログラムの実装でもその先の展開をイメージできることが求められます。
pull requestのレビューをする人はその修正のコンテキストがないため、実装意図がわからないコードは良いコードではありません。

期待した振る舞いをしたり、高速に処理できる実装だけでは不十分なのです。
エンジニアの仕事はコードを書くことよりもコードを読むことの方が多いのです。そのため、自分が書いたコードを「読んだ人がどう感じるか？」を意識しながらコードを書くことが、相手が欲しい情報をイメージすることに繋がります。

コードを「読み物」として考えるように、自分の指摘の先の展開をイメージすると、指摘ではなく提案をするべきと理解できるのではないでしょうか。

もちろんその場で提案が出来ないこともあります。その場合でも指摘で終わらず、「今良い提案がないけど、誰かこの良いアイデアはないですか？」などと次の展開に進められる発言が出来るとよいですね。

ということで、生産的な議論を進めるためには無責任な指摘ではなく、意見や提案が求められること、そのために先の展開や相手が欲しい情報をイメージすることの大切さについての話でした。

最後までお読みいただきありがとうございました。