メインコンテンツまでスキップ

非機能要件への対応方針

この文書の目的​

この文書は、Nijo により生成される業務アプリケーションが、IPA 非機能要求グレードの各観点をどこまで標準構成でカバーできるかを、導入検討者向けに整理したものである。

ここでいう標準構成とは、Nijo により生成される以下の要素を指す。

  • データモデルに基づく CRUD 処理
  • クエリモデルに基づく一覧検索処理
  • ASP.NET Core Web API
  • TypeScript 型定義と API クライアント
  • Entity Framework Core によるデータアクセス
  • アプリケーションサービス層の拡張ポイント
  • マイグレーション、ログ出力、設定外出しの土台

また、本書では生成後アプリケーションの代表例として demo/101_販売管理システム を参照している。

評価の見方​

各項目は以下の 2 区分で記述する。

  • 一部対応: Nijo の標準構成でその非機能要件を実現しやすくするための土台の提供がある。案件ごとの要件に応じてチューニングし導入する。
  • 対象外: Nijo の標準構成では扱わず、導入先またはアプリ個別の設計に委ねられる。

総論として、Nijo はデータ完全性、検索機能、保守性の土台を揃えることに強みがある。一方で、高可用構成、認証認可、監視運用、災害対策のようなインフラ寄りの非機能要件は、導入先の基盤設計と組み合わせて実現する前提である。

A. 可用性​

可用性について、Nijo の標準構成は業務トランザクションの失敗を安全に戻すことには寄与するが、冗長化や災害対策そのものを提供するものではない。

中項目小項目対応状況内容
継続性運用スケジュール対象外24時間運転、計画停止可能時間帯、夜間バッチ時間帯などの運用条件は、アプリ固有要件と運用設計による。Nijo はその判断基準自体は提供しない。
継続性業務継続性一部対応更新処理はトランザクションとロールバック前提で生成されるため、障害時にデータ不整合を残しにくい。一方、サービス継続のための冗長構成や切替運用は別途必要である。
継続性目標復旧水準（業務停止時）対象外RTO、RPO は標準では定義しない。業務停止からの復旧水準は、基盤構成、バックアップ方式、運用手順とあわせて定義する必要がある。
継続性目標復旧水準（大規模災害時）対象外遠隔地バックアップ、DR サイト、クラウド多重化などは Nijo の対象外である。
継続性稼働率対象外稼働率は生成コードではなく、基盤の冗長構成、監視、保守体制で決まる。
耐障害性サーバ対象外アプリケーション自体は一般的な ASP.NET Core アプリとして構成されるが、サーバ多重化や自動フェイルオーバーは別途設計する。
耐障害性端末対象外ブラウザ利用を前提とした Web アプリの標準構成は提供されるが、端末冗長化やキッティング運用は対象外である。
耐障害性ネットワーク機器対象外ロードバランサ、FW、プロキシ、回線冗長化などは導入基盤側の責務である。
耐障害性ネットワーク対象外通信断への再送制御、経路冗長化、WAN 障害対策は標準では提供しない。
耐障害性ストレージ対象外DB ストレージの冗長化、スナップショット、RAID、クラウド永続ディスク設計は別途必要である。
耐障害性データ一部対応楽観排他制御、ユニーク制約、トランザクション、セーブポイントにより、更新競合や更新失敗時のデータ破損を防ぐ土台がある。ただしバックアップやメディア障害対策は含まない。
災害対策システム対象外DR 構成、災害時の起動手順、代替サイト切替は標準では提供しない。
災害対策外部保管データ対象外バックアップ媒体の外部保管、クラウド別リージョン保管などは運用設計に委ねられる。
災害対策付帯設備対象外電源、空調、入退室管理などの設備要件は対象外である。
回復性復旧作業一部対応DB マイグレーション、設定外出し、ログ出力の土台はあるため復旧作業を標準化しやすい。ただし復旧手順書や訓練は別途必要である。
回復性可用性確認対象外死活監視、ヘルスチェック、SLO 計測は標準では組み込まれていない。必要に応じてそれ用のコマンドモデルを定義すること。

可用性に関する補足​

  • 更新系はトランザクション前提で生成され、失敗時にはロールバックできる。
  • 更新・削除・論理削除処理ではセーブポイントも利用され、処理途中エラー時の巻き戻しを行いやすい。
  • ただし、これは「止まりにくい構成」ではなく「壊れにくい更新処理」に近い。

B. 性能・拡張性​

性能・拡張性について、Nijo は検索・更新の一般的な実装を揃え、チューニング余地も残す方針をとっている。とくに一覧検索処理は標準でページングとソートに対応している。

中項目小項目対応状況内容
業務処理量業務量増大度一部対応業務量増加への直接的な保証値はないが、一覧検索はページング前提で生成されるため、全件取得を避けやすい。検索方式や索引設計により拡張可能である。
業務処理量保管期間対象外データ保持年限、アーカイブ方針、履歴テーブル設計はアプリごとに定める必要がある。論理削除を使う場合も保管期間ルールまでは自動化しない。
性能目標値オンラインレスポンス一部対応一般的な CRUD と一覧検索の土台はあるが、インフラ構成に大きく左右されるため応答時間目標そのものは保証しない。必要に応じて View 利用、索引設計、検索条件見直しを行う。
性能目標値バッチレスポンス（ターンアラウンドタイム）対象外バッチ処理の実装基盤として Core 層を再利用できるが、バッチ性能設計そのものは対象外である。
性能目標値オンラインスループット対象外スループット目標は基盤規模、同時接続数、SQL 設計に依存する。標準構成だけで保証するものではない。
性能目標値バッチスループット対象外バッチ並列化、分割実行、キューイングは標準では提供しない。
性能目標値帳票印刷能力対象外帳票基盤や PDF 出力基盤は標準では提供しない。任意のライブラリやサービスを利用可能。
リソース拡張性CPU拡張性一部対応一般的な ASP.NET Core / EF Core 構成であるため、スケールアップやコンテナ配備への移行はしやすい。自動水平分散機能はない。
リソース拡張性メモリ拡張性一部対応型安全な標準実装でメモリ特性は読みやすいが、大量件数処理や一括更新時のメモリ使用量は個別検証が必要である。
リソース拡張性ディスク拡張性対象外DB 容量、ログ保持、添付ファイル保管設計は別途定義する必要がある。
リソース拡張性ネットワーク対象外通信量削減、CDN、エッジ配置、回線増強の判断は基盤設計側の責務である。
リソース拡張性サーバ処理能力増強一部対応業務ロジックと UI が分離されているため、Web/API の増強はしやすい。だが、セッション共有、負荷分散、オートスケールは標準では未提供である。
性能品質保証性能テスト対象外単体テストや開発用土台はあるが、性能試験シナリオ、負荷試験、容量試験は案件側で実施する必要がある。
性能品質保証スパイク負荷対応対象外一時的な急増負荷への対策は、キャッシュ、レート制御、スケール戦略を含め個別設計が必要である。

性能・拡張性に関する補足​

  • 一覧検索は Skip / Take によるページングを標準提供する。
  • ソート条件と検索条件は型付きで扱われる。
  • QueryModel は DB View へのマッピングに対応しており、複雑な参照系を RDBMS 側で最適化できる。
  • View の定義自体は自動生成されないため、性能設計の本番品質は案件ごとの DB 設計に依存する。

C. 運用・保守性​

運用・保守性について、Nijo はソースコード構造の明確化、設定外出し、ログ、マイグレーション、テストしやすい構造により、保守しやすい土台を提供する。

中項目小項目対応状況内容
通常運用運用時間対象外営業日、運転時間帯、夜間停止の可否は個別の運用設計事項である。
通常運用バックアップ対象外バックアップ取得、保管、復元手順は標準では含まれない。
通常運用運用監視対象外ログ出力の土台はあるが、監視ルール、通知、メトリクス監視、死活監視は別途必要である。
通常運用時刻同期対象外アプリはサーバ時刻を使用するが、NTP 同期や時刻源の設計は基盤側の責務である。
保守運用計画停止対象外メンテナンス停止手順は標準では定義しない。
保守運用運用負荷削減一部対応設定外出し、マイグレーション、ログ、標準構成の統一により保守作業は簡素化しやすい。
保守運用パッチ適用ポリシー対象外.NET、Node.js、OS、DB の更新方針は導入側で定める必要がある。
保守運用活性保守対象外無停止パッチ適用やローリング更新は基盤設計の範囲である。
保守運用定期保守頻度対象外ログ掃除、DB メンテナンス、バージョンアップの頻度は運用設計による。
保守運用予防保守レベル対象外予兆検知、容量監視、脆弱性対応の運用水準は標準外である。
障害時運用復旧作業一部対応ログ、構成分離、マイグレーションにより復旧作業は定型化しやすいが、自動復旧手順は別途必要である。
障害時運用障害復旧自動化の範囲対象外自動再起動、自動切替、自動復元は基盤または運用ツールで実現する。
障害時運用システム異常検知時の対応対象外検知ルール、エスカレーション、一次切り分け手順は標準では提供しない。
障害時運用交換用部材の確保対象外ハードウェア運用の領域であり、Nijo の対象外である。
運用環境開発用環境の設置一部対応標準テンプレート、デバッグ構成、Swagger、開発用起動スクリプトがあり、開発環境を整えやすい。
運用環境試験用環境の設置一部対応UnitTest、マイグレーション、設定切替の土台はあるが、試験環境数やデータ準備運用は別途必要である。
運用環境マニュアル準備レベル対象外運用手順書、問い合わせ対応手順書、障害対応手順書は個別整備が必要である。
運用環境リモートオペレーション対象外VPN、踏み台、遠隔保守手順は基盤設計に依存する。
運用環境外部システム接続一部対応DI による外部システム切替や接続先設定の外出しはしやすい。だが接続品質保証、再送制御、回線設計は別途必要である。
サポート体制保守契約（ハードウェア）対象外Nijo の対象外である。
サポート体制保守契約（ソフトウェア）対象外OSS 利用方針、内製保守範囲、ベンダサポート契約は別途整理する。
サポート体制ライフサイクル期間対象外製品寿命やサポート年限は導入組織側で定義する。
サポート体制メンテナンス作業役割分担対象外アプリ保守、基盤保守、業務部門の役割分担は個別設計である。
サポート体制一次対応役割分担対象外障害連絡窓口、一次切り分け、エスカレーションは別途定義する必要がある。
サポート体制サポート要員対象外要員数やスキル要件は Nijo では規定しない。
サポート体制導入サポート対象外データ移行支援、利用者教育、立上げ支援は案件単位で計画する。
サポート体制オペレーション訓練対象外障害訓練、切替訓練、運用訓練は別途必要である。
サポート体制定期報告会対象外運用品質管理プロセスに依存する。
その他の運用管理方針内部統制対応一部対応ログ、更新者・更新時刻の記録、業務ロジックの集約など、統制設計の土台はある。最終的な証跡要件や承認フローは個別実装が必要である。
その他の運用管理方針サービスデスク対象外問い合わせ窓口やチケット運用は対象外である。
その他の運用管理方針インシデント管理対象外標準プロセスは提供しない。
その他の運用管理方針問題管理対象外標準プロセスは提供しない。
その他の運用管理方針構成管理一部対応ソースコード、マイグレーション、設定ファイル、リリース物の分離により構成管理しやすい。だが CMDB や棚卸運用は別途必要である。
その他の運用管理方針変更管理一部対応スキーマ変更からコード再生成、マイグレーションまでの経路が明確で、変更の追跡はしやすい。承認フローや変更審査は別途必要である。
その他の運用管理方針リリース管理一部対応リリース作業スクリプトやバージョン情報記録の土台はあるが、承認手続、段階配備、ロールバック判定は個別設計である。

運用・保守性に関する補足​

  • 自動生成コードと手動実装コードが分離されており、再生成時に手修正が潰れにくい。
  • アプリケーションサービス層に業務ロジックを集約しやすく、UI とロジックが分離される。
  • ログ出力ではユーザー ID、処理名、処理単位 ID を持たせる土台がある。
  • ログ出力用シリアライズではマスキング対応も可能である。

D. 移行性​

移行性について、Nijo はスキーマ変更の反映や新規構築・継続開発には向くが、既存システムからの複雑な移行を自動化するものではない。

中項目小項目対応状況内容
移行時期移行のスケジュール対象外カットオーバー日程、段階導入、並行稼働期間は案件ごとに決める必要がある。
移行方式システム展開方式一部対応通常の Web アプリとしてデプロイできるため展開方式は選びやすいが、ブルーグリーン、段階展開、テナント単位展開などは個別設計が必要である。
移行対象（機器）移行設備対象外サーバ、端末、周辺機器の入替は対象外である。
移行対象（データ）移行データ量対象外大量データ移行の方式や所要時間見積りは個別に実施する必要がある。
移行対象（データ）移行媒体対象外ファイル、DB 直結、API 経由などの移行媒体は案件次第である。
移行対象（データ）変換対象（DBなど）一部対応EF Core マイグレーションによりスキーマ進化には対応しやすいが、既存データの意味変換やコード変換は別実装が必要である。
移行計画移行作業分担対象外ベンダ、情シス、業務部門の役割分担は別途定義する。
移行計画リハーサル対象外移行リハーサルやリカバリ訓練は標準範囲外である。
移行計画トラブル対処対象外切戻し判定、障害時の連絡網、緊急対応手順は個別に整備する必要がある。

移行性に関する補足​

  • マイグレーション、設定外出し、リリース時のバージョン記録により、継続的な改修や再配備はしやすい。
  • 一方、レガシー資産からのデータ変換や業務切替は、業務知識を伴うため自動生成の対象外である。

E. セキュリティ​

セキュリティについて、Nijo はデータ完全性やログの土台には寄与するが、認証認可や通信保護を完成済み機能としては提供しない。導入時には「完全性には比較的強いが、機密性と認可は個別設計が必要」という整理が妥当である。

中項目小項目対応状況内容
前提条件・制約条件情報セキュリティに関するコンプライアンス対象外法令、業界ガイドライン、社内規程への適合判定は案件側で実施する必要がある。
セキュリティリスク分析セキュリティリスク分析対象外脅威分析、リスク受容判断、対策方針は標準では提供しない。
セキュリティ診断セキュリティ診断対象外脆弱性診断、ペネトレーションテスト、コード診断は別途実施する必要がある。
セキュリティリスク管理セキュリティリスクの見直し対象外運用中の見直しプロセスは対象外である。
セキュリティリスク管理セキュリティリスク対策の見直し対象外改善サイクルの運用は対象外である。
セキュリティリスク管理セキュリティパッチ適用対象外ランタイム、OSS、OS のパッチ適用ポリシーは導入側で定義する。
アクセス・利用制限認証機能対象外標準生成では認証方式を固定しない。101 デモでは Cookie ベースのログイン機構をアプリ個別に実装している。
アクセス・利用制限利用制限対象外権限モデル、ロール設計、画面・処理単位の認可は個別実装が必要である。101 デモでは販売担当や入荷担当の権限判定を独自実装している。
データの秘匿データ暗号化対象外通信暗号化、保存データ暗号化、鍵管理は標準では提供しない。
不正追跡・監視不正監視対象外SIEM 連携や不正操作検知は別途設計が必要である。
不正追跡・監視データ検証一部対応楽観排他、ユニーク制約、バリデーション、共通の更新前チェックにより、改ざんや不整合を防ぎやすい。
ネットワーク対策ネットワーク制御対象外FW、WAF、IP 制限、ゼロトラスト構成は基盤・運用設計に委ねられる。
ネットワーク対策不正検知対象外IDS/IPS やアクセス異常検知は標準外である。
ネットワーク対策サービス停止攻撃の回避対象外DDoS 対策、レート制御、エッジ防御は個別設計である。
マルウェア対策マルウェア対策対象外エンドポイント保護やサーバ保護は基盤側の対策である。
Web対策Web実装対策一部対応ASP.NET Core と型付き API により安全な実装を行いやすいが、CSRF、CSP、Cookie 方針、入力サニタイズ方針は個別に確認が必要である。
セキュリティインシデント対応/復旧セキュリティインシデント対応/復旧対象外連絡体制、封じ込め、証跡保全、復旧判断は別途整備が必要である。

セキュリティに関する補足​

  • DataModel では集約単位の楽観排他制御が組み込まれ、更新競合を検知できる。
  • ユニーク制約をスキーマから定義でき、DB の一意制約として反映できる。
  • 作成者、更新者、作成時刻、更新時刻の監査列を持たせる標準構成がある。
  • ただし、現在ユーザーの取得方法は標準では固定されず、生成基底クラスの既定値は未定義扱いであるため、認証基盤との接続は個別実装が必要である。
  • 101 デモのログイン機構は「Nijo の標準機能」ではなく、生成後アプリへの実装例である。

権限について​

  • 機能単位の権限
    • カスタム属性での実装を推奨。
    • Query / Command モデルごとにカスタム属性で権限の種類を設定する（「システム管理者のみ利用可能 (true / false)」など）
    • ASP.NET Core の ActionFilter で属性を参照し、認可処理を実装する。
  • データ単位の権限
    • 閲覧権限
      • QueryModel : CreateQuerySource でログインユーザーの権限を見て Where 句を付加する方式を推奨。
      • 画面初期表示などの CommandModel : コマンドハンドラー内でログインユーザーの権限を見て、更新対象のデータに対して閲覧権限があるかを判定する。
    • 更新権限
      • 更新系の CommandModel : コマンドハンドラー内でログインユーザーの権限を見て、更新対象のデータに対して更新権限があるかを判定する。
      • DataModel : どの CommandModel から更新される場合であっても常に権限判定が必要な場合は、DataModel 内で更新前チェックを実装することも可能である。

F. システム環境・エコロジー​

システム環境・エコロジーについて、Nijo は一般的な Web アプリケーションとして配備しやすいが、物理環境要件や環境負荷評価そのものは対象外である。

中項目小項目対応状況内容
システム制約/前提条件構築時の制約条件一部対応標準技術スタックは .NET、ASP.NET Core、EF Core、TypeScript であり、一般的な開発環境に乗せやすい。特殊なハードウェア要件は前提としない。
システム制約/前提条件運用時の制約条件対象外ネットワーク分離、クラウド利用可否、OS 制約、社内標準ミドルウェアへの適合は導入先要件による。
システム特性ユーザ数対象外想定ユーザ数に応じたサイジングは案件ごとに必要である。
システム特性クライアント数対象外接続端末数、同時接続数は性能設計とあわせて別途見積もる必要がある。
システム特性拠点数対象外複数拠点利用時の回線設計、遅延対策は標準外である。
システム特性地域的広がり対象外多地域配備、海外リージョン、データ所在制約は別途判断が必要である。
システム特性特定製品指定一部対応標準テンプレートは SQLite を採用しているが、EF Core が扱える RDBMS へ拡張しやすい。特定製品固定のアーキテクチャではない。
システム特性システム利用範囲対象外社内限定、取引先公開、インターネット公開の別は導入要件による。
システム特性複数言語対応対象外多言語化の標準基盤は提供しない。文言管理や i18n はアプリ個別に実装する必要がある。
適合規格製品安全規格対象外物理機器を伴う製品安全規格への適合は対象外である。
適合規格環境保護対象外環境法規制対応は基盤・設備側の話である。
適合規格電磁干渉対象外物理機器要件であり、Nijo の範囲外である。
機材設置環境条件耐震/免震対象外データセンタや設備要件に依存する。
機材設置環境条件スペース対象外物理設置方式に依存する。
機材設置環境条件重量対象外物理設置方式に依存する。
機材設置環境条件電気設備適合性対象外物理設備要件である。
機材設置環境条件温度（帯域）対象外物理設備要件である。
機材設置環境条件湿度（帯域）対象外物理設備要件である。
機材設置環境条件空調性能対象外物理設備要件である。
環境マネージメント環境負荷を抑える工夫対象外クラウド利用、集約率、夜間停止などの方針は導入設計による。
環境マネージメントエネルギー消費効率対象外アプリ単体では評価せず、基盤全体で評価する項目である。
環境マネージメントCO2排出量対象外基盤選定と運用方式に依存する。
環境マネージメント低騒音対象外物理設備要件であり対象外である。

導入判断の目安​

Nijo を非機能要件の観点から評価すると、次のように整理できる。

  • 強い領域: データ完全性、更新時の整合性、検索機能の標準化、保守しやすいコード構造、設定外出し、マイグレーション、ログの土台
  • 一部対応の領域: 性能チューニング余地、運用標準化、内部統制向けの証跡基盤、外部システム連携の構造化
  • 個別設計が必須の領域: 認証認可、通信保護、高可用構成、監視運用、災害対策、移行計画、インフラ設備条件

したがって、Nijo は「非機能要件をすべて内包した完成済み業務パッケージ」ではなく、「業務アプリケーションの堅い土台を生成するフレームワーク」として位置づけるのが適切である。

導入判断としては、以下のような案件で特に適している。

  • 業務データの整合性を重視する基幹寄りの業務アプリ
  • 一覧検索や CRUD の品質を早期に揃えたい案件
  • 将来の保守や引継ぎを考慮し、素直な C# / TypeScript コードを残したい案件

逆に、以下の要件が主眼である場合は、Nijo 単体ではなく、周辺基盤や個別設計を前提に採用判断すべきである。

  • 厳格な認証認可やセキュリティ統制
  • 24時間365日運用や高い SLA
  • 大規模データや高負荷トラフィックに対する性能保証
  • 複雑な既存システムからの移行や段階切替