「社長から、いきなり業務システムの発注を任されてしまった」。総務や経理のマネージャーをしていると、ある日突然そんな相談が降りてくることがあります。社内には情報システム部門もエンジニアもおらず、頼りになる相談相手は社外にしかいない。自分は本業を抱えていて、ITは多少触れる程度。本当にこんな体制で開発会社と話を進めて大丈夫なのか、不安に思うのは自然な反応です。
しかも厄介なのは、「情シス ない 中小企業 システム発注」というキーワードで調べても、出てくる記事の多くが「情シス代行サービスの紹介カタログ」か「ゼロ情シスはこんなに危険」という総論ばかりで、いま目の前の発注をどう成立させるかは教えてくれないことです。サービスの選択肢を眺めるだけでは、誰を窓口にすればよいか、何から準備すればよいかは決まりません。
実際には、情報システム部門がない会社でも、システム発注は十分に成立します。専任の情シスを置けない前提を受け入れたうえで、「窓口の役割」「最低限の準備物」「外部の伴走者」という3つの要素を組み合わせれば、開発会社にカモにされることなく、プロジェクトを前に進めることが可能です。
本記事では、従業員30〜100名規模の中小企業で、本業と兼任で発注窓口を任されそうな担当者の方を想定し、次の論点を順番に解説します。窓口は誰が担えばよいのか、社内側として最低限揃えておくべき準備物は何か、開発会社に任せるべき領域とそうでない領域はどこか、ITコーディネーターや情シス代行といった外部支援をどう使い分ければよいか、そして発注後に窓口担当が現実的に確保すべき工数はどのくらいか。最後にチェックリストを置き、社内会議でそのまま使える粒度に落とします。
「情シスなし IT発注 方法」を一度きちんと整理しておけば、今後同じ依頼が降りてきたときにも応用が利きます。読み終えるころには、自社の体制でも発注は進められるという見通しを持って、次の一手を踏み出せるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
情シス部門がない会社でもシステム発注はできるのか
最初に結論からお伝えします。情シスが存在しない、あるいは兼任のいわゆる「ゼロ情シス」「ひとり情シス」の会社でも、システム発注は問題なく成立します。むしろそれが中小企業の標準的な姿で、特別困難な状況というわけではありません。不安を感じるのは当然ですが、「自社だけが特殊」と思い込む必要はないということを、まず押さえておきましょう。
中小企業の「ゼロ情シス／兼任情シス」の実態
調査データを見ても、情シス機能が手薄な中小企業は決して少数派ではありません。ノークリサーチの調査によれば、国内の中堅・中小企業における「ひとり情シス」の割合は24.5%に達しており、直近2年で3.2ポイント上昇しています（IT Leaders 報道）。年商5〜50億円の中小企業層に絞ると、専任情シスは2023年の28.7%から2025年には16.7%へと12ポイント減少し、代わりに兼任情シスが48.0%から61.1%へと13ポイント以上増えています。
別の調査では、中小企業の44.1%が「情シス担当者の人数が足りない」と回答し、70.3%が情シス業務の一部を外部委託しているという結果も出ています（バッファロー調査リリース）。つまり、専任の情報システム部門を持たないまま、外部の力を借りつつ社内の誰かが窓口となって発注を回すという形は、中小企業にとっての主流派の働き方になりつつあります。
数字を眺めて分かるのは、「情シスがいないからシステム発注は無理」というロジックは現実とは一致しないということです。多くの会社が同じ条件のなかで発注を成立させており、その共通項を押さえれば、自社でも再現できます。
情シスがいなくても発注を成立させるための3つの前提
情報システム部門 ない 会社 システム開発を前に進めるために、最低限揃えるべき要素は次の3つです。
- 発注窓口の役割を担う人を社内に置くこと: 専任である必要はなく、兼任でも構いません。ただし「誰がボールを持っているか」が常に明確である状態は必須です。
- 最低限の準備物を揃えること: 完璧な要件定義書は不要です。業務フロー・予算感・スケジュールの3点を、たとえA4 1〜2枚のメモであっても自分の言葉でまとめてあれば、開発会社との初回打ち合わせは成立します。
- 外部の伴走者を確保すること: ITコーディネーター、情シス代行、第三者の発注支援コンサルなど、社内に不足している専門性を補ってくれる存在を持つこと。「自前か外注か」の二択ではなく、「自前＋伴走者」の組み合わせで進めるのが現実的です。
この3つが揃っていれば、専任担当者 なし 外注は十分に可能です。逆に言えば、3つのうちどれかが欠けていると、どこかで必ず詰まります。本記事の以降のセクションでは、この3要素をそれぞれ深掘りしていきます。
発注窓口は誰が担うべきか — 兼任でも回せる人の条件
「情シスがいない中で誰を窓口にするか」は、おそらく担当者として最も悩むポイントでしょう。経営層から指名されることもあれば、なし崩し的に総務や管理部門マネージャーに役割が回ってくることもあります。ここでは、現実的に選べる窓口候補のタイプと、兼任で務めるために本当に必要な条件を整理します。
窓口候補4タイプの比較
情シスのいない中小企業で発注窓口を担えるのは、おおむね次の4タイプです。
タイプ | 強み | 弱み | 向くケース |
|---|---|---|---|
経営者直轄 | 決裁が速い／全社視点 | 経営者の時間が取れない／現場業務の解像度が低い | 戦略級の大型案件、経営層が業務にも詳しい場合 |
管理部門マネージャー兼任 | 全社の業務横断知識／決裁ルートに近い | 本業（労務・経理等）の繁忙期と衝突しやすい | 業務系SaaSや基幹システムの刷新 |
業務部門リーダー兼任 | 現場業務の解像度が高い | 全社視点・他部門調整が苦手なことがある | 特定部門の業務アプリ開発 |
外部ITコーディネーターを準窓口に | 専門性が高い／公平な立場 | 社内意思決定の最終責任は持てない／費用が発生 | 社内に適任者が完全にいない場合 |
中小企業で最も多く採用されているのは、管理部門マネージャーが兼任するパターンか、業務部門リーダーが兼任するパターンです。経営者直轄は決裁の速さでは最強ですが、現業を持つ経営者が要件レベルの細部まで関与し続けるのは現実的でなく、すぐに停滞しがちです。
経営者ご自身が窓口になる場合の進め方や、経営者目線での発注プロセスの整理は非エンジニア経営者のシステム開発外注ガイドで扱っていますので、対象読者が経営者であればそちらも合わせて参照してください。本記事は、経営者から発注を任された「担当者ポジション」の方に焦点を絞ります。
兼任窓口に求められる5つの条件
兼任である以上、誰でも務まるわけではありません。次の5条件を満たしていると、開発会社との折衝で大きく失敗しにくくなります。
- 業務時間の確保: 後述する週あたり工数を物理的に確保できること。本業が常に火を吹いている人は不適です。
- 決裁ルートへの近さ: 経営層との距離が遠いと、要件変更や予算追加のたびに数週間止まります。決裁者にすぐ相談できる立場が望ましいです。
- 業務理解の深さ: 自社のどの業務がどう回っているかを、現場の用語で説明できる必要があります。技術知識よりも業務理解の方がはるかに重要です。
- コミュニケーション能力: 開発会社からの質問に「持ち帰って関係者に確認します」と整理できる力。論破するより、社内外の認識をすり合わせる力が問われます。
- 文書化の習慣: 議事録・決定事項を文書で残せること。口頭の「言った言わない」が一番のリスクです。
技術スキルは挙げていない点に注目してください。コードが書ける必要も、サーバー構成を理解している必要もありません。情シスなし IT発注 方法の核心は、技術力ではなく「業務と意思決定をハンドリングする力」にあります。
「窓口を置けない場合」の最終手段
社内をどう見渡しても窓口を担える人材がいない、というケースもあり得ます。そのときは無理に内製窓口を立てず、外部のITコーディネーターや発注支援コンサルに「準窓口」を依頼するのも一つの解です。意思決定そのものは社内に残しつつ、開発会社との実務的なやり取りを伴走者に代行してもらう形です。詳細は後述の「外部コンサルタント・ITコーディネーターを伴走者として活用する」で扱います。
システム発注前に最低限準備すべき3つのこと
開発会社と話を始める前に、社内側で揃えておくべき最低限の材料があります。完璧な要件定義書は不要です。むしろ素人がいきなり要件定義書を書こうとすると、半年経っても1行も進まないことが多いので、絞り込みが大切になります。ここでは、本業を抱える兼任窓口でも現実的に用意できる3点に絞って整理します。
なお、本セクションの3点は「最低限」のラインです。もう一歩踏み込んで準備物を揃えたい方は、はじめてのシステム発注で準備すべき3つのことも合わせて参考にしてください。初めて発注に臨む担当者向けに、最初の社内会議で握っておくべき項目を整理しています。
業務フローの可視化
最初に揃えるべきは、いまの業務がどう流れているかを示すA4 1〜2枚のメモです。きれいな図にする必要はなく、次の3項目が書いてあれば最初の打ち合わせは成立します。
- 関係者: 誰がどの業務を担当しているか（部署・役職レベルで構いません）。
- 現行ツール: いまExcel・kintone・freee・Microsoft 365のどれをどう使っているか。
- 困りごと: なぜシステム化を考えたか、現状の何が痛みなのか。
このメモを開発会社に渡すと、相手は「何を解決したい話なのか」が一発で掴めるため、見当外れな提案が出にくくなります。逆にこのメモなしで「業務システムを作りたい」とだけ伝えると、開発会社は仮説を立てるしかなく、見積もりも要件も大きくブレます。
予算感の捉え方
予算は「未確定」のまま打ち合わせに臨むのが最もまずいパターンです。額が決まっていなくても、「上限はおおむねこの辺り」「決裁ラインは○○円から経営会議が必要」というレンジ感は窓口側で握っておきましょう。
中小企業のシステム発注で活用できる公的支援も視野に入れておくと、議論の幅が広がります。たとえば「デジタル化・AI導入補助金」（旧 IT導入補助金）は、ITツール導入に対して補助率は通常1/2で、賃上げ等の要件充足によって2/3に引き上げられる場合があります。補助上限額・対象経費・申請要件の詳細は枠（通常枠／賃上げ・労働生産性向上枠等）によって異なるため、必ず最新の公募要領をご確認ください（中小企業庁 公募情報）。事業者は補助金事務局に登録された「IT導入支援事業者」と組んで申請する仕組みのため、開発会社を選ぶ段階で補助金対応の有無も比較軸に入れておくと有利です。
予算は社内で確定させてから開発会社に伝えるのではなく、「補助金を使えればこのラインまで延びる」など、複数のシナリオで握っておくのが現実的です。
スケジュール感の押さえ方
最後はスケジュールです。本業との衝突を避けるためにも、次の3点は窓口側で必ず可視化しておきましょう。
- 決算期・繁忙期: 経理・人事系のシステムを決算月直前にカットオーバーするのは無理筋です。
- 既存業務のピーク: 兼任窓口の本業繁忙期（年度末・キャンペーン期など）と要件定義の山場がぶつからないか。
- 社内ステークホルダーの可用性: 経営層レビューが取れる時期、現場ヒアリングが可能な時期。
中小企業のシステム開発スケジュールは、開発期間そのものよりも社内の意思決定・ヒアリングの空き時間が律速になりがちです。「いつまでに作るか」より「いつなら社内が動けるか」を逆算してください。
開発会社に任せるべき部分・任せてはいけない部分
ここが情シス不在の発注で最大の落とし穴になります。素人だからこそ全部開発会社に任せたくなりますが、それをやると後で必ず「こんなはずではなかった」と揉めます。任せて構わない領域と、絶対に発注側が握り続ける領域を切り分けましょう。
発注側が必ず握るべき4つの領域
社内に IT 専門家がいない場合でも、次の4つだけは外注してはいけません。
- 業務要件の意思決定: 「この業務をシステム化するか／既存の運用で回すか」「どの部署のフローに合わせるか」といった判断。
- 優先順位付け: 限られた予算と期間のなかで、何を先に作り、何を後回しにするか。
- 受け入れ判断: 完成物を見て「これでGOを出すか」「修正を求めるか」を最終判断する権限と責任。
- 運用ルール: 誰がデータを入力し、誰が承認し、誰がトラブル時の一次受けをするか。
これらは技術ではなく、自社の業務と組織に関する判断です。社外の人間が代わりに決められるものではなく、決めようとしても外したものになります。情シスなし IT発注 方法の本質的な肝は、ここを開発会社に渡さないことだと言っても過言ではありません。
開発会社に任せてよい領域
逆に、次の領域は積極的に開発会社に任せて構いません。むしろ任せた方が品質が安定します。
- 技術選定: プログラミング言語・フレームワーク・データベースなど。「これを使ってください」と発注側が指定する必要はほとんどありません。
- 実装: コードを書く工程そのもの。
- テスト計画と単体・結合テスト: 開発会社の品質保証プロセスに乗せる方が確実です。ただし「受け入れテスト」は別軸として発注側が担当します。
- インフラ設計: クラウドの構成・セキュリティ初期設定。要件と予算を伝えれば、最適解は相手の方が早く出せます。
任せる以上は、設計書のレビューも完全に追わなくて結構です。読んでも分からない技術設計書を頑張って読むより、業務要件と受け入れ条件の方に時間を使ってください。
任せてはいけない判断を任せてしまう典型例と回避策
実際にありがちな失敗パターンを挙げておきます。
- 「業務ルールどう決めましょうか？」と聞かれて開発会社に任せる: 業務ルールは社内で決めるものです。「現状こうなっているが、システム化に合わせて変えるべきか」を担当窓口が現場と詰める必要があります。
- 要件のグレーゾーンを「お任せします」で流す: グレーは必ず後で揉めます。「Aの方針で進める」と一文で書き残しましょう。
- 受け入れテストを開発会社のテストだけで済ます: 受け入れテストは発注側のテストです。社内のキー業務担当者に必ず触ってもらってください。
「分からないから任せる」のではなく、「分からないから相談相手を増やす」のが正解です。次のセクションで触れる外部支援は、まさにこの相談相手として機能します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
外部コンサルタント・ITコーディネーターを伴走者として活用する
情シス不在の不安を補う最大の打ち手が、外部の伴走者です。社内に専門人材を採用するより、必要な期間だけ外部リソースを借りる方が、中小企業の規模感には合っています。ここでは代表的な3カテゴリを整理します。
ITコーディネーター（公的スキーム・補助金との関係）
ITコーディネーターは、経済産業省推進資格として位置づけられたIT経営の専門家で、経営とITの橋渡し役を担います。中小企業のシステム化計画の策定支援、ベンダー選定の補助、補助金申請の支援などを得意とし、補助金や中小機構の派遣制度と組み合わせて使えるのが大きな特長です。
特に「デジタル化・AI導入補助金」は、IT導入支援事業者とパートナーシップを組んで申請する仕組みになっており、ここにITコーディネーターが入ると、補助金の枠内で発注プロセス全体の伴走を受けられる可能性があります（中小企業基盤整備機構 IT導入補助金 公式）。
情シス代行・アウトソーシング（スポット型／常駐型の使い分け）
情シス代行サービスは、社内の情シス機能そのものを外部委託する形態で、料金体系は大きく3種類に分かれます（BPOの窓口 比較記事）。
形態 | 月額レンジ | 向く使い方 |
|---|---|---|
スポット型 | 1回あたり1.5〜10万円 | 発注検討フェーズ・トラブル対応など、必要なときだけ |
リモート型（月額定額） | 月額3〜15万円 | 日常的なヘルプデスク・社内IT全般の窓口代行 |
常駐型 | 月額10〜50万円 | 大型プロジェクト並走・社内のIT機能を恒久的に補完 |
従業員30〜100名規模の中小企業であれば、リモート型の標準プラン（月額8〜12万円）に加えて、発注プロジェクトの繁忙期だけ訪問・常駐を組み合わせるのが現実的なバランスです。
第三者の発注支援コンサル（RFP作成・ベンダー比較の支援）
ITコーディネーターや情シス代行とは別軸で、「システム発注に特化した第三者コンサル」を一時的に雇う選択肢もあります。RFP（提案依頼書）の作成支援、複数ベンダーからの相見積もり比較、契約条件のチェックなどを依頼でき、発注のヤマ場だけ伴走してもらう使い方が中心です。料金は1案件あたり数十万〜数百万円規模となるため、案件規模に応じて検討します。
3種類の使い分け早見表
課題 | 適した伴走者 |
|---|---|
そもそも何から始めればいいか分からない | ITコーディネーター |
普段からPC・社内IT全般の相談相手が欲しい | 情シス代行（リモート型） |
大型案件の発注プロセスに公平な目を入れたい | 発注支援コンサル |
補助金を活用しながら進めたい | ITコーディネーター（IT導入支援事業者） |
3者を「いずれか1つ」と捉える必要はありません。たとえばITコーディネーターと情シス代行を併用する中小企業も多く、補完しあう関係として組むのが定石です。
発注後の管理コストは現実的にどのくらいか（週あたり工数の試算）
ここまでで体制と準備物の話は整理できました。最後に押さえておきたいのが、「兼任窓口として、発注後に週あたりどのくらいの時間を確保すべきか」というリアルです。経営層に体制を説明する際にも、この数字が一番の説得材料になります。
フェーズ別の窓口工数レンジ（目安）
業界の一般的な目安として、システム開発プロジェクトの進行管理費は開発費全体の10%前後を見込むのが妥当とされています（システム幹事 工数解説）。これを発注側の窓口工数に置き換えると、おおむね次のレンジが現実的です（中規模案件：開発期間4〜6ヶ月想定）。
フェーズ | 期間目安 | 窓口の週あたり工数 |
|---|---|---|
要件定義 | 1〜2ヶ月 | 10〜15時間/週 |
開発（基本〜詳細設計、実装中） | 2〜3ヶ月 | 5〜8時間/週 |
受入テスト・本番直前 | 2〜4週間 | 15〜20時間/週 |
本番直後（運用立ち上げ） | 1ヶ月 | 8〜12時間/週 |
運用安定期 | 継続 | 2〜4時間/週 |
注目すべきは「要件定義」と「受入テスト直前」の2つの山です。ここで窓口担当が時間を取れないと、プロジェクトはほぼ確実に詰まります。逆に開発フェーズの中盤は、開発会社からの定例報告と質問対応が中心になり、相対的に負荷は軽くなります。
兼任を成立させる時間設計
週10〜15時間というのは、本業を持つ兼任窓口にとってはかなりの量です。これを物理的に確保するには、いくつかの工夫が要ります。
- 要件定義期間中は本業の一部を他メンバーに移譲する: 期間限定で構いません。役割分担を明示的に経営層に承認してもらいましょう。
- 副担当を1名置く: 窓口担当が体調を崩したり繁忙期で動けない週があっても、副担当が打ち合わせに出られれば停滞しません。
- 打ち合わせを集約する: 開発会社との定例は週1回・60〜90分にまとめ、合間のやり取りはチャット・メール非同期に統一すると、本業との両立が現実的になります。
「専任を置けないから無理」ではなく、「兼任のままどう運用設計するか」に発想を切り替えることが、情シスなし IT発注 方法を成立させる鍵です。
限界サインと早期エスカレーション基準
兼任窓口が破綻しかけているとき、必ず先行して現れるサインがあります。次のいずれかに当てはまったら、経営層へのエスカレーションを検討するタイミングです。
- 開発会社からの質問への返信が、平均で3営業日以上遅れる状態が2週間続いている。
- 自社内の意思決定（仕様判断・優先順位決定）が1週間以上保留になっている。
- 窓口担当が本業の残業時間で発注業務を吸収している（＝表面化していないが個人で破綻している）。
- 開発会社の定例議事録に「先方確認待ち」が常時5件以上残っている。
これらが現れたら、副担当の追加、外部支援の増強、スケジュール延長のいずれかを早めに打つべきです。「もう少し頑張れば」と放置するほど、後の手当てコストは大きくなります。
情シス不在の発注でよくある失敗と回避策
最後に、情シス部門がない会社のシステム開発で実際によく起きる失敗パターンを整理します。各失敗は本記事で既に触れた章で対策できる構造になっているので、合わせて該当箇所を読み直すと立体的に理解できます。
体制起因の失敗（窓口・意思決定）
- 失敗1: 窓口が決まらないまま開発会社が稼働を始めた: 結果として、開発会社の質問が宙に浮き、社内検討が遅延します。先述の「兼任窓口に求められる5つの条件」を満たせる人物を、稼働開始前に必ず指名してください。
- 失敗2: 業務要件の意思決定を開発会社に丸投げ: 「業務ルールどう決めましょうか？」を相手に投げ返すと、自社業務と合わない仕様になります。「開発会社に任せるべき部分・任せてはいけない部分」で挙げた4領域は社内で握ります。
準備不足起因の失敗（要件・予算・スケジュール）
- 失敗3: 予算感を握らず後工程で揉める: 開発が進んだ後に「予算を超えた」と発覚すると、機能の打ち切りか追加投資の判断を急かされます。打ち合わせ前に補助金を含めた予算レンジを握りましょう。
- 失敗4: 兼任窓口の本業が圧迫されプロジェクトが停滞: 要件定義の山場と本業繁忙期を重ねないこと。スケジュール感の押さえ方を参照してください。
運用フェーズの失敗（受入・運用・ナレッジ属人化）
- 失敗5: 受入テストの責任者が不在: 開発会社のテストだけで本番リリースすると、本番投入後に業務影響が顕在化します。先述の工数試算でも示した通り、受入テスト期は窓口工数を増やすべきフェーズです。
- 失敗6: 運用開始後にナレッジが属人化: 窓口1人にすべての知識が溜まり、その人が異動すると引き継げない状態です。議事録・運用手順書を残し、副担当と共有しておくことで予防できます。
これらの失敗の共通項は、「情シス不在」そのものではなく、窓口設計と外部伴走の不足にあります。逆に言えば、本記事で扱った3要素（窓口・準備物・伴走者）が揃っていれば、ほとんどのケースは事前に避けられます。
まとめ — 情シスなし中小企業がはじめてシステム発注を進めるためのチェックリスト
最後に、本記事の要点をチェックリスト形式でまとめます。明日からの社内会議でそのまま使える粒度に整理しました。なお、より一般的な「外注前に整えておくべき準備物」の観点はシステム開発を外注する前の5つの準備でも整理しています。情シス有無に依らない外注準備の全体像を押さえたい方は、合わせてご覧ください。
発注前チェックリスト
窓口体制
- 発注窓口を担当する人物を1名指名している
- 副担当を1名置き、ボールの引き継ぎが可能になっている
- 兼任窓口に求められる5条件（時間・決裁・業務理解・コミュニケーション・文書化）を満たしている
- 経営層との決裁ルートが明確になっている
最低限の準備物
- 業務フローをA4 1〜2枚で書き出している（関係者・現行ツール・困りごと）
- 予算レンジを把握し、補助金活用の可能性を確認した
- スケジュールを決算期・本業繁忙期・社内可用性と照らし合わせた
外部伴走者
- ITコーディネーター・情シス代行・発注支援コンサルのうち、自社に必要な伴走者を1つ以上特定した
- 補助金（デジタル化・AI導入補助金）の活用可否を確認した
運用工数
- 窓口担当の週あたり工数（フェーズ別10〜20時間）を経営層と合意した
- 限界サインが出た場合のエスカレーション先を決めている
次の一歩
このチェックリストのうち、最初に着手すべきは「窓口の指名」と「業務フローのA4メモ作成」の2つです。この2つが固まれば、開発会社との初回打ち合わせは成立します。逆にこの2つが曖昧なまま打ち合わせを始めると、最初の数回がほぼ無駄になります。
情シスがない中小企業のシステム発注は、決して特別なテクニックを必要としません。窓口の役割・最低限の準備物・外部の伴走者という3要素を組み合わせれば、専任担当者 なし 外注は十分に成立します。社内会議で経営層に体制案を説明する際は、本記事の数字や役割定義をそのまま引用していただいて構いません。担当者の方が安心して次の一歩を踏み出せることを願っています。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
