enPiTでアジャイル開発を経験しました

はじめに

#

昨年の9月から今年の1月末まで、私は筑波大学・琉球大学で開講された enPiT に参加しました。enPiTとは 「日常での身近な困りごとを解決するプロダクトを作る」 という方針のもと、チームでアジャイル開発を行うプログラムです。

制作したプロダクトの概要やプログラム全体の流れを振り返りつつ、授業で得た経験・知識を記録していきます。

開発したプロダクト

#

プログラム前半の夏合宿では、私が提案した困りごとを元に 「チーム持ち物」 が結成され、 「もちもちリスト」 というプロダクトを開発しました。これは一言で表すと 「持ち物リスト版の『調整さん』」 とでも言うべきもので、リストを作成・共有することで旅行や授業などのイベントに向けた集団行動を円滑に行うことを目的にしていました。

秋学期の開始と同時にチーム持ち物は解散し、私は 「ブックマーク（仮）」 チームに合流しました。そこから数ヶ月をかけて開発したのが、Google Chrome向け拡張機能 「らくらくNotion」 です。

エレベーターピッチ

#

らくらくNotionについて、授業内でのエレベーターピッチ（短時間で要点を伝えるためのプレゼンテーション）をそのまま引用して説明すると

といったものです。

仕様説明・アクセス

#

具体的にどう「参考資料管理向けに特化」させているのかというと、

• NotionへのWebページクリップ
• クリップ先データベースへのギャラリービュー自動挿入
• カスタムCSS注入によるNotionの表示簡略化

といった機能で 「Notionについて何も分からなくても、とりあえずNotionアカウントさえあれば拡張機能側の操作だけで参考資料のデータベースが構築される」 という状況を作っています。

プロダクトのコードはGitHubのリポジトリで管理しており、リリースページから実際に拡張機能をダウンロードしてChromeで使用することも可能です。最終成果発表会時点でのバージョンは v1.1.0 です。

詳細な使い方や開発経緯については、以下の埋め込みから成果発表会で紹介されたスライドを参照できます。スライド制作をリードしたのは後述するプロダクトオーナーのD.Hさんです、デザインセンスが良すぎる……

チームについて

#

秋学期の「ブックマーク（仮）」チームは以下の6人で構成されていました。

役割分担

#

D.Hさん、Iさん、Tさんの3名がプレゼンテーション／デモンストレーションのクオリティアップに取り組み、Mさん、M.Hさん、そして私の3名がコーディングを行うという形で役割を分けました。

この分担は非常に効果的だったと感じています。毎授業（スプリント）の流れとしては、プロダクトバックログ(PBL)を元に

と進行するのですが、 「開発」の時間内で「レビュー」への準備も整えないといけない 都合上、どうしても時間が不足してしまいます。開発に集中しているとレビューのクオリティが落ちてしまいますし、レビューを意識しすぎるとあまり手を動かせていないのに少ない手札で戦略を立てる必要が生じます。

プランニングは当然チーム全員が参加しますが、方針を決定した後はコーディング担当は「プランに従って実装を進め、見通しが変わりそうなら相談する」、レビュー担当は「手元にある現状の成果物と、授業内に完成する見込みの仕様を最大限活かしたプレゼン／デモを作る」という役割に徹することで、 開発とレビューが衝突せず協働できる環境 を維持できました。

チームでのVibe Coding

#

ブックマーク（仮）チームでは、秋学期でのチーム再結成初期の段階からAIエージェントを用いたコーディングが採用されました。あくまでこれは個人の意見ですが、2026年現在では（セキュリティ面などの事情がない限り） 短期間の開発を行うのにLLMによるコード生成を活用しないという選択肢はありえない とさえ思います。

一方で、夏合宿にて「もちもちリスト」を開発した際はVibe Codingにより失敗を経験してしまいました。 私が全力でClaude Codeを使役したことで他メンバーの可読性が低いコードを量産 してしまい、結果としてレビュー負荷が偏ったり、私が授業を休んでしまうと一部の仕様を理解できる人が居なくなる状況に陥ったりするなどの重大な問題が生じてしまったのです。辛うじてプロダクトは完成に至りましたが、秋学期においてはこの失敗を二度と繰り返さないための対策を講じました。

どう対策したのかというと、初歩的な内容ではありますが

• プルリクを作成してレビューされるまでmainにはマージしない
• 仕様ごとにブランチを立てて細かくロールバックできるようにする
• 何か実装したい案が思い浮かんでも、まずはissueを立てて整理してから着手する

など、 「とにかくベストプラクティスに沿ったgit/GitHub運用を正しく行う」 ことをコーディング担当全員で徹底しました。開発終盤ではコーディングを担当するメンバー全員がOpenAI Codex, Claude Code, Gemini CLIといったコーディングエージェントを駆使して開発を進めました。

秋学期中の軌跡

#

秋学期では、数回の授業ごとに4つの「スプリント」に分けられ、それぞれのロングレビューに向けて開発を進めていきました。ここからはそれぞれのスプリントを振り返っていきます。

スプリント1/4

#

「ブックマーク（仮）」チームは夏合宿からも活動していましたが、私が合流したのは秋学期の第1スプリントからです。

夏合宿で開発されていた「まとめるくん」というアプリからどのような形で開発を続けるかという議論から始まり、結果として 「1からフルスクラッチするのではなく、既存のブックマーク用アプリ・ツールを強化する」 という方向で進めることになりました。その後も話し合いを重ねて方向性はさらに明確になり、 「Notionに挫折した人向けに、Notionを使いやすくする拡張機能やテンプレートを作る」 という形になりました。この方針は最後まで維持されることとなります。

第1スプリントではあまり技術的に高度な事柄には着手しませんでした。Notionのスクリーンショットの一部を ペイントソフトで編集する 、想定する拡張機能の動作フローを スライドで紙芝居のように再現する といった手段を用いて、毎回のデモを通じて「本当にこの機能はユーザーに訴求できるのか？」「どのようにNotionに対して介入するべきか？」などの疑問を解消していきました。

スプリント終盤では既存の拡張機能であるStylusをユーザーに導入してもらい、我々が提供するCSSを読み込ませるという形式である程度 ユーザーがプロダクトのコンセプトに触れる形 でデモを進めていきました。

スプリント2/4

#

第2スプリントの終盤では、いよいよ実際に拡張機能の開発に着手することとなります。ユーザーが普段使っているブラウザに拡張機能をインストールしてもらうことが可能となり、 「実際のプロダクトを触れる」ことによる実践的なレビューがもらえるようになる と思っていたのですが……ここで問題が発生してしまいます。

実際に拡張機能の開発に着手したのはスプリント最後のロングレビュー直前であったことも災いし、レビューの分量過多となってしまったのです。競合となる既存の拡張機能「Save to Notion」とらくらくNotionを同時に試してもらおうと考えて 両方の拡張機能をユーザー自身のブラウザにインストール してもらおうと試みたのですが、想像以上に導入に時間がかかってしまい、結果として レビューの時間切れとなり一切フィードバックがもらえない という事態に陥ってしまいました。

スプリント3/4

#

ロングレビュー2での失敗はありつつも、開発ペースは急加速していきました。「チームについて - 役割分担」の章で先述した、コーディング担当とプレゼン・デモ担当に分かれて作業を進める方式を導入したのはこの頃からです。このスプリントに入ってから、PBL→プランニング→開発→レビュー→振り返りという 理想的な流れを回せるようになった と感じるようになりました。

コーディング担当は全員LLMによるコード生成を活用するようになり、フィードバックに対する技術的な対応策を素早く試すことが可能になりました。どうしても多少オーバーエンジニアリング気味になり、ユーザー体験が損なわれる状況にも転びかけましたが、プレゼン・デモ担当の3人がユーザーフレンドリーなデモを練ってくださったお陰で 「具体的にどこでユーザーが詰まるのか」「ここからさらに何の機能が必要／不要なのか」 という問題を洗い出し、フィードバックに基づいてユーザーが本当に必要としている要素を抽出することができました。

スプリント4/4

#

最後となる第4スプリントではさらに目線をユーザーに合わせ、 「とにかくユーザーが迷わず使い始められる・使い続けられるようにしよう」 という方向性で動いていました。

• Notionと拡張機能を最初に連携させる際に詰まりそうなところはどこか？
• 表示されるチュートリアルの文言・文量は適切か？
• ページを保存する際の導線はきちんと整理されているか？
• 拡張機能について何も知らない人でも直感的に操作できるか？

といった視点で、少しでも多くの人が満足できるツールだと感じてもらえるように開発を進めました。

成果発表会

#

第4スプリントが終わってからも、最終ロングレビューでいただいたレビューやチームメンバーが持ち寄ったアイデアを踏まえ、優先順位をつけて授業外で各々が対応を進めました。

そして1月後半、enPiTを締めくくる成果発表会がやってきました。コーディング担当もプレゼン・デモ担当も、クオリティをできるだけ高めるためにギリギリまで取り組み続け……

なんと、成果発表会で 優秀賞 をいただきました！！

今後の展望

#

現在もリポジトリは放棄されたわけではなく、開発は多少減速しつつも継続しています。個人的にはWebブラウザとしてFireFoxを使用しているので、近いうちにChrome系だけでなくFireFoxへの対応も狙いたいところです。

チームAMF

#

開発中、チームで アジャイルマニフェストの4つの価値 、つまり

1. 個人と対話
2. 動くソフトウェア
3. 顧客との協調
4. 変化への対応

に沿った振り返りボードである AMF (Agile Manifesto Farm) に振り返りを集積していきました。

毎回新規作成する「スプリントAMF」と、その中で特に継承すべきだと感じたものを転記する「チームAMF」に分かれており、以下は 最終的なチームAMF です。

黄緑色の六角形が 「良かった点」 、赤色の六角形が 「改善が必要な点」 を指しています。

プロダクトの性質上、どうしても「ユーザーを巻き込んでレビューを貰う」という点に困難がありましたが、チーム内で活発にコミュニケーションを取ることで対応していったことが読み取れるかと思います。

個人的ふりかえり

#

enPiTで得た学びは数えきれないほどありますが、その中でも特に重要だと感じるものを挙げると

1. スクラムガイドに沿ったアジャイル開発が持つ力は、困難な状況でも（でこそ）発揮されること
2. 困難は可能な限り分割し、対話することで解決への手掛かりが見えてくること
3. gitを用いたコード管理の重要性

の3点です。

1. アジャイル開発の力

#

スクラムガイドに従ってアジャイル開発を行うと、作業単位（プロダクトバックログ）、スプリント単位（スプリントゴール）、成果物単位（プロダクトゴール）といった 単位の異なる目標に対して繰り返し立ち返る こととなります。

秋学期では序盤のスプリントにおいて、実際のプロダクト開発に移る前にある程度足踏みをすることとなりました。しかしながらそれぞれの目標を一つずつ達成し、向いている方向性が間違っていないことを確認しながら歩みを進めていったため、長期的に見たときに盤石な土台を築くことができました。

2. 困難の分割・対話

#

開発していく中で生じる様々な困難については、とにかく作業単位に分割することとメンバー間で共有することが重要であると学びました。

特定の仕様や方針について1人で抱え込んでしまうと、建設的な解決策が生まれる可能性がその個人の脳内で固定されてしまいます。それだけでなく、至った結論・対応策に他のメンバーが追従できなくなったり、そもそも別の誰かが解決している問題であることに気づかず無駄な時間を過ごしてしまうことにもつながりかねません。

自明であるもの以外は恥じずにとりあえず挙げてみる こと、そして自明であっても（アジャイル開発であればプロダクトバックログアイテム：PBIとして） 見落としを防ぐためにチーム内で共有する ことが非常に重要だとわかりました。

3. gitの重要性

#

これはアジャイル開発と直接的に関係するわけではありませんが、gitでのソースコード管理の重要性についても身をもって実感しました。

enPiTでgitについてガイダンスを受ける以前も個人開発でgit/GitHubは利用していましたが（そもそもこの個人ブログもGitHubのリポジトリをCloudflare Pagesでデプロイしています）、特に ブランチ についての理解は十分とは言えない状況でした。

しかしながら実際にリアルタイムでチーム開発を行ってみると、 同時に開発を進めるのであれば絶対にブランチを分けた管理が必要だ とすぐ理解しました。必要最低限のルールさえ徹底すれば、別のブランチでどれだけ無茶苦茶なことをやってもmainには影響を及ぼさないというのは非常に安心できる構造だと思います。

と同時に、その「必要最低限のルール」をチームメンバー全員が守るということのハードルの高さも感じました。慣れるまではGUIツールから触ろうがCLIで操作しようが誰でも凡ミスを起こしやすく、そのミスをリカバリーしようとしてさらにドツボにはまってしまうこともあり……GitHub側でルールセットを設定できることを知ったおかげで、ミスに起因する破壊的な操作についてはある程度防げるようになりました。

おわりに

#

数カ月間のenPiTでの学びを通して、アジャイル開発とは何たるかを実践的に理解することができました。初対面の人間同士でチームを組んで開発するという経験は、テキスト主体の学習では絶対に得られませんでした。

授業で得た学びは、研究活動や仕事・趣味での開発など、今後様々な場面でのチーム開発において活かしていきたいです。授業で体験したようなアジャイル開発をそのまま取り込むのは（組織構造など様々な事情で）困難かもしれませんが、目標設定や価値に対する考え方などは規模を問わず、たとえ個人開発であっても共通して重要なことだと思います。

また、ブックマーク（仮）改め 「ブックマーク（真）」 チームの受賞はメンバー全員が一丸となって取り組んだからこその成果であり、1人でも欠けていたらここまでのクオリティに達することは困難だったと思います。

ご指導いただいた講師の方々、そしてチームメンバー全員に深く感謝します。