【PMBOK第8版】財務のテーラリングとは？内製・外注の判断と受注側が身を守る「予備費」の考え方

プロジェクトの「お金のルール」、現場に合わせて着替えていますか？

PMBOKを学んでいると、「テーラリング（Tailoring）」という言葉が頻繁に登場します。洋服の仕立て（テーラー）が語源で、要するに「プロジェクトの規模や状況に合わせて、管理の手法やプロセスを適切に調整（カスタマイズ）しましょう」という意味です。

これは「財務（お金）の管理」においても例外ではありません。数百億円規模の国家プロジェクトと、数ヶ月で終わる社内システムの改修とでは、お金の監視レベルも予算の組み方も全く違って当然ですよね。

今回は、PMBOK第8版の「財務パフォーマンス領域におけるテーラリングの考慮事項」について解説しつつ、日本のIT実務で最も直面しやすい「発注側と受注側の立場の違い」から、現場でどうテーラリングを活用すべきかを私の実体験を交えて紐解いていきます^[1]Project Management Institute, Inc., The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition, 第2部 … Continue reading。

PMBOK第8版における「財務テーラリング」の5つの考慮事項

PMBOK第8版では、すべてのプロジェクトが固有の環境で実行されるため、財務管理も状況に合わせて調整すべきだとし、その際に検討すべき5つの主要な観点を挙げています。

また、PMBOKでは財務テーラリングの具体例として、「頻繁な調整が求められる適応型（アジャイル）プロジェクト」「財務的柔軟性の限られた小規模プロジェクト」「高い説明責任が求められる政府セクタープロジェクト」の3つが紹介されています。

日本のIT現場で真っ先に直面する「メイク・オア・バイ」

さて、PMBOKには様々な考慮事項が書かれていますが、日本の実務において私たちがまず最初に気にしなければならないのは、「5つの主要な観点」の3つ目、「調達戦略（内製か外作か＝メイク・オア・バイの判断）」です。

IT関係のプロジェクトにおいて、自社がシステム開発を専門とするIT企業でない限り、多くの場合が「外作（外注・バイ）」を採用することになります。社内に専門のエンジニアやインフラがないため、外部の制作会社やSIerに依頼してシステムを作ってもらうケースです。

実は、この「外注する」という判断を下した瞬間に、プロジェクトの財務管理（テーラリング）のあり方は、発注側と受注側で大きく真っ二つに分かれます。

発注側と受注側で異なる「財務管理のリアル」

発注側：財務の監視は「楽」になる

外注（請負契約）の場合、発注側としては、初期の見積もりで契約した発注金額から超過しなければ、基本的に金銭的な不利益を被ることはありません。

「このシステムを1,000万円で作ってください」と契約した場合、開発が難航して相手の開発会社のコストが1,500万円かかってしまったとしても、発注側が支払うのは原則1,000万円のままです。（もちろん仕様の追加変更があれば別ですが）。
そのため、発注側のプロジェクトマネージャーにとっては、日々の細かな原価管理をする必要がなくなり、財務の監視という点では非常に「楽」になります。

受注側：固定予算内で戦うための「予備費」が命綱

一方で、開発を受託した側（受注側）はシビアです。提示した見積もり金額（売上）の中で、なんとかプロジェクトを完遂させなければ自社の赤字になってしまいます。

ここで非常に参考になるのが、「財務テーラリングの3つの具体例」に挙げられていた「財務的柔軟性の限られた小規模プロジェクト」の考え方です。
請負契約は、まさに「契約金額が決まっていて予算の融通が利かないプロジェクト」の典型です。このような状況下では、プロジェクトを安定させリスクを軽減するために、コンティンジェンシー予備（不測の事態への備えとしての予備費）をしっかりと組み込んだ保守的な予算編成が極めて重要になります。

実践ステップ：受注側PMが身を守るための確認事項

もしあなたが受注側（制作会社側）のプロジェクトマネージャーになった場合、「いかに見積もりの段階で正しくテーラリング（調整）できているか」が勝負の分かれ目になります。

以下のポイントを、プロジェクト開始前に必ずチェックしてみてください。

1. 「見えない作業」が工数から漏れていないか？
   純粋なプログラミングの時間だけでなく、要件定義のヒアリング、テストのやり直し、会議の準備、レビューの手戻りなど、付帯する作業時間は見積もりに含まれていますか？
2. コンティンジェンシー予備（バッファ）は積まれているか？
   「すべてが順調にいけば1ヶ月で終わる」という理想ベースの見積もりは危険です。「未知の不具合が出た場合」「仕様の解釈にズレがあった場合」を想定した予備費（工数のバッファ）が、全体の10〜20%程度組み込まれているかを確認しましょう。
3. 前提条件を明確に合意しているか？
   「この金額で対応できるのは、〇〇の範囲までです」というスコープの境界線を、発注者と明確に合意（文書化）しておくことが、後のコスト超過トラブルを防ぐ最大の防御策になります。

まとめ：自分の立場に合わせて管理手法を「仕立て直す」

PMBOKが教える「テーラリング」とは、難しい理論をすべて適用することではありません。「自分が発注側なのか受注側なのか」「予算は追加できるのか固定なのか」という現在の立場と制約に合わせて、どこを最も厳しく管理すべきかを見極めることです。

発注側であれば、予算の監視が楽になる分「本当に自社が欲しい価値が定義できているか（価値の定義）」に注力すべきですし、受注側であれば「予備費の確保とスコープの死守（資源と調達戦略）」に心血を注ぐべきです。
プロジェクトの特性に合わせて、ぜひご自身のマネジメントスタイルを「テーラリング」してみてください。

「社内でシステム開発を外注することになったが、制作会社から出てきた見積もりに予備費が適切に含まれているのか、あるいはバッファを積まれすぎていないか妥当性がわからない」といったお悩みを抱えるご担当者様は、少なくありません。
もし、外部業者とのやり取りや見積もりの妥当性に不安を感じる場合は、SSAITSのセカンドオピニオン相談もご活用ください。第三者の専門的な視点から、プロジェクトを安全に進めるためのアドバイスをさせていただきます。