こんにちは。タイミーQAエンジニアの矢尻です。
この記事は Timee Advent Calendar 2025 シリーズ1の23日目の記事です。
「アドベントカレンダー」といえばキリスト教の待降節ですが、実は私、元神主（神職）というちょっと変わった経歴を持っています。
「異教徒がアドベントカレンダーを書いていいのか？」と心配される方もいるかもしれません。しかし、日本の神道には「八百万（やおよろず）の神」という、あらゆるものに神性を見出す懐の深い概念があります。クリスマスも正月も祝う日本人の精神性において、このテックブログもまた、技術の神々に感謝を捧げる「祭り」の一環と捉えれば、何ら問題はありません（ほんとに？）。
さて、今日はそんな異色の経歴を持つ私が、神社祭式とソフトウェア品質保証（QA）の驚くべき共通点」について、少しマニアックに語りたいと思います。
神社は「巨大なレガシーシステム」
神職からエンジニアに転身して最初に感じたこと。それは「やっていることが本質的に同じだ」という衝撃でした。
神社には「祭式（さいしき）」という厳格なプロトコルが存在し、「式次第」というプログラムがあり、「祝詞（のりと）」という仕様書が存在します。これらが緻密に相互作用し、バグ（不作法）なく執り行われることで、初めて「祭り」というシステムが正常稼働（デプロイ）されます。
私がQAエンジニアとして日々システムに祈っている「平穏」は、神主時代に祈っていた「安寧」と、構造的に全く同じものなのです。
1. 「祓（はら）へ」と「デバッグ」：ケガレを除去するリファクタリング
神道には「ケガレ（穢れ/気枯れ）」という概念があります。これは罪や穢れ、気力が枯渇した状態を指します。これを元の清浄な状態（あるべき姿）に戻すのが「祓（はら）へ」です。
システム開発における「バグ」や「技術的負債」、あるいは「不安定なテストデータ」。これらはまさにシステムにおける「ケガレ」です。
- 修祓（しゅばつ）： 祭儀の最初に行うお祓いは、本番環境（祭場）へ移行する前の初期化処理やスモークテストです。
- 大祓（おおはらえ）： 定期的に蓄積した罪穢れを祓う行事は、定期的なリファクタリングそのものです。
「祓へ」によって場をクリーンにしなければ、どんなに素晴らしい祝詞（機能）も神様（ステークホルダー）には届きません。QAがバグを見つけ出し修正を促す行為は、システムを「清浄」に保つための神聖なプロセスなのです。
2. 祭式をコードで理解する
神社の儀式はブラックボックスに見えますが、実は非常に堅牢なアーキテクチャで設計されています。 ここでは、神職が奉仕する「家内安全祈願祭」を、あえてエンジニアの皆様に馴染み深いコードに置き換えて紹介したいと思います。
身体的プロトコル：「進左退右」というコーディング規約
コードに入る前に、マニアックな仕様の話をさせてください。 神職が祭場を歩くとき、「進左退右（しんさたいゆう）」という厳格なルールがあります。「進むときは左足から、退くときは右足から」という決まりです。
「どっちでもいいだろ」と思われるかもしれませんが、これは「オペレーションミスによる障害」を防ぐための物理的な制約です。 上位（神前）に近い足を軸にすることで、体の向きが安定し、神主同士がぶつかったり（コンフリクト）、転んだり（クラッシュ）、神様に背中を向けたり（要求定義からの逸脱）するリスクを最小化しています。祭式とは、人間の身体動作に実装されたコーディング規約なのです。
Rubyによる式次第の実装
では、祭りの進行表である「式次第」をRubyのコードに落とし込みます。 原文のプロセスとコードのロジックが完全に1対1で対応している点にご注目ください。
【原文】家内安全祈願祭 式次第
- 参進（さんしん）：祭場へ入る
- 修祓（しゅばつ）：心身を祓い清める
- 献饌（けんせん）：お供え物を捧げる
- 祝詞奏上（のりとそうじょう）：願い事を申し上げる
- 玉串拝礼（たまぐしはいれい）：拝礼する
- 撤饌（てっせん）：お供え物を下げる
- 退下（たいげ）：祭場から退く
【コード】KanaiAnzenService.rb
class KanaiAnzenService include ShintoProtocols # 祭事は不可分な一連の処理であるため、トランザクションとして扱う def execute(devotee:) ActiveRecord::Base.transaction do begin # 1. 参進（さんしん） # ※Linter: 進左退右プロトコルに準拠すること enter_shrine(devotee, step_strategy: :shin_sa_tai_u) # 2. 修祓（しゅばつ）：初期化・クリーンアップ # ※ここが最重要。穢れ（Bug/Dirty Data）が残っていると後の処理は全て無効 unless perform_purification(target: devotee, level: :strict) raise UncleannessError, "祓い清めが不十分です。儀式を続行できません。" end # 3. 献饌（けんせん）：リソースロード # 依存関係順（米→酒→塩→水）にロードしないとエラーになる offer_shinsen(type: :sake_and_food, order: :strict) # 4. 祝詞奏上（のりとそうじょう）：コアロジック実行 # 言霊パラメータを神界へ送信 invoke_norito(type: :kanai_anzen, target: devotee) # 5. 玉串拝礼（たまぐしはいれい）：ユーザーインタラクション # ユーザー（参拝者）自身によるコミット操作 guide_tamagushi_worship(devotee) # 6. 撤饌（てっせん）：リソース解放 withdraw_shinsen rescue UncleannessError => e # 異常系：儀式の中断。再浄化（Fix & Re-test）が必要 handle_kegare(e) raise e ensure # 7. 退下（たいげ）：プロセス終了 # 成功失敗に関わらず、最後は退室する exit_shrine end end end end
transaction ブロックで囲んでいるのがポイントです。お祓いに失敗したまま祝詞だけ読んでも、それは儀式として成立しません（コミットされません）。実際の祭りでもロールバック（やり直し）されます。ACID特性が求められるのです。
3. 祝詞の仕様定義：Gherkin
次に、祭儀の核となる「祝詞（のりと）」です。 祝詞は、「誰が」「どういう状態で」「何をすれば」「どうなるか」を宣言するものです。これは、振る舞い駆動開発（BDD）における Gherkin記法 そのものです。
「家内安全」の祝詞の原文と、それをGherkinに翻訳したものを並べてみます。
【原文・Gherkin対応】
Feature: 家内安全 (Family Safety)
In order to 平穏無事な生活を送るため
As a 氏子/崇敬者
I want to 神の加護を得て災いを防ぐ
Scenario: 祓い清められた状態で祈願を行う
# 【原文】掛けまくも畏き（かけまくもかしこき）XX神社の大前（おおまえ）に
# 【意味】言葉にするのも畏れ多い、XX神社の神様の御前にて
Given ターゲット環境は "XX神社本番環境" である
# 【原文】宮司 氏名 恐み恐みも白す（かしこみかしこみもまおす）
# 【意味】宮司の[氏名]が、謹んで申し上げます
And 実行ユーザー(Actor)は "認定神職" である
# 【原文】此の氏子（うじこ）◯◯の家族（やから）一同
# 【意味】この氏子である[住所][氏名]の家族全員が
And 対象オブジェクトは "氏子[住所][氏名]のFamilyクラス全インスタンス" である
# 【原文】過ち犯す事無く 災い触れる事無く
# 【意味】過ちを犯すことなく、災難に遭うこともなく
When "HumanError" および "ExternalDisaster" イベントが発生しない条件を適用し
# 【原文】夜の守り 日の守りに守り恵み給い
# 【意味】昼も夜も守り恵んでいただき
And "24/365" の監視体制(Protection)を有効化し
# 【原文】平らけく安らけく 孫の代に至るまで
# 【意味】平穏無事に、子孫の代に至るまで
Then システム稼働状況は "平らけく安らけく(Stable)" であること
And データ永続性は "孫の代(LongTerm)" まで保証されること
# 【原文】家門（いえかど）高く広く 立ち栄えしめ給へと 恐み恐みも白す
# 【意味】家がますます繁栄しますようにと、謹んで申し上げます
And "家門(BusinessValue)" は右肩上がりにスケールすること
「言霊（ことだま）」とは、言葉にしたことが現実になるという信仰ですが、エンジニアリングにおいても「コード（言語）にしたことが実際の挙動になる」という点は全く同じです。 正確な言葉（コード）で記述しなければ、システムは意図通りに動きません。
4. 式年遷宮という名の「大規模リプレース」
エンジニアの世界では、大規模なシステムリプレースのことを冗談交じりに「式年遷宮（しきねんせんぐう）」と呼ぶことがあります。 伊勢神宮で20年に一度行われる、社殿を新しく建て替える一大プロジェクトのことですね。
実はこれ、神道的な観点でも意図・目的が完全に一致しています。 式年遷宮の真の目的は、建物を新しくすることだけではありません。「宮大工の知識と技術の継承」こそが本質です。 20年というサイクルは、ベテランから若手へ技術を継承するのに最適な期間（世代交代の期間）として設計されています。
システムも同じです。どんなに堅牢なコードも、それを保守する技術者がいなくなれば（属人化すれば）いずれ朽ち果てます。 コードを書き直し、技術スタックを新しくすることは、システムという「神」を若返らせ、技術という「伝統」を次世代へ継承するための、聖なる営みなのです。
結びに代えて：「平らけく安らけく」の祈りを込めて
神道の祝詞によく登場する「平（たい）らけく安（やす）らけく」という言葉があります。 これは「波風が立たず、平穏であること」を願う言葉です。
私がQAエンジニアとしてリリース直前に願うこと。それは新機能の華々しい成功よりも先に、「システムがクラッシュせず、ユーザーにとって当たり前の日常（平穏）が守られますように」という祈りです。
しかし、神主の祈りは「神頼み」ではありません。 掃除をし、場を整え、身を清め（テストをし）、作法を極めた（バグを修正した）上で、最後の最後に捧げるのが祈りです。 「人事を尽くして天命を待つ」。このプロセスこそが品質保証の本質であり、それは「祭り」の準備と何ら変わりがないのです。
今年も残りわずかとなりました。 アドベントカレンダーという「祭り」を通じて、皆様と知見（？）を共有できたことを嬉しく思います。
来る新玉（あらたま）の年が、皆様そして皆様の開発するシステムにとって、バグなき清浄なものであり、弥栄（いやさか）に栄え、平らけく安らけくあらんことを、心よりご祈念申し上げます。
タイミーでは一緒に働く仲間を募集しています。ご興味があればぜひお話ししましょう！
