システムやアプリケーションを開発する際は主に以下のような流れで進んでいきます。
- 要件定義
- ワイヤー作成
- 仕様書作成
- デザイン作成
- 開発
- テスト
- リリース
これから各フェーズで行う具体的な作業と、どういった目的で行われるかについて解説していきます。
要件定義
まずは開発を行うにあたっての要件定義を行います。
どんなユーザーを想定していて、どんな目的で、どういった機能が必要かという事を洗い出します。
ここではテキストベースで要件をまとめていくのですが、まずはあるべき姿を考えて、工数や予算などは度外視した方が、後々サービスの設計や拡張性を考えるにあたってやりやすくなります。
多くのシステムの開発に関わってきましたが、正直この「要件定義」の部分がプロジェクトで一番大事で、ここを詳細に詰め切ることでプロジェクトの成功確率は大きく上がります。
要件が曖昧で目的より手段が先行してしまったり、技術やトレンドなど小手先のものに寄った要件だと、開発のフェーズになった後に何度も手戻りが発生してしまい、プロジェクト全体を通してのコストが膨大に膨れ上がります。
なぜ、誰のために、どういうシステムが必要なのか、という核になる部分はブレる事がないようにしたいです。
この要件定義のフェーズで作成する資料として、
- 機能一覧
- 業務フロー図
などが挙げられます。
機能一覧
機能一覧はシステムに必要な機能を列挙したものになります。
例えばブログを投稿して閲覧させるようなメディアサイトを作りたい場合は
ユーザー画面
- ブログ閲覧
- ユーザー作成
- ログイン
- お気に入り
- コメント
管理画面
- ユーザー作成
- ログイン
- ブログ投稿
といったような感じです。ここで機能と目的がはっきりしているほど、次のフェーズに入りやすくなります。
業務フロー図
業務フロー図はシステムに関連する登場人物を洗い出した上で、誰がいつどの機能を利用するかを時系列にまとめたものになります。
上のブログサービスの例だと、
- 管理者が管理画面でログインをする
- 管理者が管理画面でブログを投稿する
- ユーザーがブログを閲覧する
- ユーザーがユーザー登録をする
- ユーザーがログイン後に記事をお気に入り保存する
といったような流れになります。
toC向けのサービスの時は「カスタマージャーニーマップ」に近いような形になりますし、業務改善系のシステムであれば、現時点で紙などのアナログのフローをDXするような場合も考えられます。
ワイヤー作成
作りたいサービスの要件定義が出来たら、ワイヤー作成に移っていきます。
ワイヤーとはデザインに落とす前の、ざっくりとした画面の構成で、ノートにペンで手書きであったり、ホワイトボードに書くであったり、何でも大丈夫です。
いくらテキストで機能一覧を作成しても、実際どんな画面が必要なのかという部分が分かりづらかったりするので、このワイヤーを作成するとかなりシステムのイメージが湧きやすくなります。
ここではサイトの色やボタンの形などを凝ってしまうと、余計なところに頭を引っ張られるので、あくまで「機能」のみを考えて、白黒のシンプルな資料が望ましいです。
ワイヤーを作成していく中で、機能一覧に修正が入る場合もございますし、むしろワイヤーが固まって次のフェーズに入った後に機能を変えるとなると、かなりの手戻りになってしまうので、ワイヤーの状態で先に作った「機能一覧」を網羅しているか？「業務フロー図」を実現出来る画面か？を入念に判断するようにして下さい。
デザイン作成
ワイヤーが固まったらデザインに入る事が出来ます。
デザインはデザイナーが作成するもので、主にクライアントとサービスイメージを共有する目的と、フロントエンジニアがコーディングするための材料として使われます。
デザイナーにも色々種類があるのですが、
- UI/UXの事を考えてユーザー目線のデザインを提案出来る
- 何故そのようなデザインにしているのかをロジカルに説明出来る
- エンジニアの作業を想定して、パーツの共通化や拡張性を考慮出来る
上記のような事を出来るデザイナーはかなり優秀で、出来ればワイヤー作成や、もっと言うと要件定義から関わってくれたりするとかなりプロジェクトがスムーズに進みます。
仕様書作成
仕様書は主にエンジニアに向けた資料になります。
仕様書というのは、このボタンをクリックするとこのデータが保存される、であったり、このボタンをクリックするとこの画面に遷移する、であったり、エンジニアがコーディングするのに必要な情報をまとめた資料です。
エクセルやスプレッドシートなどに網羅的にまとめるのが主流ですが、個人的にはデザインの上に仕様も記載しておいて、画面遷移や条件分岐などもデザインを見て理解出来るのが一番エンジニアに対してスムーズな情報伝達になるのかなと思います。
開発
ここまで来てようやく開発に入っていきます。
よくテレビなどで見かけるエンジニアが真っ黒の画面に文字をカタカタ打ち込む作業です。
システム開発の知識がないと、開発に入るまでの工程の重要性が認識しておらず、この開発フェーズを重視しがちですが、実際は仕様書の作成段階でプロジェクトの8割くらいは終わっているイメージです。
開発に入ってからは、いかに少ないコードでシンプルに実装が出来るか、また見積と実装のずれをいかに少なく出来るか？といった部分が大事になってきます。
デザイナーと同じくエンジニアにも色々なタイプがありますが、
- 仕様に対しての理解力がある
- 仕様の面で考慮漏れがあった時のエンジニア目線で提案をしてくれる
- シンプルでコード量が少ない
- バグが少ない
などが優秀と感じるエンジニアの定義です。
テスト
開発が終えたらテストに入ります。
実際は開発を行なっている最中に、単体テストと呼ばれる細かなテストを各エンジニアが行なっており、機能ごとのテストは開発中に行なっていて、統合テストと呼ばれる全体を通したテストを行う際にはバグがあまり出ないのが理想的です。
というのも、全体を通した機能でバグが出てしまうと芋づる式にバグが発生して、修正箇所が拡大する恐れがあるからです。
テストはユーザーが実際の画面をどのように触るかを想定した「テストシート」と呼ばれる資料を作成し、成功パターン、失敗パターン、ログイン時、ログアウト時など、あらゆる場面を想定して作成する必要があります。
ここで仕様を網羅している事がバグを見つける大きな手がかりになり、逆に言うと仕様書が正しく網羅的に書かれていればバグを見つける事は容易になります。
システム開発は前の工程に行けば行くほど重要だという事が分かってきたのではないでしょうか？
リリース
上記の工程を全て終えて初めてリリースが行えます。
リリースしてからは保守・運用や追加開発に入っていくのですが、小さいサービスでもフルスクラッチでの開発の場合は最低数ヶ月、ノーコードやSaaSなどのサービスを組み合わせたら最短1週間くらいかかると思います。
規模にもよりますが、長いものだと1年以上かかるサービスもあります。
現在は、なるべくミニマムでコア機能だけを開発してすぐリリースをし、ユーザーの意見を反映しながら修正していく、MVP（Minimum Viable Product）と呼ばれる開発手法がトレンドで、自分もミニマムスタートの開発を得意としております。
いかがでしたでしょうか？
今回は開発の大まかな流れについて解説しました。
なるべく手戻りの少なくスムーズな開発を目指しましょう！
