好ましくない事実から根本原因を抽出しJob Storyを作るプロセス
仕事でチームやチームの管理するシステムの根源的な問題を効率的に抽出する必要があった。カネビン・フレームワークやJobs To Be Doneフレームワークなど、既存の複数のフレームワークを組み合わせて独自プロセスを試したら割と手応えがあったので共有する。
きっかけ
私が所属しているチームではFeature(新規機能追加)、Support(既存コードベースの問題に対する対応)、Project(長期目線でのシステム修正)という３つの種類のタスクがある。 組織体制が変更され、今一度Projectをやっていく上でのチームやチームのシステムに対する問題の洗い出しをする必要が生じた。この際以下を必要とした:
- 問題の網羅
- 問題の掘り下げ
マネージャのマネージャからは「問題が明確であれば解決策は自ずと明確になるので問題に注力しろ」との言葉をもらい、最終的な形としてできるだけ解決策が明確に想像できるように意識しようと考えた。またチーム内で問題のインパクトの大きさについて議論されるケースが少ないと自分は感じていたため、問題とそれに対するインパクトを明確にしたいと考えた。
最終形
友人や同僚と相談しつつ最終的に以下の形でチームの問題を抽出した。
- 好ましくない事実の列挙
- カネビン・フレームワークを用い単純系・困難系・複雑系・カオス系に分類する
- 困難系の事実に対して"なぜ"を繰り返し根本原因を抽出する
- 根本原因を分類する
- Jobs To Be Doneフレームワークと某社で採用されているフレームワークを用い、Issue (Job story)、Loss 、Problemsの表を作る
1. 好ましくない事実の列挙
問題と解決策はいくつか頭の中で思い浮かぶが思い込みなどで間違っていないようにするため、事実からスタートするようにした。 例えば以下は弊チームの好ましくない事実の抜粋である:
- リソースが足りない
- ユーザーから問い合わせがない限りシステムの問題に気づかない
- システムに問題が生じた時に根本原因を探すのが難しい
- 古いシステムのスクリプトを直すのが難しい
- システムに関するドメイン知識を取得するのが難しい
この際認識の齟齬がないよう複数人によるレビューをして共通認識であることを確認した。
2. カネビン・フレームワークを用い単純系・困難系・複雑系・カオス系に分類する
1.で事実を列挙したが、解決策が自明な問題より解決策がわからないような事実を深掘りしたい。 カネビン・フレームワークの存在があることを先輩から教えていただいた。
カネビン・フレームワークによると問題は以下の４つのカテゴリに分類することができる:
- 単純系...誰でも簡単に解決できる
- 困難系...専門家の知識が必要。不具合原因追及型の問題解決を使います。題が起きるのか、なぜなぜ問答を繰り返し、追究すると真の問題が見つかる。
- 複雑系...原因が明確にわからない問題。人や組織に起こりがちな問題。仮説検証が必要。
- カオス系...突発的に発生して、すぐに何らかの対応をする必要がある問題
これを利用し事実のうち困難系にフォーカスし問題を深掘りしていく。 1.の事実の場合以下のような分類になった。
- 単純系... "リソースが足りない"
- 困難系..."ユーザーから問い合わせがない限りシステムの問題に気づかない"、"システムに問題が生じた時に根本原因を探すのが難しい"、"古いシステムのスクリプトを直すが難しい"
- 複雑系..."システムに関するドメイン知識を取得するのが難しい"
"システムに関するドメイン知識を取得するのが難しい"については単純に学習機会を増やせば良いと単純系に分類していたが、マネージャと相談した結果複雑系に分類した。これはある程度取り組んでいるにもかかわらずチームとして知識共有が十分にできていないためこのようになった。
3. 困難系の事実に対して"なぜ"を繰り返し根本原因を抽出する
カネビン・フレームワークでの困難系での解決策でも触れられているようになぜなぜ問答を繰り返すことで真の問題を探る。自身に専門知識がない場合は専門家にインタビューを行った。 2.で困難系に分類された事実"ユーザーから問い合わせがない限りシステムの問題に気づかない"は以下のようななぜなぜ問答を繰り返すことができる。
このように事実からなぜなぜ問答を繰り返すことによって問題の細部に気づくことができる。この場合アラートシステムに改善点がありそうなのと、エラーの取り扱いに対して改善点がありそうだ。
4. 根本原因を分類する
困難系に分類された事実からなぜなぜ問答を繰り返すとかなりの量の"なぜ"が溜まっていく。この"なぜ"をカテゴリに分類することによって頻出する根本原因を抽出する。 自分が取り組んだ際にはObservability, Process, System complexityと３つの大分類ができた。さらに各大分類をサブカテゴリに分類した。 例えばObservabilityについては以下のようなサブカテゴリが出現した。
- エラー詳細がない
- データが壊れた時のアラートシステムが存在しない
- そもそも問題が発生した時のインパクトがわからない
5. Jobs To Be Doneフレームワークと某社で採用されているフレームワークを用い、Issue (Job story)、Loss 、Problemsの表を作る
4.で分類した根本原因をJobs To Be Doneフレームワークを用いて表現する。
具体的には When _____ , I want to _____ , so I can _____ .で表現する。これにより対象ユーザーの欲求に対応した解決策を考えることができるようになる。
またこれに加え某社で使われている問題と解決策定義のフレームワークの一部を用いる。これは問題を以下のような形で定義する
- Issue...課題
- Loss...Issueにより被る損失を書く。
- Problems...Issueを引き起こしている様々な問題を書く。
Lossを書くことにより課題のインパクトを明確にできる。
上記を踏まえて表を作ると、Observability "エラー詳細がない"という分類に対しては以下のように書ける
| Issue (Job Story) | Loss | Problems |
|---|---|---|
| 私がSupportチケットに取り掛かる際エラー詳細が知りたいです、そうすることにより早く根本原因を見つけ修正できます(When I work on a support issue, I want to know the detail of the error, so I can detect the root cause faster and fix it earlier) | 1人の問題調査専任エンジニア工数、早いレスポンスタイム | 問題の重要度がエラータイプからわからない,そもそもエラーが曖昧だ, etc... |
これにより最終的に根本原因一覧とそのインパクト(Loss)が明確になる。 英語でJob Storyをかくとしっくりくるのだが、日本語で書くとちょっと変になるかもしれない。その場合はCookpadの価値仮説シートが参考になると自分は思う。 以下URLに価値仮説シートの言及あり。 logmi.jp
やってみた感想
"5. Jobs To Be Doneフレームワークと某社で採用されているフレームワークを用い、Issue (Job story)、Loss 、Problemsの表を作る"の時点である程度解決策が想像できる課題にまでなっていることが多かったのが良かった。
また表を作成する際Lossをうまく書けないIssueが出てきた。メトリクスが不十分な場合が明確になる点が良かった。ただエンジニアの生産性のように、数値化が難しいLossに対してはどのように取り組むべきかまだわかっていない。
自分のチームではこれまで問題が発生した際にProjectを作成し対応してきたがこのような棚卸しはしていなかった。 棚卸しをすることにより以下の良い点を感じた:
- 特に"1. 好ましくない事実の列挙"、"2. カネビン・フレームワークを用い単純系・困難系・複雑系・カオス系に分類する"、"3. 困難系の事実に対して"なぜ"を繰り返し根本原因を抽出する"をすることにより議論と共通認識の醸成ができたこと
- チームとして解決策に注意が行きすぎるので問題とそのインパクトについてちゃんと議論する時間が取れたこと
おわりに
今後作成した表を元にMVPを作成し問題を検証しつつ最終的に本番環境に解決策を反映していくことになると思うが、また知見が溜まった際には共有できればと思う。
