管理システムにおいてどこまでクラスをつくるべきか？
※この記事は、株式会社Ancarのアドベントカレンダー2019の12/10分として公開されています。
※ここで言うクラスはUMLにおけるクラス（オブジェクトを抽象化したもの）を指しています。（しかもだいぶざっくりです、ご了承ください）
はじめに
kintoneを使って、社内で使うクルマの売買管理システムを作りました。（それまではスプレッドシートで管理していました。）そのときにどこまでクラスをつくるべきか悩んだので、備忘録として残します。何かのお役に立てば幸いです。
導入の背景
まず最初に私が関わっているプロダクトについて紹介させてください。クルマの個人間売買プラットフォームを運営しています。
クルマ専門のメルカリと言ったほうが分かりやすいかもしれません。
実はちゃんとした管理画面が存在しているのですが、出品フローや業務フローの変化に管理画面改修が追いつかず、CSチームがスプレッドシートを作って運用していましたが、徐々に下記の課題が浮き彫りになってきました。
・数が増えるにつれて、タスクの抜け漏れがでてくる
・購入後のアフターフォローなどAncarに接点をもってくれた顧客や車両の管理がしづらい
・「クルマの売買体験、所有体験を健全化する」というAncarのビジョンを実現するためのデータが見づらい
上記の課題を解決するためと、オペレーションの変化にも耐えられるという点で、javascriptが書ければ誰でもメンテナンスできるkintoneを導入することに決めました。
クルマの売買に関するクラス
紆余曲折を経て、最終的に下記のクラスで運用を開始しました。
クラスは分割しようと思えば、いくらでも分割することができます。しかし、それがオペレーションにマッチするのか、開発工数に見合っているかは検討する必要があります。おそらくこれがUIデザイナーの腕の見せ所かもしれません。
今回クラスを作る上で考えた観点は下記でした。
＜観点1＞ 再利用したいものはクラスとして分割する
今まで「出品」と言っていた大きなクラスを、売買・車両・顧客の3つに分割しました。
売買が終わった後も顧客と車両を管理したいという要件があったためです。
例えば下記のような要件です。
・店舗に来店してくれた車両に整備記録をつけたい
・Ancarで購入してくれた顧客がAncarに出品できるようにしたい
この場合、顧客や車両のデータを再利用して、新たなデータを作ることが考えられます。
その際に大きな出品というクラスでは、不要なプロパティが多く、扱いにくいです。
顧客と車両をクラスとして分割することで、再利用し新たなデータが作りやすくなりました。
＜観点2＞目的語が違うものは新たにクラスを作る
CSチームにヒアリングしたところ、下記の要件がありました。
・売買の進捗を知りたい
・今日は何のタスクをやらなきゃいけないのか知りたい
「知りたい」という動詞の目的語が「売買の進捗」と「タスク」で違います。もともとスプレッドシートには売買はあったのですが、タスクというクラスがなかったので、新たに追加することにしました。
また売買の進捗や状況に応じて、タスクを生成するようにしました。
クラスを作ったことでタスク一覧ができ、対応期限が早い順といった並び替えをすることができ、「今日は何のタスクをやらなきゃいけないのか知りたい」という要件を満たすことができました。
（「売買の進捗を知りたい」という要件は売買一覧で確認することができます。）
＜観点3＞別のクラスでも同義のものは統合しても良い？？
実は最初は上記の5つのクラスに加えて「整備」というクラスを考えていました。車両に整備記録をつけたいという要件があったためです。
言葉のとおり、クルマの整備記録が紐づくものです。
しかしkintoneの特性上、クラスを分割すると、オペレーションで紐付けの作業を行わなきゃいけない、また自動化しようとすると開発コストがかかります。
悩んでいるうちに、「整備には必ずお金がかかる」ということに気づきました。「車両に整備記録をつける」という要件を「整備」というクラスを作らずに「入出金」というクラスで実現できないかと考えました。（これはめちゃくちゃ悩みました）
しかしこれには考慮漏れがありました。現金での支払の場合、整備が存在すると入金が存在するのですが、振り込みやクレジット決済の場合、整備は存在してても、入金は存在しないというタイミングのずれが発生しました。
入金が確認できたものを「完了」とするというようにステータスをつけて対応しました。
その分オペレーションとUIが複雑になってしまったので、正直正しい判断だったのか分かりません。（優しくアドバイスもらえると嬉しいです）
さいごに
以上がクルマの売買に関する管理システムを実装する上で考え、学んだ点です。
思うのは、システムに落とし込むための要件を洗い出すのが一番難しいということです。 要件が不足し、クラスが過不足になってしまうと、ユーザーにバグとなって出現するからです。
今後も要件については研究していきます。
また今回は2週間ほどで実装しましたが、それを可能にしたkintoneの簡単さと拡張性に感動しました。UIデザイナーにとっても、クラスがひとつのアプリケーションになるので、とっつきやすく、手軽に学べるサービスとしても使えると思うので、今後も活用していきたいと思います。
以上です。
最後まで読んでいただき、ありがとうございました！
この記事が気に入ったらサポートをしてみませんか？