この記事は、「架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）」の記事の一部です。
ITプロジェクトのプロセスについて
ITプロジェクトを理解するにはまずITプロジェクトの標準的なプロセスを理解する必要があります。
ITプロジェクトに限らず、ビジネスの各種業務には凡そ標準的なプロセスがあり、各プロセスにおいてそれらを管理したり、進捗させたりするための関連ドキュメントが存在しています。
ITプロジェクトの場合、それ特有のプロセスが存在するというより、要件定義→設計→開発→テストといったいわゆる開発プロセスと、見積→稟議→発注→納品→検収→請求といった一般ビジネスプロセス（受発注プロセス）が融合した形となっていて、関連するドキュメントもそれらを融合したものになっていますので、それぞれのプロセスを少し解説します。
開発プロセス
開発プロセスとは開発を進める工程（順序）のことです。開発プロセスにも「ウォーターフォール型」、「アジャイル型」、「スパイラル型」、「プロトタイプ型」等、各種存在していますが、実際の業務現場でよく見かけるのは、以下の２つです。
- ウォーターフォール型
- アジャイル型
ウォーターフォール型プロセスは、水が落ち流れるように要件定義→設計→開発→テストという順序で開発を進めるプロセスで、アジャイル型は一定に区切られたこまかな開発（イテレーションとかスプリントとかいいます）を繰り返し行っていくプロセスになりますが、アジャイル型においても、その繰り返される開発行為の中で、（要件定義）設計→開発→テストを繰り返す形となりますので、ウォーターフォール型が開発プロセスの基本とも言えます。ここではウォーターフォール型プロセス前提として話を進めます。
なお、ウォーターフォールでもプロセスの区切り方などは会社やプロジェクト毎に異なり、絶対的な基準が存在するわけではありません（補足も見てね）。
アジャイル型もさらにXP、スクラム、それらの融合等、いくつかに分類できますが、ここでは触れません。興味のある人はググってね。
一般ビジネスプロセス（受発注プロセス）
ITプロジェクトを円滑に進めるためには開発プロセスの理解のみでは不十分で、周辺業務のプロセスも合わせて理解しておく必要があります。必要となるビジネスプロセスは状況により異なりますが、開発業務を外注する場合などには、見積→発注→（開発）→納品→検収→請求といったいわゆる受発注プロセスおよび関連ドキュメントを理解しておく必要があります。
改めてITプロジェクトのプロセスとは？
本コンテンツではITプロジェクトのプロセスおよび必要なドキュメンを以下のように定義し、話を進めます。
なお、ITプロジェクトで作成するドキュメントはだいたい決まってはいるものの会社やプロジェクトにより異なるので、どのようなドキュメントをどのような方針で作成するかは、プロジェクト計画書や要件定義書等で定義しておくのが無難です。
ちなみに本コンテンツにおいてはプロジェクト計画書にて成果物一覧として定義しています。
補足
いろいろ存在するプロセス
デジタル・ガバメント推進標準ガイドライン 実践ガイドブック においても、各種プロセスが異なることが紹介されています。
必要なドキュメント
デジタル・ガバメント推進標準ガイドライン 実践ガイドブックでは、以下のドキュメントテンプレートが提供されています（本コンテンツで提供するドキュメントとの対比も記載）。
政府の調達を前提としているので、民間ではあまり見られない要領（ルール等を記載したもの）や調達、監査などのドキュメントが追加されているのがわかります。
民間？では要領は別途作らず、各種ドキュメントに含めてしまう印象です。
なお、民間の参考資料としてはTISさんが運営するFintanの開発プロセス関連の資料も参考になります。
ドキュメントという視点での整理はないですが、プロセス毎の役割分担、合意事項などが整理されています。各役割や合意に関連するドキュメントが必要という見方もできますので、興味のある方は見てみてください。特に「ウォーターフォール開発における役割分担シート」の小項目は「決めないといけないこと」のチェックリストになるかと思います。