jfluteの日記 このページをアンテナに追加

2017-01-01

DBFlute-1.1.2 Released

|

あけましておめでとうございます。

Java8対応のDBFluteの十二回目のリリース。
DBFlute-1.1.2 です。

Change Log
移行の注意点 1.1.1 to 1.1.2

九年連続、九回目の元旦リリースです!

「DBFluteフェス2016」での約束、
「やっぱり元旦に出しますかー!」
を果たすことができました。

※でも、元旦に出しても別に誰もすぐに
ダウンロードするわけじゃないんですけどね笑

f:id:jflute:20170101181404j:image

DB設計のポリシーチェック強化

SchemaPolicyCheckですよ!
昨年の元旦に出した機能です。

DBFlute-1.1.1 Released | jfluteの日記

いわば、DB設計のcheckstyleです。

「_FLAG と _FLG とカラム名がブレまくりー」
「フラグなのに NotNull 制約が付いてないー」
「フラグのデータ型がint, charとかバラバラー」
「_DATE なのに和名が "日時" なんだけどー」
「PKのないテーブルがあるー」
「FK制約名のつけ方が自由すぎるー」

いろいろありますよね。
それらをもう自動生成の段階でチェックして、
ポリシーに合わないものは先に進めないように
しちゃうという機能です。

特に、事業会社などで複数人でDB設計やるようなとき、
レビューも追っつかずにバラバラになっちゃうの、
つらいですよね。
一人でやってても、ケアレスミスとかありますから、
しっかり自動的にチェックがかかる方がいいです。
しかも、DBはなかなか後から変更できないですから。

そんな SchemaPolicyCheck,
昨年の時点ではまだチェック機能が甘かったのですが、
今回のリリースでかなり強化して、
様々なチェックをかけられるようになりました。

f:id:jflute:20170101172055j:image

SchemaPolicyCheckの使い方

dfpropに、
「schemaPolicyMap.dfprop」を作れば、
docタスク (manage の 22) のときに
自動的にチェックされます。

Maihamaプロジェクトのものを参考にするとよいでしょう。
 => schemaPolicyMap.dfprop | Maihama

PolicyにそぐわないDB構造を検知した場合は、
docタスクが Failure となり、
例外メッセージにPolicy違反の情報が表示されます。

今回の強化ポイント

細かくたくさんありますが、
ざっくりと...

「alias名(和名)で if が書けるようになった」
「FKUQの制約名のチェックもできるようになった」
「$$ALL$$を使えるようになった」
「判定で not を使えるようになった」
「正規表現でヒットできるようになった」
「then bad で期待値の補足を書けるようになった」
「共通カラムがあるかどうかチェックできるようになった」
「Policy違反メッセージが見やすくなった」
などなど...

具体的には...

o tableMapにも、statementList を追加
o if alias is ... できるように
o if tableName is $$ALL$$ できるように
o then fkName is ... できるように
o if tableName is not ... できるように
o if tableName is pattern:... できるように
o then bad => should be _FLG できるように
o then hasCommonColumn できるように

色々と表現が豊かになったきたので、
どんなチェックをするかは現場の発想次第。

jfluteも思いつかないようなチェックが期待されます(^^。
ごめんなさい、
正式ドキュメント1月に用意します。。。m(_ _)m

実際に一年運用しています

SchemaPolicyCheck,
すでに一年間運用しています。

U-NEXTさんにて、
(優秀な)DBAの方のポリシーに合わせて、
dfprop に SchemaPolicy を定義して、
別の人がDB設計した時も、
自動的にポリシーレビューがかかるようになってます。
すると、DBAの方のレビュー指摘事項も減り、
より本質的なレビューに集中することができています。

昨年版だと、まだ機能が弱いので、
take-finally で information_schema を見て、
できないことを補っていますが、
今回のリリースで完全に再現できるようになったかと。

jflute個人的にも、
もうこれない環境でのDB設計はつらいなぁと思うくらい。
チーム開発なら絶対に導入したい機能です。

f:id:jflute:20170101181449j:image

LastaFluteやERFluteも!

今回は、他にも同時にリリースしています。

o LastaFlute-0.8.8
o UTFlute-0.6.6
o ERFute-0.4.4

年末のプログラミング会で、みんなで作っていました。

// みんなで年末プログラミング会 (ついーと) | Twitter
https://twitter.com/jflute/status/814451693584687116

こうやってチームで開発できるようになった、
というのも DBFlute の大きな進化です。

LastaFluteでは、
またびっくりする機能が入ってます。
またの機会に紹介したいなと。

昨年は一回だけのリリース!?

なんと、2016年は、リリースが一回だけでした!
昔はあんなにしょっちゅうリリースのDBFluteですが、
LastaFluteでやることたくさんあって、
DBFluteがちょっと進みませんでしたね。
ただし、パッチは一杯出していましたので、
細かい改善はたくさんされていましたよ。

今年は、もうちょい DBFlute のリリースも、
やっていこうかなと思います。
まだまだ進化中のDBFlute、よろしくお願いします。

f:id:jflute:20170101172622j:image

2016-12-20

未来しか見ない人は過去に戻りたい?

|

両方だいじなんです

おそらく人類が何千年としてきた議論だと思います。

「歴史を学ぶことで未来を予測しやすくし、
同じ失敗を繰り返さないようにする」

「昔のことなんかどうでもよくて、
未来が大事だから先のことを考えよう」

NHKの「ニッポンのジレンマ」でも、
この辺が対立する場面が昔あったような...

まあ、いつものお約束。

// 両方だいじなんです | jfluteの日記
http://d.hatena.ne.jp/jflute/20150426/bothdaiji

過去しか見ない人もダメだし、
未来しか見ない人もダメだし。
両方バランスよく見ていかないと。

ブログのタイトルから、
今日の焦点は "未来しか見ない人" です。

プログラマーの世界だと、
"未来しか見ない人" が多いような気がしています。
理由ははっきりしています。

「技術の進化が全然直線ではなく、
過去から未来を想像することが非常に難しいから」
ってのが一つ。

あとは単純に、
「未来のことを考えるは楽しいから」
ってのが一つ。

それでも人間くさいのが現場

> 「技術の進化が全然直線ではなく、
> 過去から未来を想像することが非常に難しいから」

これは一つ確かに存在することですが、
プログラマーが抱える問題、
プログラマーが想像すべき未来は、
必ずしも技術だけで閉じる話ではありません。

結局、人間がプログラムを書く、
複数人の人がプログラムを書く、
これが続いている限りは、
技術が進んでも似たようなジレンマは抱え続けます。

それどころか、技術が進むことによって、
また0からその新しい技術で基盤を作り直すことで、
一時的なデグレが発生して、
昔と同じ問題が発生することもあります。
進化のジレンマと言えるでしょう。

プログラマーの世界でも、
今までの経緯を分析することで、
未来の糧になりそうなことはいくらでもあります。

同じ失敗のオンパレード

jfluteの経験、
10年以上プログラマーの現場を見てきていますが...

なんとも悲しいことに同じ失敗を見かけます。

「この人たち10年前と同じことで悩んでるよ」

「それって、10年前と同じ失敗じゃん」

10年は大げさに聞こえるかもしれませんが、
実際わりと本当にそんな感じです。
もちろん、2年前、3年前と...
スパンは様々ですが、とにかく多々あります。
そのたびに無力感に襲われます。

歴史は繰り返すのか?

...

ちょっと余談ですが...
少しセンシティブな話ですが、
ここ二、三年、素直に思ったこと。

戦後70年経って研究が進み、
いまになって戦争直前の話がちょっとずつ
詳細になってきたということがあるようで、
その話を聞いていると...(TVの特集ですけど)

「なんか、炎上するシステム開発と同じじゃん」

って思うことが多々あるんですね。
人って変わってないんだなぁと。
システム開発とは重みが全然違い過ぎますが、
成り行きと判断のジレンマでもがく人の行動は、
抽象化することができて、参考になるなぁと。

過去は伝わらないもの

> 「この人たち2年前と同じことで悩んでるよ」
> 「それって、2年前と同じ失敗じゃん」

jfluteの行動が利く範囲においては、
それをできる限り防ごうとし、
それなりに防いできたつもりではありますが、
でも、それが及ばず目撃するケースもありました。

それには二つのケースがあります。

一つは、単純にjfluteが力不足であったこと。
そのために、もっとスキルを磨かなければならない。

もう一つは、それがなかなか伝わらないこと。
過去の話はみんな興味がないのです。

...

個人差はあるでしょうが、
まだ日本史世界史はおもしろいものですよ。
しっかり体系化されていて学びやすくもなってるし。

でも、プログラミングの世界の歴史、
ましてや人間くさい開発現場の歴史なんてものは、
なかなか学びやすくもないし、おもしろいものでもない。

特定の現場に依存しない一般的な話ならまだしも、
その自分が関わっているシステムの歴史、
会社の歴史、開発チームの歴史、アーキテクチャの歴史、
そもそも教えてくれる人が非常に限られているし、
そもそもそれを知りたいと思うかどうかもあやしい。

なので伝えても伝えてもなかなか伝わらず、
結局同じ判断を繰り返してしまっている...
と思うことも多々あるのです。

でも、事業会社であれば、
現場の人はどんどん入れ替わりますし、
その中で新しく入ってきた若い人も多い。

なので、みんなにとっては初めての失敗

でもでも、それ2年前と同じだったんだよ...
と思っても防げなかったことを悲しむだけ。

「人は実感がないと動かない」

どれだけ実感を伝えられるか?

そういう意味では、
そこもjfluteの力不足なのでしょう。

...

またも余談。
戦争の悲惨な体験を伝えて未然に戦争を防ごう、
災害の悲惨な体験を伝えて災害による被害を軽減しよう、
というのも、
おそらく同じジレンマを抱えてることでしょう。

どれだけ実感を伝えられるか?

技術の進歩と判断の進歩

jfluteは、
プログラマーの世界でまだ10年ちょい。

色々な現場で見てきた経験を分析するのが
習慣になっています。
若い頃からずっと...もうクセですね。
分析せざるを得ない。頭が勝手に色々考えてる。

「これはどうしてこういう判断だったのかなぁ...?」
「なんでこういうコードになっちゃったのかなぁ...?」
「こうすればこうはならなかったんじゃないかなぁ...?」
「これがあったからすごくスムーズだったんじゃないか!」
「これは素晴らしい判断だと思う!なぜなら...」

別にそういう立場じゃなくても、
何か印象的なことがあれば、
帰り道に頭の中でシミュレーションしてたりします。

優秀な判断を下される方々もたくさん見て来ていますが、
みんな未来だけ見ていそうでちゃんと過去を分析しています。
しっかりとして道理があって判断されています。

...

でも、たまたまこの10年で似たようなことがあっただけで、
このままさらに10年経って色々なものが進化すれば、
さすがに同じ失敗を見かけることはなくなるでしょうか?

残念ながら、まだそうは思えていません。

おそらく、この先も、
人の判断が関わる部分においては、
技術的な話だろうが開発運用的な話だろうが、
同じ問題を抱え、同じ失敗を繰り返す場面を、
また目撃するだろうと。

技術は確実に進歩しているはずなのに、
進歩を感じられない気分のときもあるのです。

判断の進歩が

...
...
...

未来のための過去

jfluteは、立場的に自然と、
その現場の歴史を知っていることが多いです。
分析も勝手にしてきています。

最近は意識して、
もっと歴史的なところとか経緯的なところを、
現場の勉強会の中とかで散りばめたりして...

「どういう道を辿って今があるのか?」

を知ってもらおうとしています。

「だからこうしたらいいんじゃない?」

というのを考えてもらうために。

もちろん、
昔こうだったから今こうすれば成功する、
という短絡化はそれはまた危険ですが、
なにも知らずに考えても危険なことは同じ。
昔はこういう状況でこうやったからダメだった、
今はこういう状況なのでこうやったらOKでは?
と、ちゃんと細かく分析することが大切です。

この10年のこともそうですし、
その特定の現場のここ2,3年の話もそう。

若い人にはもっとレベルの高いことで
悩んで欲しい

この思いで一杯です。

...

本当はそれより前のことも知りたい。
いま思い返せば、師匠がよく話してくれていました。
「昔こんなことあったよ、でさぁこれこうだったわけだ」
非常に貴重な話だったなと。
その糧が自然と活きているような気がします。
いまももっと聞きたいなって。

そして、もっと実感を伝えられるように、
jfluteは努力しないとですね。

...

現場の人には、もっと

未来のために過去に興味を持って欲しい

と思っています。
(少なくともアーキテクトは絶対に必須ですね)

新しく始まったばかりのプロジェクトだとしても、
同じ会社内の他のプロジェクトはどうだったのか?
いくらでも分析する題材はあります。
知ってる人はたくさんいる。
「よし、聞いてみよう!」と思うかどうか。

でないと...

未来を見てたら過去に戻ってた

ってことがあり得るので。

f:id:jflute:20161017122620j:image

2016-12-19

フレームワークの経験で採用して空振り三振

|

エンジニアの採用ジレンマ

エンジニアの採用というのは難しいものです。
エンジニアエンジニアを採用するのも難しく、
エンジニアじゃない人がエンジニアを採用するのは
さらに難しいと考える人もいるでしょう。
現場で使うツールはすぐに身につけます
そこで頼られるのが、
エンジニアの特定の技術に対する経験です。
Java言語を使っている現場であれば、
Java言語を使った開発を何年やっているか?
まあ当然の自然なこととも言えます。

今日の焦点は、
「うちで使っているフレームワークの経験が
三年あるらしい、これは良い人材では!?」
というような採用基準です。

ここでは、仕組みを構築するアーキテクトではなく、
「業務画面を開発するディベロッパー」
を想定しています。

Emptyなんとかフレームワーク経験三年

人によって変わるので一概に言えず、
断言できないからこそ声を上げづらいのですが、
jfluteの経験から、
なんとかフレームワーク経験三年と言っても、
そのフレームワークに本当に詳しい人は一割くらい...
と言えるような気もします。

色々と聞いてみると、
「開発するための最低限のこと」
だけを知って開発してきただけで、
そのフレームワークのことはほとんど知らない。
A社の車を運転してきただけで、
A社の車に詳しいわけじゃない。

会社は、スキルの低い人、発展途上の人であっても、
成果が出せるような仕組みを作り上げようとします。
きっちり開発できるようになってから仕事では、
ひたすら教育コストばかりがかかってしまうからです。
これも当然の流れです。
なので、(ある程度の研修はしつつも)わりと早い段階で、
現場で成果を上げてもらいながら育てようとするわけです。

なので結局、追求心が高い人かどうか?
その心の強さによって、
その経験三年からどれほどのスキルを積み重ねたのか?
これが大きく変わりますので、
経歴書に「とあるフレームワーク経験三年」
とあっても、着目するモチベーションが
ほとんど上がらないのです。

わずかなコストカット

そのフレームワークを使って開発をしていれば、
そのフレームワークを使った開発がわかっているので、
わりとすぐ現場に投入できるという論理があります。
ただそこは、プログラミング言語に比べれば、
ほんのわずかなコストカットに過ぎないと考えます。

なぜなら、昨今のフレームワークは随分と洗練され、
どんなフレームワークを使っていても、
わりと同じようなインターフェースをしています。
ちょっと表現が違うところはありますが、
それは、車のハンドルの形やアクセルの場所、
ギアの変更の仕方が違うのと同じようなもの、
ちょっとやればすぐに適用できます。

結局、現場フィットレイヤがある

また、実際の現場には現場フィットレイヤがあります。

// フレームワーク選び、現場フィットレイヤを忘れずに
http://d.hatena.ne.jp/jflute/20161214/genbafitlayer

なので、実際には、
同じフレームワークだったとしても、
その現場の独自のルールや、
独自のクラスがどうしても存在します。
減らそうと努力はしていたとしても、
やはり現場は千差万別ですから、少なからず、
その現場を最適化する現地化ロジックが存在します。

なので、結局...
「同じフレームワークの経験者だから、
すぐに現場に突っ込んで開発してもらう」
とはいかず、
どんなフレームワーク使ってようが、
現場オリエンテーションが必要です。

他に大事なポイントいくらでも

フレームワークの経験を全く見ないわけではないですが、
そのほかの要素に比べれば優先度は低と考えます。

コミュニケーションがスムーズに取れるか?
仕事に対する意欲が高いか?
技術に対する意欲が高いか?
チーム開発に向いている性格か?
自ら考えて行動する人か?
仕事の正確性が高いか?
などなど...

(jfluteは、"受け応えができる人か?"
ってのをとっても重視します)

そのときどきによって、
どういうタイプの人を求めるかって変わりますが、
いずれにせよ、フレームワークの経験に比べれば、
遥かに優先度の高いポイントがたくさんあるかなと。

まあ、これらを見極めるのが難しいから、
フレームワークの経験に、
ついつい頼ってしまうのかもしれません。
これは永遠のジレンマとも言えるかも。

すべて程度の問題なので、
フレームワークの経験を見るのがダメでもないです。
単に、そこが強い主軸で他のポイントに
目をつぶってしまうことがデンジャラス。

追求心があるかどうか?

使っているプログラミング言語の経験は、
「フレームワークに比べればさすがに大事...」
ってところはありますが、
でもたとえ、プログラミング言語だとしても、
経験があまり関係ないというケースもあります。

Java言語を使っている現場で、
"Java言語初めて" で入って来た人が、
大活躍してるケースをたくさん見て来ました。
純粋にプログラミングの能力が高いわけですね。
逆にいうと、Java経験三年って言っても、
プログラミングの能力が低ければ意味ないです。

「それを見極められればこんなに楽なことはない...」

「まあ、確かに...」

jflute個人的に大切にしている
ポイントがあります。

追求心があるかどうか?

その心があるひとであれば、
その現場で使うツールはすぐに身につけます。
そういったオリエンテーションを用意していれば、
その吸収スピードはさらに上がるでしょう。
(逆に追求心がなければ、
立派なオリエンテーションを用意していても...)

そして...

経験を考慮するにしても、
その経験をどれだけ語れるか?

聞いてみたいところですね。

...

実際に、PHPしかやったことがないという人が...
「入社前にできるだけ家でJava勉強して来ました!」
そして、jfluteが一週間Javaフレームワークの
現場オリエンテーションをさせてもらったのですが、
あっという間に現場に馴染んでしまいました。

言語もフレームワークも初めてなのに、
おおよそのポイントは抑えていてそれなりの判断もできてる。
フレームワークのコンセプトがすぐに理解できるんですね。
"何か疑問に思うこと" や "教えたこと以上の深いところ" も、
気になったら、すぐに質問してくれて吸収してくれました。

Java経験ないからって採用していなかったら、
ちょーもったいなかったでしょう。

採用とフレームワーク

採用自体の課題はなかなか解決できません。
どうやって見極めるのか???

でも、その見極めの難しいポイントから目を背けて、
単純にフレームワーク経験に引っ張られても、
あまり良い結果がでないだろうと思っています。

一方で、そういうことから、
"採用のしやすいから、このフレームワークを選ぶ"
というのも、(ディベロッパーに関しては)
あまり強い意味がないことだなぁと感じます。

...

アーキテクトは除外した話にしていますが、
ディベロッパーに比べればアーキテクトの方は
もう少し重視したいポイントではありながらも、
"このフレームワークでしかアーキテクチャを
構築できないアーキテクト"
だと。またちょっと弱いかなと。

もちろん、
このフレームワークだとやりやすいとかやりにくいとか、
やりたいかやりたくないとか、色々と偏りは出るでしょうが、
要は、覚悟決めて追求してくれる人かどうか?
jflute個人的には、アーキテクトであれば、
こういう "ちから" がある人を重視しています。

// アーキテクトのちから | jfluteの日記
http://d.hatena.ne.jp/jflute/20150113/architect

...

f:id:jflute:20161024130545j:image

2016-12-14

フレームワーク選び、現場フィットレイヤを忘れずに

|

忘れてると...

既存のシステムがあるとします。
だいぶコードもぐちゃぐちゃしてきて、
今のビジネス要求に耐えられない。
フレームワークも刷新したい。

偉い人「リプレイスします!(英断)」
現場誰か「さて何を使おう?」
他の誰か「"A" が良いのでは?」
現場誰か「じゃあ "A" にしよう。」
他の誰か「じゃあ "A" で画面作り始めますね」

この開発で発生するジレンマが想像できます。

...

新卒プログラマ
「既存システムにこういうクラスあるんですけど "A" には?」

先輩アーキテクト
「いやぁ、そんな独自的なものはさすがにないよね」

新卒プログラマ
「ないと困るんですけど...」

先輩アーキテクト
「あー、わかった作るね、他の仕事あるから来週まで待って」

新卒プログラマ
「ぼくの進捗が進まないので明日まででお願いします」

先輩アーキテクト
「いやぁ、俺は俺で作らないといけないものがあって...」

新卒プログラマ
「残業すればいいんじゃないですか?
残業という美しい言葉にひれ伏しなさい」

先輩アーキテクト
「は、はい...仰せの通りに」

既存のシステムからコピーしてくることも多いでしょう。
でも、フレームワークなども環境もガラリ変えてるから、
そんな簡単にコピーもできず、わりと移植が大変でしょう。

だいたい、その辺もメンテが大変だからこそリプレイス、
って話もあったはず。そこが残ると結局同じじゃない?
いや、全く同じとは言わないけど、
リプレイスの目的を少し削られてるような。

現地化ロジックが必ずある

ちょっと気になった記事がありました。
とあるコーヒーチェーンが、
オーストラリア進出にうまくいかなかったという話。

その理由の一つとして、他の地域でうまくいったメニューを
現地化せずにそのまま導入していたという点が印象的でした。

評論的な記事だったので実際にそうかどうかは別にして、
とにかく現地化という言葉に、ふと考えさせられました。

とある有名なOSSフレームワークを
使っている現場があって、
「そのフレームワークだったら知ってるぞ!」
ということでそこに行ったら、たくさんのServletFilter、
もしくは、Interceptorや共通クラスなどがあって、
結局新しく覚えるルールや仕組みが多いなぁ、
なんて思ったことありませんか?
「なんとかcommon」ってプロジェクトあったりしませんか?

独自のクラス自動生成ツールがあったりしませんか?
また、そういった共通ロジックを、社内の別のプロジェクトに
ちょっと調整してコピーして使い回しているってありませんか?

jfluteの経験では、
それがないプロジェクトの方が珍しいなと。
「OSSフレームワーク」と
「業務機能のロジック」しかないシステム、
そんなのは見たことない。

もしそんなシステムがあるとしたら、
おそらく業務機能のプログラムの中に、
仕組みを代弁する冗長な手続きロジックがあるでしょう。
それを避けるためにも、自然発生的に
プロジェクト独自の共通の仕組みが作られるのです。
ある意味では、非常に自然なこと。

現地化ロジックは、
フレームワークを使いこなすために発生する実装と、
フレームワーク関係なく現場で必要な共通的な仕組み、
に大別されます。

# 単にフレームワークを使いこなしきれてない、
# それによって無駄な仕組みが生まれることもあります。
# それはそれで残念な話なので、現地化ロジックを
# 最大限減らすためにもフレームワークの機能をしっかり
# 使いこなしましょうという話はあります。強くあります。
# (個人的には、使いこなしてもいないのに
# フレームワーク議論することに違和感を覚えます)
# 一方で、それを差し引いたとしても、
# 現地化ロジックはそれなりに必要です。

現場フィットレイヤ

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

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

この概念はあまり一般的に話題にされませんが、
確実に存在します。
そして、フレームワーク選びの時、
確実に忘れさられます。

世に名が知られている汎用的なフレームワークは、
この現場フィットレイヤにはあまり手を出しません。

そういったものをフレームワークに含んでしまうと、
とあるタイプの現場ではフィットするけど、
とあるタイプの現場では邪魔なだけ、
みたいなことが発生し、汎用性が失われるからです。
なのでフレームワーク開発者がよく言う言葉が、

「それはアプリ側でどうにかするべきものでしょ」

正しいと言えば正しいこと。
現場の要求千差万別なので、
その中でもできるだけ共通的なものだけを、
フレームワークには入れたいものです。
特定の問題を解決するものをたくさん入れると、
「複雑だ、重い、覚えること多い」という
ネガティブなイメージが付きやすいもの。

一方で、そういう部分は、
関連ライブラリオプションとして提供されたりします。
それはそれで現場側は、
それらをしっかり選んだり組み合わせたり、
現場に合わせて使いこなすためのプログラムが
少しは必要になってきます。

現地化ロジックのコスト

既存システムは、
既存のビジネスを一生懸命成り立たせるために、
その現場でしか役に立たない、でも非常に大切な、
現地化ロジックを組み立てています。

すでにフェーズが変わって要らないものもあるかもですが、
今後もずっと必要なものもあります。

フレームワークを選ぶ時、
ほとんどと言っていいほど、そこが忘れ去られます。
リプレイスでなくても、
その会社で必要とされているやり方、
その会社で共通的にやっているやり方、
そういったものって意外に細かいところであるもので、
新規サービスでも考慮する必要があるかもしれません。

現地化ロジックを分解して...

o 新しいフレームワークの機能で置き換えられるもの
o もう不要だから完全に捨てていいもの
o 置き換えられずコピーしてこないといけないもの
o コピーだけじゃダメで移植作業が必要になるなもの

それぞれ対応していかないといけないでしょう。
そのための時間が必要になるでしょう。
「新しいフレームワークでさあ画面作っていこう」
では済まされないのです。

フレームワークを選ぶときも、
"新しいフレームワークの機能で置き換えられるもの"
が多い方が、その部分のコストを軽減できるわけです。

忘れて開発を始めれば、
予定にないコストが発生するのは当然です。
誰かがそこを無理して受け持つわけです。
忘れて突貫をしてしまったら、
「リプレイスしたのにすぐまたリプレイスしたい」
ものができあがってしまうのです。

もし、完全に現地化ロジックを置き忘れて、
新しくリプレイスしたとしたら、
今までのその現場で実現されていた非機能要件が、
デグレっている可能性もあります。

フレームワーク演出

よくよく分析してみると、
「リプレイスしたい!」って話のきっかけも、
「実は現地化ロジックを置き換えたいだけ」で、
(汎用)フレームワークはあまり関係なかった...

「既存システムで発生している課題は、
ほとんど現場フィットレイヤから来ている」

なんてことも。

ディベロッパーにとっては、
フレームワークよりも現場フィットレイヤの方が距離が近く、
現場フィットレイヤの現地化ロジックが微妙な作りだと、
仮にフレームワークが良いものだとしても、
ディベロッパーストレスは高くなります。

現場フィットレイヤの作りは、
フレームワークの良さをいくらでもつぶせる

逆もしかりです。
良さを最大限引き出すのも現場フィットレイヤです。

フレームワークという素晴らしいパフォーマーの演技を、
最大限魅力的なものに演出する、
現場フィットレイヤという舞台が必要です。

いまや、フレームワークは進化しました。
極端な話、どんなフレームワークでも良い機能が得られます。
だからこそ、この現場フィットレイヤでの演出が、
非常に重要な時代になったとも言えるでしょう。

...

でも、みなフレームワークの話が好きです。
そこばかり焦点を当てて議論をします。

もちろんフレームワークも大切なので、
それはそれで良いことではありますが...
でも少しでも、

この現場における、
現場フィットレイヤをうまく実装しやすい
フレームワークはなんだ?

そして、

現場フィットレイヤの移植コスト

そういったことも考慮していかないと、
歴史は何度も何度も繰り返すことになります。

やはり歴史は繰り返すのでしょうか?

jfluteは、この10年間に、
こういった光景を何度も見てきて、
そろそろ悲しみを抑えきれなくなったのかもしれません。

...

こちらのブログは、
以前に書いたブログの一部を焼き直しています。
なにを社内フレームワークと呼ぶか? | jfluteの日記

f:id:jflute:20161016122107j:image

2016-12-13

オープンソースに「実績は?」と聞く虚しさ

|

実績は世に出てこない

永遠のテーマかもしれません。

何かオープンソースのプロダクトを
現場に導入しようとしたとき、

「えっ、実績は?」

という質問が発生することがありますが、
実はこれほど虚しいことはありません。

システムで何のツール使われているのか?

これは機密情報に当たりやすいので、
当然、なんの許可もなく、
社外に言いふらせるものではありません。
言いふらそうと思うきっかけも
ないかもしれません。

当然、利用されたツールの実績は、
世の中に出て来ません。

オープンソースのジレンマ

有償のツールだと、
買い手がわかる (可能性がある) ため、
ビジネス的にも実績情報を活用したいですから、
買い手に依頼をして、
実績会社として紹介させてもらう、
というような線もあるかもしれません。

ですが、オープンソースのプロダクトだと、
多くは、ダウンロードされておしまい。
(有償ではないオープンソースを前提にしています)

誰がダウンロードしたのかもわからない

ちょうど、こないだの JJUG CCC 2016 Fall にて、
オープンソースの Mixer2 の作者の方が、
まさにこのジレンマを発表されていました。
俺のコードがどこでつかわれているのか
わからない問題あるいはマイナーOSSの
生存戦略 | Slideshare

ダウンロード数くらいはわかりますが、
昨今は「誰か一人がダウンロードして
プロジェクトで共有」という形ではなく、
Maven や Gradle などのビルドツールで、
各自のPCでダウンロードさせたりしますから、
ダウンロード数と現場の数というのが、
いまいち比例しません。
(いずれにせよ、プライベートで試してみた、
というダウンロードもあるでしょうし)

オープンソースの作者からすれば、
どの会社で使ってもらっているのか?
という情報は、
喉から手が出るほど欲しいものです。
それは、有償のツールだろうが、
オープンソースプロダクトだろうが、
広めたいわけですから、その欲求は同じです。

でも、オープンソースプロダクトだと、
その情報を手に入れるのは困難です。
営業するにしても、
どの会社に当たって良いのかもわからない。
だいたいお金もらってないから、
営業するコストがもろにポケットマネー。
普段別の仕事している人が大抵ですから、
そういう活動に時間は割けません。

無意味な質問

これを踏まえると、
「実績は?」という質問自体に
虚しさがあることがわかります。

わからない

としか言いようがなく、
非常に無意味な質問に聞こえるからです。

これは、そのツールを提案した人に限らず、
オープンソースの作者だって同じ状況です。

もしかしたら全く実績ないかもしれないし、
逆にめちゃくちゃ実績あるのかもしれない。

頼るのは名声!?

そこでみんなが頼るところは、
「知ってるかどうか?」
です。

"実績は?"質問のパターンで、

「聞いたことないツールだけど実績は?」

というのが圧倒的に多いです。
実際には、その人がたまたま知らないだけ、
縁遠いだけ、というケースも多いのですが、
人間「知らないことは不安」という性質を
持っていますので、当然と言えば当然です。

逆に言うと、
聞いたことのあるツールに関しては、
あまり実績を問わない傾向にあります。

要は、先の通り世に実績情報がないので、
ネット上や雑誌などで話題になっているか?
そういったところに頼るしかないわけです。
話題になっていれば耳に入ってくる、
話題になっていなければ耳に入ってこない、
耳に入ってこないということは使われてない。

ちなみに、"実績は?" と問われる方が、
そもそもそういう技術情報に敏感かどうか、
というのも気にするところです。
実は話題になってるんだけど、
その話題をキャッチしてないだけとか。

いずれいせよ、実績という言葉が、
わりとふわふわした論理で成り立っている、
というのがポイントです。

メジャーとマイナー

どれだけ頑張って議論しても、
あまり情報量は変わりませんから、

有名なオープンソースなら大丈夫だろう

という結論に陥りやすいです。

当初、実績を細かく気にしていたのに、
結局、有名でメジャーだから実績ある、
という論理で落ち着くことが多いです。

ゆえに、
マイナーなオープンソースプロダクトは、
メジャーなオープンソースプロダクトよりも、
しっかりと説得力のあるセオリーを
組み立てないといけません。

メジャーなオープンソースプロダクトは、
有名というだけで、
その義務が免除されやすいです。

実績を気にして実績ないコード

でも、jfluteはそこに危険な匂いを感じています。

「メジャーだから実績ある」というセオリーは、
「システムは千差万別」という前提を押し隠す

ものになりやすいからです。

...

本来議論しないといけないことは、

この現場にフィットするのか?

ということなので、
メジャーなツールを選んだとしても、
それが、この現場にフィットするのか?
フィットさせるためにどういうことをしたらいいのか?
この議論が必要だからです。

つまり、有償ツールだろうがメジャーOSSだろうが、
マイナーOSSだろうが、この工程は必要なのです。

でも、
1. メジャーだから実績ある
2. 選定終了
3. さあ作り始めよう

この流れをよく見かけます。
行き着く先で見かけるものは...
その
「メジャーなオープンソースプロダクト」
が可哀想だなぁ、という光景。

うまく使いこなされない、
メジャーなオープンソースプロダクト、
本当はこうすればいいのに、
なぜか自分たちでガリガリ書いてる。
そのメジャーなオープンソースプロダクトの上に、
自分たちで作った独自の仕組みが積み重なっている。
ある程度は仕方ないけど、随分多いような...

「そのコードって、実績ないよね?」

実績をすごく気にしていたのに、
実績のないコードがそのシステムの中核を担っている

そんな現場たくさんあります。

まあ、そのコードが一概に悪いわけではなく、
メジャーなオープンソースプロダクトでは
すんなり解決できない特殊な要件が、
その現場あるならしょうがないわけで。
そういうことは往往にしてよくあります。
 => なにを社内フレームワークと呼ぶか?

ただ、単純に使いこなしきれてないだけだと、
"おいおい" 感じになるわkです。
それは現場のプログラマーの実力もありますが、
選定の時に議論していないことも大きな要因です。
フィットするかどうか?どうやってフィットさせるか?

...

いつも jflute は...
あの一年前、二年前の「実績」にこだわった議論って、
いったんなんだったんだろう?って感じるわけです。

「実績関係なくない?」

とまで言わなくても、

「実績あるから(有名だから)って、
何も気にしないじゃダメじゃない?」

と言いたくなるわけです。

現場フィットレイヤプログラムは、
できるだけ少なくしようと努力はしますが、
多かれ少なかれ必要だったりもするので、
そこまで視野に入れた議論しないと。

もし、そこまで実績を気にしてるのであれば、
そもそも実績のないコードがシステム内に
蔓延することを防ぐ施策を考えないと!

質問と行動の矛盾

そして...

オープンソースに「実績は?」と聞くのであれば、
いざその現場で使うことになった時には、
その実績を世の中に公開するでしょうか?

例えば、jfluteは色々な現場に行く都合上、
色々と知っていることはあります。
「それ教えてくれ!」
そう言われても、
「御社の実績も他社に伝えてよろしいでしょうか?」
と言わざるを得ないのです。

もし、その行動と覚悟がないのであれば、
いたって矛盾した姿勢であるとも言えます。

自分は情報を出さないのに、
人から情報は引き出したい

これはオープンソースの話に限らず、
一般にあまり褒められる行為ではないですよね。

もちろん気にするけどね

とはいえ、もちろんjfluteも気にします。
仕事においては、
ギャンブルするわけにはいかないですから、
その現場へのフィット感を探るために。

ただ、実績という言葉を、
「利用してる人が多いかどうか?」
という単純な解釈だけではなく、
適用しようとしている現場に似た現場で
実績があるのか?という風にも考えます。

なぜなら、たくさんの実績があっても、
この現場のマニアックな状況と同じ状況で、
実績があるとは限らないからです。
システムというのは千差万別。
よそでうまくいってるから、
ここでうまくいくとは限らないし、
よそで失敗してるからって、
ここで成功しないとは限らない。

なので実績の内訳を気にしますし、
一方で実績といってもその程度の判断材料
でしかない、という感覚も忘れません。

そして、気にするからには、
できるだけ情報を公開できるよう努めます。
情報公開することによる会社のメリットを
確立させつつ(ブランド力のアップなど)、
ツール側もメリットが得られるように。
それで win-win のきっかけになるはずで。
情報公開をビジネスにしないと。

# 最近で言うと、U-NEXTさんが JJUG CCC で、
# LastaFluteやDBFluteの実績を発表 (Slideshare)
# してくれました。
# 会社にもメリットがあることを提案し、
# 理解をして頂けました。

プログラマーもそういう提案や行動していかないと、
この問題はなかなか解決しないと思います。

ちゃんとオープンソースを知ろう

この手の話は尽きません。
いたる現場でいたる人から、
似たようなジレンマ話を聞きます。

とはいえ、
「実績は?」
と聞く人が悪いわけではありません。
気にするのは当然のことなので。
ただ、オープンソースというものを知らないだけ。

jfluteは、今後同じような話になったら...

「このブログをまず読みましょう!」

と提案します。そのために書きました。
あまりに色々な現場で、
同じ話をし続けて来たからです。
しっかり話をすれば、
多くの人に理解してもらっています。

もし、そのオープンソース特性を
受容できないのであれば、
「その現場ではオープンソースを使うべきではない」
という話に落ち着くだけです。
そういうビジネス判断も悪くはないでしょう。

オープンソースたちも、
ちゃんとわかって使ってもらいたいはずです。

f:id:jflute:20161024131805j:image