オープンネットワークでは、1つに向かう目的があるとブレない
山本築氏（以下、山本）：先ほど、清水さんから「ITの在り方は使用料を取っている」と話がありましたが、製品（を）ドーンと（入れる）時に、ヨーロッパが反対してくるとか、アジアのこの国が反対して「お金を払いたくない」とか、ユーザーはお金がないと言っているとか、そういうことはなかったですか。
清水博氏（以下、清水）：いい質問ですね。そういう意味では、そこまでまだガバナンスを効かせることはできていません。
山本：それで言うと、先ほど言った、経営者に最初に理解してもらうところからですか。
清水：そうです。ヨーロッパにもIT担当者がいるので、そこと一緒にやっていくことになります。コミュニケーションでいうと、Microsoft 365の世界ではヨーロッパとテナントが今は分かれているから、潜在的なコミュニケーションとしての課題はあります。
その状態でも、お互いにオープンでネットワークに出ていけば、いくらでも方法はあります。IT部門が世界中で1個というのはあり得ないので、絶対（コミュニケーションが）回らないですよね。そもそも昼も夜も逆転しているのに、どうやってやるんだという話です。
そういう意味で、国内は（拠点が）一応完全に1つしかないので、ヨーロッパと日本のガバナンスにおいては違いはあります。
山本：さっき言ったように、目的がオープンネットーワークだと、ワークスペースはここの一つに向かうんだ、と。ここがあるとぶれないということですね。
清水：私はそう思います。やり方はともかく「オープンのコミュニケーションは不要だ」という人も今のところいません。「ネットワークで専用線って本当に要る？」というビジネス的なことは今は置いておいて、「これはないほうが絶対に便利だ」というのもわかっています。それはむしろあったほうがいいと言う人はあまりいません。
それをどうやるかというだけなので、やらなければいけないことは、実はどこもかしこもわかっているはずです。でも、日本のベンダーに責任があると私は思うのですが、実行するうえで「どうやればいいんだ」というところがないので、なかなかHowを教えてくれません。私のもっている基準は、やはり自分たちで考えないとダメだということです。
中野仁氏（以下、中野）：あと、FAT（Fairness、Accountability、Transparency）の設定が派手に間違っていることはよくあります。
清水：それはもう論外だと思います。
自分たちでビジョンや方向性を制定するからアーキテクチャで思想性が読み取れる
中野：（スライドを示して）清水さんにいただいたまとめが、やはりすごく重要だと思っています。中長期ビジョンがないといけないし、中長期ビジョンでオープンワークスペースの構築や、グローバルと最終的にくっつけていくような話をした時に、「それを前提としてどうやってやっていくんだっけ？」という話だからです。
私が最初に清水さんのアーキテクチャの絵を見たのは、たぶん2020年だったと思いますが、その時に「ああ、この絵は完全にグローバルのロールアウトを前提としているな」と一瞬でわかりました。
思想性があって、最初の段階で一気にグローバルに出れば、バイインスタンスは1つの契約では無理だけれど、最終的に乗るような選択肢も取れる。例えば、他の会社と他の各リージョンとをくっつけようと思えばくっつくようなかたちで作っていけるということが明確にわかります。
それがアーキテクチャ上に出ているのは、結局は基本コンセプトとして、ビジョンや方向性みたいなものを自分たちで制定しているから読み取れるんだと思います。それすら読み取れなくて、何がしたいのかよくわからないアーキテクチャを持っている会社は、けっこう多いです。
清水：「私（清水）が実現したいんだ」と思っている方もよくいます。これっぽっちも（そんな思いは）ないですけどね。そうではなくて、未来に対して不確実だからこそ、選択肢を多く持っているだけなんです。
選択肢は本来無限にあるはずですが、そういうもので会社が回るわけではない。ある程度の骨子や枠組みがあるからこそ、よく言われる“自由の中にある不自由さ”とか、“不自由だから自由がある”とか。これはすごく大事な概念だと思っています。
いわば白紙を渡されて「なんでも書いていいよ」というのはけっこう難しいです。テーマや骨子があるからこそ、より精度の高いものが出てくるのですが、「なんでもいいよ」と言われたら、ものすごく品質の低いものしか出てこないのが現実です。
アーキテクチャそのものはよく建物の設計図に表現されますが、それは作る直前に渡しておけばいいんです。家と一緒で正しく作れます。（ただ、）設計図もないのに「今から掘るぞ」というのは無理です。
正しく作るための設計図は、今書いているモバイルの話とは少し違います。“道標となるようなアーキテクチャ”という位置づけなので、図のとおりに作ればいいというものではありません。
未来に対して選択肢を1つでも多く持っておけば、何かあった時にその選択肢に対してきちんと全体の骨子が合っているか、マッチングしてるかどうかを見極めたうえで、新たな技術を入れたり、新たな戦略を立てたり（できる）。中野さんが見たアーキテクチャはそういう位置づけで考えています。
中野：個別のソリューションどうこうは仮であって、システムは本当は必要性とトレンドにおいて入れ替えられなくてはいけません。ただ、その役割みたいなもの。英語でいう文型のように、「何をどこに配置するんだっけ？」みたいなものは、ある程度共通のものがないと、議論がまともにできないと思っています。その設計図みたいなものは置いておいたうえで、「何にするんだっけ？」という会話ができるようになります。
（スライドを示して）清水さんの絵はだいたい3層なので、抽象化するレイヤーを入れておかないと（いけない）。固定化して直つなぎになってしまうと、SOR（System of Record）とSOE（System of Engagement）でまったく身動き取れなくなるとか、段階移行もできないというような会話は私もよくします。「基本的な考え方を持っているのは重要なんだ」というところは非常によく似ています。
きちんとしたシステム方針を立てている会社の企画担当者は、だいたいみんな同じような話をします。逆に言うと、そういう人がいない会社は、結局何をしたかったのかよくわからなくて、レガシーで身動きが取れないような状態になっていることが多いです。
あと、セキュリティも「あれやこれやのプロダクトを入れてみたはいいんだけど、結局どう運用を回すの？」「体制はどうするの？」という話をすると、「さあ」「困りました」「ベンダーさんに言われたものを買っていったんですけど、なんかどうにもうまくいってる気がしないです」みたいな会話になりがちです。
清水：ベンダーに言われたものを買っている会社があるんですか？
中野：一つひとつの部署が個別で、スコープを切っているとわりとそうなるんです。個々人は自分で考えていますが、担当が見ているスコープが小さすぎて、結果的に場当たり的な投資に見えるケースはよくあります。全体設計や全体企画や骨子としてあるアーキテクチャを握らないまま進むと、積み上げた話になってしまうようです。
山本：“上げて落とす”という表現をしたりするのですが、アーキテクチャ図があってこっちに向かうという……。先ほどのオープンワークスペースだと、目的があって技術アーキテクチャがあって製品を置くという3段論法ぐらいがないと、抽象化する前に体制もないし、上げるものもないし、落とすものも見失う。情報が分裂するわけです。
そういう場合、情報がつながった時によくいうインサイトも気づきもありません。要するに、見ている人が分裂していると、それはもうただのカオスマップです。中野さんはビジネスアーキテクチャと言いますが、そこはすごく重要なポイントだなと思いながらいつも聞いています。
清水：アサヒの中では“エンタープライズアーキテクチャ”と呼んでいるレイヤーもあります。やはりその領域はしっかり、概念レベルで持っていないと（いけない）。いきなりツールの話になってしまうと、だいたい騙されてしまう。
中野：騙されてる（笑）。
清水：事実として、そういうのも入れていたりします。別にないわけではないので。でも、そういうツールは一時的なおもちゃとしてはいいのではないかなと思います。戦略性がないですけどね。
山本：そういうスタンスに捉えるのがすごく大事ですね。
清水：「全体に影響を及ぼすような導入方法は絶対ダメだ」みたいなものもあると思いますけどね。
ツールを導入するならやめる時のことも考える必要がある
山本：導入するとしたら、やめる時をどう考えるかも併せて考えないといけません。
清水：そうですね。
山本：方向性は重要ですね。
中野：また1つの観点ですね。マイクロソフトさんからその言葉が出るのもあれですが、やはり導入担当者はやめる時、撤退をする時を考えないといけないですよね。うまくいかないこともあるし、トレンドが変わることもある。
最悪なのは、本当に身動きが取れなくなって、それがそのまま技術負債になるのは本当に地獄だと思っています。その時には、何を抽象化して何を捨てていくのかという判断も含めた会話をしなければいけません。たぶん本来のシステムインテグレーションはそういう話だったはずなのですが、なかなかなされていません。
あと、アーキテクチャの話はしっかり持っていなければいけないのですが、経営に持っていって「もういい、眠い」みたいな話になると、アーキテクチャを理解してもらうのは100パーセント無理です。
なので、やはりきちんとビジネスで、経営のベネフィットで語っていきましょう。イシューと彼らが解決したい課題の物語に載せて会話をしましょうということで、アーキテクチャは必要ですが、アーキテクチャはそのまま持っていってはダメというのも理解（しなければいけない）。
清水：そうですね。アーキテクチャでもいろいろな種類があるかなと思います。
山本：そうですよね。マイクロソフトの中では、やめる時を一番考えてお客さまと会話しないといけない会社になっていますから。
清水：最近こそナデラCEOが来てマシになったけれど、ひどい会社だったからね。ほんとうにもうとんでもない。
山本：私はナデラになってから入社しています。
清水：ナデラになってからだいぶよくなりましたが、ひどい会社だと思います。
山本：弊社には、先ほど言った生産性の製品もあるし、セキュリティももうポートフォリオが固まっているので、単品の製品だけでベンチャー（企業）が出てきて「来年でIPOします」というような次元ではありません。お客さんと長い付き合いをしないといけないのはもう絶対（必要なこと）だと思います。
清水：そうですね。
ベンダーに言われたままサービスを導入している企業もある
清水：ベンダーに言われてツールを買っている会社が多いと思います。
中野：でもベンダーさんに「提案を持ってきて」みたいなことを本当に言うように、私が過去に所属した会社もそうでしたが、「こういうことに困っているからなんか提案してよ」という、富山の薬売りみたいなことがやはりあるんですよね。「お腹痛いからちょっとなんか薬持ってきてよ」みたいな感じで調達する人たちも、確かにわりといます。
清水：でも弊社の組織の中でもそれがダメというわけでは当然なくて、困っていることが本当にあるのならば、ビジネスとしてそういうシーンもあるかもしれません。ただ、それをやはりチェックしたり確認したりする組織があれば、提案をもらうという意味では、新たな切り口を手にすることも十分にあると思っています。
たぶんそれを自分たちで考えなければいけないとか、ジャッジしなければいけないとなった時に、より精度の高い判断をするための、先ほど言ったアーキテクチャの戦略があるだけでもぜんぜん違うと思います。
「困ってるけどなんか提案して」というのがダメではない。そういうやり方もあるかなとは思います。
中野：我々も内製化がすごくポイントだと思っています。内製化（というもの）は、いくつかのレイヤーでとにかくコードを書けばいいということではないとは思っています。“企画レイヤーも内製化する”みたいなところがすごく重要だと思っています。
場合によってはとにかくすぐにコンサルを呼ぶとか。いや、別にコンサルを使うなとは言っていませんが、何がしたいかとか、どの方向に行きたいのかとか、コンサルから出てきたアウトプットをきちんと精査できるようなレベルにならない状態でいきなりコンサルを呼んでしまうと、完全にカモがネギ背負うような話になってしまって。もう「Salesforce入れましょう」みたいな話にしかなりません。
別にSalesforceがどうこうというわけではなく、要は、結局お金を払ってセールスをしてもらっている状態になってしまうわけです。
それが悪いというか、悪意があってというわけではなく、結果としてそういうかたちになってしまうので、やはり企画レイヤーの導入や開発力も含めて、ある程度きちんと内部でできるような状態にしていきましょう。これは、先ほどの「自分の頭で考えましょう」という話の組織版だと思っています。
（次回に続く）
