はじめに
国内のLeSS事例をまとめている際に見つけた大規模スクラムにおけるプロダクトの定義 - TechとPoemeの間の筆者さんがFOLIOのアドベントカレンダーで、会社の開発体制・組織構造の変遷について下記の記事を公開されていました。
「英語のLeSS本を読むくらいなら、開発体制もLeSSにしちゃえば挙げられている課題は解決しそうなのに」と思ったのですが、はてブのコメントでは書ききれない分量なのでここにまとめます。
LeSS (Large Scale Scrum)とは
日本語だと下記の記事が素晴らしくまとまっています。
このブログでも下記に情報をまとめています。
FOLIOさんの開発体制・状況はこんな感じなのかな…?
記事を読んでの想像です。違っていたらごめんなさい、すぐ訂正します。
- 証券会社という性質上か「抑えるべきところは抑え、固く進める必要がある」雰囲気がありそう。アジリティ・スピード感を持たせた開発を対外的に言いにくいのかもしれない。
- スクラムで規定されているイベントはやっていないか、部分的に取り入れていそう。元記事の筆者さんが入社したのが2018年2月らしいのでアジャイル開発の知見を持つ人がそこから入ったのかもしれない。
- ウォーターフォールではないのだろうが、アジャイル開発とも対外的に言えない開発プロセスになっている。
- 技術力の高いメンバの底力でベンチャー企業のスピード感に追いついてきたが、人が増え・やることが増えたことで組織づくりが急務になっている。
LeSSを導入したら解決するはずの点
プロジェクトではなくプロダクトを作る
アジャイル開発は顧客にとって価値がある成果を短期間で提供していくことが目的です。元ブログの 今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間でも「フロー効率」として挙げられている点です。 有期のプロジェクトだと終了時にメンバが入れ替えになることでチーム開発力が低下したり、文化が失われてしまいます。また締め切りが常に頭に貼り付いているような状態だと「そもそもどんな課題を解決することが目的だったのか」が後回しになってしまいます。 あくまで利用者・顧客にとっての価値を第一に置いておけば自然とプロダクト開発に皆の意識が揃っていきます。
プロダクトの定義は大きく設定する
LeSSで推奨されている考え方です。「そもそもどんな課題を解決することが目的だったのか」が正しくチーム・メンバに理解されてないとその場しのぎの解決策に負けてしまいます。
LeSS実践者研修の講師 Bas Vodde氏がNokiaを例に挙げたのが下記の考え方です。
- 通信モジュール/ライブラリ
- 通信チップ/基盤
- 通信機器
- 通信基地局/通信キャリア
Nokiaの製品は通信基地局向けの機器(3)ですが、末端のエンジニアが主に取り組むのは通信モジュール/ライブラリの開発(1)でしょう。とはいえ単に決まっている仕様をコードに落とし込む作業と、通信機器としてどう有るべきかを頭に描いた状態でやる作業の結果は大きく異なるでしょう。とはいえNokiaは通信キャリアではないので大きければ良いとは言っても自社でコントロールできない基地局運用や通信キャリアのビジネスモデル(4)まで考えた開発はできないでしょう。ということでNokiaの開発者にとってもっとも大きいプロダクトの定義は通信機器(3)でしょう。
FOLIOさんだとこんな感じでしょうか?
元記事のプロジェクトのスコープは2と3の間に見えますが、実際は4あたりなのかな。
「バックエンドエンジニアのサブグループ化」ではなく「クロスファンクショナルのフィーチャーチーム」を作る
顧客に価値が提供できるのは「3.PORT/FOLIOサービス」か「4.投資プラットフォーム」として世に出せたタイミングになるので、企画からリリースまでのタイミングを短くするのがもっとも望ましい開発体制となります。そのためには1つのチームが企画からリリースまで単独で遂行できる必要があり、「バックエンド/フロントエンドなどの職能チーム」ではなく「上から下までチーム内で取り扱えるクロスファンクショナルのフィーチャーチーム」を構成しなくてはなりません。
「フロントエンドより」「バックエンドより」はあっても良いですが、「バックエンドしか触れない」チームはNGです。
こうなると
- チーム間で調整・すり合わせのためのミーティング(XXX定例)や調整役(XXXプロジェクトリーダー)が必要になる
- 会社・組織として最優先で取り組まなければならない開発項目があっても、バックエンドに関する項目がないとチームが遊ぶことになる。またはバックエンドチームが全く価値のない開発作業を時間を埋めるために始めることになる。
フィーチャーチームは下記に詳しく書かれています。
「マイクロサービスのオーナーシップの不明瞭さ」はコンポーネントメンターを置く
フィーチャーチームを構成すると全チーム(全員)が全てのコードを触れることになりますが、好き勝手に作っていては設計方針がずれてしまいます。また技術負債や問題があってもオーナーシップが薄れ、返済・解消が遅れがちになります。
これを解決するLeSSのプラクティスがコンポーネントコミュニティー & コンポーネントメンターです。
私ならこんな順序でLeSS導入をするかな
1. バックログを作り、開発優先順位を見える化し、共通のものとする
進行中のプロジェクトが扱っている開発中の仕様のドキュメントや,プロジェクトのスコープや課題の一覧をまとめるpj-doc と呼ばれるプラクティスが社内で確立したり
内容的にスクラムでバックログと呼ばれる項目に思えます。全社で唯一の開発優先順位を決めたバックログをまず作ります。そして唯一のプロダクトオーナーを決めましょう。プロダクトオーナーが複数人いると方針がぶれるので、優先順位を決めるまでの議論は喧々諤々やった方が良いですが、最後の意思決定者だけは1人に決めます。
2. フィーチャーチームを構成する
職能別のチームを解体し、複数のレイヤに携われるフィーチャーチームに作り直します。
チーム構成を考える上で、バランスのとれたスキル配分となるよう、スキルマップを作って参考にします。
またチームを下から支えるリーダー、スクラムマスターを決めます。職能チームのリーダーが引き継ぐことも一案ですが、専門技術をリードする能力と、チームをまとめる能力は異なるので、できそうな人をピックアップしてリーダーに任命しても良いかもしれません。
先にリーダーを決め、リーダーにチームとしてありたい姿を語ってもらい、メンバにどのリーダーについていくか決めさせるやり方もあります。私はやったことはありませんが、面白い取り組みだと思います。
3. DONEの定義の拡張ワークショップを実施する
2で作ったフィーチャーチームは社内の全機能を開発できることはなく、PORTのみ・FOLIOのみ・またはそのうちの一部だけに知見があるという状態だと思います。またPORT/FOLIOは扱えるが、テスト・マニュアル・法規制確認など「リリースまでにやらなくてはいけないが、各チームがスプリント内で扱えないもの」があるはずです。一朝一夕に扱える領域は増やせませんが、増やす順番・目標・時期を決めるために「DONEの定義の拡張ワークショップ」をやると良いです。
独立した記事でまだまとめていませんが、下記で少し触れています。
Re: スクラムを大人数で運用したところ💩な結果になった。 - tuneの日記
4. コンポーネントメンターを任命し、コンポーネントコミュニティの運営を依頼する
マイクロサービスに詳しい人にメンターとなることを依頼し、コミュニティを作ることを依頼します。まずは社内のSlackチャネルにマイクロサービス固有の議論をするチャネルを作り、アナウンスして興味がある人に参加をお願いします。あとは好きに議論するなり、定期的にメンバを集めて打ち合わせを持つなりすれば良いと思います。
コンポーネントメンターにPull Requestのレビューを依頼することをやりそうですが、開発のボトルネックにならないように注意しましょう。メンターはコンポーネントの相談に乗り、時に方針を出すことに注力するべきで、コードレビューやテストの責任はあくまでチーム内で完結できるように育てていく方が良いです。
LeSS実践者研修オススメ
上記の内容を3日間で学べるLeSS実践者研修オススメです。次回は2018年3月12〜14日です。