転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。
ポートフォリオの題材を決める過程で、まったく同じ構造の間違いを2回しました。
2回目に入りかけたとき、1回目と同じ形だと気づいて止まりました。
どちらも「作らなかった案」の話ですが、2回間違えたおかげで判断軸が1つ増えました。
1回目: 身近な人に使ってもらう前提のアプリ
最初に考えていたのは、家庭菜園の記録アプリでした。
選んだ理由は、身近に実際に使ってくれる人がいることです。
自分ひとりのために作るアプリより、実際のユーザーからフィードバックをもらえるほうが強い。
そう考えていました。
崩れた理由は単純でした。
その人が日常的にアプリを使うとは限らない。
紙のノートで済ませているなら、そちらのほうが速い。
入力の手間をかけてまでアプリに移る動機がありません。
つまり、最大の強みとして数えていた「実ユーザーのフィードバック」は、
相手が使ってくれた場合にだけ手に入るものでした。
使われなければ、武器そのものが消えます。
前提頼みでした。
2回目: クライアントが承認ボタンを押す前提のアプリ
次に考えたのが、見積を作ってクライアントに共有するアプリでした。
主軸に据えたのは「クライアントが共有 URL を開いて、承認ボタンを押す」機能です。
承認の記録が自動で残る。
そこが売りだと思っていました。
これも同じ場所で崩れました。
クライアントは承認ボタンを押しません。
実際には、メールやチャットで「OKです」と返ってきます。
それが普通のやりとりで、こちらの都合でボタンを押してもらう理由がない。
さらに「相手にアカウントを作ってログインしてもらうのは手間ではないか」という指摘もありました。
そのとおりでした。
前提そのものが怪しくなりました。
共通していたのは、依存の方向だった
2つ並べて、ようやく共通点が見えました。
同じ形でした。
どちらも「他人の行動」に依存する機能を、主役に据えていました。
しかも題材を選んだ本当の理由は、どちらも「自分が毎日使う」でした。
使う人が自分だから続くし、要件も自分で分かる。それが選定理由だったのに、
説明のときになると「他の人にも使ってもらえる」のほうを前に出していました。
付加価値のほうを主機能にしていた、という言い方が近いと思います。
個人開発では「使ってもらえる人がいる」を強みとして数えたくなります。
ただそれは、相手が動いてくれる前提の上に乗っています。
主役に置くと、前提が外れたとき何も残りません。
ゼロです。
直したのは、依存の向きだけ
2回目の案は、設計をこう変えました。
- 共有 URL は閲覧のみ。相手は開くだけでいい
- 承認は自分が記録する（「電話で承認をもらった」と入力する）
- 承認ボタンは、押してくれたら自動で記録する。押されなくても成立する
機能の数はほとんど変わっていません。
依存の向きを変えただけです。
そのうえで「なぜ URL で共有するのか」を考え直したら、答えも変わりました。
相手のためではなく、自分の手間を減らすためでした。
PDF を作り直して再送すると、どれが最新か分からなくなる。
URL なら中身を更新するだけで済みます。
「手間をかけさせない」も設計の説明になる
この直し方をして分かったのは、
「ユーザーに手間をかけさせない」という判断そのものが、設計の説明材料になることです。
「相手にログインさせる前提で作りました」より、
「相手の行動には依存させていません」のほうが、説明として強い。
機能を減らしているのに、説明できることは増えていました。
結局この案自体は、別の理由で取り下げました。
いま作っているのは、自分の発信を1箇所に集めるサイトです。
外部から自動でデータを取ってきて並べる作りなので、
他人に何かをしてもらう前提の機能が、構造的に1つも入りません。
2回間違えたぶんの判断軸が、題材を選ぶ段階で効きました。
3回目はなし。
