私はソフトウェア開発手法の 1 つであるアジャイルや、ユーザ目線でのプロダクト開発手法などを学ぶ enPiT の講義を 1 年間受けてきました。
講義で「注文の多い料理店」のオーナー（プロダクトオーナー）を 1 年続けてきたのですが、講義としてはこれで終わりとなり、半年間(通算 1 年)の開発期間も一区切り、という訳で、料理店から「退職」するまでをまとめます。
春: れしぴコンパス
春学期の合宿では、れしぴコンパスというものを作った。 エレベータピッチは以下の通りである。
[れしぴコンパス]は[楽にレシピを決められ、楽に料理したい]を 解決したい [自炊をしている大学生]向けの [レシピ検索サービス] です。 これは [食材や調理法で検索する] によって、 [レシピ共有サイト、リンク集や、まとめ記事] とは違って [楽なレシピを短時間で決められる] を実現できます。
レシピコンパスは食材名からレシピを検索する Web サービスである。 Heroku で動かしていたので、このれしぴコンパスはもう動いていない。 ソースコードはここから見ることができる。
確か、アイデアの段階では、
- つくばのスーパーには、一人暮らしの大学生には量の多いほどの野菜が入っているよね
- 6 限が終わってから料理を作るのってやる気が起こりにくいよね
といったような話が出ていた。
そこで、レシピ検索サービスの中でも、食材をいかに簡単に調理できるかという部分に焦点を当ててプロダクトを作ることとした。 冷蔵庫にある大量を食材を消化するにはどうすればよいかをチームで考えた結果、レシピ名ではなく、食材名でレシピを検索する方法がよいのではないかということで、食材名で検索するシステムとした。
次に、cookpad やクラシル、delishkitchen などレシピ検索サイトは今やかなりの数あり、これらを横断的に検索したいという話も挙がった。
3 つ目に、楽に調理できるレシピでは豆板醤などあまり使いどころがなさそうな調味料がよく使われるという話が挙がり、食材で検索しつつも使わない食材を含むレシピを省く機能も必要だという話になった。
秋: cook りさん
エレベータピッチは以下の通りである。
[cook りさん] は [飽きずに冷蔵庫の食材を使い切りたい]を 解決したい [自炊するものの買い物に行くのが面倒な大学生]向けの [レシピ検索サービス] です。 これは [最近作ったレシピや家にない食材をはじくこと] によって、 [レシピ共有サイト、まとめ記事、検索エンジン] とは違って [今ある食材の中でバリエーションに富んだレシピを提案できる] を実現できます。
cookりさんはレシピを検索できる Web サイトで、様々なレシピ掲載サイトを横断して検索することができる。 また、使いたい食材名を選択して、レシピを検索する。 GitHubはここにある。
スマートフォンで検索することを想定したため、できるだけキーボードを使わず、タップだけで検索が完結できるようになっている。
これは最終報告会で用いたスライドである。 個人的にはグループでやったことを「オペレーション」と書こうといったギルドくんの発案や、なおとくんのロゴにネコがあったりと、スライドに世界観が詰め込まれていてとても好きである。
世の中には沢山のレシピ検索サイトがある。しかし、cookpad やクラシルなどには他社のサイトを横断して検索できない。
ここで、横断検索するには Google などの汎用検索エンジンを使えばいいじゃないかという話が上がる。実際、春学期のユーザインタビューでもそうやっている人はいたし、秋学期でもレビューで質問されることは多かった。
しかし、Google は、論理演算を演算子を用いて検索することができるが、それらは正しく行われていないという話を講義で聞いた。
そのため、cook りさんでは、テキストボックスでをもう 1 つ追加して表示することにより、見えやすい形で表示するようにした。
夏の発表会で、教員に「無いものを列挙することはできない」とデモをする時間で指摘された。 このアドバイスがもとになって、秋では省きたい食材を検索後に指定する方法に変更した。
使い方
このcookりさんは、スマートフォンでの利用を想定しているのでスマートフォンでアクセスしてみてください。
まず、サイトにアクセスします。
次に使いたい食材を選択して（1）、「検索」ボタンを押します（2）。
「検索」ボタンを押すと、検索結果ページへ飛び、レシピが表示されます。
「全ての食材を使う」のタブには、検索条件に加えた食材を全て含み、省きたい食材を含まないレシピが表示されます（3）。 対して、「一部の食材を使う」のタブとタップすると、使う食材として加えられた食材を1つでも含み、かつ、省きたい食材を含まないレシピを表示します（3）。
画面上部に表示されている2つのテキスト入力部は検索条件を表し、上が含めたい食材、下が省きたい食材を表しています。
この検索結果ページのレシピ名の下には、このレシピで使っている食材名書かれたのボタンがあります。食材の書かれた灰色のボタンを押すと、その食材を含むように検索条件が変更されます（4）（ページ上部の赤色の「検索」ボタンを押すと検索条件が適用されます）。さらに、含みたくない食材には灰色のボタンの隣にある赤色のマイナスのボタンを押します（4）。
また、既に検索条件として画面上部のテキストボックスに追加された食材は、再度ボタンを押すことによって検索条件から解除されます（4）。
レシピ名をタップすると、レシピを掲載しているサイトに飛ぶことができます。
ネーミング
夏合宿では、時間がなくて捻った名前が出なかったのでオリジナリティのある名前にしたいと思って提案した。 小学生の頃によく耳にした怪談？のこっくりさんのように誘導されるようにレシピを決めたいというニュアンスと、料理するの cook を掛け合わせたものとして提案した。
メンバー
秋も 5 人で開発した。
- 私(Nakaya) プロダクトオーナー。優柔不断。
- ギルドくん テックリード。最終発表会のスライドの発表などをやってもらった。タイムキーパー、議事録管理まで。
- くまさん、miro の共有をいつもやってもらってた。モブプロのドライバーを積極的にやってもらってた。夏のチームが解散して秋から参加したメンバー。
- なおとくん、デプロイ担当。講義で 1 回は「ありがと~」を聞く。
- orii さん。スクラムマスター。時間管理やプロダクトをやってもらってた。夏のチームが解散して秋から参加したメンバー。
先に出してたチームメイトのレポート見ていると、メンバーにアジカンのファンがいたっぽかったので、音楽の話をしてもよかったなと後悔。
スプリント 1
このスプリントで行ったことは以下である。
- EVP を再構築
- 環境構築、HTML のデプロイ
- レシピを 1 枚の HTML に表示する
- 検索画面を作成し、検索結果ページに飛ぶようにした
特に書いておきたいことは 3 つある。 1 つめ に、スプリントを回す直前の EVP を練り上げる時間で、スカスカの EVP を作ってしまい、レビューではツッコミがかなり入った。 そもそも、自分達(少なくとも私)は納得の行くものではなかった出してしまったようにも記憶している。このときは、みんなが使えるものを、という考えで EVP を作っていた。 そのため、 1-1 では開発をそのまま初めるのではなく、もう一度、春学期にやったリーンキャンバスやユーザストーリマッピングをやり直すなど、根本から考え直すことから始めることにした。 その中で自炊生活が十人十色であることを認識し、全員も持つ全ての困りごとが解決することは難しいことがわかった。 例え、全員も持つ全ての自炊に関する困りごとが解決できなくとも、アイデアの中で「これ!」と思ったものを決めようということで、上記の EVP にした。
2 つ目に、ギルドくんと夏合宿の反省として、私たちはチームの中でも話しすぎて、心理的安全性を下げているのではないかという話が出ていた。 ので、この当時はギルトくんがテキストで会話に参加するという方式を取っていた。 正直かなり焦りがあって、この期間はチーム内ではピリピリとしていたように思うし、自分自身先行きに不安を感じていた。
最後に、環境構築やデプロイの面では以下のように決まった。 heroku 廃止に伴う移行先検討を行い、https://deta.shと FastAPIを使うこととした。 開発で使うフレームワークやプラットフォームと、EVP が決まったので、環境構築を行った。 ここで、意識したのは全員で構築するということであった。
ロングレビュー 1
EVP の再検討をこのスプリントの最初でやったため、他の班より遅れていたのもあったのか、それともレビューに対して準備が万全ではなかったのか、このときのロングレビューはボロボロであった。
この時点では、機能はできていても、見せたものが作るユーザの体験というものが見えにくいものであった。 特にスプリント 1 の最後に作った検索画面と検索結果ページのリンクを作るということはできたものの、それらを繋いで何を体験させたいのか、という観点に欠けていたように思う。
それが原因なのか、ユーザが混乱してしまいお互いに有益な時間にならなかったのではないかと今になって思う。 レビューの時間はプロダクトを価値あるものにするためには必要なので大事にしなければ、と思った。
また、指摘された問題をレビューの見せ方や、見せられるものがまだ完成していない、など他にも原因が考えられうるにも関わらず、コアな部分に問題があると捉えてしまった。
この問題に関しては、チーム内でも配信について対立があった。 このまま進めるべきという意見と、再度 EVP を練り直すべきであるという意見である。最終的にはメンターの方やメンバーの意見に従ってこのまま進めてみようという話になった。
ふりかえりに白い六角形をもってきたのもこの回からだった。判断が遅いズ!が導入していたのも勝手にパクってこんかいの授業でよくなかった点への改善点(TRY)を書くために導入した。
加えて、ロングレビューでもまだ作りたかった UI がチーム内でも固まっていなかった。
スプリント 2
スプリント 2 で行ったものは以下である。
- Figma を使ったプロトタイプ作成
- 食材から検索
- 複数の食材でも検索できるようになった
- レシピを手動で追加
まずおこなったこととしては、 Figma を使って作りたい UI を考えることであった。 ロングレビューの時点でも、作りたかった UI がチーム内でもまだ固まっていなかった。 大まかな方針としては、スマホに最適化された UI/UX にしようという方針は決まっていたのだが、細かい部分が決まっておらず、なあなあになっていた点をロングレビューで実感させられた。
ロングレビュー 2
後半のロングレビューよりかは準備が万端であったとは言えなかったものの、ユーザに対しての質問にはしっかりと答えられるようにはなった。 具体的には、日本語の細かい表現で誤解を生むなどの問題があったが、Figma で未来予想図を見せるなどして理解してもらうことができた。
また、レシピ数の少なさが問題になってきた。 それまでの検証したいこととして、見せ方の問題でなんとかなるであろうという話だった。 しかし、次郎メソッドから脱却してくると、掲載しているレシピの少なさが問題に上がるようになった。 これまでは手動で収集して掲載していたが、自動で収集したいという話が挙がった。 しかし、クローラを作成するのは、PBI としてこれ以上分割不可能で、かつ重い PBI であるという話になり、作らなかった。 結果としては、チームとしては作らず、スプリント 3 の途中でギルドくんが作成したクローラで得た結果を挿入することになった。
このロングレビューで得られた一番大きな成果は、ある程度の自信を掴むことができるようになったことだと思う。 これによって、チームの雰囲気もこのロングレビュー以降は明るくなり、黙ったままの状態から抜け出せたようになった。
スプリント 3
このスプリントでやったこととしては以下である。
- トップページの「食材から検索」
- 「省く食材」を指定した検索
- 検索結果ページの食材名をタップすると検索条件を変更できるように
- 既に追加されている検索条件をボタンを押すと消せるように
このスプリントの中で特に記憶に残っていることは以下の 4 つである。
まず 1 つ目に、レビュー内で教員のアドバイスとして、以下のようなフィードバックをもらった。
レビュアに機能ツアーして説明するんじゃなくて，レビュアに困りごとが解決する様を体験させてください
我々は、機能ツアーと体験の違いを理解できていなかった。 前者は「このボタンを押すと、~となります」というを解説するものであった。 一方、後者を実施するようなってからは、EVP などから前提を話すことから始めるようにした。 「今日の夕食を作ろうという状態を想像してください。ここで cook りさんを使ってみましょう。実際に冷蔵庫を見てみましょう。キャベツと人参がありますね。では……」のように実感の湧きやすいようなレビューになった。
2 つ目に、リリースノートとして提示できるようにとプランニングの時間の間に PBI を書き変えることも意識的に行った。
3 つ目に、落ちついてきたところで、時間の管理の問題について取り組むようになった。 この段階で、仮説の根本の部分に関してツッコミが入ることが少なくなった。 時間の管理の問題をどうするかを振り返りで考え、改善させてることができた。 スプリントプランニングで TODO1 つ 1 つにどれくらいの時間がかかるかを見積もり、それをカンバンに書き込めるようにしたり、時間計測をどのようにすればよいかを振り返りで考えるなど時間について話す機会が増えた。
4 つ目に、この期間では複数の食材を入れて検索する機能を実装した。 これは、少し実装が難しかった。 そのため、全員が理解できるようにわかった人が解説するとっいったことを 1 つ 1 つ行った。 他にも JavaScript を使って食材名をタップのみで追加する機能を実装したが、JavaScript を触った経験がある人が少なかったのもあって、その部分の解説などもチームで行えた。
ロングレビュー 3
ロングレビューでは、以下の項目が挙がった。
- 「省く食材」を選択した際にすぐに検索に反映されてほしい
- 「豚バラ肉」「鶏むね肉」などの複数の検索条件を入力した際に双方を含んだレシピではなく、どれか 1 つでも含めば検索結果として含んでほしい
スプリント 4
最後の仕上げをがんばろうという矢先、何が重要でどれを実装するべきかという点で開発中にチームで議論になった。 次のスプリントでこのスプリントで鳴にをするべきかについてを議論するために、絵文字で投票したり、付箋で意見を出す時間を設けたりした。
これは、心理的安全性を考えた取り組みだった。
別の講義で、議論で意見を出すのではなく、付箋を出し合うほうがよいという話を聞いて取り入れた。 その結果、チームメンバーの意見が以前より活発になった。
以前要望として出てきた「『豚バラ肉』『鶏むね肉』などの複数の検索条件を入力した際に双方を含んだレシピではなく、どれか 1 つでも含めば検索結果として含んでほしい」という問題を解決した。そのために、完全一致、部分一致を tab として表現することとした。
ロングレビュー 4
ロングレビューでは、以下の項目が挙がった。
- レスポンスが遅い
- Safari 対応
レスポンスが遅いだが、検索アルゴリズムでは python の set 型と list 型を行き来するような実装になっているので、型の変換に時間がかかっていそうだとか、Database を使わず、JSON ファイルにレシピのデータを保持し読み込んでいるからではないかなどの話が挙がった。
後日、実際に使ってみてもレスポンスが遅いと感じたので改善は必要だと感じた。
期間を通した個人的ふりかえり
「とりあえず手を動かせ」
チームでは議論をしていて、煮詰まるとそのまま黙ってしまうことも多かった。 例えば、スプリントを回す前の EVP 考案などである。 考えることがいいことだが、煮詰ってしまっては議論や開発が前に進むことができない。
そのようなことがあって、ギルドくんが「とりあえず手を動かせ」という話をしていたのが強烈に心に残っている。 ある程度のことが考えれば PBI の優先度などはわかるかもしれない。しかし、手を動かして実装して、実際にレビューしてもらう。そうしなければわからないことだったある、ということを感じた。
チームの行動以外にも、私自身の行動にも刺さる部分があった。 私は石橋を叩くだけ叩き、飽きて渡らないような頭でっかちなことを繰り返してきたように思う。 ある程度叩いて問題なかったら渡ってしまう勇気みたいなものが必要だと感じた。
「プロダクトオーナーは課題を愛する」
これ他にも、
PO は最も身近な顧客
という話もあった。 これらは、メンターや受講者の方が言っていたことだ。
開発、特に誰かに刺さるものを作るためには、情熱が必要である。 情熱は課題を愛せることができなければできないという理屈は、衝撃を受けた言葉の 1 つであった。 実際に、秋の終盤では実生活で使ってみる機会を何回か作れたことはよかったかなと思った。
プロダクトオーナーは顧客の意見を鵜呑みにするのではなく、取捨選別する
メンターの方のこの言葉にはっとさせられた。
PO の仕事はねーーニコッとステークホルダーのいろんな話を聞いて頷きながら、程よく無視することですよって聞いた
また、一回目のロングレビューではツッコミどころの多い発表をしてしまった。 メンターの 1 人は「PoC がまだできてない」(注: Poc: Proof of Concept)という話 「自分達を貫け」
そもそも enPiT ではユーザである人ない人の区別を付ける必要もあった。 そして、私はフィードバックのすべてを鵜呑みにして PBI の優先度を決めてようとしていた。なので、フィードバックを取捨選択する能力はまだまだだったように思える。
「ユーザーは無能である」
これは秋学期のスプリント中盤頃にメンターの方に言われたことである。 この頃は、「この機能はどうしてほしいですか」とレビュー時にオープンクエスチョンで顧客に対して質問していた ユーザは無能であるというメンターさんの話は印象的だった
その後に教員に
レビュアに機能ツアーして説明するんじゃなくて，レビュアに困りごとが解決する様を体験させてください
と言われてから、レビューとの向き合い方をようやく理解できたように感じた。
PBI は小さく
夏合宿では、最初のスプリントで PBI が大き過ぎて、受け入れ条件を満たすことができなかった。
それから、PBI を最小単位にまで分割できないかということを、しつこいまでに主張にするようになった。 この経験から、技術的にしっかりとしたサービスを作ることはユーザにとってあまりにもどうでもよいことで、自分がどういった経験を受けられるのかということに興味があるのだなと体感した。
その後は、次郎メソッドから初めることにした。 HTML 1 枚からでもレビューの作り方によっては検証はできる。 まずは HTML1 枚から初めて、枚数を増やしていき、最終的にデータベースを使うなどの段階を踏んだ機能の実装を意識することができた。
PBI の優先度の方針
秋の初盤に、レシピを作った最終の日を記録しておけば、EVP で触れていたレパートリーを増やすことがでいるのではないかという話をしていた。 最初、PBL で夢としても決めていたが、完全に失念していたのもあり、最終的には作らなかった。
途中から、UI の修正などの部分を優先度の高い PBI としたのは間違いだったように感じる。 つまり、UI よりからよりも大きな機能を体験してもらうべきだったように思う。 そして、最後のスプリントで UI の修正などをするべきだった。
議論の時間における発散、収束の意識
夏も秋も、PBI レファインメントでどのように実装するか、などの話が盛り上がって、時間が足らなくなることが多々あった。 つまり、議論が発散しっぱなしだった。
しかし、秋学期の後半では時間が迫ってくると、「それじゃあどうするか」みたいな声を掛けることができるようになり、時間が迫ってくると発散させていたものを収束させることができるようになった。
おわりに
成果報告会では、優秀賞をもらうことができた。 周りのプロダクトの完成度や、周りのチームの取り組みがユニークかつ完成度が高かったので、正直な所、賞がもらえると思ってなくて、びっくりした。 開発期間ではウジウジ悩むよくない PO だったし、PO として開発をどう進めるべきかがわからず何度も悩んだが、ここまで来られてよかった。チームのみんなには感謝です。
「退職」と書いたけど、辞める気はさらさらない。 自炊に関する困り事は永遠の課題のような気がしているので、講義の場か無くなっても、今後もまだまだこのチームで取り組んでみたい。 みんな卒研などで忙しそうなので厳しそうだけど、作り直してハッカソンに出てみたいな……と思っている。
