サービス・プロダクト概要
PBポイントプログラムと他社ポイントプログラムの統合したバーコードを表示し、
双方のポイントが利用できるよう、POSシステムと連携したバックエンドの開発を行いました。
主な機能
・PBポイント用のバーコードと他社ポイントプログラムのポイントを統合したバーコードの表示
– バーコードは店舗のPOSシステムでスキャンされる用のものを表示
・POSシステムでバーコードをスキャンすることで、双方のポイントを使用し購買することが可能
・実際のカードは不要でLINEアプリに表示
・ポイント残高が表示
– 詳細はウェブサイトのポイント履歴で確認できるようにする
・実際のポイントカードの作成なしで、ポイント会員の電子登録
・1タップでLINE公式アカウントにアクセス可能
開発体制
| 役割 | アサイン割合(平均) |
|---|---|
| プロジェクトマネージャー(PM) | 0.5人月 |
| ビジネスアナリスト(BA) | 0.5人月 |
| 日本語コミュニケーター(Comter) | 0.5人月 |
| テクニカルリーダー(TL) | 0.5人月 |
| フロントエンドエンジニア(FE) | 2.0人月 |
| Javaエンジニア | 2.0人月 |
| テスター(QC) | 1.5人月 |
初期開発工数
・9ヶ月
・合計人月：67.5人月
開発チームに聞きました！
「このプロジェクトはここに苦労しました」
・Liffアプリは、メソッド POST で外部サイトを開くことをサポートしていないため、「security_code」と「card_number」を第三者に渡すことができませんでした。バックエンドは公式デジタル処理(UUID)で使用する仮トークンを生成し、DB APIに保存し情報処理公式デジタル獲得しました。そして、リクエストで対応するポイントナンバーとセキュリティコード対応を仮トークンに返し、 仮トークンを無効にするという作業を行いました。
・一部の機能はローカルでテストできなかったため、開発およびテストするように実環境にデプロイしなければなりませんでした。 その際、完全な解決策はありませんが、デプロイ用のスタックを分割して、他の機能にほとんどまたは全く影響を与えないようにしました。
・Githubアクションは、リポジトリごとに 100 環境を制限するため kmsとssmを使用して環境を暗号化し保存する必要がありました。
・Lambdaの全ての環境変数の合計サイズは 4 KB を超えないようにする必要がありました。そこで環境変数が大きく、あまり頻繁に呼び出されない場合は、Lambdaのenvに保存しないで代わりに、Lambdaが実行されるたびにssmを呼び出して値を取得するように工夫しました。
・dynamoDBとcdkに関して、テーブルの構造を更新したい際にテーブルの削除を強制される場合があり、cdkによるデプロイは失敗する可能性がありました。そのため、これらのテーブルを使用している関連スタックを削除した上でベーススタック上のテーブルをcdk で削除しました。また、ベーススタックを再デプロイしawsコンソールでマニュアルでテーブルを削除 ました。そして、cdkでベーススタック上に更新されたテーブルを再作成し、ベーススタックを再デプロイ 、さらに関連するスタックを再デプロイしました。
・別のサービスデータベースと連携する機能を開発する場合、アクセスと実装のための DEV 環境がないため、後にSTGで実装およびテストするためのダミー データを作成する必要がありました。
