はじめに
BASE BANK Dept で Engineering Program Manager をしている大津です。
今回は、4月にリリースした最速振込とそれまでの歴史について簡単に触れつつ、どのようにプロジェクトのリードをしたのか書きます！
振込申請の種類と歴史
最速振込は、BASEが提供する振込申請の一つの種類です。
振込申請とは、ショップオーナーさんがBASEでの売上金額を自身の銀行口座へ振り込むため申請する機能です。
BASEの振込申請には、様々な種類があります。表にまとめると下記のようになります。
| 種類 | 振込日目安 | 手数料 |
|---|---|---|
| 通常振込 | 10営業日後 | 振込手数料＋事務手数料のみ |
| お急ぎ振込 | 翌営業日または翌々営業日 | 振込手数料＋事務手数料＋振込申請金額の1.5% |
| 定期振込 | 当月末までの売上金全額を翌月25日に自動で振り込む | 振込手数料＋事務手数料のみ |
| 最速振込 | 最短10分（土日祝日含む） | 振込手数料＋事務手数料＋振込申請金額の3.0% |
1. 通常振込
BASEの基本的な振込方式として、当初から提供されている振込方法です。一般的な決済サービスでは月末締め翌月入金が多い中、10営業日での入金サイクルを実現し、早期入金を可能にしました。
手数料は、振込手数料＋事務手数料のみになります。
2. お急ぎ振込の導入（2020年2月）
個人やスモールチームが多いBASEショップのニーズに応えるため、より迅速な入金サイクルを実現する「お急ぎ振込」が導入されました。翌営業日または翌々営業日での入金を可能にし、キャッシュフロー改善に貢献しています。
手数料は、振込手数料＋事務手数料＋振込申請金額の1.5%になります。
3. 定期振込の導入（2022年7月）
申請の手間を軽減するため、当月末までの売上金全額を翌月25日に自動で銀行口座へと振り込まれる「定期振込」が導入されました。
手数料は通常振込と同じで、定期振込の設定はいつでも解除することができます。
4. 最速振込の導入（2025年4月）
さらなる入金スピードを求めるショップのニーズに応えるため、お急ぎ振込よりもさらに早く早期入金を実現する「最速振込」が導入されました。主な特徴は下記のとおりです。
- 最短10分での入金が可能
- 土日祝日を含む365日対応
- モアタイムシステム対応の金融機関であれば、当日中の振込が可能
手数料は、振込手数料＋事務手数料＋振込申請金額の3.0%になります。
どのようにプロジェクトのリードをしていったか
まず前提として、私はEngineering Program Manager（以下EPM）というプロダクトのデリバリーとクオリティに責任を持つロールについています。
最速振込のプロジェクトでは、主に下記のようなリードをしていました。
- 最速振込の設計（アーキテクチャやDB・API利用などの基本設計、バッチの詳細設計、運用設計など）、実装、QAや本番テストの方針策定と実施
- プロダクトマネージャーと連携して契約推進および関連ステークホルダーとの調整MTGの実施
- スプリントやレトロスペクティブなどのチームイベントの運営
- API調査からリリースまでの全体スケジュールのハンドリング
- リリース後の安定運用を目指した改修と保守
私個人としては中規模プロジェクトのリードは初めてでしたが、マネージャーと相談しながらいくつかの工夫を重ねてプロジェクトのリードをしていきました。
ロードマップをベースに、目標を示し続けてスケジュールをすり合わせする
プロジェクトのリードをする人は、聞かれたらいつでも答えられなければならないことがたくさんあります。
- 現在のプロジェクトが順調に進んでいるかどうか
- どのマイルストーンやリリースターゲットを目指しているのか
- どのタスクの優先順位が最も高いか、タスクの漏れはないか
- 想定されるリスクは何か
- スケジュールが遅延している場合に、どのような具体的なリカバリー方法があるか
これらの質問に答えられるよう、FigJamでロードマップを作成し、進捗管理を行っていました。
ロードマップに記載する内容は、次のようなものです。
- タスクの内容
- 担当者
- 見積もり（工数感）
- 作業ステータス
- タスクの依存関係（クリティカルパスがどこか）
- タスク開始と終了目安
などです。
このロードマップはプロジェクトハンドリングの基礎になります。
- プロジェクトがどのくらいタスクが終わっている/終わっていないのか、今の状況を把握できる
- 漏れているタスクがないか客観的にわかる
- どのタスクを最優先にすべきか、スケジュールが遅れている場合どうリカバリするか考えやすい
- メンバーとのスケジュールのすり合わせも、このロードマップをベースに行うとスムーズに進む
作成するタイミングとしては、理想は一番最初です。それが難しい場合でも、なるべく早い段階で作成すると良いでしょう。
また、このロードマップは何度でも作成し直しても構いません。重要なのは、現時点でプロジェクトメンバーとスケジュールを通して、（リリース）目標とそのプロセスを示し続けられるか、そしてスケジュールのすり合わせができているかということです。
フェーズごとの終了条件を明確にする
今回の最速振込は、銀行と連携する外部連携を必須とする開発でした。しかし、どのような外部連携であっても「API調査」「設計」「実装」「QA」「リリース」といったフェーズが必要など、基本的な流れは共通しています。
ただ、各フェーズの終了条件を明確にしておかないと、そのフェーズで無限に時間を消費してしまいます。手戻りを減らしながらも開発を進めていくバランスを考え、適切な終了条件を設定する必要があります。
最速振込では、API調査と設計について下記のような終了条件を設定していました。
- API調査：仮説ベースで最速振込にまつわる業務フロー図をたたき台として作成し、それが実現できるかどうかを調査。実現可能性が確認できた段階で、API調査を終えて設計へ移る
- 設計：全体の基本設計ドキュメントをベースに、それぞれのバッチなどの詳細設計が迷わず実装に着手できる（あるいは実装しながら詰めていく）ようになったら、バッチなどの詳細設計へ移り実装を始める
実際に動くものを一番に信じる
なるべく不確実性をなくすには、実際に動くものをベースに考える必要があります。
外部連携は動かしてみないと分からないものが多いので、いかに早く動かせるか？本番リリース前に確かめられるか？を考える必要があります。
外部連携先の開発環境で正常に動作するか
最速振込では、できるだけ早く開発環境を入手できるよう契約関連を最優先タスクに設定しました。
また、開発環境で検証できる事項をあらかじめ整理し、検証できない項目は本番環境でのテストで確認することにしました。
本番環境で期待通りに動作するか
最速振込では、本番環境での実際の銀行振込テストを実施しました。本番環境でないと分からないことを放置したままリリースするのは非常に危険だからです。
このテストは実際に銀行口座へ入金が発生するため、事前に社内での稟議手続きやテスト実施ショップの準備なども丁寧に行いました。
プロジェクトのリードをする人の腕の見せ所
プロジェクトのリードを実際に経験して、特に腕の見せ所だと感じた点をいくつか紹介します。
いかに自分がボトルネックにならないプロセスを考えられるか vs いかに自分がクオリティに責任を持てるか
「自分がすべてを確認しなければ進められない」という姿勢は非現実的であるため、適切に権限委譲していくことが求められます。
ただし、忙しさを理由に単なる丸投げをしてはいけません。移譲のプロセスやissueチケットの書き方などを工夫する必要があります。また、継続的にissueチケットを作成・管理する「筋力」も必要です。
一方で、できるだけ多くのレビューを行う姿勢も大切です。プロジェクトのリードする人は品質に責任を持つ立場であり、レビューを怠ることがPJの進捗を止めることにもつながります。
とはいえ前述の通り、「自分がすべてを確認しなければ進められない」という姿勢は非現実的です。状況によっては、期間限定でレビューを他のメンバーに委ね、タスク消化に集中するという判断が必要な場合もあります。
この権限委譲の適切なバランスを見極めることが重要です。
スケジュールが遅れそうなときのリカバリ案がいくつ出せるか
プロジェクトの開発を進めていると、スケジュールが遅れている状況もありうるでしょう。そうなった時に、すぐに「納期を伸ばす！」ではなく、どうリカバリするか、リカバリ案はいくつあるかを考えることが重要です。
例えば以下のようなリカバリ案があります。あくまで一例であり、プロジェクトの状況によってはさらに多くの選択肢があるでしょう。
- タスクをさらに分解して、並行で作業ができる状態にしたり、クリティカルパスのタスクを進めやすくする
- 先んじて（特にクリティカルパスの中で）依存関係が多いタスクをこなし、タスクが終わるまでプロジェクト全体の進捗が止まる状態を防ぐ
- 依存関係のないタスクを用意しておき、いざというとき人員追加した際のタスクとして活用する
このリカバリ案を出す能力は、実際に経験を積み、その経験を振り返りながら徐々に上達していくことで身につけられるものです。
リカバリが困難な場合、プロジェクトマネジメントの基本である「スコープ/リソース/納期」のどれを調整できるかという検討が必要になります。ただし、これは前述のリカバリ案の検討と実施を一通り行った上での最終手段と考えるべきです。
- リソース
- すぐにチーム外にヘルプを求められるよう、タスクが適切に整理されているか
- プロジェクトの知識を効率的にインプットできる資料は用意されているか（ただしプロジェクト後半になるほど難しくなる）
- スコープ
- リリースに必要な機能や優先順位が明確についているか
- 納期
- デリバリーの遅延が事業計画にどの程度の数字的影響を与えるか
- ステークホルダーはどう受け止めるか
越境するための関係値づくりやコミュニケーション力が問われる
プロジェクトで開発する機能と業務は密接に関わっています。業務は想像以上に多くのステークホルダーが関与しており、これらのステークホルダーを考慮せずに開発を進めると、簡単に手戻りが発生してしまいます。
プロジェクトの最初の段階でステークホルダーを洗い出し、早めに相談を持ちかけることが重要です。
また、コミュニケーションにおいては、場の設計、ファシリテーション、対話、ドキュメント作成など様々なスキルが求められます。これらのスキルも、先述のスケジュールリカバリ案と同様に、実践と振り返りを繰り返すことで徐々に磨かれていくものです。
おわりに
プロジェクトのリードをしてみると、する前とした後で、見えてくる景色には大きな違いがあると感じました。今後も積極的に経験を積んで上達し、プロジェクトのリードを通じて事業貢献できるエンジニアになっていきたいです！
BASE BANK Deptでは、プロジェクトの開発リードをする / したいエンジニアを募集しております。まずはカジュアル面談からお待ちしております！
