受託開発におけるOKR設定で最も大切なこと

OKRを取り入れている業種としてはやはりIT業界が多いのではないでしょうか。ただし、同じIT業界であったとしても、受託会社と事業会社（SaaS等自社プロダクトが強みの会社）とでは、OKRのフィット度が全く異なります。この辺りは以前の記事でも紹介しました。

受託開発企業のOKR設定には工夫が必要

三恵クリエスは受託（ないし準委任）での開発がメインで、現在OKRの運用は３年目です。これまでの経験から、クライアントワークがメインである受託開発会社の場合、OKRを成果（＝組織の成長や利益貢献に繋がるもの）と結びつけるためには少し設定に工夫が必要だということがわかりました。

導入時期、全くうまく機能しなかったOKR設定の反省から、「受託開発におけるOKR設定で最も大切なこと」をお伝えしたいと思います。

結論：日常のクライアント業務と紐づける

最初に結論から。
受託開発会社でOKRを設定する最大のポイントは「日常の業務中に実践できるものを設定する」ということ。
当たり前のように聞こえるかもしれませんが、意外と「日常業務と切り離したOKR設定」はあるあるだと感じています。

例えば。以前の三恵クリエスではエンジニアチームで以下のようなKRがよく立てられていました。

KR：1on1含むOKRイベント実施率　100% 
KR：ナレッジをCriiita（社内ナレッジサイト）に5件投稿する
KR：持ち回り週次勉強会の実施率　100%

OKRを導入したばかりの企業であれば、まず全社的に「OKRの運用率、理解度をあげる」というOKRが立てられることが容易に想像できますし、ぱっと見、あまり問題なさそうです。

ですが、結果としてこれらの指標は失敗となりました。なぜ・・？

日常業務vsOKRという「見え方」

上記OKRの何が問題だったのか？
それは、日常業務を進める「以外」のKRを立ててしまうことで、日常業務とOKRとの間に「別物」感が生まれてしまい、「日常業務vsOKR」という構造（見え方）を作り上げてしまったことでした。

受託開発である以上、もっとも望まれていることは「顧客のプロジェクトの成功」であるにもかかわらず、
「社内のナレッジを書くことを優先してしまう」
「勉強会の準備に追われて、開発ピークにもかかわらず疲弊してしまう」
「PJを優先していてOKRを放置していることに負債感を感じる」
など、目線が社内向けになりすぎてしまい、結果「OKR＝+αの負荷を負っている」という状態が出来上がってしまいました。

「現実」の重力の強さを自覚する

「現実」は「理想」と違い、ものすごく強い「重力」を持っています。
受託開発企業では、日々エンジニアは目の前の「現実」に意識を強く持っていかれます。
お客様先で働いている、一緒にスクラム開発を進めているなど、顧客に近い環境であればあるほど、ものすごく強い重力に無意識的に引っ張られてしまいます。

会社としても上記で紹介したKRのように、プロジェクトで学んだナレッジを社内の情報資産として貯めてもらうのは歓迎すべきことです。ですが
「ナレッジは10件投稿できましたが、プロジェクトは失敗しました！」
となっては正直会社として評価ができません。

また、このような「達成したけど評価されない」OKRは、メンバーのモチベーションを下げてしまい、OKRとしての効力を全く発揮できていません。
そのため、原則的には日常業務と紐付けることを重要視し、もし日常業務と切り離したOKRを設定する場合は相当な「やりたい」という熱量とマネージャーからの承認を必須とすべきです。

現在の開発部門OKRの方向性

OKR設定失敗の根本的な原因の１つは「しっかりOKRのレビューができていなかった」ことです。
組織における目標設定スキルが底上げされるまでは、ちゃんと会社の求める成果に繋がっているか？のレビュー、そのOKRを承認する責任はやはり経営陣やマネージャー陣が担うべきです。

現在はチームで立てるOKRは利益責任をもつマネージャーが８割がた決めることにしており、大体以下のような方向性になっています。

■「プロジェクトの成功」を第一に掲げ、その詳細をKRにする
・案件XXXの成功
　- 納期観点
　- 必須案件の完了、質
　- 開発起因のバグ件数（商用バグ０件は必須）

・ベロシティの改善率​
　- 生産性指標​
　- 想定消化ポイントの消化率（スプリントごとの消化数）
etc・・・

その他、新規参画者が多いチームであれば、その新規参画者のオンボーディングや立ち上げ時期の生産性を指標に入れたり、
そのプロジェクトで初めて取り組む言語やツールに絡めた実績作りの指標が入ることもあります。
どれも、日常業務とかなり紐付きが強いです。

そして、設定したOKRをチームメンバーと共有する際には
プロジェクトごとに改めて

①このプロジェクトのミッションは何か？（社外観点、社内観点）
②顧客が最も願っている我々への最低限の期待（日常業務）は何か
③②の期待を達成、担保した上で、次に我々が狙うステップは何か？
④全てのステップが達成されたらどのような状態が期待できるのか？それが全社OKRとどのように繋がっているか

これらのシナリオストーリーをリーダーがチームに説明します。

これらのステップを踏み、日常業務とOKRを密接につなげ、目の前の業務に完全にフォーカスすることで「いつの間にかOKRの進捗が上がっている」という状態を作り出すことが可能です。

受託開発組織にとっての価値、成長、成功は「顧客の成功」があってこそ。まず目の前のお客様に最高の価値提供ができることが会社の求めている「成果」であることをOKR設定の前提にしましょう。

組織にとっての「成果」の目線が揃ってくる

その組織にとっての「成果」とは、組織がいま置かれている状況によって変化していきますが、根本的に「利益」「成長」につながる成果にそこまで大きな変化はありません。
OKR設定を繰り返し繰り返し行なっていくことで経営陣⇄リーダー間だけでなく、メンバー一人一人の「成果とは何か」の意識、目線が合っていきます。

現在、三恵クリエスでは経営陣とマネージャー陣がOKRを決める「ミドルトップダウン」方式設定がメインになっていますが、この目線がよりあってきたらボトムアップに切り替えていくことも十分に可能だと感じています。

これもOKRを継続するからこそ少しずつ見えてくる組織の成長です。
焦らず、一歩ずつ着実に組織の変革を進めていきたいと思います。

---
三恵クリエスでは簡単にOKR導入をサポートしてくれるOKR管理ツール『Commita（コミッタ）』を開発しています！
少しでもご興味をお持ちになりましたらぜひお問い合わせください。

サービスサイト、β版申し込みはこちら↓

OKR管理ツール commita（コミッタ）｜簡単に始められるOKR管理ツール

サービスに興味のある方お問い合わせください！↓

お問い合わせフォーム