たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

「青銀行の勘定系をFirebase前提で構築できるか？」

フロントエンド
Firebaseについて、事前知識
 
Firebaseとは、以下のような機能群を「Serverless」の文脈でバンドルしたものである。「Serverless」として、これらの統合管理コンソールの出来栄えが秀逸。
 
- Firestore ... Document-oriented KVS
- Cloud Functions ... AWSのLambda
- Cloud Storage ... AWSのS3
- Hosting ... Web Assetsのデプロイ先の提供、CDN展開サポート
- Authentication ... ユーザー管理・統合認証サービスの提供
- Cloud Messaging ... iOS/Android/Web(JS)クライアントアプリへの統合プッシュ通知サービス
- その他
 
いうまでもなく「Serverless」とは「サーバー運用・管理レス」の意味。まさに「サーバー運用・管理レス」の観点において、優れた統合管理コンソールが提供されている。加えて、BaaSとして、認証機構やプッシュ通知機構が作り込まれている。
 
私がFirebaseに関心を持ったのは、かの中島聡氏が次のようなTweetをしていたから。
 
"中島聡氏（@snakajima）によるFirebaseについてのツイートピックアップ":
 
しかし中島氏の一連のツイートをみても、それでもなお、私は次のように思っていた。
 
「フロントエンド開発者」にとって「便利になった」のはわかった。「サーバー運用・管理レス」の観点にて、管理コンソールの出来栄えの良さや「スケーラビリティへの対応レディ」なことも分かった。確かに「今までバックエンド開発者が担っていた仕事のいくつか」は無用となるだろう。それでもなお、「バックエンド開発者」の立ち位置から見て、「仕事が丸ごと無くなる」といった可能性を含む、何か根本的な変革が予想されるのだろうか？（無いんじゃ無いか？）
 
「バックエンド開発者」から見ると便利なだけかもしれないが、「フロントエンド開発者」から見ると「サーバーサイドという*詳細*」からの解放に見える
 
その後、Twitter上で「フロントエンド開発者」の以下のような見解を複数散見した。
 
(a) Firebaseがあれば、全てフロントエンドが吸収する／できる。バックエンドは不要となる。
(b) バックエンド開発者がFirebaseを理解しないのは、フロントエンド開発者には見えている未来を、自分の現在の立ち位置に固執して、見ようとしないから。
(c) Firebaseへのロックインを厭わなければ、Clean Architectureの言うような重厚な論理構造は不要となる。
 
◆注意◆
上記のような表現そのものが個別にあったわけではありません。前後左右の文脈踏まえて私が解釈・意訳したものです。ですので、根本的にここの解釈・意訳がミスっている可能性があることは念頭においてください。
 
これらの見解をみるに、とにかく「目線の違い」自体は明らかに存在しそうである。中島氏の一連のツイートを見た時点では、あくまで「「バックエンド開発者」として、Firebaseにどう接するべきか」といった目線感で見ていた。「フロントエンド開発者」の上記のような見解がどこから来るのか理解するために、今度は「フロントエンド開発者」の立場の目線感を持つことを意識しつつ、改めてFirebaseを見てみた。
 
※なお、上記見解(c)は少々論点が異なるので、本記事では扱わず、別途。
 
・
 
そうして気付けたことがあった。「バックエンド開発者」の目線からはやはりあくまで「便利になった」範囲なのである。ところが、これを「フロントエンド開発者」目線で見ると確かに違う風景となる。今までは、DBアクセスしたかったら、都度都度バックエンド開発者の手を借りて、アクセスAPIの開発・運用をしてもらわないとならなかった。ところがFirebaseがあれば、その圧倒的なEasy-to-Use性とクライアント・ライブラリーのおかげで、フロントエンド開発者は、DBやファイル・ストレージへのアクセス機能の開発と、それらのサーバー機能の運用を、バックエンド開発者の手を借りずに、実現できてしまうのだ。
 
「フロントエンド」、「バックエンド」と言った"曖昧な"用語を用いずに言い直してみる。
 
JavaScript関連技術を習得しているが、しかしNginxやApacheや、あるいはPHPやRoR、あるいはMySQLの技術を習得していない者でも、もしくはこれらの技術に煩わされずに、サーバーサイドの永続化装置へのアクセス機能の開発・運用を実現できるようなプラットフォーム
 
もう一段言い直す。
 
「Webサービス」を開発・運用するときに、もはやNginx、Apache、PHP、RoR、MySQLなどサーバーサイドの個々の要素技術に煩わされずに、JavaScript等フロントエンド関連技術だけで開発・運用できる。
 
「バックエンド開発者」から見るとEasy-to-Use性以外のエッセンスが見えない一方、「フロントエンド開発者」から見ると、「バックエンド（開発者）から解放された」と見える！マーケティング・フレーズとしては、「DBアクセスAPI開発やサーバー運用などの詳細に煩わされずに、（フロントエンド）アプリ開発に集中できます。」となる。
 
これがFirebaseの本質だと理解した。
 
Firebaseは「青銀行の勘定系」を動かせるか？
 
前節で示したような「「フロントエンド開発者」の目線からみた世界観」に、「バックエンド開発者」の立場として、異なる一つの立場として理解できる部分と、いやでも何かが違うと思う部分があった。
 
少なくとも、「今までよりも、フロントエンド側にシステム開発市場の重心が移動する」ことは確かだとは思っている。類似の動きがかつてあった。想起したのは、20〜30年前くらいの「ダウンサイジング」と呼ばれた一連のムーブメントである。「ダウンサイジング」とは、技術マーケットの基軸となるプラットフォームが、「メインフレーム」から「オープン系」へ移行していくという現象だった。伴って、システム開発市場におけるボリュームゾーンも、「メインフレーム上のCOBOL」から、「Windows上のC/C++」や「Unix上のJava」などに移行していった。おそらく今、「サーバーレス」というムーブメントにおいて、SoE領域の市場が膨張するに伴って、「Unix上のRoR」や「Unix上のJava」から「Firebase上のJavaScript」などへの重心移動が進行しているのであろう。そのことは確かだと思っている。（ただし、「ダウンサイジング」ではプロプライエタリ→オープン、「サーバーレス」ではオープン→プロプライエタリと、方向性は逆である。）
 
・
 
さて、「フロントエンド開発者」が見ている「もはやバックエンドは不要」という世界観に対する、半分は理解できるのだが、何かが納得できない感じ。この点を明らかにするのに、一つあえて極端なシナリオを持ち出して、その可能性について思考実験すると何かわかるのではないかと考えた。
 
 
日経コンピュータの記事によると、この度の青銀行の勘定系刷新プロジェクトでは、積極的にCOBOL/メインフレームを残すと判断したサブシステムがあるという。ダウンサイジングの波を越えて、COBOL/メインフレームがよい、と判断されたサブシステムがあるわけである。このような基幹中の基幹を、Firebase前提で構築するとしたら、どうなるだろうか？
 

 
いくつかご意見もいただけた。
 
 
※もちろん、私をフォローいただいてる方中心なので、フロントエンド領域の方へのリーチが薄いことは適宜要補正である。
 
上記まとめ公開後、はてブにもたくさんコメントいただけた。
 
 
私自身、勘定系が実装できるか、という目線でFirebase、特に中核となるデータベースFirestoreについて、公式ドキュメントなどを調べた。気になった点が下記である。
 
・十進数型（※MySQLのDECIMAL、JavaのBigDecimal、SwiftのDecimal相当の型）が無かった。
・ACIDトランザクションは、「リトライ付き楽観ロック」で実現されている様子。この「リトライ付き楽観ロック」で、複数DocumentをACIDに更新できる様子ではある。
・排他ロックは無い様子だった。
 
十進数型のサポートが無いのは当然辛い。考えてみると、そもそもJavaScriptに十進数型が無かった。だったらJavaやSwiftで書けば良いかもしれないが、それでもFirebase中に文字列にエンコードするか、整数二つにエンコードするか分からないが、DB I/Oライブラリーに項目変換の拡張がほしい。これらの点、JavaScript自身もFirebase自身も今後拡張される可能性はあるのだろうけども。
 
トランザクションについて、コンカレントに発生する口座間送金処理をFirebaseの楽観ロックだけで実現するとどうなるのか、やりようがあるのか、性能的にどうなのか、私にはちょっと今すぐ判断できない。
 
はてブコメントで重要な指摘をいただいた。「Document更新頻度が1秒あたり1回」という制限があるとのこと。
 
 
以上を踏まえて、「Firebaseは、プラットフォームとして勘定系を支えられるか？」という問いに対する私の結論は以下の通り。
 
・技術的に、機能的、性能的に充足させられるかというと、断定はさけるとしても、相当難しそうだ。
・Firebaseの技術上の優位性が、「「フロントエンド開発者」一人でフルスタック開発できること」にあるとしたら、何せ膨大な工数が必要となるであろう勘定系開発においては差別化にはならない。その他の優位性は現時点では見えない。
 
・
 
ここまでで明らかになったことをまとめる。
 
(i) SoE中心のWebサービス展開を支えるシステムは、Firebase前提で十分によく構築できる。
(ii) 銀行の勘定系は、Firebase前提で構築するのは無理、と判断するしか無い。
 
そして私は次のように言っておく。
 
であるならば、ECサイトやそのバックエンド側業務プロセスを担う販売管理・在庫管理など、いわゆるSoR領域は、(i)と(ii)の中間となるだろう。つまり、Firebaseが使える部分と使えない部分、使えたとしても得に優位性が出ない部分、とがあるだろう。
 
繰り返すが、この度の青銀行の勘定系刷新においては、メインフレームを使うと判断したサブシステムがあるとのこと。それは旧システムを温存したのではなく、新規開発だがトランザクション性能などの面からメインフレームが良い、と判断されたから、である。今回の簡単な調査で、Firebaseは勘定系を支えるのには無理があるだろうと判断される。結局、万能なプラットフォームなどは無く、得手不得手がある、という当たり前の話に帰結するのである。
 
「バックエンド」や「サーバーサイド」という言葉が何を指しているのだろうか？
 
一連の調査や考察を行なっている中で、一つ気付いたことがある。それは、「バックエンド」や「サーバーサイド」という語に何を含意させているのだろうか？という問いが必要だ、ということである。
 
どうも「フロントエンド開発者」が「バックエンド」や「サーバーサイド」と言う時は、
 
Nginx、Apache、PHP、RoR、MySQLといったサーバーサイドの要素技術を前提とした開発と、これらの運用
 
を意味しているようである。かつ、これら「「サーバーサイド技術」を前提とした開発」において開発すべき内容はというと、
 
(あ) データベースをCRUDするためのAPI
(い) （サーバーを経由しなければ実現できない）クライアント間通信
 
概ねこのように捉えているようである。つまり、「フロントエンド開発者」が「バックエンド」と言う時、当たり前なのだが銀行の勘定系などは全く想定してない、ということだ。
 
一方の「バックエンド開発者」が、「バックエンド」や「サーバーサイド」と言う時、次のような内容を前提にしている。
 
(イ) 業務情報モデルの設計
(ロ) 各種業務ロジックのAPI
 
(あ) + (い)の全体は(ロ)に含まれる。(ロ)には(あ)、(い)以外も含む。「フロントエンド開発者」の言う話に(イ)に対応するものはない。「バックエンド開発者」が「バックエンド」というとき、銀行のシステムはその最右翼だろうが、こてこてのSoR領域を想定している。
 
「フロントエンド開発者」のサーバーサイドへの期待は、極めて明確に次の2点しかないのだ。
 
・どうしてもサーバーサイドに置かなければならないデータベースの運用と、それへアクセスするAPI
・どうしてもサーバーを経由せざるを得ない、クライアント間通信のサポート
 
「バックエンド開発者」は、自分たちの役割を次のように捉えている。
 
・ドメインモデルの提供
・データの一貫性の実際的な維持
 
「フロントエンド開発者」からみると、こんなことは本来自分たち自身でやりたいのだ。それをデータベースがサーバー側にあるからといって、いわゆる「バックエンド開発者」に依存しなければならないのは面倒なのだ。しかも、"彼ら"は無駄に重厚で融通の効かない設計を提案してくる。。
 
「バックエンド開発者」はビジネス・モデリングは自分たちが担っており、「フロントエンド開発者」を単に「UIサイドを担う開発者」という期待値で見ている。が、「フロントエンド開発者」の心持ちは全く違う。「フロントエンド開発者」は自分たちを「Webサービス開発者」だと自認している。そして、「バックエンド開発者」を（「Webサービス」という）ビジネスを見ていない人たち、と見做している。
 
「フロントエンド開発者」は、初めからSoE領域の住人なのだ。SoR領域については、"Not My Business"として、彼らの見ている世界には初めから含まれていないのだ。「フロントエンド開発者」の言う「バックエンド」は、「バックエンド開発者」のいう「インフラ」に近い。「バックエンド開発者」のいう「バックエンド」の多くは、「フロントエンド開発者」には見えていない。
 
ちなみに「インフラ技術者」については、下記のような見通しは確かにあると思う。
 
 
同様のことが「バックエンド開発者」のいう「バックエンド」にも今生じているのかと言うと、全くそうは思えない。「インフラ」にしても、DBAの需要は減少傾向としても、例えばDockerやKubernetesを扱える人への需要は高まっている。「インフラ」市場も総体としては縮小一辺倒でもない。
 
エンジニアリング的良し悪しの評価とマーケティング的選択の話を混同していないか？
 
どうやら「フロントエンド開発者」と「バックエンド開発者」とで、工学的判断についての見解が異なったとき、実は、関心を寄せている事業領域やマーケティング的に選択しているターゲットの違いに由来しているようである。お互い無意識的に特定の事業ドメインを前提にして、その文脈を暗黙の前提として、工学的判断を言う。暗黙に異なる文脈を前提に会話してしまうから、荒れるわけだ。しかも、お互い、それぞれ特定の「境界付けられたコンテキスト」に住んでいることを忘れて、自分が見ている文脈はグローバルなものだと錯覚している。文脈がズレていることに気付けない。
 
前段のような文脈違いを認識できたとして、、、マーケティング上の選択としてSoE領域に取り組むことは、それだけでは良いも悪いもないし、市場的なポテンシャルはSoE領域こそ大きい事に間違いない。青銀行ですら（出来栄えはさておき）SoEフロントを提供している。ある人がSoEという領域に魅力を感じてそこで仕事をすることにしても、もちろん何の問題も無いどころか、私が今20代ならそうするだろう。その事と、だからと言ってSoE以外の領域でビジネスをすることやそういう領域を選択することを低く見たり、SoEでない領域を前提とした場合の工学上の評価を誤りと言ってしまうとしたら、何かを見落としているとしか言えない。もちろん逆も同様である。何であれ同様である。
 
ある開発物は、純粋に工学的な産物であることは無く、どうしてもマーケティング的な纏いを持つ。工学的産物は、特定の意図や目的の元に作られる。工学的な評価は、その意図や目的をどの様にどの程度達成したかで測られる。工学としては、意図や目的は評価しない。意図や目的の選択自体は、マーケティングの問題である。ある開発物のエンジニアリング的側面とマーケティング的側面を切り分けて捉えるのは実に難しい。それでも、精度高い会話の為には、それらの切り分けは必要だろう。
 
◇
 
＜追記＞
ちなみに、「フロントエンド開発者」が自らを「フロントエンド開発者」と称し、「バックエンド開発者」が自らを「バックエンド開発者」と称する時、もはや「中核とする技術領域」を言っているのではなく、"所属するコミュニティ"を言ってるとすら思える場合がある。これは「ウォーターフォール」と「アジャイル」でも、「モデリング重視派」と「モデリング不要派」でもそうだったり。。
 
◆以上