バックオフィス業務を担うチームをAccleratorと位置づけるプレイド。複雑で予測することの難しい環境を厭わず、長期的な事業成長のために必要な業務改善を非定型的に進めるのがアクセラレーターのスタイルです。今回新たに「アクセラレーターエンジニア」のポジションを創設しました。エンジニアリングによる業務効率化だけでなく、技術的知見を活かして業務のあるべき姿に道筋をつけ、その変革の起点になるのがプレイドのアクセラレーターエンジニアです。

この記事は、これまでプレイドでアクセラレーターエンジニア「的」な役割を担ってきたエンジニア原田へのインタビューを通して、そのミッションや役割、仕事の醍醐味や得られる経験などを紹介します。バックオフィス業務のシステム開発に携わる業務エンジニアや、業務改善領域のSaaSのプロダクトエンジニアで、開発力と業務知識を磨き、現場で価値を出すための試行錯誤を求める方に読んでいただきたい記事です。

活用の場面を一番近いところで見て、どう使われるべきかを考え実装する

——まずは自己紹介をお願いします。

プレイドの原田です。新卒で株式会社ワークスアプリケーションズに入社し、会計システムのエンジニアをしていました。エンジニアとして開発しつつもお客様と向き合い直接やりとりしながら、製品が体現すべき価値を定義し、戦略と設計の指針を方向づけるPdMのような役割も担っていました。

——エンジニアとPdM、どちらの役割も担うというのはユニークなキャリアですね。

そうかもしれません。ワークス社で5年ほど経験を積み、2018年にプレイドに入りました。当初はプロダクトエンジニアとしてジョインしています。ワークス時代に、考え抜いて機能開発をしていても実際の利用には多くのハードルがあることに問題意識を持っており、入社時からプロダクトがどう使われるのかという点に興味を持っていました。入社から1年半ほどで例えば KARTE for App の「リテンションレポート」といった大きい機能の開発に携わり、お客様にもきちんと使っていただけているのを見て、自分なりに一定の価値を出せたと思えました。だから、ずっと温めていた思いである「実際の活用の場面」で力を発揮するために、ビジネス側に軸足を移すことにしたんです。

——ビジネス側に移ったことがアクセラレーターエンジニアとしての役割も担うようになったきっかけですよね。どのような経緯があったのでしょうか？

私が移ったタイミングで、ビジネス側ではCRMの大規模改修に取り組んでいました。以前から商談管理や契約管理には大いに改善の余地があることは指摘されていたのですが、いよいよメスを入れようと。改修にはエンジニアリングの知見が必須ということもあり、手伝ってくれと声をかけられ関わり始めたのがアクセラレーターエンジニア人格の原田誕生のきっかけです。

なし崩し的に始まったように見えると思いますが、私のなかでは筋は通っています。つまりこれは「プロダクトが実際にどう使われているか」の場面であるということ。プロダクトとしてのCRMがメンバーにどう使われているかを一番近いところで見て、どう使われるべきかを考え設計し、実装する。クライアントも同僚も、プロダクトを介すると「ユーザー」としての性格が立ち現れます。だからそれほど違和感はありませんでした。

使いづらいプロダクトはめちゃくちゃ負を生むと考えています。使いづらさは業務遂行に直接的な支障を来すだけでなく、間接的な悪影響も生みます。「使い方が分からないから調べます」と20分かけるとする。ここで生じるコストは20分だけじゃないんです。調べるために頭を切り替えて認識のリソースを消費しているし、そこから本来の業務に戻すためにまたリソースを使わなければいけない。プロダクトの使いづらさがなければユーザーはその20分以上の何かを生むことができたはずだし、それに集中できる環境を整えるのが良いプロダクトだと考えます。

——CRMの改修は滞りなく上手くいったのでしょうか？

一旦完了はしたものの、まだまだ改善点は多い状態でした。そうした状態で、グループ会社であるエモーションテック社への出向の話が進みまして。これにより、私がCRM改修とその後の保守整備を担うことが体制として難しくなると見込まれたので請求・契約周りの改修を外注することを試みました

結果的に一定の改修は済んだものの、まだまだ多くの課題があることを確認しました。また、それぞれの問題は複雑な業務の中に存在しているためこの領域の改善を外注していくことは非常に難しいという判断にもなりました。ここでの経験から、業務のあるべき姿から逆算してオペレーションの在り方を論じられるアクセラレーターエンジニアの必要性というのを感じました。

——請求や契約まわりの業務オペレーションの改善は、プレイド特有の問題なのでしょうか？　それともどの企業であっても課題として見られるのでしょうか？

課題の大小は会社によるので一概には言えませんが、どこの会社も一定の苦労はしていると聞きます。契約・請求・計上は複数のシステムにまたがることが多く、企業の成長速度やビジネスモデルの変化によっても管理方法は変動します。特に、私たちのようなサブスクリプションビジネスも言ってしまえば最近出てきたビジネスモデルなので、最適解が見つかっているわけでもありません。だから自分たち自身で模索し、自分たちなりの方法を作り上げる必要があります。

どの会社であっても独自の作り込みで対応している部分が割りと大きいということです。エンジニアからすると「これはなんとかしたいぞ」と興味を引かれる領域なんじゃないでしょうか。私はそう思います。

対象領域はここまで話したCRMや請求まわりだけではありません。エンジニアが介在価値を生めば、アクセラレーターメンバーの生産性を大いに上げることができる。効率化の面だけではなく、余裕がなくて手を付けられなかった領域に着手し、彼らは別のバリューを発揮できるかもしれない。先ほどの「20分」の話につながりますが、1日20分を積み重ねたら一体どれくらいになるのか。仕組みが整えば、そこで取られているリソースを新しい価値の創出に振り分けることできます。

このように考えると、アクセラレーターエンジニアの介在価値は非常に大きい。私たちは「データによって人の価値を最大化する」というミッションを掲げていますが、自社にもそれを適用しようよという発想ですね。

将来的には「これだけ凄いオペレーションを整えた会社があるんだ」ということを世の中に発信していけるようになりたいし、それができるだけの土壌がプレイドにはあるとも考えています。これから仲間になっていただけるアクセラレーターエンジニアはそれをリードする存在になってほしいですね。

エンジニアリングの介在価値が、会社全体で顧客に向き合える基盤をつくった

——「介在価値」という言葉がありました。今回は一緒に動くことが多い財務の向江さんを呼んでいます。向江さん、原田さんとの思い出深い仕事を教えてください。

向江：「リニューアル商談」のプロジェクトですね。先ほど話のあったCRM改修の直後、組織として「リニューアル商談」を管理できるようにしました。何かの延長で改修したのではなく、新たに開発したのが「リニューアル商談」です。

私たちが展開するSaaSビジネスには契約継続という考え方があります。一度契約いただいたお客様は、契約終了のタイミングで継続と解約を選ぶことができます。私たちとしては当然解約は避けたいわけですが、お客様の情報やKARTE活用の状況が把握できていないと組織として契約継続に向けたアクションが取りにくくなってしまいますね。担当者個人でお客様の状況を把握していても限界があるし、一人では解決できない問題も組織の力を結集すれば対応できます。ビジネスと開発の距離が近いのもプレイドの強みですから、場合によってはプロダクト側も巻き込んでお客様の要望に応える体制も組むこともできます。

このような動きを可能にするために、プレイドと個々のお客様の日頃のコミュニケーションの過程をシステム的に可視化し管理するのが、「リニューアル商談」という考え方です。

原田：当時はカスタマーサクセスのチームが正式に立ち上がっていたものの、会社としていつ・どの程度の規模で既存顧客がリニューアルタイミングを迎えるかをシステム的に把握するのが難しいデータ構造だったんです。だからセールスやカスタマーサクセスが組織の強みを活かしにくかった。しかしリニューアル商談の整備により、契約状況を誰でも俯瞰して見られるようになった。だから今では来るべきタイミングに向けて前倒しで、チーム力を活かして既存のお客様に価値提供する動きができるようになったし、全体でビジネスの見込みを立てられるようになったことで未来に向けた投資的な動きもしやすくなりました。

向江：当時に比べて、プレイドの価値提供の在り方は多様になっています。プロダクトや機能が増え、人的支援サービスも提供している。あのタイミングで、原田さんの力を借りてリニューアル商談を整備し切ることができたことが今のプレイドの事業展開に確実に効いています。つまり、会社として顧客に価値提供できるようになったということです。個人レベルではなくプレイドオールでお客様に向き合える基盤ができたんですよね。顧客への価値提供の拡大とはすなわち事業成長の言い換えです。タフなプロジェクトでしたが、あのときやり切ったから今がありますね。

エンジニアリングで、理想から逆算して業務を変革する

——プレイドでアクセラレーターエンジニアとして働くことで、どのような経験が得られますか？

原田：アクセラレーターたちと近い距離で働けることは稀有な経験だと思います。人事も労務も財務も法務も、誰もが専門知識を備えているのはもちろんですが、一緒に働いていると「あー！　そういう変え方があるんですか！」という発見が多いです。

彼らはバックオフィス業務に対する一般論的正解に対して、疑いの眼差しをやめることがないんですね。事業成長のための理想論から、あらゆる業務に対して「本当にそうか？　こうするべきでは？　こう変えられるのでは？」という懐疑を重ね、実行に移していく。アクセラレーターチームのメンバーにはこのスタンスが浸透しています。

一緒に働いていると、バックオフィス業務そのものに対する理解が本当に深まります。業務に会社が合わせるのではなく、会社に合わせて業務を変革することができる。懐疑は柔軟な解釈を育みます。エンジニアの立場でここに関われると、業務知識のレベルを一段も二段も上げられるはずです。

——改めて、アクセラレーターエンジニアの役割やミッションを教えてください。

原田：アクセラレーターエンジニアはアクセラレーターの一員なので、上記のようなスタンスを当然求められます。だから、専門家だからといって彼らのいうことを聞いて、請負でコードを書いておけばいいというものではありません。エンジニアリングのプロフェッショナルとして、バックオフィス業務の最適化と運用構築に専門性を発揮することが期待されます。つまり、課題対象を正しく要素分解し、問題の根本原因を特定して改善し、最適なかたちで要素を再構成すること。その過程で、最も適した技術を実装すること。後者ばかりがフォーカスされがちですが、エンジニアリングの本質は前者です。

向江：たしかに原田さんは業務プロセスの分解と再構成が得意ですよね。エンジニアとエンジニアリングは別物だとはよく言いますが、コードを書くのは当然として、対象を解決可能な最小単位まで一度全部分解して、課題の本質を突き止めてくれます。「本当の問題はそっちじゃなくてこっちでしたよ」と。こういうエンジニアリングの素養と今のアクセラレーターチームが掛け合わせられれば良いなと思うし、チームとしても刺激になりますね。

原田：先ほど「請負ではない」という言葉を使いましたが、バックオフィス業務とエンジニアリング双方のプロフェッショナリズムを掛け合わせて、自分たちの「べき論」を追求できるのは魅力的な環境だと思います。これを魅力的だと思ってくれる人と一緒に働きたいというのが本音です。しかもこの「べき論」は、まだ完全に出来上がっているわけでもありません。毎日試行錯誤の連続なので向江さんがいうように刺激的だし、伸びしろも大いにあります。

向江：やりたくてもできてないこと、まだまだたくさんありますもんね。

原田：ほんとそれです。

——最後に、アクセラレーターエンジニアにはどのようなスキルを求められますか？　どのような方と一緒に働きたいですか？

原田：ゼロベースで徹底的に考えられること、過去の成功体験に固執せずにアンラーニングできることが最も大切です。これはアクセラレーターエンジニアに限らず、プレイドで働く人全員に求められる行動指針です。

あとは先ほども言及したエンジニアリングについての観点です。ポジションとしては、現在いわゆる業務エンジニアとして活躍されている方や、業務系SaaSのプロダクトエンジニアとして活躍されている方が想定されますね。ここでもスキルというよりスタンスが大事です。今それができるかどうかよりも、「要素の分解と再構成」という点にこだわりを持てる方を歓迎します。

私もリソースを全てアクセラレーターエンジニアに充てているわけではないものの、プレイドメンバーという目の肥えた、ある意味で手強い「ユーザー」たちとゼロ距離で開発に携わり、自分の作ったものが実際にどう使われるのか、どのように価値につながるのかを確かめながら仕事を進めることができることにやりがいとおもしろみを感じていました。業務を型にハメるのではなく、自分で新しいアプローチを模索したい方にはエキサイティングな環境を提供できるはずです。

業務の根幹の、価値が生まれる一番近くで自らのエンジニアリングと業務知識を武器に、一緒にプレイドのDXを加速させ、事業成長を牽引してくれる方をお待ちしています。

アクセラレーターエンジニアに興味のある方のエントリーをお待ちしています！

以下よりエントリーいただけます。