情シスがいない中小企業がシステム開発を進める方法｜発注側の体制づくり

中小企業では、社内に情報システム部門がなく、パソコンやネットワークの面倒を詳しい社員が兼務で見ている、という形が珍しくありません。その状態で業務システムの開発を外部に依頼しようとすると、何から決めればよいのか、誰が窓口になるのか、開発会社の説明が妥当なのかが分からず、手が止まってしまいがちです。

情シスがいないこと自体は、システム開発ができない理由にはなりません。開発会社に依頼する以上、技術的な作業の多くは外部が担います。発注側に必要なのは、プログラムの知識よりも、何を実現したいのかを決め、開発の途中で判断を下し、できあがったものを受け入れて使い続ける体制です。

逆に、この体制がないまま開発会社に任せきりにすると、業務に合わないシステムができあがったり、追加費用がふくらんだり、納品後に誰も管理できない状態になったりします。原因の多くは技術ではなく、発注側の役割が決まっていないことにあります。

この記事では、情シスがいない中小企業がシステム開発を進めるために、最低限そろえたい役割、発注前に社内でまとめること、開発中の関わり方、納品後の運用とセキュリティの考え方を解説します。

情シスがいない会社で起きやすい問題

まず、情シスがいない会社のシステム開発で、どのような問題が起きやすいかを整理しておきます。原因が分かれば、どの役割を補えばよいかも見えてきます。

起きやすい問題	根本の原因
開発会社からの質問に答えられず、開発が止まる	業務の細かいルールを知っている人が、開発のやりとりに参加していない
途中で社長や現場から要望が追加され、費用がふくらむ	何を作るかを最終的に決める人と、その範囲が決まっていない
完成したものが現場の使い方に合わない	現場の担当者が、開発の途中で画面や動きを確認していない
納品後、不具合や改修の窓口が分からない	運用の担当者と保守契約の範囲が決まっていない
アカウントやパスワードの所在が分からなくなる	開発会社に任せたまま、自社で管理する仕組みがない

いずれも、ITの専門知識がないことよりも、役割と決め方が曖昧なことから生じています。情シスがいない会社に必要なのは、専門家を雇うことよりも、既存の社員の中で役割を割り振り、判断の流れを決めることです。

最低限そろえたい発注側の役割

システム開発の発注側には、少なくとも次の役割が必要です。小さな会社では1人が複数の役割を兼ねてもかまいませんが、誰がどの役割を担うのかは明確にしておきましょう。

役割	担うこと	向いている人
決裁者	予算と目的を決め、範囲の変更や追加費用を最終判断する	経営者、事業責任者
プロジェクト責任者	開発会社との窓口になり、質問に回答し、社内の意見をまとめる	対象業務を理解していて、社内の調整ができる人
業務担当者	実際の業務の流れや例外を説明し、画面や動きを確認する	そのシステムを日常的に使う現場の人
運用担当者	納品後のアカウント管理、不具合の連絡、利用者からの問い合わせ対応	プロジェクト責任者が兼ねることが多い

このなかで最も重要なのがプロジェクト責任者です。ITに詳しい社員を選びたくなりますが、優先すべきは対象業務への理解と、社内の意見をまとめられることです。開発会社の質問の多くは「この場合、業務ではどう扱っていますか」という業務の確認であり、技術の知識はそれほど求められません。

また、プロジェクト責任者には、通常業務とは別に時間を確保する必要があります。開発の時期によって負荷は変わりますが、要件を固める時期と受入テストの時期は、とくに多くの時間を取られます。通常業務を減らさずに兼務させると、回答が遅れて開発全体が遅れる原因になります。

決裁者とプロジェクト責任者が同じ人の場合は、判断は速くなる一方で、現場の意見が反映されにくくなります。この場合は、業務担当者の確認の場を意識して設けるとよいでしょう。

社内だけでは開発会社の提案や見積もりの妥当性を判断できない場合は、発注側の立場で助言する外部の専門家に、要件整理や見積もりの比較の段階だけ相談する方法もあります。その場合も、判断そのものは社内の決裁者が行うという線引きを保つことが大切です。

発注前に社内でまとめておくこと

開発会社に相談する前に、社内で整理しておくと、その後のやりとりが大きく変わる項目があります。完璧な資料は必要ありません。箇条書きのメモでも、次の内容があれば開発会社は具体的な提案をしやすくなります。

• システムで解決したい課題と、その課題でいま困っていること
• 対象となる業務の流れ（誰が、何を、どの順番で行っているか）
• 現在使っているExcelや紙の帳票、既存のシステム
• システムを使う人の人数と、社外の人が使うかどうか
• 予算の上限と、いつまでに使い始めたいか
• 必ず実現したいことと、できればほしいことの区別

このうち、必ず実現したいこととできればほしいことの区別は、費用を抑えるうえで特に効きます。すべての要望を同じ重さで伝えると、開発会社はすべてを含めた見積もりを出すため、金額が大きくなりがちです。優先順位がはっきりしていれば、最初は必須の機能だけで使い始め、運用しながら追加していく進め方も提案しやすくなります。

業務の流れは、普段の手順だけでなく、例外的な処理も書き出しておきましょう。「月末だけ処理が違う」「特定の取引先だけ別の扱いをしている」といった例外は、開発の後半で見つかると手戻りが大きくなります。業務担当者に、過去に困ったケースを思い出してもらうと洗い出しやすくなります。

予算は、相談の最初の段階で上限を伝えておくほうが、結果的に話が早く進みます。予算を伏せて見積もりを依頼すると、開発会社は要望をすべて満たす前提で金額を出すため、予算を大きく超えた見積もりが返ってきて、範囲の調整からやり直すことになりがちです。上限が分かっていれば、その範囲で何を優先して作るかという提案を受けられます。

なお、課題によってはシステムを新しく作るよりも、既製のSaaSやパッケージを使うほうが早く安く済むこともあります。会計や勤怠のように、どの会社でも業務の流れが似ている領域ではその可能性が高いため、開発を前提にせず、課題として相談するのがおすすめです。

開発会社との打ち合わせで確認したいこと

情シスがいない会社にとっては、開発会社選びも悩みどころです。技術的な提案の良し悪しを判断するのは難しくても、打ち合わせでの受け答えから、発注側に合った進め方をしてくれる会社かどうかはある程度見極められます。

確認したいこと	見るポイント
専門用語を使わずに説明してくれるか	こちらの理解に合わせて言い換えられるか。分からない点を聞きやすい雰囲気か
業務について質問してくるか	機能の話だけでなく、業務の流れや困りごとを掘り下げてくれるか
開発しない選択肢も示してくれるか	既製のサービスで足りる部分があれば、そう伝えてくれるか
発注側に求める役割を説明してくれるか	誰が何をいつまでに決める必要があるかを、最初に示してくれるか
納品後の体制を説明してくれるか	保守の範囲、問い合わせの窓口、対応時間が明確か

とくに、発注側に求める役割を最初に説明してくれる会社は、情シスがいない会社にとって進めやすい相手です。「すべてお任せください」という説明は安心感がありますが、実際には発注側の判断が必要な場面が必ず訪れます。その場面を事前に示してくれるかどうかで、開発中の行き違いは大きく減ります。

開発中の関わり方と判断のルール

開発が始まってからも、発注側にはいくつかの関わりが求められます。任せきりにすると、完成した段階で「思っていたものと違う」となりやすいためです。

開発中に発注側が関わる主な場面と、それぞれのポイントは次のとおりです。

場面	発注側がやること
定期的な進捗の確認	予定どおり進んでいるか、判断待ちになっている事項がないかを確認する
開発会社からの質問への回答	期限を決めて回答する。社内で決められない事項は決裁者に上げる
画面や試作品の確認	業務担当者が実際の業務を想定して操作し、気づいた点を伝える
仕様変更や追加要望の判断	費用と期間への影響を確認したうえで、決裁者が判断する
受入テスト	業務の流れに沿って動作を確認し、問題がなければ検収する

とくに決めておきたいのが、仕様変更や追加要望の扱いです。開発の途中で現場から要望が出ることは避けられません。そのたびに開発会社へ直接伝えてしまうと、範囲が少しずつ広がり、最終的に費用と期間が大きくふくらみます。要望はプロジェクト責任者が集約し、費用と期間への影響を開発会社に確認したうえで、決裁者が採否を決めるという流れを最初に決めておきましょう。

判断の基準もあらかじめ決めておくと迷いが減ります。たとえば、「業務が回らなくなる要望は今回の開発に含める」「あると便利な要望は使い始めてから次の改修で検討する」といった基準です。基準があれば、プロジェクト責任者が現場に説明するときにも根拠を示しやすくなります。

納品後の運用とセキュリティの体制

システムは納品されてからが本番です。情シスがいない会社では、納品後の運用を誰が担うかが曖昧になりやすく、不具合の連絡が遅れたり、退職者のアカウントが残り続けたりします。

納品前に、次の点を決めておきましょう。

• 利用者からの問い合わせや不具合の報告を、誰が受けて開発会社に伝えるか
• 保守契約で、どこまでの対応が月額に含まれ、どこからが追加費用になるか
• 入社や退職のときに、誰がアカウントを追加・削除するか
• クラウドやドメイン、外部サービスの契約者と管理者が誰か
• 管理者のパスワードや認証情報を、社内のどこでどう保管するか

クラウドやドメインなどの契約は、開発会社の名義ではなく自社の名義にしておくことをおすすめします。開発会社の名義のままだと、将来ほかの会社に保守を切り替えるときに移管の手続きが必要になり、場合によっては乗り換えの妨げになります。

セキュリティについては、情報処理推進機構（IPA）が「中小企業の情報セキュリティ対策ガイドライン」を公開しています。2026年3月27日に第4.0版が公開されており、経営者編と実践編からなる本編に加えて、「5分でできる！情報セキュリティ自社診断」や情報セキュリティ関連規程のサンプル、クラウドサービス安全利用の手引きなどが付録として用意されています。第4.0版では、従来の「情報セキュリティ5か条」に「バックアップを取ろう！」が加わり、「6か条」になりました。情シスがいない会社でも取り組みやすい内容なので、まずは自社診断で現状を確認してみるとよいでしょう（内容は改訂されることがあるため、最新版を確認してください）。

データのバックアップについても、誰がどこまで責任を持つのかを確認しておきましょう。クラウドの設定で自動的にバックアップが取られている場合でも、どのくらいの期間分が残っているのか、実際に復元できるのか、復元を依頼したときに費用がかかるのかは、契約や設定によって異なります。重要なデータを扱うシステムであれば、年に一度は復元の手順を確認しておくと安心です。

開発会社に対しては、システムのセキュリティ対策としてどこまで対応しているか、脆弱性が見つかった場合の対応が保守契約に含まれるかを確認しておきます。社内の運用で守るべきことと、開発会社が担うことを分けて把握しておくと、抜け漏れを防げます。

参考：中小企業の情報セキュリティ対策ガイドライン／IPA（情報処理推進機構）

まとめ

情シスがいない中小企業でも、システム開発は進められます。必要なのは技術の専門家ではなく、決裁者、プロジェクト責任者、業務担当者、運用担当者という役割を社内で割り振り、要望の扱い方や判断の基準を決めることです。

会社の状況によって、最初の一歩は変わります。

状況	最初にやること
開発を検討し始めたばかり	プロジェクト責任者を決め、解決したい課題と業務の流れをメモにまとめる
開発会社に相談しているが、話がかみ合わない	必須の要望とできればほしい要望を分け、予算と時期の条件を伝え直す
すでに開発が進んでいる	追加要望の窓口と決裁の流れを決め、開発会社と共有する
システムが稼働している	アカウントと契約の名義、保守の窓口を一覧にし、自社診断でセキュリティの現状を確認する

明日からできることとしては、社内で誰がプロジェクト責任者を担えるかを考え、その人の通常業務をどう調整するかを決裁者と話し合うことから始めてみてください。役割が決まれば、開発会社とのやりとりは格段に進めやすくなります。