読者です 読者をやめる 読者になる 読者になる

はむはむエンジニアぶろぐ

このブログのコンセプトは"ハッキングの為なら愛する家族を傷つけることをいとわない" 自分にとってエンジニアリングは "手段ではなく生きる目的" である

レビューを受ける技術

f:id:secret_hamuhamu:20150718015005j:plain
みなさん、レビューしてますか?
設計レビュー / コードレビュー など。
レビューをすることで、とんでもないバグの発見から知らなかった知識の吸収が得られたりします。

本日は、" レビューを受ける技術 "について記事にします。
私はよく先輩社員にレビューをしてもらいガチガチやりあってます。w
「俺の設計が正しい!」「いや、お前の設計糞だよ!」みたいなノリです。

レビューをする方(レビュアー)は、もちろんレビューを受ける方(レビューイ)にもレビューのテクニックが必要です。
実際に私が、大事にしている勘所や工夫についてまとめます。

何故、レビューをするのか?

そもそも何故レビューをするのか?答えられますか?
会社の決まり?先輩にやれって言われたから?

承認が必要という意味で、レビューが必要な環境もあると思いますが、何故、レビューをするのか?語れるようにならなくては、ならない。
バグを防ぐとか設計のアイディアがほしいとか、自分が構築した機能をチームに共有するとか目的はいっぱいある。
今回のレビューの目的はこれだ!とテーマを持つことが大事である。

レビューを受ける前と受けた後で、どのような前進があるのか?イメージしてレビューに臨まなければならない。
事前に頭のなかで、レビューの予行演習を行うことで、本当に伝えたいことは何か?見て欲しい所はどこか?一緒に考えて欲しい問題は何か?理路整然としてくる。


ベストを尽くしたか?

難しいことやよく分からないところは、先輩に聞けばいいやという姿勢で臨んでいないか?
あなたのデザインしたシステムは、あなたに責任がある。
聞かなければ、解決しない問題もあるが、そうでないのなら自分の頭と体をフルに使って "おれが考えるさいきょうのシステム" を設計する。

ベストを尽くしてボコボコにされることもあります。
初めから上手くいかないかもしれない。でも、それを繰り返す。
そうすれば、あなたはいつの日かレビュアーを言い負かすことができる。
先輩、そんなことも知らないんですか?先輩の案だとこのケースだと破綻しますよね?と言えるぐらいに。
でも、リスペクトを忘れずに。

書いたコードの全てを語れるか?

なんかよくわからないけど、コピーしたら動きました〜(^^
さすがに、こんなことをいう人はいないと思うが、コピーして持ってきたコードを語れていますか?
ソフトウェアは、再利用できるのなら再利用すればいい。
車輪の再発明にならなくて済む。(余談ですが、時には車輪の再発明もいいと思う)
再利用は、悪くない。
しかし、それがどのような原理で動いているのか?語れないのなら、今直ぐ調べるべきである。


書いたコードの全てを語れるようにならなければならない。
100行書いたのなら、100個の解説ができるぐらいに。

設計は、取捨選択である。
どのような選択肢があって、何を根拠にこの選択をしたのか?
A, B, Cの3パターンやり方があるなら、3パターンすべて検討しなければならない。
それぞれどのようなメリット・デメリットがあるのか?
足し算引き算をして、選択しなければならない。
つまり、トレードオフ。
何故、Aパターンを採用したのですか?と聞かれた時に、どのような設計判断をしてトレードオフをしたのか答える義務がある。

伝えるための工夫

エンジニアは、口下手な人が多い。
でも、優れたエンジニアは、エンジニアリングについて設計について語るときは、凄くわかりやすい。

エンジニアは、伝えるという力も磨かなくてはならない。
もし、レビュー対象のシステムの要件が、レビュアーにうまく伝えられない場合、どうしたらいいか?
口頭で、ぺらぺら話しても、レビュアーがその分野のビジネスの専門知識を持っていないときっと伝わらない。

うまく伝えることが出来ないのなら、それはあなたが理解できていないに等しい。
Xというシステムを構築するのなら「Xとは?」を語れなければならない。
専門用語を日常的に使われる言葉に翻訳できるようになれば、語れていると言っていいだろう。

伝えるために喩え話や造語を用いて、共通認識を合わせるといったことも有効的である。
例えば、削除対象のデータなのに何らかの理由で、削除がされないデータを" ゾンビ " と定義付けをすることで、複雑な背景やルールを閉じ込めてスムーズにコミュニケーションが出来る。
伝える力を磨くために言葉選びも意識しなければならない。

伝えるために図を書くのも有効的である。
システムというのはデータのコミュニケーションである。
どのようなデータ形式で、どのようなタイミングでやりとりがされて、どのようなデータ特性を持っているのか?
シーケンス図などを書いて、データのコミュニケーションを視覚的に表現すれば、レビュアーもイメージがしやすい。
図に書き起こすというのは、とても大事で矛盾点やいいアイディアに気づくヒントになる。

前提条件や制約を要約する

何事にも前提条件や制約があります。
それらを分かりやすく要約して伝える必要があります。

事前に前提条件や制約をレビュアーに伝えていないと何故このような実装なのか?とツッコミを受けることになります。
もし、前提条件や制約を事前に伝えていたとしてもレビュアーは、それを覚えているとは限らない。
こういう背景があって、こういう前提条件や制約が生まれています。ということをレビュアーに「なるほど」と思わせなければならない。

このコミュニケーションが上手くいっていない場合は、お互いストレスになる。
レビュアーは、レビューイであるあなたの知識不足や経験不足でこのような設計をしていると思い込みあなたの信頼が下がる。
レビュアーであるあなたは、制約のためこのような設計をしているが先輩レビュアーの方が正しいと思い込み誤った指摘を受け歪な設計をしてしまう。

これは、レビューイだけでなくレビュアーも気をつけなければいけない。
レビュアーは、シンプルではない設計に対して何か理由があるの?とパスを投げてあげるべきである。
しかし、レビュアーのせいにしてはいけない。
レビュアーであるあなたが、工夫をこらす必要がある。

では、どのようにして前提条件や制約を伝えるのか?
ペラペラ話してもレビュアーの記憶に残らない。
大事なのは、要約することである。
もし、3つの制約があるのなら "3つ抑えておかなければならない制約があります" と伝える。
制約のそれぞれを覚えてなくても3つの制約があるというキーワードは、覚えてもらえるはずだ。
これだけでも、レビュアーは事前に共有された制約に対して記憶をたどりやすくなる。

例えば、3つの制約があるなら、それぞれを説明する言葉選びも重要である。
あやふやな言葉は使わず、明確な言葉選びをする。
レビュアーもその言葉を使うと思って言葉をねらなければならない。
エンジニアとして語彙力を鍛える。

前提条件や制約は、往々にして複雑なものである。
それらを要約して伝えるというのは、設計にもよい効果が得られるので意識して行う。

最終的なゴールイメージを伝える

一度のリリースで、最終的に目指しているゴールに到達は出来ない。
レビュアーから不完全な実装についてツッコまれる前に、今回のリリースではこういう理由がありここまでの実装となっています。
しかし、最終的に目指しているゴールはココです。と伝える。

完璧な実装なんてないし、落とし所を考え無くてはならない。
どういう決断で、この落とし所にしたのか?レビュアーに伝えないと設計がブレるしリリースが遠のくだけである。

証拠を揃える

何故、その選択をしたのか?定性的 / 定量的な証拠がなければならない。
レビュアーが納得できる証拠でなければ、話が堂々めぐりするだけである。
レビュアーがツッコんでくるであろうポイントを先読みして証拠を揃える。

ツッコまれて反論するために証拠を揃えるのではなく、自身の設計判断が妥当だと自信を持つためにも習慣にしよう。

ペースを乱されてはいけない

レビュアーによっては、レビューイの話を最後まで聞かずにツッコミを入れてめちゃくちゃにしてくる。
こちらが、用意したストーリーで順序立てて話をすれば納得してくれるかもしれない。
そういったレビュアーは、レビュアーの設計判断にきな臭さを感じ最後まで話しを聞いていられないといったところだろう。

ツッコまれそうなポイントを感じ取り、「この点の詳細は後程話します」「一旦、ツッコミはナシで!」といったように布石を打つ。
絶対に、ペースを乱されてはならない。レビュアーが複数人いるなら、それをきっかけにツッコミ合戦が始まる。
それを相手にするのは、とても労力がかかるし時間もかかる。
「もう一回、考えなおしてこいよ」となったら最悪である。

レビューの場が荒れそうだな〜 又は 荒れてきたな〜と感じたら勇気を持ってストップをかける。
ちょっと、落ち着きましょうか?と声をかけ場を沈静化させる。
そこで問題となってい点の話を整理するとよい。

まだ伝えきれていない点があるなら「一旦、レビューの場の手綱は、私に預けてください」と宣言する。
こちらが伝えきれていない点を伝えきるまで、レビュアーのツッコミは一切受け取らない。
私が話し終わるまで黙ってくださいぐらいの勢いでいい。
ちょっと荒っぽいけど、伝えたいことを伝えきれないままレビューの場が荒れるよりはいいと思う。

さいごに

果敢にトライして、ボコボコにされても立ち上がる不屈の精神と何故、うまく行かなかったのか?自問自答できれば良いレビューが行えるようになると思います。

最近読んだ本

具体と抽象 ―世界が変わって見える知性のしくみ

具体と抽象 ―世界が変わって見える知性のしくみ

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー(日経BP Next ICT選書)

なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー(日経BP Next ICT選書)

モデルベース要件定義テクニック

モデルベース要件定義テクニック