ポートフォリオ的スケジューリング

株というか投資の世界では、ポートフォリオという言葉がある。非常に適当に説明すると、多面的に株とか国債とか外貨とか現金とかをバランスよく取り混ぜて、全体のリスクを分散させて安定的に資産を管理しましょうということだ。

昨日の続きになるが、１つのプロジェクトだけで考えた場合、スケジュールの遅延リスクを回避しようとすると、そのプロジェクトにバッファを設けないといけないということになる。

ただリスクというのはどれもこれもが具現化するわけではないので、全部をスケジュールに組み込むのは現実的な解とは言えない。そこで上記のポートフォリオをソフトウェア開発のスケジュールに適用できないかどうか考えてみる。

要するに、複数のプロジェクトをポートフォリオとして構築し、ポートフォリオ内でリスクを管理するという手法である。１つ１つのプロジェクトは少しずつバッファを持たせておいて、もしもの時には、プロジェクト間でリソースとバッファを流動させることで対応するのである。

１つのプロジェクトを１つのチームで行うより、３つのプロジェクトを３つのチームで行った方が、バッファ分のオーバーヘッドが少なくなり、競争力が増すという考え方である。

ここだけ見ると当たり前のように思われるかもしれないが、ソフトウェア開発プロジェクトというのはは、えてして同じ会社でもプロジェクト間のリソースの共有化というのが少ない。終わったら別のところに入るというのはあっても、途中でヘルプに入るというのはよっぽどの場合に限られる。

それを、会社レベルでもう少し流動的にリソース（モノ、人、金）を動かすことができれば、スケジュールの遅延がなくなるのではないだろうかと思う。

そのためには、各プロジェクトの納期が少しずつずれるようにコントロールする交渉力と、スタッフのスキルが分散しないように少なくとも同じ言語で似たようなフレームワークが使える仕事を取ってくる営業力が必要だ。

つまるところ、１つでっかい仕事がきたから、わーいと言ってみんなで開発するというようなお子様チックな会社ではだめだということだ。継続的な営業力、技術に裏付けされた見積力、納期に間に合わせる開発力、仕様や納期や金額の交渉力と、組織の力を最大限に発揮できるスタッフを集めないといけない。

ソフトウェアを開発するだけで大儲け、と思っていたが、世の中そんなに簡単ではないようだ。相手が理解してくれたらなぁと嘆くのではなくて、自社の力を向上させて、相手に心から納得させられるような、そんな組織を目指していかないと、疲労とストレスでやってられなくなる。

プログラマというのは生涯現役でもやっていける職業だと思うので、もう少し職業の中身を充実させていければいいなぁということで。