【技術関連】今日からPM（要件定義②）

オハヨウゴザイマス！
あにきです。

早速題名が揺らいでいますが、シリーズ第二弾。
前回は大雑把な章立てとそれの結びつきについて記述しました。

今回はヒト・モノ・カネのうち、ヒト・カネにまつわる部分を私の経験則上どうしているのか？というところにスポットを当ててみたいと思います。

要件定義に至るまでには、ひじょーーーーにザックリとですが
・事業計画（企画）
・予算計画、調達計画
・RFI発出、RFP発出
・RFPから超概算取得
と順序は兎も角ステップを踏むのですがここにある「超概算」なる言葉が我々を苦しめます。
見積もりの前提条件に必ずと言っていいほど「本お見積りは概算見積もりとなります。要件定義後再見積もりとさせて頂きます。」と書くのですが、ここで提示した概算金額で予算を組んじゃうユーザーの多いこと多いこと。。

前章で記述したとおり要件定義では本見積もりに至る、ビジネス面、業務面、機能面、非機能面、そして運用面が記述され各々に要員が配備され本当の予算が決定するのですが、「概算の時点で予算確定！！」「予算を超えることはまかりならん！！」という状況が勝手に生まれることも。

そういった状況下でどのくらいの人員をどうやって投下していくのか、予算はどうやって守るのかを今回は書いてみます。（ちょうど、後輩君から話があったので）

前提条件として「概算時に予算が確定している」ことを想定すると。投下人員は少ないに越したことはありません。ですので、何名と固定するのではなく、スモールスタートアップをします。

私の場合は自分である程度執筆できてしまうので、規模に関わらず自分（PM）＋後の開発リーダー。この２名で要件定義を開始し、規模に応じ増員体制を整えます。このとき記述する内容はあくまで概算を弾いた前提に基づき「兎に角書き上げ」ちゃいます。（想定しても書けない章はブランクで）

また、会議体をこの時点で組み上げる事も忘れずに。（これも規模に応じますが、ビジネス面での定例会、業務面での定例会、システム面での定例会など分科会を開くと吉です。）

会議毎に資料をブラッシュアップし、「詳細化できるな～」ってなったら人員を投入します。その塩梅は大体１億円規模で１ヶ月程度が目安でしょうか。

問題は投入された人員に対するインプットとある程度提案も伴う要件定義工程での成果物品質のバラツキです。

ここからは私のずるいところですが、先ずは各人員のスキルセットや日頃のアウトプットレベルを見て実スケジュールを引きます。その後は、
・必ず予備日を実稼働の２割程度は見込む（本来１０人日のところ１２人日とする）
・アウトプットを腹持ちさせない（ローカルに置きっぱなしにさせない）
・粒度や図書としての製本は最後に
・メンバー自身で書いた部分は本人に会議体で説明させる（勿論フォローは忘れずにやりますが）
この中でも忘れがちなのがアウトプットを腹持ちさせちゃうことですね。出てきてびっくりは避けたいものです。（勿論、中間レビューはしますが）
日々、書いたものは共有させます。

それと私的に重要なのがメンバーには「予備日を見せない」ことです。
アウトプットの締切が打ち合わせでの発表だとすると最終ビューを前々日位には依頼しておくのですが、10作業日が必要となった場合内部レビュー日は8日目、お客様レビューは12日目ということになります。この4日間で品質を上げたり、もし書き直しだったら書き直す時間を確保できます。

この場合の予算ですが、当然「その後の工程も含め予算がFIX」されているわけですから、なるべく後工程を考えると抑えたいところです。
ですので、分科会ごとに人員を割り当てたらそこから増員させない事を念頭に。多い場合は下記の分科会が開かれます。
・ビジネス分科会・・・CTO等を交えた分科会
・業務分科会・・・・・実業務を担う部署を交えた分科会
・デザイン分科会・・・UI／UX主体の分科会
・情シス分科会・・・・システム面（特に非機能）での分科会
・運用分科会・・・・・システム運用に関わる分科会（主にDC担当や情シス）
PMは全ての会議体に出席しつつ自筆しメンバーの稼働・品質管理を行うのでどうしても高稼働になりがちですが、ここで基本設計レベルの要件定義書が書けてしまえばこっちのものです。

余った予算は外部結合移行のバッファに取っておけるようにハンドリングするのが常套かと思います。

今回は浅めにコスト・リソース（人員）コントロールに言及してみました。ではまた次回にー。

ではでは。