【第一回】経費申請のフローで学ぶCamundaの基本（導入編）
Camundaとはオープンソースのワークフロー&ビジネスプロセスマネジメントの総合プラットフォームで、BPMN2.0、CMMN1.1、DMN1.1に準拠したモデリングや実行環境を構築することができます。
JJUG CCC Fall 2017では世界的な証券会社であるゴールドマン・サックス社においてもCamundaを利用してビジネスプロセスの可視化や自動化を行なっているという講演がありました。
現状Camundaに関する日本語の情報はほとんど見当たらない状況で、アドカレの記事でも書いたように自社での導入検証もしていければとも考えているので、せっかくなのでオープンな形で技術検証をしていきたいと思います。
今回、下記のような連載形式で、「経費申請」という比較的簡単な業務フローをテーマに、Camundaを用いたモデリングとワークフロー実装の基本を学んでいきたいと思います。
実際に業務要件をモデリングするような流れでひとつのアプリケーションを作成していこうと考えているので、網羅的に機能を解説していくというよりは、「Camundaを使うと何ができるのか？」を全体を通してイメージできるようになることを目的としています。
（下の流れはあくまで予定）
- 【第一回】経費申請のフローで学ぶCamundaの基本（導入編）
- 【第二回】経費申請のフローで学ぶCamundaの基本（BPMNモデリング編）
- 【第三回】経費申請のフローで学ぶCamundaの基本（BPMN実行編）
- 【第四回】経費申請のフローで学ぶCamundaの基本（DMN編）
- 【第五回】経費申請のフローで学ぶCamundaの基本（CMMN編）
- 【第六回】経費申請のフローで学ぶCamundaの基本（テスト編）
- 【第七回】経費申請のフローで学ぶCamundaの基本（まとめ）
本エントリーでは導入編として、モデリングツールであるCamunda Modelerのインストールと、Camundaの実行環境をSpring Boot上に構築してみます。
連載を通して基本的に下記の環境にて動作確認をしていますが、他のOSやJavaバージョンでもほとんど差異はないものと思います（おそらく）。もし何か気付いた点などありましたらブログへのコメントやGitHubへのプルリクをいただけると幸いです。
Mac OS High Sierra: Version 10.13.2 Java 9 Gradle 4.2.1 Spring Boot 1.5.9-RELEASE Camunda 7.7 Camunda Spring Boot Starter 2.2
Camunda Modelerのインストール
Camunda ModelerはCamundaのワークフローエンジン上で実行することができるBPMN/CMMN/DMNのモデリングツールです。各モデリング記法の目的やモデリング、実行方法は第二回以降の記事で少しずつ学んでいければと思います。
Camunda Modelerのインストールに関しては非常に簡単で、こちらのダウンロードページから対応するOSのバイナリをダウンロードして、実行ファイルを実行するだけです。
https://camunda.com/download/modeler/
次のエントリーではBPMNのモデリングをしてみる予定なので、まずは「BPMN diagram」をクリックしてみましょう。
BPMNのモデリングの画面が立ち上がりました。Camunda Modelerに関してはこれで準備完了です！
Spring Boot上でCamundaの実行環境を構築
Spring Boot上のCamunda実行環境をGradleで構築します。CamundaのSpring Boot StarterはこちらのGitHubで提供されています。最小構成のbuild.gradleはこんな感じ。
build.gradle
buildscript {
ext {
camundaVersion = '7.7.0'
springBootVersion = '1.5.9.RELEASE'
camundaSpringBootVersion = '2.2.0'
}
repositories {
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
classpath "io.spring.gradle:dependency-management-plugin:1.0.4.RELEASE"
}
}
apply plugin: 'java'
apply plugin: 'org.springframework.boot'
apply plugin: "io.spring.dependency-management"
group = 'sample'
version = '0.0.1-SNAPSHOT'
repositories {
mavenCentral()
}
dependencyManagement {
imports {
mavenBom "org.camunda.bpm:camunda-bom:${camundaVersion}"
mavenBom "org.springframework.boot:spring-boot-dependencies:${springBootVersion}"
mavenBom "org.camunda.bpm.extension.springboot:camunda-bpm-spring-boot-starter-bom:${camundaSpringBootVersion}"
}
}
dependencies {
compile('org.camunda.bpm.extension.springboot:camunda-bpm-spring-boot-starter-webapp')
compile('com.h2database:h2')
testCompile('org.springframework.boot:spring-boot-starter-test')
if(JavaVersion.current() == JavaVersion.VERSION_1_9) {
runtime('javax.xml.bind:jaxb-api:2.3.0')
}
}
最小構成のアプリケーションコードはこんな感じ。 src/main/java/sample/CamundaExpenseProcessApplication.java
package sample;
import org.camunda.bpm.spring.boot.starter.annotation.EnableProcessApplication;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
@EnableProcessApplication
public class CamundaExpenseProcessApplication {
public static void main(String[] args) {
SpringApplication.run(CamundaExpenseProcessApplication.class, args);
}
}
Camundaが使うデータベースをin-memoryのh2に設定するために、application.propertiesを作成します。下記の設定ではメモリー上のh2データベースを使用するのでアプリケーションを立ち上げなおすたびに情報はリセットされます。もし情報を永続化しておきたい場合はspring.datasource.url=jdbc:h2:mem:camundaをコメントアウトして代わりにspring.datasource.url=jdbc:h2:~/camunda;DB_CLOSE_ON_EXIT=falseを有効にしてください。
src/main/resources/application.properties
spring.datasource.url=jdbc:h2:mem:camunda #Use this config in case you want to persist camunda data into file system (comment the config above in that case) #spring.datasource.url=jdbc:h2:~/camunda;DB_CLOSE_ON_EXIT=false
デフォルトの設定として、デモユーザー（id/password = demo/demo）と、すべてのタスクを表示するfilterをapplication.ymlを追加しておきます。
src/main/resources/application.yml
camunda.bpm:
admin-user:
id: demo
password: demo
firstName: デモ
lastName: ユーザー
filter:
create: All tasks
以上で最小限構成のCamundaアプリケーションが立ち上がる状態になりました。GitHubに動作確認済みのプロジェクトを上げてあるのでこちらからどうぞ。
https://github.com/itohiro73/camunda-expense-example/tree/1-intro
GradleでSpring Bootアプリケーションを立ち上げます。
$ gradle bootRun
立ち上がったら http://localhost:8080/ にアクセスすると、下のような ログイン画面が立ち上がります。
上記で設定したデフォルトのデモユーザー（demo/demo）を使用してログインしてみます。
これでCamundaが立ち上がりました。トップ画面からはCockpit、Taslklist、Adminの機能にアクセスすることができます。
この時点ではまだワークフローをデプロイしていないのでCockpit上では何もできませんが、TasklistやAdminの基本的な機能は動くのでポチポチ遊んでみてもいいかもしれません。
以上でCamundaの準備は完了です！
第一回まとめ
今回は導入編として
- Camunda Modelerのインストール
- Gradle/Camunda Spring Boot Starterを用いた環境構築とCamundaアプリケーションの起動
新卒から12年エンジニアとして勤めた某外資証券会社を辞めてスタートアップにジョインした話
本記事は退職者その2 Advent Calendar 2017の25日目の記事です。
僭越ながら最終日を担当させていただきます、@itohiro73 と申します、よろしくお願いします。
半年前ちょっと前にすでに入社エントリーは書いているので順序が大幅に逆になってしまっていますが、今回は退職者アドベントカレンダーということで、せっかくの機会なので新卒から12年も勤めた前の会社のことを振り返ってみようと思います。
前の会社について
世界的にもかなり大きい外資系証券会社でエンジニアとして新卒から入社して12年と1ヶ月半くらい勤めました。会社名に関しては、自分がかなり大々的にOSS活動等もしていたこともあり公開情報からちょっと調べればわかるところではありますし、本記事を読んで明らかにわかる部分もあります。とくに隠しているわけではないのですが、一応大人の事情としてあえて言及はしないといったところです。
なぜ外資系証券会社に「エンジニア」で新卒入社？
よく、新卒で外資系証券会社の「エンジニア」という選択肢をどうしてとったのかとよく聞かれます。
（余談ですが12年くらい前は「エンジニア」ってあんまり呼ばれていなかった気がしていて、同様の職種は日本だとプログラマー、海外（社内）だとdeveloperと呼ばれるのが普通でした。いつのころからかエンジニア/engineerが定着しましたね。ということで当時的にはdeveloperとしての新卒入社です。）
外資系証券会社というと、投資銀行部門のバンカーであったり、トレーダーやセールス、アナリスト等のいわゆる「フロントオフィス」の職種が花形であるとされています。
そんななかで、なんでエンジニア？っていうのが外資系証券会社をよく知る人たちにとっての疑問なのでしょう。逆にエンジニア系の人たちにとっては、（今でこそFinTechが盛り上がりを見せているものの）そもそも金融であったり証券に興味がない人が多いため、SIやWeb系企業ではなくなぜ外資証券？っていうのが疑問なんだと思います。
実際当時の私にとっては、外資証券に興味があったわけでは特になく、いわゆる就職活動によくある自己分析というやつで下のような3つの軸を求めてました。
- 自分で手をうごかしてものづくりをしたい
- 自分がつくったものを実際につかってくれるユーザーの側で働きたい（フィードバックを直に受けたい）
- インターナショナルで多様な環境で働いてみたい
この軸に沿っていてくれさえすればいいと思っていたものの、当時この3つすべてを満たすような会社は自分が調べた範囲内ではほとんど存在していませんでした。
そんな中バイト先で一緒に働いていた大学の同期が、〇〇っていう会社の選考を受けてきた〜っていう話を聞いたのがこの外資証券の会社でした。へぇーそんな会社があるんだと思ってリクナビから会社ホームページを調べたりいろんな口コミページ的なのをを眺めて見たら、「社内で使われているほとんどのトレーディングシステムや業務システムが内製化されている」「チームワークを重要視するカルチャー」「外資系企業で、多様性を重視、さまざまなバックグランドの人が働いている」というような文言がならんでいるじゃないですか。まさに上の3つの軸を満たしていそうで、「自分が求めているものにすごくしっくりくる、ここしかないんじゃないかー」、と思って早速エントリーしたのがすべての始まりです。
実際、就職活動中にお話を聞いた先輩社員の方達は皆ものすごく魅力的で、最高に輝いて見えました。その中には現在bitFlyerでCEOをされている加納さんもいました。こんなすごい人たちと一緒に働けるのであれば最高に楽しいだろうなと考え、全力で選考に挑んだところ、ご縁があって採用していただけました。
最初の「外資系証券会社でなぜエンジニア？」という疑問ですが、実際蓋を開けてみると、全世界で3万数千人いる社員のうちの約4分の1、つまり8~9000人のオーダーでエンジニアが働いています。この人員だけでITの大企業がつくれてしまう規模感です。それほどまでにエンジニアリングに力をいれている環境で、世界中の優秀なエンジニアと切磋琢磨しながら証券会社という複雑怪奇なビジネスをつくりあげていく。こんな最高に面白い環境は今考えても他になかったとおもいます。実際エンジニアとして最初の12年のキャリアを積むのにはこれ以上ない環境だったと感じていますし、今でもこの会社のことは大好きです。
前の会社のカルチャーと強み
ここの会社の一番好きなカルチャーは、スーパースター個人個人に頼るような仕事の進め方はせず、チームワークを最重要視するところ。チームとして最高のパフォーマンスを出すために皆がそれぞれ自分のチームの中での役割をしっかりこなす。"I did this"ではなく"We did this"と言うのが美徳とされる、そんなカルチャーでした。
このカルチャーはチームレベルではなく、会社全体の特性としても現れていました。よく「世界最強の投資銀行」などと評される会社でしたが、特定の部門が最強だったわけではありません。投資銀行のバンカー、トレーダー、セールス、アナリスト、コントローラーズ、オペレーションズ、コンプライアンス、テクノロジー、人事から総務や広報にいたるまで、すべての部門でそれぞれ最高のパフォーマンスを出し、部門間でのチームワークを発揮することで会社として世界最強の名をものにすることができていたのではないかと、自分は12年働いてきた中でそう感じています。
会社の外でよく聞く評判では、イカつい人が働いてそうとかガツガツしてそうとか怖そうとか言われるんですが、実際そんなことはなくて、一緒に働く人みなものすごく温和でやさしくて非常に人間味あふれる人たちでした。
さらにすごいのは、このカルチャーがグローバルで、しかも偉い人から新人まで一貫しているというところ。グローバルで数万人規模の大企業であるにも関わらず、日本で働いていてもニューヨークに出張してもインドに出張しても、香港やシンガポールの人たちとリモートで働いていても、常にアットホーム感あふれるものすごく暖かいチームワークを常に感じていました。
そしてもうひとつ一貫していたのが、皆一様にものすごく負けず嫌いであるというところ。「温和」と「負けず嫌い」って相反する概念じゃ無い？って思うかもしれませんが、これは本当に面白いんですが、このふたつの性質は同居できるんですね。フロントオフィスの人たちはわかりやすく勝ちにこだわって攻めて行くという意味での負けず嫌い。バックオフィスの人たちは絶対に負けない戦略をじっくり練って守って行くという意味での負けず嫌い。温和でやさしいけど皆さん芯がしっかりしてるんです。
マイノリティであり、多様性の一部であるということ
この会社に入って一番のカルチャーショックだったと言えるのは、「日本人であることがマイノリティである」ということに気付かされたことでした。
この会社の東京オフィスでは、なんと「日本人のためのコミュニティ」というものがが存在します。東京にいるのに日本人のためってどういうこと？と思うかもしれません。私の例をとってみれば、東京オフィスでのテクノロジー部の新卒同期は9人。そのうち日本人は4人だけです。グローバルでみるとテクノロジー部新卒同期全体で240人ほど、他のオフィスでの日本人採用はゼロだったので、同期の仲間たちでも日本人であるということは全体の2％にも満たない、相当なマイノリティです。
ではこの「日本人のためのコミュニティ」（Fuji Committeeという名で呼ばれていました）は何をするために存在するのでしょうか。日本人は、実は自分たちでは普段意識していないような日本人特有の性質を平均的に持っています。たとえば、コミュニケーションのとり方がハイコンテクストであったり、同調意識が働いて他の人と違う意見を自分の中にためこみがちだったりだとか、単純に英語が得意でないとか。あとは欧米人が比較的得意なアクティブな議論の場で発言するのが難しいと感じたりだとか、「自分の意見を表明しない」という認識を周りに持たれがちだったりとか、グローバルな環境で働いている日本人たちにとっては「あるある」的な話が山ほどあります。
このFuji Committeeでは、こういった自分たちの性質に関する気づきを得たりだとか、それぞれが抱えている悩みを共有したり、その問題について議論したり、日本人がグローバルに活躍してキャリア形成を促進して行くにはどうしたらいいか、といった話をする場でした。また、シニアなメンバーが自分の培ってきたキャリアについて話す場を設けてくれて、彼らが抱えていた悩みやコンプレックス、それらをどうやって解決してきたかを赤裸々に語ってくれたりしました。自分がまだジュニアだった頃には、自分にとって凄い神のような存在である彼らが、自分と同じような悩みをかかえていて解消してきたんだという話は、とても親近感を持てますし、安心感と勇気を与えられました。
この経験からも、自分が比較的シニアになってからも、自分がかつて抱えていた仕事上の悩みやコンプレックスをジュニアなメンバーたちと正直かつ素直に共有するようになりました。
このようなある属性にフォーカスしたコミュニティは、日本人向けのものだけではなく、黒人やヒスパニック、LGBTやWIT（Women In Technology）などの様々なコミュニティが存在していました。それぞれのコミュニティで特有の悩み共有や問題解決をおこなって行くことで、それぞれの属性をもつグループが最高のパフォーマンスを出せるように改善していき、結果として会社全体への強みへと昇華して行く。このように多様性を重視して、それぞれの強みを最大限活用できるようにしていくカルチャーの大切さというのは、自分がマイノリティであることを認識してはじめて身にしみて感じました。この会社で働いて初めて、どんな人であっても多様性を構成する一部である、そんなあたりまえのことを大きな気づきとして得られた気がします。
前の会社のエンジニアリングについて
前の会社では、「コントローラーズ」と呼ばれる、トレーダーの損益を日々モニターしてリスク管理やレポーティングをする職種の人たちが日々使うアプリケーションの設計・開発・テスト・運用に関わりながら最初の10年間のキャリアを過ごしました。アナリストからアソシエイト、ヴァイスプレジデントと昇進を重ね、エンジニアとしてはジュニアデベロッパーからプロジェクトマネージャー、QAのグローバルコーディネーション、テクニカルアーキテクトと呼ばれるアプリケーションチームの技術面を支える仕事まで様々なレイヤーを経験しました。キャリアのほとんどをここのチームで過ごしたので、実はここで学んだことや経験したことが自分のエンジニアリング哲学を形成する大部分になるんですが、残念ながら会社の機密に関わる仕事が多かったため、ほとんど語ることができません（汗）
代わりに、最後の2年ほどを過ごしたプラットフォームチーム、そのなかでもOSS活動について語って見たいと思います。プラットフォームチームとは、アプリケーション開発とインフラのちょうど間くらいに位置するチームで、開発者たちが日々使うアプリケーション（たとえばSoftware Development Life Cycleのなかで重要な位置を閉めるコードレビューやビルド、リリースのプラットフォームであったり、各言語のライブラリやフレームワーク、テストのためのプラットフォーム、ジョブスケジューラー、ワークフローエンジン等々多岐に渡ります）を開発していました。ここは純粋に技術的なチームだったため、会社のビジネス業務に直接関わる機密的な話はほとんどなく、比較的表に出しやすい内容なのです。
Eclipse Collections秘話
その中でも、Eclipse Collectionsと呼ばれるJavaのコレクションフレームワークは私にものすごく関わりが深い技術で、かつOSSで公表されている技術なのでブログに記載することに何の問題もありませんw
コレクションフレームワーク誕生
このフレームワークは、もともと Donald Raab というエンジニアがコントローラーズのテクノロジーチームでCaramelという名で開発を始め、そのあと社内で広く使われるようになりました。上記の通り私もコントローラーズのチームで働いていたので、このフレームワークは当初からユーザーとして使用していました。Javaのコレクションフレームワークとしては相当使いやすい実装でかつパフォーマンスも良く、同僚たちとは「Javaに標準で入るのはいつだ」なんて冗談をよく言っていました。2012年に同社初のOSSとして公表された際は社内の皆でものすごく興奮した覚えがあります。
拡散と認知
2014年にはJavaOneで初めてDonald Raab がキーノートに登壇し、同フレームワークのセッション発表もされたことで、世界的に知られるようになりました。これを知った私はものすごく興奮し、日本でもこのフレームワークの認知を広げたいと考え、日本のJavaコミュニティへの進出の機会を探り始めました。JJUG CCC 2014 Fallに始めて参加した際に、JJUG会長の鈴木さんとお話ししたところ、驚いたことにJavaOneキーノートでの発表を見てくださっていたようで、日本支社の誰かとコンタクトを取りたいと思っていた、とのことでした。そこからはあれよあれよという間に話が進み、2015年Java Day Tokyoでの同社での初登壇が実現しました。その直後にはJJUG CCC 2015 Springでもセッションをすることができ、コミュニティによる情報拡散の手助けにより、このフレームワークは日本で一気に知名度を上げます。
この頃のコミュニティ活動は完全に社内での同フレームワークの1ユーザーとしてのボランティア活動であり、別に担当していた本業のかたわらやっていました。もともと日本では同フレームワークの開発チームはいなかったのですが、業務のかたわらちょいちょいコントリビュートを送るようにしたり、東京チームで興味のあるエンジニアにもコントリビュートを勧めたりしていました。
NYからの電話
そんな2015年夏のある日、ニューヨークから自分のデスクに一本の電話がかかってきました。
電話の主は上述の Donald Raab 、同フレームワークの創始者でありプロジェクトマネジャーです。ニューヨークのマネージングディレクターなのでめっちゃ偉い人。面識はあったものの、直属の上司ではなかったので電話で話したことはほとんどありません。いったい何の要件かと聞いてみると、
「今度同フレームワークをEclipse Foundationに移管するんだが、このプロジェクトリードをお前に任せたい。日本のお前のボスに相談しようと思うんだが、どう思う？」
と言うのです！ぶったまげましたが、同時に体の芯が震えるほど喜びました。同フレームワークはそれまで、会社内のsvnで開発・管理されているコードが社内でリリースされ、リリース時のコードのスナップショットのみがGitHubにアップロードされていると言う状態でした。つまり、GitHub上にソースコードは公開されているものの、外部からのコントリビュートを受け付けることができなかったのです。これでは完全なOSSとは言えません。Eclipse Foundationへの移管によりこの問題を解消し、完全に外部での開発ライフサイクルにのせてOSS化するというのが本プロジェクトのゴールです。
実はこの時点でUS以外での同フレームワークダウンロード数は日本がダントツ1位で、大きなユーザー数を占めていました。これはまさに上述した日本でのコミュニティ活動での成果であり、この功績を買われて白羽の矢がたったのです。
Eclipse Foundation移管と"Eclipse Collections"誕生
当然ふたつ返事でプロジェクトのリードを引き受けました。実際の移管プロジェクトでは、最新バージョンの機能開発はもちろん、同フレームワークのパッケージネーム変換から、Eclipse Foundationの開発フローに法ったワークフロー整備やツールの整備、法的書類のフォローアップなど、技術的・非技術的なチャレンジがさまざまありました。自分以外のプロジェクトメンバーは全員ニューヨーク在住、そしてEclipse Foundation本部はカナダのオタワにあるので時差の問題も大きく、電話ミーティングでのフォローアップも大変でした。2015年のJavaOneではDon Raabと共同で本件についての発表を行い（JJUG CCC 2015 Fallで発表された日本語版の同内容の資料はこちら）、2015年12月に無事移管リリースを迎えます。"Eclipse Collections"誕生の瞬間です。
当然OSSだけでは会社のビジネスに直結するわけではないので、移管リリース終了後は本業のプロジェクトも進めつつのOSS業をこなしていました。
紆余曲折を経てのEclipse Collections OSSリリースでしたが、今では開発者以外によるコミュニティでの発表も見られたりと、非常に裾野が広くなってきており、非常に喜ばしい限りです。
OSSとブランディング
こういったOSS活動は会社のブランディングとしての側面も大きいです。ここでいうブランディングは大きく2つの意味合いがあります。まず一つ目は、社外のエンジニア達に会社に興味を持ってもらうこと。つまり、会社がOSSを使うだけではなく、OSSを開発して発信することでコミュニティへの還元をしている、それくらい技術にコミットしているのだということを知ってもらうことです。もう一つは、社内のエンジニア達の士気をあげること。自分たちの会社はOSSにコミットするくらいエンジニアリングに対して本気なんだということを理解してもらい、そしてOSSという皆が平等に貢献できる土壌をつくることで、社内エンジニアリングの士気を上げて行く、空気感をつくることです。
こういった土壌はWeb系の企業だとわりと普通かつ自然に培われるものかもしれませんが、世界的な大企業であり金融機関、という環境でこのムーブメントをゼロから起こすのは相当な情熱（Passion）、忍耐力（Patience）とやり続けること（Persistence）が必要です。この3つのPは私が Eclipse Collectionsの創始者である Donald Raabから学んだ大切な哲学です。
彼は実際2004年からEclipse Collectionsのもととなるライブラリを作り始め、2012年に初めてソースコード公開、そして2015年についに会社外からもコントリビュータを受け入れられる完全なOSSとしてEclipse Foundationへの移管を完了しました（私が任されたEclipse Foundation移管のプロジェクトはこれです）。そしてDonは今現在もひきつづき同フレームワークをJavaの標準ライブラリとして取り込むための活動を続けています。これらの成果はまさに彼の情熱（Passion）、忍耐力（Patience）とやり続けること（Persistence）の賜物と言えると思います。
このOSS活動で学んだエンジニアブランディングにまつわる経験は現職でも生かされていて、現在の会社であるFOLIOで一緒にクリエーターブランディングに注力してくれているよこなさん @ihcomega のFOLIOアドカレ第一日目にもその辺の話題が書かれています。
退職直前のこと
この会社には社内SNSがあったんですが、私もそれなりに投稿してました。いわゆる社内ブログとか呟きみたいのの影響力（like数とか、コメントの数とか、投稿数とか）によってポイントランクみたいのがあって、退社直前についに8000人中の20位内に入り込みました。20位以内だとリストの一番最初のページにプロフィールが表示されるので、やめる直前でトップページに食い込めて喜んだ覚えがあります。この社内SNSのおかげで会ったことないけど私のこと知ってくれている人は世界の各オフィスに結構いて、それなりにグローバルにも影響力あったと思います。ただ、これに関しては完全に私のボスだった Donald Raab のおかげであり、彼がいなければOSSのプロジェクトリードをまかされることもなかったし、社内外に影響のあるプロジェクトを任されることもなかったと思います。彼は私のキャリアのなかで最も尊敬する人物のひとりで、技術的にもマインド的にも彼から学んだことの大きさは計り知れないです。
なぜ辞めたのか
めちゃめちゃ良さそうな会社なのに、なんで辞めたの？と疑問に思うかと思います。実際今でもこの会社のことはすごく好きですし、未だに動向はウォッチしています。
150年ほども歴史があるグローバルな会社で、仕事も楽しく待遇も良く福利厚生も良い、本当に至れり尽くせりのとても良い会社でした。とはいえ、これだけの長い歴史の中で、いろんな人たちが作り上げてきた会社、ということを肌で感じる中で、自分はただそのおこぼれを享受しているだけなのではないか、というのがここ数年のもやもや感でした。もし可能であれば、自分でもこんな素晴らしい会社・組織をつくってみたい、何よりもエンジニアが本気で活躍できるような組織や土壌というものを自分の手でつくりあげてみたい、ということをすごく考えるようになりました。
また、ここ数年日本の技術コミュニティに顔を出すようになり、日本のエンジニアたちの強さ、凄さを目の当たりにする機会が増えました。それとは裏腹に、グローバルと比較した際の日本のエンジニアたちの待遇の低さというのもよく嘆かれています。日本で埋もれているような優秀なエンジニアたちが思う存分実力を発揮して、その実力を適切な待遇で評価される、そして彼ら彼女らがグローバルで活躍できるような土壌をつくる、そんなエンジニア組織を自分でつくれたらいいなと考えていました。
そんな中FOLIOという面白い会社と出会いました。この会社と出会った当時はまだ創業1年そこそこで、社員数20数人ほどのできたてほやほやのスタートアップです。代表の甲斐もクリエーター（デザイナー＋エンジニアをあわせてFOLIOではクリエーターと呼んでいます）を非常に大事にしており、次世代証券会社、そして今までの常識をくつがえすような金融プラットフォームをこのチームでつくりあげて行くんだという、そのマインドがものすごく気に入りました。エンジニアたちとも話がめちゃめちゃ盛り上がり、自分の次のキャリアを積むのはここしかないと考えました。なんせ、次世代証券会社をビジネス陣・クリエーター陣で協力してゼロからつくりあげてしまおうというスタートアップなので、私がやりたいと思っていたことにどハマりなのです。
このFOLIOが持っている多様性はFOLIO Advent Calendar 2017を見てもらえばわかると思います。現在ではクリエーター陣だけで30数人（全社では60人ほど）の組織になっていますが、その担当範囲やバックグラウンドは多種多様です。証券会社をつくるクリエーターとして、それぞれが自分のプロフェッショナリズムを発揮して仕事をしています。
そして、FOLIO Advent Calendar 2017では「株式会社FOLIOの次世代証券システムをひもとく」と題して本日の最終記事を担当したのですが、当記事でも述べたように次世代証券会社のシステムをつくりあげていくにはまだまだやることが山積みであり、とてもチャレンジングなさまざまなプロジェクトがわれわれを今後待ち受けています。
締め
以上、わりとエモい感じで前職の会社のお話と5月にジョインしたFOLIOのお話を書き連ねました。まだまだ書き足りないことはいっぱいあったんですが、さすがに長すぎると自粛しました。楽しんでいただけたら幸いです。
株式会社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から使用するための知見等も共有していきたいと思っています。
どうぞよろしくお願いいたします！
