タスクを省略しても、スケジュール短縮につながるとは限らない――「品質を維持しつつ、高速にプロジェクトを進める4つのポイント」：リクルート事例に見るエンジニアとしての価値の高め方（2）（1/2 ページ）

リクルートでの新規プロダクト開発事例からエンジニアとしての価値の高め方を探る本連載。第2回目となる今回は「本開発フェーズ」にフォーカスし、不確実性が高いプロダクト開発において、高い品質を維持しつつ、高速にプロジェクトを進めるポイントを2回に分けて解説する。前編となる今回は「機能開発の目的から考えるアサイン方式」と「進め方の道しるべとなる開発プロセス」について。

　変化の激しい市場の中で新規プロダクトをリリースするために、リクルートテクノロジーズが実際の開発事例を基に「どのような開発プロセスや体制を作り上げていったのか」「どのような技術選定や設計をしていったのか」を紹介する本連載。

　前回「約9カ月でリリース、目標の2倍の成果――“品質”と“納期”を両立させる新規プロダクト開発でチームを崩壊させない方法」はプロダクトのコンセプトやビジネス戦略に合わせたスケジュール策定など「リクナビ HRTech 採用管理」を開発するに当たっての背景と開発を進めるための方針について説明しました。筆者が伝えたかった新規プロダクト開発のポイントは下記の3点です。

プロジェクトの方針を踏まえた「本開発フェーズ」の進め方

　これを踏まえて本稿は「本開発フェーズ」にフォーカスします。どのように高い品質を維持しつつ、高速にプロジェクトを進めていったのかを4つのポイントに分類し、前編と後編に分けて説明します。

　前編となる今回は「機能開発の目的から考えるアサイン方式」と「進め方の道しるべとなる開発プロセス」です。

目的から考える「アサイン方式」

　企業のWebサービス開発を1人で進めることはまれで、ほとんどがチームで進めることになります。そのため開発を始める前に「どのようなチームにするか」「どのような開発の進め方にするか」を決める必要があります。

　チームのメンバー構成と開発の進め方は密接な関係にあります。開発の進め方がイメージできていないと「どのようなメンバー構成にすべきか（どのメンバーをアサインすべきか）」の判断が曖昧になり、メンバーのやりたいこととスキルにミスマッチが生じます。

　ミスマッチが生じると「想定していた作業の割り振りができない」「スキル不足による設計ミス」「コードの品質低下」などの問題が発生し、想定していた開発スピードでプロジェクトを進めることが難しくなります。メンバーの視点でいえば「自分のやりたい開発スタイルとプロジェクトの方針が一致しない」とモチベーションが低下する恐れがあります。

　こういった状況を回避し、チームとして良いコンディションでプロジェクトを進めるためには「アサイン方式」を明確にし、メンバーにも納得してもらうことが重要です。今回のプロジェクトは「機能開発の目的」を意識したアサイン方式にしました。では、実際にどのようにアサイン方式を決めていったのか説明します。

プロダクトのフェーズによって効果的なアサイン方式は異なる

　アサインの方法は大きく分けて2パターンがあると考えています。

アサイン方式によって変わる担当範囲

　これらの2つのアサイン方式はどちらかが優れているというわけではなく、場合によってうまく使い分ける必要があります。プロジェクトによって状況は異なりますが、「機能開発の目的」を基に判断するのが良いと考えています。ここからは「どのような開発をする場合に、どちらのアサイン方式が有効なのか」「今回のプロジェクトで『機能によるアサイン』を選択した理由」について説明していきます。

仮説検証型のプロダクト開発には“機能によるアサイン”

　“機能によるアサイン”は、検証期や導入期といったプロダクト開発の初期フェーズにおいて有効だと考えています。初期フェーズはビジネス的な不確実性が高く、素早く価値検証してプロダクトを成長させる必要があるからです。例えばビジネス的な要因である機能の仕様に変更が発生した状況を考えてみましょう。

　“機能によるアサイン”の場合、複数の画面にまたがる機能修正が発生しない限り、ほとんどの変更が1人のメンバーの中で完結します。ところが「役割によるアサイン」を採用していた場合、フロントエンドに1人、バックエンドに1人など最低でも2人以上のメンバーが変更点について認識合わせをしながら、変更作業をする必要があります。変更が頻繁に発生するとコミュニケーションだけに時間をとられてしまい、結果的にスケジュールの遅延へとつながってしまいます。

プロダクトのフェーズによって効果的なアサイン方式は異なる

　前回も触れましたが、本開発は「価値検証フェーズでのフィードバック取り込みや開発途中の仕様変更を許容して進める」という開発フローを定義していました。これは、ユーザーヒアリングによって頻繁に仕様が変わり、開発中の手戻りが高い確率で発生すると予想していたためです。こうした不確実性が高い状況においても高いアウトプットを維持し続けるために、今回のプロジェクトでは“機能によるアサイン”でチームを構成することに決めました。

開発組織の拡大や安定を目指す場合は“役割によるアサイン”

　“役割によるアサイン”はメンバーがどの領域を担当するのかが明確に定義できるので、プロダクトの成長期、成熟期に効果的だと考えています。なぜなら成長期、成熟期では既に稼働しているサービスが存在しています。稼働しているサービスに対して全体を一気に変えるのは難しいため、特定の領域ごとにスペシャリストを集めて、影響範囲を絞りつつプロダクトを改善させることが多くなります。対応する領域も限定されるため、エンジニアを募集しやすくなり、安定した開発組織を維持できるというメリットもあります。

「実際にその方式でアサインできるか」も重要

　それぞれのアサイン方法のメリットとデメリットを「プロダクトのフェーズ」に注目して説明しました。ですが、フェーズによってアサイン方法を決めることが常に正しいとは限りません。検証期、導入期のフェーズであっても「要件のブレ」が少ない場合は“役割によるアサイン”で問題ありません。成長期や成熟期においても新機能開発や複数の領域をまたぐ改善をする場合は“機能によるアサイン”が合いそうです。

　実際にプロジェクトを進める上で無視できないのが「そのアサイン方法に合ったメンバーをアサインできるかどうか」という問題です。今回のプロジェクトで採用した“機能によるアサイン”は、メンバー一人一人が複数の領域を横断して担当しますので、幅広い分野での高度な技術スキルが必要です。今回のプロジェクトでは理想に近いメンバーでチームを編成できましたが、高度な技術スキルを持ったエンジニアを探すのは非常に難しく、仮に適性のあるメンバーを見つけたとしても会社の状況や他プロジェクトとの兼ね合いでチームに参画できないケースもあります

　このようにアサイン方式はプロダクトの状況やエンジニア市場などさまざまな要因に影響されます。仮に理想のアサイン方式が選択できなかった場合でも、それぞれのアサイン方式のメリットとデメリットをしっかりと押さえ、それに応じてプロジェクトを推進することが重要だと考えています。

それぞれのアサイン方式のメリットとデメリット