💻

SoftwareArchitectを和訳してみた

2021/05/05に公開

architect

roadmap

tech

「SWアーキテクトロードマップ」と検索して出てきた情報の和訳。

コミットIDは44770ae

ソフトウェアアーキテクトとは？

ソフトウェアアーキテクトとは、高レベルの設計を選択し、ソフトウェアのコーディング基準、ツール、プラットフォームなどの技術基準を指示するソフトウェアの専門家である。(出典：Wikipedia: ソフトウェアアーキテクト)
ソフトウェア・アーキテクチャとは、構成要素、それらの相互関係、環境との関係、システムの設計と進化を決定する原則によって表現されるシステムの基本的な構成である。(出典：Handbook of Software Architecture)

アーキテクチャのレベル

アーキテクチャは、抽象度の高いいくつかの「レベル」で行うことができる。このレベルは、必要なスキルの重要性に影響する。多くの分類が考えられるが、個人的に好きな分類は以下の3つだ。

アプリケーションレベル：アーキテクチャの最下位レベル。1つのアプリケーションに焦点を当てる。非常に詳細で低レベルな設計。コミュニケーションは通常、1つの開発チーム内で行われる。
ソリューションレベル：アーキテクチャの中間レベル。ビジネスニーズを満たす1つまたは複数のアプリケーションに焦点を当てる（ビジネスソリューション）。高いレベルの設計もあるが、主に低レベルの設計である。コミュニケーションは複数の開発チーム間で行われる。
エンタープライズレベル：アーキテクチャの最上位レベル。複数のソリューションに焦点を当てる。ハイレベルで抽象的なデザインで、ソリューションアーキテクトやアプリケーションアーキテクトが詳細を決定する必要がある。コミュニケーションは組織全体で行われる。

時にアーキテクトは、異なるステークホルダー間の「橋渡し役」とも考えらる。3つの例を挙げる。

水平：ビジネスと開発者、あるいは異なる開発チーム間のコミュニケーションを橋渡しする。
垂直：開発者とマネージャーの間のコミュニケーションを橋渡しする。
技術：異なる技術やアプリケーションを相互に統合する。

典型的な活動内容

アーキテクトに必要なスキルを理解するためには、まず典型的な活動を理解する必要がある。個人的な見解では、最重要な活動は以下のリストの通り。

開発技術とプラットフォームの定義と決定
コーディング標準、ツール、レビュープロセス、テストアプローチなどの開発標準の定義
ビジネス要件の特定と理解のサポート
要件に基づいたシステム設計と意思決定
アーキテクチャの定義、設計、決定事項の文書化と伝達
定義されたパターンやコーディング標準が適切に実装されているかどうかなど、アーキテクチャやコードのチェックとレビュー
他のアーキテクトやステークホルダーとのコラボレーション
開発者へのコーチングとコンサルティング
高次設計の詳細化と低次設計への落とし込み

注：特にアジャイルソフトウェア開発に適用される場合、アーキテクチャは継続的な活動である。そのため、これらの活動は何度も繰り返し行われる。

重要なスキル

これらの活動をサポートするためには、特定のスキルが必要である。経験や本、議論などから、ソフトウェアアーキテクトが持つべきスキルを以下の10個に集約することができる。

設計能力
決断力
単純化
コーディング能力
ドキュメント作成能力
コミュニケーション力
見積もり能力
バランス感覚
相談と助言
マーケティング力

(1)設計

良い設計とは何か？これはおそらく最も重要で難しい問いである。理論と実践を区別しよう。経験上、両方の要素を兼ね備えていることが価値がある。まずは理論について。

基本的なデザインパターンを知る：パターンは、アーキテクトが保守可能なシステムを開発するために必要な最も重要なツールの一つだ。パターンを使えば、デザインを再利用して、一般的な問題を実績のあるソリューションで解決することができる。John Vlissides、Ralph Johnson、Richard Helm、Erich Gammaによって書かれた「Design Patterns: Elements of Reusable Object-Oriented Software」は、ソフトウェア開発に携わるすべての人にとっての必読書だ。これらのパターンは20年以上前に発表されたものだが、今でも最新のソフトウェアアーキテクチャの基礎となっている。例えば、本書で紹介されているMVC（Model-View-Controller）パターンは、多くの分野で応用されており、MVVM（Model-View-ViewModel）などの新しいパターンの基礎にもなっている。
パターンやアンチパターンをより深く掘り下げる：基本的なGang-of-Fourパターンをすべて知っているのであれば、さらに多くのソフトウェアデザインパターンで知識を広げたり、興味のある分野をより深く掘り下げてみよう。アプリケーション統合に関するおすすめの本のひとつに、Gregor Hohpe著の『Enterprise Integration Patterns』がありる。この本は、2つのアプリケーションがデータを交換する必要があるとき、それがレガシーシステムからの昔ながらのファイル交換であろうと、最新のマイクロサービスアーキテクチャであろうと、さまざまな分野で応用できる。
品質指標を知る：アーキテクチャを定義したら終わりではない。ガイドラインやコーディングスタンダードが定義され、適用され、管理されるのには理由がある。それは、品質と非機能の要求のためだ。保守性、信頼性、適応性、安全性、テスト可能性、拡張性、使用可能性などを備えたシステムを構築したいはずだ。そして、これらの品質属性をすべて達成するための1つの鍵は、優れたアーキテクチャの研究成果を適用することだ。品質対策については、Wikipediaで詳しく紹介されている。

理論は重要だ。実践は同じくらい、あるいはそれ以上に重要だ。象牙の塔のようなアーキテクトになりたくないのであれば。

さまざまな技術スタックを試し、理解する：より良いアーキテクトになりたいなら、これは最重要な活動であろう。新しい技術スタックを試して、その長所と短所を学ぶ。異なる技術や新しい技術には、異なる設計面やパターンがある。抽象的なスライドをめくっているだけでは何も学べないことがほとんどだが、自分で試してみて、痛みや安堵を感じることが大切だ。アーキテクトは、幅広い知識だけでなく、特定の分野では深い知識も持っているべきだ。すべての技術スタックをマスターすることが重要なのではなく、自分の分野で最も重要な技術をしっかりと理解することが大切なのだ。また、自分の専門外の技術も試そう。例えば、SAP R/3に精通しているなら、JavaScriptも試してみるべきだし、その逆も然り。それでも、SAP S/4 Hanaの最新の進歩については、両者ともに驚くはずだ。例えば、自分で試してみたり、openSAPのコースを無料で受講してみたり。好奇心を持って、新しいことに挑戦しよう。何年か前に嫌だと思ったことも試してみよう。
応用されたパターンを分析し、理解する：Angularのような最新のフレームワークを見てみよう。例えばObservablesのように、多くのパターンを実際に学ぶことができる。フレームワークでどのように適用されているのか、なぜそれが行われたのかを理解するようにしよう。そして、もしあなたが本当に熱心であれば、コードをより深く調べて、それがどのように実装されているかを理解することができるだろう。
好奇心を持ってユーザーグループに参加する

(2)決断

アーキテクトは、意思決定を行い、プロジェクトや組織全体を正しい方向に導く能力が必要だ。

何が重要なのかを知る：重要でない決定や活動で時間を無駄にしない。重要なことを学ぶ。私の知る限り、これらの情報を掲載した本はない。個人的に気に入っているのは、何かが重要かどうかを評価する際に通常考慮する、以下の2つの特性だ。
- 構想の一貫性：1つの方法でやると決めたら、たとえ別の方法でやったほうがいい場合でも、それを貫く。通常、これは全体のコンセプトをよりわかりやすくし、理解しやすく、メンテナンスを容易にする。
- 統一性：例えば、命名規則を定義して適用する場合、大文字か小文字かではなく、どこでも同じように適用されることが重要だ。
優先度付け：ある決定は非常に重要だ。早い段階で決断しないと、回避策が構築されてしまい、後で削除できなくなったり、メンテナンスの悪夢となったりする。さらに悪いことには、決断がなされるまで開発者が作業を中断してしまうこともある。このような状況では、何も決めないよりも、「悪い」決断をした方が良い場合もある。しかし、このような状況に陥る前に、今後の決定事項に優先順位をつけることを検討しよう。それにはさまざまな方法がある。アジャイルソフトウェア開発で広く使われているWSJF（Weighted Shortest Job First）モデルを見てみることを勧める。特に、タイムクリティカリティとリスクリダクションは、アーキテクチャ決定の優先順位を見積もる上で重要な指標だ。
自分の力量を知る：自分の力量に見合わないことを決めてはいけない。これは非常に重要なことで、考慮しなければアーキテクトとしてのあなたの立場が大きく損なわれる可能性がある。これを避けるためには、自分にはどのような責任があり、何が自分の役割の一部なのかを同僚と明確にしよう。もし、複数のアーキテクトがいる場合は、自分が現在配置されているアーキテクトのレベルを尊重すべきだ。下位のアーキテクトであれば、決定ではなく、上位のアーキテクチャーに対する提案をするのが良いだろう。さらに、重要な決定は常に同僚と確認することを勧める。
複数の選択肢を評価する：決断の際には、常に複数の選択肢を用意しておこう。私が関わったほとんどのケースでは、複数の可能な（良い）選択肢があった。1つの選択肢だけを選ぶことは、2つの点でよくない。1つは、自分の仕事をきちんとしていないと思われること、もう1つは、適切な意思決定ができなくなることだ。指標を定義することで、ライセンスコストや成熟度など、直感ではなく事実に基づいて選択肢を比較することができる。これは通常、より良い、より持続可能な決定につながる。さらに、さまざまな利害関係者に意思決定をアピールすることも容易になる。また、選択肢を適切に評価していないと、議論になったときに議論の余地がなくなる可能性がある。

(3)単純化

問題解決の原則である「オッカムの剃刀」を念頭に置いて、「シンプルであることを好む」。私はこの原則を次のように解釈している。問題を解決するための前提条件が多すぎると、その解決策はおそらく間違ったものになるか、不必要に複雑な解決策になってしまう。良い解決策を導き出すためには、前提条件を減らす（単純化する）必要がある。

ソリューションを揺する：解決策をシンプルにするためには、多くの場合、解決策を「シェイク」して、異なる位置から見ることが有効だ。トップダウンで考え、もう一度ボトムアップで考えて、ソリューションを形成してみよう。データの流れやプロセスがある場合は、まず左から右に考え、もう一度右から左に考える。次のような質問をしてみてよう。"完璧な世界では、あなたのソリューションはどうなるのか？あるいは、"X社／X人は何をするだろうか？"といった質問をする。（Xは競合他社ではなく、GAFA（Google、Apple、Facebook、Amazon）企業のひとつなど）。どちらの質問も、「オッカムの剃刀」で提案されているように、仮定を減らすことを余儀なくされる。
一歩引いてみる：長い時間をかけて議論した結果、非常に複雑な落書きができあがることがある。決して最終的な結果として見てはいけない。一歩下がる。もう一度、全体像（抽象レベル）を見てみよう。それはまだ意味をなしているだろうか？そして、もう一度抽象的なレベルで検討し、リファクタリングを行う。時には議論を中断して、翌日に続きをするのもいいだろう。少なくとも、私の脳が処理し、より良い、よりエレガントな、よりシンプルなソリューションを思いつくためには、ある程度の時間が必要なのだ。
分割統治：問題を小さく分割して単純化する。そして、それらを独立して解く。その後、その小さなピースが一致するかどうかを検証する。一歩下がって、全体像を見てみよう。
リファクタリングは悪ではない：より良いアイデアが見つからない場合、より複雑なソリューションから始めることは全く問題ない。そのソリューションが問題を起こしている場合は、後でソリューションを再考し、学んだことを応用することができる。リファクタリングは悪ではない。しかし、リファクタリングを始める前に、(1)システムの適切な機能性を保証する十分な自動テストを実施すること、(2)ステークホルダーからの賛同を得ること、を念頭に置こう。リファクタリングについて詳しく知りたい方は、Martin Fowlerの「Refactoring, Improving the Design of Existing Code」をお勧めする。

(4)コーディング

アーキテクチャの最も抽象的なレベルであるエンタープライズアーキテクトであっても、開発者が日常的に行っていることを知っておく必要がある。そして、それがどのように行われているかを理解していないと、2つの大きな問題に直面することになる。

開発者があなたの言うことを受け入れない。
開発者の課題やニーズを理解できない。

サイドプロジェクトを持つ：新しい技術やツールを試して、現在および将来の開発のあり方を探ることが目的だ。経験とは、観察、感情、仮説を組み合わせたものだ（"Experience and Knowledge Management in Software Engineering" by Kurt Schneider）。チュートリアルや賛否両論の本を読むのは良いことだ。しかし、それは単なる「本の知識」に過ぎない。自分で試してみて初めて、感情を経験し、なぜそれが良いのか悪いのかについての仮説を構築することができる。そして、その技術を長く使えば使うほど、その仮説は良くなってゆく。そうすれば、日々の仕事でより良い判断ができるようになる。私がプログラミングを始めた頃は、コード補完機能もなく、開発をスピードアップするためのユーティリティー・ライブラリをいくつか持っていただけだった。このような背景があれば、明らかに今日の私は間違った判断をしていただろう。今日、私たちは膨大な数のプログラミング言語、フレームワーク、ツール、プロセス、プラクティスを持っている。ある程度の経験と主要なトレンドの大まかな概要があれば、会話に参加し、開発を正しい方向に導くことができる。
試すのに適したものを見つけよ：すべてを試すことはできない。単純に不可能なのだ。もっと構造的なアプローチが必要だ。私が最近見つけた情報源のひとつが、ThoughtWorks社のTechnology Radarだ。ThoughtWorks社は、テクノロジー、ツール、プラットフォーム、言語、フレームワークを4つのカテゴリーに分類してる。
- 採用「企業での使用に耐えるという強い感覚」
- お試し「企業は、リスクを扱える1つのプロジェクトで試すべき」
- 評価「企業への影響を探る」
- 待ち「慎重に扱う」
  この分類のおかげで、新しいものの概要とその準備状況を把握し、次にどのトレンドを探せばよいかをより適切に評価することができる。

(5) ドキュメント

アーキテクチャのドキュメントは、重要なものとそうでないものがある。重要なドキュメントとは、例えば、アーキテクチャの決定事項やコードのガイドラインなどだ。初期のドキュメントは、コーディングを開始する前に必要になることが多く、継続的に改善する必要がある。その他のドキュメントは、コードとして自動的に生成することができ、UMLクラス図などのドキュメントにもなる。

きれいなコード：コードは正しく書かれていれば、最高のドキュメントになります。良いアーキテクトは、良いコードと悪いコードを見分けることができるはずです。良いコードと悪いコードについて詳しく知るためには、ロバート・C・マーティンの「Clean Code」という本がとても役に立ちます。
可能な限りドキュメントを生成する：システムは急速に変化しており、ドキュメントを更新することは困難だ。それがAPIに関するものであれ、CMDB（構成管理データベース）形式のシステムランドスケープであれ。基盤となる情報の変化が速すぎて、対応するドキュメントを手作業で最新の状態に保つことができないことがよくある。例：APIの場合、モデル・ドリブンであれば定義ファイルに基づいて、あるいはソースコードから直接、ドキュメントを自動生成することができる。SwaggerやRAMLなどのツールがありますので、それらを利用してみてはどうだろうか。
必要なだけ、可能な限り少なく：意思決定書など、文書化が必要なものは、一度に一つのことだけに集中し、その一つのことに必要な情報だけを記載するようにしよう。膨大な量の文書は、読むのも理解するのも大変だ。追加情報は付録に格納するべきだ。特に意思決定のための論文では、大量の論拠を並べるのではなく、説得力のあるストーリーを語ることがより重要だ。そうすれば、あなたも、それを読まなければならない同僚も、多くの時間を節約することができる。あなたが過去に作成したドキュメント（ソースコード、モデル、ディシジョンペーパーなど）を見て、次のような質問をしてみよう。"理解するために必要な情報がすべて含まれているか」「どの情報が本当に必要で、どの情報が省略できるか」「ドキュメントに赤線はあるか」。
アーキテクチャ・フレームワークについて学ぶ：この点は、他のすべての「技術的」なポイントにも当てはまると思います。TOGAFやZachmannのようなフレームワークは、ドキュメント化に重きを置いた「ツール」を提供していますが、その付加価値はドキュメント化に限られたものではないので、ここで取り上げた。このようなフレームワークの認定を受けることで、より体系的にアーキテクチャに取り組むことができるようになる。

(6) 伝える

私の観察によると、これは最も過小評価されているスキルのひとつだ。設計に優れていても、自分の考えを伝えることができなければ、その考えはインパクトが弱くなり、成功しない可能性が高い。

自分の考えを伝える方法を学ぶ：ボードやフリップチャートを使って共同作業をする場合、自分や仲間の考えを構成するためには、適切な使い方を知ることが不可欠だ。「UZMO - Thinking With Your Pen」という本は、この分野のスキルを高めるための良いリソースだと思う。アーキテクトは通常、会議に参加するだけではなく、会議を推進したり、司会をしたりしなければならない。
大人数のグループで講演する：少人数でも大人数でも、自分のアイデアを発表することは可能なはずだ。苦手だと感じる人は、親友に発表してみよう。グループを徐々に大きくしていく。これは、実際にやってみて、自分の居心地の良い場所を離れることでしか学べないことだ。このプロセスには時間がかかるかもしれないが、自分自身に忍耐強くいよう。
適切なコミュニケーションのレベルを見つける：ステークホルダーによって関心や見解が異なる。そのため、それぞれのレベルに合わせて対応する必要がある。コミュニケーションをとる前に、一歩下がって、共有したい情報が、抽象度、内容、目標、動機などについて、適切なレベルにあるかどうかを確認しよう。例を挙げよう。開発者は通常、ソリューションの非常に細かい部分に興味があるが、マネージャーはどのオプションが最もコストを削減できるかを知りたがる。
頻繁にコミュニケーションをとる：優れたアーキテクチャも、誰も知らなければ意味がない。目標とするアーキテクチャとその背景にある考えを、定期的に、そしてあらゆる組織レベルで配布しよう。開発者、アーキテクト、マネージャーとのミーティングを予定し、望ましい、あるいは定義された方法を示そう。
透明であること：定期的なコミュニケーションは、透明性の欠如を部分的にしか緩和しない。決定の背後にある理由を透明化する必要がある。特に、人々が意思決定プロセスに関与していない場合、意思決定とその根拠を理解し、それに従うことは困難だ。
プレゼンテーションを行う際には、常に準備しよう：常に誰かが質問をしているので、すぐに正しい答えを出したいものだ。最も重要なスライドをまとめておき、それを見せて説明できるようにしておこう。そうすれば、時間の節約にもなりますし、自分自身の安心感にもつながる。

(7)見積もりと評価

プロジェクトマネジメントの基本原則を知る：アーキテクトやリードデベロッパーとして、自分のアイデアを実現するための見積もりを求められることがよくある。どれくらいの期間、どれくらいの費用、どれくらいの人数、どのようなスキル、などなど。もちろん、新しいツールやフレームワークの導入を計画しているのであれば、このような「管理」に関する質問に答えられるようにしておく必要がある。最初は、数日、数ヶ月、数年といった大まかな見積もりを出すことができるはずだ。また、忘れてはならないのは、導入するだけではなく、要求工学、テスト、バグ修正など、考慮すべき活動があるということだ。そのため、ソフトウェア開発プロセスで行われる活動を知っておく必要がある。より良い見積もりを得るために応用できることの一つは、過去のデータを使用し、そこから予測を導き出すことだ。過去のデータがない場合は、Barry W. BoehmのCOCOMOのようなアプローチもある。アジャイルプロジェクトに参加する場合は、適切な見積もりと計画の立て方を学ぼう。Mike Cohn氏の著書「Agile Estimating and Planning」は、この分野の概要をしっかりと説明している。
”未知”のアーキテクチャを評価する：アーキテクトとして、現在または将来のコンテキストに対するアーキテクチャーの適合性を評価することもできなければならない。これは簡単なことではないが、すべてのアーキテクチャに共通する一連の質問を用意しておくことで、その準備をすることができる。また、アーキテクチャだけでなく、システムの管理方法についても、品質に関する洞察を得ることができるからだ。常にいくつかの質問を用意して、すぐに使えるようにしておくことを勧める。一般的な質問のいくつかのアイデアを示す。
1. デザインプラクティス：そのアーキテクチャはどのパターンに従っているか？それらは結果的に正しく使われているか？デザインはレッドラインに沿っているか、それとも無秩序な成長があるか？明確な構造と関心事の分離があるか？
2. 開発の実践：コードのガイドラインが整備され、遵守されているか？コードはどのようにバージョン管理されているか？デプロイメントの方法は？
3. 品質保証：テスト自動化の範囲は？静的コード解析が実施され、良い結果が出ているか？ピアレビューは行われているか？
4. セキュリティ：どのようなセキュリティコンセプトを持っているか？内蔵されたセキュリティ？侵入テストや自動セキュリティ分析ツールが導入され、定期的に使用されているか？

(8)

品質には代償がつきもの：先ほど、品質と非機能要件の話をしたが、これには理由がある。アーキテクチャをやりすぎると、コストが上がり、おそらく開発スピードも落ちるでろう。アーキテクチャと機能要件のバランスをとる必要がある。過剰なエンジニアリングは避けるべきだ。
矛盾した目標を解決する：矛盾した目標の典型的な例は、短期的な目標と長期的な目標だ。プロジェクトでは、最もシンプルなソリューションを構築する傾向があるが、アーキテクトは長期的なビジョンを念頭に置いている。多くの場合、シンプルなソリューションは長期的なソリューションに適合せず、後になって捨てられるリスクがある（サンクコスト）。誤った方向への実装を避けるためには、2つのことを考慮する必要がある。
1. 開発者とビジネスは、ソリューションを適応させるために、長期的なビジョンとその利点を理解する必要がある。
2. 予算を担当するマネージャーは、財務的な影響を理解するために参加する必要がある。長期ビジョンの100％を直接実現する必要はないが、開発されたピースはそれにフィットするものでなければならない。
コンフリクトマネジメント：アーキテクトは、異なる背景を持つ複数のグループの間を取り持つことが多い。そのため、さまざまなレベルのコミュニケーションにおいて対立が生じることがある。長期的かつ戦略的な目標を反映したバランスの取れた解決策を見つけるために、対立を克服する手助けをするのが建築家の役割であることが多いのだ。コミュニケーション理論に関する私の出発点は、シュルツ・フォン・トゥーンの「4つの耳のモデル」だ。このモデルに基づいて、多くのことが示されたり、差し引かれたりします。しかし、この理論には実践が必要であり、それはコミュニケーション・セミナーで経験する必要がある。

(9) 相談と指導

コンサルティングやコーチングに関しては、積極的に行動することが一番の近道だろう。聞かれてからでは遅いことが多いのだ。また、建築現場での後始末は、避けたいものだ。数週間後、数ヶ月後、あるいは数年後をどうにかして予測し、次のステップに向けて自分自身と組織を準備する必要がある。

ビジョンを持つ：プロジェクトに参加する場合、それが伝統的なウォーターフォールのようなアプローチであれ、アジャイルであれ、常に達成したい中長期的な目標のビジョンを持つ必要がある。これは詳細なコンセプトではなく、みんなが働けることに向けたロードマップのようなものだ。一度にすべてを達成することはできないので（それは旅のようなものです）、私は成熟度モデルを使うことを好む。成熟度モデルは、消費しやすい明確な構造を持ち、いつでも進捗状況を把握することができる。私は、開発手法や継続的なデリバリーなど、さまざまな側面で異なるモデルを使用している。成熟度モデルの各レベルには、達成したかどうかを簡単に測定できるように、SMART基準に従った明確な要件がある。私が見つけた一つの良い例は、継続的なデリバリーについてだ。
コミュニティ・オブ・プラクティス（CoP）を構築する：共通の関心を持つグループの間で経験や知識を交換することは、アイデアの普及やアプローチの標準化に役立つ。例えば、JavaScriptの開発者とアーキテクトを3ヶ月に1度くらいの頻度で1つの部屋に集め、過去と現在の課題とその取り組み方、新しい方法論やアプローチについて話し合うことができる。アーキテクトはビジョンを共有し、議論し、調整することができ、開発者は経験を共有し、仲間から学ぶことができる。このようなラウンドは、企業にとってはもちろん、個人にとっても、より強力なネットワークを構築し、アイデアを分散させることができるので、非常に有益だ。SAFeフレームワークのCommunities of Practiceでは、アジャイル環境におけるCoPのコンセプトについて説明している。
オープンドアセッションの実施：誤解や曖昧さの原因の一つは、コミュニケーションの不足だ。毎週30分など、一定の時間を区切って、仲間とホットな話題を交換しよう。このセッションにはアジェンダはなく、何でも話し合えます。些細なことはその場で解決するようにしよう。複雑なトピックについてはフォローアップを予定する。

(10) マーケティング

あなたのアイデアは素晴らしく、それをうまく伝えているのに、誰もついてこようとしない？それは、あなたにマーケティングスキルが欠けているからだ。

動機付けと説得：企業はどのようにして顧客に製品の購入を説得するのだろうか？製品の価値や利点を示すのだ。とは言っても、ただの箇条書きではない。きれいにまとめて、できるだけ簡単に理解できるようにしよう。
1. プロトタイプ：あなたのアイデアのプロトタイプを見せよう。プロトタイプを作るためのツールはたくさんある。SAPが好きな企業であれば、build.meをチェックしてみよう。見栄えがよく、クリックしやすいUI5アプリを素早く簡単に作成できる。
2. ビデオを見せる：「退屈なスライド」の代わりに、アイデアや少なくとも方向性を示すビデオを見せることもできる。ただし、マーケティングをやりすぎないようにしよう。長期的にはコンテンツが王様です。あなたの言葉が実現しなければ、長期的にはあなたの評判を落とすことになる。
自分のアイデアのために戦い、粘り強く努力する：人は、あなたのアイデアを好まないこともあれば、ただ単に面倒くさがって従わないこともある。自分のアイデアに確信を持っているのであれば、継続的に追求し、「戦う」べきだ。これは時に必要なことだ。長期的な目標を持つアーキテクチャの決定は、しばしば最も簡単なものではない。開発者は、開発がより複雑になるため、このような決定を好まなず、マネージャーは、短期的にはよりコストがかかるために好まないのだ。そのため、粘り強く交渉することがあなたの仕事だ。
味方を見つける：一人で自分の考えを確立したり、強制したりするのは難しいし、不可能な場合もある。説得力のあるサポートをしてくれる仲間を探すようにしよう。自分のネットワークを利用する。まだネットワークを持っていない場合は、今すぐ構築を始めよう。まず、自分のアイデアを（オープンマインドな）仲間に話すことから始めてみよう。彼らがそのアイデアを気に入ってくれれば、あるいは少なくともその一部を気に入ってくれれば、他の人に尋ねられたときにあなたのアイデアを支持してくれる可能性がある（「Xのアイデアは面白かったよ」）。もし彼らが気に入らなければ、その理由を聞いてみよう。何か見落としているのではないか？あるいは、あなたの話に十分な説得力がないのか？次のステップは、決定権を持つ味方を見つけることだ。オープンマインドな議論を求めよう。議論を恐れているのであれば、時には自分の居心地の良い場所を離れることも必要だということを覚えておこう。
繰り返すと信じる: "ある意見に繰り返し触れることで、たとえその意見の発信源が一人であっても、その意見がより広く浸透していると人々が信じるようになるという研究結果がある。"(出典：The Financial Brand) 少ないメッセージを頻繁に発信すれば、より簡単に人を納得させることができる。しかし、注意が必要だ。私の見解では、このような戦略は、お粗末なマーケティング・トリックとして裏目に出る可能性があるので、賢く使うべきだ。

アーキテクトの技術ロードマップ

ソリューションアーキテクトの分類

お勧めの書籍

Refactoring. Improving the Design of Existing Code by Martin Fowler
Enterprise Integration Patterns written by Gregor Hohpe
Design Patterns: Elements of Reusable Object-Oriented Software by John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma
Experience and Knowledge Management in Software Engineering by Kurt Schneider
Clean Code by Robert C. Martin
UZMO — Thinking With Your Pen
Agile Estimating and Planning by Mike Cohn