PART 2 2015-2018
RISING4の実現
本格的な設計・製造作業をスタートしたあと、プロジェクトは大きな壁に突き当たる。
それはアプリケーション開発の遅延という形で顕在化した。
本番稼働予定を再設定し、開発の進め方や体制を見直し、アプリケーション・フレームワークを徹底的に整備。
2度目のキックオフから本番稼働へ向け、全員一丸となって突き進んだ。
RISING4を構成する
入学システムと学生システム
2015年1月に、Power Systemsが導入された（図表1）。本番環境およびテスト環境として、「Power Systems E880」が1台、Webのフロントエンド用に「同 S814」が4台、それにバックアップ機用に「同 S824」が1台の合計6台をデータセンターに設置した（これにPoC機であるS814も加わるので、同大学が所有するマシンは合計7台となる）。
RISING4は大きく、「入学システム」と「学生システム」の2つで構成され、それぞれ基幹系と情報系に分かれている（図表2）。入学システムは毎年8000～9000名の志願者、学生システムは約3万5000名の学生、約1300名の教員、およそ1000名の職員が利用する。
入学システムは大学および大学院への志願者による出願、受験、合否の確認、入学金の納付や入学手続きなどを管理するシステムとして構築されている。志願者が利用するのに加え、職員による出願管理、合否の登録、入学金の納付管理などの機能を有している。RISINGⅢでは職員が使用する機能は搭載されていたが、志願者が利用する機能はRISING4の新機能として開発されている。
一方の学生システムは、①学籍管理、②学費管理、③奨学金管理、④履修成績管理、⑤原簿管理、という5つのサブシステムで構成されている。基本的にはRISINGⅢの仕様を継承しつつ、要望に応じて新しい業務機能を追加した。
全体的な開発規模は、図表3のとおりである。画面数は合計で約3000枚に及ぶ。当初の予定では入学システムは2016年1月から、学生システムは2017年4月から、それぞれ段階的に本番稼働する予定でスケジュールが策定された。
2015年4月には、外部ベンダーを交えてプロジェクトがキックオフしている。このキックオフには、立命館大学の情報システム課、日本IBM、ISE、クレオテックが参加している。
情報システム課の服部陽介氏とクレオテックの上山哲嗣氏、阪部優子氏、ISEの箕手幸広氏、中村陽一氏がアプリケーション・フレームワークの開発を担当。なかでもクレオテックは箕手氏の支援のもとフレームワークの部品開発を進めたほか、日本IBMの渡辺佳央里氏、村谷佳紀氏の支援のもとインフラ基盤の整備・運用を担当した。並行して入学システムのアプリケーションの設計、製造が開始された。（株）金沢総合研究所、（株）サンテックは、日本IBM委託のもと、それぞれ設計、製造を担当した。キックオフ当初は、学外で25名ほどのメンバーがプロジェクトに参加している。
漠然とした不安が現実に
アプリケーション開発が難航
キックオフ前年の2014年10月ころから、学内では先行的に入学システムの要件定義が、少しあとから学生システムの要件定義もスタートしていた。要件定義は情報システム課の石井奈穂子課長補佐がリーダーとなり、サブシステムごとに情報システム課の担当者を配置し、その担当者が中心となってユーザー部門との調整を進めた。
要件定義の範囲は業務フローの確定、テーブルの分類、画面の定義など。ユーザーの要件を確認しながら、まずは手書きで画面イメージを作成。独自に開発した画面作成ツールを使って、データベースに登録された画面部品によりリアルな画面を作成し、ユーザーが確認する。要望に応じて修正し、画面仕様が決定したら、設計・製造のプロセスに渡していく。
いよいよ本格的な設計、製造がスタートするというキックオフ・ミーティングの前日。岡氏をはじめとする情報システム課のメンバーたちは、「漠然とした不安を感じていた」と振り返る。
「今から思えば、各工程で何をして、何をアウトプットして、それを誰が承認するかといった開発工程の実施タスクをきちんと確認しないまま進めていました。また『要件定義』の定義そのものが曖昧で、どこまでの要件を定義し、どこからは設計工程の責任範囲であるという線引きも未確定でした。皆が内製での新規開発という未知の不安を抱えながら、それでも予定されたスケジュールに押されて前へ進まざるを得なかったのです」（岡氏）
実際に設計、製造作業がスタートしても、期待していたほどアプリケーション開発の生産性は上がらなかった。
「生産性が上がらなかったのは、土台となるアプリケーション・フレームワークがまだベータ版の状況で、十分に固まっていなかったからです。でも当時は、製造に着手していることもあり、ベータ版でありながらもアプリケーション開発を止めることができず、日々葛藤を感じていました」（服部氏）
ユーザー部門と設計、製造チームとの橋渡し役を果たしていた石井氏も、当時の苦しい状況を思い返す。
「アプリケーション・フレームワークが未完成な状態での設計、製造に予想以上の時間がかかり、手戻りも多かったように思います。アプリケーションが完成し、ユーザーを交えてテストすると、異常停止が発生する。でもその原因がフレームワークにあるのか、業務プログラムにあるのか、あるいはテスト環境にあるのか、問題の判別にとても苦労していました。2015年6～7月はそうした状況が重なり、とても苦しい時期でした」（石井氏）
岡氏は、その状況を樹木の幹と枝葉に例えながら次のように指摘する。
「PoCで私たちのやりたいことが形になり、これで前に進めると喜んだ8カ月後に、このような大きな壁につきあたるとは想像していませんでした。PoCで形になったのは幹の部分だけで、アプリケーションとして実現するための枝葉は十分ではなかった。そのことに、あとになって深く思い知らされることになりました」（岡氏）
米IBMのキーマンが来日
アーキテクチャをレビュー
一方、アプリケーション・フレームワーク開発チームでは、箕手氏のアレンジのもと、2015年7月に米IBMのロチェスター研究所から2人のエキスパートが来日し、同大学で3日間のセッションを開催した（図表4、図表5）。Db2 for iの専門家であるダニエル・クルックシャンク氏と、IBM iの専門家であるジン・ミン・リュー氏である。
セッションの目的は、RISING4の幹となるアーキテクチャやソフトウェア基盤、とくにDB設計やプログラム構造などをレビューすることにあった。
2日にわたって情報システム部から両氏にアーキテクチャの内容をプレゼンテーションし、最終日にそのレビュー内容がメンバー全員に伝えられた。
「専門家の2人から、RISING4のコンセプトや方向性、構築しようとしているシステム基盤は先進的で、問題はないと評価されました。さらにDBの正規化、SQLのベストプラクティス、RCAC（Row Column Access Control）、フレキシブルビュー、マルチプルローフェッチの利用方法など、Db2 for iに関連する詳細な技術情報も入手できました。このセッションで、私たちの進む方向は正しいと、大きく背中を押されたように感じました」（服部氏）
アーキテクチャやソフトウェア基盤に問題はない。しかしアプリケーション開発に関する進捗の遅れは顕著になりつつあった。プロジェクトメンバーたちは夏期休暇中も懸命に作業を続けたが、2015年8月末になると、スケジュールの見直しが検討され始める。
プロジェクトメンバー全員が、スケジュール遵守に向けて踏ん張り続けるなか、最終的には9月半ばに延期が決定された。開発の進め方や改善策、開発体制および部内マネジメントの強化などの取り組みを進めたうえで、翌2016年1月に新たなスケジュールを決定することになった。
本稼働の延期を決定
すべての設計・製造作業を停止
2015年9月からの3カ月間、設計・製造作業をすべて停止。情報システム部はプロジェクトの立て直しに向けて課題を洗い出し、解決に向けて動き出した。
スケジュール延期の理由は、重要な機能の開発・検証、およびシステム全体に共通する環境整備や共通システムの整備が遅延していることにあった。そこで情報システム部ではまず、権限管理、オンライン決済、排他制御、操作ログの管理、そしてEUC環境など、アプリケーションに共通する機能の整備に着手した。RISING4のアプリケーション・フレームワークの枝葉（共通機能）の強化が求められていた。
また各工程で作業すべきタスクと成果物を整理し、それに対する承認など学内の役割分担を明確化した。
たとえば要件定義の工程では、ユーザー部門は業務一覧や業務フローを作成し、情報システム部はその業務フローを実現するための基本的な機能設計を行う。テスト工程では、情報システム部門はシステムテスト（性能改善を中心とするテスト）を実施し、ユーザー部門は運用テスト（本番業務利用を想定したテスト。マニュアル作成や説明会開催に備える）を行うなど。
進捗については、システムごとに業務システム責任者を座長とする「定例会」で進捗管理、開発各工程の作業量と詳細スケジュールを共有し、定期的に事務情報システム運営委員会で報告することとした。
「各工程で何をすべきかを整理したことにより、あらためて要件定義の段階で機能要件を整理し、RISINGⅢの仕様や機能をどのぐらい踏襲するかも明確にできました。また週次で全体進捗、各サブシステムの開発状況、基盤進捗について共有する場を部内に設けました。これによりメンバー全員で課題を共有できたのはもちろん、たとえばユーザー部門からの報告をどのように受け付けるかなどについて、サブシステム間で統一的に進められました。こうして、アプリケーション開発全体の方向性が定まることになりました」（石井氏）
そして新たなスケジュールとして、入学システムは大学院の入学者出願については2016年12月、学部・大学院の2017年4月入学者の手続きについては2017年2月に本番稼働。学生システムについては、全サブシステムを2018年1月に本番稼働させることを新たな目標に据えた。
2016年1月、プロジェクトは2度目のキックオフを迎えた。日本IBMはシステム基盤構築およびアプリケーション・フレームワークワークの開発支援を終え、4月よりアプリケーション設計、製造チームとして金沢総合研究所と京都電子計算（株）が参加している。
開発ボリュームとしては圧倒的に学生システムのほうが大きい。しかし情報システム部とユーザー部門はプロジェクト開始前から、RISINGⅢの改修について繰り返しコミュニケーションを重ねていたため、苦労はあったが、要件定義工程やテスト工程をスムーズに進めることができた。
学生システムのなかで苦労したのは、「パフォーマンス改善」と「データ移行」である。
「パフォーマンス改善」は、主に学生が利用する機能の速度改善である。学生の受講登録や成績発表、卒業合否発表はWebで実施することを基本としている。最大で3万5000名の学生からのアクセスが集中するため、プロジェクト再始動後の2017年8月から12月にかけて、性能検証およびパフォーマンスチューニングを繰り返し実施し、冗長性のあるロジックの見直しやデータの索引付けを進めた。
また「データ移行」は、RISINGⅢに蓄積されたデータをRISING4へ移行するものであり、「移行計画書」に基づき、2017年8月から12月にかけて、合計3回の事前リハーサルを実施した。
「12月末の本番切り替え期間は7日間であり、そのうちデータ移行は3日間で終える必要がありました。スケジュール上も作業内容からも後戻りが困難なので、担当者間で共通認識をもつことが重要でした。複数回の事前リハーサルで、作業内容や工程の見直しを適宜実施していたので、本番の切り替え作業時は手順どおり進められました」（石井氏）
こうして最終的には、入学システムは2017年5月、学生システムは2018年1月、無事に全面本稼働を迎えている。
桜の花が咲き乱れ、キャンパス内でフレッシュな新入生の姿を目にする2018年4月。入学式を終えると、全学生がRISING4を使って受講登録を行う。同時に教職員は、RISING4で授業準備を行う。ユーザー数が多く、パフォーマンスの負荷も高い受講登録を乗り切ることができた。
「今年は昨年に比べて、窓口での学生からの受講登録に関わる質問や問い合わせが少なかったように思います。受講登録機能を改善し、受講エラーの内容が画面上に即時に表示されることで、窓口に来なくても、学生自身で解決できたのではないかと考えています」と、柴田直人教学部次長（現。2017年3月まで情報システム部次長）は語る。
学生が無事に受講登録を終えた。大きな節目を乗り切ったこのとき、プロジェクトがついにゴールに達したのだと、メンバーたちは実感した。やっと枝葉の茂ったアプリケーション・フレームワークの大木に、これまでの苦労が実を結んだのである。
プロジェクトが停止した3カ月間で
立命館スタンダードを確立する
内製主義を現実のものとするためには、アプリケーション・フレームワークと、アプリケーション開発標準、いわば「立命館スタンダード」の確立が不可欠である。
「2015年9月に本番稼働の延期を決定するまでは『スタンダードをもたない苦しみ』、スタンダードができてからは、『スタンダードどおりに履行する苦しみ』に直面したと感じています」と、岡氏はプロジェクトの遅延について総括する。
延期決定に際しては、ホッと安堵した気分と、「予定どおりに進行できない」あるいは「ユーザーとの約束を守れなかった」という自責の念が入り混じり、複雑な気持ちを味わったというメンバーたち。
その一方で、最初に本番稼働の延期が決定し、すべての設計・製造作業を停止してから再キックオフまでの3カ月間は、非常に貴重な時間であったと誰もが指摘する。この期間に行われた体制の見直しや整備が、アプリケーション・フレームワークを含め、真の意味での「立命館スタンダード」を確立し、同大学が目指す内製主義の礎となったからだ。
「この3カ月の仕切り直しの時間がなかったら、立命館仕様のアプリケーション・フレームワークはいつまでもベータ版の域を出なかったかもしれません。これでようやく枝葉が整いました」（服部氏）
本番稼働後のトラブルシューティングが落ち着き、RISING4は安定した運用が続いている。今後は情報システム部およびクレオテックで開発者の拡充に注力していく計画である。
本番稼働後には多少のトラブルも発生したが、歴代のRISING本稼働時に比べると格段に少ないという。学内ではRISING4は安定していると、高く評価されている。
「それは内製体制により、トラブルシューティングのスピードが格段に速くなっていることが影響していると思います。大きなトラブルに発展する前に、不具合を小さな芽のうちに摘めるようになったこともあるでしょう」と、岡氏は指摘する。
学生システムのなかで、最も開発ボリュームの大きい履修成績管理サブシステムを担当した情報システム課の竹村政善課長補佐は、2012年に業務部門から情報システム部へ異動した。システムの開発経験はない。今回のプロジェクトでは、ユーザー部門との調整や要件定義に始まり、運用テストまでのアプリケーション開発工程すべてを進める役割を果たした。
「情報システム課のなかで、業務経験が豊富なメンバーとITに精通したメンバーがチームを組み、協力しながら一丸となって開発に携われたのはとてもよい経験でした。今まではユーザー部門からの問い合わせがあっても、外部からの常駐SEに確認してからでないと回答できませんでした。でも今回のプロジェクトでは、ITに精通したメンバーが常に隣にいて、普段のコミュニケーションのなかで自然に設計、製造の内容に詳しくなれました。プログラムが書けるわけではありませんが、設計、製造チームとユーザー部門の間を調整していく過程で、設計書からプログラムの実際の動きを自然に理解できるようになりました。だから今は、ユーザー部門からの問い合わせにもすぐに回答できます。これも、内製ゆえの強さではないかと思います」（竹村氏）
次のステージへ向けて
プロジェクトが再び動き出す
2018年度前半期は、本番稼働後の不具合が予想したよりも少なかったことから、今回のプロジェクトで積み残したバックログへの対応を前倒しで進めてきた。全システムで50～60件の対応を行っている。
また2018年度後半期には、本番稼働後は凍結していた各部門からRISING4への改修・新機能に関する要望の受け付けを再開する。要望を受け付ける仕組みを検討・集約し、予算化したうえで、来年度からは具体的な機能開発に取り組んでいく。
情報システム部の課題はほかにもある。たとえば入学システム、学生システムに続く第3のシステムの構築も求められている。さらに発生源入力を推進させるためのWeb申請基盤、電子稟議や内部統制を前提にした文書管理など、一般の企業と同様に、事業体を支える業務基盤の整備にも取り組んでいく。堅牢性、資産継承性に優れ、基幹データへのアクセスが容易なIBM i環境で実現していくか、あるいはクラウドサービスで実現するか、今後の重要な検討課題となっている。
同大学が目指す教学改革とグローバル化を支え、内製主義を可能とする柔軟なソフトウェア基盤は、次のステージに向けて着実に歩を進めているようだ。
････････
PART 1 2013-2015 RISING4の始動
資産継承性の高いソフトウェア基盤と
内製主義を貫く体制確立に向けて
････････
INTERVIEW
RISING4のプロジェクトで得た大きな財産が
今後の学園改革の礎となる
田尻 実氏 学校法人立命館 情報システム部 部長
････････
PART 3 RISING4の技術
独創的なWeb画面生成機構を開発
部品化・レイヤ化・テンプレート化も導入
････････
［i Magazine 2018 Winter（2018年11月）掲載］
