97
98 7.1 現状の把握と課題の特定
漁港（産地市場）の電子化・ネットワーク化にあたって、当該漁港（産地市場）におけ る業務を把握し、これを可視化することによってその課題を抽出する。また、一部業務で 導入しているシステムあればその効果についても把握するとともに、他地区の事例なども 参考とするのがよい。
漁港（産地市場）の関係者を把握する。関係者としては、市場職員の他、買受人、生産 者（船主・荷主）、問屋、運送（輸送）業者、製氷会社他資機材関係会社、地方自治体
（漁港の管理者、市場の整備事業者・所有者）、研究機関・団体（水揚げ統計、市況、
TAC管理など）などである。
99 7.2 システム化の方向とシステム化計画
(1)システム化の方向
前項において抽出された課題を解決するためのシステム化の方向を定め、基本システム やサブシステムについて、その効果や予算、受入体制などを勘案し、全体および年度ごとの 導入スケジュールを作成する。併せて、必要となる機能、監視、バックアップ、非機能（デ ータ量、通信速度、ユーザ数稼動率、保守体制等）の各要件について整理し、システムの要 件を定義する。また契約形態についても検討1)を行う。
(2)システム化計画書
作成・整理した内容を仕様書としてまとめ、業者に提案依頼および見積依頼（機器見積（簡 易構成図）、作業見積、プロジェクト管理見積、保守見積）を実施し、システム会社を決め る。システム導入・構築の契約に当たっては、契約における重要事項および委託者と受託者 の間での役割分担・責任関係の明確化を行う。
契約後、受託者はシステム化計画書（作業方針、作業内容・作業方法、スケジュール、作 業体制および管理、事業管理手法、品質管理手法、リスク管理手法）を作成し提出する。
1) 経済産業省『情報システム・モデル取引・契約書（第一版）』、『情報システム・モデル取引・契約書 （追補版）』
を参照のこと。http://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo_gaiyou.pdf
100 7.3 要件定義
要件定義について、委託者と受託者は、機能要件、関係者の役割と権限、監視要件、バッ クアップ要件、非機能要件（規模性能要件・信頼性要件・拡張性要件・事業継続性要件）に ついて、その内容を確認・整理する。
要件定義成果物の詳細は契約項目に従うが、例として以下のようなものが挙げられる 2)。
（要件定義成果物の例）
・ビジネスプロセス関連図
・業務機能構成表
・ビジネスプロセスフロー（業務フロー／システム化業務フロー）
・画面／帳票レイアウト
・業務処理定義書
・概念データモデル（実体関連図（ER（Entity-relationship Diagram）図）※）
※具体的なシステムのデータモデルを図で表現した実体関連図
・エンティティ定義書／データ項目定義書
※システム上でデータとして取り扱うことができるよう抽象的にモデル化された、
現実世界の対象物や概念のことをエンティティという。
・CRUD 図
※各 デ ー タ に 対 す る 、登 録・変 更・削 除・参 照 機 能 の 有 無 を 表 現 し た 表 が CRUD 図 と い う 。
・総合テスト計画書
・システム移行計画書
・運用・操作要件書
・非機能要件書
2) （独）情報処理推進機構「ユーザのための要件定義ガイド」、SECBOOKS「高信頼化ソフトウェアのための開発手 法ガイドブック」（独）情報処理推進機構「非機能要求グレード」を参照のこと。
101 7.4 システム設計
システムの設計は、以下の手順により実施する。なお、要件定義～システム設計～プログ ラミング～テスト～導入においては、例えば、ウォーターフォールモデル3)による開発を参 考とすることができる。
(1)基本設計
要件定義に基づき、システム運用のために必要な技術的課題を検討し、実現可能な方策を 業務の効率化・効果を考慮し、決定する。基本設計での成果物として、基本設計書とテスト 計画書を作成する。
基本設計書には、信頼性や可用性などの非機能要件を含めて、サービスレベル定義の分析 方法と、効果目標や要求事項達成、安定した運用、異常時の業務継続への適応を確保できる ようなサービスレベル基準、サービスレベル管理の方法を定め、記載する。また、次のシス テム構成図についても基本設計書に記載する。
（システム構成図）
ａ．システム構成にあたっては以下の視点での検討を行い、その結果を明記する。
・構築のしやすさ（費用面）
・冗長性（故障、バックアップ等）
・入出力機器（ディスプレイ、キーボード等の共用可能性
・フェールセーフ（停電時のUPS等）・
・省スペース、省電力性
・保守のしやすさ
・リスク対策（脅威、災害）
ｂ．ハードウェアの選定にあたっては、次の視点から検討を行い、その結果を明記する。
・保守期間、保守体制（費用）について
・同メーカ・同等スペックの中での最新機種であるか（そうでない場合その理由）
・導入実績有無
・既存資産についての把握、転用または共用の可能性
・既存システム環境への影響
ｃ．ソフトウェア選定にあたっては、次の視点から検討を行い、その結果を明記する。
・保守期間、保守体制（費用）について
・ライセンス形態と必要ライセンス数
・同一ソフトの中での最新バージョンであるか（そうでない場合その理由）
・導入実績有無
(2)詳細設計
基本設計に基づき詳細設計を実施する。詳細設計の成果物として、詳細設計書を作成する。
3) システム開発の手順を模式化したモデルの一つで、設計やプログラミングといった各段階を一つずつ順番 に終わらせ、次の工程に進んでいく方式。
102
詳細設計書には、セキュリティ対策について記載4)する。また、詳細設計では画面インタフ ェース設計を行う。インタフェース設計においては、ISO/IEC 2506X（人間中心設計の国際 規格）に記載されたユーザビリティ向上に関する情報やユーザビリティの評価法を参照し、
認知性と作業効率の向上についての検討を充分に行うこととする。また、アクセシビリティ については一般的な日本語表示による操作を基本とするが、他言語対応、音声サポート等の 対応についてはシステム要件としてあらかじめ確認事項とするのがよい。
(3)品質管理
設計・開発においては、品質・信頼性の確保に主眼をおき、インスペクション（成果物に 入り込む欠陥の早期発見と除去）等適切なレビュー手法を採用することとし、品質計画を策 定・実施する。品質管理の成果物として、品質計画書と品質管理報告書を作成する。
4)（独）情報処理推進機構「安全なウェブサイトの作り方」、「SSL/TLS暗号設定ガイドライン」、「Web Application
Firewall 読本」、「『高度標的型攻撃』対策に向けたシステム設計ガイド」、「組織における内部不正防止ガイドラ
イン」、「セキュア･プログラミング講座」を参照のこと。
103 7.5 環境構築～プログラミング～テスト
システムの設計に基づき、以下の手順により環境構築、プログラミング、テストを実施す る。
(1)環境構築（機器調達、設置）
実環境への機器設置、各種設定、動作検証においては、発注者側システム管理者またはシ ステム保守業者と充分な協議、調整、指示の下、準備・作業を実施する。なお、実環境を必 要としない作業（設計、構築、単体・結合テスト等）については受注者が用意した場所にて 実施する。
(2)ソフトウェア設計等
ソフトウェア設計、プログラミング、そしてソフトウェアテストの一連のソフトウェア開 発を実施する。
(3)テスト
要件、仕様について、システムが正しく動作し、充分な性能・品質が確保されていること を確認する。システム試験環境（システムテストデータを含む）はシステム開発受託業者に て用意する。このとき、システム試験に本番環境機器の使用可否については発注者との協議 にて決定する。実環境でのシステム総合テストにおいては、発注者側システム管理者または システム保守業者と充分な協議、調整、指示の下、準備・作業を実施する。
1)実施工程
テストは、一般に以下の3つの工程で実施する。
①単体テスト
プログラムを構成する比較的小さな単位（関数、メソッド）が個々の機能を正しく果たし ているかどうかを確認・検証する。
①統合テスト
単体テストが完了し、単体としての品質が保証されたプログラムが、相互に連携して正し く機能することを確認する。テストの実施に当たっては、機能間結合テスト、サブシステム 間結合テスト等のテスト区分を設け、段階的にプログラムを結合することにより、品質を確 保する。
③システムテスト
統合テストを完了したシステムが、機能・性能・移行・運用等に係る各種要件を満たすこ との最終的な確認を行う。確認にあたっては、品質特性（機能性、効率性、信頼性、使用性、
保守性、移植性）を網羅したテストを実施し、その妥当性を評価すること。なお、システム テストでは、以下のテストを含むものとする。
・ 運用テスト
・ 性能テスト