こんにちは、TECH Street編集部です！
この記事では、2026年1月28日（水）に開催した「アジャイル開発エンジニア勉強会〜各社の取り組みや課題から学ぶ会〜」の登壇者の発表内容の紹介と、イベント中に回答しきれなかったQ&Aを記載しています。
登壇者はこちらの方々！
遠藤瑞希
パーソルキャリア株式会社
エンジニア
2022年5月PCA入社、新卒で中小SES会社に就職。PCAは2社目。 Windows業務アプリケーションを中心に、基幹システムや販管システムのリニューアルや機能追加を行ってきました。PCAではdoda CONNECT継続開発（事業連携チーム）にアサインされ、現在はエンジニアリーダーとしてチームを牽引しています。アジャイル開発は今のチームが初経験でした。
susiyaki
株式会社TimeTree
フロントエンドエンジニア/スクラムマスター
佐世保高専、九州工業大学 情報工学部卒業後、Web系企業でフリーランスとして複数社の開発を支援する中で、チームビルディングの重要性を実感し正社員に転向。現在は株式会社TimeTreeでフロントエンドエンジニア／スクラムマスターを務めている。
長期スクラム〜変わるメンバー、進化し続けるチーム、受け継がれる意思〜
NotionからGitHub Projectsへのバックログ管理ツール移行とその効果
Q&Aコーナー
（Q）長く続けるチームで、これはやってよかったなと思うことが知りたいです。
遠藤：個人チャットなど、原則、クローズドな場での意思決定を禁止しています。雑談は問題ありませんが、仕様変更などの重要な意思決定が個人チャット内で完結してしまい、情報が共有されないケースが課題になっていました。会話は基本的に1つのオープンなチャットで行い、「何かあればここで発言する」という共通の場を設けました。この運用に切り替えたことで、情報の行き違いや認識のズレといったコミュニケーションエラーはほとんど発生しなくなりました。
susiyaki：コンテキストの異なる複数のチームが混在している状況の中で、各チームから1人ずつ参加し、ラフに近況や取り組みを共有する時間を設けています。他チームの活動内容を知る機会が生まれたことで、相互理解が進み、この取り組みはやってよかったと感じています。
（Q）doda全体でどれくらいの開発チームがありますか？どのチームも基本的にアジャイルでしょうか？
遠藤：全体の正確な数は把握できていませんが、各プロジェクトごとに少なくとも1つ以上の継続的な開発チームが存在しており、アジャイルチームは増えてきました。一方で、要件の確定や調整に時間を要する大規模システムのプロジェクトについてはウォーターフォールが採用されています。
（Q）最近のスプリントレトロでよく使っているアジェンダやフォーマットはありますか？
遠藤：ヨットのフォーマットは２年くらい使っています。色んなフォーマットを試していた時期もありましたが、現在はヨットが使いやすいということで現在はこちらを採用しています。
susiyaki：KPTのフォーマットを使用しています。すぐに実践しにくいTryなどはインペディメントリストで管理し、定期的に棚卸ししています。
（Q）使ってる各ツールの選定理由とか、あとこれは改善されてほしいとか、これはおすすめ、とかあれば聞きたいです。
遠藤：セキュリティなどの観点から会社として利用可能なツールがあらかじめ決まっているケースが多く、必ずしも自由に何でも選べるわけではありません。その前提の中で、使えるツールを最大限活用しつつ、できるだけチームの負担を減らしていこうというスタンスで運用しています。現在はJiraをメインで利用していますが、最近のUI変更により、チーム内での操作に慣れるまで少し時間がかかっているのが正直なところです。
susiyaki：レトロスペクティブもNotionを使っていました。オンラインでの議論にはZoomやMiroなどのホワイトボードを使っています。フルリモート環境ということもあり、Miroのようなポップで視覚的なUIのツールを使うことで、意見を出しやすい雰囲気づくりにつながっていると感じています。
（Q）デザインドックはどの粒度まで書くようにしていますか？最低限はどのあたりなのでしょうか？
遠藤：追加、更新、削除する対象ソースファイル一覧、大まかな構造調査の図、設計・実装方針、データパターン、画面項目一覧、関連システムへの影響有無をテンプレートとして用意しています。
（Q）チームビルディングの取り組み（手紙交換とか）は、みんなで出し合ったアイデアですか？
遠藤：元々推進メンバーに積極的な方がいました。その方の取り組みをベースにしつつ、現在はメンバーから自発的に意見が出てきたものを柔軟に取り入れていく文化が形成されています。
（Q）チームビルディングの施策が結構充実している印象ですが、チーム内で担当がいるのでしょうか？
遠藤：特に決めてはいません。企画リーダーやエンジニアリーダーからの発案が多いですが、メンバーから要望や提案があることもあります。
（Q）勉強会はどの様なことをされていますでしょうか？
遠藤：新卒～２年目といった若手エンジニアが多いときはテスト観点の勉強会を行ったり、データ分析をしたい企画職も交えてSQLの勉強会やデータ構造の勉強会を行ったりしました。メンバー入れ替わり直後などはプロダクト理解を深めるために、テストデータ作成会などを実施することもあります。
（Q）既存システムが複雑化し、設計の背景が暗黙知になりやすい状況で、デザインドックを導入・運用することについてお伺いしたいです。 長期スクラムの中で、デザインドックが ・書きすぎて更新されなくなる ・逆に軽すぎて意味を持たなくなる という状態に陥らないために、意識している粒度や運用上の工夫があれば教えてください。
遠藤：デザインドックにはその時点の実装方針を記録し、基本的にリリース後に更新はせず「なぜその設計を選択したのか」を後から追える状態を重視しています。フォーマット自体は、毎スプリントの振り返りを行いながら随時改良し、軽くなりすぎないよう調整しています。
（Q）チームメンバーの入れ替わりに伴う、ナレッジの流出、私もとても困っています。 ナレッジの蓄積に使用しているツールや、方法について詳細をお伺いしたいです。
遠藤：元々Excelにメモを残すことが多い状況から、ナレッジの蓄積をWebに移行しようという流れでした。「何かあればScrapboxに書き留める」という運用から始まりました。「とにかくドキュメントを残す」という共通認識で取り組んでいます。
（Q）DesignDocsは機能や設計に関する仕様をまとめる用途であり、資料に記載されていたような、意思決定の経緯を残すという目的であればADRがより適切だと思っていました。 ADRではなくDesignDocsを採用した背景などがあればお聞きしたいです。
遠藤：Design Docsという形式自体に強いこだわりがあったわけではありませんが、背景として「脱Excel」を進めたいという意図がありました。その流れの中で、設計に関する資料についてもDesign Docsに集約しています。ホワイトボード上で影響調査した結果も残しています。特定のフォーマットに固執するのではなく、より適したフォーマットや運用方法が見つかれば、今後そちらに移行していく可能性もあると考えています。
（Q）両社さんに、「AI」をどのように活用しているか聞いてみたいです。
遠藤：スクラムの中では、コードレビューやアジェンダ作成で活用を始めています。プロダクトへの盛り込みは、コンプライアンスや法務的な観点もあるため、現在は調査・検討段階です。
susiyaki：開発支援での活用のほか、社内では取り組み内容を自動で要約し、画像として可視化してくれるボットなども活用されています。
（Q）Notionをエンジニア以外も利用していると、移行したあとチームによって閲覧できる・できないがばらけてストレスに、といったことはなかったのでしょうか？
susiyaki：Notionは、唯一のソース（参照元）として扱う方針を取っていました。そのため、移行の前後で特定のメンバーがアクセスできなくなるということはありませんでした。
（Q）アジャイルとは関係なくて恐縮なのですが、TimeTreeさんは社内の予定もTimeTree管理なのかな？（私は開発チームメンバーでもむっちゃ使ってます）
susiyaki：社内ではGoogle Workspace を使っています。開発チームメンバーでTimeTreeをどのように使われているのか、ぜひ聞いてみたいです！
（Q）移行ってマジきついですよね。ちょっとした課題レベルじゃない大事件とか問題はおこらなかったですか？
susiyaki：ほんと体力を使いますよね...。大きく変化させすぎると反発もあるので、いかに小さく、現状の言葉を残したままみなさんに受け入れられるか、といった視点で工夫をしました。
（Q）「これが一番の大成功！」なのでこの選択・取り組みはおすすめ！なことを聞かせてください。
susiyaki：課題意識をもっているメンバーは前向きに取り組もう！という姿勢でしたが、一方で、そうでないメンバーが感じている懸念や不安にも目を向けることが重要だと感じました。全員ができるだけストレスを感じずに前に進めるよう配慮しながら進めていくことが、結果として成功につながったと考えています。
（Q）今回のこの移行は、アジャイル開発をやりやすくするためのものだった。こういう認識で合っていますでしょうか。
susiyaki：バックログ管理が特定のメンバーに依存しており、チーム内で明確なボトルネックになっていました。必要なデータを確認したくても、「どこに情報があるのかわからない」といった状況が頻発していたのが実情です。こうした課題を解消することが、アジャイル開発を進めるうえで不可欠だと思い、今回の発表をさせていただきました。
（Q）アジャイルに慣れていないメンバーへのオンボーディングは、移行前後で変化しましたか？
susiyaki：新しく参加したメンバーは、これまでの背景や経緯を十分に把握していないため、当初は意図が伝わりにくい場面もありました。しかし、プロジェクトにアサインし、実際の開発プロセスを体験してもらうことで、アジャイルの進め方や考え方を理解してもらえるようになったと感じています。
（Q）今後どんなことをやりたい（チャレンジ）のか、2社に聞きたいです！
遠藤：AIについては、今後ますます活用していくことが求められる時代だと感じています。チームとしても積極的に触れ、試行錯誤を重ねながら知見を蓄積していきたいと考えています。またプロダクト面では、これまで取り組んできたユーザビリティ向上をさらに進化させていく方針です。これまで属人化によって乗り切ってきた部分を見直し、誰でも再現性を持って取り組めるスクラムチームの構築にチャレンジしていきたいと考えています。
susiyaki：toC向けサービスという特性上、不確実性の高い領域に向き合う場面が多くあります。そうした中で、今後はアウトプットの「質」と「量」の両方を高めたいと考えています。 データを継続的に確認しながらボトルネックを特定し、改善につなげていくことで、より価値の高い成果を安定して生み出せる状態を目指していきたいです。
（Q）抵抗感があるメンバーに対して、何か前向きにさせるアプローチはありましたか？
遠藤：「これをやらねば前に進めない」というものは、一旦推し進めて、フォローアップを手厚くするという手法をとっています。メンバーが感じている不満や違和感を丁寧に拾い上げ、解消することに注力しています。
susiyaki：取り組みを進める際には、フォローアップを欠かさず行いながら、メンバー全員が使いやすい形へと改善を重ねています。現場の声を反映しつつ、継続的に調整していくことを大切にしています。
（Q）経験の浅いメンバーで、擬似的にチームを組んで開発経験を積む場合に、短期で実装していくにはアジャイル開発っぽくなるかと考えているのですが、バックログを０から管理するのであればProjectsのみの運用でもいいのでしょうか？
遠藤：よさそうだと思います！
susiyaki：いいと思います。小さくサイクルを回す意識を付けていき、その利点を体感しながら進めるよいアプローチだと思います。
イベント中にあがったQ＆Aは以上です。
今回の登壇レポート一覧
