こんにちは、 
id:kotamat です。
先日このようなリリースを出させていただきました。
このリリースに対する顧客へ伝えたいことは、COOが記事にしてもらっているので、こちらを見てもらえればと思います。
今回は組織の話をさせていただければと思います。 この機能の連携は、開発組織とは別軸の「R&D」という組織が行っています。 「R&D」という組織を発足したのにはある理由があり、発足背景がユニークなものだったので、背景とともに記事とさせていただきます。
R&Dチームのやっていること
そもそもR&Dとは「Research & Development」の略で、日本語に訳すと「研究開発」となります。 長期的な目線でプロダクトや技術を研究し、必要に応じて開発にブレイクダウンするというのが、R&Dの大きな役割となります。
SCOUTER社はSCOUTER、SARDINE共に人材紹介の事業を行っており、「転職者に寄り添う支援活動」を後押しするような機能開発を行っております。 この文脈において、すぐには結果に結びつかないかもしれないが、将来的にはやるべきな機能の検討から調査・開発までをR&Dチームは行っております。
具体的には、上記リリースの通り、転職者属性の解析や求人のリコメンド、獲得をAIを用いて解決していくことを行っています。
R&Dを作った背景
そもそもなぜこのような組織の分割を行ったのか。それは会社全体でOKRを取り入れたことが始まりでした。
導入背景は上記COOの記事を参考にしていただければと思います。 こちらを開発組織にも導入したわけなのですが、決定までは長く大変な道のりでした。
OKRの導入でわかった時間軸の違い
OKRを設定するに当たり、チーム内での野心的な目標を設定することになるのですが、メンバー内での「わくわくすること」という軸において、サービスとしていずれ解決しなければならないことと、現状の顧客をどうやって満足させるかというところで意見が割れました。 サービスとしてはどちらも大事であり、当時設定していた全社のOKRにおいてはどちらも着手しておく必要があるという判断の元、チームを分けるという判断に落ち着きました。
OKRという手段を目的として施行していくのは違うかと思いますが、少なくともOKRを用いた、理想形からのブレイクダウンという思考軸によって、各々のメンバーの中にあるサービスへの印象や課題感が明確になり、議論する中で解像度が上がったことは間違いないです。
最近OKRのことだけずっと考えてきたが
— kotamat | SCOUTER CTO (@kotamats) 2018年4月13日
-開発組織はどういう貢献ができるのか
-現状顕在化している課題にどう取り組んで行くべきか
-チームメンバーはどういう特性があるのか（何にわくわくするのか）
-結果会社全体のOKRにどのように結びつけるのか
と色々考えるきっかけとなった
この過程が大事だなと
R&Dと開発の役割
そういった中でR&D発足時のR&Dと開発の役割は下記のようになりました
- 開発
- 目の前の顧客がリアルに感じている課題を解決する。そもそものフローとして欠けている機能や、ユーザヒアリングやデータを通じて明らかになった課題への着手。とりわけリリース期間は1〜2週間程度。いかにその価値を最短で届けるかが課題。
- R&D
- サービスとしてあるべき姿からの逆算から生まれた機能。顧客ベースでの開発ではあるが、顧客がまだニーズとして認識できていないが、あるとサービスへの依存度や大きな価値を享受できるもの。理想形のイメージや実現確度のバランス感覚、実装にたる技術力や選定が課題
スタートアップにおけるR&Dの時間軸
事業ドメインにおいて、各社方針は違うかと思いますが、ビジネス面での優位性から始まったスタートアップにおいては、どのように対象の顧客をグリップできるかという軸の中で、それをいかに最短に実現するかという問題を解いていく活動になるため、一般的な大企業におけるR&Dに比べると5年10年といった長期間を指すわけではないかと思います。 ビジネスメンバーもアプローチを変えて施策を打っていくということを考えると、半年 から1年程度。さらに、その中でもユーザへの認知をいかに最短にし仮説検証フェーズに回すかという軸で考えると、リリース頻度はそれほど長くとらない方針になるかと思います。
つまり、R&Dの組織が置くべき役割は、「長期的に着手していくこと」というよりも「メイン開発とは別の時間軸で考えなえればならない大きな価値への投資」という位置づけになっていくでしょう。
まとめ：R&Dは手段ではなく目的の実現のために生まれた
開発チームからR&Dチームが分離した背景と、その役割配分を述べさせていただきました。 ビジネスドメインによってR&Dを採用するのかどうかは違うかと思います。
R&Dを導入するべきかどうかという思考回路で検討するのではなく、「サービスとしてどこを目指すか」や「自分たちはなぜここにいるのか」のような大局観からの分解から、R&Dという手段を使うかどうかを判断するという思考で選択するのが大事なのではないかと思います。 そういう大局観を持って思考するという手段として「OKR」は有効でした。 相当の覚悟は必要ですが、必要なプロセスであったと思います。
