1.　はじめに

業務の標準化と効率化を目的として広く導入されているパッケージシステムは，短期間での導入やベンダによる保守性の高さなど多くの利点を持つ一方，過剰なカスタマイズがシステムの複雑化やブラックボックス化を引き起こし，DX推進の妨げとなることが指摘されている[1]．特に，ベンダーロックインや部門間のサイロ化，外部システムとの柔軟な連携の困難さは，組織の変革を阻害する要因となっており，パッケージシステムの標準機能を維持しながら，柔軟な拡張と現場ニーズへの迅速な対応を可能にする仕組みや体制の構築が，DX推進には不可欠である．

IPA（独立行政法人情報処理推進機構）は，既存システムの刷新に向けて「使える部分は形を変えて再生し，価値ある存在に変化させること」を目指し，「スサノオ・フレームワーク」を提案した[2]．このフレームワークは，DX実現に必要なITシステムの全体像と技術要素群を示しており，現行業務を支える業務・基幹システム群や業界・社会共通基盤からなる「業務・基幹システム／共通基盤」，独自サービスアプリや他業種連携，外部サービスを含む「独自・他業種連携サービス」，そしてデータ利活用に向けた「データ分析・活用基盤」で構成される．スサノオ・フレームワークの特徴は，これら異なるシステム群をカスタマイズによる直接連携ではなく，APIを活用した疎結合で連携する点にある．APIによる疎結合は，個別システムの改修や追加が全体に影響を与えにくいため，新技術や新サービスを迅速に取り込むことができる．API連携によって，各システムの独立性と安定性を維持しながら，柔軟なデータ連携や機能拡張の開発を可能にする．

2018年に経済産業省が公表した「DXレポート～ITシステム『2025年の崖』の克服とDXの本格的な展開～」[1]では，既存の基幹システムが長年の運用の中で繰り返された過剰なカスタマイズの結果，複雑化・ブラックボックス化した「レガシーシステム」と化していると指摘している．そして，この「レガシーシステム」を刷新できない場合，2025年以降，日本全体で年間最大12兆円もの経済損失が生じる可能性があるという未来予測を提示している．パッケージシステムは基幹システムにおいても広く活用されており，特にERP（Enterprise Resource Planning）や会計，人事，購買などの業務領域では，標準化と効率化を目的としてパッケージ製品が導入されるケースが一般的である[3]．

DXレポートが指摘する問題の核心には，ITシステムを「使う側」の企業や組織であるユーザ（以下これをユーザと呼ぶ）とITベンダとの間に存在する構造的な課題がある．ユーザは，自社の固有な業務プロセスにシステムを適合させるため，ITベンダに個別最適なカスタマイズを要求する．これにより，ユーザは多大な費用（コスト）と時間（期間）をシステム開発に費やすこととなる．一方で，個別要求に応じたカスタマイズを請け負うITベンダ側も，顧客ごとに仕様が異なるシステムの保守運用という煩雑かつ非効率な業務を抱え込む．この構造は，システムの硬直化とベンダーロックインを招き，結果としてユーザのビジネスアジリティを低下させ，ベンダの技術革新への投資を阻害するという，共倒れとも言える状況を生み出している．

香川大学は，DXを推進すべくDX推進戦略「デジタルONE戦略[4]」を策定した．「デジタルONE戦略」は，「『リアル世界がデジタル世界に包含される（Online Merges with Offline [5]）状況を香川大学で実現すること』で，教職員学生の協働によりデジタル化をこれまでにないレベルに引き上げ，教育，研究，運営の質的向上に加え，それぞれの業務の効率化を進めること」を目指しており，「デジタルONEキャンパス」，「デジタルONEラボ」，「デジタルONEオフィス」の実現を全学の基本方針として定めたものである．「デジタルONEオフィス」は，「デジタル世界に大学の事務局機能を構築することで大学業務の効率的運用を促し，教育研究の本務に専念できる環境を構築する」ことを目的とする．

香川大学は，2021年5月に「デジタルONE戦略」の実現にむけて「DX推進部門」（情報化推進統合拠点DX推進研究センター）と「DXラボ」[6]を組織した．「DXラボ」は，システム設計・開発を専門とする教員や情報部の職員，企業から招聘した教員や研究員，情報技術を学ぶ香川大学の学部学生と大学院生から構成され，学内の業務課題をデザイン思考[7]を用いて分析し，DXの推進に資する業務システムの内製開発をおこなっている．DXラボによる業務システムの内製開発[8]は，現場部門の担当者をプロダクトオーナーに位置づけ，DXラボのメンバーがスクラムマスター，開発者を担い，アジャイル開発手法のスクラム開発で業務システムを開発する．DXラボによる業務システムの内製開発では，ローコード・ノーコードプラットフォームのMicrosoft Power Platform^*1（以下，Power Platform）が用いられ，2025年11月現在で140を超える業務システムが内製開発された．また，2022年4月には「デジタルONEオフィス」を実現すべく，主体的にDX推進に取り組む非情報系の事業部門職員を任命する「香川大学デジタルONEアンバサダー」制度[9]を開始した．「デジタルONEアンバサダー」には，ローコード・ノーコードプラットフォームを用いて業務システムを内製開発するスキルを獲得する「業務システム開発ハンズオン」[10]の受講が推奨された．その受講を踏まえて2025年1月の時点で176の業務システムが「デジタルONEアンバサダー」によって内製開発され，香川大学においてその多くが実際に運用されている．

香川大学では，基幹システムに位置づけられるパッケージシステムを活用した教務システム（富士通Japan株式会社製Campus-Xs^*2）の追加機能として「大学ダッシュボード」[11]と「お知らせ自動要約機能」[12]を内製開発した．これらの追加機能は，教務システムのカスタマイズではなく，API（Application Programming Interface）を介してパッケージシステムと連携する独立したシステムとして開発され，基幹システムの安定性や保守性を維持しつつ，現場のニーズに応じた機能を開発した．本稿では，香川大学における教務システム追加機能の内製開発事例について述べるとともに，その事例から有効性を考察する．2章では，プロトタイプ開発によるAPI要件の定義について述べる．3章では，教務システム（パッケージシステム）の追加機能として内製開発された「大学ダッシュボード」と「お知らせ自動要約機能」について述べる．4章では，考察を述べる．5章ではむすびを述べる．

本稿は，パッケージシステムを活用しながら業務の改善や高度化などDXに取り組む組織に向けて，それを実現するための方策を議論している．

2.　プロトタイプ開発によるAPI要件の定義

基幹システムの柔軟な拡張や外部連携の重要性が高まる中で，API設計・実装については，「コードファースト」と「APIファースト」という2種類のアプローチが存在する[13]．「コードファースト」は，まずシステムのコア機能やビジネスロジックを実装し，その後にAPIを設計・実装する手法であり，既存システムへのAPI追加や連携先が未定の場合に選択される．一方，「APIファースト」は，システム開発の最初にAPIの仕様を設計・合意し，そのAPIに基づいてコア機能やアプリケーション本体を開発する手法であり，複数チーム・サービスが連携する場合や，API連携が重要なプロジェクトで推奨される．

本研究では，香川大学の教務システムCampus-Xsを基幹システムとして活用しつつ，現場の多様な業務ニーズや新たな機能追加に迅速に対応すべく，はじめに教務システムと直接連携しない形で，教務システムから出力したCSVファイルを用いて現場ニーズに基づく追加機能のプロトタイプを開発した．プロトタイプの開発は，現場部門の担当者をプロダクトオーナーとし，DXラボのメンバーがスクラムマスター・開発者としてアジャイル開発手法を用いて進められた．この段階で，業務フローや必要なデータ項目，機能要件を具体的に把握し，ステークホルダー間で共通認識を形成した．現場からのフィードバックを迅速に反映することで，業務に本当に必要な機能やAPI連携の要件を明確化させた．

プロトタイプ開発で得られた知見をもとに，教務システムと連携するためのAPI設計を進めた．API設計にあたっては，API連携を前提とした追加機能開発をおこなうため，RESTful APIおよびOpenAPIに準拠した設計方針を採用した．プロトタイプ開発を通じて業務側の要求を具体化したうえで，APIとして公開すべき機能および対象データを限定し，その仕様をOpenAPI形式で整理・共有することで，教務システムのベンダと事前に合意形成をおこなった．具体的には，内製業務システムが必要とするデータ取得・更新APIの仕様を，教務システム側と協議しながら定義した．API仕様やドキュメントの整合を図ることで，双方の開発チームが共通認識を持ち，手戻りや仕様不一致を防止することができた．このアプローチは，「コードファースト」の柔軟性と，「APIファースト」の仕様整合・品質向上の利点を組み合わせた開発アプローチといえる．このようなハイブリッドな手法は，現場主導の業務システム開発において，基幹システムの安定性を維持しつつ，DX推進に資する柔軟な機能拡張を実現する可能性がある．

先行研究では，パッケージシステムのカスタマイズやAPI設計に関して，主にベンダ主導の開発プロセス[14]や，「コードファースト」手法[15]が中心に論じられてきた．これらの手法は，システムの安定性や保守性の確保には有効である一方，現場ニーズへの迅速な対応や，複数組織・サービス間の連携においては柔軟性に課題が残る．また，「APIファースト」型は，近年マイクロサービスやクラウドネイティブなシステム設計の文脈で注目されているが，ユーザ主導の業務システムの追加機能開発における実践例はほとんどない．本研究は，プロトタイプ開発を通じて現場ニーズを抽出し，その結果からAPI設計をおこなう，基幹システムの安定性と柔軟な拡張性を両立するこれまでとは異なるAPI開発アプローチを提案している．

3.　教務システム追加機能の内製開発

3.1　大学ダッシュボード（教育情報）

大学などの高等教育機関は，学校教育法で定められた目的を実現するため，社会への説明責任を果たすことが求められる．特に，学部・学科の名称や学生数，教職員数などの教育情報は，教育の質保証の観点から公開が義務付けられている．香川大学では，教育情報の公開[16]に加え，教育・研究・組織運営の継続的な点検・評価を通じた内部質保証の取り組み[17]を実施している．しかし，教育情報の元データは部局ごとに異なるフォーマットで管理されており，公開時には統合作業が必要であった．

香川大学では，2023年に教務システムCampus-Xsを導入した．Campus-Xsは，学生向けの「教務情報（学籍管理，修学指導等）」と「学生支援情報（健康管理，奨学金等）」を管理する機能，教職員向けの「授業に関する業務」や「教育研究活動」を支援する機能を有し，香川大学で実際に運用されている．

本研究では，この教務システムのデータ取得APIを活用し，教育情報を自動生成・可視化・公開する「大学ダッシュボード（教育情報）」を内製開発した．図1は，「大学ダッシュボード（教育情報）」の概要を示す．本システムは，Microsoft Power Automate^*3，Microsoft Power BI^*4，Microsoft SharePoint^*5と，富士通Japan株式会社と共同開発したデータ取得用API（データ取得API）を連携させ，教務システムから定期的にデータを自動取得し，教育情報を生成・可視化して公開する．

データ取得APIはMicrosoft Power Automateから呼び出され，取得データはMicrosoft SharePointに格納される．Microsoft Power BIは，SharePointに格納されたデータを基に教育情報を可視化し，大学ダッシュボードとして公開する．この仕組みにより，ダッシュボードは定期的に自動更新され，インターネットから常時閲覧できる．

図2は「大学ダッシュボード（教育情報）」の学生数ダイジェスト画面を示す．ダッシュボードは，学部や研究科，学生数などの教務システムのデータを基に教育情報を生成・公開する．各部署がデータを数日かけて集計していたが，データソースが教務システムのデータとするため，部署横断の集計作業が不要となり教育情報公開業務の工数を削減できる．

3.2　お知らせ自動要約システム

香川大学で導入された，教務システムCampus-Xsには，講義情報，管理機能や成績登録機能，お知らせ機能など教職員の教務活動を支援する機能や学習活動を支援する機能を備えている．

お知らせ機能は，講義連絡やイベント情報の周知，注意喚起など，多岐にわたるお知らせを学生に通知する機能である．しかし，お知らせの量が多く，学生がすべてを確認できず，重要なお知らせを見逃すケースが報告されていた．

この課題に対応するため，香川大学は「お知らせ自動要約システム」を内製開発した．本システムは，膨大なお知らせを自動要約し，学生に通知することで確認作業の負担を軽減することを目的とする．本システムでは，従来学生に対して複数件通知されていたお知らせを，1日1回の要約通知として集約する運用としている．そのため，本システムの目的は通知回数そのものの削減ではなく，学生が受信する通知件数および閲覧負荷を低減することにある．要約品質については，文書の内容や構成によって差異が生じることを確認しており，本研究では定量的な品質評価はおこなっていない．学生向け通知として致命的な誤要約が発生しないことを重視し，原文参照を前提とした補助的な機能として設計・運用している．また，要約結果を単独で意思決定に用いることは想定しておらず，学生が原文を確認することを前提とした情報提示の位置づけとしている．さらに，要約から気になるお知らせをお気に入り登録できる機能を備え，重要情報の見逃し防止に寄与する．

本システムは，Microsoft Power Automate，AI Builder（生成的自然言語処理），Microsoft Teamsを連携させて開発された．図3に，開発したお知らせ自動要約システムのシーケンス図を示す．毎朝9時にPower Automateが起動し，データ取得APIを通じて教職員が登録したお知らせを取得する（図4）．取得したお知らせは，要約プロンプトとともにAI Builderに送信され，要約結果はMicrosoft Teamsで学生に通知される（図5）．お気に入り登録機能は，教務システムのデータ更新用API（データ更新API）を用いて開発された．

4.　考察

本章では，香川大学における教務システム追加機能の内製開発事例について考察する．4.1では，API疎結合によるシステムの拡張性や安定性の視点から考察する．4.2では，ユーザ主導によるパッケージシステムの追加機能開発の視点から考察する．

4.1　API疎結合によるシステムの拡張性や安定性

パッケージシステムは業務標準化や効率化を目的に導入される一方で，過剰なカスタマイズがシステムの複雑化やブラックボックス化を招き，DX推進の障壁となることが指摘されてきた[1]．香川大学において基幹システムに位置づけられるパッケージシステムを活用した教務システムCampus-Xsの「大学ダッシュボード」と「お知らせ自動要約機能」の追加機能の内製開発では，基幹システムと追加機能を独立したシステムとして開発し，APIを介して必要なデータ連携をおこなうことで，基幹システム本体に手を加えることなく現場のニーズに応じた新機能を開発することができた．API設計にあたっては，取得・更新対象となるデータ項目について，業務要件およびセキュリティ要件の双方から検討を行った．具体的には，APIで取得するデータ項目の採用基準として，

• (1) 業務上必要不可欠であること
• (2) 個人情報・機微情報を含まないこと
• (3) 既存業務フローにおいて既に参照権限が付与されている利用者に限定して提供可能であること

の3点を基準とした．また，取得系APIと更新系APIでは求められるセキュリティレベルが異なると判断し，両者を明確に分離して設計した．特に更新系APIは教務システム上のデータを直接更新するため，取得系APIと比較してより高いセキュリティポリシーが求められる．このようなAPI連携を前提とした設計では，初期段階においてAPI仕様の整理や合意形成に一定の工数を要する．一方で，プロトタイプ開発を通じて業務要件を明確化し，API仕様を文書として共有したことで，開発途中での大きな仕様変更や手戻りを抑制することができた．特に「お知らせ自動要約機能」ではAI BuilderなどのAI技術を活用し，膨大なお知らせ情報を自動で要約して学生に提供する仕組みを実現している．こうしたAI技術の導入は，現場の業務負担軽減やサービス向上に寄与するだけでなく，今後のさらなる業務の高度化や新たな機能開発の可能性を広げる可能性がある．

また，追加機能が基幹システムから独立しているため，システム全体の安定性や保守性が損なわれにくく，個別システムの改修や障害が全体に波及しにくい点も利点として挙げられる．さらに，APIによる疎結合は特定ベンダへの依存度を下げ，外部サービスや他システムとの柔軟な連携を可能にするため，将来的なシステム刷新や他社サービスの導入を容易にすることも考えられる．加えて，API連携を通じて部門ごとに分断されていたデータや業務プロセスの統合が進み，組織横断的なデータ活用や業務改善も期待できる．

一方で，こうした追加機能を内製開発した場合，その運用や保守はユーザ自身が担うことになる．ベンダが提供する標準機能とは異なり，障害対応や仕様変更，セキュリティ対策，利用者からの問い合わせ対応など，日常的な運用・保守業務が発生する．特にAI技術を活用した機能については，AIモデルの精度維持やアップデート，運用中のトラブルシューティングなど，従来のシステム運用とは異なる知識や体制構築が求められる．本事例では，お知らせ自動要約システムや大学ダッシュボードに限らず，API連携による追加機能を内製開発する場合に一般的に発生しうる課題として整理したうえで，実運用を行っている．実運用においては，API連携部分のエラーや外部サービスの仕様変更に起因する軽微な障害が発生することがあったが，稼働システムを監視しエラー発生時に通知を行うKadaMonitor [18]により，早期に把握・対応できる体制を構築している．また，利用者からの問い合わせは主に機能の利用方法に関するものであり，重大な障害対応に発展するケースは発生しなかったことを確認している．

4.2　ユーザ主導によるパッケージシステムの追加機能開発

香川大学における教務システム追加機能の内製開発は，ユーザが主体となってパッケージシステムの機能拡張を実現する新たなアプローチに位置づけられる．従来，パッケージシステムの機能追加やカスタマイズはベンダ主導でおこなわれることが多く，ユーザ側は要件定義や運用面で受け身になりがちであった．しかし本事例では，現場部門の担当者がプロダクトオーナーとなり，DXラボのメンバーがスクラムマスターや開発者として参画することで，現場のニーズを迅速かつ柔軟に反映した機能を開発した．

また，ローコード・ノーコードプラットフォームの活用や「デジタルONEアンバサダー」制度の導入により，非情報系部門の職員も内製開発に参画できる体制が整えられた．内製開発を継続的におこなうためには，APIの設計・管理を個人に依存させない体制が重要である．本事例では，APIの設計および仕様管理をDXラボが担い，RESTful APIおよびOpenAPIに準拠した仕様書をバージョン管理している．新規APIの追加や変更時にはレビューをおこなうことで，APIの増加に伴う管理上の課題への対応を図っている．一方，デジタルONEアンバサダーは，DXラボが整備したAPIを利用して業務システムの開発・改善をおこなう．このように，API設計と利用の役割を分離することで，技術的な一貫性を維持しつつ，現場主導の内製開発を持続可能な形で実現している．これにより，現場の課題や要望を直接システムに反映できるだけでなく，業務改善やDX推進に対する現場の主体性や意識の向上にもつながる可能性がある．内製開発は，短期的には人材育成や運用・保守を含めた負荷が増加するという課題を伴う．一方で，業務理解や要件定義に関する知見が組織内に蓄積され，開発手法や外部サービスの選択肢が広がるという長期的な効果がある．本事例では，内製開発によって得られた知見を外部委託開発にも活用することで，ベンダとの役割分担を明確化し，状況に応じた開発手法の選択が可能となった．このように，内製開発と外部委託開発は対立するものではなく，組織の状況や対象業務に応じて組み合わせることが重要である．

一方で，ユーザが内製開発を進める場合，開発スキルやノウハウの蓄積，運用・保守体制の整備，継続的な人材育成など，組織としての開発運用体制の構築が必要不可欠となる．特に，現場主導で多様なシステムが開発・運用されることで，全体の統制や品質管理，セキュリティ対策など新たな課題も生じる．今後は，こうした課題に対応しつつ，ユーザ自らが主体的にシステムの価値向上を図るための仕組みやガバナンスを確立させる必要がある．本研究では，取得系APIと更新系APIを分離して設計したことで，APIごとに求められるセキュリティポリシーを明確化できた．特に更新系APIについては利用主体および利用目的を限定することで，誤操作や不正利用による業務影響のリスクを低減している．このようなAPI分離設計は，基幹システムの安定性を維持しつつ内製開発を進めるうえで，有効な設計指針の1つと考えられる．

5.　むすび

本稿では，香川大学における教務システム追加機能の内製開発事例として，大学ダッシュボードおよびお知らせ自動要約システムについて述べた．これらの事例を通じて，基幹システムを改変することなく，APIを介して疎結合に連携することで，基幹システムの安定性や保守性を維持しつつ，現場のニーズに応じた柔軟な機能拡張が可能であることを示した．また，ユーザが主体となって内製開発を進めることにより，業務改善やDX推進を迅速に進められる可能性について考察した．

一方で，本研究は特定の大学における事例に基づくものであり，内製開発を成立させるためには一定の前提条件が存在する．具体的には，トップダウンによる組織的な開発・運用保守体制の整備と，ボトムアップによる開発・運用を担う人材育成の双方が不可欠である．また，基幹システムで対応すべき領域と，内製開発で対応すべき領域の切り分けや意思決定は容易ではなく，組織の状況やリソースに応じた判断が求められる．これらは，本研究における適用上の限界として位置づけられる．

今後の課題としては，内製開発と外部委託開発を適切に組み合わせるための判断基準の整理，API連携を前提としたシステム構成における長期的な運用・保守体制の維持，ならびに人材育成を含めた持続可能な開発体制のあり方について，継続的な検証が必要である．

謝辞　本研究の一部は富士通Japan株式会社との共同研究によって実施された．関係者に謝意を表する．