教職員アカウントの移管とグループウェア自動連携による大幅業務改善戸田 庸介，宮部 誠人，高岸 岳，針木 剛，西垣 昌代，古村 隆明，永井 靖浩

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

Drasitic Improvement on Work by Transferring of Faculty & Staff Accounts
and Automatic Cooperation with Groupware
Yosuke Toda，Makoto Miyabe，Gaku Takagishi，Tsuyoshi Hariki，Masayo Nishigaki，Takaaki Komura，Yasuhiro Nagai
Institute for Information Management and Communication, Kyoto Univ.

概要
学生アカウントを管理していた利用者管理システムに，2015 年度教職員アカウントも管理するように改修した．
2016 年度に，利用者管理システムをグループウェアと自動連携させ，大幅な業務改善を実現した．本稿では，アカウント管理システム，認証システム，グループウェアのシステム構成と連携について説明し，アカウント管理業務の効率化，グループウェアへの自動連携とその効果，および今後の課題について報告する．

はじめに

従来の Domino を中心としたシステム構成と課題

京都大学（以下，「本学」という）では 2006 年に全学事務用グループウェアとして IBM 社のNotes/Domino を採用し，以降事務職員を中心に教職員アカウントの管理業務を行ってきた．

2.1

システム構成財務会計システムなどの業務システムへのシングルサインオン（SSO）環境を実現するためにアカウント管理業務は Microsoft 社 Access を用

IBM 社の Tivoli Access Manager（以下，「TAM」

いて行っているが，独立行政法人化以降多様化すという）を教職員アカウントの認証基盤として扱る雇用形態に対応するために度重なる改変を行なっていた．

い，多機能で複雑なデータベースとなっていた．

TAM はリバースプロキシ型の SSO を実現してそのため，アカウント管理業務を行う事務職員のいた．具体的には， Domino を含むバックエンド異動が困難な状況であった．の業務システムに TAM で生成した ID を各業務シ

この状況を改善するべく，学生アカウントを管

ステム ID に紐づけて管理する方式であった．この理していた利用者管理システムへ，教職員アカウ

TAM で生成・登録した ID を教職員アカウント（以ント管理も収容するプロジェクトを 3 ヵ年計画と下，「SPS-ID」という）としていた．

し，2014 年度より開始した．2015 年度にシステム各部局の担当者は電子申請システムで SPS-IDの大幅改修と機能移管をを行った．さらに，2016の利用申請を行い，アカウント管理者は申請 CSV

年度には Domino ユーザー登録の自動連携を実施

データを Access に取り込み，メールシステム，した．

TAM，Domino のそれぞれのシステムに対して CSV

本稿では，新旧システムの概要とワークフロを作成し，各システムで登録処理を行うという図ーについて紹介し，アカウント管理業務の効率化

1 に示すようなワークフローであった．これらのを図る取り組みとその効果について報告する．

処理は手作業で行うため，極めて煩雑で膨大な作業時間を要していた．
また，TAM の ID 情報と Domino ディレクトリ
ー情報は， IBM 社の Tivoli Directory Integrator と全学統合認証基盤である LDAP サーバー間でデー

2. 電子申請システムによる利用申請後に，常勤，タ連携を行い，データ共有している．

非常勤のユーザーを対象に人事給与システムからの確定データでクレンジング処理を行うように変更を行った．これにより人事システ
ムの異動情報に基づく処理が可能となり，利用申請時の記載誤りを修正できるようになった．
3. Domino 中心であったシステム構成から脱却するため，図２に示すように利用者管理システムをマスターとし， SPS-ID，DominoID の生成・

図1

Domino 中心のシステム連携イメージ管理を行うように変更した．利用者管理シス
テムからメールサーバー，TAM，Domino，LDAP

2.2

Domino アカウントサーバーへデータ配信する方式に変更したこ

Domino の ア カ ウ ン ト は 標 準 で 「 firstnameとにより，Domino の役割はグループウェアのfamilyname」で作成することになり，日本語環境で権限管理に限定でき，今後のグループウェアのDomino を利用する場合，Domino ディレクトリ抜本的な見直しが可能になった．

ー日本語拡張(DJX) を利用したユーザー管理が一般的である．
このようなアカウント生成ルールでは，日本においてはローマ字綴りの表記揺れ，改姓によるID 変更処理，海外からの教職員では middlenameの扱いや，familyname のない国への対応，システムの ID 文字数制限を超えるような長い名前など様々な課題が発生していた．
本来 TAM 側のアカウント生成ルールは Dominoとは独立したものであるが，当初の設計においてDomino の生成ルールに近似した「firstname<職員番号下 3 桁>familyname」というルールで生成した．
図２

職員番号をルールに含んでいた為，非常勤から常携イメージ勤などの雇用形態の変化で職員番号が変更になれば SPS-ID も変更しなければならないといった運用上の課題もあった．

利用者管理システム中心のシステム連

3.2

移管に伴う窓口担当の変更
利用者管理システムへの移管により，これまで困難であった事務職員の異動が容易になり，窓口利用者管理システム移管後のシステ
ム構成と改善のポイント
3.1

利用者管理システムへの移管
利用者管理システムへの移管に際しては，複担当も学生アカウントを管理していた情報環境支援センターへ移管した．これにより，情報環境支援センターは全構成員(学生，教職員，その他)を同じように扱うことが可能になった．

雑化しメンテナンスが難しくなった Access からの具体的には，学生と教職員で別々であったアカ

機能移管を最優先で取り組んだため，既存ルール

ウント通知書の発行フローも統一化され，SPS-IDやワークフローを踏襲する形で設計を行ったが，も有効化処理をしないと利用できない非活性状態

大きな変更点とその改善ポイントは以下の通りででのアカウント発行が可能となった．

ある．

また，これまで電子申請からの停止申請に基

1. SPS-ID の数字 3 桁を職員番号下 3 桁から乱数づき処理していた退職処理についても，人事情報へ生成ルールの変更を行った．この変更によからの一括退職処理を行うフローに変更した．こり職員番号変更に伴う SPS-ID の変更処理が不れによりアカウント不正利用のリスクを軽減でき，要となった．

セキュアなアカウント管理が実現した．

めた．（表１）年間処理件数は，3-6 月に集中して移管後も残った Access 業務

3.3

前述の通り SPS-ID 管理業務は利用者管理シスおり，これらの推移は毎年同様である．一方，エラー率は自動化後，一様に減少していることがわかテムへ移管することで Access 処理より脱却できた．

る．

しかしながら，Domino のアカウント管理は依然イレギュラーケースとしては，部署判別エラー，として DJX を通して行われており，連携用の CSV

氏名 ID エラー，システム運用エラー，申請ミスを作成するツールとして Access を引き続き利用すに大別されるが，多くの場合部署マッピングテーる運用に留まっていた．

ブルの整備不足による部署判別エラーである．マ

Domino のアカウント管理業務が Access から脱ッピングテーブルの整備がエラー率の減少を引き却できない理由として，所属部署の選択が属人的起こしている．なお，新部署対応や整備不足をメな運用となっていることが課題であった．そこでンテナンスし，現在のマッピングテーブルは約更なる改善に向けて，ユーザ管理の自動化を 2016

1,550 件となっている．

年度に実施した．詳細は次章で説明する．

2000

12.0%
10.0%
8.0%
6.0%
4.0%
2.0%
0.0%

1500
1000
500

部局マッピングテーブルの整備

近では併任，兼務，サテライト型組織など益々複
当初は人事給与システムを元に Domino の組織

表１

Jul-17

Jun-17May-17

Apr-17

Feb-17

処理件数

雑で管理が困難なものとなっている．

Mar-17

名称変更など部局マスタの管理が煩雑である．最Jan-17

大学の組織は非常に流動的で，組織の統廃合やDec-16

0

Oct-16

4.1

Nov-16

グループウェアユーザー管理の自動化と改善のポイント

エラー率

Domino 処理件数と自動化エラー率

マスタが作成されたが，掛講座マスタの設計差異と度重なる組織改変によって人事給与とは独立した組織マスタとして管理していた．

人事データによる定期更新処理

そこで Access 上に約 1,400 件の部署マッピング

教職員の異動が最も多く発生する 3 月と 4 月はテーブルを作成した．これにより運用担当者によアカウント管理の繁忙期となる．2015 年の繁忙期

る判断が必要となっていた所属選択処理の多くが，はユーザーからの申請に基づくアカウント処理実マッピングテーブルによって自動割り当てできる

績は 3,254 件であった．

ように改善できた．

3.2 で述べた通り，利用者管理システム移管後に教職員の削除処理は一括で行うことになった．

Domino のユーザー自動登録

4.2

DJX とともにユーザー管理に使用していた既存のツールを改修し，利用者管理システムからの連2017 年の繁忙期の一括削除による削除処理件数は1,209 件となり，申請による処理が約 93%削減された．

携 CSV の自動取り込み機能と，これまで運用担当

2017 年 6 月からは人事給与システムの基本情報

者が手作業にて実行していたアカウント登録作業により所属情報と役職情報の定期更新処理を開始

を DJX を介さず自動登録できるように改修を行っした．処理件数は 6 月 169 件，7 月 203 件でありた．

変更についても申請による処理が 80%以上削減さ取り込み時のチェックでイレギュラーなパターれる見通しである．

ンは担当者がチェックするといった運用は残るものの，概ね Domino 上のユーザー自動登録を 2016
年 9 月に実現した．
4.3

自動化による業務効率化のデータ
Domino のユーザー自動登録化後の運用記録からインポート時のイレギュラー率をグラフにまと

現状の課題と今後の展開
利用者管理システムにおける人事データを活用
した処理の改善や Domino のユーザー自動登録により，以前は事務職員が１名専担状態で運用を行っていた業務が，現在では約 99%自動化できており，主任級の事務職員約１名分に相当する業務改て報告した．今後も業務効率化に向けて改善を行善を実現できた．

いながらも，安定した運用を行っていく所存であ

利用者管理を実施している部署には電子申請のる．

受付担当者が存在するが，申請件数は約 60%削減されており，全体的に見ても非常に大きな業務改善が実現できた．
一方，人事給与システムのデータを積極活用することで新たな課題を認識しており以下に列記する．これらの課題解決に向けて，今後ともシステムや運用改善に取り組む．
1.

人事給与システムでは常勤，非常勤の教職員のみを扱うため，同一業務を行う構成員であっても派遣職員などは従来の申請ベースの処理が必要となる(人事給与で扱わない構成員管理の問題)．

2.

非常勤の給与財源が異なる場合に，給与明細の仕様からユーザーアカウントを 2 つ発行しているが，ユーザビリティが非常に悪く管理も煩雑になる為，名寄せを行って 1
つの SPS-ID で運用できようにすべきである(名寄せの問題)．

3.

人事給与システムは戸籍や銀行口座との整合性を求める為，「髙」「﨑」などの常用外漢字のデータとなっている．アドレス帳から他者を検索する場合に異体字は不便である為，利用者管理システムや LDAP に常用漢字での氏名フィールドを用意すべき (異体字の問題)．

4.

改姓処理については，プライバシーの問題
や，ID が変わることで e-Learning の受講履歴が別人として扱われるなどの課題がある．
現在のルールから姓部分をなくす新たな生成ルールに変更するなど生涯変わらない ID
体系を検討すべき (ID 表記の問題)．

5.

組織マスタについても既知の課題であるが，人事給与システムは組織規程に基づいた管理を行っており，財務会計システム，教務情報システムなどは各システムが独自の部署マスタを持っている．大学 IR を行うには各システムで組織コードが統一されるべきである(大学統一コードの問題)．

おわりに
本稿では，教職員アカウント管理の改善に係る取り組みとその効果ならびに今後の展開につい謝辞

利用者管理システムの運用に日頃ご協力頂いている皆様に，謹んで感謝の意を表する．