忘れてると...
既存のシステムがあるとします。だいぶコードもぐちゃぐちゃしてきて、今のビジネス要求に耐えられない。フレームワークも刷新したい。
偉い人「リプレイスします！(英断)」
現場誰か「さて何を使おう？」
他の誰か「"A" が良いのでは？」
現場誰か「じゃあ "A" にしよう。」
他の誰か「じゃあ "A" で画面作り始めますね」
この開発で発生するジレンマが想像できます。
...
新卒プログラマ
「既存システムにこういうクラスあるんですけど "A" には？」
先輩アーキテクト
「いやぁ、そんな独自的なものはさすがにないよね」
新卒プログラマ
「ないと困るんですけど...」
先輩アーキテクト
「あー、わかった作るね、他の仕事あるから来週まで待って」
新卒プログラマ
「ぼくの進捗が進まないので明日まででお願いします」
先輩アーキテクト
「いやぁ、俺は俺で作らないといけないものがあって...」
新卒プログラマ
「残業すればいいんじゃないですか？
残業という美しい言葉にひれ伏しなさい」
先輩アーキテクト
「は、はい...仰せの通りに」
既存のシステムからコピーしてくることも多いでしょう。でも、フレームワークなども環境もガラリ変えてるから、そんな簡単にコピーもできず、わりと移植が大変でしょう。
だいたい、その辺もメンテが大変だからこそリプレイス、って話もあったはず。そこが残ると結局同じじゃない？いや、全く同じとは言わないけど、リプレイスの目的を少し削られてるような。
現地化ロジックが必ずある
ちょっと気になった記事がありました。とあるコーヒーチェーンが、オーストラリア進出にうまくいかなかったという話。
その理由の一つとして、他の地域でうまくいったメニューを現地化せずにそのまま導入していたという点が印象的でした。
評論的な記事だったので実際にそうかどうかは別にして、とにかく現地化という言葉に、ふと考えさせられました。
とある有名なOSSのフレームワークを使っている現場があって、「そのフレームワークだったら知ってるぞ！」ということでそこに行ったら、たくさんのServletFilter、もしくは、Interceptorや共通クラスなどがあって、結局新しく覚えるルールや仕組みが多いなぁ、なんて思ったことありませんか？「なんとかcommon」ってプロジェクトあったりしませんか？
独自のクラス自動生成ツールがあったりしませんか？また、そういった共通ロジックを、社内の別のプロジェクトにちょっと調整してコピーして使い回しているってありませんか？
jfluteの経験では、それがないプロジェクトの方が珍しいなと。「OSSのフレームワーク」と「業務機能のロジック」しかないシステム、そんなのは見たことない。
もしそんなシステムがあるとしたら、おそらく業務機能のプログラムの中に、仕組みを代弁する冗長な手続きロジックがあるでしょう。それを避けるためにも、自然発生的にプロジェクト独自の共通の仕組みが作られるのです。ある意味では、非常に自然なこと。
現地化ロジックは、フレームワークを使いこなすために発生する実装と、フレームワーク関係なく現場で必要な共通的な仕組み、
に大別されます。
...
単にフレームワークを使いこなしきれてない、それによって無駄な仕組みが生まれることもあります。それはそれで残念な話なので、現地化ロジックを最大限減らすためにもフレームワークの機能をしっかり使いこなしましょうという話はあります。強くあります。(個人的には、使いこなしてもいないのにフレームワークを議論することに違和感を覚えます) 一方で、それを差し引いたとしても、現地化ロジックはそれなりに必要です。
現場フィットレイヤ
フレームワークと現場のギャップを埋めるレイヤ、汎用的なフレームワークを現場にフィットさせるレイヤ、それをjfluteは「現場フィットレイヤ」と呼んでいます。
現地化ロジックをたくさん含んだ現場フィットレイヤ
この概念はあまり一般的に話題にされませんが、確実に存在します。そして、フレームワーク選びの時、確実に忘れさられます。
世に名が知られている汎用的なフレームワークは、この現場フィットレイヤにはあまり手を出しません。
そういったものをフレームワークに含んでしまうと、とあるタイプの現場ではフィットするけど、とあるタイプの現場では邪魔なだけ、みたいなことが発生し、汎用性が失われるからです。なのでフレームワーク開発者がよく言う言葉が、
「それはアプリ側でどうにかするべきものでしょ」
正しいと言えば正しいこと。現場の要求は千差万別なので、その中でもできるだけ共通的なものだけを、フレームワークには入れたいものです。特定の問題を解決するものをたくさん入れると、「複雑だ、重い、覚えること多い」というネガティブなイメージが付きやすいもの。
一方で、そういう部分は、関連ライブラリやオプションとして提供されたりします。それはそれで現場側は、それらをしっかり選んだり組み合わせたり、現場に合わせて使いこなすためのプログラムが少しは必要になってきます。
現地化ロジックのコスト
既存システムは、既存のビジネスを一生懸命成り立たせるために、その現場でしか役に立たない、でも非常に大切な、現地化ロジックを組み立てています。
すでにフェーズが変わって要らないものもあるかもですが、今後もずっと必要なものもあります。
フレームワークを選ぶ時、ほとんどと言っていいほど、そこが忘れ去られます。リプレイスでなくても、その会社で必要とされているやり方、その会社で共通的にやっているやり方、そういったものって意外に細かいところであるもので、新規サービスでも考慮する必要があるかもしれません。
現地化ロジックを分解して...
o 新しいフレームワークの機能で置き換えられるもの
o もう不要だから完全に捨てていいもの
o 置き換えられずコピーしてこないといけないもの
o コピーだけじゃダメで移植作業が必要になるなもの
それぞれ対応していかないといけないでしょう。そのための時間が必要になるでしょう。「新しいフレームワークでさあ画面作っていこう」では済まされないのです。
フレームワークを選ぶときも、"新しいフレームワークの機能で置き換えられるもの" が多い方が、その部分のコストを軽減できるわけです。
忘れて開発を始めれば、予定にないコストが発生するのは当然です。誰かがそこを無理して受け持つわけです。忘れて突貫をしてしまったら、「リプレイスしたのにすぐまたリプレイスしたい」ものができあがってしまうのです。
もし、完全に現地化ロジックを置き忘れて、新しくリプレイスしたとしたら、今までのその現場で実現されていた非機能要件が、デグレっている可能性もあります。
フレームワークの演出
よくよく分析してみると、「リプレイスしたい！」って話のきっかけも、「実は現地化ロジックを置き換えたいだけ」で、(汎用)フレームワークはあまり関係なかった...
「既存システムで発生している課題は、ほとんど現場フィットレイヤから来ている」
なんてことも。
ディベロッパーにとっては、フレームワークよりも現場フィットレイヤの方が距離が近く、現場フィットレイヤの現地化ロジックが微妙な作りだと、仮にフレームワークが良いものだとしても、ディベロッパーのストレスは高くなります。
現場フィットレイヤの作りは、フレームワークの良さをいくらでもつぶせる
逆もしかりです。良さを最大限引き出すのも現場フィットレイヤです。
フレームワークという素晴らしいパフォーマーの演技を、最大限魅力的なものに演出する、現場フィットレイヤという舞台が必要です。
いまや、フレームワークは進化しました。極端な話、どんなフレームワークでも良い機能が得られます。だからこそ、この現場フィットレイヤでの演出が、非常に重要な時代になったとも言えるでしょう。
...
でも、みなフレームワークの話が好きです。そこばかり焦点を当てて議論をします。
もちろんフレームワークも大切なので、それはそれで良いことではありますが...でも少しでも、
この現場における、現場フィットレイヤをうまく実装しやすいフレームワークはなんだ？
そして、
現場フィットレイヤの移植コスト
そういったことも考慮していかないと、歴史は何度も何度も繰り返すことになります。
やはり歴史は繰り返すのでしょうか？
jfluteは、この10年間に、こういった光景を何度も見てきて、そろそろ悲しみを抑えきれなくなったのかもしれません。
...
こちらのブログは、以前に書いたブログの一部を焼き直しています。
なにを社内フレームワークと呼ぶか？ | jfluteの日記
