tuneの日記

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

Shape Up - Basecampによるプロダクト開発ガイド

f:id:tune:20200823130404p:plain

はじめに

Basecamp社が公開しているプロダクト開発ガイド「Shape Up」の存在を知り読んでみました。 Basecamp社はプロジェクト管理SaaS Basecampの開発元で、以前は37 Signalsという社名でした。 Ruby on Railsの作者 David Heinemeier Hansson氏がCTOを務め、最近だと新機軸のメールサービス Hey を立ち上げています。

basecamp.com

特徴

Basecamp曰く「アジャイル開発でもスクラム開発でもない」、Basecamp社で15年近く試行錯誤して改善してきたやり方だそうです。

「6週間の開発サイクル」と「2週間のクールダウン期間」を繰り返して開発を進めます。 サイクルの途中で中断・見直しはせず、期間内にリリースに至らなかった場合でも期間延長はされません。 6週間は「何か意味のあるものを最初から最後まで作り上げるのに十分な長さ」であり、「誰もが最初から期限を感じることができるほど短い」、経験から導き出した開発期間とのことです。

開発チームが着手する前に少人数のシニアグループが事前に検討を済ませておきます。 ただしこの事前検討(Shaping)は適切な抽象度までで留めるよう留意します。 「チームが何をすべきかを知っているほど具体的である」一方、「詳細を自分たちで考え出す余地がある」程度を目指します。

進め方

  1. Shaping
  2. Betting
  3. Building

Shaping

開発する項目を考えますが、「適切な開発スコープを切り、事前に決めすぎないようにバランスをとる」ことに留意する必要があります。

「開発前に決めすぎない」とは下記のような事例を指します。

  • ワイヤフレームを描いてしまうと具体的すぎます。開発着手後にデザイナーが創造性を発揮する余地がありません。
  • 言葉による説明は抽象的すぎます。開発着手後にチームが要件を満たす中でトレードオフを見つけるのに十分な情報を与える必要があります。

ガイドではプロジェクト管理ツールにカレンダーを追加しようとした例が挙げられています。 通常カレンダーには月・週・日のビュー切り替え、予定の移動などたくさんの機能が求められていますが、6週間内でリリースするには機能を絞り込む必要があります。 そこで「月表示のカレンダーにイベントをドットで表し、クリックすると詳細が見える」ところまでに機能を限定したそうです。 その際のShapingでのデザインが下記です。

https://basecamp.com/assets/books/shapeup/1.1/calendar_sketch-355ff96889735772138625e1d56acdbc8740186af109b5383cc5954939349cb4.png

これが開発完了時にはこうなりました。見比べると当初のデザインは詳細が省略されているものの必要な要素は満たしており、何がスコープの範囲外になるのかが明確になっていたことがわかるかと思います。

https://basecamp.com/assets/books/shapeup/1.1/calendar_screenshot-f8bcf5d1a0cd1642043ed106ac8b58db460e86acad341bde1a848f20fe1683a3.png

Shapingはインターフェース・技術的な実現性両方を考える必要があり、ジェネラリストが行うか、デザイナーが主導し他のメンバーと協力して進める必要があります。 インターフェース検討時にワイヤーフレームは具体的すぎるため、インターフェースを構成する主要なコンポーネント・関係を元に議論します。

  • Places : 画面・ダイアログ・ポップアップなど、ナビゲートできるもの。
  • Affordances : ボタン・入力欄などユーザーが操作できるもの。
  • Connections : ユーザー遷移

https://basecamp.com/assets/books/shapeup/1.3/invoice_breadboard_6-728e11c77b57f3c4ee56c00187a7c760562090f3733a4aec43cc05a2f95bb003.png

Shapingのアウトプットは開発スコープを説明する「Pitch」です。 Pitchは下記から構成されます。

  1. 問題点 - 生のアイデアユースケース、またはこの作業に取り組む動機となる何か
  2. Appetite(食欲) - どのくらいの時間を費やしたいのか、そしてそれがどのように解決策を制約するのか
  3. ソリューション - すぐ理解できる形で提示されたコアな要素
  4. リスク
  5. スコープ外の項目

Pitchはステークホルダーが時間のあるときに読めるよう、課題管理システムのIssueにまとめているなどして置いておくそうです。

各Pitchに対しては以下の2種類に分ける程度の見積もりしかしません。Shape Upの用語では"Appetite(食欲)"と呼びます。

  • Small Batch : 1人のデザイナーと1〜2名のプログラマーが1〜2週間で実装できるサイズ。
  • Big Batch : チーム全員で6週間かかるサイズ。

Betting

次の6週間で取り組むPitchの候補は"Betting Table(賭け)"の場に持ち込まれ議論されます。 Betting Tableはクールダウン期間に行われる会議で、CEO・CTO・シニアプログラマー・プロダクトストラテジストが参加します。 全員が事前にPitchを読み込んだり、関係者と話して勉強してきているため長くかからず、1〜2時間程度で終わるそうです。

計画ではなく期待値を決める賭けの場であり、6週間後に何か意味のあるものが完成することを目指します。 失敗しても高々6週間分のリソースが失われる程度に抑えるリスクヘッジの仕組みでもあります。

チームは「 デザイナー1名・プログラマー1 or 2名・QA担当者 (サイクルの後半で統合テストを行う)」で構成されます。 6週間の間、割り込みがないように留意します。

バグが見つかった場合、下記のいずれかで対処します。

  1. 2週間のクールダウン期間を使う
  2. Betting Tableにバグ修正を持っていく
  3. バグ対処だけを行う日を決めてそこで対応する

Building

早期にPitchをタスク分解してしまうと全体像を見失ってしまいます。 これはタスクが割り当てられてしまうと、互いの作業の関係性に注意が向かず、判断する責任を感じなくなってしまうためです。

そこでチームは手を動かしながら適切なスコープ(単体で価値が提供できる切れ目)を見つけ、開発タスクを徐々に分解していきます。

https://basecamp.com/assets/books/shapeup/3.3/drafts_4-1abbc8645f679d8db90f22ae2cc58e48f241a9a17f5c94555dc34ff64f2c5659.png

スコープが正しいことを示すサインは下記の通りです。

  1. プロジェクトの全体を見渡せるような気がして、心配するような重要なことが細部に隠れていない。
  2. スコープが適切な言葉を与え、プロジェクトについての会話がスムーズである。
  3. 新しいタスクが出てきたとき、どこに配置すればいいのかがわかる

進捗は「できたこと」「できていないこと」ではなく、「わからないこと」「解決したこと」にフォーカスします。 プロジェクトを丘にたとえ、スコープごとに今現在どこにいるかを示すことで進捗を見える化します。

https://basecamp.com/assets/books/shapeup/3.4/scopes_on_the_hill-592ba06433e0fbc0e45c6344efdcb44e7d2c495b8d0f0d6048e2b8aa030acb88.png

6週間で終わらなかった開発を継続する場合、下記の両方を満たす必要があります。

  • 価値が十分に議論され重要である
  • 丘を登り終え、下り途中である

リリースすると顧客から負のフィードバックをもらうこともありますが、しばらく待って注意深く観察します。 安易に対応したり、過去バージョンに戻したりせず、機能修正の対象としていた顧客の反応をきちんと見ましょう。 またフィードバックはすぐに対応せず、次の賭けとしてBetsにかけます。

HEYの開発事例

すべてShape Upのプロセスに従って進めた。1年間のシニアチームによるR&Dと1年間の製品開発、リリース前の整理に2サイクルを費やしたとのこと。

  • 1年間のR&Dモード(Jason(CEO)、David(CTO)、Jonas(シニアデザイナー)の3人のチーム)
  • 1年間の開発期間
  • 2サイクルのクリーンアップ

感想

ポジティブな面

  • スクラムが明示的に規定していないノウハウを埋めてくれそう。
    • 着手前の設計・技術調査
    • 事前に設計しすぎないとはどういうことかという事例。

ネガティブな面

  • Basecampのような思想(少数の価値ある機能に注力し磨いていく)を前提にしていないと合わなそう。
  • 運用するのが難しそう。
    • 方向転換できるまでに8週間かかる。スタートアップでは長すぎ、ビジネスモデルを確立した企業では享受できるメリット(機能を絞り込んで開発し磨く)が小さいのでは?
    • 原文を読むとわかるがBetting以降の章はルールでなく運用ノウハウ・コツが多い。

スプリントレビューのやり方・オーバーオールレトロスペクティブのやり方 - LeSS Q&A

@yohtakuさんからLeSSのプラクティスをどう実践しているかに関する質問をいただいたのでブログにも転載しておきます。

1:バザー形式のスプリントレビューのやり方

tune.hatenadiary.jp

Q: 1ヶ所に集まって、みんなでワイワイやるって感じですが、オンライン&リモートの環境でどうされていますか? オンラインでも同じように1つに集まっているのか、それとも別々にやっているのか?など。

スプリントレビューは集まって各チームの代表者がデモする形でやっており、バザー形式ではやっていません。現在はMeetで代用しています。

バザール形式にしていないのは下記の理由です。

  1. LeSS移行当初は仕様の不統一がプロダクトで目立ち、指摘やフィードバックを全員に聞いて欲しかった
  2. 質疑応答がいま一つ盛り上がらないことが多く、分散化してさらにフィードバックが減ることを嫌った

1, 2はだいぶ解消してきたので、リモートを辞めたらバザールを再度検討するかもしれませんが、今のところ変更する予定はありません。

前職もLeSSでスプリントレビューに悩んだことがありましたが、その時は

  1. 同じ内容を何度もデモするのが辛い
  2. ステークホルダーの意見を聞きたい人が多く、バザー形式にすると聞けない人が多く出た

という懸念もありました。

オンラインで開く場合、Discordで行うと、「集まっている」感じが出て良いかなと思っています。

2:オーバーオールレトロスペクティブのやり方

Q: 1と似たような感じですが、わりと参加者が多めになると思っています。 どのようにやっているのか事例やハマった点(変わっていった点など)があればお聞きしたいなと。

オーバーオールレトロスペクティブの定義は下記を参照

LeSSのルール (February 2016 (5)) - Large Scale Scrum (LeSS)

オーバーオールレトロスペクティブは各チームのレトロスペクティブの後に行われる。ここでは複数チームの共通課題や広い領域の課題を扱い、改善に向けての試みを決める。この場にはプロダクトオーナー、全スクラムマスター、チーム代表とマネージャー(いる場合)が参加する。

自分たちはチーム代表者(スクラムマスター)とマネージャーで毎週開催しています。 各チームで振り返りをしてもらった後、振り返りの概要とチーム内で解決できない課題のエスカレーションの場として設定しています。 定義を参照しても「メンバー全員でやる」とはなってないですね。

あまりハマった記憶はないですが、それなりに重たい宿題が上がってくることが多いので、対処する課題は絞って少しずつ解消していくように気をつけてはいます。

July Tech Festa 2020で組織に良い開発文化を植え付ける「Software Engineering Coach」という役割の話をしてきました

はじめに

インフラエンジニアの祭典 July Tech Festa 2020で登壇の機会をいただき話してきました。今年のテーマが「Extend Your Engineering Life」ということで、自分のキャリア観についての話となっています。ひっそりTwitterなどのプロフィールは「Software Engineering Coach」に変えていましたが、今日を機にもっと積極的に名乗って行こうと思います。

講演動画


B2:組織に良い開発文化を植え付ける「Software Engineering Coach」という役割 - JTF2020

当日Slidoでいただいたコメント

Software Engineering Coach という役割は、社内でどのくらい浸透していますか?

自称なので浸透していません。これから名乗って行きます。

マネージャーという立場とコーチという役割の利害関係がぶつかる場合がありそうだなと思いました。やはりその都度いろいろな検討をされたのでしょうか。

利害がぶつかって他に手がない場合はマネージャーに倒して考えることが多いかなと思っています。 利害関係がぶつかることは頻繁にはないのですが、頻度が多くなるなら役割を分けることは必要なのかもしれません。

Twitterでいただいた主なコメント・質問

そうですよね、役割に関係なく良いソフトウェア開発やりたいですよね。難しい願いじゃないと思うんですが、やってみると難しいんですよね。

実際に効く弾丸(ただしとどめを刺すには至らず効果がいずれなくなる)と、効果がない錯覚が混じっているような気がします。テスト自動化は今まさにハイプを上り詰めようとしているところな気がします。Rettyもテスト自動化SaaSmablを導入していますがお付き合いしていくのはそれなりに大変です。

役割つけた瞬間に縛られることがありますよね。なので嘘にならない一番抽象度の高い役割を名乗ることって大事なのかなと思っています。

私が"Software Engineering Coach"の役割を見たのはTargetのミグズさんの講演でした。ConfengineのプロフィールもSoftware Engineering Coachになっていました。 f:id:tune:20200725143517p:plain

誰かが翻訳進めているのかもしれませんが英語だけのようです。これを見たオライリーの方、私に本の翻訳任せてみませんか😁

50万円ですね。十分ペイするとは理解していますが、会社として行かせるとなると改まってしまいます。

やり方を知っていてもできるわけではないですからね。RIZAPが流行ったのも同じ理由のような気がします。

ドキュメントに目的とかスコープを書いておくと後から見返してわかりやすくなりますよね(自戒)

エンジニアが不要なコードを消せないはずはないので、消えてないとしたら別な理由があるんですよね。習慣がないのもよくあるのですが、「消した場合の検証をどう行ったら良いのか前例がなくわからない」というのは自分も目から鱗でした。

コーチングやチーミングを目的にしてしまうとちょっとした変化で満足して続かないことはありますね。そもそも解決したかった問題は紙にでも書き出しておいてたまに振り返ると良いと思います。

やっていき( ・ㅂ・)و ̑̑

言及いただいたブログ

pazoo.hatenablog.com

amarelo24.hatenablog.com

補足

自分の原体験を話していたときのスライド、せっかく映画の画像引用したのに触れるの忘れていました。「陽はまた昇る」は日本ビクターがVHSテープを開発したときの実話を元にした映画です。デスマーチの移動中にレンタルで見て涙が止まらなくなった思い出の映画です。

movies.yahoo.co.jp

失敗して涙を流すぐらいの良い仕事、やっていきましょう。

Scrum Fest Osaka 2020でスクラム開発におけるマネジメント、目標設定・フィードバック・評価の話をしてきました #scrumosaka

はじめに

Scrum Fest Osaka 2020で登壇の機会をいただき話してきました。 Regional Scrum Gathering Tokyo 2020の2日目基調講演を聞き、「普段自分がマネジメントで意識していたことが正しかったなー」と感じていたのですが、アジャイル開発/スクラム開発の発表で具体的なマネジメントの事例を扱ったものが少ないと思いました。ならば自分がまずは発表し、他のマネージャー/マネジメントを受ける側の方々からフィードバックをもらいたいと思って資料を作っています。

当日はたくさんの方に聞いていただき、質問もいただくことができありがとうございました。

Discord(参加者限定)でいただいた質問

障害出てるのは個人に行ってしまいそう

→ 急ぎの障害対応でもチームに話を振ってどちらが担当するのか決めてもらっています。※インフラ周りの監視などは別途オンコール担当がいるので別

「不満は言うけど、決まったことは尊重する」難しそう 不満を表明するが意見の押し付けにしない(ポジションパワーを働かせない)ために工夫していること気になる いち利害関係者と言っても、マネージャーはヒエラルキー上のパワーがあるので、要望や意見の優先順位が高くなりそう。「常松さん言っているから..」とか。そのあたり、どうやっているんだろう。

→難しいのはその通りでかなり気をつけています。「いちエンジニアとしては」とか枕詞をつけるとか。言い方を変えて何度か投げかけしてみたり。  強権発動するとチームの自主性が損なわれるので部門・会社に明確な損害出るまではなるべく我慢しています。多分半年に1回やるかどうかぐらい。

リモートで観察をどうやってやったかなどあれば教えてほしいです!

→Slackチャンネルたくさん入る。Discordで雑談・モブプロしている様子を観察する。特定のメンバに発言が偏っていないかをみるとか。

評価を上げるためにタスクの取り合いにならないか?

→チームにとっての困りごとに協力・貢献できていないと評価しないのでそれは起きていない。

チームでできるようになるほど、チーム内のスタンスも技術も高いメンバーと、どちらも低いメンバーの評価差をどうするの的なのある

→評価は職務グレードごとに行うため、同じ成果であっても職務グレードで扱いは異なります。

競争を促進するシステムですか?

→あくまでチームで成果を出して欲しいというスタンスですが、スクラムでチーム開発をしているとお互いの成長が刺激になるので、競争心を引き出しているのかなと思うことはあります。

マネジメントのところの話と合わせると、現状常松さんの下に30人くらいがフラットにいる感じなのかな? →20人くらいです

アウトプットの評価のバランスってどうしてるんだろう。 バグを減らした人と、外部発表した人の相対的で納得のある評価みたいな。

→影響度を考慮してマネージャー間で慣らしています。

他のマネージャとの評価方針についての合意ってどう進めたのでしょうか?

→会社の記録として残す評価フォーマットで足並みを揃えるようにしているので、その前段階は個人でいろいろ試しています。

チーム目標を達成した時に、チームとしては達成しているが、やっぱり個人的に貢献度が違うなって場合はどうしていますか?

→評価に至る前の1on1で「もうちょっとこういう貢献がチームにできるといいねー」という話をしています。

週の1on1はどれくらい時間をかけていますか

→1人30分です。

目標(非公開の個人目標含む)とそれに対する成果はどのように管理されているのでしょうか。社内システムがあるなど?

→社内の評価システムは内製ですが、そこに入力するまではスプレッドシートで管理しています。

スクラムにおける自分の立ち位置を変えるときに、どのように伝えましたか?

→素直に伝えています「自律できるチームを目指してください。私はチームのサポートをしますが、チームで解決できる問題は委ねます。」

全社共通のグレード表があり、各グレードによって期待しているレベルが記載されています。 そのレベルがかなり抽象的で自分自身もメンバーが理解できないという課題があります。 チーム内で表の認識を共通化して評価するのがよいでしょうか?他に何かいい方法ありますでしょうか?

→グレード表にあたる文言(=Competency Matrix)をManager/Engineering Managerで読み合わせし、より明確な言葉に置き換えなどをしていました。

engineer.retty.me

個人目標を組織目標に沿ったタスクベースで書いてくる人がいて、ペアプロなどでやっているので自分が何をアピールするかがわからないと言われるのですが、どのように目標を立ててもらっていますか?

→対チームメンバ、チーム外のメンバに対してどう貢献・協力するかといった振る舞いで目標を記載しています。

1on1をするマネージャを育てることってありますか? もし、育てるときにやってることあれば、知りたいです。

→あります。マイクロマネジメントをさけ、メンバの自律性を引き出す振る舞いができるよう、時間をかけて話をしています。

SMが1on1をしたがります。 マネージャーの私もしたいというときにどちらかが遠慮すべきでしょうか

→1on1に効果があるなら任せてみても良いのではないでしょうか。

例えば個人目標が育成・指導が目標になっていた場合ってありますか?良い・悪いの判断するときのポイントみたいな部分があれば教えていただけると参考になって助かります。

→あります。指導対象がどういう振る舞い・貢献ができるようになって欲しいかを目標として話します。

チーム内で、お互いの役職(号棒?)やそこから予想される給料みたいのはお互いがわかる状態なのでしょうか?

→個人の職務グレードは非公開です。

メンバーの目標設定は、観測可能な目標を設定しようとしていたのですが、あまりこだわる必要はないでしょうか??納得感が得られるか悩ましいとこです。

→観測できた方が良いですが、設定することでおかしな方向にチームが進んでいかないかを気にして慎重に設定しています。

目標設定で本人の希望ややりたいことはどの程度加味していますか?

→メンバーに聞いてできるだけ加味します。が、タスクはチームで取ってもらうので、チームで「こんなスキルを伸ばしたい」といった話は積極的にするように勧めています。

Twitterでいただいたコメント

すてきなまとめを作っていただきありがとうございました。

言及いただいたブログ

dev.classmethod.jp

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

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人から構成される。

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

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

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

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

主査と主査付の関係性

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

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

主査が持つ権限

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

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

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