検索結果

Iasa 日本支部 理事　塩田 宏治 CITA-A, TOGAF®, DASSM®, SAFe®5 SPC, CBAP®, PgMP® アジャイルのアプローチが普及してきていることは、ITに関わる方であれば多くの方がご存知かと思います。ただアジャイルという言葉で紹介される内容が、１０人以下の１チームによるソフトウェア開発をどう迅速にデリバリーして価値を実現するのかという議論が中心となってきました。こうしたデリバリー中心の議論に対し、エンタープライズ視点から考えているエンタープライズ・アーキテクチャのコミュニティや、ビジネスの視点から考えているビジネスアナリシスのコミュニティなどでは、ビジネスまたは組織のアジリティが重要であるという視点から多くの議論がなされてきています。アジャイル・コミュニティにおいても、エンタープライズ・アジャイルの考え方が広がりつつあり、Disciplined Agile®やScaled Agile Framework (SAFe®)などのフレームワークが、徐々に日本においても関心を呼び始めています。こうしたエンタープライズ・アジャイルのフレームワークもビジネスアジリティを中心的なコンセプトに据えており、“アジャイル“の関心が、手段であるデリバリーから、目的であるビジネス（営利、非営利を問わない）にフォーカスを移しつつあることは意義あることだと考えられます。今回は、ビジネスアジリティという視点を踏まえ、ビジネスアーキテクチャとエンタープライズ・アジャイルの接点について考察したいと思います。 Iasaが提供しているBTABoK（ITABoK）は、エンタープライズ・アーキテクチャについて多くの知見を提供しており、ビジネスアーキテクチャも専門領域として解説されています。以下の図は、ビジネスアーキテクチャを深堀したBIZBOK®(Business Architecture Body of Knowledge)のモデルで、ビジネスアーキテクチャのコア要素を、ケイパビリティ、バリューストリーム、情報、組織と定義しています。コア要素も変化を伴いますが、例えばプロダクト、業務を実際に遂行するビジネスプロセス、施策であるイニシアチブやプロジェクト、さらには戦略と比べても、比較的安定したビジネスの構造として定義されています。 参照：https://en.wikipedia.org/wiki/Business_architecture この４つの要素の中でも、非常に重要な役割を果たすのがケイパビリティです。ケイパビリティは、ビジネスが何をするか(What)を示すものであり、“特定の目的や結果を達成するために、企業が所有、交換できる特定の能力（ability）やキャパシティ（capacity）”とされています。ケイパビリティと等しく重要な要素であるバリューストリームは、“組織がステークホルダ、またはある一連のビジネス活動の状況におけるステークホルダに対して、どのように価値を達成するかを視覚的に示すもの”と定義されています。例えば、資材調達者というステークホルダに対し、資材が調達されるというバリュープロポジションを提供するために必要なEnd-to-Endのバリューストリーム・ステージの流れがデザインされます。情報や組織なども非常に重要ですが、本日はケイパビリティとバリューストリームを中心に扱うことにします。 バリューストリーム エンタープライズ・アジャイルでもバリューストリームは重要なコンセプトとして登場し、エンタープライズ・アジャイルを導入するには、組織がどのようなバリューストリームで構成されているかということを発見するためのワークショップを行います。これは、機能組織単位ではなく、バリューストリーム単位に企業運営することが、ビジネスアジリティにつながると考えているからです。しかしながら、エンタープライズ・アジャイルのフレームワークはビジネスアジリティへのフォーカスを標ぼうしつつも、ソフトウェア・デリバリーに関する議論がまだまだ中心でDevelopment Valuestreamに焦点があたっており、Operational Valuestreamの議論は不十分です。組織としてのビジネスアジリティを達成するには、OperationもDevelopmentもどちらのバリューストリームもアジリティを実現する必要があります。 Operationalなバリューストリームにおけるビジネスアジリティに必要な考え方は、“ビジネスアジリティ・マニフェスト”(https://busagilitymanifesto.org/10-translations/23-bam-japanese)にも示されています。関心ある方はご覧いただければと思います。 ケイパビリティ バリューストリームが“どのように”するかを示しているのに対し、ケイパビリティは“何”をするか、できるかを示しています。バリューストリームの中の各ステージは、ケイパビリティによって機能します。ケイパビリティは部門などの組織に依存せず、組織全体でユニークに定義されるべきものであり、バリューストリームや組織などを超えて呼び出されるものになります。例えば製品を調達するバリューストリームにおいて、“アカウントと協議する”=>“契約を受け取る”=>“適格性を検証する”=>“契約を最終化する”などのバリューストリーム・ステージが想定されます。一方、関連するケイパビリティとして、“契約管理”といったレベル１のケイパビリティの中に、“契約ニーズ決定”、“契約適格性決定”、“契約リスク決定”、“契約条項決定”、“契約価格決定”などのレベル２ケイパビリティが含まれることでしょう。“適格性を検証する”というバリューストリーム・ステージは、“契約適格性決定”および“契約リスク決定”という２つのケイパビリティが発揮されることによって初めて業務として適正に遂行されます。また逆に、“契約適格性決定”ケイパビリティは、“適格性を検証する”ステージだけでなく、“契約を受け取る”ステージを遂行する際にも、受け取る時点での初期検証をするタスクを実施するために必要となるケイパビリティでしょう。つまりビジネスを“賢く”遂行するためには、活動の順番が決まっているだけではだめであり、その活動を実行する能力が何であるかを議論する必要があることを意味しています。 このようなケイパビリティの考え方は、様々なフレームワークでも触れられています。TOGAF®ではCapability-based planningという考え方が強調されています。PMI®のプログラムマネジメント標準では、プロジェクトが生み出すものは所産（result）ですが、プログラムは能力（Ability）とベネフィットを生み出すことをマネジメントすると定義されています。プログラムレベルが、戦略やビジネスで実現したいこととITシステムなどのソリューションで実現することを、間でつなぎ整合を担保する重要な役割となっています。重要なことは、ビジネス戦略を実現するためには、どのようなソリューションが必要かをすぐに考えるのではなく、どのようなビジネスモデルやビジネスケイパビリティが必要かをまず定義する必要があるということです。ビジネス組織は、デジタルやITソリューションそのものが欲しいわけではなく、ビジネス組織が抱えるビジネス課題を解決したいと考えています。そのビジネス課題を解決できるかどうかを判断するには、ビジネスや業務レベルでどのような能力が必要となるかを考える必要があります。なぜならば、ITソリューションが、ビジネス組織が手に入れたいビジネスケイパビリティを100%実現できる場合は、ITソリューションがあたかもビジネス課題をダイレクトに解決するように見えますが、常にそうではありません。ITソリューションでは必要なケイパビリティが十分には獲得できない場合は、ビジネス組織はITではない別のビジネスソリューションも導入し、それによって手に入れたいビジネスケイパビリティ全体を実現するからです。私たちがビジネスの課題を解決しビジネスの価値を生み出すことに焦点を当てるのであれば、どのようなソリューションを提供するかだけを考えるのでは不十分なことが分かると思います。 こうして考えてくると、ケイパビリティとソリューションにおける機能との間に関係があることが認識できます。ソリューションを開発するエンジニアには、機能そのものだけでなく、その機能の“Why”を意味するどのようなケイパビリティを開発しようとしているのかを理解することが求められます。 従来のビジネスとITの関係は、ITはビジネスの写像またはビジネスのイネーブラーであるといった見方でした。これは、あたかもビジネス（例えば業務プロセス）とITシステムが別々にあり、ITシステムは業務プロセスを実行するための道具であるという見方です。そこから、業務プロセスや要求を考える人はビジネス組織の人で、ITシステムを作るのはIT部門の人という無意識の境界が生み出されています。こうした状況に対し、最近のビジネス環境の変化を受けて、ITがイネーブラーではなくビジネスそのものになってきたという言い方も時々耳にします。ITやデジタル技術を用いてソリューションを提供する人のミッションが、ソリューションを作ることではなく、顧客やビジネス組織の人と協働してビジネスを作りビジネスの問題解決を提供することだとするのであれば、技術でどのようなケイパビリティを作ることができ、ケイパビリティの集合としてのビジネスそのものの姿（モデル、アーキテクチャ）についての議論に、エンジニアも参加していく必要があることを意味しています。 一方エンタープライズ・アジャイルのフレームワークでは、ケイパビリティはどのように描かれているでしょうか。SAFe®を例にとれば、ポートフォリオレベルでイニシアチブに相当するエピックを定義し、Agile Release Trainというプログラムレベルのバーチャル組織でフィーチャーを主に扱い、チームレベルでユーザーストーリーを主に扱います。１つのAgile Release Trainでは扱えない大規模なソリューション・デリバリーを行うケースに対し、Large solution configurationという特定の全体像（Big Picture）が描かれており、そのレベルの粒度の要求をケイパビリティと呼び、エピックとフィーチャーの間のレベルとして位置づけられています（https://www.scaledagileframework.com/features-and-capabilities/）。SAFe®の中ではフィーチャーとケイパビリティはセットで説明されていることから、粒度は異なるが同様なものとして定義されていると解釈でき、定義としてはフィーチャーはステークホルダー・ニーズを満たすサービス、ケイパビリティはフィーチャーよりもハイレベルなソリューションの振舞いとされています。つまりSAFe®におけるケイパビリティはソリューションレベルの要求事項として議論されており、ビジネスケイパビリティという視点ではないと言えます。エンタープライズ・アジャイル・コミュニティにおいても、プロダクトマネジメント/プロダクトオーナーがステークホルダと協業して要求をディスカバリーする領域およびアーキテクチャ領域にさらに目を向け、よりビジネスの目線に立ちながらビジネスアナリシスやビジネスアーキテクチャ等の知識体系との融合を深めていくことが有効と考えます。 ビジネスアーキテクチャとエンタープライズ・アジャイル アーキテクチャは、技術やソリューションといった実装レベルと比べると、比較的安定した構造を保ちます。アジャイルの強みが柔軟に迅速に環境変化に対応するといっても、やみくもに変更を部分最適に行っていては、ビジネスや組織全体として最適な状態は作れません。つまりアーキテクチャのマネジメントの上に、それぞれのアジャイル開発が動いていなければ、全体最適な形でビジネス価値を生み出せません。さらに、最適な形でビジネス価値を生むためには、ITのアーキテクチャを見ていても不十分であり、ビジネスアーキテクチャをデザインしマネジメントする必要があります。 ビジネスアーキテクチャについて考えると、ビジネスケイパビリティ・マップのようなケイパビリティの構造は頻繁には変わりません。ビジネスがすでに立ち上がり、既存ビジネスの深化を行うフェーズでは、ケイパビリティの構造はあまり変わらない一方で、各ケイパビリティの詳細な構成（またはさらにブレイクダウンされたケイパビリティ）がビジネスニーズに応じて変更が求められ、そのケイパビリティの変更に対する実装としてのソリューションへの機能要求が、フィーチャーといった形で展開されます。一方、DXの文脈で見られるような大きなビジネスモデル、組織やプロセスの非連続のトランスフォーメーションを目指す場合は、アーキテクチャそのものが大きく影響を受けることになります。例えば３Dプリンタの導入によって、今まで後方の工場においてリペアパーツを需要予測に基づき生産し、それをビジネスの前線に近い倉庫や店舗に配送して在庫を持つサプライチェーンモデルから、当該部品のオーダが来てからビジネスの前線の３Dプリンタで短リードタイムで生産を行うことで、無在庫でのオペレーションを行うモデルの可能性が出てきます。この場合、顧客経験と価値を大きく変える可能性があるだけでなく、企業におけるビジネスケイパビリティもバリューストリームも、大きく変更を伴います。リペアパーツの需要予測ケイパビリティの重要性は大きく低下し、オーダに応じて即時に単品生産し出荷するケイパビリティを新たに構築する必要があります。そしてこれは、３Dプリンタという破壊的テクノロジーが新たに生み出すことが可能なビジネスケイパビリティの可能性について、技術サイドから連想するものです。 こうして考えると、DXに代表されるような大きなビジネス変革のケースにおいては、アジャイルデリバリーのレベルでの検討（例えば、どのようなフィーチャーが必要か）の前に、ビジネスアーキテクチャレベルで、As-IsからTo-Beのアーキテクチャにどう変更するのかのデザインが行われることが先であることがお分かりになると思います。また、企画構想段階で迅速に意思決定を組織が行うには、現在のビジネスアーキテクチャに対し、新しい施策のアイデアがどのようなインパクトをケイパビリティ等に与えるかの影響分析が迅速に行える必要があります。新しい施策のアイデアに対し、その業務プロセスへの影響や既存システムへの影響がすぐには分からず、調査をするのに多くの工数と時間をかける必要があった経験をしたことがある人は少なくないはずです。 ビジネスアジリティを高めたいのであれば、Development ValuestreamだけでなくOperational Valuestreamにも目を向ける必要があるとともに、ソリューションの前にビジネスアーキテクチャを構想することに、一層私たちのフォーカスをあてていく必要があると考えています。そして、エンタープライズ・アジャイル等のアジャイル知識体系と、ビジネスアーキテクチャやビジネスアナリシスの知識体系が一層連携し融合することで、一層ビジネスアジリティを実現するためのフレームワークとして包括的な知見が提供できるのではないかと考えます。

今年度の「Iasa日本支部主催のアニュアルカンファレンス2021」は、講演者3名をお迎えし11月5日に無事に終える事が出来ました。昨年に続き今年度もフルオンライン形式で開催しましたが、年々多くの参加者にご視聴頂きIasa日本支部関係者を代表して御礼を申し上げます。 （Iasa日本支部イベント一覧情報：https://www.iasa-japan.org/event） 今回のカンファレンスの主テーマは、「DX時代のエンタープライズ・アーキテクチャ」と題し、各方面でご活躍の講演者3名をお招きし、DX活動を成功裡に導く上で重要な鍵となる「アーキテクチャへの取組み」、「アーキテクチャを担う人材」、取り巻く課題等についてそれぞれの見解と事例等をご紹介頂きました。この振返りレポートでは、各講演者のメッセージと印象に残った点などを部分的に紹介させて頂きます。尚、3名の講演者の方のプロフィール詳細は、既にご紹介しました“「アニュアル・カンファレンス 2021」講演の主要テーマ事前のご紹介”をご覧下さい。 （https://www.iasa-japan.org/column） 講演１. なぜEAがDXを加速するのか？ 〜 DXの本質とEAによる推進手法 〜 講演者：　山本　修一郎 様 講演資料はこちら：https://www.iasa-japan.org/post/annual-conference-2021 最初に登壇頂いた山本様には「何故EA(Enterprise Architecture)がDXを加速するのか？ 〜 DXの本質とEAによる推進方法〜」について講演を行って頂きました。何故DX推進にEAが必要なのか、組織が直面する課題を中心に氏の幅広い知見から解説を頂きました。ここでは、特に印象に残った見解や論点を紹介させて頂き、筆者の個人的な感想も少々加えさせて頂きました。講演スライドの参照ページも付記しましたので必要に応じてご覧下さい。 山本様の講演では以下の題目ついて解説がありました。 DXとEAの関係について：日本と世界の捉え方の違い、主要なEAフレームワークの特徴と比較、EAとDXの相互関係についてその俯瞰的な解説（講演スライド3〜6ページ） → 世界と日本のEAの捉え方の違いは随分開きがある点は改めて認識しました。日本のEAに対する理解が今日何故そうなっているのかは興味がある所です。 デジタル・リーダー像について：DX先進企業における人材に、経営、事業、技術の３つに精通しリーダーシップを発揮できる「八咫烏（やたがらす）人材を有すると言う共通項があるとの調査結果（講演スライド７ページ） →「経営、事業、技術」のそれぞれ３分野に精通する人材は稀有と思われますが、組織的に取り組めば、八咫烏的な個人、または、チームが編成できるのでは、と感じますが読者の皆様の組織では状況はいかがでしょうか？ DXの本質について：“持続可能な企業の発展手段として既存のビジネスモデルからデジタル変革を通じて変化即応性を有するデジタルエンタープライズへ変革させる事“。 そのためにEA手法に対応したDX推進が重要（講演スライドP6〜10ページ） → DX自体は目的では無く、あくまでその手段である事を再認識しました。P10の４つの狙いは、アーキテクチャ活動として継続的に取り組まなければいずれも達成は困難に思えます。 DX推進を阻む７つの壁：DXに取り組む上で組織が直面する課題として、従来の人依存型のメンバーシップ型からジョブ型への経営変革の必要性、IT人材とDX人材の違いなど、DXを成功に導く上で見落としがちな課題（講演スライドP15〜P19） → とかくDXと言う結果イメージとして何らかのソリューションの導入がゴールとして捉えがちになりますが、現在の組織上の前提条件を前もって整備しておく事が重要である事が示されています。 デザインエンジニアリング：DXに必要な知識として開発された名古屋大学国際工科専門職大学向けの新カリキュラムの中で、「デザインエンジニアリング概論」の構成の紹介　（講演スライド21ページ） → “価値創造のためにエンジニアリングをデザインする“観点からアーキテクチャのレイヤー毎に個別の学習テーマがマッピングされている点が大変興味深いと思います。是非ご覧下さい。 → 尚、Iasaが発行するBTABoK（旧ITABoK）では、その知識とベストプラクティスを４つのアーキテクチャ領域と５つの知識体系で網羅しています。（注：BTABoK: Business Technology Architecture Body of Knowledgeの略。（詳しくはこちら https://www.iasa-japan.org/itabok） モデリングツールで視覚化したビジネスモデル例や各社のDX戦略例、SDGsに向けたDXの位置付けの解説、医療SDGsとして戦略マップ例の紹介（講演スライドP22〜P36） → DXをデジタル技術の活用・応用の視点のみで捉えると、関わる事業や経営の何処にどの様なインパクトを与え続けるかの視点が欠落しがちです。単発のプロジェクトの実装や導入で終わってしまう場合の理由はこの辺りにありそうです。 今回の山本様の講演では、DXを継続的な成功に導くために新しいビジネスモデルをEA視点でケイパビリティとして捉えそれをモデルとしてデザインするエンジアリングの重要性と、DXを阻害する課題への取組みについて、様々な事例紹介を通じて講演を行って頂きました。DXの本質に迫る大変興味深い講演を有難うございました。 講演２. 「DX時代におけるCX/UXの重要性と事例紹介」 〜 良いCX/UX、悪いCX/UXとは何か、その違いは利用者中心であるか否かに尽きる 〜 講演者： エスディーテック株式会社 代表取締役 川端　一生 様 講演資料はこちら：https://www.iasa-japan.org/post/annual-conference-2021 ２番目の講演者の川端 一生様には「DX時代におけるCX/UXの重要性と事例紹介」の講演を行って頂きました。当日の講演では以下の議題ついてわかり易い解説がありました。 利用時品質とは？ （講演スライドP5〜P8） →「利用者が実感する利用者を中心とした品質」とは大変明確でわかり易い定義です。一般的には多くのIT関係者は品質属性の一部の一部として捉えられている方が多いと思いますが、それ以上の重要性がと価値がこの領域には有りそうです。それにしても、僅か2年程度で停止されたパスポート電子申請システムの累計利用者が133人、年間運用費が8億円とは大変ショックな事例でした。 UXとCXは異なる？ （講演スライドP22〜23）/ CX/UXを良くするためには？ （講演スライドP24〜25） → UX：ユーザー（利用者）体験、CX：顧客体験の評価は、その良し悪しを決定づけるのは「利用者中心であるか否か」に尽きる、と言うシンプルな説明はわかり易く説得力があります。 人間中心設計の必要性 （講演スライドP29〜32） → 現在の多くの製品は、多機能・高機能・複雑化の道を歩んでいます。「利用者とその環境の理解が不足のまま開発すると、CX/UXは悪化する」の論点は、製品やシステム開発に携わる方々にそのプロセスの在り方や進め方で工夫できる余地が無いか見直す機会になるでのはないでしょうか？ デザインエンジニアリングの重要性（講演スライドP33〜39） →「デザインをエンジニアリングする」には、多様性と多能性を持ったチームが必要であり、職能間（デザイナ、エンジニア、データサイエンティスト、等）の専門家の共感と共創が必要であるとのメッセージは、大変新鮮で説得力があります。DXの推進体制にこの視点が足りない場合は、最適なデザインの創出は困難になる事が予想されます。冒頭の事例紹介であった2年で撤去されたシステムにはこの辺りに原因があったのでしょうか？ 私達Iasa関係者の気付きとしても、従来のEAの４つのアーキテクチャ領域(ビジネス、インフォメーション、ソフトウェア、インフラストラクチャ)に加えてCX/UXもアーキテクチャの一構成要素として捉える必要があり、それを科学的なアプローチでデザインする事がDX活動にも必要とされていると感じています。今回、川端様には「デザインをエンジニアリングする」事の意味とその価値をわかり易い事例を交えて講演を行って頂きました。貴重な講演を有難うございました。 講演3. 「BTABoKはアーキテクチャの実践にどの様に変化をもたらすか？」 〜 ステークホルダー主導のアーキテクチャ実践のフレームワーク"BTABoK"〜 講演者：IasaGlobal ファウンダー兼 CEO Paul Preiss様 (英語による講演) 講演資料はこちら：https://www.iasa-japan.org/post/annual-conference-2021 ３番目の講演は、世界最大級のエンタープライズおよびITアーキテクト協会であるIasaGlobalのファウンダー兼CEOのPaul Preiss氏（ポール・プライス氏）です 。 プライス氏には、「BTABoKがアーキテクチャの実践にどの様に変化をもたらすか？」の講演を行って頂きました。過去10年以上にわたりIasaGlobalが公開してきた’ITABoK ( ITアーキテクチャ知識体系)’ が新しく’BTABoK(ビジネステクノロジー・アーキテクチャ知識体系)’ に改定された点も注目です。(BTABoK v3英語版ドラフト: https://itabok.iasaglobal.org/) 当日の講演は英語による講演であったため、ここでは必要に応じて補足説明をする形式にしています。 現代のEAについて：DXの推進は、DXを駆動する”エンジン”がなければ困難である（講演スライド：P4〜6） → DX推進において、アーキテクチャが重要な役割を果たす中で、BTABoK（旧ITABoK）を活用する事によりアーキテクチャ・チームはより効率的、集中的に活動する事が可能になる → BTABoKは、「評価方法 - 成熟度モデル」、「価値モデル - エンゲージメントモデル」、「オペレーティングモデル - エンゲージメントモデル」、「人材モデル - スキルモデル」の４つから構成されている デジタル化には組織のDNAの変化が必要：新しい取組み方の検討を（講演スライド：P7〜10） → 顧客の環境や課題が変化しており、顧客に関連する「新たなツール、エコシステム、新たなコスト」について情報収集が欠かせない。 → ビジネスモデルの課題：ビジネスエコシステムが深く関与する場合は、複数のプラットフォームの関与と共同作業の重要性が増し、関係者のエンパワーメントが必要になる BTABoKのエンゲージメント・モデル：（講演スライド：P11〜20） → Iasaが提唱するアーキテクトの必要な全般スキルの体系についての解説 → EAの組織について：実戦を通じてビジネス価値のデリバリーにフォーカスする事が重要 → アーキテクトにはDX活動の中心的役割が期待され、アーキテクト、エンジニア、ビジネス関係者は適度な緊張感と役割の基で連携する必要がある アーキテクチャの移行と成果のケイパビリティ：（講演スライド：P21〜22） → 顧客にはビジネス成熟度評価、ビジネスには、技術成熟度評価、社員にはアーキテクチャ成熟度評価を適用する評価方法を推奨 デジタル・エンゲージメント用のツール、カードとカンバス（講演スライド：P23〜30） → エンゲージメント用カードの種類：カスタマージャーニーマップ、ペルソナ・カード、ビジネスモデル・ケイパビリティマップ、戦略スコアカード・カンバス、等ツールを公開 エンゲージメント成熟度モデルについて：（講演スライド：P33〜35） → 成果のデリバリー、アーキテクトがチームとして機能しているか等、各成熟度ゾーンを５つの成熟度レベルで測る事が可能。エンゲージメントを可視化できるモデルは大変興味深いです。 講演の最後に、Preiss氏からIasa Globalが今年度「Architecture & Governance」と言うWebサイト上でマガジンを発行する組織をM＆Aにより統合したとのアップデートもありました。 (https://www.architectureandgovernance.com/) IasaGlobal創立者であるPreiss氏の講演により、今後Iasa Globalが目指しているBTABoKとその内容を垣間見る事が出来ました。Preiss氏にとっては8時間の時差があり早朝の講演になりましたが、貴重な講演を有難うございました。 終わりに... 今回のカンファレンス参加者にご協力頂いたアンケート結果では、今後のBTABoK v3のリリースの期待が最も高い事が示されました。関係者一同、早期のリリースに向けて努めたいと思っております。今回のカンファレンスにご登壇頂いた講演者3名の方にはこの場をお借りして厚く御礼を申し上げます。来年もIasaアニュアル・カンファレンスを開催する予定ですので、是非ともご期待下さい。 Iasa日本支部の新しいWebサイト： https://www.iasa-japan.org/ ― 　終わり　ー

「Iasa日本支部アニュアルカンファレンス2021」 講演の主要テーマ 事前のご紹介 2021年10月 Iasa 日本支部 梶川　哲生 シリーズで掲載している今回のコラムでは、来たる2021年11月5日に開催するIasa日本支部主催「アニュアルカンファレンス2021」の講演の主要テーマと関連する背景等について先行してご紹介します。（Iasa日本支部イベントのご案内http://iasajapan.org/anual-conf-2021.html） 社会全体が本格的なデジタル活用と革新の時代を迎えつつある今日、DXの根幹を担う「アーキテクチャ」の理解とその取組み方如何で、DXの取組みを成功裡に継続的に具現化していけるのか、または、期待に反して成果が見えない取組みで終息してしまうのか、その分岐点となる重要な鍵を各方面で活躍されている講演者をお招きし、それぞれの立場でメッセージを発信して頂きます。本コラムでは、公開済みのイベント掲載情報を補足する形で各講演者のプロフィールと講演内容について紹介させて頂きます。 講演１. なぜEAがDXを加速するのか？ 〜 DXの本質とEAによる推進手法 〜 講演者：　山本　修一郎 様 最初に登壇頂く山本様は、現在名古屋国際工科専門職大学 情報工学科教授、及び、名古屋大学 名誉教授を担っておられます。ソフトウェア工学，要求工学，EA, DXなどの研究に基づく独自の知見と経験をお持ちで、政府機関の数々の施策や委員会のDX分野でのオピニオン・リーダーとしても活躍されています。（経済産業省のデジタルトランスフォーメーションに向けた研究会委員（2018年）、デジタルトランスフォーメーションの加速に向けた研究会委員(2020年)、その他多数の要職を歴任） 本講演では，山本様ならではの知見に基づいたDXの取組みに於いて共通する本質的な問いとその見解をご紹介頂きます。最初の論点として、 ① DXでなぜEAが必要なのか ・日本と世界のEAの違い ・デジタルケイパビリティとは何か ・ケイパビリティベースプランニングとは何か ・ダイナミックケイパビリティとは何か についてお話し頂きます。この中で「ケイパビリティ」という言葉は日頃馴染みが薄い読者の方も多いかも知れません。ここでは、DXの取組みを通じてその成果を継続的に創出する上で重要な「企業や組織が持つ、全体的な組織的能力、あるいは、企業や組織が得意とする組織的能力」(Wikipedia)とご理解下さい。ケイパビリティについてDXの観点から山本様の展望は大変興味深いところです。 更に経営者の方々に最も関心のあると思われるDX取組みの際の実際的な課題として、’DX人材の育成’, ’儲かるDX’ の論点に加え、現在世界的に関心が高まっているSDGsイニシアティブとの関連について、’SDGsとの両立’は出来るのか、についても氏の見解をお話し頂きます。 ② DXに取組む上での課題 ・石垣型経営からジョブ型経営への移行をどうするか ・ＤＸ人材の育成をどうするか ・儲かるDXをどうするか ・SDGｓとＤＸをどう両立させるか 最後に、より詳しく探求されたい方向けに氏の著書の紹介の中でその内容と背景等も触れて頂ける予定です。 ③ 著書『DXの基礎知識』（近代科学社Digital）の紹介 山本様にはDXの核心に迫る大変興味深いテーマと論点を取り上げて頂いております。是非当日の講演をご期待下さい。 講演２. 「DX時代におけるCX/UXの重要性と事例紹介」 〜 良いCX/UX、悪いCX/UXとは何か、その違いは利用者中心であるか否かに尽きる 〜 講演者： エスディーテック株式会社CEO 川端　一生 様 ２番目の講演は、エスディーテック株式会社CEO川端 一生 様にご登壇頂きます。川端様が2015年に創業されたエスディーテック社のホームページにはその企業理念として 『「Design Engineering」のプロフェッショナルチームです。デザインとエンジニアリングの分業ではなく、統合された「Design Engineering」により、⻑く愛される「ヒトとモノ」そして「ヒトとコト」のインターフェースを⽬指さしています。』 と記載されています。(エスディーテック社HP https://www.sdtech.co.jp/) 川端様の講演では、以下の要旨でお話し頂きます。 『多くのITシステムの開発において、機能品質だけが追求され、利用時品質は着目されていない。この講演では、CX/UXのベースとなる利用時品質について解説し、利用者中心の開発を行うための考え方である「人間中心設計（ISO9241-210）」の紹介と解説を行い、機能品質と利用時品質を高いレベルで兼ね備えるITシステムを実現するために、上流の企画・設計フェーズにおいて、ITアーキテクトとCX/UXデザイナがチームで取り組む必要性を解説する。』 講演では要所で事例も紹介頂けます。私達Iasa関係者の気付きとしても、従来のEAの視点に加えてCX/UXもアーキテクチャの構成要素として捉え、その設計を意識的に行う事がDXにも必須である、と思っております。まさに「DesignをEngineeringする」が意味している事では無いでしょうか？ Iasa日本支部の掲載済みコラムで、EAとCX/UXの関連性について解説をした記事がありますので、こちらもご覧頂いておくと本講演の理解がより深まると思いますので是非ご利用下さい。。 コラム（vol.23）DX 時代のエンタープライズアーキテクチャを考える～EA がビジネス変革と CX／UX をつなぐ！～ 講演3. 「BTABoKはアーキテクチャの実践にどの様に変化をもたらすか？」 〜 ステークホルダー主導のアーキテクチャの実践のフレームワークBTABok〜 講演者：IasaGlobal ファウンダー兼 CEO Paul Preiss様 (英語による講演) ３番目の講演は、Paul Preiss氏（ポール・プライス氏）による講演です。プライス氏は、世界最大級のエンタープライズおよびITアーキテクト協会であるIasaGlobalのファウンダー兼CEOです。(Iasa日本支部は、IasaGlobalの日本担当地区の支部になります) Iasa Globalは、テキサス州オースティンにあった1つのユーザーグループから、2021年現在は25カ国以上に支部を持つ国際的な組織へと発展しました。プライス氏の創設時からの一貫したビジョンは、’効果的な教育、資格、倫理観を備えた世界で通用する ’アーキテクチャ専門職’ を普及させ、企業の戦略と実現を支援する事’です。自らエンタープライズ・アーキテクトとしても活躍されており、企業の技術戦略の最適化の実践を通じて貢献しています。また、数百ものイベントで精力的に講演し、コロナ禍に置いても世界中のアーキテクトを対象としたカンファレンスやトレーニングを開催しています。(IasaGlobalホームページ: https://iasaglobal.org/) 今回のプライス氏の講演の最大のトピックは、過去10年以上にわたりIasaGlobalが公開し改訂してきた’ITABoK (IT Architecture Body of Knowledge / ITアーキテクチャ知識体系)’ の名称とスコープを変更し、’BTABoK(Business and Technology Architecture Body of Knowledge / ビジネス＆テクノロジー・アーキテクチャ知識体系)’ とリニューアルした事です。対象スコープをIT視点からビジネス視点も包含する内容に明示的に拡大した背景や理由、更に今後の展開についても本講演で紹介されますのでご期待下さい。 今回のプライス氏の講演の要旨としては、以下の内容をお話し頂きます。 『アーキテクトやアーキテクトチームの目標は、ビジネスや顧客に価値を提供することです。BTABoK(旧ITABoK)は、これを可能にする実際のツールとテクニックの大きな飛躍を指し示すと同時に、より成熟したアーキテクチャのプラクティスを開発しています。BTABoKは当初から、プロセスや単なる成果物ではなく、人を中心に設計されています。長い間待ち望まれていた3.0では、ビジネスとテクノロジーの両方の観点から価値を提供するために、アーキテクチャのプラクティス（チーム）を結びつけることができるようになります。これは、あらゆる規模の現代のビジネスにおいて絶対に必要なことです。』 (BTABoK v3英語ドラフト版: https://itabok.iasaglobal.org/) また、以下の実践的な方法についての紹介があります。 企業のアーキテクチャ的に重要な要件からソフトウェアの最小単位の決定まで、設計上の意思決定を最大化する方法 最小限の努力で最大限のステークホルダー・サクセスを実現する方法 統合、リファレンスアーキテクチャー、フレームワークなど、あらゆるレベルのスコープでパターンを適用する方法 共通の価値観や信頼関係の問題に直面せず、成功するアーキテクチャ・チームを計画し、構成し、実現する方法 これらの実践については、フォーチュン100社の多くの企業で採用、適応され始めている事も付け加えておきたいと思います。 終わりに.. 本項では、来たる2021年11月5日に開催するIasa日本支部主催アニュアルカンファレンス2021の３講演のテーマと関連する背景等について補足する形で紹介させて頂きました。 当日の講演は事前登録のみで無料でご参加いただけます。この貴重な講演の機会をご活用頂ければ幸いです。 Iasa日本支部イベントご案内：http://iasajapan.org/anual-conf-2021.html 注記：本コラムで紹介した講演要旨の補足内容と実際の講演内容が若干変わる場合があります。予めご了承下さい。 ー　終わり　ー

2021年11月5日(金)に開催された「アニュアル・カンファレンス2021」の各講演で使用した資料です。 講演 1. なぜEAがDXを加速するのか 〜 DXの本質とEAによる推進手法 〜 名古屋国際工科専門職大学 情報工学科 教授 名古屋大学 名誉教授 山本 修一郎 様 講演資料はこちら 講演 2. DX時代におけるCX/UXの重要性と事例紹介 〜 良いCX/UX、悪いCX/UXとは何か、その違いは利用者中心であるか否かに尽きる 〜 エスディーテック株式会社　代表取締役社長 川端 一生 様 講演資料はこちら 講演 3. BTABoK’はアーキテクチャの実践にどの様に変化をもたらすか？ 〜 ステークホルダー主導のアーキテクチャの実践のフレームワーク BTABoK 〜 Iasa Global ファウンダー 兼CEO Paul Preiss 様 講演資料はこちら

2019年10月30日(水)～11月1日 (金)に開催された「The 8th BITAS Executive Series 2019」の各講演で使用した資料です。 当日参加された方には閲覧用のパスワードをメールにてご案内させていただきましたが、パスワードを紛失された方や当日参加されていない方で資料をご覧になりたい方はこちらのお問い合わせ窓口からその旨ご連絡いただければ閲覧用のパスワードをご連絡させていただきます。

2018年11月30日(金)に開催された「アニュアル・カンファレンス2018」の各講演で使用した資料です。講演１.と講演３.の資料には閲覧用のパスワードを設定させていただいております。 当日参加された方には閲覧用のパスワードをメールにてご案内させていただきましたが、パスワードを紛失された方や当日参加されていない方で資料をご覧になりたい方はこちらのお問い合わせ窓口からその旨ご連絡いただければ閲覧用のパスワードをご連絡させていただきます。 講演 1.『グローバル化 & IT人材育成の取り組み 〜デジタライゼーションに向けて〜 』 日本たばこ産業株式会社 CIO 引地 久之 様 講演資料はこちら 講演 2.『Introduce Recent Trends of DX in Asia』 Iasaアジアパシフィック, ファウンダー兼会長, Aaron Tan Dani 様 講演資料はこちら 講演 3.『より豊かな社会を築くマイクロソフトの最新テクノロジー』 日本マイクロソフト株式会社 CTO 兼 マイクロソフトデベロップメント株式会社 社長 榊原 彰 様 講演資料はこちら

前回に引き続きBITASのハイライトを取り上げたいと思います。今回は、「デジタル・エンタープライズ・アジリティ」について述べていきます。 BITAS に参加するにあたっての予習ということで、ハイライトの２番目に掲げている「デジタル・エンタープライズ・アジリティを促進するクリティカルスキル」の前提知識として位置付けてください。 【参考】 BITASプログラムハイライト イノベーションを促進し、継続的な変革を推進するための方法 デジタル・エンタープライズ・アジリティを促進するクリティカルスキルの重要性 現実世界のデジタル化のケーススタディ紹介とウォークスルー デジタルビジネスを推進するための、デジタル・カスタマージャーニーマッピング IT をビジネスにとって戦略的に重要なものにするビジネス・アーキテクチャ ヒューマン・ダイナミクスの複雑さを管理し、理解する上でのアート (技能) と科学 成功するプロジェクト実施のためのビジネス要件アーキテクチャ デジタルの混乱から競争上の優位性をもたらす、ビジネスチャンスへの変換 日本企業への現地訪問を通しての DX の取り組みと企業文化の理解 他国の参加者とのつながり、ネットワーキングおよび現実世界のシナリオの共有 ビジネスニーズにより迅速に対応するため、システムを構築する現場では、アジャイル開発が普及しつつあります。しかし、企業や事業部レベルでアジャイル開発を行うためには、中長期的な情報戦略や大規模なプロジェクトの管理、PMやアーキテクトの役割など従来手法を中心に体系化されていたものを革新する新たな取り組みが必要となります。 取り組みのひとつとして、「アジャイルプロセスフレームワーク」と呼ばれるものが「エンタープライズアジャイル」という言葉とともに出てきており、その代表的なフレームワークが SAFeとDADのふたつです。 それぞれ、アーキテクトの役槍をどのように捉えているのでしょう。まずは、SAFe についてのアーキテクトの役割について紹介したいと思います。 企業戦略とシステム開発を一体化する枠組みである SAFe (Scaled Agile Framework) は、Dean Leffingwell 氏が中心になって開発したアジャイルプラクティスとリーンプラクティスを企業全体に広げるのを支援する業界標準のフレームワークです。 SAFe の導入によって、企業や事業部は、組織横断的な一貫した戦略を持つことができ、開発メンバーの仕事に関する満足度を高めることができ、より良い品質のシステムを提供することが可能となります。 SAFe では、システム開発における関係者を以下のように定義し、システム・アーキテクトには、ビジネス戦略に基づいた、技術的なビジョンと実装シナリオのディファインを期待しています。 平たく言えば、ステークホルダーが主張するビジネス要求やシステム要求を、業務要件とシステム要件として具体化し、アーキテクチャーをデザインすることであるかと思います。 この定義で登場するアジャイル・リリース列車 (ART) は、SAFe 独特のものです。SAFe ではプログラムレベルでのプロダクトオーナーに相当するプロダクト管理者という役割やプログラムレベルでのスクラムマスターに相当するリリース列車エンジニアという役割を設けています。 メタファーとしての列車は、ダイヤに従って駅を出発し、目的の駅に到着する。この列車が仮想の組織を構成し、必要な資源（プロトタイプ、ソフトウエア、ハードウエア、ドキュメントなど）は貨物として列車に載せられる。最終的には、リリースという形で列車は目的の駅に到着するということになります。 次に、DAD (ディシプリンド・アジャイル・デリバリー) における役割を見ていきましょう。 DADを考案したのは、IBMの Scott Ambler 氏と Mark Lines 氏です。DADにより、2006年に1 年ごとだった製品リリースは、2012年には3ヶ月ごとになり、すべての製品が当初計画の納期を守るといった効果を得ています。 DADフレームワークは、以下のような役割セットを提案しています。 上記にある“主な役割”と”補助的役割”との違いですが、主な役割とは、すべてのDADプロジェクトで、状況にかかわらず現れる役割のことで、補助的役割は、状況に合わせての対応や一時的な局面での対応で、必要とされる役割です。DADの特徴のひとつとして、アーキテクチャの課題を扱っており、それに応じたアーキテクチャオーナーという役割を提示している。(スクラムは、アーキテクチャを扱わないので、そのような役割がない) DADにおけるアーキテクトの立ち位置は、以下のディシプリンドアジャイルのプロフェッショナルの役割から読み取れます。 エンタープライズアーキテクトやポートフォリオ管理者といった、全社レベルのプロフェッショナルと密に協力して働く 全社標準のガイドラインを採用し準ずる。 組織内のアセットを活用する。アセットには既存のシステムやデータソースが含まれる。 組織のエコシステムを、アセットをリファクタリングすることで、拡張する DevOps 文化を適用する 学習したことを他のチームと共有する。 適切なガバナンス戦略を採用する。オープンで正直なモニタリングが含まれる DADでは、エンタープライズ対応に徹し、全社レベルの価値観によって正しい方向に向かうことを良しとしているようです。エンタープライズ・アーキテクトを中心としたアーキテクトチームが、DADの効果を上げる重要な役割をはたすことが求められています。 SAFe も DADにしても、アーキテクトの役割が、重要な位置を占めることが期待されています。いずれにしても、「デジタルエンタープライズアジャイル」の分野は、今後とも発展し、アーキテクトに期待されることも大きくなっていくことが考えられます。Iasa日本支部でもウォッチしていきたいと思います。是非、情報共有のご協力をお願いします。 追記） SAFe は、今後普及が進むと考えられており、ITABoKV3.0 でも紹介しています。参考にしてください。(日本語訳は今秋刊行予定です) https://iasaglobal.org/itabok3_0/engagement-model-overview-3-0/lean-and-agile- adoption/agile-and-architect-roles/roles-and-personas-mappings-to-safe/

このコラムでは、Iasa日本支部が標榜している「DX時代のエンタープライズアーキテクチャ」について、いくつかの見識を紹介し、考えていきたいと思います。 まず、デジタル時代のアーキテクチャをどうイメージするかですが、IBM社が提示した以下のチャートが参考になるかと思います。 図１：https://bp-affairs.com/news/2018/08/20180827-7910.html　より デジタルテクノロジーの進展は、従来の業種、業態の枠を破壊し、テクノロジーを戦略的に活用していかにビジネスモデルを変革できるかが、重要な課題となっています。ここでは、ビジネスモデル変革を考える上で、従来のフィジカルな顧客接点と、デジタルな顧客接点の双方を最適化していくことが不可欠だとしています。 このデジタル時代の次世代アーキテクチャは、企業が自社だけでなく外部との連携による新たなデジタルビジネスを実現する「デジタル変革」へと進化するためのロードマップを提示しています。 また、このチャートでは、顧客視点でのデジタル化と事業体におけるデジタルサービスが連携し、ビジネスサービスとデータサービスに繋がっています。このアーキテクチャを絵にかいた餅ではなく、実現性のあるものとして描くことが出来たときから、その企業でのDXは始まるのではないかと考えます。 さて、アーキテクチャをデザインするためのアプローチですが、その指針が、デジタルトランスフォーメーション研究会委員も務められた名古屋大学の山本修一郎教授が以下の図で示されています。 以下、「1. DX戦略をどうするか（1）－DXの目的と定義－」　山本修一郎から抜粋。 以下、抜粋ですが、詳しくは以下を参照ください。 https://www.bcm.co.jp/solution-now/cat-solution-now/2020-03_2539/ 現在の企業をデジタル企業に変革することがDXである。そこで経営、事業、ITシステムに分けてDXをみてみると、上記のようにDXを分解できる。すなわち、DXには、経営変革、ビジネス変革、IT変革がある。経営変革では組織、文化・風土ならびにビジネスモデルを変革することによりデジタル経営を実現する。 　ビジネス変革では、業務プロセスならびに、事業能力をデジタル化することにより、デジタルビジネスエコシステムを実現する。ここで、事業能力はビジネスケイパビリティのことである。ビジネスケイパビリティは欧米では企業が提供するビジネスを明確化するために用いられる基本的な考え方であり、事業能力をマップ化することにより、創出価値の大小で優先順位付けることができる。現行の事業能力マップが定義されていれば、デジタル化の脅威を受けるのはどこか、デジタル化による創出価値が高いのはどこかを明確にでき、優先順位の高い事業能力からDXを推進することで、DXロードマップを作成できる。 　IT変革では、現行のITシステムのモノリスアーキテクチャをマイクロサービスアーキテクチャによる適応型ITシステムに刷新することにより、データとデジタル技術を活用できる変革即応アーキテクチャを実現する。マイクロサービスアーキテクチャは、事業能力と対応する独立性の高いマイクロサービスを疎結合することにより、事業能力の変化に際して対応するマイクロサービスだけを変更できる。これに対してDXの足枷になっている老朽システムは機能要素が複雑に密結合しているモノリスアーキテクチャで構築されているため、特定の機能変更が老朽システム全体への影響を探索して確認する必要があり、ビジネス変化に即応できない。ITシステム刷新が必要な理由はここにあり、単に老朽システムをクラウドに移行すればいいというような単純な話ではない。 文中の事業能力（ビジネスケーパビリティ）とは具体的にどんなものでしょうか？それぞれの組織が定義していくものでありますが、定義するうえでは、ITABoKのビジネスアーキテクトのケイパビリティ定義が参考になるかと思います。ITABoK　V2デジタル版（P218～P267）を参照ください。 では、アーキテクチャを企業の財産として、整備し維持していくには、どうすれば良いのでしょうか？以下のような推進体制を構築し、アーキテクチャを進化させている事例を紹介します。それは、AMO（アーキテクチャ・マネージメント・オフィス）を組織して推進してする事例です。 AMOは、アーキテクチャマネージャーを中心として、ユーザー代表、ビジネスアーキテクトなどの専門領域アーキテクトで組織され、コラボレーションポータルサイトにメンバーが登録されます。 AMOにより、レビュー・承認されたアーキテクチャはポータルサイトに公開され、システム開発、運用、ユーザ等のプロジェクトにかかわるステークホルダーが参照することが出来ます。またＡＭＯは、常に数年先のアーキテクチャ青写真を描き、詳細な落とし込みは各現場組織に委ねるといった振る舞いも必要となります。 詳しくは、Iasa日本支部の中山理事のブログ「アーキテクチャ・マネジメント・オフィス（ＡＭＯ）」　https://www.it-innovation.co.jp/2016/08/29-004910/　参照ください。 アーキテクチャを描くには色々な方法がありますが、Iasa日本支部では、ArchiMateによる可視化を推奨しています。ArchiMateはThe Open Groupによって開発・維持管理されているエンタープライズ・アーキテクチャを記述するためのグラフィカルな言語であり、オープンな標準です。さまざまなプロジェクトやビジネスの利害関係者に関連するさまざまな視点を作成するために使用することができます。 ArchiMateは、AMOによるレビューやアーキテクチャの改善・維持に適しており、ステークホルダー間の共有が可能となると考えます。Iasa日本支部では、１回／月の勉強会を開催しています。Zoomでの参加となりますので、気楽に参加できるかと思います。詳しくはIasa日本支部　ArchiMate　勉強会　zoom_admin@iasajapan.orgＸまでお問い合わせください。 以上、筆者の「DX時代のエンタープライズアーキテクチャ」への思いと一にする考えのご紹介というコラムになりました。 まとめますと、 現状を把握し、アーキテクチャを描くとことから始まり 経営改革、事業改革、IT改革と進めながら AMOなどの体制の整備を並行して進めていくなかで 「ビジネスモデルの変革を起こし、エンタープライズアーキテクチャを進化させる」 ことになるかと思います。 ビジネスモデルの変革を伴う改革となり、その壁は高いですが、１年前のコラムで紹介した「今すぐにデジタルトランスフォーメーションの旅に乗り出さない組織は、混乱して取り残される危険性があります。」というアーロン（Chairman of Iasa Asia Pacific）の主張にあるように、事態は待ったなしの状況です。 カンファレンスや勉強会の開催などIasa日本支部の活動が、この「DX時代のエンタープライズアーキテクチャ」への道を切り拓くための一助となるよう努めていきたいと思います。何卒、よろしくお願いいたします。

原文:　Iasa global HP掲載記事 https://iasaglobal.org/Public/TOPICS/Becoming-Digital-Transformers.aspx 日本語訳について：英語原文の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箇条を読まれた方は、何かしら思い当たる考え方や振る舞いもあったのでは無いでしょうか？然しながら、それは当然の事と思われます。 と言うのも、私達の組織や環境のみならず、既存のスキルセットや個人のマインドセットを持ってしても、テクノロジーの進化のスピードとその先にあるデジタル化されたエコシステムが秘めた組織と社会へのインパクトの可能性を十分に捉え切れていない訳ですから。本当の変化は一見破壊的に見える事も含めて、まだ始まったばかりの夜明け前の状況にも思えます。皆さんはこの「デジタル変革者になるためには」の記事からどの様な事を思い描かれたでしょうか？　コメントや感想などお寄せ頂ければ幸いです。

2020年10月8日(木)に開催された「アニュアル・カンファレンス2020」の各講演で使用した資料です。なお資料には閲覧用のパスワードを設定させていただいております。 当日参加された方には閲覧用のパスワードをメールにてご案内させていただきましたが、パスワードを紛失された方や当日参加されていない方で資料をご覧になりたい方はこちらのお問い合わせ窓口からその旨ご連絡いただければ閲覧用のパスワードをご連絡させていただきます。 講演 1. デジタルIT時代に適応するデジタル・アーキテクチャと世界の最新動向 〜デジタル時代のアーキテクチャ・フレームワーク AIDAF、 エコシステム構築の時代へ〜 慶應義塾大学大学院 政策メディア研究科 特任准教授 兼 米国カーネギーメロン大学院Visiting Research Fellow 増田 佳正 様 講演資料はこちら 講演 2. 産業アーキテクチャの重要性について 〜「デジタルアーキテクチャ・デザインセンター」設立の背景と今後の展望について〜 IPA 社会基盤センター アーキテクチャ設計部 河野 孝史 様 講演 3. ビジネスアジリティをスパイラルアップ 〜幸せのためにビジネス・アジリティを高めるエコシステム〜 デジタルビジネス・イノベーションセンター(DBIC）ディレクター 鹿嶋 康由 様 講演資料はこちら

今回はIasa APAC (アジア・パシフィック) のウェブ・コンテンツをご紹介します。Iasa APAC代表で、Iasa日本支部会員の皆様にもおなじみのアーロン・タン・ダニ氏が、エンタープライズ・アーキテクチャ (EA) の概要を5つの問いに答える形で解説しています。5回にわたる連載の最後の公開から一年を過ぎていますが、ITとあまり関わりのない専門外の方々などにもEAの意義を広く知っていただく上で参考になりますので、各回のエッセンスを私のコメントも交えご紹介したいと思います。 1. “What is Enterprise Architecture?” (EAとは何か?) ITABoKではITアーキテクチャを、「価値のあるテクノロジー戦略のデザインとその実現のアート(技能)もしくはサイエンス(科学)」と定義していますが、ここではアーロン氏はEAをオーケストラに例えています。総譜(スコア)はフレームワーク、楽器はテクノロジー、演奏家や指揮者はスキル、記譜法はノーテーションです。 ここでは、フレームワークにはザックマンやTOGAF、スキルにはITABoK、記譜法にはArchiMateがそれぞれ例として挙げられています。 EAとは何か、と尋ねられたとき、オーケストラのようなものである、というのが良い答えかどうかは難しいところでしょう。質問者のバックグラウンドにもよりますが、例えば「フレームワークは総譜にあたる」と説明されても、そもそもフレームワークを知らない人にはあまり意味が有りません。少なくとも専門外の方々に対する説明としてはあまり気の利いた説明の仕方では無さそうです。 しかしながら、個人的にはアーキテクチャの要素としてノーテーション、その例としてArchiMateが挙げられている点には注目したいと思います。「百聞は一見に如かず」で、まずはArchiMateビューのサンプルを見せて、「これは楽譜のようなものだ」といった説明をするのが良いのかも知れません。もちろんEAの広大且つ奥深い世界は一つのArchiMateビューだけでは表現できませんが、だんだんとそこから広げたり、掘り下げたりしていけばよいのです。 2. “Who needs Enterprise Architecture?” (誰がEAを必要とするのか?) この問いに対するアーロン氏の答えは比較的単純明快で、彼が挙げるところの5つの過ち、すなわち① ITとビジネスのコミュニケーション不全、② バラバラのシステム、③ 自動化への時代遅れなこだわり、④ ITとビジネスとの戦略不整合、⑤ ROIの対象ではなくコストセンターと見なされるIT部門の、どれか一つでも犯した人々は、誰でもEAの恩恵を受ける、というものです。 このうち、③ 自動化への時代遅れなこだわりは中々示唆に富んでいます。興味深いのは、これを「プロジェクト第一主義」と結びつけ、その「過ち」を、ざっくりとした「自動化」の要件に基づいて、スタート時点で既に予算やスケジュールを限定してしまうこと、と指摘している点です。 これは多くの企業ITが抱える問題の核心に触れた指摘ではないでしょうか。ITといえば自動化ということで、毎年様々な目的や種類の自動化ソリューションを買い集め、やがてシステム間連携ソリューションも買ってシステム間をメッシュ状に繋ぎ、挙句にそれらの経済寿命が次から次へとやってきて、技術的負債の増大が止まらなくなる、というのが多くの日本企業が陥っている現状ではないでしょうか。 恐ろしいことに、最初にソリューション・プロダクトを買ってしまい、あとで辻褄合わせに多額の費用を投じても、二進も三進も行かなくなったりするプロジェクトは、今日でも少しも珍しくありません。それが「プロジェクト第一主義」に因るものだと分かったとき、EAがその解決策となるとアーロン氏は主張しています。つまりEAの恩恵を受ける人とは、「ITプロジェクトが炎上したり失敗したりしたことがある人」だということです。そして世の中にはそのような人々は沢山おられるのではないでしょうか。 3. “When to implement Enterprise Architecture?” (EAをいつ導入するべきか?) ここでは「適応能力(“Readiness”)」および「成熟度(“Maturity”)」の二つの尺度が取り上げられています。 とはいえ文中では「図を参照」と書かれてはいるものの、その図は見当たりません。元記事を探してみるとアーロン氏の会社であるATD Solutionのブログ記事にたどり着きます。 記事によると、適応能力は複数の要素(“factor”)からなり、それぞれの要素は5段階の数値スコアで評価されます。全体評価はおそらくはスコアの平均で、0～1なら”Not Ready”、1～2.5なら”Partially Ready”、2.5～5なら”Ready”となるようです。 成熟度の尺度としてはTOGAFにも載っているACMMが紹介されています。「存在しない」「導入中」 https://iasa-apac.org/resources/ https://www.atdsolution.com/enterprise-architecture/article/when-to-implement-enterprise-architecture/ 「定義されている」「管理されている」「最適化されている」の、CMMIと同様の5段階評価です。 結論から言えば、タイトルとは全くかみ合っていません。どちらも既にEAプロジェクトが存在している前提での、その成果に対する評価です。成熟度モデル以前に、EAがそもそも普及していない現在の日本に当てはめてもあまり意味が無さそうです。 日本の場合、先の「EAは誰に必要なのか？」で挙げられた5つの「過ち」のいずれか一つにでも気づいたら、すぐに始めればよい、というのが答えになるでしょう。そもそもEAを始める上で費用は前提にならないので、たとえ疑心暗鬼でもとりあえず始めてみれば良いのです。 4. “Why Enterprise Architecture?” (なぜEAなのか？) 日本の端的に言えば「デジタル・トランスフォーメーションに不可欠だから」というのがこの記事の結論です。これだけならネットによくある紋切り型の謳い文句ですが、そこに至るまでの議論には注目すべき点があります。 まずアーロン氏は、ITベンチャーなどの「デジタル・ネイティブ」との対比として、普通の会社を「デジタル移民 (immigrants)」というユニークなことばで表現しています。「デジタル・トランスフォーメーション」とは「デジタル・ネイティブの生息域 (アーロン氏ではなく私の造語ですが、デジタル・ランドとでも呼びましょう)への移住、入植」といったイメージになるでしょう。一方、普通の会社の現在の生息域は、(これも私の造語ですが)、マテリアル・ランドとでも名付けてみます。マテリアル・ランドの住人が、デジタル・ランドに移住し、更にそこで成功をおさめれば、それが「デジタル・トランスフォーメーション」になるわけです。 問題は、マテリアル・ランドでの適応と進化に適していたやり方は、デジタル・ランドでは通用しないことで、それをアーロン氏は移民という比喩を用いて表現しているものと考えられます。何よりデジタル・ランドでの一番の価値は「知」であり、なんでもカネで買うことが出来たマテリアル・ランドの流儀は通用しません。マテリアル・ランドがかつてのように巨大な経済規模を誇っていれば「知」を買うことも出来たでしょうが、いまとなってはそれも叶いません。 つまり私たちにとってデジタル・トランスフォーメーションとは、必ずしも夢と希望に溢れた新しい「機会」を意味するとは限らず、むしろ慣れ親しんだ価値観や習慣から如何に脱することが出来るかという「試練」と捉えるべきなのかもしれません。 日本のアーロン氏はもう一つ、”Treating the enterprise (…) like a living organism”、つまり「企業は生き物のように扱え」と述べています。これも目からうろこで、アーキテクチャは静物画のように不変ではなく、生き物のように姿かたちを変えていくものだ、というわけです。 つまり、マテリアル・ランドに適応していた資産目録のようなアーキテクチャは、デジタル・ランドでは通用せず、デジタル移民は生き物のように柔軟で迅速なアーキテクチャを身に付ける必要がある、というわけです。 先述の「プロジェクト第一主義」こそ、「マテリアル・ランドの流儀」であり、それを捨てることなくデジタル・ランドに向かっても、成功どころか生存さえも危うくなりそうです。 5. Where to Start with Enterprise Architecture? (EAはどこから始めるか？) 先述の連載記事の最後です。どこから、という問いに対して「上から(トップダウン)のアプローチ」または「下から(ボトムアップ)のアプローチ」さらにはこのふたつを組み合わせたアプローチ、という3つの切り口で解説していますが、これもなかなか参考となる内容です。 トップダウンの出発点は「将来 (To-Be、またはターゲットとも呼びます)」です。一方ボトムアップは「現状 (As-Is、またはベースラインとも呼びます)」からスタートします。 トップダウン・アプローチは分析的、論理的で、一貫性、整合性の高い組織全体の構造をシームレスにデザインすることができますが、一方でハイレベルな戦略についての合意形成という時間のかかるプロセスが必要となること、現実にそぐわない、実現可能性の低いデザインになる恐れがあること、各専門領域を担当するドメイン・アーキテクトの創造性が損なわれる可能性があることなどの欠点の存在が指摘されています。 対してボトムアップ・アプローチでは、目下の課題に即応するための創造的、革新的かつ実用的なソリューションに取り組む機会をドメイン・アーキテクトに提供でき、その結果スモール・ウィン、クイック・ウィンが期待できます。但しそのスモール・ウィンが組織や企業全体の構造と、またクイック・ウィンが長期的な戦略やビジョンと、それぞれ整合しているかは事後に検証されるべきで、結果として大きな解離が認められれば、相応の時間やコストを掛けて是正措置を講じなければならず、全体で要する期間は結局トップダウンとあまり変わらない、という結末も有り得るでしょう。 アーロン氏はこの両方を組み合わせた「複合的なアプローチ」を用いることで、シームレスでアジャイルかつスピーディなアプローチによるデジタル・トランスフォーメーションが実現可能であると主張し、それをデジタルEAと呼んでいます。簡単にいえば、巨視的な構造はトップダウンで押さえ、微視的な構造はボトムアップで対処するアプローチ、ということになります。ここでも前項の「なぜアーキテクチャなのか？」で紹介された、ある種オーガニックな存在としてのアーキテクチャのイメージが連想されます。巨視的な構造はいわば「体幹」であり、その組織の「ストラテジックな特徴」を、また微視的な構造は「手足や感覚器」で、その「オペレーショナルな特徴」をそれぞれ示しているわけです。何しろ「デジタル・ランド」では環境変化が激しいので、「巨大な一枚岩の密結合システム」や「個別最適システムの寄せ集め」では進化どころか生存さえも覚束ない、と言えるでしょう。 6. EAの意義を伝えよう ご存じのとおり、アーロン氏は自社のブログやリンクト・インなどで活発に執筆活動を行っています。時折読んでみると、なかなか良いことが書かれていているのでお勧めです。 この記事ではつまるところ、企業や組織にとって、アーキテクチャといういわば形式知の方が、償却資産としてバランスシートに載っているITシステムよりも重要だ、ということを伝えています。 また、デジタル・トランスフォーメーションといった喫緊の課題は、IT資産の取得という旧来の方法では解決しない、ということを明らかにしています。 オールド・エコノミーでは資産の大小がビジネス規模を左右するので、時価の大きな企業の多くは資産規模も大きかった訳ですが、GAFAの時価が大きいのはIT資産を沢山持っているからだ、と考える人はいないでしょう。彼らの持つ知恵や知識と、それらを将来現実にする能力に価値が付けられているのであって、しかもそれらは彼らのバランスシートには載っていません。 アーロン氏を始め海外のEAコミュニティリーダーの多くにとっては、「自分の属する組織の未来を保証するのは、他者から買う償却資産ではなく、自分で描くEAである」ということは、既に「自明の理」なのかもしれません。 日本でも組織や企業のIT部門でも、将来それが同様に「自明の理」となるように、私もEAを広めるお手伝いに取り組んでいきたいと思います。 以上 ※ 本コラムについてのご意見ご感想お待ちしております。

Iasa日本支部では、これまで14回にわたり情報提供の一環としてコラムを配信してきました。今回からは、多くの皆様からの「米国本部のコンテンツを翻訳紹介してほしい」という声に応えるため、本部コンテンツを取り上げていきたいと思います。 Iasa米国本部はIasa Globalとしてホームページを開設しており、そこで多様なコンテンツを公開しています(註1)。コンテンツとして公開されているものは、カンファレンスの講演スライド、有識者へのインタビュー動画、技術記事やエッセイ等と多種多様です。 初回となる今回は、IasaのThought Leader（思索的リーダー）でもあるニック・ロザンスキー氏のインタビュー記事(註2)を取り上げます。彼は世界的に著名なアーキテクトであるとともに、日本語訳として出版されている「ソフトウェアシステムアーキテクチャ構築の原理」の著者でもあるので、ご存じの方は多いでしょう。 本稿はインタビュー内容を翻訳したものです。世界的な思索的リーダーが考えていることを少しでもお伝えできればと思います。 （インタビュー始まり） ■ あなたとあなたの仕事について教えてください 私の名前はニック・ロザンスキーです。この20年ほどアーキテクトとして働いています。 その長いバックロググラウンドには、1980年代半ばに開発者としてITの仕事を始めたことがあります。私は開発者として、（もちろん）設計者または要件アナリストとして、少しばかりプロジェクト管理の仕事をしてきましたし、アーキテクトとして約20年間働いてきました。 私がアーキテクトになることを決心したのはIT部門で出世し続けたかったからですが、多くの同僚みたいにマネジメント職志向ではいたくありませんでした。私の技術のバックグラウンドには、コンピューター科学の修士号とMSC（Master of Science）があります。 私はさまざまなテスト技術に取り組んできましたが、小さなシステムだけでなく大きなシステムや、企業規模のシステムで仕事をしてきました。ですので、専門家というよりゼネラリストです。数多くのことを少しずつ知っているといった感じです。まぁ、より多くのことを知っている領域が1つか2つありますが、いわゆる専門家ではありませんね。 ■ 最初にアーキテクチャについて考え始めたのはいつですか？ 1990年代後半、Sybaseプロフェッショナルサービスで働くことができたのは幸運でした。当時、SybaseとOracleでDBMS市場全体の約50%を占めていました。Sybaseには大規模なプロフェッショナルサービス組織があり、その中にアーキテクチャプログラムがありました。このプログラムには、アーキテクトのトレーニングや、アーキテクチャ関連の作業に使用できるさまざまな資料が含まれていました。 私はどういったキャリアに進むべきか考えていた頃、自身の仕事においてはテクノロジー的な要素に重きを置き続けたいと思っていたので、同僚のほとんどがプロジェクト管理に従事していましたがそれをしたくありませんでした。そこで、Sybaseを使用しているアーキテクチャプログラムのことを聞いたときそれに飛びつきました。そして私はSybaseの認定アーキテクトになりました。 Sybaseで取り組んだ仕事の多くには、アーキテクチャ的な側面がありました。今にして思えばアーキテクトと必ずしも言えるものではなかったかもしれませんが、システムの主要なコンポーネントがどのように連携しているか、そしてもちろんSybase技術を使ってクライアントの問題を解決するにはどうすればよいか、といった大きな概念を理解しました。 ■ ベンダーに所属するアーキテクトの倫理的側面をどうお考えですか？ それは非常に興味深い質問です。それに対する唯一の答えは、あなたが信じている製品のベンダーで働いているということだと思います。Sybase製品は非常に強力な製品セットでデータベースが非常に強力であり、他の関連するテクノロジーも強力だったため、Sybaseをソリューションとして顧客に推奨することについて何の懸念もありませんでした。もし、あなたが信じていないことを推奨するようにプレッシャーをかけられているなら、それを跳ね返さなければなりませんが、実際にはそれはとても難しいことですね。そのベンダーがあなたの日々の賃金を支払っているのですから、それに従う必要があります。 そう、それは興味深い質問です。もし自分が推薦している製品を信じていないのだとしたら、別の誰かのために働かなければならないのだろうと思います。 ■ 専門家としてのアーキテクトとはどの様な人とお考えでしょうか？ それは私はいつもこの質問を恐れています。しっくりくる答えを出すのはとても難しいです。外科医とは何か、エンジニアとは何かと尋ねられたらその質問に答えることができるでしょう。アーキテクトとしてそれをするのはとても難しいです。 システムのアーキテクチャは何か、という問いに対しての形式的な答えはあります。「システムを構成する要素とそれらの間の相互作用と情報の流れ」です。ほとんどの場で使われている形式的な定義ですが、人々が共感できるようなものではありませんね。 アーキテクトとは何か？アーキテクトとは、白紙の状態からシステムのアーキテクチャの定義をする人です。これも人の心に響く定義ではありませんね。外科医でしたら「病気を治し、死を免れるための手術を誰かの心臓に対して行います」と言えるわけですが、アーキテクトではそのようにはいきません。私がよくやるのは、“私がしていること”や“なぜ私がしていることが役立つのか”を説明し、最終的にアーキテクトとは何かを人々が理解してくれることを願うことです。 ■ では、何をしていて、なぜそれが役立つとお考えですか？ アーキテクトは何をするのか？アーキテクトはごく初期の段階で関わっています。ここでは、ソリューション・アーキテクチャに焦点を当てます。必要ならば、エンタープライズ・アーキテクチャについても説明します。 アーキテクトはプロジェクトのごく初期の段階に関与しており、また関与すべきです。初期段階では問題を抱えている上級の利害関係者がいます。解決する必要があるビジネス上の問題があります。彼らはそのソリューションがどのように見えるかについての考えを持っているかもしれません。アーキテクトが守らねばならない制約があるかもしれません。 私たちはMicrosoft WindowsやSAPを使用しています。それが何であれ、あなたができることを制限します。また、ソリューションがどのようなものになるかについてアイデアを持っているかもしれません。しかし、これらのアイデアは検証されておらずステークホルダーが利用できる状況にありません。アーキテクトが行うことはそこに到達することです。 利害関係者を特定します。ソリューションに対する彼らの関心ごとを特定します。利害関係者と協力し、プロセスへの参加を確実にするために何が必要か理解してもらいます。彼らの要求を確実に把握していることを確認し、ソリューションに向けて動き始めます。大きなホワイトボードを使って、ホワイトボードに枠や線を描き、最終的にはそれをソリューション・アーキテクチャにするのです。 しかしこれは問題の半分に過ぎません。すべての利害関係者に説明する必要があるからです。彼らがそれを理解し受け入れたことを確認してください。もちろん、それは反復的なプロセスです。なぜならあなたが知らなかったことを発見したり、あるいは利害関係者の1人がその方法で受け入れてはならないといったことを発言することもあるからです。もう一度戻って周りを見回し、最終的にはシステムのアーキテクチャが合意され、開発者や他の人に引き渡すことができるレベルまで文書化されるでしょう。これは、延々と続くアーキテクトの道です。 ■ アーキテクチャが継続的な開発作業としたならば、それにどのように対応しますか？ あなたの質問の意図に全く同意します。実際には、他の誰かが何かを始める前に、ある程度のアーキテクチャの基礎を作る必要があります。 ですから、少なくとも概要レベルのソリューション・アーキテクチャの骨組みのようなものを設計する必要があります。その中に主要な要素を含めます。そうしないと意味をなさないものをコーディングしてしまうからです。開発者はそれを使って作業を開始することができます。アーキテクトは、アジャイルかウォーターフォールかを問わずそのプロセスに関与し続けます。提案されたアーキテクチャのようなものを提供すると、開発者はコード、モジュールや構造などの観点からどのようなものになるかを考え始め、そのプロセスの一環としていくつかのものを構築したり、ステークホルダーとの継続的な関わり合いを始めたりします。 実際のところ、あなたはさまざまな方面の人たちと仕事をしているので、開発プロセスに関与し続けることはとても難しいことです。でも、あなたがそれに関与し続け、アジャイルなプロセスで対処し、リファクタリングや再設計などを行うといったことができるので、私はアーキテクトがプロジェクト全体を通して関与すべきであることに全面的に同意します。 ■ アーキテクチャの実践において、開発への関与がより増えると思いますか？ それはビルドの設計に移ったあと、あなたがアーキテクトとして何をしているかによります。私は、最近はそれほどでもないかもしれませんが、昔は設計やアーキテクチャにも関わっていました。そうでない場合、私はアーキテクチャを設計開発チームに任せます。 あなたは関与し続けなければなりません。それは個人的な関係がとても重要になるところです。ですので、私はアーキテクトとして多くの時間を会議や人との1対1のセッションに費やしました。ある領域で仕事をする時に私が望むことの一つは、主要な利害関係者全員と定期的なミーティングを設定することです。相手が誰であるかに応じ、週に1回、2週間に1回などです。彼らと一緒に座り、彼らが直面している問題にどう取り組んでいるかを話します。それはしばしば、あなたの注意を惹かねければならないようなアーキテクチャ上の問題点を、彼らとあなたが共有する瞬間となります。人と面と向かって接触し続けるのでなければ手遅れになるまで何かを発見することはできず、彼らが何かを作ってからそれが間違いであることを発見するだけとなります。 私にとっての課題は、今は開発者ではないということです。以前はかなり優秀だったのですが。最近では実際のところ深く技術に傾倒していません。JavaやC#のコードを書くよう頼まれることはありません。そこにおいて私に何ができるかという点、その状況における技術的な価値ということに関しては少し課題があります。これはすべてのアーキテクトが直面する課題だと思います。 ■ エンタープライズ・アーキテクトとソリューション・アーキテクトの関係を説明していただけますか？ 最も単純なレベルで言えば、エンタープライズ・アーキテクトとソリューション・アーキテクトの関係は、扱っている対象の範囲に過ぎません。つまり、ソリューション・アーキテクトとしては一貫性のあるソリューションを形成するシステム、あるいは2つか3つのシステムを扱うことになります。エンタープライズ・アーキテクトとしてはビジネス部門や組織の一部、あるいは組織全体を扱いますが、その場合アーキテクチャのコンポーネントは通常システムそのものであり、データ・ストアやその他の性質を持つシステムです。 あなたの質問に対して饒舌な答えをするならば、実際には両者はかなり違います。エンタープライズ・アーキテクトは明らかに、担当するステークホルダーのレベルがシニアとなる傾向があります。したがって、シニアIT管理者であるCIO、ビジネス・ステークホルダーはCEO、ユーザーはスポンサーのシニア・マネジメントである可能性があります。したがって、より抽象的なレベルで作業する傾向があり、受け答えする質問はより広範でかつ技術に特化されない傾向となります。ですから、エンタープライズ・アーキテクトとしては、ある特定の技術的な質問に対して答えを求められることは稀です。 もう一つの違いは相手の優先順位が違うことです。エンタープライズレベルでいえば、それは企業の戦略とビジョンに関することです。クライアントや顧客、ビジネスユーザーへのデリバリーに関することことです。予算や支出などの大きな問題に関することです。 私が思うに、エンタープライズ・アーキテクトの世界の方がソリューション・アーキテクトの世界よりもずっと大きな問題があると思います。より戦略的になる傾向にあります。つまり、エンタープライズ・アーキテクチャは、戦略的に優れた方向に組織を導くということです。一方、ソリューション・アーキテクトはより焦点を絞っています。システムを提供する必要があり、それを来年までにする必要があります。 ■ これから将来に目を向けたとき、アーキテクトはどこに向かうと思いますか？ いままで目立つこともなくあまり理解されてこなかったアーキテクトというものが、この10年ほどの間で変わってきているのを見て、私は非常に勇気づけられています。私が5年間携わってきたすべてのプログラムやプロジェクトにはアーキテクトがいて、最近も多くの採用活動をしてきました。ですが、すべてのプロジェクトがこれに取り組むには変化が必要であり、まだまだ長い道のりがあると思います。 この広い業界では、アーキテクトが何をするかについてほとんど意見が一致していないと思います。2人のアーキテクトにどんな仕事をしているのか聞いても、いく通りもの答えが返ってきます。私が見てきたような組織はそれを実現しようと懸命に努力しているので、アーキテクトが役割としてもっと確立され、アーキテクトが何をしているのかについてもっと明確で一貫性があるようにしたいと思います。そうしなければならないと私は確信しています。アーキテクトに対して本当に何を求めているのか分からないため、アーキテクトを募集するのはとても難しいのです。「私こそがアーキテクトだ」と言う人もいれば、「もっと広い範囲のことをしている」と言う人もいて非常に多様です。プロジェクトマネージャやC#の開発者やテスターを雇うのも難しいですが、合理的なコンセンサスがありますよね。それは変わらなければならないと思いますしきっと変わると思います。アーキテクチャは組織におけるキャリアパスとなり、人々がそこでキャリアを積むことに対して不安を感じなくなると確信しています。昔でしたら、人々の多くはこの役割を引き受けたくないと思ったでしょう。なぜなら、それがどこに向かうのかわからなかったからです。それは変化しており、今後も変化していくと思います。 テクノロジーが急速に変化しているのは明らかであり、インターネットやIOT、クラウドはその類のものです。この数年に気づいたことですが、古き時代にはソリューション・アーキテクトは全てのこと、サーバやネットワークやデータベースについて考えなければなりませんでしたが、現在ではそこにインフラストラクチャがあると仮定したうえで、専らアプリケーションとデータアーキテクチャに焦点を当てています。これは今後も続くと思いますし、その基準(bar)はさらに上がっていくでしょう。 次の10年で明らかに状況が変化すると思います。 （インタビュー終わり） いかがでしょうか。インタビューから伝わってくるのは、自ら推奨するソリューションやテクノロジーに対する彼自身の深い愛着、そしてアーキテクチャによって顧客の課題を解決するアーキテクトとしての信念と自負です。アーキテクトとして歩む道のりは、決して平坦なものではありません。プロジェクト初期のカオスな状況において、多くのステークホルダーと対話し、アーキテクチャデザインで秩序をもたらし、組織を前進させることにアーキテクトは関与し続けていくことが求められます。であるからこそ、深い愛着や強い信念と自負が不可欠なのだろうと考えます。また、全てのアーキテクトが直面する課題として、自らの役割や提供価値を変革していくことを常に意識していかないとならないでしょう。インタビューで語られるように、次の10年も変化の時代であり続けるでしょうし、その変化を牽引するのはアーキテクト自身なのですから。 今回はIasa米国本部コンテンツから、ニック・ロザンスキー氏のインタビュー記事をご紹介しました。本記事についてのご意見・ご感想をお聞かせください。 註） 1.“Videos,Articles,Content”,Iasa Global, https://iasaglobal.org/Public/Public/News/News.aspx 2.“Software systems Architecture with Nick Rozanski”,Iasa Global, https://iasaglobal.org/Public/News/Articles/Software-systems-Architecture-with-Nick-Rozanski.aspx