原文: Iasa global HP掲載記事
日本語訳について：英語原文のDeeple翻訳を行い、Iasaの文脈と背景から一部捕捉、訳註を付け加えました。出来るだけ原文の意図を反映する様努めました。
今、私たちの専門的な職業には多くの恐れと不確実性がありますが、それは当然のことです。過去10年から15年の間に行われたアーキテクチャの実践、特にエンタープライズ・アーキテクチャは死も同然でした。私の観察では、アーキテクチャは実際には活動しておらず、まるでゾンビのように人の脳を探して組織をうろついていたのだと確信しています。"エンタープライズ・アーキテクチャー”とEAのガバナンス思考、そして場合によってはビジネス・アーキテクチャーやアジャイル・トランスフォーメーションからの発想が、世界中のアーキテクトの従来の価値観を打ち砕いてしましました。そして、一方でCIO、CTO、その他のエグゼクティブ達は、意思決定を支援するための企業の包括的なイメージではなく、今すぐに何らかの価値を提供することを求めています。
個人的な話になりますが、私はEAチームをケイパビリティ向上や業務に関連したデリバリーの役割にアサインした20数社を超える組織に会ったことがあります。その組織は競争に勝つための人材を求めています。彼らが求めているのは、「推進のためのオーナー」であり、「ゲームに精通している人」、「リーダー」であり、真の変革を実現できなければ解雇されることを厭わない人材です。アーティファクトが価値のあるツールではないと言っている訳ではなく、それだけなのです。
これらの点は概ねIasaが過去15年間にわたって広めて来た事に準じています。認定されたEAプログラムを持っていないのには理由があります。正直な所、今まで言われてきたようなEAが実際のところ可能なものかどうか少々疑問に思っています。某病院の医局長は今でも患者さんを見ています。そうでなければ、患者からすると長く医局長をやっていて欲しくないでしょう。では、10年間、顧客への何らかのインパクト、収益へのインパクト、運用面での測定可能なインパクトをほとんど何も提供してこなかったアーキテクトがいた場合、どうすべきでしょうか？私個人の考えでは、そのようなアーキテクトをデリバリーの役割に移動し、デリバリーができない場合は他の役割を検討して貰うのが良いと思います。デジタルトランスフォーメーションはここから始まり、私たちはここに到達する必要があり、また今回もその枠組みに留まる必要があります。しかし、世界に50万人から100万人の様々なアーキテクトがいる中で、どうやってこれを行えば良いのでしょうか？
アーキテクチャの本質は’文書化’ではなく、’変化させる事’と言えます。チームとして最も重要な事を見つけ出し、自分自身と組織や顧客に対して「私はこれを実現させます」と宣言する事です。もし、それが実現したなら、私達は何かしら報いられ、そうで無い場合は何らかの責任を負う事になるでしょう。
アーキテクチャとは、実践であり、スキル・セットであり、その組織にとって最も重要で価値のあるデジタル・イニシアティブ (取組み) を見つけ出し、それを実現する事でその組織は貢献の評価を得る事ができるのです。私達Iasa Globalは、これらのスキルを学び、実践し、強化し、認定するためにIasaのカリキュラムを構築しています。
ここからは、あなたがデジタル変革者になりたい場合は、何をすべきか (そして何をすべきでないか) を説明します。
1. すべてのプロジェクトに取り組もうとするのをやめる。
私は自分自身の記事を盗作していると感じるほど多くの記事でこれを書いてきました。あなたのチームは、明らかに価値がある事を示すことができるプロジェクト/製品にのみ関与すべきであり、EAも同様です。将来的にEAの役割があるとすれば、かなり大きな割合の時間が実際のデリバリーに費やされるでしょう。おそらく、より大きなものに限定されるかもしれませんが。
2. ガバナンスではなくメンタリングを重視する。
ガバナンスはガバナンスであるべきです。アーキテクトは、ガバナンスを管理するのではなく、ガバナンスに従うべきです。チームで仕事をするのであれば、チームの成功の一端を担い、ゲームに参加すべきです。
3. 成功の第一の尺度を、再利用の度合いやコストではなく、利益、顧客、良き市民、またはミッションの測定に置く。
もしコスト削減の価値について語る場合、革新を行っているのではなく、財務チームの一員でしかない発言です。あなたの組織を成長させましょう。実際の顧客に影響を与えましょう (組織内には、実際の顧客というものは存在せず、それらは従業員と呼ばれています。彼らはチームのメンバーであり、真の顧客ではありません)
4. 組織の中で最高のエンジニアになろうとするのは止めましょう。
組織の中で最高のエンジニアになろうとするのは止めましょう。エンジニア達には良きも悪しきも担って貰い、その信用栄誉や責任も取って貰いましょう。(訳註：デジタル変革者を目指すなら、自身が優秀なエンジニアとして切磋琢磨するのではなく、エンジニア達にしっかり責務と責任を取って貰いましょう、と言う原文筆者の論点です。)
5. 最初に顧客や製品に直接触れるチームに焦点を当てましょう。
あなたのチームは、顧客や市民にフォーカスした活動にできる限りの時間を費やすべきです。イノベーションは常に顧客の近くで起こるのですから。
6. もしあなたのチームがビジネスケース (またはそれに相当するもの) を書いていなければ、あなたは変革者とは言えません。
アーキテクチャ・チームがイノベーションに焦点を当てているか、エンジニアリングに焦点を当てているかを見分ける最良の方法の1つは、彼らが書いた (他の影響を受けていない) ビジネスケースの数を尋ねることです。イノベーターはアイデアを持っていて、それを実現しています。今日からビジネスケースの執筆を始める事を薦めます。
7. 分野に関わらず、チームに必要なビジネススキルを身につけさせよう。
フレームワークやツールは忘れて下さい。デジタルビジネスモデルのビジネスケースを書けるようになり、それを提供したことによる顧客への結果を測定した人は、それが実践出来ています。最も安い労働力に頼っている場合は、細かいところまで交渉します。デジタル戦略を推進するにあたり、未熟な人材に頼っているのであれば、すでに失敗の道を歩んでいます。先ずは必要なスキルを身につけて貰いましょう。それはやや利己的に聞こえるかもしれませんし、そうかもしれませんが、我々(Iasa Global)はこのような事を伝え、時に組織を指導しています。私達に連絡下さい。(訳註：コンサルティング事業は、北米IasaGlobalで行なっています。)
8. データと情報からの示唆や発見を大切にする。
変革者は新しいビジネスに触れ、顧客、プログラム、イニシアチブ、戦略、製品、人、文化、そしてデータ、データ、データの中に身を投じます。これらをあなたの骨まで染み込ませて下さい。もしあなたがアイデアを思いつくために「ビジネス」の人が必要なら、あなたはビジネスパーソンではなく、「末端のスタッフ」の一部に過ぎません。私達はデータにアクセスする必要があり、それが最も難しい部分です。しかし、本当にそうしようと思えば、そこに到達することができます。持っているヒューマン・ダイナミクス (訳註：人間力学。ITABoKで定義するアーキテクトに必須の５つの柱の１つ) スキルを使用して取り掛かります。私の個人的なキャリアの中で最高のプロジェクトは、毎日営業チームとランチをしていたからこそ成功しました。ある日アイデアが浮かび、ビジネスケースを書き、それが採用された事でなんと私はチーフ・アーキテクトになった経緯があります。
9. 技術者であること、技術フォーカスである事、技術主導型である事を躊躇するのは止めよう。
世の中には、物事がどのように動くのか、なぜ動くのかを知りたがる人やそうでない人もいます。営業、財務、マーケティングに「ビジネス」がある理由の一つは、技術を理解したくなかったからという理由もあるでしょう。今日では、営業、マーケティング、財務、オペレーションはテクノロジーなのです。自分が本質的に技術者ではないと思わせようとするのは止めましょう。私の勘ですが、この記事を読んでいる人は多分誰もが家族が集まった際にはラップトップやタブレット、または他のデバイスのサポートを求められる人でしょう。私の勘では、あなたが家族のWiFiの設定を行い、クリスマスのためにAmazonやGoogleで買い物をする人です。おそらく、ラスベリー・パイのスタックを持っている事でしょう。ファイナンスの人は、ファイナンスがビジネスの成功を助けるための主要な手段であることを恥じていません。変革者になりたければ、デジタルの部分も含めてやる事です。もしあなたの組織で「我が組織では、アーキテクチャはテクノロジーの事ではない」という人の話を耳にしたら、(アーキテクトとして) それを正すか、次の雇用機会を速やかに検討した方が良いでしょう。
10. 誇大広告はでたらめだ。
マイクロサービスがSOAより優れているわけではありません。クラウドはデータセンターより優れているわけでもありません。Webベースはメインフレームより優れているとは断言できません。AIや機械学習はあなたのビジネスそのものを救うことは出来ません。購入は構築よりも優れている訳ではありません。Javaは.NETよりも優れている訳でもありません。アジャイルはウォーターフォールよりも優れている訳でもありません。テクノロジー、プロジェクト管理プロセス、トレンドはあくまでツールです。それらはある状況には適用されますが、別の状況には適用されない事もあります。楽観的な悲観論者になるか、もしくは悲観的な楽観論者になる必要があります。選択肢が数字でより良いことを示すことができなければ、それはあくまで一つの見解に過ぎません。そして、私達はどの意見に価値があるかを知っています。
11. あなたのRFPおよびあなたの仕事の記述書を変えよう。
アーキテクチャの専門職を価値のクリエーターに変換する最も簡単な方法は、調達時のRFPを見直し、関わるすべてのプロジェクト、プログラムまたは取組みの一部として、複雑さや契約の価格に基づいて経験を有した認定されたアーキテクトを要求することです。これを行う事であなたの組織には基本的なRFPの記述の変更以外に何らコストは発生しませんが、結果はどうなるでしょうか？もし、すべてのベンダーが、あらゆるプロジェクトに高度なスキルを持ったデジタルビジネス・ストラテジストを派遣したとしたら一体どうなるでしょうか。ここからが本当の変化の始まりであり、真の専門家と一緒に仕事をすることで取り巻く業界が変わる事でしょう。
最後の注意点として、EAチームがデジタル・トランスフォーメーション・チームとして再編成を始めている際には、最新の注意が必要です。ビジネス、情報、インフラストラクチャ、ソフトウェア、ソリューション・アーキテクチャを実際に行うことに集中する必要があります。もっと重要なことは、もし彼らが何か価値あるものを提供することにコミット出来ていないとすると、その場合は先に述べたIasaが推奨するような事を行なっていないという事になります。 もしかしたらTOGAFに基づく事は行っているのかもしれませんが。(これは少々言い過ぎですが) (訳註：IasaはTOGAFを主要なフレームワークとして参照、推奨しています)
SOAプラットフォームをマイクロサービスプラットフォームとして再分類したり、ホスティングサービスをクラウドサービスとして再分類したりしているベンダーを知っています。テキサスでは、これを「豚に口紅を塗る」と呼んでいます。(訳註：IasaGlobal本部はテキサス州に在ります) 彼らの仲間入りをしてはいけません。企業を変革する前に、自分自身を変革する必要があるのです。ガバナンス、ドキュメンテーション、企業や組織のアーキテクチャの設計を行なっているだけでは、変革者としての成功は望めないのです。
(日本語訳終わり)
記事紹介＆訳者コメント：現在、市場にはトランスフォーメーション (DX) の取り組み方やソリューションの事例紹介、関連の情報やセミナーが数多く存在しますが、今回ご紹介した記事のIasaGlobalの筆者の論点は、先ずは自身の意識と行動の変革を行わずして、DXに貢献出来るアーキテクトを目指しDXの具現化に貢献することは難しい、とのメッセージを発しています。DXに参画する「人」がそのケイパビリティを持たずしてどうやって実際のビジネスに貢献できるのかを論じています。本文の後半にある11箇条を読まれた方は、何かしら思い当たる考え方や振る舞いもあったのでは無いでしょうか？然しながら、それは当然の事と思われます。
と言うのも、私達の組織や環境のみならず、既存のスキルセットや個人のマインドセットを持ってしても、テクノロジーの進化のスピードとその先にあるデジタル化されたエコシステムが秘めた組織と社会へのインパクトの可能性を十分に捉え切れていない訳ですから。本当の変化は一見破壊的に見える事も含めて、まだ始まったばかりの夜明け前の状況にも思えます。皆さんはこの「デジタル変革者になるためには」の記事からどの様な事を思い描かれたでしょうか？ コメントや感想などお寄せ頂ければ幸いです。