天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

チームと個人の可能性を最大化する - パフォーマンスを落とさない体制構築とセルフマネジメント方法に参加してきた

developer-productivity-engineering.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

本イベントでは、エンジニア組織の生産性向上支援ツールの開発をしている、FindyTeam+開発チーム 副部室長/EMの浜田さん、フロントエンドリードの熊野さんに、マネジメント目線とプレイヤー目線からみた、開発体制づくりについてお話しをお伺いします。

【マネジメント目線】メンバー増加をしてもパフォーマンスを落とさないために、チーム体制をどのように考えるのか
【プレイヤー目線】無駄な作業を減らすための取り組み実態とFindy Team+を使ったセルフマネジメント方法

開発生産性の向上や組織体制づくりに関心のあるエンジニア、組織運営に携わる方々にとって、貴重な学びの機会となることを目指すイベントです！

会の様子

講演1〜『開発パフォーマンスを最大化するための開発体制』〜

発表のコンテキスト

最初に開発状況の説明として、開発者の人数が2022年からの2年間で、10人→16人に増えたという前提が話としてありました。

デイリースタンドアップの形骸化

人数が増えたことで直接関わっていないメンバーが増え、開発状況の共有がただ行われるだけになってしまったため、デイリースクラムを一部メンバーに限定するようにしてみたということです。

ただし、効果は限定的であり、一部メンバーにとってはむしろ効果が下がるような事象も起きてしまったため、1ヶ月でやめたということです。

職能でチーム分割

そこで、バックエンドとフロントエンドでチーム分割するようにしたということです。

ただし、結局バックエンドとフロントエンドで密な連携が必須になってしまい、チームを分割した意味があまりなくなったので、不採用になったということでした。

機能でチーム分割

続いて機能毎にチーム分割したそうですが、コンフリクトが度々発生してしまい開発が遅くなってしまうことから、結果的に不採用になったということでした。

ドメインでチーム分割

バックエンドに開発作業が集中してしまうため、ドメインでチーム分割をするとチームの負荷が偏ってしまうということで、不採用となったということでした。

コンプリケイテッド・サブシステムチームで分割

複雑性が高い領域があるということで、その複雑性に対応するチームとしてコンプリケイテッド・サブシステムチームを採用したということでした。

ただし、2チームに分割したとしても両チームともドメイン知識が必要になってしまう*1上に、1チームあたりの人数が2チームに分けても多いので、最終的には領域ごとに3チームに分けるようにしたということです。

講演2〜自己改善からチームを動かす！「セルフエンジニアリングマネージャー」のすゝめ〜

開発フローをはやくする

システム開発をするにあたっては、プロセスを段階的に進める必要があり、プロセスを減らすことができない点が難しいという話がありました。

そこでFindyの開発では、以下のような工夫を行っているということでした。

  • CIの高速化(修正箇所に応じて自動テストを回す部分を限定するとともにキャッシュを活用)
  • PRがアサインされたりすると、自動でSlack通知が来るようにしている
  • QA箇所の自動生成
  • フィーチャーフラグの活用
何がチームのパフォーマンスを妨害するか？

個人の開発速度は急に成長しないうえに、コードを書く時間とコードを書いたあとの時間で分けて考えるとコードを書いたあとの時間の短縮が重要になってくるという前提で、プルリクエストをとにかく小さくするようにしたということです。

プルリクエストを小さくすることで、誰でもできるレベルまで作業難度を落としたり型による自動チェックが行え、コードがほぼ衝突しないようになったため、ほとんどコードが書けないようなPdMが22件のPRを出してくれるレベルになったということでした。

セルフエンジニアリングマネージャーのすすめ

自分のパフォーマンスをあげるためには、チームのマネジメントをしてチームの苦手を減らすようにする必要があるという話がありました。

そのために、まずは自分で自分のパフォーマンスをマネジメントすることが重要だということで、実際にshootaさんは自分のPR数を測定し、プルリクエスト数が他の日より少ない日でも、MTGが詰まっているにもかかわらずその少ない件数を出せたことをマネージャーに主張したりすることができたということでした。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を常体かつ一問一答形式で記載していきます。

チームを分けた事で、サービス内での境界が曖昧である事が理由で「この機能はそっちのチームで作ると思っていた」みたいなコミュニケーションミスは発生したか？チームを横断するPdMみたいな人か仕組みが必要に感じた

最初に分けたタイミングでは、どっちのチームが作りますか？という意味でコミュニケーションコストが非常に大きかった。

次にチーム分割した後は、そういった問題は発生しなかった。

フロントエンド、バックエンドのエンジニアを同じチームにした際に、コンプリケイテッド・サブシステムチームを作るほどではない一時的な作業量の偏り(暇な人)の解消のために、もし何かしら対策を講じたことはあるか？

基本的には暇な人はいなかった。機能開発以外の改善タスクもあるので、仮に手が空いた人がいれば、その作業をするようにしていた。

独自のslack appはgithub公式のと比べてどの辺に良さがあるのか (どういう運用をしているのか？) もうちょっと深ぼって聞きたい

Slack IDとGitHub IDが紐づけされているようにしている部分が非常によい。

業務上生じた問題について上司からの部下へのフォローの仕方で良い事例があれば知りたい

ポストモーテムを活用し、障害や問題を起こした人に焦点を向けないようにしている。

おそらく今回の発表での「リードタイム」はファーストコミットからマージされる or デプロイされるまでなのかなと思いながら聞いていた。リードタイムの定義は様々かと思うのですが、プロダクトの課題が発見されてからそれがデプロイされるまで、という定義での改善活動はなにかされているか？エンジニア組織内で完結しないプロダクトチームとしてのリードタイム短縮に向けてどのように活動されてるかを知りたい（よくあるのは課題がふわっとしていて着手しても要件定義で時間がかかるだったり、手戻りが発生したりで伸びたりするケースがあるのかなと思っている）

明確に仕組みとしてはない。課題発見からという意味だと、発見しきれていない課題というのもあると思うので、開発チームとしては如何にそういう関係性を速く維持するのか？という意味で大切にしている。具体的には、Storybookを活用するとか。

熊野さんのGitHubコントリビュートの分析の仕組み化づくりや運用はどこにどうやって情報をとって、どのように分析→共有しているか？

完全に宣伝になってしまうが、自社が作っている製品であるTeam+がやっている。

タイトルにある「パフォーマンス」をどのように定義し、計測・分析しているのか知りたい。またチームでパフォーマンスの状態について振り返る機会があればその仕組みや方法が知りたい

これもCMになってしまうが、Team+を使っている。パフォーマンスに対するふりかえりはFour Keysを活用している。

プログラミングをしていないエンジニアの生産性はどのように測るか?

難しいとは思う。Issueをまとめてもらってそこを見てもらうようにしたり、定性的作業の生産性評価も組み合わせしている。

「やっぱりやめます！」を受け入れてくれるチームづくりで意識されていることや、施策として具体的に取り組まれていることはあるか？

採用として、前向きかどうかといったValue Matchを重視している。

また、無策で臨むのではなく事前に根回ししたり実施のロジックを説明しておくことで、もしだめだとしても受け入れられやすくなると感じている。

会全体を通した感想

最初の浜田さんの講演に関しては、アンチパターンも踏んでいるとはいえ、チーム体制を短いスパンでどんどん変化させていくスピード感がさすがだなあと思って見ていました。

shootaさんの講演に関しては、自分のパフォーマンスを上げるためにチームのパフォーマンスを上げよう、チームの苦手を取り除こうという姿勢がすごく素敵だなあと感じました。

*1:システムがX as Serviceになっていない