1.　はじめに

情報処理推進機構（以下，IPA）の「DX白書2024」[1]は，DX実現にむけた技術としてシステム開発の内製化を取り上げるとともに，内製化に取り組む企業が近年増えていることを報告した．香川大学では2021年5月に，システム設計・開発を専門とする教員，情報部職員，企業から招聘された教員・研究員，学生らで構成される「DXラボ」を組織し，学内業務課題の分析と業務システムの内製開発にも取り組んでいる[2]．業務システムの内製開発では，ローコード・ノーコードプラットフォームであるMicrosoft Power Platform（以下，Power Platform）[3]を採用しており，多くの内製システムが実際に香川大学で運用されている[4]-[7]．

香川大学における出張処理業務は，申請者から出張申請・報告システムを用いて出張申請に必要な情報を収集する「申請フェーズ」，部局事務担当者が，財務情報システムを用いてそれら情報から決裁書類を作成し，決裁者がそれを決裁する「決裁フェーズ」，出張者が出張する「出張フェーズ」，申請者が出張申請・報告システムを用いて出張を報告するとともに，必要な証憑を提出する「報告フェーズ」，経理担当者が，出張報告書や証憑から旅費を計算し，財務情報システムを用いてそれを精算する「精算フェーズ」の5つの業務フェーズから構成されている．出張申請・報告システムは香川大学で内製開発された．本システムにより，出張処理業務の一部は電子化・自動化されたが，「『申請フェーズ』は正しく完了されたのに『決裁フェーズ』の決裁書類の作成が開始されず，出張者からの出張報告書によって出張処理が正しく実行されていないことが判明した」や「出張者から出張報告書が提出され，正しく『報告フェーズ』が完了したにもかかわらず『精算フェーズ』が開始されず，精算されないことを不審に感じた出張者からの問い合わせでそれが判明した」など，香川大学は，正確性，迅速性，信頼性といった観点で出張処理業務の品質の確保に課題を有していた．

モダナイゼーション[8]とは，老朽化した情報システムを，新しい技術やアーキテクチャへと移行・刷新する取り組みを指す概念である．DXの文脈においても，基幹業務システムの刷新やクラウド化，マイクロサービス化などがモダナイゼーションの代表例として挙げられる．しかしながら，大学における基幹業務システムは，制度対応や安定運用の観点から，長期間にわたり利用されてきたレガシーシステムであることが多く，全面的な刷新や再構築は容易ではない．本研究では，こうした制約条件を前提として，モダナイゼーションを「刷新が困難な既存のレガシーシステムを活用しつつ，業務全体の改善や高度化を段階的に図る取り組み」と定義し，業務プロセスの進捗や停滞を横断的に可視化・監視する出張処理業務モニタリングシステムをローコード・ノーコードプラットフォームを用いて内製開発する．本システムは，基幹業務システムそのものを刷新するのではなく，業務プロセス全体を横断的に可視化・監視し，データに基づく継続的な改善を可能とする運用基盤へと転換する点において，本研究で定義したモダナイゼーションに該当する．

本稿では，既存の出張申請・報告システムや財務情報システムの運用データから出張処理業務を分析した結果について述べるとともに，内製開発した出張処理業務モニタリングシステムについて述べる．2章では，他大学や他組織で導入されている出張処理業務システムについて述べる．3章では既存の出張申請・報告システムと財務情報システムの運用データから出張業務を分析した結果について述べる．4章では，分析結果に基づいて内製開発した出張処理業務モニタリングシステムについて述べる．5章では，運用結果を述べる．6章では，考察を述べる．7章では，むすびを述べる．

2.　関連研究

他大学や他組織で導入されている出張処理業務システムとしては，業務における申請・承認・決裁などの一連のワークフローを電子化するワークフローシステム（例：SmartDB [9]，Kintone [10]），経費精算処理における申請・承認・支払などの業務を効率化し，サポートする経費精算システム（例：楽楽精算[11]），交通機関や宿泊先の手配，経費処理など出張に関する業務を一元管理できる出張管理システム（例：SAP Concur [12]）等が存在する．ワークフローシステムは，柔軟な承認ルートや入力チェック機能，権限制御機能などにより各組織の事情に合わせた柔軟なワークフローを実現することができる．経費精算システムは出張の経費精算機能を，出張管理システムは経費精算機能に加えて交通手段や宿泊の手配機能などを提供する．複数のフェーズに分かれた出張処理業務の進捗を可視化するとともに，出張報告書の提出遅延や業務停滞を検知し，それについてアラートを通知する仕組みを実現するためには，財務情報システムのような既存の基幹システム（レガシーシステム）とのデータ連携が必要となる．基幹業務システムとのデータ連携については，複数のクラウドサービスやオンプレミスで管理されている基幹業務システムのデータを一元的に連携するiPaaS（Integration Platform as a Service）等の採用が考えられる[13], [14]．iPaaSを採用することで，基幹業務システムが用意するAPI（Application Programming Interface）やCSV出力機能を用いて必要なデータを取得することはできるが，本研究で対象とした香川大学の出張処理業務のように，システムを利用しない業務を含む，複数のフェーズに分かれた業務全体をシステム化するためには，業務プロセス全体をワークフローシステム等でシステム化し，基幹業務システムと連携させるなど，大規模な開発が必要になる．

出張処理業務モニタリングシステムは，スサノオ・フレームワーク[15]の設計思想に基づき，「業務・基幹システム／共通基盤」である既存の財務情報システムと，ローコード・ノーコードプラットフォームにより内製開発した「独自・他業種連携サービス」である既存の出張申請・報告システムを拡張し，システム外の業務も含めた業務データを対象とする「データ分析・活用基盤」として開発したものである．本研究は，このような構成により，レガシーシステムを前提としながら業務全体を横断的に可視化・分析するモニタリング基盤の構築方法を示すものであり，業務改善や高度化に取り組む組織に対する1つの方策を提示している．

3.　既存システムの運用データ分析

香川大学において出張処理業務は，既存の出張申請・報告システムや財務情報システムを用いて実施され，業務品質の確保に課題を有していた．本章では申請者，部局事務担当者へのインタビュー調査結果から明らかとなった出張処理業務の課題，既存システムである出張申請・報告システムと財務情報システムの運用データを分析した結果を報告する．

3.1　既存の出張処理業務に関連するシステム

出張申請・報告システムは，Microsoft Forms（以下，Forms）[16]とMicrosoft SharePoint [17]（以下，SharePoint），Microsoft Teams [18]（以下，Teams）を連携させて開発された．財務情報システムについては，香川大学では富士通Japan社製のIPKNOWLEDGE [19]が導入されている．図1は出張申請・報告システムを用いて実施される「申請フェーズ」と財務情報システムを用いて実施される「決裁フェーズ」のBPMN図（Business Process Model and Notation）を示している．申請者は出張申請・報告システムを用いて部局事務担当者に出張申請を提出する．出張申請はTeamsで部局事務担当者に共有される．用務関連資料（会議の開催案内等）や領収書については，それを提出するフォルダがSharePointに生成される．申請者は用務関連資料や領収書をそこにアップロードする．申請・報告情報の不足，不備に関する連絡については，Teamsを介しておこなわれる．申請内容は，SharePointのリスト機能で構築されたデータベースに保存される．部局事務担当者はSharePointのリスト機能で構築されたデータベースから財務情報システムを用いて決裁書類を作成し決裁する．

3.2　運用データ分析の結果

出張申請・報告システムは，香川大学情報化推進統合拠点を対象として2024年4月から運用が開始された．香川大学では，出張申請の運用ルールや管理プロセスが部局ごとに異なるため，まず情報化推進統合拠点において運用モデルを構築し，その有効性を検証したうえで，他部局へ展開するパイロット運用の場として同拠点を位置づけた．対象とした業務規模は，情報化推進統合拠点の構成員47名であり，2024年4月から2025年3月までの1年間における出張申請・報告システムでの出張申請数は144件であった．一方，財務情報システム上での決裁完了数は237件であり，この差異は，クロスアポイントメント（大学と企業の双方と雇用契約を結ぶ形態）により企業から派遣されている研究者の出張や，出張後に個別連絡により処理される案件など，出張申請・報告システムを利用しない処理パターンが存在することに起因する．144件の申請・報告に対して，Teamsでは794件のやり取りがおこなわれた．794件のやり取りの多くが申請・報告情報の不足や提出資料の不足，不備に起因して発生したやり取りである．香川大学では業務工数の削減を目指し，申請者，部局事務担当者，経理担当者間のやり取りを減らすべく，申請・報告情報の不足や提出資料の不足・不備を自動で確認し，申請者に不備を連絡する「自動チェック・連絡機能」の開発を現在おこなっている．

財務情報システムは，香川大学全体の出張処理業務における「決裁フェーズ」で利用され，香川大学では，出張に際しては原則として出発前に決裁すること（事前決裁）が求められている．図2は情報化推進統合拠点の2024年度に出張申請・報告システムから事前申請された申請のうち事前決裁された割合を示しており，事前申請されたにもかかわらず34.0%が事前決裁されていない状況が明らかとなった．図3は，情報化推進統合拠点の2024年の決裁日から出張開始日までの日数を示している．X軸の決裁日から出張開始日までの日数がマイナスのデータは，事前決裁された申請を示す．出張開始日の1週間前までに決裁された申請は20.1%（図3※1）に過ぎず，出張開始から31日後（図3※2）に事後決裁がすべて完了するなど，決裁にかかる日数が長期におよぶ実態も明らかとなった．申請者からの出張申請が遅れたケースに加えて，出張申請がかなり早くされた（「申請フェーズ」は適切に完了していた）にもかかわらず，決裁されず放置されていた（「決裁フェーズ」が適切に開始されなかった）ケースも多数あることも明らかとなった．また出張直前の申請など至急対応が必要なケース（優先して対応しなくてはならないケース）でも，それを優先して実施する仕組みがなかったため（属人的に「これは優先して実施してください」など口頭で伝えるケースはあったが組織的に優先させる仕組みはなかった），多くの出張申請業務が出張後に決裁されていた．

図4は情報化推進統合拠点の「報告フェーズ」の完了日数を示している．「報告フェーズ」を1週間以内に完了したのは全体の63.2%（図4※1）に過ぎず，1カ月以上かかったケースが2.1%（図4※2では97.9%）確認された．図5は2024年度の出張終了日翌月末の精算完了割合を示す．出張終了日翌月末の精算完了割合は，96.6%であった．

3.3　既存システムの課題分析

本研究では，情報化推進統合拠点の職員3名を対象にインタビュー調査を実施した．インタビュー調査は2025年2月に実施され，「設問1：既存の出張申請・報告システムの効果に関する設問」，「設問2：既存の出張申請・報告システムの課題に関する設問」，「設問3：既存の出張申請・報告システムの課題を解決するために必要なシステムに関する設問」の3つの設問から構成された．「設問1：既存の出張申請・報告システムの効果に関する設問」では，「申請者と部局事務担当者による『前泊や昼食の有無』，『用務内容』などが事前に確認できることで，問い合わせが減った」，「資料の不足が発生した場合も，迅速にTeams上でコミュニケーションができるようになった」など，一定の効果があったことを示すコメントが寄せられた．「設問2：既存の出張申請・報告システムの課題に関する設問」では，「出張申請は事前に提出されていたが，用務関連資料等の提出待ちの状態で放置されるケースがあること」，「出張直前の申請など至急対応が必要なケースがあっても，出張申請が多い時期など処理が遅れるケースがあること」，「申請者から出張報告書の提出が遅れるケースがあること」，「経理課に支払依頼をおこなったかを忘れてしまうことがあること」など業務品質の確保に課題があることを示すコメントが寄せられた．「設問3：既存の出張申請・報告システムの課題を解決するために必要なシステムに関する設問」では，「出張報告の提出を促す仕組みがあるとよい」，「出張申請単位でどこまで進捗しているのか，申請者と部局事務担当者の双方がお互いに状況が確認できるとよい」とのコメントが寄せられた．インタビューの結果から，既存の出張申請・報告システムには一定の効果はあったが，業務品質の確保に課題があり，出張処理業務全体を俯瞰し，申請者・部局事務担当者双方での進捗の可視化や，出張報告の提出を促すアラートの通知などが望まれている状況が明らかになった．

本研究では，上記で述べた出張処理業務の課題を踏まえ，特性要因分析[20]をおこなった．特性要因分析は，ある事象（特性）がなぜ起こったのか，その要因を視覚的に表現することができる．特性要因分析は魚の骨になぞらえて，背骨（解決したいテーマ），大骨（背骨の要因となる，主要な要因のカテゴリ），小骨（大骨を構成する個々の要素），孫骨（小骨に潜んでいるミクロな要素）から構成される．本研究では，「出張処理業務が適切に実施されない」を背骨（解決したいテーマ）として設定し，大骨（背骨の要因となる，主要な要因のカテゴリ）として3つの要因（人（申請者，部局事務担当者，経理担当者），システム（出張申請・報告システム，財務情報システム），業務プロセス（業務手順））を設定した．図6は，本研究で実施した特性要因分析の結果を示している．

大骨として設定した「人（申請者，部局事務担当者，経理担当者）」については，小骨として「事後決裁の増加」，「出張報告書の提出遅延」の要素を設定した．小骨の「事後決裁の増加」については，孫骨（小骨に潜んでいるミクロな要素）として「孫骨①：出張日が近い申請から優先的に処理する仕組みがない」という要素を設定した．小骨の「出張報告書の提出遅延」については，孫骨として「孫骨②：出張報告書の提出を促す仕組みがない（もしくは手動で促している）」という要素を設定した．大骨として設定した「システム（出張申請・報告システム，財務情報システム）」については，小骨として「処理の遅れ」，「出張処理業務の進捗状況が不明」の要素を設定した．小骨の「処理の遅れ」については，孫骨として「孫骨③：個々の業務の遅れを確認する仕組みがない」を要素として設定した．小骨の「出張処理業務の進捗状況が不明」については，孫骨として「孫骨④：進捗を担当者が個別に管理している」を要素として設定した．大骨として設定した「業務プロセス（業務手順）」については，小骨として「業務全体を管理する担当者が不在」，孫骨として「システム（出張申請・報告システム，財務情報システム）」と同じ「孫骨④：進捗を担当者が個別に管理している」が設定された．

4.　出張処理業務モニタリングシステム

3章で述べた運用データ分析および特性要因分析の結果を踏まえ，出張処理業務モニタリングシステムを内製開発した．システムの設計にあたっては，「スサノオ・フレームワーク[15]」の設計思想を参考とした．

「スサノオ・フレームワーク」は，「DX実現のためのあるべきITシステムとそれを構成する技術要素群の全体像」で，「業務・基幹システム/共通基盤」，「独自・他業種連携サービス」，「データ分析・活用基盤」の異なる特性を持つシステム群を連携させ，共存させることを求めている．既存の出張処理業務のシステムにこれを当てはめると，財務情報システムが「業務・基幹システム/共通基盤」，出張申請・報告システムが「独自・他業種連携サービス」に位置づけられる．2章で明らかになった業務品質の課題は，これら2つのシステムが連携して業務プロセスを構成しているにもかかわらず，プロセス全体を横断して監視・分析する「データ分析・活用基盤」が不在であることに起因すると分析した．そこで本研究では，業務プロセスを継続的に監視し，改善につなげるBusiness Activity Monitoring（以下，BAM）[21]の考え方を取り入れ，「データ分析・活用基盤」として，新たに出張処理業務モニタリングシステムを開発した．

出張処理業務モニタリングシステムは，既存の出張申請・報告システムの機能を継承・拡張する一方で，申請・報告に関するデータ収集機能と，業務の監視・分析機能を疎結合に構成している．このような構成により，既存システムへの影響を抑えつつ，モニタリング機能を独立して設計・改修できるようにし，システム全体の保守性の確保に配慮した．また，ローコード・ノーコードプラットフォームであるPower Platformを採用することで，現場の業務要件に応じた機能追加や改修を比較的迅速に行える構成とした．システムの分離・増加に伴う運用負荷や管理コストについては，認証やインフラ管理をPower Platformに委ねるとともに，確認結果通知機能にインタフェースを集約することで，DXラボおよび部局事務担当者の運用負担を抑制することを意図している．

4.1　出張処理業務モニタリングシステムの要件

BAMは，業務の進行状況を可視化し，業務プロセスの正確性や効率性などをモニタリングし，問題の検知やアラートの通知をおこなうための方策およびツールを指す．出張処理業務モニタリングシステムは，出張処理業務の進行状況を可視化し，出張処理業務の正確性や効率性をモニタリングしている点でBAMの取り組みにも該当する．

出張処理業務モニタリングシステムは，以下の要件を満たすように開発された．

要件1：出張日が近い申請から優先的に業務が実施できる（確認結果通知機能，孫骨①に対応）

要件2：出張終了後，出張報告の実施を促すことができる（報告リマインド機能，孫骨②に対応）

要件3：出張報告完了後，精算について期限内の実施を促すことができる（業務停滞通知機能，孫骨③に対応）

要件4：出張処理業務全体をモニタリングし，実施ができていない担当者に対してそれを通知できる（業務停滞通知機能，ダッシュボード機能，孫骨④に対応）

要件1は，確認結果通知機能によって実現する．確認結果通知機能は，申請結果，決裁結果，報告確認結果，精算結果を通知する機能である．

要件2は，報告リマインド機能によって実現する．報告リマインド機能は，出張終了日翌朝8時に出張報告未提出者に出張報告提出依頼を送付するとともに，未提出者に毎日リマインドメールを送信する機能である．

要件3は，業務停滞通知機能によって実現する．業務停滞通知機能は，開始から7日間を超えて完了していない業務が存在する場合，業務の停滞を検知して通知する機能である．

要件4は，ダッシュボード機能によって実現する．ダッシュボード機能は，当日の出張者，今後の出張予定，現在処理中の処理状況と，年度別，月別の出張件数，事前申請割合，事前決裁割合，出張終了後1カ月以内の精算完了割合，申請・決裁・報告・精算の各業務フェーズ完了までの期間別出張件数，各業務フェーズの期間分布，Teamsの返信回数を表示する機能である．

4.2　出張処理業務モニタリングシステム

図7は，出張処理業務モニタリングシステムのコンポーネント図を示す．出張処理業務モニタリングシステムは，申請受付機能，確認結果通知機能，報告リマインド機能，業務停滞通知機能，ダッシュボード機能の5つの機能と，申請者からの申請データを記録する出張申請DB，出張処理業務の業務記録を記録する業務記録DBから構成される．出張処理業務モニタリングシステムは，Forms，Microsoft Power Automate（以下，Power Automate）[22]，Microsoft Power Apps（以下，Power Apps）[23]，Microsoft Power BI（以下，Power BI）[24]，Teams，SharePointを用いて開発された．

申請受付機能は，出張申請・報告システムを踏襲し，Formsにより申請者からの出張申請を受け付け，SharePointのリスト機能で構築された出張申請DBに申請内容を記録する．加えて，業務記録DBに申請履歴を記録する．Formsにより受け付けた出張申請は，Teamsに申請単位で別スレッドとして投稿され，部局事務担当者に通知される．同時に，用務資料や領収書を保存するフォルダをSharePointに生成し，申請者には用務資料と領収書のアップロードを促す．申請・報告情報の不足，提出資料の不足，不備に関する連絡については，Teams上のスレッドをコミュニケーションの場として利用する．

確認結果通知機能（図8）はPower Appsで開発され，現在進行中の出張申請の一覧として出張日が近い申請から表示し，申請単位に現在の業務フェーズ，現在の業務フェーズでの滞留日数，報告リマインドや業務停滞通知の実施回数，Teamsの返信数を表示する．詳細画面では出張申請内容の詳細や，用務資料，領収書等，申請者が提出した証憑類が確認できる．

報告リマインド機能はPower Automateにより開発され，出張終了日の翌朝8時に，申請者に対して出張報告の提出依頼を通知する．出張報告の提出依頼は，出張報告の提出を部局事務担当者が確認するまで毎日通知される．

業務停滞通知機能はPower Automateで開発され，開始から7日間を超えて完了していない業務フェーズが存在する場合，業務の停滞を検知して部局事務担当者に通知する．

ダッシュボード機能はPower BIで開発され，当日の出張者，今後の出張予定，現在処理中の申請状況と，年度別，月別の出張件数，事前申請割合，事前決裁割合，出張終了後1カ月以内の精算完了割合，申請・決裁・報告・精算の業務フェーズ完了までの期間別出張件数，各業務フェーズの期間分布，Teamsの返信回数を表示する．

表1は，申請データを管理する出張申請DBのスキーマを示す．申請者からの申請は，「申請者」から「備考」までの各項目に記録される．「用務資料」，「領収書」，「出張報告書」には，SharePointに申請単位で作成されるフォルダのURLが記録される．「フェーズ」，「ステータス」には各業務フェーズの最新の状態が記録される．「メモ」は部局事務担当者が利用可能なメモ欄，「完了」は申請にかかわる処理がすべて完了したか，「完了日時」はすべての処理が完了した日時を記録する．

表2は，各業務フェーズで部局担当者が確認結果を通知した履歴を記録する業務記録DBのスキーマを示す．確認結果通知機能を用いて各業務フェーズの確認結果を送信すると，現在の業務フェーズの「ステータス」が「完了」に更新され，画面から指定された内容が「承認結果」，「承認時コメント」，「通知内容」にそれぞれ記録される．また，「終了日時」にはその操作をおこなった時点の日時が記録される．同時に，次業務フェーズに関する業務記録として，新たなレコードが作成され，「ステータス」は「実施中」に，「開始日時」および「終了日時」には操作時の日時が記録される．

図9はダッシュボード機能により提供される「当日の出張処理業務状況」を示す．「当日の出張処理業務状況」は，当日の出張者の用務先，今後の出張予定，現在処理中の案件を業務フェーズごとに表示する．図9は，2名の出張者が出張していること，今後の出張予定として3名の出張予定であること，2件が申請中であり，2件が決裁中であることを示す．当日の出張処理業務状況では，当日出張により不在となっている部局内の教職員を確認できるだけでなく，地図上に出張先を表示することで，地震などの災害発生時に被災地に出張者がいないかどうかも確認できる．

図10はダッシュボード機能により提供される「出張処理業務状況」を示す．出張処理業務状況は，年度別の出張件数，月別の出張件数の推移，申請・決裁・出張・報告・精算の業務フェーズごとのデータのばらつきを箱ひげ図（最小値，25%タイル値，中央値，75%タイル値，最大値の5つの値を使い，箱とそこから伸びる「ひげ」でデータの分布を示す）として表示する業務フェーズごとの期間分布，月別のTeams返信回数の箱ひげ図，年度別事前申請割合，年度別事前決裁割合，出張終了日翌月末の精算完了割合，決裁日から出張開始日までの日数，申請期間別の出張件数と累積割合，決裁期間別の出張件数と累積割合，報告期間別の出張件数と累積割合，精算期間別の出張件数と累積割合により，出張処理業務全体の状況を俯瞰し，業務全体の進捗に問題がないかを確認するために利用することができる．

5.　運用結果

本研究では，出張処理業務の正確性を「正しく業務がおこなわれること」，迅速性を「業務ができるだけ早くおこなわれること」，信頼性を「業務が遅滞なく完了すること」と定義した．評価にあたっては，正確性を「事前決裁の割合」および「決裁日から出張開始日までの日数（どれほど余裕をもって事前決裁がおこなわれたか）」，迅速性を「出張終了後出張報告書提出1週間以内割合」，信頼性を「出張終了日翌月末の精算完了割合」および「決裁日から出張開始日までの日数（事後決裁期間の短縮）」として評価した．なお，本研究では比較対象となる運用期間が短く対象件数も限定的であるため，統計的検定ではなく実データの傾向分析に基づく評価をおこなった．出張処理業務モニタリングシステムは，香川大学情報化推進統合拠点を対象に2025年4月から運用が開始され，2025年12月10日時点で88件の出張申請を受け付けた．図11は，2025年度の事前決裁割合を示す．正確性の指標と定義した事前決裁割合（事前決裁件数÷事前申請件数）は2024年度の66.0%（図2）に対して2025年度は84.9%（図11）へと向上した．図12は，2025年度の決裁日から出張開始日までの日数とその割合を示す．正確性の質的な改善（どれほど余裕をもって事前決裁がおこなわれたか）を示す，出張開始日の1週間前までに決裁された申請は，2024年度の20.1%（図3※1）に対して2025年度は34.9%（図12※1）へと，余裕をもって1週間前までに事前決裁が完了する割合が向上した．また，信頼性の指標である業務の遅滞なき完了（事後決裁期間の短縮）を示す，出張開始後の事後決裁完了については31日間（図3※2）かかっていたものが29日間（図12※2）で完了した．図13は，2025年度の出張報告提出日数を示す．迅速性の指標として定義した出張終了後出張報告書提出1週間以内割合については，2024年度に1週間以内に完了した割合が63.2%（図4※1）であったのに対し，2025年度は12月10日時点で62.5%（図13※1）であった．図14は，2025年度の出張終了日翌月末の精算完了割合を示す．信頼性の指標として定義した出張終了日翌月末の精算完了割合は，2024年度の96.6%（図5）に対して2025年度は12月10日時点では88.9%（図14）に低下した．

出張処理業務モニタリングシステムの運用開始後（2025年4月以降），部局事務担当者からの問い合わせは，2025年5月および6月に計3件，12月に1件確認された．本研究では，これらの問い合わせ内容をもとに，運用上の課題や設計上の改善点を整理し，必要な是正措置を迅速に実施した．具体的には，以下の対応をおこなった．

• 1) 部局事務担当者の変更に伴い，確認結果通知機能の利用権限付与およびTeams通知先設定を変更した（2025年5月）．
• 2) 出張期間開始前に報告フェーズへ移行できないよう，業務ルールを反映した制御機能を追加した（2025年5月）．
• 3) 帰着日翌日以降に報告フェーズへ移行可能とするため，上記2)で追加した制御機能を修正した（2025年6月）．
• 4) 二重クリックにより発生したデータの二重登録事象について，原因調査およびデータメンテナンスを実施した（2025年12月）．

6.　考察

6.1　出張処理業務課題への本システム機能の効果

正確性の向上の指標である事前決裁の割合が66.0%（図2）から84.9%（図11）へと向上した主な要因は，「確認結果通知機能」が出張日の近い申請案件を優先的に表示し，部局事務担当者が対応すべき業務の優先順位を明確化したこと（孫骨①への対応），および「ダッシュボード機能」によって処理中の案件が常に可視化され，対応漏れが減少したこと（孫骨④への対応）により，「出張申請は事前に提出されていたが，用務関連資料等の提出待ちの状態で放置される」という課題に効果があったと考えられる．

出張開始日の1週間前までに決裁された申請の割合の増加（20.1%（図3※1）から34.9%（図12※1））は，「確認結果通知機能」により出張日の近い申請案件を優先して処理できたこと（孫骨①への対応）により，余裕をもって事前決裁がおこなわれるという正確性の質的な向上に一定の効果があったと考えられる．

迅速性の向上の指標である，出張報告書提出が1週間以内に完了する割合は，2024年度の63.2%（図4※1）に対し，2025年12月10日時点では62.5%（図13※1）であった．2025年10・11月に報告完了に40日以上かかっていた出張が合計8件あり，詳細を確認したところ，これらの遅延は，教員が自家用車で学生とともに高速道路を利用した出張において発生していた．この場合，旅費精算の証憑としてETC利用明細の提出が必要となるが，ETCの明細は取得までに時間がかかることもあり，それが出張報告書の提出や精算処理が遅れる原因となっていることが分かった．

信頼性の指標として定義した出張終了日翌月末の精算完了割合は，2024年度の96.6%（図5）に対し2025年12月10日時点では88.9%（図14）に低下した．この原因も，2025年10・11月にあった8件の日帰り出張の出張報告の遅延であった．それ以外の出張については，すべて出張終了日翌月末までに精算を完了していた．「報告リマインド機能」が出張終了後，出張報告書が提出されるまで申請者に自動で出張報告書の提出を督促し続けること（孫骨②への対応）により，従来は担当者が手動で督促していた手間が省かれ，「業務停滞通知機能」が7日以上停滞している業務を検知し担当者に通知することで，業務の停滞（孫骨③への対応）を自動的に発見し，対応を促す効果があったと考えられる．信頼性の向上の指標である出張終了日翌月末の精算完了割合については，迅速性の向上の指標と同様に，事前決裁割合の向上（正確性）と出張報告書提出の早期化（迅速性）の双方が信頼性の向上に寄与した可能性がある．また，出張開始後の事後決裁完了期間については，31日間（図3※2）から29日間（図12※2）へと，わずかな短縮が確認された．この短縮は，「業務停滞通知機能」が7日間を超えて停滞している業務を検知し，部局事務担当者に対応を促したこと（孫骨③への対応）により，業務の遅滞なき完了という信頼性の質的な改善に一定の寄与があった可能性を示すものであるが，事後決裁完了までの期間全体に大きな変化が生じたとまでは言えない．

6.2　内製開発とローコード・ノーコードプラットフォーム選択の有効性

香川大学では出張申請・報告システムを内製開発した．1年間の出張申請・報告システムや財務情報システムの運用データ分析，申請者，部局事務担当者への調査から，業務全体の進捗可視化や停滞検知といった新たな課題が明らかになった．香川大学ではこれらの課題に対し，業務の進捗を可視化・支援するBAM機能を内製開発した．

本研究におけるローコード・ノーコードプラットフォームを活用した内製開発の有効性は，コスト，スピード，持続可能性の3点から評価できる．第一に，Microsoft社は教育機関向けにローコード・ノーコードプラットフォームであるPower Platformを無償提供している．Power Platformは一般的なプログラミング言語によるプロコードと比較して技術的なハードルが低く，ベンダー等への委託をせずに既存のDXラボの要員のみで，システムの開発が可能となった．第二に，Power Platformの活用により，約1カ月という短期間で現場の課題に対応したシステムを迅速に構築できた．第三に，香川大学の内製開発体制により，持続的な維持・改善が可能となった．

一方で，内製開発およびローコード・ノーコードプラットフォームの留意点としては，開発担当者に保守・運用が依存し，異動や退職によってシステムの維持が困難になる属人化のリスクがある．また，既成のパッケージやサービスと比較すると，ローコード・ノーコードプラットフォームで内製開発した機能は運用における課題解決に特化しており，広範な機能は有していない．これら留意点に対し，香川大学ではDXラボ内で複数人での開発，業務の引継ぎの徹底をおこなうこと，段階的な開発の中で要件を明確化し，既成のパッケージやサービスの組み合わせにより，より広範な機能の提供をすることを想定している．

6.3　本研究の意義

本研究は，既存の出張申請・報告システムや財務情報システムの運用データの分析から，事前決裁率や報告提出日数など業務が適切に実施できていない状況を明らかにした．また，特性要因分析では，出張日が近い申請から優先的に業務が実施できる仕組みや，出張終了後，出張報告の実施を促すことができる仕組み，出張報告完了後，精算について期限内の実施を促すことができる仕組み，出張処理業務全体をモニタリングし，実施ができていない担当者に対してそれを通知できる仕組みが必要であることも明らかにした．本研究では，業務プロセスを継続的に監視し，改善につなげるBAMの考え方を取り入れ，申請受付機能，確認結果通知機能，報告リマインド機能，停滞通知機能，ダッシュボード機能を有する「出張処理業務モニタリングシステム」を開発することで，それらの仕組みを実現した．

本研究の取り組みは，Business Activity Monitoring（BAM）に基づく可視化基盤の構築と，それに基づく改善活動を継続的に実施するための枠組みを提示した点に意義がある．モニタリングシステムが提供する各種の機能・仕組みにより，以下の点において出張処理業務の改善を支援することを狙いとした．

• 1) 優先順位の自動整理（正確性への寄与）：「確認結果通知機能」により，出張日の近い案件が優先的に表示され，部局事務担当者が対応すべき業務の優先順位を把握しやすくなった．
• 2) ヒューマンエラーの防止（迅速性・信頼性への寄与）：「報告リマインド機能」および「業務停滞通知機能」により，手動による督促の漏れや対応遅れを防止する仕組みが整備された．
• 3) 業務全体の進捗把握（信頼性への寄与）：「ダッシュボード機能」により，滞留日数や業務フェーズの状況が可視化され，出張処理業務全体の進捗を俯瞰的に把握できるようになった．

一方で，モニタリングシステムの導入とあわせて実施した運用上の取り組みや改善活動も，業務改善において重要な役割を果たした．具体的には，以下の点が挙げられる．

• 1) 組織的なリソース管理：「ダッシュボード機能」を事務組織内で共有することで，個人単位の対応から，組織全体で案件の滞留状況を把握しフォローする運用へと移行した．
• 2) 定量データに基づくボトルネック分析：運用データの分析により，「ETC利用明細の取得待ち」といった遅延要因が特定され，改善策の検討が可能となった．
• 3) リスク管理および安全確認の高度化：出張者の所在や不在状況を可視化することで，災害発生時の確認や組織内での情報共有といった付加的な運用に対応できるようになった．
• 4) 段階的な横展開と業務プロセスの是正：蓄積されたデータをもとに，他部局における運用ルールの整理や役割分担の見直しを検討するなど，組織全体への段階的な展開を進めるための基盤が形成された．

香川大学では，財務情報システム，人事給与システム，教務システムを基幹システムに位置づけ，安定性や専門性の観点からベンダー企業が開発したパッケージシステムに委ねる判断をしている．しかしながら，基幹システムだけでは組織固有の細やかなニーズや，システム間の隙間を完全に埋めることは困難である．そのため，香川大学では，開発の迅速性，現場部門の関与の容易さといった特性をもつローコード・ノーコードプラットフォームにより開発した内製システムを戦略的に組み合わせ，業務全体をカバーしていく方策を採用している．本研究の取り組みは，基幹システムと内製システムを組み合わせることで，組織全体の情報化やDXを推進する1つの方策を提案している．

実運用を担う部局事務担当者からは，「優先順位の可視化や自動督促は，少人数の担当者間で業務を確認し合う中で有効である」とのフィードバックを得た．このことは，前述した「優先順位の自動整理」や「ヒューマンエラーの防止」が，実務の中で機能していることを示している．また，システムを独立したレイヤーとして構築したことにより，運用中に実施した機能追加や不具合対応においても，他の機能への影響を抑えながら実施できる構成となっており，内製開発および疎結合設計の有効性を示唆している．

7.　むすび

本稿では，既存の出張申請・報告システムや財務情報システムの運用データから出張処理業務を分析した結果とともに，分析結果に基づいて内製開発された出張処理業務モニタリングシステムについて述べた．DX推進の文脈において，ローコード・ノーコードプラットフォームの活用が様々な組織で進められているが，多くの場合が業務効率化や生産性向上にとどまっている．本研究は，既存の出張申請・報告システムや財務情報システムを用いて実施される出張処理業務において，その運用データから出張処理業務を分析するとともに，分析結果から業務品質を向上させる方策を導出し，出張処理業務モニタリングシステムの内製開発を通じて，その有効性を考察した．

本システムの適用にあたっては，ローコード・ノーコードプラットフォーム（Power Platform）の利用基盤が整備されていることが前提となる．また，これらのプラットフォームを業務に適用する際には，システムの社会的影響度に応じたリスク管理と，安定した保守体制の確立が重要となる．香川大学では，内製業務システムの適用範囲をIPAの定義における「社会的に影響がほとんどないシステム」に限定し，高い信頼性が求められる基幹システムとの役割分担を明確にしている．さらに，属人化リスクを回避し，保守品質を確保するため，DXラボのような複数人による開発・保守体制と，稼働状況を客観的に監視し，改善サイクルを回す仕組みを並行して整備している[25]．

加えて，本システムを全学的に適用していくためには，組織内の出張申請情報管理プロセスを整備する必要がある．各部局で運用ルールが異なる状況では，一律の展開には調整コストを要するため，まず特定部局での成功事例を創出し，その有効性をエビデンスとして示しながら，段階的に横展開を図るアプローチが現実的かつ有効である．

一方で，本研究の評価結果には，対象組織である情報化推進統合拠点の特性に起因するバイアスが含まれている可能性がある．同拠点は，学内のDX推進を担う組織であり，構成員のITリテラシーが比較的高いことや，組織規模が小さいことが，新たなシステムの導入や可視化結果への迅速な対応を支えた側面は否定できない．そのため，本システムを全学的に展開する際には，各部局のIT習熟度の差を考慮したユーザ教育や，運用実態に応じた通知設計などへの配慮が，評価結果の再現性を確保するうえで重要となる．

利用状況の分析から業務品質をモニタリングすることで継続的な改善を促すという本研究で実施した一連の取り組み（モニタリングシステムの機能提供，およびそれに基づく運用改善活動）は，今回対象とした出張処理業務に限らず，大学内の他の業務や，同様の課題認識を持つ他の組織におけるDX推進においても応用可能な，汎用性の高い取り組みである．システムの機能による業務の自動制御と，可視化されたデータに基づく人間側のプロセス是正を組み合わせることで，レガシーシステムを活用しながら，持続的な業務品質の向上に資する可能性が示唆された．

今後の展望としては，本システムによって蓄積されたモニタリングデータを活用し，業務プロセスのボトルネックをより詳細に特定すること（特定の教員が報告日数が異常に遅いなど）ができるようになる．さらに特定された課題に対して，RPA（Robotic Process Automation）[26]による定型作業の自動化や，生成AIを活用した問合せ対応支援・申請内容の最適化提案を組み合わせることで，迅速性や正確性，利用者満足度といった，業務品質の向上も期待できる．

本研究で得られた知見を基盤とし，改善サイクルをさらに効果的に実践・発展させるための研究を進めていきたい．

謝辞　本研究は，香川大学DX推進研究センターにおける取り組みとして，DXラボのメンバーによるシステム運用と改善を通じて進められたものです．関係者の皆様に心から感謝いたします．