こんにちは！TECH Street編集部です。
今回は、2021年3月18日（木）に開催した「アジャイル開発エンジニア勉強会」のイベントレポートお届けいたします！
今回の登壇者はこちら！
・パーソルキャリア株式会社 鳥居 旭洋さん
・株式会社トラックレコード 上原 将之さん
・みんなのマーケット株式会社 Megumiさん
・石井食品株式会社 石井 智康さん
※登壇順に記載
レポート前半では、皆さまの発表内容をご紹介。記事後半では、当日の質疑応答の内容も紹介します！
doda Recruiters 1プロダクト複数チームスクラムへのチャレンジ
鳥居 旭洋／パーソルキャリア株式会社
鳥居さんは、2019年10月に、dodaが提供するダイレクトソーシングサービスであるdoda Recuritersのスクラムマスターに着任。現在は、パーソルキャリアのプロダクト領域へのスクラムプロセスを展開し、チームや開発プロセスの改善を推進されています。
doda Recruitersについて
doda Recruitersはdodaの持つ会員データベースに企業が直接アクセスし、転職希望者の登録情報を確認した上で、直接スカウトメールが送れるサービス。
doda Recruitersでスクラムを導入した背景
当時、下記のような課題を抱えていたことから、アジリティの向上や施策効果の最大化を狙い、スクラム化を図ったのだそうです。
①組織・人の課題
＜エンジニア組織＞
・プロジェクトごとにベンダー請負開発なので、仕様を把握しているエンジニアが内部に残らない
・新規アサインの繰り返しなので、既存に影響を与えないような増築ばかり
・言われたものを言われた仕様で作るベンダー気質
＜企画組織（ビジネス企画・プロダクト企画）＞
・事業計画と納期が最優先
・要件定義フェーズが終わった後はIT組織とベンダーにまるっとおまかせしてしまう
②プロセスの課題
・最初の要件定義が長引いてエンジニアとの最初の会話まで1ヶ月以上かかる
・基本的にウォーターフォール開発かつ、作るものを明確化して最初に予算承認を取っているので、プロジェクトの途中で状況が変わっても作りきるしかない
・顧客の状況が変わって、当初一番良いと考えて作ったものがリリース後に現場から批判を受ける状況も発生…！
③システムの課題
・課題の合わせ技で大小様々な技術負債が山積み
・技術負債を解消するために大規模プロジェクトが計画されるような状況
doda Recruiters スクラムチームのノウハウ
doda Recruitersのスクラムチームの構成は上記図の通り。各チームはスクラムマスターとPOと、企画側のプランナー、エンジニアで構成されています。
開発の流れはこちら。全体バックログチェックを中心にし、プロダクト関係者全体でデモとフィードバック、リリース判定、優先度検討を行います。そこから、バックログリファインメント、スプリントプランニングをし、スプリントを1週間で実施するそう。
毎日、全体デイリースクラムとチームデイリースクラムをしてアーキコミュニティは隔週に有志で開催しているそうです。スプリント開始から1週間後、スプリントレビュー・振り返りをし、また全体のバックログに戻ってくるという流れとのこと。
ノウハウ①：チームテーマとチームのバックログ
当初は、Large-Scale Scrum(LeSS)の考えをベースに1つのプロダクトバックログで優先度をつけ運営しようと試みていましたが、様々な問題でスクラムが健全ではない状態になってしまったのだとか。
ここで、プロダクトマネージャーを中心に、プロダクトビジョン、注力テーマ、中間KPIを設定。POはスクラムの中で話し合い、注力したいテーマに絞ってインセプションデッキを作成したそうです。
これにより、各チームが独自のプロダクトバックログを持ち、プロダクトのテーマに沿った施策をチームが受け持つ形をとることで、チームの中からもテーマに沿ったユーザーストーリーを出す形が実現できました。
また、チーム内での効果の最大化を狙って施策を考え、プロセスの改善を図ることができるようになるいい変化もあったそう◎
ノウハウ②：アーキコミュニティ
1チームのスクラムの場合は、経験の蓄積や振り返りをチーム全体で共有し、自チーム内で完結することができたので、改善が図りやすい状態となります。しかし、複数になると、経験や改善がチームで閉じてしまうため、コンポーネント共通化など他チームにも影響がある改善がやりづらい状況となっていました。
このような状況から生まれた様々な課題を解決するため、アーキコミュニティを導入したとのこと。
アーキコミュニティでは、チーム内の有志が集まり、隔週で各チームの取り組みを共有します。チームをまたがった改善案を出し合って議論し、アクションと主担当を決めることで、それぞれがチームに持ち帰って活かす・チーム間で連携して改善を実行することができるような体制づくりをしたそうです。
ノウハウ③：MVF（Most Valuable FURIKAERI）
MVF（Most Valuable FURIKAERI）は、クォーターごとに、プロダクト関係者全員がいる場所で、各チームでよかった取り組みを共有するのだとか…！これを実施することで、若手を中心に「次は表彰されるようにチャレンジしたい」という意識が出てきたそうです。
ノウハウ④：リモート下のスクラムで大事なこと
鳥居さんによるとスクラムで大事なのは、コミュニケーションをいかに活発化させるか、そして心理的安全性をいかに確保するか。これらを実現するため、doda Recruitersでは、下記のことを実践したそうです。（めちゃくちゃ具体的です…！）
・同じファイルをリアルタイムに、みんなで同時に編集できるOneDrive上のファイルをフル活用
・Slackチャンネルを分割＆用途を明確にして発言しやすい環境を作る
・昼会・夕会を作り、話す場を作る
・週2回アイスブレイクのためだけに集まる「おやつタイム」の開催
・毎朝のアイスブレイクで「トークテーマ出題スロット」を活用
・個別の1対1ミーティングで「自分がチームをリードする」という意識をメンバーに持ってもらう
doda Recruitersでは、この先、「全体最適で優先度を考えられる組織づくり」を目指していくそうです。理想は、「プロダクト関係者が、今チームでやっていることをしっかり把握」し、「今これをやったほうがいい！」をエンジニア含めてみんなで考え、「今やるべきもの」を「今のSprintでやっている」状態になっていること。
また、開発リードタイムをより短縮できるように、技術負債をより低コストで削減できる仕組みも導入も目指しているそうです。このためには、システムの現状の可視化の強化及びCI/CD環境の整備を実施していく予定だそうです。
最後に、スクラム化を進めていてよかったことを3つまとめていただきました。
✓スクラムチーム全体で技術負債の解消を行う意識を持ってくれた
リファクタリングを積極的にやり始めてくれるようになり、アーキコミュニティを通じてチーム間で連携し、より良いシステムになるように意識しているそうです。
✓エンジニアがプロダクトの成長に意識を向けてくれた
言われたものを早く作ることから事業成長に向かって技術をいかに使って解決するかが楽しい、と言ってくれるメンバーが出てきたのだとか！
✓リリースまでのリードタイムを大幅に短縮できた
小さく作って早く出す、が実現できたのでこれまでよりも短い期間でリリースすることができているそうです。
フルリモート x 副業メインな小さなスタートアップの開発現場
上原 将之／株式会社トラックレコード
上原さんからは、“アジャイルでやっていくしかない”初期のスタートアップの試行錯誤の現実をお話いただくとともに、フルリモートかつ、副業中心で進めている組織で工夫をしているポイントをお話しいただきました！
現在20名のメンバーが働いているトラックレコード社ですが、Slackアプリ「Colla（コラ）」の開発チームにフォーカスすると半分以上を副業のメンバーが占めているのだとか。
日々の開発は“いわゆるオレオレスクラム”で実施されているそう。厳密なスクラムの運用というよりは、1週間でスプリント、全体の週次会議、振り返り、デザイン定例という形で回しているのだとか。日々のタスク管理はnotionを使用、開発のコード管理はGitHub、CI/DeployはGitHub Actionsを使用しているそうです。
このような副業メンバーメインの環境の中で発生する日々の失敗や、それに対する工夫をご紹介いただきました！
権限管理機能の開発
要件
もともとCollaの設定には権限による制限がなく、誰でも設定ができていたため、大きめのWSだと設定の乗っ取りも発生していたそう。そのため、特定の権限を持った人のみが設定できるように管理機能の開発を実施。
課題
この機能の開発にあたり、副業メンバーとのコミュニケーションに問題が発生。Colla自体、シンプルな仕様となっているため、mini specや最低限の仕様書を元にタスクアサインをしたそうですが、レビューのたびに色々な例外条件を思いついてしまい、どんどん要件が複雑化、度重なる改修にレビューコストもどんどん増大していく事態に…！最終的に、進行中の別機能と一緒に検討しないと難しいということに気づき1ヶ月かけてやってきたものが全てひっくり返ってしまう状況になったのだとか。
何がいけなかったか
そもそも副業は本業もある中で時間制約が厳しい（週に1日程度、週によって変動）中で参加してもらっているのにもかかわらず、ドメイン知識の理解など、前提条件の共有にあまり時間を取れずにいたそうです。「自分だったらこれくらいできそうだから、きっとこれくらいできるだろう」と、コア機能を雑に依頼することは、だいたい失敗に繋ってしまうのだとか。
学び
影響範囲の大きいものについて、初期フェーズは特に、フルタイムでコミットできる社員が自らやるべきであると気づいたそうです。ドメインの複雑さにもよりますが、時間制約がある副業メンバーにとっては、例外ケースの考慮などがそもそも難しいのだとか。
また、「時間がないこと」を免罪符にせず、例外ケースなど含め十分検討できるレベルまでは要件を詳細化することも大切な要素であるそうです。こちらは副業メンバーのアサインには関係なく、タスクの見積もりやスケジュールにも関わってくる要素のため、今後は十分に時間を使うことに。
ルール化の重要性
課題
色々なメンバーが関わってくると、色々な形でPull Requestが飛んでくる状況となりますが、概要説明や補足コメントがないと、キャッチアップに時間がかかり、バラバラな命名やファイル配置が問題になるそうです。また、Pull Requestだけでいつレビューするタイミングなのかわからない状態になってしまい、レビューコストの高さが問題になっていました。
この状況を解決するため下記のことに取り組み、レビューコストが劇的に改善したのだとか。
CI環境の整備
CI環境自体はもともとあったものの、なるべくPull Request時点で問題が発生しないように対応したそうです。
Pull Requestのルール化
WIPやReviewersの追加、コメントの仕方などをルール化。
設計方針の言語化
どういう構成にしたいか、命名規則はどうするかなどを言語化。
月イチ1on1
副業メンバーとも月に一回、1on1を実施しているそうです。直近のスケジュール感や今後の方針の説明だけでなく、「こういうことをしようとしているのだけど…」という会話から、本業で似たようなことをやった、などといった話も出てくるのだとか！単純に業務の共有だけでなく、それぞれが持つノウハウの共有をしてもらえる点でも非常に有意義なものとなっているそうです。
フルリモートならではの問題、学びについても共有していただきました。
少なくとも現状フルリモートが原因でチームの生産性が著しく下がった、という状況がないのですが、一番はトラックレコードで開発しているSlackアプリ「Colla（コラ）」の存在が大きいそうです！
Colla（コラ）とは？
Collaは、Botが社員インタビューをしてメンバー紹介をしてくれる無料Slackアプリ。コロナ禍におけるリモートワークで、コミュニケーションがどんどん減っていく中で企業が抱える課題を解決してくれるそう。
皆さんも下記のような課題をかかえているのではないでしょうか？
・コロナ禍でリモート前提の働き方にシフト
・チャットベースだとコミュニケーションが偏りがち（雑談がしにくい…）
・新メンバーのオンボーディングもなかなか対面で顔を合わせることが出来ない
そんななかでCollaはこのようにコミュニケーションをアシストしてくれます。
・Collaさんが勝手にメンバーに質問、毎日回答を発表。
・新メンバーがSlackにJoinしたタイミングで質問、回答するとみんなに紹介してくれる。
このCollaを使うことで、強制的に雑談の場が生まれ、全く接点のないメンバー同士でコミュニケーションができ、チームの一体感が生まれるのだとか。リモートワークでのコミュニケーションにお困りの方は、ぜひ利用してみてください◎
「くらしのマーケット」開発のしくじりとカイゼン話
Megumi／みんなのマーケット株式会社
くらしのマーケットでプロダクトマネージャーを務めるMegumiさんからは、開発のしくじりとカイゼン話をご共有いただきました！
スクラム開発導入時の“やりにくさ”
3年前に初めてスクラム開発を導入した際は、誰も経験者がいない中、アジャイル開発の実践本である『カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで』に沿ってスクラムを取り入れ、1年弱開発を進めていったそうです。
しかし、やっていく中で、“やりにくさ”を感じるようになり、完全なスクラム開発はやめて、自社に合うように変化させていく方向にかじを切ったとのこと。
当時、開発チームでは、下記のような「やりにくさ」を抱えていたそうです。
①リリース日を出せない
②チーム内でやっているタスクがバラバラで、一緒のチームではなくてもいい感がある
③ドキュメントが溜まっていかず、新しいメンバーが増えた際に開発しにくい
④ミーティングの時間が多くなり、開発に割ける時間が少なくなる
⑤振り返りはするけど振り返りっぱなし
こちらは、他社の皆さんも共感する「やりにくい」なのではないでしょうか…！これに対して、Megumiさんは下記の方法で、カイゼンの取り組みをしていったのだとか。
①リリース日を出せない
→半年以上かかりそうなプロダクト開発や明確な期限のある開発はアジャイルをやめたそうです。この方針を採用することで、今の状態がいいのか悪いのか判断をしやすくなったそう。そして最初にすべて見積もることで考慮漏れも防ぎやすくなったとのこと。
②チーム内でやっているタスクがバラバラで、一緒のチームではなくてもいい感がある
→開発内容によってチームを組み替えることによって改善。スクラムを行うことでコミュニケーションは密になるものの、他のプロジェクト内容を全員が知っている必要がなく、メンバーが話半分で聞いていることがあったそうです。また、他部署からの依頼が多いため、計画通りに進まないことも多く、雰囲気が悪くなってしまうことも。
そこで、7〜9名体制のチームは、大きいプロジェクト1つ＋細かいタスクを、4〜5名体制のチームは、大きいプロジェクトを1つ、といったように、開発内容に応じてチームを組み替えていったそうです。また、小さいタスクは即応チームを作って対応したそうです◎
③ドキュメントが溜まっていかず、新しいメンバーが増えた際に開発しにくい
→月に一度、ドキュメントだけを書くドキュメントデイを設定することで改善。エンジニアがコードを書かない日を意図的に作ったことで組織の拡大にも対応ができるように◎
④ミーティングの時間が多くなり、開発に割ける時間が少なくなる
→スタンドアップミーティングからフルリモート環境に変化したことにより、話が盛り上がってミーティングが長くなりがちに。これに対して、デイリーミーティングに時間制限を設け、違うテーマについて話したければ別ミーティングを開くようなルールを設定し、改善を図ったそうです。
⑤振り返りはするけど振り返りっぱなし
→Tryは毎回でるものの、1回きりで終わってしまうなど、積み上がっていない状況だったためKPTでのTryに対して振り返りを実施し、Keepするかしないかを判断するようにしたそうです。これによって、チームの改善の定着スピードも上がったのだとか。
課題を明確にし、一つ一つ改善をしていけているのが素晴らしいですね◎また、このほかにも、やってよかったことをご共有いただきました。
✓自分が開発していない仕様をチームメンバーと話す場を作ったことで、細かい認識のずれを修正する会話が減った。これにより、PMとエンジニアが1対1で話していたことが誰に聞いても答えをもらえる状態になり、スピードアップにつながった。
✓ユーザーテストを1ヶ月に1度実施。そしてテスト日程を事前に設定することで、自然とタスクの優先度の見直しができ、完成させる意識も高まった。
今後について
今後は、2月よりエンジニアの目標がプロダクトの期限や数字から技術に対するものに変更になったため、自己完結できるチームでプロダクトを作りたいと考えているそうです。また、これまでの改善の積み重ねにより、臨機応変にチーム体制を変えていける土台があるため、より良い方法を模索していくのだとか！
今回は、やりにくさが何かを突き詰めていき、一つずつ潰していく作業を積み重ねることで改善に取り組んでいく、というお話をいただきました。「やりにくさ」は会社によって異なるため、自社に合わせて改善していくことが重要とのまとめで締めくくっていただきました◎
老舗食品会社でのアジャイル実践
石井 智康／石井食品株式会社
石井さんからは老舗食品会社でのアジャイル実践についてお話いただきました。石井さんは、SIerでの大規模基幹システム開発や、ベンチャーでのアプリ開発の経験、フリーランスでのスクラムマスターとしての経験を生かし、アジャイルに取り組まれているのだそうです。
石井食品のアジャイルについて
これまで、石井食品が取り組んできたことはデザインスプリントやスキルマップ、雑談など多様。
石井さんがアジャイルにこだわる理由は、「楽しいから」というシンプルなもの。そして、アジャイルを実践するにあたり、石井さんが決めている「やること」と「やらないこと」はこちら。
・やらないこと
→アジャイルという言葉を使わない
食品会社では、あまりITが得意でないメンバーがほとんどなので、そういった場でアジャイルという言葉を使っても意味がないと考えているそうです。そんな時に使うのは「PDCA」。「PDCAを回そう！」とで興味を持ってくれるのだそうです。
・やること
→傾聴から始める
まずは現場の声や、それぞれの課題を聞きながら何が困っていて、何がうまくいっているのかを傾聴することが大切なのだそうです。先人たちが作り上げてきたプラクティスがたくさんあるとしても、それが現場に適用できるかはわからないから。現場の課題を正確に把握し、やれることから始めることが大事なことだそうです。
石井食品における課題と改善
①隣の人が何をしているのかわからない
業務がかなり属人化しており、何に忙しいのか、何をしているのかがわからない状況だったため、まずは「カンバン」を使って業務を可視化してみたそうです。
②改善意見が出てこない
各マネージャーが「改善意見が出てこない」という課題を抱えていましたが、ふりかえりの時間をとることで、改善意見が出てくるように。
③リモートで一体感がない
特に、コロナ禍におけるリモート勤務が多くなった昨年は、一体感のなさが問題になっており、Zoomで毎週全社朝会を実施して改善を図ったそうです。
④マネージャーが捕まらない
デリゲーションポーカーを使い権限移譲ができるような取り組みを取り入れ、なるべくマネージャーがいなくても現場で決められるような取り組みをしたそうです。
そのほかにも、開発がなかなか進まないときはタイムボックスを使って進捗管理をする、
仕様がなかなか決まらないときはユーザーストーリーに落として仕様を考えてみる、ゴールが決まらずギスギスしているときはインセプションデッキを使ってみる、など取り組まれたとのことです。
大切なのは「共通認識」であると石井さんは語ります。全ての手法は信頼関係があることがベースであり、共通認識を増やせば信頼が増えていきます。これによって、同じ敵を協力して倒す、同じ課題を協力して倒すことができるようになっていくそうです。
これからアジャイルを実践しようとしている方々へのメッセージ
“実践すると、必ず失敗する”
石井さんは、失敗してもいい、失敗から学ぶしかないと語ります。今まで見えていなかった課題が見えてくると、色々な波乱が生まれ、失敗も生まれるのだとか。しかし、失敗していないのは挑戦していないからであり、失敗しているということは新しいことに取り組んでいることであるので、それでいいと考えているそうです。
どのようなチームでも、いい時もあれば悪い時もある。しかし努力を続けていけばだんだん上がっていくので、状況が悪い時も、チームが良くなるタイミングになる可能性を意識していくのが良いのだそうです◎
まとめ
今回はアジャイルに取り組まれている各社の事例共有から、改善施策まで盛りだくさんの内容となりました◎
参加者からの声
・アジャイルを導入したことによって発生した課題や、改善への取り組みなど、実体験に基づいた知見が聞けたのが良かった
・取り組むまでの経緯や、失敗など具体的な事例を聞けたため。
・登壇くださった方がご自身の経験（特にうまくいかなかったこと）を語ってくれたから
濃い実体験の話だったから。
・私は今年5月よりアジャイル開発に関わるため、アジャイル開発を取り組んだ方々の失敗談やノウハウ、マインドや参考本など色々な情報が得られて、大変参考になりました！
ビデオオンの参加者の皆様との集合写真
次のページでは、各登壇者の方々へのQ＆Aを紹介します。当日ご回答しきれなかったものも紹介しております！
参加者からパーソルキャリア鳥居さんへのご質問
（Q）アジャイルで感じるデメリット教えてください。
（A）ミーティングの時間が多く縛られて辛いというところがあります。あとは、見通しが立てづらいところも。遅延を防ぎたい思いがあったので、アジャイルを入れることで作業が増えて遅延が発生することは、報告しづらいところもあります。あとは、課題やタスクを透明化するのでサボれなくなる＆なあなあにしていたことに対してしっかり考える必要が出てくるという点ですね。
（Q）みなさん、ウォーターフォールの経験ってどれくらいですか？ウォーターフォール経験がないとアジャイルの良さって語れないですもんね？
（A）ウォーターフォールは8年くらいです。2018年くらいに初めて「an」でアプリのスクラムマスターを初めてやって以降はスクラムマスターでやっています。
（Q）スクラム導入しても、設計者と実装者がぱっきり別れて、スプリントを切ったウォーターフォール開発になってしまいがちなのですが、どう回避すれば良いでしょうか？
（A）メリット多いのならそれでいいのですが、その状態が良いとメンバーが考えていないならば自然と振り返りの中で変えるために取り組みを実施すると思います。が、スクラム的な回答になります。
自分がそういう状況に直面したら、基本的に実装者の要件定義スキルが低い場合だと思うので、小さめのUSを一人に任せて設計→実装を体験させます。
（Q）アジャイルの何かフレームワークの儀式をやるだけではアジャイルではないと思いますが、アジャイルであるというのは具体的にどういったものでしょうか？ 何ができいれば「我々はアジャイルです」と言えるかについて何かあれば教えていただきたいです。
（A）改善、施策問わず、現状を見つめて次何をどの優先度でやるか、ということを常に考えて、常に実行している状態。
（Q）スクラム開発の場合、各メンバーが自律的に動くことが求められるかと思います。外部ベンダーが開発メンバーに加わるとなるとスライドにもありましたが指示待ちになってしまうことも多いかと思います。そのあたりを解決するために何か工夫されたのでしょうか？
（A）メンバー一人ひとりの人格を大切にして話をし、外部ベンダーの人も内部の人として考えて自律性を出してもらえるように試していくしかないと思います。外部・内部だろうがあまり変わらないと思います。
やはり一人ひとりに自律した行動を行うように1on1で声をかけたことが大きいかと思います。
あと、MVFなどの取り組みを始め、様々な場で自律的な行動をした人を褒めまくってます。
振り返りでKPT＋Goodというやり方をしていまして、そのGoodのところでちょくちょく褒めてます。
（Q）アーキコミュニティって興味あるけど毎回モチベーション高く参加してくれるかが課題だったり・・ 何名くらいで実施してますか？
（A）各チーム1名ずつと、スクラムマスターで合わせて4名ほど。現在は8名くらいになっている。
モチベーション低くなってきたら、やめて別の方法を探したほうが良いかもです。僕たちは一定うまくいってるので続けてますが、領域毎とかで分けて人数は減らしたほうがいいかな？と最近考えてます。
（Q）ウォーターフォールの前例しかない発注企業を説得するコツや、ご経験をお聞きしたいです。
（A）今後うちはこういうふうに変わっていこうと思っているから、それに対して協力してほしい。と伝えてきました。また、複数ベンダーに相談した上で、アジャイルな開発に付き合ってくれるベンダーを選んだ場面もあります。
（Q）企画部にいます。 企画の要望を開発スクラムに渡すところに課題を感じています(要望粒度・コミュニケーション方法、技術知識の差etc..) 企画部と開発部の連携のコツがあれば教えて頂きたいです。
（A）一度企画と開発それぞれで不満に思っていること、やられて困ることを腹を割って話すことをおすすめします。
あと、企画はここまで作らなきゃいけない、ここまでは企画の領域。などと線を引かずに、エンジニアが歩みよる（というか領域を食いにいく）とうまくいくと思います。
もちろんエンジニアの役割や領域について、企画側が歩み寄る前提ですが。
参加者からトラックレコード上原さんへのご質問
（Q）アジャイルで感じるデメリット教えてください。
（A）アジャイルしか経験していない立場ですが、スケジュール感もうまく組めない中、ボトムアップで進めることもあるので、業務が肥大化してスケジュールが進まないことが大変です。
（Q）上原さんの感覚で、今は少数精鋭だが、何名くらいになってきたら体制もろもろ刷新を検討しないと・・・と感じますか？
（A）少なくとも、常に刷新を検討しないといけないと感じています。あえて少数精鋭でやっているというよりは、やるしかないから頑張っているというニュアンスです。
参加者からみんなのマーケットMegumiさんへのご質問
（Q）即応チームは何名で誰がこれは「即応チーム」だねって決めているのですか？
（A）最初は5名くらいでスタートをし、CTOが主体となって決めています。
（Q）自分たちで「やりやすいやり方に変える」ことは、どのような経緯で進んでいったのですか？
（A）メンバーの一人が本を読んだりして勉強したことの中で「やってみるか」という一声で始まることも多いので、やりやすさはありました。
（Q）「小さいタスク」はその時々によって量に波があることが多いと思います。即応チームメンバーの稼働の変動についてはいかがでしたか？ 手の空いた時にしていたことや、手が回らなくなった時にどうしたかなどお聞きしたいです。
（A）依頼タスクやバグ修正などやりたいことはたくさんあり、タスクがなくなることはありませんでした。
（Q）やりにくさの共有すごくありがたいです。よかったこともあったという事で、模索中かもしれませんがスクラムもホンキでやる予定はある感じですか？
（A）スクラムも視野には入れています。今後の開発体制に関しては現在検討中です。
（Q）即応チームの人数設定、チーム構成の変更はどのようなサイクルで誰がジャッジしているのでしょうか
（A）CTOと即応チームのメンバーで、毎月新しい人が入る度にジャッジしています。
参加者から石井食品石井さんへのご質問
（Q）アジャイルで感じるデメリット教えてください。
（A）必ず最初は失敗する（今まで見えなかった課題がでてくる）ので、心が折れそうになること。
（Q）食品会社のシステム開発部門って他はどんな感じなのでしょう？
（A)最初は1人情シスで、やばい状況でした。システムはレガシーシステムが残っており、ベンダーはウォーターフォールなので、その中でうまく動かしながら推進していっています。
（Q）他の食品会社から学んだことってありますか？というか他の企業の方が石井さんを参考にする感じなのかな？
（A）日清さんのCIOの話とかを聞くと、もっと大変だし、強力なリーダーシップと莫大なコストが必要なのだなと参考にさせてもらっています。
（Q）老舗企業で経営陣にエンジニア経験のある方って珍しい気が！ 開発組織の雰囲気が気になります！
（A）超楽しいですよ。社員と協力会社さんとの混成チームですが、わいわいやっています。
（Q）そのマニフェスト、わかります、わかりますが…それを遵守できているアジャイル開発って…実際出会えないですよね
（A）アジャイルが提唱する価値を求めようっていう営みだと捉えています。終わりや完成はありません。ただ上手くいっている開発チームはありますよ！ヴァル研究所さんが有名なので、調べてみてください。
（Q）スクラムの他にカンバンのフレームワークもあると思うのですが、カンバンを使った経験があれば教えて頂きたいです。
（A）もちろんありますよ。何を計画していて出来ているのかいないのかが分かるのでおススメです。カンバン仕事術という本がオススメです。
（Q）失敗する！それを上が理解して許してくれない場所だと辛い…（ウチです
（A）上司が見えないレベルから始める、ですかね…週1か隔週のふりかえりから始めることをオススメします。あと、頑張って偉くなってください！
（Q）失敗は必ずすると思いますが、経営者視点だと失敗のサイズ・コストは無視できないと思います。逆に、経営者視点でも許せるような情報連携、アジャイルの説明があれば知りたい。
（A）経営者が許せる失敗のサイズがあると思います。それは現場が思うより結構大きいです。経営においても大失敗すると死ぬので、小さな挑戦・失敗を先に経験をしておくといいです。実験を積み重ねて、大きな挑戦に向けていけるといいかと思います。
経営者に分かりやすい文脈は、平鍋さんやジェフサザーランドの本がオススメです。
https://amzn.to/30U9hj5
https://amzn.to/3eTEefh
最近、KDDIさんがアジャイル経営を謳いはじめたので、そういう文脈も紹介したらいかがでしょうか。
（Q）スクラム導入しても、設計者と実装者がぱっきり別れて、スプリントを切ったウォーターフォール開発になってしまいがちなのですが、どう回避すれば良いでしょうか？
（A）ぱっきり分かれることに課題を感じないのであれば、そのままで良いのではないでしょうか。
私には、設計者と実装者が分かれているメリットの方が少ないように思います。
（Q）アジャイルの何かフレームワークの儀式をやるだけではアジャイルではないと思いますが、アジャイルであるというのは具体的にどういったものでしょうか？ 何ができていれば「我々はアジャイルです」と言えるかについて何かあれば教えていただきたいです。
（A）アジャイルマニフェストで定義されている価値観です。それを実現するためのプラクティス、フレームワークと捉えないと、魂がこもらないので、すぐ形骸化します。それだと何もよくなりません。現場をよくしていこうという想いを持ち続けてトライしていれば、アジャイルを実践していると言っていいと思っています。（完璧はありません）Be Agileです
（Q）各社のアジャイル歴ってどのくらいなのか知りたいです。
（A）形骸化したものを続けていても意味はないので、年数はあまり関係ないように思います。私個人は2014年からで、会社はどうですかね？まだアジャイル歴を語れるほどではないかも知れません。
今回のイベントレポートは以上となります。
ご参加いただいた皆さま、ご登壇者の皆さま、ありがとうございました！次回のイベントもお楽しみに♪
