---
title: 【非機能要件のリアル】「サクサク動いて、絶対に止まらないシステム」が引き起こす悲劇。エンジニアが語る5つの着地点
description: "システム開発の発注において、「非機能要件」は、しばしば抽象的な言葉で語られがちです。\ndeeptierエンジニアに、「システム発注者の安易な要望が引き起こす技術的リスクと、その正しい着地点」について、解説してもらいました。"
image: https://deeptier.co.jp/hubfs/11.png
---

[![deeptier](https://deeptier.co.jp/hubfs/raw_assets/public/deeptier-theme/images/logo_brand_white.svg)](https://deeptier.co.jp/)

- [システム受託開発](https://deeptier.co.jp/system-development)
- [AI見積](https://deeptier.co.jp/ai-mitsumori)
- [実績紹介](https://deeptier.co.jp/case)
- [ニュース](https://deeptier.co.jp/news)
- [会社概要](https://deeptier.co.jp/#about)
- [お問い合わせ](https://deeptier.co.jp/contact)

- [システム受託開発](https://deeptier.co.jp/system-development)
- [AI見積](https://deeptier.co.jp/ai-mitsumori)
- [実績紹介](https://deeptier.co.jp/case)
- [ニュース](https://deeptier.co.jp/news)
- [会社概要](https://deeptier.co.jp/#about)
- [お問い合わせ](https://deeptier.co.jp/contact)

[テックブログ](https://deeptier.co.jp/info/tag/テックブログ)

# 【非機能要件のリアル】「サクサク動いて、絶対に止まらないシステム」が引き起こす悲劇。エンジニアが語る5つの着地点

 2026.05.11

「とにかくサクサク動くようにしてほしい」  
「業務で使うのだから、24時間365日絶対に止まらないのが当たり前」  
「将来は100万人規模になるから、最初からそれに耐えられる構成で」

システム開発の発注において、こうした「機能以外の要望（＝非機能要件）」は、しばしば抽象的な言葉で語られがちです。

![11](https://deeptier.co.jp/hs-fs/hubfs/11.png?width=1200&height=628&name=11.png)

しかし、これらを「具体的な数字とコスト」に変換しないまま開発をスタートさせると、後から「インフラ費用が予算の3倍になった」「いつまで経ってもリリースできない」といった悲劇を引き起こします。

deeptierエンジニアに、「システム発注者の安易な要望が引き起こす技術的リスクと、その正しい着地点」について、解説してもらいました。

 

---

 

## Q1. 【レスポンス速度】「サクサク動くようにして」と言われたら、どう困りますか？

【エンジニアの回答】  
「サクサク動く」という要望はユーザー体験の本質であり、素晴らしい出発点です。しかし、これを「〇秒以内に表示」という数値に落とし込まないと、エンジニアはサーバーのスペック（クラウド費用）や、APIの基本設計（同期か非同期か）を決められません。  
さらに、生成AIの推論や大量データ集計など「物理的にどうしても時間がかかる処理」を無理にコンマ秒で動かそうとすると、インフラ費用は際限なく膨れ上がります。

【deeptierの技術解】  
速度を上げるだけでなく、「待ち時間をデザインする（UI/UX設計）」アプローチをご提案します。  
重い処理は裏側（バックグラウンド）で実行させつつ、画面上では別の作業を許可したり、心地よいプログレスバーを表示させたりすることで、インフラ費用を抑えながら「体感的なサクサク感」を実現します。

 

##  Q2. 【可用性】「24時間365日、絶対に止まらないシステム」を初期要件とすることが危険な理由は何ですか？

【エンジニアの回答】  
「止まらないシステム」を作るためには、単なるサーバの設定変更では実現できず「物理的にサーバーをどこに、何台予備を用意するか」という議論が必要です。障害に備えてサーバーを2台にすれば費用は2倍、別のクラウド環境にもバックアップを置けば3倍以上に跳ね上がります。予算が無限にある企業はありません。「システムが1時間止まった時のビジネスの損失額」と「止まらないために追加で払う月額インフラ費用」を天秤にかける必要があります。

【deeptierの技術解】  
「絶対に止まらない城」を作るのではなく、「障害は必ず起きる前提に立ち、迅速かつ安全に復旧できるレジリエンス（回復力）」を設計に組み込みます。許容できる停止時間（SLA）を明確に合意し、費用対効果が最も高いアーキテクチャをご提案します。

 

## Q3. 【拡張性】将来を見据え、最初から「100万人規模」に耐えうるインフラ構成（マイクロサービス等）で開発すべきですか？

【エンジニアの回答】  
将来を見据えることは重要ですが、最初から大規模向けの複雑なアーキテクチャ（マイクロサービスやKubernetes等）を採用すると、ビジネス機能とは無関係な実装やテストの負荷が激増します。結果、リリースが遅れるだけでなく、ユーザー数がゼロでも高額な費用が発生してしまいます。

【deeptierの技術解】  
最初から巨大な城を建てるのではなく、まずは現在の規模に最適化した「快適な家」を建てます。ただし、後から増築しやすいよう「モジュラーモノリス（内部が綺麗に分割された疎結合な設計）」を採用します。ビジネスの成長に合わせて、負荷のかかる部分だけを段階的に強化・独立させていくのが、最も無駄のない戦略です。

![9](https://deeptier.co.jp/hs-fs/hubfs/9.png?width=1200&height=628&name=9.png)

## Q4. 【バックアップ】「毎日バックアップを取っているから、いつでも復旧できる」と安心してしまうのはなぜ危険ですか？

【エンジニアの回答】  
例えばAWSには過去の任意の秒単位に戻せる機能（PITR）がありますが、実運用における障害は「サーバーが物理的に壊れた」よりも「一部のデータだけ論理的におかしくなった（バグで上書きされた等）」ケースが大多数です。この時、単純にシステム全体を過去に巻き戻すと「正常に処理された他のデータ」まで道連れにして消してしまうため、単純な復元ボタンひとつでは解決しません。

【deeptierの技術解】  
単にデータを保存するだけでなく、「何時間分のデータ消失なら許容できるか（RPO）」と「何時間以内に復旧できれば良いか（RTO）」を事前に定義します。さらに重要なこととして、「実際の障害を想定した復旧リハーサル（訓練）」を運用要件に組み込み、いざという時に確実にサービスを再開できる体制を構築します。

 

## Q5. 【監査・セキュリティ】情報漏洩が起きた時に、誰がいつ何をしたかのログは取れますよね？

 【エンジニアの回答】  
「誰が・いつ・どのデータをどうしたか」という監査ログは、システム構築の土台部分に組み込む必要があります。これを要件定義で決めておかないと、万が一情報漏洩や不正アクセスが起きた際、原因究明の義務（個人情報保護法など）を果たせなくなります。また、ISMSやPマークなどの外部認証を取得・更新する際にも、改ざん不能なログの存在は必須要件となります。

【deeptierの技術解】  
監査ログは単なる「テキストの記録」ではなく、クラウドサービス（AWS CloudTrailなど）を活用し、「システム管理者でさえ改ざん不能なセキュアな形」で保存するアーキテクチャを標準で組み込みます。これが、もしもの時の企業の砦となります。

 

---

## まとめ：非機能要件は「ビジネスの決断」である

「サクサク」「絶対に止まらない」「安全」……。

これらは技術の魔法でタダで手に入るものではなく、すべて「インフラ費用」と「開発期間」とのトレードオフで成り立っています。

良いシステム開発会社とは、「何でもできます」と安請け合いする会社ではありません。  
「御社のビジネスにおいて、どこにお金をかけ、どこで妥協すべきか」というバランスシートを一緒に描き、最適なアーキテクチャを提案できる会社です。

「予算内で最高のパフォーマンスを出すシステム設計」にご興味がある方は、ぜひ一度弊社のエンジニアチームにご相談ください。

 

[ 【deeptierのシステム受託開発】現状の課題やビジネスゴールについて、壁打ちベースからご相談を承ります。 ](https://deeptier.co.jp/system-development)

---

## 【本記事の監修者】

浅野 貴史  
株式会社deeptier　技術フェロー

組込みソフトウェア開発からキャリアをスタート。その後、クラウド技術への深化を図り、数千万DL規模のサービス基盤構築やWebサービス開発を主導し、事業成長に貢献するなど、大規模サービス基盤を中心に低レイヤーからクラウドまで横断する技術知見を強みとする。  
日本、米国、ドイツの3ヶ国での常駐・開発経験を経て、複数の企業でCTOを歴任。近年は生成AI領域のスペシャリストとして、新規事業開発や企業のDX推進を牽引している。2024年 当社設立時より技術フェロー（非常勤）。

---

※この記事の技術情報について  
本記事は2026年4月時点の一般的な開発情報に基づいて執筆されています。技術トレンドの変化により、推奨されるツールや手法は変わる可能性があります。

[![deeptier](https://deeptier.co.jp/hubfs/raw_assets/public/deeptier-theme/images/logo_brand_white.svg)](https://deeptier.co.jp/)

 〒231-0032  
 神奈川県横浜市中区不老町3丁目13-12 2F

- [HOME](https://deeptier.co.jp/)
- [システム受託開発](https://deeptier.co.jp/system-development)
- [AI見積](https://deeptier.co.jp/ai-mitsumori)
- [実績紹介](https://deeptier.co.jp/case)
- [ニュース](https://deeptier.co.jp/news)
- [会社概要](https://deeptier.co.jp/#about)
- [お問い合わせ](https://deeptier.co.jp/info/contact)

© deeptier Inc. All Rights Reserved.

```json
{
  "@context" : "https://schema.org",
  "@type" : "WebSite",
  "alternateName" : "株式会社deeptier",
  "name" : "deeptier",
  "url" : "https://deeptier.co.jp/"
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "浅野 貴史",
    "url" : "https://deeptier.co.jp/info/author/浅野-貴史"
  },
  "dateModified" : "2026-05-11T06:46:13.475Z",
  "datePublished" : "2026-05-11T05:41:39.000Z",
  "headline" : "【非機能要件のリアル】「サクサク動いて、絶対に止まらないシステム」が引き起こす悲劇。エンジニアが語る5つの着地点",
  "image" : [ "https://deeptier.co.jp/hubfs/11.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://deeptier.co.jp/info/hikinoyoken",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://deeptier.co.jp/hubfs/yokp.png"
    }
  }
}
```

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://deeptier.co.jp/info/author/%E6%B5%85%E9%87%8E-%E8%B2%B4%E5%8F%B2",
      "name": "浅野 貴史",
      "jobTitle": "技術フェロー",
      "worksFor": {
        "@type": "Organization",
        "name": "株式会社deeptier"
      },
      "description": "組込みソフトウェア開発からキャリアをスタート。その後、クラウド技術への深化を図り、数千万DL規模のサービス基盤構築やWebサービス開発を主導し、事業成長に貢献するなど、大規模サービス基盤を中心に低レイヤーからクラウドまで横断する技術知見を強みとする。日本、米国、ドイツの3ヶ国での常駐・開発経験を経て、複数の企業でCTOを歴任。近年は生成AI領域のスペシャリストとして、新規事業開発や企業のDX推進を牽引している。2024年 当社設立時より技術フェロー（非常勤）。",
      "url": "https://deeptier.co.jp/info/author/%E6%B5%85%E9%87%8E-%E8%B2%B4%E5%8F%B2"
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Q1. 【レスポンス速度】「サクサク動くようにして」と言われたら、どう困りますか？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "【エンジニアの回答】
「サクサク動く」という要望はユーザー体験の本質であり、素晴らしい出発点です。しかし、これを「〇秒以内に表示」という数値に落とし込まないと、エンジニアはサーバーのスペック（クラウド費用）や、APIの基本設計（同期か非同期か）を決められません。
さらに、生成AIの推論や大量データ集計など「物理的にどうしても時間がかかる処理」を無理にコンマ秒で動かそうとすると、インフラ費用は際限なく膨れ上がります。

【deeptierの技術解】
速度を上げるだけでなく、「待ち時間をデザインする（UI/UX設計）」アプローチをご提案します。
重い処理は裏側（バックグラウンド）で実行させつつ、画面上では別の作業を許可したり、心地よいプログレスバーを表示させたりすることで、インフラ費用を抑えながら「体感的なサクサク感」を実現します。"
          }
        },
        {
          "@type": "Question",
          "name": " Q2. 【可用性】「24時間365日、絶対に止まらないシステム」を初期要件とすることが危険な理由は何ですか？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "【エンジニアの回答】
「止まらないシステム」を作るためには、単なるサーバの設定変更では実現できず「物理的にサーバーをどこに、何台予備を用意するか」という議論が必要です。障害に備えてサーバーを2台にすれば費用は2倍、別のクラウド環境にもバックアップを置けば3倍以上に跳ね上がります。予算が無限にある企業はありません。「システムが1時間止まった時のビジネスの損失額」と「止まらないために追加で払う月額インフラ費用」を天秤にかける必要があります。

【deeptierの技術解】
「絶対に止まらない城」を作るのではなく、「障害は必ず起きる前提に立ち、迅速かつ安全に復旧できるレジリエンス（回復力）」を設計に組み込みます。許容できる停止時間（SLA）を明確に合意し、費用対効果が最も高いアーキテクチャをご提案します。"
          }
        },
        {
          "@type": "Question",
          "name": "Q3. 【拡張性】将来を見据え、最初から「100万人規模」に耐えうるインフラ構成（マイクロサービス等）で開発すべきですか？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "【エンジニアの回答】
将来を見据えることは重要ですが、最初から大規模向けの複雑なアーキテクチャ（マイクロサービスやKubernetes等）を採用すると、ビジネス機能とは無関係な実装やテストの負荷が激増します。結果、リリースが遅れるだけでなく、ユーザー数がゼロでも高額な費用が発生してしまいます。

【deeptierの技術解】
最初から巨大な城を建てるのではなく、まずは現在の規模に最適化した「快適な家」を建てます。ただし、後から増築しやすいよう「モジュラーモノリス（内部が綺麗に分割された疎結合な設計）」を採用します。ビジネスの成長に合わせて、負荷のかかる部分だけを段階的に強化・独立させていくのが、最も無駄のない戦略です。"
          }
        },
        {
          "@type": "Question",
          "name": "Q4. 【バックアップ】「毎日バックアップを取っているから、いつでも復旧できる」と安心してしまうのはなぜ危険ですか？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "【エンジニアの回答】
例えばAWSには過去の任意の秒単位に戻せる機能（PITR）がありますが、実運用における障害は「サーバーが物理的に壊れた」よりも「一部のデータだけ論理的におかしくなった（バグで上書きされた等）」ケースが大多数です。この時、単純にシステム全体を過去に巻き戻すと「正常に処理された他のデータ」まで道連れにして消してしまうため、単純な復元ボタンひとつでは解決しません。

【deeptierの技術解】
単にデータを保存するだけでなく、「何時間分のデータ消失なら許容できるか（RPO）」と「何時間以内に復旧できれば良いか（RTO）」を事前に定義します。さらに重要なこととして、「実際の障害を想定した復旧リハーサル（訓練）」を運用要件に組み込み、いざという時に確実にサービスを再開できる体制を構築します。"
          }
        },
        {
          "@type": "Question",
          "name": "Q5. 【監査・セキュリティ】情報漏洩が起きた時に、誰がいつ何をしたかのログは取れますよね？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "【エンジニアの回答】
「誰が・いつ・どのデータをどうしたか」という監査ログは、システム構築の土台部分に組み込む必要があります。これを要件定義で決めておかないと、万が一情報漏洩や不正アクセスが起きた際、原因究明の義務（個人情報保護法など）を果たせなくなります。また、ISMSやPマークなどの外部認証を取得・更新する際にも、改ざん不能なログの存在は必須要件となります。

【deeptierの技術解】
監査ログは単なる「テキストの記録」ではなく、クラウドサービス（AWS CloudTrailなど）を活用し、「システム管理者でさえ改ざん不能なセキュアな形」で保存するアーキテクチャを標準で組み込みます。これが、もしもの時の企業の砦となります。"
          }
        }
      ]
    }
  ]
}
```