プロジェクトの人的資源管理

D社は，首都圏近郊の不動産会社と提携して，不動産情報サイトを運営している不動産情報サービス会社である。D社は，一般利用者向けのサービス向上を狙いとして，地図情報サービスとの連携対応，スマートフォン対応などの開発を，半年前から行っている。

今回，提携先における不動産情報登録業務の利便性と情報鮮度の向上を図ることにした。同業務に必要な画面の大きさと携帯性を併せもつ，カメラ付きのタブレット型PC（以下，タブレットという）から，写真を含む物件情報の登録・更新を行う機能を追加開発するプロジェクト（以下，追加開発プロジェクトという）を立ち上げた。追加開発プロジェクトは，提携先からの強い要望によって，6か月での完了が必須となっている。また，投入できるコストや人員も限られている。プロジェクトマネージャに任命された開発部のE主任は，追加開発プロジェクトの人的資源計画の策定に着手した。

プロジェクトメンバの要求

E主任は，追加開発プロジェクトで重要となるスキルを次のように列挙した。

1. 不動産会社における，物件情報の収集と登録・更新の業務知識
2. タブレット特有の操作や入出力などのユーザインタフェース（以下，UIという）設計のノウハウ
3. 最近実用段階に入った，Webアプリケーションによるカメラ制御と写真取込み機能（以下，Webアプリによるカメラ制御という）の実装方法や制約などの知識

E主任は，追加開発プロジェクトのスケジュールを作成し，工数を見積もり，これらのスキル要件を加味したメンバの選定依頼を，開発部の要員調整会議に提出した。

メンバの選定と追加開発プロジェクトへの指示

要員調整会議を踏まえた社内外との調整の結果，E主任の指定したそれぞれの重要スキルを保有した，次のメンバが選定された。

• 営業部Fさん：不動産会社から転職してきたベテランの営業員で，物件オーナから様々な情報を聞き出すのが得意である。また，情報の登録・更新の業務にも詳しい。
  ただし，システム開発に携わった経験はなく，追加開発プロジェクトで予定している成果物を作成した経験もない。
• 社外の技術者N氏：現在行っているスマートフォン対応の開発に，ソフトハウスM社のリーダとして参画して，高い評価を得ている技術者である。業種は異なるが，他社でのタブレット対応の実績がある。ただし，スマートフォン対応の開発との兼務になるので，担当することができるのは，成果物のレビューや参考資料作成などの支援的な作業に限られる。
• 開発部G君：開発部の若手プログラマで，最新の技術動向に詳しい。インターネット上の有用な情報を収集して，新しい技術を社内のシステムに取り込んだ実績が多数ある。

また，開発部の中堅SEであるH君もメンバとして選定された。H君は，PC画面であれば，UI設計に精通しているので，外部設計を1人で期限内に何とか完了できる。しかし，タブレットUI設計については，H君を含め，社内にノウハウをもつ者はいない。

写真入力画面以外の内部設計・製造・テスト（以下，開発1という）は，請負契約でM社に発注することが決定し，責任者はN氏となる予定である。Webアプリによるカメラ制御は，D社では利用した実績がない。D社と取引のあるベンダ各社にも利用実績がないので，写真入力画面と，サーバに送付した画像を他の画面から参照するためのAPI開発（以下，開発2という）は，社内で行うことにした。

なお，要員の選定の際に，追加開発プロジェクトに次の指示が与えられた。

• 利用実績がない技術に対しては，相応の準備工程を置いて，実現性を担保すること
• 近々発足する複数のプロジェクトでタブレット対応が予定されているので，それらのプロジェクトで活用できるような成果を社内に残すこと

工程とスケジュールの考慮

E主任が，N氏に，外部設計準備として，①タブレットUI設計標準の作成を打診したところ，"他社でタブレット対応を行った際は，設計標準がなく，2か月間試行錯誤を重ねて苦労した。今回はそのノウハウがあるので，スマートフォン対応向けに作成した資料をタブレット対応向けに書き直すことで作成可能である。"との回答を得た。

E主任は，タブレットUI設計標準の作成に加えて，外部設計におけるUI に関するレビュー，及びH君への支援もN氏に依頼することにした。

Webアプリによるカメラ制御は，追加開発プロジェクトの鍵になる技術である。D社で利用した実績がないので，E主任は，開発準備の工程を追加してG君にある作業を割り当て，外部設計開始直後から作業させることにした。

E主任は，これらの検討結果を，図1のスケジュールに反映させた。

責任分担の整理

D社では，中規模・小規模のシステム開発を複数並行して進めることが多い。プロジェクトのメンバは，開発部員と社内の他部門や社外要員との混成になることが多く，上下関係が複雑と逆転する体制になる場合もある。そのような状況を踏まえて，開発部では，プロジェクトの作業ごとの役割，責任，権限レベルを明示するために，責任分担マトリックスの一種であるRACIチャートの作成を必須としている。

なお，D社では，PMBOKを参考に，プロジェクトでの実用性を考慮し，RACIの略号を次のように定義し直している。

R (Responsible): 実行責任：作業を実際に行い，成果物などを作成する。

A (Accountable): 説明責任：作業を計画し，作業の進捗や成果物の品質を管理し，作業の結果に責任を負う。

C (Consult): 相談対応：作業に直接携わらないが，作業の遂行に役立つ助言や支援，補助的な作業を行う。

I (Inform): 情報提供：作業の結果，進捗の状況，他の作業のために必要な情報などの，情報の提供を受ける。

これまでの検討結果を基に，E主任は表1のRACIチャートを作成した。

E主任は，メンバ全員を集めた追加開発プロジェクトのキックオフ会議を開催し，表1のRACIチャートを使って，各工程の作業内容と責任分担を全員に説明した。