社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

プロジェクト計画書の書き方:開発方針

プロジェクト計画書の書き方の説明です。

第三回は、開発方針(開発手法、技術、テスト環境、パッケージのカスタマイズ方針等)の説明です。

1.開発方針

システム開発をどのようなルールで行っていくかを記載します。

ウォーターフォールなのかアジャイルなのか

ウォーターフォールの場合、プロトタイプはどの程度作成するか

・パッケージであればカスタマイズをどの程度、許容するのか

・QCD のうち、どれを最優先とするか

といった感じです。他にも

ブラウザー固有の関数の利用を許可するか

・ストアドプロシージャの利用を許可するか

・自社のフレームワークを利用すること

・自社のコーディングルールに準拠すること

・開発ツールの指定

など。

ただし具体的になればなるほど、非機能要求と重複してくるので、重複する分は重要なものだけを記載するのが良いです。

あくまでも「方針」なので、プロジェクトメンバーが常に念頭における程度の分量に絞るのが望ましいです。

2.開発方針(環境)

どのような環境を使って開発をしていくかを記載します。

これはマスタースケジュールや工程定義、全体テスト計画とも密接に関わるので、とても重要です。

何を先に決めるかはプロジェクトによって異なりますが、上記のような環境の利用方針と、サーバー環境の構築スケジュールは一致させる必要があります。本番環境を先に作って、テスト環境をその後に作るようなスケジュールだと、テストで利用する環境と整合が取れません。

また環境に依存する可能性のあるテストを単体テストで実施する計画にしてしまうと、PC環境とサーバー環境との違いがテストに影響が出てしまうかもしれません。

作業場所も重要です。ベンダーのオフィスからのリモート接続が許されているのか、発注者が自社オフィス内にベンダーの作業場所を用意するのか。後者の場合には、発注者とベンダーの双方に負担が生じます。

また最近ではクラウドを利用することが多くなってきているので、結合テストまでをベンダーのサーバー環境で行うケースも増えてきています。どんなテストをどの環境で行うかは、プロジェクトの最初にベンダーと合意しておく必要があります。だたし費用にも直結する話なので、ベンダーと揉めないためには、極力、RFP に記載することが望ましいです。

【振り返り】

今回はプロジェクト計画書に記載する開発方針の説明でした。次回はマスタースケジュールと工程定義の説明です。

①プロジェクト概要(目的、背景、範囲、特徴、前提・制約事項等)
②開発方針(開発手法、技術、テスト環境、パッケージのカスタマイズ方針等)
③マスタースケジュールと工程定義
④プロジェクト体制と役割分担
⑤工程管理基準と会議体計画
⑥プロジェクト管理ルール