属人化を終わらせる方法──知見を資産に変える「レガシー侍コミュニティ」【レガシー侍】

「私たちは、語ることができる以上のことを知っている。」
― マイケル・ポランニー

属人化は、なぜ繰り返されるのか

レガシーシステムの現場では、特定の担当者に知識が集中していることがあります。
「あの処理は、あの人に聞かなければ分からない」
 「この障害は、以前から担当している人しか直せない」
 「仕様書よりも、担当者の記憶の方が正確だ」
こうした状態は、珍しいものではありません。

属人化を解消しようと、設計書を整備したり、引き継ぎの時間を設けたりしても、しばらくすると別の担当者に知識が集まり、再び同じ問題が起きることがあります。

なぜ、属人化は繰り返されるのでしょうか。それは、知識を単なる情報として扱っているからかもしれません。
システムを支えているのは、プログラムの仕様や操作手順だけではありません。

• なぜこの処理が必要なのか
• どのような経緯で現在の形になったのか
• どの条件では通常と異なる判断が必要なのか
• どこを変更すると、想定外の影響が出やすいのか

こうした知識は、長年の経験の中で形成されます。形式的な資料だけでは、すべてを残すことが難しい。
だからこそ、知識は自然に人の中へ蓄積されていきます。

人に知識が集まること自体は悪くない

属人化という言葉には、否定的な印象があります。しかし、一人の人が深い知識を持つこと自体は、決して悪いことではありません。

専門性は、経験を重ねることで生まれます。複雑なシステムを理解し、わずかな変化から異常を察知し、過去の経緯を踏まえて判断できる力は、簡単に置き換えられるものではありません。

むしろ、問題なのはその知識が一人の中にとどまり、ほかの人へ移動できないことです。
専門性と属人化は、似ているようで異なります。
専門性とは、個人の知識が組織に価値をもたらしている状態です。
属人化とは、その人がいなければ組織が動けない状態です。

目指すべきは、専門家を減らすことではありません。専門家の知識が、組織の中を循環する状態をつくること。それが、属人化を乗り越える出発点になります。

問題は「知識が移動できないこと」

知識には、大きく分けて二つの性質があります。
一つは、文書や図、データとして表現しやすい知識です。

• システム構成
• プログラムの処理内容
• データ項目の定義
• 操作手順
• 障害時の復旧手順

もう一つは、言葉や文書だけでは表現しにくい知識です。

• なぜ、その設計になったのか
• どのような状況では例外を認めるのか
• どこに注意すべきか
• どの判断を優先すべきか

前者は、比較的ドキュメントに残しやすい知識です。後者は、経験や対話の中で受け継がれやすい知識です。

属人化を解消するには、すべてを文書化すればよいわけではありません。文書に残すもの、対話で伝えるもの、実際の作業を通じて学ぶもの。

知識の性質に応じて、残し方を変える必要があります。知識継承とは、情報を保管することではなく、知識が人から人へ移動できる状態をつくることなのです。

知見を資産に変える三つの条件

個人の知見を、組織の資産へ変えるためには、少なくとも三つの条件が必要です。

1．知識を見つけられること
必要な情報が存在していても、どこにあるか分からなければ活用できません。設計書、議事録、ソースコード、障害記録、担当者のメモなど、システムに関する情報はさまざまな場所に分散しています。

知見を資産にするためには、必要なときに見つけられる状態が必要です。重要なのは、すべてを一つの巨大な資料にまとめることではありません。
「どのような情報が、どこにあり、誰が説明できるか」が共有されていることです。

2．知識の背景を理解できること
仕様だけを残しても、その背景が分からなければ、将来の変更判断には使えません。たとえば、複雑な例外処理があったとします。

一見すると不要に見えても、過去の事故を防ぐために追加されたものかもしれません。 特定の顧客との取引条件を守るために必要なものかもしれません。
「何をしているか」だけでなく、「なぜそうしているのか」を残すことが重要です。

3．知識が更新され続けること
知識は、一度残せば終わりではありません。システムは変わり、業務は変わり、担当者も変わります。更新されない資料は、やがて現実と合わなくなります。

そして、誰も資料を信用しなくなります。知見を資産として維持するためには、更新を特別な作業ではなく、日常の一部にする必要があります。

知識を残す。
使う。
間違いに気づく。
修正する。

この循環が続いて初めて、知識は生きた資産になります。

コミュニティが知識継承に果たす役割

知識継承というと、社内の仕組みを想像しがちです。しかし、レガシーシステムに関する知識は、一つの会社の中だけに存在しているわけではありません。

同じ言語、同じOS、同じデータベース、似た業務システムを経験してきた人は、さまざまな企業や業界にいます。ある会社では珍しい問題でも、別の会社ではすでに何度も経験されているかもしれません。

ここに、コミュニティの価値があります。コミュニティは、知識を一つの組織の中に閉じ込めず、会社や世代を越えて循環させる場です。

• 同じ技術を経験した人同士が知見を共有する
• 過去の失敗や成功を、次の現場に生かす
• 一人では解決できない問題に、複数の視点を持ち寄る
• 若い技術者が、過去の技術や設計思想を学ぶ

知識が共有されることで、個人の経験は、社会的な資産へと広がっていきます。

ベテランの知識と次世代の技術をつなぐ

レガシーシステムの世界では、長年の経験を持つ技術者と、新しい技術を扱う世代が分かれてしまうことがあります。ベテランは、既存システムの構造や業務背景を深く理解している。

 一方、若い技術者は、クラウド、AI、データ活用、新しい開発手法に詳しい。どちらか一方だけでは、持続的なモダナイゼーションは成立しません。

過去を理解しないまま新しい技術を導入すると、必要な知識が失われます。過去の知識だけを守っていても、新しい環境への適応が進みません。必要なのは、どちらかを選ぶことではなく、両者をつなぐことです。

ベテランが持つ背景知識を言葉にする。
若い技術者が、それを新しい設計や技術へ翻訳する。
その過程で、双方が学び合う。

知識継承とは、古い知識をそのまま保存することではありません。過去の知識を、次の時代で使える形に変換することです。

レガシー侍コミュニティが目指すもの

レガシー侍コミュニティが目指しているのは、レガシー技術を懐かしむ場ではありません。また、特定の技術や考え方だけを正解として広める場でもありません。

目指しているのは、長年培われてきた知識や経験に、もう一度光を当てることです。企業の中では、レガシーシステムに関する仕事が目立ちにくいことがあります。

大きな障害を起こさず、毎日同じように動き続けること。
 誰にも気づかれないまま、重要な業務を支え続けること。

それは派手ではありませんが、企業活動に欠かせない仕事です。その仕事を担ってきた人の知識を、個人の中で終わらせない。会社や世代を越えて共有し、次の変化へつなげていく。そのために必要なのは、巨大な仕組みだけではありません。

勉強会で経験を語ること。
過去の事例を共有すること。
分からないことを質問すること。
若い世代に技術の背景を伝えること。

一つひとつは小さな活動です。しかし、こうした活動が積み重なることで、知識は人から人へ移り、やがてコミュニティ全体の資産になります。

おわりに：知識は、共有されたときに組織の力になる

属人化を完全になくすことは、現実的ではないかもしれません。人はそれぞれ異なる経験を持ち、異なる強みを持っています。知識が特定の人に集まることもあります。大切なのは、その状態を放置しないことです。

• 知識を見つけられるようにする
• 背景や判断理由を残す
• 更新される仕組みをつくる
• 対話と実践を通じて次の人へ渡す
• 組織や企業を越えて知見を循環させる

個人の知識が共有されたとき、それは組織の力になります。組織の知識が開かれたとき、それは業界全体の力になります。

レガシー侍コミュニティが目指すのは、知識を保管することではありません。知識が人と人の間を移動し、次の価値を生み出し続ける状態をつくること。属人化を終わらせるとは、人への依存を否定することではなく、人が持つ知恵を次の人へ渡せるようにすることなのです。

次回予告｜Vol.9
レガシー＋AIで長期運用は実現できるのか──人の知恵とテクノロジーの新しい関係
AIは、人の経験を置き換えるのでしょうか。それとも、失われかけた知識を読み解き、次の世代へ渡すための道具になるのでしょうか。

※免責・ご注意
本記事は、レガシー侍コミュニティにおける一般的なナレッジや議論をもとに、ChatGPTにより生成・編集された内容を含みます。
本記事は、特定企業の公式見解、サービス仕様、提供方法、プロジェクトの進行方法、成果物等を示すものではありません。また、記載内容を前提とした発注、見積依頼、契約上の条件としての利用を想定したものではありません。個別のシステムに関する判断や対応は、それぞれの状況、要件、リスクおよび契約条件に応じて検討する必要があります。