Tweet

アーキテクチャ・ジャーナル アーキテクトのソフト・スキル Joe Shirey 2009/06/01

Page1 Page2

■概要

　優秀なアーキテクトには優れた技術力が欠かせないことに異論はないでしょう。しかし、私がこれまでに会った中で最も優れたアーキテクトは優れた技術力を持っているだけではなく、周りの人と協力できる資質も持っています。

　このような “ソフト スキル” を向上させることにより、普通のアーキテクトを効率の面でその経歴上新しいレベルに引き上げることができます。この記事では、私の経験と優れたアーキテクトとの交流を基にして、アーキテクトに必要なソフト スキルと戦略を定義するために開発したフレームワークについて説明します。

■ソフト スキルを取り上げる理由

　皆さんもこれまでに、技術的な問題を解決できる優れた技術者ではあっても傲慢で鼻持ちならない性格のために周囲の人から一緒に働きたくないと思われている人間と一緒に働いたことがあることでしょう。このような技術に傾きすぎた人の中には、それ以上昇進できず、ビジネス的観点からその価値が過小評価されてしまう人もいるでしょう。彼らのキャリアが頭打ちになるのは、“人” と “ビジネス” に関するスキルが足りないからです。このようなスキルをソフト スキルと呼びます。

　Microsoft 認定アーキテクト プログラムを見れば、技術力を超えるコンピテンシーがあることに気付くでしょう。このようなコンピテンシーは、企業の大小にかかわらずフォーカス グループに見られました。これらのフォーカス グループに共通するテーマの 1 つには、ソフト スキルが深く関係していました。実際に、技術的なコンピテンシーよりもソフトなコンピテンシーが目立ちました。この観点から、ソフト スキルは、高度な技術を持った技術者と真のアーキテクトを区別するものと言えます。

　また、International Association of Software Architects (IASA) でも詳細な分析検討を行い、そのメンバーに対し、優れたアーキテクトに必要なスキルを特定する調査を行いました。IASA が特定した 5 つの基礎的なスキル領域のうち、2 つはソフト スキルに基づくものです。

　アーキテクトにとって重要なスキルを定義しようとしたときに、ある程度のソフト スキルが含まれることは明らかです。私の経験から見てもそのとおりです。私が知っている最も優れたアーキテクトは、技術的なスキルと技術以外のスキルを組み合わせることによって、実効性を高めることができます。

　効果的な技術ソリューションには、ビジネスとの連携、様々な観点の認識、コミュニケーションの 3 つの主要なソフト スキルも必要とされると考えられます (図 1)。ほとんどのアーキテクトはこれらの分野の重要性を認識していますが、プロジェクトのライフ サイクルでこれらを実際の優先事項にすることができません。この記事ではこれらの各領域について説明し、多大な労力をさらに投入しないで、これらをプロジェクトで優先できるようにする戦略を示します。

図 1: 効果的な技術ソリューションには 3 つの主要なソフト スキルが必要

■ビジネスとの連携

　どんなプロジェクトでも、ビジネスとの連携が成功の重要な要素であることを否定する人はいないでしょう。ほとんどのプロジェクトは、技術的な意思決定の大部分を行う一種の要件を示す文書か、少なくともアーキテクチャがビジネス ニーズを満たす方法を示すアーキテクチャの文書から始まります。通常、問題は意志が欠如していることではなく、戦略レベルでの連携が弱いことにあります。

　私はさまざまな役割をこなしてきましたが、多くのプロジェクトをレビューし、プロジェクトについてアーキテクトと詳細に議論する機会がありました。通常、アーキテクトはビジネス要件については議論できますが、CFO の視点からプロジェクトを説明できないアーキテクトが多いことには驚くばかりです。実際のビジネスの促進要因や、ビジネス要件に対する詳細な財務的な関わりが理解されていません。これが実際のプロジェクトの決定を促進する重要な要因です。

　私がビジネスの促進要因について言及するときは、具体的で評価可能なものを指しています。アーキテクトはプロジェクトの促進要因を "顧客満足度の向上" と表現することがよくありますが、これは具体性に欠けます。ビジネスの促進要因は、必要に応じて財務的な言葉に詰めていく必要があります。この例では、"今後 1 年間で顧客のリピート収入を 10% 増加させ、コール センターのサポート コストを 5% 削減する" など、プロジェクトに基づいてこの目標が達成可能である理由を示す詳しい説明のある目標が望ましいと言えます。このような目標はプロジェクトの真の利益を促進し、プロジェクトに必要なコストを組み立てることができます。純粋な財務的観点からは促進されないプロジェクトも一部にありますが、プロジェクトには常にビジネス上の理由が内在しています。たとえば、コンプライアンス プロジェクトの場合、投資モデルにおける純粋な利益に基づいて実施されない場合もよくあります。しかし、プロジェクトを進めなかった場合のビジネス上のリスクを理解し、それらのリスクを使用して適切なソリューションを開発することは重要です。

　実際のビジネスの促進要因を理解することにより、アーキテクトはプロジェクトのライフ サイクルで技術的な意思決定を合理的に行うことができます。多くのプロジェクトはビジネス要件に基づいているため、これらの要件は “契約” として扱われます。計画のすべてがこのような “契約” に基づいているために要件を柔軟に変更できない場合がありますが、ビジネスの状況および促進要因はプロジェクトの途中で変わることがあります。ビジネスの考え方を真に理解していれば、自分の組織のビジネスサイドにソリューション開発におけるこのような変化の影響を理解させることができます。

　2 〜 3 年前のニッチ ソフトウェア ベンダーとのプロジェクトについて思い出すことがよくあります。このプロジェクトでは、顧客は質が高く保守が容易なソリューションを構築するには、非常に大規模で複雑なプロジェクトを非現実的な時間で完了するようにと要求していました。状況について激しい議論を何回か行った結果、期限は動かせない、つまりその企業の死活問題であることがわかってきました。ソリューションがその期限に間に合わなければ、その企業は倒産するでしょう。この切迫感はソリューションのアーキテクチャを確実に促進しました ("アーキテクチャの欠如" と言えるかもしれません)。私たちはプロジェクトのスケジュールのために品質と保持性を犠牲にしました。CEO は将来この対価を払わなければならないことを認識していましたが、事業が立ち行かなくなるよりましでした。

　この例では、技術的なソリューションについては自慢できませんが、顧客の問題を解決し、ビジネスを破綻させずに操業を続けさせました。このほうがずっと難しい目標でした。また、私たちは、プロジェクトで行われるトレードオフと将来への影響を顧客に理解させる適切な手段を講じました。私たちは時間をかけてビジネスを促進する問題を完全に理解したので、短期的な戦術的役割ではなく、戦略的役割を担うようになりました。

　私は、アジャイル メソドロジはビジネスと連携する戦略であると考えます。このメソドロジによって定期的に関係者が交流し、その結果、基本的なビジネス ニーズがよく理解され連携できるようになります。アジャイル プロジェクトが常にこの連携を行うというわけではありませんが、アジャイル メソドロジによって連携がよく行われるようになります。非アジャイル メソドロジで連携できないわけではありませんが、その大部分のメソドロジではビジネスが定期的に関与することはありません。

●ビジネスとの連携に関する戦略の要約

• CEO や CFO になったつもりでプロジェクトを考えてみます。あらかじめ時間をかけてプロジェクトのビジネス促進要因を分析し、可能であれば、プロジェクトのコストと利益について実際の財務面の影響を見極めます。
• ソリューション アーキテクチャを開発する際の手がかりとして、要件ではなくビジネス促進要因を使用します。プロジェクトのライフ サイクル全体でビジネスの状況を把握し、プロジェクトでの適切な柔軟性を維持します。
• プロジェクトのライフ サイクルで、自分のメソドロジがビジネスとの連携をどのように維持しているかを評価します。必要に応じて定期的に連絡を取り、ビジネスをプロジェクトに近づけておきます。
• ソリューションが運用体制に入ったら、定義された目標を達成する能力を評価する方法を考えます。

INDEX
	［アーキテクチャ・ジャーナル］
	アーキテクトのソフト・スキル
	1．ソフト スキルを取り上げる理由／ビジネスとの連携
	2．様々な観点の認識／コミュニケーション

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）