意外と作れない基本設計の目次構成

プロジェクトマネージャになったとき、流石に失敗したいとは思わないのでどうすれば成功できるか、そのために何をプロジェクトマネージャになる前から準備しておけばいいかを考えていた時期がある。

結果的にそれは後に生きたわけで、そうした準備は必要で頭の中で考えるだけ絵ではダメだと実感することになる。

とはいえ、準備できることとできないこともある。そこの分界点と準備しないことで何が起きるかは自覚しておかなければならない。

プロジェクトマネージャなのだからプロジェクトマネジメントを一生懸命準備しても意味はない。ここに気づくこと。

誰と何を成し遂げるか。

その誰に、何を伝えるか。

成し遂げる対象は、準備をする時点で何も決まっていない。

アサインされていないのであるから当たり前。

そこでできることはシステム開発手法の作業標準、つまり、どのように進めるかの段取りのモデルを作っておくこと。

ウォーターフォールなら工程（局面）と中身のWBSのアクティビティ。

アジャイル開発ならどの開発方法かとその中身のアクティビティ。

さて、アクティビティはどうするか。

特にウォーターフォールなら目次構成の雛形は必須である。

特に基本設計（外部設計）が重要。

インプットの要件定義は基本設計の要件としてカバーしていればいいので逆に作れる。

詳細設計は基本設計で決めたシステム方式でカバーしていれば抜け漏れは防止できる。

目的、概要、論理構成、物理構成、機能仕様、非機能仕様、セキュリティなどで構成する。

このレベルでは荒すぎるのでもう1つくらい詳細化しておく。

機能仕様は業務の機能を分解するので内部の目次構成は同じになる。

非機能仕様は多岐にわたる。セキュリティはここに含める方が良いかもしれない。

作業の結果は、成果物か提出しない内部のアウトプットか何も残さないのどれか。

字工程（後続のアクティビティ）のインプットにならなくてそれでも必要ならメモ程度にする。

特に要員計画で工程の途中からエンジニアを入れる場合、検索可能なプロジェクトのリポジトリを用意し、タグをつけて放り込んでおくこと。

それだけかとここまで引っかからずに読めていたとしたら、それはもともとスキルが高いか、怖さを知らないのどちらか。

基本設計の目次をレベル3くらいまでスラスラ作れるか。

過去の経験でインフラからアプリ、システム運用をカバーできるかどうか。

経験ベースで作ろうとしたら、インフラ視点かアプリ視点のどちらかが欠損する。

今はブログやIPAの資料を探して自分なりに整理し、作る目的を理解できればいいので、載っているから作るではなく、必要なものを選べる方が重要。