マルチクラウドを活用したグループウェア環境の構築― クラウド連携の要となるサブシステムの要件定義，設計，結合テスト―
戸田 庸介，宮部 誠人，高岸 岳，朝尾 祐仁，澤田 浩文，
岡田 悦子，栗川 和巳，古村 隆明，永井 靖浩

京都大学 情報環境機構
jimusys@mail2.adm.kyoto-u.ac.jp

The construction of the groupware using multicloud- Requirements definition, design, and joint testing of subsystems
that are the key to cloud collaboration Yosuke Toda，Makoto Miyabe，Gaku Takagishi，Yujin Asao，Hirofumi Sawada，Etsuko Okada，Kazumi Kurikawa，Takaaki Komura，Yasuhiro Nagai
Institute for Information Management and Communication, Kyoto Univ.

概要
京都大学（以下「本学」という）では 2019 年 1 月に Google 社の G Suite for Education （以下「G Suite」という）と Cybozu 社の Garoon，kintone を組み合わせたマルチクラウド環境で教職員グループウェアを構築した．大学内の業務を行う上で重要なインフラとなっていたグループメール機能を Google グループで実装し，ユーザーからのグループ作成申請をGaroon のワークフロー機能から受け付け，開発プラットフォームである kintone 上にグループ管理システムを構築した．本稿では，マルチクラウド環境を前提とした４つのサブシステムで構成される要件定義，クラウド連携の要となる統合情報連携サブシステムのアカウント連携に関する設計や結合テストについて報告する．
JavaScript 等の標準的な Web 技術により業務アプはじめにリケーションを開発できる SaaS 型，PaaS 型のグループウェア環境の構築と既存情報資産の移行を

本学では 2006 年に教職員グループウェアとし大きな方針として，グループウェアをクラウドサて IBM 社の Notes/Domino（以下「Notes」という）ービスへ移行するプロジェクトを立ち上げた．

を導入し，Notes 開発プラットフォーム上で，利便性を重視して独自に機能追加を行うなどサービス拡充に努め，10 年以上運用を行ってきた．

既存サービスを考慮したマルチクラウド環境における要件定義

しかしながら，Notes 開発プラットフォームでは技術者の確保が難しくなり，ベンダーロックインの問題や，新しい技術への対応が困難でセキュリ今回のプロジェクトにおいて最も重要な課題とティ面での対応が遅れるという課題があった．

なったのは，Notes のアドレス帳を拡張し，多機能一方で，可用性の担保と運用コスト削減のメリなグループ管理を実現していた 2 次アドレス帳機ットからクラウドサービス市場は拡大し，国内外能の移行であった．の大学におけるクラウドサービスを活用したシス

2 次アドレス帳は主に 3 つの機能を有していた．

テム導入事例は年々増加していた．本学において1 つ目は，メールアドレスを付与できるメーリンも「京都大学クラウドサービス利用ガイド」を策グリスト機能，2 つ目は Notes 上の文書ファイルへ定した．これによりクラウドサービス利用におけのアクセス権に使用するセキュリティグループとる考慮事項が整理され，クラウドサービスへの移しての機能，3 つ目は利用者がグループの作成や行の環境が整った．

変更をできる機能である．課単位や掛(係)単位で仕

これらの課題と情勢を踏まえて，HTML，CSS，

1

事を行う事務組織を中心に広く活用され，本学に(2)基幹グループウェア連携開発サブシステム：

おける重要なインフラ基盤として 3,000 以上のグ

Notes 上で独自開発したアプリケーションの開発プラットフォームとしてクラウド基盤で PaaS

ループが存在していた．
システム調達にあたり市場調査を行ったとこ型として提供されるサービスが必要と考えた．2

ろ，前述のような多機能なグループ管理機能を持次グループで必要となる利用者がグループを作成

つ製品やサービスが市場にないことが明確となっや変更をできる機能において，グループのメンバた．一方，EDUCAUSE2016 の「QuiltingCollaboration: Piecing Together the Best Tools for File
Sync and Share」というセッションでは，アメリカ

ーに別のグループを設定できるネスト機能が必要の 4 つの大学で G Suite，Office 365 Education，Boxと考えた．

であり，再帰処理が要件になることから基幹グループウェア連携開発サブシステムでの開発が必要というクラウドを組み合わせてファイル共有サービス提供しているという事例が紹介されていた．

(3)電子メールサービスサブシステム：

そこで，本学では図１に示す通り，(1)基幹グルオンプレミスで提供していた教職員メールサー

ープウェアサブシステム，(2)基幹グループウェア

ビスも今回のグループウェア移行と同時にクラウ

連携開発サブシステム，(3)電子メールサービスサドへ移行するという大きな決断を経て，クラウドブシステム， (4)統合情報連携サブシステムの 4基盤で SaaS 型サービスとして提供されるサブシつのサブシステムより構成することにした．以下，ステムとして位置付けた．2 次グループで必要とサブシステムごとに前述の課題を抱えた 2 次アドなるメーリングリスト機能をメールサービスのグレス帳の後継となる 2 次グループ機能の要件定義

ループ管理機能で実装することで，関連性の高いを中心に述べる．

教職員メールとともに高可用性を担保できると考えた．

(1)基幹グループウェアサブシステム：
クラウド基盤で SaaS 型サービスとして提供さ(4)統合情報連携サブシステム：

れる標準的なグループウェアには，グループ管理本学の既設の統合認証，人事情報，利用者管理機能が存在し，施設予約やファイル管理などの機システムとの連携で各サブシステムへの利用者追能においてグループ単位でアクセス制御可能であ

加・停止，予定表，連絡先の連携を行い，グルーる．2 次グループで必要となるセキュリティグル

プウェアのユーザー管理の自動化を実現するためープ機能についてはこの標準的なグループ管理機に本学の情報基盤システムと連携するサブシステ能にて実現可能と考えた．

ムと位置付けた．

図1

マルチクラウド環境を前提としたサブシステム構成

2

マルチクラウド環境へ移行するにあたっては計，詳細設計を行った後に，システム開発や各種認証についても課題が発生する．教職員メールサ

テストを実施して新しいシステムへの移行を行っービスと Notes をシングルサインオン（以下「SSO」た．ここでは概要設計について述べる．という）で利用できる環境を構築していたが，本図２にグループウェア環境のサブシステムと情学で利用する各種システムは年々Web 化，クラウ報の連携を示す．基幹グループウェアサブシステド化が進んでおり，前述の SSO システムとは別にムは Garoon，基幹グループウェア連携開発サブシ

Shibboleth 認証に対応したシステムが増えていた．

ステムには kintone，電子メールサービスサブシス

これらの状況から，教職員グループウェアについテムは G Suite を採用し，統合情報連携サブシステても Shibboleth 認証にすることでマルチクラウド

ムは別調達の事務用汎用コンピュータシステム上環境においても SSO が実現できると考えた．にスクラッチで開発した．
マルチクラウド環境を実現する観点から，また2 次グループ機能を実現する観点から，最も重要マルチクラウド環境における大学基盤システムとの連携に関する概要設計なサブシステムとなるのは，統合情報連携サブシステムであるため，アカウント連携について詳しく述べる．
まず G Suite のアカウント連携方式について検要件定義に従って，システムベンダーと概要設

図2討を行い，図３に示すように Google 社より提供さグループウェア環境の概要設計

3

れている Google Cloud Directory Sync（以下「GCDS」

成，変更，削除の申請を行う．次に申請内容をバという）を使用することとした． また G Suite のッチ処理で自動的に処理し，kintone 上に開発したスケジュールと Garoon の予定表を連携させるた

2 次グループ管理アプリケーションにて管理する．

めにセゾン情報システムズ社製の PIMSYNC を使最後に，連携プログラムで 2 次グループ管理アプ用することとした．

リケーションを参照して， 基幹グループウェアサ
ブシステムへの連携や GCDS の参照元となる中間
LDAP に連携する処理フローとした．
従って，統合情報連携サブシステム全体としては以下の処理の流れとなる．
1.

本学の基盤となる全学統合 LDAP を連携プ
ログラムが参照し，差分を中間 LDAP に反図3

映する．

G Suite アカウント連携イメージ

2.

次にグループ管理機能のユーザーが作成や変更同様に 2 次グループ管理アプリケーションを参照し，差分を中間 LDAP に反映する．

ができる機能については，Garoon のワークフロー

3.

Garoon，kintone には連携プログラムでユー機能を利用することとした．図４にサブシステム

ザー，組織，グループ，役職情報を連携し，への連携イメージを示す．利用者はグループの作

G Suite へは GCDS を使って連携を行う．

図4

統合情報連携サブシステムでの連携イメージ4

図 5 クラウドサービスの ID 設計
次に，全学統合 LDAP からの差分抽出について説明する．LDAP には構成員の姓名，所属組織，大学基盤システムとの連携に関する
詳細設計

役職，職員番号，メールアドレス，SPS-ID などの前項の概要設計を元に，統合情報連携サブシス

子申請を基に，登録，変更，復活，停止などの処テムを中心に詳細設計について報告する．サブシ

理が利用者管理システムで行われ，LDAP へ配信

ステム毎のクラウドサービスのアカウント管理形される．本学の SPS-ID は氏名を含むことから改姓

態は，G Suite，Garoon については教職員 13,500 名を考慮する必要があり，メールアドレス(mail)と職分の個人アカウントとして用意し，kintone につい員番号（employeeNumber）の 2 つの項目をキーとてはコスト削減のため，業務システムにデータ入するような複雑な設計になっている．また，教職力を行う事務組織の最小単位である掛を ID 単位

員の流動的な雇用事情からアカウントの復活処理とすることにした．（図５参照）

を考慮する必要がある．
（表１参照）

情報が格納されている．また，これらの情報は電

具体的には，Garoon と kintone のサブドメイン

全学統合 LDAP からの連携は今回のマルチクラを分けてそれぞれで Shibboleth 認証を行い，認証

ウド環境の根幹を成す部分であり，次項にてシナ

後，Garoon には個人のメールアドレスを属性情報リオベースの結合テストについて報告する．

として連携し，kintone には組織コードを属性情報として連携する仕組みで実現した．

表1

ユーザー情報更新操作判断5

前項で述べた通り，個人アカウントに対しては，大学基盤システムとの連携に関する結合テスト

登録，部署変更，改正処理，職員番号変更，復活，概要設計，詳細設計，導入ベンダーによる開発

組織アカウントに対しても登録，変更，削除に関と単体テストを経て，この項では本学の基盤となするテストが必要となる．これらすべてのパターる利用者管理システム，全学統合 LDAP とのシナンを網羅するようなテストシナリオと期待されるリオベースによる結合テストと教職員の異動が最結果を事前に作成した．
（表２参照）

停止，削除に関するテストが必要となる．また，も多く発生する年度切り替え時の負荷テストにつ期待される結果については，全学統合 LDAP にいて記述する．

反映されたテストデータが，連携プログラムによ

表2

シナリオテストの一覧

6

り，中間 LDAP に反映され，Garoon，kintone，G Suiteのそれぞれのアカウントや組織情報に反映されるシステムリリースと今後の展開べき内容までを詳細に記述した．加えて，表２のリリース直前の運用変更も含め，当初計画よりそれぞれのテストシナリオについて利用者管理シも約 1 ヶ月スケジュールが遅延したが，調達期限ステムの前段にある電子申請システムからの申請内の 2019 年 1 月にシステムをリリースすることがに必要な 22 項目のテストデータを作成した．

できた．

1 時間に 1 回のバッチ処理を手動実行するなど

全学統合 LDAP からの毎時連携処理において現の時間短縮措置を講じたものの，1 回目の結合テ時点で大きな障害は発生していない．2 次グルー

ストは 1 日を要した．また，1 回目で改姓処理時プの申請についても，一部で組織処理の仕様変更のテストシナリオに考慮漏れが発覚したため，細による影響があるものの，ユーザーへの影響は局分化した 9 つのシナリオテストを追加し，これの所的で大きな問題なく運用できている．また，年実施についても 1 日を要した．合計 2 日を要した

度切り替え処理についても，負荷テストを行ってが，シナリオベースによる結合テストにより，日々いたため，処理遅延も発生せずにスムーズに年度の運用に関する対応パターンは網羅できた．

切り替え処理が完了した．

最後に，年度切り替えを想定した負荷テストを今後の展開としては，これまでグループウェア実施した．本学の年度切り替えでは，登録，変更，削除のあるアカウントは例年 3,000 件前後となる．
Notes では夜間バッチが処理時間内に完了しなか内の機能で活用していた 2 次グループを他のシステムでも利用できるよう EDI システムでグループ情報を提供していく計画をしている．

った事例もあり，年度切り替えの夜間処理が統合情報連携サブシステムで正しく完了することを負おわりに荷テストによって確認する必要があった．
負荷テストの内容については，2 年前の統合

本稿では，マルチクラウドを活用したグルーLDAP のバックアップファイルを使用して中間プウェア環境の構築について統合認証基盤との連LDAP を 2 年前のデータに書き換え，Garoon，携に関する設計とテストを中心に報告した．事務kintone，G Suite に連携した．例年の 2 倍となる約用汎用コンピュータのクラウド化と同時並行のプ6,000 件で負荷テストを行うこととした．また，2ロジェクトでスケジュール面，要員面で厳しい状

次グループで組織情報をネストして使用できる機況の中，大きな障害の発生なくシステム切り替え能をリリースすることから，2 次グループに組織できたことから，プロジェクトとしては成功したをネストしたテストデータを現状に即した数用意と考えている．今後も業務効率化に向けて改善をした．

行いながらも，安定した運用を行っていく所存で負荷テストの結果，連携プログラム部分は事前ある．に計算で求めた処理時間から大きな差異なく処理が完了することを確認できたが，GCDS の同期処謝辞

理に時間がかかることがわかった．ただし，夜間今回のグループウェアリプレースにあたり，複の処理で想定している時間内には問題なく完了す

雑な業務要件に対して設計，開発，テスト，デーることから，年度処理は問題なく処理できると判タ移行，それらを統括するプロジェクトマネージ断した．
結合テスト，負荷テストを進めて，統合情報連メントにおいて尽力いただいた富士通エフサス高

携サブシステムに大きな課題はないと考えていた

橋正樹氏に謹んで感謝の意を表する．同時に，プが，リリース直前の受け入れテスト時に，Garoonロジェクトに関わったすべての担当者にも感謝ののレスポンスが著しく低下する現象が確認された．

意を表する．

原因の調査を進めると Garoon に組織情報を上書き処理する際に，高負荷になることが判明し，この高負荷状態ではエラーが頻発することから，組織処理については，1 日 2 回のバッチ処理に運用を変更することで対応した．

7