スタロジカンファレンスを傍観して〜ABDのこととか
先日のぶり祭りも昨日のスタロジカンファレンスも諸般の事情で行けず、同僚が行って来たという話やログを聞きながら残念に思う二日間を送っています。
ただ少なくとも昨日は、現在のいろんなスケジュールと相談の上で決めたことなのでどうこう言うことじゃないですが。興味を失ったように思われるのも*1さすがに心外なのでエクスキューズしときます。
で、今日はご厚意でAP4Rの方々と勉強会＆懇親会をやらせていただいたわけですが、その場でもやっぱりスタロジカンファレンスの話がいっぱい出ました*2。だってかっこいいし悔しいし。平常心じゃいられないですって。
で、二月のデブサミとこれまでにうかがったこと、同僚の話を聞きながら思ったこと。あくまで私の妄想なうえ、前述の通り最新状況にキャッチアップできていないので注意。
DBスキーマからCRUDな画面を生成する、というのはRailsの例を見るまでもなく現在のテクノロジーでは出来そう。
で、それでもRailsのscaffoldを見て感じる限界というのは、あくまで静的なものからできるのは単一テーブルのマスタメンテとかになりがち。関連を考慮したscaffoldもできるけど、それで出来るのも便利な単票のCRUDベースなのかな、と。でも実際の業務にはフローというか、もっと動的な流れが存在しているわけで、それをどうするか。
じゃあ、単一テーブルのCRUDで流れを表現できればいいじゃんということでそれを実現するのがABDとかですよね。「Activityをエンティティとして(CRUD可能な単位として)扱う」ということは、フローという「移りゆくものを移りゆくという特性を保ったままに永続化する」手段な訳だと思ってます。
でも移りゆくものを移りゆくものであると認識するための情報はやっぱりDBからだけじゃ取得できないわけです。例えばマスタデータはいつマスタデータになるの？とか。だからこそ対象となる業務の流れをつかみたいわけで、それがマジカでそれをシステム的に落としこむ手段がBuriなのかな、と。
すると何が出来るか。システム的には、その画面で入力すべき項目と、それから進むべき次のアクションというのが推測可能になります。なぜなら、その業務によってどのような情報が保管されるべきかということの特定と、情報の保管状況と業務の流れをルックアップすることでによる次のアクションの推定が可能になるから。その情報を活用すれば自動生成で出来ることの幅が、旧来のそれとはまったく違った次元になることは想像できます。
もうひとつ。Activityを名前のついたエンティティとして扱う、ということはそのエンティティを指すUnifiedなIndicatorが持てるということでもあります。そのIndicatorをCRUDするタイミングを制御するための情報を取得できれば以下略。
などなどを考えると同業他社が悔しがるべきは8万円をどうこういう以前に、そういう仕組みを持ってる企業が**いま**あり、自社ではまだそれがそこまでは(と予防線)出来ていないということかと。さらに、それでぼろ儲けをしようというわけじゃなく、それが最低基準である世界を作ろうという野望を持ってそうなこと。ぼろ儲けを狙ってくれたほうが嬉しいんですけどね*3。
じゃあ自分らではどうしようかというと、そんな妙案は簡単には思いつくわけがない。ずいぶん前から危機感/面白そう感を感じていながらそのための準備を何一つ出来ていない自分にうんざりします。そのうえでどうするか、というのは見えませんが、同僚と問題意識を共有できたこと自体は良かったです。すぐに結果が出ることじゃないですが、そこは受け入れて一歩ずつやるしかないかな、と。
話を聞けば聞くほど書けば書くほど、想いを巡らせれば巡らせるほど、昨日はナマで聞いとくべきだったなぁ、という想いは強まります。それでも自分の選択したことですのでそれは納得してますし、たぶんもう一度同じシチュエーションがあっても、お客様に対して自分がコミットしたことを遂行することを選びますけどね。責めるなら、それを両立できるくらいに、前倒しで進められなかった私自身が悪い。自身としては救いがない締めですが。。。。
