自作サービスを作り切るためのフィヨルドブートキャンプの取り組み

:::message info これは「フィヨルドブートキャンプ Advent Calendar 2022」の19日目の記事です。 https://adventar.org/calendars/7760 今日は :@machida: machida と、:@GennyBoy: [GennyBoy](https://gennyboy.hatenablog.com/entry/2022/12/19/083821) さんが担当です。 昨日（18日目）の記事は、 - :@Paru: Paru さんの 「[Paruさんの2022年を一緒に振り返ってみよう〜😸 - Every day is a new day.](https://paru871.hatenablog.com/entry/adventcalendar2022)」 - :@masuyama13: masuyama13 さんの 「[近況報告（プログラマになって1年8ヶ月） - No Solution for Life](https://masuyama13.hatenablog.com/entry/2022/12/18/165230)」 でした。卒業生の近況が知れるのも Advent Calendar の楽しみの一つです。投稿ありがとうございます！ ::: 昨年の Advent Calendar では、[フィヨルドブートキャンプに「自作サービスを作る」という課題がある理由とフィヨルドブートキャンプの取り組み](https://bootcamp.fjord.jp/articles/41) という記事をアップしたのですが、昨年に引き続き今年も自作サービスについての記事をアップします。 この記事を書いている machida は、フィヨルドブートキャンプのメンターで本業はデザイナーです。主に、HTML や CSS に関係するプラクティス、自作サービスのペーパープロトタイプ、自作サービスのリリース前のデザインのレビュー、チーム開発ではプロダクトオーナーをやっています。 フィヨルドブートキャンプでは、卒業前の最後のプラクティスに自作サービスをリリース、というものがあります。プログラマーとして働いている方はご存じだと思いますが、自作サービスを「作ってみた」ではなく、「私が作った」と言えるまでのもの（これ大事！）になるまで作りきってリリースするのはかなり大変です。受講生のみんながサービスリリースまで到達できるようにメンターのサポートも色々と工夫をし、今も改善を続けています。リリースに到達するまでにフィヨルドブートキャンプやメンターは何をしているか、についての書いていこうと思います。 ## コードを書くのはまだ先 フィヨルドブートキャンプでは、自作サービスのプラクティスに入ったからと言って、いきなりコードを書き始める訳ではなく、いくつかのプラクティスを経た上でやっとコードを書く作業に入ります。 まず初めに、何を作るかを考え、それをエレベーターピッチという形で提出します。これが自作サービスの最初のプラクティスになります。次にペーパープロトタイプ作成、技術調査・検証、かんばんを作る（タスク登録）のプラクティスを行い、それらが修了になったところでやっと自作サービスのコードが書き始められます。（なので、自作サービスのプラクティスの一つ前のプラクティスであるチーム開発に入ったら、それが修了した後に手が止まらないように、チーム開発と同時に自作サービスの準備を進めておくのを推奨しています。） このような段階を踏むのは、手戻りを小さくするためです。 例えば、 - 自分で作ったサービスを使うより Excel を使った方が楽に問題を解決できた。 - ペーパープロトタイピングを行うことで、問題を解決するまでのクリック数や画面遷移数などの手間や時間が検証できるので、競合（Excel を使うこと）との比較ができ、それよりも便利になっていることを確認。 - 自分の抱えている問題をこのAPIを使えば解決できる、ということでサービスを作ってみたんだけど、そのAPIの提供元のデータが不十分で、せっかく作ったのに問題が解決されなかった。 - サービスを作り始める前に API の検証を行い、自分の欲しいデータが取得できるかを確認することで回避。 - スクレイピングを使おうと思っていたら、それは規約違反だった。 - これもサービスを作り始める前に利用規約を確認して回避。 などなど、完成目前で、「あれ？今作ってるサービスって存在する意味なくない？」と疑いを持ち始めてしまったら大変です。一気にモチベーションは下がり、手が止まってしまいます。 ## 一番大変なのはエレベーターピッチ 自作サービス関連のプラクティスの最初は、自作サービスの内容を考え、エレベーターピッチの形で提出するというものです。 自作サービスを作りを始める前に行うプラクティスで一番大変と言われています。なかなか提出したエレベーターピッチが通らないと受講生の間で評判ですが、この機会にエレベーターピッチをレビューするときに見ているポイントを解説します。 ちなみに、エレベーターピッチとは、エレベーターに乗っているくらいの短い時間で自分自身や自社のビジネスなどについてプレゼンする手法です。このプラクティスでは、30秒で説明できるくらい簡潔に自分の作るものを言語化する、というのを目的にしています。 フィヨルドブートキャンプの場合、簡潔であることはいいのですが、エレベーターピッチを話す人と、それを聞いた人の頭の中で同じものが浮かぶくらい具体的なものになっていることを求めています。そのサービスがいかに素晴らしいとか、そのサービスがいかに新しいとか、どれだけの人に役立つとかそういうのは削り、どんな問題をどのように解決するものを作るのかに絞りましょう。 すごくおしゃべりな営業マンとクールなエンジニアがいたとします。営業マンがこれから作るサービスについてエンジニアに熱心に長時間かけて説明したとします。エンジニアがそれを一通り聞き終わった後、一言、要するにXXXですね、と言いました。このXXXのようなエレベーターピッチをイメージするといいですね。 相手が投資家だったり会社の上司だったりする場合は、そのサービスはどれだけ需要があるのか、儲かるのか、なども見られると思いますが、フィヨルドブートキャンプのプラクティスでは、はっきり言ってそういうのは無視しています。最後まで作りきれるか？つまり、作ってる途中でこのサービスって作っても意味がない、と思わないかどうかを見ています。 - 解決したい問題は明確で具体的か？ - 解決策は問題を解決できているか？ - その解決策が別の問題を発生させてないか？ - 解決したい問題は本当に起きている問題なのか？サービスを作るために問題をでっち上げてないか？ - 解決したい問題はサービスを作らないと解決できない問題なのか？他の方法で解決できないか？ フィヨルドブートキャンプでは、以下のエレベーターピッチのテンプレートを採用しています。 - [サービス名] というサービスは、 - [解決する問題] を解決したい - [このサービスを使うターゲット（誰のため・どんなシチュエーション）] 向けの、 - [サービスのカテゴリー（サービスを一言で）]です。 - ユーザーは [このサービスでできること（問題の解決手段）] ができ、 - [サービスの競合（問題解決の代替手段）] とは違って、 - [差別化要素（代替手段ではなくこのサービスを選択する理由）] が備わっている事が特徴です。 以下のエレベーターピッチに必要なキーワードを挙げていくときのポイントを一つずつ解説していきます。 - サービス名 - 解決する問題 - サービスの競合（問題解決の代替手段） - このサービスを使うターゲット（誰のため・どんなシチュエーション） - サービスのカテゴリー（サービスを一言で） - このサービスでできること（問題の解決手段） - 差別化要素（代替手段ではなくこのサービスを選択する理由） ### サービス名 これはエレベーターピッチを提出する時点では仮で大丈夫です。気を付けるポイントとしては、探している人がググってたどり着けるか、英語の場合は英語として間違っていないか、くらいですね。例えば、「Apple」なんて名前を付けると、検索をしたときに Mac の Apple のサイトや、それに関連する記事などが引っかかって、このサービスにたどり着きにくくなってしまいます。ドメインを取る場合は、その名前を含んだドメインが空いているかのチェックもしておきましょう。 ### 解決する問題 これがすごく大事です。再提出をお願いする場合、この解決する問題が曖昧で具体的になっていなかったり、この後の「このサービスでできること（問題の解決手段）」ではここで挙げた解決する問題が解決されないことがほとんどです。 また、使いたい API があった、使いたい技術があった、作ってみたいサービスがあったらからと、作るものを先に出して、後出しで問題を出した場合は、そもそもその問題は起きていないことが多いので再提出になりがちです。 #### 範囲を狭く具体的に 範囲を狭く具体的にする、というのが大きなポイントです。 例えば、「英語が話せない」という問題は広すぎます。このサービスを使うことで英語が話せるようになったら、それで一つの会社になって大儲けをするほどの大発明ですよね。 もっと狭めて、「英語の発音が上手くできない」、という問題にしてもまだまだ広すぎます。さらに絞って、「英語の発音を上手くするためにシャドウイングをしたいが教材がない」、という問題までにしても、じゃあ教材をどこで集める？という新しい問題が生まれてしまいます。 実は YouTube を教材にシャドウイングの練習をしていました。でも、その際に「英語の発音を上手くするために YouTube の動画を教材にシャドウイングをしているんだけど、練習をしたい部分だけをリピート再生することができない」という問題が起きていました、までいくと、解決する問題は狭く具体的になってとてもいいです。この問題だったら自作サービスで解決できます。 この場合のいい点は、この後に解説しますが、すでに「英語の発音を上手くするためにシャドウイングをしたいが教材がない」という問題を「リピート再生できない」という問題を抱えながらも解決しようとしていたところです。実際に問題があった場合は、何かしらの最高ではない手段で問題を抱えながらも解決しようとしているものなんですよね。 もう一つ別の例を。 例えばグループでキャンプに行く場合、各自が持っていく物とは別に、グループで一つあればいい物があります。鍋とか、おたまとか、ライターとか。それを誰が持っていく？と担当を決めるのが面倒、という問題。 この問題をもっと具体的にしていきたいと思います。具体的にするにあたって、面倒とは、何が面倒なのか？が重要になります。このグループは担当を決めるときにLINEで会話をしながら担当を決めていました。 LINEで担当を決める際、 1. グループで一つあればいい物を挙げる 1. 誰が持ってきて、と発言をする 1. 私が持っていきます、と発言をする 1. ありがとうございます、と発言する 1. どれが担当が決まっていて、どれが決まっていないのかの途中経過を発言する の流れで担当を決めます。この中に「面倒」がありますね。面倒と一言で言ってしまうと解決したい問題も不明瞭になってしまいますが、面倒とは何かを具体的にすると、解決すべき問題も具体的になります。2 〜 4 が発生することが問題とした場合、 グループでキャンプに行く場合、グループで一つあればいい物を持ってくる担当者を決めるのに、担当を募りお礼を言い途中経過を手動で告知する手間が発生する問題 となり、具体的になります。 ### サービスの競合（問題解決の代替手段） これから自分が作るサービスは、当たり前ですがまだこの世には存在していません。ということは、最適な手段ではないのだけど、我慢をしながら自分が作るサービスとは別の方法で何とか問題を解決させている状態にあります。例えば聴きたい曲があったとき、今はサブスクで大体の曲は聴けますが、それ以前はインターネットで配信してくれたらいいのに、と思いながら CD を購入したり、レンタルをしていました。そんな感じで、自分のサービスがまだ存在しない今、満足はしていないながらもどうやってその問題を解決しているか？をここで挙げてもらいます。 先程の例で言えば、シャドウイングの方は YouTube にあるループ再生機能を使うになったり、キャンプの方は LINE のグループチャットで会話をしながら担当を決める、というのになりますね。 競合というと、同じ目的を持った別サービスを思い浮かべてしまうかもですが、そういうサービスがあったら大体上手くいかないです。というのも、こちらは一人で作る初めての自作サービスで、相手は何人もエンジニアを抱えた企業が運営しているサービスだったら勝ち目がないです。なので、範囲やシチュエーションを狭めることが重要になります。 Excel より便利な表計算ソフトを作るのは難しいですが、同棲をしている2人の間の支払いの割り勘を計算することに特化した計算機だったら、Excel で同棲をしている2人の間の支払いの割り勘を計算するよりも便利なものが作れるし、Evernote より便利なメモ帳を作るのは難しいですが、覚えたい英単語をメモするための単語帳なら覚えたい英単語を Evernote でメモするよりも便利なものが作れます。 #### 競合を探す際の注意 競合がすぐに思いつかない、初めて自分が挙げた問題の解決策の手段について考えた、という場合は要注意です。今までそれを考えなかったということは、自分が挙げた問題は実際には起きていない問題である可能性がかなり高いです。なくても困らないもの、あっても足しにならないものを作り切るのってモチベーションの維持がかなり大変なので、その場合は別の問題を考えましょう。 ### このサービスでできること（問題の解決手段） このサービスでできることを色々挙げたくなるかもですが、挙げるのは問題の解決手段だけにしましょう。シャドウイングの方は YouTube をループ再生できる、キャンプの方はグループで一つあればいい物のリストが作れて持ってくる人が自分に担当をアサインできる、といった形です。 シャドウイングの方は、他にも再生速度を変えられるとか、シャドウイングを行った日にはカレンダーに印が付くとか、メモを残せるとかの機能もありますが、それらを挙げていくと問題の解決手段は何なのかがブレてくるので省きましょう。 ### 差別化要素（代替手段ではなくこのサービスを選択する理由） 解決したい問題は競合でもできるかもしれないですが、それでも競合ではなく自分の作るサービスを選択する理由を挙げてもらいます。 シャドウイングの方は YouTube はシャドウイング以外にも使うので、YouTube にあるループ再生機能を使うには、都度ループ再生の設定をしなくてはないけないが、このサービスでは一度登録すればサービスを開く度に設定が保存されているので、サービスをブラウザで開けばすぐにシャドウイングを始められるのはこのサービスを使う理由になります。 キャンプの方は、途中経過やアサインのした人が出たら自動で LINE に投稿される、という機能なんかがあれば競合の LINE のチャットで会話をしながら担当を決めるよりもこっちを使う理由になりますね。 ### サービスのカテゴリー（サービスを一言で） これはそこまで重要視してはないのですが、一言で自分のサービスを説明する言葉を用意しておくと、自分がこれから作る巨大な壁の様に見えるサービスがコンパクトなもののように体感できます。また、そういう言葉を用意しておくとプレゼンのときにも便利だし、Web サービスのタイトルタグに入れる文言(検索のときに探しやすいワード)にも使えます。 シャドウイングのための YouTube ループ再生プレイヤー、キャンプの持ち物担当決めツール、英単語帳、カップルのための割り勘計算機、など。 ### このサービスを使うターゲット（誰のため・どんなシチュエーション） さんざん書きましたが、限られた人、限られたシチュエーション...ターゲットは絞りましょう。 例えば、シャドウイングのための YouTube ループ再生プレイヤーの場合、実際にはシャドウイング以外にも楽器の練習やダンスの練習にも使えてしまいます。でも、だからと言って、ターゲットを広げてしまうとサービスがブレてしまいます。サービスは作って終わりではなく、リリースをして使う人がいれば新たな問題や要望が出てくるものです。 シャドウイングで使っている人から、スクリプトを文字で表示して発音記号も表示してほしい、という要望があったり、楽器の練習で使っている人からは採譜の機能が欲しいとか、録音の機能が欲しいとか、自分の録音した演奏と YouTube を同時に再生したいとかの要望が出てくるかもしれません。機能の優先順位や取捨選択には絞られたターゲッティングが必要になります。 ### エレベーターピッチを考えるメリット エレベーターピッチでの重要視しているポイントを解説させていただきました。自作サービスプラクティスの必読図書になっている Basecamp 社の [Getting Real](https://basecamp.com/gettingreal) を合わせて読んでもらえるとより理解できると思います。 エレベーターピッチを考えるメリットは自作サービスだけではなく、チームでのプロダクト開発にも活かせるものだと考えています。チーム開発のプラクティスでは、僕がプロダクトオーナーとして、受講生が学習で使っている学習アプリ（[bootcamp](https://github.com/fjordllc/bootcamp)）の開発をしていますが、機能の一つ一つをエレベーターピッチで考えています。 例えば、フィヨルドブートキャンプの学習アプリに追加するペアプロの相手募集機能を考えるとき、今はペアプロの相手の募集をチャットで募集をするという形で運用しているので、これが代替手段になります。その運用ではどんな問題があって、その機能を学習アプリに実装する際はどのようにその問題を解決すればいいのかの解決手段が機能の仕様になります。 追加機能要望は取捨選択を迫られることになりますが、エレベーターピッチの形で問題と解決手段を整理し言語化することで自分の中でも取捨の選択がしやすくなるし、開発メンバーにも選択した理由の納得のいく説明に役立ちます。逆に自分が納得が行かない場合は、エレベーターピッチの項目の埋まっていない部分の説明をしてもらうことで考えの共有がしやすくなります。 ### 問題はフィヨルドブートキャンプでも用意しています 解決したい問題が思いつかないという人もたくさんいます。それを考えるのに時間を使うのは勿体ないので、フィヨルドブートキャンプで解決したい問題を用意しています。そっちの問題解決に挑戦するのもありです。 フィヨルドブートキャンプとしては、自分で考えたアイディアだから偉いという考えは持っていません。問題を解決できるものを世に送り出した人が偉いです。実際の仕事では、人の問題を解決することがほとんどで、あえて人の抱えている問題を解決するというのはその練習にもなります。人の抱えている問題をヒヤリングして、エレベーターピッチを作成したり、解決策の画面や仕様を考えるのもこれはこれでとても勉強になります。 ## ペーパープロトタイピングと技術調査 エレベーターピッチの解説で長くなってしまいましたが、もう少しだけ続きます。 エレベーターピッチの後は、ペーパープロトタイピング、技術調査のプラクティスがあります。 ペーパープロトタイピングは、紙に手書きをしたり、Figma などのツールを使って、自分の作るサービスの画面を描いてもらいます。これをすることで、問題解決までのクリック数や画面遷移数、登録する情報の数などがわかり、実際に問題解決するまでにかかる手間が可視化されます。その手間があっても競合より便利なのかの検証し、もっと手間を減らすために、この入力項目は削れるか、機能は削れるか、このページは削れるか、などを実際の画面を考えてブラッシュアップしていきます。 技術調査は、どの技術を使うかを決めたり、API を使う場合は、その API で問題は解決できるかの確認、規約違反にはならないかの確認、どこにデプロイするかなどを決めます。このプラクティスは主に komagata さんにレビューをお願いしています。 ## かんばんと自作サービス進捗報告会 リソース・データ設計のプラクティスを挟んで、コードを書く前の最後のプラクティスがかんばんを作るです。 かんばんを作るプラクティスでは、GitHub projects を使って[かんばん](https://ja.wikipedia.org/wiki/%E3%81%8B%E3%82%93%E3%81%B0%E3%82%93_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA))に 1st リリースまで必要なタスクを洗い出して登録してもらいます。作り始めてから気づいたり、発生するタスクもあるので、都度更新してもらいます。 自作サービス作りは長期間になります。早ければ1ヶ月、長いと半年くらいかかってしまいます。いくらしっかりしたエレベーターピッチがあっても、この間、モチベーションを維持し続けるのは難しく、気分が乗ったときにガーッと作って、また気分がノッたときまで手を付けない、というやり方をしているとなかなか完成しません。開発のリズムを作るために、自作サービス進捗報告会を週一で開催しています。この会では、かんばんの状態を画面共有し、今週やったことと、来週までにやること、悩んでいること、迷っていることなどを各自発表してもらっています。この会で週一の区切りを付け、開発リズムを作ってもらいます。 この会でかんばんに変化がないときは要注意で、タスクを大きくし過ぎていたり、タスクのゴールが明確でなかったりしている可能性があります。モチベーションを維持し続けるために、タスクをなるべく小さくし、ちょっとでも作業をしたらかんばんに反映されるようにしましょう。 例えば、自作サービスでは React を使いたいので、React の調査というタスクを登録したとします。これではゴールが明確ではありません。はじめは React を使って XXX ができるサンプルアプリを作る、にすればゴールが明確になります。React について学習を進めていくと、それを作るまでの手順もわかってくるので、タスクをどんどん細分化して、ばしばしタスクを完了できる状態にしましょう。 ## 自作サービスを作り切るための取り組み 以上が自作サービスの開発を始める前にやってもらっている、自作サービスを作り切るための取り組みになります。開発を始めた後も、CIの設定、デプロイ、デザインレビュー、コードレビューのプラクティスがあって、とかなり大変ですが、今まで学習したものの総復習ができ、さらにプラスアルファも勉強ができるので、自作サービス作りはお得です。（ぬるい現場の業務経験者よりよっぽど自作サービスをリリースしたフィヨルドブートキャンプ生の方がスキルを持ってると思うのですが、採用担当者の方どうでしょうか？） 昔は自作サービスを作る、という一つのプラクティスだったのですが、長年スクールをやっていく間に、途中のプラクティスを作ったり、自作サービス進捗報告会を開催したりなど、色々進化して今の形になってきました。受講生のみんなが「作ってみた」ではなく、「私が作った」と言える自作サービスをリリースできるスクールになるよう、今後も改善を続けていきたいと考えています。 ちょっと、僕と komagata さんが自作サービスを作るのが好き過ぎて自作サービス作りのプラクティスに熱が入りすぎている感もあるのですが、受講生のみんなが自作サービスを作ることを楽しんでもらえると幸いです。 :::message info 「[フィヨルドブートキャンプ Advent Calendar 2022](https://adventar.org/calendars/7760)」明日（20日目）の担当は、 - :@clio209: clio209 さん - :@karlley: karlley さん です。楽しみにしてます😄 :::