キチンと分析とかしてない、単なるボヤキ。
最近までデスマってた案件では、とあるワークフローエンジンを採用していた。仕様の段階で「ほにゃららワークフローエンジンを採用すること」なんて記述があったらしい*1。何作るかまともに決まってない段階でプロダクト決め打ちならそりゃ火吹く可能性も高まるわな…と後に思ったりした。
それはともかくとして。デスマに放り込まれ、ワークフローエンジン使ってあれやこれや機能つくっていく内に芽生えた疑問。
「ワークフローエンジン使う意味あんの？」
大まかな仕様としては、あるデータの状態が A → B → C と遷移して各状態によってユーザのアクセス権が異なってくる。ワークフローっちゃあそうなんだけど、状態遷移が一方向しかない（差戻しがない）し、状態数も多くて 3,4 個。ユーザーのアクセス権もよくよく仕様読むとかなり単純な制御で済んでしまうことが判明。
んでまぁ、コレって大仰なエンジン使わなくても単純な「状態管理テーブル」「ユーザーがアクセス可能なサービス一覧テーブル」みたいなのだけで十分なんじゃねーの？エンジン使って大げさな管理する必要ホントにあんの？と。
結果、コードがワークフローエンジンを使うためだけに必要な部分で埋め尽くされてしまったのよね。今回の案件ではマッタク使わないけどエンジンの API 呼ぶためにアレとソレのデータ作ってあっちとこっちの API 呼んで…みたいな。何が本質的なコードで、何が非本質的な―エンジンを使うためだけに必要な―コードなのかサッパリになり保守性超悪化。オマケに余分なデータが大量に発生するからパフォーマンスも超劣化。
で、タイトルの「ワークフローって何なんだろうね」に戻る。今回の案件に関しては、ユーザーさんがどんな「ワークフロー」を望んでいるのかマッタク検討してなかったっぽいのでまぁ仕方ないっちゃ仕方ないんだが（本当はよかないが）。
今回使用したワークフローエンジンもそうだけど、世の中に溢れまくってるエンジンはホントーに多機能で高機能。実際のとこ、お客さんに「ワークフローが必要です」と言われてもホントーにあれほど高機能なワークフローエンジンが必要なケースって実は少なかったりするんじゃないかなぁ？
*1:そのワークフローエンジンの売上を何とかして計上せにゃならんから無理矢理ねじ込まれたんじゃないか、みたいな政治的意図が感じられます。
