enPiT個人レポート: ゼロからアジャイル開発を始めて感じた事

Gild

はじめに

昨年の4月から筑波大学 知識情報・図書館学類の授業の一つである「ビジネスシステムデザイン」を履修しており、この授業は文部科学省が過去に推進していた「enPiT」と呼ばれるプロジェクトに参加するカリキュラムの一つとして実施されています。
この記事はそんな「enPiT」の秋学期の最終レポートとなっております。
時々春学期の話も交えながら書けたらなと思っていますので、特に来年度履修を考えている方はご一読いただけるとありがたいです。

enPiTとは

多分私の記事の公開と同時期に様々な人が「筑波大学のenPiTはビジネスシステムデザイン分野」ですとか、先ほど書いたような「文部科学省が推進しているプロジェクト」等様々な説明をしていると思いますので、省略させていただきます。
是非私だけでなく、ほかの方の記事も読んでいただけるとありがたいです。

そもそもなぜenPiTを履修したか

実は私自身、コーディング自体はあまりしてきませんでしたが高専時代に何度かチーム開発を経験しています。
ただ、アジャイル開発とかスクラム開発とか話にはたまに聞いても特に取り入れることもなく自己流チーム開発をすることがほとんどでした。
そんな形でうまく行ったり行かなくなったりしたわけですが、体系的な開発手法を学んでみたいな(あわよくば作ったチームでハッカソンとか出てみたいな)、といったところがモチベーションになっていました。


開発したプロダクトについて

「Cookりさん(コックリさん)」というレシピの横断検索サイトを作成しました。
どんなシステムかは以下の発表スライドを見ていただけるとわかりやすいと思います。

使用技術としては、KlisでPythonしか習わないということもあり、Pythonを使うことになりました。私が某フレームワークを拒絶したり多数決によりFastAPIを使うことになりました。

人力でレシピ収集してたり、DBを使わずにJSONで無理やりデータを扱ったりの限界構成ですが、この理由については後程。

システム構成図

そんなCookりさんを作るまでのプロセスについても、ここから色々言及していこうと思います。

チームについて

  • Nakaya君：プロダクトオーナー(PO)、開発経験あり

  • O君：スクラムマスター(ScM)

  • なおと君：開発者

  • くま君：開発者

  • ギルド：開発者

私は一応は開発経験者ですが、POでもScMでもなく基本的に突っ込み役でした。いろいろなことに口を出していましたがいい方向にも悪い方向にも転びかなり難しかったなぁという印象があります。

注文の多い料理店とCookりさんはどうできたか

ここからはスプリントごとに当時考えていたことも思いだしながら書いていこうかなと思います。

Sprint1

夏合宿では同じくレシピ検索サービスである「recipe-compass」を作成していたのですが、デプロイ先のHerokuの無料枠廃止やメンバーの入れ替わり、夏季休暇で忘れてしまい、コードをまともに説明できる人がほぼいなかったので、プロダクトの作り直しをすることに決め、プロダクトの方針を再検討していました。
ただ、夏合宿の間はPOがいないことが多くチームでの方針を決めていたのが私だったため、その時のノリで口を出しすぎてしまうことが多々あり、自己反省を重ねていましたが、今後の開発で更なる反省をすることになります。
また、このスプリントから既に開発も着手し始めており(enPiTではデプロイされたものがあり、UI・機能的に目に見える進捗があることが是とされやすいので)、プロトタイプもまともに組んでいませんでした。
正直、スプリント1つは1-1～1-4と計4つの時間で構成されていますが、Sprint1-3の頃にはチームメンバーの意見に自分もガンガン意見を出していたものの、チームメンバー全員において話のかみ合わなさをものすごく感じていました。ただ、正直この時これを感じていたのは僕だった気がしていて、チームで自分の意見だけ浮いているのがどんどん浮き彫りになっており、チームのコミュニケーションも阻害してしまっていたと感じていたのでものすごくもどかしさを感じていました。
実際これはレビューの際も、メンバーごとに考えていたことが違ったみたいなことが起こっていて、意志共有手段を色々提案しなかったことを正直後悔していました。
当時はPOと全ての意見がかみ合っておらず、授業内で毎回言い争いに見えなくもない議論が発生していて心理的安全性を下げてしまったことは大きな反省点の一つですね。。。

出席のための振り返りに書いているログを振り返ってみたのですが、

PBIどころか今日はTODOの内容でさえ完全にぼやけてしまっていた。

Sprint1-3

と書いていて他にも「違和感」やら「認識の違い」やらのワードがたくさん出ていて、自分のチーム内の立ち回りにかなり苦心していた記憶があります。(ちなみにこの日は口を出しすぎたことを前の授業で反省していて、できるだけ口頭ではなくDiscordのチャットに書き込んでいました)

そんなことがあり、認識のすり合わせができてないよりは「違和感は全て口に出す」を徹底したほうがいいと考えるようになりました。

ロングレビュー1

これまでのチーム運営の問題点が浮き彫りになります。
まず、Proof of Concept(PoC)がはっきりしないまま仮説ベースでの議論でスプリントの時間をほぼ使っていて検証が曖昧だったことが指摘され、正直ぐぅの音も出ませんでした(汗)
そのうえで、「レシピ検索」というサービスはレビュアーもチームメンバーも「俺が考える最強のレシピ検索」が基本的に全員違うので多種多様な要望が出て、それを管理しきれずに仮説の議論に入って更に時間を浪費するという悪循環に陥っていました。

Sprint2

ロングレビューを得て、とりあえずチーム内での意識をすり合わせようと思い、自分にできることを考えに考えた結果、時間外でFigmaでプロトタイプを作成して授業時間でチームメンバーからのFBを基に修正というプロセスを一度作りました。(授業外での作業自体は良しとはされませんが、授業時間内でプロトタイプを1から作成し始めて、、とかやっていると時間がいくらあっても足りないので)
そんな感じで動き始めてからチーム内での認識が固まり、このあたりからだんだんチームらしさが出てきます。こうして、検索機能の実装やUIの改善が進んで開発自体は順調でしたが永遠の課題が出現します。
そう、「レビュー」です。授業ごとに短時間レビュー時間が設けられているのですが、レビュアーは自分たちの思うサービスを基準にレビューをくださるので、スプリントの途中でも結構容赦ないです。ということで、前提を大声で叫ぶことが個人的には重要だなぁという感想を当時は抱いていました。
Sprint2ではこんなレビューに振り回され始めます。
夏合宿では作りたい機能を「初期リリース」「目標」「夢」に分けてプランニングしろと指導を受けますが、頂くレビューは大体「夢」だったり、技術的には1スプリントで実現可能であってもチームの目指す完成形をよく考えた上で実行するかを決める必要があります。
そのため「レビューの取捨選択」に慣れていないと、レビュー通りの機能を提案することになり「どこかで見たことのアプリ」に近づいてしまう可能性があります。
この考え方が体にしみこむまではチームでも意思決定に凄く苦戦を強いられていました。

ロングレビュー2

この辺からレビューに対して、チームでもかなり議論して準備を行い、ロングレビューに臨みました。
例えば、Figmaで作成したプロトタイプを投げて僕たちが考えている完成形をしっかり提示したり、実際のユースケースをストーリー立てて説明し、前提(こういう使い方をしている、これからこういうことを実装するのを想定している)みたいな工夫をしていきました。
その結果、かなり身になる意見が多くなってきてチーム内でも協議がしやすくなり雰囲気も心なしか明るくなっていきました。

Sprint3

このあたりからチーム全体に余裕が出てきて心理的安全性とか休憩とかいろんなことを考えられるようになってきました。
課題として挙がったのは、

  • 休憩を忘れがち→休憩時間もプランニングする

  • 時間見積もりが甘い→プランニング時に時間の見積もりとタイムキープをする

みたいな感じです。
また、書くコードの難易度も上がり、幣チームではチーム全員でのモブプロをしていたのでコードの解説もPOや私を中心にしていきました。
全員がコードの理解をしておくことで、もしいつも開発で中心になっている私やPOがいなくても少しでも進捗を出せる状態にしておきたい！という夏合宿時から続く注文の多い料理店の文化が続いた結果このような開発体制を取っていました。

ロングレビュー3

ここではUIについてかなり突っ込みを受けました。
現在、Cookりさんはタグやタグの横の「－」ボタンを押すと検索バーに追加され、追加した後に検索ボタンを押すという形のUIになっています。
これはPOのこだわりでもあったわけですが、私も含め「タグのボタンを押したらすぐに検索しなおしてほしい」という意見が入ります。
これ、以下の図のようにタグを2度タップすると検索バーから食材が消えるというUIを提供しているのですが検索ボタンを押さずに自動で遷移してほしいという意図になります。

タグのトグルUI

このUI、最終的に僕も検索ボタンを押すUIで行こう！となったのですが、その理由は

  • 検索ボックス自体はテキスト入力なので、マイナス検索を走らせた後、「やっぱほしい！」となったときに手作業でテキストを消す必要がある

  • 検索ボックス上でもタップで検索条件をリセットできるようなUIの作成コストが高い

というのがあり、「期間内での価値提供」を考えた時に1スプリント4授業といいつつ、enPiTの授業の実態は1スプリント1授業なので、授業時間内で実装が終わらないとスプリントが停止するものだと明言はされていませんでしたが暗黙の了解でした。
そのため、2時間弱の時間で実装できないものを取り入れることは基本的に厳しく、代替手段を考えるか、そもそも実装しないかの判断が必要でした。
DBを使わずjsonで何とかするという限界開発環境になったのもDBの導入コストが高いことを夏合宿で学んでいたため1授業でやるのは厳しいという判断をしました。

とはいえ、「レビューをはなから取り入れない」というのと「議論したうえで取り入れない」というのは違います。
ということで私が行ったのは

  1. レビューを分解する

  2. POがやりたいこと尋ねてみる

です。
1に関しては「もっと表示するレシピが増えてほしい」というレビューが出ました。

突発発生したレビュアー発のアンケート

これ、ぱっと見でとらえるのであれば「レシピ数を増やす」というのが純粋な解決策にも見えますが、当時のCookりさんはAnd検索にしか対応していなかったので、「OR検索ができるようにして、選択した食材が一つでも該当したらレシピを表示する」という方法も考えられるのです。
そして、And検索という前提で考えるのであれば単にレシピ数(ちなみにこの時点でのレシピ数は696)を増やしたとして、ユーザーが入力したクエリに対する結果が増えるとは限りません。
となれば、OR検索という方法の方がユーザー体験は良くなる可能性があります。というようなことを、レビューを鵜吞みにせずに、分解したらこうなるよね？というのをこのロングレビューからは意識していました。

2ですが、ロングレビュー1でチーム内で意見が浮いてしまっている自分の状態やチーム全体の状態をメンターに相談したときに、「みんながやりたいことが違うのは当たり前だから、POがやりたいことから議論していったらいい」とうろ覚えですがこんなことを言われたのをここで思い出しました。実際、POもレビューを受けて今後の方針に悩んでいる様子があり、まずPOがやりたいことを聞いてみることにしました。
Sprint4はそこからPOが出した意見を基に組み上げていく過程に入っていきます。

Sprint4

ここまで来るとプロダクトの完成形はほぼ見えてきていたので、もう磨き上げるだけだぞ！というのを毎回チーム内で言い合っていました。
このスプリントでは新しい機能の追加というよりは、軽微な修正を繰り返して少しでも今のアプリが使いやすくなるかという事を意識していました。
まずはPBIの優先度を再検討するというItemを作って意思決定をチーム全体で改めて行い方針決めをしました。

実際のPBI


アプリ内に説明を追加したり、トップページで検索できる食材を増やしたり、と本当に細かいUXの改善をしていて、最終成果発表に向けて足りないところを補うという気持ちも個人的にはありました。
このあたりで、チームメンバーもレビューをどう受け取るか等々について自分なりの考え方が身についてきたのか、レビューでいろいろ意見を受けた後もポジティブな議論が活発になっていました。

ロングレビュー4

このロングレビューの意義はほぼ最終発表会への準備かなと思いながら望んでました。
この辺はドッグフーディングしたかとか、最終発表でどれだけチームで作ったサービスの良さをアピールできるかが争点となっていました。ということで、技術的な目線のアドバイスも受けつつ平和に終わりました。

発表準備

さて、流れで私がプレゼンのスライド準備・及び発表を任されることになりました。
正直、プレゼンを成功させる自信はありました笑。
私自身プレゼン経験自体は何度かある事、チームで制作したサービスを自信をもって推せると思ったことが理由です。ということで、改めてチームメンバーにサービスの推しポイントを聞いてみたり、全員でアウトラインを決めて、それを基にスライドを作っていました。
スライド自体はかなりこだわったつもりですが、

  • EVPをそのまま貼らない

  • 実際に社会問題になっている具体的な課題(外食の値上げ)の提示

という点に関しては最初から実行すると決めていました。実際、プレゼンはかなり好評を頂けたので凄くうれしかったです。

最終発表

ということで、万全の態勢で臨んだ最終成果発表会ですが、他大学や準拠テーマのかかわりがなかった方たちのプロダクトやプレゼンを見ることもできて非常に刺激になりました。
そして気になる結果ですが、、、、なんと優秀賞。
どのチームもレベルが高かったので取れないと思っていたのですが、今までの自分たちのやり方が認められた気がしてとても嬉しかったです。
何故か準備していた背景素材が記念撮影のおかげで日の目を浴びました(笑)

何故か作成したZoom背景素材

改めてenPiTを振り返ってみて

さて感想も文句も交えながらここまでだらだら書いてきたわけですが、個人的に学んだことや感じた事をまとめてみようと思います。

  1. PBIは細かく分ける

  2. 違和感は全て共有する

  3. やりたいことも全て共有する

  4. プロダクトだけでなく、プロセスにも自信を持て

  5. レビューは言う側について説明されがちだが、もらう側にも下地がいる

1. PBIは細かく分ける

先にも話した通り、秋enPiTの実態は実質的に1授業1スプリントの合計16スプリントです。また、スプリントの原則から言えばそのスプリントに終わらなかった作業は捨てることになります。
その中で授業毎のスプリントレビューに対応するには「いつでも目に見える進捗」を出す必要があり、例えば「Sprint1-2でDBの設定とスキーマ定義までする、Sprint1-3でDBにデータを流してフロントで見せる」みたいなことをするとSprint1-2のレビューでなにをやってたの？となるわけです。(もちろんプロトタイプを用意するなどの回避策はありますが)
というわけで、タスクを小さく分解して小さな進捗をコツコツ出し続けるということをSprint1から常に意識し続け、少しでも進捗を見せることを心掛けていました(後半が進捗のための進捗なっている、という突っ込みはありますが)。

2. 違和感は全て話す

Sprint1で違和感を感じていたということを書きましたが、「①何も考えず全部口に出す」「②口では黙ってDiscordを活用する」「③取捨選択して話す」「④議論として全部提示する」というような方法を勝手に試していました。
僕の肌感では④が一番良かったです。③も部分的には良かったのですが、些細な違和感でもそのままにしていると意外と後々大きくなって返ってきたりしました。なので、一つの意見として挙げていくことが大事でした。
事前に心構えができているかといないかで、チームの対応も結構変わってきました。

3. やりたいことも全て話す

これに関しては少し慎重でした。なので提案するときは「目標」「夢」という立場を明言して話していたつもりです。

4. プロダクトだけでなくプロセスにも自信を持て

これ、「チーム全員でモブプロ」という事をやっていたチームが幣チームだけだったことに起因しています。
完全に2人チームに分けて分業したりしているチーム等と比べると、実際に関わらず、ぱっと見はやはり自分たちの方が進捗が遅いように感じます。
また大体のチームがペアプロ分業という方針を取って、「全員がプログラミングをする必要はないよね」というようなことも話していました。
正直これに一番チーム内で不安になっていたのは僕だと思います。実際、他のチームより進捗が出てなさそうと錯覚して、夏合宿から秋学期の中盤まで何度か分業を提案しました。
ですが、POからそのたび全員でやりたいと諭されまして、冷静に考えるとこのやり方にもいい点がいくつかあることに気づきました。
具体的にはチーム全員がコードの理解をしていることで、プロダクトについても「こういう実装はできそうだから、これやってみない？」等のある程度技術ベースも交えた議論もできるようになってきました。
enPiTでの考え的には技術ベースの議論はあまりよくないとは思うのですが、作るのには技術の話をする必要がありますし、具体性をもって全員がレビューでの質問に答えられる下地がいつの間にかついていました。
こんなことがあり、プロセスに自信を持つのも重要だなという学びを得ました。

5. レビューは言う側について説明されがちだが、もらう側にも下地がいる

enPiTではレビューを送る側に関しては、

  • 「ターゲットユーザーか」「ちょっと気になる程度か」などの立場を明言して話そう

というような指導がありましたが、レビューを受ける側の立場に関しては当たり前ですが体系的な指導はできません。これはプロダクトのターゲットスコープ等々、かなり変化に対応する必要がありからです。
が、これをザックリ言われただけで身に付けるのはレビューを出す以上に難しいです。
その状態で、初めからプラスのレビューを貰えることは正直まれだし、プロダクトの概形が見えてくれば来るほどレビューに対して「あれもいい！これもいい！」となって鵜呑みにして取り入れたくなってしまい破滅します。
というわけで、ある程度レビューを予測しておくことや私たちが作ったような「完成形の予測しやすいプロダクト」については自分たちの完成形のイメージをレビューの際に共有するといった方法でレビュアーを誘導する必要があります。
これに気づくのに時間がかかり、最初の方はレビューが近づくにつれてチームの雰囲気が暗くなっていました。。。

以上が学んだこと・感じた事になります。
enPiT全体を通して一番身になったことは「アジャイル・スクラムの考え方について」もそうですが、「レビューをどう受け止め、どう生かすか」といったところが大きかったような気がします。
今後、携わっているプロジェクトでenPiTでの学びをしっかり発揮していきたいと感じました。

enPiTに望むこと

最後に、個人的に少しもったいないなと思っていたことについて書いていきます。enPiTの春学期では個人学習として自分がやりたい技術について学び、Scrapboxにまとめます。

実際に私が作成した記事

こういった知見だけでなく、enPiTで開発を続けていくうえで身についた実践的な知見が受け継がれていかないのは若干の寂しさを感じます。
知見をまとめる場は用意されていますが、秋学期はほぼ動いていませんでしたし、昨年のScrapboxの共有などはありませんでした。
自分で1から学ぶことも重要ですが、こういった先人たちの教えはenPiTのような短期間の開発ではとくにありがたいものな気がします。
特に今年度は今まで学生の見方だったHerokuが無料枠を廃止し、代替手段を各チームが各々の方法で見つけ、使用していました。私たちもDeta.shに移行し、以下のような記事を個人的に書いています。

Deta.shでサクッとウェブアプリをデプロイしてみる
https://crowd4u.github.io/posts/2023-01-01-start-deta/

今でもHerokuの移行先を探している人たちは多いと思いますし、来年度困る受講生も出てくるかもしれません。そのためにも、このような知見を活かす手段が用意されていると良いのかなぁと思います。(こういった技術記事もアウトプットや学びになりますし)

最後に

と、enPiTについて色々書いてきました。ここまで読んで良い印象を抱いた方も悪い印象を抱いた方もいると思います。
ただ、enPiTという場に関してここで書いた以外にも様々な学びや気付きを得られたと思っていますし、履修して良かったと強く思っています。
また、川口先生をはじめ先生方やメンターの方々もenPiTをよりよくしていくために様々な取り組みをしています。今後enPiTはどんどん良いものになっていくと思いますし、私もできることで協力していきたいと考えています。
というわけで、来年度以降受講したい人を全力で応援したいなと思っているので、お気軽にご相談ください。
最後に、ここまで超長文かつ拙文にお付き合いいただきありがとうございました！

この記事が気に入ったらサポートをしてみませんか？