「エンジニアが幸せになる会社にしたい」受託開発から、自社開発への転換。#後編
こんにちは。HRの松岡です。今回はTOWN株式会社さんとの合同記事です。
TOWNさんもメグリも、どちらも受託開発から自社開発へ転換したという共通点があります。本企画では「受託開発から自社開発へ」をテーマに、前後編にわたってお伝えしたいと思います。
前半では、受託開発から自社開発へ転換した時のお話しを中心に伺いました。後半では、自社開発へ転換してからのお話を、プロダクトや開発を中心に詳しくお伺いしていきます。
ニーズ把握方法
島津：プロダクト開発していく上で、クライアントからのニーズはどのように把握していますか？
篠田：MGReだと導入時にニーズを把握することが多いです。導入時のパターンとしては、大きく2つあります。クライアントのやりたいことがはっきりしていて、すでにMGReにある機能がそのまま適応できる場合だと、 あまり細かいニーズを伺わずに、オンボーディングの機会を得てリリースへと進みます。
もう一つは、アプリの要件定義がしっかりできていなかったりMGReの機能ではカバーできない要望がある場合です。クライアントによっては、裏側にあるシステムが複雑でいろいろと制約があったりとか、そもそもどういうアプリを作ればいいのか明確になっていない場合もあります。
そのため、まずはどういったアプリを理想としているのか、そしてメグリでどんなことを叶えたいのか、など寄り添いながらニーズを引き出すようにしています。
岩崎：「クロジカ スケジュール管理」（2023年3月28日に「Aipo」から名称変更）は、個別カスタマイズは一切しないため、既存機能の中から何を使うかユーザー自身に判断してもらっています。
ニーズの把握方法としては、アプリの中のチャットサポートが多いです。チャット上で、実際にユーザーとやり取りができるので、困っている点や機能開発の要望を吸い上げています。
現在、合計4,000件程の要望があって、それを取りまとめて約1000件になっているのですが、優先順位として要望の多いものから順に開発しています。
開発する機能の決め方
松岡：作りたい機能がたくさんある中で、どのように負担を減らしながら開発していますか？
篠田：僕らは基本的にカスタマイズを受けています。MGReはWEBで即決出来るようなサービスではないので、クライアントのニーズをヒアリングした上でカスタマイズの提案をしています。
しかし、僕らもシステムのコア部分に適用する機能に対してはかなり慎重です。「使われない機能をどう省くか」は重要だと思っています。
ただ実際に、クライアントと直接お話していると頂く要望はどれも重要に思えるんですよ。でも、僕らプランナーは常に冷静でい続ける必要があります。「これは本当に多くのクライアントに使ってもらえる機能なのか」と。
開発が必要な機能の場合は抽象化・汎用化を考えた上で追加するよう意識します。
岩崎：「クロジカ スケジュール管理」の場合も、全ての要望を取り入れるのではなく、抽象化など吟味して「少しニッチだけど、こうすればある程度みんな使える機能」にすることを意識しながら開発しています。
実は、以前にとある機能を1年かけて開発したにも関わらず、実際リリースすると利用状況は1％以下だったということがありました。そのような経験があるため、何を開発するかはすごく慎重に考えています。
また、新機能開発においては、ユーザーへのインパクトをなるべく減らすようにしています。例えば、インパクトの大きい機能を作るときは、なるべく小分けにして機能を出すとか、機能を使える人を一部に限定してリリースするとか。
やはり、ユーザーが多いとインパクトや反響が大きいので、なるべく影響範囲を狭めるよう意識しています。
「使われない機能をどう省くか」
島津：「使われない機能をどう省くか」という視点はとても面白いですね！全体的にはあまり使われていない機能でも、一部ユーザーにとっては必要な機能だったりしますよね。ちなみに、汎用性のある機能かどうかはどのように判断するのですか？
篠田：MGReの場合は、プランニングチームでまずどういう機能にするかを決めます。そして、実際に提供したら使ってもらえそうか、魅力的な機能だと思っていただけるのか、クライアントへのヒアリングを行います。
その後、セールスやカスタマーサクセスの担当に説明して意見を聞きます。 そうしないとクライアントに説明できないものをリリースしてトラブルになりかねません。社内での情報共有には、かなり気を使っています。
松岡：クライアントへのヒアリングというのは、インタビューの時間をもらうのでしょうか？
篠田：こちらからインタビューする場合や、定例会議に紛れ込ませてもらって状況を観察する場合もあります。あとは実際にクライアントのお店や、同業種のお店に観察しに行くことも多いです。
実際に店舗にいくと発見も多くて、「店員さんがアプリを勧めてこないけど、これはどういうことだ？」 とか（笑）。聞いてみると実は「アプリ導入の説明が大変で、そこに時間取られるとレジが止まるから勧められない」という課題があったり。クライアントの生の声を聞き、現場の状況を把握することはアプリ開発する上で重要だと思っています。
松岡：考えることがとても多いですね。クライアントの担当者のこと、店舗スタッフのこと、そしてアプリのユーザーのことも考え、みたいな。
篠田：カスタマーエクスペリエンス（CX）と、エンプロイーエクスペリエンス（EX）の両方を良くしないと、アプリは長く使ってもらえないので、どちらもとても意識しています。
汎用性が機能かあるかどうかの判断基準
島津：TOWNの場合は、色々ある要望の中からどのように汎用性がある機能かを判断していますか？
岩崎：最初は、どうしても自分たちの判断では難しいので、早い段階でユーザーに聞くようにしています。モックを作って「このような機能を作ろうと思うのですがどうですか？」と聞いて、反応がよければ開発を進めます。
しかし、ヒアリング時は「良い！」と言ってくれても、本当に使ってくれるかは別問題なので、なるべく機能最小限の形で開発します。
要望をくれるユーザーはプロダクトに対する熱量が高い方が多く、積極的に意見を出してくれます。「クロジカ スケジュール管理」は同じ会社の中でも特定の人だけにリリースすることができるので、対象を絞った上でリリースし「この機能いいので、社内の他のメンバーも使えるようにしてほしい」となればPMFしたとわかります。
「多少使い勝手が悪くても、この機能がないと無理」というのは、頑張って使ってくれるので、そこでニーズを汲み取っています。本当に必要な機能だと分かれば、次にUIの改善をするなどの流れで進めています。
島津：「使われない機能をどう省くか」というのは、エンジニアの働く環境を良くすることでもありますし、ユーザーにとっても「本当に使う機能を作ってくれる」ということなので、両者にとって良いことだなと思いました。
受託開発を経験したからこその開発環境や方法
松岡：受託開発を経験したからこその特徴や開発環境は何かありますか？
篠田：メグリの特徴として、僕が今まで経験してきた会社の中でも突出してプロジェクトマネジメント力が高いと思ってます。他社さんでうまくいかなかったプロジェクトを引き継ぎ、取りまとめた経験が多くて。さらに、システムインテグレーション力も高いので、自分の領域だけでなくて、他の領域も含めて先回りしてケアしたりとか。元々受託の経験がいきていると思っています。
また、MGReのシステム自体も複雑な構造ですが、それをしっかり作りきって、 相当なユーザー数を捌いています。エンドユーザーでいうと、現在の月間アクティブユーザーが約900万人で、PV数は約3億あります。それでも、安定して動くクラウドシステムを構築できています。
島津：TOWNの場合はどうですか？
岩崎：開発サイクルに関しては、とにかく小さくすることですかね。受託の頃は、 Excelでガントチャートを引いて、 実装してテストして検収みたいな流れで開発していたのですが、検収のタイミングでクライアントに見せたら「こうじゃない」ということも結構ありました。
そういうことがないように、今は基本的に1週間以内で成果物ができるサイクルで回しています。1週間経ったら「新しい機能ができました」と見えるようにしていて、そこは受託の時の反省を活かした部分です。
今後の展望
篠田：サービスの目指すところは、まずは対応業種を増やしていくことです。MGReはもともとアパレル業界での認知が広がって、多くのクライアントにご依頼いただいているので、どうしてもアパレル業界に偏っています。
今後は新しい業種へも対応していきたいです。例えば、スーパーマーケットなら「チラシをみたい」とか、アパレル業界にはない機能を用意しなくてはいけません。僕らのPMFを含めて、対応業種を増やしていきたいです。
もう一つは、MGReから派生する形で事業領域を広げていき、新規事業も行っていきたいと考えています。
岩崎：プロダクトの展望としては、カレンダーをハブにしていろんな情報が集まるようにしたいです。例えば、勤怠の情報とか、会社に関わる情報は日付が絡んでくるケースが多いので、そういったものをカレンダーに表示させたいです。まずは、カレンダー上に全ての情報が集まる世界を作りたいと考えています。
それができたら、次はカレンダー自体をもう少しインテリジェントなものにしたいです。例えば「この場所で、何時から」と予定入れると、勝手に移動時間を計算してくれるとか。「次の商談はここぐらいがいいですよ」と教えてくれるとか。
篠田：それはいいですね。リモートワークだと移動時間がなくなって、空いてるからって平気で予定を入れられて「6回連続ミーティングって、俺が昼ご飯食べる時間はどこにあるの！？」 ってことが結構起きるんですよ。なのでカレンダーに「この予定をここに入れたら、篠田さんが可哀そうですよ」とか言ってほしい（笑）。
一同：（笑）
岩崎：いいですね（笑）。そうやって他のグループウエアと差別化して、よりAipoを使う意味を作っていきたいです。
来てほしい人物像
篠田：メグリは本当に自由に色々とやらせてくれて、意欲があればチャレンジできる環境だと思います。ただその分、結果に関しては厳しく捉えることはあるので、そこにコミットできる方だとマッチしています。
働き方としては、完全フルリモートにシフトしました。なので、仕事する場所に関して自由度が高いです。実際に島根県からフルリモート勤務している社員もいます。
そして、子育て世代が多いです。僕もそうなのですが、働きながら育児する人や、育児などで一度離れた方が戻ってくるパターンは多いです。仕事中のSlackでも「そろそろご飯作らなくちゃいけないので終わります」とか、 そういう会話が日常的に飛び交っています。
島津：ちなみに、どういうエンジニアが向いていると思いますか？
篠田：技術が好きで、今後も新しいことに挑戦していきたい方に向いていると思います。うちは、技術的にチャレンジしてる会社だと思っていて、プロダクトはシレッと動いてますが、裏では結構難易度の高い仕組みになっています。地味だけどハイレベルなことをしているので、チャレンジすることが好きな人に向いてますね。
プロジェクトの規模は、改善や機能追加は、大体1ヶ月や短ければ2週間で終わるようなサイクルで回しています。
チーム規模としても、フロントとサーバーサイドとインフラというように役割分担された少人数でチームを組んでいます。チームでコミュニケーションを取りながら、リモートという裁量を任せられてる状況で、ちゃんと自分を律して仕事ができてそれを楽しめる人だと合うと思います。
岩崎：うちの場合は、サーバーサイド、フロントエンドも全部1人でやりきるという体制を取っています。さらに言えば、クライアントにヒアリングして、モックを見せてやり取りするのもエンジニアが直接しています。なので、クライアントに価値を届けて、直接フィードバックをもらうことにモチベーションを感じる人には向いています。
「この機能は全然使ってもらっていない」とか、反応がダイレクトに返ってくるので大変ですが（笑）、その分自分で改善案を考えて進められるので、それは楽しいのではないかなと思います。
あとは、本当にリリースのインパクトがないようにしているので「リリース日に残業しないといけない」とかはなく、さざ波のような小さい波がちょっとずつ来るぐらいなイメージで開発しているので、無理なく取り組めると思います。
島津：さざ波の開発だからこそ、残業時間も少なくできるんですよね。
岩崎：大きい波は受託の時にたくさん経験しているので、もういいかなと（笑）。
篠田：うちも最初のプロダクトを作りながら、大きな受注案件を並行して作っている最中は、本当に大変でしたね。
── 今回の対談を通して、受託時代を経験したからこそ強みや開発体制をお伝えできたかなと思います。今回はお時間いただき、ありがとうございました！
メグリ・TOWNでは、一緒に働く仲間を募集しています。
年間を通して、さまざまな職種を募集しています。ご応募をお待ちしています！
