数千年にわたって風雪に耐え続ける万里の長城。その驚異的な耐久性を持つ理由の一つが、万里の長城を構成するレンガ一つひとつに製造者の名前を刻印する制度があったからだと言われています。なぜ、わざわざ名前を刻んだのでしょうか。それは単なる責任追及のためではなく、品質への誇りとオーナーシップを可視化する仕組みだったようです。そこで今回は、この古代の知恵を現代のソフトウェア開発に重ね合わせ、GitやCI/CDログが持つトレーサビリティ（追跡可能性）の本質を考えてみたいと思います。コードの意図を継承し、品質に誇りを持つためのオーナーシップの象徴として捉え直すことで、何かが見えてくるかもしれません。
- もくじ
1. なぜ万里の長城は崩れなかったのか
1-1. 万里の長城の「レンガの記名制度」とは？
万里の長城は、中国の歴史を象徴する巨大な建造物です。現存する延長は6000kmを超えていて、総延長は約21,196kmとされています（中国国家文物局2012年発表）。万里の長城は、数千年にわたって侵略者から国を守ってきました。万里の長城の建設は、周王朝時代からはじまっており、紀元前221年の秦の始皇帝の時代から本格化し、明の時代まで繰り返されました。厳しい自然環境や敵の攻撃にさらされながらも崩壊せずに残った背景には、建築技術の高さだけでなく、人間的な管理システムが深く関わっていたとされています。
Discover China's History Along the Great Wall（National Geographic）
万里の長城のレンガに、製造者の名前や工房名、時には担当官の名が刻まれている例が各地で確認されています。中国各地に点在する博物館や文化財研究機関の報告でも、製造地や担当組織を示す文字が残っていることが記録されています。万里の長城のレンガは粘土を焼き固めたもので、一つひとつに銘文が入れられており、建設現場で問題が発生した際に原因を遡って追及できる仕組みになっていたそうです。
この制度の目的は、もともとは品質の悪いレンガが使われたときに責任者を特定しやすくすることでした。万里の長城の建設は辺境防衛の要であり、不良品はそのまま防衛力の低下につながります。レンガに名前を刻むことで「誰が作ったのか」が明確になり、もし崩落や欠陥があれば製造元を特定できる。つまり、責任の所在を可視化していたのです。
しかし、これは単なる「監視」の仕組みではとどまりませんでした。そこにはもう一つの意味がありました。それが「誇り」を刻み込むことです。自分の名前が永遠に残る建造物に刻まれるなら、誰しも手を抜かなくなるのではないでしょうか。刻印は処罰のための道具であると同時に、職人の誇りを刺激する役割も果たしていたと考えられています。
1-2. 古代中国のトレーサビリティ思想は？
トレーサビリティとは、「いつ、どこで、誰が、何をしたのか」を追跡できる状態や機能を指しています。現代では食品や医薬品、自動車産業などで不可欠な概念ですが、万里の長城の記名制度はその原型ともいえるものでした。こうした制度は中国の官僚主義の伝統から生まれ、明代になるとさらに洗練されたといいます。万里の長城の修復工事では地方の工場ごとにレンガを割り当て、刻印で管理することで手抜き工事を防いでいました。
「品質管理か、責任追及か」という視点では、両方が絡み合っていたといってよいでしょう。中国の歴史研究では、明代には軍需物資や建材に対する検査制度が存在し、品質基準を満たさない場合は罰則が科されたことが記録されています。たしかに問題が起きれば責任を問われます。
しかし、名前が刻まれることで職人は自らの仕事に誇りを持ちました。この構造は単なる罰則ではなく、品質を担保する文化の形成に寄与していたと考えられます。責任の可視化は、恐怖による統制ではなく、信頼を前提とした品質保証へとつながっていたのです。
1-3. 「チャイナクオリティ」で数千年残る理由
現代では「チャイナクオリティ」という言葉が揶揄的に使われることがあります。しかし、万里の長城は数百年、場所によっては千年以上もその姿を保っています。これは一体なぜでしょうか。
万里の長城の耐久性については、材料の選択と管理システムが鍵だったと指摘されることがあります。たとえば、明代のレンガは高温で焼かれており、現代の基準でも強度が高いといわれています。また、レンガは粘米（もち米）のおかゆと消石灰を混ぜたモルタルで接着され、耐久性がさらに高められていたこともわかっています。
Sticky Rice Mortar, the View From Space, and More Fun Facts About China's Great Wall
地形や材料、修復の歴史など複数の要因がある中でも、組織的な品質管理と記録制度が存在したことは無視できません。万里の長城は単なる「大量生産の建築物」ではありませんでした。誰がどのレンガを作り、どの区間を担当したのかを追跡できる仕組みがあったからこそ、不具合の修正や再建も可能だったのです。つまり、耐久性を支えたのは「石やレンガ」だけでなく、「記録」でもあったといえるでしょう。
2. Gitは現代の「レンガ刻印」？
2-1. Gitのコミット履歴・署名・blameが果たす役割
転じて、ソフトウェア開発の世界で見ると、コードはまるで万里の長城のレンガのようなものです。複雑なシステムは数え切れないほどのコード行からなり、変更が積み重なっていきます。ここで、分散型バージョン管理システムであるGitが、古代の記名制度に似た役割を果たしています。万里の長城のレンガが無記名だったら、崩れた時に原因究明が難しく修復が遅れるでしょう。同様に、ソフトウェアでも変更履歴がなければ、バグの修正が迷宮入りします。
Gitでは、誰が、いつ、どのファイルを、どのように変更したかがすべて記録されます。コミットメッセージには「なぜその変更をしたのか」を書くこともでき、GPG署名を使えば変更者が本当に本人であることも証明できます。さらに、git blame コマンドを使えば、特定のコード行が誰によって書かれたのかを即座に確認できます。これは、まさに万里の長城の「レンガの刻印」と同じ発想です。GitHubのドキュメントによると、コミットメッセージに「なぜこの変更をしたか」を書く習慣が、チームの理解を深めるといいます。
blameはコードの文脈を把握するのに役立ち、単なる責任追及ではなく学習ツールとして機能します。履歴は消えません。時間が経っても追跡可能でトレーサビリティが実現されています。
2-2. 「誰が書いたか分からないコード」の問題点
開発現場でありがちなのが、「このコード、誰が書いたの？」という状況です。担当者が退職し、ドキュメントもなく、コミットメッセージも「fix」や「update」だけ。この状態は、名前の刻まれていないレンガで城壁を築くようなものです。不具合が起きても原因特定に時間がかかり、修正の影響範囲も読めません。
AtlassianのBitbucketブログでは、無記名のコードがメンテナンスコストを高めると指摘されています。調査では、コードの80%が理解不足から来るバグだとされています。特に長期運用されるシステムでは、開発当初のメンバーがいなくなることは珍しくありません。そのとき頼りになるのは、「記憶」ではなく「記録」です。
Gitの履歴は、未来の開発者への手紙でもあります。そこに意図が書かれていなければ、後任は推測するしかありません。「なんとなく動いているが、なぜそう書いたのかわからない」コードは、触るたびに新たなバグを生む温床になります。これは保守コストを大きく押し上げ、チーム全体の生産性を損なう深刻な問題となります。
2-3. CI/CDログと変更履歴が障害対応を救うケース
トレーサビリティは、障害対応の現場で真価を発揮します。たとえば、本番環境でエラーが急増したとします。そのとき、直前のデプロイ履歴やCI/CDログを確認すれば、「どの変更が、いつ反映されたのか」を特定できます。変更が追跡可能であればロールバックも迅速です。誰の変更かが明確であれば、本人に意図を確認できます。ログが整備されていれば、再発防止策も立てやすくなります。
DORA（DevOps Research and Assessment）のレポートでは、デプロイ頻度や変更失敗率、復旧時間などがパフォーマンス指標として示されており、変更管理と障害復旧の関係性が繰り返し報告されています。多くの企業がDevOpsを導入し、変更履歴とデプロイログを統合的に管理している背景には、こうした知見の蓄積があります。
これは犯人探しではありません。迅速な復旧と、チームとしての学習のための仕組みです。万里の長城の記名制度が崩壊を防ぎ修復を可能にしたように、CI/CDのログと変更履歴は、現代のシステムを守る盾になるのです。
3. 「責任追及」ではなく「オーナーシップへ」
3-1. なぜ「犯人探し」だと、トレーサビリティが思われてしまう？
トレーサビリティの本質は、責任追及ではなく、オーナーシップ、つまり所有意識を育むことです。万里の長城の職人が自分の名前を刻むことで誇りを持ったように、開発者も変更履歴を通じてコードに愛着を持つべきです。これにより、チーム全体の品質が向上し、長期運用がしやすくなります。
トレーサビリティが嫌われる瞬間があります。それは、「誰がやったんだ」と責める文化が根付いたときです。Gitのblameは便利な機能ですが、使い方を誤れば心理的安全性を損ないます。「ミスをした人を探す道具」になれば、開発者は萎縮し、履歴を残すこと自体を恐れるようになります。
Harvard Business Reviewの記事では、心理的安全性が低いチームでトレーサビリティが避けられる理由が分析されており、信頼のない環境では記録が脅威になると述べられています。ミスを責める文化では、隠ぺいや責任転嫁が起き、問題がさらに悪化します。
High-Performing Teams Need Psychological Safety: Here's How to Create It
本来、記録は組織を強くするためのものです。個人を罰するためのものではありません。万里の長城のレンガも、単に処罰のためだけなら長続きしなかったでしょう。名を刻むことが誇りであり、品質の象徴であったからこそ機能したのです。blameという名前自体が「責める」を意味し、心理的な抵抗を呼ぶように、同じツールでも使い方次第でその価値はまるで変わります。
3-2. 「誰が、いつ、なぜ変えたか」を残す文化づくり
では、どうすれば健全なトレーサビリティ文化を築けるのでしょうか。鍵は「なぜ」を書くことです。変更内容だけでなく、背景や意図をコミットメッセージに残す。設計判断の理由をIssueやPull Requestに記録する。レビューでは人格ではなくコードを議論する。こうした習慣の積み重ねが、健全な文化を育てます。
Googleのエンジニアリングプラクティスでは、変更の理由を明確に記録しレビューで議論するアプローチが取られており、GoogleのSite Reliability Engineering本のオンライン版によると、このアプローチでチームのコラボレーションが向上したとされています。
「誰が」だけでなく「なぜ」まで追跡できるとき、履歴は資産になります。それは未来のチームメンバーへの贈り物であり、過去の自分からのメッセージです。初心者の方は、まずは小さなチームで「なぜ」を書くルールを試してみてください。次第に、オーナーシップが芽生えていきます。
3-3. 長期運用されるシステムに必要な記録とチーム設計
システムが10年、20年と運用されるとき、重要なのは「人が入れ替わる前提」で設計することです。記録が整備されていれば、新メンバーは過去の意思決定を理解できます。CI/CDログ、アーキテクチャ図、変更履歴が揃っていれば、属人化は防げます。
金融システムのようにミッションクリティカルな分野では、変更ログが規制遵守にも役立つといいます。チームは定期レビューを組み込み、記録を活用する設計をすることが理想です。
トレーサビリティは保険のようなものです。普段は意識しなくても、いざというときに組織を守ります。万里の長城がいまも残るのは、単に物理的に強固だったからではありません。建設と維持の過程が、記録と責任の体系の上に築かれていたからです。現代のソフトウェアも同じです。コードそのものよりも、「誰が、いつ、なぜ作ったのか」という履歴こそが、長期運用を支える土台なのです。
4. まとめ
万里の長城のレンガに刻まれた名前は、品質管理と誇りの象徴でした。現代のGitやCI/CDログもまた、「誰が、いつ、なぜ変更したか」を残す仕組みです。トレーサビリティは犯人探しの道具ではなく、オーナーシップを育て、長期運用を支える基盤です。記録を資産と捉える文化を築くことが、未来のシステムと、そこで働く人々を守ることにつながります。
