はじめに
DMMのプラットフォーム開発本部/第2開発部/プロジェクト推進グループのManagerをしております、星野と申します。
私のDMM歴はまだ浅く、この12月でようやく１年半ほどになります。
また、私が join した2024年時点では、決済領域にはまだ PjM ポジションが少なく、プロジェクト推進グループ自体も発足から半年ほどになります。
今日は、そんな経験の浅い私が、タイトルにあるミッションを拝命したときの話をしたいと思います。
背景
DMMの決済領域は、DMM全体のビジネスを支える重要な共通機能です。
そのため、ビジネスサイドからは常に多くの期待と多様なリクエストが寄せられています。
これらの期待にさらに高いレベルで、迅速に応えていくため、私たちは今、開発コストや期間の効率化という大きな成長の機会に直面しています。
1件あたりの開発効率を高めることは、より多くのビジネスニーズを実現し、DMM全体のサービス価値を最大化するための最重要テーマであると捉え、取り組んでいます。
期間を短縮するためにやったこと
というわけで、まず、そもそも開発期間を半分にするようなことが現実的に可能なのかを探るために、ざっくりとしたスケジュールを引いてみました。
基本的にプロジェクトはウォーターフォールで進行していくため、各工程にかけられる期間と、そもそもの要否を検討しました。
その結果、以下のようなことがわかりました。
- 大前提として、要件の最小化は必須（王道）
- 決済領域単独で開発進行できれば省略できる工程がありそう
- 過去実績を鑑みると、各工程の効率化は必須
- 大きな手戻りが発生したら終わる
なるほど、少なくとも、まったく実現できない話ではなさそうだ。
この霊感を信じて、それぞれの課題について検討を進めました。
１．大前提として、要件の最小化は必須（王道）
これはプロジェクトマネジメントにおける王道中の王道です。
スピードを重視するならばスコープは最小にさせて欲しいと、各方面と期待値調整をしました。
具体的には、既存の決済手段と同一の仕様とすることで、新規の考慮点が発生しないようにしました。
２．決済領域単独で開発進行できれば省略できる工程がありそう
これもスコープ調整に近い話です。
決済機能は各サービスから呼び出される機能であるため、これまでの慣習的に、サービス側の対応と一緒にリリースされることが通例でした。
しかし、プラットフォームとして考えれば、こちら側の機能が先にリリースされて、その後にサービス側が都合の良い時に対応する進め方でもおかしくはないはずです。
これによって、決済機能としてのシンプルな要件のみに抑えられる、サービス側との結合テストを省略できるメリットがありました。
３．過去実績を鑑みると、各工程の効率化は必須
いくつかのプロジェクトを経験した中で、個人的に効率化できそうな領域が２つありました。
ずばり、設計工程と、結合テスト工程です。
設計のスリム化
過去実績として、設計工程に工数がかかり過ぎている課題感がありました。
これはステークホルダー全員が感じている課題感でしたが、決済がミッションクリティカルな領域であることを考えた時に、どうしても品質を優先させる必要があり、そのための方策として、設計レビューで品質を担保する方針であったため、中々解消できないジレンマがありました。
そこで、設計品質は落とさずに、記載ボリュームを削ることで、全体としては効率化する方向で、可能性を探りました。
例えば、執筆者ごとにばらつきのあったデータモデル設計のフォーマット化や、細かいところだとシーケンス図に記載するエラー処理を物理→論理名に変えるなど、細かな改善も積み重ねました。
また、これはもともと認識されていた課題でもあったため、以前から設計ガイドラインの整備は進めており、着手前にエンジニアと十分な認識合わせをすることで、設計のスリム化を目指しました。
結合テストの最適化
こちらは設計程インパクトのある話ではありませんが、結合テストで単体レベルのテストケースを実施しているケースがあるように感じていました。
そこで、全体テスト計画を策定し、それぞれのテスト工程で確認したいテスト観点を明らかにすることで、結合テストとして最小限のテストケースしか作成されないように、担当エンジニアと認識合わせを進めました。
ここでも、あらかじめ全体テスト計画のひな型を整理していたことが活きました。
４．大きな手戻りが発生したら終わる
ここまで色々な期間短縮のための方策を検討してきましたが、大きな手戻りが発生すると、計画に致命的な影響が出てしまいます。
各工程での管理も重要ですが、要件レベルでの漏れが一番怖いので、要件定義を効率的に進めつつも品質は担保しないといけません。
また、プロダクト間IFの認識違いはよくある落とし穴であり、ダメージも大きいため、それぞれについて対策を考えました。
既存決済手段のユースケースを用いたGap分析
要求通りのユースケースに沿って漫然と要件定義するのではなく、既存の決済手段追加時のユースケース及び対応内容と比較することで、抜け漏れの防止や、検討作業の効率化を画策。
エラーコードレベルでIFを網羅的に整理
最終的な通信先となる決済代行からのエラーコードをベースに、すべてのエラーパターンを網羅的に整理することで、プロダクト間のIF認識齟齬の発生を防止。
結末
結果として、新規決済手段追加プロジェクトの工数及び期間を、直近のものと比較して、半分以下にすることに成功しました。
| 決済手段 | 工数 | 工期（設計～リリース） |
|---|---|---|
| 直近 | 45人月*1 | ４ヶ月 |
| 新規決済手段 | 12人月 | 1.6ヶ月 |
また、設計後の詳細見積工数に対して、実績工数との誤差が１%未満というお土産もついてきました（上手くいきすぎて怖い）。
雑感
個人的に色々と対策は講じたのですが、プロジェクト成功の主要因を考えてみると、過去資産を最大限利用できたことと、大きな手戻りが発生しなかったことの２点が大きかったのかなと思います。
さらに言えば、プロジェクト体制も良かったですし、正直私が何もしなくても上手くいった可能性もあります。
この辺がプロジェクトマネジメントの難しいところでもあり、面白いところでもあるのかなと思ったりします。
さいごに
ここまで筆者目線で色々と書いてきたのですが、エンジニアの皆さんをはじめ、ビジネスサイドとの調整を担っていただいたアルファ室*2の皆さんや、裁量を持って任せてくれた上司など、多数の方々のご協力が無ければ今回の成果は生み出せませんでした。
この場を借りて感謝申し上げます。
あと…我々決済領域では、多数のリクエストに応えるために、常に新しい仲間を求めております！
PjM文脈で言えば、ちょうどいいサイズのプロジェクトを次々に回していくプロマネ修行道場のような恵まれた？環境とも言えます。
ということで、我こそはと言う方が居らっしゃいましたら、下記からのご応募お待ちしております。
