アーカイブ動画
【SmartHR】モノリシックなアプリケーションを7チームでスクラム開発
株式会社SmartHR
プロダクトエンジニアグループ マネージャー 迫 康晃氏
最初に登壇したSmartHRの迫康晃氏は、「大規模スクラムにおけるコミュニケーション課題への対応～7チームでどうやってるんですか？～」というタイトルでセッションを行った。迫氏は3年前にバックエンドエンジニアとしてSmartHRに入社。2022年10月より現職として働いている。
SmartHRが開発する労務管理、人事データベース、タレントマネジメントという3つの領域の機能を備えたクラウド人事労務ソフト「SmartHR」。主に基本機能とオプション機能で構成されており、今回のセッションでは基本機能の開発について語られた。
基本機能は電子申請や従業員データ管理、マスタデータの管理、入社手続きなど、リリース時より積み重ねてきた様々な機能があり、モノリシックなアプリケーションで構成されている。
このアプリケーションを7チームで開発。開発手法はLeSS（Large Scale Scrum）を採用している。LeSSではスプリントプランニング、デイリースクラム、PBR、スプリントレビュー、レトロスペクティブという5つのスクラムイベントに加え、複数チームで進めるためのスクラムイベントもいくつか実施している。
スプリントプランニングは1と2を実施する。まず1で全体のプランニング、2で各チームのプランニングを行う。PBRはオーバーオールPBR、複数チームPBR、チームPBRの3つに分けて実施。レトロスペクティブもチームで行うチームレトロスペクティブと、全体で行うオーバーオールレトロスペクティブを用意している。
「各チームでのスクラム開発、ロードマップや開発アイテムに対する意思決定については、7チームで開発していてもハチャメチャになっていない。うまくいっていると思います」（迫氏）
一方、LeSSがうまくいっていないこととして迫氏が挙げたのが、「組織全体に対しての改善サイクルが回っていない」「全体的にスピード感がない」。この2点が個別チームではうまくいっているが、複数チームになるとうまくいかないことがわかった。
例えば、オーバーオールPBRでは7チーム全員が参加して、PBIの振り分け、ロードマップの共有、各チームの開発状況や個別で行っているプロジェクトの共有、異動の情報など全体向けの共有を行っていた。
オーバーオールレトロスペクティブも7チーム全員が参加し、各チームの振り返り内容や各チームの取り組みで他チームでも参考にできる良い取り組みの共有、グループ全体のプロブレムを話してトライを決めることをやっている。
スプリントプランニング1も7チーム全員が参加し、各チームのPBIをスプリントバックログにいれ、大まかな修正箇所の共有を行っていた。
「LeSSのイベントと組織としてやることが混ざっており、扱う課題の内容、優先順位が定まっていない。議論と共有のコストが高いという課題が見えました」（迫氏）
LeSSは2020年1月に2チームからスタートし、21年に4チーム、22年に6チーム、23年には7チームに増加した。その一方で、スクラムイベントに対してはマイナーチェンジをするだけで、「やり方を大きく変えなかったため」だと、迫氏は振り返る。
議論と共有のコストの高さをどう解決するのか。まず行ったのは、各イベントでやりたいことの整理だ。次に各イベントの目的の整理。オーバーオールPBRではロードマップや検討中・今後予定している開発に関することの共有、PBIの振り分けを行うことにした。オーバーオールレトロでは、全体や複数チームのプロセスに関わる方針の議論、決定を行った。
スプリント内の複数チームに関わる課題については、オーバーオールレトロスペクティブで、LeSSのメンバーで扱うが、議論しやすいよう参加者を絞ったという。
「事前にトピックを上げてもらうことで、気になるトピックがある人は参加OKで、参加してほしい人にも声がけするようにしました」（迫氏）
組織全体の課題については中長期的な課題が多いため、POやマネージャー、ステークホルダーなど少人数で扱うようにした。レトロスペクティブで扱わない課題のため、戦略検討会という別の機会を設けた。
最後に行ったのが共有方法の整理だ。オーバーオールレトロスペクティブの結果については、各チーム内で共有し、中長期の課題への方針やアナウンス系のお知らせについては、オーバーオールPBRをPBRと共有会に分離し、共有内容にメリハリをつけることにした。
「現在はコミュニケーションコストが大きいという課題を解決するため、組織構造と合わせてアーキテクチャ全体の見直しを進めています」（迫氏）
人事評価サービスチームが抱えていた課題
株式会社SmartHR
プロダクトエンジニアグループ 大谷 洋生氏
続いて登壇した大谷洋生氏は、「エンジニア主導の仕様検討: はじめの一歩を踏み出す」をタイトルにセッションを行った。普段はRailsやReact、Flutterを使って開発をしている。
大谷氏のチームは、SmartHRの人材マネジメント機能における人事評価サービスの開発を担当。1年前はPM1人、エンジニア5人の1チーム体制で同サービスを開発していたが、今年9月時点には2チーム体制となったが、相変わらずPMは1人。エンジニアが8人に増えたという。このような状況の中でチームは大きく次の2つの課題を抱えていた。
「2チームになりましたが、PMは1人のままだったので、単純にPMの手が足りないという課題がありました」（大谷氏）
ボトルネックになったのは、仕様検討。PMが責任を持つのは要求定義と仕様検討、一方のエンジニアは設計と実装に責任を持つという文化になっていたからだ。もう1つの課題は、技術的な観点で手戻りが発生することだ。
「PMが仕様をまとめてくれるが、エンジニアがそれをレビューすると現行の仕様とかみ合わなかったり、工数がかなりかかったり、そもそも実現できないような仕様だったりすることが起こっていました」（大谷氏）
この2つの課題を解決するために大谷氏が採用したアプローチは、エンジニアがHowの提案をやってみることである。
従来は、PMが要求定義書と仕様書を書き、エンジニアが設計・実装をする。質問があればPMに確認するというフローだった。それをPMが要求仕様書を書き、エンジニアが詳細な仕様を提案する。PMと仕様をすり合わせて決定。エンジニアが設計・実装する。考慮漏れや曖昧な仕様が出てきたら、エンジニアがチームに提案するというフローに変えたのだ。
これにより、まずは手戻りが減ってリードタイムが短くなった。リードタイムが短縮されたことで、エンジニアは未来の価値により多くの時間を使えるようになったのだ。
「エンジニアは機能開発をより自分事にできるようになったことで、仕事がさらに楽しくなった。これは嬉しい誤算でした」（大谷氏）
もう一つの変化は、エンジニアに意思決定のスキルが身に付いてきたことだ。
「PMとキャッチボールする中で、どうすれば意思決定がスムーズに進むのか、勘所がつかめるようになりました」（大谷氏）
フローを改革するのは容易なことではない。では、どうやってその一歩を踏み出したのか。「PMとエンジニアそれぞれが責任を持つ境界を見直すこと」だと大谷氏は言い切る。そしてさらに一歩を踏み出すために、PM、エンジニア共に意識することを定めたという。
PMは課題とスコープ、ゴールの3つを明確にすること。エンジニアについては仕様検討をスムーズに進めるために幅出し（松竹梅のように幅を持ってHowを出す）、比較（メリット・デメリット、工数などの判断材料）、決定（投資効果を踏まえつつPMと意思決定）の3点を意識するようにした。
「仕様検討の手戻りに悩んだら、PMはしっかりWhatを握りながら、エンジニアはHowの提案をすること。ぜひ試してほしいですね」（大谷氏）
【カケハシ】大規模SaaSにおけるプラットフォームエンジニアリング
株式会社カケハシ
プラットフォームドメイン 岩佐 幸翠氏
続いて登壇したのは、カケハシの岩佐幸翠氏。「大規模SaaSにおけるプラットフォームエンジニアリング～チームを越境し、横断的関心事をエンジニアリングで解決する～」をタイトルにセッションを行った。
岩佐氏は2022年にカケハシに入社。現在は、組織管理サービスという社内プラットフォームを開発するチームのテックリードを務めている。まず岩佐氏が紹介したのは、プラットフォーム（共通基盤）開発の悲しい現実。それが次の図だ。
社内プラットフォームがプロダクト開発チームの期待からずれてしまう理由は、大きく2つある。1つは要求分析の不足だ。
「プロダクト開発チームからの表層的な要望をそのまま受け入れてしまうのではなく、潜在的な要求を深掘る必要があります」（岩佐氏）
もう1つは、デリバリーの遅さである。社内プラットフォームは機能要件がどんどん入ってくるので、デリバリーもどんどん遅くなってしまう。要求とのズレに早く気づくには、早く小さくデリバリーして早めにフィードバックを得る必要がある。
つまり社内プラットフォーム開発に起きるズレをなくすには、深い要求分析と高速なデリバリーの両立が必要になるというわけだ。ではこの両立をどうやって実現するのか。岩佐氏は「要求分析とアジャイル開発を小さく反復すること」だという。
社内プラットフォームを開発するのは、開発工数を削減するためだといわれるが、岩佐氏は「これは誤解だ」と言う。そもそも、プラットフォーム開発のミッションは、顧客に価値を提供し、対価を得ること。プロダクトにとっての価値は常に変化をし続けることであり、当然プロダクト開発チームも、顧客の価値に集中したいと考えている。
岩佐氏が担当する組織管理プラットフォームが生まれる背景となったのは、2つのプロダクトにおいて「階層的な権限の管理機能」へのニーズが高まったためだ。しかし、それらを単に「共通機能」として実装してしまうと、双方のドメインが双方のシステムに入り交じる、密結合で変更しづらいシステムになってしまう。各プロダクトの「コアドメイン」と「サブドメイン」は何に当たるか分析した上で、「サブドメイン」だけを上手に社内プラットフォーム化する必要がある。
「プラットフォームの開発の目的は、本質的な価値提供に収集させること。つまりコアドメインとの関連度の低い組織管理ドメイン、認可ドメインからプロダクト開発チームを開放することを目的とし、組織管理プラットフォームを開発することにしました」（岩佐氏）
プラットフォーム開発における要求分析は難しい。その要因は2つあると岩佐氏は指摘する。1点目は要望の表現の方法。社内プラットフォームは画面ではなくAPIやメッセージキューが利用者とのインタフェースとなるため、エンジニア以外も含めた対話に向かないのである。
2点目が「プロダクト開発チームの要望を満たす」=「プロダクト開発チームや顧客に価値をもたらす」とは限らないこと。プロダクト開発チームがコアドメインに集中できるのか、コアドメインを分断していないかどうかが後から分かったりするからだ。そこでプラットフォーム開発の要求分析は、ドメインモデルで対話することを提案したいと、岩佐氏は語る。
「ドメインモデルとはシステムに関連するオブジェクト（登場人物）とその関係を示したもの。要望や要件をドメインモデルで図式化することで、各プロダクト開発チームのPdMも含めて議論に参加できるようになります」（岩佐氏）
プラットフォーム開発の要求分析のためのドメインモデリングおいては、プロダクト開発チームをコアドメインに集中させつつ、社内プラットフォームのスコープは限定して作ることになる。
そこで最初はFigJamやMiroでリアルタイムに描き出し、ドメイン・サブドメインの境界に対する認識を揃える。プラットフォーム開発の要求分析は、まず現状と展望をドメインモデリングし、次に要望をドメインモデリングする。
そして要求に漏れがないか、ユースケースモデリングで確かめる。漏れが出ればユースケースモデリングを止め、そこで得られた洞察を反映してドメインモデリングし、またユースケースモデリングするという流れになる。
一方で、現状に寄せすぎた社内プラットフォームはすぐに汎用性を失ってしまう。長く使われる社内プラットフォームを作るには、どうすればよいのか。
「プラットフォーム開発の要求分析では現状と中長期的な展望をモデリングし、理想へ近づけるためのロードマップを意識しながら、直近で折り組むべきドメインを特定することが大事です」（岩佐氏）
社内プラットフォーム開発ではどのような課題に直面したのか。当初の組織管理サービスは2週間のスプリントにスクラムで取り組んでいた。開発体制はプロダクトマネージャー（PdM）、テックリード、エンジニア2人、スクラムマスター(兼務）。PdMはプロダクトの品質の説明責任を果たし、テックリードは技術的な意思決定の説明責任を果たす。
しかし、プラットフォーム開発において課題となるのは、PdMが理解するべきコンテキストが広すぎること。なぜなら社内プラットフォームにおける品質は、機能要件そのものがAPIやデータベースなどで表現され、さらにそのインタフェースには非機能要件も大きく絡んでくるからである。
「プラットフォーム開発においては、テックリードがPdMの役割を担い、従来のPdMはプロダクトマーケティングマネジャー（PMM）として位置づけることをお勧めしています」（岩佐氏）
【リクルート】プロダクトプラットフォーム開発におけるフィードバックループの回し方
株式会社リクルート プロダクト統括本部
小中高プロダクト基盤開発G 吉岡 良治氏
最後に登壇したのは、リクルートの吉岡良治氏。「プロダクトプラットフォーム開発におけるフィードバックループの回し方」というタイトルでセッションを行った。
吉岡氏は『スタディサプリ』の基盤開発グループでエンジニアリングマネージャーを務めている。RailsエンジニアとしてWeb開発に長く携わってきた。最近はGoやRustを推しているという。
吉岡氏のチームが基盤開発を行っている『スタディサプリ』のサービスは3領域に分けられ、小学生から受験生、大人まで学習したいすべての人が学べるオンラインの学習サービスである。『スタディサプリ for TEACHERS』は、先生が生徒個々人のレベルに合った最適な学習を提供できる教員向け管理ツールだ。
スタディサプリにおける基盤は2種類ある。1つはアプリケーションプラットフォーム。これはSREが提供するアプリケーションを開発するための基盤。もう1つがプロダクトプラットフォーム。これは認証や動画配信などの機能を利用するための基盤である。
プロダクトプラットフォームがないと、複数のサービスに処理が分散し、そこに変更を加えるには影響範囲の確認が必要になるなど、実装の負荷が非常に高くなる。加えて仕様のズレが起きやすいなど、様々な問題が起きていたという。吉岡氏はこれを解決すべく、基盤開発に取り組むこととなった。
基盤開発においては次の2つの課題が発生した。1つが認知負荷の増大である。基盤開発グループは機能開発で初めての、横断領域を開発するチーム。しかも複数のサービスから参照されるモジュールはオーナーシップが曖昧だった。
「そこにオーナーシップを持てるチームが生まれ、事業的に優先度の高い横断プロジェクトなどが差し込まれるようになりました」（吉岡氏）
そこで、領域横断的な課題を解決する開発支援グループを誕生させ、4人のプロダクトプラットフォームエンジニアが所属することになった。4人のチームで横断領域にある複数の課題を同時に進めるのは、非常に大変なことだったと吉岡氏は振り返る。
バックログの優先順位付けが複雑化しているので、どこを優先すればよいのかの判断が難しい。また、アラートや他チームからの差し込み対応もしなければならない。それが続くと、コンテキストスイッチが多発してしまう。このような状況から、基盤開発のプロジェクトは一時停止することになった。
もう1つの課題がスプリントレビューの形骸化である。当時は、専任のプロダクトオーナーやスクラムマスターもいない状態だった。開発目標はAs-Isのまま機能をマイクロサービスへ切り出していたので、特に新しい機能の実装もせず、整合性を担保しながらデータを移行するということを行っていた。
プロダクトバックログは技術中心な内容となってしまい、関係者を集めてレビューを実施しても、進捗の確認の場にしかならず、スプリントレベルで求めているところしかフィードバックループが回らず、考慮漏れによる手戻りも多数発生していたという。
前者の課題を解決すべく、最初に行ったことはドメインの境界を定めることだ。まずはグループワークでビジョン、ミッション、バリューを作成した。ビジョンはプロダクトチームが価値の提供に集中できる世界の実現、ミッションはプロダクト開発を支援する堅牢なプロダクトプラットフォームを作ることである。
さらに、組織名を自分たちのミッションを表すものに変更した。それが現在のグループ名となった小中高プロダクト基盤開発グループである。
「チーム名を変えた影響は大きかったですね。名前でこのチームがやるべきことがわかるからです。そして同時に自分たちが何をしているグループなのか、何度も能動的に繰り返し社内にアピールし、認知を広げていきました」（吉岡氏）
それでも高い認知負荷は続いた。グループ内のドメインやコンテキストの増大は防いだが、すでにある複数のコンテキストをハンドリングするのが難しく、スプリントプランニングは変わらずに時間がかかっていた。
理想は一つのチームが一つのドメインに集中する環境を作ること。差し込みや並行作業によるコンテキストスイッチは最小化したいとはいえ、グループには4人しかいない。そこで思い切って採用を強化してメンバーを充足させることを前提に、チームを2つに分割。2名チーム体制を構築した。
グループとして最優先で進めたかった認証ドメインを切り出し、残ったドメインは引き続き1チームで進めるという形を試すことにしたのだ。
「まず試すことでフィードバックを得ることを最優先し、厳しければすぐに戻す前提で進めました。試みは成功し、チームのスループットが向上しました」（吉岡氏）
形骸化するスプリントレビューをなんとかしたいと思っても、専属のプロダクトオーナーやスクラムマスターを用意するのは難しい。そこでスクラムに変わる開発プロセスを探してみた。すると、「社内PlatformチームのProduct Management」というブログを見つける。
「基盤も社内向けのプロダクトとして捉えることと書かれていて、衝撃を受けた」と吉岡氏。自分たちがやるべきことが明確になり、得られた知見を元にチームでミニマムに検証。リリースサイクルは6週間と定義した。
提供するだけではなく、開発したリリースアイテムをレビューすることも行った。レビューの実施者はまだ自分たちであるものの、進捗管理だけのレビューではなくなってきていることを実感しており、「スプリントレビューが息を吹き返した」と吉岡氏は語る。
成果を実感したことで、Platform as a Productという取り組み自体の解説検証を行っている。この仮説検証ではいくつかのテーマを定めているが、その1つがフィードバックの質を高めることだ。いずれの改善においても大事なことは、フィードバックループを素早く回すことだと吉岡氏は示唆する。
開発した機能を評価してもらうためには、能動的な成果の共有を大切にすることが必要になる。そこで大事になるのが、「能動的にアピールし、認知してもらうこと」だと強調する。吉岡氏たちは社内のプロダクトチャンネルでリリースアイテムの共有化を図り、ブログを書くなど、グループの成果を社内に宣伝していると語り、セッションを締めた。
【Q＆A】参加者からの質問に登壇者が回答
セッション後は、イベント参加者からの質問に登壇者が回答した。抜粋して紹介する。
Q．スプリントプランニング 1 の「やっていること」に PBI の振り分けが入っていないのは、リファインメント担当チームがプランニングから実装まで担当しているからなのか？
迫：一部やっているというのが回答です。理想はすべての開発アイテムについてプランニング1で振り分けるのがよいが、月単位にわたる機能開発を複数チームに分けて開発すると、コンテキストスイッチやコミュニケーションコストが大きくなるため、各チームに大きめの機能開発を振り分けて開発しています。それ以外の小さな機能開発やバグフィックスは、プランニング1で振り分けています。
Q．OSSにどう向き合っているか、選定、評価、更新などの考え方を教えてほしい
岩佐：ライブラリやフレームワークの選定についてどう向き合っているかという観点で回答すると、社内プラットフォームを開発する上で一番大事なことは長く使われること。他の言語やフレームワークに移行する可能性があります。
つまり、OSSを選定する上で大事になるのは長く使われていて実績があることが大事。その上で、更新についてはRenovateやDependabotなどのツールを使うことで、工数を下げながら、自動で反映できる部分を反映します。
きちんとレビューするメジャーアップデートについてはチーム内でレビューする機会を設けて、アップデートをするようにしています。
吉岡：一度選んでしまうと簡単には変えられないので、基本的には長く利用できるものを選定しています。OSSのコミュニティが機能しているかどうかを重要視しています。その上で有力なライブラリが複数あるときは、全部プロトタイピングで作り、チームのユースケースに照らし合わせて判断します。
迫：長く使えるのか、複数選択肢があった場合は実際に使って見て、メリット・デメリットを洗い出して、何人かで選定します。
大谷：更新への対応については、DependabotやRenovateなどが社内でよく利用されています。テストを書いて、CIを通してステージング環境で動かしてみること。そこで大丈夫だったら更新するというように、愚直にやっていくことが大事だと思います。
株式会社カケハシ
https://www.kakehashi.life/
株式会社カケハシの採用情報
https://recruit.kakehashi.life/
関連するイベント
