井上さんの記事読んだ。
Yes/Noで言えば、余裕で出来るでしょう。業務という名前を出すと仰々しいけど、そんなの議論するまでもない。
エンジニア不足の時代を見据えたPaaS
ITで何かを解決したいヒトはITが当たり前になれば増えていく。でも、ITで課題解決が出来る人は人口不足から始まりIT技術の細分化等で減少していく。ニーズがあっても、供給が足りないという状況は加速していく。井上さんもこのミスマッチについては言及されている。
エンジニアの需給ギャップが問題になるなら、エンジニアがいなくてもITを提供できるようになればいい。プログラムレスで必要なプログラムを手に入れる。そのような狙いもPaaSにはあるんじゃないかなと感じました。
NoSQL的な考え方が基本
1アプリ：1フォーム：1テーブル：n一覧ですから、例えば受注というアプリを作ったとすると、受注と受注明細というデータの塊について、CRUD（作成・参照・更新・削除）が出来て、一覧については色々な切り口で複数作ることが出来ます。
でも、受注する際に必要となる「商品」というデータは別アプリで管理しなければなりません。商品マスタや在庫に関する情報を別アプリで管理した上で、受注アプリでは商品をルックアップして、受注明細の商品項目を入力することが出来ます。
kintoneの機能を眺めてみる（アプリ機能の基本） | コラム | artisan edge thinking
ん？KVSかな？受注.xlsっていうドキュメントが１個ずつできて、それを個別に保存しているようなイメージ。ま、それが事務処理ってもんだ。１つの書類に必要な全ての情報が格納されている。議事録・日報・FAX・発注.... そういったものは各々連携する必然性がない。追加して保存が出来れば良いし、必要な時に引っ張ってこれたらそれでいい。
双方向性を実現するのは当然困難
すごく簡単に言うと、こういうことでしょ。受注001.xlsxというExcelがある。注文数のセルを訂正して保存しても、VLOOKUPで取得した商品の在庫数は更新されない。Excelにおいては、当然の話だけど。また、VLOOKUP先を更新する方法がないし、取得した在庫が最新かどうかも保証されない。
この連携を実現するとなると、商品データを取得した時にリビジョンIDを仕込ませて、更新時にそのリビジョンIDとマッチすれば在庫数を更新するんだって。商品の更新履歴を管理しているのね。注文取るとなると商品点数は複数あるので、30個の商品を一気に在庫更新すると大変だね。コンフリクト祭になりそう。
月締請求とか死ねる予感
KVS的なデータ構造が最も苦手なことなので、まず無理だろうな...
見積→売上→請求っていう感じで、1つのドキュメントがそのまま流れていくだけなら何の問題もない。取引と伝票は1対1で、その都度振り込んでもらうとかそういうの。が、10/21〜11/20の売上を集計して11月度の請求書を作るってなると、死ねる予感。
〆処理には、顧客・入金・請求先・売上・請求と５つデータが「最低」必要で、顧客と請求先は一致しないし、締日も支払いサイトも顧客データに依存する。当然のごとく訂正・再発行もある。
もし請求までkintoneやりたいとなれば、上記に気をつけよう。
PaaS市場は伸びていくのか
どうなんやろ。受託で人月脱するためにはPaaSやるしか無いと思うけど。僕はやる予定無いけど。
倉貫さんの会社もKintone担ぎだした。「それ、Kintoneで出来るよ。速くて安くて安心だね。」っていう規模の仕事が多いんでしょう。HerokuにあげてRailsで作って...では重すぎるというか。データの双方向性が求められないのなら、kintoneで出来る。プログラマとしてはつまらないと思うけど、コード書くより早そうだし、プログラム書かないのでシステム納めることが出来るって良いよね。要件定義段階のリスク以外は、ほとんど無いように思える。
クラウドを担いでクラウド上のサービスをつなぎ合わせるSIがこれからの主流となるでしょう。僕は生暖かくその動向を見守ることにします。
