Vol.5 複雑な機能との付き合い方 - その1
おはようございます。こんにちは。こんばんは。
ハグカムでCTOをやっておりますPontoです。
ユーザーが簡単に操作できる分、裏のシステムがややこしく設計されていることはよくあると思います。今日はそういったシステムの少しややこしい部分に関して書いていこうと思います。
ハグカムでは初期からシステムの投資はできるだけやるという方針で、進めてきています。
できるだけオペレーションの皆さんやバックオフィスの業務等も動きやすくなるように管理画面や先生の画面などには結構機能を入れています。
具体的な機能例
例えば、ハグカムの管理機能の中には売上管理の機能があります。スタートアップ初期はあまり正確には売上や原価を管理できていないことも多いかと思いますが、ハグカムでは早いうちに厳密に作る意思決定を行いました。ざっくり以下のような機能を盛り込みました。
機能としては単純で毎月の売上がわかるようにしたい。管理画面から確認できてほしい。といったものですが、会計上の正確性のため、以下の条件を満たす必要があり、その計算がそこそこ複雑になります。
「曜日と時間を決めてもらった上で毎月課金する」ため、月によって同じ売上でも一回のレッスンあたりの売上は異なる(同じ額だが曜日の関係で、例えば4回レッスンがある月と、5回レッスンがある月がある。売上は支払金額を対象レッスン数で按分するので、一回あたりの売上は常に同じではない)
振替をしたり、中止になったレッスン等をチケットで補填する場合、売上が立つ日が移動する
ルール自体はそこまで複雑ではありませんが、実装するとなるとそう簡単にはいきません。
毎レッスンの売上が異なるので、状況に合わせていくらの売上になるレッスンがいつ実行されたか(= いつ役務提供されたか)を一つ一つ追っていく必要があります。レッスンに関する様々なオペレーションがあるので、抜け漏れが無いように気を付ける必要もあります。
実装は大変でしたが、これらは中でいい感じに計算・処理され、毎月の売上レポートなどに現在使われています。
なぜ実装を決定したのか?
このようにハグカムでは少々複雑な機能でも実装することがあります。思い出しながらにはなりますが、これを実装したタイミングでは以下のことを天秤にかけて意思決定しました。
開発優先順位
たまたま優先度が高い機能はなかった
オペレーションコスト
正確に売上が管理されておらず、困っていた。簡易版の売上シートが不正確かつ肥大化してきていた(当時のオペレーションでは限界に来ていた)
開発コスト
直前にリファクタを行っており、データ管理周りで思ったよりも影響範囲が少なくて済みそう
今回実装しない場合、将来の時点で正確な売上を計上する必要が発生し、その場合更に実装コストは上がる
見積もり段階では 何ヶ月もかかるなどのコストは見込まれなかったため、今のタイミングは今後のことを考えるとチャンスと言えそうと判断し、開発に踏み切りました。
また、100%バグなしでのローンチは難しいと考えたので、売上の検算用のページを別途作り、一つ一つエッジケースを潰しながら完成させるフローにしました(データの管理を早くローンチし、考慮漏れを順番に潰していった)。
また、正確になるまでの多少のズレは一旦目をつむってもらいました。(もちろんシート運用よりも正確性は高い)
効果はあったのか?
これは明確にYesと言えます。
全体的に調査を入れる・挙動の確認の過程で既存のバグ等の発見に繋がり結果として安定度が向上しました。(その分完成までは長くなりましたが)
また、こちらのシステムは現在も元気に動作しており、今後の憂いがない状態になっています。「今から実装する」と考えるとかなりゾッとします。今は今で新たな課題が発生したり、より機能を充実させたい状況になっているため、問題が小さく、早いうちに、タイミングを逃さずに解決できたのは正解だったかと思います。
今回はどのように判断したのか、結果どうだったのかを具体例を中心に紹介しました。次回はもう少し抽象化した判断軸などについて紹介していければと思います。
おわりに
以上、弊社のシステムの複雑性と判断軸に関して具体例を用いて紹介いたしました。
少しでも興味を持っていただけましたら、ぜひ一度お話しましょう!
募集ポジションはこちらから!
・テックリード
・Reactエンジニア
・バックエンドエンジニア
採用情報はこちらから!
それではまた!
この記事が気に入ったらサポートをしてみませんか?