複雑なプロダクトを、少数精鋭で速くつくる──kickflow CTO・小林佳祐氏が語る、顧客起点の開発思想

株式会社kickflow

大企業が求める柔軟性と、クラウドの使いやすさを両立する

──　まずは、御社の事業内容について教えてください。

稟議ワークフローSaaS「kickflow」と、AIを活用したタレントマネジメントサービス「Talentify（タレンティファイ）」を開発・提供しています。

kickflowは創業期からの主力サービスで、Talentifyは新規事業として立ち上げました。現在は、この2つが事業の柱です。

主な顧客層は、中堅企業からエンタープライズ企業です。業種を問わず、従業員数が数百名から数千名規模の企業を中心にご利用いただいています。

──　クラウド型のワークフローには多くの製品がありますが、kickflowの強みはどこにあるのでしょうか。

クラウド型のワークフローは、私が知っているだけでも数十種類あります。ただ、その多くは中小企業を対象につくられています。

大企業では、例えば「金額が1億円以上なら役員決裁、1,000万円以上なら部長決裁」といった、複雑な条件分岐を含む承認経路が必要です。組織変更も頻繁にあるので、それに合わせて承認経路を追従させることも求められます。

中小企業向けの製品は、シンプルで導入しやすい反面、こうした大企業特有の複雑な要件までは想定されていないことが多いんです。そのため、クラウド製品を使えず、オンプレミスの製品を使い続けている大企業があると捉えています。

kickflowの強みは、クラウドでありながら、大企業が必要とする高度な柔軟性や機能を備えていることです。クラウドであること、多機能であること、そして使いやすいこと。この両立が、差別化につながっていると思います。

ゲームをつくりたいという思いと、理想のチームに出会った経験

──　エンジニアとしての原点を教えてください。

パソコンを触り始めたのは、高校に入った頃です。家にパソコンが来て、インターネットも使えるようになったことがきっかけでした。

もともとゲームが好きだったのですが、家があまり裕福ではなく、ゲームを買ってもらえなかったので、お小遣いやお年玉を貯めて買っていました。

パソコンを手にしたときに、「これがあれば、自分でゲームをつくれるんじゃないか」と思ったんです。本を買ったり、インターネットで調べたりして勉強しようとしましたが、まったく分からず、挫折してしまいました。当時できたのは、簡単なホームページをつくるくらいでしたね。

大学進学を機に上京し、授業で初めてきちんとプログラミングを教わりました。コードを書けるようになって、「楽しいな」と感じたんです。3年生から学部が分かれる大学だったので、情報系の学部を選びました。

──　大学では、どのような研究をされていたのでしょうか。

学部ではロボットに搭載するAIを研究していました。研究室でロボットのサッカーの大会であるRoboCupに参加しており、サッカーをテーマにロボットの行動計画や機械学習を研究していました。

大学院では画像認識を研究し、画像や動画から写っている人物の行動を判定・予測することに取り組んでいました。

──　新卒でソニーに入社した後、どのようにキャリアを歩まれたのでしょうか。

コンシューマー向けのデバイスに興味があり、特にテレビやデジタルカメラなどの分野を代表するメーカーとして、ソニーを志望しました。

大企業かつ組み込みソフトウェアの開発現場を経験できたのはよかったのですが、インターネット企業に比べるとどうしても開発手法や開発環境にレガシーさを感じることはありました。

その頃、ちょうどスマートフォンが日本でも登場したタイミングで、趣味でAndroidアプリの開発をしていました。ちょうど急成長していたソーシャルゲームの会社がフィーチャーフォンからスマートフォンへの移行を進めているタイミングで、Androidエンジニアを募集していたのでグリーに転職しました。

GREEでは、ゲームプラットフォームのモバイルSDKやチャットアプリの開発を経験しました。その後、会社がモバイルゲームを強化する方針になり、以前の上司に声をかけてもらって、新規ゲームの立ち上げにも取り組みました。

今の私のエンジニアとしての土台を最もつくってくれたのは、GREEだと思っています。

──　特に、現在につながっている経験はありますか。

新規ゲームの立ち上げで、とても良いチームでものづくりができたことです。

もともとAndroidエンジニアとして転職したのでゲーム開発自体にはそこまで興味はありませんでしたが、そのプロジェクトはとても楽しかったんです。上司が素晴らしい方で、同僚もさまざまなチームから集まった精鋭でした。その経験は、今の私が理想とする開発組織のモデルの一つになっています。

その後、予約管理SaaSなどを開発していたクービックに入社しました。GREEで一緒に働いていた人が立ち上げた会社で、副業で手伝っていた流れから加わりました。これが、初めてスタートアップで働いた経験です。

社員番号が5番か6番くらいの初期段階で、マンションの一室のような場所から会社が大きくなる過程を経験しました。GREEにもスピード感はありましたが、スタートアップの開発や意思決定の速さは、それとはまったく違いました。

その後、担当していたサロンの予約アプリの開発をいったん止める話が出たタイミングで、Kyashに転職しました。1人目のAndroidエンジニアとしてアプリをゼロからつくり、後に開発のマネージャーも担当しました。

今のkickflowの代表である重松とは、そこで一緒に働いていました。重松がプロダクトマネージャーで、私がエンジニアという関係です。

──　重松さんと、再び一緒に働くことになった経緯を教えてください。

私はKyashの後は、メルカリに転職しました。以前から知っている優秀なエンジニアが何人もいましたし、ちょうどフィンテック部門であるメルペイを立ち上げている時期でした。Kyashの頃からFinTechには強い関心があり、事業内容と開発組織の強さに可能性を感じました。

優秀な方々と働けたことは良かったのですが、会社がグローバル化し、カルチャーが大きく変わる時期でもありました。マネージャーとして組織内の摩擦やトラブルへの対応が多く、精神的に疲弊してしまいました。

辞めようかと考えていた頃、SmartHRの子会社を運営していた重松から、「一緒にやらないか」と誘われたんです。

次に行きたい会社がなく、フリーランスになろうかとも考えていましたが、「重松とだったら、信頼して一緒に仕事ができる」と思い、加わることにしました。

顧客の課題を起点に、事業の可能性を見つける

──　重松さんには、どのような印象をお持ちですか。

「究極のゼネラリスト」という印象です。

今の会社では、基本的に私がプロダクト部門を、重松がビジネス部門を見ています。重松には、もともとSaaSの営業やカスタマーサクセスの経験があったわけではありません。それでも、試行錯誤しながら学び、ビジネス組織をつくってきました。

得意かどうか、やりたいかどうかに関係なく、やると決めたことは最後までやり切る人だと思っています。メンバーの気持ちを盛り上げたり、チームをつくったりすることも、とても上手な人ですね。

──　前身の事業から、kickflowを立ち上げるまでの背景を教えてください。

私が加わったのは、SmartHRの子会社で進めていた保険関連の新規事業でした。フルタイムのエンジニアやCTOがいなかったので、その体制を補強するために声がかかったのだと思います。

ただ、入社して間もなく、事業の方向性を見直すことになりました。入社した直後だったので驚きはありましたが、実際に営業していた重松の判断なので、特に異論はありませんでした。

その後、再びSmartHRの子会社として、重松と次の事業を考え始めました。

きっかけになったのは、2019年末頃のSmartHRでの出来事です。会社が大きくなるにつれてワークフローの導入が必要になっていたのですが、担当者の方がさまざまな製品を試しても「良いものが一つもない」と不満を持っていました。

私たちは、昔からある領域なので、良い製品があるだろうと思っていました。ところが、既存の製品が使いづらく、顧客が大きな課題を抱えている市場なのではないか、という仮説を持ったんです。

主に重松がさまざまな会社へヒアリングに行くと、多くの方が同じような課題を感じていました。それなら新しい製品をつくれば売れるのではないかと考え、始めたのがkickflowです。

──　中堅・大企業向けという方向性は、どのように定まっていったのでしょうか。

まずは、身近な企業に使っていただくところから始めました。その後、つながりのあった大企業から半年後くらいに受注できたんです。

さまざまな会社と商談する中で、中小企業よりもエンタープライズ企業の方が、課題が強そうだと気づきました。そこで、中堅企業やエンタープライズ企業を主な対象とする方針に転換しました。

2020年2月に株式会社kickflowを設立し、その後SmartHRからのMBOを経て2021年8月に独立しました。

──　Talentifyも、課題を起点に生まれたのでしょうか。

そうですね。最初のきっかけは、自社の社員が増え、人事評価の運用が大変になってきたことでした。

他社のタレントマネジメントシステムを導入したのですが、人事評価のフォームへの記入はできても、その後の評価調整をシステム上で完結できなかったんです。

当社では、各マネージャーがつけた評価を横並びで比較し、「この部署は評価が甘いのではないか」「この部署は厳しすぎないか」と調整する、キャリブレーションという作業を行っています。

その作業ができず、人事担当者が結果をGoogleスプレッドシートに転記していました。「システムを導入しているのに、その中で完結しないのはどうなのだろう」と感じたんです。

そこで、タレントマネジメントもワークフローと同じように、多くの企業が不満を抱えている領域なのではないかと考え、ヒアリングを始めました。「今使っている製品を100点満点で評価すると何点ですか」と聞いて、「5点」という回答が返ってくることもありました。

それなら自分たちでつくろう、というのが事業のきっかけです。当社はエンタープライズ企業の課題を解くことをミッションに掲げているので、ワークフロー以外にも課題があるなら、その解決を通じて新しい事業を立ち上げていこうと考えています。

一人が開発から運用まで担う、速さを支える体制

──　創業当初から現在まで、CTOとしての役割はどのように変化してきましたか。

担当領域は一貫してプロダクト開発全般ですが、働き方は会社のフェーズに応じて変わってきました。

最初の2年ほどは、私以外のエンジニアは業務委託の方だけだったので、重松がお客様と話し、私がひたすらコードを書くという形でした。

3年目くらいから正社員のエンジニアが入ってきて、チームのマネジメントや育成、開発プロセスの整備、他部署との調整が増えました。

一方、直近1年はTalentifyの立ち上げで、創業期に近い働き方に戻っています。私自身が一人で開発を進めることも多かったですね。ほかにも、人事評価制度の設計や採用チームの立ち上げなどを担当しています。

──　現在の開発組織と、一気通貫で開発する体制について教えてください。

兼務のメンバーも含め、プロダクト開発に関わる人数は、全体で25名ほどです。

基本的に、一人のエンジニアがバックエンドもフロントエンドも、運用まで担当します。一番の狙いは、開発速度を上げることです。

職能別にチームが分かれていると、新しい機能をつくるにも、各チームから人を出してもらい、調整する必要があります。担当が決まった後も、APIの仕様などをすり合わせ、合意してから進めることになります。

一人が一気通貫で担当すれば、自分で判断しながら進められるので、エンジニア間の調整やリソースの取り合いが発生しにくくなります。開発中の意思決定や調整にかかる負担を、小さくできることがメリットです。

フルリモートで仕事を進める上でも、こうした仕組みは重要だと思います。コミュニケーションコストの高い業務プロセスは、フルリモートと相性が悪いからです。

──　一人で幅広く担当するために、仕様を理解する仕組みも必要ですね。

オンボーディングには、かなり力を入れています。入社後の最初の1〜2週間ほどは、実際の業務に入る前に、集中的にオンボーディングを行います。

kickflowではRailsを使っているので、Railsで課題として設定したアプリケーションをゼロから開発する研修もあります。プロダクトの仕様も細かくドキュメントに残していて、社内ツールで検索したり、AIに聞いたりすれば、大体のことは分かるようになっています。

入社したメンバーからは、「スタートアップなので、オンボーディングや仕様書はそれほど整っていないと思っていたけれど、想像以上に整備されていて驚いた」という声をよく聞きます。

──　技術選定では、どのようなことを重視していますか。

Railsを選んだのは、自分が慣れているものを採用した方が高速に事業を立ち上げられることが大きな理由です。それまでのキャリアはモバイルアプリ開発が中心だったのでバックエンドの開発経験は豊富ではなかったのですが、唯一クービックにいたときにRailsで開発した経験がありました。

加えて、日本にはRailsエンジニアが比較的多いので、採用のしやすさもあります。「Rails Way」と呼ばれる標準的な開発の進め方に沿えば、小規模なチームでも生産性を出しやすいことも理由です。

フロントエンドにはVueを採用していますが、Reactに比べると標準的な構成が示されている点はRailsに近いかもしれません。エンジニアが増えたときに技術選定や書き方で議論するよりも、お客様に価値を届けるためのコードを書くことに集中したいという思いがあります。

創業期のインフラにはHerokuを採用したのですが、これもインフラの構築や保守よりもアプリケーションの開発に時間を使いたかったからです。現在はリージョンやコストの都合でGoogle Cloudに移行しましたが、できるだけマネージドサービスに寄せるという思想は現在も貫いています。

顧客の要望の奥にある課題を理解し、品質に投資する

──　エンタープライズ向けのプロダクト開発で、難しいと感じるのはどのような点ですか。

会社ごとに運用が違う一方で、SaaSとしてすべてのお客様に同じアプリケーションを提供していることです。特定の会社だけに特化した機能を、そのまま搭載するわけにはいきません。

汎用的なプロダクトをつくりながら、どうお客様の課題解決につなげるか。その両立が難しいところです。つくるべきではなかった機能をつくったことも、必要な機能をつくるのが遅かったと反省することもあります。

そのため、社内では「お客様の言っていることを、そのまま鵜呑みにしない」と繰り返し伝えています。

例えば、「前の製品にあったので、この機能が欲しい」と言われたときに、そのままつくるのではなく、その機能で何を実現したいのかを理解します。

やりたいことが分かれば、既存の機能で代用できるかもしれません。あるいは、別の機能をつくった方が、より汎用的にさまざまなユースケースへ対応できる場合もあります。まず課題をきちんと理解してからつくることを、大切にしています。

──　開発の速さを維持しながら、品質をどう担保していますか。

初期からQAの体制をつくってきました。エンタープライズ向けのSaaSは仕様が複雑で、機能の組み合わせによるテストケースも多く、開発者だけですべてを確認するのは大変だからです。

当初は外部のベンダーに依頼していましたが、QAエンジニアの入社後、社内の組織も拡大してきました。開発エンジニア10人に対してQAが4人ほどという人数比で、品質にはかなり投資していると思います。

また、当社では、先に仕様書を固めてそれをもとにAIで実装する「仕様駆動開発」を採用しています。その仕様書は、QAチームが正しい仕様を確認するときにも、テクニカルサポートの担当者がユーザー向けのヘルプを作成するときにも使っています。

──　セキュリティについては、どのように取り組んでいますか。

品質と同じく、創業初期から重視しています。しっかりしていなければ、そもそも導入していただけません。

毎年1回、外部のベンダーに脆弱性診断を依頼し、見つかった問題を速やかに修正しています。会社全体ではISMS認証を取得し、情報セキュリティの管理体制を運用しています。

クラウドセキュリティに特化したISO/IEC 27017の認証取得も進めていますし、AIによる脆弱性スキャンにも取り組んでいます。

AIが変えるエンジニアの役割と、組織の課題

──　AIの活用によって、エンジニアの仕事はどう変わっていますか。

働き方は大きく変わりました。2年ほど前は、私もすべて手でコードを書いていましたが、今はほとんど書いていません。

設計や実装にかかる時間がAIによって縮まったことで、エンジニアが従来プロダクトマネージャーの担っていた要件定義に取り組んだり、お客様と直接話したりするようになっています。

技術を理解していることに加えて、ビジネスや顧客への理解、ドメイン知識も求められるようになっていると感じます。今いるメンバーには、そうした力を身につけてもらえるよう育成していきたいですし、採用でもAI時代の働き方に適応できる人を迎えたいと考えています。

──　会社として、AIを活用しやすい環境も整えているのでしょうか。

エンジニアだけでなく、ほかの職種にもAIツールを提供しています。必要な投資だと経営として判断していて、複数のAIを使い比べられる環境もあります。

全社的にAIへのリテラシーが高いので、業務改善や新しい開発フローを提案し、実行しやすいことは、組織の魅力だと思います。

ただ、ツールを提供するだけでは十分ではありません。人間が仕事をする前提でつくられてきた業務プロセスを、AIエージェントが仕事をする前提へ変えていく必要があると思っています。

Talentifyは最初からAIを前提に開発フローをつくっているので、kickflowのチームと比べてもかなり速いんです。単純には比較できませんが、当社にも、まだ生産性を向上させる余地は大きく残っています。

そこは私がトップダウンで変える必要もあると考えています。ただ、人によって生産性の上がり方に差があり、それが能力によるものなのか、使い方によるものなのかは、まだ十分に見えていません。その点には難しさを感じています。

──　組織づくりでは、ほかにどのような課題がありますか。

会社全体で、マネージャーや部長・本部長といったポジションに対して人材が足りていません。kickflowの開発チームでは、1人目のエンジニアがマネージャーを務めていますが、メンバーが増え、負担が大きくなってきています。次のマネージャー候補の育成や採用が、重要な課題です。

採用と内部からの登用の両方を考えていますが、外部から採用した人を、いきなりマネージャーに任命する方針ではありません。中長期的にマネージャーとして活躍してもらうためには、まずは現場の業務を理解してもらい、メンバーとの信頼関係を構築する時間が必要だと考えているからです。まずプレイヤーとして成果を出してもらい、その上で登用する形を考えています。

勝ち筋のある事業を育て、少数精鋭で大きな仕事をする

──　今後の事業の可能性を、どのように捉えていますか。

タレントマネジメントとワークフローは、基本的に成長を続けている市場だと捉えています。

最近はAIの普及を背景に「SaaS is dead」と言われますが、当社や他社の実際のKPIを見ている限り、AIによって業績が傾いているとは感じていません。

一方で、AI時代に対応できないSaaSが、対応した新しい世代のSaaSに置き換えられていくような再編は起こると思います。当社は、その変化を起こす側に回りたいんです。大きな変革期に、SaaSの領域で大きな企業に挑んでいけることは、やりがいの一つです。

また、使いやすいソフトウェアを提供することで、お客様の業務を改善し、働く人のストレスを減らしていく。そうした社会的な意義もあると思います。

──　今後の目標やビジョンを教えてください。

会社としてはIPOを目指しています。そのために、kickflowをさらに成長させ、ローンチしたばかりのTalentifyも育てていきます。新しい事業の立ち上げも考えています。

ただ、バックオフィスのすべての領域に対して無闇矢鱈にSaaS事業を展開しようとは考えていません。お客様が課題を抱えていて、当社に勝ち筋がある領域に事業の柱を立て、それぞれをきちんと育てたいと思っています。

一つひとつの事業に手間をかけて、着実に伸ばしていく。そうした成長を実現できる組織をつくりたいですね。

製品のラインナップを大幅に増やす予定はないので、人数をどんどん増やしたいという気持ちも、それほどありません。できるだけ少数精鋭で、大きな仕事をしたいと考えています。

顧客の課題を見つけ、解き方から考えたい人と働きたい

──　どのようなエンジニアと、一緒に働きたいと考えていますか。

まずは、当社の4つのバリューを体現している人です。実際に活躍しているメンバーにも、そうした人が多いと感じます。

エンジニアに限って言えば、お客様の課題解決や業務に興味を持てることが、特に重要です。誰かに言われたとおりにものをつくるだけではなく、自分で課題を見つけ、どう解決するかを考えて仕事を進められることが、これからは必要になると思います。

そのため、渡された仕様書をもとに実装するだけでなく、もっと仕様を考える段階から関わりたい、という熱意のある人にとっては、とても良い会社だと思います。

また、オンボーディングなどは整備していますが、当社はスタートアップです。求められるスピードは速いですし、役割がきれいに分業されているわけでもありません。幅広い仕事に、臨機応変に対応することを苦に感じないことも、大切だと思います。

──　御社では、どのような経験やスキルを得られるのでしょうか。

特定のスキルというより、総合力を高められると思います。

設計、実装、運用といったエンジニアとしての経験はもちろん、要求定義や要件定義など、より上流の経験も積めます。プロダクトマネージャーに近い仕事にも関われるので、将来的にそちらへ進むキャリアも可能性があります。

また、AIを前提とした業務フローを、常に取り入れようとしています。AIをコーディングだけに使っている会社と比べると、仕事を任せる範囲が大きく異なります。

AIとどのように働き、どう使いこなすか。その経験も、当社で積めるものの一つだと思います。