はじめに
みなさんこんにちは。easy memo管理人の大助です。
今回も、前回に引き続きIT企業の色々をご紹介していきたいと思います。
今回ご紹介するのはシステム開発の具体的な流れです。
最近はファミレスのタッチパネルや駅の券売機など様々なシステムが日々生活を支えていますが、
その開発方法にはあまりなじみがないのではないでしょうか。
今回は、そんなシステム開発の流れをご紹介したいと思います。
ちなみに、前回の記事はこちらからご覧になれますので是非合わせてお読みください。
システム開発の流れ
システム開発と言っても、大まかな流れとしては夕飯を作るのと変わりません。
夕飯を作る際、まず「何を作るか」を考え、次に「どうやって作るか」を考えます。
作るものと作り方が決まったら「実際に作る」作業を行い、最後に味見をしておいしくできているか「チェック」します。
システム開発も全く同じです。
まず要件定義工程で「何を作るか」を考え、基本設計工程、詳細設計工程で「どうやって作るか」を考えます。
次に開発工程で「実際に作る」作業を行い、最後に単体テスト、結合テスト、システムテスト工程で「チェック」を行います。
ここからは、それぞれの工程について詳しく解説していきますね。
1.要件定義
要件定義はシステム開発の一番最初の工程です。
この工程ではクライアントがどのようなシステムを求めているか、どのような用途で使うかなどをヒアリングし、クライアントのニーズやシステムが満たすべき要件を定義します。
システムが満たすべき要件は機能要件と非機能要件の二つに分けることができます。
機能要件
機能要件とはシステムが行うことができる機能を表したものです。
ファミレスのタッチパネルで例えると、以下のような機能が挙げられます。
- タッチパネルからメニューを選べる機能
- タッチパネルで注文したメニューが厨房に連携される機能
- テーブル決済できる機能
- 料理の在庫状況を確認する機能
非機能要件
非機能要件とは、そのシステムが満たすべき機能要件以外の部分の要件です。
こちらもファミレスのタッチパネルで例えると、以下のようなものが挙げられます。
- ボタンをタッチしたら2秒以内に画面が切り替わること。
- メニュー変更があったときにすぐに反映できる造りになっていること。
- セキュリティ対策ができていること。
このように要件定義段階では、クライアントのニーズを機能要件、非機能要件ともに定義する作業を行います。
基本設計
要件定義を終え、クライアントのニーズと開発すべきシステムが整理されたら、さっそくシステムの設計に取り掛かります。
まず初めに行うのが基本設計です。
基本設計は要件定義書に記載されている内容をもとに、大まかな動きの設計を考える工程です。
この工程ではまだプログラミングの知識はあまり使わず、「〇〇ボタンを押したら○○画面に遷移する」程度の大まかな動きを記載します。
分かりやすく言うと家電の取り扱い説明書と同じような粒度ですかね。
（電源ボタンを押したら掃除機のスイッチがオンになる、「モード切替」ボタンを押したら掃除機が「強」モードになるなど）
具体的には以下のような設計を行います。
また、要件を達成するためにどのようなモジュールが必要か、どのような実現方法にするかを洗い出すのも、基本設計の役割です。
例えば「注文済みの商品を確認できるようにしたい」という要望があった場合、以下の2つの実現方法があります。
- 「注文履歴」画面を新しく作成して表示させる。
- 注文した履歴をポップアップで表示させる。
前者であれば新しく「注文履歴」画面の作成が必要になり、後者であればポップアップの作成とそれを呼び出すモジュールが必要になります。
このように同じ要望でも実現方法によって必要なモジュールが異なり、それも基本設計の工程で決めることになります。
この基本設計の工程で作成した基本設計書は、一次受け企業やクライアントのレビューを経て完成となります。
一次受け企業や二次受け企業の解説はこちらに記載していますので、合わせてご覧ください。
詳細設計
基本設計が完了すると詳細設計を行います。
詳細設計とは、基本設計書に記載した内容を、開発に向けてより具体的に記載する工程です。
基本設計はクライアント向けでしたが、詳細設計は開発するエンジニア向けに行います。
例えば画面の遷移を考えるとき、以下のような違いがあります。
基本設計
「『グランドメニュー』ボタンを押下すると『グランドメニュー』画面に遷移する。」と記載
詳細設計
「『グランドメニュー』ボタンを押下した際、「changePages(“00000001（遷移先の画面番号）”)」で画面遷移する。」と記載
「詳細」設計というだけあって、裏で動く処理まで詳細に記載しているのが特徴です。
他にも「追加するオプションによって表示するポップアップを変える処理」は以下のように記載します。
条件① サラダボタンを押下した場合
サラダを選択する画面を表示する
条件② スープボタンを押下した場合
スープを選択する画面を表示する。
条件③ ライスボタンを選択した場合
ライスのサイズを選択する画面を表示する。
上記以外の場合
金額確認画面を表示する。
このように詳細設計では、実際に開発する際のソースコードを日本語で記載します。
また、同じ処理でもどのように実装すれば負担が少ないか、後の仕様変更で変更しやすいかなどをしっかり考慮した上で最適な設計を考えることが重要です。
開発
開発とは、詳細設計書の内容をもとに実際にシステムを実装していくことです。
いわゆる一般的に想像するエンジニアって感じの仕事ですね。
実際にプログラミング言語を駆使してコードを書いていきます。
プログラミングを行うので難易度は比較的高いですが、実際の現場でも調べながら行うのでプログラミングをマスターしている必要はありません。
単体テスト
開発が完了したらその部品が正しく動くかどうかを確認します。
その確認工程のことをテストと言い、何段階かのテストを行います。
まず初めに行うのは単体テストです。
単体テストは作った画面やモジュールが期待通り動くかどうかを確認するテストです。
実は人によって単体テストの範囲は異なりますが、あくまでも単体テストなので、その画面やモジュールの中だけで確認できる事柄をテストします。
例えば作ったのがトップメニュー画面だった時、以下のような事柄をチェックします。
特に注意深く行うのが条件分岐の箇所で、先ほどの例だとサラダボタンを押したときに正常にサラダ選択画面画面に遷移するかなど、1つ1つ全部チェックします。
結合テスト
単体テストが完了したら行うのが結合テストです。
単体テストはその部品や画面単体が動くかどうかをチェックしていましたが、
結合テストでは部品や画面を複数つなげて動かしたときに正常に動くかをチェックします。
例えば「グランドメニュー」画面でハンバーグを選択した後、「注文かご」画面に遷移すると選択したハンバーグの情報が入っているかなどをチェックします。
実はこの時、「グランドメニュー」画面から「ハンバーグを選択した」という情報が「注文かご」画面に受け渡されるのですが、その画面間やモジュール間の「情報の受け渡し」などを詳しく見るのが結合テストというわけです。
この情報の受け渡しの部分でエラーが出ることが結構多く、「結合テストが怖いな」というセリフが現場ではよく飛び交っています（笑）
システムテスト
システムテストはシステム全体が設計通りに動作するかを確認するテストです。
単体テストでモジュール単体、結合テストで一連の流れのテストを行ったため、最後にシステム全体のテストを行うわけですね。
システムテストではシステムが想定通り動くかのチェックの他に、セキュリティや性能のチェックも行います。
性能やセキュリティのテストはそれまであまり行わないため、意外とエラーが出ることがあります。
なのでこの場面に来て初めて「いいシステムを作ったのに重すぎて使い物にならない」なんて事態に陥ることもあります。
そうなると万事休すですね。結局システム全体の見直しを行うことになります。
後の工程に行けば行くほど改修にかかる時間やコストが大きくなるので、できるだけ早い段階でエラーを見つけておきたいですね。
受入テスト
システムテストでも問題がなかった場合は、実際に運用する環境でシステムを動かしてテストを行います。
ここでも問題がなければ初めて、リリースできることになります。
まとめ
いかがだったでしょうか。
システムはこのような工程を経て作られていきます。
普段使用しているタブレット注文のシステムやアプリなどが長い段階を経て世に出ると考えるとなかなか感慨深いですね。
もし興味がありましたら是非一緒にエンジニアやってみましょう！
