こんにちは、DevBrandingのellyです。4月15日に配信した「freeeの要を支えるデータアグリゲーションチーム」の様子をご紹介します。
freeeには様々なソースからデータを集約する要となるシステムがあります。 今回はデータアグリゲーションチームの2人を招いて、このシステムを支えているチームが日々どのような工夫を行いながら喫緊の課題に向き合っているのかを聞きました。また、チームの指標としてNorth Star Metricを導入しており、その導入後に生まれた効果や、今後の展望についても話してもらいました。
taiyo:写真右上。2017年4月新卒入社。コアエンジンチームマネージャー。趣味はトライアスロン、サウナ、コーヒー。
narinari:写真左上。2017年6月入社。コアエンジンチームテックリード。趣味は自作キーボード。
のぶじゃす (@noblejasper): 写真右下。ラジオパーソナリティ、2017年に中途入社。mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。しゃべりたがり。声が大きい。
データアグリゲーションチームとは
―データアグリゲーションチームってどの会社にでもあるようなチームではないかもしれませんね。freeeの中で内部的にはコアエンジンチームと呼ばれているんですけど、コアエンジンチームとは何をやっているチームなんでしょうか？
taiyo:ざっくりいうと、freee会計の一機能で銀行やクレジットカード、交通系IC、レジサービス、決済サービスなどのfreee外のサービスからユーザーさんのお金の動きについてのデータをfreee会計に連携して、ユーザーさんの仕訳業務を自動化・効率化する連携機能を開発しているチームです。
外部連携機能を作っているサービスはそれなりにあると思うんですけど、連携先の数は2300くらいあって、それぐらいの連携数があるサービスはそう多くないと思うので、そういう意味では独特だと思います。
―インパクトがある数字ですね。freeeでいうと連携はサービスの根幹ですが、それを止めずに正しいデータを常に保つことをやっているのがデータアグリゲーションチームということですね。
データアグリゲーションチームの面白いところ、辛いところ
―データアグリゲーションチームの面白いところ、辛いところを教えてもらえますか？
narinari:そうですね。私はテックリードなので技術的な面白いところでピックアップしようと思うんですけど、取り扱うシステム自体がただのWebアプリケーションではなくて、外部のサービスに対してクライアントとしての役割をするっていうところが、他とはちょっと違うところだと思っています。 ものすごく連携先が多くて、それぞれに仕様が違っていて、その数ある中で保守性や生産性を保って作り上げるってところがすごく難しくて逆にそれが面白いところでもあると思っています。
あとはfreee会計というサービス上、会計のドメイン知識が必要になる場合もあるんですけども、それよりもインターネット上にあるデータを持ってくることになるので、インターネットそのものを構成するようなOAuthやcookieやキャッシュといった、純粋なプロトコルの知識みたいなところを持っていないといけないというところも難しさです。
連携するためのリクエスト数も多くて、freeeはわざわざ連携の指示を出さなくても許可を与えれば自動で一定のタイミングでデータを取得するということをやろうとしています。なので連携が動いていない時間はないくらいずっと動いているようなもので、設定の数もものすごくたくさんあるので、そういったものをなるべく早く捌きつつ、先方にアクセスが集中して負荷をかけないよううまく分散できるようにするみたいなところを解決するのが面白いところだと思っています。
―技術的難易度と面白さが共存するってことですね。
narinari:そうですね。一方で辛いところは、データ数と連携先が多いので多種多様な問題が発生するっていうのがあって、一つの問題がたくさんのお客さんに迷惑かけたりとか、逆にとあるお客さんにしか起きないすごいレアなケースで問題が起きるみたいなものがあって、それらがいろんなパターンで起きてモグラたたきのように対応しなきゃいけない場面がどうしても出てきてしまっていて、リソースも限られるので優先順位付けして対応していくしかないんですけども、長くお待たせしちゃってる問題もあったりして、心苦しくて辛いなと思うところですね。
―どうにかしたいけどすべて100%対応するのは現状だと難しい、それは心苦しいですね。taiyoさんはどうですか？
taiyo:多種多様な連携先があるので、それぞれのドメインに詳しくなれるっていうところが面白いところかなと思います。 例えば、同じ業種の連携先さんでもAPIのインターフェースやデータモデルの設計がちょっとずつ違ったりとか、利用者の立場で色んな設計を見ることが出来るので1エンジニアとしてシンプルに勉強になるなと思います。
一方で辛いところは、narinariさんとほとんど同じで、データアグリゲーションチームはアプリケーション開発がメインのチームではあるんですけれども、機能の稼働率のような数字を追っているという性質もあります。そういうチームに見られる性質として、やっぱり保守運用に工数が割かれることが多く、連携先が多いとより工数がかかります。改善のためにOKRも立ててやっているんですけど、中々思ったように進められない状況が続いています。
保守運用も保守運用以外の新規の開発や機能追加も、どちらもお客さんの価値には繋がっているはずなんですが、保守運用が多くなるとそれがあんまり実感できていないっていう状況があったので、あるタイミングでチームのミッション・ビジョンの改定とNorth Star Metricと一般的に呼ばれている重要なKPI群を決めて、チームでやっていることが価値に繋がっていることを可視化しました。
チームの指標としてNorth Star Metricを導入
―データアグリゲーションチームではNorth Star Metricをどのように導入していったんですか？
taiyo:まず最初にやったのはミッションの改定で、チームが一体どこに向かっているんだっけ？とか、ユーザーさんに対してどういう価値を提供するために我々は日々開発をしているんだっけ？みたいなところをまずは決めました。 それによってこの価値を届けるために我々は開発するんだという定性的な目線はチーム内で揃ったんですが、それだけだとじゃあ我々の現在地はどこで、何が優先度が高いのかみたいなところが分かりづらく、どこから攻めればいいのか分からず手探りな状態になっていました。
アクションに実際に落とし込むためには何が必要なのかと思って本をいくつか読んでいたんですけど、その中に「Measure What Matters」っていう本があって、それを読んでいる中で一つの事例と共にヒントが載っていました。
どういう内容だったかというと、全社のOKRと各チームのOKRのアラインメントという文面で、組織が追う一つの指標を決めるといいと書かれていて、それを元に私がOKRをこうしたいというのをdocにアウトプットして、こんな感じで考えてるんだけどどうですか？とみんなに共有してみたところ、いいね、分かりやすくなるね、と良い反応をもらうことができて、当時のプロダクトマネージャーと一緒にミッションを定量化しKPIを決めていきました。
その中の最上段にあるKPIのことを、North Star Metricと呼んでいます。
―「ユーザがfreee会計を開くと常に外部サービスの最新の情報があり、すぐに業務で使える状態を提供する」っていうミッションがあって、そこに向かっていくための指標・KPIとしてNorth Star Metricで「全口座における、明細/取引が取得できている連携口座割合」を定めていると。 自分のタスクがいまこの割合に対してどう影響しているのかっていうのが分かるんですね。
taiyo:はい、これは概念的に略したもので、実際はもう少し詳細な定義で置いています。ミッションの定量化というトップダウン的なアプローチと、我々の日々の取り組みが提供している価値ってなんだろうというボトムアップ的なアプローチの両面からNorth Star Metricとその下に連なる5つの要素のKPIを決めて行きました。
―これらの指標を日々の業務ではどのように活用しているんでしょうか？
narinari:全部を同時に追うって言うのは難しいんですよね。なので、例えばこのQは導入のしやすさを上げることによって、ユーザーさんにこの連携機能を使ってもらい便利だなと感じてもらうところにフォーカスを当てようとか。あるいはリアルタイム性でいうと、いつでもデータがある状態を目指しているものの、やっぱり作っているうちに遅くなっちゃったり、あるいは口座数が増えてもっとパフォーマンスを良くしないと連携を捌けないといったような課題が出てきているのでそこの改善に注力したり。
それらは5つに分けたKPIのどれかしらに当てはまるような問題なので、今回はここに注力しようと選んでOKRの中に反映している感じですね。それぞれのKPIに対して指標も決めていて、それがNorth Star Metricに跳ねるような式にしてあります。
―これの裏側にはたくさんの計算式があるんですね。今はこの中で何を重視して改善しようとしているんですか？
taiyo:リアルタイム性かなと思ってます。「ユーザーさんがデータが欲しいと思ったときにちゃんとある」というフェーズから、「気付いたらある」みたいな状況まで持っていきたいんですよね。 今そこまで行けてるかというとまだ行けてない状況で、重視していきたいかなというところですね。
North Star Metricを導入して良かったところ、今後の課題
―North Star Metricを入れてみて良かった点と課題を教えてもらえますか？
narinari:ミッション・ビジョンって言葉だけだと、良くなってるのか悪くなってるのかって言うのが割と主観的になってしまうところがあって、それが定量化されたっていうのが一番いいポイントですね。 上がったり下がったり以外にもペースを維持してるよねとか、そういった見方も出来るようになったので、それはすごいよかったなと思っています。
課題は今言った話とちょっと関連していて、上がったり下がったりしてるんですけど、いろんな要素が関連して上がったり下がったりしているので、これは本当にこれが効いたんだろうか？みたいな関連性を見出すのに距離があるところに課題感を感じていますね。
―合計点は出てるけど、どこが良いか悪いかは調べるのにちょっと手間がかかるってことですよね。
narinari:そうなんですよ。それぞれのKPIは見てるんで、それを細かく見れば分かるはずですが本当にこんな跳ねるのかな？とかいうのがちょっとあります。これは導入してからまだデータが溜まってないというのも要因ではあるので、継続的に改善していきたいと思っています。
―taiyoさんはどうですか？
taiyo:みんなで決めたKPIやNorth Star Metricという数値があって、それらがユーザーの価値に繋がっているはずという認識がみんなで持てているので、それを共通言語にした会話もしやすくなっているし、課題がどこにあるかという分析もしやすくなって、いろんな分析Queryがぽんぽん作られて、内訳がこうなっているからここに取り組むのが良さそうというのも見えてきていて、進んでいる感覚があります。
一方で、重要KPIの内の一つに「正確性」というのがあったんですけど、これに関しては指標としての設計が難しくて、短期的なKPIは設定することが出来ても、長期的に追うことで意味があるみたいなKPIが設置できているという感覚がないのでそれは今後の課題だと思っています。
今後の展望としては、チームが今拡大中なので、チーム単位で一つ一つの重要KPIに対して、オーナーシップを持って改善に務めていくようなチーム体制を作っていけたら、我々が提供できる価値っていうのはもっとどんどん大きくなっていくんじゃないかなっていう風に思っていたりします。
直近だと、チーム内で「チームトポロジー」という本を読んだメンバーが何人かいて、その内容を踏まえて今後のチーム体制ってどうしていくのがいいんだろうね、って話がぽつぽつ出てきているので、そういったこともみんなで話し合いたいと思っています。
―よく本を読むチームなんですね。リーダーのこういうチームにしたいという考えと、逆にメンバーからこっちの方がいいんじゃないかという考えをぶつけて相談しながら決めていくって、freeeらしくていいですね。
本編終了後にZoomで開催されたアフタートークにもたくさんの方にご参加いただき、さらに深い話で盛り上がりました。
▶データアグリゲーションチームではエンジニアを募集しています
freeeの要である「自動化」を支える基盤を一緒に作りませんか？ご興味のある方はぜひ気軽にご応募ください！
https://freeecommunity.force.com/jobs/s/detail/a4l1000000170hbAAA
▶次回freee Tech Night
6月1日（水）19:00～「品質を追及するfreeeの守護神、QAエンジニアのお仕事」
▶今回のイベントのアーカイブ（録画）
