8
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

未経験新卒エンジニアのパン派です。
最近ちょこちょこレビューを受ける機会があり、緊張しつつもそれなりに有意義な時間にできている気がするので、やってよかったなと思うことを書いておきます。

先輩のレビューに出席する

先輩から助言頂いて何度か自分以外のレビューに出席しましたが、超効果ありでした。
百聞は一見に如かずとは言いますが、なんとなくああいうことやるんだなとわかっているだけで流れがスムーズになります。
あと、先輩も結構がっつり指摘食らうしそれが普通なんだなというのがわかるのがかなり大きいです。もちろん指摘事項は少ないに越したことはないですが、「指摘のない完璧なものを発表する」ことが目的なのではなく、「指摘を受けてより良い状態にしていく」ことが目的なんですから、メスを入れてもらうつもりで臨むくらいでいいんだな。となります。

慣れないうちは発表の練習を1回でいいからやっておく

これも助言頂いてやったことです。
「学生のうちから口頭即興プレゼンなんて何度もやったことあるから大丈夫」って人ほどやった方がいいです。
なぜならそういうプレゼンの目的は大抵「プレゼンで紹介する内容を良いと思ってもらうこと」なので、話がちょっと不正確だったりごまかしたりしても、プレゼン相手が「良い」と思ってもらえればokになります。
しかし、当たり前ですがコードレビューでは不正確やごまかしはご法度です。不具合の要因になります。
そういうわけで、今まで適当に乗り切れていたものがコードレビューでは乗り切れないといった事態が起きかねません。
自分で説明していて引っかかったところは間違いなく他の人も引っかかります。慣れないうちは事前にそれを把握して潰しておく方がいいでしょう。

リスケの可能性も視野に入れた連絡をする

当然ながら、組織の方針や納品の期日にもよります

リスケは当然無い方がいいですね。でも思いのほかバグ改修に手こずったり、あるいはレビューの予定入れないといけない時期だけど工数が読めなかったりということはあると思います。
絶対に間に合わないとわかっている場合にレビューの予定を入れるのは悪手ですが、多分いけるけど不確実だなくらいの時には、リスケの可能性ありますと前置きして潔く予定を入れてしまうのがいいと思っています。
その後も日次で逐一「ちょっと怪しくなってきました」など報告すればばレビュー出席者も「リスケになりそうだな」などとわかります。
そういった流れがあった上で「すみませんやっぱりリスケにします」と言えば、「そういう報告受けてたな。了解」となるだけではないでしょうか。
予定の変動はないに越したことはないですが、開発に不確実性はつきものですから、「予定通りに進める」というより「予定の変動の報連相を徹底する」方向で動いた方が自他ともにストレスが低くなる気がします。

「良く見せよう」という意識を捨てる

コードレビューでは実態より良く見えてしまってはダメです。不具合の見落としにつながります。
どんなに不備だらけ穴だらけのコードのレビューだったとしても、不備や穴をうまいことごまかしたコードのレビューよりは100億倍マシの気持ちを持って、潔く当たって砕けましょう。
レビューは「良く見せるプレゼンの会」ではなく、「(必要な)指摘をもらう会」ですので。

わからないことには「わかりません」と言う

「良く見せよう」という意識を捨てることの一つです。
「○○ってどうなってるんですか?」とか、「○○にも影響ないですか?」とか言われたとき、つい人は「(多分)大丈夫です!」とか「(おそらく)影響ないです!」などと答えたくなってしまいます。
しかしそれで後々苦しむのは自分です。もっと言うなら自分以外も不具合対応に追わせる可能性があります。そうなると、「調査不足なので持ち帰って再度調べます」の方が互いにとって有益です。

大筋に影響のない不備は最初に補足する

レビューの直前になって細かいミスに気付くことがあります。
よほど致命的なミスならリスケもありですが、後から修正すればいいかな、くらいの内容であれば、「○○について、△△への影響の調査が足りていないためのちほど対応します」と最初に補足すればいいでしょう。
もしそれが思いのほかとんでもない見落としで「後ほど対応します」では済まされないレベルであればおそらくツッコミが入りますし、その点が不安なら「後ほど対応するという方針なのですが問題ないでしょうか?」と最初に聞いてしまえばokです。
「完成した!」と思っていても絶対にどこかしらに不備はあるものなので、直前に見つけても焦らず規模感を確かめましょう。

質問の意味がわからなければしつこく聞く

質問されるとなんだか焦ってしまって、質問の意味がよくわかっていないのにそれらしいことを言ってしまうこと、ありませんか。
焦らずに、「すみません、どういう意味ですか? よくわからず…」と聞いてしまった方がいいです。相手もこちらがどれだけ理解しているのかなんて知らないので、無意識のうちに省いている前提を補って説明してくださるかもしれません。
1回意味を聞いてもわからなかった場合もう一度聞き直すのには勇気がいりますが、2,3回聞いてやっとわかることも結構あります。まず怒られることはないので聞きまくりましょう。

終わりに

この辺りを意識してから、あんまりレビューが怖くなくなってきたなという気がします。
使えそうなものがあれば是非。

8
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?