【システム開発とは？】工程・手法だけでは成功しない—“品質×運用×社会価値”でDXをやり切る実践ガイド
Be A Racer Team
Author
「システム開発って、結局は何から手を付ければいいのだろう？」——御社のDX推進や基幹刷新、業務効率化の場面で、こんな問いが頭をよぎったことはありませんか。
現場は忙しい。予算は限られる。しかも、要件が揃ったと思った瞬間から、事業環境は変わっていく——。それでも、システムは“作って終わり”ではなく、稼働して価値を出し続けて初めて成功です。
本記事では、参考記事で整理されていた「工程」「手法」「依頼のポイント」を土台にしつつ、オリジナル視点として品質保証（第三者検証）・運用設計・社会価値（CSR）まで含めた“やり切るための設計図”として再構成します。読む価値は明確です。炎上を避け、現場に使われ、監査・セキュリティにも耐え、事業KPIに効く——そのための実務を、ケースと実装例で具体化します。
「ソフトウェアは“リリース”がゴールではなく、“信頼”がゴールである」
— 品質保証の現場でよく語られる言葉（筆者意訳）
✅この記事で得られること
- システム開発の全体像（工程・役割・成果物）を、発注側目線で整理
- ウォーターフォール／アジャイル等の選び方を、失敗パターン込みで理解
- RFP・見積・契約・品質・運用・セキュリティまで“抜け漏れ”を潰す
1. システム開発の定義を「価値が出る仕組み」まで拡張する
システム開発＝ソフトを作る、だけではない
参考記事でも触れられている通り、システム開発は要件定義〜設計〜実装〜テスト〜運用までの一連の活動です。ただ、経営・DXの文脈では、“業務が変わり、数字が変わる”ところまでが開発の責任範囲になります。たとえば勤怠管理の刷新でも、単に打刻画面を作るのではなく、締め処理の工数削減、未打刻率低下、監査対応の短縮など、KPIに落とし込む必要があります。
「システム開発」と「システム構築」の違いが、炎上の芽を生む
参考記事4の通り、開発は“作る”、構築は“組み合わせる”が基本です。しかし現場では混同されがちで、ここが認識ズレの温床になります。例：SaaS導入を「開発」と呼んでしまい、後から「カスタム開発が必要」と判明して追加費用が膨らむ。⚠️注意：言葉ではなく“成果物と作業範囲”で合意しましょう。
企業事例：Salesforce導入で“構築”のはずが“開発”になったケース
多くの企業がCRMにSalesforceを採用しますが、業務が複雑な場合はApex開発や外部基幹連携が必要になります。実際に、国内のSIプロジェクトでも「標準機能でいける」という前提が崩れ、結合テスト段階で連携仕様が未確定のまま炎上する例は珍しくありません。成功企業は、最初に“To-Be業務”と連携境界（API/バッチ/手作業）を決め、構築と開発を分けて見積します。
✅アクションアイテム：御社の案件で「開発／構築／導入支援」を、作業範囲（WBS）と成果物（設計書・設定一覧・テスト仕様）で言語化してください。次章では、その全体像を工程として分解します。
2. 工程を知るだけでなく「戻りが発生する前提」で設計する（V字モデルの現実）
一般的な工程：要件定義→設計→実装→テスト→リリース→運用
参考記事3・5が整理する通り、典型は要件定義、基本設計、詳細設計、実装、テスト、リリース、保守運用です。重要なのは、工程名を覚えることではなく、各工程で“何を確定させ、何を検証するか”です。要件定義で確定すべきは機能一覧だけではなく、SLA、運用体制、データ移行方針、監査ログ要件なども含まれます。
V字モデルは「テストが設計を照らす」ための地図
V字モデルは、左（設計）と右（テスト）が対応関係にあることを示します。たとえば基本設計に対してシステムテスト、詳細設計に対して結合テスト、実装に対して単体テストが対応します。✅チェックポイント：テスト仕様が作れない設計は、設計として未完成です。SHIFTのような第三者検証が重視される背景には、「作った側は見落とす」現実があります。
企業事例：Microsoftの調査が示す“後工程での修正コスト”の重さ
古典的ですが実務では今も有効な示唆として、欠陥修正コストは後工程ほど増大すると言われます（要件段階より運用段階の方が桁違いに高い）。だからこそ、上流での合意・レビュー、そしてテスト設計の早期化が効きます。特に基幹系では、運用後の障害は売上や出荷に直結し、機会損失が“開発費”を超えることもあります。
✅アクションアイテム：要件定義のレビューで「テスト観点（受入条件）」を同時に作ってください。次章では、手法選定（ウォーターフォール／アジャイル等）を“現実の制約”で比較します。
3. 開発手法の選び方：ウォーターフォール vs アジャイルを「制約条件」で決める
メリット・デメリットは“組織の成熟度”で反転する
参考記事3が示す通り、ウォーターフォールは計画重視、アジャイルは反復で価値を積む手法です。ただし、どちらが優れているかではなく、御社の制約（監査、契約、現場協力度、プロダクトオーナー不在など）で最適解が変わります。⚠️注意：アジャイルは“早い”のではなく、“学習が早い”。意思決定が遅い組織では逆に遅くなります。
比較表：手法選定を誤ると何が起きるか
| 観点 | ウォーターフォール | アジャイル（Scrum等） | アンチパターン |
|---|---|---|---|
| 要件の変動 | 変動が少ない前提で強い | 変動を前提に吸収 | 要件未確定でWF開始→後半で大崩壊 |
| 契約・予算 | 固定範囲・固定価格と相性が良い | 準委任・T&Mと相性が良い | 固定価格でアジャイル→変更管理が地獄 |
| 品質保証 | テスト工程を厚く計画しやすい | 自動テスト/CIがあるほど強い | 手動テスト頼みのアジャイル→速度も品質も落ちる |
| 意思決定 | 承認プロセスが重くても回る | POの即決が必要 | PO不在でスクラムイベントだけ実施→形骸化 |
企業事例：Spotifyは“スクワッド”でスピードと自律性を両立
Spotifyモデルはしばしば誤解されますが、重要なのは組織設計と開発文化（自動化・権限委譲）がセットである点です。単にスクラムを導入しても、承認待ちが長ければリードタイムは縮まりません。日本企業で成功している例では、小さく始める（MVP）→学習→横展開の順で、現場の納得を積むアプローチが多いです。
✅アクションアイテム：手法を決める前に「要件変動の見込み」「意思決定者の配置」「自動テスト/CIの有無」を棚卸ししてください。次章では、発注・依頼を成功させるRFPと見積の勘所に進みます。
4. 依頼（発注）で8割決まる：RFP・見積・契約で“事故を減らす”
RFP（提案依頼書）は“仕様書”ではなく“意思決定の道具”
参考記事4でも触れられるRFPは、見積精度と提案品質を左右します。ここでのコツは、機能要件を細かく書きすぎるより、業務課題・制約・優先順位・受入条件を明確にすること。たとえば「月次締めを3日→1日に短縮」「監査ログを7年保存」「ピーク時同時アクセス500」など、測れる条件があると、提案の比較が可能になります。
見積の“妥当性”は金額ではなく前提条件で判断する
参考記事3が示す通り、開発費の大半は人件費です。重要なのは、見積書に「何が含まれ、何が含まれないか」が明記されているか。特に抜けやすいのが、データ移行、運用設計、教育、性能試験、脆弱性診断です。⚠️注意：安い見積ほど“前提”が多く、後から追加請求になりやすい。複数社比較では、金額より前提の差分をレビューしましょう。
企業事例：Amazon流の“Working Backwards”をRFPに応用する
Amazonの有名な手法「Working Backwards」は、まずプレスリリース（顧客価値）から書く考え方です。これをRFPに応用し、「完成したら誰が何をどれだけ早くできるか」を冒頭に置くと、SIerの提案が“機能羅列”から“価値設計”に変わります。結果として、無駄機能が減り、スコープが締まり、総コストが10〜20%下がることも現実に起こります（筆者の支援案件の傾向）。
✅アクションアイテム：RFPに「目的KPI」「受入条件」「非機能（性能・可用性・セキュリティ）」の3点セットを必ず入れてください。次章では、その非機能の中核である“品質保証”を掘り下げます。
5. 品質保証（QA）を“最後の門番”にしない：SHIFTに学ぶ第三者検証の効き方
QAはコストではなく“損失回避と信頼の投資”
参考記事1が強調するように、第三者検証は品質を高め、ビジネス成功にまでつなげる打ち手です。障害が起きれば、復旧工数だけでなく、顧客離反、問い合わせ増、ブランド毀損が連鎖します。特にBtoBでは、1回の重大障害で更新率が落ち、LTVが毀損します。✅チェックポイント：品質KPI（欠陥密度、テストカバレッジ、MTTR）を経営指標に接続しましょう。
実装例：CIで自動テストと静的解析を回し、品質を“仕組み化”する
アジャイルでもウォーターフォールでも、品質を人海戦術だけに頼ると限界が来ます。以下はGitHub ActionsでPythonのテストとLintを実行する最小例です。小さな自動化が、後工程の手戻りを着実に減らします。
name: ci
on:
pull_request:
push:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.12'
- run: pip install -r requirements.txt
- run: pip install pytest ruff
- run: ruff check .
- run: pytest -q
アンチパターン：テスト工程を“最後に詰め込む”と必ず破綻する
「開発が遅れたからテストで巻き返す」は、現場ではよくある判断です。しかしテストは“品質を作る”工程ではなく、“品質を測る”工程。欠陥が大量に見つかれば、修正→再テストで雪だるま式に遅れます。成功している企業は、設計レビュー、テスト設計の前倒し、そして第三者視点の導入で、欠陥の流入を抑えています。
✅アクションアイテム：次回プロジェクトから「テスト仕様は基本設計と同時に作る」「CIで最低限の自動テストを回す」をセットで導入してください。次章では、リリース後に価値を出し続ける“運用設計”に進みます。
6. 運用・保守までがプロダクト：SRE/DevOpsで“止まらない仕組み”を作る
運用設計が弱いと、現場は静かに離れていく
運用・保守は「障害対応」だけではありません。問い合わせ導線、権限管理、マスタ更新、監査ログ、データ訂正手順など、日々の業務に直結します。ここが弱いと、現場はExcelに戻り、投資対効果が消えます。⚠️注意：運用は“後で考える”ほど高くつく。要件定義段階で運用フロー（誰が、いつ、何を）を合意しましょう。
実装例：可観測性（Observability）をログで担保する
障害対応のスピード（MTTR）を下げるには、ログとメトリクスが必要です。たとえばNode.jsなら、リクエストIDを付与してログを構造化するだけでも、原因追跡が劇的に早くなります。
// Express middleware example (Node.js)
import { randomUUID } from "crypto";
export function requestId(req, res, next) {
const rid = req.headers["x-request-id"] ?? randomUUID();
req.requestId = rid;
res.setHeader("x-request-id", rid);
next();
}
// log example
console.log(JSON.stringify({ level: "info", msg: "order_created", requestId: req.requestId, orderId }));
企業事例：Googleが提唱したSREの考え方が“運用の属人化”を崩す
GoogleのSRE（Site Reliability Engineering）は、信頼性をエンジニアリングで担保する思想です。日本企業でも、オンコール体制、障害のポストモーテム（責めない振り返り）、SLO（サービス目標）を導入することで、障害が減るだけでなく、開発チームの心理的安全性が上がり、改善が回り出すケースが増えています。
✅アクションアイテム：要件定義に「SLO（例：稼働率99.9%、復旧目標60分）」「運用RACI」「監視・アラート設計」を入れてください。次章では、見落とすと致命傷になりやすい“セキュリティとガバナンス”を扱います。
7. セキュリティとガバナンス：開発会社選定の“必須条件”にする
機密情報を扱う以上、セキュリティは要件である
参考記事3でも「セキュリティマネジメントがしっかりしていること」が強調されています。個人情報・顧客情報・財務情報を扱うなら、セキュリティは“努力目標”ではなく、契約と設計に落とすべき要件です。ISMS（ISO/IEC 27001）やSOC2の有無だけでなく、アクセス権限、鍵管理、脆弱性対応のSLA、ログ保全など、運用まで含めて確認しましょう。
実装例：最小権限と秘密情報管理（Secrets）
クラウド利用が一般化した今、事故の多くは「設定ミス」や「秘密情報の漏えい」です。たとえばAWSならIAMの最小権限、Secrets Managerの利用、S3の公開設定の禁止などが基本です。CI/CDでも、APIキーをリポジトリに置かない運用が必須です。
# Anti-pattern (NG): committing secrets
API_KEY=xxxxxxxx
# Better: use environment variables + secret store
export API_KEY="$API_KEY"
企業事例：大手金融が“ゼロトラスト”を進める理由
金融・保険業界では、内部不正やサプライチェーンリスクを前提に、ゼロトラスト（何も信頼せず検証する）を進めています。これは大企業だけの話ではありません。取引先からセキュリティチェックシートが来たとき、答えられないと受注機会を失うこともあります。✅チェックポイント：セキュリティはコストではなく売上機会の条件です。
✅アクションアイテム：開発会社選定のRFPに「脆弱性診断の範囲」「インシデント時の連絡体制」「ログ保管期間」を必ず含めてください。次章では、地域・社会への価値（CSR）を“開発の成果”として捉える視点を紹介します。
8. “社会価値”まで設計する：CSRと採用力がシステム開発の持続性を決める
地域・顧客・従業員に価値を返す開発は、結果的に強い
参考記事2の株式会社システム開発（宮崎）のメッセージは示唆的です。ITを通じて地域社会に貢献し、ステークホルダーの信頼を獲得していく——これは単なる理念ではありません。人材不足が深刻化する中、開発を継続する力＝採用・育成・定着です。社会価値のあるプロジェクトは、エンジニアの誇りになり、結果として品質と継続改善を支えます。
企業事例：自治体DX・医療DXは“運用”と“信頼”が成否を分ける
自治体向け、医療向けは、止められない・間違えられない領域です。歯科医院向けサービスなども含め、現場のITリテラシー差が大きく、サポート設計が品質そのものになります。成功している企業は、導入後の問い合わせ削減（例：チュートリアル整備で問い合わせ30%減）や、教育コンテンツの内製化で運用コストを下げています。
アンチパターン：短期の納期だけを追い、人が疲弊する
無理な納期で燃え尽きると、知見が残らず、次の改善が止まります。結果として、障害が増え、顧客満足が下がり、さらに現場が疲弊する悪循環に入ります。✅チェックポイント：持続可能性（Sustainable Delivery）をKPIに入れる。たとえば残業時間、属人化指数、ドキュメント充足率などを測ると、開発の“体力”が見える化できます。
✅アクションアイテム：プロジェクトの目的に「現場定着」「教育」「運用の省力化」を入れてください。次章では、ここまでの要点をチェックリストに落とし、Next Stepを提示します。
まとめ：成功するシステム開発は「工程」ではなく「信頼の連鎖」でできている
重要ポイントの再掲（ここだけ押さえてください）
✅システム開発は“作る”ではなく“価値が出続ける仕組み”を作ること
✅手法選定は流行ではなく、制約（意思決定・契約・自動化）で決める
✅品質保証は最後に足すのではなく、設計と同時に組み込む
✅運用・セキュリティ・CSRまで含めて、投資対効果が完成する
実践チェックリスト（5〜7項目）
- ✅目的KPI（時間短縮/売上/ミス削減）と受入条件が合意されている
- ✅「開発」と「構築」の範囲がWBSと成果物で明確になっている
- ✅V字の対応（設計⇔テスト）が取れており、テスト仕様が前倒しである
- ✅見積の前提（移行/教育/性能/診断/運用）が明記され比較できる
- ✅CI等で最低限の自動テスト・静的解析が回っている
- ✅運用RACI、監視、SLO、障害時の連絡体制が決まっている
- ✅セキュリティ要件（権限/ログ/診断/インシデント対応）が契約に入っている
Next Step（明日からできる一歩）
- 御社のプロジェクト目的を「業務KPI」と「受入条件」に書き換える
- RFPに「非機能（性能・可用性・セキュリティ）」を追記する
- 見積比較では金額ではなく“前提条件の差分表”を作る
- CIで自動テストを1本でも良いので回し始める
- 運用フロー（問い合わせ、権限、マスタ更新、障害対応）を図にする
システム開発は、御社の未来を背負う大きな投資です。だからこそ、工程や手法の知識に加え、品質・運用・セキュリティ・社会価値まで含めた“信頼の連鎖”を設計して、やり切りましょう。
Tags
コメント
🗣️ コメントするにはログインしてください
Sign in to leave a comment and join the discussion