株式会社メルペイ 執行役員 VP of Engineering 木村秀夫
ISPでエンジニアとしてのキャリアをスタートさせ、独立起業や通信キャリア等での開発業務を経て、2009年株式会社ディー・エヌ・エーに入社。Mobageオープンプラットフォームの立ち上げ、グローバル展開、Mobage全体のマネジメントに従事。2013年に執行役員に就任。その後もオートモーティブ新規事業立ち上げ、システム&デザイン本部長を経て、2018年5月、株式会社メルペイ執行役員 VP of Engineering に就任。
依存関係の整理と優先順位付けでタイムリーなリリースを実現
――メルペイのリリースより１年前は、プロダクトマネージャーに業務が集中し、エンジニアとの連携にも支障が出ていた状態だったと伺いました。エンジニアリングマネージャーとして、どのようにプロダクトマネージャーと連携し、プロジェクトを立て直されたのか、具体的に行われたことについてお話しいただけますか。
木村：まず、さまざまな要件について同時並行でプロジェクトが進み、混沌としていたので、各プロジェクトの依存関係を整理し、リリースの時期やリソースの投入などについて優先順位を見直しました。その際に意識したのが、「ビジネス」「ユーザー」そして「社内リソース」の3つの観点です。
例えばメルペイの決済手段はiDとバーコードの2種類あるのですが、その優先順位決めでは、決済店舗側との関係性を考慮しました。iDは裏側での連携は必要ですが、店舗に対応してもらうことはほとんどありません。しかし、バーコードの方は店舗側にもインストールが必要で、いわば依存関係にあります。つまり、iDの方が早く搭載できるわけです。
人的リソースについても、iOSよりもAndroidの方がさまざまな端末に対応する必要があるため難易度が高く、スキルを持つエンジニアも限られます。またユーザーニーズについても、メルカリではiOSの方が利用者が多いので優先度が高いでしょうと。こういったことを考慮して、Android対応は後ろ倒しにするなどの決定を行いました。
――こうした調整過程で、最も難しかった部分、苦労された部分はどのようなことですか。
木村：整理することは黙々とできますが、優先順位を付ける際に、それをプロダクト側（企画・プロダクトマネジメントを担うチーム）に合意してもらうことには苦労しました。メルペイにとって初めてのブランドローンチだったために、「目玉となる機能を盛りだくさんで出したい」という要望が、プロダクト側だけでなく、マーケティング部門などからも出ていたのです。決済アプリは市場的にもホットで、まさに「TTM（time to market）」としてビジネスの成功にも直結するタイミングですから、私としても意図や気持ちは十分に理解できました。しかし、プロダクトとして失敗するわけにはいかないので、とにかく丁寧に、理由と優先順位、品質とリスクなどについて説明し、納得してもらいました。
特にエンジニアリングの観点で言えば、負荷については出してみないとわからない部分があります。どんなにテストを行ってもエッジケースはあり、範囲が広がるほど100％のカバレッジを担保することは難しい。リスクを回避するには、できるだけ影響範囲を小さくして出す必要があることも説明しました。
重要度や依存関係で返すべき技術的負債を決定、OKRでのタスク登録で確実に取り組む
――そして、リリース後は新しい機能も追加され、順調な成長段階にあるように見受けられます。リリースまでとそれ以降とで、エンジニアリングの手法など変わったことはありますか。
木村：初期リリースについてはプロモーションスケジュールまで決まっており、ずらしようがなかったため、ガチガチに仕様を固めていわゆるウォーターフォールに近い形で行いました。依存関係も複雑で自分たちだけ調整しても意味がなかったですし、とにかくリソースも時間もギリギリの状態でしたからね。
成長段階に入ってからは、体制がコンポーネントに閉じるので、アジャイルで行っています。ただ、ローンチ後の3か月間は、注目度も高かったので、「メルペイスマート払い」という信用を軸にした新しいサービスの開発やキャンペーン、クーポン配布などのプロモーションに注力し、初期リリース時と同じような力技で行っていました。メルカリの方に頼み込んでエンジニアを動員してもらい、なんとか乗り切ったというところですね。幸い事業的には大成功を収めましたが、いろいろと負債も残りました。
そこで、次の3か月間は、意識して「技術的負債を返す時間」とするように調整しました。リリースから3か月後まで、無理に調整したところや、自動化すれば効率が上がるとわかりつつも力技でやってしまったところなどが残っていたため、そのまま新しい機能を追加し続ければ、後に大きな負債となることは明白でした。そこで、プロダクト側、経営側に技術的負債によるリスクについて説明を行い、理解を得てタスクとしてもらいました。
――技術的負債に関しては、その後の開発運用を妨げる要因としてあげられます。新機能の追加が順調に行われているのは、その返済をしっかりなされたからということなのですね。
木村：とにかく大きく借りましたからね。でも、それも必要なことで、決して悪いことではなかったと思っています。そして完全に返済する必要もないと思っています。本来は「小さく借りて小さく返す」のが基本ですが、負債そのものが悪いのではなく、大きく借りたままなのが問題なのです。そこで早々に開発速度が担保できるよう、期間を設けて、重大性と優先度で優先順位を付けて返済に取り組むようにしたわけです。
まず真っ先に返すべきなのは、セキュリティや品質を損ねる可能性のあるもの、そして、プロダクトの外側と依存関係にあり、部署横断で意思決定が必要なものでした。プロダクトで閉じているものなら、後から自分たちで返せばいいわけです。そうして決定した返済業務は、経営層の理解のもと、当社で導入している目標設定・管理手法の「OKR（Objectives and Key Results）」にタスクとして入れ込んだことで確実に取り組まれることとなりました。エンジニア以外についても技術的負債に関する理解が進んだことは大きな意味があったと思います。
ただし、こうした技術的負債や返済の案配は、エンジニアリングマネージャーが知っておくべきことで、スキルと言うより経験値なのかもしれません。例えばビジネスとして成功するかどうかわからないスタートアップなら、大きく借りたままでまずは出してみるという判断もできます。成長が妨げられると判断すれば、その前に返済すればいいわけです。そして、必要な返済についてはプロダクト側や経営層に理解してもらい、不必要な返済や返済時期の繰り延べについてエンジニアに納得してもらう。それもスキルのうちだと思います。
