Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜

 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜

## 技術

SRE, ポストモーテム, DevOps, SECIモデル, メンタルモデル, ダイアローグ, SLI, SLO

More Decks by レバレジーズTechアカウント

Other Decks in Technology

Transcript

  1. | © Leverages inc. 2 • ポストモーテムは学びの場 • メンタルモデルを意識した振り返り • 発生対策と流出対策

    この発表を通して伝えたいこと✉ ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  2. | © Leverages inc. 3 • 前半(学び編) ◦ ポストモーテムとその周辺の知識 ◦ ポストモーテム実施のコツ

    • 後半(実践編) ◦ 組織のより良いポストモーテムを目指してやったこと ▪ 弊社での実際の取り組みを知りたい方は後編をご覧ください 󰡇 本資料の構成⚙ ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  3. 小堺 拓実 • 所属 ◦ レバテック開発部 基盤システムグループ • 出身 ◦

    東京の下町 • 趣味 ◦ 任天堂 • 最近のトピック ◦ 第一子の子育てを楽しんでいます ◦ 右の画像は多いと週に3回は食べるTMCカ レーです。美味しいよ。 自己紹介
  4. | © Leverages inc. 13 • 再発防止策が思いつかない • 観点と対策がズレている • ドキュメントを埋めることだけ考えている

    なぜ、うまくいかないのか?🤔 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  5. | © Leverages inc. 14 • 再発防止策が思いつかない ◦ 知識を増やす ◦ 人に聞く・AIに聞く・ネットで調べる(大抵の問題は解決されている)

    ◦ インシデントを深く振り返る • 観点と対策がズレている ◦ 観点を学ぶ ◦ 対策の勘所を磨く • ドキュメントを埋めることだけ考えている ◦ ポストモーテムの目的・心構えを知る なぜ、うまくいかないのか?🤔 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  6. | © Leverages inc. 15 • 再発防止策が思いつかない ◦ 知識を増やす ◦ 人に聞く・AIに聞く・ネットで調べる(大抵の問題は解決されている)

    ◦ インシデントを深く振り返る • 観点と対策がズレている ◦ 観点を学ぶ ◦ 対策の勘所を磨く • ドキュメントを埋めることだけ考えている ◦ 👉ポストモーテムの目的・心構えを知る なぜ、うまくいかないのか?🤔 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  7. | © Leverages inc. 50 • 理想は、24時間以内にポストモーテムを実施すること • なぜか? ◦ インシデント発生から時間が経てば経つほど、記憶は薄れ、詳細が失われる。

    ▪ これによって、学びが薄れ、良い改善に繋がらなくなる。 ◦ 失敗の背景にある感情やエネルギーを活用する為 心構え其の三 熱いうちに叩く
  8. | © Leverages inc. 51 • 理想は、24時間以内にポストモーテムを実施すること • なぜか? ◦ インシデント発生から時間が経てば経つほど、記憶は薄れ、詳細が失われる。

    ▪ これによって、学びが薄れ、良い改善に繋がらなくなる。 ◦ 失敗の背景にある感情やエネルギーを活用する為 ▪ 例:交通事故にニアミス 心構え其の三 熱いうちに叩く
  9. | © Leverages inc. 52 • 理想は、24時間以内にポストモーテムを実施すること • なぜか? ◦ インシデント発生から時間が経てば経つほど、記憶は薄れ、詳細が失われる。

    ▪ これによって、学びが薄れ、良い改善に繋がらなくなる。 ◦ 失敗の背景にある感情やエネルギーを活用する為 ▪ 例:交通事故にニアミス • その後しばらくは気をつける 心構え其の三 熱いうちに叩く
  10. | © Leverages inc. 53 • 理想は、24時間以内にポストモーテムを実施すること • なぜか? ◦ インシデント発生から時間が経てば経つほど、記憶は薄れ、詳細が失われる。

    ▪ これによって、学びが薄れ、良い改善に繋がらなくなる。 ◦ 失敗の背景にある感情やエネルギーを活用する為 ▪ 例:交通事故にニアミス • その後しばらくは気をつける • いつしか、信号待ち中に携帯を見るようになっている 心構え其の三 熱いうちに叩く
  11. | © Leverages inc. 54 • 理想は、24時間以内にポストモーテムを実施すること • なぜか? ◦ インシデント発生から時間が経てば経つほど、記憶は薄れ、詳細が失われる。

    ▪ これによって、学びが薄れ、良い改善に繋がらなくなる。 ◦ 失敗の背景にある感情やエネルギーを活用する為 ▪ 例:交通事故にニアミス • その後しばらくは気をつける • いつしか、信号待ち中に携帯を見るようになっている ▪ モチベーションが高いうちにやろう 心構え其の三 熱いうちに叩く
  12. | © Leverages inc. 55 • 理想は、24時間以内にポストモーテムを実施すること • なぜか? ◦ インシデント発生から時間が経てば経つほど、記憶は薄れ、詳細が失われる。

    ▪ これによって、学びが薄れ、良い改善に繋がらなくなる。 ◦ 失敗の背景にある感情やエネルギーを活用する為 ▪ 例:交通事故にニアミス • その後しばらくは気をつける • いつしか、信号待ち中に携帯を見るようになっている ▪ モチベーションが高いうちにやろう 心構え其の三 熱いうちに叩く 熱いうちに叩く!
  13. | © Leverages inc. 58 • 学ぼうとする精神 • 批判をしない • 熱いうちに叩く

    • 根性論は禁止 心構えまとめ 🍀 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  14. | © Leverages inc. 59 • 再発防止策が思いつかない ◦ 知識を増やす ◦ 人に聞く・AIに聞く・ネットで調べる(大抵の問題は解決されている)

    ◦ インシデントを深く振り返る • 観点と対策がズレている ◦ 観点を学ぶ ◦ 対策の勘所を磨く • ドキュメントを埋めることだけ考えている ◦ 👉ポストモーテムの目的・心構えを知る ✅ なぜ、うまくいかないのか?🤔 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  15. | © Leverages inc. 60 • 再発防止策が思いつかない ◦ 知識を増やす ◦ 人に聞く・AIに聞く・ネットで調べる(大抵の問題は解決されている)

    ◦ 👉インシデントを深く振り返る • 観点と対策がズレている ◦ 観点を学ぶ ◦ 対策の勘所を磨く • ドキュメントを埋めることだけ考えている ◦ ポストモーテムの目的・心構えを知る ✅ なぜ、うまくいかないのか?🤔 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  16. | © Leverages inc. 83 • バッチの存在を知らなくて、、 • NULL許容になっていると思わなくて、、 • ALB使ってたんですね、、

    • などなど。。 とあるインシデントにて2 🏢🏢 メンタルモデルを知る これらは全て、暗黙知の可能性があります
  17. | © Leverages inc. 87 • ドキュメント化 ◦ アラート対応手順書 ▪ アラート内容にリンクを含めるとさらに効率

    UP ◦ システム構成図・インフラ構成図 ▪ Githubで管理するのがおすすめ ▪ sudoモデリング図でさらに理解が深まる 暗黙知を形式知に ✍ メンタルモデルを知る
  18. | © Leverages inc. 88 • ドキュメント化 ◦ アラート対応手順書 ▪ アラート内容にリンクを含めるとさらに効率

    UP ◦ システム構成図・インフラ構成図 ▪ Githubで管理するのがおすすめ ▪ sudoモデリング図でさらに理解が深まる ◦ テスト仕様書・テスト観点 ▪ コスト検討しながらテスト自動化 暗黙知を形式知に ✍ メンタルモデルを知る
  19. | © Leverages inc. 89 • ドキュメント化 ◦ アラート対応手順書 ▪ アラート内容にリンクを含めるとさらに効率

    UP ◦ システム構成図・インフラ構成図 ▪ Githubで管理するのがおすすめ ▪ sudoモデリング図でさらに理解が深まる ◦ テスト仕様書・テスト観点 ▪ コスト検討しながらテスト自動化 ◦ ポストモーテム ▪ ポストモーテム読書会・発表会 ▪ チーム外の人が読んでもわかるような内容にすることがポイント • チームや領域特有のワードに解説を入れるなど 暗黙知を形式知に ✍ メンタルモデルを知る
  20. | © Leverages inc. 90 • ドキュメント化 ◦ アラート対応手順書 ▪ アラート内容にリンクを含めるとさらに効率

    UP ◦ システム構成図・インフラ構成図 ▪ Githubで管理するのがおすすめ ▪ sudoモデリング図でさらに理解が深まる ◦ テスト仕様書・テスト観点 ▪ コスト検討しながらテスト自動化 ◦ ポストモーテム ▪ ポストモーテム読書会・発表会 ▪ チーム外の人が読んでもわかるような内容にすることがポイント • チームや領域特有のワードに解説を入れるなど 暗黙知を形式知に ✍ メンタルモデルを知る オンボーディングにも使える!✌
  21. | © Leverages inc. 96 • 一緒にやる ◦ 調査・設計・実装 ▪ ペアプロ

    ▪ モブプロ ▪ これだけで一人の知識ではなくなる 暗黙知を形式知に 󰠗 メンタルモデルを知る
  22. | © Leverages inc. 97 • 一緒にやる ◦ 調査・設計・実装 ▪ ペアプロ

    ▪ モブプロ ▪ これだけで一人の知識ではなくなる ◦ 障害対応 ▪ ベテランの指示を受けながら、新米が作業する ▪ 最優先で対応しないと!と言ってベテランがずっとやってると後続が育たない • スピードは成長とトレードオフ 暗黙知を形式知に 󰠗 メンタルモデルを知る
  23. | © Leverages inc. 101 • タイムラインに必要な情報 ◦ どのようなアクションやイベントがあったのか ◦ 誰がそれを行ったのか

    ◦ それが行われた時刻はいつか 前提:ポストモーテムのタイムラインとは ⏰ メンタルモデルを知る
  24. | © Leverages inc. 104 • 質問の例 ◦ なぜそれが正しい行動だと感じたのか ◦ システムで何が起こっているかについて、なぜそのように解釈したのか

    ◦ 他の行動を検討したか、検討した場合、なぜそれを排除したのか タイムラインを見て、行動の背景にある動機を質問する 󰢧 メンタルモデルを知る
  25. | © Leverages inc. 105 • 質問の例 ◦ なぜそれが正しい行動だと感じたのか ◦ システムで何が起こっているかについて、なぜそのように解釈したのか

    ◦ 他の行動を検討したか、検討した場合、なぜそれを排除したのか ◦ 誰か他の人がそのアクションをとる場合、あなたがその時に持っていた知識をその人はどのよう に得るか タイムラインを見て、行動の背景にある動機を質問する 󰢧 メンタルモデルを知る
  26. | © Leverages inc. 110 • 再発防止策が思いつかない ◦ 知識を増やす ◦ 人に聞く・AIに聞く・ネットで調べる(大抵の問題は解決されている)

    ◦ 👉インシデントを深く振り返る ✅ • 観点と対策がズレている ◦ 観点を学ぶ ◦ 対策の勘所を磨く • ドキュメントを埋めることだけ考えている ◦ ポストモーテムの目的・心構えを知る ✅ なぜ、うまくいかないのか?🤔 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  27. | © Leverages inc. 111 • 再発防止策が思いつかない ◦ 知識を増やす ◦ 人に聞く・AIに聞く・ネットで調べる(大抵の問題は解決されている)

    ◦ インシデントを深く振り返る ✅ • 観点と対策がズレている ◦ 👉観点を学ぶ ◦ 👉対策の勘所を磨く • ドキュメントを埋めることだけ考えている ◦ ポストモーテムの目的・心構えを知る ✅ なぜ、うまくいかないのか?🤔 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  28. | © Leverages inc. 125 • ありがちな再発防止 ◦ 〇〇を徹底する ◦ ちょっと待ってほしい

    ▪ 徹底できていなかったから障害が発生したってこと?であれば、なぜ徹底出来なかったのか、その状況を改善するにはどうすれば良いかまで考 察しないと! ▪ 例 • 実は、人によってタスクの作り方に差があって、テストのタスクが漏れてしまったんですよね。当時リリース前で急いでいたのもあって、 誰も気づけませんでした。 • なるほど、じゃあ、タスクをテンプレート化して、人による差異が出ないようにしよう。 • でも、テンプレートを使うのを忘れてしまうかも。 • いや、普通にタスクを作るよりもテンプレを使う方が楽であれば、忘れることはないと思うよ。人は楽な方に流れるから。 • テストを実施していたとしても、観点によっては防げなかったかも。 • なるほど、じゃあテスト観点書が必要かな。 • そもそも、そのテストって自動化出来ないかな? ▪ このように、再発防止策は様々なレベルとコストが存在します。 ▪ これらをどこまでやるかに正解はないので、考えなければなりません。 ◦ 安易なプロセスの追加 ▪ もう一つありがちな話。 ▪ 今回の事態を繰り返さないように、〇〇さんに必ずレビューと承認を得るようにフローを変えよう。 • パターナリスト症候群と呼ばれる • ある行動の実行や承認に必要な資格や信頼性を持つのは特定の人物やグループであるという考えに基づいている。 • 短期的には妥当かもしれないが、すぐに生産性の低下を招く。 • なので、同時にその状態を解消する為の行動をする(自動化も考える) 再発防止 4つの観点のポイント
  29. | © Leverages inc. 127 • ありがちな早期検出 ◦ アラートにすぐ気づいたので OK! ▪

    ちょっと待ってほしい ▪ アラートとはシステムがエラーを発したタイミングである。しかし、実際のところアラート発報の前に「システムはエラー が発生するかもしれない状態」になっている。 ▪ この状態を、アラート前に検出する方法を考えないと! 早期検出 4つの観点のポイント
  30. | © Leverages inc. 128 • 結構早く対応できたと思うなあ ◦ ちょっと待ってほしい。その対応、少しでも早く改善できたかも ◦ 例えば

    ▪ アラートの内容はわかりやすいものだった? ▪ 調査するのに欲しい情報はログにあった?見やすい状態になっていた? ▪ 一人じゃなくて、複数人で対応に当たっていたらもっと早く解決できたかも? 早期復旧 4つの観点のポイント
  31. | © Leverages inc. 129 • 再発防止策が思いつかない ◦ 知識を増やす ◦ 人に聞く・AIに聞く・ネットで調べる(大抵の問題は解決されている)

    ◦ インシデントを深く振り返る ✅ • 観点と対策がズレている ◦ 👉観点を学ぶ ✅ ◦ 👉対策の勘所を磨く ✅ • ドキュメントを埋めることだけ考えている ◦ ポストモーテムの目的・心構えを知る ✅ なぜ、うまくいかないのか?🤔 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  32. | © Leverages inc. 130 • 再発防止策が思いつかない ◦ 👉知識を増やす => 本を読みましょう😉

    ◦ 人に聞く・AIに聞く・ネットで調べる(大抵の問題は解決されている) ◦ インシデントを深く振り返る ✅ • 観点と対策がズレている ◦ 観点を学ぶ ✅ ◦ 対策の勘所を磨く ✅ • ドキュメントを埋めることだけ考えている ◦ ポストモーテムの目的・心構えを知る ✅ なぜ、うまくいかないのか?🤔 ポストモーテムは学びの場!〜組織のより良いポストモーテムを目指してやったこと〜
  33. | © Leverages inc. 147 • 影響度に含まれる要素 ◦ 影響を与えたユーザーの数 ◦ 解決するのにかかった時間

    ◦ 金銭的損失 ◦ 不整合データの数 ◦ など 障害の数値化🤖 改善策を実行する
  34. | © Leverages inc. 148 • 影響度に含まれる要素 ◦ 影響を与えたユーザーの数 ◦ 解決するのにかかった時間

    ◦ 金銭的損失 ◦ 不整合データの数 ◦ など • 頻度 ◦ 過去同じような事象があった ◦ 将来同じような事象が起こりうる 障害の数値化🤖 改善策を実行する
  35. | © Leverages inc. 149 • 影響度に含まれる要素 ◦ 影響を与えたユーザーの数 ◦ 解決するのにかかった時間

    ◦ 金銭的損失 ◦ 不整合データの数 ◦ など • 頻度 ◦ 過去同じような事象があった ◦ 将来同じような事象が起こりうる • これらの要素を数値化して ◦ 数値が大きいものから順に対応する ◦ 一定の数値を超えたものだけ対応する 障害の数値化🤖 改善策を実行する
  36. | © Leverages inc. 165 • ノートラブルシステムへの道 • システム運用アンチパターン • Google

    SRE Books • ダイアローグ 価値を生み出す組織に変わる対話の技術 • エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング • こうしてふりかえりは終わってしまった もっと深く知りたい方への参考文献📖 効果的な情報共有
  37. | © Leverages inc. 168 • 開発部の規模 ◦ 50人くらい ◦ 17チームくらい

    • ポストモーテムを実施する文化はあった • ポストモーテム用のテンプレートもあった 前提📝 実践編
  38. | © Leverages inc. 169 • ポストモーテムは実施されていたが、どのように実施すれば良いかはわからずふんわりとした理解で やっていた。 • チームによってポストモーテムの質にばらつきがあった •

    一部の人が障害レポートを見てフィードバックするも、あまり改善が見られない状態が続いた。 ◦ 障害レポートのレビューにもあまり時間が取れていなかった 課題感🗻 実践編
  39. | © Leverages inc. 171 • ポストモーテム向上委員会発足 • ポストモーテムの推進 &啓蒙 •

    ポストモーテムテンプレートテコ入れ • 障害対応Slackワークフロー作成 • ポストモーテム実施目安作成 • ポストモーテムのあれこれを社内発表 やったこと💪 実践編
  40. | © Leverages inc. 172 • 一番最初にやりました • 思いつきで初めてもブレるし、「そういう取り組みをしている」ことを組 織に知ってもらいたかった •

    指標を決めて計測したかった(改善といえば計測) • 委員会と言いつつ、最初は自分一人 ポストモーテム向上委員会発足🏯 やったこと
  41. | © Leverages inc. 174 • 委員会の発足を周知して各チームのポストモーテムに招待を促しつつ、自分からも参加希望を出すよう にしました • 参加した際は、進行することもあれば意見や疑問を投げかけるだけのことも。 ◦

    チームの経験値によって使い分ける感じ ◦ チーム独自のやり方をするところもあるので、あまり進め方に固執せずに任せる • 参加できなかったポストモーテムは、レポートを見てフィードバック ポストモーテムの推進&啓蒙🏋 やったこと
  42. | © Leverages inc. 177 • レバテック開発部だけではなく、レバレジー ズ全体の開発部で使われているテンプ レートを変更 • それぞれの記入項目に考え方のヒントを入

    れたりしています • とはいえ見ない人も結構いると思われるの で、大きな効果は期待していません • ちなみにDocbaseです テンプレートのテコ入れ🔨 やったこと
  43. | © Leverages inc. 178 • 今までの活動と少し毛色が違って、障害発 生時とポストモーテム含むその後の対応を 改善する取り組みです • 元々障害発生時の対応はタスク管理ツー

    ルのasanaで行われていたのですが、少し 複雑でやることがわかりづらい問題があり ました ◦ 各所のポストモーテムに参加するこ とでこの問題が見えてきました 障害対応Slackワークフロー作成 やったこと
  44. | © Leverages inc. 179 • そんな時ちょうど弊社の SREで障害対応 Slackワークフローを作る動きがあったので 便乗しました •

    ワークフローの内容は 10Xさんの事例や GMOペパボさんの事例を参考にさせても らいました ◦ Botの方が色々出来るけど、一旦は 手軽なワークフローに。 障害対応Slackワークフロー作成 やったこと
  45. | © Leverages inc. 180 • 心理的ハードルを乗り越えて報告してくれ たことにまず感謝を伝えるようにしています • また、絵文字を使ってかっちりしすぎないよ うにしてます

    ◦ 障害報告時は心の余裕がないの で、少しでも和らげたかった 障害対応Slackワークフローを作る ときに考えたこと やったこと
  46. | © Leverages inc. 181 • 活動を続ける中で、障害の度に毎回ポストモーテムを実施するのはしんどい。。というような声も聞こえ てきました • 元々ポストモーテムの実施は必須ではなかったのですが、わかりやすい基準が無かったからか、いつの 間にか必須であるような認識が広がっていました

    • これによってポストモーテムの印象が悪くなってしまうことは避けたかったので、コスパの良いポストモー テムが実施できるよう目安を設けました ◦ 割と緩めに設定したので、「基準」ではなく「目安」としています ポストモーテム実施目安作成👀 やったこと
  47. | © Leverages inc. 182 • 活動を続ける中で、障害の度に毎回ポストモーテムを実施するのはしんどい。。というような声も聞こえ てきました • 元々ポストモーテムの実施は必須ではなかったのですが、わかりやすい基準が無かったからか、いつの 間にか必須であるような認識が広がっていました

    • これによってポストモーテムの印象が悪くなってしまうことは避けたかったので、コスパの良いポストモー テムが実施できるよう目安を設けました ◦ 割と緩めに設定したので、「基準」ではなく「目安」としています 実際の目安がこちら やったこと
  48. | © Leverages inc. 183 • 他社事例をいくつか参考にしました • あくまでもポストモーテムを実施するかどうかはチームに一任しているので、目安は厳しめにしているつ もりです •

    ちゃんとやるならSLI/SLOを設定した方が良いと考えますが、それには時間がかかるのでパッと作りまし た 目安を作るときに考えたこと💭 やったこと
  49. | © Leverages inc. 185 • 障害レポート自動化 ◦ Docbaseのテンプレートから手動で作っている状態 ◦ 障害対応ワークフローから一部の自動作成を行いたい

    ▪ Docbaseが連携弱い • 障害分析 ◦ Docbaseでは入力内容を構造化して集計、分析が出来ない ◦ 社内生産性可視化ツールBoostでfour keysとして一部は集計可能 • 障害対応管理 ◦ asanaで管理しているが、障害発生時にたくさんあるタスクを見て理解してぽちぽちやる余裕がない ◦ 障害発生したその日中に対応必要なものはワークフローに寄せて、それ以降の事後対応はasanaで管理するよう分 割したい • 恒久対応管理 ◦ 期限切れのタスクが多い状態 ◦ どこまで管理するか? ◦ まだ手をつけられていない • SLO/SLI設定 ◦ SREの方で進められている。 ◦ 今後、より説得力を持って進めるには必要になってくると思う 色々やったけど、課題はまだたくさんある😇 やったこと
  50. | © Leverages inc. 186 • 👍 ◦ 各チームのポストモーテムに積極的に参加していったのは良かった ▪ 言うだけでは伝わらないものがある。一緒にやってナンボ

    ▪ 普段あまり関わりのないチームのことを知るきっかけにもなった ◦ あまり時間をかけずにワークフローや実施目安を作れたのが良かった ▪ 「早く行くなら一人で行け、遠くに行くならみんなで行け」私の好きな言葉です • 👎 ◦ 最初にみんなが楽になる施策をやった方がよかった ▪ イネイブリングするときは「仕事が減る」ことからやると感動される。刺さる 振り返ってみてどうだったか🚩 やったこと
  51. | © Leverages inc. 188 • 活動開始前(6月) ◦ 障害レポート数:22 • 活動開始後(7月)

    ◦ 障害レポート数:16 • 活動開始後(8月) ◦ 障害レポート数:17 ポストモーテム向上委員会の効果(抜粋)🤖 定量評価
  52. | © Leverages inc. 191 • 社内のポストモーテム改善の為、様々な取り組みを行いました! • 定性的には効果を感じているけど、定量的にはまだまだ分析が足りない • 何かを啓蒙・推進するときのポイント

    ◦ まずは「やって見せる」「一緒にやる」 ◦ 何かやってほしいことがあるなら、仕事を増やすだけではなく 「仕事を減らす」 まとめ📌 組織のより良いポストモーテムを目指してやったこと