大学の事務内製化が、数年後に止まる理由

大学の事務を、外注に頼らず自分たちで自動化する。この動き自体は正しいと思っています。

システムを1つ入れるたびに見積もりを取り、仕様を伝え、納品を待つ。その間に制度が変わる。予算も毎年は取れない。外注し続けると、コストも速度も持ちません。 Googleフォームとスプレッドシートを組み合わせるだけで回る業務は、実際にかなりあります。

ただ、内製化した業務が数年後に止まる例を、私はいくつも見ています。

止まり方には、はっきりした共通点があります。

作った人が辞めた日に止まる

ある国立大学で、こういう状態を見ました。

各部局へ配る予算執行の通知業務が、Excelマクロで動いていました。毎年きちんと配布できていたので、業務としては成立していました。

そのマクロを作った職員が、退職していました。

残されたのはコードだけで、何をしている処理なのかを説明できる人が学内にいません。制度が変わっても、部局が増えても、直せない。仕様がブラックボックスになったまま、担当者が手作業で埋めていました。

これは内製化に失敗した例ではありません。内製化に成功して、そのあと止まった例です。

内製と外注の話ではない

こう書くと「だから外注すべきだ」と読まれそうですが、そうは思っていません。外注しても、業者が変われば同じことが起きます。仕様書が残っていても、読める人がいなければブラックボックスです。

分かれ目は内製か外注かではなく、変更するときに何を触るかです。

止まる形    制度が変わったら、プログラムを書き換える
止まらない形  制度が変わったら、表の設定を書き換える

前者は、プログラムを読める人が必要です。その人が辞めた時点で止まります。後者は、担当者が自分で変えられます。

最近は、「AIに頼めば、誰でもマクロを更新できるのではないか」という期待もよく聞きます。実際に試してみて、意外とできなかった、という声も聞きます。AIはコードを書き直してくれますが、その修正が業務として正しいかを確かめるのは、業務を知っている人です。何をしている処理か分からないままでは、AIに何を頼めばいいかも、出てきた結果が合っているかも判断できません。AIで速くなるのは書くところで、読めて、確かめられる人が要るという構造は変わりません。

先ほどの国立大学では、部局・財源・予算項目・加算の条件を、すべて表の側で定義し直しました。いまはプログラムに触らずに更新できます。部局が増えても、制度が変わっても、書き換えるのは表です。詳しくは大学のExcelマクロ依存からの脱却→にまとめています。

内製化した業務は、なぜ属人化しやすいのか

内製化は、たいていその業務をよく知っている大学職員が始めます。困っているのが本人なので、当然そうなります。

そして詳しい人ほど、自分が分かっている前提で作れてしまいます。 変更が入ったらコードを直せばいい。自分は直せるので、それで困りません。

困るのはその人が異動・退職したあとです。作った時点では誰も気づきません。動いているからです。

内製化の落とし穴は、技術の話ではなく「作れる人が作ると、その人にしか直せない形になりやすい」という構造の話です。

一般に属人化は「特定の人しかできない状態」を指しますが、内製化で起きる属人化は少し性質が違います。誰かが抱え込んだのではなく、うまくやった結果として起きます。 だから問題として認識されにくく、その人がいなくなって初めて表に出ます。

作る前に見るところ

新しく内製化するとき、私は次の3つを見ています。手順ではなく、判断の話です。

毎年変わるものは何か。 部局、予算科目、様式、担当者。毎年変わるものは、必ず表の側に出す。 ここをコードに埋めると、毎年プログラムを触ることになります。

担当者が自分で変えられるか。 完成した後に、作った人以外の職員が変更を1回やってみる。できなければ、その時点で属人化しています。動くことと、引き継げることは別です。

説明できる人がいるうちに作るか。 すでにブラックボックスになっているものは、解析から始まります。作った人がまだ在籍しているうちに手を入れるほうが、圧倒的に速い。退職を待つと、コストが跳ね上がります。

一度に全部やらない

もう一つ。最初から全部を対象にしないことです。

同じ国立大学では、まず一部局で動かして、そこで確かめてから全部局へ広げました。別の学校法人では、申請・承認業務をNotionでデジタル化→しましたが、そこも業務の棚卸しと優先順位づけから始めています。

先に全体設計をしてから作ると、使われないものができます。 一つ動かして、担当者が自分で変更できることを確かめてから広げる。この順番のほうが、結果的に速いです。

まとめると

内製化はやったほうがいいと思っています。ただし、

• 止まる原因は、内製か外注かではなく「変更するときに何を触るか」
• 毎年変わるものは、コードではなく表の側に出す
• 作った人以外が変更できるかを、完成時に必ず確かめる（ここで属人化しているかが分かる）
• 説明できる人が在籍しているうちに着手する

この4つを外さなければ、数年後に止まる形にはなりにくいはずです。

ここでは大学の話として書きましたが、作った人しか直せない形になりやすいという構造は、学校事務でも、学校法人の本部でも変わりません。

コントランでは、大学の生成AI研修・業務改善・産学連携の支援→を行っています。すでにブラックボックスになっている業務の解析からでも構いません。

なお、業務改善は収益の多角化とも地続きです。そちらは大学の収益多角化が進まない理由→に書きました。