• プラクティス：どんなサービスを作るかを考える
• どんなものが良いか/ダメか
  • 自分が使うもの = 自分の問題を解決するもの
  • 「誰も使っていないもの」はこの世に存在していないほうがマシ
  • たくさんのユーザーが必要なもの
  • 途中で自分の作ってるものよりスマートな方法で同じ問題を解決している何かを見つけた場合、モチベーションはだだ下がり、自分も今作っているサービスのユーザーにならずに、そっちのユーザーになってしまいます。間違えに気づくのは早いほうがいいので、作る前に気づける調査は怠らないようにしてください。

📅4/6(水)の進捗報告会で↓の案を持って行って相談した

• machidaさん
  • 僕たちも、issue割振る時に、「今何ポイントですか？」って聞くのが面倒 & 気がついたら重いissueふってないうちに20ptいっちゃったってことがある
  • このへんの問題をずっと解決したいと思ってた
  • 忙しくてレビューできない人が、「今ちょっと忙しくてできないです〜」とか分かるといいですよね
  • エレベーターピッチの文言はちょっと変わるかもですけど、GitHubのAPIとか今から調べ始めたり進めちゃって大丈夫です
• 🤔 かなり好感触で、とくに鋭いツッコミもなく、嬉しかった。

テンプレート

[1.サービス名] というサービスは、
[2.解決する問題] を解決したい
[3.このサービスを使うターゲット] 向けの、
[4.サービスのカテゴリー]です。
ユーザーは [5.このサービスでできること（問題の解決手段）] ができ、
[6.競合サービス] とは違って、
[7.差別化要素（問題の解決手段の特徴）] が備わっている事が特徴です。

[1.Smooth Choice (仮)] というサービスは、
[2.PRのレビューを誰にお願いするか決める際、他の開発メンバーの状況が分かりづらいので決めるのが難しい問題] を解決したい
[3.フィヨルドブートキャンプのシステム開発プラクティスに取り組んでいる受講生のうち、開発メンバーの状況を知った上で誰に依頼するかを決めたい人] 向けの、
[4.開発メンバーの状況を見える化するサービス]です。
ユーザーは [5.開発メンバーがすでに持っているレビュー依頼や、マージ済のPRのポイント数など、開発メンバーの状況を知ること] ができ、
[6.GitHub]とは違って、
[7.フィヨルドブートキャンプのスクラム開発プラクティスに特化した情報] が備わっている事が特徴です。

解決したい問題

つい、作りたいものを考えてから逆算して解決したい問題をでっち上げてしまいがちがですが、それはやめましょう。無理矢理辻褄を合わせるために作った解決したい問題は、起きていない問題を解決しようとするものになりがちです。

解決したい問題の欄がAAAができない問題、AAAに手間がかかってしまう問題という形式になったら注意しましょう。この形式の文章全てが悪いわけではありませんが、AAAを作りたいとかAAAだったら作れそうから逆算してAAAができない問題を作り出している場合が多いです。

繰り返しになりますが、まず解決したい問題を考え、その後で解決策としてのWebサービスを考えましょう。

• レビュー依頼する時に、今の手持ちのレビュー依頼の負担が比較的少ない人にお願いしたい。けど、GitHubだと現状、自分にきてるレビュー依頼一覧は見れるが、openなPRのうち他のチームメンバーにレビュー依頼がいっているかの一覧は見る方法がない
• GitHubの機能では、「他の開発メンバーがもってるレビュー依頼の状況」がすぐにさっと分からない。自分にきてる依頼はすぐに見れる。
• レビュー依頼が同時に複数きた時、職場とはちがってメンバーが流動的に変わるのもあって、どれくらいの頻度で何個依頼がきたら”多い”といっていいのか迷う。他の人のレビュー依頼状況を一覧で見る方法がない(カンバンをしらみつぶしに開いて一個一個調べたり等)ので、自分が気持ち的にいっぱい来たと感じただけで、実際は他の人は自分が依頼されたのと同じくらいorもっと多くやってるかも...とか思うと「手持ちのレビュー依頼の数」を理由にして断りづらい。
• 何より、「私も自分がPRを作ったら誰かに見ていただかないといけない。お互いに協力しながら開発していかないといけない」と思うと余計に断りづらい。自分が断ったら他の誰かにレビューがいく。→ 負担を理由に断るんだったら、最初から誰がどのくらいレビュー依頼をもってるか見えたほうが良いのではないか?
  • 誰に依頼するか考えるのが面倒なので、ランダムに [Aさん,Bさん,Cさん].sample とかで決める方もいる。それは一理あるしなるほどと思うが、お願いした人にもってるレビュー依頼の数を理由に断られるのだとしたら(私は一度やったことがある) 、事前に、開発メンバー全体のレビュー依頼状況の一覧を見れれば「あ、この人は(他の人より)いっぱい持ってるからやめとこ」とか判断できるかもしれない。
  • チーム開発のPRは、スムーズにマージされることが目標だと思うので、依頼して断られるという時間が勿体無いことを考えると、レビュー依頼が誰にどのくらい来ているかはやはり大事な情報だと思う