DXで求められるIA（インフォメーション・アーキテクト）の役割
最近、DX（デジタル・トランスフォーメーション）という言葉をよく目にします。
書店でも、ネットニュースでも、そこかしこで「DX」が注目されています。
これほど流行り言葉になっているのに、DXの成功事例よりも遥かに多く、
「このプロジェクトうまくいっていない…」
「思ってたのと全然違う」
ということを耳にします。
失敗する理由はいくつかあると思いますが、
僕はその原因を次の６つで分類しています。
上層部の意思決定の問題
ビジネス視点での再設計・戦略の不足
脆弱なプロジェクト体制
内部スタッフの教育の問題
増改築されたアーキテクチャ
先端技術への理解不足
例えば、完璧に近いほど緻密に設計されたUX。
良質な体験を可能にするアーキテクチャがあったとしても、意思決定する上層部が「いまいちピンとこない（≒説明されてもよくわからない）」という理由で予算削減。「社内浸透が伴わず頓挫」するようなケース。
反対に、意思決定者がDXに対して好意的。
この潮流に従って、自社サービスを変革しようと外部コンサルをアサインするも、上層部の顔色ばかり伺って実務・現場が置いてけぼり。挙句、内部スタッフの育成が全く進まないまま「自走できずに頓挫」するようなケース。
どちらもよくある話なのですが、１つ言えることは、こうしたプロジェクトを「組み立てられる人」がいない問題。そして、相手の目線に合わせて「翻訳できる人」が業界全体で圧倒的に少なくなっているという事実。
ここに尽きるのだと思います。
10年ほど前、僕は独立する時に名刺の肩書きを「インフォメーション・アーキテクト」と名乗りました。
コンサルタントでも、プランナーでも、
ストラテジストでも、ディレクターでも、
UXデザイナーでも、UIデザイナーでもなく、
「IA（≒インフォメーション・アーキテクト）」としました。
IAには、アプリやサイトを作る時の「情報設計」を担当する人、というとても狭い意味合いから、目前に散見する課題に対して、ビジネスをどのように変革していくかを論じる広義の意味でのBIG-IAまで含まれると考えています。
そこで、今の時代に求められるIAの役割についてまとめつつ、DXプロジェクトに必要な「翻訳者」としての立ち振る舞いについても言及しようと思います。
DX人材の圧倒的不足
DXが頓挫する根本にあるもの。
それは「ものごとを組み立てられる人」が不足しているためだと書きました。これは統計資料でも同じことが言及されています。デジタル・トランスフォーメーションを進める際の課題について、
DXプロジェクトの主導者、ITのスキルセットを併せ持った人材が不足している
2030年にはIT人材がおよそ45万人（※最大で79万人）不足する
という試算も出ています。
僕は、この記事を目にして「単純な話ではないな」と思いました。というのも、
クライアントのビジネス理解
業界に対する知見
チームの組閣と主導者としてのリード
課題解決と新たな収益化の構想
自走化できる枠組みの準備
人材の教育体制
そもそも、これらをやりきれる素養にプラスして、「特定のITスキル」を持つ「上位互換のゼネラリスト」、そんな人は業界全体を見回してもほとんど見つかりません。
一般的にIT人材と聞くと、おそらくバックエンド／フロントエンドのエンジニアをイメージされると思うのですが、そうした成果物は徐々に平準化されていく。
上で求められる主導者としての立ち回りは、こうした平準化とは対局にあるものです。物事≒プロジェクトの姿形を、初手として輪郭を描き、組み立てていくことが求められます。
物事を「組み立てる」とは何か？
ここで言う「組み立てる」とはなにか。
僕は頭の中でこんな風に捉えています。
DXプロジェクトは、
クライアントの思惑・どうなりたいか（ビジョン）
市場環境における置かれた立場（ポジショニング）
人的・金銭的資源（確保できるリソース）
効率化を見据えた事業構想（システム）
ect
さまざまな要因をもとに課題感が変化していきます。まるで生き物を取り扱うような感覚に近いです。
そこには「このフレームワークを使えば全て解決する」という銀の弾丸が存在しません。
何もないところから形をつくり、目指すべき未来の姿を想像する必要があります。プロジェクトの先導者として、これら一切のことをまさに「デザイン」していく。
システム開発の流れの中で、「要件定義」というものがあります。が、それと似ているものの異なる点が１つあります。それは、最上層部の意思決定者に対して翻訳する（≒そうした役目を拝命することが多い）ということ。
このプロジェクトの意義、目標が達成されたあとに、今後のビジネスにどのように寄与するか。もちろん、先導者が考える「論理」が破綻しないように提言することが大前提です。
しかし、それを意思決定者に一字一句説明しても全く響かずに終わってしまう。論理で人の心は動かない、とはよく言ったものです。
相手に伝わる言葉、相手が腑に落ちるスライドをもって、自分に任せてもらえたら結果を残せると共感してもらうこと。
異なる立場、その人の目高に合わせて「論理ではなく感性をもって翻訳する」ことで、プロジェクトをリードする。そのために「必要な情報はどんな些細なことでも漏らさない」という考え方が必要になってきます。
「単純な話ではない」
と、冒頭に書きました。
自分の学生時代〜社会人初期を振り返ると、こうした答えのない物事をどのように計画して進めていくか、ということについて訓練されたことがない。クライアントからの相談事項、案件を通して経験として得てきたものがベースになっているのです。
今後、物事を「組み立てられる側」の人材を増やそうとしたときに、そうした教育システムは必ず必要になってきます。その辺りのことも、僕なりの考えがあるので、近日中にnoteに書こうと思います。
話をDXの中での「IA」に戻します。
ウェブ開発におけるアーキテクト
DXの中での広いアーキテクトの話をする前に、まずはウェブサイト、モバイルアプリ開発における「IA」についてまとめておこうと思います。
IAの歴史はとても古く、由来の１つは「図書館情報学」にまで遡ります。
図書館の中の無数にある蔵書から、ユーザーが求める特定の本を抽出する時に、どういう手がかりで検索させるのがよいか。これらを含め体系的に研究する学問となります。
試しに好きな本を思い浮かべてみてください。
その本を誰かに説明するときに、相手にイメージしてもらうには、次のような輪郭をもって伝えることになるでしょう。
年代
著者
国内（海外）
出版元
ジャンル
内容（キーワード）
こうしたパターンをデータ化し、本の格納と検索しやすくするための方法論をまとめていく。これは「情報を分類し、最適なカテゴリ化と道筋となる導線を模索していく手続き」と同じであり、まさにインフォメーション・アーキテクトの源流にあると思います。（※僕自身が図書館情報学を学んだことはないため、理解不足があるかもしれません。）
古い歴史をもつIAですが、狭い範囲のIAについて「何をする人なんですか？」と質問されたら、次のように答えています。
普通に生活しているだけで、
日々、取り扱う情報は無数に生まれる。
その情報は、勝手に増えていく
（≒発散しがちなもの）。
散らばったままだと、どうしようもない。
そこで、情報をまとまりよく、
誰もが理解できるルールで整理していく。
IAは「情報の建築家」です。こういう説明をすると、
「UXやUIデザイナーとも違うんですか？」
と質問されることがあります。
日本だとインフォメーション・アーキテクトという存在事態が馴染み浅いものなので、混乱を招きがちです。
例えば、UIデザイナーの観点で行くと
xDやFigmaに代表されるアプリを使用
前提となるデザインシステムの存在
多種多様なテンプレート候補
一定の基準を学ぶと再現性が高い
技術のコモディティ化が顕著
IAが考えたカテゴライズ、導線、ルールに従って、画面≒インタフェースとしての機能性を考えたデザインを実現していく存在。
実際に、IA→UIデザイン、その両方を担当する場合もあります。
住宅に例えると、それは「建築家」と「インテリアコーディネーター」のように、両者には明確な差異があります。
DXに不可欠な全体像のアーキテクト
以上が、ウェブ開発における狭い意味でのIA。
では、DXプロジェクトおけるIAの役割ってなんだろうか？というところ。
つまり、広い意味でのIAの役割ってなんだろう？ということを詰めていこうと思います。
僕は、広い意味でのIAの役割をこんな風に捉えています。
クライアントが直面している課題に対して、どのように事業変革を進めていくか。
それを論じるためには「成果へのコミットメント」が必要不可欠です。
与えられた課題に対して、
DXプロジェクトの主導者として、
どうあるべきかの問いを設定→戦略を立案し実行していく者。
それは、クライアントのビジネスモデルを大きく変える可能性が高いため、PMO（≒Project Management Officer）内部での調整と提言にとどまりません。
取締役などの意思決定者への翻訳と、彼らの意思決定の補佐をする役目を司る。
彼らは尋ねてきます。
「この構想を実現するのに、どの程度の人と予算が必要か？」
「この構想が実現した後の、ビジネスインパクトは？」
「自走化に辿り着くための期間、人材の教育方法は？」これに対する回答は単なるウェブ開発案件の要件定義から導かれるものとは異なります。≒視座が異なるわけです。
ウェブ開発プロジェクトの要件定義項目
これは僕がよく使う要件定義の項目です。
一見すると、彼らの質問に答えられる内容が揃っているようにも見えますが、実際にはそうもいきません。
ウォーターフォール型のウェブ開発案件とは異なり、求められる回答には、その「範囲」も「規模」も「深さ」も、だいぶ差がある内容になります。
それらを理解した上で、感性的な表現になってしまいますが、
クライアント以上に、そのビジネスと顧客を理解し、成果にコミットする主導者になりきれるか。それを持ち続けない限り、意思決定者の補佐や判断を促すことは難しいと思います。
DXの５段階モデル
上で書いたようにプロジェクトのあり方や、その範囲、規模感、ビジネス理解の深さなども含めて、DXプロジェクトの全体像をざっと掴むなら、次のモデルが役立ちます。
トニー・サルダナが、著書「なぜ、DXは失敗するのか？」で提唱しているDXのロードマップです。
ステージ１として挙げられる「単なるオートメーション化（≒デジタライゼーション化）」から、ステージ５として「企業が業界をリードするイノベーター」として君臨するため、自走化までの道のりを体系的にまとめています。
ただ、これはプロジェクトメンバーが、今回の取り組みに関して「どの段階を目指したもの」なのか、その対象範囲を知るためにわかっていた方がズレが少なくなる「一般的なロードマップ」に過ぎません。
広義のIAが設計するDXプロジェクト全体像
広い意味でのIAが、アーキテクトとしてプロジェクトを設計する際に、どんな視点が求められるのか？僕はDXプロジェクトをこんな風に捉えています。
その昔、Jesse James Garrett 氏がまとめた5 planes modelという構想があります。
それは、システムやウェブ開発は、表層的なデザインを行う前に、プロジェクトの目的や要件を整理し、利用者に対して提供できる価値、アーキテクトとしての骨格や構造を定義することが大切である、というものです。
このモデルはUIデザインの文脈に偏りすぎているため、DXプロジェクトの場合、IAが考えなければならない対象範囲をだいぶ広げておく必要があります。
たとえ、同じプロジェクトの中に、
ストラテジスト、ビジネスプロデューサー、ディレクター、UXデザイナー、エンジニアといったその領域の専門家がいたとしても、です。
「なぜそんな泥臭いことを、IAがやらなきゃならないか？」
抽象化された思惑を達成するために、具体的な実施内容へ落とし込む。
１つ１つの具体的事象の集まりを、とりまとめた抽象的概念へ昇華させる。
DXプロジェクトでは、このような具体と抽象を常に行き来しながら、全体を見渡した行動（≒アジャイル的）が求められます。実は狭い意味でのIAが、日々、設計作業で鍛錬しているスキルだったりします。
そのため、DXプロジェクトにおける先導者は、鳥の目になれるIAが担当するのが一番であり、そのプロジェクトを成功へ導く存在だと思っています。
他の専門家の領域まで一歩足を踏み込んで、全体をリードしていく。
DX化が求められる時代において、
そんな役割が僕たちIA≒アーキテクトには求められています。
この記事が気に入ったらサポートをしてみませんか？