過去の障害対応記録からプロセスの改善に繋げる

はじめに

皆さんこんにちは。Linc'wellでバックエンド基盤チームを担当している山本です。普段はRuby on Railsで作られたサービスに関わるバックエンド全般の業務改善活動を行っています。
私達のチームの役割として、患者や医療従事者が利用するサービスを開発するプロダクト開発チームへの提言・啓発があります。
今回のエピソードは過去の障害対応記録を分析しプロセスの改善につなげたお話です。

弊社の「障害対応記録」とは

開発部では発生したサービスの障害に対して 障害対応記録 というドキュメントをまとめています。このドキュメントは障害の一次対応後に作成され、障害に関する時系列に発生した事象や影響範囲などが記録されています。
そして、その情報を元に振り返り会を実施し恒久対応に繋げています。
この障害対応のフローは有効に機能しており、各チーム工夫を凝らした恒久対応案を打ち出し改善活動に活かされています。

私のモチベーション

上記の通り個々の障害に対しては各チーム適切な振り返りは行われている認識です。しかし私が所属する「技術基盤チーム」という プロダクト開発 とはやや離れた活動を行うチームなら、俯瞰した視点でサービスの品質改善活動に関わることができると思い分析を始めてみました。

世の中に存在する障害の分析手法

分析する！と決意はしましたが、この分野についてシロートな私は、世の中に存在する障害の分析手法を調査してみました。

統計的分析

過去の障害内容を記録し、障害内容ごとに成長曲線的なグラフを作成する手法です。プロジェクトの時系列に沿った障害の傾向を把握することはできますが、具体的な改善提案につなげにくい印象があります。

▲統計的分析の例
時間とともにバグの発生は収束していく。

根本原因分析（RCA）

いわゆる「なぜなぜ分析」です。例として以下のように「なぜ？」を繰り返しながら障害を分析します。たとえばこんな感じです。

• なぜシステムが停止したのか？➡️サーバーに負荷が集中したから
• なぜサーバーに負荷が集中したのか？➡️特定の時間にアクセスが集中したから
• なぜ特定の時間にアクセスが集中したのか？➡️キャンペーンを開始したから
• なぜキャンペーンを開始したらアクセスが集中したのか？➡️事前に負荷テストをしなかったから

弊社の開発部の障害振り返りではどちらかと言うとRCA的なアプローチで分析することが主流ですが、深堀りしだすときりがないのである程度の深さで止まってしまうことが多い印象です。
その結果、発生した障害単体にフォーカスする改善しかできないのが問題点だと感じています。

ODC分析のエッセンスを取り入れる

統計的分析は開発発注者などに対外的に報告するためには必要な分析です。
一方RCAは部内で一定の効果を上げているが、限られた時間内に実施する場合スコープが限定されてしまう問題を抱えています。
この問題を解決するためODC分析のエッセンスを取り入れることを検討しました。
ODC分析とはソフトウェアの欠陥を定量的に分析するための手法です。単に欠陥の数だけを数えるのではなく、欠陥の属性に着目して分類し、その分布や傾向を分析することで、開発プロセスやテストプロセスにおける問題点を明らかにすることを目的としています。

弊社に当てはめると「障害が発生したプロセス」を軸にすると障害の原因が入り込むプロセスが見えてくるような気がしてきました。

障害発生プロセス

請負開発で広く使われているウォータフォール開発では「設計」「単体テスト」「結合テスト」などのプロセスがきっちり決まっています。しかしスクラム開発においては上記を小さい単位で回しながら、プロダクトアウトプットを最大化する点に注力します。そして、障害が 発見・記録 されるのは本番フェーズに入ってからとなります。

これでは「障害が発生したプロセス」が必ず「本番」となってしまいます。

そこで私は、社内の開発プロセスを4つに抽出し「障害のタイプ」に紐づける形で 本来どのプロセスで発見するべきだったのか という観点で対応表を作りました。

1. 要件定義
   PdMの要求定義に従い、エンジニアが実装するための要件定義を行うプロセスを意味します。
2. 開発と単体テスト
   エンジニアが考える要件定義に従い、コーディングを行うプロセスです。ここにはRSpecなどによるテストコードや開発環境上の単体テストも含みます。
3. 結合
   本番リリース前に各プロダクトチームが開発したものをステージング環境に反映し、動作検証を行います。これを結合プロセスとしました。
4. 本番
   本番環境へのデプロイから実際にユーザーが使うシーンを想定したプロセスを設定しました。

このプロセスに紐づくよう、障害のタイプを以下のように設定しました。

1. 要件定義	2. 開発と単体テスト	3. 結合	4. 本番
要件定義	コーディングミス	スキーマ不具合	デプロイ
	ライブラリ	影響範囲	設定
		ソースコード管理	外部要因

分析結果

2024年の半年間で発生した大小合わせて計82件の障害を分析したところ以下のような結果となりました。

もっとも多かった障害タイプは「要件定義」で、次は「影響範囲」「コーディングミス」と続きます。
つまり、全体的には要件定義プロセスと結合プロセスに多くの問題を抱えていることとなります。

また、障害に紐づけたプロダクト開発チーム別にチームごとの傾向分析も行いました。

▲あるチームの分析結果。赤がもっとも多い障害タイプとなる。

分析結果後のアクション

今回の分析をやってみてプロダクト開発チーム別に改善が必要なプロセスが見えてきたことが大きかったです。今回の分析を受けて障害対応記録にプロセスの分析を盛り込むことで、各プロダクト開発チームに開発プロセス別の取り組みを考えてもらう機会ができたと思います。
また、技術基盤グループとしてもどのようなプロセスでプロダクト開発チームと強いコラボレーションを取る必要があるのか、認識できました。

個々の障害にさまざま観点を追加し、クロスして分析することで今まで見えなかった領域が見えてくることもあります。
これを読んでいるみなさんも、ぜひ俯瞰した視点で障害の分析を行ってみることをオススメします！