ID:62591さん

バックエンドAPI開発において、ベンダーとの要件定義から実装までの一連のプロセスをマネージメントしました。特にポイントカード管理システムのリニューアルでは、非IT職のベンダー担当者との技術的なコミュニケーションの橋渡し役として、プロジェクトの技術的方向性と進捗を管理していました。

ベンダー側の業務要求を正確に理解し、技術的に実現可能な形に落とし込んだ上で、高品質なAPIシステムを構築する責務がありました。具体的には、会員検索、カード発行、ポイント交換といった主要機能を、既存の業務フローを損なうことなく、かつ将来的な拡張性を持たせた形で実装する必要がありました。 また、非IT職のステークホルダーでも理解できる形で仕様を文書化し、認識の齟齬なくプロジェクトを進行させることも重要な責務でした。最終的には、エンドユーザーに快適に利用できる、安定性の高いシステムを提供することが求められていました。

まず、ベンダー担当者の多くがIT専門職ではないという課題に直面しました。技術的な説明をそのまま伝えても理解を得られず、要件の認識齟齬が頻発するリスクがありました。そこで、コミュニケーション戦略を根本から見直しました。技術用語を極力排除し、業務視点での説明を徹底しました。例えば「API連携」という言葉を使う代わりに「システム間でデータをやり取りする仕組み」と説明し、実際の業務フローに即した具体例を交えて説明しました。 また、画面イメージやフロー図を多用した視覚的な資料を作成し、抽象的な概念を具体的なイメージとして共有できるよう工夫しました。ポイントカード機能の実装では、まず現場の業務フローを詳細にヒアリングし、システム化によって業務がどう変わるかを明確に示しました。特に、既存業務との互換性を保ちながら、新機能を段階的に導入する移行計画を策定し、現場の混乱を最小限に抑えました。要件定義の段階では、曖昧な要求に対して積極的に質問を投げかけ、具体的なユースケースに落とし込むことを心がけました。 例えば「検索を速くしたい」という要求に対しては、「何秒以内なら許容できるか」「1日に何回程度検索するか」といった定量的な指標を引き出し、技術的な実装方針を決定しました。プロジェクト進行中は、定期的なデモンストレーションを実施し、開発中の機能を実際に動かして見せることで、ステークホルダーの理解と納得を得ながら進めました。これにより、完成後の手戻りを大幅に削減することができました。

複数の広告代理店・メディア企業との技術連携と要件調整をマネージメントしました。各社の既存システムとの互換性確保と、マーケティング担当者への技術仕様の説明・合意形成プロセスを主導していました。

法規制に完全準拠しながら、各クライアント企業の既存システムにスムーズに統合できるクッキー管理システムを構築する責務がありました。具体的には、Webサイト訪問者の同意を適切に取得・管理し、同意状態に応じたクッキー制御を実現する必要がありました。 また、技術的な知識が限定的なマーケティング担当者でも、システムの仕組みと導入後の運用イメージを明確に理解できる状態にすることも重要でした。最終的には、法的リスクを回避しつつ、ユーザー体験を損なわない形で、広告配信の最適化を可能にするシステムの提供が求められていました。

プロジェクトの最大の課題は、法規制の複雑性と、クライアント企業ごとに異なる既存システムへの対応でした。まず、GDPR/個人情報保護法の要件を詳細に分析し、技術的な実装要件に落とし込みました。 各クライアントの既存システム調査では、それぞれの技術スタック、データフロー、セキュリティ要件を詳細に把握し、共通化できる部分と個別対応が必要な部分を明確に分離しました。これにより、コアとなるAPIは汎用的に設計しつつ、各社固有の要件にはアダプター層で対応する柔軟な設計を実現しました。 マーケティング担当者とのコミュニケーションでは、同意フローの図解を中心とした説明資料を作成しました。実際のユーザージャーニーに沿って、どの時点でどのような同意画面が表示され、その結果がどのようにシステムに記録されるかを、画面遷移サンプルを用いて視覚的に説明しました。 特に工夫したのは、法的要件と技術的制約、ビジネス要求のバランスを取ることでした。例えば、厳格な同意取得プロセスはコンバージョン率を下げる可能性があるため、法的要件を満たしながらもユーザー体験を最大限考慮した同意UIを設計しました。複数パターンのモックアップを作成し、A/Bテストの結果を基に最適な実装を選択しました。 また、Laravel側でのAPI実装と並行して、クライアントの要望に応じてNext.jsのフロントエンド改修も担当しました。バックエンドとフロントエンドの両方を理解していることで、システム全体の最適化を図り、パフォーマンスとユーザビリティの両立を実現しました。 導入フェーズでは、段階的なロールアウト計画を策定し、小規模なテストサイトから始めて徐々に本番環境に展開する方式を採用しました。各段階で発生した問題を迅速に解決し、次の段階に反映することで、大規模障害のリスクを最小化しました。

運用フローの分析から、システム設計、LINEミニアプリ連携の技術実装までの全体プロセスをマネージメントしました。保育士、バス乗務員、保護者という異なる立場のユーザーニーズの調整も担当していました。

社会問題となっている園児のバス置き去り事故を確実に防止できる安全管理システムを構築する責務がありました。具体的には、バス乗務員の作業負担を最小限に抑えながら、確実な乗降確認ができるシステムを実現する必要がありました。 また、保護者への即時通知により安心感を提供し、万が一の降車漏れを絶対に防ぐフェイルセーフ機能を実装することが求められていました。システムは現場の保育士や乗務員が技術的な知識なしに直感的に操作でき、日々の運用に無理なく組み込める状態にする必要がありました。

プロジェクト開始時、最初に行ったのは保育現場への詳細なヒアリングでした。実際にバスに同乗し、乗降時の作業フローを観察することで、システム化における課題を洗い出しました。 最大の課題は、忙しい乗務員がミスなく確実にチェック作業を行える仕組みの構築でした。当初、複雑な確認フローを検討していましたが、現場観察により、シンプルさこそが最重要であることを認識しました。そこで、タブレット上でワンタップで乗降チェックができるUIを設計し、視覚的にも分かりやすい大きなボタンと色分けによる状態表示を実装しました。 降車漏れ防止機能の設計では、ヒューマンエラーを前提とした多重の安全機構を組み込みました。全員の降車確認が完了するまで、画面上に目立つアラートを表示し続け、さらに音声でも注意喚起する仕組みを実装しました。また、万が一確認を忘れた場合でも、一定時間経過後に管理者へ自動通知が送信される仕組みも追加しました。 LINEミニアプリとの連携では、技術的な制約が多く存在しました。特に、リアルタイム性の確保と通知の確実性のバランスが課題でした。LINE APIの仕様を詳細に調査し、プッシュ通知とメッセージ送信を組み合わせることで、高い到達率を実現しました。また、通信エラー時のリトライ処理や、通知履歴の保存機能により、システムの信頼性を向上させました。 保護者向けの機能では、技術に不慣れな方でも使えるよう、登録フローを極限までシンプル化しました。QRコードによる簡単登録と、分かりやすい手順説明により、サポート問い合わせを大幅に削減することができました。 開発過程では、実際の保育園での実証実験を複数回実施し、現場からのフィードバックを迅速に反映しました。特に、雨天時や園児が多い日など、様々な状況でのテストを行い、あらゆる場面で確実に動作するシステムを構築しました。 最終的に、このシステムにより乗降確認の作業時間を従来の半分以下に短縮しながら、確認漏れゼロを達成することができました。