なにを社内フレームワークと呼ぶか?

社内フレームワークという言葉があります。
また、独自フレームワークと呼ぶことも。
会社の規模によっては、
社内共通とプロジェクト独自の境界線が曖昧なときも。

えてしてこの言葉はネガティブなイメージを持ちます。
とにかく、ダークなイメージです。

jfluteも、若い頃なんかは特に
「DKJフレームワーク (DoKuJi)」とか揶揄してました。
(jfluteはいまもバカですが、昔はもっとおバカだったので...)

ただ、アーキテクトとしては、
単なる好き嫌い感情や、イメージだけで語るわけにはいかない。
特にここ一、二年で、その辺をよく考えるきっかけがあったので、
そもそも、社内フレームワークという定義、少しまとめてみたいと。

ネガティブイメージの最たる理由

社内フレームワークのネガティブイメージの最たる理由として、
「ノウハウが独自なので、
他の現場で活かせない、新しい人が来ても敷居が高い」
ということがよく言われます。

うむ、その通り。
と言いたいところですが、なんのセオリーもなく
終わりにしてはいけませんと。

オープンソースを拡張、どれくらい?

もう少し社内フレームワークというものを分析してみましょう。
すっごい簡単に二つに分けると、

o ゼロから全部社内で作ってる
o オープンソースを拡張して作ってる

ゼロから全部社内で作ってる、ってすごいですね。
昔はよくありましたが、いまはあまりみかけないかも。
というか昔は何もなかったんだから仕方がない。

とあるオープンソースを拡張しているのであれば、
そのオープンソースのノウハウを活かせるかもしれません。
ただ、ここもこんなに綺麗に分かれるわけではなく、
「程度」の問題があります。
すっげー拡張して跡形もないのか、
わりとそのままのノウハウが活かせるくらいのラッパーなのか。

社内フレームワークが、どういった構成のものなのか?
これによって、議論は少し変わるでしょう。

ここでは「ゼロから全部社内で作ってる」ケースというのは、
議論の対象から外させて頂きまします。
個人的にはあまり見かけないので、議論の簡略化のために。
というのは、こちらのタイプの社内フレームワークと
混同して議論が進むことが多いのです。
ここでの焦点は、
とあるオープンソースを拡張した社内フレームワークにします。

実は社内フレームワークは現地化ロジック

ちょっと気になった記事がありました。
とあるコーヒーチェーンが、
オーストラリア進出にうまくいかなかったという話。
その理由の一つとして、他の地域でうまくいったメニューを
現地化せずにそのまま導入していたという点が印象的でした。

評論的な記事だったので実際にそうかどうかは別にして、
とにかく現地化という言葉に、ふと考えさせられました。
この社内フレームワークという言葉とリンクさせて。

とあるOSSフレームワークを使っている現場があって、
そこに行ったら、たくさんのServletFilter、
もしくは、Interceptorや共通クラスなどがあって、
結局覚えるルールや仕組みが多いって思ったことありませんか?

RequestProcessor(に相当するフレームワーク内のクラス)
をオーバーライドしていませんか?
独自のクラス自動生成ツールがあったりしませんか?
また、そういった共通ロジックを、社内の別のプロジェクトに
ちょっと調整してコピーして使い回しているってありませんか?
それって、社内フレームワークとは呼ばないのでしょうか?

jfluteの経験では、それがないプロジェクトの方が珍しいなと。
OSSフレームワークと業務機能のロジックしかないシステム、
そんなのは見たことないよぅ、って感じです。
それがもしあるとしたら、業務機能のプログラムの中に、
仕組みを代弁する冗長な手続きロジックが混在しているでしょう。
それを避けるためにも、自然発生的にプロジェクト独自の
共通の仕組みが作られるのです。

って、それは当然のことだと思うのです。
なぜなら、それらは「現地化ロジック」だからです。
OSSフレームワークは、よそでも利用できる汎用的なものです。
とあるプロジェクト専用、もしくは、組織に特化した機能は
備えていません。それらは利用者が自分たちで作るものです。

フレームワークと現場のギャップを埋めるレイヤ、
汎用的なフレームワークを現場にフィットさせるレイヤ、
それをjfluteは「現場フィットレイヤ」と呼んでいます。

「現地化ロジックをたくさん含んだ現場フィットレイヤ」

この概念はあまり一般的に話題にされませんが、確実に存在します。

そう考えると、
先ほどの社内フレームワークのネガティブイメージ、
あまり意味のない議論だなぁと思えるのです。
(少なくともOSSを拡張した社内フレームワークにおいては)

ちょっとしたカラクリがあります。
フレームワークの議論をするときに、
匿名のそれら独自の共通の仕組みや共通の使い回しロジックは、
社内フレームワークとは呼ばれず、話題にもされません。
なので、社内フレームワークの持つネガティブイメージは付きません。
それらを整備して明確な社内フレームワークにした途端に、
そのネガティブイメージを受けることになります。

論点のズレた議論をしないために

A というOSSフレームワークを拡張した社内フレームワーク B、
そして、C という全く別のOSSフレームワークがあるとして...

「B と C に置き換えよう」

というような議論になることがよくあります。
ここまで読み進めていれば、これがおかしいことがわかるでしょう。
ちょっとズレていますよね。
「C を適用したときの現場フィットレイヤはどうするの?」って。

でも実際に、そういうの昔からよくみかけます。
最初はそこに全く着目せず、というか気付かず、
開発していくうちにあれが足りないこれが足りない、
それを作るコストは見積もりに入ってないから時間がなく四苦八苦。
できあがった共通の仕組みはツギハギのとっ散らかったもの。
誰もメンテができず、新しく参入した人にはとても厳しい。
「C に移行した意味、どこにいったのだろう?」って。

実は、Aを拡張したときの社内フレームワークの現地化ロジックも
一緒に移植しないといけなかったわけです。
また、移植コストがかかるという面を無視してはいけないのです。

そのフレームワーク、どこまで?

現場フィットな機能をたくさん備えたフレームワークもあります。
それらを使えば、現地化ロジックを自分たちでせっせと書くことも
少なくなるでしょう。DBFluteなんかは典型的な例だと思います。

ですが、そういったフレームワークの現場フィット機能は、
現場の要件や文化と合わないときにはちょっと邪魔になります。
実際は、設定で調整できたりするので問題はないものですが、
どうしてもネガティブなイメージが先行します。

また「機能が多くて複雑」というイメージが付くため、
そういったフレームワークがメジャーになりにくいもので、
それよりも機能がシンプルで(イメージ的に)適用範囲の広い
フレームワークの方が多くの人に好まれやすいものです。
(メジャーなフレームワークほど、
現場フィットレイヤまで突っ込んでないものが多いかも!?)

そもそもフレームワークが受け持つ領域には、
「汎用レイヤ」と「現場フィットレイヤ」があって、
どのフレームワークがどこまで受け持っているのか?

そこまで考えて議論しないと正確な答えは導けないのです。

現場フィットレイヤこそ大切

ここはもうちょいjfluteの考えが強く出てしますが、
昨今のフレームワークはどれも優秀で、
「全然システム作れない」
なんて致命的なフレームワークはもうあまり見かけません。
もちろん、その中で特徴や品質など色々な付加価値があるものの、
ちゃんと使いこなしたら、それなりに良い結果を生むものばかり。

そのフレームワークの付加価値を台無しにもできるし、
逆にもっと高い価値できるのが現場フィットレイヤです。
そう、それはまさしく社内フレームワークと呼ばれる部分。
(社内で共有しないなら、プロジェクトフレームワーク)

「そこをどう構築するか?どうデザインするか?」

ってところに、もうちょい関心が集まってもいいのでは?

実はもう一つのネガティブ理由

さて、実はもっと潜在的なネガティブな理由があります。
こちらの方が実は致命的な問題と言えるかもしれません。

社内フレームワークにかけるコストはどこからも払われません。
それゆえ、品質が担保されにくく、整理整頓も行き届かない。
トラブルがあってもなかなかすぐに対応されない。
現場に近い部分のロジックがそんなんだから、
余計にそこから発生する「がんじがらめ感」が半端ない。
ダークなイメージは、ここが発祥なのではないかとも思います。

多くの人が片手間で作っています。
先ほどの「C への移植」のパターンと同じように、
最初どれほど必要か全くわからずに、
つどつど足りない足りないで付け足していくことが多いため、
もともとのOSSの付加価値をうまく活かせない、
もしくは、活かせたとしてもさらに向上させることができない、
そういったものに仕上がってしまう可能性が高いです。

また、そもそも
「フレームワーク作りを得意としている人」
なんて人は現場にそうそういません。
でも、社内フレームワークを作るというのはそういうことです。
そして、複数の人が使うライブラリロジックの実装というのは、
画面の業務ロジックを実装するのとはちょっと違い、
考慮すべきことも変わり、独特のノウハウが必要です。
しっかりとした「ライブラリ」に仕上げるというのは、
それなりの経験とノウハウが必要です。

何をもって失敗と呼ぶかは色々な視点がありますが、
「社内フレームワークの失敗」と言えば、
ほとんどの原因がこれだと考えます。

汎用的でない分、ノウハウも一般的ではないため、
単純に「作る難易度」は高いものです。なのに、片手間。
また、どうしても最初に適用したプロジェクトに依存した
設計になってしまうため、その後の展開で社内汎用性を
キープするのがとても難しいです。

自然と、社内フレームワークの開発は、
「インクリメンタルなもの」
になります。

現場に密着し、ヒアリングをして、
つどつど改良を加えて向上させていかないといけないのです。
逆に、それができないと、ネガティブイメージの通りの結果に
なってしまうのです。

ですから、社内フレームワークを作ってるって聞いたら、
「よくがんばってるなぁ、すごいなー」ってね、
jflute は素直に尊敬します。

jfluteのチャレンジ

jfluteはここ一、二年のなかで、
社内フレームワークにチャレンジする機会がありました。
でも別に「社内フレームワークを作ろう」なんて感じではなく、
やはり自然発生的な感じです。

リーン・スタートアップでの開発だったので、スピード重視。
そして、現場フィットレイヤがスピードに影響すると考えたので、
それをしっかりと考慮した作りのものを。
というか、開発者が現地化ロジックを実装すること自体が、
大変なコストですからね。

とはいえ、やったことは、

o SAStrutsをちょっと使いやすくした
o 既に別のプロジェクトであった現地化ロジックを整理して導入
o さらに別のプロジェクトの現地化ロジックをもういっこ導入
o 現場で困っていることを常にウォッチしてインクリメンタル実装

DBサイドは、DBFluteをフル活用すること自体が現場フィットなので、
あまり現地化ロジックはなく、注力したのはそれ以外の部分ですね。

気をつけたことは...大きく五つ

{1}: インクリメンタル開発していけること
フレームワークの修正で業務プログラムに影響でないように。
フレームワーク内のプログラムのレイヤ管理をすること。

{2}: 細かい現場フィットがつどつど独自にできること
社内独自ではなくプロジェクト独自の現地化ロジックを、
簡単に追加できるような仕組みを最初から提供。

{3}: 夜中だろうが土曜だろうが日曜だろうが実装
やはり片手間であることには変わりませんから、
存在する時間は最大限使ったという感じです。

{4}: 現場でのヒアリングを欠かさないこと
常にウォッチして、現場のコードや開発者の言葉に敏感になり、
現場の要件をしっかりキャッチして分析していくことが大切です。

{5}: メンテナンスできる人を増やすこと
全体設計やコアな部分の修正はjfluteがやりますが、
若い人のフレームワークデビューの土台にしています。
フレームワークのソースは社内オープンで誰でも修正可能で、
jfluteがレビューして取り込みます。プルリクたくさん!
また、コードリーディング会も活発です。

運がよかったのか、
社内の8つのプロジェクトで採用されています。
それなりの規模で継続開発されているもので言うと4つ。

また、その4つのプロジェクトでは適用バージョンがほぼ最新です。
これって何気に(我ながらですいませんが)すごいことなんですよっ笑。
普通はなかなかそうなりません。
既に運用しているシステムの社内フレームワークを修正するって、
とっっっっっても、敷居の高いことです。

現場と密に連携をして、必要性と安全性を説明して入れてもらいます。
そう、「現場との信頼関係」がないとできないことです。
それをとてもとても大切に考えています。
(ということで、DBFluteもほぼ最新です、ありがとうありがとう)

その代わり「こういうの欲しいな」と言われたら、
夜中だろうが休日だろうが構わず実装して、朝にはできてるみたいな。
DBFluteのやり方と同じですね。

そしてなにより、
使ってる現場の開発者がとっても喜んでくれているということ。
これが一番うれしい!

社内フレームワークというネガティブなイメージ、
別のプロジェクトでの現地化ロジックを整理して移植して、
名前を付けた途端に持つことになったネガティブなイメージ、
これが少しは払拭できたでしょうか?

こちらですね。

SAStrutsと半同棲の三ヶ月 | jfluteの日記

SAFlute | DBFlute

独自のノウハウができるだけ少なくなるように、
オープンソースとなっています。

もちろん実際には、公開できないもの、
公開してもあまり意味のないものもあり、
それらは、SAFlute には含まれていません。
なので SAFlute が全てではありませんが、
土台として大きな役割を担っています。

ちなみに、別の現場で、
SAFluteを使ってくれているところもあるようです。
少なくとも、参考になれば幸いだなーって思っています。

自分で作った道具を愛せますか?

一方で、ベースが SeasarSAStruts ということから、
やはりもっと将来性のあるフレームワークにしたい、
という話もあります。
なんだか、Seasarを語ること、使っているということが、
言いづらいムードも出てきて肩身が狭い笑
(ただまあ、一生懸命学んでる若い人がいる人のことを考えると、
あんまりそういうこと言いたくないなという気持ちもあり...)

ただ、どのフレームワークを選ぼうが...
「SAFluteでやっているような現地化ロジックを、
新しいフレームワークでも (ある程度) 構築しないといけない」
これを忘れてはいけないかなと。

これを忘れると、その場でみんなでつぎはぎ作った、
誰も管理していない「common群」が結局できてしまい、
OSSの土台フレームワークの良さを半減させてしまいます。

今の「社内フレームワーク」は、
次の「社内フレームワーク」の参考になるはずです。
この「社内フレームワーク」が「現場要件の辞書」みたいになればと。
そういう思いも込めて、今でもせっせと実装しています。

ビジネス最優先、
そして「論理的に」役割を終える日が来るなら、
それはそれで静かに見守るでしょう。

ただ、現役時代は最高のパフォーマンスを!
ぼくらはプログラマーなんだから、
将来性がなかろうが、イメージ悪かろうが、
プログラミングで改善することができる。

そして、現役を引退する日が来ても、
違った役割を持たせて有終の美を飾らせてあげたい。
自分が作ったものだから、できるかぎり、
利害を超えてでも世話したいなってね、思うのです。

とまあ、そのくらいの想いがないと、
社内フレームワークというもの、
成功させるのは難しいのかなって感じます。

【追記】
そして、LastaFluteになっちゃいました。
 => LastaFlute (Javaでリーンスタートアップ)

そのフレームワークの論点は何か?

フレームワークの議論するときの論点、
つまり、そこにある問題の本質は何か?

そのフレームワークで何を解決したいの?

「今」の解決だけでなく、「先」の解決も含めて、
これをしっかり見極めた上で進むべき道を歩いていくことが、
「もっと楽しい世界を見る第一歩」かなって思って、
こんなブログを書いてみました。