ハードウェアアーキテクト

エンジニアという集団は、人間のニーズを的確に理解し、それに応える能力や、人間にとって機能的で美的にも優れた製品を開発する能力に長けているとは言えません。一方、建築家は人間のニーズを理解し、人間にとって機能的で美的にも優れた製品を開発することが期待されています。優れた建築家は、ユーザー／スポンサーとエンジニアの間、さらには異なる専門分野のエンジニア同士の間でも、橋渡し役を務めます。また、優れた建築家は、最終製品に対するユーザーのビジョン、そしてそのビジョンから要件を導き出し、実現していくプロセスを管理する主要な役割を担います。

ユーザーやスポンサーが口にする要望ではなく、実際に何を求めているのかを見極めることは、エンジニアリングではなく芸術である。 アーキテクトは厳密な手順に従うのではなく、ユーザーやスポンサーと緊密にコミュニケーションを取り、共に設計システムに必要な真の要件を抽出していく。ハードウェアアーキテクトは、エンドユーザー（またはシステムアーキテクト）と常に連絡を取り合う必要がある。そのため、アーキテクトはユーザーの環境と問題点を熟知していなければならない。エンジニアは、潜在的なエンジニアリングソリューションの範囲について十分な知識があればよい。

ユーザー/スポンサーは、アーキテクトをユーザーの代表者とみなし、すべてのインプットをアーキテクトを通して行うべきです。 プロジェクトエンジニアとの直接的なやり取りは、相互の誤解が生じる可能性が非常に高いため、一般的には推奨されません。ユーザー要件の仕様は、ユーザーとハードウェアアーキテクト（またはシステムアーキテクトとハードウェアアーキテクト）の共同作業の成果物であるべきです。ユーザーは自身のニーズと要望リストを提供し、アーキテクトはコストと時間の制約内で実現可能な事柄に関する知識を提供します。ユーザーのニーズが高レベルの要件セットに変換された時点で、受け入れテストの最初のバージョンを作成するのが最適であり、その後は要件に合わせて常に最新の状態に維持する必要があります。そうすることで、ユーザーは自分が何を得るのかを完全に理解できます。また、テスト不可能な要件、誤解、要件の肥大化を防ぐことにもつながります。

ハードウェアエンジニアリング要件の第一段階の開発は、単なる分析作業ではなく、ハードウェアアーキテクトとエンジニアの両方が関与する必要があります。コスト、スケジュール、電力、スペースなどの制約を満たすために何らかの妥協が必要な場合、アーキテクトは最終製品と全体的な外観がユーザーの意図から大きく逸脱しないようにしなければなりません。エンジニアは、制約を最適化しつつ、実用的で信頼性の高い製品を保証する設計の開発に注力する必要があります。アーキテクトは主に製品の快適性と使いやすさに関心を持ち、エンジニアは主に製品の生産性と有用性に関心を持つのです。

エンジニアリングされたシステムの真の機能は、ユーザーに必要なサービスを提供することです。しかし、システムがますます大規模かつ複雑化し、単純なハードウェアコンポーネントから重点が離れるにつれて、従来のハードウェア開発原則を狭義に適用するだけでは不十分であることが判明し、より一般的なハードウェアアーキテクチャの原則を（サブ）システムの設計に適用する必要性が認識されるようになりました。ハードウェアアーキテクチャは、完成した最終製品の簡略化されたモデルでもあります。その主な機能は、ハードウェアコンポーネントとそれらの相互関係を定義し、全体としてユーザーが意図したものを、特にコンピュータと人間のインターフェースにおいて、一貫性があり、完全かつ正確に表現できるようにすることです。また、コンポーネントが適切に連携し、望ましい方法で関連していることを保証するためにも使用されます。

ユーザーの世界のアーキテクチャと、設計されたハードウェアのアーキテクチャを区別する必要がある。前者は、ユーザーの世界における問題と解決策を表し、それらに対応する。これは主に、設計されたシステムのコンピュータ・ヒューマン・インターフェース（CHI）に反映される。設計されたシステムは、エンジニアリング上の解決策、つまり、エンジニアがCHIをサポートするために技術インフラストラクチャのコンポーネントをどのように開発、選択、組み合わせるかを示すものである。アーキテクトがいない場合、エンジニアはハードウェアの観点から考えるが、ユーザーは、人々をA地点からB地点まで妥当な時間とエネルギー消費で移動させる問題、あるいは顧客やスタッフに必要な情報を提供する問題の解決という観点から考える可能性があるため、この2つのアーキテクチャを混同する傾向が残念ながらある。ハードウェアアーキテクトには、ユーザーの世界のアーキテクチャと（潜在的に有用な）ハードウェアエンジニアリングアーキテクチャの両方の知識を組み合わせることが求められる。前者はユーザーとの共同作業であり、後者はエンジニアとの共同作業である。この製品は、ユーザーの要求を反映した高レベルの要件セットであり、エンジニアがハードウェアシステムの設計要件を策定する際に使用できます。

要件はプロジェクト、特に長期にわたるプロジェクトの過程で変化するため、ハードウェアシステムがユーザーに受け入れられるまではアーキテクトが必要となります。アーキテクトは、開発過程で行われる変更や解釈によってユーザーの視点が損なわれることがないようにするための最良の保証となるからです。

ほとんどのハードウェアエンジニアはスペシャリストです。彼らはハードウェアの設計と開発の応用を熟知しており、その知識を実際の状況に適用します。つまり、現実世界の問題を解決し、ハードウェアの専門分野におけるさまざまなソリューションの費用対効果を評価し、設計したものが正しく動作することを保証します。ハードウェアアーキテクトはジェネラリストです。彼らは特定のハードウェア技術やアプローチの専門家である必要はなく、多くの技術やアプローチに精通し、特定の状況への適用可能性を判断できることが期待されます。彼らもまた、知識を実際の状況に適用しますが、たとえば独自開発のハードウェアコンポーネントと市販のハードウェアコンポーネントなど、異なるハードウェア技術を使用したさまざまなソリューションの費用対効果を評価し、システム全体がユーザーの期待どおりに動作することを保証します。

市販の既製品や既に開発済みのハードウェアコンポーネントの多くは、コスト、応答速度、スループットなどの制約条件に基づいて個別に選択できます。場合によっては、設計者はエンドシステムを単独で組み立てることができます。あるいは、コンポーネントの選択や、特定の用途向け機能の設計・構築のために、ハードウェアエンジニアの支援が必要になる場合もあります。設計者（またはエンジニア）は、安全性、セキュリティ、通信、特殊用途向けハードウェア、グラフィックス、ヒューマンファクター、テスト・評価、品質管理、RMA、インターフェース管理などの専門家の協力を得ることもできます。効果的なハードウェアアーキテクチャチームは、重要な専門分野のスペシャリストにすぐにアクセスできる体制を整えておく必要があります。

建物の設計を担当する建築家は、住人にとって快適で使いやすい建物となるよう、全体的なデザインに取り組みます。一戸建て住宅であれば建築家一人で十分な場合もありますが、斬新な高層ビルを設計する際には、詳細な問題を解決するために多くのエンジニアが必要となる場合があります。プロジェクトが大規模かつ複雑な場合は、建築の一部を構成要素として設計することもあります。つまり、集合住宅を建設する場合、集合住宅全体を担当する建築家と、建物の種類ごとに建築家を配置し、建築チームを編成するといった形になります。

大規模なハードウェアシステムには、設計者と高度なエンジニアリング能力が不可欠です。設計対象のシステムが十分に大規模かつ複雑な場合、主任ハードウェアシステム設計者は、共同設計チームのメンバーであっても、業務の一部を部下の設計者に委任することがあります。 しかし、設計者をエンジニアリング部門の監督者とみなしてはなりません。

設計者は、ハードウェア要件を、単一のハードウェアエンジニア、エンジニアリングマネージャー、または下位の設計者の担当範囲内にある主要コンポーネントまたはサブシステムに細分化する必要があります。理想的には、各ハードウェアコンポーネント/サブシステムは十分に独立したオブジェクトであり、単純なテストベッドを使用してシミュレートされた入力を供給し、出力を記録するだけで、全体から切り離された完全なコンポーネントとしてテストできます。つまり、航空交通管制システムの仕組みを知る必要はなく、そのデータ管理サブシステムを設計および構築できます。必要なのは、サブシステムが動作することが期待される制約条件を知ることだけです。

優れたアーキテクトは、システムがどれほど複雑であっても、各（サブ）システムまたはレイヤーごとに比較的シンプルで「クリーン」な概念に基づいて構築されるようにします。これは、特別なトレーニングを受けなくても、特にユーザーにとって容易に理解できるものです。アーキテクトは、各パーティションが明確に定義され、場当たり的な対応、回避策、近道、あるいは紛らわしい詳細や例外が排除されるように、最小限のルールを使用します。ユーザーのニーズが進化するにつれて（システムが運用開始されてから）、例外、特殊なケース、そして多くの「細かい規定」で埋め尽くされた概念よりも、シンプルな概念の方が後々進化させるのがはるかに容易になります。

ハードウェアアーキテクチャを階層化することは、各階層において十分にシンプルさを保ち、単一の人間が理解できる状態を維持するために重要です。階層が上がるにつれて、下位階層のシステム全体が上位階層の単純な構成要素となり、最上位階層では完全に消滅することもあります。

受け入れテストは常に設計者（アーキテクト）の主要な責任です。これは、設計者がハードウェアが当初の計画どおりであること、およびすべての下位の設計者とエンジニアがそれぞれの目標を達成したことをユーザーに証明する主要な手段です。大規模プロジェクトは、途中でユーザーが必要とする変更（例えば、問題の変化）や、ユーザーに期待される変更（例えば、コストやスケジュール上の理由）が発生するなど、動的な傾向があります。しかし、受け入れテストは常に最新の状態に保たなければなりません。受け入れテストは、最終製品がどのように動作するかをユーザーに知らせる主要な手段であり、すべての下位担当者が設計、構築、テストを行う主要な目標となります。

建築設計士はスケッチ、模型、図面を使用します。ハードウェアシステム設計士は、スケッチ、模型、プロトタイプを使用して、ユーザーやシステム設計士、エンジニア、および下位の設計士とさまざまな解決策や結果について話し合うべきです。ユーザーマニュアルの初期草稿は、特にプロトタイプと併用すると非常に貴重です。ユーザーとのコミュニケーション手段として、一連の（エンジニアリング）要件を用いることは、明確に避けるべきです。適切に記述された要件、または仕様は、弁護士にとっての法的契約書と同様に、エンジニアリング関係者にしか理解できません。