おいて必要となるドキュメント標準が定義されております。本稿では「ドキュメント標準」の一部をご紹介しますので、是非ご参考にしてください。各工程で必要なドキュメントを定義しましょう下記のように工程ごとにドキュメント成果物、内容を定めております。どの企業でも必要なドキュメント成果物になりますが、必要に応じて追加・削除頂ければと思います。※業務系のシステム開発に照準を当てております。要求分析(要件定義)システム開発は要求分析(要件定義)というプロセスから始まります。要求分析(要件定義)は、顧客の要求を把握してシステム要件を確定することです。以下のような事項をまとめます。大変な作業は要件を整理すること、可視化することです。そのためにブレーンストーミング、問題要因関連図やフィッシュボーンダイアグラム(魚骨図)の作成など様々な手法を使います。要求仕様書の書き方は「IEEE830」で国際標準としても定義されています。ユーザとの仕様確認を目的に、業務の整理やデータ、画面レイアウトなどの「枠組み」を設計する作業になります。こちらのドキュメントの作成にあたってのポイントを解説します。業務の流れを可視化して把握する必要があります。流れをイメージしないで断片の組み合わせで作成されたアプリケーションは、運用に大きな落とし穴がある場合が多いからです。システム化の対象を明確に表す資料となります。システム開発対象となる機能を洗い出して、大分類(サブシステム)、中分類(機能分類)ごとに整理して一覧表にまとめています。種類に区分けをしています。機能一覧表は、システム化の対象を明確に表す資料となります。「機能一覧表」は、契約時に作成しておくドキュメントですが、下記のようにプロジェクトの段階でその情報が活用されますので、きちんと作成しましょう。後は、詳細設計を行います。基本設計は顧客向けにレイアウトなどの枠組みを作成したのに対し、詳細設計はプログラマへの説明向けにロジックなどの具体的な肉付けを行う作業になります。画面の遷移(展開)を図で表したものです。作成したドキュメントはそのまま(必要に応じて修正も加えて)利用され、さらに詳細機能を表すためのドキュメントを追加して「詳細設計書」となります。「項目説明書」を追加します。項目説明書は、基本設計で作成した画面/帳票レイアウトと対になるシートです。基本的にユーザのイメージ確認を主目的としますが、その情報だけでは画面を作成できません。そこで詳細設計フェーズで「項目説明書」を追加し、画面や帳票の各項目について必要な情報を記載します。画面や帳票の項目名は、わかりやすい日本語名で記載します。これらの「項目名」は、実際の画面/帳票の「コントロール名」と対比します。この2つは、ER図におけるデータベース項目の論理名と物理名の関係に似ています。プログラミング設計書ではないので、設計書上にコントロール名までは記載しません。コントロール名については、プログラミング規約を別途用意し、その中の命名規約に基づいてプログラマの裁量にまかせるという方針にしています。本稿では抜粋したものを紹介しましたが、さらに詳しく確認したい場合、下記に「即活用できる!設計書の書き方講座」資料をご用意しましたので、是非ダウンロードして自社の生産性向上に役立ててください。