GLOBIS Advent Calendar 2024 20日目の記事です。
グロービスでスクラムマスター、テックリードなどをしている@tom_bo_meganeといいます。
昨年は普段の仕事のふりかえりについて書きました。
今回はシステム障害のふりかえり方法「ウォークスルー」を紹介します。
プログラムレビューを行う方法としてよく聞く言葉ですが、作業プロセスをチェックする方法としても有効です。ひな型画像も載せたので、参考にしていただければ。
システム障害の分類
システム障害は内的要因と外的要因に分類されます。
- 内的要因:プログラムバグ、オペレーションミス、設定不備など
- 外的要因:自然災害、利用者環境など
システム開発・運用を担当するチームが、改善を行って防止したり減少したりできるのが内的要因になります。そのためふりかえりも内的要因のケースを取り扱って行うことが多いかと思います。
内的要因の代表的なケースを挙げます。
- プログラムバグ
- 開発したプログラムにバグが混入し、リリース後にシステム障害を伴ったケース
- 例:金額処理の仕様相違によるバグで誤った金額が計算される
- オペレーションミス
- 本番環境へのリリース作業やメンテナンス作業などで、操作ミスや想定外事象によりシステム障害になったケース
- 例:本番環境のリリース作業で操作手順を行ったが、成否判断が行わなかったためエラー発生に気づかなかった
- 設定不備
- 本番動作に関係する設定内容の不備によりシステム障害になったケース
- 例:開発環境の設定内容を含んだ設定ファイルを本番環境に反映してしまい一部の機能が動かなくなった
では、「プログラムバグのケース」、「オペレーションミスと設定不備のケース」について、ウォークスルーを活用したふりかえり方法に入っていきましょう。
プログラムバグのケース
プログラムのバグが減らない、そもそも開発のすすめ方のどこに品質低下の原因があるかを探す例です。
プログラム開発の作業プロセスでよく使われるV字モデルがあります。ウォーターフォールやスクラム、内製や外注など、開発スタイルに合わせてチューニングしやすいので、僕はV字モデルをふりかえりのひな型として使っています。
やり方
品質低下の原因探しをする場合、V字モデルが対象に役割分担されているか、各工程のインプットとアウトプットに矛盾はないかなどを観点に、作業プロセスをふりかえりの場で確認していきます。普段の開発のすすめ方を確認していくと、サンプルのシートのようになります。
あえてサンプルとしてわかりやすくしていることもありますが、以下のような矛盾に気づきます。
- 記憶を頼りにテストケースを作成している
- テストされる側のプログラムをもとにテストケースを作成している
単体テストのインプットを見直すため、手書きの写真でもよいので仕様検討したもの詳細設計として残すようになりました。
オペレーションミスと設定不備のケース
本番環境への作業はすべて本番リリース作業と同等を原則として、「準備・リハーサル・本番実施」の工程のすすめ方の確認をします。運用されているシステムの開発時期や稼働状況に合わせられるように、以下のパターンごとに皮切り質問をひな型として用意しています。
- CI/CDのように自動化されている
- 手動実行であるが、ツール化されている
- すべて手動操作を行っている
やり方
文末のひな型で載せたシートを見ながら読みすすめていただけるとわかりやすいかと思います。関係者で上記3パターンのうち、当てはまるものについて「準備・リハーサル・本番実施」ごとの皮切り質問に回答します。そこから実際に使用した手順書やスクリプトなどを共有しながら、状況を確認していきます。
これまでのふりかえりを思い返すと、以下のような改善ポイントがみつかってきます。
- リハーサルが行われていなかった
- 手動操作だがダブルチェックで行っていなかった
- 手順書はあるが、成否確認と確認内容が書かれていなかった
- 手順書が担当者単位で作成されて、内容がバラバラだった
- 手動ツールの仕様を知らずに利用していた
システム運用を行っていると、ある程度のプラクティスやベースとなる考え方は心得ているかと思います。でもミスは、忙しい中でも対応しないとという責任感から起こってきます。そのためふりかえりで尋問や詰問のような雰囲気にならないように、皮切り質問を書くようにしました。作業プロセスを客観的に確認していく上で効果があると感じています。
ひな型
ここまで紹介したケースで使っているひな型です。大前提は、「客観的に作業プロセスを確認して、システム障害原因のポイントを探すウォークスルーを行うこと」です。犯人探しや責任の押し付けあいはご法度です。
次の1歩となる改善に役立てていただければ幸いです。