株式会社マクロミル
グローバルテクノロジー本部 エンジニアリング部 部長
濱田順司さん
新卒入社したホテルでIT部門に配属となり、基幹システムの開発経験を積む。その後、福岡のベンチャー企業へ転職し、複数社を経てメルカリに入社。メルカリ初の福岡拠点でエンジニア組織を立ち上げる。基幹システムの刷新など大規模なプロジェクトをプロジェクトリーダーとしてけん引し、2023年4月よりマクロミルへ入社。同社の研究開発拠点として、23年2月に新設された福岡拠点の立ち上げ責任者を務める
【PR】 働き方
新しくゼロから作り上げるよりも、既にかたち作られたものを作り替える方が難しい。組織や価値観、そしてITシステムもその例外ではないだろう。
このシステム刷新という難題を、楽天やメルカリと名だたるテックカンパニーで次々と成功させた実績を持つのが、マクロミルの濱田順司さんだ。現在はマクロミルの福岡拠点の組織立ち上げ責任者として、その手腕を振るっている。
システム刷新の成功と失敗を握る鍵とは、一体どのようなものなのだろうか。濱田さんのキャリアから紐解いてみた。
株式会社マクロミル
グローバルテクノロジー本部 エンジニアリング部 部長
濱田順司さん
新卒入社したホテルでIT部門に配属となり、基幹システムの開発経験を積む。その後、福岡のベンチャー企業へ転職し、複数社を経てメルカリに入社。メルカリ初の福岡拠点でエンジニア組織を立ち上げる。基幹システムの刷新など大規模なプロジェクトをプロジェクトリーダーとしてけん引し、2023年4月よりマクロミルへ入社。同社の研究開発拠点として、23年2月に新設された福岡拠点の立ち上げ責任者を務める
濱田さんが初めてシステム刷新を経験したのは、自身にとって最初の転職先となるITベンチャーでのことだった。
当時の福岡にはIT企業が相次いで進出していたことに加え、M&Aの波が大きく押し寄せていた真っ最中。濱田さんの所属していたITベンチャーも例に漏れず、その波の渦中にいた。「部門の合併や売却が行われる中、システムの統合と分離に携わったことで、システム刷新の経験を積むことができました」と振り返る。
その後濱田さんは広告系のIT企業に転職し、福岡拠点の立ち上げに従事。組織の作り方、プロジェクトの進め方をひと通り経験した後、活躍の場をメルカリに移す。当時ちょうど福岡に開発拠点を設立しようとしていたメルカリにとって、濱田さんは適役だった。
「会社からのオーダーは、目的やミッションをエンジニア自身で設定し、自発的にプロジェクトを推し進められる開発組織を作ること。その上で、福岡ならではの付加価値を生み出せる拠点作りも求められていました」(濱田さん)
福岡には、ゼロベースで立ち上げるエンジニア組織だけではなく、カスタマーサポート(以下、CS)の拠点もあった。そこで濱田さんは、福岡の組織方針を「CSに最大限コミットできる開発組織」と定め、顧客満足度を向上させるためにCSのシステム刷新に乗り出した。
「CSはコールセンターでやり取りしたことやクレームなど、お客さまの声のデータが集積する大事な場所なんですよね。刷新に失敗した場合は大きな混乱を呼ぶので、誰しも慎重になります。さらに改善した時の効果が見えづらいので、経営的にも投資判断を下しにくい。
でもCSはお客さまとの最大のタッチポイント。ここを改善できると、よりお客さま満足度が向上し結果的にはLTV向上にも寄与します。そして蓄積されたデータをフル活用することでプロダクトへのフィードバックサイクルを高速に実現できる。刷新へのハードルは高いけれど、成功したときのインパクトは大きい。せっかく新規で立ち上がる開発組織だからこそ、やるべきだと思いました」(濱田さん)
濱田さんは『コンタクトセンター業務をテクノロジーを駆使して効率化する』ことをプロジェクトのミッションに掲げ、既存システムをマイクロサービス化し、AI等も駆使しながらお問い合わせ対応効率を高め、最終的に大幅なコスト削減に成功した。
「システム刷新はあくまでも課題解決の方法の一つ。刷新をすること自体が目的やゴールではありません。解決すべき課題はなにか? 今後実現していきたいことはなにか? プロジェクトの目的を明確に定め、刷新を行う理由を正しく自覚することの大切さを学びました」(濱田さん)
濱田さんがこれまで手掛けたシステム刷新の成功の鍵を握ったのは何だったのか。そう問うと、「(プロジェクトマネジメントなどのテクニック以外に)プロジェクトに対して、関連する部署の感情の方向性をそろえることは特に大切にしてきました」と明かす。
濱田さんは、システムに携わる人の感情を重視した段取りをいつ何時も欠かさなかった。
「システムを刷新する時は、エンジニア、営業、マーケティング、PR、CSなどさまざまな立場の人が関わります。使い慣れたシステムの変更は、業務に与えるインパクトも大きく、不安がつきまといますよね。それを払拭できずにいるとネガティブな感情が生まれて、プロジェクトを推進する際に必要な協力が得られにくい状況になります。
以前関わったプロジェクトでは、視座の違いや感情のもつれからプロジェクト進行がうまくいかない現場を見てきました。そのため、私がシステム刷新のプロジェクトリーダーを務めるときは、ステークホルダーとの信頼関係を常に重視します」(濱田さん)
不便なシステムを改善すること自体は、関係部署の多くの人にとってハッピーなこととして受け止められる。ただ、刷新に伴う変化やリスクにはセンシティブになることが多い。「トラブルが発生しないか」「新しいシステムの操作を覚えるのに時間がかかるのでは」といったネガティブな感情がつきまとうからだ。結果、システム刷新に対して関係部署の腰が重くなるケースはあらゆる組織がぶつかる壁だろう。
だからこそ、濱田さんはそうした不安を払拭し信頼関係を築くために、早い段階で動くシステムを見せるように心掛けている。
「オペレーションの一部が変わるのか、全てが変わってしまうのかは、システムが変わるときに最も知りたいポイントです。新しいシステムを使用するユーザーの気持ちがどうなっているか考え、不安を払拭しながらプロジェクトを進めるようにしています」(濱田さん)
また、プロダクトマネージャーとして重視しているのが経営層への説明だ。長期にわたるプロジェクトでは、常に開発リソースとの戦いとなる。成果が見えるまでの一定期間、経営側への投資判断材料を継続的にインプットし、予算などの条件を握っておくことは、成果を出すために欠かせないという。
「大規模なプロジェクトを推進するには、経営層に対する説明責任は非常に重要です。ロードマップを提示し、達成のためのマイルストーンを定期的にインプットしていきます。投資継続のメリットをかいつまんで説明することで、経営層と確かな合意を取るようにしています。
大規模プロジェクトに臨む時には、必ずといって良いほどリソースとの戦いになります。これは大企業でもスタートアップでも同じです。だからこそ、プロジェクトの目的と遂行計画を明確にした上で、リソース不足が発生したときに、方向転換を含めて対処できるようにしておく必要があります」(濱田さん)
経営層への説明において重要になるのが、エンジニアとしての視点ではなく経営的な視点でプロジェクトの意義を整理して伝えることだ。
「最も意識すべきことは、プロジェクトが経営に与えるインパクト。私の場合は、どれくらいの利益率向上につながるのか、という視点でプロジェクトの意義を説明するようにしています。
例えば、オペレーションを考えた場合、1秒早く処理を実行できるようになれば、数百万円のコストインパクトになることがある。10秒だともっと効果は大きくなりますよね。技術的なメリットだけだと伝わりにくいので、会社の利益にどれだけのインパクトを与えるかを意識して経営陣に説明するようにしています」(濱田さん)
チームメンバーや経営層とのやり取りの中で、濱田さんは相手の立場や考えを思慮しながら、丁寧かつ堅実にプロジェクトを成功へと導いてきた。その上で、プロジェクトを進める上で最も考慮すべき存在について、濱田さんは次のように語る。
「お客さまにプロダクトの価値をどのように提供するか。この問いに向き合い続けられることが、プロジェクトの成功の鍵を握っていると思います。ビジネスである以上、どんなに最新技術を投入しようと、どんなに最高のアーキテクチャ設計をしたシステムでも、お客さまを満足させられなければ、プロジェクトが成功したとは言えません。だからこそ、お客さまの課題に寄り添い、それらを解消するためのプロダクト作りを追求していくべきだと考えています」(濱田さん)
幾多のシステム刷新をリードしてきた経験を振り返り、濱田さんは「刷新を見越したシステム設計の重要性」に気付いたと語る。
「アプリやWebサイトなどエンドユーザー向けのUI/UXは、お客さまへの提供価値が分かりやすいので頻繁に変えていくケースが多い。ただお客さまに見えない管理画面やバックエンドシステムは、長期的に利用することを前提に設計すべきです。
そのため、システムを作る段階からビジネスドメインごとにモジュール性を意識して設計することが重要です。将来的に再構築されることを前提にモジュールごとの入れ替えで済む状態にしておくことで、刷新した際のトラブル発生率を軽減し、成功率を高めることができます」(濱田さん)
システムの構成要素は複雑だ。モノリシックなシステムの場合、構成要素を把握すること自体に時間を要する上に、刷新時に予期せぬエラーが発生する可能性も高まる。だからこそ新しいシステムを開発するときには、拡張性を考えたシステム設計が肝になるのだ。
では、拡張性を考慮した設計を実現するためには、具体的にどのようなアクションを起こせば良いのか。その疑問に対し、「マーティン・ファウラーが提唱した犠牲的アーキテクチャの概念を一読することをおすすめします」と濱田さんは答える。
「犠牲的アーキテクチャとは、チームが開発しているプロダクトは数年後には破棄することを受け入れて製品開発に臨むという考え方です。コードは捨てる前提と心構えを持てると、中長期的な目線でプロダクト開発に臨むため、分離性の高いシステムを作れるようになります。職人のような『作品を作っている』という意識を持ちすぎず、『工業製品を作っている』と一歩引いた目線で業務に取り組むことが重要なんです」(濱田さん)
数社にわたりゼロからの組織作り、システムの刷新を遂行してきた濱田さん。マクロミルでは、24年2月に完成した福岡の開発拠点でリーダーとして陣頭指揮を取る。
「マクロミルは現在、コアビジネスであるリサーチシステムの大規模刷新を進めています。福岡の新拠点は、リサーチシステムに関するプロダクト開発やデータサイエンスを駆使した研究開発をリードする組織へと成長させていきたいです。
既に社内のプロジェクトは、モダンアーキテクチャを採用したアジャイル開発で進めており、社内英語化の推進によってグローバルメンバーもジョインし始めています。福岡は地理的な面でも『アジアの玄関口』というグローバル開発拠点のハブになり得る場所。マクロミルのブランド価値を向上させるような開発組織を目指すために、これまでのキャリアで培った経験を活かしてマクロミルのビジネスを成功に導いていきたいですね」(濱田さん)
取材・文/中たんぺい 撮影/桑原美樹 編集/今中康達(編集部)
NEW!
NEW!
NEW!
タグ