社内システム開発の進め方【2026年版】業務の棚卸しと「作らない判断」、社内の合意形成から定着まで

「社内システムを作ることになったが、どこから手をつければいいのか分からない」——業務改善を任された方から、こうした相談をよく受けます。対象の業務は勤怠から受発注、在庫、申請、顧客管理まで広く、部署ごとに別のExcelが動いている。経営層は「DXで効率化」としか言わず、現場は「仕事が増えるだけだ」と身構えている。費用を調べる前に、何を作るかで止まってしまう。

結論から言うと、社内システム開発の成否は、コードを書き始める前の3つの決定でほぼ決まります。どの業務をシステム化するか(手作業の棚卸し)、それを本当に作る必要があるか(SaaSやノーコードで足りないか)、誰が何を決めるか(経営・情報システム・事業部門・ベンダーの役割分担)の3つです。この順番を飛ばして機能一覧から入ると、完成しても使われないシステムになります。

社内システムが外部向けの製品と決定的に違うのは、使う人が社内にいて、しかも使わない自由を持っている点です。現場が「前のExcelのほうが早い」と判断すれば、どれだけ機能を積んでも使われません。使われるかどうかを決めるのは機能の数ではなく、その人の手順が減ったかどうかです。だからこそ、作る範囲は小さいほど有利になります。

本記事では、対象業務の棚卸しと優先順位の付け方、SaaSやノーコードで足りるかを振り分ける「作らない判断」、情報システムと事業部門の役割分担と現場の合意形成、使われる状態を作る段階的な導入とベンダー選定の入口、よくある質問の順に解説します。規模別・機能別の費用相場は「業務システム 開発 外注 費用」の記事に譲り、本記事は企画から導入までに集中します。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。社内システムの相談で止まってしまうのは、決まって「全社の業務を1つにまとめる」構想から入った案件です。この記事を読み終えるころには、自社でどの業務から着手し、どこを作らずに済ませるかが判断できるはずです。

社内システム開発は「何を作るか」で決まる——対象業務の棚卸しと優先順位の付け方

社内システムの検討を任されたとき、最初にやるべきことは機能を決めることではありません。自社のどの業務を対象にするかを決めることです。社内で使う仕組みは勤怠・経費精算から受発注、在庫、申請、顧客管理、社内ポータルまで幅広く、部署によって呼び方も期待する役割も違います。まずは言葉の範囲をそろえ、手作業の実態を書き出すところから始めてください。

社内システムの4区分と一覧——基幹、業務、情報系、部門特化で自社の対象を指させるようにする

社内システムという言葉は、会社によって指す範囲がまったく違います。経営層は基幹システムを、現場は日々使う申請画面を思い浮かべていることが珍しくありません。次の4区分に分けて一覧にすると、自社の対象がどこかを指させるようになります。

「業務システム」と「社内システム」はほぼ同義で使われることも多いのですが、本記事では社内で使う仕組みの総称を社内システム、そのうち日常業務の入力と承認を担うものを業務システムと呼び分けます。どちらの言葉で社内の議論が進んでいるとしても、まずはこの表のどの行の話をしているのかを確認してください。ここがずれたまま進むと、要件の議論が噛み合いません。

手作業の棚卸し——「誰が・どの頻度で・どのデータを・何分かけて」の4項目で書き出す

対象候補が見えたら、次は手作業の棚卸しです。ここで機能一覧を書いてはいけません。書き出すのは、いま実際に人がやっている作業です。項目は4つで足ります。

この4項目を20〜30行ほど書き出すと、自社の業務の全体像が数字で見えるようになります。私が相談を受けるときも、最初にお願いするのはこのシートです。多くの場合、担当者が「大変だ」と感じている作業と、時間を実際に食っている作業は一致しません。感覚ではなく所要時間で並べ替えると、議論の前提が変わります。

書き出すときのコツは、例外処理を隠さないことです。「基本は注文書のとおりだが、A社だけは電話で変更が入る」といった例外こそ、後で現場が「このシステムでは回らない」と言い出す原因になります。例外は削るのではなく、まず全部書き出して、システム化するかしないかを後で決めてください。

優先順位は4つの軸で採点する——頻度、関わる人数、ミスの影響、属人度

棚卸しシートができたら、どれから着手するかを決めます。全部を同時に進めようとすると、どれも中途半端になります。次の4軸で各業務を3点満点で採点し、合計点の高いものから着手してください。

合計10点以上の業務が、最初に着手すべき候補です。逆に、合計6点以下の業務は、システム化しても効果が見えにくく、費用対効果の説明もしづらくなります。予算を通す社内説明でも、この採点表はそのまま使えます。

よくある課題5つ——目的が曖昧、要件が機能一覧になる、ベンダー主導、現場説明が後回し、成功基準がない

社内システムの開発でつまずく会社には、共通する課題が5つあります。ヒビノシステムの解説でも同じ5点が挙げられており、私の実感とも一致します。技術力の不足ではなく、着手前の決定が抜けていることが原因です。

1. 目的が曖昧なまま開発が始まる。「効率化」「DX推進」という言葉だけで、何がどうなれば成功かが決まっていない
2. 要件定義が機能一覧になる。現場が「使えない」と言う理由は機能の不足ではなく、遅い・分かりにくい・手順が増えたという使い勝手にあるのに、そこが議題に上がらない
3. ベンダー主導で設計が進む。業務の解像度が低いまま仕様書を埋めることが目的化する
4. 現場への説明が後回しになる。完成間際に初めて見せて、ちゃぶ台返しが起きる
5. 成功基準が決まっていない。導入後に「よくなったのか」を誰も判定できず、次の改善に進めない

私は2018年からホーチミンで約100社の開発体制の相談に乗ってきましたが、社内システムの相談で止まってしまうのは、決まって「全社の業務を1つにまとめる」構想から入った案件です。対象が広すぎて棚卸しが終わらず、関係部署が増えて決定が遅れ、半年経っても要件が固まらない。逆に動き出すのは、1つの部署の1つの業務に絞り、3か月で動くものを出してから広げる案件です。対象を絞れたら、次はその業務を本当に作る必要があるのかを確かめます。

「作らない判断」——SaaSやノーコードで足りるかを4つの問いで振り分ける

棚卸しで着手候補が絞れたら、次に確かめるのは「それを本当に作る必要があるか」です。開発会社の人間がこう書くと意外に思われるかもしれませんが、作らずに済む範囲は作らないほうがよい、というのが私の持論です。作る範囲が小さいほど、導入も速く、直し続ける負担も軽くなります。

4つの問い——標準化できるか、競争優位に直結するか、変更頻度は高いか、連携とデータ量はどうか

候補に挙がった業務を、次の4つの問いにかけてください。順番どおりに答えるだけで、作るべきかどうかの見当がつきます。

1. その業務は標準化できるか。 会計、勤怠、経費精算、給与のように、法令や商習慣で形が決まっている業務は、既製品に業務を合わせるほうが早く安全です。「うちのやり方」が本当に必要かを疑ってください
2. その業務は自社の競争優位に直結するか。 顧客に選ばれる理由そのものに関わる業務(独自の見積ロジック、独自の検査記録、自社商材の在庫引当など)は、作る価値があります
3. 変更の頻度は高いか。 半年に一度は仕様が変わる業務なら、変更しやすい形(ノーコードや小さな自作)が向きます。3年変わらない業務なら、既製品で構いません
4. 既存システムとの連携とデータ量はどうか。 基幹システムとの双方向連携、数百万件規模のデータ、複雑な権限制御がある場合は、既製品の標準機能では収まらないことが多くなります

4つのうち「標準化できない」「競争優位に直結する」の2つがそろったときだけ、作る価値が明確になります。逆に、標準化できて競争優位にも関わらない業務を独自開発するのは、費用の面でも保守の面でも失敗のもとです。

振り分けの早見表——SaaSに寄せる業務、ノーコードで試す業務、作る業務

4つの問いの答えを、次の表で振り分けます。判断に迷ったら、まず上の行から当てはめてください。

この3分類の定義と、パッケージ・フルスクラッチを含む細かい比較は「スクラッチ開発とは」の記事にまとめています。本記事では、自社の業務をどの行に置くかという判断に絞ります。なお、選び方によって費用が大きく変わる点については、規模別・機能別の相場を「業務システム 開発 外注 費用」の記事で扱っているので、金額の目安が必要な段階になったらそちらをご覧ください。

「全部を作る」をやめる——SaaSを土台にして、合わない部分だけを作る

実際の現場で最も効くのは、3つのうち1つを選ぶのではなく、組み合わせる考え方です。標準化できる業務はSaaSに寄せ、そのSaaSでどうしても合わない画面や承認フローだけを作る。この構成なら、作る範囲は当初の想定の2割か3割で済むことがあります。

たとえば、販売管理のパッケージが自社の締め処理と掛け率の計算に合わない、というご相談がありました。この場合、販売管理そのものを作り直すのではなく、パッケージはそのまま使い、締め処理の画面と計算だけを別に作ってデータを受け渡す形にすれば足ります。当社でも、お話を伺った結果「その用途なら既存のSaaSで足ります」とお伝えして、開発をお受けしなかったことが何度もあります。合わない案件にその旨を率直に申し上げるのは、後から作り直しになるほうがお互いに損だからです。

作る範囲を絞ると、もう1つ良いことがあります。現場に説明する内容が減るのです。「勤怠はこれまでどおり、変わるのは受注入力の画面だけです」と言えれば、次の章で扱う社内の合意形成は一気に楽になります。作らない判断は、費用の話であると同時に、社内調整の話でもあります。

社内の合意形成——情報システムと事業部門の役割分担、現場の抵抗をほどく順番

作る範囲が決まっても、社内の合意が取れていなければ動きません。そして導入して使われないシステムの原因は、ほとんどが技術ではなく社内の構造にあります。誰が何を決めるのかが空いたまま進むと、要件定義は機能一覧の確認作業に変わり、完成間際に「こんなはずじゃなかった」が噴き出します。

経営・情報システム・現場の「三すくみ」が要件定義を形骸化させる

社内システムの検討では、次の三すくみがよく起きます。NIアンドシー(XIMIX)の解説でも同じ構造が指摘されています。

• 経営層: 「コスト削減」「DX推進」という抽象的な号令にとどまり、投資対効果の判断を現場に委ねてしまう
• 情報システム部門: 業務の解像度が高くないまま、技術的な整合性と納期を優先し、仕様書を埋めることが目的になる
• 現場: 変化への警戒が働き、「どうせ意見を言っても通らない」と受け身になる。ヒアリングには応じるが本音を出さない

三者とも悪意はありません。それぞれの立場では合理的に動いています。だからこそ、放置しても解決しないのが実情です。解決の入口は、誰が何を決めるのかを紙に書いて配ることです。

誰が何を決めるか——4者の役割分担表と、決定権を空けてはいけない項目

次の表を、着手前に関係者で埋めてください。埋まらないマスがあれば、そこが後で揉める場所です。

◎ を空欄にしたまま進めるのは要注意です。特に「業務のあるべき姿」と「受け入れの合否判定」を事業部門が持たない体制では、現場が当事者になりません。逆に、事業部門にすべてを背負わせて情報システム部門が調整役に徹するのも、技術の判断が宙に浮くため危険です。開発会社に丸ごと委ねてよい範囲については「システム開発の外注 丸投げ」の記事でも整理しています。

現場の抵抗の正体は「手順が増える」への警戒——会議室で聞かず、現場を見て、動く画面で合意する

現場が新しい仕組みに抵抗するとき、本音は「変化が嫌だ」ではありません。「いまのやり方でぎりぎり回っているところに、新しい入力作業が増える」という具体的な警戒です。この警戒は、会議室でのヒアリングでは出てきません。担当者本人が日々の手順を当たり前だと思っており、わざわざ課題として言語化しないからです。

そこで有効なのが、次の2つです。1つは、現場に行って作業を見ることです。マニュアルに載っていないExcelの小技や、手書きメモのバケツリレーが必ず見つかります。もう1つは、仕様書ではなく動く画面で合意することです。数十ページの仕様書を読み解ける現場担当者はまずいません。ノーコードでも簡易な試作でもよいので、数週間で触れるものを出し、「この順番だと手が止まる」「ここはリスト選択にしてほしい」という具体的な反応をもらうほうが、文字での確認よりはるかに精度が上がります。

もう1点、現場に向けた言い方も効きます。「業務を効率化します」ではなく、「いまメールと転記で25時間かかっている作業を、10時間にします」と数字で言う。h2-1で作った棚卸しシートは、ここで説得の材料になります。要件定義そのものの進め方(決める7項目と5ステップ)は「要件定義の進め方」の記事に譲ります。

着手前に決める3つ——何を変えるのか、何を変えないのか、成功をどう測るのか

合意形成を一言でまとめると、次の3つを紙にすることです。

1. 何を変えるのか。 対象業務と、変わる手順を具体的に書く。「受注入力をメール転記からシステム入力に変える」まで書く
2. 何を変えないのか。 これが抜けている会社がほとんどです。「勤怠と経費精算は現行のまま」「A社向けの電話変更は当面いまの運用を残す」と明記すると、現場の警戒は目に見えて下がります
3. 成功をどう測るのか。 所要時間、入力ミスの件数、利用率のいずれかで測れる形にする。「効率化できた」では次の改善に進めません

この3つが決まっていれば、開発が始まってからの判断はほとんど機械的に片づきます。決まっていなければ、毎回の会議で最初から議論をやり直すことになります。あなたの会社では、いまこの3つを誰が決める立場にあるでしょうか。

使われるシステムにする段階的な導入と、ベンダー選定の入口——当社の位置づけ

社内システムは、リリースした日が終わりではなく始まりです。使われ方を見て直し続けられるかどうかで、投資が回収できるかが決まります。ここでは、小さく出して広げる進め方、定着のための設計、そして開発会社に相談する入口を整理します。

段階的な導入の4段階——1部署1業務のMVPから、横展開、連携、全社へ

全社一斉の切り替えは、関係者が多いほど決定が遅れ、問題が起きたときの影響も大きくなります。次の4段階で広げてください。

第1段階で「毎日触られない」と分かったら、そこで立ち止まるのが正解です。横展開に進む前に原因を潰せば、傷は小さく済みます。段階を分ける最大の利点は、失敗できる場所を用意しておくことにあります。

定着の設計——問い合わせ窓口、教育、旧運用の締切、利用ログの確認、権限とセキュリティ

導入そのものより難しいのが定着です。次の5点は、開発の計画と同時に決めてください。

• 問い合わせ窓口: 誰に聞けばよいかが分からないと、現場は元のやり方に戻ります。部署ごとに1人、質問を受ける担当を置くと定着率が上がります
• 教育: 全機能の説明会は不要です。その人が毎日使う3画面だけを、その人の実データで触ってもらうほうが効きます
• 旧運用の締切: 新旧の並行期間を設けるのは構いませんが、「◯月◯日で旧Excelは更新を止める」と期限を切ってください。期限がないと両方が残り、二重入力が固定化します
• 利用ログの確認: 誰がどの画面をどれだけ使っているかを月次で見ます。使われていない画面は、消すか直すかのどちらかです
• 権限とセキュリティ: 閲覧・作成・編集・承認・削除・エクスポートを分けて設計し、退職者アカウントの停止手順と監査ログを最初から用意します

ベンダー選定の入口——要件が固まる前に相談してよい。確認する5項目と、費用の考え方

「要件が固まっていないので、まだ相談できない」とおっしゃる方が多いのですが、固める前で構いません。むしろ、社内だけで固めきってから相談すると、技術的にもっと簡単な方法があっても後戻りできなくなります。棚卸しシートと、先ほどの「変える・変えない・成功の測り方」の3点があれば、相談の材料としては十分です。

相談する会社を選ぶとき、最初に確認したいのは次の5項目です。

1. 要件が固まる前の段階から一緒に整理してくれるか(いきなり見積書だけが出てくる会社は、後で要件変更に弱い)
2. 同じ規模・同じ業種の社内システムを作った実績があるか。画面の作り方だけでなく、権限設計と移行の経験があるか
3. 作った後に誰が直すのか。保守の範囲と、機能追加を頼むときの進め方が決まっているか
4. 見積もりに何が含まれ、何が含まれていないか。データ移行、既存システム連携、教育、初年度の保守の扱いを確認する
5. 「作らないほうがよい」と言ってくれるか。SaaSで足りる場面でそう伝える会社のほうが、長い目では信用できます

費用については、画面数だけで決まらない点を押さえてください。金額を押し上げるのは、権限の複雑さ、既存システムとの連携、データ移行、そして運用保守の範囲です。規模別・機能別の相場と見積書に載らない費用は「業務システム 開発 外注 費用」の記事で詳しく扱っています。内製と外注のどちらで進めるかで迷っている場合は「システム開発 内製 外注」の記事の比較表が判断材料になります。

当社の位置づけ——ラボ型で作った後も直し続ける体制。向く案件と向かない案件

当社はベトナム・ホーチミンを拠点に、ラボ型(準委任)で専属チームを提供しています。社内システムとの相性がよいのは、作って終わりではなく、使われ方を見ながら直し続ける形に合っているからです。オフショア開発白書2025年版(オフショア開発.com、2026年9月21日確認)では、ラボ型が契約形態の45%で最多となりました。

体制は、日本人PMまたはブリッジSEをフロントに置き、その後ろにエンジニアを配置するパターンAを推奨しています。2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインし、協力会社を挟まないため仲介マージンがかかりません。公開している単価は実務3年目安で1,500USD(約22.5万円/1USD=150円換算目安)、5年で2,000USD、10年目安とブリッジSEで3,000USDです。最小構成は日本人PMフロント+2〜3人月で月額約80万円〜、1名から契約でき、開始は最短2週間、増員は約1週間、縮小と交代は1か月単位で調整できます。品質は、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点で担保しています。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

実績では、介護記録SaaS「CareViewer」を日本語ブリッジSE1名とフルスタックエンジニア2名の体制で支援し、週次で優先順位を判断しながら継続開発しています。社内システムに近い性質のものでは、求人プラットフォーム(ATS)やヘッドレスCMSを用いたWebサイトの構築を手がけてきました。ベトナムとの時差は2時間で、午前中に出した判断がその日のうちに反映されます。祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)、テト(旧正月)休暇は2026年が2月14日から22日です。

一方で、当社が向かない案件もあります。要件が完全に確定していて一度きりのリリースで終わる小規模な開発、社内に優先順位を判断する担当をどうしても置けない案件、そしてSaaSの標準機能で足りる業務です。最後のものについては、お話を伺った段階で率直にお伝えしています。作らずに済むものを作ってしまうと、その後の保守費まで抱えることになるからです。ここまでの手順を踏めば、自社が本当に作るべき範囲は最初の想定よりずっと小さくなっているはずです。

社内システム開発でよくある質問

社内システムの企画段階で、相談の場で繰り返し聞かれる質問を5つにまとめました。社内の検討会議でそのまま使える形にしています。

Q1. 費用はどのくらいかかりますか?

金額は画面数ではなく、権限の複雑さ、既存システムとの連携、データ移行、保守の範囲で決まります。当社のラボ型では、日本人PMフロント+2〜3人月の最小構成で月額約80万円〜が目安です。規模別・機能別の相場は「業務システム 開発 外注 費用」の記事をご覧ください。

Q2. 期間はどのくらいかかりますか?

1部署1業務のMVPであれば2〜3か月が目安です。そこから横展開に1〜2か月、基幹システムとの連携とデータ移行に2〜3か月というのが、当社が現場で使っている段階ごとの目安です(業界の標準として定められた期間ではありません)。全社を一度に切り替えようとすると、この何倍もかかるうえに失敗のもとです。

Q3. 情報システム担当が1人しかいなくても進められますか?

進められます。ただし、その1人にすべてを背負わせない設計が必要です。対象業務と受け入れ判定は事業部門が持ち、技術方式と権限方針を情報システムが持つ、という役割分担を最初に紙にしてください。開発会社側にPMを置く体制にすれば、日々の進行管理と品質確認は巻き取れます。

Q4. SaaSと併用できますか?

できますし、そのほうが現実的です。会計や勤怠のように標準化しやすい業務はSaaSに残し、合わない画面や承認フローだけを作ってデータを受け渡す構成が、作る範囲を最も小さくします。連携の方式(API連携か、ファイル連携か)は早い段階で確認してください。

Q5. 既存システムからの移行で気をつけることはありますか?

データの正本をどちらに置くかを決めること、移行対象の期間を絞ること、そして並行稼働の終了日を先に決めることの3点。

まとめ: 対象を絞り、作らずに済む部分は買い、誰が決めるかを先に決める

社内システム開発の成否は、コードを書き始める前の3つの決定で決まります。1つ目は、どの業務をシステム化するか。基幹・業務・情報系・部門特化の4区分で自社の対象を指させるようにし、「誰が・どの頻度で・どのデータを・何分かけて」の4項目で手作業を棚卸しし、頻度・人数・ミスの影響・属人度の4軸で優先順位を採点します。2つ目は、それを本当に作るか。標準化できるか、競争優位に直結するか、変更頻度は高いか、連携とデータ量はどうかの4つの問いで、SaaSに寄せる業務、ノーコードで試す業務、作る業務に振り分けます。

3つ目は、誰が何を決めるか。経営層・情報システム部門・事業部門・開発会社の役割分担表を着手前に埋め、「何を変えるのか」「何を変えないのか」「成功をどう測るのか」の3点を紙にします。使われないシステムの原因は技術ではなく、この3点が決まっていない構造にあります。導入は1部署1業務のMVPから4段階で広げ、問い合わせ窓口・教育・旧運用の締切・利用ログ・権限設計をあらかじめ設計してください。開発会社には、要件が固まる前の段階で相談して構いません。

当社はホーチミンを拠点に、日本人PMをフロントに置いたラボ型の専属チームを提供しています。1名から、最短2週間で開始でき、最小構成は日本人PMフロント+2〜3人月で月額約80万円〜。作って終わりではなく、使われ方を見ながら直し続ける形に向いた体制です。規模別・機能別の費用相場は業務システム開発を外注する費用、内製と外注のどちらで進めるかの比較はシステム開発は内製か外注かもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、どこまで作るべきかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。