プロジェクトにおける外部リソースの考え方

請負を業として受けているWeb開発会社にとって、一定以上の大きなプロジェクトをまわすときに外部リソースの活用は避けて通れません。
請負案件には波があり、大きな波にあわせて内部人員を確保してしまうと、波が小さくなった時にくる固定費によって会社が傾きます。

外部リソースの活用方法は各社ナレッジを溜めているかと思いますが、弊社も実体験をもとに知見をためていますので、今日は少しその一端をお披露目できればと思います。

外部リソースは使わざるをえない

まず、「外部リソース」という言葉についてですが、これは「自社と雇用契約していない、外部の人員」のことを指し、それには派遣会社の人員や、SESの人員、フリーランスなどを含みます。
なので、自社の正社員や契約社員はもちろんのこと、社内バイトやインターンなども雇用契約があるため、この定義の対象外となります。

特にこの文脈で使う外部リソースは、開発会社のプロジェクトで活躍してもらうことを前提としていますので、ほとんどは「ITエンジニア」のことを指します。人月商売で出入りする外注エンジニアさんたちに、どう活躍してもらうか、という話をしていきます。

さて、冒頭で請負案件のことに触れましたが、請負を扱っているWeb開発会社にとってこの外部リソースの活用は死活問題です。
2026年5月現在、ITエンジニアの人月単価はかなり高く、下は80万から上は200万を超える方もいらっしゃいます。一定規模以上のプロジェクトは成功させることも難しく、変に単価をケチるとプロジェクトがぽしゃって大変な損失が発生するため、高いとは思いつつも開発会社は単価の高いエンジニアさんに仕事をしてもらいます。

しかし、開発会社の仕事は常に一定で動いているわけではありません。もしこの単価の高いエンジニアを内部にかかえ、大きなプロジェクトがおわって次のプロジェクトまで半年ほど空くとなったときも、会社はこのエンジニアに対して同じ額を渡さなければなりません。
これは空稼働といわれる状態ですが、売上もたたないのに毎月200万もの費用が固定費として出ていくとなると、その会社のキャッシュフローが瞬く間に傾いていきます。

なので、開発会社は耐えられるリスクに応じて内部リソース（プロパーともいいます）と外部リソースを使い分け、安定した経営を目指して波のある請負案件をこなしていく必要があるのです。

開発会社によって外部リソースの建て付けは違う

外部リソースの使い方は、開発会社によってさまざまです。
中にはプロジェクト全部を外部リソースにだし、運用からプロパーでまわすという戦略をとっている場合もあります。
ただ、自分のこれまでの実体験として多いと感じるのは、上流工程や上流職（PMやPMO）に関してはプロパーを使い、作業に近い部分に関して外部リソースを使うという体制の組み方です。

この体制のいいところは２点です。
まず、責任の所在が明確になります。上流でプロパーが動いているため、クライアントは安心してプロジェクトの相談ができるようになります。また、外部のエンジニアも、プロパーが上流にいた方が話が早いため動きやすくなります。
もう１点は、上流ノウハウの蓄積です。多くのプロジェクトにとって価値が高いのは上流であり、そのノウハウが貯まることは会社の価値をあげることにつながります。

これは言い換えると、構築をすべて外部リソースで構築した場合、会社内にそのノウハウが蓄積されないことを意味します。そのプロジェクトが解散してプロジェクトメンバーがいなくなり、次のプロジェクトが始まったときにはその前のプロジェクトで得た知見、経験は引き継がれません。

もちろん、上流を担えるエンジニアは単価が高くなりますので、上記で解説した固定費のリスクがでるため、この体制を嫌う開発会社もあります。
そのあたりは開発会社のスタンスがでるかな、といったところです。
まあ、今は上流ができるエンジニアが希少なので、この体制をやりたくてもやれない会社も多そうですが。

エンジニアの書類審査とレベル感

体制の方針がきまると、次は外部エンジニアの発掘です。
フリーランスのエンジニアの方で、すでに発注した経験がある方がいる場合、かなり優先度があがります。その理由は後々お伝えしますが、一度一緒に仕事をした縁は本当に大切にした方がよいです。

次に選択肢に上がるのは派遣会社のエンジニアで、最後の選択肢としてSESのエンジニアです。
派遣会社とSESは何が違うのかと言いますと、契約形態が違います。
派遣契約の場合は、開発会社の社員が直接指示をして作業をしてもらうことができます。一方、SES（System Engineering Service）は業務委託契約を指し、時間単価の準委任契約が採用されることが多いです。業務委託契約の場合はエンジニアに直接指示することができず、必ずSES会社を通して指示をする必要がでてきます。（業務委託契約なのに直接指示をしてしまうと、偽装請負になりますので注意してください。）
間に会社を挟むことになりますので、コミュニケーションコストがあがることになります。

開発のプロジェクトを請負で実施する場合、細かな指示ができる派遣契約の方がやりやすくメリットは大きいですが、その分単価感があがります。
また、派遣契約の場合は会社の格をみられて断られる（与信で落ちる）なんてこともありますので、泣く泣くSESで対応するなんていうこともあったりします。

派遣契約、SESともに、まず行われるのは書類審査です。
これまでやってきたプロジェクトやスキルセットをみて、今回のプロジェクトにハマるかどうかを検討します。
弊社の場合、この検討をする前にプロジェクト全体の予算を組み立てていて、必要なエンジニアの人数、レベル、予算を決めています。例えば特定の機能にかかる工数をミドルクラスレベルで10人月と見積もった場合、それに見合う人員を探す、という動きになります。
なのでまずはこの書類上の情報をみながら、今回のプロジェクトに入った時の期待値を想像します。

エンジニアのレベル感にはジュニア、ミドル、シニアなどのざっくりした区分けがありますが、このあたりの定義は会社によってまちまちです。
弊社では大体次のような単価感で設定しています。

もちろん、10年エンジニアをやっていたとしてもまともにコードがかけなければジュニアクラスですし、3年目でも設計までできるならシニアクラスとして考えます。年数や単価はあくまで目安と捉えてください。

このあたりの相場感で書類審査をし、今回のプロジェクトに必要な人員構成にあわせて人員の選定を行います。ただ、書類審査はそれほど難しくない、と私は考えています。たまに書類に書いてあるスキルセットや経歴が嘘だったりすることもあります。が、そんなものは目を皿にして眺めてもわからないので、そこは真実として扱います。
問題はその後です。

外部リソースは「能力」より「不確実性」が難しい

書類審査のあとに行われるのは面談です。大きい開発会社だと筆記試験などを設ける場合もあるかもしれませんが、中小規模くらいだと書類審査から面談をして判断するケースが多いかなという印象です。

この面談が外部リソースを活用する上での肝となります。
さきほど「特定の機能にかかる工数をミドルクラスレベルで10人月と見積もった」という例を出しましたが、これは自分の想定するミドルクラスレベルの人が来てくれることが前提となっています。
このレベル感がはずれると見積もりがずれ、プロジェクトの成否に影響する、成功したとしても利益がでないみたいな現象が発生します。

ここで大事なことは、書類より優秀な人が来る必要はない、という点です。もちろんジュニアクラスレベルと見込んだスキルセットの人が、ミドルクラスレベルにできる人だったというのは嬉しい誤算だったりしますが、ここで気をつけるのは書類以下の人が来てしまうケースです。
ミドルクラスが2名と見込んだのに、1名がジュニアクラス程度の実力しかないと雲行きが一気に怪しくなる、ということですね。

私が経験したケースとして、書類上はかなり優秀なエンジニア、キャリアとしてはミドルからシニアくらいの海外出身エンジニアがいました。そのプロジェクトは前提として日本語テキスト、日本語話者が中心となるため日本語能力必須として面談をしていました。
面談上は問題なく日本語が話せるように見え、仲介したエージェントも日本語には問題ないことの太鼓判を押してくれたので採用しましたが、プロジェクトが始まって3週間もしないうちに、日本語能力が足りていないことが露呈しました。
こちらの質問に対して「大丈夫です」と答えるので、「復唱してもらっていいですか？」と聞くと復唱できませんでした。
設計書が読めない、指示文も読めない、口頭で指示した内容もわからないのではプロジェクトが進みません。

契約は１ヶ月更新としていましたので、更新はせず退場していただくという結果になりましたが、ほぼコードを書かかずに終わったエンジニアに対して１ヶ月分の費用が発生し、プロジェクトにとってそこそこの痛手となりました。
外部エンジニアがどの程度のスキルなのか、書類通りのスキルなのか、どのような人物なのかを見抜かなればならない面談は、それだけ重要ということになります。

これは高い能力のエンジニアを見つけることが課題なのではなく、どのようなエンジニアなのかわからないという不確実性の問題です。
さきほどの例であげたエンジニアも、英語ドキュメントが中心のプロジェクトであれば実力を遺憾無く発揮し、即戦力になったのだろうなと思います。要はこちらが彼のことを知らなかったがために起きたミスマッチです。

前段で「フリーランスのエンジニアの方で、すでに発注した経験がある方がいる場合、かなり優先度があがります」と書きましたが、その理由はここにあります。
期待値があらかじめ読めるエンジニアほど、プロジェクトの見積もりがしやすく進めやすい方はいないからです。

面談を工夫する

弊社ではこの失敗をふまえ、この面談を重視するようになりました。
特にレベル感のミスマッチはプロジェクトが失敗する大きな要因になるため、そこが埋まるような工夫が必要になります。

仲介エージェントは基本的な姿勢として、エンジニアのスキルを盛ります。
なぜかというと、その方がエンジニアの単価が上がって儲けられるからです。悪質なところは未経験者をミドルクラスとして現場に放り込み、訴訟になったケースもありますので注意してかからないといけません。

スキルを確認する方法としては、次ようなものが考えられます。

• 口頭による技術的な質問

• 筆記によるテスト

• 過去のプロジェクトにおける課題解決の方法

• 最近気になっている技術

ただ、筆記によるテストを騙し討ちのような形でいきなりやるのはいただけないので、もしやる場合はあらかじめ仲介エージェントに連絡しておく必要があります。この場合、エンジニア側から断られてしまう可能性もあるので、ちょっと諸刃の剣的要素もあります。

弊社で採用しているのは、「口頭による技術的な質問」です。
この項目をあらかじめレベル感ごとに用意しておき、ジュニアクラスならジュニアクラス、ミドルクラスならミドルクラスの質問を行います。
大事なのは書類とのレベル感が違っていないかを確認することなので、ジュニアクラスの方にシニアクラスの質問をするのはやりすぎだと認識しています。

また、最近気になっている技術について深掘りすることも大切です。
その技術をどのように語るかで、その方の技術に対しての向き合い方、考え方、情報収集能力がわかります。レベル感が高い人ほど技術に関心がある印象がありますので、もし心当たりある方は普段から気になる技術を押さえておくと良いかと思います。

最後に

外部リソースに関して、現場からのレポート書いてみました。
2026年時点で過去のプロジェクトを振り返りつつ書きましたが、昨今ではAIが急速に普及しつつあり、外部リソースとの向き合い方も各社見直しをかけているところかもしれません。

AIは便利なツールではありますが、結局ツールは人が使わないといけないので、AIを使える人を集める必要があることに変わりはない、という認識です。
外部リソースをうまく活用することはプロジェクトを成功させる中核部分になると思いますので、今回披露した知見がどなたかのプロジェクトの役にたてれば幸いです。

お問い合わせ・ご相談

株式会社ShareDanでは、ホームページの制作やWebシステム開発・技術支援を行っています。

案件のご相談やお問い合わせは、下記よりお気軽にどうぞ。

▼会社ブログ

▼お問い合わせ

▼イベント情報