Technology Architectロールの紹介 〜Part.2〜

はじめに

Technology Architect（以降、TA）というロールをご存じでしょうか。
こちらはアクセンチュアにおけるTAロールの紹介記事のPart.2になります。
もしまだPart.1をご覧になっていない方は、以下のリンクからまずPart.1の記事をご一読ください。

1. TAとはなにか / アクセンチュアにおけるTAの関わり方を紹介
2. TAに求められること / TAのキャリアモデル（本記事）

Part.1ではTAロールの紹介と、アクセンチュアにおける具体的な関わり方を事例ベースでお伝えしました。
Part.2では特にアクセンチュアのTAで求められていることや、若手〜ベテランのキャリアモデルについてご紹介します。

TAに求められること

アクセンチュアのTAに求められることはたくさんあるのですが、一言で言えば「プロジェクトを成功に導くこと」です。
もちろん、どのチームのどのロールの方でも、プロジェクトの成功というゴールに向けて動いているのですが、TAは特にチームを横断してアーキテクチャ方針を決め、プロジェクトを前に進めていくロールなので、成功に ”導く” という表現が当てはまると考えています。

プロジェクトを成功に導くために、アクセンチュアのTAは次の4つの力を特に大事にしています。

1. 最前線の技術力
2. 最善のアーキテクチャを描く力
3. ステークホルダーと合意までもっていく力
4. 先を読む力

1. 最前線の技術力

機能要件/非機能要件に対して適切なアーキテクチャを検討していくうえで、プログラミング言語の特性、ネットワークの理解、アルゴリズムやデザインパターンなど幅広い分野に対して知識が求められます。
さらにいえば、それぞれを知っていて、アーキテクチャ方針策定ができるだけでなく、自身がそのアーキテクチャでシステム開発を進められるレベルの深い技術力が、TAには必要です。
その技術力が、実現可能なアーキテクチャ策定に繋がり、アーキテクチャ起因の課題が後のフェーズで発覚することを未然に防ぎます。

2. 最善のアーキテクチャを描く力

最善のアーキテクチャを描くということもTAに求められることの1つです。単に技術力の幅が広くて深くても、プロジェクトを成功に導くことはできません。
例えばですが、採用したアーキテクチャが機能要件も非機能要件も満たしていたとします。
しかしそのアーキテクチャを維持するために莫大なコストがかかったとしたら、プロジェクトが成功したとはいえません。
クライアント、ひいてはその先のエンドユーザが何を望んでいるかを正しく理解したうえで、最善のアーキテクチャを描ける必要があります。

3. ステークホルダーと合意までもっていく力

最善のアーキテクチャを描けたとして、それを実現するためには、ステークホルダーに説明し、理解、意思決定をしてもらう必要があります。
ステークホルダーがTAと同等のテクノロジーに対する知識やスキルを持っているとは限らないため、納得してもらうだけのアーキテクチャ選定理由を分かりやすく説明する必要があります。
その際に批判や反対意見が出ることは自然です。
ステークホルダーの懸念点や関心ごとは、単に技術的な観点に留まらず、開発体制、今後のビジネス戦略、コスト、過去の失敗例など多岐に渡ります。
ステークホルダーの目線に立って説明をすることで、アーキテクチャに納得してもらい、プロジェクトを推進することができます。
TAと聞くと技術に長けたメンバという印象があるかもしれませんが、たとえ素晴らしいアーキテクチャを描けたとしても、それをステークホルダーに伝えて意思決定してもらわなければそのアーキテクチャには価値がないので、伝える力というのもTAに求められることの1つです。

4. 先を読む力

アプリ/インフラ/開発/運用などシステムにまつわる全体を見通し、前もってプロジェクト推進におけるリスクを想像できる、先を読む力も大切です。
TAによっては、この力が一番大事という人もいます。
例えば、ステークホルダーが多くて皆の認識を合わせる詰めができておらず、結果的に仕様が曖昧になってしまうことがあります。
このような場合、後工程になるとリカバリーがより手間になり、プロジェクト推進の課題となりえます。
また、アーキテクチャは決定したものの実際のシステム開発を行う上でガイドラインやライブラリなどの準備ができていないと、開発の出だしでつまづいたり品質課題を招いてしまいます。
TAとしての嗅覚を研ぎ澄まし、この先どうなるかを考え、怪しいと感じるところにはいち早く手を打つことが重要です。

TAのキャリアモデル

アクセンチュアにおけるTAのキャリアについて、ここでは入社して

• 5年以内の若手
• 5〜10年くらいでいくつもプロジェクトを経験した中堅
• そしてプロジェクトでTAの責任者としてリードするベテラン

の3つのキャリアモデルについてご紹介します。
※記載の年数はあくまで参考としてとらえてください。

若手TA🍀

若手メンバーはまずはキャリアの核となる技術力を伸ばしていきます。
自らの得意とする技術領域を見つけ、例えば採用するクラウドサービス、通信IF（インタフェース）やプロトコルなどの選定といった、システムを構成する一領域のアーキテクチャを検討します。
プロジェクト背景や求められること、各選定案のメリット／デメリットと何を優先すべきか、様々な観点から検討し、他のTAからのレビューを受けて方式を決定します。
方式決定のために、若手でもクライアントや他の会社のエンジニアと直接話をしていく場面もあります。
方式決定後は選定したアーキテクチャ案でシステム開発が行えるよう、共通ライブラリの開発、開発ガイドの整備、クラウドサービスの構築などを行います。

また、自分以外のTAが検討しているアーキテクチャについてもしっかりキャッチアップし、「どのような考え方でアーキテクチャを選定しようとしているのか」「自分の考え方と齟齬はないのか」といったことを把握することもキャリアアップにおいて重要です。
全体のアーキテクチャがどのような構成になるのか把握し、積極的に他チームとのコミュニケーションを行いプロジェクトを推進します。
ただアーキテクチャを検討するだけでなく、調査や検証のために簡易的な実装したり、より説得力のある説明や提案のために他のTAと一緒にPoC（Proof of Concept）を行う、といった場面もあります。

中堅TA🌴

中堅メンバーはTAとしての技術力、アーキテクチャ検討力に加えてマネジメントの力も求められます。
プロジェクト全体のいわゆるプロジェクト・マネジメントではなく、TAのチームとしてのマネジメントを担い、「決めるべきアーキテクチャの対象選定」「チーム内のタスク割り振り」「若手メンバーからあがってくるアーキテクチャ案のレビューやコードレビュー」などが挙げられます。

また、自チームだけではなく他の開発チームの動きや開発スケジュールを把握し、開発に影響が出ないよういつまでにどの領域のアーキテクチャを決めてライブラリなどの整備を行う必要があるか舵取りをします。
他にも対向先となるシステムとのIF決定など、まさにTAチームの顔としてプロジェクトを牽引します。

あるいはマネジメントよりも、得意とする領域のエキスパート（SME）としてプロジェクトで難易度の高い技術領域や課題、アーキテクチャ検討をカバーしていくといったキャリアもあります。

ベテランTA🌲

ベテランメンバーはプロジェクト全体のTAの代表者・責任者としての振る舞いが求められます。
技術的な観点だけでなくビジネスやクライアントの視点にたち、

• 開発アーキテクチャ
• 実行アーキテクチャ
• 基盤アーキテクチャ
• データアーキテクチャ
• セキュリティ
• テストアーキテクチャ

といったシステムや開発を支える様々なアーキテクチャ領域全体を把握し、レビューと決定を行います。
必要に応じてクライアントのステークホルダーやCXOと会話し、今回採用しようとしているアーキテクチャの優位性や技術ポイント、いかにビジネスへ貢献できるかなどを説明・提案を行います。 加えてプロジェクト・マネジメント面においても、プロジェクトマネージャやPMOと連携しながらTAというロールにおいて様々なプロジェクト課題に対応します。

また、ベテランメンバーはプロジェクトだけでなく、TAの組織としてTAロールを担えるメンバーをいかに増やし、底上げしていくか、組織的な課題や活動にも積極的に参加することが求められます。
※この記事もその一環ですね！

おわりに

全2回にわたってTechnology Architectがどんなロールかご紹介しました。

繰り返しますが、要件を満たしたシステムを設計し、そして実現できるTAの需要は高く、技術力だけでなく様々な力が培われ自身のキャリアにおいてスキルアップや成長に繋がります。とても刺激的なロールなので少しでも興味を持っていただけたら嬉しいです。

もしアクセンチュアでTAとして働くことに興味をお持ちでしたら、下記から是非ご応募ください。
https://www.accenture.com/jp-ja/careers/jobdetails?id=R00004278_ja

他の職種に興味がある方は、下記をご覧ください。