自己紹介とEnterprise ITセンターについて
廣瀬崇人氏：こんにちは。Enterprise ITセンターの廣瀬と言います。今日は「1万人規模の組織が経営統合したときの社内システムの課題と取り組み」という題で発表します。
はじめに、自己紹介をさせてください。2011年に入社し、サーバーのセットアップツールの開発や、プライベートクラウドのIaaSレイヤーのコンポーネントの開発を行ってきました。社内システムについては2012年の（NHN Japan、ネイバージャパン、ライブドア3社の）経営統合時、在籍していた部署で社内システムの導入を行ったことが始まりで、引き継ぐまでの1年ほど運用を行っていたのが、最初のかかわりです。
そして2021年4月に、Enterprise ITセンターのEnterprise開発チームという部署に異動し、社内システムの開発、運用、改善といった業務に従事しています。また、5月からZホールディングスに出向して、グループ企業間で使われる協業プロジェクトのための社内システムの開発や導入も行っています。
私が所属しているEnterprise ITセンターはどういう部署で、何をしているのかですが、いわゆる情シスというものが想像しやすいかと思います。最近はコーポレートITとも言われていますが、主に社内システムの開発や導入、運用、サポートをしています。
Enterprise ITセンターでは、「社内サービスの提供を通じて、働きやすさナンバーワンの企業を目指す。よりよい環境を提供し続ける」というミッションがあります。そのため、私たちは“LINER”と言っていますが、LINEの社員に対し、よい環境を提供し続けるため、日々改善を行っています。
今日のアジェンダになります。2021年に（ZホールディングスとLINEの）経営統合がありましたが、その後Enterprise ITセンターでは、グループ企業との協業に向け、社内システムの開発や導入を行ってきました。
今日はその開発や導入の背景から、プロジェクトで直面した課題、そしてそれをどうやって解決してきたか。また、開発や導入を通じて見えてきた、今後の新しいシステムを導入、開発していく時に直面するであろう課題と、その解決のための取り組みを話していきます。
社内システム導入の背景
それではまず、背景から話します。経営統合後、私たちはヤフーのコーポレートITの方と、どのように協業していくか話し合いを行いました。その会議で、協業のプロジェクトを始めるためには何が必要で、どういう準備が必要なのか議論を行い、いくつかのシステムを導入していくことが決定されました。
どういったシステムを導入、選定したかというと、はじめにドキュメントに「Confluence」、タスク管理に「JIRA」を準備しました。これらのツールは、LINEでもヤフーでも運用して使われています。
しかし、どちらかが使っているものを協業用プロジェクトに使用しようとすると、アクセス制限の管理やユーザー権限の管理が難しくなってしまうため、協業用プロジェクトに新しく準備することにしました。
次に「Zoom」ですが、ヤフーもLINEもふだんから使っていたので、そのまま使うことにしました。
そして「Slack」や「Box」のようなSaaSについても両者使っていたため、テナント連携を行うことにより、お互いに情報共有をできるようにしました。
しかし、スケジュール調整については違ったツールを使っていて、どのように共有するのか、別途議論が必要になりました。今日はそのスケジュール調整を例に、どのような課題に直面し、どういうふうに解決してきたのか話を進めていきます。
スケジュール調整の状況
スケジュール調整がどうなっていたかというと、会議のスケジュールを調整したあと、LINEはLINEが使っている「LINE WORKS」へ、ヤフーの会議出席者はヤフーが使っている「Exchange」へ、別々に登録していました。どちらかが違う時間に会議を設定してしまったりすると、時間が無駄になってしまう可能性があります。
私たちもグループ企業間で使われるシステムを準備するためにヤフーと会議を行っていた背景もあり、この問題は早く解決したいというモチベーションが高かったです。しかし、両者が使っているカレンダー共有のシステムのデータを同期するようなツールはなかったので、自分たちで開発する必要があり、今回のプロジェクトを開始しました。
最初に検討したのは、お互いの社員の予定を、お互いのスケジュール調整に同期することです。今までのツールを使えることが、お互い一番負荷も少なく楽なので検討しました。
しかし、両社とも1万人規模なので、APIを使った同期を行おうとすると、どうしてもAPIリミットに引っ掛かってしまいます。1人当たりの同期間隔が1時間になってしまうと、同期を待っている間に別の予定が入ったり、また予定を更新されてしまう可能性があります。
現在、弊社の会議はほとんどZoomで行われていて、Zoomでの会議は月平均14万回ほど設定されています。そして会議の出席者は、合計で63万人ほどになります。
ここでたとえ話ですが、会議の30分前にZoom URLが変更されてしまった場合、会議に10分気づかなかっただけでも、その会議出席者にとっては時間のロスになってしまいます。それが月平均の10分の1の6万人の会議出席者に影響を与えることも想定できます。
また、今回はヤフーとの協業に向け準備していますが、そのほかのグループ会社との協業を行おうとした時に、この同期間隔はより広がってしまい、深刻な状況になってしまいます。そのため、今回は同期というプランは、選択できませんでした。
スケジュール調整のアプリケーション「Meet Up」
そして私たちが開発したのは、スケジュール調整のアプリケーションです。LINE WORKSとExchangeのAPIを使い、両者が使っているスケジュール調整に登録するものです。
私たちは、このアプリケーションを「Meet Up」と呼んでいます。なぜMeet Upが必要だったかというと、ほかの会議と重複してしまう可能性が一番少なかったこと。そして、先ほど言ったように会議の更新にも対応できます。そしてグループ企業が増えた場合でも簡単に改修、更新ができるので、このアプリケーションを開発することにしました。
（スライドを指して）そしてこれが、開発したMeet Upです。普通のスケジュール調整のツールと同じように、タイトルや会議の内容などを入力し、まずは会議出席者の予定を取得します。スケジュールは1日のスパンで表示され、予定のあり・なしがわかるようになっています。
スケジュールの内容を表示してしまうと、個人情報や機密情報が含まれている可能性があるため、あり・なしの表示にしています。そして、空いている時間に会議を予定するのがMeet Upのアプリケーションです。
ここまで開発はスムーズにいきましたが、2つの課題に直面しました。1つ目が、検索できるユーザーを制限する必要があること。2つ目は、ログインできるユーザーを制限することです。
これらはセキュリティチームとの話で出た課題ですが、1つ目の課題は主にLINE側からの課題。そして2つ目は、グループ企業全体で使うためのツールとして、Zホールディングスとしての課題です。
制限がどういった背景から来ているかと説明すると、今回のZホールディングスグループ内で協業に使うシステムを構築したのは、Zホールディングスです。しかしユーザーは、Zホールディングスの子会社にあたる、ヤフー、LINEといった会社の社員です。
例えば、今回作ったMeet Upのようなアプリケーションが別にあったとします。そしてそれを使うのと、Meet Upは同じ構成になります。そのため、外部サービスを利用するためのセキュリティチェックをヤフーとLINEで受ける必要があり、また、サービスを開始するためのセキュリティチェックを、Zホールディングスで受けなくてはいけませんでした。
そこで2つの課題が生まれ、明確になり、取り組むこととなりました。
今回、この開発を行うにあたり、私たちはZホールディングスに出向し、そして開発を行いました。そのため、ふだん使っているインフラリソースや開発環境が使えませんでした。ふだんの社内システムの開発とは違う、インフラ環境や開発環境をゼロから準備するのも、今回のアプリケーション開発において、課題ではありませんが、大変だったポイントでした。
課題1：協業とは関係のない社員は表示しない
では、1つ目の課題から入ります。協業とは関係ない社員は表示しないようにすることですが、ユーザーの制限の課題には2つのポイントがあります。1つ目はメールアドレスの入力欄です。ふだんの社内システムを使うことを想像してみてください。
社内システムなので、社員を検索すると、たぶんその社員の候補が出てくるかと思います。しかしそれを実装すると、協業と関係ない社員が出てきてしまう可能性があります。
先ほど説明したとおり、Meet Up自体はZホールディングスで開発を行っています。そのため、社員情報は持たせられませんでした。候補を出そうとすると、各社の社員情報を都度データから検索する必要があります。それは今回は難しいと判断したため、この機能は外すこととしました。
この課題を解決するためには、技術的にではなく、LINEグループ各社と約款というかたちで合意を取る必要があります。現在、各社と協業に向けた取り組みを行いやすいようにするための議論を行いながら、約款を作成しています。
そういった約款の作成を行うことにより、このような機能の追加が可能になります。
もう1つ、入力候補がなくても、協業と関係ない社員を検索できてしまうケースが想定できます。それは、協業と関係ない社員のメールアドレスを知っていた場合や、1文字違いで間違ってメールアドレスを検索してしまったケースです。
予定のあり・なしの表記ですが、検索できてしまうこと自体に問題があるため、LINE WORKSへリクエストを投げる前に判定する仕組みが必要でした。
そして、そのために開発したのがChecker APIです。これは、リクエストに入っていたメールアドレスが、検索されても大丈夫なユーザーかを判断しています。もし検索してはいけないユーザーだったら検索せず、そのままリクエストを返すようにしています。
このAPIは社員情報に触れなければいけないため、Zホールディングスではなく、LINEの社内にAPIを立て、Meet Upのバックエンドとやり取りを行うようにしています。
ユーザー制限についての課題をまとめると、メールアドレスの入力に関しては、現在約款を結ぶかたちで解決を結ぶための議論を行っています。リクエストに入っていたメールアドレスのケースは、Checker APIというかたちでMeet Upに組み込み、検索されないように解決を行いました。
課題2：ログインできるユーザーを制限する
それでは次の課題に入ります。次はユーザー認証についてです。私たちはふだん、社内システムにSAML（Security Assertion Markup Language）認証を導入しています。
SAML認証の仕組みを簡単に説明すると、ユーザーが社内システムにアクセスした時、認証していなかったらIdP（Identify Provider）側にリダイレクトされます。そこで認証を行い、またサービス側にリダイレクトされることでログインできるというのが、SAML認証の仕組みになります。
社内システムの管理者が社員の転籍や異動を追わなくても、マスターが更新されればそのまま使えるのは、管理側の負担も少なく、使っているユーザー、社員側にとっても、都度設定をしなくてもいいのがメリットかと思っています。
しかし今回はユーザーを絞る必要があったため、このような対応を行いました。IdP側に「Datastore」という、ログインできるかをチェックする仕組みを開発しました。
Datastoreは、協業を行っている社員のリストを持っています。そこで認証の可否の判断を行います。この仕組みはMeet Upに限らず、先ほど紹介したConfluenceやJIRAなどの協業で使われるシステムにも導入しています。
ユーザー認証については、SAML認証の利便性とユーザー認証の制限のバランスを保つため、今回はIdP側に認証可能なユーザーかを判断する機能を追加することにより、解決を行いました。
今後の改善点
こうしてリリースまで漕ぎ着けましたが、今後の改善点も見えてきました。現在、各社が認証基盤を持っている状態で運用しています。（スライドを指して）このような画面のように、ログインできる会社名が並んでいます。これは、各社の認証基盤を各サービスに設定しているからです。
今後利用する会社が増えれば、それだけ認証のエンドポイントが増えてしまいます。そして、サービスも増えればそれだけ設定する分、コストが増えてしまいます。
そういった課題を解決するために、IdPを統合するような仕組みを検討しています。グループ企業間の協業で使われるシステムについては、統合したIdPで認証を行うのが、ユーザーにとっても、管理側にとってもメリットがあると考え、現在その検証を行っています。
グループ企業間で使われるシステムの開発はどういったかたちが最適なのか、私たちもはじめてのことが多く、手探りで進めていますが、このように一つひとつ直面した課題を解決していくことで、よいシステムが提供できると考えて検証を行っています。
課題を解決し続けることでEnterprise ITセンターのミッションを遂行する
最後にまとめに入ります。今日は、経営統合でグループ企業との協業のための社内システムの開発を例に、直面した課題と、その解決について話をしてきました。
私たちEnterprise ITセンターには、「働きやすい環境を提供し続ける」というミッションがあります。これは、今回話したようにLINEだけではなく、グループ企業で使われるシステムについても同様にやっていくことが大事だと考えています。
今日お話ししたように、技術的ではない課題もたくさんありますが、1つずつ見つけた課題の検証を行いながら改善していくことで、働きやすい環境を提供し続けられると考えています。
以上で発表を終わります。ありがとうございました。
