アドベントカレンダー参加記事です。社内で推薦してもらったのですが、社外向けに書こうとすると、社内向け以上に長くなりました。ご了承ください(汗)。
弊社のパッケージでは、給与計算を実行することができます。
一連の処理を実行して、計算結果が固まったら、「締め処理」というものを実行して翌月に進みます。
■矛盾のない計算結果を作成する一連の処理：トランザクション処理
■締め処理：コミット処理
…という考え方なのですが、「間違って締め処理を実行してしまいました」という事故が起きることがあります。
「何故、締め処理を戻せる機能を作らないの？注意しろとか言ってくるけど、間違いは起きるのだから、それを想定してシステムを作らないとダメでしょ」と言われたり、言われないけど明らかに思っているな、ということがあります。
これまで、システム的に判断できる点は、ワーニング、またはエラーを出す機能を追加してきました。例えば、給与明細の作成処理がされていない社員がいたら、画面実行ならワーニング、スケジュール実行ならエラーになるような機能です。
しかし、システム的に何の異常もなくても、入力データが漏れていた、だから戻したい、ということもあります。「制御とかじゃなくてさ…戻せるようにさ…」という生の声や、心の声が聞こえてきます。
簡単に言ってくれますけどね…。
システムは、トランザクション処理とコミット処理の積み重ねで成り立っています。トランザクション処理の中でデータの整合性を保ち、コミット処理でそれを固めます。そして、また新たなトランザクション処理を進められるようにします。
締め処理は、大型のコミット処理です。中身としては、累積テーブルにデータを移したり、累計値を作ったり、ということを多数、実行しています。月が変わるところでコミット処理を入れることで、また翌月の処理、新たなトランザクション処理を進めていけるのです。
締め処理をした瞬間、まだ新たなトランザクション処理が何も動いていないタイミングに限れば、基本的に戻せるであろうスクリプト、手順というのも、実は用意しています。でも、新たなトランザクション処理が進んでいたら？機能化するとしたら、どこまでを想定するのか。例えば、「締め処理直後なら戻せます」という機能を出すと、締め処理のハードルが下がり、次は翌月の開始処理まで進めてしまうケースが出てきます(※今もあるのですが)。
別視点のアイディアもあって、例えば、締め処理についてシステム的に承認操作を強いるようにすれば良いのでは？というものがあります。しかし、これはスケジュール実行との相性が非常に悪いです。
また、さらに制御を追加することも考えられますが、制御が強過ぎると、今度は止めなくて良い状況で処理が止まって、特にスケジュール実行の場合は業務上、大きな問題になり得ます。また、制御が強いからといってオプション化して出すと、今度はそのオプション設定ができていませんでした、ということになったりします。
そもそもスケジュール実行を禁止すれば、という発想もありますが、スケジュール実行自体、お客様としてはミスを防ぐために組んでいます。
これは、強い実感も含めてのことなので、この文章だけで伝わるか分からないのですが、要はいたちごっこなところがあります。だから私は、如何に「戻せるようにさ…」という声が聞こえても、締め処理の持つ重みを軽んじられることだけはないよう、振る舞っています。
もちろん、開発部門に属する人間としての思いは別です。
昔、弊社の採用インターンシップで、お題に沿ってシステムを作りなさい、という課題が出たことがありました。これに対して、画面の真ん中に「業務」というボタンを配置し、押すと「業務が完了しました」というShowMessageが表示されるシステムを開発して、プレゼン込みで奇跡の合格を果たした者がいました(※今やったら多分落ちますが)。
開発として目指すべきところは、こういうところなのかな、とは思います(※もちろん、中でちゃんと処理が動いて)。
が、以前ユーザーサポートをやっていた身として、これを開発の問題だけで済ませてはいけないとも思うのです。
プロダクトを持っている会社では、何かと、「プロダクトで解決し得る問題=プロダクトが悪い」ということになり勝ちと思います。それで済ませようとすれば、全ての問題がそうなります。仮にユーザーサポート側がそういうスタンスなら、間違っています。ユーザーサポートと開発が、お互いにできることをやって、前進すべきです。