見出し画像

【3つの方針】0→1のプロダクト作りで、開発者はどんな設計・技術選定を行えば良いか

フリーエンジニアの西元です。仕事柄、新しいプロダクト開発に携わることが多いのですが、技術選定にちょっと悩ましいことがあります。

ただ、大まかな方針は変わらないはず。カンタンに考えを整理してみたいと思います。

1. 柔軟性を重視する

あたり前といえばあたり前なのですが、新規開発では特に注意しておかなければなりません。なぜなら、開発中に状況は刻一刻と変わり、「仕様を変えたい!変えるべき!」と言う話が9割方出てくるからです。

開発者にとっては結構ややこしい事態であることは言うまでもないのですが、ビジネス上はある程度仕方がない部分です。

だから、開発者としては「大幅な変更があるかもしれない」と考えながら設計・開発をするのがベター。事業全体の目的を理解した上で、「こんな変更があるかもしれない」と具体的に想像できれば理想ですね。

明確な完成形を決めすぎず、アジャイル開発を行えればベストだと思います。が、大人の事情でできない場合もあるので、ウォーターフォールであっても柔軟性を確保しておくというのが大切なポイントだと思います。

2. 工数を下げる(開発スピードをあげる)

極力工数を下げて開発スピードをあげることもポイントかなって思います。なぜなら、時間をかければかけるほど、変更したくなってくるから。終わりが見えなくなっていきます。

また、工数をかけて「なんとなくできのいい」プロダクトをつくっても、最終的に使われるかどうかというと結構あやしいケースが多いです。

だから、一旦の完成までできるだけ早くもっていくこと。MVP(minimum viable product)をまずつくる、という風に言い換えてもいいかな。

もちろんコアな部分はしっかりつくっていく必要もでてくるでしょうが、仮説検証の結果によって大きく変わりそうなところはできるだけ簡易に機能を実装するのがベターだと思います。

3. スケールは考えすぎない

新しいプロダクト開発では、「もしかしたらこれくらいのユーザーさんが使ってくれるかもしれない!」と過剰に期待してしまうことがあります。でも、大抵の場合そんなすぐにアクセスがあるようなプロダクトにはなりません。

なので、スケールはあんまり考えすぎない。バズったらこういう方針でいこう、とか考えられていれば十分だと思います。取り急ぎ、数ヶ月たえられるような構成だったら大抵の場合はなんとかなるんじゃないかな。


P.s.

結局のところ、できるだけ軽くサイクルを回すと言うことが大事ってことかな。開発者も、良い仕事をするならビジネス的なロジックもしっかり考えられなきゃいけないよねえ。

基本方針としては大枠間違っていないと思うのですが、ツッコミがあればお待ちしております。

いいなと思ったら応援しよう!