1.　はじめに

香川大学は，2021年5月にDXラボを組織した[1]．DXラボは，システム設計・開発を専門とする教員や情報部の職員，企業から招聘した教員や研究員，情報技術を学ぶ香川大学の学部学生と大学院生から構成され，学内の業務課題をデザイン思考[2]を用いて分析し，DXの推進に資する業務システムの内製開発をおこなっている．DXラボの業務システムの内製開発[3]は，現場部門の担当者をプロダクトオーナーに位置づけ，DXラボのメンバーがスクラムマスター，開発者を担い，アジャイル開発手法のスクラム開発で業務システムを開発する．DXラボの業務システムの内製開発では，ローコード・ノーコードプラットフォームのMicrosoft Power Platform（以下，Power Platform）[4]を用い，2024年9月現在で100を超えるシステムが開発され，実際に運用されている．

情報処理推進機構（以下，IPA）の「DX白書2021」[5]は，DXに必要な開発手法としてデザイン思考，アジャイル開発，DevOps [6]を示すとともに，システム開発の生産性を向上すべくローコード・ノーコードプラットフォームを活用した開発手法についても示した．同白書では，ローコード・ノーコードプラットフォームを用いた開発は，開発技術者の不足を補いシステム開発の生産性を向上させるメリットがある一方で，保守や管理がきちんとされず，セキュリティホールが生まれる可能性，すなわち保守品質の確保に課題があるデメリットを指摘した．飯泉ら[7]は，ローコード・ノーコードプラットフォームを含むクラウドサービスの品質について，「クラウドサービスの機能追加や改修などによりクラウドサービスの動作が変化することがあること」，「クラウドサービスを利用するときのネットワークやリソースは，他の利用者と共用される部分があるため，性能が安定しないことがあること」，「クラウドサービスプロバイダーの都合により，クラウドサービスの一部またはすべてが停止，終了することがあることに留意する必要があること」を指摘した．そして，検討すべき対策として，「稼働状況の監視と再実行，自動テストなどでの定期的な確認により，自組織での利用に問題があれば早期に知る対策が必要であること」などを示した．

DXラボで内製開発に用いられるローコード・ノーコードツールのMicrosoft Power Automate（以下，Power Automate）[8]は，サービス側のネットワークやインフラの一時的な問題，サービスの仕様変更，一時的な障害など，ローコード・ノーコードプラットフォームで開発したシステムの保守品質の課題により，様々なエラーが発生する．Power Automateでは，開発したシステムになんらかの障害が発生しても，週1回の通知メール，もしくはシステム管理画面の「28日間の実行履歴」にアクセスしなければそれを確認することができず，香川大学では，内製開発された業務システムに障害が発生しても，ユーザからの報告ではじめて気づくケースが多数報告されていた．

SLO（サービスレベル目標）は，サービス提供者が定めるサービス品質の目標値を指す．IPAの「非機能要求グレード2018」[9]は，社会的影響度からシステムを「社会的影響がほとんどないシステム」，「社会的影響が限定されるシステム」，「社会的影響が極めて大きいシステム」に分類し，それぞれに対して必要なSLOを示した．香川大学では，内製業務システムのSLOを「社会的に影響がほとんどないシステム」と定め，実行履歴からシステムを監視し，内製業務システムの保守品質が確保されているかどうかを確認できる運用監視ツール「カダモニタ/KadaMonitor（以下，カダモニタ）」を開発した[10]．香川大学では，内製業務システムやその機能が99%以上の成功率（総実行回数における成功回数の割合）を確保できている状態を，システムおよびソフトウェア製品の品質要求と評価に関する国際規格SQuaRE [11]が規定する「成熟性」と「可用性」が確保されている状態（保守品質が確保されている状態）と定義した．カダモニタは，内製開発した業務システムやその機能が99%以上の成功率を確保していることを確認すべく開発された．

カダモニタを用いた内製業務システムの運用監視の取り組みでは，システム改修などを通じて運用開始数か月目にはすべてのシステムやその機能が99%以上の成功率を確保していることが明らかになった．本稿では，カダモニタについて述べるとともに，カダモニタを用いた内製業務システムの運用監視の取り組みから，その効果について考察する．2では，内製業務システムを対象とした運用監視ツール「カダモニタ」について述べる．3では，カダモニタを用いた内製業務システムの運用監視の取り組みについて述べる．4では，考察を述べる．5では，むすびを述べる．

2.　運用監視ツール「カダモニタ」

本章では内製業務システムを対象とした運用監視ツールカダモニタについて述べる．

2.1　カダモニタの機能要件

カダモニタは，内製開発した業務システムやその機能が99%以上の成功率を確保していることを確認すべく，以下の要件を満たすよう開発されている．

要件1　システムの実行履歴を定期的に取得し，エラー発生時にそれを通知することができる（2.3実行履歴取得・エラー通知機能）．

要件2　24時間以上実行されていないシステムをテスト実行することで，障害を事前に確認することができる（2.4テスト実行機能）．

要件3　週次・月次での各システムの実行回数，成功・失敗回数，処理時間を表示・可視化できる（2.5ダッシュボード機能）．

要件1は，実行履歴取得・エラー通知機能によって実現する．実行履歴取得・エラー通知機能の詳細については2.3で述べる．実行履歴取得・エラー通知機能は，実行履歴を取得し，エラー発生時にそれを通知する．開発者（監視者）は，エラー原因を特定するとともに，運用への影響を分析しながら，システム改修の可否を判断したうえで必要があればシステムを改修する．香川大学では，内製業務システムやその機能が99%以上の成功率（総実行回数における成功回数の割合）を確保することを目指している．実行履歴取得・エラー通知機能は，システム改修にむけた気づきを促している点で，「成熟性（長期間にわたって安定して動作する能力）」の確保に寄与している．

要件2は，テスト実行機能によって実現する．テスト実行機能の詳細については2.4で述べる．テスト実行機能は24時間以上実行されていないシステムをテスト実行することで，障害を事前に確認する．Power Automateは，システムを実行しなければシステムに障害が発生してもそれを確認することができない仕様である．香川大学では，24時間以内にシステムが正しく実行されていれば，当該システムに障害が発生していないと定義した．テスト実行機能は，24時間以上実行されていないシステムをテスト実行することで，障害を事前に確認している点で，「可用性（要求されたときにシステムが動作する能力）」の確保に寄与している．

要件3は，ダッシュボード機能によって実現する．ダッシュボード機能の詳細については2.5で述べる．ダッシュボード機能は，週次・月次での各システムの実行回数，成功・失敗回数，処理時間を表示・可視化する．ダッシュボード機能は，取得した実行履歴から，内製開発した業務システムやその機能が99%以上の成功率を確保できているかどうかを確認している点で，「成熟性（長期間にわたって安定して動作する能力）」と，「可用性（要求されたときにシステムが動作する能力）」の確保に寄与している．

2.2　カダモニタの概要

図1は，カダモニタのコンポーネント図を示す．カダモニタは，運用監視の対象となる内製業務システムの実行履歴を取得し，エラーがあれば開発者（監視者），管理者に通知する「実行履歴取得・エラー通知機能」，運用監視対象システムが24時間以上実行されていない場合に，システムをテスト実行させる「テスト実行機能」，取得した実行履歴から内製業務システムの運用データを表示・可視化する「ダッシュボード機能」の4つの機能と，「運用監視対象システムDB」，運用監視の対象となる内製業務システムの実行履歴を格納する「実行履歴DB」，テスト実行機能の実行履歴を格納する「テスト実行履歴DB」，カダモニタ自身のエラーログを格納する「エラーDB」の4つの運用データベースから構成される．カダモニタは，Power Automateのほか，Microsoft Power BI（以下，Power BI）[12]，データベースのMicrosoft Dataverse（以下，Dataverse）[13]，Microsoft Teams（以下，Teams）[14]を用いて開発した．

表1は，運用監視対象システムを一元管理する「運用監視対象システムDB」のスキーマを示す．「環境ID」，「システムID」，「前回監視実行時間」は，実行履歴取得・エラー通知機能起動時のパラメータとして使用する．実行履歴の取得が完了すると，「最終実行日時」，「最終実行時ステータス」，「最終実行時メッセージ」を記録する．「監視開始日」は，当該システムの監視を開始した日付を指定する．「テスト実行用実行履歴ID」，「前回実行時テスト実行用実行履歴ID」，「前回テスト実行時ステータス」，「前回テスト実行日時」はテスト実行機能で利用する．表2は，システムの実行履歴を記録する「実行履歴DB」，テスト実行の実行履歴を記録する「テスト実行履歴DB」のスキーマを示す．実行履歴確認用URLはPower Automateの実行履歴詳細画面のURLを示し，URLに遷移することでPower Automateの提供する実行履歴詳細画面でエラー発生時の詳細状況を確認することができる．表3は，実行履歴取得・エラー通知機能の障害発生時にそのエラーを記録する「エラーDB」のスキーマを示す．実行履歴取得・エラー通知機能の障害が発生すると，実行履歴を取得していた運用監視対象システムの「システムID」，「システム名」，障害発生時の「実行開始日時」，「実行終了日時」，「ステータス」，「メッセージ」と実行履歴取得・エラー通知機能の実行履歴確認用URLを「URL」に記録する．

2.3　実行履歴取得・エラー通知機能

「実行履歴取得・エラー通知機能」は，運用監視の対象となる内製業務システムの実行履歴を取得し，エラーがあれば開発者（監視者），管理者にそれを通知する機能である．図2は，「実行履歴取得・エラー通知機能」のシーケンス図を示す．実行履歴取得・エラー通知機能は平日8時～19時まで1時間ごとに実行し，運用監視対象システムの最新の実行結果を実行履歴DBに記録する．実行結果にエラーが含まれている場合，DXラボの開発者（監視者）と管理者にそれを通知する．

実行履歴取得・エラー通知機能は，カスタムコネクタ[15]を用いて開発した．Power Platformにあらかじめ構築されているコネクタが利用できないサービスとの接続についても，独自のカスタムコネクタを作成することができる．本研究では，「Get Flow Runs」「Get Run Detail」の2つのカスタムコネクタを作成した．

「Get Flow Runs」はシステムが作成された環境（Environment ID），履歴を取得するシステムID（Flow ID），実行開始日時（Start Time）の範囲を指定してシステムの実行履歴を取得する．表4は，「Get Flow Runs」のリクエスト時に指定可能なパラメータを示す．また，図3は，「Get Flow Runs」がAPIから取得した実行履歴の例として，処理が失敗した際の履歴の一部を示す．「name」は実行履歴ID，「startTime」はシステムの実行が開始した日時，「endTime」はシステムの実行が終了した日時，「status」はシステムの実行結果のステータスを示す．「status」は「Succeeded」，「Failed」，「Running」の3段階から構成され，「Cancelled」のステータスを持つ．「Succeeded」は，最後までシステムが実行されたことを示す．「Running」は，システムの実行が中断され，待機中の状態であることを示す．「Failed」は，システムの実行が失敗したことを示す．「Cancelled」は，システムの実行が強制的に中断されたことを示す．「message」はエラー発生時のメッセージを示す．

「Get Run Detail」は，システムが実行される際に発行される実行履歴IDを指定して実行履歴の詳細を取得する．表5は，「Get Run Detail」のリクエスト時に指定可能なパラメータを示す．図4は，「Get Run Detail」がAPIから取得した実行履歴の例として，処理が成功した際の履歴を示しており，2024年10月29日10時8分（日本時間では19時8分）に実行を開始した「name」で示される実行履歴IDの処理が，13時間後の2024年10月29日23時29分（日本時間では10月30日9時29分）に正常終了したことを意味している．このとき，「Get Flow Runs」は，日本時間2024年10月29日8時の処理で，ステータス「Running」を実行履歴DBに記録する．「Get Run Detail」は，日本時間2024年10月29日10時の処理で，ステータス「Succeeded」を実行履歴DBに記録する．

2.4　テスト実行機能

「テスト実行機能」は，運用監視対象システムが24時間以上実行されていない場合に，システムをテスト実行させる機能である．香川大学の内製開発で使用しているPower Automateは，サービス側のネットワークやインフラの一時的な問題，サービスの仕様変更，一時的な障害など，ローコード・ノーコードプラットフォームで開発したシステムの保守品質の課題により，様々なエラーが発生する．香川大学では，24時間以内にシステムが正しく実行されていれば，当該システムに障害が発生していないと定義し，テスト実行機能を開発した．テスト実行機能は，24時間以上実行されていないシステムをテスト実行することで，障害を事前に確認することを意図して開発された．

図5は，「テスト実行機能」のシーケンス図を示す．「テスト実行機能」は前回実行日時が24時間以上以前のシステムを運用監視対象システムDBから抽出し，システムをテスト実行する．Power Automateは，実行ごとに実行履歴IDが付与されるだけでなく，実行履歴IDを指定して処理を再実行させることができる．テスト実行用に運用に影響のないテスト実行を本番環境で実施しておき，その実行履歴IDを指定することでシステムをテスト実行させる．テスト実行機能では，表1で示す運用監視対象システムDBの「最終実行日時」が24時間以上前の監視対象システムを抽出し，「テスト実行用実行履歴ID」を指定してテスト実行し，「前回テスト実行時ステータス」にテスト実行の結果を，「前回テスト実行日時」にテスト実行日時を記録する．

2.5　ダッシュボード機能

「ダッシュボード機能」は，取得した実行履歴から内製業務システムの運用データを表示・可視化する機能であり，内製開発した業務システムやその機能が99%以上の成功率（総実行回数における成功回数の割合）を確保できているかどうかを確認する．表6は，ダッシュボード機能で表示・可視化する運用データを示している．「ダッシュボード機能」は，運用監視対象システムすべての直近1週間の運用データを表示・可視化した「運用監視ダッシュボード（週間）」，月ごとの運用データを表示・可視化した「運用監視ダッシュボード（月間）」の2種類のダッシュボードを有している．それぞれのダッシュボードは，システムを選択することで，個別のシステムの運用データを確認することもできる．

図6は，運用監視ダッシュボード（週間）を示す．上部に運用監視対象システムの一覧が表示され，システムを選択することで，選択された個別のシステムの過去1週間の運用データ（「過去1週間の日別ステータス別実行件数」，「過去1週間のステータス割合」，「過去1週間の日別ステータス割合」，「過去1週間の日別の平均・最大処理時間」）を確認することができる．

図7は，運用監視ダッシュボード（月間）を示す．左側の条件指定部分で運用監視対象システム，ステータス，処理開始日の条件を指定し，「月別実行件数」，「月別ステータス割合」，「期間中のステータス分布」，「監視開始経過月数別実行件数」，「監視開始経過月数別ステータス割合」，「月別平均・最大処理時間（時間）」を確認することができる．

3.　カダモニタを用いた運用監視の取り組み

本章ではDXラボによるカダモニタを用いた内製業務システムの運用監視の取り組みについて述べる．カダモニタは，2023年11月から農学部教員向け休暇申請システムや，KadaMikke（落とし物管理システム）など4システム（6機能）を対象に運用が開始され，12月に4システム（5機能），2024年1月に2システム（3機能），3月に1システム（1機能），4月に1システム（1機能），7月に3システム（3機能），8月に1システム（1機能）と段階的に監視対象を追加し，2024年8月30日時点で，15システム（20機能）を運用監視している．

表7は，2023年11月から2024年8月までの運用監視対象システム・機能別の，月別の実行回数と成功回数を示す．対象期間中の全システムの総実行回数28476回，成功回数28158回，成功率は98.9%であった．

最も実行回数が多いのは勤務時間記録システム「カダキンタイ/KadaKintai」（以下，カダキンタイと呼ぶ）の「残業申請機能」である．図8は，「残業申請機能」の運用監視状況を示す．「残業申請機能」は，2024年1月15日から1月24日の運用において963件の処理が実行され，49件のエラーが発生した．原因解析の結果，残業申請の削除を実施した際にエラーが発生することが分かった．しかしながら削除申請処理は成功しており，業務に支障がないことが確認できたため，エラー発生ごとに同様のエラーであることを確認しつつ，「残業申請機能」は継続運用された．当該エラーについては2024年3月15日に改修を完了した．

2024年12月に，「オンライン選考用個室BOX予約システム」で，2件のエラーが発生した．エラー原因を解析した結果，Formsに入力された学籍番号の最後に空白（スペース）が入っているとエラーが発生することが分かった．DXラボでは「エラー発生頻度が低い」こと，「同様のエラーは他システムでも発生する可能性がある」ことから，エラー発生の都度暫定対応（空白スペースを取り除き再実行）しつつ，空白の除去と学籍番号の存在をチェックする入力チェック機能を開発するとともに，同様の仕組みが実装されているオンライン選考用個別BOX予約システム以外のシステムも改修する方針とした．「オンライン選考用個別BOX予約システム」の入力チェック機能については開発が完了している．また同様の仕組みが実装されているシステムについても，2025年6月には改修が完了する予定である．

図9は，カダキンタイの「休暇申請機能」の2024年8月19～30日の運用監視状況を示す．それぞれの日に存在する「実行中」の履歴は，承認が未実行の申請があることを示す．カダモニタは承認業務などにおいて，人間による未実行の処理についても可視化される．DXラボでは，未実行の処理については，当該のユーザに処理の実行を促す連絡を実施している．ダッシュボードの平均・最大処理時間は，運用監視対象システム別に確認することで，当該システムの実運用における起動から終了までの処理時間の変化を可視化することができる．

表8は，監視開始からの経過月数別の全運用監視対象システムの成功率（総実行回数における成功回数の割合）を示す．経過月数1カ月目では成功率は96.1%，2カ月目に96.8%，3カ月目に97.3%，4カ月目に98.7%，5カ月目に99.9%まで上昇し，その後も成功率は99%以上で推移していることが分かる．

テスト実行機能は，2024年8月31日より対象機能1機能（KadaMikke通知メールの登録機能）でのテスト運用を開始した．テスト運用の開始以降，テスト実行機能は2025年2月14日現在で65回実行され，2024年9月23日に1件のエラーを検知した．エラー原因を解析した結果，「KadaMikke通知メールの登録機能」の呼び出し元であるFormsのフォームを，個人のフォームからグループで共有するフォームに変更したことにより発生したエラーであった．当該エラーについては，即日システムの改修が実施され，改修後は当該エラーは発生していない．

4.　考察

DXラボよるカダモニタを用いた内製業務システムの運用監視の取り組みからその効果について考察する．香川大学で開発された内製業務システムは，リーン・スタートアップ[16]で提唱されている実用最小限の製品であるMVP（Minimum Viable Product）[17]を特定して開発を進めることから，少ない機能で構成されたシステムが多く，KadaMikke（落とし物管理システム）やKadaKintai（勤務管理システム）など複数機能があるシステムでも，多くても4～5つの機能で構成されている．システム監視の粒度については，機能単位で監視をおこなっており，1システム1機能の場合のみシステム単位で監視している．

カダモニタは2023年11月から運用を開始し，2024年8月30日の時点で，15システム（20機能）の運用を監視している．監視対象となるシステムやその機能の実行回数は28476回であり，その内訳は，成功25652回，実行中2493回，失敗318回，キャンセル13回であった．「カダモニタ」運用開始後，全システムの成功率は96.1%であったものが，運用2カ月目に96.8%，運用3カ月目に97.3%，運用4カ月目に98.7%，運用5カ月目に99.9%まで上昇し，その後も成功率は99%以上で推移している．カダモニタは，開発担当と運用担当が連携しながら保守品質の向上に貢献している点で，DevOpsの実践事例に該当する．

テスト実行機能は，2024年8月31日より対象機能1機能でのテスト運用を開始し，2025年2月14日までに65回実行され，1件のエラーを検知した．エラー原因を解析した結果，呼び出し元システムの変更に伴う影響で発生したもので，即日，システムの改修が実施された．これらの結果から，カダモニタは開発時の要件を満たし，「成熟性（長期間にわたって安定して動作する能力）」と，「可用性（要求されたときにシステムが動作する能力）」の確保に寄与している．

Power Automateの運用監視システムとしては，スイスに拠点を置くIOZ社が2021年より提供する「Power Automate Monitor」[18]，2024年6月にMicrosoftがプレビューとして提供を開始した「オートメーションセンター」[19]がある．双方のシステムともにダッシュボードを持ち，環境内のシステム全体を運用監視する．カダモニタはこれらの機能に加え，運用監視開始からの経過月数ごとのシステムの成功率により，運用監視対象システムの保守品質が確保されているかどうかを確認することができる．

ゲーミフィケーション[20]とは，ゲームデザインやゲームの原則をゲーム以外に応用する活動を全般をを指す．カダモニタは，システムやその機能の成功率が99%以上の状態を保守品質が確保されている状態と定義し（目標要素を提示），システムやその機能の実行回数や成功回数から成功率を提示（進行状況の可視化）することで，システムやその機能の改修を促している点でゲーミフィケーションを応用したシステムにも該当する．

5.　むすび

本稿では，カダモニタについて述べるとともに，カダモニタを用いた内製業務システムの運用監視の取り組みからその効果について考察した．カダモニタを用いた内製業務システムの運用監視の取り組みでは，システム改修などを通じて運用開始数か月目にはすべてのシステムやその機能が99%以上の成功率を確保していることが明らかになった．

2024年5月12日に，カダモニタの「実行履歴取得・エラー通知機能」に障害が発生した．カスタムコネクタが呼び出すAPIのクライアントシークレットの有効期限切れに起因して発生した障害であったが，DXラボではその有効期限を定期的に確認する運用がなされていなかった．「実行履歴取得・エラー通知機能」の障害は，2024年5月17日に復旧した．DXラボでは，カダモニタについても他の内製業務システムと同じくSLOを「社会的影響がほとんどないシステム」と定めていたが，障害発生以降はカダモニタのSLOを「社会的影響が限定されるシステム」に分類を変更し，「アプリケーションの各業務機能が正常に稼働しているかどうか監視をおこなうこと」，「クライアントシークレットや証明書などの有効期限管理と定期的な確認をおこなうこと」を新たに定めた．

カダモニタはPower PlatformとMicrosoft社のクラウドサービスであるMicrosoft Azure [21]の機能を組み合わせて開発されており，Power Automateを利用した内製業務システム開発をおこなっている組織であれば，一部追加ライセンスが必要となるが汎用性が高い構成としている．香川大学ではこれまで内製開発した業務システムをダウンロードできるカタログサイトとして，Kadai DXソリューションカタログサイト[22]を運営している．カダモニタについても他組織向けに提供することで，予算が潤沢ではない大学や組織でも運用可能な仕組みとして活用が可能となる．今回の知見をさらに発展させ，ローコード・ノーコードプラットフォームを用いたシステム開発の生産性や運用保守性向上にむけた研究開発に取り組んで参りたい．

謝辞　本研究にあたり，丁寧かつ熱心なご指導を賜りました八重樫理人教授に深謝の意を表します．また，様々なご意見，アドバイスをいただきました米谷雄介教授，山田哲教授，浅木森浩樹特任教授，油谷知岐助教，末廣紀史課長に感謝いたします．そして，カダモニタの改善にあたり支援をいただいた米村拓海氏に感謝いたします．本研究は，研究室の先輩である竹内悠翔氏が開発したシステムを，DXラボのメンバーが日々運用することで成立したものです．DXラボの関係者の皆様に心から感謝いたします．