編集部注
本稿は、CodeZineに掲載された、ソフトウェア開発者向けカンファレンス「Developers Summit 2025（デブサミ2025）」のセッションレポートを転載したものです。プロダクトづくり、プロダクトマネジメントに近しいテーマを選りすぐってお届けします。
ゼロからサービスを立ち上げる「超初期フェーズ」においてとるべき選択
本講演に登壇したウェルスナビ株式会社 執行役員CTO 保科智秀氏は、2015年10月に創業間もないウェルスナビに入社して以来、同社の事業の急成長をエンジニアとしての立場からけん引してきた。現在同社が提供する資産運用ロボアドバイザーサービス「WealthNavi」は40万人以上のユーザーを獲得し、総運用資産額は約1兆4000億円に達している（2025年2月13日時点）。これだけの規模に事業が急成長する過程において、同氏がエンジニアとしてどのように事業成長に関わってきたのか、事業成長の各フェーズに分けて解説が行われた。
まず創業当初の「超初期フェーズ」では、事業計画とコンセプトはあるものの、サービスの形はまだ何もない状態からスタートした。このフェーズでサービスに求められた主要な要件は、「資産運用の手続きが簡単にできること」「簡単な質問に回答することで最適な資産配分を提案できること」「資産配分に基づいて金融商品を自動で売買できること」「一連の取引に関して法令などを遵守した帳票などが作成されること」の4点だった。
これらの要件を限られたリソースの中で満たすべく、保科氏らのチームはまず優先順位を明確にしたという。「簡単に手続きが行える」という要件についてはこの時点ではいったん妥協し、「簡単な質問による最適な資産配分提案」と「自動売買機能」の開発に注力した。その結果、一般公開前の評価バージョンである「クローズドβ」の完成にまでこぎ着け、法令を遵守した取引が実現できる基盤を構築できたものの、UIとUXの出来栄えについてはこの時点ではまだ不十分だった。
またこのフェーズの開発において保科氏が特に重視したのが、「前向きなコミュニケーション」だったという。
「人も時間も足りないという状況下では、エンジニアは得てして『こんな開発スケジュールでは到底無理です。とにかく要件を削ってください』というネガティブなコミュニケーションに終始しがちです。しかしそれでは、サービスを一刻でも早くローンチしたい事業側との間で軋轢が生じてしまいます」（保科氏）
こうした課題を解決するために、システムを作る側と事業を考える側が、互いにパートナーとしての立場から「事業として目標を達成するために、どこが本当に重要なのか？」「譲れないポイントはどこか？」といった本質的な対話を重ねることを心掛けたという。
サービスのローンチに向けてエンジニアが心掛けるべきこと
次に、クローズドβからサービスの一般公開に向けたフェーズでは、「利用開始手続きを簡単にすること」「デザイン全体を良くすること」「売買のアルゴリズムを高度化すること」という3つのサービス要件が新たに掲げられた。
まず利用開始手続きの簡素化については、サービスのUIを見直してユーザー側の入力項目を減らすとともに、社内の業務プロセスの分析・改善も同時に行った。またデザイン面では継ぎはぎ的な改修ではなく、将来のサービス拡張にも耐えられるようフレームワークを一から新たに刷新した。
その結果、簡単に利用を始められるユーザーフレンドリーなサービスが実現した一方で、その代償としてUX改善を目的とした社内の業務オペレーションが増えてしまうという副作用が生じた。一例を挙げると、ユーザーが身分証明書の画像をアップロードできる機能を新たに実装したが、その内容のチェックを全て手作業で行っていたため業務負荷が一気に高まってしまったという。
なおこのフェーズにおいてエンジニアが心掛けるべきことについて、保科氏は「要件を満たすために手段をシステムだけに閉ざさないこと」「安易な解決策に飛びつかないこと」の2点を挙げるとともに、当時を次のように振り返る。
「UXを抜本的に改善するために業務プロセスを見直す際、エンジニアも業務プロセスにしっかりと入り込み、システムだけでなく業務プロセスについてもしっかり把握することがポイントでした。また安易な解決策に飛び付かず、将来にわたって継続できる改善策を考えることも大事ですが、その一方で10年後のような遠い未来のことを考えすぎると時間だけがかかってしまうので、その辺りのバランスをうまくとることも大事です」
開発スピードが最優先されるフェーズでは技術的負債の発生もやむなし
サービスのローンチ後、ユーザーを増やしていく成長期のフェーズでは、新たに「ユーザーが簡単に資産運用を開始・継続できる機能の構築」「少額で資産運用を開始できる仕組みの実現」「社内の業務負荷の軽減」という3つの要件が掲げられた。
これらの要件を満たすべく、同社の開発チームはリアルタイムでのオンライン入金機能や口座からの自動引き落としによる積立機能を新たに導入し、ユーザーの利便性を高めた。また「1000分の1株」から取引できるようシステム全体を変更することで、少額からの資産運用を可能にした。また前フェーズにおいて新たに持ち上がった「社内業務の負荷増大」という課題を解決すべく、業務のシステム化による自動化を進め、作業コストと人為的ミスの削減を実現した。
その一方で、スピードを最優先した開発の結果、「美しくない設計」や「システム全体の整合性を欠いた実装」が増えてしまい、システム的な負債も蓄積していってしまった。この点について、保科氏は「このフェーズにおいて技術的負債が発生することは、ある程度はやむを得ないことではないか」と見解を述べる。
「この『1から10に成長するフェーズ』は、事業成長にとって極めて重要な局面です。このタイミングで成長スピードが鈍化すると後発の競合サービスにあっという間に抜き去られるリスクがあるため、このフェーズではシステム的な負債にある程度目をつぶっていても前に進むマインドをエンジニアも持つべきだと思います」
新機能の素早い投入と技術的負債の解消を両立させるために
さらなる成長を目指す「10から100へ」のフェーズでは、前フェーズで発生した課題を解消するとともに、さらなる事業成長を目指して「トレンドに合わせたプロダクトのアップデート」「負債の解消とキャパシティの強化」「新規事業展開を見据えたアーキテクチャ変更」というサービス要件が新たに掲げられた。
ここでは、「最低取引金額の引き下げ」や「新NISAへの対応」といった市場トレンドへ対応するための新機能の開発が求められる一方で、蓄積した技術的負債への対応も同時に行わなくてはならなかった。そこで保科氏らのチームは、新機能の開発を止めることなく、かつ同時並行で技術的負債を解消するための大規模改善を行うべく、開発プロセスに新たにさまざまな工夫を凝らした。また新事業を立ち上げる際に俊敏に対応できるよう、プロダクト間で共通する機能の切り出しと共通化を進めるなどのアーキテクチャ変更も行った。
この「サービス規模を一気にスケールさせるフェーズ」においてエンジニアに求められることとして、保科氏は「ビジネスの将来像に対する高解像度なイメージ」を挙げる。
「技術的負債解消の必要性を事業側に説く際には、『事業の目指すべき姿を実現するためには、こういうシステムが必要ですよね』『現在と未来のあるべき姿とのギャップを埋めていかないと、次の事業の成長につながりませんよね』といったように、あくまでも事業の目線に立ったコミュニケーションを行うことが重要です」
事業成長に貢献できるエンジニアであるために心掛けるべきこと
これら一連の事業成長フェーズと、それぞれにおいてエンジニアとして心掛けてきたことや学んだことを振り返りながら、保科氏は次のように述べる。
「振り返ってみると、事業成長の各フェーズにおいて、それぞれエンジニアとして異なる判断を下してきました。最初は『とりあえず作れ！』という判断でしたが、後のフェーズになると『将来の価値』に着目した判断もするようになりました。逆に、もし全てのフェーズで画一的な判断を行っていたら、事業成長は成し遂げられなかったかもしれません」
このように保科氏は、事業成長に貢献できるエンジニアになるためには、事業の状態や目標、将来の展望に合わせて判断を柔軟かつ適切に変えられることが重要だという。そのために有効な思考法として、同氏は「事業の状態や目標、将来の展望を理解するためのコミュニケーションを重視する」「直感的に受け入れにくい意見にも耳を傾け、その正しさを確認してみる」「前提となるファクトを疑い、見えていない情報にも目を向ける」「スピード感を常に意識し、情報収集と判断のバランス感覚を鍛える」の4点を強調する。
最後に同氏は、「『やるぞ！』と決めたら迷わず前に進むことが一番大事」と強調した。
「何かをするときに『ああしておいた方が良かったかな？』と迷っていると、なかなかアウトプットが出ません。一度『やるぞ！』と決めたらとにかく前に進むことが大事です。ただし進む途中で間違いに気付いたときには、素早く軌道修正する切り替えの早さも大切です」
