物販会社のシステム設計
きっかけ
大手小売企業の自社アプリと自社決済サービスの設計に、上流工程の担当として参画しました。
背景にあったのは、業界内で「◯◯Pay」と呼ばれる自社決済サービスを導入する企業が相次いでいたことです。競合他社が次々と自社決済を立ち上げる中、「うちもやらないと」という危機感から、このプロジェクトは動き出しました。
自社アプリに決済機能を組み込み、ポイント制度と連携させ、顧客との接点を自社でコントロールする ── 構想としてはシンプルですが、大手小売の既存システムと連携させながら安全な決済基盤を設計するとなると、考慮すべきことは山ほどあります。
一緒に考えたこと
プロジェクトに入った当初、私は先方と直接やり取りできる立場ではありませんでした。間に入る企業を通じて要件を受け取り、設計に落とし込むという進め方です。
ただ、設計を進める中で「これは直接話を聞かないと正しい判断ができない」と感じる場面が増えていきました。伝言を経由すると、細かいニュアンスや業務上の制約が抜け落ちる。特にセキュリティに関わる部分は、曖昧なままにしておくわけにはいきません。
設計書を通じて、既存システムとの矛盾点やセキュリティ上のリスクを一つひとつ指摘していきました。「ここはこのままだと危ない」「この仕様だと将来的に拡張できなくなる」── そうしたフィードバックを重ねるうちに、先方から直接やり取りの場をいただけるようになりました。
設計者として信頼を得られたことで、より深い部分まで踏み込んだ設計が可能になりました。
つくったもの
このプロジェクトで担当したのは「設計」です。コードを書いたわけではありません。ただ、設計が開発の成否を左右するプロジェクトでした。
自社アプリの設計 ── ユーザーが実際に触れる画面構成、機能要件の整理、画面遷移の設計を行いました。「使いやすさ」と「業務要件」のバランスを取りながら、開発チームが迷わず実装に入れる精度の設計書を目指しました。
自社決済サービスの設計 ── 決済の仕組みは、一度設計を間違えると取り返しがつきません。既存の基幹システムとの連携方法、セキュリティ要件、将来的な機能拡張を見据えたデータ構造まで、慎重に設計しました。「今動けばいい」ではなく「3年後、5年後も安全に運用できる」基盤を意識しています。
既存システムとの整合性チェック ── 大手企業には長年運用されてきた既存システムがあります。新しい決済基盤を載せるにあたって、既存システムとの矛盾点や整合性の問題を洗い出し、解決策を提示しました。この作業は地味ですが、ここを怠ると開発フェーズで手戻りが発生します。
何が変わったか
設計フェーズの完了後、私は別のプロジェクトに移ることになり、開発フェーズには直接関わっていません。ですが、この設計をもとにサービスは無事にリリースされたと聞いています。
設計だけで離れるのは、正直なところ少し心残りではありました。ただ、開発チームが設計書をもとにスムーズにリリースまで持っていけたということは、設計が役割を果たした証でもあると思っています。
上流工程の仕事は、リリースされたプロダクトに自分の名前が載るわけではありません。でも、プロダクトの品質と安全性の大部分は、開発が始まる前の設計で決まる。そういう仕事です。
ふりかえり
このプロジェクトで改めて感じたのは、「設計者が当事者意識を持てるかどうか」がプロジェクトの質を大きく左右するということです。
言われたことを設計書にまとめるだけなら、誰でもできます。でも、「この仕様は本当にユーザーにとって正しいのか」「ここにセキュリティリスクはないか」「既存システムとの整合性は取れているか」── こうした問いを自分から投げかけられるかどうかで、設計の質はまったく変わります。
株式会社才は、開発だけでなく「設計だけ」のご依頼も歓迎しています。開発チームはいるけれど設計を任せられる人がいない。外部に開発を依頼する前に、要件と設計を固めておきたい。── そんなご相談があれば、ぜひお声がけください。