最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。
これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。
エンジニアは説明することが多い
開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。
例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。
もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。
ほとんど伏せているのでわかりにくいかもしれませんが、 「こういう理由でこうした方がいいと思うけどどう？」みたいな説明をして、それに対して 「いや、こう思ったんですよ」という説明を返し、一番いい方法を模索しているわけです。
説明が上手い人多い
エンジニアは説明下手と思われてるかもしれませんが、実はそんなことはないです。 あくまで自分の経験上の話ですが、むしろ説明が上手な人が多い印象です。できる人ほど説明が上手い。
また説明する時も、できる人は相手を論破したり萎縮させてしまったりするようなことをしません。 チームギークに『相手に対する疑問ではなく自分の疑問として謙虚に聞く』とあるように、メンバーへのリスペクトを持って接して自分の意見を説明してくれます。
説明の仕方の工夫なんですが、これはすごく重要なんですよね。
極端に言うと、 「これ変だから直して」という指摘より 「ここってちょっと意図がわからなかったんですが、教えてもらえますか？」と入ってから必要に応じて自分の意見を説明した方が、お互いにとっていい方向に進みやすかったりします。
もちろん対面では口下手だったり、口調がひどいことになる人もいます。 「何だよこのクソコードは！殺すぞ！」みたいな感じで接してくる人もいますが、その人の思う理想をちゃんと聞いてみるとたしかに筋が通っていたりします。
説明が必要なのは答えがないから
そもそもなぜ説明が必要かというと、本質的には 答えがない問題を解くことが多いから じゃないかなぁと思っています。
締切や影響範囲など色々なトレードオフを考慮して一つの方針を決める時には、 「おれはこう思う」という指針が不可欠です。で、エンジニアは担当している開発には一番詳しく責任も持っているはずなので、その指針を自らが示す必要があります。
もちろん明らかな答えがある時もあります。いわゆるベストプラクティスってやつです。 例えばAndroidの開発だと、コードレビューでの指摘でGoogleのガイドラインのリンクを引用して説明することもあり、それはGoogleの定めた正解と捉えていいと思います。そのため、日々の勉強が欠かせません。
説明するための軸を持つこと
エンジニアは 自分の書いたコードに関してはなぜそう書いたか全て説明できる必要があると思っています。
「このコードは他のところからコピペしました」という説明をする人がいたとして、単にコピペしたという話だけだと説明責任を放棄しています。コピペ自体が悪いというわけではなく、コピペしたコードの意図やコピペの方がいい理由を説明できるなら、それは問題ないんじゃないかなぁという気がします。問題があればなぜ問題があると思うか自分の意見を説明すればいいだけです。
重要なのは、 説明するには自分の考えの軸を持つ必要があるということです。信念や指針と言ってもいいかもしれません。これがなかなか難しいです。
例えば、「こっちのほうがわかりやすいと思う。なぜなら〜」という説明は、少しばかり主観が入ることもあります。これはある意味仕方のないことなんですが、それが筋の通った主観であることが重要です。
軸のある説明は納得感があります。逆に説明できないということは、腹落ちしておらず軸が固まってないことがほとんどです。自分は結構軸がブレていることが多くて、コードレビューでもうまく説明できずにメンバーに迷惑をかけてしまっているので、ブログに吐き出したりして考えをまとめておくようにしています。
こういう軸は人によって違うので、組織が大きくなるにつれてチームで認識を合わせてルール化しておくほうがいい部分もあるかもしれません。
説明範囲の視野を広げる
説明する範囲の話なんですが、個人的にはなるべく視野を広げた方がいいんじゃないかなぁと思っています。
これは、新卒1年目の時の時にやった速度改善の開発経験が元になっています。
たしか「バッチ処理が遅すぎて8時間くらいかかってお客さんが困ってるから何とかして」という感じの仕事でした。一応効果が出たのでレビューに持って行ったら 「なんで速くしたの？」と言われたんですよね。
つまりどういうことかというと、 「誰も開発して解決しろとは言ってない」という話で。 例えば、お客さんのところに直接行って、運用の改善で何とかできますよという説明をして納得してもらえるなら、別に開発という解決方法じゃなくてもいいよね？ということです。
当時は正直 「それもっと早く言ってよ…」とも思ったんですが、この指摘自体にはかなり衝撃を受けました。
大事なのは問題解決であって、 開発以外の理想的な解決方法があるならそちらを選択することも視野に入れる方がいいんだなという発想を持つようになりました。ただ、そういう垣根を越えた方法を取る時には自分の考えをわかりやすく伝える必要があって、そのためのツールとしても説明能力は重要なんだなぁと思いました。
これは今でも自分の考えの元となっています。
まぁ大きなことを書いてきましたが、自分は説明上手くなくてメンバーにも迷惑をかけているので、自分の考えを説明できるように軸を作りつつ頑張ります。
