フルリモート×少数精鋭でエンタープライズ企業の課題解決を実現するkickflowの開発組織論

2021年8月に創業した株式会社kickflowは、稟議・ワークフローのクラウドサービス「kickflow」を展開しています。組織構造や意思決定・承認フローが複雑になりがちな大手・エンタープライズ企業を中心に導入が進み、創業4年ほどで導入企業数は約200社に到達しました。

CTOの小林さん・EMの森本さんは、エンタープライズ企業のニーズに的確に応えることができている背景には「スピード」と「品質」があると言います。企業によっては二項対立しがちなこの二つの要素を少数精鋭の開発組織でどのように両立しているのか、また、それらを支える開発体制や組織の文化に迫ります。

単機能に絞った戦略でエンタープライズ企業の課題に応える

――kickflow社の概要と事業の特徴について教えてください

小林：kickflowは2020年にSmartHRさんの子会社として設立・スタートし、2021年にMBO（経営陣による買収）により独立したスタートアップです。創業当初の2～3年ほどは、IT系ベンチャー企業のご導入が多かったですが、最近の新規導入に関しては業界・業種もさまざまで、大手ホテル事業者や大学法人、不動産会社など多岐にわたります。規模感としては少し幅が広いですが、従業員300名から5,000名の規模感の企業に多くご導入いただいていますね。

創業当初は、当時300名ほどの規模だったSmartHRさんと同規模の企業群をメインのターゲットとしていましたが、中小企業向けのクラウド型ワークフローSaaSとして競合になりうるプロダクトはすでに市場に多く存在していました。

一方で、大企業の方にお話しを聞きにいくと、組織規模が大きくなるほど”かゆいところに手が届かない”などの悩みを抱えていることが分かりました。

――大企業が抱えている“課題”にはどのようなものがあったのでしょうか

小林：従業員が増え組織規模が大きくなるにつれて、企業の組織図や承認経路、意思決定フローがどうしても複雑になり、ワークフロー製品に求められる要件も複雑になりがちなのですが、これに応えられる製品がない、というのが一番大きな課題です。

また、導入されている製品はまだまだオンプレ型も多いのですが、ゴリゴリにカスタマイズした上で導入されているケースもあるので、導入後に「この申請フォームを少し手直ししてほしい」といったニーズが、現場で利用する社員から上がってきても、ベンダーに依頼しないと物事が進まないという現状もありました。

結果的に、現場からワークフロー製品に対する不満がたまるだけでなく、「うちの情シスが動いてくれない」など情シスの社内における立場が悪くなってしまう、といった状況も生まれていました。

一社一社にヒアリングを重ねる中でこうした状況・課題に対する解像度があがり、そこからは中堅・大企業をメインターゲットに据えて開発を行っています。

――SaaS企業の中には“マルチプロダクト戦略”を掲げる企業も多い印象ですが、kickflowがワークフローという単機能に特化させているのはなぜですか？

小林：SaaS企業の戦い方として２パターンあると捉えています。

freeeさんやジョブカンさんのように、勤怠や経費清算、ワークフローと幅広いラインナップで“面を取りに行く戦い方”と、SmartHRさんであれば人事労務領域、Sansanさんであれば名刺管理領域という“特定の領域に根ざしてプロダクトを伸ばしていく戦い方”。

特に大企業のニーズに応えるような製品をつくるにはやはり時間を要するので、僕たちが「ワークフローでスタートして中堅・大企業をターゲットにする」という方針を決めた段階で、後者の戦略を選択しました。

規模の小さな会社で数多く使ってもらうのか、導入数は少なくとも中堅・大企業を中心に開拓していくのか、という戦略の違いと捉えていただくとイメージしやすいかもしれません。いたずらに製品数を増やすというより、大企業の課題を解決できるような製品をいくつか携えている状態にしていくイメージですね。

実際に導入企業から、経費精算機能をつくって欲しいというご要望をいただくこともありますが、現状は着手していません。いずれは新規事業という形で製品化していくことも考えられますが、現在は、ワークフローという軸で企業のニーズに応えられるような機能開発を、スピード感を持って進められるような意思決定・リソース配分を行っています。

スピードと品質の両立を支える、「小さくて強い」組織

――中堅・大企業の課題をどのようにキャッチアップし、プロダクトに反映させているのか教えてください

小林：現状では営業やカスタマーサクセスチームが実際に企業からヒアリングしたフィードバックをFlyle（※1）に貯めていき、プロダクトマネージャー（以下、PdM）とプロダクトマーケティングマネージャー（以下、PMM）を中心に開発ロードマップを策定する際の参考としています。

（※1）Flyle：顧客フィードバックの分析やアイデア管理、ロードマップ作成が行えるプロダクトマネジメントプラットフォーム

――多い時には週1件以上の機能アップデートを行っていらっしゃいますが、そのスピードはなぜ実現できているのでしょうか

小林：大きくは2つあります。1つ目は先ほどの内容にも関わるのですが、企業の本質的な課題を見極めて開発スコープを定めていることです。

営業やカスタマーサクセスのオンボーディングでは僕からも、「企業の“欲しい機能”ではなく“課題”をキャッチアップしてほしい」ということと、Flyleにも「“企業の課題”と“担当者の主観”を分けて記載して欲しい」と伝えています。

森本：このように実際に企業と相対しているチームの声を元に、要件を全て満たす最大公約数的な機能開発ではなく、本当に解決しないといけない課題は何か、その課題を解決するための最小限のソリューションは何か、という議論を行いスコープを定めることができています。

小林：機能開発・機能改修の方向性はPdM・PMMが中心となって決めていますが、ただ上から降りてきた決定事項に従って開発を行うような、納得感のない仕事ってつまらないじゃないですか？

なので、開発メンバーが納得感を持って進められるように、PdM・PMMがつくったたたき台を開発メンバー全員がレビューしたうえで、最終的な仕様を確定させるようなフローにしています。

弊社は地方在住者も含めて基本的には完全フルリモートなので、このような取り組みは属人化や情報格差を抑止することにもつながると思います。

森本：こうした小さい組織ならではの機動力の高さを生かした情報共有や意思決定を行えていることが、競合と比べて柔軟に価値提供できていることにもつながっていると思います。あとは、意思決定の軸として“やらないこと”も決めていますね。

たとえば、中小企業から特定の機能の追加や仕様に対する多くのフィードバックがあっても、私たちが向き合っている中堅・大企業の実際のユースケースに即さない場合は、あえて“やらない”判断をすることもあります。

――高いスピードを実現できている、2つ目の要因はなんでしょうか

小林：特定の職能にとらわれずに高いパフォーマンスを発揮できる、マチュアな人材が多く集まっていることです。

組織規模が大きくなると、職能別組織のようにエンジニアも分業化していくことがままあると思いますが、kickflowではバックエンドもフロントエンドも全部その人が担当することになります。

そのため開発が始まってからエンジニア間でAPIの仕様を調整するのに時間をかける必要がないですし、各チームから人を出してもらうためにリソースを調整する、みたいなあるあるも一切発生しないことも、高いスピードの要因になっていると思います。

――このようなスピード感のある開発と品質の担保は、どのように両立させているのでしょうか

小林：高頻度で機能追加していることもあり、kickflowの仕様は複雑性が高く、開発者が影響範囲を網羅的に把握するのは難しい状況です。

そのため、開発者5名に対してQAチームは8名体制（社員2名＋ベンダー6名）とかなり手厚くしています。特にE2Eテストの整備に力を入れており、主要なユーザーのシナリオに関しては自動でリグレッションが検知できるような仕組みを構築しています。

森本：実際に週に2、3回は検知されていますね。またライブラリのアップデートについては、最新に追いつくようにほぼ毎日のようにマージしているのですが、1件1件に対してQAエンジニアを張り付けることができないので、先ほどのように仕組みで解決している部分もあります。

この体制と仕組みによって、エンジニアが安心してリリースでき、技術的負債も最小限に抑えて、かつ、クリティカルな不具合が発生しないような状況にしています。

拡大フェーズの葛藤とカルチャー維持への挑戦

――今後導入企業数が増える中で、意思決定や開発スピードなどの“機動力”を担保するのは大変そうですが……

小林：まさに過渡期を迎えていると認識していまして、実は前述のPdMとPMMを中心とした意思決定のプロセスも、それぞれの着任（PdMは新たに入社、PMMはセールスチームからの異動）をきっかけに、今年の5月ごろからスタートし、チューニングしながら進めているところだったりします。

2人の着任までは僕と森本とデザイナーの3名体制で、3カ月に一度フィードバックの取捨選択をしていたのですが、1カ月に100個近くフィードバックが貯まるようになってきた頃から回らなくなってきてしまいました。3人で3時間くらい作業して「今日も終わらなかった……」という日もありました（笑）。

そこから、PdM・PMMが中心となって取捨選択を行い仕様のたたき台をつくった上で、開発メンバー全員でレビューし意思決定する、という現在の運用にしたことで、短いスパンでの取捨選択と、意思決定のスピードの担保ができるようになりました。

ただ、今後事業も組織も大きく成長していく中で、これまでのように全員と同期しながら意思決定するのは難しくなっていくかもしれません。それでも、今のような凝集されたチームで、機動力高く動ける状態はできる限り保ち続けたいので、状況に応じた最適な進め方をその都度考えていく必要があると感じています。

現状はやりたいことに対して人手が足りない状態ですが、Amazonのジェフ・ベゾス氏が提唱した”Two Pizza Rule”にならい、1プロダクトあたりのチーム規模を増やしすぎない方向がいいかなと。

今後メンバーが増えたら、並行して立ち上げている新規事業のチームにも一部が参画し、さらに増えたら新たなチームを立ち上げる――そんなふうに”小さくて強いチーム”を繰り返し形成していくイメージに近いです。

――そのほかに取り組んでいること、取り組もうとしていることはありますか

森本：現場からのボトムアップや自走力も高めていきたいですね。

直近では現場からの発信を元に、RBS / RBS::Inlineを導入しました。元々、各々が最近気になっているトピックや技術・ツールの共有などをし合う“勉強会”を開催しているのですが、あるエンジニアが、今年のRubyKaigiでキャッチアップしたRBSについて共有をしてくれたんです。

どうやらコストを抑えてリプレイスできてAIコーディングとも相性が良く、今後主流になりそう、という話で、その日中に導入を決めました。YARDからRBS::Inlineへの移行もAIを活用して一気に進めました。検討・意思決定・実行までを短いスパンでやりきった、一つの事例だと思います。

制度面でも、現場の動きを後押ししています。出張・宿泊を含めたカンファレンス参加費の補助や、電子書籍含む技術書の会社負担など、個人のインプットをサポートする仕組みは強化しています。

一人ひとりの生産性を高めるという意味でも、AIの活用は積極的に進めています。Roo CodeやClaude Codeをコーディングで活用したり、コードレビューではGitHub CopilotやCodeRabbitに加えて、最近はClaude Code GitHub Actionsも導入しました。それぞれに強み・弱みがあるので、広くキャッチアップしつつ、アップデートに応じて最適な活用法を模索しているところです。

小林：開発部門だけでなく、全社的に“AIを使って当たり前”な文化を醸成したいと思ってます。その一環として、全社員にDifyを配布し、今年7月には一人ひとつアプリを開発するコンペも開催しています。

ChatGPTをはじめとしたAIツールが広く使われるようになったこの2年ほどで、“少人数でも生産性の高い組織”にシフトしていく必要性をより強く感じていますし、AIを前提とした時代に取り残されないためにも、全員がツールと自然に付き合える状態を目指しています。

開発職は“AIで何ができるか”を理解しているだけで、新しい機能のアイデアや実装の選択肢が増えるし、営業やCSであってもこれまで対応できなかった企業からの要望に対して、AIを使えば実現できるかもという視点が持てるようになりますよね。

“できなかったことが、できるようになる”この感覚を、職種問わず全員が持てるようにしていきたいですね。

“強くてニューゲーム” 変化を楽しみながら、次のkickflowを一緒につくって欲しい

――最後に、どんなエンジニアにkickflowはおすすめでしょうか？

小林：“技術を使って課題解決をするのが好きな人”には、すごくフィットする環境だと思います。

僕たちが向き合っているのは、エンタープライズ × ワークフローという、複雑で表に出づらいけど、根深い課題です。営業やカスタマーサクセスと連携しながら、エンジニアリングでプロダクトを進化させ、それが事業成長に直結していく──この循環をスピード感を持って回せる環境って、なかなかないと思います。

また、一人ひとりの守備範囲が広い分、自然とスキルの幅も広がるし、AIをはじめとする新しい技術にも積極的に投資しているので、新しい開発スタイルや開発プロセスを業務の中でどんどん試せるのもエンジニアには嬉しい環境なんじゃないかと思います。

森本：過去の経験を振り返ると30人規模の組織フェーズが一番面白かったんですよね。あの「売上をどうやって伸ばしていく？」みたいな会話をみんなでしながら開発を進めていく経験がすごく面白くて。エンジニアとしていろいろ経験した上で、あの時よりもう少し小さい規模にジョインしたい、という思いもあってkickflowに入社しているのですが、そうした、いろいろな経験を経た上で”強くてニューゲーム”をやりたい人には良い環境と言えると思います。

一方で、プロダクトも組織においても課題や未整備なものが多くあります。

そのため、プロダクトで言えば、特定の技術をどのように適用していくかに興味関心がある方よりも、今の現状を踏まえると1年後のプロダクトはこうなっていって欲しいから、こういう機能を作っていこうと”プロダクトを一緒に育てていく感覚に共感いただける方”の方が合うかなと思います。

また、フルリモート環境でのコミュニケーションを成立させるためにも、仕様や意思決定プロセスをドキュメント化して管理する文化は徹底していますが、そのほかの制度や組織の仕組みにおいてもまだまだ行き届かないところはあります。

大手企業のように出来上がった組織ではなく、今後の事業や組織の成長・変化に合わせて一緒に楽しみながら最適解を模索し、これからのkickflowをつくっていってくれる人にご入社いただきたいですね。