学校法人の財務・経理の仕事をしていると、
これは専門外だから、業者にお願いするしかない
と、最初から自分で線を引いてしまう領域があります。
経理の仕訳や決算、学費の管理なら自分の領分です。けれども、その裏側で動いている基幹業務システムの中身——データがどう保存され、どう連携し、どう取り出されているか——となると、とたんに「そこは専門家の世界」だと感じてしまう。私にとって、システムのデータ周りはまさにそういう領域でした。エラーが出れば業者に問い合わせ、新しいことをやりたければ見積もりを取る。それが当たり前だと思っていました。
この記事は、そのようにに線を引いていた私（大学職員）が、生成AIを「通訳」として使いながら外注任せだった領域に少しずつ踏み込み、最終的にはある新機能の要件定義から受入検証まで自分で握れるようになるまでの、等身大の記録です。といっても、AIで業者を置き換えた話ではありません。専門家に丸投げするのではなく、専門家と対等に話せるだけの理解を手に入れた、という話です。
先に断っておくと、これは武勇伝や自慢ではありません。「AIを使えば誰でも専門家になれる」という話でもありません。むしろ書きたいのは、AIに任せきらなかったこと、相手に突き付けなかったこと、うまくいかなかったことのほうです。同じように「自分には無理」と線を引いている誰かにとっては、きれいな成功談より、そうした生々しい部分のほうが役に立つように思います。
出発点は、学校法人の事務で「前任者の残したものを、意味も半分で実行するだけ」だった
もともと私がやっていたのは、前任者が残してくれた手順を、その通りに実行する程度のことでした。
システムのデータを直接参照して確認する作業自体はやっていましたが、中身はほとんどがデータを「見るだけ」のもので、データを書き換えたり消したりするような、影響の大きい操作は一度もやったことがありませんでした。そもそも、自分が実行しているものの意味を、正直なところ半分くらいしか理解できていなかったと思います。前任者がそう書いていたから、そう動かす。その程度でした。
その前任者が異動することになり、この仕事を私が引き継ぐことになりました。
幸いだったのは、異動までの1年ほど、一緒に仕事をする時間があったことです。おかげで、何のために何をやっているのか、その雰囲気は掴めていました。基礎をまとめた引き継ぎメモももらえました。それでも、引き継ぎが決まったときの正直な気持ちは、「これを、これから一人でやるのか」という不安のほうが大きかったです。
メモは確かにありがたいものです。けれども、メモに書いてあることと、実際に自分の手で操作してエラーと向き合うことの間には、いつも大きな溝があります。その溝の前で、私は最初、かなり心細い思いをしていました。
AIを「先生」ではなく「隣にいる、いつでも聞ける同僚」として使った
その溝を埋めてくれたのが、生成AIでした。
全く意味のわからない会話・単語聞くたびに、作業でつまずくたびに、私はAIに聞きました。たとえば、こんな初歩的な疑問です。
- このメッセージは何を意味しているのか。初心者向けに解説して。
- この操作をすると、データに何が起きるのか。わかりやすく教えて。
- なぜこういう書き方をする必要があるのか。〇〇ではだめなのか？
人に聞けば「こんなことも分からないのか」と思われそうな質問も、AIには何度でも、気兼ねなくぶつけられます。この「気兼ねなく何度でも聞ける」という点は、初心者にとって思っている以上に大きいものでした。
ただ、使ううちに自分なりのルールが固まっていきました。AIの答えを、そのまま実行に移さない、ということです。
システムに関連すること以外にもAIに聞いていたので、自分の専門とする学校会計のところではAIの回答が間違っていたり、微妙なことがあるのを知っていたためです。
データを書き換えるような影響の大きい操作は、一つ間違えれば実務に直接響きます。ですから「AIがこう言ったから」で手を動かすことは、絶対にしないと決めました。AIの説明を読んで、分からなければさらに「なぜ？」を重ねて聞いて、最終的に自分納得して初めて、実行する。AIは答えを教えてくれる存在であると同時に、私の理解が本物かどうかを試す壁打ち相手でもありました。
この使い方を続けるうちに、変化が起きました。最初は単発の操作の意味を聞いていただけだったのが、だんだんと、データがどういう構造で保存されているのか、システム同士がどうやってデータをやり取りしているのか、その全体像が見えるようになってきたのです。
気づけば、外部のサービスとデータを連携させるような、以前なら「完全に業者の領域」だと思い込んでいた仕事にも、自分で関われるようになっていました。理解が一段上がると、見える景色が変わります。線を引いていた場所が、少しずつ自分の側に動いていく感覚がありました。
新機能の要件定義で、AIの「出来の悪い叩き台」に助けられた
大きな転機は、ある新機能の開発に、主担当として関わることになったときでした。
この機能は、自部署の実務担当だけで完結するものではありませんでした。他部署の複数の担当者——それぞれ別の業務を持ち、別の都合と優先順位を抱えた人たち——にも関わります。まず必要だったのは、関係者を集めて話し合い、「結局、何を作るのか」を固める要件定義でした。
これが、ゴールとしてはみんなで合意できていたものの、意外と難しいものでした。
難しさは二つありました。
- 関係者の「こうあってほしい」が微妙に食い違う：ある担当者にとって便利な仕様が、別の担当者には手間を増やす、ということが普通に起きます。
- 機能として必要なこと、やりたいことはわかるがUI/UXが分かりづらい：何が欲しいのかは分かっているが、いざ形にしようとすると自分都合の設計になりやすく、ユーザーのUI/UXとして微妙になりがち。
そこで私は、頭の中の要望をもとに、画面の叩き台（モックアップ）をAIに試しに作らせてみました。
正直に書きます。出てきたものは、デザインもUI/UXも、決して良いものではありませんでした。そのまま使えるような完成度ではまったくないし、見た瞬間に「いや、これは違うな」と思いました。
ところが、それが役に立ちました。
白紙の状態から「理想の画面」を考えるのは、ものすごく難しいことです。けれども、目の前に「これは違う」と言える具体物が一つあるだけで、考えはぐっと進めやすくなります。叩き台が効いたのは、次の二つの場面でした。
- 自分の考えがまとまる：「ここはこうしたい」「この要素は要らない」「この順番は逆だ」と直していくうちに、本当に作りたかったものの輪郭がはっきりしていく。
- 関係者との議論が前に進む：叩き台を見せると、抽象的に話していたときよりずっと具体的で建設的な意見が出てくる。「こういうイメージですか？」という共通の土台ができるからです。
AIの出力は、完成品として受け取るのではなく、みんなで叩くための素材として使うと効きます。これは要件定義に限らず、企画でも文章でも、いろいろな場面で当てはまる感覚だと思います。批判や修正は、ゼロから創造するよりずっと易しい。だったら、AIにまず「叩かれ役」を作らせてしまえばよいのです。
こうして関係者と固めた要件をもとに、データの連携部分の設計にも主体的に関わりました。そして、出来上がった機能が要件通りに動くかを一つひとつ確認する受入検証も、主に自分が担当しました。想定通りの入力で正しく動くかだけでなく、おかしな操作をしたときに変な挙動をしないか、別の業務のデータに影響を与えていないか。気になるところは、納得いくまで確認しました。かつては「業者がテストしたなら大丈夫だろう」と任せていた工程を、自分の責任で見られるようになっていました。
業者の回答を「検証」はした。でも「突き付け」はしなかった
開発を業者と進める中では、相手の説明や回答に対して、「これは本当に正しいのだろうか？」と引っかかる場面も出てきました。以前の私なら、引っかかっても確かめる手段がなく、結局は飲み込むしかありませんでした。けれども今は、AIという壁打ち相手がいます。
そういうとき、私はAIに、その回答が妥当かどうかを検証させてみました。
ただ、ここで自分の中に、はっきり一線を引いていたことがあります。検証の結果を、業者を論破するために使うわけではない、ということです。
理由は二つあります。
- AIの検証も間違うことがある：それを鵜呑みにして相手に突き付け、もしAIのほうが間違っていたら、相手に不必要な負担をかけ、これまで築いた信頼関係を損なってしまいます。また業者のほうが当該システムについては詳しく、AIが理解している文脈（私がAIに伝えている文脈）が足りない場合があると思っていました。
- そもそも目的は、相手を打ち負かすことではない：良い機能を、業者と一緒に作りたい。それがゴールであって、議論で勝つことはゴールではありません。
そのため検証は、突き付けるためではなく、自分が相手の話の中身をきちんと理解し、的確な質問を準備するための「予習」として使いました。「ここはこういう理解で合っていますか」「この場合はどうなりますか」と、対等に、建設的に話すための土台づくりです。AIは、相手と同じ目線で会話するために自分を底上げしてくれる道具であって、人間関係に持ち込んで振り回す武器ではありません。
この使い分けは、これから仕事にAIを取り入れる人ほど、意識しておいて損はないと思います。AIは人を賢く見せてくれますが、それを相手を黙らせるために使い始めると、建設的な関係はかえって遠のいてしまう——そう感じています。
振り返ると、「業者に丸投げしない」ことと「AIに丸投げしない」ことは、私のなかでは同じ一つの姿勢でした。どちらも、誰かに預けて終わりにせず、最後は自分で理解して判断する、ということです。専門外の領域に踏み込めたのは、この姿勢をどちらに対しても崩さなかったからだと思います。
結果として、何が変わったか
この新機能は、導入して最初の時期だけで、従来の運用の数倍の人数に使われました。もっとも、これはシステムが優れていたからというより、締切を守ってもらうための案内を強化した影響も大きいです。ですから「AIで作った機能がすごかった」と胸を張るつもりはありません。ただ、従来は到底捌けなかったであろう規模を、大きな混乱なく処理しきれたのは事実です。
けれど、本当に変わったのは数字ではなく、私自身でした。
「これは業者に任せるしかない」と引いていた線が、確かに一本、自分の側に動きました。以前なら業者に「確認してください」と投げて終わりにしていた場面でも、今は前提条件を自分で整理し、論点を絞ってから相談できるようになりました。専門家に丸投げするのではなく、専門家と対等に話せるだけの理解を、自分の中に持てるようになったのです。分からないことを分からないまま飲み込むのではなく、「分かろうとすれば、分かる」と思えるようになった。これは、一つの業務をこなせるようになったこと以上に、大きな変化だった気がします。
同じように「自分には無理」と線を引いている人へ
生成AIは、こうした理解にたどり着くまでの距離を縮めてくれたと思います。専門外の壁は、以前よりずっと低くなりました。
ただし、それは「AIに任せれば何とかなる」という意味ではありません。実際はむしろ逆でした。私がAIから恩恵を受けられたのは、AIに任せきらず、自分の理解と判断の補助線として使った範囲だけです。振り返ると、AIとの付き合い方はこう整理できます。
- AIに任せたこと：分からない用語や挙動の説明、要件を詰めるための叩き台づくり、業者の回答が妥当かの下調べ
- AIに任せなかったこと：実行するかどうかの最終判断、関係者との合意形成、そして結果に対する責任
叩き台は人間が直してこそ意味があり、検証は人間が責任を持って使ってこそ意味があります。AIが出した答えの最終的な責任は、いつも自分が持つ。その距離感を守れたときに、AIははじめて自分の力になりました。
もしあなたが今、「これは専門外だから」と、どこかに線を引いているなら。その線は、思っているより動かせるかもしれません。AIを、答えをくれる魔法ではなく、隣で根気よく付き合ってくれる同僚だと思って、一度その線の少し向こうに足を踏み入れてみてほしいと思います。私がそうだったように、見える景色が変わるかもしれません。
そもそも私が「専門外」に踏み込めるようになった背景には、数年前に挫折した仮想通貨botづくりや、そこで触ったプログラミングの経験がありました。その回り道がどう生きたのかを、noteに書いています：学校法人の経理担当が、AIと一緒に15法人の決算書を読むようになった話。
生成AI（Claude Code）の具体的な使い方は、別記事でも扱っています。
実際に公開情報の決算分析をやってみた例：
業務で使うときの情報管理リスクの整理：
