製品志向のエンジニア (Japanese Edition)

第9章 プロダクトアーキテクチャ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

ソフトウェアにおいて、意味のある要件が存在するケースは稀だ。仮に存在したとしても、成功の唯一の尺度は、顧客が抱える問題の認識が変化する中で、我々の解決策がそれを解決できるかどうかだけである。

ジェフ・アトウッド

機能要件とは、ユーザが望むことを実現する製品の機能性目標の集合体だ（ ）。第8章では機能要件の達成について論じたが、当時はそのように呼んでいなかった。

もしそれだけを考えれば、ソフトウェア版のポテムキン村——見た目は良いが機能しないインタフェース——になってしまう。だから非機能要件（NFR）を考える際には、エンジニアが設計対象とする主要な属性——コスト、拡張性、遅延、スループット、データの一貫性、弾力性、可用性——を考慮する。プライバシーとセキュリティも忘れてはならないが、ここでは扱わない。

NFRは目的達成の手段であって、それ自体がユーザの目標を実現するものではない。時には、機能していない時にだけユーザが気づく要素でもある。

このトピックが好きなのは、本書で最もエンジニアリング的な主題でありながら、プロダクト思考の利点も受けられるからだ。これらの要素を考慮したシステムアーキテクチャの設計は、ユーザ中心とシステム中心の思考を純粋に統合したものであり、プロダクトマネージャーや他の役割が設計支援を最も困難に感じる領域でもある。

この統合は「 プロダクトアーキテクチャ」と呼ばれることもある。ユーザとビジネス制約のコンテキストにおけるシステム設計だ。それを適切に行うために必要な思考の全範囲を示している用語が気に入っている。

この章では、システム設計に編集者的なプロダクト思考を適用する方法を示す。

まず、編集者の考え方をプロダクトアーキテクチャに取り入れるための基礎を築く。

次に、通常のケーススタディに移行し、以降のセクションのフレームを提示する。

次に、 の製品思考を2種類のNFR（非機能要件）に適用する。

第一のカテゴリーのNFRは、遅延、可用性、データの一貫性といった要素を通じて、迅速で信頼性の高いユーザ体験を提供する。

第二のカテゴリーは、拡張性要因だ。スループットや分離性など、多数のユーザが同時にシステムを利用する場合にのみ影響する要素である。

最後に、コンプライアンス、セキュリティ、プライバシーといったデータガバナンス要件という重要なカテゴリーは省略したが、これらもプロダクト思考の力を示すものである。

最後に、顧客がシステムのどの特性に依存できるかを理解してもらうためのコミュニケーション方法について説明する。

プロダクトアーキテクチャの基礎

プロダクトアーキテクチャの はインタラクションデザインと関連している。内部抽象化はそれ自体がミニチュアプロダクトであり、ユースケースや3つの規則、反復開発など、第8章で学んだ教訓のほとんどが適用されるからだ。

しかし製品アーキテクチャは、非機能要件が厄介なため独特の難しさがある。それらは数多く存在し、満たすのが困難な場合が多く、つまり通常はそれら全てに対処する時間と資金がない。さらに悪いことに、たとえ無限の時間があっても、それらはしばしば相互にトレードオフの関係にある——堅牢なデータレプリケーションが遅延増加を招くことや、セキュリティ上の障壁が可用性を阻害することを考えよ。

したがって、製品アーキテクチャには編集的な視点が必要だ。ユーザが本当に重視しているのは何か？ ...