新サービス開発と基幹システム刷新の根本的な違い
新サービス開発と基幹システム刷新のプロジェクトで強く意識すべきなのは、以下の違いです。
新サービス開発は、要件定義時に決めた要件が利用者（エンドユーザー）に使われるかどうかわからない不確実なモノを作るプロジェクトです。
一方、基幹システム刷新は、要件定義時に決めた要件が利用者に確実に使われる、使われないといけないモノを作るプロジェクトです。
この違いにより、マネジメントでまず意識するべきQCD（品質・コスト・納期）の優先度も大きく異なります。
基幹システムは「使われないといけないモノ」なので、要件の網羅性や妥当性、それを実現したプログラムの妥当性など、システムそのものの品質が非常に重要です。
つまり、D（納期）に比べてQ（品質）が重要になることが多いのです。
一方、新サービスは、網羅的に作れば必ず利用者にウケるというわけではありません。
若干のミスもUI・UX上問題ない範囲であれば許容されることがあります。
品質にこだわるより早くリリースをしたほうが早く改善ができるからです。
つまり、Q（品質）に比べてD（納期）が重要になることが多いのです。
基幹システム経験者が陥りがちな2つのパターン
このような違いがある中、基幹システム従事者が陥りがちなパターンが2つあります。
第一に、基幹システム開発と同様にプロジェクトをしっかり、丁寧に進めようとするパターンです。
かっちりしたウォーターフォール開発で進めることにより計画全体が長くなってしまうことに加え、工程判定などの過度な報告、分析・評価を行うことで、サービスの初期開発時点で想定以上のコストをかけてしまい、その後の変更予算が限られてしまったりする事態に陥ります。
第二に、「新サービスは納期が優先だからアジャイル開発が望ましいだろう」と安易に決めてしまうパターンです。
その結果、なかなか要件が確定しない、関係システムとの調整が難航してリリースに時間がかかってしまうといった問題が発生します。
前者は、基幹システムのやり方をそのまま踏襲することが背景となって陥る問題です。
後者は、新サービス開発といえども一定規模の開発の場合ステークホルダーや関係システムが多くなり、ウォーターフォール開発のようにマイルストーンを決めながら進めないと前に進まない部分もあるにもかかわらず、その点が十分に理解できていないことで起きる問題です。
「サービスは作りながら要件や仕様をブラッシュアップすることが望ましい」という幻想を元に突き進んでしまうのです。
新サービス開発を成功に導くアプローチ
では、どのようなアプローチを取るべきでしょうか。
サービス開発で求められるアプローチは多岐にわたりますが、ここでは事例も交えながら要件定義工程と開発工程で意識するべきことをいくつかご紹介します。
まず、要件定義工程では、プロダクトオーナーを1名明確に決めることが大事です。
プロダクトに求める要件を最終決定する人を明確にしたうえで、そのオーナーのもと、プロダクトに求める要件をまずは幅広く関係者から集めます。
それを顧客価値、ビジネス価値、開発コスト、リスクといった観点でメリット・デメリットをPMOにて整理し、プロダクトオーナーがジャッジするという進め方が有効です。
基幹システム開発では、要件や仕様を定義するのは現場の各担当者が行います。そのシステムの責任者もいますが、各部署でスコープでもめた時、コストを超過しそうなときなどに、判断をするというような役回りですので、自分で要件や仕様を決定していくプロダクトマネージャーとは役割が異なります。
サービス開発は利用されるか不確実なものを作るからこそ、そのタイミングでの正解（ありたき姿）を決めるプロダクトオーナーを明確に据えることが非常に大事なのです。
1つ事例をご紹介します。
私が経験した某量販店アプリ開発プロジェクトでは、ECサイトでの販売を活性化したいEC事業部と、リアル店舗での販売を活性化したい営業部とで大きな対立がありました。
どちらを優先するのも正解はありませんし、両立させるとサービスとしてぼやけてしまいます。
しかし、この時は、経営判断ができるプロダクトオーナーがいましたので、それによってプロジェクトは前に進んでいきました。
当時はECサイトでの販売活性化の方向で全てのジャッジを行い、サービスをローンチしましたが、数年たった今、そのアプリはリアル店舗でも使えるようなサービスが散りばめられたものになっています。
もし、最初からこの姿を目指していればこのアプリの開発には非常に時間がかかったと思います。
ある程度スコープを絞り、リリース後にサービスをブラッシュアップする、そのような進め方をプロジェクト全体で合意していくことが非常に大切です。
開発工程では、基幹システム開発に比べ、工程や領域横断でタスクを組むことが重要です。
基幹システム開発は工程ごとに区切って、工程終了タイミングで進捗や品質を点検し、次の工程に進めるかどうか判定するのが当たり前です。
例えば、基本設計完了で点検、詳細設計完了で判定という具合です。
しかし、この進め方は時間を要します。工程判定だけでも資料の準備や対応だけで2週間程度がとられてしまうことがよくあります。
最近のスマホアプリやECサイトは物流や会計システムとの連携が必要なことも多いので、マイルストーンや合流地点を考えることは大事ではありますが、工程判定をしっかりやっていると、どうしても求められるスピード感にはなりません。
そこでどうするか。
私がPMを担当した某ECサイト開発プロジェクトでは、要件定義工程で画面のワイヤーフレームと、画面に存在するパーツの定義と押下時などの挙動といった要件・仕様を決めた後、デザイン作成と各種設計（外部設計や画面処理設計、API設計など）を並走させます。
そして、デザインが出来上がったものからマークアップ作成に着手し、画面処理設計ができたものからJavaScriptの実装へ。
単体テストに向けて初めてデザイン、マークアップ、JavaScriptを合流させてテストを実施する。
そして、内部結合テストに向けて、画面単位に利用されるAPIを整理し、その順番で開発し、効率的に合流させる。
この画面単位で各工程のタスクが進んでいくというやり方でWBSを作成し、最短でのリリースを実現させました。
もちろん、このような五月雨開発は、変更が起きたときの取り込み影響の増加、品質低下のリスク、管理工数の増加といった問題は起きます。
しかし、最初から変更要求の取り込み予算や対応期間を準備しておくなど、事前の対策を講じることでリスクは軽減できます。
実践する際の注意点
このアプローチを実践する際には、いくつかの注意点があります。
まず、ディテールから積み上げると計画を立てるのが非常に難しくなります。
画面単位でタスクを組み立てる必要はありますが、画面単位でボトムアップ的に計画を立てていたら規模が大きい場合は破綻します。
まずは大きな期間の中（例えば要件定義、基本設計～結合テスト、システムテスト以降の3つのフェーズのスケジュールは決めたうえ）で、各工程の領域単位（例えばフロント開発とAPI開発、バッチ開発）に見積もり工数と体制ベースを考慮して、どの程度かぶりがあっていいのかを整理し、そのあと細かくタスクを組んでいくアプローチが重要です。
次の注意点は、このアプローチは画面単位で進められる工程までという点です。
具体的には、私のプロジェクトの場合、基本設計の後半から内部結合テストまではこのような画面単位の五月雨開発をすることが多いですが、システムテストでは原則として全画面、全API・バッチが揃った状態でテストを進めています。
各プロジェクトの特性で、合流タイミングは異なるとは思いますが、必ずベンダーサイドの最終品質担保に向けた一定期間は全ての資材を合流させ品質確認することが重要です。
これ以外に、サービス開発では非機能に関する考え方も重要です。
サービスが利用されるか不確実であるということは、当然サービスそのものを変更することも多いですし、嬉しいことにサービス自体が想定以上にバズることもあり得ます。
あまりにもプログラムを共通化したサービスを作りすぎると修正自体に時間がかかってしまいます。
加えて、スマホアプリの場合は修正してA/BテストしようとしてもAppleやGoogleの審査があったりと、簡単ではありません。
サービスである以上、A/Bテストを通じてブラッシュアップすることは確実のあるので、その可能性がある情報は拡張性を意識し、できる限りバックエンドやFirebaseのRemote Config（ネイティブアプリのアップデート不要で外観や動作を変更できる）で実装しておく、インフラもスパイクに耐えられるようスケールしやすい構成にしておくなどの配慮が必要です。
サービス開発のマネジメントをする際には、PMやPMO自身が開発そのものがどのようなアーキテクチャ、思想で作っていくか、それによるメリデメ、リスクを理解しておくことがとても大事になります。
違いを理解し、適切なマネジメント方法を考える
新サービス開発と基幹システム刷新では、「リリース後の利活用の確実性」に根本的な違いがあります。
この違いを理解せずに、基幹システムの進め方をそのまま踏襲したり、逆に「新サービスだからアジャイル」と安易に判断したりすると、プロジェクトは思うように進みません。
プロダクトオーナーを明確に据え、要件の優先順位を経営判断できる体制を作ること。
そして、プロジェクト内の大まかなスケジュールの中で、画面単位など細かい粒度でタスク設計をし、最短でのリリースを目指すこと。
これらのアプローチが、新サービス開発を成功に導く鍵となります。
そして、細かい粒度での作業はどのタイミングまでか、を見極めること、非機能面の考慮も忘れてはいけません。
サービス開発で求められるマネジメントは内容や求められる速度、体制などによってまちまちなところがありますが、基幹システムとの違いを理解し、納期と品質のバランスを常に意識しながら、プロジェクトの特性に合ったマネジメントにするという姿勢こそが、新サービス開発の成功につながると思います。
