想定プロジェクトでは，多くのサーバーやミドルウエアが使われる。OS，Web/APサーバー，データベース，負荷分散装置などだ。プロジェクト内にこれらの製品のうちひとつでも利用経験者がいなければ，スケジュールは見直しを迫られる可能性が高い。使用方法を取得するのに多くの時間を要するからだ。多くの残業，休日出勤を招くことになり，納期にも影響を及ぼす。
スキルマップの整備が不可欠
 図7●スキルマップの例 [画像のクリックで拡大表示] |
プロジェクトと技術者をうまくマッチングするには，社内での分野別スキル保有者リストが欲しい。スキル保有者がいなければ，社内からの協力を仰ぐといった運用が可能になる。
スキル評価の方法は，一般的には大分類から小分類へツリー構造で細分化していくのが使いやすい（図7）。
大分類としては「技術」「業務知識」「マネジメント」の3つが標準。技術なら「ハード」「ネットワーク」「OS」「開発言語」など中分類に分け，さらに開発言語なら「Java」「VB」「VC」など小分類に分けていく。
技術の評価は5段階で行う。
5：プロジェクトでの使用実績が豊富で勉強会の講師ができる
4：プロジェクトでの使用実績があり，メンバーに指導できる
3：独力で使用できる
2：マニュアルまたは指導を受けながら使用できる
1：概要把握のレベル
評価は自己申請を基本とし，上司や専門の委員会などによる客観的な評価ができればベスト。プロジェクトのメンバーが固まったら，評価5または4の人を講師にして社内勉強会（ナイトスクールなど）を行う。できる限りプロジェクト開始までに済ませたい。
間に合いそうになければ，勉強会の予定を加味してスケジュールを変更することを考える。メンバー確定時点でスキルを把握できていれば，どの程度の影響が出るか見当を付けやすい。
評価1と2は0.5人分
もっともこれは理想で，現実には新人の頭数を揃えたような弱い体制しか作れないことも多い。そういう場合は，以下のように判断する。
まず，1人×1カ月＝1人月と見積もるのは，スキルが「3（独力で使用できる）」以上に限定する。評価1～2の場合は，1人を0.5人分とカウントして，2人×1カ月＝1人月と見積もる。それで増員を図る。経営者やPMO＊8との交渉力が求められる。
開発規模によって，このリスクは上下しがちだ。最も危険なのが，想定プロジェクトのような50人月程度のプロジェクトだ。10～20人月程度のプロジェクトでは，優秀なマネージャや開発者が入れば，1人で全体のスキル不足を何とか補える。反対に500人月規模なら，経営に対する影響も大きいため，優秀な開発者を確保するための会社からの支援が期待できる。
ところが50人月程度のプロジェクトは，大きなプロジェクトである割に全社的なサポートを期待しにくく，優秀な開発者を確実に確保することが困難なのだ。
そこで，まずはマネージャの配下に開発に必要なスキルをもったリーダー・クラスのキーパーソンを何としても確保することを最優先に考える。
また，想定プロジェクトのようなソフト開発のみの受託開発だと，技術的なリスク要因がある場合，ソフト開発者のみで解決を図ろうとすることが多い。しかし，ハードやネットワーク技術者に相談したり，支援したりしてもらえる体制を事前に組んでおくことが重要である。
例えば，ハードやネットワークの技術者にレビューアとしてプロジェクトに参画してもらう。またハードが外部購入品でノウハウが社内にない場合などは購入先の技術サポート部門に事前にお願いする。市販品でない特注のハードや海外メーカーのハードは，有償でサポート契約することも考える。
|
町田 仁司 |
