# モノづくりをするシステムエンジニアに対して全社の数値を意識したOKRの設定とは By [Y's note](https://paragraph.com/@y-s-note) · 2022-07-12 --- ### はじめに [@yutakikuchi\_](https://twitter.com/yutakikuchi_)です。 OKRの導入は様々な企業で行われているかと思うのですが、会社のOKR、事業部のOKR、個人OKRなど、ブレークダウンしていったときに、個人のOKRがその上の事業部・全社のOKRに直接ひも付きを持つことが難しいという場面に遭遇するかと思います。特Sales・Businessの方々のOKR設定より、ものづくりをするシステムエンジニアの方々などの設定が難しさを生むと思います。**ここではその難しいという課題に対して、具体的な解決方法を提示するよりも、問題提起とそれに対して解決方法の候補を提示する**というものになります。 ### 前提として **システムエンジニアの方にも売上数値など上位の定量的なKRに対して意識を向けたい**という思いで書いています。理由はそのように意識付けをしないと、会社全体の組織の意識がバラバラになる可能性が高いためです。ここではその意識付けをOKRを用いて行う場合の課題や解決策について書いたものです。よってOKR以外での実現方法や、そもそも上位の定量的なKRに対してシステムエンジニアの意識を持つ必要が無い、間接的な要素が強いOKRを持てば良いというケースは考えずに記載をしています。 また組織内の研究会開発部門など、個人のKRの成果がそのままプロダクトの売上に繋がりやすいなどOKRを設定しやすいケースとそうではないケースが存在し、ここでは**そうではないケースに対して焦点を当てています。** ### 難しさの理由 会社→事業部→チーム→個人とブレークダウンをしていったときに、会社・事業部の\*\*定量的なKR(具体的には売上の数値目標など)\*\*を、ものづくりのシステムエンジニアが個人のOKRと紐付けをするが難しく、下記はその理由の考察として書きます。 * 要件定義や設計フェーズなど、スケジュールが不透明なタイミングで具体的な上位の数値への紐付け、または顧客データなどが不十分で満足なプロジェクトが実施できないタイミングでのOKR設定は**外的要因によるズレの影響が大きく、設定がしづらい(外的要因)** * 実際の開発作業に入る前のプロセスについては、ビジネス側の貢献要素も大きいため、フェーズ的に精緻なOKRを設定することが難しい * AIのプロジェクトなど、顧客側が十分なデータなどが用意できず、その中で精度を出さなければならないような場合、個人OKR達成のための前提条件が揃わず、不利に働く * システムエンジニアの**個人OKRの設定と人事評価を密に連携してしまいがち**で、**設定する側の心理的な不安要素が大きい。よってシステムエンジニアからは設定を嫌がられる。**(心理的要因) * 本来のOKRの思想からすると、Objectiveはチャレンジ目標であり、達成されないことがあったとしてもマイナス評価をすべきではないが、一方で何を元にシステムエンジニアを評価すべきかが組織的に分からない * バグフィックスやシステムの緊急メンテンナンスなど、OKRの設定時には考慮できなかった不足の事態への対応が日々の活動で数多くあり、OKRを重視しすぎるとそれらの活動が組織として軽視されがちになる * システムエンジニアの日常のコミットを定量的に上位のOKRに**何を紐付けすべきかが不明確になる(項目設定要因)** * ロールとしてシステムエンジニアが売上を直接作るわけではないので、あくまでも**上位OKRへの紐付けが間接的な貢献の設定**になってしまいがち * リリース日に対して遅延なくユーザーに対して機能を提供できたか、または構築したシステムの処理パフォーマンスなど、**システム開発をする自社側の行動に紐づく結果**に対して紐付けすべきか * ユーザーからのフィードバック、NPSやPMF Survey、更には継続率など点数や数字で評価できる指標、など**導入企業側のユーザーからのプロダクト評価に紐づく結果**を改善数値として紐付けを行うべきか これらの理由により難しさが発生することとして、その根幹にはシステムエンジニアの方々にもなるべく売上貢献などに直接的な意識を持たせるために、個人OKRを設定すべきかどうか。この**OKRに対する考え方や方針の不一致**により、上層部とメンバー間で摩擦が起きてしまい、OKR設定のタイミングで思うように進まないなどの課題が出てくるのかと思っています。 ### 上記課題仮説に対するOKR設定での解決方法案 感覚的な話になりますが、過去にマネジメントしてきた組織の中では、**2番目の心理的要因によりOKR設定がうまく行かないというケースが多いと感じています。** * 外部要因に対して * 実施中に外部要因要素が大きく、達成できない期中でOKRの設定の見直しをメンバーとマネージャー間で実施する * そもそものOKR設定項目として、短期的なObjectiveよりも長期的なObjectiveを重視し、外部要因による影響を最小化される目標を持つなどの工夫もある * 心理的要因に対して * \*\*OKRの達成だけでその人のコミットパフォーマンスを評価しない。\*\*またこの方針を会社全体へ評価の仕組みとして共有できていること。OKRは達成されることよりも、まずは高い目標を目指すことを優先とした仕組みであることを理解する。 * OKRの設定のタイミングでマネージャーとメンバーでよく対話をすることが重要。Key Resultをメンバー自身で考えることも、事業への貢献やユーザーに対して価値を提供することを意味するので、 **メンバー自身の意志を込めることも尊重**。また組織のマネージャーが会社のKRの数値面を意識して、システムエンジニアのメンバーに対して常日頃から期待役回りを伝えておく。 * OKR以外でも、普段のコミットをできる限り可視化数値化できる内容を個人評価に組み込む * 項目設定要因に対して * 個人のOKRの設定の前に事業部単位のKRに対して、KPIツリーと合わせて分解して、その項目をどのように個人Objectiveと紐付けるかを事前に検討する。そうすると、KPIの5,6階層目ぐらいの具体的な要素を個人に紐付けるなどが可能になる * KPIツリーを利用すると、ユーザーからの評価という観点が入ってこないため、個人KRの一つとしてユーザーからのフィードバックである**PMF Survey、NPS、継続率などを定量数値として目標値や改善値を必ず入れる**。システムパフォーマンスなど、自社側の行動に紐づくものより、その実行がユーザー評価にどう紐づくかを考える。そうすると自然と全社のユーザーの導入につながるKRとなる これらを実施する上で重要なこととしては、最終的に個人のOKRを設定するメンバーを見るマネージャーが会社の数値状況も理解しつつ、その方の言葉としてメンバーに対しての期待を伝え、常にOKR達成の進捗を見て方向性がずれていないかなどを適切に指摘してあげることになります。またOKRの達成の全てを個人の業績評価としないことも重要なので、マネージャーが個人評価を行う際にはOKR以外の普段のコミットにも目を向け、定性・定量面で評価することも必要です。(もちろん、マネージャーはかなり広い責任範囲を求められるので、非常に大変ですが) ### この記事をまとめると * システムエンジニアであっても全社OKRの具体的な数字に対して、事業部を挟んだ上でも、個人OKRに対して紐付けを持つべき。そのためには下記を実施すると良さそう。 * OKRは設定し、その高い目標を目指すことが重要なので、KRをKPIツリーと合わせて設計し、5,6階層目の深い要素をシステムエンジニア個人のKRと紐付けを行う。 * OKRの達成全てで個人評価をしない。普段のコミットも定性・定量面で評価を行う。またOKRへの考え方や方針を全社に共有しておく。 * 個人のKRにはシステムに対して外部からの定量評価項目も必ず入れる。 ### 参考URL [https://www.kaonavi.jp/dictionary/okr/](https://www.kaonavi.jp/dictionary/okr/) [https://aki-m.hatenadiary.com/entry/2021/11/12/000100](https://aki-m.hatenadiary.com/entry/2021/11/12/000100) --- *Originally published on [Y's note](https://paragraph.com/@y-s-note/okr)*