Why I want to rename OKRs to OACs - Allan Kellyという記事を読みました。
NotebookLMの要約は以下です。
著者は、OKR（目標と主要な結果）の名称をOAC（成果と受け入れ基準）に変更することを提唱しています。この変更の主な理由は、より焦点を当てるべきである成果という用語の使用が増加していることと、主要な結果という用語のあいまいさです。著者は、主要な結果を、成果が達成された際に確認できる測定可能な影響、すなわち受け入れ基準と再定義しています。この変更は、テストファースト管理の原則を強調し、アジャイル思考との関連性を強化することを意図していますが、OKRの名称はすでに広く認知されているため、名称変更の実現は困難であるとも認めています。
今は違いますが、過去しばらくOKRで目標や業務の進捗を管理していたこともあります。個人的にはOKR自体はわりと良いと思っているほうなのですが、一方で色々と難しさもあったなと記事を読みながら思い返しました。
- Objectiveに紐づかない業務をしている人としては組織貢献してる感が薄まる
- KeyResultをうまく書き出せない
- 「やらなければならないこと」ベースで書き出してOKRのフォーマットに合わせた感じになる
などなど。
このうちのいくつかは、今回読んだ記事がアイディアとして出しているような、OAC＝Outcomes and Acceptance Criteriaという言い方に変えることで解消するかもしれないと感じています。
とくに、記事後半に出てくる
This rename has two more benefits. Because this interpretation highlights test first management it continues the test first story which began with automated test first unit tests (TDD, Test Driven Development). Then Acceptance Test Driven Development (ATDD) into Behaviour Driven Development (BDD).
のところは考え方として面白いなと思います。まさに受け入れ基準として扱えると、いろいろな部分で整合性がとれそうです。
一方、なにか開発業務をやるというのではなく「組織横断で改善や仕組み化をする」とか「組織で技術推進をする」といった形の業務をやっていると、スクラムもOKRもビミョウになじまないところが出てくるのが悩みでした。 OACとして考える際にもおそらく似た壁にぶつかる気がするので、そのあたりうまい方法があれば自分も整理してみたいところです。
元記事の筆者自身が「まだアイディアレベルで途中」といった書き方をしているので、皆がそれぞれ考えてみると面白いかもしれません。（と思って雑な感想記事にしました。）