
目次
「システム開発を検討しているが、何から始めればよいかわからない」「費用の相場や開発会社の選び方を知りたい」という方に向けて、この記事ではシステム開発の基礎知識から実践的な発注の流れまでを体系的に解説します。
この記事でわかること
- システム開発の種類・工程・手法の違い
- システム種別の費用目安と見積もりのチェックポイント
- システム開発会社に外注する際の流れと選び方
- 2026年現在の最新開発トレンド(AI活用・クラウドネイティブ・DevSecOps)
システム開発の全体像を把握したい方、外注先の選定を進めている方は、ぜひ最後までお読みください。
システム開発とは?わかりやすく解説

システム開発とは、企業や組織の業務を効率化し、生産性を向上させるためのソフトウェアやシステムを作り上げる過程を指します。
作業の流れは、以下のとおりです。
- 要件定義(クライアントの要望や課題分析)
- 設計
- 開発(プログラミング)
- 試験
- 導入
開発の目的は、業務プロセスの改善や自動化、データ管理の効率化、顧客サービスの向上など多岐にわたります。
システム開発の目的
システム開発とは、企業や組織が抱える課題を解決するために、コンピューターシステムやソフトウェアを設計・構築するプロセス全体を指します。単にプログラムを書くことにとどまらず、「何のために作るのか」という目的の定義から、設計・開発・テスト・リリース・運用保守まで、一連の工程をすべて含む概念です。
システム開発の目的は、大きく以下の3つに分類できます。
| 目的の分類 | 具体的な内容 | 代表的なシステム例 |
|---|---|---|
| 業務効率化・自動化 | 人手で行っていた作業をシステムに置き換え、ミスの削減と処理速度の向上を実現する | 勤怠管理・受発注・在庫管理システム |
| データ管理・活用 | 社内外のデータを一元管理し、分析・意思決定に活用できる環境を整える | CRM・SFA・BIダッシュボード |
| 顧客サービスの向上・新規事業創出 | ユーザー体験を改善したり、新たなサービスをデジタルで提供したりする | ECサイト・予約システム・マッチングプラットフォーム |
システム開発はIT部門だけの取り組みではなく、経営課題や事業戦略と直結する企業活動です。「どの課題をシステムで解決するか」の判断が、開発の成否と投資対効果を大きく左右します。
システム開発が必要なシーンと活用例
システム開発が検討されるのは、業務上の非効率や課題が顕在化したタイミングがほとんどです。以下のようなシーンで「システムを作る・刷新する」という判断が生まれます。
| よくあるシーン | 課題の例 | 導入されるシステム例 |
|---|---|---|
| 手作業・Excelでの管理が限界 | 入力ミス・集計漏れが多発。更新のたびに複数ファイルの修正が発生し工数を圧迫している | 業務管理システム・基幹システム |
| 複数ツールのデータがバラバラ | 顧客情報が営業・CS・経理で分断されており、横断的な分析や対応ができない | CRM・SFA・データ連携基盤 |
| 紙・FAXベースの業務が残っている | 書類の作成・承認・保管に多大な時間がかかり、テレワーク推進の障壁になっている | 電子申請・ワークフローシステム |
| 市販のSaaSでは対応しきれない | 自社独自の業務フローや商習慣に合わせた細かいカスタマイズが必要で、パッケージでは限界がある | スクラッチ開発による業務特化システム |
| 新規サービスをデジタルで立ち上げたい | 新事業やサービスのプラットフォームをゼロから構築したい。競合との差別化機能が必要 | Webサービス・アプリ・マッチングプラットフォーム |
| 既存システムの老朽化(2025年の崖) | レガシーシステムの保守コストが増大し、新機能追加や外部連携が困難になっている | システムリプレース・マイグレーション |
特に近年は「2025年の崖」問題として、老朽化した基幹システムの刷新が経営課題として注目されています。経済産業省の試算では、DX推進が遅れた場合に2025年以降で最大年間12兆円の経済損失が生じるとされており、システム開発・刷新の重要性は年々高まっています。
システム開発会社とソフトウェア開発の違い
システム開発会社とソフトウェア開発会社の違いは、以下のとおりです。
| システム開発会社 | ソフトウェア開発会社 | |
|---|---|---|
| 対応範囲 | 企業の業務全体を総合的に捉える | プログラムやアプリの開発に特化 |
| 対象 | ハードウェアやネットワークも含めたソリューションを提供 | 特定の機能やアプリの開発に焦点を当てる |
| 求められるもの | 広範囲な知識と経験が求められる | 専門性の高い技術力が重視される |
システム開発会社は、プロジェクト管理やコンサルティングなども行う場合が多いです。一方、ソフトウェア開発会社はコーディングや技術的な実装に重点を置く傾向があります。
関連記事:ソフトウェア開発とシステム開発の違いとは?開発の流れや種類を解説
システム開発の種類

システム開発の種類は、4つあります。
- スクラッチ開発(フルオーダー)
- パッケージ開発(カスタマイズ)
- クラウドサービス活用(SaaS連携)
- オフショア開発・ニアショア開発
それぞれ詳しく解説します。
スクラッチ開発(フルオーダー)
スクラッチ開発とは、市販のパッケージソフトウェアやテンプレートを一切使わず、1からプログラムを生成してシステムを作り上げる開発手法です。既製品には存在しない機能が必要なときや、自社の業務フローに完全に合わせた設計が求められる場面で選ばれます。
スクラッチ開発の主なメリットは4点あります。
- サポート終了のリスクがなく長期間使い続けられる
- 独自機能を実装できるため競争優位性を築ける
- 予算に合わせた段階的な開発が可能
- 1から構築するため、セキュリティ設計やシステム障害時の対応まで自由にコントロール可能
一方のデメリットは以下の2つです。
- あらゆる仕様をゼロから決めるためプロジェクトマネージャーの負担が大きい
- 開発費用と期間がかかる(小規模なシステムでも6ヶ月〜1年)
そのため、スクラッチ開発は、パッケージ開発では実現できない高度な機能を有したい場合や社内の独自フローに適応したい場合に適した手法といえるでしょう。
パッケージ開発(カスタマイズ)
パッケージ開発とは、スクラッチ開発とは反対に、既製品のソフトウェアをベースにカスタマイズしてシステムを構築する手法です。
テンプレートや部品を組み合わせるため、スクラッチ開発と比べて開発期間が短く、初期コストを抑えられます。会計システムやグループウェアなど、業界標準の機能がすでに揃っているジャンルでは特に有効です。
一方で、パッケージ製品の仕様範囲内でしかカスタマイズできないため、自社独自の業務フローへの対応や画面のカスタマイズに限界が生じる場合があります。
また、運営会社の事情によってはサポートが終了し、セキュリティリスクなども念頭に置く必要があります。
パッケージ開発は、コストと速度を重視し、標準機能で業務要件を満たせるかどうかが導入判断の鍵です。
クラウドサービス活用(SaaS連携)
クラウドサービス活用(SaaS連携)とは、Salesforceやkintoneなどの既存のクラウドサービスをそのまま利用したり、APIで自社システムと連携させたりする手法です。初期投資がほぼ不要でサービス開始までの時間が短く、利用人数や機能に応じてプランを変更できる柔軟性が強みです。
一方で、サービス提供会社の仕様変更や価格改定の影響を直接受けるリスクがあります。
また、カスタマイズの自由度はスクラッチ開発より低く、複数のSaaSを連携させる際はデータ管理や権限設計が複雑になりやすい点に注意が必要です。
クラウドサービスの活用は、業務の標準化が進んでいる領域や、まず素早く立ち上げたい場合に適しています。
オフショア開発・ニアショア開発
オフショア開発とは、人件費の低い海外(中国・ベトナム・インドなど)の開発会社にシステム開発を委託する手法です。
コスト削減効果が大きく、国内では確保しにくい技術領域のエンジニアを活用できるメリットがあります。
ニアショア開発は、国内の地方都市にある開発会社へ委託するもので、時差や言語の壁がなく、コミュニケーションコストを抑えながらコスト削減を図れます。
どちらも開発費用を抑える手段として有効ですが、言語・文化・時差によるコミュニケーションのズレが品質や納期に影響するケースがあります。
要件定義を国内で固めてから委託する、進捗管理の仕組みを整えるなど、ブリッジSEの活用も含めた体制づくりが成否を左右します。
システム開発の工程・流れ

システム開発の工程は、以下のとおりです。
- 要件定義
- 外部設計
- 内部設計
- 製造(プログラミング)
- 試験
- 運用・保守
それぞれ詳しく解説します。
関連記事:システム開発の工程を徹底解説!要件定義から運用まで失敗しない進め方と注意点
1.要件定義
要件定義は、システム開発プロジェクトの一番最初の工程を指します。クライアントのニーズや課題を明確化し、開発するシステムの目的や機能を決定します。
業務プロセスの分析や現状における問題点の洗い出し、新システムに求められる機能や性能の特定を行う流れです。
関連記事:システム開発の要件定義とは?欠かせない要素と作り方を解説
2.外部設計(基本設計)
外部設計(基本設計)は要件定義で明確化されたシステムの機能や性能を、具体的な設計に落とし込む工程です。ユーザーインターフェース(UI)の設計や画面遷移の定義、入出力データの仕様決定などを行います。
目的は、システムの外部から見た振る舞いや機能を明確にすることです。画面レイアウトやメニュー構成、データ入力フォームなどを設計し、ユーザビリティを考慮したインターフェースを作成します。
3.内部設計(詳細設計)
内部設計(詳細設計)は、外部設計(基本設計)で定義されたシステムの機能や振る舞いを実現するために、内部構造やロジックを設計する工程です。システムのアーキテクチャ設計やデータベース設計、モジュール設計などを行います。
目的はシステムの内部構造を明確にし、効率的で保守性の高いシステムを実現することです。システムを構成するモジュールやコンポーネントの定義、それらの間のインターフェースの設計などを実施します。
関連記事:詳細設計の成果物は何が重視される? 進め方や注意点を紹介
4.製造(プログラミング)
製造は、内部設計で定義されたシステムの構造やロジックを実際のプログラムコードとして実装する工程です。選定したプログラミング言語や開発フレームワーク、ライブラリを使用して、システムの各機能やモジュールを開発します。
目的は、設計書に基づいて動作する実際のソフトウェアを作成することです。ユーザーインターフェースやビジネスロジック、データアクセス層などの実装を行います。
また、コードの品質を確保するため、以下の項目に注意が必要です。
- コーディング規約の遵守
- 適切なコメントの記述
- 効率的なアルゴリズムの使用
プログラミングでは、バージョン管理システムを使用してコードの変更履歴を管理し、複数の開発者が協調して作業できる環境を整えることも欠かせません。
5.試験
試験は、開発されたシステムが要件を満たし、正しく動作するか確認する工程です。さまざまなレベルと種類の試験を実施し、システムの品質を保証します。
おもに、以下が実施されます。
- 試験ケースの設計
- 試験環境の準備
- 試験の実行
- 結果の分析
- 不具合の修正
目的はバグや不具合を発見・修正し、システムの信頼性と安定性を確保することです。段階的に以下の試験を実施することが一般的です。
| 種類 | 内容 |
| 単体試験 | 個々のモジュールの動作を確認 など |
| 結合試験 | 複数のモジュールの連携を確認 など |
| 総合試験 | システム全体の機能や性能を検証 など |
| 受入試験 | セキュリティ試験や負荷試験 など |
適切な試験の実施は、高品質なシステムの提供とユーザー満足度の向上につながります。
関連記事:システム開発におけるテストの種類は?工程別に特徴と進め方、成果物を解説
6.運用とサポート
運用とサポートは、開発されたシステムを実際の業務環境に導入し、維持と改善を継続していく工程です。システムが稼働した後に始まり、ライフサイクルが終了するまで続きます。
運用とサポートの目的はシステムの安定稼働を確保し、ユーザーに価値を提供し続けることです。具体的には、以下があります。
- システムの監視
- パフォーマンス管理
- セキュリティ管理
- バックアップとリカバリ
- ユーザーサポート
- トラブルシューティング
また、定期的なメンテナンスやアップデート、機能拡張なども行います。
運用とサポートでは、インシデント管理や問題管理、変更管理などのITILプロセスを導入し、効率的なサービスを提供しなければいけません。さらに、ユーザーからのフィードバックを収集し、システムの改善に活かす必要があります。
システム開発の手法・開発モデル
システム開発の手法・モデルはいくつかありますが、ここでは以下の開発手法の詳細と、各手法の選び方についてご紹介します。
- ウォーターフォール開発
- アジャイル開発
- スクラム開発
- スパイラル開発
- プロトタイプ・MVP開発
- ノーコード・ローコード開発
ウォーターフォール開発
ウォーターフォール開発とは、要件定義→設計→製造→テスト→リリースという工程を上から下へ順番に進める開発手法です。各工程を完了してから次の工程に移るため、全体の計画とスケジュールが立てやすく、進捗管理や品質管理がしやすい点が特徴です。
要件が開発着手前に固まっており、仕様変更が少ないプロジェクトに向いています。一方で、開発途中での大きな仕様変更には対応しづらく、テスト工程になって初めて問題が発覚するリスクもあります。基幹システムや官公庁向けの大規模開発など、要件が明確で変更が少ない案件で多く採用されています。
アジャイル開発
アジャイル開発とは、開発を小さなサイクル(イテレーション)に分けて繰り返しながら、機能単位でリリースを積み重ねていく開発手法の総称です。「アジャイル(agile)」は「機敏な」を意味し、仕様変更や市場の変化に素早く対応できることが最大の特徴です。
ウォーターフォール開発と異なり、最初に全要件を固定せず、優先度の高い機能から順に開発してフィードバックを反映しながら進めます。スクラムやカンバンなど複数の手法がアジャイルの考え方を具体化したものとして位置づけられます。変化の激しい事業領域や、ユーザー検証を早期に繰り返したいプロダクト開発に適しています。
関連記事:アジャイル開発とウォーターフォール開発の違いとは?メリット・デメリットを解説!
スクラム開発
スクラム開発は、アジャイル開発の代表的な手法のひとつです。「スプリント」と呼ばれる1〜4週間の短い開発サイクルを繰り返し、スプリントごとに動作する成果物(インクリメント)を積み上げていきます。プロダクトオーナー・スクラムマスター・開発エンジニアという役割分担のもと、毎日の短いミーティング(デイリースクラム)や振り返り(レトロスペクティブ)を通じてチームで継続的に改善します。
仕様変更への柔軟な対応とPDCAサイクルの高速回転が強みですが、メンバーのスキルや自律性が求められるため、チーム構築の難度は高い手法です。小〜中規模の開発プロジェクトや、要件が変化しやすいプロダクト開発に適しています。
関連記事:スクラム開発とは?進め方・メリット・デメリット・失敗例までわかりやすく解説
スパイラル開発
スパイラル開発とは、システムをいくつかのサブシステムに分割し、「計画→設計→開発→評価」のサイクルを螺旋(スパイラル)状に繰り返しながら段階的に完成度を高めていく開発手法です。各サイクルの評価段階でリスク分析を行い、問題があれば次のサイクルで修正するため、大規模システムでもリスクを管理しながら開発を進められます。
ウォーターフォール開発の計画性とアジャイル開発の柔軟性を組み合わせた中間的な手法といえます。サイクルごとにステークホルダーの確認を挟めるため要件の認識ズレを防ぎやすい反面、サイクル管理の工数がかかり、プロジェクトが長期化しやすい点に注意が必要です。
プロトタイプ開発・MVP開発
プロトタイプ開発とは、初期段階で試作品(プロトタイプ)を作成し、ユーザーや発注者に確認してもらいながら要件を固めていく手法です。画面や機能のイメージを早期に可視化することで認識ズレを防ぎ、手戻りを減らす効果があります。
MVP(Minimum Viable Product)開発は、最小限の機能だけを持つ製品をいち早くリリースして市場の反応を検証し、フィードバックをもとに機能を拡張していく考え方です。
関連記事:MVP開発とは?開発にかかる期間やコスト、PoCやプロトタイプとの違いについて解説
両手法に共通するのは「作りながら要件を磨く」アプローチです。新規サービスや要件が曖昧なプロジェクト、ユーザーのニーズを早期検証したい場合に特に有効です。一方で、試作を繰り返す分スケジュールや予算の管理が難しくなりやすいため、プロトタイプの目的と範囲を事前に明確にすることが重要です。
ノーコード開発・ローコード開発
ノーコード開発・ローコード開発とは、プログラミングの記述量を最小化(ローコード)または不要(ノーコード)にして、GUIの操作やテンプレートの組み合わせでシステムやアプリを構築する手法です。kintone・Bubble・AppSheetなどのプラットフォームを活用することで、エンジニアでなくても業務システムやWebアプリを短期間で立ち上げられます。
開発コストと期間を大幅に圧縮できる一方、プラットフォームの仕様範囲内でしか構築できないため、複雑なロジックや高度なカスタマイズには限界があります。業務の標準化が進んでいる社内ツールの内製化や、まずPoCとして素早く試したい場面に適しています。
関連記事:ノーコード開発・ローコード開発・スクラッチ開発のそれぞれの特徴
各手法の比較・選び方
| 開発手法 | 向いているプロジェクト | 開発する際の注意点 |
|---|---|---|
| ウォーターフォール | 要件が固まっている・大規模・官公庁系 | 途中の仕様変更に弱い |
| アジャイル(総称) | 変化が多い・ユーザー検証を重視 | チームの習熟が必要 |
| スクラム | 中小規模・PDCAを高速で回したい | メンバーのスキル・自律性が必須 |
| スパイラル | 大規模・リスク管理を重視 | サイクル管理の工数がかかる |
| プロトタイプ/MVP | 新規サービス・要件が曖昧 | スコープ管理が難しい |
| ノーコード/ローコード | 内製化・PoC・短納期の業務ツール | カスタマイズ自由度に限界 |
開発手法の選択は、プロジェクトの性質・チームのスキル・予算・納期によって異なります。上の表を参考に、自社の状況に合った手法を選んでください。
一つの手法に縛られる必要はなく、要件定義はウォーターフォールで固めてから開発フェーズはアジャイルで進める「ハイブリッド型」も広く採用されています。どの手法が適切か判断に迷う場合は、開発会社に相談しながら決めることをおすすめします。
システム開発の事例

システム開発の事例を業界で分けると、5つあります。
- 医療・介護業
- 飲食業
- 金融業
- 物流業
- 製造業
それぞれ詳しく見ていきましょう。
医療・介護業
医療・介護業におけるシステム開発は、患者や利用者のケアの質を向上させ、業務効率の改善を目的としています。
代表的な事例は、以下のとおりです。
| 事例 | 特徴と成果 |
|---|---|
| 電子カルテシステム | 医療従事者は患者の診療情報を迅速に共有できるほか、適切な治療方針を立てられる |
| 医療画像管理システム(PACS) | X線やMRIなどの画像データを効率的に管理・閲覧できる |
| 介護記録管理システム | 利用者の日々の状態や提供されたサービスの記録や管理が可能 |
また、近年では遠隔医療システムの開発も進んでおり、過疎地域や高齢者の在宅医療に貢献しています。
関連記事:日本の医療現場でのDXの現状とは。DX推進によるメリットや立ちはだかる課題と共に読み解く
飲食業
飲食業におけるシステム開発は、店舗運営の効率化や顧客サービスの向上が目的です。
代表的な事例は、以下のとおりです。
| 事例 | 特徴と成果 |
|---|---|
| POS(販売時点情報管理)システム | 売上管理や在庫管理、顧客データ分析が一元化される |
| タブレット端末を活用したオーダーシステムの導入 | 注文ミスの減少や提供時間の短縮につながっている |
| 予約管理システムの開発 | オンライン予約の受付や顧客情報の管理が効率化される |
| デリバリー管理システム | 注文から配達までの一連のプロセスを効率的に管理できる |
| AIを活用した需要予測システム | 食材の無駄を減らしコスト削減につながる |
これらのシステム開発により、飲食業の生産性と顧客満足度の向上、新たなビジネスモデルの創出が実現されています。
金融業
金融業におけるシステム開発は、取引の安全性を確保しつつ、業務効率化や顧客サービスの向上を目指しています。
代表的な事例は、以下のとおりです。
| 事例 | 特徴と成果 |
|---|---|
| オンラインバンキングシステム | 顧客が自宅や外出先から口座管理や振込ができる |
| リスク管理システム | 金融機関は市場の変動や信用リスクをリアルタイムで分析し、適切な対応を取れる |
| AIを活用した不正取引検知システム | 不正な取引や詐欺行為を早期発見できるため、被害を未然に防げる |
また、ブロックチェーン技術を活用した決済システムや、ブロックチェーン上で自動的に実行される契約のスマートコントラクトも注目されています。
これらの技術は、安全性と透明性を兼ね備えた取引を実現できるだけでなく、新たな金融サービスの提供につなげられます。
関連記事:金融業界におけるDXの課題|IT活用法と成功事例をわかりやすく紹介
物流業
物流業におけるシステム開発は、配送効率の向上やコストの削減を目的としています。
代表的な事例は、以下のとおりです。
| 事例 | 特徴と成果 |
|---|---|
| 配送管理システム | 配送ルートの最適化やリアルタイムでの配送状況確認ができる |
| 倉庫管理システム(WMS) | 在庫状況の把握や入出荷作業を効率化できる |
| IoT技術を活用したトラッキングシステム | 貨物の位置情報や温度・湿度などの環境データをリアルタイムで取得できるため、高価値商品や生鮮食品などの品質管理が向上する |
また、自動化技術を取り入れたロボット倉庫や、ドローン配送システムも注目されています。
これらの技術を導入すれば、人手不足解消と効率化が可能です。
製造業
製造業におけるシステム開発は、生産性向上と品質管理強化を目的としています。
代表的な事例は、以下のとおりです。
| 事例 | 特徴と成果 |
|---|---|
| 生産管理システム | 生産計画から工程管理まで一元的に管理できるため、生産効率が向上する |
| 品質管理システム(QMS) | 不良品発生率の低減や製品品質向上につながる |
| IoT技術を活用したスマートファクトリー | 生産設備から収集したデータを分析して稼働状況や故障予測を行えるため、生産ライン停止による損失を防げる |
近年では、AI技術による需要予測や最適化アルゴリズムの活用も増加し、生産計画の精度が向上しています。
GeNEEは、医療業や飲食業などをはじめ多数(350件以上)の開発実績を持つシステム開発会社です。具体的な開発実績は以下のページをご覧ください。
⇒GeNEEのシステム開発実績を見る
システム開発の費用・料金相場

システム開発にかかる費用は、プロジェクトの規模やシステム種別などによって変動します。ここではシステム別の開発費用相場をご紹介します。なお、算出方法なども知りたい方は以下の記事をご参照ください。
関連記事:システム開発にかかる費用はどのくらい?内訳と算出方法も解説
システム種別の開発費用目安
システム開発の費用は、作るシステムの種類と規模によって大きく異なります。以下は小規模・中規模・大規模のチーム体制を想定した、システム種別ごとの費用目安です。
| システム種別 | 小規模システムの 開発費用目安 | 中規模システムの 開発費用目安 | 大規模システムの 開発費用目安 | 開発費用が上がる主な要因 |
|---|---|---|---|---|
| 社内ポータル/ナレッジ | 100〜300万円 | 300〜800万円 | 800〜2,000万円 | SSO・権限管理・ワークフロー連携 |
| 勤怠管理/人事管理 | 150〜300万円 | 300〜800万円 | 800〜2,500万円 | 複雑な勤務体系・給与計算連携 |
| 在庫管理・物流 | 200〜500万円 | 500〜1,500万円 | 1,500〜5,000万円 | 複数倉庫・WMS・ハンディ端末連携 |
| CMS | 100〜300万円 | 300〜800万円 | 800〜2,000万円 | カスタム投稿・多拠点・検索高度化 |
| マッチングシステム | 300〜600万円 | 600〜1,500万円 | 1,500〜4,000万円 | チャット・決済・レコメンド機能 |
| ECサイト | 150〜300万円 | 300〜800万円 | 800〜2,500万円 | 多店舗・ポイント・在庫連携 |
| 業務支援(SFA/CRM) | 150〜400万円 | 400〜1,000万円 | 1,000〜5,000万円 | 複数部署連動・基幹連携・権限管理 |
| 予約管理 | 100〜300万円 | 300〜800万円 | 800〜2,000万円 | 決済連携・多店舗・複雑な予約ロジック |
参考として、開発工程別の費用目安は以下のとおりです(エンジニア複数名体制の場合)。要件定義から運用保守まで、各工程を合計すると880万円〜が一般的な目安となります。
| 開発工程 | 開発費用相場の目安 |
|---|---|
| 要件定義 | 150万円〜(PM1名で簡易的な要件定義を想定) |
| 設計 | 200万円〜 |
| 実装(開発) | 300万円〜 |
| 試験 | 150万円〜 |
| デプロイメント | 80万円〜 |
| 合計 | 880万円〜 |
なお、リリース後の保守・運用費用は年間で開発費の15〜20%が目安です。予算計画の際は初期開発費だけでなく、運用コストも含めて試算することをおすすめします。
費用を左右する主な要因
システム開発の費用は、主に「人件費(全体の約70〜80%)」と「諸費用」で構成されます。費用が上振れる主な要因を理解しておくと、予算設計や開発会社との交渉がスムーズになります。
| 費用が上がる要因 | 内容 |
|---|---|
| 開発期間の長期化 | 仕様変更・要件定義の不備・コミュニケーション不足などで工期が延びると、人件費・設備費が増大する |
| 機能・画面数の増加 | 実装する機能や画面が増えるほど、設計・実装・テストの工数がすべて比例して増加する |
| 対応デバイスの多さ | PC・スマートフォン・タブレットなど複数デバイス対応は、UI設計・動作検証のコストを押し上げる |
| 外部システム連携 | APIや既存システムとの連携は仕様確認・実装・テストに追加工数が発生しやすい |
| 非機能要件の高さ | 高い可用性・セキュリティ・パフォーマンス要件は設計・試験の工数を大幅に増やす |
| 試験の繰り返し | 仕様変更や不具合により再試験が必要になると、試験工程のコストが膨らむ |
費用を抑えるには、①解決したい課題を事前に明確化して機能を絞る、②相見積もりで適正価格を把握する、③要件定義に十分な時間をかけて後工程の手戻りを防ぐ、の3点が特に効果的です。
見積もりで確認すべきポイント
見積書は金額の大小だけで判断するのは危険です。以下のポイントを確認することで、提示された見積りが妥当かどうかを正しく評価できます。
関連記事:システム開発の見積りとは?算出方法・内訳・チェックポイントを徹底解説
| 確認ポイント | 見るべき内容 |
|---|---|
| 工程ごとの内訳が明確か | 要件定義・設計・開発・テスト・管理が分かれているか。「一式○○万円」はどこに何の工数がかかるか分からず、後から増減の説明を受けにくい |
| 要件定義・設計の工数が十分か | 初期工程が極端に少ない場合は注意。これらが軽視されると、仕様の認識ズレ・手戻り・追加費用の原因になりやすい |
| テスト工程の範囲が明記されているか | 単体テストのみか、結合・シナリオテスト・不具合修正・再テストまで含まれるかを確認。テスト不足はリリース後のトラブルに直結する |
| PM(プロジェクト管理)費が含まれているか | 進捗管理・仕様調整・課題対応の工数が含まれていない場合、別途費用が発生するか品質低下のリスクがある |
| 対象範囲と前提条件が明記されているか | 「何を含み、何を含まないか」が不明確なまま契約すると追加費用の発生要因になる。機能・画面・連携範囲と対象外事項を確認する |
| 概算・確定のどちらの見積りか | 見積りの粒度が明示されていないと、金額が変動する可能性や再見積りのタイミングが不明確になる |
| 金額変動の条件が示されているか | 機能追加・仕様変更・外部連携の増加時の扱いを事前に確認しておくことで、後からのトラブルを防げる |
見積書の内容について「なぜこの金額か」を明確に説明してもらえるかどうかも、開発会社の信頼性を判断する重要な基準です。金額ではなく構造を見ることが、適切な開発会社選びの第一歩です。
システム開発会社に依頼するメリット

システム開発会社に依頼するメリットは、5つあります
- 専門知識や技術が不要
- 開発にかかる手間とコストを省ける
- 開発に必要な設備投資が不要
- 請負契約なら不具合が起きた時に無料で対応してもらえる
- 最新技術やノウハウを習得できる
それぞれ詳しく解説します。
専門知識や技術が不要
自社内でIT専門家を育成するには、時間と費用がかかります。しかし、システム開発会社へ依頼すれば、高度な専門知識をもつエンジニアによってプロジェクトが進められるため、本来の業務に集中できます。
また、新しい技術トレンドへの対応が容易です。AIやIoTなど最新技術への理解がなくても、それらを活用したソリューションを提供してくれるため、自社内で試行錯誤をする必要がありません。
開発にかかる手間とコストを省ける
自社で開発を行うと、要件定義から設計、製造、試験までの全工程を自前で行わなければいけません。これには、多大な時間と人的リソースが必要です。また雇用していたエンジニアが退職するときなど、大きな波乱を生むことになるでしょうか。
システム開発会社に開発を依頼すれば、効率的な開発プロセスとノウハウにより、開発期間を短縮し、本業に集中することができます。また、開発に必要な端末や検証ツール、ライセンスの購入が不要なため、効率的にプロジェクトを開始することができます。
開発に必要な設備投資が不要
自社でシステム開発を行うと、ハイスペックなコンピューターや開発用ソフトウェア、試験環境など、多くの設備が必要です。これらの初期投資は、中小企業にとっては負担となる可能性があります。
しかし、システム開発会社に依頼すれば、すべての設備が用意されます。クラウド環境やセキュリティ対策など、最新の技術インフラも利用可能です。
さらに、設備の維持管理やアップグレードの手間も省けるため、長期的なコストの削減にもつながります。
最新技術やノウハウを習得できる
システム開発会社は最新のIT動向をキャッチアップし、さまざまなプロジェクトを通じて経験を蓄積しています。そのため、依頼をすれば最新テクノロジーや効率的な開発手法、業界のベストプラクティスなどを学べる可能性があります。
たとえば、AIやブロックチェーンなどの先端技術を自社のシステムに取り入れる際、その活用方法や導入のポイントを理解できるでしょう。
また、プロジェクト管理手法やユーザー体験設計など、さまざまなスキルを吸収できます。
システム開発会社に依頼するデメリット

システム開発会社に依頼するデメリットは、5つあります。
- コストが高くなる
- 情報漏洩のリスクがある
- 開発会社が自社の事業を把握できるとは限らない
- 開発ノウハウが蓄積されない
- 開発会社とのコミュニケーションや管理が必要
それぞれ詳しく解説します。
コストが高くなる
システム開発会社は専門知識と技術を持つ人材を抱えているため、相応の人件費や間接費用が反映されます。また、プロジェクト管理や品質管理のためのコストも含まれるため、全体的な費用が増加しやすい傾向です。
小規模なシステムや単純な機能を開発する場合は、自社で行うよりも外部委託のほうがコストが割高になる可能性があります。
情報漏洩のリスクがある
システム開発を依頼すると、自社の機密情報や顧客データなどの重要な情報を開発会社と共有しなければいけません。そのため、意図的または偶発的に情報が外部に漏れるおそれがあります。
とくに、顧客の個人情報や企業の戦略的情報が含まれる場合は、漏洩リスクに対して細心の注意を払わなければいけません。また、開発会社が複数の競合企業と取引している場合は、情報の取り扱いに関する懸念が生じるでしょう。
開発会社が自社事業を把握できるとは限らない
システム開発会社は多くの企業と取引しているため、各クライアントの事業特性やニーズの理解に時間がかかる場合があります。理解不足は、開発されるシステムが実際の業務フローと合致しない、重要な機能が欠落するなどの問題につながりかねません。
また、業界特有の規制や慣習に対する把握が不十分だと、コンプライアンス上の問題が生じるおそれがあります。
開発ノウハウが蓄積されない
自社でシステム開発を行うと、プロジェクトを通じて社員がスキルを向上させ、技術的な知識や経験を蓄積していきます。しかし、外部委託ではこれらの機会が失われる可能性があります。
また、システムの運用や保守に関する理解が欠如していると、トラブルが起こったときに適切な対応ができません。
開発会社とのコミュニケーションや管理が必要
システム開発では、要件定義から納品の各段階で綿密な打ち合わせや進捗確認が必要です。自社の要望や変更点を適切に伝え、開発会社の提案を評価する能力も求められます。
このプロセスは、大規模なプロジェクトや複雑なシステムの開発において顕著です。
さらに、開発会社との契約管理、予算管理、スケジュール管理なども欠かせません。
システム開発の外注・依頼の流れ

システム開発を外注する場合の依頼の流れと、各工程でやることを示したのが以下の図となります。

ここでは、各工程の詳細を解説していきます。
①開発要件・目的の整理
最初のステップは、「何のためにシステムを作るのか」を社内で明確にすることです。この段階での整理が不十分だと、開発会社への要件伝達がブレ、後工程でのやり直しや追加費用の原因になります。
以下の4項目を事前に整理しておくと、開発会社との最初の打ち合わせがスムーズになり、見積もりの精度も上がります。
| 整理すべき項目 | 具体的に考えておくこと |
|---|---|
| 解決したい課題 | 現状どの業務が非効率か、どこにコストや時間がかかっているか |
| 欲しい機能の概要 | 必須機能と「あれば嬉しい」機能を分けてリストアップする |
| 利用ユーザーと規模 | 社内用か社外向けか、想定ユーザー数、アクセス頻度 |
| 予算と納期の目安 | 予算の上限、いつまでにリリースしたいか(絶対条件か目安か) |
この段階では完璧な仕様書は不要です。ただし「課題」と「予算感」だけは必ず固めておきましょう。課題が曖昧なまま進めると、不要な機能が積み上がって費用が膨らむ「スコープクリープ」が起きやすくなります。
②開発会社の選定・相見積もり
整理した要件をもとに、複数の開発会社へ問い合わせて相見積もりを取ります。最低3社、できれば5社程度に同じ条件で依頼することで、相場感の把握と各社の提案力を比較できます。
選定時に確認すべき主なポイントは以下のとおりです。
| 確認ポイント | 見るべき内容 |
|---|---|
| 自社開発体制の有無 | 外注比率が高い会社はコミュニケーションロスや品質低下のリスクがある。自社エンジニアが主体かを確認する |
| 類似案件の実績 | 同業種・同規模のシステム開発経験があるか。事例をヒアリングし、課題解決の具体性を確かめる |
| 見積りの内訳の明確さ | 「一式○○万円」ではなく工程別に内訳が示されているか。内訳が不明な見積りは後から追加費用が発生しやすい |
| コミュニケーションの取りやすさ | 初回の打ち合わせでの対応スピード・説明のわかりやすさ・質問への回答の明確さを確認する |
| セキュリティ対応 | ISMS・Pマーク取得の有無、守秘義務契約(NDA)の締結が可能かを確認する |
注意点として、見積もり金額の安さだけで選ぶのは危険です。要件定義・テスト・プロジェクト管理の工数が削られた「安い見積もり」は、後から追加費用が発生して結果的に高くつくケースが少なくありません。
③契約・要件定義のすり合わせ
開発会社を選定したら、契約と要件定義のすり合わせを行います。この工程がシステム開発全体の品質を左右する最も重要なフェーズです。要件定義の精度が低いと、後の設計・開発・テストすべてに悪影響が及びます。
まず契約形態を確認します。主に「請負契約」と「準委任契約」の2種類があり、それぞれ特徴が異なります。
| 契約形態 | 特徴 | 向いているケース |
|---|---|---|
| 請負契約 | 成果物の完成を約束する契約。不具合があれば無償修正の義務がある。費用は原則固定 | 要件が明確で変更が少ない案件。品質保証を重視したい場合 |
| 準委任契約 | 作業の遂行を約束する契約。工数に応じて費用が発生する。仕様変更に柔軟に対応できる | 要件が変化しやすい案件。アジャイル・スクラム開発との親和性が高い |
要件定義のすり合わせでは、「機能要件(何ができるか)」と「非機能要件(どれくらいの速度・安全性・可用性が必要か)」の両方を明確にします。この段階で認識ズレをなくすことが、手戻りゼロへの近道です。開発会社が提示する要件定義書・画面設計書の内容を丁寧に確認し、疑問点は必ず解消してから次工程に進みましょう。
④開発・テスト・納品
要件定義が完了したら、設計→製造(プログラミング)→テストの各工程が進みます。発注者はこの期間も定例会議や進捗確認を通じて、開発の状況を把握し続けることが重要です。
発注者側が各工程で行うべき主なアクションは以下のとおりです。
| 開発工程 | 開発会社の作業 | 発注者側の主なアクション |
|---|---|---|
| 設計 | 基本設計・詳細設計・DB設計 | 画面設計・仕様書の内容確認。認識ズレがあれば早期に修正依頼 |
| 製造 | フロントエンド・バックエンド実装 | 中間デモがあれば参加し、動作イメージを早期に確認する |
| テスト | 単体・結合・総合・受入試験 | 受入試験(UAT)では実際の業務フローで動作を確認。不具合を報告する |
| 納品・リリース | データ移行・本番環境構築 | 操作マニュアルの確認、利用者への周知・研修の実施 |
開発期間中に仕様変更が発生した場合は、必ず「変更管理」を通じて書面で合意を取ることが重要です。口頭での変更依頼は認識ズレや追加費用トラブルの原因になります。変更の都度、工数・費用・納期への影響を確認してから承認しましょう。
⑤運用保守・改善フェーズ
リリース後は「運用・保守」フェーズに移行します。システムは作って終わりではなく、安定稼働の維持・不具合対応・機能改善を継続していくことで、投資対効果を最大化できます。
| 運用・保守項目 | 内容 |
|---|---|
| 運用 | システムの監視、バックアップ管理、セキュリティアップデート、ユーザーサポート対応 |
| 保守 | 不具合(バグ)の原因調査と修正、法改正・外部サービス変更への対応 |
| 改善・追加開発 | ユーザーのフィードバックをもとにした機能追加・UI改善・パフォーマンス最適化 |
保守・運用費用の目安は年間で開発費の15〜20%です(例:500万円で開発したシステムなら年間75〜100万円程度)。開発会社との保守契約には「定額制(月額固定)」と「従量課金制(対応した工数に応じて支払い)」があり、システムの安定性や改修頻度に応じて選ぶとよいでしょう。
また、リリース直後は想定外のトラブルや問い合わせが集中しやすい時期です。社内のシステム担当者を事前に決めておき、開発会社の窓口と連携できる体制を整えておくことを推奨します。
システム開発会社の選び方・比較ポイント

システム開発会社を選ぶ際のポイントは、5つあります。
- 自社の開発ニーズ・予算との照合
- 開発実績・得意領域の確認
- 開発体制・プロジェクト管理力
- セキュリティ対応(ISMS・Pマーク)
- サポート・保守体制
それぞれ詳しく見ていきましょう。
自社の開発ニーズ・予算との照合
まず「自社が何を解決したいのか」「どの程度の予算と期間を想定しているか」を事前に明確にしたうえで、それに合った開発会社を探すことが重要です。ニーズや予算感を整理せずに問い合わせると、提案がズレたり、不要な機能を含む高額な見積もりが出やすくなります。
照合すべき主なポイントは以下のとおりです。
| 確認ポイント | 具体的に見るべき内容 |
|---|---|
| 開発の目的・課題感との一致 | 自社の課題(業務効率化・コスト削減・売上拡大など)を理解し、解決策を提案できる会社かどうか |
| 得意とする開発領域 | 業務システム・Webアプリ・スマホアプリなど、自社が必要とするシステム種別の開発実績があるか |
| 予算規模との適合性 | 想定予算に対して現実的な提案ができるか。予算を大きく超える見積もりしか出せない会社は選定から外す |
| 納期への対応力 | 希望するリリース時期に対して、適切なチーム体制と開発期間を確保できるか |
| 小規模・大規模への対応幅 | 自社の開発規模(数百万〜数千万円)に対応した実績と体制があるか |
予算感については、まず自社で上限の目安を持ったうえで開発会社に伝えることが、適切な提案を引き出すコツです。「いくらかかるか教えてほしい」だけでは、要件のすり合わせ前に正確な見積もりを出すことは難しく、概算値の幅が大きくなります。
開発実績・得意領域の確認
プロジェクトの成功例や類似業界での開発経験は、システム開発会社の能力と信頼性を示す指標です。検討する際は、以下に注目しましょう。
- 開発したシステムの規模や複雑さ
- 導入企業の業種
- プロジェクトの期間や予算管理の状況
- クライアントからの評価や満足度
- 業界内での評判や受賞歴
実際に開発されたシステムの話のヒアリングをするのも非常に有効な手です。ただし、実績だけでなく、現在の技術力や開発体制も併せて評価しましょう。
開発体制・プロジェクト管理力
プロジェクトの成功と品質の確保をするには、信頼できるシステム開発会社を選ばなければいけません。以下の項目に注目し、開発会社の開発体制が万全かどうか確認しましょう。
- プロジェクトマネージャーの経験や能力
- 開発チームの規模と技術力
- 品質管理プロセスの有無
- 緊急時の対応体制
- 開発後のサポート体制
さらに、アジャイル開発やDevOpsなど、最新の開発手法に対応できる体制があるかどうかも確認するべきです。
セキュリティ対応(ISMS・Pマーク)
開発プロセスでは機密情報や個人情報を扱うシーンが多いため、高度なセキュリティ対策が欠かせません。したがって、情報セキュリティマネジメントシステム(ISMS)の認証取得状況や、プライバシーマークの取得の有無を確認しましょう。
また、以下の項目にも注目するべきです。
- データの暗号化
- アクセス制御
- ネットワークセキュリティ
- セキュリティインシデントへの対応体制
- 従業員への教育プログラムの有無
セキュリティマネジメントの質はデータ保護だけでなく、システム全体の信頼性や安定性にも影響するため、慎重に評価する必要があります。
サポート・保守体制
システムはリリースして終わりではなく、その後の運用・保守が品質と稼働率を左右します。開発会社を選ぶ際には、納品後のサポート体制についても必ず確認しておきましょう。
| 確認ポイント | 具体的に見るべき内容 |
|---|---|
| サポート対応時間・方法 | 平日日中のみか、夜間・休日対応も可能か。電話・メール・チケット管理などの対応手段を確認する |
| 障害発生時の対応速度 | 重大障害の場合、何時間以内に一次対応するかのSLA(サービスレベル合意)が明示されているか |
| 定期メンテナンスの内容 | セキュリティアップデート、OSやミドルウェアのバージョンアップ対応が保守契約に含まれているか |
| 改善・追加開発への対応 | 運用開始後の機能追加や仕様変更にどう対応するか。スポット対応か月額契約かを確認する |
| 担当者の継続性 | リリース後も開発を担当したエンジニアがサポートに関与するか。担当者が変わると引き継ぎコストが発生する |
保守契約には「定額制(月額固定)」と「従量課金制(対応工数に応じて請求)」があります。改修頻度が高い場合は定額制、安定稼働が見込まれる場合は従量課金制が費用対効果の面で有利になるケースが多いです。契約前に保守範囲と費用の目安を書面で確認しておくことを推奨します。
関連記事:【2026年版】システム開発会社おすすめ23社と費用相場を解説
システム開発の最新トレンド

ここではシステム開発のトレンドについてご紹介します。
AI・生成AIの活用(コード生成・テスト自動化)
GitHub CopilotやCursor、ChatGPTなどのAI・生成AIツールが開発現場に急速に普及しています。コード生成・補完、テストコードの自動作成、バグ修正の提案、ドキュメント生成など、開発工程の幅広い場面で活用が進んでいます。
| 活用領域 | 具体的な内容 | 発注者への影響 |
|---|---|---|
| コード生成・補完 | AIがコードの雛形や続きを自動補完し、実装工数を削減 | 開発スピードが向上し、納期短縮や費用削減につながるケースがある |
| テスト自動化 | テストコードの自動生成や網羅的なテストケース作成をAIが支援 | 品質向上と試験工程の効率化が期待できる |
| コードレビュー支援 | AIがバグや脆弱性のリスクをリアルタイムに指摘 | ヒューマンエラーの早期発見につながり、手戻りを減らせる |
| 仕様書・設計書の生成 | 要件定義の内容からドキュメントを自動生成 | 上流工程のコスト削減と一貫性のある文書管理が可能になる |
ただし、AIが生成したコードは必ずエンジニアによるレビューが必要です。AIは文脈の読み違えや仕様外のコードを出力することがあり、品質管理のプロセスを省くことはできません。開発会社を選ぶ際は、AI活用ツールの導入状況だけでなく、AIと人間の役割分担がどのように設計されているかを確認することが重要です。
関連記事:生成AI導入の成功事例:企業が得た具体的なメリットとは?
クラウドネイティブ・マイクロサービス化
クラウドネイティブとは、AWS・Google Cloud・Azure などのクラウド環境を前提に設計・開発されたシステムの考え方です。従来のオンプレミス(自社サーバー)からの移行が進むとともに、大きなシステムを機能単位の小さなサービスに分割して開発・運用する「マイクロサービスアーキテクチャ」も広く採用されるようになっています。
| アプローチ | 特徴 | 発注者へのメリット |
|---|---|---|
| クラウドネイティブ設計 | インフラをコードで管理(IaC)し、自動スケーリングや高可用性を実現 | 初期のサーバー投資が不要。需要に応じてコストを柔軟に調整できる |
| マイクロサービス化 | システムを独立した機能単位(サービス)に分割して開発・デプロイ | 一部機能だけを素早く改修・追加でき、システム全体を止めずに更新できる |
| コンテナ技術(Docker/Kubernetes) | アプリの実行環境をコンテナ化し、どの環境でも同じ動作を保証 | 開発・検証・本番の環境差異によるトラブルを防げる |
一方で、マイクロサービスはシステム構成が複雑になるため、小規模なシステムや開発体制が整っていない場合には管理コストが増大するリスクもあります。モノリシック(一枚岩)設計が向いているケースもあるため、開発会社と要件・運用体制を踏まえたアーキテクチャ選定を行うことが重要です。
DevSecOps(セキュリティの内製化)
DevSecOpsとは、開発(Dev)・セキュリティ(Sec)・運用(Ops)を一体化したアプローチです。従来はリリース前のセキュリティ検査を別部署が担当するケースが多かったのに対し、DevSecOpsでは開発の各工程にセキュリティチェックを組み込み、脆弱性を早期に発見・修正する体制を実現します。
| 取り組み | 内容 |
|---|---|
| SAST(静的解析) | コードを実行せずにソースコードの脆弱性を自動検出。開発中にリアルタイムでセキュリティリスクを把握できる |
| DAST(動的解析) | 動作するアプリに対して疑似的な攻撃を行い、外部から見えるセキュリティ上の問題を検出する |
| 依存ライブラリの自動監視 | 使用しているOSSやライブラリに既知の脆弱性が報告された場合、自動で検知してアップデートを促す |
| CI/CDパイプラインへのセキュリティ統合 | ビルド・テスト・デプロイの自動化フローにセキュリティ検査を組み込み、問題があればリリースをブロックする |
個人情報保護法の改正やサイバー攻撃の高度化を背景に、セキュリティ対応の重要性はますます高まっています。開発会社を選ぶ際は、ISMS・Pマークの取得状況に加え、開発プロセスにDevSecOpsの考え方が取り入れられているかどうかも確認するとよいでしょう。セキュリティを後付けで対応するよりも、設計段階から組み込む方がコストと品質の両面で有利です。
まとめ

この記事では、システム開発の基礎知識から外注・依頼の流れ、費用相場、開発会社の選び方、最新トレンドまでを解説しました。
「どんなシステムが必要か整理できていない」「費用感を把握してから検討したい」という段階でも、ぜひお気軽にご相談ください。GeNEEでは要件整理の段階からご支援が可能です。350件以上の開発実績をもとに、貴社の課題に合った最適なシステム開発のご提案をいたします。

-
GeNEEの開発実績製造業、小売業、流通業、印刷・出版業など、業界別のベストプラクティスを保持しています。
弊社の開発実績にご関心のある方はこちら一部公開可能な事例を掲載中
-
GeNEEの事業内容
現在、6事業を展開しております。お客様の状況や目標に合わせて、FITするソリューションを提供いたします
6事業の詳細はこちら
-
弊社主催セミナー
最大月に1回のセミナーを開催しております。毎回30名以上の方にご出席いただいております。
テック系のセミナーにご興味ある方はこちら月に1回テック系セミナー開催中
-
オウンドメディア
GeNEE は技術に関する情報発信を積極的に行っています。 弊社のお客様だけでなく、業界全体に貢献のできる品質の高い情報提供を心掛けています。
最先端テクノロジーの情報配信中
-
GeNEEの会社概要
ビジネスxテクノロジーxデザインの三位一体で、お客様の課題を解決する独自のアプローチをご紹介
創業から15年の実績
-
GeNEEの5つの特徴
なぜGeNEEはコンサルティングやシステム開発のプロジェクト成功率が高いのか。
競合他社との違いや優位性についてまとめております。GeNEEの5つの特徴
-
GeNEEへのお問い合わせ
DX/ITコンサルティングのご依頼やシステム開発・スマホアプリ開発のご相談はこちらのフォームからお願いいたします
お問い合わせフォームはこちら
-
GeNEEの資料をダウンロード
ご希望の会社様にGeNEEのパンフレットをお送りしております。
ITベンダーとの繋がりをお探しの方は是非お気軽にリクエストください。資料ダウンロードはこちら
取締役
<略歴>
大阪大学工学部、大阪大学大学院情報科学研究科修了。
国内最大手IT企業の株式会社NTTデータで大手金融機関向けに債権書類電子化システム、金融規制・法規制対応システムの要件定義・インフラ設計・開発・構築・複数金融サービスのAPI連携等を手がける。その後、株式会社GeNEEの取締役に就任。
<資格>
基本情報技術者試験、応用情報技術者試験、Oracle Master Platinum等多数
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>