enPIT2022をおえて

この記事は、2022年度の筑波大学のenPiTという授業でチーム開発についての個人レポートです。
以下の内容を中心に書いていきます。

• 開発したプロダクトの内容
• 開発したプロダクトの使い方
• チームメンバーについて
• 期間中の自分の主な役割
• 各スプリントの振り返り
• 期間を通した個人的振り返り

開発したプロダクトの内容

開発したプロダクト

• Gadeter

EVP

Gadgeterは、自分が持っているガジェットをどのようにすれば最適な配置にできるかを解決したい自分の理想のデスクトップを知りたい人向けのデスクトップ共有SNSです。
もっているガジェットのジャンル検索によって、デスクトップガジェットYoutuberの視聴、Pinterest とは違って自分の持っているガジェットから、別のレイアウトを提案してくれるプロダクトです。

既存の課題(悩み事)

デスク環境を一新させたいけど、何を買っていいのか分からない。また、自分が所持しているガジェットが他の人がどういう使い方をしているのか知りたい。

既存の解決策とその問題

• ガジェット系YouTuber

  • 1人のデスク環境しか知れない
  • 動画を見るのに時間がかかる
  • レイアウトの説明がほぼない

• Pinterest：「好みの画像・動画をあつめる」ことに特化したSNS

  • ガジェット購入リンクがない
  • 机のサイズが自分の物と違う

• ネットでデスクのレイアウト画像を調べる

  • デスクのサイズが分からない
  • デスク画像が多い
  • 画像中に気になるガジェットについて詳細をしれない

Gadeterの独自価値

• 自分の机のサイズで検索ができる
• ガジェットのジャンルから様々な配置がわかる
• 気になった商品のURLがわかる
• ガジェットを実際に机に置いた状態を可視化できる

開発したプロダクトの使い方

完成したシステムは、ここから使えます。

0.TOPページ

この画面では、下にスクロールすることでデスクのデザイン案として登録されている画像を一覧で見ることができます。

1.ガジェットのジャンル選択

TOP画面の画面上部のプルダウンからガジェットのジャンルを選択してください

2.デスクのサイズ選択

TOP画面の画面上部のプルダウンからデスクのサイズを選択してください

3.検索ボタンをクリック

ガジェットとジャンルが指定されたら検索ボタンをクリックしてください

4.該当する検索条件にあったデスク画像と商品URLが出てくる

リンクをクリックすると、商品のamzonでの販売画面が表示されます

チームについて

このチームは、夏のenjoy勢と龍郎があわさってできたチームです。
メンバーの構成としては、院生3人、学群生3人の構成でした。
院生が多忙でなかなか全員が揃わないので、前回の進捗共有の時間を開発前に多く取ることで、今の進捗となぜそうなったかなどの認識をすり合わせ誰一人置いていかないようにしました。

自分の主な役割

私は、このチームでPOを担当しました。
POとして自分で意識して行ったことは、プロダクトの方向性を論理的に決める、議論の際に一部の人の意見で決まらないようにする、議論のときに議題から逸れないようにする。この三点を意識的に行いました。
開発面では、Djangoの指示出しとDB設計を担当しました。
Djangoは、enPIT自己学習期間とそれ以前に使用したことがありました。自分がコードを積極的に書く選択肢もあったのですが講義の意義を考えて、基本的には機能を実装するために参考となるページをドライバーに提供することやエラー時のデバッグを担当しました。
DB設計は、秋にデータベースの講義を受けていたので講義を踏まえて設計しました。特に、ガジェットのジャンルは画像を追加する過程で増える可能性があるので、ガジェットのジャンルの選択肢の変更に対応できるような設計を行いました。

秋学期各スプリントの個人的ふりかえり

各スプリントの振り返り10月

夏までに活動していた二つのチームの合体ということもあり、コミュニケーションに問題はなく活発な議論が出来ていました。夏までにそれぞえのチームが行っていたプロダクトを続けるのではなく新しいプロダクトを行おうと決まりました。
　　　　　　

　　　　　ミテルゾのEVP

ミテルゾは、webカメラを設置してデスク上の散らかり度スコアを算出して、散らかっている場合には掃除を促すwebアプリを作ることにしました。
しかし、チームとしてレビューより開発に重みを置いていたため、レビューの準備が十分に出来ないままレビューを迎えることがありました。そのため、自分たちの作ろうと思っているものを適切に伝えることができないため、レビューする側はレビューすることが難しく、自分たちとしてはレビューが的外れなものが多いと思っていました。このように、双方にとって悪循環に落ちいてっていました。

各スプリントの振り返り11月

このスプリントでは、前スプリントでレビューの質が低かったのは自分達のレビューに問題があると考えレビューを重視するようになりました。そのために、「事前に質問を考える」、「デプロイを優先しユーザに触ってもらう」 を施策として行いました。その結果、前スプリントに比べて質の高いレビューをもらえるようになりました。
しかし、ある問題が露呈しました。それは、掃除の促し方です。我々のターゲットは、掃除をサボりがちな一人暮らしのユーザーです。対象のターゲットは、机が散らかっていても気にしないのでただ単に掃除をするように促しても効果は薄いと考えました。そこで、「Discordに写真を送ってもらって汚れ度を返信する」「Twitterに晒す」などを行ったのですが、上手くいきませんでした。なぜ上手くいかないかを話しました。それが、以下の価値検証の結論です。

価値検証の結論
ユーザーが求めているのは、自分の机の上の片付けのモチベーションを上げるプロダクトではなく、自動で片付けてくれるシステム

つまり、開発初期の開地検証と問題の深掘りができていないことにより問題解決のアプローチがよくないという結果になりました。

各スプリントの振り返り12月

このスプリントにプロダクトを変えました。プロダクトを変更した一番大きな要因は、困りごと(部屋がすぐ汚れる)に対しての促しのアプローチが適切ではないことと、今後適切なアプローチを思いつくと思えなかったからです。ミテルゾ(前回のプロダクト)で自分たちは、このアプローチが適切と思って価値検証そっちのけで機能の実装を優先しました。いざ機能ができて自信満々でレビューに望んだのですが「そのアプローチでいいの？」という意見が多く、かなり凹みました。こうなった原因は、「価値検証のための最小の実装を考えて入れなかったから」 だとチームでいきつきました。次のプロダクトは、デスクの汚れ度を測定するための画像を見て、「人のデスクを見るのって面白い」というメンバーの声をもとにプロダクトを考えました。(個人的には、思い入れのあるプロダクトだったのでプロダクトの変更は辛かったらのですが、「価値検証のための最小の実装を常に考える」という意識改善ができたのでその点は良かったと考えています。)
このプロダクトでは、価値検証を各スプリントで行いながらユーザの価値を念頭に置いてPBLを何度も修正しました。また、ユーザーを絞り込むことで限られた時間での開発を効果的に行いました。このプロダクトは、ガジェット共有SNSです。そこで利用者を　2つに分けました。一つは「ライト層」もう一つは「ヘビー層」です。デスクのレイアウトが気になるのはライト層に多いと考え、ライト層向けの機能をenPITでは実装することにしました。(ヘビー層向けは自分のデスクの投稿などの機能です)

第 1 段階 (価値検証)

前プロダクトの反省から、なによりもまず価値検証を行いました。価値検証のために複雑な実装をするのではなく、価値検証のための最小の方法は何かを考えるようにしました。一番初めは、miroでWOZ法を使って、デスクのレイアウト画像にタグが付いている方がいいかどうがの価値検証を行いました。その結果、画像に商品タグをつけるようにしました。

第 2 段階 (価値検証)

実際にデプロイしてユーザに使ってもらいどのような機能があったら良いかというものを調べました。その結果、ジャンル検索の表示方法や、デスクサイズの指定があった方が良いなどのフィードバックをもらいました。

第 3 段階 (ジャンル検索)

フィードバックを元にガジェットのジャンル検索ができるようになりました。
ジャンル検索をボタン選択でできるようになった

第 4 段階 (ガジェットのリンク)

デスク画像のガジェットのURLをリストで知れるようになりました。

第 5 段階 (机のサイズ)

机のサイズから検索できるようになりました。

各スプリントの振り返り1月

このスプリントでは、DBにデータを追加する作業、デプロイ時のエラーのデバッグを全員で行いました。
また、スライド作成などに注力しました。

期間を通した個人的振り返り

• 開発では、デプロイが一番大事
• 価値検証のための最小の実装を常に考える
• 損切り
• モブプロは限定的

開発では、デプロイが一番大事

我々のグループでは、デプロイにかなり時間と労力を取られました。機能はできているけど、デプロイ環境だとうまく動かないことが多々ありました。また、前述したように実際にユーザーに触れるものを提供できないのでユーザーがプロダクトのイメージがしずらくレビューの質が低くなることです。レビュー早い段階で、CI/CDの仕組みを作れていたら限られた100分の時間を有効活用できたと思っています。

価値検証のための最小の実装を常に考える

前述したように、一つ目のプロダクトが価値検証を十分行う前に機能の実装を行なったため、実装後にそもそも問題に対するアプローチが違うのではないかという話になりました。その経験から、価値検証のための最小の実装を常に考えるという学びを得た。例えば、Gadterでは実装する前にDiscordやmiroで価値検証を複数回行った。価値を検証するためにいかに最小の実装がで済むかを、メンバー内で何度も議論した。このように学びを得るだけでなく実際に行動に移せたのは更に良かった。

↓実装前に価値検証のために行なったWOZ法

損切り

講義外でプロダクトを作るならいくらでも期限を先延ばしにしてやりたいことをできるのですが、講義内の限られたリソース　（時間的にも、労力的にも）の中では、ときとして価値のないプロダクトから新しいプロダクトに変更する必要があると考えています。しかし、頭でわかっていても自分の作ったプロダクトなので、どうしても愛着が湧きました。今回はプロダクトをミテルゾからGadeterに変更する際にも同じような状況に陥りました。そこで、感情的ではなく論理的にチーム内で話しました。

モブプロは限定的

(個人的な意見)
我々のチームでは、モブプロをよく行ったのですが個人的な感想は有効的に使えていないなと感じました。
効果的に使えた場面としては、プログラミングのアウトプットやプロダクトの初期にわかっている人がわからない人に教える場面では、効果的に使えました。
一方で効果的でない場面としては、開発がある程度進んでいる状態やメンバーの休みなどが多い場面では効果的ではないと感じました。特に私たちのグループではメンバーが揃わず入れ替わりが多かったです。そのため、コードの説明に時間がかかったり、お互いのプログラミングに関する知識を正確に測ることができませんでした。特に、相手の理解度がわからないので、ドライバーが実装のためにどのくらいの情報や説明が必要かを考えるのが困難でした。そのため、情報・説明の粒度が細かすぎたり、荒すぎたりして場合によって時間が多くかかることがありました。

最後に

最後まで文章を読んでいただきありがとうございます！
POとしての役割を果たせたかというとそうでもないなという感じでした。自分自身、ミテルゾからGadeterに早い段階で変更する。もしくは、課題の深掘り、価値検証の意識をもっていれば満足のいくプロダクトが完成したと思っています。しかし、議論の際に意見を出せていない人に指名して話をふったり、意見が逸れそうな時に今までの話の経緯をまとめて議題を再確認させることを意識して心理的安全性を保てたのは良かったです。最後に、enPITをやらなければ得られなかった考え方(ものづくり、デザイン、価値)をたくさん学べたのですごく有意義な講義でした。特に、院生の方と同じ講義を受ける機会はないのでとても刺激的でした。