tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

リモートでアジャイル開発に取り組んでの変化

f:id:tune:20200517085050j:plain
Photo by Anna Auza on Unsplash

コロナウイルスの影響で自社でもリモート推奨・原則リモートで開発するようになり、3ヶ月が経ちます。 「どうリモートワークをしているか」の記事はよくみますが、「リモートでアジャイル開発をどう行っているか」に限定した記事はあまり見かけないので自分の記録も兼ねて残しておきます。

スプリントレビュー

元々Google Meetで中継していましたが、徐々にMeet参加者が増え、原則リモートになってからは全員Meetで参加する形となりました。 5チームの大規模スクラム(LeSS)でやっていますが、各チームの代表者が持ち回りで発表する形式をとっていたので、Meetになっても画面共有を回す形をとっています。 最初のうちは画面共有にてこずったり、音声がうまく入らないといった課題が起きたため、スプリントレビューの直前にリハーサルの予定を入れ、画面共有ができるか・音声がきちんと聞こえるか・発表内容が整理できているかといった事項を確認する時間をとるようにしました。

デモ中の反応が少なく寂しいという課題にはMeetのチャットを使うようにし、普段以上にリアクションすることを意識してもらっています。以前は質疑応答をSlackチャンネルに投げてもらっていましたが、一つのツールで完結する方が皆の集中力が削がれず良さそうです。

またスケジュールが合わずスプリントレビューにどうしても参加できないメンバーがいたため、レビューを録画して共有するようにしました。Meetの録画は非常に簡単で、動画・チャット内容がGoogle Driveに自動で保存されます。子供をみながらのリモートワークだと急遽出れなくなるメンバーもいるため、録画は非常によい打ち手だったと感じています。

リファインメント

複数チームをまたいだメンバーで毎日バックログリファインメントを行っています。

出社していた頃は時間になると近くのメンバーに声をかけメンバーを集めていましたが、リモートになるとリファインメントの希望があるか申告制になりました。当初はSlackでメッセージを送るだけでした流れてしまうため、今ではGoogleフォームに記入してもらい、その結果をスプレッドシートに記入し、当日にSlackワークフローで予定を通知する仕組みを設けています。

使用するツールは当初Meetを使っていましたが、リファインメントの対象件数が多いとメンバーを分割する必要があるため、ブレイクアウトルーム機能を持つZoomに移行しました。しかしZoomの無償版だと40分でミーティングが終了してしまい、ブレイクアウトルームの管理もミーティングの主催者しかできず、MeetとZoomを混在して使うことに混乱するメンバーもいたため、使用をやめました。

現在はDiscordのボイスチャンネルに集まって行っています。チーム分けも簡単にできて良いのですが、サーバー負荷からか画面共有ができない/不安定になることがあるのんが課題です。

スプリントバックログ(カンバン)

元々物理ふせん を使ってやっていましたが、Spreadsheet / Confluence /Github Projectを経てMiroになりました。 カンバンを物理で運用する期間が長かったため、ツールの都合に自分たちを合わせず、要求を満足するものにたどり着けたのだと思います。 Miroになるかなとは昨年の時点から予想していましたが、一気に移行が進んだのは強制リモートワークによるところが大きかったなと思います。

振り返りやワーキングアグリーメントも同じボード上で残しており、物理の使い勝手のよさが残っているように感じています。

進捗共有

チーム内・チーム外への進捗共有が徐々に洗練されていきました。

チーム内のやりとりは専用Slackチャンネルを活用し、これまでよりも密にやりとりしています。またテキストコミュニケーションだけにとどまらず、DiscordやMeetもうまく活用しているようです。ちょっとした質問・雑談はDiscordで、30分を超えそうな相談はMeetでやるように住み分けができています。ペアプロ・モブプロもこれらのツールを活用する形で自然に運用されています。

チーム外への進捗報告も毎日デイリースクラム後にスクラム開発に携わる全員が入ったSlackチャンネルで行われています。代表者がまとめて報告する形・メンバーが個別に報告する形が混在していますが、報告の粒度は欲しい情報を互いにフィードバックし合うことで徐々に揃うようになってきました。

タスクの進め方

以前は1人1ストーリーを担当してスプリント内に完了させるスタイルが多かったように感じたのですが、タスクを小さく分解し、細かく協力・分担しあって進めるやり方が増えてきたように感じています。

下記要因の複合ではないかと考えています。

  • コロナ影響で全社的な開発優先順位が変わり、これまで開発の核になっていたメンバーが別プロダクト開発に携わるようになった。結果的にチームの開発力が以前より落ちた。
  • 4月になり新卒がチームに配属された。
  • 在宅で子供の世話をしながら仕事をするメンバーが増え、詰まったとき・手が離せなくなったときに誰かに協力を仰がないとデリバリーできない。

全体的に

「リモートワークだからこういうツールを使えば良いよね」と決めつけから入るのではなく、都度発生した課題を少しずつ実験しながら解決することでいい感じにカイゼンが進んでいると感じています。

Failed #SquadGoals を読んで

はじめに

Spotifyモデルに反論する下記記事を読んで、いろいろと考えさせられるところがあり、記事の概要・考えたこと・守田さん(@wsfjp)・藤村さん(@aratafuji)と議論した内容をまとめました。

www.jeremiahlee.com

Spotifyモデルと本記事の概要

Spotifyモデル」は2013年頃のSpotify社の開発体制を指して使われる用語です。 Squads / Tribe / Guildなど特徴のある呼び名でグルーピングを行ったマトリクス型組織であり、各チーム(Squads)に強い自律性を持たせたことが特徴です。

Spotifyモデルはアジャイル開発のスケーリング事例・フレームワークとして一定の支持を集めていました。

本記事はそんなSpotifyモデルが機能しないとJeremiah Lee氏が主張したものです。 記事では2017年にSpotifyに入社したとありますが、著者のLinkedInを見るに2018年4月にはInVision社へ移っているので1年弱の体験に基づくものと思われます。

整理すると下記の課題を主張しています。

  1. マトリクス組織の問題(Matrix management solved the wrong problem)
    • エンジニアは機能軸で切られたチーム(Squads)に所属するが、職能軸で切られたChapterにも所属し、Engineering Managerの元管理される。
    • 機能軸の責任者であるProduct Managerは技術課題の解決のため複数のEngineering Managerと調整が必要。
  2. チーム自律性に重きを置きすぎた(It fixated on team autonomy)
    • 「チームが好きなことをできる」を自律と勘違いしてしまう。製品価値・説明責任よりも自律の優先順位が優ってしまう。
  3. チーム単位でのコミュニケーションプロセスの不在(Collaboration was an assumed competency)
    • チーム同士で協力するためのフローが定義・整備されていない。
    • アジャイルコーチが不足しており、エンジニア皆がアジャイル開発を理解していない。
  4. Spotifyモデルが有名になりすぎた事で変えることが難しくなった(Mythology became difficult to change)

疑問に思ったこと / 議論して腹落ちしたこと

Spotifyモデルの根本的な問題なのか、組織の運用の問題なのか

半々かもしれない。 プロセスに関する健全な批判があるのは、まだ機能している証拠とも言える。 一方でSpotifyモデルを運用する上で課題になりそうな点がやはり指摘されており、単にコピーすればうまくいくものではなく、自分の組織に合わせて常に考え続けなければ使い物にならなそう。

Engineering Managerの権限が弱すぎる問題なのでは

Engineering Managerがエンジニアに関与する権限を強くしたり、序列をつけたりして技術的に揉めたときの決定プロセスを明確にすれば良いかと思ったが、そもそもマトリクス型組織は長続きしないといわれてそうかもと思いました。

マトリクス型組織は縦軸(機能軸)か横軸(職能軸)か、その時に仕事が進めやすい一方に自然と寄ってしまい、形が崩れてしまうものなのかもしれません。 この記事の指摘はSpotifyでマトリクス型組織の形が崩れても、戻すことも止めることもできないことから上がった問題点のように感じます。

この記事から何を学ぶべきか

Spotifyモデルがバズり、広く知られた結果、これを根本から見直すことがSpotifyの中でやりにくくなってしまったことを「Mythology became difficult to change」は指しているかもしれません。 アジャイルな開発では小さく実験を繰り返し、うまく行った少しのことを大事に育てていく方がよいとされていますが、確かにSpotifyモデルは出自が明示されていません。試行錯誤の結果生まれたものではなく、誰かが意図して入念に設計したものなのかもしれません。これはHenrik Kniberg氏に聞いてみないとわからないことですが。

その他

そんな筆者はどんな開発プロセスにすべきと考えているかというとSAFe推しのようです。Fitbitでうまう行ったとなっていますが、強いトップダウンでの開発が好きなのかもしれません。強い自律性を第一とするSpotifyモデルとは対極です。

More than 200 people in your product—engineering—design organization? The Scaled Agile Framework worked well for Fitbit when I worked there.

またSpotifyモデルを世に出したHenrik Knibergはどうしているのだろう・・・と思ったらもうSpotifyにいないそうです。 Minecraftを開発するMojang社に2019年3月に転職していました。

Henrik Kniberg – Official Minecraft Wiki

トヨタの製品開発: トヨタ主査制度の戦略,開発,制覇の記録

はじめに

トヨタ マークⅡ 3代目の開発過程を綴ったドキュメントですが、冒頭に主査制度の説明があり、全編を通じて実例を交えて主査の働きを理解することができる本になっています。 車種ごとに社長よりも強い決定権限を持つ主査を置き、全てに責任を持たせるという制度は非常に興味深いものでした。

開発初期の段階から1人に責任を集め全体に目を光らせることで、初期から売れる製品をプロセスとして作り込むことができているのだと思います。

トヨタ主査制度

目的

一人の主査に担当車種に関する全ての領域を見ることを移譲し、決定権と責任の所在を一元化する。 「担当車種に関しては、主査が社長であり、社長は主査の助っ人である。」

主査は下記の全てを主導し、その結果について全責任を負う。

  • 企画:商品計画、製品企画、販売企画、利益計画など
  • 開発:工業意匠、設計、試作、評価など
  • 生産:生産開始
  • 販売:発売準備、記者発表、店頭発表・販売促進、定期報告

主査制度を実現する組織構造

技術部門の一部署である製品企画室に所属する。製品企画室は室長、副室長、主査10から20人から構成される。

  • 室長 : 専務取締役または常務取締役
  • 副室長 : 取締役
  • 担当主査 : 部長または次長クラス。

室長・副室長は部下の主査の人事権を持つが、個別の車両に関して担当主査に命令することはない。

一人の主査と若干名の主査付から主査グループを構成する。製品開発の初期は少なく、後期になるに従って他部門からの派遣者を受け入れて多くなり、製品発売後には再び少なくなる。 主査は直属の主査付については人事権を持つが、他部門からの派遣者に対しては持たない。

主査室は大部屋制で、主査グループの間には間仕切りがない。 他グループとの情報交換は日常茶飯事に行われる。

主査と主査付の関係性

主査と主査付は同一人格とみなされる。 そのため主査は日頃から自分の考え方を主査付と揃えておかなければならない。 また主査付も先の問題を予測して、主査の考えを事前に把握しておかなければならない。

  • 主査付は主査の意思に沿って発言・行動しなければならない。単独で決断が必要な場面では主査を代行して行う。
  • 主査は主査付の決定が自らの意思に反していても、主査付の発言・行動とその結果に対して責任を負わなければならない。

主査が持つ権限

主査の意思決定は製品開発の全てに関わる。 提案書類・設計図には主査のサインを持って発行される。

主査は直属の主査付以外には人事権も命令権も持たず、「説得・調整する権利」だけを有する。 「本当に主査の主張が正しいのであれば、関連部門のメンバーは理解を示す」という考えに基づいている。

主査は社内外の誰でも「説得する」権利を与えられており、必要であれば社長・副社長・協力会社の誰でも自分から面談・説得する権利を持つ。

Re: Pull Request レビューの限界

はじめに

読んで色々と思うところがあったのでアンサーソングです。

note.com

tl;dr;

レビューはバグを見つけるための門番では無く、コード品質をよくするための仕組み。Pull Requestの形式にこだわる必要はない。

Pull Requestの位置付け

「目を皿のようにしてバグがないか、ロジックを追う」コードレビューをしてくれる人がよくいますが、レビューでバグを見つけるのはコストが高いと思っています*1。またレビューでバグが見つけられるエンジニアは開発力が高い人となり人数も限られます。その人にレビューが集中すると負荷が高まり、徐々に門番化していくことは避けられないでしょう。

バグがないか検証したいのであればテストをきちんと書くべきです。仮にテストが書きにくい箇所があったとしても開発者がきちんと動作確認を行うべきです。

レビューの目的はバグを見つけることではありません。 私は「開発者個人の責任から、開発チーム共同責任にする」ための儀式だと考えています。

自分がメンバーにお願いしていること

開発部門のマネージャーとして、上記の文化を醸成するためにメンバーにはこんなお願いをしています。

  • わからなくてもコードをレビューして欲しい。
  • レビューしたらなんらかの反応を残して欲しい。
    • 良いねでも、勉強になりましたでも、LGTMでもいい。
    • 読みにくいコードがあれば読みにくいとコメントして欲しい。
    • わからなければそのまま「この箇所がよくわかりませんでした」と書いて欲しい。
  • コメントでのやりとりが続いたら直接話して欲しい。PR上でのレスバトルは不毛
  • 自動アサインするとその人しか見なくなるのでアサインは意図的につけない。
    • 「人のPRをレビューしてないな」と感じる人がいたらマネージャーとして1on1でレビューするように促す。

tune.hatenadiary.jp

Pull Requestレビューは必要か?

プロダクトのリリース前にレビューがなされるのであれば直接git push masterした後にレビューを行う形式でもよいと思っています。 個人的にはトランクベース開発の方が好みだし、実際にうまくいった開発現場も経験したことがあります。

コードの設計議論はコードを書き始める前にメンバーと同意を取っておいた方が良いです。 ホワイトボードなり紙なり簡単な方法で詳細を詰めておくべきです。 コードを書き終わってから設計のまずさが指摘されるのは、OSS開発プロセスに憧れすぎた人の過ちではないかと思っています。

*1:この形式のレビューがダメという主張はないです。全員がこうするべきとは思っていないだけです

帆船のふりかえり / Sailboat Retrospective

f:id:tune:20200301195654p:plain

はじめに

チームのふりかえりはいつもKPTを使ってしまいますが、Agile Talks vol.1で帆船のふりかえりというものを知りました。日本ではあまり聞きませんが、海外では割とメジャーみたいです。"sailboat retrospective"で調べると例がたくさん見つかります。

f:id:tune:20200301174332p:plain

sailboat retrospective - Google 検索

一度聞けばやり方は簡単に覚えられますが、実践する人が増えるように日本語でやり方をまとめておきます。

やり方

  1. 中央に帆船、左右の一方に追い風の絵、もう一方に島の絵を描く。
  2. 船の下に錨と岩の絵を描く。
  3. 各箇所ににチームの現状を当てはめてコメントを書く。
    • 追い風 : チームにとっての追い風、チャンス・機会
    • 島 : チームが到達したいゴール・ビジョン
    • 錨 : チームが島を目指すにあたり阻害要因となっていること
    • 岩 : 気にしなければならないリスク

KPTとの違いとして、「絵を描くことでチームのムードを表せる」、「帆船とゴールの位置関係を生かして中期的な目標・長期的な目標を表現できる」ことがあるかなと感じました。

森さん(@viva_tweet_x)からのアドバイス

ふりかえりで有名な森さんから、RSGT2020の会期中にやり方を聞く機会があったので、もらったアドバイスを紹介します。

順序は決まっていないが、KPTと同じ順序でやると良い

コメントを記入する箇所がいくつかありますが、KPTと似たような項目なので、K->P->Tの順に話していく方が話しやすいそうです。

すなわち下記の順となります。

  1. Keep : 追い風
  2. Problem : 阻害要因・リスク
  3. Try : ゴール

モチーフは帆船でなくても良い

ゴールを目指すモチーフとそれを阻害する要因があればよいので帆船以外の絵でもできるそうです。

例えば縦長のホワイトボードを使う時は空を目指す気球・ロケットで絵を描くと似たようなふりかえりができます。

参考

www.infoq.com

luis-goncalves.com

大規模スクラム(LeSS)に取り組んでいる国内事例一覧

昨年自社(Retty)に大規模スクラムを導入した際、社内で「LeSSの国内事例は無いのか?」という質問をもらって困ったことがありました。LeSS実践者研修に参加したり、大規模スクラム本を読んだり、LeSS Studyに参加するなど学んでいる人はいたのですが、事例はなかなか出回っていませんでした。少しずつ聞いて回ったところある程度数がまとまったのでまとめて公開します。公開されている資料をベースにまとめていますが、「うちもやってるよ!」というところがあればぜひお知らせください。

Retty

グルメサービスRettyの開発。

f:id:tune:20200208134642p:plain

atama plus

塾向けのタブレット型のAI教材の開発。

f:id:tune:20200208140719p:plain

Cybozu

kintone、Garoonの開発。それぞれLeSSをベースに5-6チームくらいまでスケーリングさせているそうです。

f:id:tune:20200208133915p:plain

ebookjapan

国内最大級の電子書籍販売サービス

f:id:tune:20200208132229p:plain

Groove X

家族型ロボット「LOVOT」の開発

f:id:tune:20200208131050p:plain

Repro

カスタマーエンゲージメントプラットフォームの開発

f:id:tune:20200208134453p:plain

2021/8/5追記 LeSSやめたそうです。

f:id:tune:20210805091604p:plain

尾藤正人氏(BTO氏)|世界を代表するテックカンパニーを目指す!世界66ヶ国で導入されるシステムの3代目CTOに迫る | 国内唯一のCTO/VPoE育成・転職支援サービス「OCTOPASS(オクトパス)」

SmartHR

クラウド労務ソフト「SmartHR」の開発。

f:id:tune:20200208141044p:plain

Ubie

AI問診Ubieの開発

f:id:tune:20200208135551p:plain

アソビュー!

便利でオトクな遊びの予約サイトの開発。

f:id:tune:20200208140305p:plain

うるる

クラウドソーシングプラットフォーム「シュフティ」及びクラウドソーシングを利用した入札情報サイトなどの開発。

f:id:tune:20200208140431p:plain

ヤフー株式会社

クレジットカード事業に関わるシステム

f:id:tune:20200208131433p:plain

Yahoo! MAP、Yahoo! カーナビ

地図アプリ・カーナビアプリの開発

f:id:tune:20200208140901p:plain

リクルートライフスタイル

Airレジ(海外版)の開発。

f:id:tune:20200208135034p:plain


以下は記事初回公開後の追記

Mixi (2020/3/4)

家族アルバム「みてね」の開発

f:id:tune:20200306075900p:plain - 組織の壁みたいなもの. 会社のブログではないでのあくまで個人の雑記です。 | by Atsushi Sakai | Medium

2021/6/25追記 LeSSやめたそうです。

f:id:tune:20210625200448p:plain

みてねの開発スタイルを大きく変えた話 - Atsushi Sakai - Medium

Timers (2020/3/12)

家族アプリFammの開発

f:id:tune:20200312115539p:plain

東京海上日動システムズ (2020/10/24)

地震保険プロジェクトの開発

f:id:tune:20201024095335p:plain

NEC (2021/2/19)

f:id:tune:20210227161447p:plain

アカツキ (2021/3/20)

f:id:tune:20210320090420p:plain

OPTiM (2021/4/25)

f:id:tune:20210425104328p:plain

LINE (2021/5/19)

LINE TODAYの開発

f:id:tune:20210519102217p:plain

ラクス (2021/7/8)

HERP (2021/8/2)

f:id:tune:20210803100737p:plain

Mobility Technologies (2021/10/22)

f:id:tune:20211022142501p:plain

はてな (2021/12/09)

Mackerelの開発

f:id:tune:20211209084616p:plain


[asin:B07RFVB7KG:detail]

耐えるコミュニケーションからの卒業

はじめに

マネージャーとして多くの人と仕事をし、メンバーが伸び悩んでしまうパターンに「耐えるコミュニケーションに陥る」例が少なからずあるなと感じていました。自社イベントで話す機会があったのですが、同内容をブログでもまとめておきます。あらかじめ断っておくとこれは特定の誰かを非難するものでは無く、多くの人がある特定の事象に関しては陥ってしまうことがあるように感じています。

耐えるコミュニケーションとは?

下記のように思い込んだ行動をとってしまうパターンを指しています。

  • 相手の指摘にひたすら耐える。言われたことだけ対処する。
  • 一定時間耐えたら次の段階に進めると思い込んでいる。

エンジニアだけに限らず、一般的な全ての業種で起き得るのではないでしょうか? 例えば個人的な経験では下記の事象で遭遇したことがあります。

  • レビュー
  • 対外発表
    • 学会、勉強会、カンファレンス、論文
  • 会議資料
    • 事業計画・ビジネスモデルなど

全体的に「答えがない」ものに対して起きがちではないでしょうか?個人的には前職の昇進試験論文がこのパターンにハマってしまいました。毎年試験時期が近づくと終わりのない書き直し練習を嫌がってやっていたのを思い出します。

なぜ耐えるパターンに陥ってしまうのか

直接的な原因は「期待するレベルと本人のレベルに一定以上の差があるから」だと思います。 間接的には「壁を乗り越え方がわからない」「答え・正解がないものに取り組んでいる」「受け手がこういうものだと観念してしまう」ことが引き金になっていると思います。 「自分はXXXに目を付けられているから邪魔されている」「どんな資料を作ってもイチャモンを付けられる」「提出日ギリギリまで直しが続く」とか、覚えがありますよね?

耐えている本人はいろいろと頑張ってはいるものの、耐えることが主目的になり近視眼的な対応・行動が増えます。 また指導をするメンバーも時間が取られ色々と疲れてしまいます。どちらも非効率です。

耐えるパターンから抜け出すにはどうしたらよいか

まずは耐えている本人に状況を理解させることから始めています。 「耐える」考え方をやめさせるために「一定以上のレベルに達したら終わる」ものであることをまず強調します。

つぎに一緒に伴走してあげます。自分でやり方を見つけて欲しいマネージャーの気持ちもわかりますが、「耐え」パターンに陥った人が自力で抜け出すのは困難です。プログラミグならペアプロ・モブプロをする、資料ならアウトライン・構成を一緒に考えるなどを行い、詰まっているポイントを理解し、助け舟を出してあげます。

最後に壁を登り切るまで見届けます。 途中で切り上げさせて別の機会に改めて取り組ませることもできますが、それだと成長はできておらず、問題の先送りにしかなっていません。 この手の問題は一度レベルを上げると下がることがないので、何度もチャレンジさせるより、一度登り切らせた方が効率が良いです。

おわりに

かなりあちこちで観測する事象だと思うのですが、良い名前がついていないために議論されることが少ないように感じています。 もっと良い名前を見つけた方はぜひ教えてください。