【enPiT2024】アジャイル開発、苦心惨憺の記録

はじめに

　みなさん初めまして、筑波大学の情報学群、知識情報・図書館学類の３年のあさひです。
　2024年の夏より筑波大学の授業として、「enPiT」というプログラムに参加してきました。自分たちはB3が5人、M1が1人の計6人で「アイホン」というチームを組んで開発に取り組みました。今回は自分たちのチームがどのようにしてこの授業に取り組んできたのか、多々悶着のあったチームの内情と我々の苦心惨憺の記録をここに綴ります。
　端的にまとめると、

　　・ enPiTの授業の仕組み
　　・ アジャイルについて
　　・ 独自のアジャイル開発

　などがわかります。
　もしこれを読んでいる後輩がいたら、来年度以降にenPiTを受講する時に役に立てばなとも思います。
　あまり真似はしない方がいいと思いますが、随所つまみながら参考にしてみてください。

目次

1. そもそもenPiTって何？
2. プロダクト「SuStudy,」
3. 自分たちのスクラム
   3.1. チーム情報
   3.2. 高速スプリントへの対応
4. 開発記
   4.1. 夏合宿(9/18~9/20, 9/24~9/27)
   4.2. 秋学期(10月~1月)
5. 授業を通じての学び
6. 終わりに

1. そもそもenPiTって何？

　enPiTとは、「成長分野を支える情報技術人材の育成拠点の形成」を目標とし、「特色あるプログラムを通じて実社会においてイノベーションを起こすことができる人材を輩出」することを目指した取り組みです。
　筑波大学のenPiTの授業では、身の回りの困りごとを挙げて解決案を練り、アジャイル開発のためのスクラムを組み、問題を解決するための適切なシステムの設計と構築、実装、レビューを通じて、問題を真に解決するシステムを探索的に構築する能力を身につけることができます。
　アジャイルとは短い期間でのサイクルを実現する開発概念、スクラムとは固定的長期的にチームを組むことであり、チームワークを高めスクラムにおける開発サイクルの単位であるスプリントを回してその度に評価を行うことでビジネスの目標を達成することを目指します。

　授業のスケジュールは以下のようになっています。

　授業は2モジュールに分かれており、夏休みの集中授業である前半と秋学期ABCに渡る後半があります。知識情報・図書館学類の生徒では選択必修の科目で5単位分貰え、他の学類生では主専攻実験の単位として扱われるようです。
　通例的にスクラムでは2週間前後を1スプリントとすることが多いですが、enPiTの授業では1授業1スプリントとなっていたため、時間がかなり制約されていました。

2. プロダクト「SuStudy,」

　「SuStudy,」は、勉強の始まりから継続をサポートする「コミュニティ型」「勉強」「習慣化」アプリです。
　→実際のアプリはこちら(チュートリアルに沿って進めばアプリの使い方がわかります)

　資格勉強や受験勉強をしなければならないのに、つい後回しにしてしまいがちな人に送るプロダクトであり、以下のような機能を備えています。

　
　
　

• コミュニティ性
  　ランキングでの他ユーザーと競争や、グループ機能での友人との高め合いなどSuStudy, ではコミュニティ性が重視されており、新たな繋がりや繋がりの強化が得られます。

• 勉強
  　アプリ内での学習はもちろん、後回しにしがちな人も通知によって受動的に勉強を開始することができます。

• 習慣化
  　習慣化のサポートとして、 日々の学習記録で継続的な勉強に向けてやる気を高めたり、 継続学習の報酬として王冠やスタンプ、文書で視覚的にもアプリが充実していきます。

3. 自分たちのスクラム

3.1. チーム情報

• チーム名：アイホン

• チームメンバー：

  • あさひ(B3)：スクラムマスター(ScM)
    　プロダクトの発案と進行の管理決定、機能の基幹作成、拡張、UIの作成
    　
  • kake-p (B3)：プロダクトオーナー(PO)
    　プロダクトとチームの方向性管理決定、グループ機能
    　
  • Yumi Matsui (M1)：サーチマスター
    　行き詰まった時の模索、モバイルの対応
    　
  • uchi (B3)：開発者
    　機能の拡張、デイリー画面、デザイン面、プレゼン準備
    　
  • gotout86 (B3)：開発者
    　ランキング作成、バグ修正、データ保存
    　
  • rinrin456 (B3)：開発者
    　ログイン機能、ランキング作成、プレゼン準備

　基本はこの6人で開発を行なっていましたが12月中盤から1人授業に来られなくなってしまい、残り5人で開発を進めてきました。

3.2. 高速スプリントへの対応

　自分たちのチームは1授業1スプリントという高速スプリントに対応するために、ジョブローテーションとジグソー法を組み合わせた開発を行いました。
　自分たちはチーム内で2人×3チームの組に分かれ、スプリントごとにチーム内で、1人はもとの作業のまま、もう1人をローテーションさせることでの進捗状況、開発の仕方などの共有を繰り返しチーム内の1人を入れ替えることで、メンバー間での獲得知識差を最小化し、全員がコードをある程度理解している状態を作りだすことで開発コストを下げることを狙いました。

　また、スプリントごとに価値のあるものを提供するために、しっかりとレビューでフィードバックを受け取らなければいけません。しかし、1授業でレビューの時間も含めると開発の時間は80分であり、チームのレビューの時間は5分だけになってしまいます。自分たちのチームでは、

• スプリント開発目標を細分化する
• レビュー15分前までに作業を終わらせる

　ことにより、レビューの準備に十分な時間を割り当て、多くのフィードバックを得ることを図りました。
　ただ、これによってさらに開発の時間は短くなってしまったため、残業は余儀なくされてしまいました。アイホンは体裁が悪いことではありますがenPiTで最も残業の多いチームの1つであったと考えられます。
　しかし、私たちにとってこの手法を取り入れたことで多くのフィードバックを得られたことは、開発記にて後述しますが、チームの方針が行き詰まった際に蛍雪の功を積む結果となりました。

4. 開発記

4.1. 夏合宿(9/18~9/20, 9/24~9/27)

　自分たちのチームはもともと、「SuStudy,」というプロダクトを作るために集まったチームではありませんでした。元来は自分の「家にいない時にインターホンが鳴ったら不便だ」という悩み事に共感を得たメンバーが集まったチームでした。
　そこから、「ラズパイを用いてインターホンとスマホを繋ぐアプリを開発する」という案が上がりましたが、すでにスマホでのやり取りが可能なインターホンが存在するという理由から、条件を「インターホンが鳴る時」から「宅配が届く時」と絞り、「宅配を一括管理して不在をなくす」という案でプロダクトを作成していきました。しかし、複数回のレビューを経てこのプロダクトにはあまり価値がないものと気づき始めました。
　そしてここで自分たちの夏合宿は終わりました。

4.2.秋学期(10月~1月)

　夏合宿が終わり、他のチームは数日かけて錬られた困りごとへの解決案を持っており、さらに丸3日分の開発が進んでいる状況で、自分たちのチームは現在のプロダクトに価値を見出せていないという状況でした。
　秋学期が始まるまでに今後プロダクトをどうするかそれぞれ案を考えてこようという話だけをしており、

• 現在の困りごとに対して別の解決案を考える
• そもそも新たな困りごとを見つける

　という2択に迫られていました。
　前者は、夏合宿でも2度目の解決案を考えるときにたくさん考えましたがかなり案を出すのが難しい上に、受け取り時不在でも再配達があるから問題ないという意見がかなり多かったことから自分は後者しかないと考えており、秋1回目の授業でチームでの話し合いが行われ、喜ばしいことに満場一致で新たな困りごとを見つける方向へと舵を切ることとなりました。
　
　
　
　授業2回分の時間を使い、自分たちは「一人で寂しい」「スキルを得たい」「後回し癖がある」という3つの困りごとを日常から見出しました。これらを解決するために、「コミュニティ性を持ち」「学習ができ」「受動→能動の形で習慣化を促す」アプリの開発へ取り組んでいくことになり、これが「SuStuduy,」の端緒となりました。

　プロダクトの方針が決まってからは、3.2. 高速スプリントへの対応の方法を用いてスプリントを回し、順調に開発を進めていました。10月と11月で10月までの遅れを取り戻しながら、良いペースでアプリは完成へと向かっていたのですが、12月の中頃、チューターの方からある問題を提起されました。
　ところで、アジャイル開発ではユーザが実用可能な最小限の機能を備えたプロダクト、MVPをスプリントごとに開発し、ユーザーに「体験」を提供して仮説を検証することが良しとされており、有名な話として、車の制作の話があります。
　ある街で、車というものを発明するにあたって、車というプロダクトを思いついた時、タイヤを作って、エンジンを作って、車体を作って……という風にプロダクトを作成していくと、完成まで実用することができず、ユーザーに価値を提供できない。しかも、完成した時にその価値が認められなければ、それまでにかかったコストが全て無駄になってしまう。しかし、初めはスケートボードを作り、車輪での移動の楽さを検証し、キックボードを作って両手の必要性、自転車を作って座っての移動の楽さ……とユーザーに価値を伝えられる最小限のもので良いので提供し、その価値を確認しながら開発を進めていきプロダクトを完成させると、もし途中で価値が認められなければ、方向修正した場合に無駄になるコストの量も最低限に抑えられるという話です。

馬田隆明, MVP の作り方 🔨 とにかく雑に作る「手作業型 MVP」のススメ

　自分たちは、開発にあたってこの時点まで、

1. 問題
2. 問題を解く画面
3. ホーム画面
4. 見せかけの学習記録画面
5. ログインシステム
6. 通知システム
7. 王冠などのモチベーション維持のアイコン
8. 問題の増設
9. 投稿システム
10. ランキングシステム
11. 検索システム
12. グループ機能
13. タイムライン機能

　という順番で開発を行い、得たフィードバックを経て調整を行っていました。自分たちでは良い進め方であると考えていたのですが、挙げられた問題は、

• 目先の機能を作成し調整を行うためにフィードバックを得ているのであって、それらがコミュニティ性、勉強、習慣化へ通づる価値を持つのかの検証でない
• それらが価値を持つものであるという前提に基づいて進められている

　というものでした。
　確かにその通りでした。もっと見せかけの方法であれアナログな方法であれ、作成してきたものや作成予定のものが3要素の価値を持つ検証はできたはずであったけれど、その検証を行なっていなかったのです。もちろん作成したコンテンツごとに3要素へ価値を感じるかの質問は行い、その回答は得ていました。しかし、「体験」を提供できていたかというと爪の甘いところでした。
　言い訳をすると、この最後のタイムライン完成とあと少しの作業を皮切りに今まで作成したものたちが3要素としての価値を持つかの検証は行う予定ではありました。なぜそれまで検証を行なっていなかったかと言うと、自分たちが3要素の中で最も大事にしていたのが習慣化であり、あまりに不完全なシステムでは、作成したコンテンツ以前の問題で習慣的に利用されないと考えていたからです。1授業のレビューでは習慣化のフィードバックは得られません。ある程度、利用して良い状態になって、ようやく「体験」が提供でき、システムごとの価値検証へと繋がると考えていたのです。また、作成したコンテンツが3要素へと繋がるかどうかも当然調査していて、それら単体が価値を持つことは自明な共通認識としてありました。屁理屈を重ねますが、今現在車を作成しその街で販売するため、キックボードを作成する意味は全くないでしょう。車輪を用いた移動方法の速さも、座席に座って移動する快適性も周知です。ビジネスを始めるにあたって、公共交通機関や道路の混み具合、車を使用する目的や使用量を調べればいいと考えられます。「体験」を提供するならばレンタカー屋を開くのもいいでしょう。自分たちは、すでに存在する価値を組み合わせ、それによって倍加された価値を欲したのです。
　しかし、もちろんこの方法でも、その他の部分で検証が必要です。その検証を行なっていなかったのは自分たちの怠慢でした。

そこで自分たちの前には二つの道が示されました。

• 今からでもMVPを意識したアジャイル手法に戻す
• このまま突っ走る

　MVPを意識したアジャイル手法に戻すとかなりの時間を食います。
　そのまま突っ走ると、「体験」を提供して価値検証を行なったときに全てが無に帰す可能性があります。
　この議題については、チーム内で1スプリントを消費して話し合いを行いました。12月中旬での出来事です。自分たちに残された時間はあとわずかしかありません。チームアイホンは、このまま突っ走る決断を下しました。

　必要な要素の開発を終え、勉強したいが後回しにしてしまいがちな数人にお願いして「体験」を提供して価値検証を行い、多くはない標本数ではありましたがフィードバックを得ることができました。
　それを元に最後の調整を行い、最終発表を迎えることができました。
　
　
　
下図はチームの振り返りのAMFの最終版です。

5. 授業を通じての学び

　このenPiTプログラムを通じ、自分たちは技術的なスキルのみならず、チームとしての成長や組織運営に関する多くの知見を得ることができました。以下、特に印象深かった学びをいくつか挙げます。

1. リーダーシップと意思決定の重み
   　スクラムマスターとして、チーム全体の方向性を統一し、迅速かつ適切な意思決定を下す責任を担いました。短いスプリントごとに決断を迫られる状況下で、情報の整理やメンバーの意見を傾聴する大切さ、そして時には難しい選択をする勇気を学びました。これにより、個々の意思決定がチーム全体に与える影響の大きさを実感し、リーダーシップの真髄を体得する機会となりました。
   　
2. 効果的なコミュニケーションとフィードバックの循環
   　高速スプリントという環境では、限られた時間で正確な情報共有が求められました。スクラムや振り返りを通じ、意見交換や改善点のフィードバックが不可欠であると痛感しました。各メンバーが自身の進捗や課題をオープンに共有することで、問題解決のスピードが飛躍的に向上することを実感し、組織内コミュニケーションの重要性を深く学びました。
   　
3. アジャイル開発の理念と実践
   　自分たちは、完全なアジャイル開発ができたわけではありませんでしたが、従来のウォーターフォール型開発とは異なる、アジャイル開発の柔軟性と反復的な改善プロセスを体験することで、「失敗を恐れず、小さな改善を積み重ねる」という考え方がいかにプロジェクト成功に寄与するかを理解しました。特に、MVPを意識した段階的な開発アプローチは、ユーザーのフィードバックを即座に取り入れ、迅速に方向転換するための有効な手法であると、話し合いの段階で、重要性を理解することができました。
   　
4. チーム内の知識共有と役割の流動性
   　自分たちは、ジョブローテーションとジグソー法を取り入れ、各メンバーが互いの作業内容を理解するよう努めました。これにより、特定のメンバーに依存しないチーム体制を構築でき、予期せぬ事態に対する柔軟な対応が可能となりました。この経験は、今後のどのようなプロジェクトでも「知識の共有」がプロジェクトの安定運営に直結するという大切な教訓となりました。
   　
5. 時間管理とプレッシャー下でのパフォーマンス
   　1授業1スプリントという極限状態での開発は、限られた時間の中で最大限の成果を上げるための工夫と自己管理を求めました。タイムマネジメントの徹底や、短いレビュー時間をいかに有効活用するかという実践的な知識は、今後のどのような職場環境においても非常に価値のあるスキルとして身に付くと感じています。
   　
6. 自己反省と継続的改善の文化
   　授業の振り返り（レトロスペクティブ）では、成功体験だけでなく失敗からも多くを学ぶことができました。自分たちの進め方に疑問を持ち、議論を重ねることで、常に「より良い方法」を模索する姿勢が根付いていく過程は、個々の成長に直結するものでした。このような継続的改善の文化は、今後どのようなチームやプロジェクトでも不可欠な要素であると確信しています。

6. 終わりに

　最後になりましたが、川口先生とメンターの皆さん、講師の方々、一緒に授業を受けた皆さん、本当にありがとうございました。

　何よりチームアイホンのみんな、半年間至らなすぎるスクラムマスターだったけれど、最後まで一緒に取り組んでくれて本当に本当にありがとう！！　最高に楽しかった！！！！