PART 1　2013-2014
RISING4の始動

 

 

グローバル化を軸にした新しい教学制度への対応、そして資産継承性が高く、内製主義が可能なソフトウェア基盤の構築を目指し、新・事務情報システム「RISING4」が動き出す。検討開始からIBM iの採用、PoCを経て立命館仕様のアーキテクチャが決まるまでを追う。

 

グローバル化を軸に
長中期計画「R2020」を推進

　学校法人立命館は、東京オリンピックが開催される2020年に創立120周年を迎える。西園寺公望が、私塾「立命館」を創始した1869（明治2）年から数えると、およそ150年の長きにわたって輝かしい教育の歴史を刻んできた。日本の私立総合学園のなかでも、ひときわ長い歴史と伝統を誇ると同時に、国内で最も積極的に大学改革、学園創造、そしてグローバル化を進める教育機関の1つとしても知られている。

　現在は立命館大学、立命館アジア太平洋大学の2つの大学に、4つの附属中学校・高等学校と1つの小学校を擁し、およそ4万8000名の学生・生徒・児童が学ぶ。

　その中核的存在である立命館大学は1980年代以降、グローバル化を軸とする大学改革に向けて大きく動き出した。1988年に、国際関係学部を設置。1994年にびわこ・くさつキャンパス、2006年に朱雀キャンパス、2015年には大阪いばらきキャンパスを開設した。京都の衣笠キャンパスを含めたこれら4キャンパスの合計15学部22研究科で、ほぼすべての学問領域をカバーする。2014年にはグローバル化に向けた功績が認められ、立命館アジア太平洋大学とともに、文部科学省から「スーパーグローバル大学創成支援」事業の採択を受けている。

　こうした動きを支えているのが、2020年の立命館を構想した学園ビジョンである「R2020」である。この長中期計画が発表されたのは2010年。その翌年から、同大学は「Creating a Future Beyond Borders　自分を超える、未来をつくる」を掲げ、具体的な施策を展開してきた。大阪いばらきキャンパス開設は、その中核事業に位置付けられている。2019年4月には、新たにグローバル教養学部を開設する予定である。

　そしてさらなる次の10年後、2030年に目指す新たなビジョンとして、「挑戦をもっと自由に」を掲げた「学園ビジョンR2030」も発表された。R2020の到達点を基礎としながら、もっと自由な発想で、もっと自由に挑戦する。同大学は、一層ダイナミックな歩みを進めている。

 

第4世代の事務情報システム
RISING4の構築に向けて

　本特集で紹介する「RISING4」は、立命館大学が運用する事務情報システムの第4世代に当たる。第1世代の「RISINGⅠ」は国産メインフレーム上で稼働し、約3年の開発を経て1990年に全面稼働を開始。続く第2世代「RISINGⅡ」はメインフレームからクライアント／サーバーシステムへ移行し、1998年に稼働した。さらに第3世代である「RISINGⅢ」はJavaやOracleなどのオープン系技術を主体にしたWebアプリケーションへ移行し、2006年から利用をスタートしている（図表1）。

 

　同大学が運用する事務情報システムは、大きく「法人系システム」と「学生系システム」に大別される。法人系システムは人事給与、勤怠管理、会計管財などの各サブシステムで構成され、同大学では「社会的一般性の高い業務領域」と定義し、パッケージソフトウェアを導入している。これに対し、学生系システムは歴代「RISING」と名付けられて、利用されてきた。

　RISINGⅢは、パッケージ製品をベースに大幅なカスタマイズが加えられている。約50台のPCサーバーが稼働しており、2010年にサーバーやOS（Windows、Linux）などのインフラを更改した。次の保守契約が終了する2018年度末までには、何らかの次期システムを稼働させねばならない。

　情報システム部がRISING4に向けた検討をスタートさせたのは2013年秋のことである。同部は情報基盤課と情報システム課で構成されている。情報基盤課ではサーバーやPC、ネットワークなどのインフラを担当し、一方の情報システム課はアプリケーションの開発・運用を担当している。RISING4の構築を担当するのは、情報システム課である。

　同年11月には、情報システム部とユーザー部門で構成される「事務情報システム運営委員会」の場で、次期システムに関する初めての意見交換会が開かれた。

 

RISINGⅢの運用から浮上した
次期システムへの課題

　同委員会ではさまざまな意見が交わされ、大学の現状、システムの利用者、情報システム部というそれぞれの観点から、RISINGⅢの運用に基づく現在の課題が指摘された。

　それは、「教学制度改革の課題」「システム利用者の変化に対応する課題」「ソフトウェア基盤としての課題」「システムの開発・維持管理体制の課題」という4つにまとめられている（図表2）。

 

 

教学制度改革の課題

　最も大きな課題は、1980年代後半期の事務体制を引き継いだRISINGⅢが、同大学が展開する現在の教学制度、グローバル化の動きに対応するためには、根本的な見直しが必要になっている点である。

　大学のグローバル化に伴う新しい学年暦（4月入学・9月入学）、授業時間制（3カ月単位で履修するクオーター制や春学期・秋学期で履修するセメスター制など）、科目ナンバリング制の導入、多言語対応、それに関連して生じ得る学籍・学費制度の変更や4キャンパス化に伴うキャンパス単位での教務運営といった教学制度改革に対応するには、システムの根本的な設計思想の変更が求められていた。

 

システム利用者の変化に対応する課題

　1980年代後半の設計思想を引き継いだRISINGⅢは、一定の業務知識を有する職員の利用を前提にしていた。しかし派遣職員の採用や業務委託の推進など雇用形態は多様化し、当初想定したユーザー像にも変化が生じている。

　操作方法を問い合わせなくても簡単に操作できるユーザーインターフェース、各種登録情報のリアルタイム化、全部門で入力・出力を整理して重複や過不足、転記、仲介作業などを廃止する、など。より広い範囲の学生・教職員を対象にした新しいシステムでの業務設計、入力設計が求められていた。

 

ソフトウェア基盤としての課題

RISINGⅢがベースとするWindowsやLinuxの環境では通常、OSがバージョンアップすると、それに伴ってミドルウェアやアプリケーションの移行・改修作業が発生する。

　2010年に実施されたインフラ更改時も例外ではなく、とくにRISINGⅢではパッケージ製品を利用しつつ、立命館仕様の大幅なカスタマイズを実施していたため、アプリケーションプログラムの非互換部分の洗い出しや改修、稼働テストなどに多大な工数が発生していた。

　機能的な変更はなくとも、維持するために多大な工数を費やすことに疑問が呈され、プログラム資産の継承性が高いソフトウェア基盤が必要と指摘されていた。

 

システムの開発・維持管理体制の課題

　RISINGⅢでは、カスタマイズ部分やその後の追加開発・拡張などの開発作業一切を、パッケージ製品のベンダーに委託していた。そのため保守費用、移行開発費用、運用サポートなどの維持管理コストが増大していたのに加え、複雑な仕様・要件を外部に伝え切るまでの時間的なロス、コミュニケーションロス、手戻りなども大きかった。

　また多様なオープン系技術要素を個別に組み合わせて実現するRISINGⅢでは、インフラの構築・運用スキルが高度化しており、スキルを備える人員を学内で維持するのは困難な状況にある。外部依存度の高い体制を改め、システムを内製できるソフトウェア基盤が望ましいと考えられていた。

 

内製主義による自前開発
資産継承性の高いソフトウェア基盤

　2013年11月の事務情報システム運営委員会で、初めて意見交換会を開催してから、2014年7月に常任理事会が次期システムの開発基本方針を承認するまでの約8カ月間、情報システム部では新しいシステム基盤の構想策定を活発化させていた。

　情報システム部が重視したのは、前述した課題解決を導き出す次の3つの条件である。すなわち自前開発型（非パッケージ型）システムの導入、プログラム資産の継承性の高さ、内製主義を可能とするソフトウェア基盤である。

　情報システム部ではいくつかの学校法人向けパッケージ製品も調査したが、同大学では業務に独自要件が多く、カスタマイズ開発が避けられない。ほとんどの場合、パッケージのカスタマイズは標準保守サービスの適用外となるため、特別保守費が発生する。そのため次期システムではパッケージ製品を使わず、スクラッチ開発で実現する方針であった。

　さらにプロジェクトでは外部ベンダーへ開発作業を委託するものの、最終的には自前開発・自前維持を原則とした「内製主義」の体制でシステム構築・運用を進める。OSのバージョンアップごとにミドルウェアやアプリケーションの改修が発生しない、資産継承性の高いシステム基盤を実現する、という目標が掲げられた。

　上記の要件をクリアできるシステムは、かなり限られる。開発経験の豊富な部内のメンバーを中心に、次期システム基盤の候補として、Power SystemsとIBM iはかなり早い段階から検討の俎上に上げられていたという。

　そこで情報システム部は2013年12月に日本IBMへコンタクトし、翌年1月に営業担当者が同大学を訪問。続いて2月以降、具体的なミーティングの場を重ねた。そして5月にはIBM iに最も精通している日本アイ・ビー・エム システムズ・エンジニアリング（株）（以下、ISE）のコンサルティングITアーキテクトである箕手幸広氏が訪れて、情報システム部から要件をヒアリングしている。

「非パッケージ型による自前開発・自前維持の体制確立やプログラム資産の継承、学内機能要求に迅速に対応していきたいといった大学側の要望を伝えると、初めて会ったにもかかわらず、箕手さんは短い時間ですべてを理解してくれました。私たちの印象では、箕手さんは『わかった、みなまで言うな！』とでも言いたげでした（笑）。『やっとやりたいことが伝わった』『これで前に進める』と、そこにいた全員が安堵した瞬間でした」と、情報システム課の岡潤也課長（当時。現・業務改善企画課 課長）は当時を振り返る。

 

 

 

レガシー言語への逆マイグレーション
RPGへの抵抗

　日本IBMとISE、それに情報システム部は、4月から通算5回のアーキテクチャ策定会議を開催し、箕手氏らを交えてコンセプトの確認、アーキテクチャやソフトウェア基盤の提案、PoC（Proof of Concept）の打ち合わせなどを進めていった（図表3）。

　これには当初から、（株）クレオテックも参加している。同社はキャンパス管理や式典運営、給与計算や事務業務のアウトソーシングなどを担う立命館の100％出資会社である。2012年には、IT業務を担当するICTソリューション部が発足。それ以来、情報システム部と一体となってシステムの構築・開発・運用を担ってきた。RISING4でも当初から、設計・製造の重要な戦力と位置づけられていた。

　IBM iで行く。

　箕手氏が登場する以前、この方針には部内に少なからぬ抵抗もあった。RPGをして、「レガシー言語への逆マイグレーションだ」と感じる向きもあり、学内・外で開発人員を充当する担当者たちからは、「RPGでは、必要な数の開発者を集められないのではないか」と危惧する声も上がった。開発人口の多さから、「まだCOBOLのほうがよいのでは」という意見も出されたという。

　そこで情報システム課では服部陽介課長補佐（当時。現・課長）、クレオテックの上山哲嗣課長（ICTソリューション部システム事業課）ほか数名が、アイ・ラーニングの開催するIBM iアプリケーション開発講座に参加した。Java、C#.NET、Oracleなどの開発経験が豊富な服部氏は、初めてRPGに触れたときの感想を次のように語る。

「ILE RPGのフリーフォーム版を見たとき、これまで使ったことのある言語とは趣が違うものの、これならJavaスキル中心の開発者でも、それほど違和感なく馴染めると思いました。今までWebアプリケーションを運用してきたので、レガシーな5250画面に戻ることは考えられませんが、ILE RPGで開発することに不安はなく、部内を説得できると考えました」

 

立命館大学のコンセプトを
PoCで実証する

　同年7月には、PoC用のマシンとして「Power Systems S814」を導入し（図表4）、箕手氏、中村陽一氏らISEチームによる検証がスタートした。

　このPoCの狙いは、日本IBMが提案するアーキテクチャとシステム基盤で、同大学が求める要件をどのように実装するかを明らかにすることであった。

　箕手氏は、図表5の右のようなアーキテクチャとシステム基盤を提案している。業務ロジックは完全フリーフォーム型のILE RPGで開発する。Web側はIBM i上のWebSphere Application Server（以下、WAS）、IBM HTTP Server、それに「XML-Bridge」を活用する。XML-BridgeはWAS上で動作し、バックエンドプログラムを呼び出すためのIBMソリューションである。XMLやXSLによりWeb画面を生成し、画面の変更要求が生じた場合もXSLファイルを修正するだけで対応できる。

 

　またプレゼンテーション層、ビジネスロジック層、データ層の3層を完全分離できる点も大きな特徴である。
　さらにこの提案で注目すべきは、XML-Bridgeとは別に、立命館仕様のアプリケーション・フレームワークを構築する点である（図表6）。

　RISINGⅢでは、プレゼンテーション層とビジネスロジック層の分担が不明瞭であった。そのため画面デザインの些細な変更でもプログラム変更が発生していた。

　学内ではユーザーインターフェースへの変更要求がとくに多く、画面変更は頻繁に生じる。

「それはRISING4になっても変わらないだろうと思いました。こうした要求に迅速に対応するために、Web画面の構成要素、チェックルール、表示文言をすべてデータベース上でマスタ化する。そして業務要件別の独自処理部分のみをプログラミング実装することで、できるだけプログラミングレスでアプリケーションを完成させられる環境を整えたいと、かねてから考えていました」と語る服部氏は、2014年2月ころに、OracleやJavaなど身近な技術を使いながら、画面構成要素のデータベース化を自ら検証していた。いわば「PoCのためのPoC」、情報システム部内では「服部PoC」と呼ばれるコンセプト検証である。

　ISEチームによるPoCは、実機でRPGやWAS、XML-Bridgeの使用環境を実装すると同時に、情報システム部の意向を受け、「服部PoC」の目指す立命館仕様のアプリケーション・フレームワークが実装可能であるかどうかの検証プロセスを兼ねていた。

　このPoCは、6～9月まで約1カ月単位で4つのフェーズに分けて進められた。第1フェーズは独自フレームワークのコンセプト検証、第2フェーズは業務アプリケーション実装方式の検証、第3フェーズは共通機能の部品化とXML-Bridgeの機能拡張検証、第4フェーズは業務実装手法確立とプログラミング環境の検証である。

　すべてのPoCが終了し、その成果が学内で発表されたのは9月末。情報システム部ではPoCの途中ですでに、箕手氏の提案するアーキテクチャやソフトウェア基盤、そして立命館仕様のアプリケーション・フレームワークが実装可能であることを確信し、Power SystemsおよびIBM i採用の意思を固めた。

　そして最終的にはこのPoCが、「レガシー言語への逆マイグレーション」という言葉が象徴するIBM iへの抵抗感を一掃することになった。情報システム部の描くコンセプトがシステムイメージとして結実し、実装に裏打ちされた確かな青写真を描くことに成功したからである。

　こうしてRISING4の開発が、正式に動き出したのである。

 

････････

PART 2　2015-2018

RISING4の実現

独自のアプリケーション開発標準と
アプリケーション・フレームワークを構築

････････

INTERVIEW

RISING4のプロジェクトで得た大きな財産が
今後の学園改革の礎となる

田尻 実氏 学校法人立命館 情報システム部 部長

････････

PART 3

RISING4の技術

独創的なWeb画面生成機構を開発
部品化・レイヤ化・テンプレート化も導入

････････

［i Magazine 2018 Winter（2018年11月）掲載］