請求管理ロボのエンジニアリングマネージャーの白坂です。最近カジュアル面談などでご質問をいただく機会の多い請求管理ロボの開発の進め方についてすこし突っ込んでご紹介します。
当社で公開している資料「3分でわかるROBOT PAYMENT」のP12をベースに紹介します。
機能を実装してリリースする際には上記資料の右図の通りで1〜8のプロセスを実施しています。
- 要望確認
- プランニング
- 要件定義
- 開発
- テスト
- レビュー
- ドキュメント整備
- リリース
要望確認
担当ロール:プロダクトマネージャー、デザイナー 請求管理ロボではユーザーの声はもちろん、今話題のインボイス制度などの社会的な法制度の変化に合わせたプロダクトのアップデートを行っています。本プロセスでは、主にプロダクトマネージャーがユーザーインタビューや法制度解釈の確認などを通し、本質的な課題が何かを検査します。そして解決するためのユースケースや機能案を記述した要求定義書と呼ばれるドキュメントを作成します。
プランニング
担当ロール:プロダクトマネージャー、開発者 スプリント毎のはじめにプロダクトマネージャー/開発者でオンラインミーティング形式で開発計画を行います。このミーティングでは開発する機能の目的や具体的なユースケースを共有したうえで、方針についてディスカッションし開発内容に対する開発者の理解を深めます。
要件定義
担当ロール:開発者、プロダクトマネージャー 要求定義書をもとに実装方針や、「機能追加により影響を受ける機能」を検討し、要件定義/内部設計書というドキュメントにまとめます。基本的には開発者が主体となって作成しシステムの制約や開発者からの機能提案がある場合には随時プロダクトマネージャーとチャットやオンラインミーティングでディスカッションして方針を固めていきます。 多くの場合、このプロセスでデータベースのモデル設計まで行い、開発担当者が複数人に分かれる規模の開発においてはクラスやモジュール設計なども行います。
開発
担当ロール:開発者 開発者は先述のドキュメントをもとに、実装とユニットテストを記述します。コードレビューはプルリクエストをベースに実施します。レビュアーはプルリクエストを作成すると自動で生成されるチェックリストを参考にセキュリティや性能、可読性などの観点でレビューします。
コーディング規約への準拠については静的解析をしてGitHub上で警告するなどの自動化も進めています。
テスト
担当ロール:開発者 一連の機能の実装が完了すると、テスト仕様書を作成しユーザーテストを手動で実施します。要件を満たしていること、リグレッションが発生していないことなどを中心に検査します。
レビュー
担当ロール:開発者、プロダクトマネージャー、カスタマーサクセス、サポートデスクなど 週に一度、請求管理ロボのステークホルダーが集まりオンラインミーティング形式で、リリースする機能のデモ発表会を行います。
ドキュメント整備
担当ロール:開発者 「ドキュメント整備が開発フローに含まれているのは珍しいですね」とコメントをいただくことも多いプロセスですが、API仕様書のような対外的に公開している仕様書はもちろん、DB定義書などの内部向け資料についてもメンテナンス対象のドキュメントリストをもとにチェックをしてアップデートしています。
リリース
担当ロール:開発者 週に一度定期的にリリースを実施しています。基本的にはデプロイパイプラインを使ってリリースしています。
最後に
今回は少しばかり深ぼって請求管理ロボの開発の流れについてご紹介いたしましたが、まだまだ紹介できていないことや検討中の改善策もございます。少しでも興味を持たれた方がおりましたら、カジュアル面談のご応募をお待ちしております!
We are hiring!!
ROBOT PAYMENTでは一緒に働く仲間を募集しています!!!
speakerdeck.com
www.robotpayment.co.jp