キーポイント
- Corporate agile is an improvement for many companies but it falls to deliver on the original promise of agile which excited some many practitioners.
- Objectives and key results pre-date agile but share several characteristics and are a good fit
- OKRs can be used to restore some of the radical nature of agile by decentralizing decision making and promoting team autonomy.
- However OKRs can also be misapplied to reintroduce command-and-control from above.
- Used sympathetically OKRs can restore purpose to agile teams and free them from the tyranny of the backlog.
遠い昔、10年ほど前でしょうか。企業を訪問したり、あるいはカンファレンスで講演したりすると、決まって"アジャイルを試したいが、マネージャが理解してくれない、やらせてくれない"、と嘆く開発者に出会ったものでした。当時の開発者は、アジャイルをやりたい、と思っていました。アジャイルは新しい大胆な働き方の代名詞であって、正しくないと思われる多くの問題を解決してくれる、と考えられていたのです。
現在でもアジャイルを"正しく"行いたい、という開発者に出会うことはありますが、チームをアジャイルにしたいと望んでいるマネージャに、"私のチームがアジャイルをやりたがらない"、と相談されることの方がはるかに多くなりました。アジャイルがもたらす楽しさ、興奮、希望というものが、どこかに失われてしまったのです。
一方で、変化する環境においても、仕事を楽しみ、協力して働くことの興奮を体感しているチームもあります。
アジャイルが広く普及するにつれて、存在感が希薄になり、多くの面において、その魅力の大部分が失われてしまいました。チームには"とにかく実行する"ことが期待され、バックログやストーリは会話やネゴシエーションの出発点ではなくなりました。バックログに至っては、"いつ終わるのか"、という抑圧の道具になり果てています。
私はしばらく前から、この二極化の問題に取り組んできました。"Extreme Programming Explained"(邦題:エクストリーム・プログラミング)を出版の数週間後に読み、その素晴らしさを伝道した身として、開発者から"アジャイルは管理手法だ"、あるいは"アジャイルはマイクロマネジメントだ"、という声を聞くのは、率直に言って心が痛みます。私が心酔して、提唱してきたアジャイルは、こんなものではありません。
私は昨年、この2つの形式を"マイルドアジャイル"と"ラジカル(radical)アジャイル"と呼ぶようにしました。しかしその後、"マイルド"ではなく"企業(corporate)"ではないか、と思うようになってきました。アジャイルを流行として取り入れた企業にとって、アジャイルのこの変貌は望ましいものだったからです。
先駆者として、10年以上の長きにわたって、マネージャの理解できることばでアジャイルを説明しようと試みてきた私たちにとって、これは皮肉な話です。私たちの試みは成功し、マネージャの理解を得られたのですが、その過程でアジャイルは骨抜きにされ、ラジカルな部分を失ってしまいました。
"企業アジャイル"は私が夢見たアジャイルではないかも知れませんが、それでも以前よりはよくなった部分は少なくありません。旧来型の銀行のような大企業において、スクラムやSAFeが公式に採用されたことは、それ以前の状態に比べれば大幅に改善されている、と言えるでしょう。
さらに、"ラジカル"が望ましいものであるとは限りません。ラジカルはリスクを暗に含んでいて、良識のある企業は不必要なリスクは取らないものなのです。問題なのは、リスクが取り除かれた結果、アジャイルが希薄化され、その興奮が失われたことです — 例えるならば、300フィートのループ付きローラーコースタを、幼児向けのメリーゴーランドに取り換えたようなものです。
アジャイルテクニックの大部分を非ラジカルなものにすれば、残ったものは、アジャイルが始まった頃とあまり変わっていません — しかも、大して面白くもないものばかりです。
ひとりでペアプログラミング?それはただのプログラミングです。
自動化の困難な部分は省いた上に、一日一回しか実行しない自動化ユニットテスト?1992年頃ならば、それも許されるでしょう!
企業内のすべてのチームについて、1日を等しく1ポイントとするストーリポイント見積もり?それでは、普通の見積と同じです。
アナリストがユーザストーリを書き、プログラマが実装し、テスタがテストする — 言葉によるコミュニケーションなしで?ウォーターフォールそのものです。
アジャイルのラジカルな部分を削ぎ落とせば、アジャイルを支えるフィードバックループや学習プロセスも削ぎ落とすことになります。同じように、アジャイルの大規模化は標準化へとつながり、さまざまなバリエーションや学習を生み出す実験を阻害します。
なぜこうなったのか、誰の責任なのか、ということを論ずることも可能ですが、それは生産的な議論ではありません。要因はたくさんありますが、なぜこうなったのかを理解するのは、ストーリの半分に過ぎないのです。必要なのは、ラジカルな考え方を改めて取り入れ、フィードバックループと学習の機会を作り出して、チームによる実験を可能にすることなのです。
数え切れないほど多くの"アジャイル 2.0"が提案されていますが、アジャイルの世界は、当初よりもはるかに大きく、はるかにコマーシャルなものになっています(この意味を知りたければ、"アジャイル2.0"で検索してください)。初期の頃は、先駆者たちはお互いに顔見知りで、情報を共有していました — Snowbirdを覚えていますか? XPとスクラムは、友好的なライバル関係にありました。今日では何千人ものアジャイルエキスパート、何十人もの有名人、無数のコンサルタントがいて、皆が私たちの関心を引こうと躍起になっています。
OKRについて OKR(Objectives and Key Results)は、元々はIntelのものでしたが、Googleが使用したことによって多くの注目を集めるようになりました。ここ数年で、スタートアップやアジャイルサークルの間で一般的になった用語です。 "Objective"は組織やチームが目指す大きな目標であり、"Key Result"というのは、その大目標を達成するための小さな目標であったり、あるいは達成する必要のある目標であったりします。OKRは通常、3か月単位でリセットされます。目標(Objective)が特別に大きかったり、内容が多いものである場合には、次の四半期に持ち越されることもありますが、過去の内容はきれいに拭き去って最初から始める方が一般的です。 例えば、 Objective: オンラインストアを12月1日に開く Key Result #1: 少なくとも12品目のカタログをオンラインでブラウズして、買い物かごに品物を追加できる Key Result #2: 少なくともひとつの大手クレジットカード支払いを使って、安全にチェックアウトできる Key Result #3: 12月1日以前に、少なくとも10人のターゲットカスタマがストアを使用して商品を購入し、自身のエクスペリエンスをフィードバックする アジャイル用語で言えば、"Objective"はエピック(epic)、"Key Result"はストーリあるいは受け入れ基準(acceptance criteria)になるかも知れませんが、OKRのエクスペリエンスを見れば、これらが完全に同じものではないことが分かります。Objectiveは、実際にはスプリントの目標に近いのです。 |
あり得ないソリューション
このような状況の中で、数年前、私はOKR — ObjectiveとKey Resulに出会いました。OKRのことは何年も前から知ってはいましたが、それほど興味を持ってはいませんでした。最初の印象は、経営学の第一人者であるPeter Drucker氏が最初は提唱し、後に撤回した"MBO(Management by Objectives)"にかなり近い、というものでした。
それにも増して気に入らなかったのは、OKRが数値目標を設定する方法でした。このようなアプローチがうまくいかない例は、枚挙にいとまがありません。そのため、"目標の転移(goal displacement)"というような名称や、さらにはそれに対する警告である"Goodhartの法則"というものもあるほどです。
それでも私は、実験精神に従って、いくつかのチームでOKRを使ってみました。そして驚きました — 極めて効果的である上に、極めて反アジャイル的な方法で使用される可能性のある一方で、アジャイルを強化することも可能なのです。
例えばOKRは、チームにとって新たな作業のソースを作り出します。チームは極めて早い段階で、OKRと自分たちのバックログとの関係を決定しなくてはなりません。どちらを優先すればよいのでしょう?
最も成果を上げたアプローチは、OKR、つまりチームが望むことを優先する、というものです。自らのバックログは捨てて、"ジャストインタイム要件"アプローチを採用するのです。"お金と時間以上の仕事をする"ことを失敗の兆候として見るのはやめて、成功の兆候だと捉えるのです。
作業を計画する必要があるたびに、OKRに立ち返って、次のように自問するのです — "OKRに近づくために、今ある時間で何ができるだろうか?"
バックログでバーンダウンすることを心配せず、目標を第一に置いて、チームの存在理由を思い出し、"今、ここで、どうすれば価値を創造できるか"を問うのです。
マネージャが設定したOKRが社内の階層を降りて、チームがそれぞれの小さな部分を与えられるという、従来的なMBOスタイルを期待するかも知れませんが、それにはGosplan的な計画部門が必要であると同時に、チームの自律性と本来の意思決定力を奪うことになります。(Gosplanというのは、ソ連で5か年計画を担当していた部門です。その結果がどうなったのかは、皆さんよくご存じでしょう。)
そうではなく、リーダがリードすべきです。リーダには、大局を見る必要があります。組織の目的とミッションを強調し、組織全体の大きな目標を設定するべきです。しかし、その目標がチーム固有のものであってはなりません。
その上でリーダは、チームにこう言うのです — "私たちの目指す場所はこれで、その理由はこれです。チームのために、あなたには何ができますか?"
その上でチームは、自分たちのOKRを設定します。チームが組織目標に対してどのように貢献できるかを決めるのは、チーム自身がベストなのです。それぞれのチームにはユニークな人材による専門的スキルのミックスがあり、それらが一緒になってプロダクトの開発やサービスの提供をしています。チームは離れ小島ではないので、自分たちのOKRを設定するには、他の人々 — 特に顧客 — の要望や価値に耳を傾けなくてはなりません。
分散的意思決定
私たちのオンラインストアのCEOが、カナダ市場へ進出するという組織的目標を設定したとしましょう。これまでのやり方ならば、プランナがプランを描き、何が必要かを判断し、小目標を設定してそれを組織全体に落としていくはずです。プランを実現するために、既存のチームを分解して、新たなチームを構成することになるかも知れません。
これに対して、ボトムアップの考えでは、CEOの掲げる目標は、組織内のチームに対するひとつの課題です。決済チームは、カナダドルを処理するために必要な決済システムが必要であることをすぐに理解して、それを実現するための目標を設定するでしょう。
不正対策チームも同じように、システムの何を変更しなければならないか、自分たちが実施しなければならないのは何か、といったことを検討し始めるはずです。どちらも決済システムの強化が必要であると結論付けたとすれば、両チームは連携する必要があります。おそらくは、お互いを満足させるための"Key Result"を取り入れることになるでしょう。
その過程の中で、外部のスタッフや専門家のスキルが必要になるかも知れません。その場合も、プランナが必要なスキルや要員を決定して、それらのリソースをチームに押し付けるのではなく、チームが自律的に、組織の内外から必要に応じて引き込むのです。
一元化されたプランナが何が必要かを決めるのではなく、組織の自律的な部分が対応方法や他との調整について決定する必要があるでしょう。個々のチーム — 特にプロダクトオーナ — は、顧客やステークホルダ、経営層にメリットを提供する機会について理解した上で、何をするのかを決めることになります。
期限が理不尽なものであったり、あるいは遠い未来であったりすれば、メンバのモチベーションを引き出すことはできない、ということを、私たちは苦い経験から知っています。スプリントがリードタイムを改善し、小さな作業では機能することは分かっています。しかしこれには、大きな目標 — 木を見て森を見ず — や目的を見失う、というマイナス面があるのです。
OKRは、3か月単位のビューをチームに提供することで、この問題に対処できます。3か月というのは、ある意味で絶妙な時間枠です — ある程度の目標を持つ上で短過ぎるということもなく、終わりがずっと先というほど長くもないからです。
次の四半期の最終目標に向けて前進するために、リーダから与えられた課題に対して、チームが広範かつ発展的に考えることが可能になります。あらゆる意見を聞いて、選択肢を検討することもできますし、チーム自身の — チームが設定した — 目標に沿ってOKRとして抽出されれば、チームを越えてそれを共有し、議論することが可能になるのです。
OKRは、チームの意思を集中するための強力なツールですが、さらに重要なのは、コミュニケーションツールとしての役割でしょう。OKRを抽象化インターフェースとして考えるのです。
OKRは他の人たち — 具体的にはリーダ — に対して、チームに何が期待できるか、より大きな目標に対してどのように貢献するか、を告げるものです。チームとリーダは、インターフェースを中心として取り決めを行い、その結果を広く共有することができます。
そして、そのインターフェースの背後で、チームはそれを実現する責任を担うのです。実現方法は、リーダに対してブラックボックスでも構いません。チームが自律性を持って、目標に向かう方法を自らオーガナイズするのです。
アジャイルの復権?
OKRは今、アジャイルの生殺与奪の権を握っています。OKRはテストファーストマネジメントの一形態を表現しています。アジャイルの精神(ethos)を持って用いることにより、チームへの権限移譲を促進し、作業を実施するチームと権限を持つチームとの間のコミュニケーションを改善することで、好循環を生み出すことが可能になります。
その一方で、思慮を欠いたOKRの使用は、チームの作業負荷を増やし、トップダウン管理を蘇らせて、巨大なターゲットゲームを生み出す危険性をはらんでいます。最悪の場合には、アジャイルそのものの正当性を奪う可能性もあるのです。
最後に、私自身も販売するプロダクトを持っていますし、OKRとアジャイルの組み合わせに関する本(Succeeding with OKRs in Agile)を書いていますので、今回の記事は利益誘導と思われるかも知れません。それでも記事を書いたのは、アジャイルのラジカルな性格をもう一度蘇らせて、私を含む初期の関係者が感じた情熱を呼び戻すことができるのではないか、と考えたからです。
同じことを実現するツールは他にもあるかも知れません — ワクチンはいくつもあった方がよいですから!現時点ではOKRが頭一つ抜きんでていて、広く採用されるようになっていると思います。
これはおそらく、OKRがその起源をMBOに辿ることができること、著名なコンサルタントが認めていること、などが理由だと思われます。いずれにしてもOKRには、アジャイルが長く失っていた正当性があります。しかも、スクラムのように、マネジメントフレンドリという薄板の背後にあるのは、開発者の日常を大きく改善する力を持ったツールなのです。
"Succeeding with OKR's in Agile"のメッセージを要約したこのインフォグラフィックは、Yoan Thirion氏の手によるものです。
インフォグラフィック作成: Yoan Thirion
著者について
Allan Kellyは、仕事の整理と要求の方法を改善することで、ソフトウェアのプロが仕事を通じて、より多くの充足感と満足感を感じられるようにするための指導をしています。社員の幸福感が高まって、仕事の方法が改善されれば、企業はより効果的になり、価値はより高まり、競争上の優位性が生み出されます。氏のアドバイス、コーチング、トレーニング、執筆といった活動は、ソフトウェア開発で直面する課題に対する氏の幅広い経験に裏打ちされたものです。最新の著作は"Succeeding with OKRs in Agile"です。