エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン

ヤフーのeコマース革命は第2フェーズへ~小澤氏らに聞く、人員が増え続けても「爆速開発」が可能な理由

公開

 

昨年10月、「出店料無料化」という切り札を掲げてYahoo! JAPANが開始したeコマース革命。その革命が、次なる動きを見せ始めた。

同社では、今春までをメドにトータル170名の大規模採用を行っており、そのうち約90名がエンジニア募集となっている。

Yahoo!ショッピングが行っている中途採用の募集ページ

新規採用者が従事するのは、主にeコマース革命を担っているショッピングカンパニー。昨年の弊誌インタビュー《Yahoo!ショッピング小澤隆生氏が描く、未来のeコマース構想 》で触れたとおり、Yahoo!ショッピングを抜本的に見直している部門だ。

このタイミングで人員を増やすのは、eコマース革命が「第2フェーズ」に入ったから。Yahoo! JAPAN執行役員でショッピングカンパニー長を務める小澤隆生氏は、「もともとeコマース革命はロケットの打ち上げのように進めることを想定していた」という。

うまく1段目が切り離せたら2段目、その次は3段目といった具合に、ステップを踏んで革命を起こそうとしている。

新規にAPI50本をリリースetc.でオープン化戦略を開始

今年2月に行われたソフトバンクグループの決算発表会によると、Yahoo!ショッピングは出店料無料化などの施策でストアの新規出店希望者数を9万件以上に伸ばしている。「Webサービスには、立ち上げ直後に話題をさらっても失速するものがたくさんあるが、Yahoo!ショッピングは幸いにも第1フェーズをうまく切り抜けた」と小澤氏は振り返る。

結果、満を持しての戦力増強となったのだ。

そして、すでに第2フェーズは動き出している。3月には出店者向けAPIを50本リリースしてYahoo!ショッピングのオープン化戦略を開始する予定で、3月13日に行う開発者向けイベント『Yahoo!ショッピング デベロッパーミーティング2014』で詳細を発表するという。

ほかにも、現在提供している「スマホだけでも3ステップでストアが構築できる」が売りの『ストアクリエイター』の改善や、より作り込みたい人のための『ストアクリエイター・プロ』の提供などを予定している。

急増したトランザクションに対応するインフラ強化や、CI(継続的インテグレーション)を含めたあらゆる側面でのバージョンアップと、まさにYahoo! JAPANが昨年掲げていた“爆速”で開発が進んでいるが、このスピードは、エンジニアの人数が増えても保たれるのだろうか。

その疑問を、Yahoo! JAPANに直撃してきた。

承認数の削減や、タスクフォースによるチーム編成が速さの根源

(写真左から)Yahoo!ショッピングのカンパニー長を務める小澤隆生氏と、テクニカルディレクター平田源鐘氏

「そもそも、eコマース革命が始まる前に比べて、ショッピングカンパニーのエンジニア数は従来の約10倍になっています。それでも、開発スピードは落ちていません」

そう話すのは、ショッピングカンパニープロダクション本部の本部長で、テクニカルディレクターを務める平田源鐘氏だ。

「最新のOSSや便利なライブラリ、開発手法などを駆使して開発効率を上げても、コーディングスピード自体は変わりません。それでもプロダクトの開発が爆速になったのは、進む方向性が明確になり、現場判断が速くなったからです」

判断の高速化をもたらすために徹底的な開発プロセスの見直しを行い、さらに開発陣を少人数のユニットに細分化した上で、権限を委譲して現場判断で仕事を進められるようにしてきた。

「承認待ちや手戻りが、まったくなくなりました」と平田氏は言う。

ユニットも柔軟に構築している。従来なら人事異動を伴うような人の動きも、バーチャルに構成するタスクフォース単位で開発を進めることで、最適なチームを組むための自由度を上げた。

「例えばクーポンを開発するなら、それに適したスキルや経験を持つ社員を従来の担当業務から完全に切り離した上でタスクフォースに参加してもらい、クーポン開発に没頭してもらうのです」(平田氏)

そして、タスクフォースの目的を達成したら、順次解散。その後の保守・運用や改善作業は、別の専任チームに任せる格好になる。

では、「進む方向性が明確になった」のは、どんな施策によるものなのか。ヒントは、小澤氏がショッピングカンパニーを見るようになってから言い続けてきた、あるフレーズの中にあった。

「正しいのは唯一数字」9カ月かけて行った意識改革

現職に着任した当時に感じていた「違和感」について話す小澤氏

「会議のたびに、何度も言ってきたんです。『新しい機能開発には興味がない』と。

興味があるのは、その機能で(現時点のKPIである)流通総額が上がるのかということ。作った機能がどれだけ流通総額の向上に貢献するのか、数字と一緒に出してもらわないと評価ができないと、9カ月くらいずっと言い続けていました」(小澤氏)

「開発陣としては、痛いところを突かれたという感じでした」と平田氏は振り返る。それまで、カンパニー内でのエンジニアの評価は、どれだけ機能を追加するか、いくつ機能改善したかという「手数」で決まっていたからだ。

それが、小澤氏による再三のリクエストによって、チーム全体の動き方が変わった。