はじめに
株式会社LITALICOでエンジニアをやっている@kazuisです。
この記事は『LITALICO Engineers Advent Calendar 2025』の2日目の記事になります。
放課後等デイサービスや就労移行支援の事業所を300以上運営している会社です。
障害者福祉・介護領域・学校教育領域でSaaSプロダクトを自社で開発し提供している会社でもあります。
この記事は、3匹のこぶたを題材にポストモーテムしてみようという内容です。
シフトレフトを活かすためには、開発プロセスのどのフェーズで品質の議論していくかタイミングがもっとも重要だからです。
対象読者
- プロセス改善したい人
- QAエンジニア
- システム全体設計をするアーキテクト
- プロダクトの品質に興味ある人
「3匹の子豚に学びシフトレフトでプロダクト品質をつくる」の概要
先日、技術書典で「3匹の子豚に学びシフトレフトでプロダクト品質をつくる」という記事を書かせてもらいました。これは、その記事の兄弟記事です。
書籍を読んでない方向けに概要をまとめると、童話「三匹のこぶた」をメタファーに、ソフトウェア開発における「シフトレフト」と品質保証活動の重要性を書いています。
「藁」と「木」の家は、納期とコスト（早さ・安さ）を優先した結果、オオカミ（高負荷や攻撃といった非機能要件）というリスクに耐えられず崩壊してしまいます。対して「レンガ」の家は、設計段階から安全性と品質を作り込む「シフトレフト」を実践し、堅牢なアーキテクチャで脅威を防ぎました。 しかし、煙突からの侵入という潜在的リスクを残してしまいました。
現代のQAエンジニアはテスト工程だけでなく上流工程から参画し、オオカミのような潜在的リスクを定義・対策することで、手戻りを防ぎ、長期的なプロダクト価値を作っていきましょうという内容です。
ポストモーテムとは
プロダクト運用時に障害が起きたとき、「障害報告書」や「始末書」を書かされた経験はありませんか？ 「誰がミスったんだ」「なんでチェックしなかったんだ」と詰められるあの時間は、胃が痛くなります。
でも、ポストモーテムは違います。これは「犯人探し」ではなく、「仕組みの改善」をするための活動です。
目的は二度と同じ失敗を繰り返さないための「学び」を得ること。ルールは個人を責めない。「あの時、チームとして何が足りなかったのか？」を考えるをチームで考えます。個人のスキルやチェックミスを攻めてはいけません。
「三匹のこぶた」を１つのプロダクト開発としたときの失敗事例にして、明日から使える「プロセス改善のヒント」を探っていきます。
あの家、なんで吹き飛んだの？
ポストモーテムをはじめましょう！
ポストモーテムはインシデント対応が終わったあとに行います。言葉の意味の通り「事後検証」という事になります。SRE(信頼性エンジニアリング)で使われる事が多い用語だと思いますが、本記事はアプリケーション・アーキテクチャー中心のポストモーテムを意識して書いています。
開発者だけでポストモーテムを行うと視点が狭くなりがちなので推奨しません。気づいたらアプリケーションの修正方法などの振り返りになってしまったり、プロセス改善の視点とズレがちです。
PdM・QA・サポートや営業などプロダクトを運営しているメンバーを集め、ホワイトボードに書きながらプロセスを振り返りをする雰囲気作りが大切です。ホワイトボードには以下のStepで順序をつけた事柄を書いていきます。
Step1.発生した事象（何が起きたか）
3匹のこぶたの「新居建築プロジェクト」では、3匹のこぶた（開発者）がそれぞれ住居を開発したが、藁の家・木の家はオオカミの攻撃によって破壊され、住居提供が失敗しました。
-
長男の「藁の家」の場合
開発リードタイムは最短だったが、初回の負荷（オオカミの一吹き）で即時崩壊。 -
次男の「木の家」の場合
一度は耐えたが、高負荷に耐えられず破壊。 -
三男の「レンガの家」の場合
開発期間は長かったが、攻撃に耐え、最終的な成功となった。
オオカミの攻撃をシステム負荷・外部脅威・破壊的変更として捉えるなら、
藁・木の家は 非機能要件（性能・耐久性・セキュリティ・変更容易性）の定義・検証不足 により失敗したと言える。
Step2.事象発生までの時系列
| 時系列 | 出来事 |
|---|---|
| 11月2日 | 3兄弟は、母ブタから「早急に住める家を作ってほしい」と依頼を受ける |
| 11月3日 | 3兄弟は、それぞれでどんな家を立てるのか設計をする |
| 11月4日 | 長男は藁で家を“爆速”開発（MVP重視） |
| 11月4〜6日 | 次男は木材を使い、それなりに強度のある家を開発 |
| 11月4〜10日 | 三男はレンガによる堅牢なアーキテクチャを計画・設計・実装 |
| 11月11日 | オオカミ第一次攻撃発生・藁の家が即時崩壊 |
| 11月12日 | 第二次攻撃発生・木の家、部分的に耐えるも最終的に崩壊 |
| 11月13日 | 第三次攻撃発生・レンガの家は耐久性を発揮し、破壊されず |
| 11月14日 | レンガの家も煙突経路の脆弱性が露呈するが、対策（暖炉）で回避 |
| 11月15日 | 全員レンガの家に避難し、事象収束 |
※日付はイメージです。（11月は暖炉いるかな）
Step3.ユーザー視点での影響
障害の影響を書くとき、「サーバーがダウンしました」、「XX機能が使えませんでした」だけでは不十分です。「ユーザーがどう困ったか」を想像するのがポストモーテムの第一歩です。不具合やシステム障害が発生して、ユーザーは何が困ったでしょうか？ 業務知識がある人も、ない人も、ユーザーがシステムを使えない事で発生する不利益を共有していきましょう。
3匹のこぶたの場合
- 生活基盤の喪失
長男（藁の家）・次男（木の家）は「帰る場所」を失いました。これは単に家が壊れただけでなく、安心して眠る権利、明日の仕事への活力、プライバシーのすべてが奪われたことを意味します。 - 恐怖とストレス
「いつ食べられるかわからない」という極限状態での避難は、ユーザーにトラウマを植え付けました。もう二度と藁の家には住みたくないと思うでしょう。サービスを解約したくなります。 - 避難コストの発生
長男（藁の家）・次男（木の家）は、着の身着のままで逃げ出したため、家具や資産は全損。三男（レンガの家）の家に居候するための「肩身の狭さ」や追加の食費など、想定外のコストがかかりました。
[tips] ユーザー視点から、はじめよう
ユーザー視点での振り返りを行うために、ユーザーの影響をみんなで共有することが重要です。これがプロセスを改善して解決すべき状態になります。
Step4. 振り返り
学んだ教訓・うまくいったこと
- 「シフトレフト」が有効だった
三男（レンガの家）は、開発の後半でバグを直すのではなく、最初の設計段階で「オオカミが来るかもしれない（リスク）」を想定し、対策を組み込んでいました。これを「シフトレフト」といいます。他の兄弟より、初期コストはかかりましたが、結果的に一番安上がりでした。 - フェイルオーバー先があった
長男（藁の家）・次男（木の家）は「三男の家」の家に逃げ込めました。もし孤立した環境だったら、寒さで凍えてました。 - とっさの運用対応ができた
オオカミの煙突からの攻撃に対し、防ぐための設備はありませんでしたが、三男が足音を検知し、手動対応（お湯を沸かす）で乗り切りました。（足音は、サーバーのログからの不具合やリスクの発見と言い換えてもよいかと）
うまくいかなかったこと
- 要件定義の甘さ
長男・次男は「オオカミなんて来ないでしょ」と高を括っていました。「早くて安い」を優先しすぎて、非機能要件（安全性・耐久性・変更容易性）を無視してしまいました。 - テスト不足
藁や木の家を建てた後、「ちょっと揺らしてみる」「風を当ててみる」といった負荷テストを一切行いませんでした。ぶっつけ本番でリリースした結果がこれです。(リリースしてみらた動かないとか、、、あるようなないような話） - 潜在的リスクに気づかなかった
シフトレフトで設計したに見えたレンガの家ですが、「煙突」という侵入経路が開けっ放しでした。壁の厚さに安心しすぎて、このリスクに気づきませんでした。
運が良かったところ
ポストモーテムで「運」で助かった部分を明確にした方がいいです。運は再現しない事象だからです。プロセス化した方がいい場合もありますからね。
- オオカミが「一匹ずつ」狙ってくれた
もし同時に攻撃されていたら、逃げる時間がありませんでした。 - レンガの家に「3人入れるスペース」があった
三男がギリギリ1人用の設計にしていたら、キャパシティオーバーで共倒れでした。リソースに少し余裕があったのは幸運でした。 - お湯がたまたま沸いていた
オオカミの侵入が夕食の準備中だったから助かりました。もし深夜で火が消えていたら、侵入を許していました。
Step5. 根本原因分析
なぜ藁や木の家は崩壊し、レンガの家は侵入を許しかけたのか。「なぜなぜ分析」を用いて深掘りします。
良かった所、うまくいかなかった所、運が良かった事を参加メンバーと話し合いができていると、「なぜなぜ分析」の議論もみんなで意見を言って進めやすくなります。
なぜなぜを5回言ってみる
1.あの家、なんで吹き飛んだの？？
- 耐久性の低い素材（藁・木）を使用していたから
2.なんで耐久性の低い素材を使用したの？
- 短期間かつ低コストで建設することを最優先したから
3.なんで短期間・低コストを最優先したの？
- 「オオカミによる攻撃」というリスクシナリオを現実的なものとして評価していなかったから
4.なんでリスク評価が甘かったの？
- プロジェクト開始時の要件定義プロセスにおいて、非機能要件の定義と検証を行う品質計画が存在せず、個人の楽観的な判断に委ねられていたから
5.なんで品質計画が存在しなかったの？
- 組織（3兄弟・母ぶた）として、品質基準とセキュリティポリシーが標準化されていなかったから
これが根本原因とさせてもらおうと思います。少なくとも三男はレンガの家を設計しました。リスクとしては物語の世界では判断されてもいいものと思えます。3匹のこぶたの物語で起きた不幸の根本の問題は、リスクが共有されていなかったというように考えることとします。（諸説あります）
さて、この根本原因を解決すればStep3のユーザー視点での影響は改善しそうでしょうか？
Step6. プロセス改善のアクション
次の同じことをするときに、どのようなプロセスにしますか？
開発プロセスはプログラムコードと同じです。
プロセスを変えない限り、問題は繰り返されます。
改善プロセスを考えます。プロダクトの開発から事象対応の時系列を整理しました。開発プロセスに、今回の根本原因分析の結果を念頭に改善箇所を探します。
11月3日 3兄弟は、それぞれでどんな家を立てるのか設計をする
11月3日のプロセスに改善要素がありそうです。
これまでは、母ぶたの要求を聞いた後に、3兄弟がそれぞれで設計を行っていました。
ここに「リスクや非機能要件を話す時間」を設定します。
プロセスとは再現性がある事を指します。再現性があるというのは実施の仕方が特定のルールに沿っているという事です。そこで、「リスクや非機能要件を話す時間」を仕組み化します。
プレモーテムという仕組みを導入する
このシステムは壊れます。
なぜですか？
これにシステムを作るリーダは答えを持っている状態を作るための仕組みです。
-
プロジェクトが“完全に失敗した”と仮定する
プロジェクトが“失敗した”と仮定します。ここで脳を危険探知モードに切り替える効果があります。チームで“なぜ失敗したのか？”をあらゆる観点から事前に想像し、リスクを洗い出します。チームが見ていない盲点を浮き彫りにするのが目的です。 -
各メンバーが、失敗の理由を書き出す
3匹のこぶたの場合、家が壊れる理由を母ぶた、3兄弟で出し合うだけで大きな効果を期待できそうです。オオカミの脅威以外にも、台風や地震、経年劣化の耐久性の低下などを出し合います。 -
品質計画をつくろう
リスクの重大度 × 発生しやすさ を評価し、優先順位付けを行います。
ここで大切なのは、プロダクトとして「重要」として判断するリスクや非機能要件を優先度をつけることです。
すべてのを満たす事はQCDSのバランスを崩してしまいます。
高優先度リスクに対して “予防策” を設計することができている事がゴールです。
※ LITALICOのQAエンジニアはこれをユーザーストーリーで分析するフレームワークを作っています。
Step7. プロセスが変わった
プロセス改善のアクションを実施しました。
これで、これから作る家はリスクを話し合った状態で家（プロダクト）が作られるでしょう。
開発するこぶたによって、品質がバラバラという状態は防げると思います。
3兄弟は建築家ではないので、そんなにたくさん家は建てないでしょうけどね。
[tips] 変化するQAエンジニアの役割
「3匹のこぶた」プロジェクトにQA（品質保証）エンジニアが参加していれば、結果は違ったものになったでしょうか？ 従来のQA的役割であれば、藁の家が完成した後にテストを行い「強度が足りません」と指摘するだけであり、プロジェクトは手戻りで破綻していたかもしれません。しかし、現代的なQAは「シフトレフト」する事によって要件定義フェーズや要求フェーズで品質リスクを提示する事にあります。つまり、設計段階で長男に対し「この地域にはオオカミがいます。藁ではSLA（Service Level Agreement）を満たせません」と警鐘を鳴らし、要件定義自体を修正させることが求められます。
未来のQAエンジニアはAIがコード生成や定型テストを自動化する中で、人間であるQAエンジニアに求められるのは、オオカミのような「予期せぬ脅威」を想像するクリティカルシンキングと、ビジネスリスクに基づいた品質戦略の立案だと思っています。レンガの家の「煙突」の潜在的リスクを見抜けるのは、AIではなく、文脈（業務知識や、業界の暗黙知）を理解するエンジニアの洞察力が必要なスキルなのだと思います。求められるスキルも要求開発や要件定義にまつわるモデリングのスキルなどが追加されていくと想像しています。
さいごに
ポストモーテムの"改善"はプロセスを変えることです。プロセスを変えないで吹き飛ばない家をつくるとしたらどうなるでしょうか？ 障害報告書などのこれまでの個別最適な対応を行ってしまう場合、藁の家・木の家は吹き飛ばされない改修を行うために、藁の量を増やして重たい家を建築したり、木の家は材質を固くて重たい木材に変えるかもしれません。きっと保守コストが大きく肥大化してしまう問題が新たにでてきそうです。
すぐ吹き飛ばされてもいいけどMVPがすぐ提供できる藁の家がいい場合もあります。ちょうどいいQCDSバランスをつくるプロセスを、話しながらSaaSプロダクトを作っていくのがいいと思います。