2.1システム方式設計の基礎

システムアーキテクトの最初の仕事は、要件定義で洗い出された機能を「誰が・何で実現するか」に振り分けることです。すべてをソフトウェアで自動化することが常に正解とは限りません——専用ハードウェアの方が性能・信頼性で優れる場合もあれば、発生頻度が極めて低い例外処理はあえて手作業に残す方が開発コスト・保守コストの総和で有利な場合もあります。この節では、機能配分の判断軸と、複数のトレードオフを踏まえた方式選定の考え方を学びます。

2.1.1機能配分：ハード・ソフト・手作業

• 機能配分＝要求される機能を、専用ハードウェア（高速・高信頼だが変更コストが高い）、ソフトウェア（柔軟に変更できるが処理性能はハードに劣る場合がある）、手作業（発生頻度が低い・判断が高度に属人的な例外処理に向く）のいずれで実現するかを決める設計工程。
• 配分の判断は単一の軸（例えば性能だけ）で決めてはならない——ハード化すれば性能は上がっても仕様変更のたびに再設計・再製造が必要になりコスト・納期面で不利になり得る。逆にすべて手作業に残すと、頻度が高まった途端に人的ミス・処理遅延のリスクが増大する。発生頻度・変更頻度・要求性能・要員コストを総合して配分するのがシステムアーキテクトの役割。

2.1.2方式選定の判断軸

• 方式選定では性能（応答時間・スループット）、コスト（開発・運用・ライセンス）、可用性（稼働率・障害時の影響範囲）、保守性（変更のしやすさ・影響範囲の局所化）の4軸が代表的なトレードオフ関係にある。ある軸を最大化すると別の軸を犠牲にすることが多く、要件の優先順位に沿って妥協点を選ぶのがシステムアーキテクトの判断。
• 例えば、冗長構成を増やせば可用性は上がるがコストは増大し、機能を細かく分割すれば保守性は上がるが呼び出し間の通信オーバーヘッドで性能は下がりやすい。方式選定は「どれが優れているか」ではなく「この要件のもとで何を優先し何を許容するか」という相対評価である。

あるシステムアーキテクトが、工場の生産ラインを監視する新システムの設計を任されました。要件には「センサから得た温度・振動データをミリ秒単位でリアルタイム判定し、異常があれば即座にラインを緊急停止する」という機能と、「月次で生産実績データを集計し、経営層向けレポートを自動生成する」という機能の2つが含まれています。前者は判定の遅延がそのまま設備損傷・安全事故につながるため、汎用サーバ上のソフトウェア処理では通信・OSスケジューリングの遅延が無視できず、専用の組込み制御ハードウェア（PLCやFPGA等）に機能配分する判断が妥当です。ハード化により再設計コストは上がりますが、この機能は仕様変更の頻度が低く安全要件が最優先されるため、コスト増より性能・信頼性を優先する判断が理にかなっています。一方、後者の月次集計・レポート生成はリアルタイム性が不要で、集計ロジックの変更（新しい指標の追加等）が今後頻繁に見込まれるため、ソフトウェア（バッチ処理）に配分し、保守性・変更容易性を優先する方が妥当です。さらに、ごく稀にしか発生しない「センサ自体の故障を判別する」という機能については、発生頻度が極めて低く、誤判定時の影響が大きいため、自動化のための開発コストをかけるより、稀な異常を検知した際に現場担当者が目視確認する手作業のフローとして残す判断も検討に値します。このように、システムアーキテクトは同一システム内でも機能ごとに配分先を使い分け、それぞれの発生頻度・変更頻度・要求性能・コストという複数軸から最適な組み合わせを設計します。

2.1.3この節のまとめ

• 機能配分はハード/ソフト/手作業を発生頻度・変更頻度・要求性能・コストで総合判断する
• 方式選定は性能・コスト・可用性・保守性のトレードオフの相対評価であり、単一軸で決めない
• 同一システム内でも機能ごとに配分先を使い分け、要件の優先順位に沿った組み合わせを設計する