若手社員とエキスパートがテクノロジーについて語る、「ITアーキテクチャ設計とは」

ITアーキテクチャは企業のビジネスの在りようを映す鏡

玉置：最初に基本的な質問です。「ITアーキテクチャ」とは何を指すのでしょうか。

木村：「ITアーキテクチャ」という言葉の定義は、業界や企業の立場によって異なることがあります。例えば、IaaS（Infrastructure as a Service）と呼ばれるITインフラのレイヤーを指す人もいますし、PaaS（Platform as a Service）のような開発プラットフォームを指す人もいます。ただし今回フォーカスしたいのは、業務アプリケーションのレイヤーとそれらのつながりです。一般的にビジネスで「ITアーキテクチャ」という場合には、この領域を意味します。

玉置：その大前提を理解していないと、クライアントとのディスカッションの中ですれ違いが生じてしまう可能性がありますね。

木村：現在のビジネスはITシステム抜きには考えられませんが、企業の目的はビジネスを成長させて社会の発展に貢献することであり、ITシステムを構築することではありません。「効率的にビジネスを成長させるITシステムとは何か」を考え、それを具現化したものがITアーキテクチャです。いわば、企業におけるビジネスの在りようを映した鏡のようなものです。ITアーキテクチャには、その企業がどのようなビジネスをしたいのか、今後どのような企業に成長したいのかが反映されていると考えてください。

玉置：「ITアーキテクチャは企業のビジネスの在りようを映す鏡」という表現は腑に落ちます。

木村：例えば、M&A（合併・買収）や事業設立などの経緯から、グループ企業内で重複するビジネスファンクションを保持することがあります。その場合、企業全体の効率化を図るために、組織の統合を考えなければなりません。なぜなら、1つの企業内で同じファンクションのシステムが複数稼働していれば、組織統合しても十分なシナジーが得られないからです。ビジネスの変革を行う際には、必ずと言っていいほどITアーキテクチャの改革が必要になります。

ITアーキテクチャの構築はSaaS（Software as a Service）を第一に考える

玉置：次にITアーキテクチャ構築の進め方について教えてください。クライアントの将来的なビジネス像を理解し、それに向かってITアーキテクチャを設計するとのことですが、一筋縄ではいかない作業であると感じています。どのように進めていけばよいのでしょうか。

木村：まずはクライアントが公開している中期経営計画やIR情報など、クライアントの社内資料などを読み込むことです。クライアントが目指している方向性を把握し、そのうえでクライアントにインタビューします。「クライアントと同じ土俵に立つ」という意味においても、こうした作業は必須です。

当たり前ですが、クライアントのビジネスを最も理解しているのはクライアント自身です。外部のコンサルタントがどんなに中期経営計画やIRを読み込んでも、クライアントと同レベルの知識が身に付くわけではありません。こうした作業はクライアントと話し合えるだけの知識を身に付けるためです。業界の知識はもちろん、クライアントのビジネスモデルや事業別利益、組織構造なども理解する必要があります。

玉置：話は少し脱線してしまいますが、「クライアントの将来的なビジネス像」は揺るぎないものなのでしょうか。例えば、M＆Aや企業内組織の大改変があった企業では、現場で意見の相違があってもおかしくないと思います。

木村：確かにM＆Aや事業統合などによって、これまでの業務とは違う業務に就く部門がITアーキテクチャの構築に協力的でないケースはあると思います。

私たちにできることはクライアントのトップを巻き込むことです。企業が示した中期経営計画は、会社が目指したい方向性を明確に示した「錦の御旗」です。ITアーキテクチャの構築はそれを実現するためのIT改革ですから、反対する大義はありません。そのことをクライアントのトップに理解してもらい、従業員が同じ目標に向かって進めるよう社内の機運を醸成してもらうことが大切です。

玉置：具体的にITの仕組みを検討するには、何から実施するのでしょうか。

木村：現状においては、SaaSの利用を検討することが第1の候補です。SaaSのメリットは迅速に導入できることです。また、昨今では業界特化型のSaaSが多数あり、一部のSaaSは業界のデファクトスタンダードになりつつあります。業界特化型のSaaSはアドオンやカスタマイズを大幅に削減できますし、コストの抑制も期待できます。

また、こうしたSaaSを活用するもう1つのメリットは、業界標準として必要な機能が迅速にアップデートされることにあります。逆に、カスタムで作り込んだシステムであれば、自分でアップデートしなければなりません。ただし、そうしたプロジェクトには失敗がつきものですから、ある程度のリスクを伴います。そのリスクを極小化できるのがSaaSなのです。

玉置：まずはSaaSの導入を念頭にITの仕組みを検討するのですね。その他に留意すべきことはありますか。

木村：気をつけなければならないのは、システム間の境界線を決めるところです。それぞれのSaaSやソフトウェアを比較すると、機能的な重複が必ずあり、どちらを利用するのかが議論になります。この課題を解決するには、外部の調査や同じSaaSやソフトウェアを導入しているユースケースなどを参考に検討する必要があります。また、必要であれば、SaaSやソフトウェアを提供しているベンダーにヒアリングをして決めていきます。