ペチコン仙台でちょっと喋った
はじめに
週末に下記のカンファレンスに参加させてもらったので色々と残しておこうと思います
お話させてもらった内容
気づけばスタートアップしてから6年目なんだなーと思いつつ色々とまとめたレビューに関する発表資料になります。
おそらくプログラミングのレベルの差関係なく、聞けるものだと思ったし、セッションを聞いて色々と意見や感想を持つ人がいるのではと思ったので私はあえて少し早めにセッションを終えてQAの時間にしようと思っていた。
まぁQAで手が上がらなかったとしたら、色々質問を投げかけて見ようと思っていました。
こういった時間や同じ空間で意見交換できる事が個人的には一番のカンファレンスに行くメリットだと思っているところもあります。
いただいたQAを元にあらためて考えてみた
受託開発の立場だと、こういったレビュースタイルはどう適用すれば良いのか？
もうかれこれ、10年ぐらいは自社サービスをしている会社に所属してまして、その立場目線が持ててなかったです。💦
改めてちょっと考え直してみると、受託の場合でもその期待値がシステムだけでなくて、開発・レビューを通じての情報とかノウハウとかという感じで成果物を定めて契約をするとやりやすいかも？って思いました。ちょっとビジネス交渉必要になりますが。形として残りづらいから難しいのかな...
よい気づきをありがとうございました。
レビューも立派なチームの成果だが、査定にはどう反映されているのか？
当然レビューで得た気づきや潜在的なバグの防止なども成果になるのであれば、査定で考慮されてしかるべきですよね。
レビューでのやりとりを査定で拾う仕組みは現状ありません。このへんは今の所、問題提起もされていないですね。
でもよく振り返ってみると、今のチームメンバーでいうと自分だけでした。正社員は。他の方はみな業務委託契約でした。なので査定って当然正社員だけの話になるので自分が気にしていなかっただけと言うオチですね💦
自分としては、基本的に査定に不満があるわけでもなく（正確に言うと大して気にしていない。正しいと思った事は細かい事は気にせずやってしまうべきスタンス）という感じで過ごしていた為ですね。
ただ、査定面談の時に、このgithubに残っているコメントは良いねというフィードバックをいただいたりするので仕組みはないが、現状の上司はそのへんの価値・成果を汲み取ってもらってると思われます。
結局レビュー中に議論が紛糾してしまったらどう着地するの？
最終的には、テックリードもしくはそのプロジェクトをマネージメントしているPMに判断が委ねられますね。
感情は無くしてフラットにどちらのがメリットが高いのか、今後の戦略に合うのかでちゃんと選択をする理由を持ってジャッチする事が重要なのかなとか思います。 あとはちょっと思うのは、あえて少し冷却期間を置いてからもう一度話すみたいな事をするとみんなが冷静にもう一回話せるかなとも感じています。
レビューの通りやすい人、通りにくい人出て来ませんか？
実際ありますよね。自分も経験があります。
ちょっと振り返ってみると
レビューが通りやすい人の特徴ってその人との関係値で他のプロジェクトで一緒にやった経験から信頼残高がある場合とかエンジニアリングの感覚が近い人なのかなって思っています。
逆にレビューの通りにくい人はエンジニアリングの感覚が遠い人なんだろうなと感じます。どちらが正しいという事ではないです。
こう言うのってすごくありがたい機会だと思います。新しい観点で指摘してくれるからです。自分のエンジニアリングを見直すきっかけになる可能性があります。
長年同じ現場にいてベテラン領域になってしまうとコメントで指摘してくれる機会が少なくなってしまいます。という視点からも逆にありがたい事
でも、プロジェクトを納期までにリリースするのも大事なmissionなのでそうも言っている時間がない場合もあると思います。その際は直接話をするMTGを設定してしまって、そこで直接コミュニケーションをしてしまいますかね。さらに私の場合はslackでやりますかね（オープンなチャンネルで）
そこで率直な議論をして得られた着地をgithubの該当のPRに残せる。詳細の議論はslackのリンクを貼っておく。そうする事で他の人も全てを追える状態にしておくとさらに他のメンバーにも有益な情報を還元できるという感じです。
あとは、事前にリーダブルコードのような内容をなるべく準拠しましょうとか、このデザインパターンにある程度乗りましょうとか、と言うような事をプロジェクトの最初とかに決めておくとスムーズになる部分はあると思います。
新しい技術を導入する際の知見のあるレビュアー不在問題にはどうしている？
当然新しい言語やFW等をいれる際って、知見を持っている人は限られる or いない場合があると思います。その場合当然レビューに困りますよね。
うちではブラックボックステストならぬ、動作検証をするレビューもokとしています。 こう言う正常な叩き方以外にこんな叩き方をしたらエラーログ出たんだが...というレビューです。中身のコードを読まずに、外から色々叩いてみて正常な動作をしているかというレビューです。
だいたいの人が、それをやっているうちにコードにデバッグプリントを仕込んでみて動かしてみたりし始めます。
昔、新人だった頃よく先輩に動くコードをもらって、それを動かしながらどう処理を書いてるんだろうって学習した人は自分だけではないと思います。その思考と同じでこういったレビューを繰り返す事で新しい技術に対しての理解が進みます。（ただ自身で本を読んだり等の自助努力は前提です）
そうした時間を過ごして本来のコードレビューを可能にしていきます。
ちょっと脱線しますが、その世界でのエキスパートを招聘して1日外部講師をしてもらって一気に知見をチームに吸収させる手もありだと思います。
新しいアーキテクチャを導入する主導者でもちょっと不安が残る場合などにこの手の方法を取っています。無鉄砲にプロダクションに投入して事故を起こすより、事前にこう言った事をする事で防止できる事を考えるとどちらがコストを安くつくかという話をプロジェクトをリードしている人には理解してもらう必要はありますが。
最後
前夜祭、懇親会等々色々なところで色々な方とお話できてとても楽しかった。やっぱりエンジニアの横の繋がりは大切だな〜ってつくづく思った。
懇親会のLTが一番楽しいんじゃないか説がちょっとあります。まぁお酒も入るのでってところもあります。
おまけ
カンファレンスは前夜祭や懇親会、2次会等々、食べ過ぎ飲みすぎパターンを何度か経験したので、翌日はおやすみにしてブログを書いてジムにいく日にした。あとは今日はジムいくだけだ。
