webサービス開発の流れ

目次

マーケター、エンジニアを月1時間からジョインできるプラットフォーム

airteamは月1時間からマーケターやエンジニアに相談できるプラットフォーム。 雇うのはハードル高いけどプロをチームに入れたい。そんな経営者のためのサービスです。 相談にのる方も募集しています。

タスクなしだから月一時間からジョイン可能

作業はなくオンライン相談メイン。 月1時間からさっと経験者に継続的に相談できます。

多様な経験者を雇用するより何倍も早くチームに

あらゆるジャンルの経験者がいるので あなたのチームのノウハウの選択肢が広がります。

NDAはすでに締結済み、契約もスムーズ

契約の煩雑なやりとりはなく、NDAはすでに締結済み、書面のやりとりはありません。

webサービスを作る際の流れを非エンジニアの経営者向けに解説していきます。外注時に開発の流れを発注者が知っていることでよりスムーズになります。また、自分で作ってみたい場合にも役立ちます。

この記事は下記動画でも解説しています。

webサービスの定義

まず、webサービスというとfacebookやtwitter、amazonなどを想像すると思います。かねがねあっているのですが、今回はブラウザに表示せるwebのサービスを対象とします。iOSやandroidなどアプリの開発は一旦置いておきます。

webサービス開発の流れ

webサービス開発は下記の流れで進んでいきます。

  1. 要件定義
  2. 仕様策定
  3. デザイン
  4. スケジュール決め
  5. 開発
  6. 納品

webサービスの開発というと5のコードを書く工程をイメージされると思いますが、実は結構いろんな工程があります。もちろん組織や人によって多少前後します。それぞれの工程を解説していきます。

要件定義

要件定義と言うのはやりたいこと、作りたい機能を決める工程です。EC作りたいです!だけではダメで、例えば商品ごとに決済できる機能が欲しいです。決済は一回払いでクレカで払えるようにしたいです。などです。ここをちゃんと決めないクライアントさんも多いですが、必ず決めましょう。絶対に揉めます。

そんなの技術力がないから無理。。。と言う方、逃げです!技術力がなくても何が欲しいかはあなた自身が知っているはずです。それを伝えた上でどう実現させていくのかは次の仕様策定でエンジニアさんに相談して決めます。ここは技術力が必要です。

仕様策定

仕様策定というのは要件定義で決めた作りたいものをどう実現していくか決めていく工程です。ここはエンジニアさんが中心になっていくと思います。例えば

「クレカの決済できる機能」

と言う要件定義があったら

「クレカ決済をstripeと言う決済プラットフォームにつなげて行う」

と決めるのが仕様策定です。(本来はもっと詳細に決める)

デザイン

デザインは仕様策定と同時進行の場合もあります。サイトの見た目を決めていく工程になり、デザイナーさんとのやりとりが中心になります。ここで具体的に形にすることで仕様に影響することも多いです。密にやりとりが必要なのでデザインを最後まで進めてから仕様策定、みたいな進め方や仕様策定してからデザインにしてしまうと後でやはり変更しなきゃみたいなことが起こるので要注意です。

タスク割り振り

作るものが決まればタスクを割り振っていきます。これは外注している場合、開発会社さんの方でやる工程になります。

スケジュール決め

そしてそれぞれの実装をいつまでにやるかを決めます。よくある勘違いは仕様策定する前にスケジュールを求めてしまうパターンです。経営者の方が外注時にやりがちですが、何をするのか決まっていないのにスケジュールを決めるのは無理なのでこの順番で決めていきましょう。

開発

開発になります。実際にコードを書いていく工程です。ここで開発していく中でできないことやもっとこうした方がいいと言うのが出てきます。これはエンジニアさんのミスでもなんでもなく、開発というのは都度調べながらやるので当然のことです。

テスト

動くかどうかをテストします。これはQAと言う専門の人を置く場合もありますが、小規模な場合、開発会社とクライアント双方でやるのが一般的です。

納品

テストし、問題なければ納品になります。

開発の途中経過のコミュニケーション

開発期間中何をするのか。これは自社でやるのか外注でやるのかでも変わってきますが、途中経過をちゃんと確認するステップを踏んだ方がいいです。DeNAの南場さんも起業当初、リリース直前で開発会社が全然開発していないことを知ったというエピソードがありますが、こういうことがないように途中で確認するべき。

部分的な機能でマイルストーンを引くのがいいかなと思います。機能単位でないと確認もしにくいと思うので。これを断ってくる会社は怪しいのでやめた方がいいです。

どこまで発注者が決めるべき?

外注時に揉めるのはどこまで発注者が決めるかというところです。多くの発注者がECを作りたい!他は考えて!と投げがちで実は必要な決定をちゃんと行っていない人が多いです。まあ、これは発注側はわからないのでプロである受注者、開発者側がリードしなきゃいけないところでもあるのですが、発注側は気をつけた方がいいです。

ではどこまで決めるべきかというと何をしたいかです。いやECを作りたいんだけどと思っているかもしれませんが、それでは不十分です。

せめて機能レベルで決めましょう。ただ、どう実現するかまで決めなくていいです。機能単位で何をしたいか決める。これが要件定義になります。そしてそれをどう実現するかが仕様策定で仕様策定は開発側がリードすべきです。

つまり、作る内容を決める際にまず

  • やりたいこととどう実現させるのかを分けて考える
  • やりたいことを要件と呼び、これは発注者側がリードして決める
  • どう実現するかを仕様とよび、受注側、開発側がリードして決める

ここでリードして決めると言ったのは片方だけでは決められないからです。必ずお互いコミュニケーションしながら「こういうの作りたいんだけど」「こうだったらできますよ」みたいなやりとりで決めていきます。

お勧めツール

webサービス開発をするにあたって便利なツールを紹介していきます。上記の開発進行を手助けします。開発において重要なのは

  • タスク管理で誰が何をするのか、そのタスクのステータスがわかる
  • デザインなどを伝えやすくする

で、上記ができればなんでもいいんですが、私が使ってて重宝しているものを紹介します。

notionでドキュメント管理

notionはなんでもできますが、開発の進行管理にも使えます。エンジニアだとgithubのzenhubやjiraなどを使いたいと思いますが、開発以外の部署も絡む場合、notionの方が連携しやすいかなと思います。notionのいいところはDBに施策やタスクをため、その表示をボード形式だったり、タイムライン形式だったりに簡単に切り替えられることです。

一元管理しつついろんな見せ方ができるのは非常に重宝します。

figmaでデザイン

発注側がワイヤーを引いて指示を出せるかは開発効率に大きく影響します。上手くなくてもいいのでワイヤーを引けた方が良いです。その際、figmaが最も便利で学習コストも低いです。