1. LayerX NOW!
  2. [特別編]「バクラク」CTOとVPo..
2025-12-25 38:05

[特別編]「バクラク」CTOとVPoEが明かす、急成長する組織で爆速開発を叶える秘訣

「謎に包まれている」と言われることが多い、LayerX バクラクの開発チーム。「爆速開発」と呼ばれるその開発スタイルは、「2〜5人」の少人数チームで構成されています。バクラクのCTO、VP of Engineering (VPoE) の2人が、その裏側をたっぷり語ります。・1年でリクエスト量が2倍に成長・下半期だけで新規プロダクトライン4〜5本が並行稼働・AIを活用した「業務の自動運転」への挑戦・70人以上のエンジニアで10以上のプロダクトを同時開発・1チーム2〜5人の少人数体制・毎週のレビュー会は「ボリュームが多すぎて収まらない」・「開発がエネルギー補給になっている」という働き方Bakuraku Engineering Team Deck(バクラク エンジニアリング チームデック)https://speakerdeck.com/layerx/bakura...LayerX エンジニアブログhttps://tech.layerx.co.jp/Xアカウント @layerx_techhttps://x.com/LayerX_tech


▼LayerX Now!とは・・・

こんにちは、LayerX NOW!です。LayerXの日常を伝えるPodcast『LayerX NOW!』は事業やチームの話を中心に、"いま知っておくべき"LayerXのホットなトピックスをお届けしていきます。時々社外ゲストの招待があるかも!お楽しみに!

サマリー

特別編では、バクラクの急成長と爆速開発の秘訣について、CTOの吉木氏とVPoEのカニー氏が語ります。バックオフィス領域の課題解決に焦点を当て、AI技術を活用したプロダクトの進化や組織の変化にも触れています。ポッドキャストでは、バクラクの組織が顧客中心の開発や爆速開発を実現するための戦略を紹介し、AIエージェントへの取り組みやチームのエネルギーの補給方法が重要な要素として挙げられています。この開発プロセスの変化が組織全体の成長に寄与しています。彼らはお客様の声を重視しながら、開発のスピードと質の向上を目指すアプローチを示し、AIエージェントを通じた業務自動化のビジョンにも触れます。また、急成長する組織内での爆速開発の秘訣において、特にAIネイティブなSaaSの進化と顧客志向のエンジニア組織の重要性に焦点を当てています。技術力の高いメンバーが集まり、顧客のニーズに応える開発を行う姿勢が強調されています。

バクラクの急成長
急成長中のバクラクの今。
エンジニアチーム、実は割と謎に包まれている感じになってて。
LayerXの印象と、実際に中で働いている風景みたいなのが全然違うなと思っていたりする。
なんでLayerXでは、バックオフィス領域の課題っていうところの解決にフォーカスをしているのか?
バックオフィスの機能がない会社さんって、ほぼないと思うんですよね。
日本の労働需給のギャップっていうのが、2040年に1100万人。
同じ仕事量を今より少ない人数でやれって言われたら、多分まず無理だと思うんですよ。
その課題を徹底的に解決していくっていう。
開発スピード、爆速開発っていう、これってどれくらい早いんですか?
レビュー会の中でも、結構ボリュームが多すぎて収まんないみたいな。
開発物が毎週すごくいっぱい出てくるんですよね。
バクラク全体の大きなテーマは、業務の自動運転みたいなことを言ってたりするんですけど。
全ての働いている方に届けたいようなものを、みんなで作っているっていうところがあって。
AIネイティブなサーツに進化していくのに、必要な変化っていうのをしていくっていうところが、
これからの一番でかい課題の一つかなと思っています。
皆さんこんにちは。レイヤーXのちあきです。
本日は、バクラク事業部CTOの吉木さん、VPOEのカニーさんのお二人をお招きして、
12月2日にリリースしたバクラクエンジニアリングチームデックの内容を使いながら、
組織プロダクトとともに急成長中のバクラクの今。バクラクらしいプロダクト作りと爆速開発を両立する秘訣。
プロダクトと開発の進化
今取り組んでいる課題やAIエンジェントの開発、プロダクトの組織との展望について、いろいろと話を伺っていきたいと思っております。
バクラクエンジニアリングチームデック、12月2日にリリースしてまして、もうすでに6,000ビューを超えてるんですかね。
6,000。結構でかいですね。
たくさんの方にご覧いただいております。
そもそもこのデックを作ったきっかけみたいなところから伺いたいなと思うんですけど、吉木さんいかがですか。
そうですね。一番の目的は、バクラクの組織、今の開発組織、他のチームにないような良い点を持ってるかなというふうに思っていて、
そういうところを広い方に知っていただきたいという点と、
専攻の中だったりとか、あとはカジュアル面談という形とかで、お会いする社外の方々から見たときのレイエックスの印象と、
実際に中で働いている風景みたいなのは全然違うなというふうに思っていたりするので、
そこのギャップみたいなところを埋めながら、ただ実際に話していくと雰囲気の良さだったりとか、
あとはどんな技術レベルのメンバーがやってるんだっけとか、具体のフィーチャー開発どうやってるんだっけとかというところ、
もっともっと伝えていきたい部分が多かったので、そこを広めたかったのが一番の理由になります。
実はレイヤーXってエンジニアリングチーム実は割と体系的には謎に包まれているという感じになってて、
外からカジュアル面談とかでお話をする機会をいただいたときにも、
実際どういうことやってるんですかとか、そもそも何人ぐらいの規模なんですかみたいな、
そのすごいベーシックなところから、やっぱりその実際の活動のところまで、
いろいろ興味持って聞いていただける方がすごい多いなというふうに思ってるんですけれども、
そういったベーシックな部分をまとめてぜひ紹介したいなというところと、
またやっぱり物を作る集団としてのレイヤーXですとか、
いろいろある調整に関してやっぱりすごく伝えたいなと思って、
今回作ることにしたというところですね。
改めて今回の動画を見ていらっしゃる方の中には、
レイヤーXのことだったり爆落についてよく知らないという方もいらっしゃるかなと思いますので、
吉木さんからレイヤーXと爆落というプロダクトについて、
簡単に資料を使いながらご紹介いただければと思います。
我々の会社でいきますと3つの事業が独立してあるという形になっております。
1つが我々所属しているAIサービスのやる爆落の事業と、
もう1つがAIワークホフトと呼ばれているエンタープライズ向けのAIサービスというところを提供しております。
もう1つがAIDX事業というところで、
三井武さんさんの大面会社でデジタルアセットマネジメントという会社があります。
ここの3事業の関係性みたいなところを結構聞かれたりすることが多かったりするんですけど、
私よく説明しているのは3つ透明な会社があるみたいな形で、
内部のスラックのコミュニケーションだったりとか、
全社の手入れみたいなところは共通でやりながらも、
エンジニアリング組織としても交流だったりとか、
横の繋がりみたいなところは持ちながらなんですけど、
やっぱり1個1個の事業というところはお互いが干渉せずに進んでいくと言いますか、
独立した意思決定をどんどん進めていくみたいな形で進んでいるので、
透明な3つの会社が見えている状態なのかなというふうに説明していたりしています。
爆落についてなんですけど、
基本的に我々が提供している今のサービスの領域というところはバックオフィスというところで、
コーポレートの方だったり経営の方だったり人事労務の方だったり、
そういった方々が日々使うものと、
あとは従業員サイドとして経費生産のために使う法人カードだったりとか、
あとは自分で経費生産を上げますとか勤怠だったりとか、
従業員向けのところも展開していて、
よく言っているのは管理者の方から従業員の方まで滑らかな体験みたいなところを
届けていくというところを取り組んでおります。
最近だとAIアジェントみたいなところで、
どれだけサービスのなめらかさだったり自動化だったりというところを目指していまして、
自分たちが持っているサービスの面積はとても広いし今後も増えていくんですけど、
ここをちゃんとAIを使って自動化していくというところが、
一つ爆落としての大きな躊躇期で考えているミッションというか、
大きいテーマかなというふうに考えております。
組織運営の変化
ちょっとカニさんにも追加で伺いたいんですけれども、
なんでLayerXでは特にこのバックオフィス領域の課題というところの解決に
特にフォーカスをしているのかというところをお聞かせいただきたいなと思うんですけど。
はい。いろんな会社さんがある中でバックオフィスの機能がない会社さんってほぼないと思うんですよね。
それぐらいやることが避けられない領域というか必ず必要な機能だと思うんですけど、
一方でバックオフィスの領域に取り組んでいらっしゃる方の仕事ってめっちゃ大変なんですよ。
私も前職からずっとバックオフィスの業務システムであったりだとか、
今でも関わっているところではあるんですけど、
もちろん例えば経理とか人事みたいな形で、
業務に対しての専門性というところはもちろん求められると思うんですが、
それに加えて例えばですけど、領収書を出してくれない人にリマインドしたりだとか、
あとはみんなからの質問に答えたりとかですよね。
このルールってどうなってるんでしたっけみたいな質問とか、
多分働かれてる皆さんも誰しも一度ぐらいはやったことあるんじゃないかなというふうに思うんですけど、
かと思えば未来の組織に関わる設計をする必要があったりですとか、
その仕事の幅がすごい多岐に渡るし、
おまけにその仕事の性質っていうところも結構異なったりとかするんですよね。
今、日本の労働需給のギャップっていうのが2040年に1100万人っていうふうに言われていまして、
実際2040年迎えたときに同じ仕事量を今より少ない人数でやれって言われたら、
多分まず無理だと思うんですよ。
なんですけど、ただ仕事量が2040年に減ってるかと言われると多分減ってないと思うんですよね。
そこに対して少子高齢化っていう社会課題を解くのにバックオフィスにフォーカスして、
その課題を徹底的に解決していくっていうことそのものが今は我々にとってすごく大事なことなんじゃないかなというふうに思っているというところですね。
ではここからですね、また本題にまた入っていきたいなと思うんですけれども、
今レイヤーXは今全社で500人を超える組織になっていますと。
それと同時にですね、爆落の開発組織も大きくなってますし、
社内のエンジニアも増えて、またプロダクトの数も増えて、
そして爆落を使ってくださるお客様の数もユーザー数も増えていますっていうところだと思います。
この1年で組織としてどれぐらい大きくなっているのかっていうところ、
開発組織に大体どれぐらいのエンジニアさんが入ってきているのかみたいなところをちょっとカニンさんに伺えたらと思うんですけど。
はい、爆落の開発チーム全体では70人以上エンジニアがいる状態になっていまして、
これは昨年と比べると20人ぐらい増えているっていう計算ですかね。
なので全体だともう20%ぐらいどんどん増えてきているというような形になっています。
ペースを落としていくというよりはむしろより積極的にどんどん人を採用していきたいというところはあるので、
それがさらに成長していくと基本的には考えていただくと良いのかなと思っています。
吉木さんに伺いたいんですけど、この爆落シリーズのプロダクト数というのは今後また新しいプロダクトのリリースも控えてますし、
使ってくださっているお客様も増えているということで、どれぐらいこの1年でユーザー数が伸びてきた?
リアルな数字というのはまだ外部に公開していなかったりするんですけど、
我々エンジニアから見たシステム的なところでいきますと、
爆落のリクエストを全て受けているようなサーバーがあったりするんですけど、
そこのリクエスト量とかって2倍とかになっていたりして、
特に月末・月初みたいなところってお客様がヘビーに使われている、
勤怠システムもそうですし、承認の領域もそうですけど、かなり使われていて、
そこのリクエスト数というのはもう去年と比べると倍になっているという形で、
なかなかTUBIの中でもかなりヘビーなリクエストを受けているかなというふうに思っていますし、
それに伴う責任といいますか、自分たちの求められる技術力みたいなのも高まっているかなというふうに、
今後やっぱりスケールする技術というのは全然また違う領域として磨いていかないといけない、
強みにしないといけない部分かなというふうに思っていますね。
その短期間でプロダクト的にも組織的にも結構大きな変化が起きているところかなと思うんですけれども、
今まで通りに開発が進まなくなってしまったりだとか、
ちょっと組織運営の形、見直さなきゃいけないことが出てきたりとか、
そういうことって今の時点であったりしますか?
そうですね。組織運営というところだとそこまで大きなものはなかったりするんですが、
やっぱりSaaSとしてお客様に広く使われていっているという文脈というところだと、
お客様からのお問い合わせだったりとか、あと不具合の報告だったりとかというところに、
自分たちがどうやって真摯に向き合っていくかというのと、
それと新しいプロダクトの開発だったりとか、新しいフィーチャーの開発みたいなところというのを
どう両立していくかというのは結構考えながらというか、
プロダクトチームの中で試行錯誤しながら進んでいっている部分かなというふうに思っていますね。
会社のフェーズの変化に合わせた制度変化であったりだとかというところはありまして、
爆落のエンジニアリングチームというよりは会社全体ですけど、
報酬制度の見直しがあったりですとか、
グレードの制度を社内で運用しているんですけど、
そのグレードの再設計であったりだとか、
そういったものはここ2年ぐらいで起きてきた全体の変化かなというふうに思っています。
加えてやっぱり人数が増えてきて、採用のペースもどんどん上がってきてというところで、
採用のプロセスに関しても、
応募いただいている方をできるだけお待たせしないような形で、
かつお互いの理解が進むような先行のプロセスに、
うまく我々のプロセスを変えていくであったりだとか、
伸びていく組織スケールであるとか、
組織負荷に対応するための変化というところは、
徐々に徐々に起こしているというところかなと思っていますね。
この1年振り返っていただいて、
お二人が個人で特にチャレンジングだったことだったり、
これは大変だったなっていうような、
何か乗り越えたことだったりとかあれば、
ぜひエピソードを伺えると嬉しいなと思うんですけど。
変わったなというところでいくと、
やっぱり組織とか採用に時間を使うということが、
2024年と比べると、
2025年すごく増えたなというのはありますね。
ネガティブな意味では全くなくて、
フェーズの違いみたいなところを自分で認識する、
エネルギーと働き方の変化
すごくいいきっかけになったなというふうには思っていますね。
それなりにエネルギーを使う業務というか、
そういうものがすごく増えたなみたいな、
評価もそうですし採用もそうですし、
増えたなという中で、
一方で自分のエネルギーをちゃんと補給できる業務というか、
その開発を自分でやっていくとか、
チームと一緒にこういう方向性を磨いていこうとか、
こういうプロダクトの方向性をやっていこうみたいなところを話している時間とかって、
やっぱり違うエネルギーとして補給されているところもあったりするので、
そこが自分の時間の使い方も変わりましたし、
働き方としてなんかちょっと一個変わったかなというところかなと思いますね。
一種の王室としての開発という。
そうですね。
開発がエネルギー補給なんですね。
自分に求められているレバレッジの高い仕事といいますか、
ちゃんとコミットしないといけないものっていうのはやっぱりあるので、
そことの両立っていうところがこの1年やりながら、
自分の中でペースがつかめてきた、
リズムができてきた部分かなというふうに思っていますね。
ありがとうございます。
AIエージェントと組織の進化
カニさんどうですか?
そうですね。
組織的な話をしようかなと思ったんですけど、
だいたい吉木さんに言われちゃったので。
そうですね。
全体のマネジメントとして考えていたところで言うと、
もう1つは爆落として作っていくものをどう変化させていくかみたいなところ。
具体的に言うとAIエージェントであったりだとか、
AIに対しての取り組みを開発チーム全体でシフトさせていくのかみたいなところは、
結構吉木さんだったりだとか、
他のマネジメントであったりだとか、
それこそ各メンバーとかと議論しながら進めてきたところではありますね。
もともとやっぱり2025年始まった段階で、
すごくAIエージェントに対しての開発が前者的にすごく盛り上がって、
最初からもういけいけでっていうような状態だったかというと、
別にそうではなかったなというふうに今思い返すと思っていて、
そこから例えばですけど、
もちろん経営レベルで会社の行動指針の中で、
もともと別途テクノロジーだったものを別途AIに変えて、
ここにちゃんと別途していくんだっていう姿勢をまず出しつつ、
その上でそれをリアルに変えていくっていう部分で、
例えばですけど、
自分たちでももっと気軽にエージェントを開発できるんだっていう感覚を
みんなに身につけてもらうために、
エージェントを開発するイベントをやったりですとか、
あるいは先端でエージェントをどんどん作っていっている人たちが、
それを周りに広められるようにするであったりだとか、
そういったところのシフトを結構全体的に入れていったのが、
ここ1年だったなっていうところもあって、
結構やっぱり1年前と今で、
開発をする上で念頭に置くものみたいなところが、
割と変わってきたのかなというふうには思っています。
顧客中心の爆速開発
なるほど。
先ほど吉木さんからエネルギーの補給の開発っていう話がありましたけど、
カニさんにとってはそういう仕事ってないじゃないですか。
そうですね。仕事の上でエネルギーの補給。
僕は結構人と話すのも好きなので、
メンバーだったりだとか、
他の人と実際に喋ったりとか、
飲みに行ったりとかっていうのでも、
自分エネルギー補給にもなるんですけど、
それ以外のところで言うと、
自分はSREとかコーポレートエンジニアとか、
あとセキュリティとか、
そういった技術領域そのものも結構好きだったりとかするので、
やっぱりそういったところの新しいものに触れたりですとか、
また実際仕事の中で、
アプリケーションのパフォーマンスチューニングの話だったりだとか、
細かいトラブルシューティングみたいなものとかに入っていくのは、
結構個人的には好きなので、
そういうときは、
そうですね、だいぶ多分外から見ても生き生きしてるんじゃないかなと思います。
あと最近ね、海外にも行かれてましたよね。
はい、そうですね。
先週、AWSのリインベントという年次カンファレンスに、
私とあとは他のメンバー3人で、
合計4人で行ってきまして、
1週間アメリカで、
AWSの新しい情報であったりだとか、
他のエンジニアだったり、
そのコミュニティの皆さんっていうところと、
いろいろと話してきたりとかっていうようなところをやってきました。
交流だったりとかコミュニケーションを通してエネルギーを補給してるってことですね。
そうですね、やっぱりそういうところから得られるものというか、
そこからしか得られない栄誉があるっていうのは、
自分の、そうですね、
自分的には好きなところかなと思ってます。
結構なんかプラットフォームの誘拐みたいなところに行くと、
ちゃんと理題として話してるものと、
ある程度テッキーな話題というか、
そういうものをみんなで共有できるみたいな空気感というか文化は、
我々のチーム限らず広がるかなというふうに思いますよね。
そうなんですよね。
誘拐の時間がだいたい3、40分ぐらい取ってあるんですけど、
僕がいないと10分早く終わるっていうのがよく言われたりとかするので、
それはつまりみたいなのはあったりするんですが、
そうですね、結構話すの好きなので、
常に喋りすぎちゃったりすることもあるかなっていうのはありますね。
そういうカルチャーの話にも移ってきたかなと思うんですけれども、
ズバリですね、この爆落らしい開発、
そしてこの爆落らしさっていうものが一体何なのかっていうところを、
今回の動画としてはぜひ聞いていきたいところなんですけれども、
吉木さんにまず伺いたいと思うんですけれども、
爆落らしさっていうところってどういうところにあるんですか?
まずはやっぱりプロダクトとしてお客様を主語にしているというか、
お客様が中心にあるというところは大きいかなというふうに思っていて、
プロダクトの話もそうですけど、
ビジネス組織としても同じかなと思っていて、
やっぱり爆落の中で中心にあるのってカスタマーセントリックというか、
お客様が中心にあって、
そこに向けてお互いどうやって物を作っていくんだっけとか、
物をちゃんと使っていただくためにどうしていくんだっけっていうのを話している組織かなというふうに思っています。
プロダクト開発組織もそうですし、
組織全体で見たときの爆落らしさみたいなところっていうのが、
まさにここなのかなというふうに思っていますね。
開発のフローだったりとかっていうところでいきますと、
我々2020年から開発のところを開始しているんですけれども、
1チームの数ってその頃から変わりなくて、
今も2人から5人とかで開発しているっていうのは、
1個特色かなというふうに思っていまして、
これ以上でも以下でもない、
今が最適な人数というのをずっと続けてきているっていうのは1つあるかなと思いますね。
カニさんからもこの爆落らしい開発っていうところの特徴、
ぜひご紹介いただければと思うんですけど。
そうですね。
やっぱり一番はお客様にとっての価値フォーカスっていう部分が一番大きいかなと思っていて、
例えばそれこそ毎週レビュー会っていう作ったものを発表し合いながら、
これから出す機能とかについて話す会をやってるんですけど、
その中でも、例えば作ってこれから出すっていうものであっても、
本当にこれで楽になってるんだっけみたいな、
意見交換とかが結構積極的にされるような環境ではあるんですよね。
お客様に対して出している価値に対して徹底的にこだわって議論して作っていくっていうところが、
一つ爆落らしさとしてはあるのかなというところ。
もう一つはバックオフィスの業務に向けたいわゆるSaaSのサービス分でありながらも、
直接管理側としてお使いいただいているバックオフィス部門の方々に向けたものっていうところに加えて、
日々経費生産であったりだとか、実際に業務をする従業員の皆さんっていうところの両面に目を向けながら開発をしているっていうところが、
もう一つの爆落の面白い部分なのかなというふうに思っています。
なので、よく2B SaaSって言われたりするんですけど、
自分の頭の中では実際に使っていただくインターフェース全体はどちらかというと2Cに近いというか、
やっぱり全ての働いている方に届けたいようなものをみんなで作っているっていうところがあって、
そこが爆落らしさのもう一つの部分なのかなっていうふうに思っているところですね。
あとやっぱり爆落の開発といえば爆速開発というスピードをすごく大事にしているっていうところも特徴の一つかなと思うんですけれども、
やっぱり開発に関わる人も増えてきたり、ユーザー数も伸びていたりとかする中で、
この爆速開発というところと爆落のプロダクトとしての質っていうのを両立していくために大事にしていることっていうところも吉木さんに伺いたいなと思うんですが。
一つあるのはやっぱり我々マルチプロダクトを展開していきます。
かつお互いに共通したデータとかを持っていきながらコンパウンドスタートアップみたいな話もあったりすると思うんですけど、
複合的なプロダクトを展開していくという中だとやっぱりプラットフォームの技術みたいなのってかなり重要になってくる部分あって、
そこは2022年3年4年と続けてきたアセットがすでにあって、
やっぱりそこを複数のプロダクトを同じお客様に提供していくっていうところを技術として作っていこんできた資産が一定あったりして、
ある程度のレールがある程度敷かれていて本当にコアなお客様との対面する部分にプロダクトのエンジニアが集中していけるみたいなところはあるかなと思います。
もう一つはPDMの人とエンジニアとお客様の体験みたいなところにはちゃんと入っていくといいますか、
そこを一緒に考えていく、作っていくっていうところがバクラクらしい開発で、
かつウォーターフォール的にPDMの人はここまで、エンジニアはここまで、デザイナーはここまでみたいな区切っているわけではないので、
小さなチームで意見を出しながら開発をしていく、一個のフィーチャーを作っていくっていうところだと、
かなり手戻りとかっていうところも同じ人の頭の中でぐるぐる回転しながら作れるっていうところが、
一つ爆速開発と呼んでいるところの特徴というか、あるのかなというふうに思いますね。
お客様の課題にとことんまで入り込んで、やっぱりこれやっていう作るものを見定めて作るっていうところが結構でかいんですかね。
そうですね。
お客様の課題を深く理解するみたいなところ、お二人はどういうふうにやってらっしゃるんですか。
社内に商談動画が残っているので、それを見るっていうのはマストでやっているのと、
あとはセルフの方の意見っていうのもすごく聞いていて、
もちろん何に困ってるんだっけっていうところを聞きながら、
他のお客様と話しているときはどうなんですかっていうところも含めて聞いていくのと、
最後はもう自分も商談に出るみたいなところはずっと取り組んでいることではあるので、
そうでないと確証が持てないというか、自分も自信が持てない部分があるので、
やっぱりここはお客様の近くに行くっていうのはすごく大事にしていることですね。
カニさんはどうですか。
そうですね。私はセキュリティ部門としてお客様側のIT部門の方ですとか、
そういった方と話すことも多かったりするので、
そういったところから実際にお客様が心配に感じられている部分であったりだとか、
痛みに感じられている部分がどこなのかっていうところをやっぱり結構考えながら、
普段仕事しているっていう部分は結構大きいのかなと思います。
そういう一時情報に触れながら感覚を磨いていくっていうところは一つあるのかなと思いますね。
なるほど。さっきですね、この開発スピードっていうところの話で、
爆速開発っていうキーワードも使いましたけど、
これってどれくらい早いんですかっていうのも聞けたら嬉しいなと思うんですけど。
2025年下半期とかでいくと、
もう新しいラインが4つとか5つとか走ってるみたいな形だったりしてますね。
まさに自分が一緒に見ていたチームとかだったりすると、
まずまだシステム上のものっていうのはまだ整えられていません。
でももうお客様としてこういうことがやりたいってことが課題としては明確にあるので、
爆速開発のスタイル
もう一旦業務を受けましょうという形で、
自分たちでオペレーションとかも組みながら、
じゃあ実際にこれどうやってやっていくっていうのをエンジニアとPDMと、
あとVisDevみたいなメンバーで話しながら進めているみたいなところがやっていたりして、
もはや開発もしてないですけど、
やっぱりもう爆速で機械があるので入りに行くといいますか、
そこからはじゃあこういう形だよねっていうところを共通認識持って作っていくというか、
迷いなく進んでいけてるところとかっていうのがあるので、
ここがどれくらい早いかって言われると難しいんですけど、
そういうスタイルを取っていくといいますか、
あくまでシステムありきで入っていかないとかっていうのは一個大事なことかなというふうに思っていますね。
今年からいわゆるHCMの領域、爆落近代ですとか、
そういった領域にどんどん入ってきているんですけれども、
近代もかなり今多くのお客様にお使い頂いている状況ではあるんですが、
まだ実はリリースからちょうどもうすぐ1年経つぐらいですよね、
っていうようなスピード感でやっているところもありまして、
ただそこって別に最初サービスリリースした直後から全ての機能が揃っているとか、
そういう状態ではなくお客様の声を伺いながらどんどん必要なものを作っていくっていう中で、
いろんなお客様に選んでいただいているというところはあるので、
1年でいろんなお客様に使っていただけるようなプロジェクトに成長させられるっていうところでも、
やっぱりスピード感としては結構すごいものはあるのかなと思いますし、
先ほどお話ししたレビュー会の中でも結構ボリュームが多くて、
多すぎて収まらないみたいな時とか全然あるぐらい開発物が毎週すごくいっぱい出てくるんですよね。
なので結構アップデートの頻度みたいなところとかも含めてですけど、
開発のボリュームもスピードも質も今のところはすごく良い形で進められている状態なんじゃないかなというふうに思っています。
意思決定の軸
そうですね。思い出したのは、
今年2つか3つぐらいプロジェクトのキックオフみたいなところに自分も入りながらやったんですけど、
ミニマムで作るものを先に決めるというか、自分たちが一時情報を得た中で、
じゃあここまで作り切ろう、期間はここまでみたいなところを期限を切って作り始めるというか、
そしたらみんなの中でどういう道筋を進んでいったらいいのかというのがタイムラインとともに見えてくるみたいな。
そこをみんなで走り切るというか、どんだけ自分たちで意思持って進められるかというところになってくるので、
これは一つ爆速開発を作る上での一個重要なことかなというふうに思っていたりします。
それによって本当に作るべきものが結構シャープになったりしますよね、その中でね。
なので作らないものを決めたりだとか、最初のバージョンでは落とすし、
後のバージョンでまた改めて考えるみたいなものとかもどんどん出てくるし、
時間間隔を持って進められるという部分は結構大事な部分なのかなと思いますね。
あれですね、創業から何日経ったんだっけとか、
あとは目標の日まであと何日なんだっけみたいな、見るみんなのカルチャーみたいなところが導入されていたりして、
キックオフのタイミングとかでも、残り何日だね、じゃあここまでで線引いてやっていこうとか、
そこをみんなで共通認識を持ちながら、一日一日どうやって過ごすかっていうところが、
みんなの目線がすごく揃いやすくなったというか、今後も大事にしていきたい。
自分たちが創業して何年経ってここまで来れたのか、残り何日でここに達するのかっていうのは、
まさに常に見ていく指標かなと思ってますね。
あとこれだけ多くの機能だったりとか、プロダクトもどんどん生まれていく中で、
お二人も決めなければいけないことっていっぱい出てくると思うんですけど、
意思決定を下す時にお二人が大事にしていること、軸だったりとか、
こういう価値観はぶらさないようにしているみたいなことってありますか。
軸は冒頭とかでもしゃべった通り、お客様が中心にあるというか、
カスタムセントリックな部分っていうのはまずぶらさない部分かなというふうに思っていますね。
よく社内の中でもこういうのいいんじゃないとか、いろんな意見でながらも、
やっぱりみんなこれって提供者目線になってないかなみたいなのって、
すごく気を配ってるっていうような感じがしますね。
それはもうエンジニア限らず、PDMもそうですけど、セールスの方もそうですけど、
自分たちの都合だけでしゃべってないか、見てないかっていうのはやっぱり大事な観点かなというふうに思います。
自分もそうならないように、自分たちが提供者の方にどんどん頭が寄っていきそうな時には、
忘れてはいけない観点っていうところであるかなと思いますね。
カニさんどうですか?
そうですね。何か決断しなきゃいけない時とか、何かの案について考える時によく思うのは、
本当に千点満点の答えって何なんだろうっていうところから出発するっていうのは結構思ってるところですかね。
なので、世の中いっぱいやった方がいいことってめっちゃあると思うんですけど、
やっぱり時間限られてるし、リソースも限られてるし、
その中で本当に集中すべきことというか、
グレートなことっていうのにやっぱりどんどんフォーカスしていかないといけないかなっていうふうに思うんですよね。
意思決定の時って何を削ぎ落とすかっていうような部分であったりだとか、
そういったところを考えつつ、最終的に目指す目的地をちゃんと見定めて、
それを見ながら進んでいく方向を決めるっていうところはあるのかなというふうに思ってるんですけど、
なので、自分の意思決定が何を引いて、
グレートを目指す上ではあとどれだけの差分があるのかみたいなところは結構気をつけてみるようにはしてるかなと思ってます。
先ほど爆落の新機能とかリリースされていくもののお話あったんですけど、
やっぱり今AIエージェントの機能についても注目されてるところかなと思うんですけれども、
リリースしたデックの中でもAI申請レビューの事例などを掲載してるんですけど、
これ一体どういうものなんですかっていうのをご紹介いただければなと思います。
こちらはリーグの中だったりとかで、申請者の方が、ケースの方でもそうですし、
申請を上げるっていうタイミングでお客様の方に社内規定だったりとか、
社内のルールに沿っているかっていうところをAIが判定してレビューを返してくれるっていうところになっています。
一つ面白い点かなというふうに思っているのが、やっぱり申請を上げた後のタイミングでレビューをしますだったりとか、
あとは承認者と一緒にレビューしますっていう段階になってしまうと、
謝っていた場合に申請者の方に一個戻さなければいけない。
そこで戻すコミュニケーションだったりとか、一度申請を戻してみたいなところ、
手数を踏まないといけないみたいなところがあるので、
よりリアルタイム性というものを重視していて、
申請者が上げるタイミングでちゃんとレビューしてあげようみたいなところが一つ、
我々がこだわっている点というか、ワウな部分かなというふうに思っていて、
開発の文脈でもシフトレフトみたいなことを言うんですけど、
マグだったり不具合だったら、あとは仕様的な手戻りみたいなところを、
どんどん開発の初期段階に寄せていくというか、
後ろの工程で見つかると、やっぱりいろんなコミュニケーションだったりとか、
手戻りの工数が発生してしまうので、それを戻すみたいなところで、
申請レビューもすごくそれに近いかなと思っていて、
より失敗だったりとか間違っているケースというのを、
より左に映していく、シフトレフトしていくみたいなのが、
一個特徴かなというふうに思っております。
いろんな人からの倫理を受ける立場として見てみても、
実は意外と見てるんですよね。
僕のチームメンバーからすると、
実は見てないんじゃないのって思われたかもしれないですけど、
実は意外と見てて、例えばですけど、支出の理由だったりだとか、
あとはどこでどういうものにお金を使おうとしているのかだったりだとか、
そういった部分ってちゃんと見ておきたいし、
見ることも責任の一つだよねって考えられているマネージャーの方とかも、
すごく多いんじゃないかなというふうに思うんですけど、
そういったところのコミュニケーションのコストであったりだとか、
すごくベーシックな部分とかに関しては、
ちゃんと事前に機械的にチェックして返してくれているから、
それを前提にさらに踏み込んだレビューができるよねっていうようなところに、
たどり着ける機能の一つなんじゃないかなというふうに思っているというところですかね。
本当にサクサク使えて作業が効率化するというだけじゃなくて、
心理的な負担というか、間違えるかもしれないという不安が解消されるところのポイントですよね。
そうですね。例えばルールから外れてますみたいな話とかは、
前もってチェックしておいてほしいんですよね。
自分が見るかどうかというよりは。
どっちかというと、やっぱり自分が見たいのは、
今そのお金を使うのが本当に正しいかとか、
選んでいるものが本当に正しいかみたいなところに対して、
倫理の上ではちゃんと確認したいっていうところかなと思っているので、
そのルールとかベースの部分に関しては、
むしろ前段階でちゃんとチェックしておいてよっていうようなところに、
まさに応えられる機能なんじゃないかなって思いますね。
今後もやっぱりAIエージェントの開発には力を入れていくっていうところなんですかね。
そうですね。やっぱり難易度高い箇所もあったりするんですけど、
そこから逃げずにと言いますか、やっぱり目指しているサービスの形があるので、
そのためには必要な部分として取り組んでいくというのは変わらないかなと思ってます。
そうですね。でも一つあるとすれば、
AIエージェントを作ることを目的にしているサービスではないですし、
我々自身もそこを目的にしているわけではないんですけど、
ただ我々が行きたい世界に行くために、
業務の自動運転
AIエージェントを作っていくっていうのはすごく大事なことなのかなっていうふうに思っています。
これから目指していきたいサービスの姿だったりとか、
たどり着きたい先っていうところのキーワードが今出てきたと思うんですけど、
それもちょっと具体的にどういうところを目指しているのかっていうのを教えていただきたいなと思っているのと、
そこにたどり着くために今トライしていること、やっていることっていうのもちょっと合わせてお二人から伺いたいんですが。
一つ開発チームもそうですし、バックラック全体の大きなテーマは業務の自動運転みたいなことを言ってたりするんですけど、
どれだけ業務自動化できるんだっけっていうところも、
コーポレートの業務っていうところが完全自動化に近づくためにはどうすればいいんだろうかっていうところを取り組んでいくっていうところが
まず目指している姿かなというふうに思っていますね。
そこまで自動化まで進んでいくと、おそらくコーポレートの方の働き方って全く変わってきて、
もっと想像的なところに自分の時間を使っていくし、
従業員の方も自分の業務のところに、こうなる業務に時間を使っていくみたいな、
そういうところがお客様に向けて提供したい世界観というか、あのところかなと思っていますね。
こういったところ、コーポレート領域の自動運転を目指す。
ドライバーとしても任せていただけるし、
同時にその必要なときにちゃんとお客様であったりとか、
必要な人にちゃんと自分で見てもらえるような、
自動運転とハンドルの切り替えを両立したプロダクトにできる状態っていうのが一番理想なのかなというふうに思っています。
このコーポレート領域の自動運転を目指していくにあたって、
特にここが課題になっている、
これから入っていただくエンジニアの方と一緒に取り組んでいきたい、
向き合っていきたい課題みたいなところもぜひ伺いたいなと思うんですけど。
めっちゃいっぱいあるんですけどね。
いっぱいありますね。
そうですね、デックにもいっぱい課題は書かせてもらってますが。
そうですね、テクニカルな面でいくと、
ベストプラクティスみたいなところがまだまだ世の中にいなかったりっていう部分。
我々も発信みたいなところをすごく力を出している部分もありながら、
まだまだこれで一通りいけたよねというか、
フェーズでは全然ないかなというふうに思っているので、
そこを一緒に作っていくっていうフェーズ。
AIネイティブなSaaSの進化
まさにビルディングのフェーズっていうのがすごく今なのかなというふうに思っているのと、
もう一つはドメインの複雑さといいますか、
我々が扱っている2Bのサービスをどうやって自動化していくかってやっぱり簡単ではないし、
我々はホリゾンタルなサービスとして提供していますので、
お客様が1万社、2万社、何万社、今後数十万社に向けて提供していきたい部分があるので、
やっぱりそこの業務に対しての自動化っていうのは簡単ではできない。
複雑なより業務を理解していくっていうところがエンジニアに求められるので、
やっぱりここは2つ難しい点があるかなと思っていますね。
そうですね。
技術的なチャレンジ全体としては、
やっぱりこれまでは人が使うサースというのをずっと作ってきたんですけど、
それに加えてAIがいることが前提になったサースっていうところへのシフトっていうのが1つあるかなと思っています。
これまで人が使う前提で設計してきたAPIであったりだとか、
データ構造であったりだとか、メモリだったりだとか、
そういったものだけじゃなくて、
例えばエージェントが誰の許可を得て動くのかみたいな、
いわゆる認可の基盤であったりだとか、
エージェント自体がどこで動くのかみたいな実行基盤であったりだとか、
そういったところも含めたエージェントがうまく動いていくためのシステムの再設計みたいなところは
1つ必要なのかなというふうに思っています。
同時にいろんなお客さまに使っていただくにつれて、
データ量ですとか処理の重要さっていうところがどんどん増している中で、
そこにちゃんと応えられるようなスケーラブルな基盤であるとか、
システムを作っていくっていうところが同時にかなり大事なところになっているのかなというふうに思ってまして、
やっぱりそれを前提にAIネイティブなサースに進化していくのに、
必要な変化っていうのをどんどん起こしていくっていうところが、
これからの一番でかい課題の1つかなというふうに思っています。
顧客志向のエンジニア組織
ありがとうございます。
本当に取り組んでいくべき課題はますますいっぱいあるというところなんですけど、
じゃあそこの課題にどういう方たちと一緒に向き合っていきたいかっていうところも
お二人に伺えればと思うんですが、
どんな方がバクラクのエンジニアの組織にフィットすると思います?
どの職種でもそうだと思うんですけど、
お客様の近くで開発したい方というか、
お客様の提供価値にこだわって開発していく方っていうところかなと思っていて、
中盤でも話した通り技術があるっていうところをベースに持ちながら、
手前ミソですけどやっぱりバクラクの開発チーム、
中から見た中でもやっぱり技術力高いメンバー多いなと思っていて、
この領域だったらこの人いるよなっていうところがやっぱりあったりしていて、
そういうエンジニアも抱えていきながら、
やっぱりそのメンバーたちがみんなお客様に近いところで開発していく、
これは他の会社ではなかなかできない部分か、
自分たちが持っている一番の特色かなと思っているので、
そこを一緒に作っていきたい方。
お客様のことを考えて、
自分の独立した思考を持って作っていく、
そういうエンジニアの方と働きたいなというふうに私は思っています。
課題を見つけてその課題を解決するっていうサイクルを
とにかく楽しめる人っていうのがすごく合うんじゃないかなと思っています。
今やっぱりいろんな課題あるし、
その中でも取り組まなきゃいけない課題とか、
取り組みたいんだけどなかなかできない課題とかっていうもの、
いろんなものあったりとかするんですけど、
それを例えばできるようにするにはどうするかであったりだとか、
これまでにないものを生み出していくっていうところであったり、
お客様のそばにある課題から自分たちのそばにある、
もっと開発を例えば加速させる課題であったりだとか、
そういったものまでこの先もどんどん増えてくる課題を
どんどん見つけて倒していくぜっていう勢いのある人たちに囲まれて
一緒にやっていけたらすごい楽しいなって思っています。
ぜひこの動画を見てご興味持ってくださる方がいらっしゃいましたら、
概要欄に採用ページカジュアル面談のリンクも載せておりますので、
ぜひお気軽にお申し込みいただけたらと思います。
では本日は吉木さん、カニさん、お話ありがとうございました。
ありがとうございました。
38:05

コメント

スクロール