全体最適と個別最適をどうするか
中野仁氏（以下、中野）：いただいた質問の中にもありましたが、全体最適を目指そうと思うと、システムアカウントの統合であったり、使う社内システムはかなり厳密に監視していくべきという話があると思います。
どこまで自由をオーケーにして、どこまで会社として集約していくかというポイントについて質問がありました。あとはコーポレートITとサービスサイドの関係はどんな感じでしょうかという質問ですね。
よくあるのが、いわゆる開発環境はサービスサイドが存在してそこが面倒見ているとか、JIRAやGitの面倒を見てます、みたいなケースはあると思いますが、そこについての話ですね。では、片野さんからお願いできますか？
片野秀人氏（以下、片野）：いただいた質問の中にも同じようなのがありましたが、いろいろやってるので、その中で個別最適と全体最適みたいなところは本当に難しいですよね。決まったやり方やルールはもちろんありませんが、それは判断していくしかありません。
何をもとに判断しているかということで1つで言うと、僕はサービス開発側を見ているので、いろんな要望が来ている中で、どれが事業やサービス側から見て優先度が高いのかは肌感である程度わかっているんですよね。
そういう肌感も含めて、短期的にやるしかないものはやりますし、とはいえ全体最適を考えたら、1年後にリプレイスしなきゃいけないということもあるのですが、それでやるしかなくて。それをやりつつ、裏でもう1個全体最適で1年後を見据えてやっていくようなこともあります。
全体最適ってだいたい現場からの要望でやるものではなく、自分たちで戦略立てて、1年後2年後を考えてやらなきゃいけないということを、目の前で受けまくっているものをやりつつも、全部は止めないように死ぬ気でがんばる、みたいなバランスは常に取りながらがんばっています。
答えになっていないかもしれませんが、常に考えながら、個別で今やらなくていいよねと判断してるものは結構あります。それをやらないと全部やることになってしまうので。
リスクの影響範囲を考える
加藤徳英氏（以下、加藤）：個人によって考え方がだいぶ違うかもしれませんが、ほぼ片野さんのおっしゃるとおりかなとは思っています。例えば多少使いづらくてもこっちのやり方で全社的にはやろうよとか、結局全社の方針は我々が決めなければいけませんから。
あとはリスクですね。リスクも事業部内で閉じるリスクだったらいいんですが、閉じないリスクが増えてきているので、そこは押さえてあげないとほかの事業に迷惑がかかってしまうということも考えていますが、まあ難しいですね。本当に。個別に判断してるとしか言えないんです（笑）。
ただ、そこを事業側と一緒に考えたいかどうかは重要で、一緒に考えてあげるという気持ちがある方がそこをやるかどうかというのはすごく大事だと思ってます。
浦田智樹氏（以下、浦田）：M&A後の統合や、新事業の立ち上げなどで、どっちに行ったらいいのって悩むことが多いです。
事業スピードが本当に早いので、そのときに判断基準にしていることは「事業を止めるな」「ブレーキをかけるな」ということです。というのもDMMが20年やってきてる中で様々な社内ルールが作られているんですが、そのルールが曖昧なものもあり、判断を邪魔しているケースも非常に多いので、それを再度見直すなどしてスピードを落とさないようにすることを意識しています。
一方で、エンタープライズだというところもあって、Slackで言えばワークスペースは個別でやるのか、できる限り一つのワークスペースにまとめるべきかなどの判断が非常に悩ましくなっています。そこはビジネスオーナーとしっかり話し合って、都度都度聞いて判断しているような感じです。
チームに裁量を認めつつ、ルールを設定
徳山文晟氏（以下、徳山）：うちだとネットワーク周りのことも見ていますし、全社で使っているG SuiteやSlackの運用も管理してます。あとはネットワーク、情報スキームのところですね。
個別要件と全体最適については、うちだと何に対しての個別要件かというのもあるかと思いますが、基本的には事業ごと、チームごとに好きなものを使えるということがもともとありました。
その中から共有していいものが残っていくという、チーム主体の文化があるのですが、とはいえCorporate IT部門を立ち上げて、ある程度管理しなきゃいけないよね、というのが今のフェーズです。
その中で、リスクの判断はやるべきだと思っています。こういうことが発生するとこれくらいの影響があるよね、のような中で、テーブルで規定されている影響範囲が何千万以下のものとか、これが漏洩すると何億以上にもなるよね、ということもあります。
弊社も上場してるので、そういった影響を見て、「このあたりの情報を扱うのであればこういうルールに則ってやらないといけないですね」みたいな方針です。例えばID管理は大本と連携できるようにしないといけないとか、そういった要件を満たせれば好きなものを使っていいですよ、というルールがあります。
なぜ北米系のエンタープライズは同じようなシステム構成なのか
中野：ありがとうございます。全体最適の問題について、例えば私が前職でやっていたのは、ある意味「北米系のシステム投資をガチで日本企業でやってみる」という試みだったかなと。そのときにいくつか学びがありました。
北米系の大企業は、エンタープライズならほぼ同じようなシステム構成しているのはなんでなんだろうと思ったのですよ。それで、自分でやってみてわかったのが、システムを統合しておくと逆にルールをゆるくできるんですよ。
なぜかと言うと、みんな同じものを使っているので、そのシステム上でやってるんだったらログは取れている。Audit権限でログはあるので、何かあった時に追跡や説明責任が果たしやすい。結果、ルールはある程度緩くできる。
一方で、システムがバラバラだとルールって最終的に運用でカバーみたいな話になるじゃないですか。ルール作ってもシステムに運用できない。でも、だいたい運用でカバーってまあ実際カバーできないんですよね（笑）。
外に出てしまうとセキュリティ・ガバナンスの観点からあれをやるなとかこれをやるなみたいな話になってしまう。
一方である程度統合しておくと、とりあえず一番いいものを用意したからこれ使ってよ、みたいな話で、その中でやってもらえるならルールを細かくしなくてすむ。例えば閲覧権限やセキュリティポリシーを細かく運用してワークスペースを細かく切ったりしなくても、なんか事故ったときに全部トレースできるような状態になるということが1つ大きいなと思います。
基本的に、セキュリティ・ガバナンスは中央集権以外では実効性を持たすのは難しいと思います。ましてやエンタープライズの規模、海外にまで展開になるとシステムでプロセスを実装しないと無理でしょう。そうなると、自由と速度をみんなに渡すために、こういったシステムに統合していっている側面もあるなと。
どこに何がつながっているかがわかる仕組み
中野：次のお題に行きたいと思います。事前のご質問でセキュリティ系のお話があったので、トピックとしてお話をしておきたいなと思います
みなさん、3、4件くらいゼロトラストアーキテクチャについての質問がありました。セキュリティについての考え方をアップデートする必要があるのでしょうね。確かにWebに来た時にはWAN前提の考え方だったので、自分も随分と認識は変わりました。
会社規模が小さい段階でセキュリティは問題になりますよね。扱う情報の重要性は企業規模関係ないですからね。ただ、正社員で10人くらいなら自分たちで面倒見れてるんですけど、100台200台ってPCが増えていく。協力会社の方も増え、なぜか社員の倍くらい端末がある場合や、インターネットに個人端末で繋ぐのが当たり前ということがあったときにどうするか。
セキュリティに投資してきた会社さんといったら、やはりLINEさんとDMMさんだと思うので、片野さんにセキュリティ施策についてお聞きしたいです。
片野：弊社だとセキュリティは専門部署ですね。しかもセキュリティの中も情報セキュリティとアプリケーションセキュリティとインフラセキュリティにチームが分かれているので、サービス側と同じように社内のネットワークも含めてセキュリティを全部見ている感じです。
なので私たちのチームも、なにかクラウドのシステム入れるとなると、そのクラウドのシステムの監査がバーっと始まって、脆弱性がないかといった事前のチェックをして、その結果「これは入れられません」みたいなこともあるんです。深刻な脆弱性を見つけてしまうということが結構あります。
そういうパターンのときはしょうがないですが、そのサービスを提供している会社さんに「こういう脆弱性がありますよ」と伝えて「すみません、採用できません」という話をすることもあります。
そういったことで、サービスは社内のものはもちろんそうですし、クラウドのものも同じように自社で全部セキュリティ診断をかけて、認証などは全部統合できるように、一定の基準はおいてやっています。
あとは、情報セキュリティの話もよく出ます。どういった情報をそこに置くのかはすごく大事です。あとは利用シーンですね。どういう場面で使うのか、社内だけなのか、自宅とか、社外のほかのパートナー会社の人もつなぐのかとか。
ちなみにゼロトラストは遠い未来ですね（笑）。
（会場笑）
中野：遠い未来、遥か遠き理想郷みたいな感じですね。では浦田さんお願いします。
浦田：前職はどちらかと言うと事前に全部止める方向にありました。ビジネス部門が強い会社だったので、ガチガチにして事前で止めないと、という意識が強かったです。
今回DMMに入って、みなさんの自由さを制限してしまうと事業自体が縮小してしまうんじゃないかなという思いもすごく感じています。なのでルールを作ったりということは、事後さえなんとかなればいいんだな、くらいの感じでセキュリティを考えています。
それをアイデアとして持っていってセキュリティ部門と話して、こういうふうにして会社に告知を出して入れていきましょうか、みたいなところを段取りしてやっています。
アカウント統合のつらみ
中野：せっかくいただたのでSlidoの画面を出していただきましょうか。「社内システムが無数に乱立して人事マスタやアカウント管理に悩んでいるが、どうやって調整して統合していったか知りたい！」という質問にいいねがたくさん付いてますね！ みなさん、つらいですか～？
（会場笑）
つらいですよね～。これ、つらいですね。ちなみにこのあたりの話を記事に書いたことがあるのですが、あの記事読んでいただいたことある方？
（会場挙手）
それなりにいますね。まさに人事マスターが5個くらいある状態からシステムをひたすら統合して北米型にするみたいなお話を書いています。
統合系は本当につらいんですよ。冗談抜きで老けこむ（笑）。マスタがバラバラだって話は、いわゆるシングルサインオンとかのID管理、おそらく人事マスタ系の話であったり、会計系のところにも全部出ている症状だと思います。
そこをどうやって統合してくかという話だと思うのですが、統合できているのかという。
（会場笑）
さっきのシステム構成図を見てみると……統合できてる人？
（登壇者手があがらない）
はい。答えは「統合できてない」です！
（片野氏が挙手）
ありがとうございます（笑）。
じゃあどうしよう。統合できてないという結論が出てしまったようなんですけれども、システムの統合をプランとして考えてらっしゃるところはありますか？
（浦田氏と徳山氏が挙手）
じゃあアカツキさん。お聞きしましょうか。
外資系のERPには兼務が存在しない
徳山：IT周りの統合というところだとSSOの仕組みに寄せていくということをしているので、SaaS系のID管理の統合で言うとけっこう進めてこられているかなぁという気はしています。人事マスターがという話になると、そこは統合できればいいなぁというのはありますが、難しいかなぁと思っています。
これは中野さんがよくおっしゃいますが、北米型の構造じゃない、組織がそういう構造じゃないということもあって、社内に例外がたくさんあります。
ここのポジションだけどこっちも兼任してて、こっちだとこの決裁権限持ってるみたいなことがあって、それを人事マスターとして使うみたいなことをシステムで解決することができなくてID管理の機能と統合するというのは難しいなぁと。
中野：まさにエンタープライズに入ってくると一番最初に当たるのが、人事マスターはどこなのか。あと、「兼務とは？ この人は何が決められる人なのだ？ というか、そもそも必要か？」みたいな（笑）。というのは、外資系のERPをガッツリ入れたんですが、外資系のERPって基本的に兼務の考え方があんまりないんですよね。
あるんですけど、本当に明確なジョブディスクリプションをもとに仕事をして、かつ指示系統指示の縦と横に関しては明確に組織上構造的に分かれることを前提としてやっています。
ふわっと兼務みたいな話とか、組織図がちゃんと組織図になってないような発令とか出たりする事もあったりするわけじゃないですか。 お気持ち発令みたいなやつ。やっていきたいという気持ちを発令して組織図に反映してしまうケースがあるんです。論理的に表現するのムズいみたいな。
それって結局システムの問題じゃなくて、システムの外で起こる問題をどう取っていくかという部分なのは非常に悩ましいところです。結論として、CIOが取締役会で突っ込んで止める以外は……。
（会場笑）
要は巨大ロボットと怪獣の戦いなので、そこにITマネージャーが「この組織構造は人間にも論理的に理解できないのでシステムのせるのは厳しいし、そもそも実効性も怪しいですよ」って言ったら「できる理由を探せ」みたいな話になったりするわけです。
ですよね、片野さん？（笑）。片野さんもまさに経営に近いので、そういったヤンチャ感が経営で出たときの落とし所の取り方とかはたぶんベテランだと思うのですが、そのあたりをお聞きしたいです。
経営層とのコミュニケーションについて
片野：どうですかね。結局会社がどういう経営をやるんだとか、どういう組織構造にするのかにすごく影響を受けますよね。ものすごくでかい組織を、期中のど真ん中で「え、ここの組織割っちゃうの!?」とか「くっつけちゃうの？」とか（笑）。「会社の予算という仕組みを知ってますか？」みたいなことがあるんですよ（笑）。
（会場笑）
中野：あと「買っちゃった☆」ってノリで会社を買ってくるパターンとかですね（笑）。
片野：M&Aとかそういうことはよくあると思うんですけど、本当は仕組みをある程度ルール化していきたいんですよね。最近だとうちは経営企画とかある程度全体を取りまとめてこういうふうにやっていこうということをやれるようになってきたので、ひと通り一緒に話をしながら、組織構造はこうあるべきだよね、ということがちょっとずつできるようになってきましたが、まだコントロールは効いてないです（笑）。どこまでコントロールするべきなのか？という議論もあり。
中野：そうですよね。ある程度の会社規模になってくると戦略レベル、戦術レベル、作戦レベルみたいな話があります。どのツールを使ってどうするか、みたいなことは戦術とか作戦のレベルの話なんですが、会社の構造に関わることだったりとか下手するとビジネスモデルも踏まえたうえでの意思決定みたいな話になる。それは本当戦略レベルのお話です。
結局システムで解決できない問題って、すごく重要なことがここで決まるんですよね。その上のところに対してどうやってアプローチしていくかをとくに考慮しなければいけないのが、エンタープライズなのかなぁと考えています。単純に技術の外で起こる問題が増える。
これも先ほどの全体最適と同じで答えがあるわけではないのですが、基本的にはそこを解決しないとうまく話が進まないね、という感じです。本当に、経営とのコミュニケーションどうすんだ、みたいな話にもなってくるんですよね。
Corporate ITの業務成果をどう測るか？
片野：最後に1個だけ、他社さんにも聞いてみたいなと思ったんですが、業務成果みたいなところをどうやって測っていますか？ 結局僕らは自分たちの組織の価値を会社に認めてもらわないとやりたいこともやれません。
「いいからやっとけ！」みたいなこととか抵抗できないじゃないですか。それをやるためには自分たちの組織の価値を示さなきゃいけないと思うのですがなにかやっていますか？
中野：これはけっこう重要なことだと思うので、順番に行きましょうか。
片野：じゃあ言い出しっぺなので。聞きたいと言ったのはやり切れてない部分があるからなんですが、会社全体に対して今やっているのは、社内でアンケートを取って、それを数値化して各システムごとの満足度を可視化したりしています。
それを毎年やって良くなっていたり、否定的なところではこういうコメントがあって、そのコメントに対してわかりやすい対策はないのかとか。そういったことはやっていますね。
経営陣に対して数字でアピールするということはあんまりやっていません。ROIみたいなもので数字だけで戦うと、現場が本当に困ってることが良くならないことが多くて。個別のところで困っていることを助けてあげても、数字上はそんなに良くならないですよね。
だからROIとか数字だけを追うと、すごく大きな事業的に強いところだけを相手するとか、そういうことが起こったりするので、あまり数字ではアピールしていません。けっこう定性的に「めっちゃいろいろやってます！」「がんばってます！」みたいなことをアピールして、うんうんって言わせてるのが大きいですかね。そういうやり方で納得して任せてくれる経営陣なのはありがたいですね。
社員側に関しては、さっき言ったアンケートで、不満点が多いものはROIとか関係なくやっています。こういうこと改善してますよ、というのが見えるように積み上げたりしていますね。
加藤：我々も一緒で、先ほどの資料で7拠点って書いてたんですが、7拠点全部我々が作っているので、それをやるだけでも今のところは評価されています。下りてくるものをひたすら対応しているだけでも評価されているのが今の状況です。
でも、やっぱりそれだけだといけないなとは思っていて、どうしていこうかなというのはありますが、下手に数値化したり、コストの話にされてしまうとちょっと違うなと。そういったところも考えてやってもらう事が重要なポジションかなと思っております。
チームメンバーの個人評価をどうするか
浦田：我々のところの評価なんですが、先ほど私のプレゼンの中でTECH VISIONというものを紹介させていただきましたが、そこで変えたところとしては、成果はもちろん成果として評価します。それに加えて自分たちの等級に合わせてどんな行動をしているか、みたいなところを評価していたりします。
とくに行動評価は、例えば半期だったり通期だったりでいきなり「あなたの行動ははこうだったよね」と言われてしまうのはつらいので、月に1回、1on1をやったりして双方の認識を合わせていくということをやっています。
今おもしろいなと思ってやってるのは、社内のプロセスを可視化して、どれくらい貢献できているか測るということを進めています。。それが本当にうまくいくかどうかはわかりませんが、中野さんがおっしゃるように実験をしてなんとか成果を出していきたいなと思っています。
徳山：うちだと部門の評価、個人の評価という部分で言うと、部門の評価に対してアピールみたいなものはうちは今のところないです。定量化もしてないです。立ち上げて整理していってる段階なので、別にアピールしなくても成果は自明ですよね。
（会場笑）
まだそういう段階です。明らかに見ればわかっちゃうという状態です。あと、組織としてCTOが自分の上にいます。CTOがCorporate IT部門のGMを兼任していて、その下に自分がいるというかたちです。
現場でも一緒にやっていて、評価者が一緒にやっているので良くしていっているというところもありますし。そのCTOが社内的にも取締役や役員とも話せるので、とくにアピールするということは今はないですね。
個人の評価という意味だと、うちは半期ごとに目標を立ててこのあたりのことをやりましょうか、みたいなことは擦り合わせています。半期終わって成果を擦り合わせて、「このへんができましたね」みたいな感じで評価されるというスタイルですね。
それだとやるべきことが明確になるし、実際ここは半期でできた、みたいなところを目標を立てるときに、そこで振り返って擦り合わせるみたいなかたちでの評価というかたちですね。個人に関しては。
システム投資に対する考え方を経営層と合わせる
中野：ありがとうございます。評価の部分ってけっこう悩ましくて、例えば、コーポレートIT知らない上長と反りが合わなくて困るというのはけっこうよくある話ですね。上長が財務や人事といった管理部門系の人だったりする事が結構ありますからね。
ITマネージャーの上は経営陣とかになってくるんですね。やっぱりシステム投資に対する考え方みたいなものが合うと話しやすいですね。一方で、効果よりもなるべく金かけないでやってくれみたいな雰囲気のケースもあると思います。
そういったところに対してだと、「どういうふうにROI出すんだっけ？」みたいな数字上のコミュニケーションをすると「お、いいね。」みたいな話になったりするので相手のパターン次第という側面がある。
でも、経営幹部からちゃんと評価を得て、かつ投資をしてもらわないと、やっぱり予算・体制なければやれることもやれないわけですよ。でも、Web系が厄介なのが確実にやるのはいいけど、会社がバンバン大きくなるところなんですが……。
そこをどうやって勝ち取っていくんだっけ、みたいなものは答えがない。ケースバイケースであるからこそ、いろんな会社とディスカッションしながらどう戦略を立てていくか、みたいな話をするのはすごくいいのかなと思いました。
外に出て学ぶ。当たり前ですが、これを続けることが大切かなと。
では、時間が来ましたので今回はこんな感じでしょうか。ありがとうございました。
（会場拍手）
