「業者に任せるしかない」領域に、AIで踏み込んだ話
学校法人の財務・経理の仕事をしていると、「これは専門外だから、業者にお願いするしかない」と思う領域があります。
経理の仕訳や決算、学費の管理なら自分の領分です。けれども、その裏側で動く業務システムの中身、データがどう保存され、どう連携し、どう取り出されているかとなると、そこは専門家の世界だと感じていました。私にとって、システムのデータ周りはまさにそういう領域でした。
だからといって、業者に業務上の要望をうまく伝えられなかったわけではありません。業務の流れは分かっていましたし、画面の正式な機能名を使って話せば、業者にも理解してもらえていました。それでも、画面の裏側で何が起きているかは、自分では分からないことが多かったのです。
これは、私が生成AIに何度も質問しながら少しずつシステムへの理解を深め、ある新機能の要件定義から受入検証まで関われるようになった話です。業者をAIに置き換えた話ではありません。自分で考え、確認できる範囲が広がった話として読んでもらえたらと思います。
前任者の手順を、意味も半分で実行していた
もともと私がやっていたのは、前任者が残した手順を、その通りに実行する程度のことでした。
システムのデータを直接参照して確認する作業もありましたが、中身はほとんどがデータを「見るだけ」のものです。データを書き換えたり消したりするような、影響の大きい操作はやったことがありませんでした。そもそも、自分が実行しているものの意味を、正直なところ半分くらいしか理解していなかったと思います。前任者がそう書いていたから、そう動かす。その程度でした。
その前任者が異動することになり、この仕事を私が引き継ぎました。幸い、異動までの1年ほど一緒に仕事をする時間があり、基礎をまとめたメモももらえました。それでも、「これを、これから一人でやるのか」という不安のほうが大きかったです。
メモはありがたい。でも、メモを読むことと、自分の手で操作してエラーと向き合うことの間には、やはり溝があります。
AIには、分からないことを何度でも聞いた
その溝を埋めてくれたのが、生成AIでした。
分からない用語や挙動に出会うたび、作業でつまずくたびに質問しました。「このメッセージは何を意味しているのか」「この操作をするとデータに何が起きるのか」「なぜこの書き方が必要なのか」。初歩的な質問でも、何度でも聞けるのが助かりました。
ただ、使ううちに自分なりのルールもできました。AIの答えを、そのまま実行に移さないことです。
私の専門である学校会計についてAIに聞いたとき、回答が間違っていたり、どこか微妙だったりすることがあります。自分が間違いに気づける分野でそうなのですから、専門外の分野で出てきた答えだけを信用するわけにはいきません。
特にデータを書き換える操作は、間違えれば実務に響きます。説明を読んで分からなければ「なぜ？」とさらに聞く。業務上の前提や実際の動きとも照らす。納得できてから判断する。AIは答えをくれる相手というより、自分の理解を確かめるために付き合ってもらう相手でした。
そうしているうちに、単発の操作だけでなく、データがどう保存され、システム同士がどうつながっているかも、少しずつ分かるようになってきました。最初は名前も分からなかったテーブルやスキーマも、業者と話す中で使うようになりました。分からないときは、今でも画面の機能名で話しています。
画面のたたき台が役に立ったのは、学内で話すときだった
大きな転機は、ある新機能の開発に主担当として関わったときです。この機能には自部署の実務担当だけでなく、ほかの部署の担当者も関わりました。システムの知識も、日頃どの画面を使っているかも、人によって違います。
ゴールは共有できていても、画面の操作や機能のイメージを言葉だけですり合わせるのは、思ったより難しい。そこで、AIに画面のたたき台を作らせてみました。
出てきたものを見て、「そのまま使える」とは思いませんでした。デザインも操作の流れも、直したいところがいくつもあります。それでも、具体的な画面が一つあると、「ここはこうしたい」「この順番は逆だ」と考えやすくなりました。
とくに役に立ったのは、ITの知識がまちまちな人が集まる学内の会議やチャットアプリでのやり取りです。画面が目の前にあると、同じものを見ながら話せます。システム担当者も、日頃の業務を担当する人も、気になるところを具体的に指摘できました。
これは「業者に言葉で伝わらなかった要望を、AIの画面で伝えた」という話ではありません。業者とのやり取りには、それまで通り業務の流れや機能の正式名称を使いました。画面のたたき台は、主に学内の関係者が同じイメージを持つために使ったのです。
機能を考える中では、システム間のデータ連携についても、図のたたき台を作りました。関係者と要件を詰め、出来上がった機能が意図通り動くかを確認する受入検証にも関わりました。想定した操作だけでなく、別の業務のデータに影響していないかなど、気になるところを一つずつ確認しました。
業者の回答を確かめても、AIの答えを突き付けない
業者と開発を進める中で、相手の説明を聞いて「これはどういうことだろう」と思う場面もありました。そういうときは、AIにも聞いて、自分の理解を整理しました。
ただ、AIから出てきた答えを、そのまま業者に突き付けることはしませんでした。
業者のほうが、そのシステムに詳しい。私がAIに伝えられた前提が足りず、AIの答えのほうが間違っている可能性もあります。そもそも、相手を論破したくて調べているわけではありません。良い機能を一緒に作りたいのです。
だから、AIは「予習」に使いました。説明を自分なりに咀嚼し、「ここはこういう理解で合っていますか」「この場合はどうなりますか」と聞くための準備です。以前から業者との意思疎通はできていましたが、自分でデータの状態を確かめられるようになってからは、質問の中身が変わったと感じています。
業者に丸投げしないことと、AIに丸投げしないこと。私の中では、どちらも同じ姿勢につながっています。最後は自分で理解して判断する、ということです。
変わったのは、機能の数字よりも自分のほうだった
この新機能は、導入して最初の時期だけで、従来の運用の数倍の人数に使われました。ただし、利用が増えたのは機能のおかげだけではありません。案内を強化したことも大きかったと思います。
それでも、従来の運用では捌ききれなかっただろう規模を、大きな混乱なく処理できました。
私にとって、もっと大きかったのは、自分で調べて考えられる範囲が広がったことです。「業者に確認してください」と投げる前に、何が分からないのかを整理し、必要ならデータも見て、論点を絞って相談できるようになった。
業者にお願いする仕事は、今もあります。頼む前に自分で確認できることが増えた。その違いが、日々の仕事では大きいのです。
同じように「自分には無理」と線を引いている人へ
生成AIは、専門外のことを理解するまでの距離を縮めてくれました。用語を聞く。操作の意味を確かめる。考えを整理するためのたたき台を作る。業者に質問する前に、理解が足りないところを探す。
一方で、実行するかどうかの判断、関係者との合意形成、結果に対する責任は自分の仕事です。AIの説明に納得できないまま動かせば、その責任をAIが引き受けてくれるわけではありません。
もし今、「ここから先は専門外だから」と線を引いているなら、まずは普段使う画面の裏側で何が起きているのか、一つだけ調べてみるのもいいと思います。私自身、そこから分かることが少しずつ増えていきました。
数年前に挫折した仮想通貨botづくりやプログラミングの経験が、その後どう生きたのかは、学校法人の経理担当が、AIと一緒に15法人の決算書を読むようになった話に書いています。
公開情報の決算分析にAIを使った例は、「大学職員がClaude Codeで3大学の決算書を分析した話」に。業務でAIを使うときの情報管理については、「大学職員がClaude Codeを使って感じた確信」にまとめました。
