はじめに
普段システムやアプリケーションを作るのに、どういう手順でやるっけかなーというのを書き出してみた、というものです。
必ずしもこの通りにすればうまくいく、というものではなく、一例だと考えてください。
流れ
大雑把に次のような流れになります。
- 何をしたいのか、まとめる(企画、要件定義)
- 要件を満たすシステムの入力や出力の詳細、データの流れやシステムの処理をまとめる(仕様策定)
- 要件、仕様をどうやって実現するのか考えてまとめる(設計)
- 設計に対応する実装をする、システムを構築する(実装)
- 実装、構築して出来上がったものが、要件や仕様を満たしているか確認する(試験)
- 完成
各工程で、アウトプットしたものを後工程で使ったりします。
1. 何をしたいのか、まとめる(企画、要件定義)
システムやアプリケーションに限らないですが、そもそも何をするのか決めていないと、始まらないので、やりたいことをまとめます。
システムが解決したい課題は何か、文章や図でまとめます。
次のようなことを書き出してみればいいです:
- どういう背景(ストーリー)があってシステムを作るのか
- システムが無い場合、どような課題があるのか
- 既存の作業や仕組みを置き換えるのであれば、その流れ
- 誰がシステムを使うのか
- システムでは何をするのか
- 課題のうち、システムが扱う範囲、扱わない範囲
- システムに入力されるデータは何か
- 人間の操作、外部のデータ、システムによって取得されるデータ
- システムはどのぐらいの性能が必要か(性能要件)
- 利用者の数(延べ人数、同時に操作する人数など)
- 扱うデータ量(入出力のデータ量、保存するデータ量)
- システムの処理時間(入力から出力までの時間、画面の応答速度)
- システムはどのような環境で動作させるか(動作環境の制限、要件)
- 特定のハードウェアやクラウド、プラットフォームを使わないといけないなどの制約はあるか
この工程でのアウトプット:
- 企画書、要件定義書などに相当する資料(読んだら何をしたいのかがわかる資料)
ポイント:
- 長い文章よりも、箇条書きで整理されたものがわかりやすい
- 文章だけではなく、図もあるとわかりやすい
- 具体的な画面のイメージや処理の流れがあるなら絵を書いておくとよい
- やりたいことがまとまらない、という場合、課題がはっきりしていない可能性があります。現状何が問題なのか、整理するとよさそう。
2. 要件を満たすシステムの入力や出力の詳細、データの流れやシステムの処理をまとめる(仕様策定)
前工程で何をしたいのかを明らかにしたので、システムが扱う部分をもう少し具体的にします。
次のようなことを書き出してみればいいです:
- システムを機能毎に分けたもの
- 入力、出力、処理など
- 機能数が多い場合は大中小などのまとまりを作って、ツリー状にして整理するとわかりやすい
- 最上位階層が10~20程度になる場合は、やりたいことが多すぎるので、サブシステム化(別のシステムに分割して、システム間で連携させる)も検討したほうがよい
- 入出力されるデータのフォーマット
- 各機能毎の入力と出力
- 外部のデータを取り込むor送信する、ファイルを読み込むor書き込む、データベースを読み込むor書き込む など
- 利用者の具体的な操作(何を使って、どのように操作するのか)
- 画面上の入出力
- 各機能毎の入力と出力
この工程でのアウトプット:
- 仕様書に相当する資料(各機能と入出力がわかる資料)
ポイント:
- 箇条書きを使って、できるだけ簡潔に説明する。仕様が複雑だと後の工程が大変です。
3. 要件、仕様をどうやって実現するのか考えてまとめる(設計)
前工程で機能と入出力を明らかにしたので、この工程では具体的にどうやって作るのかを考えます。
機能、入出力をつないで、1つのシステムとして整合性のとれた状態にする必要があります。
次のようなことを書き出してみればいいです:
この工程でのアウトプット:
- 設計書に相当する資料(各機能毎に、入力から出力までの間に何をするのか、どのように構築するのか、がわかる資料)
ポイント:
- 箇条書きや図を使って説明する。
- 実装や構築が困難な設計を避ける(後の工程が大変になります)
- 必要以上に複雑にしない(要件を満たす以上のことは、実装が終わってから余力でやるぐらいのほうがいい)
- 実装に着手するには、すべての機能の設計が終わってないとダメ、ということはないです。並行作業で進められることもあります。
- しかし、並行作業で進めると、「実装中の機能に設計変更が必要になった」というのもよくある話です。システム全体の整合性のためにも、設計は早めに終わらせといたほうがよさそうです。
4. 設計に対応する実装をする、システムを構築する(実装)
前工程の設計に従い、システムの実装、構築をします。
設計が適切であれば、実装は楽に進められます。
この工程でのアウトプット:
- 必要な機能が実装されたシステム
ポイント:
- 設計や仕様に不備がある場合は、設計、仕様にフィードバックしつつ、実装を進めていくとよさそうです。
5. 実装、構築して出来上がったものが、要件や仕様を満たしているか確認する(試験)
実装が終わったら、最後に要件や仕様を満たしているのか、確認(試験)をします。
試験の方法は、要件と仕様を元に、試験項目書を作ってテストしたり、ざっくり動かしてみて問題なかったらOKとしたり、プロジェクト毎に異なります。
試験の結果、問題がある場合は修正して再試験します。問題がなければこの工程は終了します。
この工程でのアウトプット:
- 試験結果
- 問題の有無(要件や仕様に沿ってない場合は問題がある。)
- 問題を修正したシステム
ポイント:
- 試験項目書をつくる場合は、試験項目書に記入した結果がアウトプットとなる
- 問題が致命的かそうではないか、などカテゴリ分けすると、わかりやすい
6. 完成
試験が完了したら、システムは完成となります。
必要であれば利用者向けのドキュメントを作成したり、納品物にまとめたりします。
まとめ
企画、要件定義→仕様策定→設計→実装→試験、という流れになります。
書いてから思ったけど、ウォーターフォール・モデルですね、これ。
自分の中で、開発の手順を意識できていれば、次に何をすればいいのかわからず戸惑う、という状況は減るのではないかと思います。
記事中のイラストは、いらすとやのものを使ってます。