あけましておめでとうございます。Java8対応のDBFluteの十二回目のリリース。「やっぱり元旦に出しますかー!」を果たすことができました。※でも、元旦に出しても別に誰もすぐにダウンロードするわけじゃないんですけどね笑DB設計のポリシーチェック強化SchemaPolicyCheckですよ!昨年の元旦に出した機能です。jfluteの日記いわば、DB設計のcheckstyleです。「FK制約名のつけ方が自由すぎるー」いろいろありますよね。それらをもう自動生成の段階でチェックして、ポリシーに合わないものは先に進めないようにしちゃうという機能です。事業会社などで複数人でDB設計やるようなとき、レビューも追っつかずにバラバラになっちゃうの、つらいですよね。一人でやってても、ケアレスミスとかありますから、しっかり自動的にチェックがかかる方がいいです。DBはなかなか後から変更できないですから。様々なチェックをかけられるようになりました。ときに自動的にチェックされます。Maihamaプロジェクトのものを参考にするとよいでしょう。例外メッセージにPolicy違反の情報が表示されます。できるように色々と表現が豊かになったきたので、どんなチェックをするかは現場の発想次第。jfluteも思いつかないようなチェックが期待されます(^^。正式ドキュメント1月に用意します。_)m実際に一年運用していますSchemaPolicyCheck,すでに一年間運用しています。自動的にポリシーレビューがかかるようになってます。すると、DBAの方のレビュー指摘事項も減り、より本質的なレビューに集中することができています。今回のリリースで完全に再現できるようになったかと。jflute個人的にも、もうこれない環境でのDB設計はつらいなぁと思うくらい。チーム開発なら絶対に導入したい機能です。LastaFluteやERFluteも!今回は、他にも同時にリリースしています。ERFute-0.4.4年末のプログラミング会で、みんなで作っていました。LastaFluteでは、またびっくりする機能が入ってます。機会に紹介したいなと。昨年は一回だけのリリース!?なんと、2016年は、リリースが一回だけでした!昔はあんなにしょっちゅうリリースのDBFluteですが、LastaFluteでやることたくさんあって、DBFluteがちょっと進みませんでしたね。細かい改善はたくさんされていましたよ。リリースも、やっていこうかなと思います。進化中のDBFlute、よろしくお願いします。両方だいじなんですおそらく人類が何千年としてきた議論だと思います。未来が大事だから先のことを考えよう」NHKの「ニッポンのジレンマ」でも、この辺が対立する場面が昔あったような...まあ、いつものお約束。未来しか見ない人もダメだし。両方バランスよく見ていかないと。多いような気がしています。理由ははっきりしています。過去から未来を想像することが非常に難しいから」ってのが一つ。「未来のことを考えるは楽しいから」ってのが一つ。技術だけで閉じる話ではありません。技術が進んでも似たようなジレンマは抱え続けます。昔と同じ問題が発生することもあります。進化のジレンマと言えるでしょう。未来の糧になりそうなことはいくらでもあります。同じ失敗のオンパレードjfluteの経験、10年以上プログラマーの現場を見てきていますが...なんとも悲しいことに同じ失敗を見かけます。実際わりと本当にそんな感じです。2年前、3年前と...スパンは様々ですが、とにかく多々あります。そのたびに無力感に襲われます。歴史は繰り返すのか?...ちょっと余談ですが...少しセンシティブな話ですが、ここ二、三年、素直に思ったこと。戦後70年経って研究が進み、いまになって戦争直前の話がちょっとずつ詳細になってきたということがあるようで、その話を聞いていると...(TVの特集ですけど)「なんか、炎上するシステム開発と同じじゃん」って思うことが多々あるんですね。人って変わってないんだなぁと。抽象化することができて、参考になるなぁと。「それって、2年前と同じ失敗じゃん」jfluteの行動が利く範囲においては、それをできる限り防ごうとし、それなりに防いできたつもりではありますが、でも、それが及ばず目撃するケースもありました。それには二つのケースがあります。一つは、単純にjfluteが力不足であったこと。そのために、もっとスキルを磨かなければならない。一つは、それがなかなか伝わらないこと。過去の話はみんな興味がないのです。...個人差はあるでしょうが、まだ日本史や世界史はおもしろいものですよ。体系化されていて学びやすくもなってるし。プログラミングの世界の歴史、ましてや人間くさい開発現場の歴史なんてものは、なかなか学びやすくもないし、おもしろいものでもない。会社の歴史、開発チームの歴史、アーキテクチャの歴史、そもそも教えてくれる人が非常に限られているし、そもそもそれを知りたいと思うかどうかもあやしい。結局同じ判断を繰り返してしまっている...と思うことも多々あるのです。現場の人はどんどん入れ替わりますし、その中で新しく入ってきた若い人も多い。みんなにとっては初めての失敗でもでも、それ2年前と同じだったんだよ...と思っても防げなかったことを悲しむだけ。「人は実感がないと動かない」どれだけ実感を伝えられるか?そういう意味では、そこもjfluteの力不足なのでしょう。災害の悲惨な体験を伝えて災害による被害を軽減しよう、というのも、おそらく同じジレンマを抱えてることでしょう。どれだけ実感を伝えられるか?技術の進歩と判断の進歩jfluteは、プログラマーの世界でまだ10年ちょい。色々な現場で見てきた経験を分析するのが習慣になっています。若い頃からずっと...もうクセですね。頭が勝手に色々考えてる。帰り道に頭の中でシミュレーションしてたりします。優秀な判断を下される方々もたくさん見て来ていますが、みんな未来だけ見ていそうでちゃんと過去を分析しています。して道理があって判断されています。...でも、たまたまこの10年で似たようなことがあっただけで、このままさらに10年経って色々なものが進化すれば、さすがに同じ失敗を見かけることはなくなるでしょうか?残念ながら、まだそうは思えていません。同じ問題を抱え、同じ失敗を繰り返す場面を、また目撃するだろうと。進歩を感じられない気分のときもあるのです。判断の進歩が.........未来のための過去jfluteは、立場的に自然と、その現場の歴史を知っていることが多いです。分析も勝手にしてきています。現場の勉強会の中とかで散りばめたりして...「どういう道を辿って今があるのか?」を知ってもらおうとしています。「だからこうしたらいいんじゃない?」というのを考えてもらうために。昔こうだったから今こうすれば成功する、という短絡化はそれはまた危険ですが、なにも知らずに考えても危険なことは同じ。今はこういう状況なのでこうやったらOKでは?と、ちゃんと細かく分析することが大切です。この10年のこともそうですし、その特定の現場のここ2,3年の話もそう。若い人にはもっとレベルの高いことで悩んで欲しいこの思いで一杯です。...本当はそれより前のことも知りたい。いま思い返せば、師匠がよく話してくれていました。非常に貴重な話だったなと。その糧が自然と活きているような気がします。いまももっと聞きたいなって。実感を伝えられるように、jfluteは努力しないとですね。...現場の人には、もっと未来のために過去に興味を持って欲しいと思っています。同じ会社内の他のプロジェクトはどうだったのか?いくらでも分析する題材はあります。知ってる人はたくさんいる。「よし、聞いてみよう!」と思うかどうか。ないと...未来を見てたら過去に戻ってたってことがあり得るので。エンジニアの採用ジレンマエンジニアの採用というのは難しいものです。エンジニアがエンジニアを採用するのも難しく、エンジニアじゃない人がエンジニアを採用するのはさらに難しいと考える人もいるでしょう。現場で使うツールはすぐに身につけますそこで頼られるのが、エンジニアの特定の技術に対する経験です。Java言語を使っている現場であれば、Java言語を使った開発を何年やっているか?まあ当然の自然なこととも言えます。「うちで使っているフレームワークの経験が三年あるらしい、これは良い人材では!?」というような採用基準です。「業務画面を開発するディベロッパー」を想定しています。断言できないからこそ声を上げづらいのですが、jfluteの経験から、なんとかフレームワーク経験三年と言っても、そのフレームワークに本当に詳しい人は一割くらい...と言えるような気もします。「開発するための最低限のこと」だけを知って開発してきただけで、そのフレームワークのことはほとんど知らない。A社の車を運転してきただけで、A社の車に詳しいわけじゃない。成果が出せるような仕組みを作り上げようとします。開発できるようになってから仕事では、ひたすら教育コストばかりがかかってしまうからです。これも当然の流れです。現場で成果を上げてもらいながら育てようとするわけです。経歴書に「とあるフレームワーク経験三年」とあっても、着目するモチベーションがほとんど上がらないのです。わずかなコストカットそのフレームワークを使って開発をしていれば、そのフレームワークを使った開発がわかっているので、わりとすぐ現場に投入できるという論理があります。そこは、プログラミング言語に比べれば、ほんのわずかなコストカットに過ぎないと考えます。昨今のフレームワークは随分と洗練され、どんなフレームワークを使っていても、わりと同じようなインターフェースをしています。表現が違うところはありますが、それは、車のハンドルの形やアクセルの場所、ギアの変更の仕方が違うのと同じようなもの、ちょっとやればすぐに適用できます。結局、現場フィットレイヤがあるまた、実際の現場には現場フィットレイヤがあります。独自のクラスがどうしても存在します。減らそうと努力はしていたとしても、やはり現場は千差万別ですから、少なからず、その現場を最適化する現地化ロジックが存在します。現場オリエンテーションが必要です。他に大事なポイントいくらでもフレームワークの経験を全く見ないわけではないですが、そのほかの要素に比べれば優先度は低と考えます。遥かに優先度の高いポイントがたくさんあるかなと。これらを見極めるのが難しいから、フレームワークの経験に、ついつい頼ってしまうのかもしれません。これは永遠のジレンマとも言えるかも。すべて程度の問題なので、フレームワークの経験を見るのがダメでもないです。そこが強い主軸で他のポイントに目をつぶってしまうことがデンジャラス。経験があまり関係ないというケースもあります。大活躍してるケースをたくさん見て来ました。純粋にプログラミングの能力が高いわけですね。逆にいうと、Java経験三年って言っても、プログラミングの能力が低ければ意味ないです。「まあ、確かに...」jflute個人的に大切にしているポイントがあります。追求心があるかどうか?その心があるひとであれば、その現場で使うツールはすぐに身につけます。いったオリエンテーションを用意していれば、その吸収スピードはさらに上がるでしょう。立派なオリエンテーションを用意していても...)そして...経験を考慮するにしても、その経験をどれだけ語れるか?聞いてみたいところですね。...実際に、PHPしかやったことがないという人が...「入社前にできるだけ家でJava勉強して来ました!」そして、jfluteが一週間Javaやフレームワークの現場オリエンテーションをさせてもらったのですが、あっという間に現場に馴染んでしまいました。言語もフレームワークも初めてなのに、おおよそのポイントは抑えていてそれなりの判断もできてる。フレームワークのコンセプトがすぐに理解できるんですね。気になったら、すぐに質問してくれて吸収してくれました。Java経験ないからって採用していなかったら、ちょーもったいなかったでしょう。採用とフレームワーク採用自体の課題はなかなか解決できません。単純にフレームワーク経験に引っ張られても、あまり良い結果がでないだろうと思っています。一方で、そういうことから、"採用のしやすいから、このフレームワークを選ぶ"というのも、(ディベロッパーに関しては)あまり強い意味がないことだなぁと感じます。...アーキテクトは除外した話にしていますが、ディベロッパーに比べればアーキテクトの方はもう少し重視したいポイントではありながらも、"このフレームワークでしかアーキテクチャを構築できないアーキテクト"だと。ある人を重視しています。忘れてると...既存のシステムがあるとします。今のビジネス要求に耐えられない。フレームワークも刷新したい。画面作り始めますね」この開発で発生するジレンマが想像できます。既存のシステムからコピーしてくることも多いでしょう。フレームワークなども環境もガラリ変えてるから、そんな簡単にコピーもできず、わりと移植が大変でしょう。だいたい、その辺もメンテが大変だからこそリプレイス、って話もあったはず。そこが残ると結局同じじゃない?いや、全く同じとは言わないけど、リプレイスの目的を少し削られてるような。現地化ロジックが必ずあるちょっと気になった記事がありました。とあるコーヒーチェーンが、オーストラリア進出にうまくいかなかったという話。その理由の一つとして、他の地域でうまくいったメニューを現地化せずにそのまま導入していたという点が印象的でした。評論的な記事だったので実際にそうかどうかは別にして、とにかく現地化という言葉に、ふと考えさせられました。結局新しく覚えるルールや仕組みが多いなぁ、なんて思ったことありませんか?「なんとかcommon」ってプロジェクトあったりしませんか?独自のクラス自動生成ツールがあったりしませんか?また、そういった共通ロジックを、社内の別のプロジェクトにちょっと調整してコピーして使い回しているってありませんか?jfluteの経験では、それがないプロジェクトの方が珍しいなと。「OSSのフレームワーク」と「業務機能のロジック」しかないシステム、そんなのは見たことない。仕組みを代弁する冗長な手続きロジックがあるでしょう。それを避けるためにも、自然発生的にプロジェクト独自の共通の仕組みが作られるのです。ある意味では、非常に自然なこと。現地化ロジックは、フレームワークを使いこなすために発生する実装と、フレームワーク関係なく現場で必要な共通的な仕組み、に大別されます。それによって無駄な仕組みが生まれることもあります。使いこなしましょうという話はあります。現地化ロジックはそれなりに必要です。汎用的なフレームワークを現場にフィットさせるレイヤ、それをjfluteは「現場フィットレイヤ」と呼んでいます。確実に忘れさられます。世に名が知られている汎用的なフレームワークは、この現場フィットレイヤにはあまり手を出しません。いったものをフレームワークに含んでしまうと、とあるタイプの現場ではフィットするけど、とあるタイプの現場では邪魔なだけ、みたいなことが発生し、汎用性が失われるからです。正しいと言えば正しいこと。現場の要求は千差万別なので、その中でもできるだけ共通的なものだけを、フレームワークには入れたいものです。「複雑だ、重い、覚えること多い」というネガティブなイメージが付きやすいもの。関連ライブラリやオプションとして提供されたりします。現場に合わせて使いこなすためのプログラムが少しは必要になってきます。現地化ロジックを組み立てています。今後もずっと必要なものもあります。フレームワークを選ぶ時、ほとんどと言っていいほど、そこが忘れ去られます。新規サービスでも考慮する必要があるかもしれません。コピーだけじゃダメで移植作業が必要になるなものそれぞれ対応していかないといけないでしょう。そのための時間が必要になるでしょう。「新しいフレームワークでさあ画面作っていこう」では済まされないのです。フレームワークを選ぶときも、"新しいフレームワークの機能で置き換えられるもの"が多い方が、その部分のコストを軽減できるわけです。予定にないコストが発生するのは当然です。誰かがそこを無理して受け持つわけです。「リプレイスしたのにすぐまたリプレイスしたい」ものができあがってしまうのです。今までのその現場で実現されていた非機能要件が、デグレっている可能性もあります。「実は現地化ロジックを置き換えたいだけ」で、(汎用)フレームワークはあまり関係なかった...「既存システムで発生している課題は、ほとんど現場フィットレイヤから来ている」なんてことも。仮にフレームワークが良いものだとしても、ディベロッパーのストレスは高くなります。現場フィットレイヤの作りは、フレームワークの良さをいくらでもつぶせる逆もしかりです。良さを最大限引き出すのも現場フィットレイヤです。現場フィットレイヤという舞台が必要です。いまや、フレームワークは進化しました。極端な話、どんなフレームワークでも良い機能が得られます。非常に重要な時代になったとも言えるでしょう。...でも、みなフレームワークの話が好きです。そこばかり焦点を当てて議論をします。歴史は何度も何度も繰り返すことになります。歴史は繰り返すのでしょうか?jfluteは、この10年間に、こういった光景を何度も見てきて、そろそろ悲しみを抑えきれなくなったのかもしれません。以前に書いたブログの一部を焼き直しています。実績は世に出てこない永遠のテーマかもしれません。実はこれほど虚しいことはありません。社外に言いふらせるものではありません。言いふらそうと思うきっかけもないかもしれません。世の中に出て来ません。実績会社として紹介させてもらう、というような線もあるかもしれません。多くは、ダウンロードされておしまい。作者の方が、まさにこのジレンマを発表されていました。各自のPCでダウンロードさせたりしますから、ダウンロード数と現場の数というのが、いまいち比例しません。喉から手が出るほど欲しいものです。広めたいわけですから、その欲求は同じです。オープンソースプロダクトだと、その情報を手に入れるのは困難です。営業するにしても、どの会社に当たって良いのかもわからない。営業するコストがもろにポケットマネー。普段別の仕事している人が大抵ですから、そういう活動に時間は割けません。「実績は?」という質問自体に虚しさがあることがわかります。非常に無意味な質問に聞こえるからです。これは、そのツールを提案した人に限らず、オープンソースの作者だって同じ状況です。逆にめちゃくちゃ実績あるのかもしれない。「知ってるかどうか?」です。「聞いたことないツールだけど実績は?」というのが圧倒的に多いです。人間「知らないことは不安」という性質を持っていますので、当然と言えば当然です。聞いたことのあるツールに関しては、あまり実績を問わない傾向にあります。要は、先の通り世に実績情報がないので、ネット上や雑誌などで話題になっているか?そういったところに頼るしかないわけです。耳に入ってこないということは使われてない。問われる方が、そもそもそういう技術情報に敏感かどうか、というのも気にするところです。実は話題になってるんだけど、その話題をキャッチしてないだけとか。いせよ、実績という言葉が、わりとふわふわした論理で成り立っている、というのがポイントです。有名なオープンソースなら大丈夫だろうという結論に陥りやすいです。結局、有名でメジャーだから実績ある、という論理で落ち着くことが多いです。ゆえに、マイナーなオープンソースプロダクトは、メジャーなオープンソースプロダクトよりも、しっかりと説得力のあるセオリーを組み立てないといけません。有名というだけで、その義務が免除されやすいです。実績を気にして実績ないコードでも、jfluteはそこに危険な匂いを感じています。「システムは千差万別」という前提を押し隠すものになりやすいからです。...本来議論しないといけないことは、この現場にフィットするのか?ということなので、メジャーなツールを選んだとしても、それが、この現場にフィットするのか?フィットさせるためにどういうことをしたらいいのか?この議論が必要だからです。有償ツールだろうがメジャーOSSだろうが、マイナーOSSだろうが、この工程は必要なのです。さあ作り始めようこの流れをよく見かけます。行き着く先で見かけるものは...その「メジャーなオープンソースプロダクト」が可哀想だなぁ、という光景。本当はこうすればいいのに、なぜか自分たちでガリガリ書いてる。自分たちで作った独自の仕組みが積み重なっている。実績のないコードがそのシステムの中核を担っているそんな現場たくさんあります。そのコードが一概に悪いわけではなく、メジャーなオープンソースプロダクトではすんなり解決できない特殊な要件が、その現場あるならしょうがないわけで。いうことは往往にしてよくあります。選定の時に議論していないことも大きな要因です。は...あの一年前、二年前の「実績」にこだわった議論って、いったんなんだったんだろう?って感じるわけです。何も気にしないじゃダメじゃない?」と言いたくなるわけです。多かれ少なかれ必要だったりもするので、そこまで視野に入れた議論しないと。知っていることはあります。「御社の実績も他社に伝えてよろしいでしょうか?」と言わざるを得ないのです。その行動と覚悟がないのであれば、いたって矛盾した姿勢であるとも言えます。一般にあまり褒められる行為ではないですよね。気にするけどねとはいえ、もちろんjfluteも気にします。仕事においては、ギャンブルするわけにはいかないですから、その現場へのフィット感を探るために。適用しようとしている現場に似た現場で実績があるのか?という風にも考えます。実績があるとは限らないからです。システムというのは千差万別。よそでうまくいってるから、ここでうまくいくとは限らないし、よそで失敗してるからって、ここで成功しないとは限らない。一方で実績といってもその程度の判断材料でしかない、という感覚も忘れません。気にするからには、できるだけ情報を公開できるよう努めます。情報公開することによる会社のメリットを確立させつつ(ブランド力のアップなど)、ツール側もメリットが得られるように。きっかけになるはずで。情報公開をビジネスにしないと。理解をして頂けました。プログラマーもそういう提案や行動していかないと、この問題はなかなか解決しないと思います。オープンソースを知ろうこの手の話は尽きません。似たようなジレンマ話を聞きます。「実績は?」と聞く人が悪いわけではありません。気にするのは当然のことなので。オープンソースというものを知らないだけ。jfluteは、今後同じような話になったら...「このブログをまず読みましょう!」と提案します。そのために書きました。同じ話をし続けて来たからです。多くの人に理解してもらっています。「その現場ではオープンソースを使うべきではない」という話に落ち着くだけです。いうビジネス判断も悪くはないでしょう。オープンソースたちも、ちゃんとわかって使ってもらいたいはずです。