株式会社博恒

コンピュータシステム開発

コンピュータ、その周辺機器、通信機器、デジタルコンテンツ及びソフトウェアの開発・設計・製造・販売・賃貸並びに輸出入業務

システムプロジェクト計画

実際の開発をスタートする前準備として、 プロジェクト全体のスケジュール、体制、サービス概要などを関係者で共有し、全体の目線合わせを行います。目的やゴールを明確にして開発者との認識の齟齬を防ぐため、必ず発注者も参加します。

スケジュールの決定	開発/リリース計画とリリース後の保守・運用計画
体制図の作成	発注側・受注側のコミュニケーションパス
サービス概要の決定	機能内容・範囲と非機能範囲

システムV字モデル

V字モデルは、サービスの品質確保に向けて開発現場でよく利用される考え方です。プログラミング（単体テスト）工程を中心に、各開発工程で必要とされるテストをVの字に表しています。 V字モデルを活用することで、開発工程で実施した内容を漏れなく検証でき、品質向上につながります。

システム開発工程の具体的な流れ

要件定義

要件定義とは、システム開発で実装する範囲や内容（システム要件）を決定する工程です。発注者が求める要件を開発者側の視点からまとめ、定義します。この工程にも発注者は必ず参加し、開発者とともに要件を定めます。
今回実現する機能の一覧と概要、逆に今回は対象外となる範囲のそれぞれが明確化されることで、 発注者と開発者が同じ目線でスタートラインに立つことができます。

機能要件の決定	ソフトウェアやシステム開発において、発注者が求める「機能」のこと
非機能要件の決定	「機能」以外のユーザビリティ、性能、拡張性、セキュリティなど

基本設計

要件定義の工程で決定した内容をもとに、システムに実装する機能を明確化・具体化する工程です。この工程が完了すると、画面構成・遷移先・入力内容といった サービスの全体像が可視化され、要件定義で洗い出した機能一覧の実現方法が明確化されます。
発注者と開発者の意見のすり合わせを行うため、この工程にも発注者は必ず参加します。ユーザーから見たときにどのような動作になるのかを決めるため、「外部設計」とも呼ばれます。

画面設計	・画面デザイン、遷移、バリデーション（入力チェック）・特殊操作
データ設計	・データベースに保存するデータ・データベースのテーブル一覧化（実データだけでなく、アカウント情報やサイト画像などの補助情報も含む）・画面からデータベースにデータを保存する処理(API)の一覧化
インフラ設計	・システム構築の方針・方式レベルの設計・サーバー数・OSは何にするか・サーバーのスペック・サーバーの用途　など

詳細設計

基本設計書をもとに、開発を行うエンジニアへ向けて「機能をどのように実装するのか」という設計を行う工程です。ユーザーから見えない部分の設計を行うため「内部設計」とも呼ばれます。
また、基本設計では「何をしたいか」を表現するのに対し、詳細設計では「どのように実現（実装）するか」を表現する違いがあります。 具体的な実現方法を開発者が実装可能な状態まで落とし込む作業です。
基本的に開発者側が中心となって行いますが、定期的なミーティングを設け、発注者側も進捗や成果を確認しておくことが重要です。

画面処理設計	・処理詳細・画面レイアウト・画面項目定義・項目定義・チェック・業務チェック・メッセージ・入出力処理設計・アクション処理設計
API処理設計	01 Web APIの種類選定　・REST（REpresentational StateTransfer）　・RPC（Remote Procedure Call）　・SOAP（Simple Object Access Protocol） 02 インターフェース設計 03 API処理詳細設計
データベース設計	01 論理設計・概念スキーマを定義します。・エンティティの抽出・エンティティの定義・正規化・ER図の作成 02 物理設計論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決めます。・テーブル定義・インデックス定義・ハードウェアのサイジング・ストレージの冗長構成決定・ファイルの物理配置決定
バッチ処理設計	01 ビジネス側の要件を明確にする 02 Dry Runできるようにする 03 APIを叩く処理はリトライする 04 外的要因に依存しないようにする 05 テストコードを書く 06 ログを出力する 07 コミュニケーションツールに通知する 08 冪等性をもたせる 09 処理対象を引数で指定できるようにする 10 リソースの消費を減らす

実装（開発）

詳細設計書に基づき、開発会社のエンジニアがプログラミングを行います。「作る・レビューする・改善する」の繰り返しにより機能を実装し、システムを作っていきます。
レビューとは、プログラムのソースコードを記述者とは別の人が査読し、誤りや改善点を見つけ出す取り組みです。 レビューと改善を繰り返すことで、プログラムの品質を高めていきます。
リリース後の改修などを考慮し、どのような開発言語で実装するのかを発注者側もある程度把握しておいた方が良いでしょう。

テスト

開発が完了したら、作成したシステムが正しく動作するか確認するためのテストを行います。テストの種類は以下の通りで、上から順番に行います。

単体テスト（ホワイトボックステスト）	システムの内部構造に重点を置くテスト手法。作成したプログラムを１行ずつテストし、ロジックが正しく動くことを確認する。
単体テスト（ブラックボックステスト）	システムの外部仕様に重点を置くテスト手法。インプットに対して単体モジュールが正しいアウトプットを行うことを確認する。
結合テスト（内部結合テスト）	システムを複数の意味あるサブシステムに分割し、サブシステム内の構成要素間（例：画面A→画面B）で正しくデータや操作の流れが連結されることを確認する。
結合テスト（外部結合テスト）	サブシステム間（例：Web管理画面→アプリフロント）で情報や挙動が正しく連結されることを確認する。
システムテスト	基本設計の仕様に基づき次のポイントを確認する。　・画面間の遷移が期待通りに動作するか　・機能要件としてあげられた各機能が設計書の記載(期待値)通りに動作するか　・入力上限、性能負荷、故障発生時など正常時以外の挙動も同じく設計書の記載通りに動作するか
受け入れテスト	発注者が実際の運用環境またはそれに近い環境でシステムを使用し、次のポイントを確認する。　・要件定義で定義された機能要件を満たすか　・発注側が期待したサービスレベルを提供できているか