9
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

ZOZOテクノロジーズ #2Advent Calendar 2020

Day 5

【BtoBシステムあるある】特別対応する場合のモデルについて考察する

Last updated at Posted at 2020-12-04

この記事は ZOZOテクノロジーズ #2 Advent Calendar 2020 5日目の記事になります。

昨日はkotatsu360さんのAWS SSOのユーザx権限一覧をつくるでした。(棚卸し大事!)

はじめに

BtoBのシステムを運用していくと、よくあるケースとして、「このお客様はこの箇所を現状のとおりでなく、特別な運用としたい」ということがよくあると思います。

接続する基幹システムの都合であったり、会社のルールの都合であったりサービスを使っていただくために避けられない壁を超えるために対応することが多々あるかと思います。

例えば、
・ システムは電話番号がハイフンありだが、お客様側の基幹システムでは数字のみのバリデーションが走っておりハイフンが使えない

・ システムで自動で作成されるIDがあるが、お客様側の基幹システムで別のID付与ルールがあるため基幹システムで使っているIDを使用したい

・ システムではAPIで連携しているが、お客様側で使っている連携システムの方が拡張できないためファイルで連携して欲しい。。。
などなど、よくある話かと思います。

このようなケースでやりがちなパターンと問題点、改善パターンを紹介します。

やりがちなパターン

よくある対応の仕方として、単純にこのお客様の場合処理を分けるということをするかと思います。

class あるクラス
  String ある変数;

  Boolean validFormat(Client client){
    if(client.name == "B社"){
      // B社用のチェック
    }else{
      // 既存のチェック
    }
 }
 

改修も数行で済んで良いですね(???)。

対応後によくあること

さて、このような対応を何箇所かに設定して、無事B社向けにリリースできました。

その後、順調にサービスも成長して導入企業様も増えていきます。そんななかで、別の特別対応が色々と入っていくのが世の常であります。

そんなある日、営業からこんな問い合わせが・・・

「今検討中のF社がB社と同じ基幹システム使ってるけどB社の時どんな対応したっけ?」
とか、
「以前特別に○○対応したと思うんだけどどのお客様で対応したっけ?」

さてこんな時どうします?
多くの対応が既に入ったソースコードの中から if(client.name == "B社") とある箇所を全部検索するか?
または、開発当時のスプレッドシートやスライドの資料を探しまくるか?

いずれもちょっと面倒かつ、正確に割り出せる気がしませんね。

こういうケースは、BtoBなビジネスをしているシステムのあるあるかと思いますので、あらかじめ追いやすいソースコードを書いておきたいものです。

改善策

どういうソースコードなら良かったか?要件は2つです。

  1. 特別に対応した箇所のソースを探しやすいこと。IDEで1回ソースの参照をしたら全部抜き出せたらいいですね。

  2. 特別対応したお客様の一覧が容易に抜き出せること。顧客のマスターから辿れれば良さそうです。

であれば、こんなクラス構成でどうでしょうか?

blog.png

「Client」は「〇〇対応」をしているかどうかを知っている。
「あるクラス」はClientが○○対応をしているかどうかで、「通常あるクラス」か、「特別あるクラス」かになる。
といった感じです。(※ かなり簡略化した図なので諸々汲み取ってください・・・特に名前は慎重に)

ポイントは3つ。
・「〇〇対応をしている」クラスから IDEで参照箇所を検索するだけで該当の箇所がわかる
これは営業からの問い合わせに容易に答えられるだけでなく、実際に他社展開して導入することも、その後のバグFixも容易になる、ソースコードも追いやすいということです。

・Clientのマスターから対応しているお客様一覧が容易に検索できる。SQL一発ですね。

クラス図で表現できる から資料化しやすい。意外とここがポイントで、こういう特別に対応した箇所は大体運用でも重要な箇所になってきます。メンテが入りがちだったり、バグが出やすかったりするところです。
だから資料に起こすことがよくあることかと思いますが、これが文章で残ってても大概分かりにくく、資料作った人に結局聞くということになりがち。これが、図でソースの中身を説明できれば分かりやすい資料もできると思います。

終わりに

こういう特別対応したケースというのは、開発中から、リリース後日々システムを運用していくなかでも頻繁に話題に上がってくるものだと思います。
つまり、注目すべきドメインであって、ソースコード、特にドメインモデルとして表現されていてしかるべき内容であったりします。

将来こうなりそうだ、こういう問い合わせが来そうだとか、こういう改修をしそうだという予測はなかなか難しいものですが、どういうドメインがビジネスの中心になるかどというのを考えておくことでこのような対応ができるのはないでしょうか?

・・・・・というのを「やりがちなパターン」のような実装をやってしまった後、振り返ったときに気がついたのでこのブログに記録しておこうと思ったのでした。

明日はsestaさんへバトンタッチです!

9
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?