二つのチームが、それぞれの領域へ深く入る

—まず、現在の役割を教えてください。

S.Tさん：開発部の責任者を務めています。ただ、開発部全体が一つのチームとして、すべてを一緒に進めているわけではありません。現在は、大きく二つのチームに分かれ、それぞれの領域へ集中しています。

一つは、「Eigyo Engine」や企業データ基盤など、営業支援とデータ領域を担うチーム。もう一つは、「ジーエン図面」を中心としたSaaS領域を担うチームです。

扱うプロダクトも、必要な技術も異なるため、開発の進め方やチームの雰囲気にも違いがあります。全員を一つの方法で管理するより、それぞれが担当領域へ深く入れる体制にしています。

—責任者としては、どのような仕事を担っていますか。

S.Tさん：各チームが開発に集中できるように、役割を整理することです。

営業支援・データ領域では、担当者の対応範囲が広く、社内からさまざまな相談が集まります。技術的に幅広く対応できるほど、「この人に聞けば解決できる」と仕事が集中しやすくなります。

ただ、一人が多くの案件を抱えると、その人の判断待ちになり、周囲の仕事まで止まってしまいます。そこで、私が引き取れる仕事を分け、採用活動も担うことで、特定のメンバーに業務が集中し、開発が滞らないようにしています。

スクラムからカンバンへ。AI時代に合わせて開発方法を変える

—SaaSチームでは、どのように開発を進めていますか。

S.Tさん：以前は、アジャイル開発の手法の一つであるスクラムを採用していました。スプリントプランニングなどの場を設け、チーム全員で一つのテーマへ集中し、リリースまでの時間を短くする方法です。

現在はスクラムをやめ、GitHub上のカンバンを使い、開発する機能や作業の進捗を管理しています。未着手、進行中、完了といった状態を見ながら、各メンバーへ仕事を割り当て、一人が比較的大きな単位を担当します。

変えた理由の一つは、コーディングエージェントの進化です。以前は複数人で分ける必要があった開発も、一人で短期間に進められる場面が増えました。複数人で細かく分担すると、かえって調整の負担が大きくなることがあります。

開発手法そのものを守るのではなく、今の技術とチームにとって、最も速く価値を届けられる方法を選んでいます。

開発する機能や作業を細かく分けず、一人が大きな単位を担う

—カンバンでは、どのくらいの大きさで仕事を任せるのでしょうか。

S.Tさん：以前よりも、大きな単位で任せています。コーディングエージェントがコードベース全体を把握し、実装を支援してくれるため、細かな作業へ分解しなくても進められるようになったからです。

もちろん、何も説明せずに任せるわけではありません。なぜ必要な機能なのか、過去の開発から見て何に注意すべきか、どの部分にリスクがあるかといった勘所は共有します。

チケットには、重要なポイントを箇条書きで記載します。複雑な機能であれば、最初に実装方針を出してもらい、方向性を確認してから進めます。

メンバー全員が、プロダクトの目的や現在の開発状況を具体的に理解しています。細部まで仕様書に書かなくても、目的と注意点を共有すれば、自分で考えて開発を進められる状態です。

週に一度、ビジネス側と「何をつくるか」を決める

—開発する機能の優先順位は、どのように決めていますか。

S.Tさん：週に一度、開発チームとビジネス側（営業メンバーや役員）が集まり、開発方針や優先順位を共有する場を設けています。スクラムでいうスプリントレビューに近いものです。

まず、直近でリリースした機能を共有します。現在調査していることや、開発中のテーマも説明します。その上で、ビジネス側から顧客の状況や営業上の課題を聞きます。

「この機能がないため、導入が進みにくい」「このお客様が、こうした使い方を求めている」といった具体的な情報をもとに、何を先に開発するかを決めます。

SaaSチームでは、現時点では私が最終的な優先順位をつけています。ビジネス側の要望をそのまま開発へ流すのではなく、複数の顧客へ与える影響、技術的なリスク、プロダクト全体の方向性を考えながら判断します。

管理のための管理は増やさない

—メンバーの生産性は、チケットの完了数などで評価するのでしょうか。

S.Tさん：チケットの進捗は見ていますが、完了数だけで細かく評価しているわけではありません。今のチーム規模であれば、日々どのように進め、どこで困っているかを直接見られます。

機能によって難しさも大きさも異なるため、数だけを比べても正確ではありません。現状は、実際の仕事を見ながら判断しています。

組織が大きくなれば、別の仕組みが必要になるかもしれません。ただ、現在の規模であれば、管理のための指標や会議を増やすより、プロダクトと顧客へ向き合う時間を確保する方が重要だと考えています。

新規プロダクトは、動くものから考える

—新しいサービスを立ち上げるときは、どのように進めますか。

S.Tさん：以前は、Figmaで画面を設計するところから始めることが多かったです。現在は、よりコードに近い形で、動くプロトタイプを先につくることが増えました。

コーディングエージェントを使えば、簡単な画面であれば1〜2週間で一通り用意できます。実際に触れるものがあると、ビジネス側も利用イメージを持ちやすくなり、要件のずれに早い段階で気づけます。

すべての仕様を確定してから開発するのではなく、まず動くものをつくり、触りながら具体化する。技術の変化によって、新規プロダクトを試すまでの時間は短くなっています。

小さく始めた図面管理サービスが、SaaSへ育つまで

—ジーエン図面は、どのように立ち上がったのでしょうか。

S.Tさん：最初は「図面エンジン」という名称で、小さく提供を始めました。まずEigyo Engineのお客様に使っていただき、声を集めながら改善する計画でした。

製造業では図面を中心に仕事を進めますが、会社ごとに業務フローが異なります。図面の保管だけを解決すれば良いわけではなく、見積、受注、その後の工程まで含めて管理したい場合もあります。

当初は、顧客の業務を十分に理解し切れていない状態でした。そこで、小さく出し、実際の使い方を聞きながら、必要な機能を増やそうとしていました。

しかし、途中で営業活動を拡大したことで、開発側の想定より早く顧客要望が増えました。売り方、開発コスト、顧客ごとに異なる業務への対応など、さまざまな課題が表面化しました。

一度立ち止まり、今後どのような価値を提供するのかを見直すことになりました。

一度立ち止まったからこそ、価値の核を見つけられた

—そこから、どのように現在のジーエン図面へつながったのですか。

S.Tさん：新規営業を止め、既存顧客への対応と、次に何をつくるべきかの検討へ集中した時期がありました。

その後、もう一度可能性を探る中で、大きく二つの改善が進みました。一つは、類似図面を検索する精度が上がったこと。もう一つは、導入時に顧客の図面データを取り込む作業を改善できたことです。

図面を大量に保有する企業にとって、最初のデータ移行は大きな負担です。検索機能が優れていても、利用開始までに手間がかかれば導入は進みません。検索の価値と、使い始めるまでの体験の両方を改善したことで、サービスとしての可能性が見えてきました。

プロダクト名や提供方法を見直し、現在のジーエン図面へつながっています。最初の構想をそのまま進めたわけではなく、顧客の反応や事業性を見ながら、何度も方向を調整してきました。

「図面を管理したい」の奥にある業務課題を見る

—顧客からの要望は、そのまま機能へ反映するのでしょうか。

S.Tさん：そのまま実装するわけではありません。「図面を管理したい」という言葉だけでも、顧客が本当に解決したい範囲は異なります。

製造業では図面を起点に業務が進むため、図面管理という言葉で表現されていても、実際には見積や受注を含む一連の業務を管理したいことがあります。

要望の背景にある業務フローを理解しないまま機能をつくると、一社だけに合うものになったり、本来の課題を解決できなかったりします。

何を欲しいと言われたかだけでなく、なぜ必要なのか、現在はどのように仕事を進めているのかを分解することが重要です。

開発責任者が、顧客の商談へ参加する理由

—S.Tさん自身が、顧客へ話を聞きに行くこともあるそうですね。

S.Tさん：はい。特定の機能を求めているお客様や、その機能があるサービスを探しているお客様がいれば、営業の商談へ参加します。

「その機能を、実際にはどのような場面で使うのか」「現在のやり方では、どこに負担があるのか」を直接聞きます。既存機能で解決できる場合もありますし、業務フロー自体を見直した方が良い場合もあります。

営業メンバーは製造業の営業支援には強みがありますが、全員がSaaS営業やシステム導入を経験してきたわけではありません。複雑な業務フローを整理する必要がある商談では、開発側にも相談が入ります。

営業だけに顧客理解を任せるのではなく、必要な場面ではエンジニアが顧客と直接話す。そこで得た具体的な顧客理解を、機能の設計や開発の優先順位に反映しています。

役割を手放すことで、メンバーの自走を促す

—組織づくりの中で、印象に残っているメンバーの変化はありますか。

S.Tさん：営業職からエンジニアへ転身したS.Jさんの成長です。入社当初はエンジニアとしての経験が多くなく、新しいことばかりの状態で、先輩が仕事を管理しながら進めていました。

ただ、その状態が続くと、情報も判断も一人へ集まります。そこで、先輩には一度手を離してもらい、白澤さんが一人で担当領域を進める体制へ変えました。

任せてみると、自分で調べ、判断し、どんどん開発を進めるようになりました。現在は、Eigyo Engineに関わる開発を広く担っています。

責任者や先輩がすべてを握る方が、短期的には安全に見えるかもしれません。しかし、任せる範囲を広げなければ、本人の成長にも、組織の拡張にもつながりません。必要な支援はしながら、判断や実行を任せる範囲を、段階的に広げることを大切にしています。

異なるチームを、同じ型にはめない

—開発部として、共通して大切にしている文化はありますか。

S.Tさん：二つのチームは、扱う領域も進め方も異なります。その違いを無理にそろえないことです。

SaaSチームは、顧客要望とプロダクト全体の方向性を見ながら、カンバンで機能開発を進めます。営業支援・データ領域では、社内の業務や企業情報の基盤など、複数のテーマを横断して扱います。

どちらにも同じ会議の進め方や評価指標を適用すれば、管理しやすくなるかもしれません。しかし、それぞれが速く価値を出せる方法は違います。

共通しているのは、目的に合わせて方法を変えることです。スクラムを続けること、仕様書を細かく書くこと、全員を同じ評価指標で見ること自体を目的にはしません。技術や事業の状況が変われば、開発のやり方も変わります。