モバイル端末でさっと見積もり、プロにおまかせできるミツモア依頼者アプリ誕生！ 2ヶ月あまりで開発を実現したアプリチームの連携力を紐解く
「この開発の最優先プライオリティは何か？」チーム全員が全く同じ目標に向かい、それぞれがクオリティの高い仕事に務めること、それが働きやすい環境を作り、短期間でのモバイルアプリ開発を可能にしました。働きやすいと評判のアプリチームに開発の詳細について聞きました。
Zachary Davison プロダクト部 開発f8nチーム（写真左）
アイルランド出身。2021年、エンジニアとしてミツモアに入社。ダブリン工科大学でコンピューターサイエンスを学び、医療業界で5年、ソフトウェアエンジニアとしては10年の業務経験をもつ。
現在はベルリンに在住し、ミツモアにリモート入社して1年が経つ。
kei agou (邢 亜豪) プロダクト部 開発f8nチーム（写真中）
中国出身。2021年8月、エンジニアとしてミツモアに入社。日本企業で働くのはミツモアで3社目。2015年に中国の大学を卒業後、日本に来て京都の日本語学校で日本語を勉強しながら、進学準備。2017年に一橋大学大学院に進学、経済学専攻。大学院にてプログラミングでデータ分析する際にプログラミングの楽しさを実感して、エンジニアになりたいと決意。2019年一橋大学大学院卒業後、受託開発のECサイトエンジニアとして就職。その後、2社目を経験。2021年、新しいチャレンジと技術を高めることを求め、ミツモアに入社。
Yuki Mizoguchi（溝口 悠樹） CEO室 SWATチーム（写真右）
首都大学東京 理工学系物理学コース卒業。JICA 青年海外協力隊として、2年間タンザニアの公立中等学校で理数科教師を勤めた後、2020年9月ミツモアのIBチームに入社。その後CEO室SWATチームに所属。事業者登録フローの改善や、トップページのリデザイン、依頼者アプリ制作等に取り組む。
依頼者アプリ概要と開発前半〜徹底的議論
―依頼者アプリのリリースおめでとうございます！ まずはどのようなアプリかご説明お願いします。
溝口：依頼者アプリは、見積もりを受け取ってプロにお仕事を自由に頼むことができるプラットフォームである「ミツモア」を、モバイルアプリ上でも使えるようにしたアプリです。具体的にはiOSのアップルストア、iPhoneで利用できるアプリとして作っています。「ミツモアPro」という事業者様向けのアプリ、つまり集客する側のアプリはすでにあり、300以上のサービスでプロの方にご利用いただいています。今回は、その300以上のサービスの中から自分にぴったりのプロを見つけたいという人たちに向けて、アプリを作っています。
―モバイルアプリにしかない機能は？
溝口：プッシュ通知ですね。今はweb上でミツモアを使うとEメールがユーザーに届いて、Eメールのリンクを踏むとミツモアのwebにアクセスするんですね。モバイルアプリではEメールだけではなくてプッシュ通知でお知らせがきて、タップすると、すぐに該当のプロとのチャットのページに飛べて、プロとコミュニケーションできる。そのプッシュ通知というのが、モバイルアプリを作りましょうという、一つの大きな意思決定にもなっていましたね。
―開発チームは何人ですか？
溝口：エンジニアは、ザックさん、けいさん、インターンの馬淵くん、QA山本さんの4人ですね。Biz側は僕がチームリードで、あとはデザイナーののぞみさんも入れて6人のチームです。基本的には僕、ザックさん、けいさんの3人でコミュニケーションをかなり取りながらやっていましたね。
―2.5カ月で開発されたというのは本当ですか？
溝口：本当です。最初は間に合わない可能性が高い、という作業見積もりをザックさんとしていました。ただMVP（=Minimum Viable Product 註：必要最小限の機能を備えたプロダクト。ユーザーからのフィードバックを反映することを前提とした開発手法のこと）の機能を実装しながら、順次更新していきましょう、みたいな感じで開始しました。。
―2.5ヶ月間の内訳を教えてください。
溝口：開発に入る前、いろいろと検討した期間が1ヶ月弱ぐらいありました。依頼者アプリを作ることでどれくらいのインパクトがあるのか。どれくらいダウンロードしてくれて、マンスリーでどれくらいのユーザーがアクティブでいてくれるのか。もしくは、そこから依頼を作成して実際にプロにどれくらいお仕事を頼んでいただけるのか。またマーケティング的にどれくらいの価値があるものか、LTVをアップさせるためにどのぐらい重要な位置を占めそうなのか、といったことです。その後に、開発フェーズに入ると、基本的にはたくさん機能があるので、機能ごと、もしくはページごとに、プロダクトの要件を決めていって、順々に、ザックさん、けいさんとコミュニケーションを取りながら実装はこういう風に進めましょうと、決めていって実装していく。開発がほぼ始まったタイミングから大体2〜3週間ぐらいは、フローチャートや仕様書を見ながら議論してました。というのは、意思疎通をしながら作らないと、後から手戻りがたくさん出るとリリースが間に合わないと最初から思っていたからです。特に最初は、ものすごく慎重に、視覚的にコミュニケーションを取るようにしてましたね。
議論を助けたFigmaでの視覚的コミュニケーション
―その溝口さんの仕様書が分かりやすいと評判だったそうですが？ ザックさんとけいさんはどう思われましたか？
ザック：素晴らしかったです。書かれてあるべきことが書かれていたということと、自分はまだミツモアに入って7、8ヶ月ぐらいなので、webサイト上で、ミツモアに存在している機能に普段の業務で触れてきていなかった。自分にとっては新しい領域が多かったので、細かいドキュメンテーションだったり、けいさんと溝口さんが長い時間ミツモアで仕事してきているので、わからないこともクイックに返事が返ってくるのが良かったです。
けい：私もそんなにミツモア長くないので（笑）、知らないことも多いので、溝口さんがすぐ返事してくれるのは助かりましたね。
溝口：ザックさんとけいさんは入社時期がほとんど変わらないんですね。僕も1年半なので、みんなそんなに長くはない（笑）。僕が少しは知ってることが多くて役に立ったのかな？
―仕様書は何語で書かれたんですか？
溝口：エンジニアサイドには英語で書いて、ビジネス側のメンバーと共有するために日本語でも作りました。
―アプリ開発等では仕様書が肝になると良く聞きますが、溝口さんは仕様書を書く経験はこれまでありましたか？
溝口：初めてでした。特にブランディングフェーズ、要件を決めるようなフェーズでは、どうドキュメンテーションすべきか勉強はしました。本なども読みましたね、それが役に立った部分はあったと思います。ユーザーストーリーをマッピングしていって、どのストーリーが重要そうかを視覚的に区別する手法で、どの機能を作ってどの機能を作らないのか、最初のフェーズでコンセンサスを取ることができました。ただ機能を羅列しただけだと何が重要か良くわからなくて、実装の開始が遅れてしまったかもしれません。
―けいさんは日本の別の企業でもエンジニアをされてましたが、溝口さんの仕様書はその時と比べてどうでしたか？
けい：その時感じたのは、文字で表すことはなかなか難しい。溝口さんはユーザーストーリーのマッピングを、Figmaで説明してくれてすごくわかりやすかったですね。
溝口：ドキュメントを書く時、文字が多いと抜け漏れがある。デザイナーさんが日本人の方で、リモートで仕事されていて、僕は直接は一度も会ったことがないです。そのためあまり文字には頼らずに、webアプリ版のミツモアの画面遷移をどうアプリ上で表示するかコメントを残して、できるだけ視覚的にコミュニケーションを取ろうとはしていましたね。正直なところ、僕も英語が久しぶりだったり、時にわからなかったりして、英語のコミュニケーションが難しいと思った時や、訳すのが大変な時にも、絵を見ながらコミュニケーションすれば「これをこうすればいい」みたいな簡単な言葉であとは通じる。そういう風に意識して、いろいろ仕様について議論するというのはしてきました。確かにそれは良かったと、今振り返って思っています。
―Figmaで作った仕様書の画面を少し見せてもらえますか？
溝口：このように、今あるWeb上に存在しているページをアプリにどのように変更するか、議論するためにいろいろとドキュメントを用意していましたね。
―すごく面白いし、確かに視覚的にコミュニケーションをとりやすそうですね。
溝口：起点となるページのここを押すと矢印が伸びていって、ある箇所をタップするとweb上に存在しているこのページに飛びます。ただ仕様変更する場所は「アプリ上ではこの箇所は表示しないよ」というコメントをひたすら書き残していきました。ミーティングの時にこれを見ながら、ここの仕様はこうすべきだね、などの議論をして、何を作るのか決めるというのを特に前半ではやってました。
ザック：溝口さん、Figmaでこのフローを作ってくれてありがとう。Figmaでデザインが明示されていたのと、遷移図などいろんな機能がある中で、どういう風に繋ぎ込めばいいのかなどが、とてもわかりやすかったです。
開発の後半〜webアプリとネイティブアプリの違い
―エンジニアが一番最初にとりかかった所はどこだったんですか？
ザック：最初はログイン画面です。ログインしてから事業者さんとチャット等でやりとりしたり、面談の予約ができるようになるので、最初にログイン機能、もしくはサインアップ機能を実装しました。その後、ほとんどの機能というのは、web側に存在しているので、TOPページを最初に見せるホームタブのところに埋め込みました。その後は、依頼者さんと事業者さんがやりとりするチャットのページや、過去に見積もりを頼んだサービスの一覧を見られる依頼リストのページといった「ログインした後に見られるページ」、つまりwebにすでに存在しているページをとにかくアプリの中に埋め込んでいく、繋ぎ込んでいくというような実装を進めていった流れになりますね。
―webがあるので短期間でできたのかと思うんですが、逆にwebがあるから大変だったことはありますか？
ザック：常にwebサイトに存在している機能を、web画面そのまま見せるわけじゃなくて、アプリの画面として新しく作って見せる、そしてアプリの機能として使えるようにする。web上の機能をそのまま繋ぎ込んだ訳ではなく、繋ぎ込み方がすごく複雑だったり、時には作り直しに近いような実装をしないといけなかった。Webをアプリに繋ぎ込んだ時に失われる機能もあって、うまく行かなかったこともたくさんありました。それをちゃんとアプリの画面でも使えるようにすることにかなりの時間がかかりましたね。ほとんどの時間を使ったといっていいくらいです。
けい：自分はスマホアプリの開発の経験が浅いので、スマホアプリならではの機能、考え方、UX的に考えるべきことがweb上と違うことなどを、初めて意識して開発していましたね。それは自分にとって難しい仕事でした。それと、ミツモアwebアプリはすでにあるので、それをwebviewを使ってモバイルアプリにして、モバイルアプリのロジックと合わない時は大変でした。モバイルアプリの経験が少ないので、すでにあるものとロジックが合わない時、webアプリをどう変えるのかが難しかったですね。ザックさんはどこが難しかったですか？
ザック：ネイティブモバイルアプリと、webアプリとの違いが難しかったですね。ログインの画面はwebアプリにはもちろんあるので、モバイルアプリのログインとwebアプリのログインとのロジックが違って、それをどう組み込むのがいいのか、それが難しかったですね。あとは、ログインのところもwebアプリにいくつもあって、それを正常に動くようにするのが大変でした。
溝口：webアプリとモバイルアプリのいろんなところで接続設定、接点があって、そこでちゃんとログインしてますという情報を受け渡すのが、とても大変でした。グッドニュースだと、ほとんどの機能はweb上にある機能だったので、そのweb上にある機能をちゃんとアプリでも使えるようにするというのが、さっきのログインを含めて一番重要な実装で、もしその機能を1から作らなきゃいけないとなっていたら、そもそも4ヶ月ぐらい実装にかかってましたね。ログイン状態を保持したままいろんなページに行かないとログアウト用のトップページに行ったりしてしまう。いろんなタブでいろんな画面でログインstateであるという情報を保持したままユーザーが使えるようにするのが大変だったという話ですね。
ザック：QAチームの山本さんはすごくいい仕事をしてくれましたね。
溝口：QAというのは品質保証、ミツモアで開発した機能をオモテに出す前にちゃんと機能すること、期待している要件を満たしてくれることをチェックしてくれるエンジニアの仕事です。特に2ヶ月あったうちの後半の1ヶ月は、山本さんに、web上にある機能をモバイルアプリに繋ぎ込んだら、そのまま品質のチェックというタスクをお願いしました。「この機能実装したから、山本さんチェックお願いします」とざっくりした依頼をしても、山本さんがどういうテストをするのか構想していただいて、ユーザーにとって重要な機能のテストを実施してくれた。バグなど発見すれば、ザックさん、けいさん、僕にSlackでメンションしてくれて、後半の1ヶ月は特に、山本さんがチェックして、バグが起きたら開発チームで直してく、というやりとりを頻繁に行いましたね。
―他社のエンジニアの人に、ミツモアの開発部は、こんなに働きやすいぞ、とアピールしたいことはありますか？
ザック：モダンなテクノロジーを使っているというのと、ドキュメンテーションがしっかりしていることの二つです。モダンなテクノロジーは、Typescriptや、Storybookですね。すでにweb側で使われているミツモアのコンポーネントに関する情報がある。新しく作ったコンポーネントをStorybookの中に入れておく。Storybookを作ったら、スマホアプリを見なくても、コンポーネントがどうなっているのかわかる。今はスモールチームでやっているので、これからの話ですが、これから依頼者アプリを追加実装するスタッフの方がジョインした時、だんだんチームが大きくなってくると、新しく作ったコンポーネントが視覚的にどういうものなのかを確認できる。
けい：これからジョインするエンジニアはこれがあるとわかりやすいですね。初期メンバーはどんなものかもうわかっているので、あまり使わないんですけど、これから入るエンジニアにはすごく良いものです。ミツモアでは主にReact Nativeというツールを使って開発しています。Typescriptで書いて、iOSのネイティブ言語のSwiftにコンパイルすることができます。これからのAndroid版もほぼ同じコードベースでコンパイル先をAndroidのJavaに変えればすぐに作れます。
短期間での開発を可能にした理由は働きやすさ
―ここ2ヶ月は開発のコミュニケーションで忙しかったと思うんですけど、この機会に3人で何か言っておきたいことや聞いてみたいことはありますか？
ザック：タイトなスケジュールだったので、何かモバイルアプリ上の機能で実装のアイデア、何か別のものがありそうとか、この機能この方法で実装するとうまくいかなそうとか、工数がかかりそうとか、という話があった時に、slack上ですごくクイックにチーム内で話し合いました。別のアイデアで実装できないかとか、時にはこの機能はバージョン1ではなくて、1.1とか、将来の実装にしようとかいう意思決定をかなりフレキシブルに話せたのはよかったね。
けい：今回時間がなかったので、機能をシンプルにしたい時がよくありましたね。その時は溝口さんと相談して、溝口さんの返事が速いのはすごくよかったですね。理解してくれることもありがたいですね。こういう機能を作れないことはないんですけど、時間がかかるので今回は後回しにして導入を見送ったものも、いくつもありますね。
溝口：今の話を聞いてて思ったのは、最初にザックさんにもけいさんにもチームの目的が何なのかという話を、最初のミーティングで1時間ぐらいかけて認識合わせしたのを思い出しました。具体的にはミツモアがTVCMを4月22日に控えていたんですけど、そのTVCMに間に合わせる形でモバイルアプリをリリースしたい、というのがファーストプライオリティだね、という話を私やマーケティングチームの人と話ながら、デザイナーさんと開発チームにもシェアできていたかなと思います。なので、けいさんやザックさんから「この機能の実装は時間かかるけど、プライオリティ高いの？ UX的にはそうでもないんじゃない？」と相談があった時には、目的が一致していたので、割とスピーディに、その機能はバージョン1.1にするとか、ていうコンセンサスを取れてたのではないかと思ってます。
―このチームは働きやすいと評判みたいですが？
けい：アイデアがあればすぐに相談できる人がいます。何でも話して大丈夫というのは一番働きやすいところです。ザックさんはすごく経験豊富なエンジニアです。ビジネス側とのコミュニケーションの仕方も上手ですし、私たちエンジニアとの話し方も上手です。多分これが働きやすさの秘訣ですね。優秀なエンジニアです。
溝口：開発2ヶ月という中での前半1ヶ月は僕がよく喋って、ミーティングの中でもがんばって仕様決めようみたいにやっていたんですけど、プロジェクトの後半1ヶ月はザックさんが、主に機能ごとにストーリーを立てて、各受入条件をどうしようかとか、主に開発側の話にシフトしてきていたので、プロジェクトをリードしてくれた部分が無茶苦茶助かったなと思ってます。そういう意味だと、僕がリードっていうよりは、役割に応じてという表現がぴったりだと思ってますし、実際ザックさんがリードするrefinement会議は、とても効率的に進められました。実装タスクを行う上での懸念点だったり、何がベストなソリューションかということを議論するミーティングを主宰されたんですけど、そのミーティングもフランクな雰囲気かつ時間も守るようなスタイルで、ベストなソリューションが出るようにいろいろコミュニケーションをオーガナイズしてくれた。僕にとっては初めて開発寄りのミーティングに出る機会だったんですけど、いつもすごいなと感じていました。
けい：ザックさんは、例えば仕様を決める時、すごい具体的にしてくれますね。受入条件も箇条書きで、ミーティングで決めてしまうのが助かりますね。どんなことをすべきかその場ですぐわかります。どのくらい時間がかかるのか、受入条件があればすごく分かりやすいですね。普通、受入条件は、箇条書きじゃない時もありますね。
溝口：それは文章としてただバーっと書くみたいな感じですか？
けい：そうですね、ザックさんの方がもっと詳しく書いてます。エンジニアの立場で、困ることとか、こういうことが発生したらどう対応するか、もう全部考えてくれてます。
溝口：僕がビジネス側が要望する機能をスプレットシートにリストアップしたのですが、すごい抽象的に書いていたにもかかわらず、いざ開発しようとなった時の仕様検討ミーティングをエンジニア側で開く時には、ザックさんが他のエンジニアと一緒に、その機能を実装する時に、どういうリスクがあるのか、より簡単に実装することができないかなど、エンジニア側に立って具体的に何を達成しなきゃいけないのかというのを、箇条書きに細かく書いてくれました。その合意をちゃんと取ってから、どのぐらいの時間がかかるのか、タスクなどの作業見積もりをしていていましたね。
けい：他の開発のエンジニアのミーティングだと、もうちょっと抽象的なところまでしかお話してないみたいなので、それを箇条書きでエンジニアが困りそうなポイントとかにちゃんとメンションしながら、どうやってタスクを進めればいいのかというのを明確にする役割をザックさんが担われていて、そこが他の開発がやっているようなミーティングとは違ったみたいですね。
―皆さんは今後、どういうエンジニアと一緒に働きたいですか？
溝口：僕はザックさんやけいさんみたいなエンジニアの方と働ければ嬉しいですね。ミーティングでも仕様についても細かく分解した上で具体的に考えてから開発してくださるし、すごく気軽にコミュニケーションも取れる。開発の途中でもフレキシブルに方向転換しながら開発してくださるのでありがたかったですね。そんな人そうそういないとも思います。ただただありがたかったなと。
けい：モダンな技術が好きな方、ハイクオリティなコードが好きな方、ドキュメントとテストを書くことに慣れてるエンジニアと一緒に働きたいですね。今は主にTypescript、あとはAWSとか、Terraformとか。これからもモバイルアプリを作るチャンスはあると思います。ネイティブのモバイルアプリ経験があるエンジニアも、ウェルカムです。
ザック：目の前の機能の実装だけではなくて、長期的にコードのクオリティを向上させるすることに努力するエンジニアがほしいですね。ドキュメントとテストをちゃんと書く人。コードは書くよりも見ることが圧倒的に多いので、自分のためだけに書くんじゃなくて、誰がみても分かりやすいコードをがんばって書きましょう。
―ありがとうございます！ このチームの働きやすさについて各自もう一度お願いします。
溝口：特に僕が働きやすいなと思っていることは、ある意味でザックさん、けいさんの方が、ビジネス側のアイデアに対して的を射た意見を言ってくれる。そういう意味で僕はまだミツモアのようなIT企業で1年半しか働いてないのですが、経験豊富なエンジニアの方と働けてとても嬉しい。会社の目的がこうだから、今このプロジェクトはこうしようと同じ目標を持ちながら仕事が出来ています。すごく成長の機会に恵まれていると思っています。プロダクトマネジメントに興味ある方だったり、今プロダクトマネジメントをやってる方も、今のミツモアはプロジェクトをリードしたり、どういう要件で何の目的を達成するのかというのを決定してからインパクトを出すところまでを、一気通貫で責任を持ってやらせてくれるチームばかりです。成長意欲がある方、経験豊富な人と仕事がしたい方、挑戦したいという方にはぴったりだと思います。
けい：アプリチームはなんでも相談できます。導入したいツールとかあれば、みんなで相談して導入できるとか、みんなクオリティが高いコードが好きなので、少し時間かかっても、より良いクオリティを求めています。それがよかったです。
ザック：仕事のクオリティが高いです。溝口さんは、ビジネス側と開発側のコミュニケーションを頻繁にとってくれてよかったです。きっと実際はたくさん大変なことがありながら働いてくれたはず。けいさんは知識がそもそも豊富で、良いエンジニアです。馬淵くんもインターンでありながらすごく良いエンジニアリングをしていました。QAの山本さんも、彼の仕事なしではリリースに間に合わなかった。すごく能力の高い人たちが集まっています。なので「能力の高い人たちと一緒に働ける」というのが働きやすさの答えかもしれませんね。
―ありがとうございました！
（取材・執筆 字と図 吉田千枝子）
======================================
ミツモアでは、現在事業拡大を進めており、エンジニア・デザイナー・PdMをはじめ多くの職種で積極採用中です。
Wantedlyにて募集しているので、カジュアルに面談に来てみませんか？
デザイングループも所属するプロダクト部の詳しいご紹介は「ミツモア エンジニア向け会社説明資料 / about meetsmore for engineers」を公開しております。
この記事が気に入ったらサポートをしてみませんか？