DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

前回ブログでは、DX（デジタルトランスフォーメーション）を標榜する昨今のITプロジェクトにおいては、「ビジネス貢献」と「IT構造の転換」が車輪の両輪であることを述べました。その実現に対し、誰が説明責任を果たすべきなのでしょうか？私のこれまでのブログをお読みなら、そこにITアーキテクトが大きな役割を持つことはお判りと思います。しかし、それは言葉で言うほど簡単な話ではありません。今回は、アーキテクチャにおける説明責任とはどういったことで、それが企業にどんな価値をもたらすのか考えてみたいと思います。

＊＊＊

＜説明責任の不在＞
昨年、7Pay問題が世間を賑わせました（変化の激しい現代においては、これも一昔の感覚かもしれませんが）。振り返れば、基本的なセキュリティ考慮がなされていなかったといった基本的な問題もさることながら、その設計判断がどういう経緯から為されたのかが外部から全く見えないということが、市場の納得感や信頼感を損なう理由になったと思います。そのシステムが持つ設計思想に対して、誰が説明責任を果たすかが曖昧だったということです。その結果として、ビジネスの打ち止めを余儀なくされました。
「原因が不明」という最大の問題。7payのセキュリティ問題を考察する
7pay問題、本質は「船頭不在」にあり

「なぜそういう仕組みになっているのか？」「それによって利用者はどういう（負の）リスクまたは（正の）ベネフィットがもたらされるのか？」「（負の）リスクに対してどう対応していくのか？」。こうした説明責任が十分に果たされることのないITサービスは、市場からNGを突き付けられるでしょう。それは、BtoCのITサービスに留まらず、あらゆるITシステムにあてはまります。にも関わらず、説明責任に対してあまりにも無頓着な企業が多いように感じるのは、私だけではないと思います。

＜ITアーキテクトが果たすべき説明責任＞
ITアーキテクチャの説明責任と言われた時、具体的にどのようなことを指しているでしょうか。パッと思いつくだけでも以下のようなことがあげられると思います。
① 恩恵（または制約）を受けるステークホルダー
② ビジネス課題、ニーズ、および制約条件
③ アーキテクチャ要求
④ アーキテクチャのコンセプト、実現方針。その採用理由
⑤ アーキテクチャ構成要素とその関連
⑥ 構築ロードマップ、必要な組織体制、想定する費用、期間、スコープ、リスク
⑦ 標準化の考え方、品質の考え方、完了基準

他にもあるかもしれませんが、個人的にはここにあげたようなことが答えられないようなら、説明責任を果たしているとは言えないと思います。しかし、経験を積んだITアーキテクトにとっても、これらに適切に答えることは簡単ではないでしょう。人間の心の働きには「知」「情」「意」があるといいます。「知」は知識や思考を活かすということ。「情」は感情を感じるということ。美的感覚も含まれるでしょう。そして、「意」は決断する意志をいいます。こうした心の働きを最大限に動かして、はじめて答えることができるものなのかもしれません。その答えそのものが、ITアーキテクトの作品とも言えるものでしょう。この作品はさらに、他者に理解できるように表現され、文書化され、プロジェクトを通して改善と検証のサイクルが回されていきます。こうした活動を「アーキテクティング」と呼びます。

＜プロジェクトにおけるアーキテクチャ組織の類型＞
「アーキテクティング」がプロジェクトのなかでどのチームに担われるのかは様々です。しかし、一般的に次の３つの類型に分けることが出来そうです。なお、誰に尋ねたらいいかわからない、というのは論外とします。

１． ボトムアップ型
デリバリーチーム自身が、説明責任をもつケースです。最近はアジャイル開発が広がっていますが、自己組織化された高いITリテラシーを持つデリバリーチームの場合、こうしたスタイルとなるかもしれません。前回のコラムで企業IT利活用ステージを紹介しましたが、その初期段階（部門内最適化企業群まで）でも多くみられます。メリットは、判断スピードが早いこと、最適なアーキテクチャが採用される可能性が高いことです。半面、チームが得意な技術に片寄ったり、多くの目にさらされることによって良いアイディアを生むといった機会が得にくい、といった落とし穴に要注意です。

２． トップダウン型
プロジェクト外部にアーキテクトチームがあるケースです。最近ですと、DX（デジタルトランスフォーメーション）推進の専任部署もここに含まれるかと思います。企業IT利活用ステージでは、企業全体最適化企業群のレベル以降で多く見られます。ビジネスレベルに近いこともあり、企業レベルでのITガバナンスや全体最適に特化していると言えるでしょう。半面、デリバリー部隊から距離を置くため、現実から乖離したあるべき論に走る（IT業界では象牙の塔アーキテクトと揶揄されます）ことのないよう注意が必要です。

３． ミドルアップダウン型
このタイプは、プロジェクトマネジャー直属チームとしてプロジェクト内を横断的に見る位置に配置されます。ビジネスレベルとデリバリーレベルの両方に接点を持ち、３つの類型では最もバランスが良い形と思います。プロジェクトマネジメントと健全な牽制関係を築き、不確実性と変動性が高い昨今のプロジェクト環境では、この位置にアーキテクト組織を配置することが望まれると考えます。半面、多大なエクスポージャー（発生する可能性のあるリスクの全て）にさらされることで情報過多となり身動きが取れなくなるなど、ボトルネックとなる懸念もあります。ビジネスとテクノロジーの間のバランス感覚が要求されます。

一概にどれが正解とは言えません。しかし、私はどんな場合でも、特定のチームに説明責任が押し付けられるべきではないと考えています。今までのブログで再三取り上げた、２つのギャップを肯定してしまう理由付けに使われやすいからです。今まで私は、プロジェクト内で孤立するアーキテクトを多く見てきました。結局そうした状況から生まれる歪みは、それぞれの類型であげたデメリットを顕在化させてしまいます。理想を言えば、３つの類型にあたる各階層において、それぞれの役割に応じたアーキテクチャ組織を立ち上げていくことが望まれます。プロジェクトマネジメントの世界では、プログラムマネジメント組織とプロジェクトマネジメント組織があります。アーキテクチャ組織も同様に考えていくべきでしょう。

＜BAとPMとITAの有機的つながりを目指して＞
ITアーキテクチャに関わる説明責任は、プロジェクトに関わる全てのステークホルダーの関心ごとです。決して他人事とできるものではありません。説明責任の内容をご覧いただくとわかるように、ITアーキテクト単独で決定できるものは限定的です。例えば、①②③はBA（ビジネスアナリシス）からのアウトプットが不可欠です。プロジェクトマネジャーとの協調がなければ⑥⑦を定義することはできないでしょう。よって、ここであげた項目は、アーキテクトの作品であると同時に、BA（ビジネスアナリシス）とPM（プロジェクトマネジメント）との共同作品とも言えます。どうせ説明責任という言葉を使うなら、「説明責任の共同所有」という考え方も取り入れてみませんか。きっと、プロジェクトという空間が、より人間らしい活き活きとした場に変わっていくと思います。

企業の方々から、「BAとPMとITAがどう繋がるのかよくわからない」という声を聞くことがあります。しかし今回のブログでお話ししたように、ITアーキテクトがプロジェクトにおいて自らの説明責任を果たすには、BAとPMとの関係性は不可欠です。前回ブログで、私は「もはや一人の優秀なProject Managerが引っ張っていくという時代ではなくなってきた」と書きました。これは、ITアーキテクトについても同じことが言えます。お互いがその関係性を強めていくことで、個々の能力よりも高い能力を全体として発動していく。その関係性を通して、画期的なソリューションやイノベーションを生み出していく。これからのプロジェクトアプローチはそういう姿になっていくと思います。

＊＊＊

英語では、「腹を割って話す」ということを「a heart‐to‐heart talk」と言うそうです。プロジェクトの場が、「全員で腹を割って話せる」ような協調の場となれば素晴らしいですね。次回も、引き続きプロジェクトにおけるアーキテクチャ活動を考えていきます。
お楽しみに！