【イベントレポート】アジャイル開発エンジニア勉強会／イベントレポート

こんにちは、TECH Street編集部です！

この記事では、2025年2月27日（木）に開催した「アジャイル開発エンジニア勉強会」の各登壇者の発表内容の紹介と、イベント中に回答しきれなかったQ&Aを記載しています。

今回は「パーソルキャリア株式会社」「株式会社MIXI」「株式会社ラクスライトクラウド」のアジャイル開発に携わるエンジニアが集まり、取り組み事例を発表していただきました。

登壇者はこちらの方々！

小林壮太氏

パーソルキャリア株式会社
リードエンジニア

2021年にパーソルキャリアに新卒入社。アプリ開発チームのバックエンドエンジニア、スクラムマスターを経て、現在はマイクロサービス化に取り組んでいる。好きな振り返りフレームワークはeffort & painと555(Triple Nickels)です。

日下亜紀子氏

株式会社MIXI
ライブエクスペリエンス事業本部　ファンコミュニケーション部
Fansta開発ｸﾞﾙｰﾌﾟ Fansta第1開発ﾁｰﾑ

2015年にFA機器メーカーに新卒入社し、ウォーターフォール開発を経験。その後、技術系雑誌の編集職を経て、2019年に技術系スタートアップ企業に入社。そこで初めてスクラム開発に触れる。2021年からは株式会社ミクシィ（現 MIXI）でFanstaというスポーツ観戦に特化した店舗の検索・予約サービスの開発を担当し、スクラムマスターではないものの積極的に開発プロセスの改善に取り組んでいる。

ウチノ氏

株式会社ラクスライトクラウド
フロントエンドエンジニア

webエンジニアとしてフロントエンド、バックエンドの開発を経験。ラクスライトクラウド入社後はフロントエンドエンジニアを担当しつつ、スクラムマスター見習い＆プロジェクトマネジメント見習いとして日々研鑽中。

こうして私はスクラムマスターをやめた。

小林壮太さんの発表内容については、以下の記事リンクからご覧ください。

www.tech-street.jp

スクラムマスターなしでもいい感じにスクラム開発している

日下亜紀子さんの発表内容については、以下の記事リンクからご覧ください。

www.tech-street.jp

スクラムとウォーターフォールの間で開発スタイルを模索している話

ウチノさんの発表内容については、以下の記事リンクからご覧ください。

www.tech-street.jp

Q&Aコーナー

（Q）スクラムを実施する以前はどのような手法で進められていたのでしょうか？どのような課題があってスクラムにしたのでしょうか？
小林：私が参加した時点ですでにスクラムが導入されておりました。正解のわからない継続的なエンハンス開発に対して柔軟に対応するためにスクラムを採用しています。

（Q）ケースバイケースでスクラムマスターに限らずですが、引き継ぎ期間はどのくらいがベストなのか、なにを引き継ぐべきかは悩みますね。
小林：引き継ぎ期間の長さが重要というよりも、実際に業務を「担当してもらう期間」を設けることで引継ぎ先が疑問を持って解消できる状態を作ることが重要だと考えます。

（Q）生産性について気になるポイントをピックアップされるとおっしゃっていたかとおもいますが、見るべき指標と気になるのはどんな状況に注目していますか？
小林：見るべき指標としては、アウトプットの量がわかる指標とその品質がわかる指標の2つだと考えています。気になる状況でいうと正直時と場合によるのでここでは詳しく語りませんが、仮定が多いと適切な問題解決ができないので、そのスプリントで実際に起こった問題に注目しております。

（Q）社内にどれくらいのスクラムチームがありますか？部署単位ですか？プロダクト単位ですか？横断組織はありますか？
小林：社内には約7つのスクラムチームがあり、プロダクトの中でアプリチームとサイトチームに分かれています。横断組織も存在します。

日下：会社の組織が大きいため、正確な数は把握できていないです。
プロダクト単位で開発チームが分かれていて、一部がスクラム開発を採用しているイメージです。スクラムマスターが集うといった、スクラムの横断組織はありませんが、アジャイル雑談会という名目で月1程度で横断的な交流できる会はあります。他には、別チームでスクラムの知見が深い人がおり、全社横断でスクラム勉強会を定期的に開催してくれています。

ウチノ：開発チームはプロダクト単位で存在し、横断組織はありません。
スクラムのサイクルの中にはテスト工程まで含まれています。

（Q）論理的思考能力の強化で行なった練習法など、よろしければご紹介いただけると嬉しいです
小林：論理的思考能力を実際に活用することが大切です。具体的には、ロジックツリーやMECEを意識して練習します。また、自分の思考が正しくMECEになっているかを他者にレビューしてもらい、気づく機会を増やすことが効果的です。特に、自分では気づきにくい点については、自分より論理的思考能力の高い方からフィードバックを受けるようにすると、さらに成長できます。

（Q）スプリント期間とスクラムのイベントに使う時間どれくらいか聞きたいです
小林：スプリントは1週間のサイクルで進めており、スクラムのイベントには5日のうち1日を使っていました。これは、仮説検証のサイクルをできるだけ早く回すことを重視しているためです。

日下：スプリント期間は2週間で、スプリントレビュー＋スプリントレトロスペクティブ＋スプリントプランニングを丸一日使って開催しています。

（Q）スクラムに感じている一番のメリットと、一番の課題をお聞きしたいです。
小林：一般的に「スクラムを導入すると開発が早くなる」と思われがちですが、それは誤解だと感じています。スクラムの最大のメリットは、短い検証サイクルを通じてメンバーの成長を促せることです。一方で、スクラムでは自分の課題が可視化されやすくなるので、それにメンタル的に耐えられるメンバーを見つけるのが難しいという課題もあります。

日下：プロダクトの観点では、小さな単位で機能をリリースでき、ユーザーからのFBを元にすぐに軌道修正できるのがメリットです。
個人の視点では、スクラムでは特定の技術の専任になるよりも、幅広い知識が求められるため、好奇心旺盛な人には成長の機会が多いことがメリットだと感じています。
スクラム自体に対して現時点で課題はあまり感じていません。
ただ、人によってはペアプロが嫌いだったり、特定の技術をとことん深めたい人もいると思うので、スクラムに傾倒しすぎてなんでもスクラムのフレームワークに押し込めないように気をつけないとなと思っています。

ウチノ：メリットはチーム内の認識合わせが活発になり、コミュニケーションが円滑になることです。チームの風通しが良くなったと感じています。課題は、プロダクトオーナーやスクラムマスターの負担が大きいことです。本では学べない実践的な課題も多いと感じています。

（Q）QAの方の職務はどのようなことを行っているんですか?
日下：一般的にテスターさんだと実施だけのイメージですが、QAさんは開発の上流工程から関わっており、仕様のブラッシュアップやテストの設計・計画も担当します。各スクラムイベントにもどういうテストが必要かという観点で参加し、適切なテスト計画を立てた上で、実施もQAさんが行っています。

（Q）リファインメントは定期的にということではなく、必要に応じてやっているんですか?その場合どんなタイミングでやることになるのか知りたいです
日下：必要に応じて毎日チーム全員が集まる全体デイリーの中で実施しています。

（Q）デイリースクラムは15分でやると思いますが、リファインメントと同時に行うのはなぜですか？　デイリーの目的とリファインメントの目的は異なるので、混じってしまわないか、集中できているのかが気になりました。
日下：時間は明確に区切っているので、混ざることなく集中できています。
毎日開催しているデイリーは全体デイリーと開発デイリーの2つに分けて実施しています。
全体デイリーは開発メンバー以外にもPOとデザイナーが参加し、リファインメントに近い形で新しい機能や仕様のすり合わせを行っています。その後開発メンバーだけでいわゆるデイリースクラムの内容の開発デイリーを実施しています。デイリーの中でリファインメントと同時に行う理由は、日程調整の手間を省ける上で、必要なタイミングで随時実施できて効率的だからです。

（Q）セレモニーデーの日は丸一日ミーティングだと思うのですが、集中力切れませんか?集中力を保つために工夫されていることがあれば教えてください。
日下：1時間ごとに必ず10分休憩を取るようにしています!
また、スクラムセレモニーデーが終わった後はほぼ100%飲み会が開催されています!笑

（Q）マネージャーは直属の上司でしょうか。POがマネージャーであることによるデメリットはありませんでしたか？
日下：はい、スクラム導入当時は直属の上司でした。エンジニア出身のマネージャーで開発チームへの理解も深かったので、特にデメリットは感じませんでした。

（Q）SMがいなくても自走できているのはとても素晴らしいですね。POとDevsのコミュニケーションの質が高いのだろうなと感じましたが、もともとチームワークがよくファシリテート力も高いメンバーだったのでしょうか？
私の経験だと、POが忙しかったり偉い人が多かったりして、DevsがPOの想いを汲み取れなかったりPBIも作りきれないので、間にSMが入ることが多いです。
日下：主要なエンジニアがジョインしてから半年後くらいにスクラムを導入したので、チームワークがよくなってきたタイミングではあったと思います。
また、最初のPOがエンジニア出身で開発チームへの理解が深く、エンジニアの採用にも関わっていたので、最初からコミュニケーションしやすい人が採用されている印象で、ファシリテート力も課題に感じることはありませんでした。

（Q）開発者と兼任するSM、という方法もあると思うのですが、その方法を選択しなかったのはやはりチームが自走できているからでしょうか？
日下：導入時は開発メンバーの中でスクラムに知見のある人がいない状態だったので、誰か1人に高負荷がかからないようにみんなで協力しながら進めていく形になりました。個人的には、もし知見のある人がいれば、1人が兼任してみんなを引っ張っていく形で始めた方が改善サイクルは早まりそうに思います。

（Q）PRではどのようにコードレビューを行っていますか?
日下：エンジニアのうちの誰か1人がApproveすればマージしてよいというルールでおこなっています。他の人の意見も聞きたい場合はコメント上でメンションすることもあります。

（Q）全社横断のアジャイル雑談会は良いですね！
雑談できるくらいの人数感の会でしょうか。（参加される方は何人くらいですか）
日下：現状は4〜5人程度で、雑談はしやすい人数感です。メンバーが固定化されてしまっているので、もっと誰でも気軽に参加できる会にしていきたいという話をしているところです。

（Q）開発チームとは別に遊撃部隊というインフラ系の担当者がいて自動化回りを支援してくれるとのことですが、試験の自動化コード等も作成いただけるのでしょうか？その場合、開発内容を把握できていないと試験の自動化コードを作成するのは難しいと思いますが、どのように解決されているのでしょうか？
日下：テストの自動化は主にQAが担当しています。GUIで自動テストを作れる「MagicPod」というツールを使っています。
技術的にうまくいかないところがあると、遊撃部隊がサポートしてくれています。

（Q）メンバーがごろっと変わったとしたら、どうなるかは気になりますね。
日下：慣れるまでは大変そうですね。ただ専任のSMを置かずにみんなでやっているおかげで、みんなが別チームに分散してもそれぞれでスクラムを続けていけそうな気はします。

（Q）新しいメンバーがjoinした際に気を付けていることはありますか?
日下：各スクラムイベントについて最初は説明を挟みながら進めたり、ファシリテーションはある程度慣れてから担当してもらうようにしたりしています。あとはSlackのハドル機能などを活用していつでも気軽に相談できる文化づくりはしていくつもりです。

（Q）いまのスクラム形式を推進するまでの一番の壁やどう乗り越えたかを聞きたいです。ウチは全然浸透しなくて悩んでます
日下：スクラムに前向きなメンバーを集めることに成功していたおかげで、導入の壁は低かったように感じています。

（Q）リリースする前のソースコードのモジュールとコンポーネント単位ごとに静的検査とカバレッジテストなども行っているのでしょうか?
日下：はい、QAが担当するE2Eテストや手動テスト以外にも、単体テストや結合テストはエンジニアがコードを書いてCIで実行しており、エンジニア側もテストへの意識は高いと思っています。
カバレッジの測定も行い、可視化していますが、まだ活用はできていない状況です。

（Q）スクラムが「いい感じ」に回るまでどのぐらいの期間が必要でしたか?
日下：改善していく意識が高い、という意味では割と最初からいい感じでしたが、スクラムに熟練していくという意味では、1年半くらいかかったイメージです。それまではPBIの分割の単位が大きすぎたりしていたのですが、見直してからは小さい単位で分割していくようになりました。また、ポイントづけもメンバー間でばらつかないようになってきました。

（Q）不具合の原因調査のプロセスや手順を決めているのでしょうか?
日下：特に決めておらず、issueの担当者が各自で対応しています。

（Q）開発プロセスの中でテスト計画はスクラムのどのタイミングでどのようなメンバーで行なっているのか聞きたいです
日下：QAがスプリントバックログアイテムとしてテスト計画の作成のタスクも切って、スプリント中におこなっています。その間エンジニアは別の機能の実装を進めていることが多いです。

（Q）要件定義、設計、実装、運用についてモジュールやコンポーネントの機能をどのようにトレースしているのでしょうか?
ウチノ：設計書に、要件定義やデザインなどの他の成果物や実装する機能・コンポーネントなどの必要な情報を集約するようにいます。そうすることで、何かあった時に設計書から追えるようになって調査や確認がやりやすくなったと感じています。

（Q）大型リプレイスを3名体制で行う際の役割分担について教えてください。
ウチノ：当初、3人ともエンジニアだったので、イベントや振り返りを3人で持ち回りで実施していましたが、次のように役割を分担しました。
・1人はプロダクトオーナー
・1人はアーキテクトに近い設計担当として、詳細設計を作成
・自分はスクラムマスターとして、リリース準備や進行管理を担当

（Q）ラクスさん、チーム体制なんかも気になります。
ウチノ：上記の体制に加えて、全体を見るプロジェクトマネージャーが1人、テスト専門のエンジニアが1人います。バックエンドは別チームに分かれています。

（Q）WFからの脱却、大変ですよね。壁は多いかと思いますが、なかでも「一番」の壁はなんでしたか？
ウチノ：結果的にWFに回帰したので少し質問の意図とは異なるのですが、WFから脱却しようとして結局戻ってくることになったのは、手戻りを防ぐために要件定義をしっかりやる必要があったためでした。

さまざまな関係者の意見を聞きながら要件を詰め、合意を取るプロセスに丁寧に時間をかけるなど、要件定義の進め方を1から再構築することになったのが、それまでしっかりとはやってこなかっただけに一番大変だったと思います。

（Q）各社さん、スクラムやるなら、実はこんな技おすすめだよ！Tips、みたいなお話聞けますか？
小林：スクラムを導入しただけでは、すぐに開発スピードが上がるわけではないので、期待値の調整を事前に行っておくことが大切です。

日下：ペアプログラミングやペアワークを実施する際の具体的なTipsなのですが、弊社では、Slackのハドル機能を多用しています。ZoomやMeetより気軽に相談できるので、チーム内の障壁を下げる目的でも積極的に使っています

ウチノ：解決すべき課題を明確にし、指標を設定して進捗を可視化することが大切です。指標は1つでもよいので、基準を決めて取り組むことで、スクラムの効果を実感しやすくなります。

（Q）要件定義と設計の手法にどのようなものを採用していますか? たとえば、ドメイン駆動開発などのようなものです。
ウチノ：特に何かを採用したりはしておらず、抜け漏れや手戻りを防ぐといった課題を解決できるやり方を、PDCAを回しながら探っているところです。

（Q）要件定義は、 GUI、システムの振る舞い、データモデルについて全部、整合的にどのように行っているのでしょうか?
ウチノ：それぞれに担当者がいて、それらの意見をプロダクトオーナーが取りまとめて要件定義に落とし込んでいます。

（Q）デスマーチプロジェクトに陥った時は、どのようにリカバリしているのでしょうか?
ウチノ：幸いなことに、デスマーチと呼べるほどの状況には陥ったことはありません。ただし、プロジェクトが遅れたことはあり、その際のリカバリはなかなかできていませんでした。大きな変更は慎重に精査し、優先順位の低いものは対応を見送ることで調整を行っています。遅れが生じないように、事前の計画をしっかり立てることを重視しています。

（Q）プロジェクト進行はウォーターフォールということなのでリリースまでのロードマップを引いて開発はスクラムで回しながらスケジュールの影響を測ったりしているんでしょうか？
ウチノ：要件定義、設計が完了したら、開発、レビュー、テストのサイクルをスクラムで回しながら進めています。また、ロードマップは別途作成して、関係者と相談しながらスケジュールを引いて調整を行っています。

（Q）スクラムを回せてなかった要因の一つにリソース不足もあったかと思います。スクラムを回す上で時間も割かれると思いますがどのようにバランスをとりましたか?
ウチノ：リソース不足で設計やスクラムマスタの仕事が十分にできなかった面はあったので、それらにリソースをある程度割くこと前提でスケジュールを組むようにしました。

（Q）要件定義の変更に対応するときはどのように影響範囲を探るにはどのようなことをやっているのでしょうか?
ウチノ：要件定義から基本設計、詳細設計と順に修正が必要な範囲や内容を精査しています。詳細設計にコンポーネントや機能も含まれているので、そこから実装やテストへの影響範囲を調査しています。

（Q）PHPだとFeature Testなどのテストコードを結構、書いているんでしょう?
ウチノ：PHPのほうはレガシーなので自動テストはあまりできていないです。（手動テストはしている）。Reactではまだ十分に自動化はできていないですが、ユニットテストなどから順次自動化を進めているところです。

（Q）ストーリーの優先順位はどのように決定していますか?
ウチノ：手戻り発生時のインパクトの大きいものや、実装順的に先に手を付けた方が良いものから優先して着手するようにしています。

（Q）設計ドキュメントはGoogleのDesign Docを使っているのでしょうか?
ウチノ：今のところ特にそういうものは使っておらず、独自のフォーマットを使用しています。

（Q）振り返りの内容について具体的にどのような傾向があるのかなど、もしわかれば教えてください（どういう種類の問題や改善が多いなど）
ウチノ：今は生産性についての目標値を設定しているので、生産性を下げている要因にフォーカスするようにしています。例えば、設計に漏れがあったことで見積もりよりも工数が膨らんで遅延につながった場合は、設計漏れが出ないようなやり方は何か、設計漏れがあった場合はどうすれば遅延を抑えることができるか、などを具体化してトライにする感じです。具体的な目標を立てておくことで、漫然と振り返ることがなくなったと感じています。

イベント中にあがったQ＆Aは以上です。