株式会社FOLIOの次世代証券システムをひもとく
これはFOLIO Advent Calendar 2017の25日目の記事です。昨日は弊社CTOである椎野（tshiino48）による「IOTA ~ポストスマートフォン時代のフィンテック~」でした。
本日はFOLIO Advent Calendar最終日、締めの記事を「株式会社FOLIOの次世代証券システムをひもとく」と題して、Head of Engineeringの伊藤（@itohiro73）が務めさせていただきます。
株式会社FOLIOでは、フォリオという、個別銘柄ではなくテーマを選んで投資するオンライン証券サービスを提供しています。
*図表やデータ等はあくまでもサンプルであり、将来の運用成果等を示唆あるいは保証するものではありません。また、サービスの詳細はこちら 。
本エントリーでは株式会社FOLIOを支える次世代証券システムについて、機能面とエンジニアリングの両方の視点から解き明かしていきたいと思います。
PORT + FOLIO
株式会社FOLIOには大きく分けて「FOLIO」というオンライン証券サービスと、「PORT」という証券業務システムの二つのプロダクトが存在します。
FOLIOとは
ここで解説する「FOLIO」はフォリオのサービスを構成するシステム群全体を表すプロダクト名です。まさにユーザーが直接接するプロダクトのことですね。株式会社FOLIOと同じ綴りですが、ここでいうFOLIOはプロダクトそのものの名称なのです。ちなみに、FOLIOの中にも厳密にはFOLIO-WebとFOLIO-Mobileが存在しており、FOLIO-MobileではiOS（Swift + Redux）とAndroid（Kotlin + Flux）での実装が現在開発進行中です。
今回はすでにβ版としてリリースされているFOLIO-Webに軸足をおいて説明します。
FOLIOのフロントエンドはBFF(backend for frontend) on Node + React/Redux というモダンなアーキテクチャーで構成されており、BFFの裏側はScalaのマイクロサービスで構成されたバックエンドシステムとThriftによる通信でコミュニケーションを行なっています。ユーザーの口座情報やポートフォリオなどのマイクロサービスが提供する情報をBFFが集約し、サーバーサイドレンダリングした上でユーザーに表示しています。
実際の取引には受発注処理のためのマイクロサービスの実装があり、株式会社FOLIOとお客様の相対取引を執行する店頭市場の実装、そして株式会社FOLIOが外部の証券ブローカーへFIXプロトコルを通じて取引を発注・約定するためロジックが実装されています。
現時点で20を超えるマイクロサービスが存在しており、Consulによるサービスディスカバリ、Fluentd/Kibanaによるサービスログ集約・可視化やSlackへのアラート通知、Zipkinによるサービス間トレース、Prometheus/Grafanaによるインフラ監視・ダッシュボードの整備等々、サービスの成長に従って増加していくマイクロサービスやそれを支えるインフラを管理していくにあたって重要なミドルウェア群も整備されています。
証券会社としてはかなりモダンでチャレンジングなアーキテクチャーを採用しており、エンジニアリングの側面からも非常に面白いシステム構成になっています。
FOLIOのチャレンジ
証券会社のサービスとはいえ、FOLIOの構成は一般的なWebサービスのマイクロサービスアーキテクチャーとも言えますし、ぱっと見普通のWebサービスのような開発が行われているのだろうと想像されがちです。しかし、証券の取引やお客様の資産を扱うという面において非常に繊細かつ高度な品質が要求され、通常のWebサービスと比べても機能面・技術面の両方において非常にチャレンジングな側面を持っています。
機能と技術両方において難しい一つの典型的な例をあげると、たとえばコーポレートアクションという機能。
コーポレートアクションとは、「企業の活動」という意味ですがその中でも特に有価証券の価値に影響を与える企業の意思決定のことをさし、具体的には株式分割、株式併合、株式移転・交換・合併などが含まれます。
このコーポレートアクション、機能的にはそもそも扱わなければいけない状態数が非常に多いために、UXデザイン、フロントエンドやバックエンドの要件定義と実装、テストを行うだけでも膨大なリソースと相当なエンジニアリング力が試されます。
技術的には、情報の更新タイミングを合わせるための難しさがあります。たとえば株式分割という事象では、お客様の資産において「保有株数」と「株価」というふたつの情報が違うタイミングでシステム上の変更が行われます。お客様が最終的に興味がある「保有資産評価額」はこのふたつの情報をもとに計算されます（「保有資産評価額」= 「保有株数」x「株価」）。このふたつの情報更新のタイミングの違いによりデータベース上でシステム反映時間とビジネス的な有効時間情報の両方を同時に表現する必要があり、これは技術的に非常に扱いが難しいものになります。
この問題の解決のために弊社ではreladomo-scalaというOSSを開発し、活用しています。本OSSはScala関西Summit 2017で公開され、当該セッション資料にもコーポレートアクションの例が記載されているため、興味がある方はのぞいてみてください。
www.slideshare.net
PORTとは
PORTは、顧客が日々直接接するWebサービスのプロダクトであるFOLIOとは違い、証券会社の内部業務を支えるミドル・バックオフィスシステムの総称で、株式会社FOLIO独自のプロダクト名です。実は、証券会社が業務を行う上では証券取引の性質上行わなければいけない業務や、さまざまな法律や規制に基づいて規定された必要業務が存在しており、それらを支えるPORTは株式会社FOLIOの心臓部とも言えるシステムなのです。
PORTという名前には、FOLIOというサービスプロダクトを毎日無事に出港させるための港（Port）でもあり、PORT+FOLIOが両方合わさって初めてPortfolioという概念が完成される大事なシステム、という想いが込められています。
では、PORTとは一体どういう機能を持つものなのでしょうか。すべてを事細かに紹介することはできませんが、おおよそ下記のような業務機能をサポートします（未実装の機能も含まれます）。
顧客口座管理
口座開設のための本人確認や、必要情報の整備、カスタマーサポートに必要な顧客情報等を管理します。
取引管理
約定や決済の情報管理やそれらの処理が正しく行われているかどうかの突合処理、コーポレートアクション情報の管理などが含まれます。
入出金管理
銀行とお客様のフォリオ口座の間の入出金処理や履歴を管理し、金額情報に誤りがないことを担保する重要な機能をサポートします。
報告書作成
お客様への取引報告書や法定帳票の作成をサポートします。
財務処理
自己資本規制比率を算出し、証券会社としての財務の健全性を保つための業務をサポートします。
リスクコントロール
自己勘定取引におけるポジションリスクの管理や、ヘッジのための機能を提供します。
コンプライアンス業務
コンプライアンスに関わる売買審査や社内コミュニケーション管理、監査情報の管理等をサポートします。
投資委員会業務
フォリオで提供するテーマの銘柄選定や入稿をするための業務をサポートします。
上記のように、PORTでサポートする機能は多岐にわたり、会社の業務を支える重要な要件や、法律や規定によって定められた複雑な要件を満たす必要があります。たとえば「本人確認」といったひとつの業務要件においても、顧客ユーザー、社内ユーザー、社外システム等のそれぞれのアクションによって異なる状態遷移を管理する必要があり、非常に複雑でかつ高品質を求められる業務システムになっています。
PORTのアーキテクチャとBPMN/ワークフローエンジンの活用
PORTに関しては、フロントエンドがRuby on Railsによって作られている以外はFOLIOとほとんど同じ構成で、バックエンドのマイクロサービスアーキテクチャはFOLIOと同様Scalaによるマイクロサービスが配置されており、Thriftによる通信でサービス間コミュニケーションをしています。サービス監視やインフラ構成もFOLIOと同様の構成です。
実はPORTの機能の多くはいわゆる業務システムであり、さまざまな状態遷移をもつワークフローに基づくものが多いです。このような性質をもつ業務の要件定義を行う際に、BPMN（Business Process Modeling Notation）と呼ばれるモデリング記法が非常に役立ちます。
BPMN自体は業務フローのモデル化のための記法にすぎませんが、BPMNと組み合わせてワークフローエンジンを活用することで、モデル化したフローをの大部分をコード生成し、実装コストを大幅に下げることが可能だと考えています。
FOLIOでは現在オープンソースのBPMNワークフローエンジンであるCamundaに着目しており、この技術でPORT開発と業務フローの改善ができないかの検証に着手しようとしています。
PORT+FOLIOの誕生秘話
このように、PORT+FOLIOは次世代証券会社を支えるシステム構成であり、それぞれが非常にモダンかつエキサイティングな技術によって支えられています。
しかし、PORTというプロダクト概念はまだ産まれてから半年強しかたっておらず、フロント以外のバックエンド構成はFOLIOと密に結合してしまっています。これは、FOLIOというベンチャー企業が誕生してから約一年半、これらの概念が認識される余裕もないまま一気にシステムが成長してきてしまったことに起因しています。
実は半年ちょっとくらい前まではPORTという名前も概念も存在せず、その機能の一部であり社内ユーザーが触れるRuby on Railsのフロントエンドの機能群が単に「管理画面」と呼ばれている状況で、その重要性やプロダクトとしての地位、エンジニアが機能開発にとりくむモチベーションさえもが非常に低い状況でした。これは由々しき問題です。
上記で述べたように、証券業務の機能は株式会社FOLIOの心臓部ともいえる非常に大事なシステムであり、重要な概念として認識される必要がありました。今年の春に証券会社出身のエンジニアが何名かジョインした後にこれらの概念が整理され分類されることで、顧客に提供するWebサービスと証券業務システムふたつの概念としてまずは認識されるべきだという提案が共有されました。
この概念整理に伴って証券業務システムにも愛着の持てるエキサイティングなプロダクト名が必要だろうということで社内で名前募集をした際にPORTという名前が提案されました。その提案がなされた際の、まさにその瞬間の社内Slackのキャプチャ。PORT爆誕の瞬間です。
われわれは会社全体としてビジネス陣、クリエーター陣（デザイナ＋エンジニア）含めて、証券業務システムをサービスプロダクトであるFOLIOと同じくらい重要視しつつ育て上げていくというマインドを育んでいく必要があり、PORTという命名はその第一歩だったのです。
そして、最初に載せたこちらのイメージこそが、PORT + FOLIOの目指していく姿を共有するためのプロダクトビジョンでもあるのです。
PORT+FOLIOの未来
FOLIOとPORTというふたつのプロダクトの概念を説明しましたが、上でも述べたように、実はフタを開けてみるとこれらのシステムは互いに密に結合してしまっています。PORTは概念として誕生し、育まれてきましたが、まだ完全に独立したライフサイクルをもつシステム群としては存在できていません。
特にバックエンドに関してはポートフォリオ管理サービスや受発注処理サービス等、FOLIOを構成するマイクロサービス群の一部から直接のAPI提供も受けており、決済やポジション管理に必要なバッチ処理もFOLIO側のバックエンドサービスに直接接続するなど密な構成になってしまっているのです。
本来であればこれら二つのプロダクトは、全く違う対象ユーザー、システム要件、ライフサイクルの性質を持っており、それらをふまえた適切なアーキテクチャやPORT<=>FOLIO間のメッセージングの設計、また、それぞれのプロダクトに対応したエンジニアチームの編成もつくっていきたいところです。
理想としては、FOLIOは最高のUXと高品質なサービスを提供するためにアジャイルなリリースサイクルをまわしつつグロースハック施策をうつ、PORTは必要な業務要件を適切に吸い上げながら堅牢なシステム構成と高い品質を保った開発リリースをまわしつつコスト削減をめざす、といった形で全く違う開発ライフサイクルを持つべきであり、そのためにもアーキテクチャ分離がなされている必要があります。
しかし、現在のPORT+FOLIOアーキテクチャーでは適切なサービスモジュール分離と完全な開発リリースサークルの分離はまだ完全に達成されておらず、互いに密な設計、テスト、リリース計画を行う必要がある構成になってしまっています。
もちろんPORT用途のAPIサービスが一部分離されていたり、PORTフロントエンドのリリースサイクルの分離が推進されていたりと、改善してきている部分は多くあります！が、本来あるべき姿に到達するまでまだまだやるべきことは山積みです。
そして、PORTに関しては現在外部システムとの連携や外注システムの利用に頼っている部分があったり、まだ完全にシステム化されておらずマニュアル作業にたよっている機能も多く存在します。株式会社FOLIOの長期的な成長とコスト構造改善を推進していくためにも、これらのPORT機能を内製化していくことは非常に重要なアクションと言えるでしょう。
つまり何が言いたいのか...？
この記事を読んでいただいたことで、株式会社FOLIOの次世代証券システムのエンジニアリングに興味を持ったあなた、FOLIOの最高のUXづくりとアジャイルな開発プロセスを推進したいモダンな技術に興味があるエンジニアのあなた、PORTの堅牢な証券業務システムづくりに興味がある重厚感を持ったエンジニアのあなた、PORT+FOLIOのアーキテクチャ分離とリリースサイクル改善に興味をもった改善マインドを持ったエンジニアであるあなたと、われわれはぜひ一緒にこれらの施策を推進していきたいと考えております！
興味を持った方は、ぜひ下記の募集要項からご自身の興味のある職種にご応募ください。
本日は「株式会社FOLIOの次世代証券システムをひもとく」と題しまして、弊社の2大プロダクトであるFOLIOとPORTについて解説しました。これを持ちましてFOLIO Advent Calendar 2017の最終エントリーとなります。本エントリーでFOLIOに興味を持った方はアドベントカレンダーの他の記事ものぞいてみてください。多種多様な記事があって面白いですよ！
それではみなさん、メリークリスマス！素敵な年末をお過ごしください。
Scala関西 Summit 2017で瀬良さんと「Reladomo in Scala」という話をしてきました #scala_ks
9月9日に開催されたScala関西 Summit 2017に参加して来ました。私の所属する株式会社FOLIOもブロンズスポンサーとして協賛させていただきました。
Scala関西、やって参りました！へーしゃ株式会社FOLIOもスポンサーしております。求人も見てね。 https://t.co/LmO099kxep #scala_ks pic.twitter.com/b6HsZbwqpx
— Hiroshi (@itohiro73) 2017年9月9日
セッションでは、ScalikeJDBCやSkinny Frameworkでおなじみ瀬良さんと共同で「Reladomo in Scala」という話をしてきました。
www.slideshare.net
今年のカンファレンス参加はひたすらReladomoの話ばかりしている気がします…！今回はReladomoそのものの紹介と共に、ReladomoをScalaから使うためにFOLIOとグッドフロー・テクノロジーズ瀬良さんが共同で開発したラッパーライブラリreladomo-scalaの紹介をしました。詳しくはスライドをご覧ください。
今回のセッションの目玉はなんといってもreladomo-scalaをリアルタイムでGitHubに公開したことでしょうか！
FOLIOでの業務委託としてグッドフロー・テクノロジーズ瀬良さんに手伝っていただいている成果物をOSS公開するという、非常に珍しい形でのリリースかと思います。
お!!
— Yoshitaka Fujii (@yoshiyoshifujii) 2017年9月9日
きた!!
reladomo-scalaが公開されるぞ!!#scala_ks #scala_ks_main
いまからreladomo-scala 公開するぞー！！！！！！！！！！！！！！！！！！！！ #scala_ks #scala_ks_main
— よこな (@ihcomega) 2017年9月9日
VSCode の公開のときみたいなやつだw #scala_ks #scala_ks_main
— むらみん (@Mura_Mi) 2017年9月9日
伊藤さん「今からここで・・・！(テンションマックス)」
— よこな (@ihcomega) 2017年9月9日
瀬良さん「あ、ちょっとまって」#scala_ks #scala_ks_main
https://t.co/95HGTKKwuC
— ねてる (@pajamaao) 2017年9月9日
reladomo-scala 公開なう#scala_ks #scala_ks_main
おお!!
— Yoshitaka Fujii (@yoshiyoshifujii) 2017年9月9日
公開されたぞ!!https://t.co/IaVG2PXZdm#scala_ks #scala_ks_main
reladomo-scala、セッション中にライブOSS公開。 🎉 https://t.co/XH0dMmO678 #scala_ks
— ザネリ🤔 (@so_zaneli) 2017年9月9日
reladomo-scala 公開したぞー！！！！！！！！！！！！！！！！！！！！https://t.co/PCmb7tGMCW#scala_ks #scala_ks_main
— よこな (@ihcomega) 2017年9月9日
giter8のテンプレートも同時に公開しているので皆さんぜひご活用ください。
こちらのコマンドで動かしてみてください。
# sbt new folio-sec/reladomo-first-example.g8
前にもどこかで言ったかもしれないですが、「バイテンポラルデータモデル」という名前とその概念が当たり前のように認識される世界が来るとエンジニアの世界はもう少し幸せになるかもしれないと思っています。金融に限らず履歴や有効期間の概念を扱わなければいけないシステム開発要件は山ほどあるはずなので。
Reladomoのキラーコンテンツであるバイテンポラルデータモデルを理解するにはJJUG CCCのこちらのスライドがおすすめ。
www.slideshare.net
Reladomo本体の基本的な使い方を理解するにはこちらのスライドがおすすめ。
www.slideshare.net
OSSはコミュニティの輪が広がってなんぼなので、皆さんぜひReladomoやreladomo-scalaを使って盛り上げていきましょう！
当日の様子はこちらから。
今回Scala関西 Summit初参加でしたが、Scala界隈の初めてお会いする方々といろいろ話すことができて、非常に有意義な時間を過ごせました。運営の皆さん、素晴らしいカンファレンスを開いていただきありがとうございました。本当にお疲れ様でした！！！
おまけ：懇親会2次会で食べたセル牡蠣、お刺身、ヒレ酒がうまかったぞ〜。
ヒレ酒～。めっちゃいい薫り！！ pic.twitter.com/Ksl5GCcRvx
— Hiroshi (@itohiro73) 2017年9月9日
JJUGナイトセミナーにて、古くて新しいJava ORMフレームワーク「Reladomo」の紹介をしてきました
ちょっと（かなり！）遅くなりましたが、7月26日のJJUGナイトセミナーで「Reladomo入門」の話をしてきました。 以前JJUG CCC 2017 Springでバイテンポラルデータについてお話ししたのですが、その際に紹介したORMフレームワークがReladomoです。
今回はそのReladomoの入門編で、当日のスライドはこちら。
www.slideshare.net
セッションで紹介した例はこちらのGitHubプロジェクトで公開しています。
Reladomoはゴールドマン・サックス社が開発し2016年にOSS化したJava ORMフレームワークです。一般に公開されているORMとしては非常に新しい部類に入りますが、実際には同社内では2004年から開発が行われている、枯れた技術になります。
当日は25分という非常に短いセッションだったのですが、前半では駆け足でReladomoの基本的な機能を紹介しました。純粋にORMとしての機能だけをみても、クエリをコード上で型安全に表現でき、高パフォーマンスを期待できる、非常に有用かつ便利なフレームワークです。
- Reladomoのコード生成
- Reladomoの検索・挿入・更新・削除処理
- Reladomoの関連
- GS Collectionsサポート
- ユニットテストサポート
また、最後に紹介したバイテンポラルモデルのセクションでは、前回JJUG CCCでは紹介できなかった関連を絡めた例を紹介しました。
- バイテンポラルモデル
世の中のWebシステムや業務システムにおいて、有効期間や履歴の概念を扱うことは非常に多い中、Reladomoはこれらの概念を自然に扱えるフレームワークとして非常に強力な味方になります。
たとえばPersonがPetという1対多の関連を持っているときに、下記のような状態を表現するのは通常のデータモデルでは非常に複雑になりますが、バイテンポラルデータモデルを使うと正しく容易に表現でき、検索することも容易です。
ある日時から別の状態へと遷移する履歴の表現
- 田中さんは1月1日時点ではペットを飼っていませんでした
- 田中さんは3月1日から犬のチビを飼い始めました
- 田中さんはさらに5月1日から猫のサクラを飼い始めました
ある日時における状態の検索
- 2月1日に田中さんが飼っていたペットの検索（なし）
- 3月2日に田中さんが飼っていたペットの検索（チビ）
- 5月2日に田中さんが飼っていたペットの検索（チビ、サクラ）
上記のような例を、スライドではp59 - p70、GitHubのコードではbi-temporalというモジュール内で例示しているので、実際のコードやデータを眺めてバイテンポラルモデルとReladomoの理解を深めていただけると幸いです。
今回のスライドとコードを参考にしてもらうと、Reladomo本家のKata（武道の型もしくは形の意味です）がわりとスムーズにできると思うので、ぜひお試しください！
そして、このReladomoをScalaで使うお話しをするのが、2017年9月9日に来たるScala関西 Summitでのセッション「Reladomo in Scala」になります。本セッションは、ScalikeJDBC や Skinny Framework でおなじみ瀬良さんとの共同セッションになります。興味のある方はぜひお越しの上セッションをご覧いただければと思います！！
JJUGナイトセミナーの当日の様子はこちらのTogetterからどうぞ。
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。
今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。
世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。
たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。
・社員が退職（・転属）する
・（売掛金の回収を諦めて）売上を打ち消す
・「お知らせメッセージ」を公開日がくるまで非表示にする
・既読メッセージを表示しない
・保存期間が過ぎたアンケート結果をオペレーターが見れなくする
これらの要件は、ほとんどがある状態の「有効時間」を適切に扱いたいだけであって、「削除」をしたいわけではないでしょう。スライドでは「履歴」という観点で例を説明していますが、「有効時間データモデル」は時間の経過とともに変化する状態の概念を適切に扱えるデータモデルなので、上記のような要件をフラグに頼らず扱うことができます。
今回のセッションでは「スナップショットデータモデル」、「トランザクション時間データモデル」、「有効時間データモデル」、「バイテンポラルデータモデル」という4種類のモデルを紹介しました。下記の方がおっしゃるように、これらの名前と概念を広めるだけでも世の中が少し幸せになるのではないかと考えています。ぜひスライドをご覧になってみてください。
このデータモデルの名前だけでももっと有名になるべきやね。名前がないとそれぞれのデータモデルを区別できないし。 #ccc_g3
— て＠JJUG CCCいいね！ (@tethon) 2017年5月20日
テンポラルデータモデルの実際の実装としてはJavaを使う方はぜひともReladomoを検討してみてほしいですね。とても良いフレームワークです。
JUnitでテストをパスしていきながら使用法を学ぶKataも提供されています。
現存するドキュメントではGuided Tour Of Reladomoが一番わかりやすいですが、英語です。今回、Java技術メモ三銃士のうちお二方が聴講しておられるのを把握したので、きっとそのうち素敵な日本語のメモが出てくるに違いないと信じております。
皆さんぜひ活用して周りに広めてみてください！
合わせて読みたい
かわしまさんが下記のスライドで紹介しているイミュータブルデータモデルの設計法と上記テンポラルデータモデルの設計法を合わせて適用すると、非常に堅牢かつ柔軟な設計ができると思います。ぜひご参照ください！！
株式会社FOLIOに入社しました & JJUG CCCで登壇します #jjug_ccc
itohiro73です。初ブログで入社エントリーです！
昨日2017年5月17日付で株式会社FOLIOにテックリードとして入社しました。FOLIOは「資産運用をバリアフリーに」の理念のもと、日本で約10年ぶりとなるネット証券をゼロからつくっていこうという、非常にエキサイティングな会社です。
証券バックエンドシステムの開発をリードしていく立場で働くことになります。
私はもともと約150年もの歴史をもつ大規模な外資系証券会社でエンジニアをしてきたので、UXを大切にするマインドを持ってデザイナー・エンジニアが主体となって証券会社をつくっていく、というのは非常に対照的で、ワクワクしております。
かなりダイナミックな環境でかつ急成長中なので、エンジニアの組織づくり、プロジェクトマネジメント、要件定義、設計、実装、運用と幅広く関わっていく予定です。
フロントエンドはReact + Node.js (BFF)、バックエンドはScala/Finatra/Finagleのマイクロサービス構成でつくっています。
モバイルアプリも本リリースに向けての開発に加わる仲間を絶賛募集中！iOSの開発はiOS/Swfit界の神エンジニア、Wantedly技術顧問の杉上さんに手伝ってもらっており、爆速で開発中！Androidサイドも先日モバイルアプリ開発エキスパート養成読本を出版したKotlin大好きふじたくと一緒に開発を進めていくことになります。時代の先端を行くモバイルエンジニアたちと一緒に次世代証券のアプリを創業メンバーとしてつくれるのは今だけ！
（ところでこれを書いている途中にKotlinがAndroid開発言語として公式サポートされることが発表されましたね。めでたい！）
各ポジションで絶賛エンジニア募集中ですので興味を持たれた方はぜひWantedlyからの応募をお待ちしております。
で、誰？
伊藤博志と申します。前職では外資系証券会社のテクノロジー部のエンジニアとして新卒入社より12年にわたってさまざまな仕事を経験させてもらいました。金融機関という会社の特性上、Web系のエンジニアさんと比べると外に見えるアウトプットは少なめです。なので、本ブログエントリーが初ブログになりますw とはいえ、前の会社は金融の会社としては世界的にみてもトップレベルでエンジニアリングに注力している会社で、最近は技術コミュニティに進出する機会も多く、とても素晴らしい会社でした。仕事としては12年もいるといろいろやってきたんですが、ブログで書ける内容としてはpublicに公表されている下記くらいでしょうか。
- 直近1年半ほどはEclipse Collectionsというオープンソースのコミッター兼プロジェクトリードを任されていました。もともと別名でリリースされていたプロダクトのリブランディングも含めてEclipse財団への移行、新規開発、Java 8への対応、JavaOneでの登壇やJava Day Tokyo、JJUG CCCの登壇等々いろいろやりました。この間にOpen JDKへのコントリビュートやソフトウェアの品質に関わる講演もしています。最近、自分のあずかり知らぬところでeFinancialCareersというところの記事で私の名前が紹介されていてちょっとビックリ。
- 仕事とは関係ないですが、JavaOne San FranciscoでNullPointersというバンドに参加しました。
前の会社では、ほぼすべてのシステムを自社のエンジニアで内製しているという、金融機関としては非常に珍しい施策をとっており、エンジニアとして非常に誇りの持てる職場でした。ビジネスに直接関わるシステムのみならず、上記のように純粋に技術的なライブラリやフレームワークも大量につくっており、今後もいろいろオープンに出してきてくれるといいな、と期待しております。エンジニアのキャリアとしても、マネジメントを突き詰めるキャリアとエンジニアリングを突き詰めるキャリアが並行して存在しいる素晴らしい会社で、今後、自分が組織設計をする際の羅針盤となる非常におおきな存在です。
技術コミュニティでの出会いとJJUG CCC登壇
上に書いたようにここ2、3年くらいJavaのコミュニティ界隈にぽつぽつと出没しており。JavaOneで登壇したり、関ジャバでEclipse Collectionsの話をしたりJJUG CCCでコード品質の話をしたりしてきました。
今回もJJUG CCC 2017 Spring (5月20日)に「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という題名で、#ccc_g4の枠でセッション登壇予定です！
技術コミュニティに出没する大きな理由は2つあって、もちろん上記のような技術知見の共有や情報収集が一つ目。二つ目はいろいろなエンジニアさんたちとの出会いですね。で、Javaコミュニティでいろいろお世話になったひとりで、Java女子部部長として活躍されていて、お仕事ではScalaを書かれていて英語もできるよこなさんは注目エンジニアのひとりでした。そんなよこなさんとScalaMatsuriでばったりお会いしたのですが、なんとこのタイミングで東京に帰ってきている（もともと京都にいた）とのことだったので、FOLIOにお誘いしたところ、非常に興味を持ってもらいこの度めでたくジョイン。私より早く入社しましたw
こういう出会いもいろいろあると思うので、今回のJJUG CCCも非常に楽しみにしております。JJUGにはScala書ける人もたくさんいますしね！
Reladomoとは
JJUG CCCで紹介予定のReladomoですが、ほとんどの方はご存じないと思います。本ブログでも少しづつご紹介していこうと思いますが、2016年の秋にGoldman Sachs社がOSSとして公開した、JavaのORMフレームワークです。
金融機関でクリティカルとなる、データの履歴管理に長けたORMフレームワークで、金融機関以外でも非常に有用だと思うので、ぜひJava界隈・JVM言語界隈の皆さんに知っていただきたいです。
JJUG CCCのセッションでは、まずはバイテンポラルデータモデルという履歴を扱うデータモデルのコンセプトを解説し、具体的な実装例としてReladomoでの履歴の扱い方等を紹介する予定です。
ReladomoのドキュメントとしてはGuided Tour Of Reladomoが一番わかりやすいと思います。とりあえず手を動かしてみたいという方は、チュートリアルであるReladomo KataがGitHubで公開されているので、これを解いてみるのがてっとり早いです。
この度ジョインしたFOLIOでもしっかり使っていきたいので、今後Scalaから使用するための知見等も共有していきたいと思っています。
どうぞよろしくお願いいたします！
