LASSIC Media らしくメディア
属人化解消できないと内製化支援のあと自走は止まる｜4つの仕組み
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 内製化支援のあとに自走できているかは、特定の人が不在でも作業と判断が止まらないかで確かめます。
- 金融庁の障害事例では、直されない手順書、詳しくない人のレビュー、足りない引き継ぎが原因に挙がっています。
- 支援が終わる前に、手順書・レビュー・担当の入れ替え・判断の記録を社内だけで回せるか試しておきます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
内製化支援を受けて、社内のチームで開発や運用を回せるようになった。ところが、ある機能のことは特定の社員しか分からず、その人が休むと作業が止まる——。内製化を進めた会社では、支援が終わったあとにこうした状態が残ることがあります。ここでいう属人化解消とは、手順や判断の理由が特定の人の頭の中だけにある状態をほどき、誰が担当しても同じ水準で作業できるようにすることを指します。
属人化を解いておけば、異動や退職があっても自走を続けやすくなります。ただし手順書を作るだけでは足りず、手順書を直し続ける決まりや、中身を確かめる人の置き方まで要ります。本記事では、開発チームを預かるマネージャーに向けて、金融庁が公表した障害事例を手がかりに、手順書、レビュー、引き継ぎと担当の入れ替え、判断の記録の4つの仕組みと、支援が終わる前に確かめておきたい点を整理します。
目次
内製化支援のあとに残る属人化
内製化支援は、外部の専門家が社内の担当者と一緒に作業しながら、知識や手順を社内に移していく支援です。支援の期間中は、分からないことがあれば支援側に聞けます。支援が終わるとその問い合わせ先がなくなり、支援から最も多くを学んだ社員に質問と判断が集まりがちです。支援先への依存が、社内の一人への依存に置き換わる形です。
属人化が問題になるのは、ふだんの作業よりも、担当者が不在のときや、いつもと違う作業をするときです。本番環境の設定変更、障害からの復旧、久しぶりに触る機能の改修といった場面では、手順や判断の理由を知る人がいないと、作業が止まるか、誤った手順のまま進んでしまいます。
自走とは、外部の支援がなくても社内で開発と運用を続けられる状態を指します。自走化の判断の基準そのものは内製化支援から自走へ、自走化判断で確かめる3つの基準で扱っているので、本記事では属人化解消の具体的な仕組みに絞ります。
金融庁の事例集から読めること
手がかりにするのは、金融庁が2026年7月に公表した「金融分野におけるITレジリエンスに関する分析レポート」です。*1 金融機関から報告されたシステム障害をもとに、2025年度（2025年4月〜2026年3月）の障害の傾向や原因、対策をまとめたもので、補論1にシステム障害の事例集が収録されています。
事例集は障害を起きた場面ごとに分け、事例ごとに業態、事象、原因、対策を並べています。本記事が主に見るのは、日常の運用・保守の中で起きた障害のうち設定ミス・操作ミスなどの管理面・人的要因に分類された22件と、プログラム更新や普段と異なる特殊作業から起きた障害のうち同じ分類の12件です。*1
事例は銀行や証券会社、資金移動業者などの金融機関のもので、内製化支援を受けた会社を調べたものではありません。それでも原因の欄には、手順書が直されていなかった、詳しい人がレビューに入っていなかった、引き継ぎが足りなかったといった、業種を問わず起こりうる記述が並びます。以下では、これらを4つの仕組みに分けて読んでいきます。
手順書を直し続ける決まり
1つ目は手順書です。事例集を読むと、手順書が無かったことよりも、あっても中身が実態と合っていなかったことが原因になった例が目立ちます。ネットワーク機器の予防交換を誤った事例では、「手順書の変更管理ルールが徹底されていなかった」ことが原因に挙がり、作業の手順書が直されないままになっていました。*1
別の事例では、外部委託先から「マニュアルに基づき復旧を実施」したと報告を受けていたものの、実際にはその事象に合うマニュアルが無く、復旧手順が整っていませんでした。*1 手順書があると思い込んでいると、実は特定の人の記憶で動いていたことに、障害が起きてから気づくことになります。
内製化支援で受け取った手順書は、支援側が書いたまま更新されないことがあります。システムに手を入れたら、同じ変更の中で手順書も直す、という決まりにしておくと、手順書が実態から離れていくのを防げます。作業の指示を定型のテンプレートで出す方法もあり、事例集ではルート定義の作業指示書をテンプレートにして「属人的なミスの抑制」を図った例が挙がっています。*1
読みやすさにも目を配ります。設計書の判読性が低かったために作業者が環境の構成を取り違え、本番環境のファイルシステムが壊れた事例もあります。*1 書いた本人には分かる書き方でも、初めて読む人には伝わらないことがあるので、手順書は書いた人以外の人に一度たどってもらって確かめます。
詳しい人と別の目のレビュー
2つ目はレビューです。DBサーバーの変更作業を誤った事例では、システム環境の理解が十分でない担当者が誤った手順で作業し、事前の手順のレビューも「有識者ではない管理者」が行ったため、不備を見逃したとされています。*1 対策には、手順を作るときのチェックリストの整備と、レビューへの有識者の配置が挙がっています。
一方で、詳しい人が一人で調べて一人で決める形も危うさを抱えます。暗号資産交換業者の事例では、外部サービスについて担当者が単独で行った技術調査の結果をほかのメンバーが確認しておらず、誤った調査内容のまま要件定義と実装に進んでいました。*1 作業量が少なく難しくない作業だからと担当者1名の体制にし、作業時の確認が十分に働かなかった事例もあります。
内製化した直後のチームでは、詳しい人が少ないため、その人がレビューも作業も引き受けがちです。詳しい人がレビューに入ることと、詳しい人の作業を別の人が見ることの両方を決まりにしておくと、知識が一人に閉じたままになるのを避けやすくなります。レビューの観点をチェックリストにしておけば、経験の浅いメンバーもレビュー役を担えるようになります。
引き継ぎと担当の入れ替え
3つ目は引き継ぎと担当の入れ替えです。利用者情報を変更する機能を改修した事例では、同じプログラムが別の操作からも使われていることを担当者が知らず、改修の影響を見落としました。その理由として、開発メンバーが替わったときの引き継ぎが十分でなく、業務の仕様を理解しきれていなかったことが挙がっています。*1
引き継ぎで漏れやすいのは、手順書に書くほどではないと思われていた前提です。テーブルを更新した開発担当者とバージョン管理の担当者の間で情報が伝わっていなかった事例や、開発担当から運用担当へサーバーの再起動が要らないことを伝えておらず、不要な再起動でATMが使えなくなった事例もあります。*1
担当の入れ替えをあらかじめ計画に入れておくと、引き継ぎを異動のときだけの作業にせずに済みます。たとえば、半年ごとに機能の担当を一部入れ替え、前任が後任のレビュー役を務める形にすると、手順書に書かれていない前提が入れ替えのたびに表に出てきます。一度に全部を入れ替えると作業の質が落ちやすいので、重要な機能ほど担当が重なる期間を長めに取ります。
判断の理由を記録に残す
4つ目は判断の記録です。手順は書き残せても、なぜその設定にしたのか、なぜその対応を見送ったのかという理由は、決めた人の頭の中に残りがちです。勘定系システムが副系統に切り替わった際、パッチを当てていなかったOSの不具合が表に出た事例では、委託元として外部委託先に「パッチ未適用と判断した根拠まで確認していなかった」ことが原因の一つに挙がっています。*1 対策には、パッチを適用する判断基準の明確化が入っています。
承認の手順も判断の記録の一部です。災害対策環境の起動試験からATMの誤接続が起きた事例では、例年の訓練と同じだと誤認してリスクを評価できず、「本来は経営承認が必要な案件が部内決裁のみで実施され」たとされています。*1 対策には、試験と環境変更の承認ルールの明確化や、IT人材の配置と育成計画の策定が並んでいます。
内製化したチームでは、判断ごとに、何を決めたか、なぜそうしたか、誰が承認したか、どうなったら見直すかを短く書き残しておくと役立ちます。形式は課題管理ツールのチケットでも、設計判断の記録用の文書でも構いません。後から来た人が理由をたどれれば、前任に聞かなくても、その判断を続けるか変えるかを決められます。
支援が終わる前に確かめる点
4つの仕組みは、支援が続いているうちに試しておくのが確実です。支援側が手を出さない期間を設け、社内のメンバーだけで手順書をたどった作業、レビュー、担当の入れ替え、判断の記録が回るかを確かめます。詳しい人を外した状態で、障害対応の訓練を手順書だけで進めてみるのも一つの方法です。事例集でも、システム基盤に詳しい人が運用担当者に行う研修の内容の最新化と、研修の定期的な実施が対策に挙がっています。*1
確かめる観点は4つに整理できます。主要な作業の手順書が最新の変更を反映しているか。どの作業にも、作業者とは別にレビューできる人がいるか。各機能に主担当と副担当がいるか。直近の主な判断について、理由と承認者をたどれるか。欠けている点があれば、支援の範囲や期間を決める段階で、その部分を優先して移してもらうよう相談するのが一案です。ただし、支援を受けたことだけで自走が保証されるわけではないので、社内で回す力を見極めながら進めます。
外部に委託するときに確認しておきたい点
内製化支援を頼むときは、提案の段階で、手順書や判断の記録を誰がいつ書き、支援の終わりにどの状態で受け取るのかを確かめておきます。支援側が作業を代わりに進めるだけだと、知識が支援側に残ったままになりかねません。社内のメンバーが主担当やレビュー役を務める時期を計画に入れてもらえるかも聞いておきます。
自走したあとも、ある技術に詳しい人が社内に一人しかいない状態が続くことがあります。その場合は、社内での育成と並行して、その技術の経験を持つ人を社員として採るか、業務委託で開発に加わってもらうかを検討します。どちらの場合も、手順書・レビュー・判断の記録の決まりに沿って動いてもらえば、新しい属人化を生みにくくなります。
担当者の離脱に備えた洗い出しは担当者の離脱に備えて技術情報の個人依存を洗い出すで扱っています。
外部の人材から社員へ技術を移す方法は外部人材活用から内製化へ、技術移転で社員に移すものと確かめ方にまとめました。
まとめ：属人化解消で確かめておきたい4つの点
内製化支援のあとに自走を続けるうえで、属人化解消のために確かめておきたい点は4つに整理できます。第一に、手順書をシステムの変更と同時に直す決まりがあること。第二に、詳しい人がレビューに入り、詳しい人の作業も別の人が見ること。第三に、主担当と副担当を置き、担当の入れ替えを計画に入れること。第四に、判断の理由と承認者を記録に残すことです。この4点を支援が終わる前に試しておけば、「あの人がいないと分からない」状態を減らしやすくなります。社内に一人しかいない技術があれば、外部の手を借りるのも一つの選択肢です。
よくある質問
属人化解消は、内製化支援のどの段階から始めればよいですか
支援の終盤ではなく、始めの段階から計画に入れておくのが扱いやすい方法です。手順書の更新、レビューの体制、担当の入れ替えは、支援を受けている間に一度回しておかないと、支援が終わってから足りない点に気づくことになります。社内のメンバーが主担当を務める時期を、支援の計画に書き込んでおきます。
詳しい人が一人しかいない場合、レビューはどうすればよいですか
その人の作業は別の人が見る、その人がほかの人の作業を見る、の両方を決めます。見る側が詳しくなくても、チェックリストに沿えば手順の抜けや前提の食い違いは確かめられます。事例集でも、管理者に加えてプロジェクト責任者がレビューすることと、確認の観点を明確にすることが対策に挙がっています。*1
判断の記録は、どの程度の判断まで残せばよいですか
すべてを残そうとすると続かないので、後から変えると影響が大きい判断に絞ります。たとえば、採用した技術や構成、見送った対応、セキュリティ上の例外、本番環境への変更の承認です。記録は、決めたこと・理由・承認した人・見直す条件の4点があれば足ります。
社内に一人しかいない技術があれば相談
社内で担える人が一人しかいない技術や、担当を重ねたい機能が分かっていれば、そのままご相談いただけます。どの機能から手を付けるか決めきれていない段階でも構いません。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：金融庁「金融分野におけるITレジリエンスに関する分析レポート」（2026年7月）（PDF）（https://www.fsa.go.jp/news/r8/sonota/20260730/01.pdf）。出典：第1編（はじめに）と、補論1 システム障害に関する分析（事例集）のうち、第3章第2節（設定ミス・操作ミス等の管理面・人的要因）の事例3・6・14・16・21、第4章第1節（同）の事例1・2・4・6・9・10・11・12を参照（確認日2026年10月6日）（2026年10月確認）
- *2 参考：金融庁「『金融分野におけるITレジリエンスに関する分析レポート』の公表について」（https://www.fsa.go.jp/news/r8/sonota/20260730/20260730.html）。出典：レポート本体と概要の掲載ページ（確認日2026年10月6日）（2026年10月確認）
