SoR系分散システムでのもろもろ考慮点（勢い版 2017.07

今は無き親父がエンジンをベースに自分で作ったコンプレッサー。結構な勢いで動作効率が悪い。

Fintechブームのなかで、SoR (System of Record)系に手を出す若手技術者中心の企業もちらほら出てきました。いざお金や契約が絡むシステムを創ることになりますと、やはりというかいろいろとビビるそうです。いやー多分、ソシャゲ界隈の営業や顧客サイドからの圧力のほうが厳しいんじゃないかな、と想像するんですが、それは本題ではありません。

今回の資料は、SoRなシステムを創る際に、創ってる最中に、そのシステムは妥当なんだろうか、という不安に苛まれた際、ちょっと横目に見てみる資料です。余計不安になるとか言わないの。最近、このネタを若手中心、業務系分散システム初心者に向けて話すことがあったので公開します。

業務システムっていうよりは I/O の塊の処理系っていう話よね。

今回の公開の背景

SoRなシステムに携わっている人達も当然、SoEでハイトランなシステムを担ってる人達と同様に、システムを設計し構築し運用していく際には、様々な事にぶつかり、いろいろと考えを新たにする機会を噛みしめ、失敗こそ糧だなぁと確信しつつも不安の中で模索していくわけです。

（ゲームやネット事業系やガチの交通機関系とか）大規模なシステムの開発や運用に、技術や部署の壁を越えて知見を得る程度に携われる経験は、実際には限られてるわけで、派手だけとモノシリックなシステムで完結してしまう規模のFintech企業や、大規模でも組織の壁が高く誰かが書いた書く前から終わってる仕様書からコードを転記する仕事に従事してたりすると、職務経歴書の割に、考える事を知らずに転職することになるなんてことも、ままある話です。

特に課題になるのは、若手の育成でしょう。大学で高専でCやJavaを書いていたっていう経験と、実務現場での分散系の業務システムとは、その実践においてやはり、考慮することに違いがあるのは事実です。

でも、その違いを知る、考慮する際の取っ掛かりというか、モデルがないよねぇ、と常々思ってまして、その整理をした資料です。

あわせて、以下の資料も面白く使えるんではないか、と期待してます。

あえて再考「クラウド」とは何か（事業会社向け概論

ディスカッション、ご意見ほか

arichika.taniguchi は、https://twitter.com/arichika とか、https://www.facebook.com/arichika.taniguchi このあたりにいます。