enPit 楽しかった！！！
筑波大学情報学群知識情報・図書館学類2年の高橋空希です。
本記事は、2024/9/18〜2025/1/29にかけて行われた「ビジネスシステムデザイン基礎・実践」(以下enPit)の振り返り兼最終レポートです。
5ヶ月間にやったこと、授業で学んだこと、感想を述べていこうと思います。
enPit受講生、教員・メンターのほか、来年度以降に履修を考えている人にお読みいただければ幸いです。
開発したプロダクト
私たちのチームは、「Who?Name!」というプロダクトを開発しました。
このプロダクトは、「人の名前が覚えられない」という悩み事を解決するために生まれた「人間版なんじゃもんじゃゲーム」です。
サークルなどの新歓やグループ活動などのアイスブレイクゲームとして使われることを想定しています。
これから、新歓シーズンです。使いましょう！！！！！！！
チームについて
チームの移籍
夏合宿以降は「脱・薄情者」というチームで活動し、「Who?Name!」を開発しましたが、夏合宿中は「アルフォート」というチームで活動していました。
移籍理由は、「アルフォート」が扱った「買い忘れを防止したい」という悩みが自分にそこまで刺さらず、このまま5ヶ月間このモヤモヤを抱えたまま活動するのがもったないと感じたからです。
円満に送り出してくれた「アルフォート」と、受け入れてくれたと「脱・薄情者」の皆さんに感謝しかありません。
「脱・薄情者」
メンバー紹介
Aさん
情報理工学位プログラムM1
抜群の安定感
Iさん
情報理工学位プログラムM1
enPit熟練者。クリティカルなとこを常に突いてくれる
Yさん
情報理工学位プログラムM1
今何をしているかをよくまとめてくれていた
Tさん
情報理工学位プログラムM1
意見のアシストが上手だったなと(follower)
Mくん
情報科学類B2
話をまとめてくれていた。同期なのに技術の方も頑張ってて尊敬
Tちゃん
知識情報・図書館学類B2
同期。いいアイディア出してくれる。考えてること似てるなと個人的に感じてた
僕
知識情報・図書館学類B2
議論が長引いた時に、チームにユーザー視点から考えることを意識させていたと勝手に思ってる。発表とかもやりました。
という感じで、M1が4人とB2が3人という両極端な人数構成で活動してきました。長男と末っ子みたいな関係性で遠慮なく話せたので、やりやすかったです！計7人という人数が多いチームでしたが、分裂することなく、仲良くやっていけました！
その反面、ついつい話が長引いてしまったり、すぐ話がそれてしまい、時間が足りなくなるという問題を抱えていました。そこで、タイムキーパーの導入や、タイマーを用いて時間を意識した議論を逐一行うことで、enPit後半では時間が足りないという問題はだいぶ減ったと感じています。
5ヶ月間にやったこと
夏合宿
9/18~9/20, 9/24~9/27という夏休み中の計7日間の10:00~18:00に夏季集中授業という形でenPit夏合宿が行われました。
当初は、「enPit楽しみだけど、夏休みが終わってしまう😭😭」みたいな感情だったのを覚えています。
チームビルディング演習、git/github演習
klis同期3人とM1の先輩1人の計4人でチームを組んで活動しました。
チームで、brunchの立て方、Pull Requestの出し方、issueの立て方など、Githubのチュートリアル的なことをやりました。Git/Gihubに関しては若干の知識はあったもののしっかりと実務で使ったことはなく、学びが多かったです。M1の先輩が頼りになりすぎて感動したのを覚えています。
また、この時に各学年の人数比を知り、klis２年生が3人しかいないことに驚きました。
デザイン思考入門
デロイトからkyonさんが来てくださり、デザイン思考とは何かや、デザイン思考を実行するプロセスについて教えていただきまいた。
自分の中でデザイン思考とは、「プロダクトをつかうユーザー視点から、課題を見つけ、プロダクトの質を向上させる手法」だと考えています。
私はこれまで、プロダクト開発とは、開発者が必要だと思ったものをいかに作るかが重要であると考え、使う人を意識したことがなかったため、デザイン思考との出会いはなかなか衝撃的でした。
この講義で紹介されていた『エンジニアのためのデザイン思考入門』も即購入して読みました。デザイン思考を取り入れた開発過程をたくさん知ることができたのでお勧めしたいです。
余談ですが、kyonさんが僕の出身高校の先輩であったことが一番衝撃でした。
Agile Mini Camp
9/24~9/27の4日間でみほらぶさんが講師の元、Agile Mini Campが筑波大学、筑波技術大学、琉球大学の三大学合同で行われました。
Agile Mini Campの流れ
1日目：課題と解決案を考える。アイデアの価値を考える
2日目：プロダクトの1段階目を公開する(Hello World)
3日目~4日目：プロダクトの開発を進め、授業の終わりにフィードバックをもらう(レビュー)
という流れで行われました。
ここの4日間で「ユーザー目線」についてほんっとに考えさせられたと感じています。「レビューは成果発表会ではない」というのが衝撃的でした。どんなものを作ってもユーザーに価値がなきゃ意味がないというみほらぶさんの辛辣なレビューが怖かったのを覚えています。
とはいえ、常にユーザー目線を意識して開発を行うと、出来上がるのはユーザーが求めているものというデザイン思考の全体像をここでなんとなくイメージすることができたので、得たものはデカかったです。
毎授業打ち上げ
夏合宿の１番の思い出であり魅力はこれかなと感じてます。
夏合宿、なんと毎日打ち上げしてました。僕は、2日目から7日目まで計6日間お邪魔させていただきました。ほんとにkyonさんごちそうさまでした。
打ち上げでは、美味しい料理をいただいただけでなく、kyonさんやメンターの皆さん、受講生など色々な人とお話しすることができました。学部2年の僕にとっては、誰の話も本当にためになる話で、毎打ち上げごとに、人間として成長できたと感じました。
来年もメンターとしてたくさん参加させていただきたいです。
秋学期
Sprintとは
1. 前回のレビューを受けてプロダクトの方針を再検討
2. 本日作る価値の検討
3. 開発
4. レビュー
を毎授業行い、ロングレビューで大きいフィードバックをもらうみたいな感じで進んでいきました
Sprint1
「脱・薄情者」に移籍しました。
「脱・薄情者」は夏合宿の時点では、「U_Name」という、近くにいる人の名前を確認できるプロダクトを開発していました。
そのため、私も、「U_Name」の開発に加わる形で活動を始めていきました。
Sprint 1では、「自分の近くにいる人がわかる」ことをゴールに開発を進めました。
そのために、Bluetoothを用いて近くにアプリを入れているユーザーを検知し、名前を確認するというプロダクトの開発を進めてきました。
しかし、実装のための環境構築やデプロイに時間がかかってしまい、レビューに出せるものがない時間が続きました
結果として、実装はできず、実装予定の画面を作ることで、このプロダクトを使った時の体験を提供してレビューをいただきました。しかし、レビュー準備が不足していたため、欲しいレビューがもらえた感はなく、このあたりでチームのレビューに対する向き合い方が変わっていったと感じています。
Sprint2-1~2-3
レビューやゲスト講義を経て、プロダクトの方針に関する議論が増えました。その結果、議論だけが長引き、結論が出ないまま開発の時間がなくなるからと開発を始め、結果中途半端な開発で終わるという時間が続きました。結果的に、Bluetoothの実装は困難だから方針転換を早めにしようということで、「U_Name」の開発はここで一旦中止し、Sprint2-4から方針転換をすることになりました。
Sprint2-4~ロングレビュー2
Sprint2-4ではどのように方針転換を行うかの話し合いを行いました。その結果、「名前を知る」から「名前を覚える」という方向性に切り替え、「Who?Name!」の案が出ました。
すぐに、「Who?Name!」の価値検証を行えるようにするため、チームメンバーの画像が切り替わるシステムのみを開発しました。
ロングレビューではレビュワーに、チームメンバーの画像でなんじゃもんじゃゲームをやってもらうことで、名前を覚えることができたかという方法でレビューを行いました。
結果、名前を覚えることができたというフィードバックを頂けたので、この方針で進めていくことに決定しました。
Sprint3-1~Sprint4-4
ロングレビュー2で価値検証を行うことができたので、Sprint3からは、いかに使いやすく、いかに名前を覚えやすくするかを意識して活動してきました。
この時点から、毎授業2人レビュー係というものを作り、レビュー開始30分前からレビューの準備を行うことで、毎回のレビューで有益なフィードバックをもらうことができました。
「前回の授業のフィードバックをもとに、今回の授業で改善」
というサイクルがうまく機能しはじめ、Sprint3以降は「アジャイルできてる感」をひとり勝手に感じていました。
成果発表会
いよいよ成果発表会です。
私たちのチームは、スライド作成を授業中終わらせることができず、授業のない日に空いている人で作ったり、成果発表会前の午前中に集まるなどして、最終的にスライドが完成したのは成果発表会中の休み時間でした。もし発表順が最初の方だったらどうしたんでしょうね。成果発表会では私が登壇させていただきました。ドドドドド緊張の中でしたが、笑いありの発表ができ、チームメンバーにもよかったと言ってもらえたので素直に嬉しかったです。
発表の後はデモです。
他のチームの成果物を見るのはやはり楽しく、ついつい長居してしまい、全部のチームの成果物を見ることができなかったのが残念です。
また、「Who?Name!」を使ってくれているも多く、皆さん楽しんでいる様子を見て、本当に嬉しかったのを覚えています。
最後に表彰がありました。
正直、素晴らしいプロダクトばっかりだったので、賞をいただける自信はありませんでした。
ところがどっこい「脱・薄情者」の名前が呼ばれました！
優秀賞をいただくことができました！ありがとうございました！
授業振り返り
AMFのリファクタリングを行いました。AMFとは毎授業終わりに行っていた振り返りをまとめたボードです。薄緑がよかったところ、赤が悪かったところ、青が改善案、緑が各エリアの項目です。
その後、enPitに対するフィードバックが行われました。「アジャイルの定義」や「残業について」などさまざまな面白い議論がなされて楽しかったです。
学んだこと・考えていること
ユーザー目線(デザイン思考)のメリット
何度も書いてきた通り、「ユーザー目線」を意識し、考えさせられた授業でした。enPitを受けた中で、「ユーザー目線」を意識することで得られたと感じるメリットを3点紹介します
1点目は、「ユーザーが求めるもの＝使われるプロダクト」が完成するということです。開発者が「この機能があれば便利だ」と考えて実装しても、必ずしもユーザーに使われるとは限りません。むしろ、不要な機能が増えることで使いにくくなるケースも多いでしょう。実際、iPhoneやゲームのアップデート後に「前より使いにくくなった」と感じることはよくあります。（それが収益にどう影響しているかは分かりませんが……）
そこで、ユーザー目線を意識することで、本当に求められている機能が揃ったプロダクトを作ることができます。ユーザーが実際に使いたいと思う機能にフォーカスすることで、より使いやすく、継続的に利用されるプロダクトへとつながるのです。
2点目は、開発者側の負担を軽減できるということです。デザイン思考を取り入れた開発では、実装する機能に優先度をつけ、重要なものから順に開発を進めます。この優先度は、ユーザーが求めている機能の順番に基づきます。このアプローチを取ることで、もし優先度の高い機能がユーザーにとって価値のないものであれば、そのプロダクト自体に価値がないという判断が可能になります。つまり、顧客のニーズを満たす最低限のプロダクト（MVP）を開発し、実際にユーザーに使ってもらった結果、価値がないと分かれば、早い段階で方針転換ができます。そのため、UIまで含めて完成させたものの、結局使われないという事態を防ぎ、開発コストや時間の無駄を最小限に抑えられるのです。
3点目は、チームの方針決定をスムーズにするということです。私たちのチームでは、プロダクトの機能について意見が割れることが多々ありました。しかし、実際のところ、このような議論は本質的ではありません。なぜなら、最も簡単な解決策は、機能を素早く実装し、ユーザーの評価を基に良い方を採用することだからです。このように、「ユーザー中心」の考えをチーム全体で共有することで、無駄な議論を減らし、より迅速なプロダクト開発が可能になります。意思決定のスピードが上がることで、より効率的な開発サイクルを実現できます。
デザイン思考の限界
一方で、デザイン思考には限界もあると考えることがあります。
そう考える理由について2点書いていこうと思います。
1点目は、開発者の熱量や情熱がプロダクトに反映されにくくなる場合があるという点です。プロダクト開発を進める中で、開発者とユーザーの認識に齟齬が生じることは少なくありません。その際、デザイン思考のプロセスに従い、ユーザーが求める機能だけを優先して実装すると、開発者が本当に作りたいものとはかけ離れたプロダクトになってしまうことがあります。このような状況では、開発者のモチベーションを維持するのが難しくなり、プロジェクトの進行に影響を与える可能性があると感じました。
2点目は、ユーザーの声に依存した結果、革新的なアイディアが生まれにくい点です。デザイン思考では、ユーザーのニーズを重視し、それに応じたプロダクトを開発することが基本となります。しかし、ユーザーの意見だけに頼りすぎると、既存の枠組みの中での改善にとどまり、従来にない革新的なアイデアが生まれにくくなると感じました。ユーザーは自身の経験の範囲でしか意見を出せないため、「もっと便利にしてほしい」「この機能がほしい」といった要望が中心になりがちです。しかし、本当に革新的なプロダクトを生み出すためには、ユーザー自身も気づいていない潜在的な課題や、新しい価値観に気づくことが大切です。そのため、デザイン思考に固執しすぎると、大胆な発想や、開発者の独自の視点が活かされにくくなる点が課題だと感じました。
もちろん、開発者の技量次第で熱量を維持したり、潜在的な課題を発見したりすることは可能だと思います。しかし、それを実現するには高い経験値や洞察力が求められ、決して簡単ではないと感じます。
こういうの、kyonさんとかみほらぶさんに話聞いてみたい。
発言する勇気
先述の通り、私のチームは議論が長引きやすく、その結果、開発に充てる時間が短くなるという課題を抱えていました。しかし、私は「チームの雰囲気を乱したくない」「みんなと仲良くしたい」という思いから、「また長引いてるな……」「本当にその方向性で大丈夫？」と思いつつも、積極的に発言できずにいました。
しかし、授業の後半になるにつれて、自分が意見を言ってもチームメンバーは真剣に耳を傾けてくれ、違う意見にはしっかりと「違う」と伝えてくれることに気づきました。そのおかげで、徐々に自分の考えを言えるようになりました。また、enPiTの打ち上げでIさんから「そらきはもっといろいろ言ってほしかった」と言われたことで、自分の意見を伝えることの大切さを改めて実感しました。
次チーム開発などを行うときは、積極的に自分の意見を伝えていきたいです。
おわりに
ここまで読んでいただきありがとうございます。
今まで履修した授業の中で一番ためになったと感じています。
2年次から履修させていただいたことに本当に感謝です。
また、「脱・薄情者」は3/23(日)にAgile PBL祭りで登壇させていただきます！
enPit関係者他、本記事をよんで興味を持ったことはぜひいらしてください！
来年度以降はメンターとして、enPitに参加し、より「アジャイル開発」や「デザイン思考」を理解していきたいなと考えています。
最後に
enPit楽しかった！！！
ありがとうございました！