“つくる”だけで終わらない。価値を問い続ける開発組織

新卒でベーシックに興味を持ったきっかけは、大学に来ていた採用イベントで人事の方と話したことでした。

正直、その時点ではベーシックという会社のことをよく知らなかったですし、マーケティングという領域にもそこまで強い関心があったわけではありませんでした。

ただ、その場で当時のCTOと直接話す機会があり、そこで一気に興味が湧きました。プロダクトや技術に対する向き合い方、エンジニアとしての考え方に触れて、「この会社には、ちゃんと技術を大事にしている人がいるんだな」と感じたのを覚えています。

その後、サマーインターンで2daysのハッカソンに参加しました。本社で開催されたのですが、そこで実際に社員のエンジニアがメンターとして関わっていたり、参加者と一緒になってものづくりを楽しんでいたりする姿を見て、すごく印象が変わりました。単に仕事として開発しているというより、本当にプログラミングやものづくりが好きで、それを楽しみながら働いていることが伝わってきたんです。

その空気感にすごく惹かれましたし、「自分もこういう人たちと一緒に働きたい」と思ったことが、入社を考える大きなきっかけになりました。

選考を通じてマーケティングについての解像度も高まり、それまでの自分の考えや行動が会社のビジョンとも合致していることを確認できて、入社を決めました。

開発組織全体を見る立場として意識しているのは、メンバーとの距離感を必要以上に遠くしないことです。

役職としては部長ですが、役職はあくまで役割です。もちろん組織としての上下関係や責任の違いはありますが、だからといって壁を作ったり、現場から離れた存在になったりするのは違うと考えます。

もともとマネージャーとしてやってきた時から大事にしているのですが、できるだけメンバーと近い距離で話すこと、気軽に相談できる関係性を保つことは、今の立場でも変わらず大切にしています。距離が遠くなると、ちょっとした違和感や困りごとが見えにくくなりますし、現場の温度感もわからなくなってしまうからです。

開発は、結局チームでやるものです。だからこそ、単に管理するのではなく、みんなが楽しく、前向きに開発できる状態をつくることが、自分の役割の一つだと考えています。安心して意見を言えること、困った時に助け合えること、挑戦してみようと思えること。そういう空気をつくることを意識しています。

ベーシックのプロダクト開発で大切にしている考え方は、「自分たちがプロダクトを作っている誇りを持ち、創造的かつ挑戦的にエンジニアリングに向き合う」ということです。

エンジニアリングは、ただ仕様通りにつくることではなく、プロダクトをより良くするために考え、工夫し、責任を持つことです。自分たちの仕事がユーザー体験や事業の価値につながっているという実感を持ちながら、前向きに挑戦することを大事にしています。

そのために、開発組織では次の4つを行動指針として定義しています。

1. 質とスピードに妥協しない

良い設計や良いコードは、一見すると時間がかかるように見えても、長い目で見るとむしろ開発を速くします。品質を犠牲にして一時的にスピードを出しても、後から手戻りや保守コストが増えてしまうことが多い。だからこそ、少ない人数と限られた時間の中でも、高い生産性を出せる開発を目指しています。

2. 課題に共感し、プロダクトを進化させる

良いプロダクトは、ユーザーの課題を理解するところから始まります。単に機能をつくるのではなく、「なぜその課題が生まれているのか」「ユーザーは何に困っているのか」を想像し、同じ目線に立って考えることを大切にしています。そうすることで、表面的な解決ではなく、本当に価値のある改善につながります。

3. 他者の生産性に配慮する

開発は一人で完結しません。レビューの出し方、相談の仕方、ドキュメントの残し方、日々のコミュニケーションひとつで、周囲の動きやすさは大きく変わります。困っている人がいたら助ける、相手が理解しやすい形で伝える、チーム全体がより前に進みやすくなるように行動する。そうした思いやりも、エンジニアリングの大事な一部です。

4. 常に学び、共有する

技術も事業も変化が速い中で、学び続けることは欠かせません。ただ、学ぶだけでなく、それを共有することも同じくらい大事です。知識や経験をチームの中で循環させることで、個人だけでなく組織として成長できますし、その方が開発そのものも楽しくなります。

ベーシックの開発組織には、3つの大きな特徴があります。

1つ目は、職種を越えた信頼関係

エンジニアの仕事はコードを書くことだけではなく、営業、CS、マーケティング、プロダクトマネージャーなど、さまざまな職種と一緒にプロダクトを作っていくことです。その中で、他職種の方々がエンジニアを信頼してくれているか、逆にエンジニア側も事業や顧客理解を持って会話できるかで、仕事のやりやすさも、出せる価値も大きく変わります。

ベーシックには、職種を越えて相談したり、課題を一緒に考えたりする文化があり、エンジニアが単なる実装担当ではなく、プロダクトをより良くするための一員として期待されているので、自分の意見や提案を出しやすい環境です。

2つ目は、事業として価値のあるプロダクトに、技術の力で深く関われること

たとえば、ferret One や formrun のように、多くのユーザーに利用されるサービスに関われるのは大きな魅力です。実際に使われる規模があるからこそ、性能、安定性、運用、UXなど、さまざまな観点で技術的な課題と向き合う面白さがあります。

また、サービス特性の異なる複数のプロダクトがあることで、ひとつの型にはまらない経験ができます。同じ会社の中にいながら、異なる事業課題や技術課題に触れられるので、エンジニアとしての視野が広がります。

3つ目は、自主性や裁量が高い環境

手を挙げるメンバーには積極的に任せたいですし、「こうした方がいい」という提案を実際に形にしやすい。決められたことだけをやるのではなく、自分から課題を見つけて動ける人にとっては、とても面白い環境です。

解決すべきだと感じて取り組んだことのひとつが、開発生産性の改善です。

2024年頃から、プロダクト改善のスピードをもっと高めていくには、まず今の自分たちの状態を正しく把握する必要があると感じていました。それまでも「レビューは早く返した方がいい」「もっとスムーズに進めたい」といった声がけはしていたのですが、自分たちの開発が実際にどのくらいのスピードで進み、どこにボトルネックがあるのかは、感覚でしか捉えられていませんでした。

そこで、まずは開発の流れを見える化し、データをもとに現状を理解するところから取り組みました。見える化してみると、どこで滞留しやすいのか、どこに対して改善策を打つべきなのかが具体的に見えるようになり、チームで事実ベースの会話ができるようになりました。ベストエフォートで「頑張ろう」と言うだけではなく、改善の優先順位をつけて動けるようになったのは大きかったです。

実際、サイクルタイムの推移を見ても、取り組み当初は月によっては70〜120時間前後まで大きくなっていたのに対して、直近では20〜40時間台に収まる月が増えてきています。ピーク時と比べると半分以下、月によっては3分の1近くまで改善できているので、継続的な取り組みがきちんと成果につながった実感があります。

また、この取り組みは自分ひとりで完結するものではないので、チームを巻き込みながら進めたことも大事なポイントでした。開発生産性は個人の頑張りだけで決まるものではなく、チーム全体の進め方やコミュニケーションの積み重ねで変わります。だからこそ、数字を共有しながら一緒に改善を進めることで、短期的な効率化だけでなく、中長期的な組織づくりにもつなげられたと思います。

特に新卒育成では、成長を感覚ではなく具体的に見ながら支援しやすくなり、育成の質を高めることにもつながりました。開発生産性の改善は、単に速くつくることではなく、より良いプロダクトを継続的に届けるための土台づくりだと捉えています。

これから入社してほしいのは、問題解決に真摯に向き合える人です。

技術が好き、コードを書くのが好き、ということはもちろん大事です。その上で、「何のためにつくるのか」「どうすればプロダクトの価値につながるのか」を考えられる人と一緒に働きたいです。単に実装をこなすだけでなく、ユーザーや事業にとっての価値を追求し、そのための方法を粘り強く考えられる人です。

最近はAIを使ったコーディングも当たり前になってきていますし、コードを書くこと自体のハードルはどんどん下がっています。だからこそ、これからのエンジニアには、単にコードを書けること以上の価値が求められます。どんな設計にするべきか、何をつくるべきで何を作らないべきか、どこに責任を持つのか。そういった判断に向き合えることが重要です。

極端に言えば、コードを書かないことが正解な場面もあると考えます。もちろんコードを書く喜びは大事にしながら、その先にある「本当にユーザーに価値を届けるための判断」まで考えられる人。自分の技術を手段として使いこなせる人に来てほしいです。