2016.11.27 まなびん

アプリ開発・ウェブ開発

ウェブサービスを納品するのは不可能なのではないかと思う

ウェブサービスって開発中に改善や問題に気がつくことが多くて完成が難しいんですよね。

当初の仕様のまま制作するとサービスとして大きな課題を抱えることになるので、遅かれ早かれ改善をすることになるし、改善するとそれに伴う問題が見つかったり、世間のトレンドやユーザーの行動やリアクションなどからまた改修すべき部分が出てきたりしてなかなか完成には至らないのです。

また、世の中の流れも早く、PCファーストのウェブの時代から、モバイルファーストになり開発側は休んでるヒマはないわけです。

そう考えると、そもそもウェブサービスの完成ってあり得ないんですよね。FacebookもInstagramもAirbnbも日々開発続けて改善してるし。

日々問題は出てくるし要件は変化していくし、マーケティングも日々考えないといけないし。

保守ベースの方が向いている

保守は本来完成したサービスの継続やトラブル対応を意味することが多いですが、保守に開発コストを含めてしまうようなやり方はウェブサービスの受託の形として向いているのではないかと思います。

ユーザー増加やトラフィック増加にともなって発生するインフラの改修作業は保守の作業になると思いますが、インフラに手を入れなくてもシステム側を改修してやったほうが効率が良い場合もあるだろうし、インフラ+システム+マーケティングをトータルで見れるので、バランスも良いです。

とはいえ、もちろん当社でも納品する案件はありますし、納品しないとお金がもらえなかったりします苦笑

性質上納品に向いていると思うものとそうでないものがあると思いますが、ズバリ納品に向いてるウェブサービスは業務システムだと思います。

業務システムというのは

・倉庫管理システム

・在庫管理システム

・受注管理システム

・顧客管理システム

のようなもので、会社の業務フローが変化しない限り基本的に要件は変わらないものです。

要件定義が明確にできるのでプログラマーは要件に沿ってシステムを開発すればいいということになります。

また、イベント系のサービスやアプリも向いていると思います。

この場合は納品できると言うより、納品せざるを得ないと言ったほうが正しいかもしれません。

イベントの時期は決まっているので、それまでに完成させないといけないことは必須で、とりあえずリリースして後から改修ということはできないからです。

納品してもらう場合、制作物でどこまでの成果を生めるかの予想と計画は決めておいた方がいいと思います。

例えば最初の開発で目標ユーザー数などを決めて、達成したらさらに追加開発、みたいな感じ。

曖昧な仕様でも目標が決まっていると必要なものが具現化できるので、仕様に落とし込む形にしていくことができます。

この時大事なのは目標を達成できるかのテストマーケティングです。

想定していた仕様でユーザーを確保できる根拠があれば、目標達成までは後で改修する必要もないので後はひたすら実践していくだけということになるわけです。

納品してもらうなら、目標決める→テストマーケティング→仕様に落とし込む→開発は最低限決めた方がいいですよと。

まなびん

会社の代表やってます。遊ぶように仕事やってます。