【自社サービスへの転身】「作ることメイン」から「リリース後の運用」を見据えた開発へ。開発マネージャーがモビルスで実感する自由度と成長。

こんにちは。モビルスRecruiterの大野です。

今回はSES企業から転職し、現在は「MOBI BOT（モビボット）」チームなど開発マネージャーを務める長塚さんにインタビューを行いました。

自社サービスならではの製品をレベルアップしていく「運用改善のサイクル」に携わりたいという思いからモビルスへ入社し、現在は生成AIを駆使した効率的な開発から、チームの品質向上に向けたドキュメント化までを幅広く推進しています。

受託開発やSESの環境から自社サービスへのステップアップを考えている方や、チームでの仕組みづくりに興味があるエンジニアの方は、ぜひ最後までご覧ください。

【プロフィール】

・長塚渉さん：開発チームマネージャー。前職のSES企業にてリーダーを経験した後、2024年モビル中途入社。現在はチャットボット「MOBI BOT」のバージョンアップに向けて、チームをリード。プライベートではワールドカップと近所のコーヒー屋のコーヒーソフトにはまっている⚽🍦

「運用改善のサイクルに関わりたい」――SESでの経験を経て、ボトムアップの環境を求めてモビルスへ

私は前職において、SES（システムエンジニアリングサービス）企業に約4年間在籍し、AWS環境下で主にPythonを用いた開発中心の業務に携わっていました。システムを形にする開発業務にはやりがいがありましたが、一方で自社サービスではないため、リリース後のシステムを実際に運用し、そこから得られたデータをもとに改善サイクルを回すという経験を積む機会がありませんでした。

エンジニアとしての将来を考えたとき、開発して終わりにするのではなく、運用や保守、調査といったプロセスを通じて経験や知識をさらに深めたいという思いが強くなっていきました。これが、自社サービスを展開する企業への転職を志したきっかけです。

数ある企業の中でモビルスを選んだのは、開発面とビジネス面の双方に強い魅力を感じたからでした。開発面においては、使用している技術が比較的モダンであることに加え、技術選定などがトップダウンではなく開発チームでちゃんと話し合って進める風土があると面接で聞いたこと、そして新プロジェクトの立ち上げメンバーの募集であったことが決め手となりました。またビジネス面でも、コンタクトセンターが抱えるオペレーターの離職率や顧客対応の難しさといった課題に業務的な興味を持てたこと、そしてパートナー企業と連携して効率的にフィードバックをもらい改善を進められる「開発オピニオンパートナー」という体制に独自の強みを感じました。

入社前に大きな懸念はありませんでしたが、実際に参画してみてもギャップは全くありませんでした。前職では取引先が決定した大まかな設計通りに実装することが多かったのに対し、モビルスではプロダクトマネージャー（PdM）から強制されるようなことはなく、チーム内で話し合って物事を進めるボトムアップの環境がしっかりと定着しています。

自分たちでゼロから考えて作る難しさや責任は伴いますが、単にプログラムを組む以上の難易度があるからこそ、確かな成長を実感しています。特に、以前の「作ることメイン」だった姿勢から、エラー検知や問題発生時の追跡性など「リリース後の運用を考慮した開発」を強く意識して取り組めるようになったのは、自分の中で大きな変化だと感じています。

「設計書の詳細な記述が、綺麗なコードを生む」――GitHub Copilotを活用した開発と、これからの課題

入社後は、まず新規プロジェクトの構築に少し携わった後、SecurePathやCRM Connectの開発を1年半ほど担当しました。そして今年の春頃からは「MOBI BOT」チームに配属され、現在は主にその開発業務にあたっています。

現在の開発における大きな特徴の一つが、チーム全体で生成AIを積極的に活用している点です。なかでも最も効果を実感しているのがプログラミング（実装）の領域です。私たちは、開発を行う前に作成する設計書に、あらかじめ細かい情報をしっかりと書き込むようにしています。その詳細な設計書を仕様としてAIに読み込ませることで、精度の高いものを創り上げています。これにより、「綺麗なドキュメント」と「高品質な実装」の両方が成果物として手元に残るという、非常に良い開発サイクルが確立されています。

この生成AIの導入は、開発部門の方針と、チーム独自の試行錯誤の両面から進んでいます。ディビジョン全体としては、人によるコードのばらつきをなくすために製品ごとの共通ルールを整備する動きがあり、私たちのチームではそれを実際の設計・実装タスクへ具体的に落とし込む役割を担っています。主なツールとしては、開発エディタに組み込まれている「GitHub Copilot」をメインに使い、日常的な質問や調べ物には「Gemini」を活用しています。

もちろん、AIの利用には注意も必要です。ハルシネーション（でたらめな回答）の可能性が常にあるため、AIが作成したものを100%鵜呑みにすることはせず、最終的には必ず人間の目でレビュー・チェックを行う体制をつくっています。

体感として、単純なプログラミング作業だけで言えば、AIの導入によって倍以上のスピード（工数削減）になっていると感じます。ただし、仕様のすり合わせやマネージャーとの調整といった「コーディング以外の業務」がなくなるわけではありません。そのため、コーディングの高速化がそのまま開発全体の劇的なスピードアップに直結するわけではない、という点もチームの振り返りで挙がっており、これが今の新たな課題でもあります。今後はAIによって実装工数が減った分、相対的に負担が大きくなっている「人の目によるレビューやテスト」のプロセスを、さらに効率化できる仕組みづくりにチャレンジしたいと考えています。

「情報は残さないと自分が困る」――チーム全体のパフォーマンスを最大化するための仕組み化

私が考える理想のチーム像は、一人ひとりが自分の割り当てられたタスクをこなすだけで終わるのではなく、「どうすればチームや会社全体で最高のパフォーマンスを出せるか」を全員が意識し、自律的に動ける組織です。担当領域をガチガチに固めすぎず、お互いの状況を意識しながら必要に応じてフォローし合える体制がベストだと考えています。その環境整備の第一歩として、春に増えた新しいメンバー向けに、情報の整理や開発フローのドキュメント化を進めています。

こうした「情報を残す、仕組み化する」という意識は、前職での経験から培われたものです。当時は適切な情報がドキュメントとして残っていなかったために、何か問題が起きた際に最終的に自分が一番状況を把握しきれずに苦労するという経験をしました。「仕組み化しておかないと、結局は自分に返ってくる」という実感を強く持っていたのです。また、誰が対応することになったとしても、ドキュメントさえあればスムーズに一次対応ができる状態を作っておくことが、チームの体制として最も望ましいという想いもあります。

実際に人によって検証結果の書き方などにばらつきがあるという課題がありました。そこで私は、記載内容のテンプレートやテスト結果のひな形を作成し、チーム内で統一して運用することを提案しました。結果として、当時のプロダクトマネージャー（PdM）からも「非常に品質が良くなった」と評価をもらい、仕組み化の重要性を再認識しました。