ソフトウェア開発者の日常

こだわりなく書きたいことを書いていきます。

依頼元を支える、外注先

依頼元から、システム同士を連携させたいので、打ち合わせの時間を確保して欲しいと連絡がありました。
どんな会社のシステムと連携をさせたいのかと思いながら、打ち合わせの準備をしました。

準備として、システムの仕様を確認

こちらのシステムは、イベントへの参加を受け付けています。
有料のイベントで、クレジットカードで決済しています。

システムの処理の流れは、大雑把には、こんな感じです。
参加者の情報を入力

入力情報を確認

入力情報をデータベースに仮登録

クレジットカード決済

データベースの情報を確定

受付完了のメールを送信

このシステムで、他のシステムとの連携は、

  1. 他のシステムが、こちらのシステムから、情報を取得する機能を用意する。
  2. こちらのシステムが、他のシステムに、情報を登録する機能を用意する。

のどちらかが考えられます。

1.の機能であれば、これまでにも用意したことがあります。
2.はありません。

新たに2.を作成する場合、他のシステムへの登録でエラーが発生した場合、どのように処理をすればいいのかが悩みます。
登録でエラーが発生したら、リトライすればいいのか?
登録をリトライするなら、どのタイミングで行えばいいのか?
登録のリトライでもエラーが発生したら、どうればいいのか?
このように悩みます。

イベントの関連のページで、認証に必要なID/パスワードを、こちらのシステムの受付完了のメールに、記載していないことも確認しました。

オンライン会議
Photo by Christina @ wocintechchat.com on Unsplash

これまでにも連携したことがある会社のシステムと連携

打ち合わせはオンラインで行われました。
時間になって、オンラインで参加者を確認すると、これまでに連携をしたことがある会社の方が参加されていました。

過去に連携したことがあり、今回の連携方法は、過去と同じ方法となったので、1.の機能の用意とあっさり決まりました。

イベントの関連のページで、認証が必要なはずだけれど、認証に必要なID/パスワードはどこから配信するのか?と僕から確認をしました。
連携する他のシステムが、こちらのシステムから情報を取得後、配信すると決まりました。

依頼元はわかっていたかな?

ここまで、連携するシステムの会社の方とほとんど話をして決まりました。
依頼元は、どこまで考えていたのかわかりません。
認証に必要なID/パスワードの配信について、考えていたのかな?と思いました。


外注先が主導して、仕様が決まっていくので、依頼元としては楽だと思います。
楽な分、ノウハウが残らない気がします。
特定の外注先に依存するようになるので、ノウハウが残るようにして欲しいです。