Resilyは企業向けOKRツールを提供しているスタートアップですが、自社の開発組織にもOKRを取り入れています。「どのようにOKRを運用しているのか？」「スクラム開発とどのように混ぜ合わせているのか」などの疑問について、CTOの西方とリードエンジニアの石川に話を伺いました。

スクラム開発にOKRを加えるメリットとは？

ーー本日はCTOの西方さんとチームリーダーの石川さんにResilyの開発組織について伺います。Resilyではスクラム体制にOKRを紐付けて運用されていると聞きました。開発組織にとってOKRを取り入れることのメリット、具体的な方法について教えてください。

西方聖一（以下、西方）：よろしくお願いします。質問の通り、Resilyでは社としてOKR（Objectives and Key Results）に取り組んでいますし、開発組織に関してはOKRと合わせてスクラム開発も導入しています。この背景として、スクラム開発を進めていく上で重要な「開発の優先順位」を判断する上でOKRがかなり有効だと考えているからです。

私自身、スクラム開発をしていく中で"陥りがちな罠"を数多く見てきました。その1つが目の前のスプリントを回す事に必死になってしまい、優先順位の判断が鈍ってしまうことです。スクラムを用いて開発する場合には大体スプリントを1〜2週間で実施しているところが多いのかなと思います。その中で作り手の気持ちとしては、当然良いものを早く届けたい気持ちが先行します。また、会社やプロダクトの状況によってはスプリントが乱れてしまう場合もあります。その結果、「限られた時間の中でアウトプットを出し続けなければならない」といったマインドに陥りやすい。「なんとか期間内にアウトプットを出さなければ」といった焦りに引きずられてしまい、最悪の結果として、本質から外れた機能を開発してしまうことも少なくありません。

また、目の前のスプリントに追われ続けていると組織内でも開発中に「何を目指しているんだっけ？」「だからプロダクトバックログリファインメントはこうしなきゃいけないんだっけ？」「この開発は本当にやるべきなんだっけ？」といった会話が生まれ、途中で立ち止まってしまうこともよく経験しました。例えばインセプションデッキを作って共通認識持つ事も有効だと思います。しかし、インセプションデッキを作るとしても会社やステークホルダーがこのサービスをどういう風にしていきたいのか、何をゴールにして成長させていきたいのか。という大前段の目標を掲げ伝えていくことも重要ですが、実際のところ欠けがちな部分だと思います。

開発の意思決定者であるPO（Product Owner）以外の開発メンバーもプロダクトの存在意義、開発する機能の背景や開発の優先順位について、文脈も含めて情報が伝わるようにしておくべきだと考えます。
エンジニアも背景がわからない機能をつくりたくないはずです。自分にとって「この優先順位でいいんだっけ」と疑問が出てきた段階で、目の前のタスクに対する意欲がどんどん削がれていると思うんですよ。これは意図的に開発の意識を変えなければ抜け出せない悪循環だと思っています。

スクラムは素晴らしいフレームワークだと思います。そして、そのスクラムを最大限活用出来るための補助輪としてOKRが非常に有効だと考えています。OKRは「会社や自分たちはこういうことを目指しているんだよね」「この人はこういう風に成長しようとしているんだよね。だからこそこういうタスクを渡してあげるべきではないか」といった事業や開発組織の成長に必要な会話を生むきっかけになります。OKRそのものに機能的な効果があるわけではなく、OKRを導入することで失いがちな視点を探しにいくきっかけづくりになる。そこに最も価値を感じています。

OKRをベースにSB、PB、スクラムイベントを組んでいき、POだけでなく開発メンバーも開発の意思決定に関われるように。

※参考：https://speakerdeck.com/resily/resily-enziniacai-yong-zi-liao?slide=47

石川 尚洋（以下、石川）：開発組織におけるOKRの運用方法として、Resilyではバックログリファイメント時にOKRをベースにPBL（プロダクトバックログ）、SBL（スプリントバックログ）を組んでいきます。最初のスプリントをはじめるときに「この優先順位でいいのか」「この仕様でいいのか」といった議論を、OKRを軸にして開発組織内で話すようにしていますね。

実際には、新しいスプリントを開始する時に、今回のスプリントで開発するべきタスクと優先順位を、OKRを参照して全員で決めていきます。

通常だとPOが開発の優先順位を意思決定し、開発メンバーとコミュニケーションしていきますよね。ただ、POが最初に想定しているリリース速度と実際につくる開発チームのスピードには乖離があることもありますし、そもそもPOが単独で考えた開発の優先順位は一個人の考えのため、本当に正しいかどうかわかりません。OKRと照らし合わせた時に、「この優先順位で本当にいいのか。こうあるべきではないのか」とスプリントプランニング時に開発組織全体でブラッシュアップしていけるのが理想だと思っています。

ただ、開発メンバー自体が機能の背景や目的を理解していないと、POが提案した優先順位に対して自分の意見を伝えるコミュニケーションは生まれにくい。そのため、基本的にPOの言いなりになってしまい、開発メンバーは「どう綺麗に進めていくか」という観点に移りがちだなと。機能開発はHowの一つでしかなく、正すべきは「どういう風に道を登っていくのか」という話がもっとも大事なはず。だからこそ、優先順位を決めるスプリントプランニング段階からOKRを使って、開発組織全体が納得できる仕組みを作ろうとしています。その方がプロダクトの精度は確実に上がりますから。

参考：https://speakerdeck.com/resily/resily-enziniacai-yong-zi-liao?slide=48

西方：また、スクラムでは代表的なセレモニーが5つ（デイリースクラム、プランニング、バックログリファインメント、スプリントレビュー、レトロスペクティブ）あります。OKRでもセレモニーが代表的なもので2つ（チェックイン／アラインメント、ウィンセッション）あります。「このセレモニーをまず両方運営しているんですか」とよく聞かれるのですが、結論はノーです。状況に合わせてマージして実施している場合もあります。

顧客の課題解決に繋がるような、本質的な機能開発に取り組めるのがスクラム×OKRを運用する魅力

ーースクラム×OKRを運用してきた中で、もっとも感じている魅力について教えてください。

西方：OKRを軸にすることにより「機能をどのように開発したらよいか」ではなく「機能でどのように事業に貢献していくか」といったコミュニケーションができています。そうすると、実際に機能を開発するためにビジネスサイドと協力することも不自然ではありません。事業全体を考えて本質的な機能開発のPDCAを回せているのがOKRの魅力だと感じています。

Resilyの新機能を開発するためのプロジェクトでは、エンジニアだけではなくビジネスサイドと同じOKRを持ってプロジェクトを実行しています。通常のプロジェクトだとエンジニアは機能を開発すれば、あとのデリバリーはビジネスサイドに任せて一旦仕事は終わりになりますよね。しかし、ビジネスサイドと共通のOKRを見ることで、たとえばそこから先「クライアントに対してCSがどのように新機能を案内するか」や「テストのために機能を開放するクライアントをどう選定するか」なども気にするようになる。また、ビジネスサイドとの距離も近くなるため、たとえばCSが感じている課題感をすぐ聞くこともできます。「であるならばデザインごと調整した方が良さそう」といったように、良いプロダクトにしていくためにPDCAを回すスピードが早いと感じています。

また、同じ目標に向かっているため、開発vsビジネスのような無駄なコミュニケーションもほとんどありません。各部門の状況や課題もわかりますし、機能を開発する活動自体が開発組織の枠組みではなくOKRの枠組みで動いているので、部門を超えての情報伝達、コミュニケーションが非常に早いのも大きなメリットです。

プロダクト全体の課題を可視化でき、優先順位をつけやすい

石川：各機能の開発で感じた課題をすべてOKRに集約すれば、プロダクト全体の課題を把握できます。「今後何を潰していくべきか」の優先順位をつけられるのも大きな魅力だと思っています。

スクラム開発を進めていく中では、「このタスクがこなせない」「このタスクがある事情によって進められない」などさまざまな課題が出てきますよね。ただ、その課題は個人やプロジェクト単位でしか共有されず、会社全体として可視化されていないことがほとんど。

仕事を進める上での課題は当然同じチーム内、プロダクトに関わるメンバー全員に共有されるべきだと思います。そういった時に日々の業務で溢れていく課題をOKRにすべて集約させていく。そうすることで、会社全体での進捗やプロジェクトの課題もすべて可視化され、何をするべきかクリアになっていきます。そういった使い方をイメージしてスクラムとOKRを混合させています。

エンジニアとして感じる、HRプロダクトに関わる面白さ

ーーエンジニアがHRプロダクトに関わることの醍醐味、面白さについて教えてください。

西方：HRプロダクトはすべての物事を自分なりに咀嚼し、解釈して仮説を持たなければ進められないほど難しいと思っています。個人的にはそれがかなり楽しいですね。必ずしもシンプルで簡単な回答は持っていない。それが逆に頭を悩ませてくれるのが好きです。

もっとわかりやすくてプロダクトを売りやすい業界はたくさんあるじゃないですか。たとえば特定の業界の業務効率を向上するサービスは課題もやるべきことも明確なので、買い手側も買いやすいし売り手側も売りやすいと思うんです。ただ、それだと「やることが明確で想像ついてしまって面白くないな」と個人的には感じてしまうんですよね。一方、HR領域はまだまだ研究が盛んな分野で科学されている最中だと個人的に考えています。かつそれをプロダクトに落とすのはさらに難易度が高い。その難しさやまだ科学されている状況は流れ仕事ではない感じがして、かえって面白いと感じています。

石川：個人的に人の心理や行動に興味があります。人それぞれ考え方とかも違ったり、やり方も違ったりするので、それを見える化していくプロダクトをつくるのは非常に面白いと感じています。とくにOKRは、人の動き、想いを表現できるものだと考えています。OKRを通じて各々に責務を任せ、それによって「なぜ動いたのか」「どうしてこういう考えに至ったのか」をプロダクトを通じて見える化する。そして組織の流れ、各人の動きや流れがプロダクトを通じてわかることによって、組織や会社の行動が変わり、成長につながっていく。HRのプロダクトを創っていて「面白いな」と感じているところです。

プロダクトの成長ために、組織も環境も変化していく

ーーこれからResilyをどんなプロダクト、開発組織にしていきたいですか？

石川：”コミュニケーションツールが手放せない＝Slackが手放せない”のように、”OKRが手放せない＝Resilyが手放せない”といった世界観にしたいと考えています。そのため、OKRのメリットをクライアントが享受できるようなプロダクトにしていきたいです。

コミュニケーションツールのSlackは今ビジネスをする上で手放せないツールになっていますよね。Resilyもこれからそうなりえるのではないかと期待を持っています。なぜかと言うと、OKRのメリットを享受できれば組織として同じベクトルで物事を進められますし、他部署間の連携もできるようになる。つまり、Resilyを通じてOKRのメリットを伝えられれば、間接的にResilyも手放せない状態になると思っています。そういった存在になるためにも、クライアントに対してResilyを導入してもらうだけではなく、Resilyを通じて、OKRのメリットを存分に享受できるようなプロダクトづくりに専念していきたいと考えています。

西方：石川の言ったことを実現するためにも、これまで以上にプロダクト開発のクオリティ、スピードをより早めていきたいです。そのためには開発チームの数を増やすことが急務に他なりません。

しかし、人数を増やせばさまざまな問題が起きることも事実です。想定される問題はさまざまですがたとえば開発環境について。チームの増加に合わせてプロダクト自体のアーキテクチャや設計も変えていく必要があると思っています。よく聞くのが、「組織の人数が増え、プロダクトも成長している。だが外部から見るとプロダクトの中（環境）がまったく成長していない」という観点。個人的にはプロダクトを成長させるためには、組織（社員人数や個人の能力）の成長も必要ですし、プロダクトの中（環境）も成長していかなければならないと強く感じているので、両方改善していくつもりです。

「これだけ成長してやろう」というモチベーションに対して提供できる環境が間違いなくある

ーーどんな方がResilyの開発組織にフィットしそうですか？一緒に働きたいと思いますか？

西方：色々未熟で整備できていないからこそ、この環境を利用して「これだけ成長してやろう」「こういうキャリアを築いてやろう」と思っている方は相性がいいと思っています。なぜならばそのモチベーションに対して間違いなく提供できる環境があるから。これはフェーズが変わってしまうと得られない部分がたくさんあると思っています。なので今のフェーズを活かして自分自身のキャリアのパスを広げていったり、スキルを身につけていったりしてほしい気持ちがあって。事業的には中途のベテラン人材を採用する選択肢もあると思うんですよ。ですが、今は社内で未来のコアになる人材を育てていきたいのがResily開発組織の想いです。

また、スペシャリスト志向よりもジェネラリスト志向の方が合うとも思っています。個人的な意見ですが、弊社の課題感でいくと、頭を抱えるような深刻な課題よりも考えてみれば大したことない課題がまだまだ多いんです。なので特定の領域に詳しい人材は、深刻な課題として顕在化していないがゆえに、今のタイミングで入社いただいても活躍できる環境を提供できないと思っています。

石川：各々が個人で機能開発している人にとっては、Resilyは他者の知識や経験から学ぶことのできる最高の環境だと思います。私も前職では開発メンバーの人数が少なく、各々が機能開発していく開発体制だったため、フィードバックをもらったり、他者から知識や経験を教えてもらう場面は多くありませんでした。対してResilyのスクラム体制では最初にプランニングがあり、開発組織全員で設計方針を決めますし、スクラム開発で足並みを揃えてチームで開発を進めていく。なのでフィードバックを受けたり、他の開発メンバーを見て学んだりして成長していける環境があるのではないかと思っています。

また、スタートアップだからこそ、小さい課題から大きい課題までたくさん転がっています。自分の領域外であってもその課題を積極的に取っていくマインドのある方と働きたいですね。現状Resilyの課題として、現在フルタイムメンバーが2人しかいないため、課題の発見はしているのですが、それを解消するアクションを起こせていないことが散見していて。解消できれば会社として前に進めるし個人としても成長できる。WinWinにも関わらずやれていないんですね。なので、自発的に課題に対して好んで進んでいける方がマッチすると思っていますし、一緒に働きたいと思っています。