“フォームを作るだけ”じゃないResilyのフロントエンド開発
— さっそくですが味野さんは現在どういうお仕事をされていますか？
味野：今は1割を企業向けOKRツール「Resily」のプロダクトマネジメント、残りの9割をがっつりフロントエンドの実装に充てています。
OKRってフレームワークとしてはシンプルですが、具体的にどう運用するのかというところは、色々な本を読んでもわかりづらいんですよね。それをUI上で表現して解決するのはデザイナーの力で、UXを向上させるのはフロントエンドの腕の見せ所だと思っています。
— OKRというのはどういう仕組みなんですか？
味野：OKRはObjectiveと複数のKey Resultから成ります。Objectiveは達成すべき目標、Key ResultはObjectiveの達成具合を観測するための数値指標です。組織はトップのOKRを設定して、それチームのOKRが追従するというツリー構造になります。
組織でOKRツリーを定義することによって、チームは優先事項にフォーカスすることができ、自チームの上位に定義されているOKRから自チームの優先事項がなぜ設定されているのかが明確になります。また、他チームのOKRも明確なため補完関係が生まれたり、組織に対する自チームの貢献が見えるようになるため仕事にやりがいが生まれます。
例えばジョジョでOKRを作ってみたらこうなります（笑
— なるほど。このタイプのサービスだとフロントエンドも難しそうですね。
味野：そうですね。フロントエンドはフォームを作るだけじゃなくて、ツリー構造をつなげていくようなインタラクティブな実装も多いですね。
— Canvas APIを使って書いていくようなイメージですか？
味野：Canvasは使っていないです。普通にHTML Elementを使って、ツリー構造の部分はCSSではなくJavaScriptで位置計算をするような実装になっています。
表示面積が一番小さく、かつ綺麗なツリーが描けるようなアルゴリズムを使ったり、ズームの操作もGoogle Mapっぽくピンチで好きな位置を中心に拡大・縮小できるようにするために行列計算をしたり。フォームを作るだけのフロントエンドは面白くないなって思ってる人は面白さを感じると思います。
— なるほど。ツリー構造のデータとなるとクライアントでどう持たせるかってところも考えるのが大変そうですね。
味野：そうですね、結構エグイです（笑）。どういうふうにエグイかっていうと、GraphQLで取ってきたツリーのノードはフラットに入っているんですよね。それを一度フロントエンドでツリー構造のオブジェクトになおしてあげてプリレンダリングする。そのときにノードのサイズを取ってきて、ツリーの全体のどこにノードが配置されていれば良いのかみたいなのを計算しています。わりとさくっと動いてますけど実装されているコードたるやエグイ（笑）。
ツリー構造をパフォーマンスを落とさずに構築するために、子供から親を引けるようにしてたりとか、親から子供を引けるようにしてたりとか。色んな情報がごちゃごちゃいっぱいあったりするのを、ReactのHooksを使って全部実装しているので。
わりとコンポーネントの実装のうち8割くらいはデータを整理してるコードが書いてあって、下の方にちょろっとJSXが書いてある構造ですね。
ぎょっとするかもしれない。ぎょっとするかもしれないけど、こうするしかないんや！
目指すは、千差万別のユースケースに対応できるUI設計
— プロダクトマネージャーとしての仕事も聞かせてください。ローンチしたのが2018年の8月ということで、今は事業を拡大させていくフェーズですか？
西方：ローンチから今まで、いろいろなお客さまからフィードバックをもらいました。そのフィードバックを元に、プロダクトとしてどうあるべきなんだっけというのを、味野さんがリードして整理してくれています。
今はその一環のデザインリニューアルの開発中で、近々リリース予定です。それを皮切りに機能拡充により力を入れていきたいなと思っています。
— どのような会社が利用されているんでしょう？
西方：様々ですね。僕は、OKRに大きく期待されていることは大きく分けると2つだと思っていて、ひとつは閉塞感・停滞感を打破したい。この点では大企業がかなり多いです。
一方で小さい会社に関しては、僕自身Resilyにいても思いますけど、人数が少なくてもまぁまぁカオスになり得るんですよ。それを制御するための1つの旗としてOKRを使っているのかなと思っています。
味野：使い方もお客さまによりますね。例えばOKRをベースに1on1を行っている会社もあるんです。その場合、会社から下りてきたチームのObjectiveがあって、その下に個人に紐づけられたOKRが入っていて、その画面を見ながら1on1ミーティングを行います。
一方で、なるべくResilyのサービス上にログを残していこうという文化の会社だったら、毎日何かしらを書き込む可能性もあります。さらには、最低限のフレームワークだけ運用しようという会社の場合は、毎週業務の進捗を更新して、このKRが何%上がったのならこの方向性にしようと確認するくらいの頻度で使っていたり、本当に千差万別だと思います。
なので、どんな使い方でも対応できるようにUIの設計を工夫しています。
— そうなるとUXの設計がかなり難しそうですね。
味野：そうなんですよ。例えばツリーのマップの画面ですが、誰がこの画面を1番見るのかという議論があります。
仮説ですが、例えばズーム率で1番引いて、全体感を見てるのはおそらく経営層寄りの人なので、その人たちに対しては必要な情報だけを示す。ひとつの箱にObjectiveとKey Resultが複数書かれるんですが、経営層はObjectiveのツリー構造だけが見えている状態でいいかもしれない。
一方で、マネージャーレベルの層の人たちはもう少し拡大率の上がったところで見ていて、隣のチームってどういう進捗なんだっけ、どういうObjectiveとKey Resultを抱えているんだっけというのが気になるでしょうし、更に細分化されたチームの中にいる人はカードの中だけが見られる拡大率であればいい。こうしてデザインから実装まできちんと考えないといけないです。難しいですが、面白いところですね。
OKRの実践で見える景色が変わった
— 話を変えて、Resilyでも実際にOKRを運用しているとのことですが。先ほどもミーティングをしているのを見かけたのですが…
味野：OKRのフレームワークにある「ウィンセッション」ですね。僕も入社当初、何だろうって思いました。
西方：方向性としては、“自分がやった自慢できる今週の成果”っていうのを共有する場で、共有したうえで何かが気になったら「それって何ですか？」って話すイメージで、議論というよりかは発表に近いかもしれないですね。
味野：ウィンセッションをやることで、誰が具体的に何をやっているかわかります。例えば”Customer Success”という役割の人が、具体的に何をやっているのかは知らなかったりする。成果に対して「それって何ですか？」と質問をすることによって、より理解を深めていく。これは会社をひとつのチームにするための重要な要素なので、実践しているわけです。
もちろん、組織の規模が大きくなってくると時間的にも物理的にも全社ではできないので、だからこそ物事を整理して一覧性を持たせて、目標達成のためにどんどん進めていけるようなサービスが凄く求められます。
— ウィンセッションを含め、自社内でOKRをやった印象どうですか？
味野：そこなんですよね。そこがまぁまぁ難しくて。ですよね、西方さん。
西方：難しいです。僕はもう少しシンプルで、やりやすい目標の立て方をすれば良かったっていうのが今期の反省です。
味野：でもそもそも目標を立てていなかったら、そういうことにも気づかないわけですしね。
西方：あとは、「自分はこれが出来ていないな」とか、「会社がこれ出来ていないな」と思う瞬間はすごく増えましたね。
今までの会社で、単にプロダクト開発チームにいるだけだったら絶対に気づかなかったなということは、結構あります。視座を高めに会社の目標を見るので、そうすると見る景色が違って、また別の発見があるんですよね。
味野：OKRは以前働いていた会社でもやっていたことがあったので概念だけは知っていましたが、そのときはうまくいっていませんでした。
でもResilyでの最初の面談がCEOの堀江さんから「OKR is 何」を聞く会で、会社の目標から細分化していくというのがすごくロジカルだと思いました。そういうものの上で組織が運用されたら確かに気持ちよく回るんだろうなと。それから半年くらい経って、当時の職場で経営陣とも話す機会が増えたことで組織全体のペインを直に感じたんです。
何かのフレームワークが組織に入っていて、それをベースにうまく運用されていくのが理想ですよね。理想を追い求めるのって、めちゃくちゃエンジニアは好きなんですよ。正しいと思ってることが実装され、正しく運用されたいという思いが強いので、OKRは組織を運用するフレームワークとしては最も正しいだろうなと感じました。
ペインと感じたものをプロダクトで解決できるって、そんな幸せなことはない。そういうプロダクトを作っていくことは凄くやりがいがありますね。
「OKRをやって会社がよくなったね」ってみんなが実感できる世界になってほしい
— 最後に、味野さんがResilyで何を成し遂げたいかとか、どういうふうになっていきたいかというものはありますか？
味野：会社によって必要としている組織運用のためのパーツは異なるんですが、その中で最大公約数みたいなものを見つけて機能追加していくのが1つの使命だと思っています。
それによって企業が最終的に「パフォーマンスが上がったよね」と感じる状態にしないと本質的にダメだと思ってます。そうじゃないとやっている意味がないし、時間だけかけて「気持ちよくなったよね」みたいな話がなくてもダメなので、最終的にはそういうところにもっていきたいと思いますね。
— それが実感できるのって、どういうタイミングなんでしょうか？
味野：結構難しくて、それが本当にOKRによるものなのかはわからないんですね。色んな要因があるじゃないですか。でも、皆が実感してくれるんじゃないかなと思ってます。じわっと心のどこかで「OKRをやったからなんじゃね」って。
それくらいのパフォーマンスを出せる可能性があるものだと思ってるので。数字で測るのは本当に難しいと思いますが、良かったって言ってもらえる世界になってほしい。どうですか？そんな世界。いいですよね。
