Re: Pull Request レビューの限界
はじめに
読んで色々と思うところがあったのでアンサーソングです。
tl;dr;
レビューはバグを見つけるための門番では無く、コード品質をよくするための仕組み。Pull Requestの形式にこだわる必要はない。
Pull Requestの位置付け
「目を皿のようにしてバグがないか、ロジックを追う」コードレビューをしてくれる人がよくいますが、レビューでバグを見つけるのはコストが高いと思っています*1。またレビューでバグが見つけられるエンジニアは開発力が高い人となり人数も限られます。その人にレビューが集中すると負荷が高まり、徐々に門番化していくことは避けられないでしょう。
バグがないか検証したいのであればテストをきちんと書くべきです。仮にテストが書きにくい箇所があったとしても開発者がきちんと動作確認を行うべきです。
レビューの目的はバグを見つけることではありません。 私は「開発者個人の責任から、開発チーム共同責任にする」ための儀式だと考えています。
自分がメンバーにお願いしていること
開発部門のマネージャーとして、上記の文化を醸成するためにメンバーにはこんなお願いをしています。
- わからなくてもコードをレビューして欲しい。
- レビューしたらなんらかの反応を残して欲しい。
- 良いねでも、勉強になりましたでも、LGTMでもいい。
- 読みにくいコードがあれば読みにくいとコメントして欲しい。
- わからなければそのまま「この箇所がよくわかりませんでした」と書いて欲しい。
- コメントでのやりとりが続いたら直接話して欲しい。PR上でのレスバトルは不毛
- 自動アサインするとその人しか見なくなるのでアサインは意図的につけない。
- 「人のPRをレビューしてないな」と感じる人がいたらマネージャーとして1on1でレビューするように促す。
Pull Requestレビューは必要か?
プロダクトのリリース前にレビューがなされるのであれば直接git push masterした後にレビューを行う形式でもよいと思っています。
個人的にはトランクベース開発の方が好みだし、実際にうまくいった開発現場も経験したことがあります。
コードの設計議論はコードを書き始める前にメンバーと同意を取っておいた方が良いです。 ホワイトボードなり紙なり簡単な方法で詳細を詰めておくべきです。 コードを書き終わってから設計のまずさが指摘されるのは、OSSの開発プロセスに憧れすぎた人の過ちではないかと思っています。
*1:この形式のレビューがダメという主張はないです。全員がこうするべきとは思っていないだけです
帆船のふりかえり / Sailboat Retrospective
はじめに
チームのふりかえりはいつもKPTを使ってしまいますが、Agile Talks vol.1で帆船のふりかえりというものを知りました。日本ではあまり聞きませんが、海外では割とメジャーみたいです。"sailboat retrospective"で調べると例がたくさん見つかります。
sailboat retrospective - Google 検索
一度聞けばやり方は簡単に覚えられますが、実践する人が増えるように日本語でやり方をまとめておきます。
やり方
- 中央に帆船、左右の一方に追い風の絵、もう一方に島の絵を描く。
- 船の下に錨と岩の絵を描く。
- 各箇所ににチームの現状を当てはめてコメントを書く。
- 追い風 : チームにとっての追い風、チャンス・機会
- 島 : チームが到達したいゴール・ビジョン
- 錨 : チームが島を目指すにあたり阻害要因となっていること
- 岩 : 気にしなければならないリスク
KPTとの違いとして、「絵を描くことでチームのムードを表せる」、「帆船とゴールの位置関係を生かして中期的な目標・長期的な目標を表現できる」ことがあるかなと感じました。
森さん(@viva_tweet_x)からのアドバイス
ふりかえりで有名な森さんから、RSGT2020の会期中にやり方を聞く機会があったので、もらったアドバイスを紹介します。
順序は決まっていないが、KPTと同じ順序でやると良い
コメントを記入する箇所がいくつかありますが、KPTと似たような項目なので、K->P->Tの順に話していく方が話しやすいそうです。
すなわち下記の順となります。
- Keep : 追い風
- Problem : 阻害要因・リスク
- Try : ゴール
モチーフは帆船でなくても良い
ゴールを目指すモチーフとそれを阻害する要因があればよいので帆船以外の絵でもできるそうです。
例えば縦長のホワイトボードを使う時は空を目指す気球・ロケットで絵を描くと似たようなふりかえりができます。
参考
大規模スクラム(LeSS)に取り組んでいる国内事例一覧
昨年自社(Retty)に大規模スクラムを導入した際、社内で「LeSSの国内事例は無いのか?」という質問をもらって困ったことがありました。LeSS実践者研修に参加したり、大規模スクラム本を読んだり、LeSS Studyに参加するなど学んでいる人はいたのですが、事例はなかなか出回っていませんでした。少しずつ聞いて回ったところある程度数がまとまったのでまとめて公開します。公開されている資料をベースにまとめていますが、「うちもやってるよ！」というところがあればぜひお知らせください。
- Retty
- atama plus
- Cybozu
- ebookjapan
- Groove X
- Repro
- SmartHR
- Ubie
- アソビュー！
- うるる
- ヤフー株式会社
- リクルートライフスタイル
- Mixi (2020/3/4)
- Timers (2020/3/12)
- 東京海上日動システムズ (2020/10/24)
- NEC (2021/2/19)
- アカツキ (2021/3/20)
- OPTiM (2021/4/25)
- LINE (2021/5/19)
- ラクス (2021/7/8)
- HERP (2021/8/2)
- Mobility Technologies (2021/10/22)
- はてな (2021/12/09)
Retty
グルメサービスRettyの開発。
- 「1プロダクトをみんなで作る！」Rettyでの大規模スクラム(LeSS)導入記 - Retty Tech Blog
- Rettyの開発組織をぶっ壊して、LeSSを導入した話をPO視点で書きました｜のぐちひろき｜note
atama plus
塾向けのタブレット型のAI教材の開発。
Cybozu
kintone、Garoonの開発。それぞれLeSSをベースに5-6チームくらいまでスケーリングさせているそうです。
ebookjapan
国内最大級の電子書籍販売サービス
- https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/12168/agile?fbclid=IwAR0uZABJOIfrzCRf-T_7ZGyatNxrD4BCl9XLvqCW60P0TnrYdvnSP8RjtrA
- Unification of the middle scale services by Nuxt.js
Groove X
家族型ロボット「LOVOT」の開発
Repro
カスタマーエンゲージメントプラットフォームの開発
2021/8/5追記 LeSSやめたそうです。
SmartHR
Ubie
AI問診Ubieの開発
アソビュー！
便利でオトクな遊びの予約サイトの開発。
うるる
クラウドソーシングプラットフォーム「シュフティ」及びクラウドソーシングを利用した入札情報サイトなどの開発。
ヤフー株式会社
クレジットカード事業に関わるシステム
Yahoo! MAP、Yahoo! カーナビ
地図アプリ・カーナビアプリの開発
リクルートライフスタイル
Airレジ(海外版)の開発。
以下は記事初回公開後の追記
Mixi (2020/3/4)
家族アルバム「みてね」の開発
- 組織の壁みたいなもの. 会社のブログではないでのあくまで個人の雑記です。 | by Atsushi Sakai | Medium
2021/6/25追記 LeSSやめたそうです。
みてねの開発スタイルを大きく変えた話 - Atsushi Sakai - Medium
Timers (2020/3/12)
家族アプリFammの開発
東京海上日動システムズ (2020/10/24)
地震保険プロジェクトの開発
NEC (2021/2/19)
アカツキ (2021/3/20)
- https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15221/less1
- 大規模組織でLeSSの再導入をしています - ねこのひたい
OPTiM (2021/4/25)
LINE (2021/5/19)
LINE TODAYの開発
- LINE TODAYにおける大規模スクラム（LeSS）の導入事例とその効果 -日本語版- - YouTube
- Large-Scale Scrum (LeSS) Road, Where does it Leads?
ラクス (2021/7/8)
HERP (2021/8/2)
Mobility Technologies (2021/10/22)
はてな (2021/12/09)
Mackerelの開発
耐えるコミュニケーションからの卒業
はじめに
マネージャーとして多くの人と仕事をし、メンバーが伸び悩んでしまうパターンに「耐えるコミュニケーションに陥る」例が少なからずあるなと感じていました。自社イベントで話す機会があったのですが、同内容をブログでもまとめておきます。あらかじめ断っておくとこれは特定の誰かを非難するものでは無く、多くの人がある特定の事象に関しては陥ってしまうことがあるように感じています。
耐えるコミュニケーションとは?
下記のように思い込んだ行動をとってしまうパターンを指しています。
- 相手の指摘にひたすら耐える。言われたことだけ対処する。
- 一定時間耐えたら次の段階に進めると思い込んでいる。
エンジニアだけに限らず、一般的な全ての業種で起き得るのではないでしょうか? 例えば個人的な経験では下記の事象で遭遇したことがあります。
- レビュー
- コード、アーキテクチャ
- 対外発表
- 学会、勉強会、カンファレンス、論文
- 会議資料
- 事業計画・ビジネスモデルなど
全体的に「答えがない」ものに対して起きがちではないでしょうか?個人的には前職の昇進試験論文がこのパターンにハマってしまいました。毎年試験時期が近づくと終わりのない書き直し練習を嫌がってやっていたのを思い出します。
なぜ耐えるパターンに陥ってしまうのか
直接的な原因は「期待するレベルと本人のレベルに一定以上の差があるから」だと思います。 間接的には「壁を乗り越え方がわからない」「答え・正解がないものに取り組んでいる」「受け手がこういうものだと観念してしまう」ことが引き金になっていると思います。 「自分はXXXに目を付けられているから邪魔されている」「どんな資料を作ってもイチャモンを付けられる」「提出日ギリギリまで直しが続く」とか、覚えがありますよね?
耐えている本人はいろいろと頑張ってはいるものの、耐えることが主目的になり近視眼的な対応・行動が増えます。 また指導をするメンバーも時間が取られ色々と疲れてしまいます。どちらも非効率です。
耐えるパターンから抜け出すにはどうしたらよいか
まずは耐えている本人に状況を理解させることから始めています。 「耐える」考え方をやめさせるために「一定以上のレベルに達したら終わる」ものであることをまず強調します。
つぎに一緒に伴走してあげます。自分でやり方を見つけて欲しいマネージャーの気持ちもわかりますが、「耐え」パターンに陥った人が自力で抜け出すのは困難です。プログラミグならペアプロ・モブプロをする、資料ならアウトライン・構成を一緒に考えるなどを行い、詰まっているポイントを理解し、助け舟を出してあげます。
最後に壁を登り切るまで見届けます。 途中で切り上げさせて別の機会に改めて取り組ませることもできますが、それだと成長はできておらず、問題の先送りにしかなっていません。 この手の問題は一度レベルを上げると下がることがないので、何度もチャレンジさせるより、一度登り切らせた方が効率が良いです。
おわりに
かなりあちこちで観測する事象だと思うのですが、良い名前がついていないために議論されることが少ないように感じています。 もっと良い名前を見つけた方はぜひ教えてください。
Re: 最高のScrumキメた後にスケールさせようとして混乱した話
www.slideshare.net
Regional Scrum Gathering Tokyo 2020の講演で「あの時こうしておけばよかった」という考えを教えて欲しいと講演で話されていたので自分の考えをまとめました。
事例・講演の概要
1チームスクラムでモバイルアプリの開発を行い、顧客の信頼を得てプロダクト開発は成功した。そこで顧客から運用・データ分析含め3チームをすべてスクラム開発へ移行したいという要望が出た。 スクラムマスターでアジャイルコーチの藤村さんは機能開発と運用のチームを合わせた15人1チームスクラムを行い、慣れたところでチーム分割を行いScrum of Scrumを行おうとした。 結果はチームは機能せず、元に近い形に戻すことになった。
私ならこうする
チームを混ぜた上で最初からチームを分割する。
チームの人数が多すぎると協力を引き出すことが難しいです。経験的には5〜7人が良さそうで、9人を超えるとチーム内からコミュニケーションの不満が出ます。 ミーティングが長い、誰が何をやっているのか分からない、開発効率が悪いというコメントがふりかえりで出てきたら分割の時期だと思っています。
チーム分割はメンバー同士の話し合いに委ねるやり方もありますが、私はメンバーが備えるスキルセット、性格などを考慮して慎重に決めています。
機能開発と運用が分かれているのは悪手
チームを分割するときは機能開発と運用のメンバーを均等に2チームに分け、運用チームそのものをなくします。 運用チームは負債を返し続けるだけのチームなので雰囲気は自然と悪くなりがちです。 また機能開発チームも自分たちの作った負債にきちんと向き合わせないといいアーキテクチャ・メンテナンスしやすいコード・運用しやすいシステムは得られないでしょう。
複数プロダクトオーナーがいる場合はチームを組んでもらう。
PO同士が話し合って優先順位を決めるのは難しいと思っています。 とはいえ代表者1人を決めることも難しいのであれば、チームを組んでもらいチームとして要望を出すことを依頼します。
いきなりLeSSを入れる。
上記を遵守しているとLeSSに限りなく近い形になります。なので人数が増えてチームを分ける必要があるだけならLeSSが1番労力が低いです。 LeSSをやるとチーム・ステークホルダーに言わなくても、スクラムイベントを2チーム同じ場所で一緒にやるだけでも効果が見込めます。
パフォーマンスが落ちることをチームメンバー、ステークホルダー全員に繰り返し伝える。
当たり前ですが人が増え、やり方が変わると学びや試行錯誤が必要なのでパフォーマンスが落ちます。 スケールを希望するステークホルダーにはこのことを十分に理解してもらう必要があります。 自分の場合2〜4スプリントかかることを織り込んでおり、これでも改善の見込みがなければやり方がまずいと考えなんらかの手をうちに行きます。
少しずつ増やす
メンバーの1/3が新しく入るのがギリギリ、1/2になるとうまくいくかどうかは賭けだと思っています。 増やす時は数だけでなく、業務の性質(toC/toB、リリース間隔、スキルセット)、メンバーの性格(前向きに新しいことに取り組む、分からないことを聞くことを恐れない)をかなりよく考えて決めるとよいです。
チーム数を増やすときは下記にそれぞれ壁があるのでメンバー・ステークホルダーと事前に話しておくと良いです。
- 1→2 : スケールの最小限。チームが対等にコミュニケーションを取り、タスクをこなせるか。
- 2→3〜8 : 1人のプロダクトオーナーの目が届く限界。チームが自律的に必要なコミュニケーションを取り、タスクをこなせるか。
- 8→N : 責任者が全員の顔を覚えられなくなるであろう限界。プロダクトオーナーも複数人で責務を分担する必要がある。
組織を見ることは悪いことではない。
反省に含まれていましたが、私は悪いことではないと思っています。 単一チームのことをいつまでも気にかけることはできず、2人目を見出し、育てて任せないといけないはずです。
いいスモールチームであっても自律的に連携しない
複数のスクラムチームを育てることと、それらが連携して1つの成果を出せるかは別問題であり、その解決のためにスケーリングアジャイルのフレームワークが存在していると認識しています。なのでチーム同士のコミュニケーションを律するなんらかの仕組みは必要だと思います。
おわりに
しくじりの反省としてでていた上記スライドですが、よく読むとスケールすることのメリットはちゃんと出ています。
- プロジェクト全体の俯瞰
- 作業の分担、余裕
- 属人化の解消、ペアプロ・モブプロ
今回はしくじり事例とのことでしたが、ぜひまたスケーリングにチャレンジして学びを共有して欲しいです。 今年もアジャイルのスケーリング一緒に悩んでいきましょう！
Regional Scrum Gathering Tokyo 2020に参加しました #RSGT2020
はじめに
去年に引き続いて2回目の参加です。今年はスポンサーとして参加してきました。 スポンサーから見た話は会社のブログに書いたのでここでは個人的なメモを残します。
聞いてきた話など
基調講演が最高！
Coplienさんの十牛図になぞらえたScrumの理解・説明はいろいろと考えるところがありました。「アジャイルの理解・実践の段階が進んでいればいい」という単純な話ではなく(「It is NOT good, it is NOT bad.」と何度も言っていました)、自分たちの現在地を知り、内なる声に耳を傾けて目的地を決め、日々改善を積み重ねていくしかないんだという指摘が、これからもまだまだやれることがあるのだと身に染みました。
Sahotaさんのアジャイルな組織におけるマネージャーの位置付けも、ここ1年の自分の実践(スクラム開発チームの外でサポート、プロセス改善・人材開発に注力)に近く、非常に納得感のあるものでした。自己管理チームを作ると自然と上が下を支える形に変わっていくのを日々感じています。
その他心に残った話
椎葉さんのスクラムチームにおけるTech Leadの役割も自分の考えに近く、非常に明快に言語化されていてためになりました。 「任せる時はコミットメントを信頼する。コミットメントは献身のことであり、結果ではない」、「相手が受け取った感情を否定しない。その原因に対処する」といった言葉は椎葉さんの思いやり・優しさ・凄みが滲み出ていて、今年も話が聞けてよかったと心から思いました。
TargetのDX変革のための教育場作りもロジックが整理されていて聞きやすかったです。「世の中に新しく生まれる仕事のうち、大卒で埋められるのは19%」という数字をつきつけられると、「足りない分は既存のメンバーを教育する必要がある」のは自明ですよね。「XXXできる人がいない、採用できない」と嘆くだけでなく、場を用意し成長に期待するのはいつだって必要な事だと再認識しました。
立ち話・ブースでの情報交換ができた
2回目の参加だからか、知り合いが増えてきたからか、セッション外での交流がたくさんでき、これだけでも参加に値するものでした。 聞かないと分からなかったような事例、非公開での情報交換のお願い、ワークショップの開催打診、お会いしたいと思っていた方々との繋がり。これができたのは運営の皆様に場をきちんと整えていただけたからだと感じています。
今年の感想
昨年転職し自分のチームは変わりましたが、去年の感想と変わらずアジャイルな開発/スクラム開発の実践が進められていたと再認識しました。 今年も一層の精進を目指し、日々の実践・コミュニティへの貢献をやっていきます。
まずはScrum Fest Sapporoにプロポーザルを出してみました。興味を持っていただけたらぜひ投票(リンク先に遷移→ログイン→プロポーザル表示にあるハートマークをクリック！)をお願いします。
#RSGT2020 を楽しむために
はじめに
いよいよ1/8(水)からRegional Scrum Gathering Tokyo 2020が始まります。 私も去年が初参加でしたが、今年も参加できることを楽しみにしています。
今年から会場が変わり、参加者数も増え、初めて参加される方も多いのだろうと予想しています。 自分も今年より楽しむために、去年知っていたらよかったなーと思ったことを思い出したので下記に紹介させていただきます。
アドバイス
タイムテーブルは印刷して持っていく
詳細スケジュールがConfengineで管理されていますが、スマホではタイムテーブルがうまく表示されず苦労しました。 昨年は会場にもタイムテーブルが印刷されていなかったので紙に印刷して持参すると何をみようか考えるときに役立つと思います。
大きめのカバンを持っていく
ストラップ付きの参加証に加え、記念品(昨年はビールグラスでした)、水・お茶、本、ブースでもらえるノベルティなどいろいろな配布物がありました。 ジャストサイズのカバンで行くと持ち帰りに苦労することになるので余裕を持っていくと良いと思います。
参加者に積極的に話しかける
初日の最後にネットワーキングパーティーがあります。 「初日に仲良くなってイベント盛り上がろうね」な位置付けだと思うのですが、初めて参加する人にとっては初日は仲良くなるきっかけが少なく、「旧知の人や同じ職場からきた人たちが集まってが飲み食いする場」になりがち(見えがち?)です。 一方通行で話を聞いて終わりのカンファレンスではなく、双方向に意見を交わしてよりよいやり方を模索するカンファレンスなので、普段の勉強会では他人と話さず帰宅してしまうあなたも、ぜひ積極的に話しかけてみてください。
また講演は発表時間ギリギリでQ&Aの時間が取れないものが多かった印象です。 なので疑問に思ったことは発表を終えて会場をうろうろしている講演者を捕まえて直接話しかけると良いです。 よくよく聞いてみると発表者の多くもフィードバックを期待しているそうです。
セッションに参加しなくてもよい
タイムテーブルをみてどれを選ぼうか考えてしまいがちですが、ピンとくるものがなければ講演を聞かず廊下にいる誰かと話を しても良いカンファレンスです。
講演者の言っていることが正解とは限らない。素直な気持ちで疑問をぶつけてみよう。
プロダクト開発は一つとして同じ事例がなく、唯一の正しいやり方があるものではないので講演者が言っていることが必ずしも正しいということはありません。 去年は基調講演でChris Lucian氏が「no estimates(見積もりしない)」を提唱していましたが、それに疑問を持った参加者が3日目の議論の場で「見積もりの良い点を議論しよう」と言っていました。それを受けてChris Lucian氏も「no estimateを参加者と話したい」と議題を挙げていました。誰かの発表を受けて議論があちこちで始まるそんなライブ感のあるカンファレンスです。
今年は大崎ではなく御茶ノ水です！
うっかり大崎に行かないようにしましょう。
ジョブボードを活用しよう(追記)
アジャイルな職場を探している人・アジャイルな人材を探している人向けにジョブボードがあります。 実際に転職に繋がる事例もあるので是非活用しましょう。
See also
去年の参加振り返り記事
他の方が書いたRSGTの楽しみ方
