システムの属人化を解消するには｜コードより先に残したい業務の仕様

システムの属人化を解消するために、私が最初に確認したいのは、業務としてどう動くべきかを説明できる人と資料があるかです。

ソースコードが残っていても、そこに書かれた処理が正しいとは限りません。なぜその処理が必要なのか、どの結果なら業務上正しいのか。その判断が特定の人の頭の中にしかなければ、担当者が替わったときに困ります。

私は以前、コードしか残っていない業務システムの改善に取り組みました。幸い、当時の開発者と、クライアントの業務やシステムを理解している人が社内にいました。その人たちに話を聞き、あるべき仕様を把握してから、処理を一つずつ見直しました。

この経験から、属人化への対策では、コードだけでは分からない業務の仕様を残すことに価値があると考えています。

コードしかなくても、業務を知る人に聞けた

私が担当したのは、長年運用されてきた業務システムです。まとまった仕様書はなく、手元にあったのはソースコードでした。

何をしているプログラムなのかは、コードを読めば調べられます。ただ、それが本来の業務に合っているかまでは、コードだけでは判断できませんでした。

そこで、当時システムを作った人や、クライアントの業務を理解している人から話を聞きました。既存システムのあるべき姿を理解し、処理を分解して、正しく動いている箇所とそうでない箇所を切り分けていきました。

仕様を確認する相手がいたことは大きかったと思います。もしその人たちもいなければ、コードの動きを調べたうえで、その結果が業務として正しいのかを確かめるところから始める必要があったはずです。

システムが動き続けていると、引き継ぎも何とかなるように見えます。でも、仕様を知る人に聞けるうちに残せる情報は、退職してからでは集めにくくなります。

人手と予算が足りないと、知識を残す仕事が後回しになる

私の見方では、システムが属人化する背景には、人手不足や予算不足があります。特定の会社だけに起きる問題ではありません。

限られた人数で開発と運用を続けていれば、目の前の改修や障害対応が優先されます。業務を知っている人に聞けば解決する間は、仕様を文書にまとめる仕事に時間を割きにくいのでしょう。

「担当者に資料を作ってもらう」と決めても、普段の仕事に上乗せするだけでは進みません。経営者が属人化を解消したいなら、聞き取りや仕様の整理に使う時間も、仕事として確保する必要があると思います。

残したいのは、コードから読み取れない業務の仕様

この経験を通じて、業務システムには「あるべき仕様」が正確にまとまったドキュメントがほしいと感じました。

例えば、請求処理を考えてみます。どの取引を当月の請求対象に含めるのか、取り消しがあったらどう扱うのか。こうした業務の決まりと、その理由を残しておくと、改修時に何を守るべきか判断できます。これは説明のための例ですが、コードの動きと業務の仕様を分けて考えるときに分かりやすいと思います。

一方、コードの処理をそのまま図や文章に写しただけの「コードの設計図」は、私はあまり必要だと思っていません。実装の細部はソースコードを読めば確認でき、生成AIもその読解を助けてくれるようになりました。

もちろん、設計の理由や、外部システムとの取り決めまで不要という意味ではありません。コードからは分からない判断や制約は残したい情報です。

業務の仕様を整理するなら、まずは次の内容があると役立ちます。

何の業務のために、その処理が必要なのか
どのデータを、どの条件で処理するのか
どの結果になれば正しいのか
例外の場合はどう扱い、判断に迷ったら誰に確認するのか

立派な資料を一式そろえるより、次の担当者が正誤を判断するときに使える情報を残したいです。

属人化したシステムの改善は、あるべき仕様から始める

私が進めた順番は、まず業務として正しい仕様を把握し、それをもとに既存の処理を調べるというものでした。

業務やシステムを理解している人に、あるべき仕様を確認する
ソースコードを処理ごとに分解し、仕様と照らし合わせる
正しく動いている箇所とそうでない箇所を切り分け、修正する

既存のコードを正解として読み始めると、もともとの誤りまで仕様として受け継いでしまうおそれがあります。長く動いている処理でも、意図どおりに実装されているとは限りません。

IPAの要件定義の解説でも、業務部門が主体的に参加し、関係者の要求を整理して合意する進め方が示されています。既存システムを引き継ぐときにも、技術者だけで正解を決めず、業務を知る人と確認することが必要です。

私の経験では、仕様を確かめながら処理を見直すことで、正しく動くように改善できました。引き継ぎで目指したいのは、そこで分かった仕様を文書にまとめ、自分以外の人もシステムを理解できる状態です。

聞き取りで分かったことを自分の頭の中だけに置いてしまえば、詳しい人が自分に替わっただけになってしまいます。

生成AIにも、書かれていない業務の正解は渡せない

生成AIは、コードを読んだり、処理の内容を説明したりする作業を助けてくれます。古いコードを調べる際にも、使える場面はあると思います。

ただし、業務の前提を与えていなければ、AIの説明をそのまま「あるべき仕様」として扱うことはできません。既存コードの動きを説明できたとしても、その動き自体に誤りがあるかもしれないからです。

私はAIを使った開発で、必要な情報が足りないまま処理が作られ、一見動いているように見えるケースを経験しています。コードから作った資料も、業務を知る人と技術者が内容を確かめる必要があります。

AIに任せられる作業と、人が引き受ける判断については、AIでエンジニアは不要になるのかでも書いています。

技術者がいない会社は、判断できる人と業務資料を確保する

重要な業務システムの運用を、開発や運用の経験がない社員に任せるのは、生成AIがあっても現実的ではないと私は考えています。決められた操作ができることと、障害や改修の影響を判断できることには差があります。

社内で技術者を採用できなければ、外部でも構いません。そのシステムを調査し、変更や復旧を判断できる人を確保しておくことを勧めます。定期的な助言を頼むのか、障害時にも対応してもらうのかは、依頼するときに確かめたいところです。

経営者や業務担当者が概要を理解するためには、仕様書と操作マニュアルが役立ちます。仕様書には業務上の決まりや正しい結果を、操作マニュアルには日常の使い方を書きます。両方があれば、「いつもどおりに操作できたか」に加えて、「期待した結果になっているか」も確認しやすくなります。

担当者がまだ在籍しているなら、まずは重要な業務から聞き取りの時間を確保する。すでにいなければ、現場で業務を知る人と、システムを調べられる技術者をそろえる。分かっている仕様と、まだ確認できていないことを分けて残すところから始めるのがよいと思います。

外部に技術判断を補ってもらう方法は、技術顧問の役割と依頼できることにまとめています。

システムの属人化を解消したいなら、「業務として何が正しいのか」を説明できる状態を残したい。そのための仕様書と、実際の処理を評価できる人がそろって初めて、次の担当者へ引き継げると考えています。