エンジニアに必要な説明能力 - Konifar's WIP

最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、

[shngmsw]

自分から説明“しにいく“ときは準備万端だからいいんだけど、急に聞かれたときに答えられるように経緯とかを日頃から記録しとくのが大事だと最近痛感してる。

[kimromi]

設計にしろコードにしろ人に説明できるような明確な理由を持たないといけない。それには軸を持ってないと根拠のないものになってしまい、筋の通った説明にはならない。と自分なりに解釈させてもらいました。

[raimon49]

クソコードに対して「クソだから直して。以上」で終わらせてしまうと、教育効果も無いしアレという話。謙虚（Humility）、尊敬（Respect）、信頼（Trust）のHRTほんと大事。分かってる人ほど丁寧に問い掛ける。

[su_zu_ki_1010]

筋が通った説明をすれば、こちらの立場は理解してもらえる。考え方の軸は常に一定させておきたい。

[akatakun]

相手に対する疑問ではなく自分の疑問として謙虚に聞く。

[shiba_yu36]

エンジニアに必要な説明能力

[mut00tum]

unun

[Dryad]

『開発以外の理想的な解決方法があるならそちらを選択することも視野に入れる方がいい』

[northlight]

説明が必要なのは答えがないから

[rryu]

まあ「見積もり出すから対応方法をいくつか考えて」みたいに説明されないと作っちゃうよねえ。

[koogawa]

読んでいる

[operando]

説明能力大事だよねー。自分は説明するときあまり固い言い回しとかしないようにしてる。いつものように自然に話した方がうまく説明できたりもするからね。

[tak4hir0]

エンジニアに必要な説明能力 - Konifars WIP

[ikemkt]

"考えの軸をもつこと"←同意。自分がいた組込み業界では、それは『考え方』という用語で呼ばれていて、仕様〜コードレビューに渡ってよく飛び交ってた。なぜこの仕様にしたのか？＝仕様の考え方は？ってな感じ。

[inouetakuya]

"エンジニアは 自分の書いたコードに関してはなぜそう書いたか全て説明できる必要があると思っています" 同意

[pmint]

最後の段、開発で解決する人のことをエンジニアと呼ぶのでおk. 解答例は「それが私の仕事なんで」。チームだからって発想の統一までは要らない。開発プロセスに面倒があるとか、元から運用が不適切とか理由が欲しい。

[yhys07]

キャリアを積むほど、非エンジニアの方向けに対する説明力も必要になってきますよね。そしてコードよりも設計書や説明資料を、書く時間の方が多くなる、と。

[ken1flan]

説明できること、説明の軸を持つこと。大事だよなあ。

[tbpg]

"開発以外の理想的な解決方法があるならそちらを選択することも視野に入れる方がいいんだな"

[Vaduz]

“「何だよこのクソコードは！殺すぞ！」”

[ikedas]

「説明」フェイズが重要なのは、それが「仕事」だからかな。提案を受け容れてもらえるかに直結する部分だから。どんなに良い仕組みでも、納得してもらえないとお金は払ってもらえない。当然、協力も受けられない。

[mitsugusakamoto]

これはううん、納得。

[yu_dachi1408]

今、説明が大事なところにいるので参考になります。ありがとうございます。

[solidstatesociety]

まあそれで誠実にやれば開発自体やめさせるということもあるある。

[kiyo_hiko]

"「誰も開発して解決しろとは言ってない」という話"