【ポップコーン開発日記】2024年12月3日（火）

やかんです。

ポップコーン開発は前向きに取り組んでいますが、生活を支配されたくはないです。とりあえず今日は

• 数値解析レポート着手
• 最適化手法レポート着手
• 筋トレ

あたりはしっかりやりたい。時間にして2時間はかかるよな。意地でも確保したい。

いったん、プロダクトイメージを形にしてみる。

こういうフェーズの時ってもう何が正解なのかほんとわからないんですけど、

具体的な形にしてみるとそこから思考が進んだりしそうですし、他人にイメージを共有しやすいと思っています。

で、多分この「プロダクトイメージを形にする」にはコツがある気がするんですよね。まじでしょうもないお子様思考ですが。

• 技術的制約はガン無視する
  • 技術的に現実的に実現可能かどうかは無視して実装するのがコツかと。例えばDB設計ゴリむずいなと思った場合、設計と運用が現実的かどうかは置いといて、とりあえずプロダクトイメージだけをダミーデータとかlocal storageとかで超ハリボテでいいから作る。
• 鍵となる体験のみ実装する
  • 例えば、「ログイン機能」とかはプロダクトの必須要件ではあるかもしれないけど、鍵となる体験は提供しません。「そのプロダクトの鍵となる体験はどこですか？あるいは何ですか？」という問いに対する答えをプロダクトイメージとして実装する。この時、この問いに答えられない場合は思考が浅いものと思っている。

そういえば、今までの反省をしてみる。

とりあえず反省を殴りがいてみます。少しでも、「楽して」プロジェクトに取り組みたい。今までの経験を活かさない手はないということでの反省。

シンプル時間かかりすぎている。

「最終的に必須にはなるけど、鍵となる機能ではないもの」を一生懸命実装していたことに起因すると思われる。

端的に、いらないものを一生懸命作っていた。

「ユーザーがつかないのは、プロダクトの完成度が低いからだ」と都合よく解釈して開発頑張っていたけど、最終的にユーザーはつきませんでした。

場合によっては一定の完成度を達成したら順調にユーザーがつき始めることもあるかと思います。でも今回の場合は違いました。

これは原因が複数あるなー、列挙してみます。

• 技術に飛びついた感ある。使ってみたいツールを使うことに夢中になり、プロダクトの目標を見失っていた側面が強い。
• 「作れるもの」という思考から抜け出すことができなかった。
• プロダクトの軸がなかった。ユーザーからフィードバックがあっても、プロダクトの軸を自分が理解していなかったため、実装すべきか否かを決定することができなかった。

ちょっと一旦、「プロダクトの軸がなかった」というのが深ぼるに値する反省な気がするのでこれについて触れます。

プロダクトの軸がなかった

自分が作っているものについて、

• 何のために作っているのか（目標 or 目的）
• 何を作っているのか
  • 作っているもののジャンルとかで良い。

とか考えないで取り合えず手を動かしていた気がする。手を動かすのはもちろん大事だと思うけど、例えば機能実装の場合は「なんでその機能を実装するの？」という点を強く意識することが大事な気がする。「何で実装するの？」という問いに対する答えとしては「この仮説を検証したいから」とか「これがあればいいのにと言われたから」とかが考えられる。

結局、開発していたポップコーンは何のツールなのかわからないもんなあ。。プロマネツールなのか？

使ってもらうことに貪欲じゃなかった。

「エンジニアあるある話」として聞いたことがあるが、「作ればみんな使ってくれるっしょ」「使ってくれないのは、作りが甘い or 足りないからだ」みたいに考えがちという話があろようだが、まさに自分にドンピシャだな。。

うん、これまじで反省だわ。恥かくのが怖かったのかなあ。実際怖いよね。「それいる？」という反応を得るとしても、「これ作ったんですけどどうですか！」みたいにみんなの時間を頂戴すればよかったかなあ。

「使われない」というのもより詳細に分類可能という話がある。シンプルに存在を認知してないから知らない場合もあるし、触れてみたけど良いと思わなくて使わないとか。

ここはちょっと他人に期待しすぎたよなあ。スラックで「使ってみて！」といえばみんな使ってみてくれると思ってた。そんな甘くなかったなあ。

良いこともあった気がする

反省としてポジティブなものもあります。反省てか振り返り？

思考と実装の距離が近かった

思いついたものをすぐ実装、というスタイルは諸刃の剣だけど、ハマるとそれなりに威力があることがわかった。「はや！」というリアクションを得ることができると、自分が作ったものに対する関心を獲得することができる。

反省をして、次どうしよう。

よくある話だけど、課題ドリブンな開発をすることはやはり大事だと痛感している。別に「これがあったら面白くない？」という程度でいいんだけど、それは「『これ』がないから今つまらない」という課題に定式化することができる。

この程度でいいから課題として定式かしたものから開発は始めた方がいい気がする。で、課題として定式化してみたらめっちゃしょうもねえやん、となったらその課題は多分筋が悪い。

だから、もっと速く回せるよなあ。「速く回せる」というのは、プロダクト開発に関する無駄な時間を省くことができるという意味。

節目を設ける。

いや、これがスムーズにできたら誰も苦労しないんだよっていう内容ではあります、「節目を設ける」。ただこの「節目を設ける」というのは、「まあそうだよね」と多くの人が共感してくれそうな内容ではあるものの、それはつまり具体性が低いということでもあり、解像度が低いということでもあります。

で、節目って何ですか？

適切な粒度の検証したい仮説、そのために作るべき「動くもの」の要件、検証の仕方、プロダクト全体に対してなぜその仮説を検証したいのかというところの理由づけ、以上の4点が揃ったものに「期限」を付加したものが節目であると定義することはできるかね？

自分の場合は上記4点でそれっぽい雰囲気があるけど、人によってはこれが「リードの獲得」とかになるわけだよな。

さて。

十分に頭使った気がする。次は動く時間かな。まずは節目を設けます。

一旦日記以上。最後までお読みいただき、ありがとうございます！