昨日、私たちは実際のSI案件のなかでvte.cxを活用してきたと述べました。
自分たち開発者だけでは本当に価値のあるサービスやフレームワークを作ることは難しいです。
それは、開発時よりもお客様の本番環境で実際に利用してからわかることの方が多いからです。
だから、まずはドックフォーディングをやり、私たち自身がvte.cxのユーザとなって、お客様の要求するシステムを作ってみる必要があるのです。
しかし、SI案件で自分たちのサービスやフレームワークを採用してもらうことは難しいのではないかと思われる方も多いと思います。
たしかに、フレームワーク採用はスクラッチ開発に比べてハードルは高くなるとは思います。お客様も簡単には受け入れてはくれないでしょう。しかし、実はSI案件だからこそフレームワークが必要になるケースはむしろ多いのです。
今日はこの話をもう少し掘り下げて説明します。
#請負でフレームワークを売るべき理由
請負というのは、辛く、切ない世界です。Web業界に転職したくなる気持ちはよくわかります。
決められた期間と工数のなかで、限られた裁量の範囲で作業しなければなりません。そんなSIは奴隷のように働くIT土方という人もいます。私には、単に時間をお金に換えるだけの不毛な期間が過ぎていくように思えることも多々あります。
ところが、自分たちのサービスやフレームワークが採用されるとわけが違ってきます。
これまではいかに楽をしようかと考えていた「やっつけ仕事」が、(自分たちの製品を)いかに品質を高めるかといった「価値ある仕事」に変わります。
時間をお金に換えるだけの不毛な作業ではなく、やればやるほど自分たちの資産（製品の価値）が増えるという意識が出てきます。
つまり、プロジェクトの様々な要求が製品の価値を高める手段に変わるのです。これは単なる意識の違いですが、お客様から多少厳しい要求があったとしても、開発者は猛烈に「価値のある仕事」に取り組むようになります。
また、これは生産性や品質という面でお客様にも大きなメリットをもたらします。つまり、Win-Winの関係になれるのです。
#優秀な人はフレームワークを作るべき
生産性が５倍〜１０倍という優秀な技術者が稀にいます。
しかし、SIの業界では評価されることが少ないです。
単金が高いことは時々ありますが、せいぜい+１０％〜+２０％ぐらいで、１０倍の生産性だからといって１０倍になることはまずありません。
なので、優秀な人はフレームワークを作るべきです。
１０倍の単金を払ってもらうことは無理かもしれませんが、フレームワークであれば購入してもらえるかもしれません。
#SIの現実とスペシャリストの必要性
SIの１次受けはなるべく単価の安い人材を調達しようとします。
その理由は簡単で、仕入れを安くすれば利益が大きくなるからです。
必ずしも優秀である必要はありません。とにかく人数を確保することだけを考えます。
しかし、低スキルの寄せ集めのチームが、SoEのミッションクリティカルシステム、つまり、高パフォーマンスや高可用性が要求される大規模な基幹システムを構築しなければならなくなったときに、悪夢が始まります。無秩序がまねく混乱の渦、デスマーチの音が聞こえてきます。
平易なコーディングしかできない者が１００人集まっても無理なものは無理です。
システムは単に動けばいいというものではありません。
高パフォーマンスや高可用性の要件を満たすには、それに精通した高度なスキルを持った人材が必要不可欠なのです。
#フレームワークで炎上を防ぐ
しかし、フレームワークがあったらどうでしょうか？
ご作法どおりに実装していくだけで、自然と高いパフォーマンスが得られ、可用性も問題にならないようなフレームワークがあったとしたら？
私は、難易度の高いシステムを優秀な人材が束になってスクラッチで開発するよりは、フレームワークを活用することで誰でも簡単に開発できるようにする方がよいと思っています。そもそも、高スキルな人材はそんなにいませんから。
例えば、vte.cx/reflexworksには、以下のようなルールがあります。開発者はフレームワークを使うことで自然とルールに則った開発ができるようになります。
- RDBはBDBの代わりのデータストアとして使用されるがキーバリューデータストア以上の機能を求めるものではない
→最も優先されるものはパフォーマンスと可用性であり必要以上のRDBの機能は使わない。 - パフォーマンスに大きな影響を及ぼすJOINとViewについて、JOINはなるべく使わない。Viewは使用禁止。
→普通に開発しても上記制約を設けることでパフォーマンス劣化問題が入り込む余地をなくすことが目的 - 業務要件を満たす限りシンプルな設計をこころがける。
Entityの第一階層の項目がテーブルに対応する
→１テーブル＝１エンティティを基本とすることで詰め替え処理のような無駄をなくすことができる。
可用性については特に触れませんでしたが、フレームワークにおいて可用性を考慮し、ビジネスロジックでは考慮する必要がないようにすべきなのは言うまでもありません。
開発者はフレームワークのレールに乗って実装するだけで他に難しいことは考える必要はありません。そのため、それほどスキルの高くないチームであったとしても高い生産性を発揮できるようになります。しかも、パフォーマンス劣化問題や可用性の心配もする必要がありません。
#システム全体で統一したエンティティを第一に考える
上記はRDBを使用したときの考慮点について述べていますが、元々、vte.cx/reflexworksでは、KVS(BDB)が標準のデータストアです。
これは、エンティティオブジェクトをそのままの形でデータストアに格納して管理できるようになっています。RDBというよりはオブジェクトストレージの方が近いかもしれません。
これまでKVSを使ってみてわかったことは、ソートなど一部の機能に不自由はあるものの、業務アプリを動作させるうえで必ずしもRDBである必要がないということ。むしろ、正規化をしないKVSの方が素直で直感的に作ることができるということです。
だから、vte.cx/reflexworksではテーブル設計ではなく、エンティティ設計を第一に考えます。
スキーマテンプレートの一元管理により、システム全体で統一したエンティティの項目名が使われ、見通しがよくなり品質の向上につながります。また、スキーマテンプレートはソフトスキーマであり、項目の追加変更が自由にできます。スキーマの変更は運用中でも可能であり、リソースの再デプロイも必要ありません。
#業務アプリケーションはBaaSでも十分に開発できる
以上述べたように、フレームワークでルールを作り、スキーマによってエンティティを統一的に管理する。これが、高パフォーマンスかつ高品質なシステムを作るうえでの重要なポイントになります。
一方で、制約が厳しすぎると実用的なアプリケーションを作ることが困難になります。残念ながら世の中のBaaSやPaaSなどでは厳しい制約のあまり中途半端なものしか作れないという印象があります。
弊社では、この１年、大規模なB2Cサイトから小規模な受注システムまで、vte.cx/reflexworksを利用した複数のプロジェクトをリリースすることができました。
これらの実績は、本格的な業務アプリケーションをBaaSでも作ることができることを証明するものです。KVS上で業務アプリケーションを動かすための条件については、KVS上でアプリを動作させるために必要なたった２つのことに詳しく書いているのでぜひ読んでみてください。
では、また明日。