アジャイル開発への一歩目：実践を通したチームの成長
はじめに
KDDIアジャイル開発センター（KAG）ますのです。
KAGでは地方の採用強化の一環としてサテライトオフィスにて高専・大学との連携を進めており、2025年1月14日〜2025年2月10日の間大阪国際工科専門職大学（大阪IPUT）2年生の臨地実務実習を受け入れました！
今回は実習3、4週目レポート（最終回）です。前回は初めてのステークホルダー（中田先生）を交えたスプリントレビューを開催し、プロダクト価値を伝えることの難しさを実感したみなさん。
3、4週目でプロダクト価値についてどう向き合い何を学んだのかを書いてくれているのでぜひ見ていってください！
1週目、2週目の様子はこちら
研修Sprint 3, 4 を振り返って：
こんにちは！ 実習生として配属されている大阪国際工科専門職大学2年生の共田、野村、藤村です。本学では2年次の後期から長期の企業実習を行っており、その一環でKAGにお邪魔させていただいております。
そんな実習も、4週目（Sprint 4）を以っていよいよ終了することとなりました。
Sprint 2を通じて、開発メンバーである私たちもプロダクトの提供価値についてユーザーストーリーを考え、提案していくべきだと気付きました。
そこで、Sprint 3からは、価値のために必要だと感じた機能は、新たにバックログアイテムとして追加するようにし、優先順位をつけて対応していきました。
その結果、実習の大詰めであり時間的に余裕のないSprint 3, 4でしたが、プロダクトの完成まで無事漕ぎつけることができました！
KAGの方や大学の教員にもプロダクトの完成度の高さをほめていただきました！（うれしい！）
また、Sprint 2でプロダクトの価値を伝えることができず失敗に終わったスプリントレビューですが、Sprint 4でも大学の教員をステークホルダーとしてお呼びしました。リベンジです！
Sprint 4の半分以上をプレゼンの準備に費やし、KAGの方にも何度もプレゼンを見て改善していただきました。
その結果、プレゼンは大成功しました！ プレゼンによって、プロダクトの価値を伝えることができ、ステークホルダーからプロダクトに対する要望を聞き出すこともできました！
今回の記事ではプレゼンの成功やプロダクトの完成について、私たちが何を学び、どう生かすことで成し遂げたのかSprint 3, 4での体験を踏まえて紹介します！
ユーザー目線・読み手目線を意識することの重要性
Sprint 2のブログ作成時に、業務を列挙した「報告書」となってしまっているというフィードバックをいただきました。このフィードバックを通じて、「読み手にとってのメリット」や「読み手の興味を引く工夫」を考えていなかったことに気づきました。
そこで、まず読み手がどんな人か、何に興味を持って読むのかを想像しながら書くことにしました。
例えば、私たちのように実習に行くことを考えている人なら、「どんな雰囲気なんだろう」や「どんな体験ができるんだろう」などです。
そこから文章を組み立てていくことで、報告書のような文章から自分たちの視点も混ざったブログらしい文章になりました！
また、プレゼン練習の時にも、「プロダクトがどんな人のどんな悩みを解決するのか」をベースにプレゼンしたほうが良い、というフィードバックをいただきました。プロダクトの機能を紹介するだけにとどまり、その機能が「どんなユーザー」に「どのような価値を提供するのか」という視点が欠如していたからです。
このフィードバックをもとに、Sprint 4のスプリントレビューではプロダクトの価値を伝えることができました！
発表者としても、機能をベースに話している時より、何のためにプレゼンしているのかを明確に感じることができて話しやすかったです。
Sprint 2では、読み手の興味を引く工夫が足りていないという課題が明確になりました。それに対しSprint 3, 4では、情報を列挙するだけではなく、「誰に」「何を」「どのように」伝えるのかを意識することが大切であるということを学びました。読み手や聞き手が何を求めているのかを考慮することで、より分かりやすい伝え方をすることができると実感しました。
タスク管理と優先度付けの大切さ
Sprint3の初日にメンバー2人が優先順位の低い作業を行ったため、本来やるべきだったSprint 2のブログ作成に遅れが生じ、Sprint 3初日中に完了できませんでした。
ブログを作成するのにかかる時間を計算していなかったことも原因の一つですが、一番の原因はタスクの優先度を考えていなかったことです。
初日において最も優先度の高いタスクがブログを完成させることなのは明らかだったので、メンバー全員で取り組むべきでした。
この失敗を踏まえ、作業に取り組むまえにタスクの優先度を話し合い、確認するようにしました。
これによって、タスク管理の意識が高くなり、どんな作業をするにもまずタスク管理表を見るようになりました。
その結果、Sprint 3の半ばには、Sprint 4のスプリントレビュー終了までに達成するべきタスクがとても多いことが分かりました。
そこで、少しでもプロダクトの完成に近づくためにタスクを細かく分け、できるタスクからクリアしていきました。すると、着実に進歩していくのが目に見えて分かり、多くの達成感が得られました！ そして、分からないところにぶつかっても自分が行っているタスクを把握してくれているので、すぐに助けてもらえたのも良かった点です！
また、どのタスクにどの程度時間がかかるかを想像しやすかったので、限られた時間で最大限に価値を実現するための作業を見極めることができたのもよかったです！
Sprint 2では、優先度の低いタスクに過剰な時間をかけているという問題が明らかとなりました。それに対して、Sprint 3, 4ではタスクを分割しそれぞれの優先度を共有することで、進捗状況が明確になり、限られた時間のなかで着実に価値を生み出せるようになりました。
価値のためのコミュニケーション
Sprint 3ではプルリクエストを細かく出していませんでした。そのため、実装している機能が価値につながっているのかPOが確認する機会が少なく、POの目指すユーザー価値から逸れてしまうことが多々ありました。優先度の低い機能を実装してしまったのもその一つです…
そこで、Sprint 4ではプルリクエストを細かく出すことにしました。それによってPOとの会話の機会が増え、プロダクトの提供価値をよりしっかりと共有できるようになりました。
これまでだと、プロダクトにどの機能を優先して実装するのかを理解せず曖昧なまま開発していたこともありました。しかし、価値をよりしっかりと共有することで、タスクの優先度を理解することができました。
また、開発メンバーも積極的に提供価値を考えることにしました。これまではPOが実現してほしい価値をプロダクトに実装するだけだったのですが、開発メンバーからも提供価値を提案することで、よりユーザーにとって良いものを作ることができるようになりました。
Sprint 1, 2ではPOが求めている提供価値を実現することしか考えていませんでした。それに対して、Sprint 3, 4では開発チームが主体的に提供価値を考え、POとビジョンを細かくすり合わせることで、ユーザーにとっての価値をより高めることができるようになりました。
チームで学ぶ仕組みの大切さ
チーム内でスキルレベルに大きな差がありました。しかし、チームメンバーを誰も置いてけぼりにしないことが、この実習を通したチームのゴールでした。
そこで、Sprint 1ではメンバーが同じ作業を行い、全員が一度完成してから教え合うようにしていました。この方法ならスキルレベルの足りないメンバーでも理解しながら進行できました。しかし、先に終わらせたメンバーの手が余ってしまい、効率が良くありませんでした。
Sprint 2の半ばからは、タスクを分担し、1日の始めと終わりにタスクの整理と自分たちがやったことの共有会をすることにしました。この時間にメンバーは互いのタスクの内容を把握・理解しました。時には分からないところを教えてもらったりもしたので、プロダクトに使用した技術などについてはよく理解することができました。また、分担して作業するので、以前より作業効率が大きく上がりました！
もう一つの対策として、スキルレベルの足りないメンバーは一緒にモブプロを行いました。話し合いながら作業をすることで出来るタスクの幅がひろがり、開発の効率があがりました。さらにタスクへの理解も深まって一石三鳥です！ （あと、話しながらワイワイやるのが楽しかったです！）
このように開発を進めていくと、スキルレベルの足りなかったメンバーもどんどん知識がついていくのが分かりました。そして、全員が技術力の向上を実感でき、モチベーションの維持にもつながりました！
Sprint 1, 2では、全員が理解するというチームのゴールのために個人個人で同じタスクをやっていました。それに対してSprint 3, 4では、チームでタスクを分担して作業をすることで生産性が上がり、互いが自身のタスクについての教師となり教え合うことで、理解の差も生まれなくなりました。
まとめ
Sprint 3, 4では、以下のようなことを学びました。
ユーザー目線・読み手目線を意識することの重要性
「誰に」「何を」「どのように」伝えるのかを意識することが大切！
タスク管理と優先度付けの大切さ
限られた時間を有効活用するにはタスクの優先度を大事にするべし！
価値のためのコミュニケーション
POとプロダクトの提供価値について共有するためにもプルリクエストを細かく出す！（タスクの優先度を決められるようになる）
開発メンバーも積極的に提供価値を考えてPOと話し合うと、もっといいものが作れる！
チームで学ぶ仕組みの大切さ
作業以外に勉強の時間も作ることで作業効率を保ったまま、チームメンバーが成長することができる！
モブプロは勉強しながら開発にとても良い！ユーザー目線・読み手目線を意識することの重要性
これらを生かすことで、プレゼンを成功させることができ、プロダクトも完成させることができました！
おわりに
この実習を通じて、これまではチーム内での理解度の差は気にしておらず、チームとしての成長がなく作業効率も上がっていなかったということに気が付きました。
スクラム開発を進めるうちに、徐々にチームとしての力がついていき作業効率が上がっていくのを実感しました。また、細かくデイリースクラムやスプリントレビューなどを挟むことでチームの方向をすぐに修正でき、プロダクトのゴールに向けてまっすぐ進むことができました。
ほかにも、スプリントレビューでプロダクトの報告会をすることでモチベーションにもつながるので、楽しく開発に取り組むことができました。
最後に、今回の実習を通してのメンバーそれぞれの感想を書きました！
メンバーの中では最も知識がなく、実習が始まる前はついていけるのかとても不安でしたが、分からない時など、KAGの方々がとても丁寧に教えてくださり、楽しく実習を終えることができました。今回の実習を通して、実際の開発がどのように進められるのか、どのような姿勢で開発をすればいいのかなどを体感することができました。
Web開発もスクラム開発の手法も知らずに始まった実習でしたが、KAGの方々が手厚くサポートしていただいたおかげで、非常に充実した実習期間を過ごすことができました。知らない言語にどのように取り組むかであったり、スクラムの理念、自分たちのプロダクトをどのように伝えるか、そういった大事な手法や思想を学習することができました。
Web開発について少し知識のある状態での実習でしたが、実装力についてはもちろん、開発に対する姿勢・取り組み方や、プレゼンなどの人に伝える際の考え方など多くのことを学ぶことができました。我々の実習を担当してくださったKAGの方々もとても気さくで、気になったことを聞ける環境で学べ、とても良い実習となりました。
今回実習で私たちの面倒を見てくださったKAGの皆様、とても貴重な体験をさせていただき本当にありがとうございました！