コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 | CROSS 2014 で親方として登壇しました。
このイベントについては他の登壇者の方もエントリーを書いているので是非参照してみてください。
実際参加してみて良い事も悪い事も含めて色々気がついたので、今後もより良い企画になるように書き留めておきます。
ぶつかり稽古2014初場所に含まれた要素
大きく分けて以下があると思います。
- 知的エンターテイメント
- コードレビューの心構え、やり方
- ペアプロ(初回の延長線上 (秋のエンジニアぶつかり稽古 2013 - ペパボ技術基盤チーム | Doorkeeper)
知的エンターテイメントについては今回の初場所では一切ペアプロしていないし、コードレビュー vs. 修正 みたいなぶつかり合いも無いのでエンターテイメント要素としてはパネルディスカッションにあったと思います。
じゃあぶつかり稽古とはなんだったのか
上記であげた要素について順に考えてみます。
コードレビューとペアプロとしてのぶつかり稽古
まず一番最初に重要なことを伝えたいのは以下の画像についてです。
この画像はぶつかり稽古の例として持ちだされる画像ですが、コードレビューにしろペアプロにしろこんな風に酒飲んで笑いながら指差して罵詈雑言を浴びせ倒してドライバーが頭を抱えている様な状態はクソです。
こうなってしまっては絶対ダメです。
(画像は面白おかしく使ってください。というか @sora_h が撮った写真と @songmu さんがペンギンコラと合わせた会心のネタ画像なのでこうなってしまったからには使ってもらわないとおれが困る)。
ペアプロのアンチパターンとコードレビューのアンチパターンが合わさったとても良い画像なので、普段の皆様のやり取りをこの吹き出しに当てはめてみてしっくりくるようだったらやり方を改めてください(べんり)。
それと合わせてあんちぽさんが壇上で言っていた "今日のことを現場に持ち帰って色々考えてみてください" っていうのは言葉通り色々考えてみてください。
ちゃんと壇上で登壇者の皆さん全員が良いことたくさん言っているのでこういうわかりやすい画像に振り回されないできちんと自分の頭で考えて自身の現場に良い影響をもたらしましょう。
コードレビューディスカッションとしてのぶつかり稽古
ぶつかり稽古2014初場所のメインテーマとなった内容です。
わずか1時間という限られた時間の中でもたくさんのコードレビューがの観点がキーワードとして出てきました。
- 設計
- パフォーマンス
- レビュータイミング
- レビューやり取りの姿勢
- レビュー観点
- テスト
- 教育
- チームビルディング
- チーム外レビュアーにレビューしてもらうときどうすれば良いか
今回話題にあがってこなかっただけで、コードレビューに含まれる要素はこれら以外にもまだまだあると思います。
だからこと壇上で私が言ったように "空気を導入しない" ということを心がける必要があって、レビュイーはこのコードレビューで何をレビューして欲しいのか、レビュアーは何に対してレビューすべきか、というのを逐次整理しながらレビューを進める必要があります。
コードレビューを経験した人はわかると思いますが、コードレビューは容易に脱線します。
デプロイが直前に迫っていたとしても容易に脱線します。
なぜならレビュアー、レビュイー共にこれからデプロイするものをより良くするためのプロセスとしてコードレビューを行っているからです。
なのではてなでやっているようなコメントへのタグ付けはレビュアーからのメッセージとしてはひとつの方法だと思いますし、レビュイーとしてはレビューのやり取りで今回見て欲しいところからは脱線しそうだなーと思った時には "この内容については後ほど要点を整理するためにタスクを切って対応しますが、今回はこのままで行くことにします" などレビューの論点を明確にすることが必要です。
あと個人的に印象的だったテーマが "チーム外レビュアーにレビュー依頼するとき" というものです。
これについては色々思うところがあって、仕事でも実際に依頼したり依頼されたりというのをやったり見たりしている訳ですが、大体いくつかのパターンがありました。
- でかめの機能を丸っと依頼される
- 極々狭い特殊な専門性の高い部分の限定的なレビュー
- アーキテクチャ、設計のレビュー
一番あるのが "でかめの機能を丸っと依頼される" これ。
もうこれはどうしようもなくって、なんでかというとその機能をそのように実装して今実装しているのはどうしてで、それまでどういうアーキテクチャになっていてどういう設計、コーディング規約があるのかわからない状態でのレビューになることがほとんどです。
このパターンは上記の様なコンテキストを共有できていないので、往々にしてレビュアーは深くつっこめなくて、つっこんだとしても "歴史的経緯でほげほげ〜" となってしまうパターンが多いです。
(できてコードの見た目の話しとか名前の話し。(まあそれもコーディング規約がーとか歴史的経緯でーとか言われてレビューが空中分解して終わるか人が死ぬ))
下の2つの "極々狭い特殊な専門性の高い部分の限定的なレビュー", "アーキテクチャ、設計のレビュー" のパターンはコンテキストを限定しやすいのでうまくいくパターンが多いです。
というかコンテキストを限定しないと丸投げにならないレビューって依頼できないのでは。
なので個人的には外部レビュアーにレビュー依頼するときは出来る限りコンテキストを限定した内容に留めておくとうまくいくと思います。
今後の知的エンターテイメントとしてのぶつかり稽古
今後どの様にぶつかり稽古が発展していくかはわかりませんが、ペアプロを軸にしたぶつかり稽古として発展していくとしたときに気をつけないといけないことが2つあると感じました。
- リアルなペアプロをぶつかり稽古にすべきかどうか
- 見る側に何を持って帰ってもらうか
前者は突き詰めるとエンターテイメント性が無くなって "なるほど、こうやればいいのか" といういい話になります。
後者はエンターテイメント性を突き詰めてショーにしてしまうと何を持って帰ってもらうかどうかが曖昧になります。
私的にはどっちかに寄れ、という風には考えませんが、やるとしたらどっちもやってプロレス的にやる、というのがいいんじゃないでしょうか。
見る側もやる側も色んな前提条件を把握した上で実施する。
こうするとぶつかり稽古というよりは巡業でのショー取り組みに近くなってきてしまうのですが、よく考えてみて欲しい。
相撲の場合のぶつかり稽古って見てて楽しいか？
本来の相撲のぶつかり稽古って人と人がひたすらぶつかって投げ飛ばされて砂まみれ汗まみれになりながら稽古するやつですよ。
(ついでに言うとぶつかられる方は親方じゃなくて兄弟子だろって @songmu さんが言ってたの思い出した。親方が現役力士にぶつかられたら死んでしまう。)
ぶつかり稽古の本質とか良くわからないですが、きっと言葉で伝えられない、感じられないものをお互いがぶつかることでコミュニケーションするというものなんじゃないでしょうか。
でもそれなら我々はぶつかり稽古は見に来るんじゃなくて現場でやれって話しですね。
現場でやろう。
まとめ
まとまらない。
ぶつかり稽古、特に今回のぶつかり稽古2014初場所は見た目やタイトルばかり先行してネタにして終わるっていうことになりがちな気がしますが、ここまでつらつら書いた通り得られるものは山ほどあるし、持ち帰れるものは山ほどあります。
今後どう展開していくかは本当にやる側、求める側次第だとは思うけどちゃんと皆で良く考えてイベントを育てていけばすごいことになると思うのでネタにして終わらないで欲しいです。
最後に、今回機会を与えてくれた @studio3104 さん @kentaro さんはじめ登壇者の方々、CROSS2014 実行委員の方々、参加者の方々、本当にありがとうございました。
