レビュー再定義@TAKAKING22

Photo by Jantine Doornbos on Unsplash質問

レビューしていますか？

@TAKAKING22

質問

あなたにとっての／あなたの考える
レビューの目的は何ですか？

@TAKAKING22

レビューの目的✴ 品質を担保するため✴ バグを見つけるため✴ コードの均一化をはかるため✴ スキルの低いメンバーの教育のため✴ スキルトランスファーをするため✴ コードのクオリティを上げるため…
@TAKAKING22

SQuBOK Review 2017 Vol.2 レビュー技術動向：図2 開発者のコードレビューに対する期待@TAKAKING22

分類するとこの3つくらいになりそう• 品質を担保する• バグを見つける• テストとして• （最低限の）検査

Check

リファクタリング• ナレッジの共有• スキルトランスファー• 新人教育• 文化の醸成

学習
Learning

強化
Enhance@TAKAKING22• リファクタリング• もっとよく• もっとキレイに• 先行投資質問

レビューの目的を達成できていますか？

@TAKAKING22

SQuBOK Review 2017 Vol.2 レビュー技術動向：図3 モダンコードレビューの目的に対するそれぞれのレビュー結果（指摘率）@TAKAKING22

レビューの目的が達成できていない！？
レビューの目的

実際のコメント内容@TAKAKING22

質問

レビューは楽しいですか？

@TAKAKING22

レビュー目的の3要素検査

Check

学習Learning

強化Enhance@TAKAKING22

もう少しわかりやすくすると…
やらなくてはいけない

Must

やるべきやりたい

ShouldWill@TAKAKING22

レビューの話をするとこのあたりに終始しがちやらなくてはいけない

Must

やるべきやりたい

ShouldWill@TAKAKING22

実際にはやらなくてはいけないことすら難しい
意図がわからない
なんでこんな変数名になってるの？

ここに置くべきじゃないよね

こっちを直したらこっちも直すだろ

仕様理解してる？
@TAKAKING22

Photo by フリー写真素材ぱくたそ (https://www.pakutaso.com/)エンジニアのキャリアの話
エンジニアとしてスキルアップしていくと、エンジニアリーダーとかテックリードとかを任されたりする。
そうなると、メンバーの教育やシステムの安定稼働の責任がのってきて、例えばレビューをする時間がどんどん増えていく。
エンジニアリングが好きで頑張ってきたんだけど、スキルアップしていくとどんどんコードを書く時間が減っていくのってなんかツライ。

なんかツライ@TAKAKING22

もっとわくわくするレビュー
やらなくてはいけないMust

やるべきやりたいShould

Will@TAKAKING22

@TAKAKING22

モブプログラミングの経験を通して、“もっとわくわくするレビュー”についてのアイデアが出てきたのでそんな話をします。

@TAKAKING22

★
★
★

★
★
★

及部 敬雄
@TAKAKING22
育児休暇中ーャ
ージ

ネ
マグン
リ事
ア理
ニ会
ジるン
えエ
支社
を会
ム
式ーん株
チ
さ天ル
じ楽イ
おャグジン
アミ
人ラ
法グ
団ロプ
ブ一般社
モータ彩ス
本ン
山モ：ルイン
ャメ@TAKAKING22
アジ推し✴ FA宣言中✴ https://takaking22.com/contact/
ブログ

スライド

アジャイルチームを支える会

http://www.agileteam.jp/
https://speakerdeck.com/takaking22
https://takaking22.com/@TAKAKING22

今日のお話✴ モブプログラミングを始めてレビューが不要になった✴ でもレビューはやっぱり必要だった✴ 我々にとってのレビュー✴ レビューを再定義する@TAKAKING22

やらないことリスト✴ モブプログラミングを薦めること✴ 詳細なレビュー方法についての説明✴ ○○レビューに限定した話@TAKAKING22

こうなるといいなー✴ レビューについて再定義するきっかけ✴ もっとわくわくするレビューが少しだけ増える@TAKAKING22

@TAKAKING22

モブプログラミングとはチーム全員で✴ 同じ仕事を ..
✴ 同じ時間に ..
✴ 同じ場所で ..
✴ 同じコンピューターで ..

すること@TAKAKING22

@TAKAKING22

1つのディスプレイと1つのコンピューター
ディスプレイコンピューター1人のドライバーと複数人のナビゲーター
ドライバー
ナビゲーター
ナビゲーター
ナビゲーター@TAKAKING22

ナビゲーター我々のモブプログラミング✴ 楽天株式会社 新規事業開発部✴ 4人チーム→3人チーム✴ 働き方＝モブプログラミング✴ 開発も運用も企画も営業も✴ 2017年5月〜現在@TAKAKING22

働き方としてのモブプログラミング
モブワーク
09:00-11:00 個人時間
11:00-11:15 モブプランニング
11:15-11:30 モブモンキーテスト
11:15-13:00 モブワーク
13:00-14:00 モブランチ
14:00-17:15 モブワーク
17:15-17:30 モブふりかえり@TAKAKING22

モブワークを始めてやらなくなったもの✴ 朝礼（3つの質問）✴ チーム内ミーティング✴ 合意形成のためのドキュメント✴ レビュー全般（ソースコード、ドキュメント）✴ Git Flow
✴ カンバンの個人レーン

レビューもやらなくなった@TAKAKING22

分担作業とモブワークを比較してみる
分担作業

モブワーク

VS

@TAKAKING22

分担作業
ex.
タスク分割、設計、キックオフ..

ex.
レビュー、承認、引き継ぎ..

分担作業の前後に同期する作業が必要になる@TAKAKING22

分担作業

ミスコミュニケーションによって手戻りする可能性もある@TAKAKING22

モブワークex.
設計、レビュー、ノウハウ共有

同期していないではなくて常に同期している@TAKAKING22

モブワークを始めてやらなくなったもの✴ 朝礼（3つの質問）✴ チーム内ミーティング✴ 合意形成のためのドキュメント✴ レビュー全般（ソースコード、ドキュメント）✴ Git Flow
✴ カンバンの個人レーン

これらはすべて作業前後に同期する作業@TAKAKING22

Teamwork Revolution チームとものづくりに真正面から向き合うモブプログラミング@TAKAKING22

分担することが前提になっていなかったか「分担する＝生産性が高い」という思い込み

WBS

スクラム

ガントチャート@TAKAKING22

カンバン

二者択一ではない分担作業

モブワーク

VS
Photo by Marvin Meyer on Unsplash@TAKAKING22

Photo by rawpixel on Unsplash

仕事や状況に合わせて使い分けている
分担作業

モブワーク

Photo by Marvin Meyer on Unsplash@TAKAKING22

Photo by rawpixel on Unsplash

工程としてのレビューは不要になった@TAKAKING22

モブプログラミングの強み
検査

Check

学習Learning

強化Enhance@TAKAKING22

モブプログラミングの検査✴ リアルタイムでフィードバック✴ タイポすると親の仇のように指摘される✴ チーム全員の合意のもとでコードが組まれていく✴ 忖度せずにチームの最善を目指すことができる@TAKAKING22

レビューにおける忖度
ちょっとイケてないんだけど、今パツパツだろうし、動くからとりあえずいいか…
まだこれは理解できないから言わなくてもいいやストレス源
今回は指摘多いからこれくらいにしておこう@TAKAKING22

Photo by フリー写真素材ぱくたそ (https://www.pakutaso.com/)

チームの最善を目指す
分担作業

Aさん

仕事知識範囲Bさん

Cさん@TAKAKING22

チームの最善を目指す
分担作業

Aさん
Aさんの知識範囲内なので対応可能

このチームでは対応が難しい
アサインされると不安で仕方がない

Aさんの知識範囲外
Bさんにレビューしてもらうことができればフォロー可能

Bさん

Cさん

@TAKAKING22

Aさんの知識範囲外
Cさんにレビューしてもらうことができればフォロー可能

チームの最善を目指す
モブワーク

Aさん
チームの知識範囲内なので対応可能このチームでは対応が難しい
チーム全員でやってもダメなので割り切って対応する判断ができるAさんにとってははじめての仕事でも、まわりのナビゲーターにフォローしてもらいながら進めることができる

Bさん

Cさん

@TAKAKING22

モブプログラミングはチーム全体の活動である✴ チーム全員で立ち向かってダメなら仕方がない✴ 判断をチームですることができる✴ 絶対なる安心感とそこから学ぶ姿勢@TAKAKING22

モブプログラミングの学習✴ チームの学びの量が最大化する✴ 結果だけでなく過程を学ぶことができる✴ 新しい技術の習得もチームで立ち向うことができる✴ 新メンバーの受け入れや教育にも向いている@TAKAKING22

モブプログラミングで教育✴ 経験値が低い人をドライバーにするとよい✴ わからなければ手を止める権利を✴ 聞きながら手を動かして覚えることができる✴ ノウハウのJust in time

@TAKAKING22

学びの量の最大化
. ..

分担作業

同期されればチーム全員の学びになるが、されなければ個人の学びだけになる

. ..
. ..

モブワーク

. ..

. ..
. ..

. ..

. ..

. ..
. ..

. ..

@TAKAKING22

全てチーム全員の学びになる. ..

形式知も暗黙知もまとめて伝える✴ 暗黙知は意識できないから暗黙知になっている✴ 暗黙知は暗黙知のまま共通体験で伝える- なぜつくったのか- どうやってつくったのか- どんな問題解決のプロセスを経たのか- どんな学びがあったのか- どこに苦労したのか@TAKAKING22

モブプログラミングの強み検査

Check

学習Learning

強化
Enhance@TAKAKING22

ところがレビューの必要性を感じてきた!!

@TAKAKING22

足りない部分を補うレビュー
検査

Check学習Learning

強化Enhance@TAKAKING22

我々に必要なレビュー✴ Pull-Request＝自分たちの仕事の成果を自分たちで見直す✴ 最＆高の仕事ができたのか✴ もっとよくする余地があるのか✴ 次に自分たちが学ぶべきことは何か

ふりかえりに近いレビュー@TAKAKING22

働き方としてのモブプログラミング
モブワーク
09:00-11:00 個人時間
11:00-11:15 モブプランニング
11:15-11:30 モブモンキーテスト
11:15-13:00 モブワーク
13:00-14:00 モブランチ
14:00-17:15 モブワーク
17:15-17:30 モブふりかえり@TAKAKING22

自分たちの今日の仕事は最＆高だったのか

ここからもっとよくすることはできそうか
それは今やるべきか・やりたいか

次にどういうことを学ぶべきか・学びたいか@TAKAKING22

再び見るRe-view@TAKAKING22

あなたの言うレビューは本当にRe-viewなのか✴ 実際にはFirst-viewであることが多い✴ 初めて見る場合は理解するコストが発生する✴ 非同期で他人の思考・仕事を理解をすることは、自分で思っているよりも難しい@TAKAKING22

強み

弱み

✴ 常にチームの最善を尽くす ✴ その場の熱によって誤ったことができる判断をしてしまう可能性
リアルタイム ✴ 結果だけでなくプロセスを ✴ 局所最適に陥る可能性
モブプログラミング
評価することができる✴ 冷静に見ることができる
レビュー
Re-view✴ 忖度が生まれやすい

ex. イマイチだけど時間がないから…
✴ 全体最適を考えてフィード✴
結果のみで読み取れない
バックしやすい
部分を知るためには、コミュニケーションが必要@TAKAKING22

強み

弱み

✴ 常にチームの最善を尽くす ✴ その場の熱によって誤ったことができる判断をしてしまう可能性
リアルタイム ✴ 結果だけでなくプロセスを ✴ 局所最適に陥る可能性
モブプログラミング
評価することができる

補完関係✴ 冷静に見ることができる
レビュー
Re-view✴ 忖度が生まれやすい

ex. イマイチだけど時間がないから…
✴ 全体最適を考えてフィード✴
結果のみで読み取れない
バックしやすい部分を知るためには、コミュニケーションが必要@TAKAKING22

我々のチームにおけるレビューの位置づけ
検査Checkレビュー• ふりかえり• 自分達の仕事の評価• もっとよくするには学習Learning

強化Enhance@TAKAKING22

まとめ✴ モブプログラミングを初めて、それまでの工程としてのレビューは必要がなくなった✴ Re-viewとFirst-view✴ リアルタイムにもレビューにも強み・弱みがある✴ 自分たちに合ったレビューを再定義@TAKAKING22

レビュー再定義

Photo by Jantine Doornbos on Unsplash

レビュー再定義✴ 自分たちの知っているレビューを見直す✴ レビューの強みを活かすことができているか✴ レビューではないプロセスの方が解決しやすいことはレビューで解決する必要がない@TAKAKING22

プロセスを改善する✴ プロセスを改善するという意識は大切✴ しかしそのプロセスでの解決に固執しなくてもよい✴ 目的を達成するために、そのプロセス自体をやめるという選択肢も常に頭に入れておく@TAKAKING22

完璧にやらなくてはいけないからの解放@TAKAKING22

Photo by Pierre Herman on Unsplash

無限に湧いてくるやらなくてはいけないこと

凸有限のリソース@TAKAKING22

完璧にやらなくてはいけないという幻想✴ 完璧もやらなくてもいけないも考えたらキリがない✴ 目指したところでたどりつけるものではない✴ たどりつけないのでツライしギスギスする@TAKAKING22

完璧にやらなくてはいけないからの解放✴ ROIを考えて自分たちにできることをする✴ これでダメなら仕方がないという割り切り✴ 最善を尽くしても失敗したときはそこから学ぶだけ@TAKAKING22

変化に対応する@TAKAKING22

Photo by Lucas Clara on Unsplash

変化に適応する✴ 他人のうまくいったことが、自分たちにそのまま当てはまるとは限らない✴ チームの練度や状況によって最適解は変化する✴ 一度定義したら終わりではない✴ 変化に適応し続けること@TAKAKING22

情緒を大切にする@TAKAKING22

Photo by rawpixel on Unsplash

情緒を大切にする✴ 小手先のテクニックだけでどうにかできると思わない✴ 人間であることを楽しむ✴ 完璧ではないけれど成長することができる✴ 楽しいと楽しくないのインパクト@TAKAKING22

人間らしいレビュー@TAKAKING22

Photo by rawpixel on Unsplashあなたのレビューは楽しいですか？
＠TAKAKING22@TAKAKING22