プログラムを立ち上げるとき、最初に決めるのが「いくつのプロジェクトに分けるか」です。ここでの切り方が、その後1年以上の動かしやすさを決めます。

よくあるのが、工程で切る方法です。要件定義を1本、開発を1本、テストと移行を1本。分かりやすく見えますが、プログラムとしてはうまく動きません。

■ 工程で切ると、何が起きるか

工程で切った場合、最後まで何も使えません。つまり、成果が出るのは全部終わったあとです。

これは3つの問題を生みます。

• 途中で効果を確認できない。うまくいっているか分からないまま1年が過ぎる

• 1本でも遅れると、後ろが全部止まる

• 予算を削られたとき、削れるのが「テスト」しかない

3つ目は実際によく起きます。「予算が2割減りました」と言われたとき、工程で切っていると、品質を落とす以外に手がありません。

■ 成果で切ると、判断ができる

一方、成果で切ると、それぞれのプロジェクトが要件から稼働までを含みます。期間は短くなり、終わった時点で何かがよくなります。

この形なら、途中でこういう判断ができます。

プログラムマネジメントの価値は、こうした組み替えができることにあります。切り方を間違えると、その価値がなくなります。

■ 切るときの3つの基準

3つ目が、実はいちばん厳しい基準です。「止めたら全部が無駄になる」なら、それは独立したプロジェクトではありません。1つの大きなプロジェクトの一部です。

■ 分けすぎにも注意する

逆に、細かく分けすぎる失敗もあります。プロジェクトが10本を超えると、今度は管理そのものが重くなります。

目安として、1本あたり3〜6か月、全体で4〜7本。この形に収まれば、たいていうまく回ります。

■ 共通基盤をどう扱うか

悩ましいのが、複数のプロジェクトが使う共通部分です。認証の仕組み、データ連携の基盤など。これ単独では効果が出ませんが、なければ他が動きません。

扱い方は2つあります。

• 最初のプロジェクトに含める：PJ1の中で作り、PJ2以降はそれを使う。責任がはっきりする

• 独立した「土台」として置く：ただし効果が出ないので、成果の評価対象からは外す

おすすめは前者です。共通基盤を独立させると、「誰のためでもない作業」になり、優先順位が下がって遅れがちになります。最初に使う人が作るほうが、現実に合った物ができます。

■ まとめ

構成プロジェクトは、工程ではなく成果で切る。基準は「これだけ終わったら何かよくなるか」。本数は4〜7本、1本3〜6か月を目安にします。

いま手元にプログラムの構成図があるなら、各プロジェクトについて「これだけ終わったら何がよくなるか」を一言で書けるか試してみてください。書けない箱があれば、切り方を見直す価値があります。