COBOLエンジニアを業務委託で確保する方法｜基幹系延命の人材戦略と実行手順

「業務委託で COBOL 保守人材を確保する」——情シス役員会で稟議は下りたはずなのに、承認から数ヶ月が経過しても最初のチャネル打診に踏み出せていない。そんな停滞にお心当たりはないでしょうか。中途採用は 1 年戦って応募すら乏しく、社内に残る COBOL 経験者は数名。退職スケジュールを見れば、来年には引き継ぎ可能な人物がゼロになる。頭では「業務委託しか選択肢はない」と分かっていても、実際の着手には多くの発注者が二の足を踏んでいます。

停滞の原因は多くの場合、大方針が誤っているからではなく、実行の手順が具体的に見えていないためです。COBOL エンジニアを探せるチャネルは複数存在しますが、単価表を並べただけでは「うちの環境で来月から動ける人材にたどり着けるか」は判断できません。面談では、経歴書上の COBOL 経験年数だけでは「本物の基幹系保守経験者」か判別できません。契約書は他業界のテンプレートを流用しづらく、メインフレーム／オンプレ環境固有の論点は法務任せにできない領域が残ります。契約後にはドキュメントの乏しい基幹系へ安全にジョインさせる設計が待っています。

本記事では、COBOL エンジニアを業務委託で確保する発注者向けに、4〜6 週間で 1〜2 名を契約クローズし、翌月からのオンボーディングまで到達するための実行ワークフローを整理します。「探す」「見極める」「契約する」「立ち上げる」の 4 局面を、稟議書に添付できるレベルの具体性でご提示します。

はじめに、なぜ確保プロセスだけが動かないのかを市場構造の観点で確認し、発注者が直面しがちな 3 つの壁を可視化します。続いて委託先チャネルを 4 分類で比較し、確保リードタイム・打診コスト・打率という発注実務の指標で選び分けます。その後、5 ステップの確保プロセス、単価交渉の可変域と固定域、面談で確認する 5 つの技術観点、基幹系固有の契約論点、オンボーディング 4 週間モデルを順に扱います。最後に「今月中に第一歩を踏み出す 3 ステップ」で全体を締めくくります。

なお、刷新か延命かの上流判断そのもの、および COBOL フリーランス人材市場の単価相場（受託者視点の一次データ）については、姉妹記事に詳細を譲り、本記事は「延命を選んだ発注者が業務委託で人材を確保する実行手順」に焦点を絞ります。

なぜCOBOL保守人材の確保だけが動かないのか｜市場構造と発注者が直面する3つの壁

稟議は下りたのに、確保プロセスがなぜ数ヶ月単位で停滞するのか。多くの現場を観察すると、その原因は情シス責任者の実行力不足ではなく、COBOL 市場そのものが「探す・見極める・契約する」の全工程で通常のエンジニア採用と異なる特殊性を持っていることに起因します。本セクションでは、その構造を 4 つの角度から整理します。

2025年の崖と延命判断（本記事は延命を選んだ発注者向け）

「2025年の崖」は、2018年9月に経済産業省が公表した DXレポート で提示された概念です。同レポートでは、21 年以上稼働している基幹系システムが 2025 年には約 6 割を占めると指摘され、レガシーシステムの刷新が急務だと繰り返し訴えられてきました。

一方で、実務の現場では「刷新すべきと分かっていても、業務ロジックの複雑さ・移行コスト・停止リスクから、あと数年〜十数年は延命前提で運用せざるを得ない」という発注者が多く存在します。特に金融勘定系・保険契約管理・製造業生産管理・官公庁基幹などでは、法規制対応や年次バッチ処理の互換維持が優先されるため、刷新プロジェクトは検討中でも保守は続けなければなりません。

本記事は、この「延命側」を選んだ、あるいは選ばざるを得ない発注者を読者として想定しています。刷新／段階改善の判断や、外部人材を活用した進め方については、次の記事も併せてご参照ください。

• レガシーシステム刷新の判断フレーム
• レガシーコード改善の外注｜全面刷新を避ける判断軸と進め方

COBOL保守人材が不足する構造的要因（高齢化・若手不在・稼働シェアの実データ）

COBOL 保守人材の不足は「人気のない言語だから」といった表層的な理由ではなく、より深い構造要因の重なりで発生しています。

まず、COBOL 経験者の中心層は 1980〜1990 年代に基幹系開発の第一線にいた世代であり、その多くが定年前後に差し掛かっています。IPA が 2019 年に基本情報技術者試験の対象言語から COBOL を除外したことに象徴されるように、若手エンジニアが COBOL を学び始める入口がほぼ閉じられている状況が続いています。

次に、稼働している基幹系そのものは減っていません。DX レポートの追跡調査でも「レガシーシステムがない」「一部領域のみ」の回答は増加していますが（2025年の崖の実態と対策 等の調査解説）、基幹の核心部分は依然として COBOL のまま残るケースが少なくありません。需要は縮小せず、供給側だけが細っていく——これが COBOL 保守人材不足の実像です。

この構造的要因への直接的な対策は本記事の後半（次のセクション以降）で扱う「業務委託によるチャネル多層化」「面談品質の標準化」「基幹系固有の契約設計」「オンボーディングの型化」の 4 点セットに集約されます。

発注者が確保プロセスで直面する3つの壁

業務委託への切替方針が承認されてから、実際に人材を確保するまでの間に、発注者が繰り返しつまずくポイントを整理すると次の 3 つに集約されます。

1. どこで探せばよいか分からない: COBOL 人材の登録数はプラットフォームによって桁が違います。汎用マッチングサービスに登録しても、COBOL タグの案件・人材が薄い場合、数週間反応がないという状況が起こります
2. 面談でスキルを見極める自信がない: 経歴書上の「COBOL 開発経験 15 年」は、方言・環境・業界ドメイン・保守／新規開発の別によって実質的な意味が大きく異なります。何を聞けば「本物の基幹系保守経験者」だと判断できるかの基準が社内に存在しません
3. メインフレーム／オンプレ固有の契約条項が分からない: 一般的な業務委託契約テンプレートは、リモートワーク前提・Web システム前提で書かれていることが多く、本番データへのアクセス制限・オンサイト常駐要件・端末持ち出し禁止といった基幹系固有の論点が抜け落ちがちです

本記事は、この 3 つの壁を順番に取り除いていくための実務ガイドとして構成しています。

本記事のゴール（4〜6週間で1〜2名確保する実行モデル）

「時間をかけずに確保する」ことは目的ではありません。ただし、社内 COBOL 経験者の退職時期から逆算すると、多くの発注者にとって「4〜6 週間で 1〜2 名の契約クローズ、その翌月から稼働開始」が現実的なスケジュール感になります。

本記事のゴールは、稟議書・上申書に添付できるレベルの「COBOL 保守人材確保プロセス（4〜6 週モデル）」を、以下の要素とともに提示することです。

• 委託先 4 チャネルの比較（確保リードタイム・打診コスト・打率）
• 5 ステップの確保プロセス（要件定義シート作成〜オンボーディング準備）
• 面談で確認する 5 つの技術観点（質問例・判断ライン付き）
• 基幹系固有の契約論点 3 点（データアクセス・オンサイト・再委託）
• オンボーディング 4 週間モデル（キックオフ〜継続契約判断）

次のセクションから、この実行モデルを構成要素ごとに解説していきます。

COBOLエンジニアを業務委託で確保できる4チャネル比較｜確保リードタイム・打診コスト・打率で見る

「COBOL エンジニアを業務委託で確保できる場所」と一口に言っても、実務上は 4 つの異なるチャネルが存在し、それぞれ強み・向いている用途・確保リードタイムが大きく異なります。単価だけでなく、「1 名確保までに何週間・何社の打診が必要か（打診コスト）」「打診に対する契約成立率（打率）」まで含めて比較することが、4〜6 週モデルを守るための鍵になります。

フリーランスマッチングプラットフォーム（自走型：レバテック・ITプロパートナーズ等）

フリーランスエンジニアと発注者を直接マッチングするプラットフォームです。レバテックフリーランス・ITプロパートナーズ・フリーランスHub・TechReach などが代表的です。

• 強み: 単価が中間マージン控えめで、経歴書・希望条件を直接確認できる。1 案件を複数人に並行打診しやすい
• 弱み: COBOL 特化人材の登録数は言語別で見ると相対的に少なく、条件がニッチ（例: メインフレーム COBOL＋オンサイト常駐必須）になるほどヒット率が下がる
• 向いている用途: リモート主体・オープン COBOL 案件・週 3〜4 日稼働の部分委託
• 確保リードタイムの目安: 要件出しから面談セット完了まで 1〜2 週間、契約クローズまで 3〜4 週間

COBOL フリーランス案件そのものの市場感（案件数・単価・案件タイプ 3 分類）を発注者側からも把握しておきたい場合は、受託者視点で 2026 年の市場実態を整理したCOBOLフリーランス案件の実態と単価を併せてご参照ください。市場相場を「向こう側から」見ることで、単価提示の妥当性判断や交渉時の相場感形成に役立ちます。

専門エージェント（マンパワー型：メインフレーム系人材紹介）

メインフレーム・COBOL 領域に特化した人材紹介・派遣・準委任エージェントです。金融系 SIer の OB を中心に人材プールを維持している事業者や、地方拠点のベテラン層を組織化している事業者などが存在します。

• 強み: メインフレーム経験者・特定業界経験者にリーチできる可能性が高い。エージェント側で 1 次スクリーニング済みのケースが多い
• 弱み: 中間マージンが大きく、同スキルでもフリーランス直接契約より単価が 1〜2 割高くなる傾向。稼働開始まで 1 ヶ月以上かかることがある
• 向いている用途: メインフレーム COBOL・特定業界ドメイン必須（勘定系・保険契約管理・官公庁）・オンサイト常駐前提
• 確保リードタイムの目安: 要件出しから面談セット完了まで 2〜3 週間、契約クローズまで 4〜6 週間

COBOL専業ベンダー・SIer系子会社（チーム型・開発会社）

COBOL 基幹系の保守運用を専業で受けている開発会社、または大手 SIer の子会社・関連会社です。個人単位ではなく「保守チーム」を丸ごと引き受ける形態が中心になります。

• 強み: 個人の稼働ではなくチーム体制で受けるため、担当者交代・繁忙期・障害対応時の冗長性が確保できる。ドキュメント整備・移管ノウハウの蓄積がある会社が多い
• 弱み: 最低契約金額が月 200〜400 万円規模になることが一般的で、小規模案件には向かない。個々のエンジニア指名はしにくい
• 向いている用途: 保守運用まるごと委託・オンサイト常駐チーム編成・年次バッチ含む通年保守
• 確保リードタイムの目安: 提案受領から契約クローズまで 6〜10 週間（規模により変動）

COBOL に対応する開発会社の一覧は業界メディアでもまとめられていますが、「延命側の保守運用を継続受託できるか」「メインフレーム／オープン COBOL の両方に対応可能か」「基幹系固有の機密要件を満たせるか」の 3 点を必ず確認してください。

総合コンサル・大手SIer（統合支援型）

アクセンチュア・アビームコンサルティング・NTTデータ・野村総合研究所などの大手 SIer・総合コンサルです。単純な保守委託ではなく、「延命／モダナイゼーション／全面刷新」の中長期戦略とセットで受託するのが基本形です。

• 強み: 中長期のロードマップ策定・PMO 支援・部分刷新プロジェクトを並行して回せる。全社 DX 戦略との整合を取りやすい
• 弱み: 単価が最も高く（COBOL 保守個人相当で月 150 万円以上になるケースあり）、日常保守の細かい対応には向かないケースがある
• 向いている用途: 数年後の刷新プロジェクトを見据えた延命保守＋モダナイゼーション準備、上流工程含む統合支援
• 確保リードタイムの目安: 提案受領から契約クローズまで 8〜12 週間

4チャネル比較表（確保リードタイム・打診コスト・打率・向いている用途）

主要 4 チャネルを実務指標で比較すると、次のように整理できます。数値は 2026 年時点の一般的な相場観に基づく目安であり、案件条件・地域・時期によって変動します。

4〜6 週モデルを守るためには、フリーランスマッチング＋専門エージェントの並列打診が現実的な選択肢になります。単一チャネル依存はリードタイムを 2 週間以上悪化させるリスクがあるため、少なくとも 2 チャネル同時進行を基本方針にしてください。

COBOL保守人材確保プロセスの5ステップ｜4〜6週間で1〜2名クローズする実行モデル

ここからは、稟議承認から契約クローズまでを 4〜6 週間で回すための 5 ステップを、週次スケジュール・工数・関係者・成果物とともに具体化します。稟議書・上申書に添付できるレベルの実行スケジュールとしてご活用ください。

ステップ1（Week 1前半）要件定義シートの作成

最初の 3〜5 日で、委託先に共有する要件定義シート（A4 で 1〜2 枚）を作成します。曖昧な条件でチャネル打診しても打率は上がらず、逆に打診コストが跳ね上がります。

含めるべき項目は次のとおりです。

• COBOL 種別: メインフレーム COBOL（IBM z/OS、富士通 GS、NEC ACOS 等）／オープン COBOL（Fujitsu NetCOBOL、Micro Focus 等）／両方
• 周辺ミドル・DB: JCL・DB2・IMS・VSAM・CICS・Oracle・PostgreSQL 等の必要範囲
• 業界ドメイン: 金融勘定系・保険契約管理・製造業生産管理・官公庁基幹などの経験要否
• 稼働形態: 完全リモート／週 N 日オンサイト常駐／フルオンサイト
• 稼働率: 週 5 日フル／週 3 日／週 2 日
• 契約期間: 初回 3 ヶ月／半年／1 年、更新想定
• 開始希望日: 具体日付（Week 5〜6 起算）
• 単価レンジ: チャネル別の相場感で幅を持たせて提示

工数目安: 5〜10 時間（情シス責任者＋実務担当者）。関係者: 情シス責任者、実務保守担当者、法務・調達部（背景共有）。成果物: 要件定義シート 1 枚、上申書添付用の予算稟議根拠メモ。

ステップ2（Week 1後半）チャネル選定と並列打診

要件定義シートが固まったら、Week 1 後半のうちに 2〜3 チャネルへ並列打診します。

• チャネル選定は、前セクションの 4 チャネル比較表を基準に、案件条件（リモート／オンサイト、単価上限、開始希望日）から絞ります
• フリーランスマッチング＋専門エージェントの組み合わせが 4〜6 週モデルには最も適合しやすい構成です
• 打診時は「要件定義シート＋想定単価レンジ＋開始希望日＋NDA 準備状況」をワンセットで送付し、初回返信で面談セットまで進めやすくします

工数目安: 3〜5 時間（各チャネル 30〜60 分×3〜5 社）。関係者: 情シス責任者、調達部（発注書式確認）。成果物: 打診済みチャネル一覧、初回返信受領記録。

ステップ3（Week 2〜4）スキルスクリーニング（書類→技術面談→トライアル保守）

Week 2〜4 の 3 週間で、書類選考→技術面談→トライアル保守という 3 段階のスクリーニングを回します。

• 書類選考: 経歴書の COBOL 経験年数だけでなく、方言・環境・業界ドメイン・保守／新規開発比率を確認します
• 技術面談: 60〜90 分の 1 対 1 面談で、後述の「5 つの技術観点」を軸に質問します
• トライアル保守: 契約前に 1〜2 日程度の有償トライアル（1〜3 万円程度のスポット単価）で、実際のソースを見せて質疑や改善提案を依頼するのも有効です。金額以上に「本物か」の見極め精度が上がります

工数目安: 1 名あたり 5〜10 時間（書類選考 1 時間＋面談 90 分＋トライアル対応 3〜7 時間）。関係者: 情シス責任者、実務保守担当者、法務（NDA 締結）。成果物: 面談メモ、トライアル評価メモ、内定候補リスト。

ステップ4（Week 4後半）契約締結（NDA→本契約）

スクリーニング完了後、Week 4 後半で NDA→本契約の順に進めます。

• NDA は打診段階で先行締結しておくと、面談時に踏み込んだ話題（本番データの扱い・システム構成の詳細）に入れます
• 本契約では後述の「基幹系固有の契約論点 3 点」を必ず盛り込みます。法務任せにせず、情シス側で論点整理してから法務レビューを回すと、レビュー往復回数を減らせます

工数目安: 5〜10 時間（法務レビュー含む）。関係者: 情シス責任者、法務、調達部、契約先。成果物: NDA、業務委託契約書、月次体制表。

ステップ5（Week 5〜6）オンボーディング準備

契約締結が見えた段階で、並行してオンボーディング準備を進めます。稼働開始初日から「何をしてもらうか」が定義されていないと、稼働の最初の 2 週間が空転します。

• キックオフ会議のアジェンダ作成（初日〜3 日目の学習・共有内容）
• ドキュメント発掘（設計書・パラメータ表・JCL 手順書・障害対応履歴・年次バッチスケジュール）
• アクセス権付与（開発環境・ステージング環境・本番閲覧権限の粒度定義）
• 社内側受け入れ窓口の指名（実務担当者、質問窓口）

このステップの詳細は、後述の「オンボーディング 4 週間モデル」で扱います。

工数目安: 10〜15 時間。関係者: 情シス責任者、実務保守担当者、社内他部門（アクセス権付与の承認）。成果物: キックオフアジェンダ、ドキュメント一覧、アクセス権付与記録。

COBOL業務委託の単価交渉と「安すぎ案件」の見極め方｜発注者が押さえる可変域と固定域

単価交渉は「相場より少しでも安く抑える」ためではなく、「妥当な単価で妥当な人材を確保する」ためのプロセスです。安すぎる提示にはほぼ確実に裏があり、逆に相場より 30% 以上高い提示にも合理性を確認する必要があります。本セクションでは、発注者視点で「動かせる変数」と「動かせない変数」を切り分けたうえで、「安すぎ案件」の見極め基準を提示します。

単価レンジ全体像は姉妹記事に譲る（本記事内は概略のみ）

COBOL 業務委託の単価レンジは、フリーランス直接契約で月 50〜100 万円、モダナイゼーション主導や高難易度案件で月 100〜120 万円台、専業ベンダーのチーム受託で月 200〜400 万円、大手 SIer 統合支援で月 300 万円以上、というのが 2026 年時点の概略です。

案件タイプ別（保守・移行・モダナイゼーション主導）の単価差、経験年数別（1〜3 年／3〜5 年／5 年以上）の内訳、業界別の単価分布などの詳細な相場データは、COBOLフリーランス案件の実態と単価 で受託者視点の一次データとして整理していますので、そちらをご参照ください。

本記事では、これ以降「発注者が交渉で動かせる範囲」と「動かせない範囲」の切り分けに集中します。

発注者が動かせる交渉可変域（稼働率・契約期間・成果物範囲・支払サイト）

発注者が交渉テーブルで動かせる主な変数は次の 4 つです。これらを組み合わせることで、単価総額を実質 10〜20% 変動させられる余地があります。

• 稼働率: 週 5 日フル→週 4 日／週 3 日への調整。稼働率を下げる代わりに、単価は月額比例で下げつつ、必要工数は業務の優先順位で絞り込みます
• 契約期間: 3 ヶ月契約より 6 ヶ月・1 年契約のほうが単価は下がる傾向にあります（受託者側の営業コスト・空白リスクが下がるため）
• 成果物範囲: 保守運用に特化する／ドキュメント整備を含める／障害対応 24 時間対応を含める、で単価が変動します。「何を含めない契約か」を明示することで単価を抑えられます
• 支払サイト: 月末締め翌月末払い→月末締め翌々月末払いの延長で、単価が下がる場合があります（キャッシュフロー逼迫の受託者ほど反応があります）

発注者が動かせない固定域（実務経験年数・業界特化・メインフレーム固有スキル）

一方、発注者が交渉で動かせない・動かすべきでない固定域は次のとおりです。これらは単価を下げても人材の質が担保されないため、原則として妥協の対象にしないでください。

• 実務経験の年数: 「COBOL 経験 5 年以上必須」と要件に書いたなら、3 年の候補に単価だけ下げて発注するのは危険です
• 特定業界の実務経験: 金融勘定系・保険契約管理・官公庁基幹などのドメイン経験は、ドキュメントを読める・障害の見当がつく速度に直結します。ドメイン未経験者を単価だけで妥協すると、立ち上げの遅延で回収不能な工数損失が発生します
• メインフレーム環境固有スキル: JCL・IMS・VSAM・CICS 等は、経験の有無で作業時間が数倍〜十数倍変わります。「業務中に学べます」という受託者側の申し出は基本的に真に受けないほうが安全です

「相場より30%以上安い」案件で確認する5つのチェックポイント

提示単価が市場中央値の 30% 以上下振れしている委託先には、多くの場合以下のいずれか（複数）の要因が隠れています。契約前に必ず確認してください。

1. 実務経験の年数偽装: 経歴書の COBOL 経験年数と、面談で語れる具体的な保守エピソードの粒度に乖離がある。「実際に手を動かしたのは何案件・何ヶ月か」を掘り下げる
2. 再委託を前提とした薄い体制: 契約先は営業のみで、実作業は別会社・別担当者に流す想定になっている。体制表の月次提出義務がなく、担当者交代の通知義務も甘い場合は要警戒
3. ドキュメント作成放棄: 保守作業のみ実施し、変更履歴・パラメータ変更記録・障害対応履歴のドキュメント化を含まない提案。属人化を悪化させる原因になる
4. VSAM・IMS 等の周辺スキル未経験: COBOL 本体は書けるが、周辺ミドル・DB の実務経験が乏しい。オンプレバッチ処理の 8 割は周辺ミドルとの連携部分で発生するため、この経験不足は致命的
5. 機密保持・持ち出し規約の甘さ: NDA の押印だけで、実質的なデータアクセス制限・端末制限・ログ監査の運用ルールが未整備。金融・保険・官公庁案件では特に危険

以上 5 点のいずれかが確認できた場合、単価が魅力的でも見送りが原則です。「妥当な単価で妥当な人材」の原則を崩さないでください。

COBOL保守人材のスキル評価｜発注者が面談で確認する5つの技術観点

「経歴書の COBOL 経験 15 年」は、それ単体では何の判断材料にもなりません。方言・環境・業界ドメイン・保守／新規開発比率・ドキュメント欠如環境での立ち上げ経験——この 5 観点で掘り下げて初めて、「本物の基幹系保守経験者」かが見えてきます。本セクションでは、面談で使える具体的な質問例と、合格・不合格の判断ラインを観点ごとに提示します。

観点1 COBOL方言・実装環境の実務経験

COBOL は方言・実装環境によって開発体験が大きく異なります。オープン COBOL 経験者にメインフレーム COBOL の保守を任せると、JCL・SPOOL・データセット概念の学習だけで数週間から数ヶ月を要することがあります。

質問例:

• 「これまでどの COBOL 環境で開発／保守されましたか？（IBM z/OS、富士通 GS、NEC ACOS、Fujitsu NetCOBOL、Micro Focus 等）」
• 「メインフレーム COBOL とオープン COBOL の両方の経験があれば、それぞれで一番戸惑った差分を挙げてください」

合格ライン: 自社の環境（例: IBM Enterprise COBOL＋z/OS）と一致する環境での 3 年以上の保守経験。または類似環境での 5 年以上経験＋自社環境への短期立ち上げ実績。 不合格の兆候: 「COBOL は COBOL なのでどの環境でも大丈夫です」という抽象的な回答。方言・環境差分を語れないのは、単一環境しか経験がないか、実務経験が浅い可能性が高い。

観点2 周辺ミドル・DBスキル（JCL・DB2・IMS・VSAM・CICS）

COBOL 単体で完結する保守作業は極めて稀です。実際の作業時間の 5〜7 割は、周辺ミドル・DB との連携部分に費やされます。周辺スキルの実務経験が薄いと、障害切分けや変更影響調査で立ち往生します。

質問例:

• 「JCL の PROC・SYMBOLICS を使ったジョブ組み立てを実務でどの程度書かれましたか？」
• 「DB2 の LOAD ユーティリティで運用データを投入する際、パフォーマンスチューニングで気を付けたポイントは？」
• 「VSAM ファイルの再編成（REORG）を運用で回した経験と、その頻度は？」

合格ライン: 自社で使用している周辺ミドル・DB について、パフォーマンス問題・障害対応・運用ルーチンを具体的なエピソードで語れる。 不合格の兆候: 「経験はあります」だけで具体エピソードが出てこない、名前は知っているが実運用の粒度で語れない。

観点3 業界ドメイン適合性

同じ COBOL 保守でも、業界ドメインが変われば必要な業務知識は全く異なります。金融勘定系の残高計算、保険契約管理の責任準備金計算、製造業生産管理の MRP、官公庁の税・社会保障計算——これらは COBOL の技術力とは独立した専門性です。

質問例:

• 「これまでどの業界のどの業務システムを保守されましたか？」
• 「（自社ドメインを提示して）この業務ロジックのうち、経験のある部分と初見の部分を教えてください」
• 「業界特有の年次バッチ（例: 保険なら年度末解約返戻金計算）の対応経験は？」

合格ライン: 自社ドメインでの 3 年以上の実務経験、または近接ドメイン（例: 銀行→クレジット）で 5 年以上の経験＋業務理解の速度への自信。 不合格の兆候: 業界ドメインへの言及を避け、技術論に終始する。ドメイン未経験でも自覚があるかどうかで判断が変わる（自覚があり学習意欲があれば長期契約でカバー可能）。

観点4 保守運用の実務経験（バグ改修・年次バッチ変更・障害切分け・リグレッション試験）

新規開発と保守運用では、必要スキルが大きく異なります。保守経験者は「本番運用中のシステムを壊さずに変更する」という緊張感の中で、リグレッション試験や事前検証のクセを身に付けています。新規開発しか経験のない人材は、本番運用の心理的プレッシャーで動きが鈍る場合があります。

質問例:

• 「直近で対応したバグ改修の中で、影響範囲調査に一番時間がかかったものを教えてください」
• 「年次バッチの改修で、リグレッション試験の観点をどう設計されましたか？」
• 「本番障害の切分けで、最初に見るログ・データは何ですか？」

合格ライン: 具体的な改修エピソード・影響範囲の洗い出し方・リグレッション試験の設計プロセスを、実際の作業手順として語れる。 不合格の兆候: 「テスト仕様書に従って実施しました」レベルで留まり、自分で影響範囲を洗い出す思考プロセスが語れない。

観点5 ドキュメント不足環境での立ち上げ経験

多くの基幹系は、設計書が数十年前のもの・断片的な変更履歴のみ・パラメータの意味が口伝——という状況です。ドキュメントが揃った環境での経験だけでは、本番投入初日から動けません。ソースリーディングで業務ロジックを逆算できるスキルが必須になります。

質問例:

• 「ドキュメントが不十分な既存システムに新規参画したとき、最初の 1〜2 週間で何をされますか？」
• 「ソースコードから業務ロジックを逆算した経験があれば、その手順を教えてください」
• 「未知の COPY 句や JCL パラメータに出会ったとき、どう調べますか？」

合格ライン: 過去のドキュメント欠如環境での立ち上げ手順（呼び出し関係の可視化・パラメータ表の逆生成・現行担当者への集中インタビュー等）を具体的な手順として語れる。 不合格の兆候: 「ドキュメントを整備してから作業に入ります」という理想論のみで、ドキュメント不在の環境での実務対応を語れない。

秋霜堂株式会社でも、前任者が不在でドキュメントも残っていない既存システムについて、初期調査から改善対応までを継続的に実施した実績があります（参考: /work-blog/ のアパレル品質管理システム大規模改善事例）。ドキュメント不足環境での立ち上げは、単なる技術力ではなく「業務ロジックを短期間で解体する分析力」が問われる領域だと、実務を通じて再認識しています。

COBOL業務委託契約の締結チェックリスト｜基幹系・メインフレーム固有の論点に絞った実務ガイド

標準的な業務委託契約テンプレート（契約期間・報酬・支払条件・解除条項等）の網羅解説は本記事では扱いません。代わりに、COBOL 業務委託／基幹系保守ならではの 3 つの実務論点に絞って、法務と詰めるべき具体表現とともに提示します。契約形態 3 種（準委任・請負・成果報酬）の使い分け一般論、報酬支払条件・解除条項の一般論などは、汎用の業務委託契約解説をご参照ください。

データアクセス範囲・持ち出し制限（本番／マスキング／サンプリング）

COBOL 業務委託で最も慎重に定義すべきは、データアクセスの粒度です。本番データへの直接アクセスは、法規制（個人情報保護法・金融庁ガイドライン等）と情シスセキュリティポリシーの両方から制約されます。

契約書に定義すべき条項の観点は次のとおりです。

• 開示データの粒度: 本番データ／マスキング済みデータ／サンプリングデータのどれを開示するか、業務によって異なる場合は業務単位で定義
• アクセス経路: VPN 経由・仮想デスクトップ（VDI）経由・オンサイト常駐時のみ許可、のいずれか
• 端末制限: 委託先私物端末禁止、社給端末のみ、または VDI 内でのみ作業
• 持ち出し禁止範囲: ソースコード・データ・設計書・スクリーンショット等の物理／電子持ち出しの明示的禁止
• ログ監査: アクセスログ・操作ログの取得範囲と保管期間

法務レビューに回す前に、情シス側で「業務ごとにどのデータ粒度が必要か」を整理しておくと、後日の運用トラブルを防げます。

メインフレーム／オンプレ環境のオンサイト常駐要件

メインフレーム基幹系では、物理端末アクセスや専用ネットワーク経由が必要になるケースが多く、フルリモートでの保守運用は現実的でないことがあります。契約書上でオンサイト常駐要件を明示的に定義しないと、稼働開始後にトラブルになります。

• オンサイト頻度: 週 N 日オンサイト＋残りリモート、または月 N 日オンサイト、の明示
• オンサイト場所: 発注者オフィス／専用作業スペース／データセンター
• オンサイト時の交通費・宿泊費: 契約金額に含める／別途実費精算、の明示
• 緊急オンサイト要請: 障害発生時の緊急駆けつけ要件（何時間以内・回数上限）と対価
• リモートアクセス制限時の作業ルール: 特定のシステム（勘定系マスタ等）はオンサイトからのみ操作可能、といった業務単位のルール

「基本リモートで、必要に応じてオンサイト」という曖昧な表現は避け、必ず具体的な日数・場所・費用負担を明記してください。

再委託禁止・体制の透明化

業務委託先が再委託で第三者に開示するリスクは、基幹系案件では特に重大です。契約書での明示的な統制が必要です。

• 原則再委託禁止: 事前書面承認なき再委託は禁止、と明示
• 承認再委託の範囲: 承認する場合の承認プロセス、承認先の範囲、機密保持義務の再委託先への継承
• 体制表の月次提出義務: 稼働メンバー・稼働率・役割の月次提出、変更発生時の即時通知義務
• 担当者交代時の通知義務: 交代の何日前までに通知するか、交代時の引継ぎ要件
• 監査権: 発注者が委託先の体制・作業内容を監査できる権利の明示（実施は限定的でも権利として持つことに意味がある）

これらの論点を情シス側で整理してから法務レビューに回すと、レビューの往復回数を 2〜3 回に抑えられます。法務任せにするとテンプレート契約書に近い形で戻ってきてしまい、基幹系固有の論点が漏れがちです。

業務委託後のオンボーディング設計｜ドキュメントの乏しい基幹系に安全にジョインさせる4週間モデル

契約締結がゴールではありません。稼働開始から 1 ヶ月以内に「業務委託を選んで良かった」と情シス役員に報告できる状態にすることが、真の目標です。ドキュメントの乏しい基幹系では、オンボーディング設計の質が稼働 3 ヶ月目以降の生産性を左右します。

キックオフ会議のアジェンダ（初日〜3日目）

稼働初日〜3 日目の 3 日間で、システム全体像・障害履歴・運用ルールを共有します。この 3 日間を「自習してください」と丸投げすると、その後の立ち上げが 1 ヶ月以上遅れます。

初日アジェンダ例:

• 自社事業概要と基幹系の位置付け（30 分）
• システム全体像（主要サブシステム・データフロー・年次スケジュール）（60 分）
• 開発・ステージング・本番環境の構成と作業ルール（60 分）
• チーム体制（社内担当者・質問窓口・エスカレーション先）（30 分）

2〜3 日目アジェンダ例:

• 直近 12 ヶ月の障害履歴と対応内容の共有
• 主要バッチジョブ（月次・年次）の実行スケジュールと過去のトラブル
• ソースコード管理ルール・変更申請フローの説明
• パラメータ表・COPY 句・JCL の主要ファイル紹介

Week 1のドキュメント発掘リストと引継ぎインタビュー

Week 1 は「ドキュメントを揃える」ではなく「散在するドキュメントを発掘して一覧化する」フェーズです。整備されていなくても、断片が存在するだけで委託先の立ち上げ速度は大きく変わります。

発掘リスト例:

• 設計書（初期版・改訂版・部分改訂メモ）
• パラメータ表・マスタ定義書
• JCL 手順書・運用手順書
• 障害対応履歴（直近 3 年分）
• 年次バッチスケジュール表
• 過去の変更申請書（改修理由・影響範囲）

並行して、社内 COBOL 経験者（退職前の 1〜2 名）に対する引継ぎインタビューを Week 1 のうちにセットします。1 名 60〜90 分×2〜3 セッションを目安に、口伝で残っている「なぜこの実装になっているか」を録音・書き起こしします。

Week 2〜3の初期成果物（ソースリーディングレポート）

Week 2〜3 で、委託人材に「既存ソースの読み解きレポート」と「改善提案 1〜2 件」を初期成果物として依頼します。これは委託先の実力確認と、社内側のドキュメント資産形成を兼ねます。

• ソースリーディングレポート: 主要サブシステムの呼び出し関係図、主要パラメータの意味、業務ロジックの再構成（A4 で 10〜20 ページ規模）
• 改善提案: 現行運用の非効率箇所や潜在バグの指摘＋改善案（実装は次月以降）

このアウトプットが薄い・的外れな場合、契約後 3 ヶ月以内に契約継続・打ち切りの判断が必要になります。トライアル保守（前述ステップ 3）を経ていれば、この段階での大きなミスマッチは減らせます。

Week 4の初回成果報告と継続契約判断

Week 4 で、委託人材＋社内実務担当者＋情シス責任者の 3 者で初回成果報告会を開催します。

• Week 1〜3 の成果物レビュー
• 委託人材から見た「立ち上げで詰まった点」「社内で解消してほしい情報アクセス」
• 社内から見た「委託人材の実力評価」「継続契約への意向」
• 次月の作業計画（保守運用の定常タスク＋新規改修）

この 4 週間モデルを標準化しておくと、複数名を並行して立ち上げる場合や、担当者交代が発生した場合にも同じ枠組みで運用できます。

まとめ｜今月中にCOBOL保守人材の確保プロセスを回す3ステップ

本記事では、COBOL エンジニアを業務委託で確保するための実行ワークフローを、市場構造の理解から 4 チャネル比較・5 ステップの確保プロセス・単価交渉・面談 5 観点・契約 3 論点・オンボーディング 4 週間モデルまで、発注者視点で整理しました。

情報の量そのものは既に十分に手元にあるはずです。停滞のボトルネックは「情報整理」ではなく「実行の第一歩」です。稟議承認から数ヶ月が経過している場合、次の 3 ステップで今月中に確保プロセスを回し始めてください。

1. 今週中: 要件定義シートを A4 で 1〜2 枚作成し、フリーランスマッチング＋専門エージェントの 2〜3 チャネルに並列打診する
2. 再来週から: 打診で挙がった候補について、書類選考→技術面談→トライアル保守の 3 段階スクリーニングを進める（面談は本記事の 5 観点を軸に設計する）
3. 月末までに: 1〜2 名の契約クローズを実現し、翌月からのオンボーディング準備（キックオフアジェンダ・ドキュメント発掘リスト・アクセス権付与）に着手する

社内 COBOL 経験者の退職スケジュールから逆算すれば、実行を先延ばしにできる時間はほとんど残されていません。本記事の 4〜6 週モデルを、稟議書・上申書に添付できる実行スケジュールとしてご活用いただければ幸いです。

関連情報

COBOL 保守運用や外部人材確保の判断材料としてご活用いただけるお役立ち資料を お役立ち資料一覧 にてご用意しています。稟議書に添付できる形の判断整理をお探しの方はぜひご覧ください。

基幹系の延命保守・外部人材の要件整理段階からご相談いただける場をご用意しています。COBOL 保守運用の体制設計・要件整理をご検討中の方は、お問い合わせフォーム からご相談ください。

本記事と併せてお読みいただきたい関連記事です。

• COBOLフリーランス案件の実態と単価 — 受託者視点で 2026 年の COBOL 案件市場・単価相場・案件タイプを整理した姉妹記事
• レガシーコード改善の外注｜全面刷新を避ける判断軸と進め方 — 全面刷新を避けてコード診断から段階的に改善する場合の発注観点
• レガシーシステム刷新の判断フレーム — 延命／刷新の上流判断フレーム