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

2018-05-20

DBFlute Intro-0.2.1 Released

|

DBFlute Introのリリースです。

Decomment (でこめんと) の改善、
そして、Hacomment (はこめんと) の登場です!
(今回の機能は、DBFlute-1.1.8 と
組み合わせることで利用できます)
 => DBFlute-1.1.8 Released

そもそも Decomment (でこめんと) とは?
という方はこちらのページを:
 => Decomment (でこめんと) on Intro

DB変更による置き去り回避

Decommentでコメント登録後に、
DB変更でテーブル名やカラム名が変わると、
そのDecommentが置き去りにされてしまいました。

Introの新しいバージョンでは、
それを検知してマッピングできるようにしました!
(かぼマッピング)
 => テーブル名が変更されるとどうなる?

もし、その状況が発生した時は、
SchemaHTMLの上部の目立つところに、
マッピングのためのリストボックスたちが表示されます。

これで安心して利用することができますので、
どんどんDecommentしていきましょう。

gitブランチ名を活用

Decommentで、コンフリクトしたとき、
gitのブランチ名を表示するようにしました。
こうすると、何と何でバッティングしたのか、
よりわかりやすくなるはずです。

もちろん、gitが入ってない環境であれば、
その処理は無視されて正常に動作します。

# こちら、昨年の DBFluteフェス2017 での、
# コミッターの "でこちゃん" の発表の時に出た、
# ユーザーの方からの発想です。
# しっかり約束守りましたね!(^^

HistoryHTMLでもコメントを

さて、こちら新機能!

HistoryHTMLでもコメントを
登録できるようになりました。

Hacomment (はこめんと) と呼びます。
 => Hacomment (はこめんと) on Intro

HistoryHTMLは、DBFluteが自動で作成する、
DB変更履歴ドキュメントですが...

"この日のDB変更は、どういう理由のものだっけ?"
"この日のDB変更は、スプリントいくつ?"

などなど、もっと業務的な情報も、
HistoryHTMLに置いておきたいものです。
そこで、Hacomment機能を使うと、
HistoryHTML経由でどんどんコメントを
残しておくことができます。

こちらも、Decommentと同様に、
gitコンフリクトが起きないような仕組みなので、
トピックブランチでもどこでも、
気軽にコメントしていくことができます。

使い方も、要領はDecommentと同じです。
DBFlute Intro経由でHistoryHTMLを開き、
それぞれの "Diffのタイトル" 付近で、
クリックしてみてください。

ぜひ、HistoryHTMLにもコメント書いていきましょう!

Introのアップグレード方法

DBFlute Intro は、
Manageタスクで 88 (intro) を選択すると、
自動的に最新版がダウンロードされます。

すでにダウンロード済でも、
ローカルにあるのが古いバージョンであれば、
自動的に判別して上書きしますので、
アップグレードは非常に簡単です。

ただ、手動でダウンロードして利用している場合は、
新しいバージョンも手動でダウンロードして、
差し替える必要があります。
(そこも自動でアップグレードできるように、
どうにかしたいですねぇ...)

Introコミッターたち!

今回の DBFlute Intro の実装は、
jfluteはほとんどやっておらず...

DBFlute Introコミッターの若者たち、
"チームいんとろんずおん" が、
リリース作業まで自分たちでやり遂げました。

jfluteは、プロダクトオーナー的な立ち位置で、
機能デザインなどのアドバイスやテストなど、
ファシリテーションに徹しました。

これだけの機能を自力でリリースできる、
ってすごいことですよ。
紛れもないオープンソースプログラマーたちです。

かぼす、でこちゃん、はきば、ありがとう!

f:id:jflute:20180507175246j:image

2018-05-19

DBFlute-1.1.8 Released

|

Java8対応のDBFluteのリリース。
DBFlute-1.1.8 です。

Change Log | DBFlute
(1.1.8からの移行の注意点は特になし)

今回は、Alto DBFlute周りが、
大きく改善されています!

SchemaHTML

テーブル作成日、カラム作成日が、
表示されるようになりました!
 => SchemaHTMLのExample

もともと HistoryHTML を見ればわかることでしたが、
やはり、SchemaHTML上でパッとわかったほうが、
活用されることも多いでしょう。

直接的に役立つ情報ではありませんが、
"このカラム...後から追加されたんだ、なるほどだから..."
って、何かDBに関して迷うことがあったときに、
役立つかもしれません。

...

さて、Decommentの大きな改善に関しては、
DBFlute Introリリースブログでお知らせします。

その他、小さな修正です。
DBコメントにHTMLエスケープ文字(<)が入ってると、
HTMLタグに展開されて表示されていたのを修正しました。

HistoryHTML

まず、デザインを修正!少しだけ見やすくなった...はず。

そして、DB変更の "作者" と "gitブランチ名" が、
表示されるようになりました!
 => HistoryHTMLのExample

作者は、Systemプロパティのuser.nameより、
gitブランチ名は、gitコマンドから。
(もちろん、gitを使ってない環境なら素通りです)

DB変更の履歴はどんどん積み上がってきますが、
"誰が、どのブランチで?" ってのがわかると、
迷ってることが解決しやすいかもしれません。
(ブランチ名がチケット名になっていれば、
実質的にチケット番号になりますし)

また、HistoryHTMLの自動生成スピードが上がっています。
今まで、Historyがたくさん積み上がると、
Docタスク自体が何秒もかかってしまっていたのですが、
大量Historyに関するパフォーマンス劣化は、
ほとんどなくなりました。
もし、"Docタスクで30秒くらいかかる" とか、
感じている方いらっしゃいましたら、
ぜひ 1.1.8 にアップしてみてください。

内部的には...
古くからあった MapListString の代わりに、
新しく作った DfMapStyle を使っています。
今後、他の "mapスタイル" のファイルの読み込みでも、
DfMapStyle の方を使っていく予定です。

...

さて、大きな新機能、Hacommentに関しては、
DBFlute Introリリースブログでお知らせします。

その他、小さな修正:
o DBコメントにHTMLエスケープ文字(<)が入ってると、
HTMLタグに展開されて表示されていたのを修正

SchemaPolicyCheck

まず、SchemaPolicyCheckって何?
のために、概念ドキュメント作りました!
 => DB設計のチェックスタイル (SchemaPolicyCheck)

そして、今回の改善の目玉は...

運用途中からでもチェック書けやすくなった!

に尽きます。

既存テーブルでチェックかかりまくってしまう問題、
これで新しいテーブルもチェックが外れちゃう...
というジレンマありました。
ですが、こんな条件が書けるようになりました。
# 2018/05/19より未来に追加されたテーブルは、
# FK制約名は FK_[テーブル名] で始まること
; if firstDate is after:2018/05/19 then fkName is prefix:FK_$$table$$
ドキュメントでも紹介しています。
 => 運用途中からの導入

とある日付から未来に追加されたテーブルやカラムだけ、
...なチェックをする、ということが可能に。
既存テーブルは置いておいて、これからはこうしていこう!
ということができるので、もっと気軽に適用できます。

それに伴って、
いままで theme だけでしか指定できなかったチェックが、
statement でも表現できるように改善が行われています。

o hasAlias, hasCommentなどが statement でも
o same...IfSame... が statement でも

その他、細かい改善が行われています。

o ドットつなぎの tableColumnName が利用できるように
o if columnName is $$table$$_ID と表現できるように
o if alias is $$tableAlias$$ID と表現できるように
o then columnName is $$table$$_ID と表現できるように
o then alias is $$tableAlias$$ID と表現できるように

ぜひ、SchemaPolicyCheckで、
良いDB設計ライフをお過ごしください()^^。

ConventionalTakeAssert

ReplaceSchemaで、
テストデータが一件も入ってなかったら落ちる...
という ConventionalTakeAssert ですが、
こちらもやはり、運用途中から適用が難航していました。
すでにテストデータのないテーブルがたくさん!

ということで、ここでも firstDate が使えるようになり、
; onlyFirstDateAfterTargetDate = 2018/05/19
とすると、その日付以降に追加されたテーブルだけ、
チェック対象とすることができます。
    # /- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    # o conventionalTakeAssertMap: (NotRequired - Default map:{})
    #  Does it assert data by conventional rule in take-finally
    #  For example, you can check empty table (no-data).
    #
    ; conventionalTakeAssertMap = map:{
        ; emptyTableMap = map:{
            ; isFailure = true
            ; workableRepsEnvTypeList = list:{ut}
            ; tableExceptList = list:{}
            ; tableTargetList = list:{}
            ; onlyFirstDateAfterTargetDate = 2018/05/19
        }
    }
    # - - - - - - - - - -/
テストデータ、しっかり入れていきましょう!

simpleDtoDefinitionMap

SimpleDtoを自動生成する機能があります。
 => (転送用の)シンプルなDTO

ここで、テーブルや外だしSQLごとに、
自動生成の除外や対象を指定できるようになりました。

o tableExceptList/tableTargetList
o sql2entityExceptList/sql2entityTargetList

DBFluteユーザの集いメーリングリストで、
要望を頂きました。
 => SimpleDtoの生成範囲に関して | DBFluteユーザの集い

SimpleDtoのご利用ありがとうございます!
(マニアックな機能ですけど、使われているもんですね^^)

Spring + HikariCP

SpringFramework + DBFlute で、
HikariCP を利用する時に、
自動でトランザクション制御が行われるようにしました。

今まで、commons-DBCP と Tomcat-DBCP だけが、
自動制御の対象だったので、他のDBCPを使う時は、
"一手間だけ" 必要でした。
今回、その一手間を省けるDBCPが増えました。

こちらは、ユーザーの方のフィードバックで、
コードレベルで指摘をしてくださいましたので、
本当に助かります。
taktosさん、ありがとうございます!
(ついでに!? commons-DBCP2 も対象になっています)
 => HikariCPへの対応依頼 | DBFluteユーザの集い

ただ、そもそもの構造を変えて、
どんなDBCPだろうが自動制御できないか!?
まだ議論が続いています。
TransactionAwareDataSourceProxy を、
うまく組み込めたらいいですが...

ついでに、DBFluteのSpringページが、
だいぶ古くなっていたので刷新しました。
 => Spring Frameworkの取扱い

LastaDoc

LastaFluteの自動生成ドキュメントLastaDoc,
 => Actionのドキュメント自動生成 (LastaDoc)

のデザインを微調整しました。
(少し見やすくなったはずです)

また、lastafluteMap.dfprop にて、
LastaDocの表示内容を少しだけ
微調整できるようにしました。
とりあえず、Action一覧のdescriptionを
非表示にできるように。

LastaDocを、オフィシャルドキュメント的に使う想定で、
その辺を調整したいという要望がありました。

オープンソース全文検索サーバー Fess にて、
LastaDoc が大いに活用されているようです。
 => Fess の LastaDoc

LastaFluteの特徴の一つですね(^^

Oracle, BLOB in プロシージャ

Oracle で、ストアドプロシージャの引数で、
BLOB型を使っている場合に、
大きなサイズのbyte配列を指定すると、
エラーになってしまう問題を修正しました。

なんと、そういう場面でもDBFlute使われてるんですね(^^。
フィードバックをくれた awaawa さん、ありがとうです。

また、今後そういった場面が他の箇所でもあるかもしれないので、
プラグインのvalueTypeとして、
"bytesBlobType" を利用できるようにしました。
いざとなったら、これを指定すれば、
何かBLOB周りで発生した問題を回避できるかもしれません。

その他、細かい修正

o 組み込んでいる H2 database を 1.4.197 にアップ

o Runtime の DfStringUtil.count() のパフォーマンス改善

o DBコメントに、バックスラッシュが入っていると、
自動生成されたクラスがコンパイルエラーにならないように

ユーザーがいるからリリースできる

様々なユーザーの方の協力のもと、
リリースできたバージョンと言えるでしょう。

本当に、ありがとうございます。

古いドキュメントを少しずつ改善していこうかなと
思っています。これからもよろしくお願いします。

f:id:jflute:20180511161644j:image

2018-04-01

DBFlute-1.1.7 Released

|

Java8対応のDBFluteのリリース。
DBFlute-1.1.7 です。

Change Log | DBFlute
(1.1.6からの移行の注意点は特になし)

今回は、dfprop で新しいプロパティ多く追加されています。
でも、それらどれも非常にマニアックではありますが...

# DBFlute Runtime, DBFlute Engine
# 両方ともアップグレードしないと、
# 自動生成クラスでコンパイルエラーになりますので、
# 両方のアップグレードお忘れなく。

repsAsDataManagerMap

replaceSchemaMap.dfpropにて指定できます。
ReplaceSchemaをデータ登録としてだけ使うことができます。
例えば、Flywayと連携する時に使えるかもしれません。
# flyway creates schema by own-managed DDL so replace-schema becomes data manager
; repsAsDataManagerMap = map:{
    ; isUseRepsAsDataManager = true
}
でも、Flywayを使う時に、
必ず使うかというとそうではないと思います。
ローカル環境ではフルのReplaceSchemaで、
サーバー環境ではFlywayを使う、という風な住み分けに
なっていればこの機能は不要です。

ローカルでもFlywayを使うけど、
テストデータはReplaceSchemaを使いたい、
というような時に利用します。

databaseSubType

basicInfoMap.dfpropにて指定できます。
例えば、SQLServerを使うにしても LocalDB だと、
またちょっと動きを変える必要が出てきたりします。

具体的には...
ストアドプロシージャーやVIEWのdrop文で、
データベース名の修飾を付けるとエラーになるとか。
(将来変わるかもしれませんが)

そんなとき、subTypeOnDatabase に、
localdb と指定しておくと、
LocalDB用の挙動になってくれます。
    ; database = sqlserver
    ; subTypeOnDatabase = localdb
対応はまだちょっとだけですが、
将来的に色々と「同じDBでも種別によって違う」が
増えてきた時に、このプロパティを利用していきます。

take-finally.sh

ReplaceSchema の take-finally にて、
スクリプトが利用できるようになりました。

大量データ登録など、
DBMSネイティヴコマンドを利用したい時に使えます。
Windowsなら.bat, Mac/Linuxなら.shです。

// TakeFinallyで外部スクリプト
http://dbflute.seasar.org/ja/manual/function/generator/task/replaceschema/takefinally.html#outsidescript

conventionalTakeAssertMap

replaceSchemaMap.dfpropにて指定できます。

例えば、ReplaceSchemaにて...

"テストデータが一件もないテーブルがあったら落ちる"

というチェックをかけることができます。

テストデータなしで新しいテーブルが
どんどん追加されるのを防ぐことができます。
(最低でも一件はデータを作ってテーブル追加)
    # /- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    # o conventionalTakeAssertMap: (NotRequired - Default map:{})
    #  Does it assert data by conventional rule in take-finally
    #  For example, you can check empty table (no-data).
    #
    ; conventionalTakeAssertMap = map:{
        ; emptyTableMap = map:{
            ; isFailure = true
            ; workableRepsEnvTypeList = list:{ut}
            ; tableExceptList = list:{}
            ; tableTargetList = list:{}
        }
    }
    # - - - - - - - - - -/
tableExceptList で除外もできるので、
既存テーブルを指定して、途中から運用するというのもできます。
また、一時テーブルで0件じゃないといけないものも指定できます。

deprecatedSelectByPKUQMap

littleAdjustmentMap.dfpropにて指定できます。
selectByPK(), selectByUniqueOf() を、
非推奨にするオプションです。

あんまりやらないと思いますが、
SpecifyColumn を必須にしている現場だと、
自動的に全カラムspecify()になってしまう
selectByPK()が困るということで、
このようなオプションが設けられました。

deprecatedSpecifyBatchColumnMap

littleAdjustmentMap.dfpropにて指定できます。

deprecatedSelectByPKUQMapと同様で、
SpecifyColumn を必須にしている現場だと、
specify().everyColumn()されたら意味ないので、
このようなオプションが設けられました。

細かい改善していってます

他にも細かいのありますが、
DBFluteもまだまだこういった細かい改善が
求められています。

昨年はあまりリリースできませんでしたが、
今年はちょくちょく改善をリリースしていきたいと思います。

2018-03-18

「ニュアンス」と「エンジニアの心得」という新卒研修のお仕事

|

昨年、2017年に、とっても意外で、
とっても嬉しかったことと言えば、
jfluteとしては、こちらですね。

「”価値あるサービスを生み出すエンジニア”になるために」
新卒エンジニア研修を全公開!
| REACH ONE ビズリーチのイマとこれから

新卒が成長して新卒研修を

入ってくる新卒スキルの前提や、
会社としての状況の変化から、
新卒研修自体の形が変わってきて、
講義形式から実践形式に変わってきました。

というか、もともとそういうのもやりたいね、
でもフォローできる体制がなかなか整わない、
というところでしたが...

新卒研修を受けた新卒が成長して、
自主的に新卒研修の運用をしていく

これが年々しっかりと積み重ねられて、
jfluteも驚くくらい自己組織化されていました。
(素晴らしい...)

ということで、
「そろそろ俺もあまり出番ないかな」
と感慨と寂しさの狭間にいたのですが...

「jfluteさんの話は新卒に聞いて欲しい」

と、言ってくれて、(わりと)急遽、
週一でお話することになりました(^^。

ニュアンスの技術話

実践に寄った分を補完するように、
もう少し高度な技術のお話、
現場ニュアンスを含んだお話、
をさせて頂きました。

具体的には...

o DB設計の実践とjfluteレビュー
o 例外ハンドリング徹底(例外の翻訳)
o オブジェクト指向の補足
o Lambda式、Stream API, Optional 
o map()とflatMap()の違い
o DIコンテナとは?
o フレームワークとは?
o オープンソースとは?
o レビューしやすいコードとは?
o 素早い操作をするためには?

基本的には、新卒研修担当の方からの要望ですが、
その場で新卒たちの理解度見てのアドリブもあり。

これらを「現場では...」とか、
「こういう解釈の人もいるし、こういう...」とか、
「歴史的にはこうなってからこうなった...」とか、
様々なニュアンスと一緒に理解していくのが、
jflute流です。そこ大切に思ってくれるのは嬉しい。

また、できるだけ、
「ソースコードを読む意識が付くような説明」
を心掛けています。
何かと「ctrl+クリック」して奥のコードを読んで、
「だからこうなっているんだよ」的な感じで。
JavaAPIだろうが、ライブラリだろうが、
ちょこっとコードを覗いて確認をするのが当たり前、
という風なのが少しでも伝わればと。

個人的には、オープンソースってなに?ってのを、
この段階からしっかり知ってもらうことも大切だなと。
まあ、オープンソースプログラマーですから、
オープンソースのお話いくらでもしますよ^^。

エンジニアの心得「よもやま話」

「よもやま話」と呼んでいて、
一日の最後に、ひとつお話をします。

jfluteの日記からピックアップして、
ブログを紹介するわけですが、
jflute本人から色々なエピソードなどを交えて、
ニュアンスとともに心得を伝えていきます。

これは数年前からお約束のようにやっていて、
ぶっちゃけ勝手に(!?)やっていたわけですが、
これをぜひ「新卒には聞かせたい」と、
前の新卒たちが言ってくれたわけです。
そんな風に思ってくれていたなんて、
涙出るほど嬉しいことですね。

さて、2017年は何をやったかな?
記録を見ないと思い出せないので見てみると...

// 答えよりも答えを導くプロセスhttp://d.hatena.ne.jp/jflute/20110530/1306729010

// エラーメッセージ読め読め大合唱
http://d.hatena.ne.jp/jflute/20130522/errorsinging

// ドキュメントを無料(タダ)だと思っている?
http://d.hatena.ne.jp/jflute/20170402/documentfree

// SIとスタートアップの違いを知ろう
http://d.hatena.ne.jp/jflute/20151007/sista

// 技術的負債の返済プロジェクトが失敗する 11 のワケ
http://d.hatena.ne.jp/jflute/20170211/deptagain

// 独学のきっかけ、技術欲、問題解決欲、自己成長欲
http://d.hatena.ne.jp/jflute/20160210/selfgrowth

// 質問のコツその一: なんでその質問してるのか?も伝えよう
http://d.hatena.ne.jp/jflute/20170611/askingway1

// 90パーセント終わりました、って何パーセント?
http://d.hatena.ne.jp/jflute/20110702/whatninety

// プログラマーに求められるデザイン脳
http://d.hatena.ne.jp/jflute/20170623/desigraming

// 既存コードの甘い匂い (悪意なきチグハグコードの誕生)
http://d.hatena.ne.jp/jflute/20160203/existingcode

// 成長するかしないかは選べる
http://d.hatena.ne.jp/jflute/20160316/selectgrowth

// こうはい extends せんぱい
http://d.hatena.ne.jp/jflute/20131124/extendsmaster

// サービス開発者は、それ必要?いつ必要?スキルが求められる
http://d.hatena.ne.jp/jflute/20170708/servicepriority

// レスポンスのある人は信頼される
http://d.hatena.ne.jp/jflute/20170828/responsetrusted

結構ありました笑。
一日一回だけでなく午前終わりで時間が空いたとき
とかにもやっていたようです。

でも、これでも取捨選択しています。
その前の年からしたらしゃべる機会が少ないので、
毎日の恒例みたいな感じにはできないので厳選しました。

でも、また新しくブログ書いてあるから、
厳選も変わってくるかもしれませんね。

一生懸命やっていれば驚けるよ

あと、DBFluteハンズオンも入ってます。
最初のさわりだけでも全員で。
厳密には、配属次第でDBFlute使わない人も
多くなってきているのですが...
(そもそもJavaじゃないって人もいるし)

o DBFlute自体から学べる思想やノウハウ
o ハンズオン自体から学べる技術力

これを買ってくれたようです。
そのように作ってきたつもりですから、
よりいっそう嬉しい驚きです。

...

また、新卒研修を受けた方々から、
DBFluteオープンソース活動を
手伝ってくれる人たちも出てきてくれたこと、
これまた予想外の嬉しい...

...

まだあるよー。
「考え方もオープンにしたい」ってことで、
整理整頓も兼ねてブログしっかり書いてきたら、
こんな風に自分の仕事に役立つなんて!
書いてるときは、思いませんよそんなこと。

...
...
...

「新卒研修、頑張ってきて良かったんだなぁ」

ちょっと個人的な感傷ですが、
そういう風に言えるって幸せだなと。
なんか本当良かったなぁって。

一方で、昨年は伝えるチャンスが少なかったですから、
どれだけ響かせられるかって非常に不安で怖かったです。
チャレンジャーのつもりで集中していたと思います。
それで新卒自身に紹介記事のようなこと書いてもらえて、
ああ、良かったぁってホッとしてます笑。

今後も色々な変化があると思いますから、
こういうのいつまでできるかわかりませんが、
いつでもチャレンジャーの気持ちは
忘れないようにしたいなと。

...

何ごともそうですね。
最近ひしひしと感じます。

一生懸命やっていれば予想もしない形で、
積み重ねが嬉しさになって跳ね返ってくるよ

その驚きを楽しみに、
目の前のことに集中したら、
いいんじゃないでしょうか?

f:id:jflute:20180101154931j:image

2018-02-23

まず何より、目の前の道具を使いこなしてください

|

チャーハンまだ?

あなたが中華料理屋の料理人になったとします。
まだ料理は初めて、これから学びます。

さて、少しだけ学んだので、
チャーハンを作ってお客さんに食べてもらいます。
もちろん、お金をもらっています。
まだあんまりおいしくはないです。
評判も悪くクレームも来ます。

チャーハン自体に画期的工夫が必要とか、
お客さんの好みが変わったとかではなく、
単純にまだ普通のチャーハンすら、
まともに作れてないだけです。
先輩が作ればちゃんと喜んでもらえます。

「色々な料理を作ったほうが良いから、
ショートケーキを作る練習しよう」

...
...

「いや、お前チャーハン作れよ」


「いやいや、ショートケーキを作ることで、
また違った世界の味覚や調理方法を学べて、
別角度からチャーハンを見つめ直すことができて、
チャーハンがおいしくなるかもしれないし、
画期的工夫でチャーハンがおいしくなるかも!?」


「いや、まずはチャーハン作れよ」


「いやいや、普段の業務チャーハン作っているので、
自主トレでまたチャーハン作るのは飽きちゃうから、
別のことしたほうが気晴らしになって楽しいし」


「いいからチャーハン作れよ」


「いやいや、実はチャーハンはあまり好きではなくて、
ショートケーキを作る方が圧倒的に楽しい。
ショートケーキ最高!(^^/」


チャーハン作れよ」

魔法の言葉の程度の問題

「色々な言語を書いたほうがいいよ」
「色々なフレームワークを使ったほうがいいよ」
「色々なエディターを使ったほうがいいよ」

つまり...

「色々なことをやったほうがいいよ」

その通りだと思います。
先の料理人の言う通り、違う世界を見ることで、
目の前の世界を違う角度から見つめ直すことができて、
結果的に目の前の世界を良くすることにつながります。

でもそれは、
目の前の世界を "ある程度" 知ってるから、
別の世界と比較して新しいものが見えるわけで、
そもそもチャーハンもよくわかってなかったら、
ショートケーキを作ることによるチャーハンへの
フィードバックはほとんどないでしょう。

もちろん、ショートケーキ単独で
学べることは大いにあります。
それが記憶になって、
後のフィードバックにもなるかもしれません。

でもまだ、お金もらっておきながら、
おいしいチャーハン作れてないですから...

浅い学びのつまらなさ

「すでに仕事で使ってるものを
勉強してもつまらない」

という声もよく聞きます。
これもある程度はその通りなのですが...

本当にチャーハン作りの楽しさを得たでしょうか?
まだ浅いところしか見てないから、
つまらないだけじゃないでしょうか?

どのようなものでも奥深い世界があります。
突き詰める人は物事の深淵に感心します。

ある程度書けるようになったら、
もうこのプログラミング言語はつまらない?
ある程度使えてるから
もうこのフレームワークはつまらない?

もっと追求すれば楽しいことは幾らでもあります。
逆に、その追求による楽しさがわからなければ、
別のことをやっても浅い楽しみしか得られず、
またすぐに飽きるでしょう。

もちろん、それでも、
別の世界の楽しみを探すことに意義はあります。
大いに意義があります。ぜひとも!

でもまだ、お金もらっておきながら、
おいしいチャーハン作れてないですから...

プロ意識はどこへ?

「別のツールのほうが好きで...」

お金をもらってチャーハンを作っているのに、
まだおいしいチャーハンを作れないことの
許される理由になるでしょうか?

お客さんはそんなこと知りませんし、
お店だって知ったことではありません。
同僚だって知ったことではありません。
プロの料理人として誇れることでしょうか?

明日にでも、そのお仕事を辞めたらどうでしょう?
ショートケーキ作りの道に行ってみては?

ただ、"そうもいかない" というのは確かにあります。
生活ができなかったらしょうがないですから。

でも、目の前のお客さんを喜ばせられない、
喜ばせる努力ができない人が、
ショートケーキの世界に行って成功するか?

もちろん、向いてる向いてないがあるので、
厳密にはショートケーキなら大成功の可能性もありますが、
プロ意識の薄いパティシエになりそうで心配です。

そうまだ、お金もらっておきながら、
おいしいチャーハン作れてないですから...

お店のために!?

「先輩に付きっきりでフォローしてもらえば、
お客さんに喜ばれるおいしいチャーハン作れます!
なので、お店のために毎回そうしています!
三年くらいずっとそうやって貢献しています!」


早く先輩を解放してあげてください。

目の前は学びの宝庫

仕事で使っているツールから得られる学び、
それは非常に大きいものです。

なぜかというと、本気の実践で使っているからです。
本気の実践で使っているそのツールの「様(さま)」を、
しっかり見ることができるからです。

個人ではなかなか...

400テーブルのDB設計はしませんし、
1000万件データにクエリを投げることもないですし、
100画面作ることもないですし、
アクセス負荷に悩むこともないですし、
多様な決済機能を備えたりもしませんし、
凝ったキャッシュ戦略を実装することもありませんし、
複数人での開発をすることもありません。

多少、狙ってやることはあるかもしれませんが、
仕事では厳しい要求の中でツールが活躍しています。
そのツールの真価が問われていて、
そのツールの本質を知るきっかけも多いです。

もちろん、破片プログラマー になりやすいので、
個人の小さな環境で何かを作ることに意義はあります。
そして、とても大きな意義です。
仕事の大きすぎる環境だとだと試せないことを、
個人の小さな環境だと試せることもあります。

でも、まずはショートケーキじゃなくチャーハンで、
プレッシャーなしで色々と試行錯誤したり、
世のチャーハンのレシピを調べたり、
自宅の小さな設備で作って苦労してみたり、
などなど、
本番のチャーハン練習チャーハンで比べることで、
チャーハンの本質を知ってみてはどうでしょう?

そうすると、ショートケーキを学ぶときも、
チャーハンの本質とショートケーキを比べられて、
ショートケーキの本質に早く辿り着けるかもしれません。

少なくとも、それをやらないということは、
「仕事場という目の前にある豊富な学びをスルーする」
ことになるのです。

転職すると前の現場を見ることができません。
その仕事場を見て分析できるのは、
"いま" しかないのです。

できる人は使いこなしてる

常に色々なことを学んで、
色々なツールに長けている人がいます。
jfluteの身の回りにたくさんいます。
若い人も含めて。すごいですね。

でも、彼らはみな、
目の前のツールもちゃんと使いこなしてます。
そのための勉強も実はしていたりします。

それがその人にとってキライなツールだったとしても、
仕事で使うことになって避けられない以上は...

「なるほど、これこうすればこうなるんだな」
「あー、わかった、こうなってるからこうなんだ」
「しょうがなく勉強してきたよぅ、まあ大体わかった」

とか言って、ちゃんと詳しくなってたりします。
本当にキライなのか?って疑いたくなったりもします。
聞くと「俺これイヤなんだよね」って言うわけですが、
でもその人が誰よりも詳しかったり...。

その土台がある上で別のことも学ぶから、
得られる相乗効果が非常に高く、
好きなツールもキライなツールも、
どちらの習熟度も上がっていくの繰り返し。
プロの技...というかプロの立ち回りでしょうか。

...

ちなみに、昔々の時代に一緒に仕事をしていた、
jfluteが心から尊敬する二人を思い出します。
彼らは本当にそんな感じでしたね。

お金もらってやる以上は、
要求を超える品質を目指して行動する

あー、自分も頑張らねば...
ってブログ書きながら背筋が凍ってきました。

程度の問題という問題

たぶん、そんなことはわかっている、
という人も多いでしょう。

本当にチャーハンを極めようとすると、
もしかしたら10年以上かかるかもしれません。
ラーメンも極めなきゃいけないかもしれません。
パティシエに転職したいなら、
確かにどこかでちゃんとショートケーキに
時間を当てないといけないかもしれません。

なので程度の問題です。
でも程度って線引きが曖昧だから判断がしづらい。
バランスをどう取るか?
そこは個人プロ意識に委ねるしかありません。

ただ、いま時代のプログラミングの世界は、
変化も激しく選択肢も要求もあまりに多様化していて、
その辺のバランスを崩しやすいとも思っています。

少なくとも、jfluteの身の回りで、
それを感じることがたくさんあるのです。
チャーハンの話がたくさん感じるのです。
若い人でもそうですし、
ベテランでも感じることがあります。

「自分これは詳しくないので...」

役割分担という言葉が通じないほど、
さすがにそろそろ詳しくないとダメでは?
なんか詳しくなろうとしてないだけでは?

【追記】
ツールの選定や技術的負債の返済でも、
このことが影響してきます。
目の前のツールを使いこなしてないのに、
新しいツールを使ってハッピーになれるのか?
目の前のツールを使いこなしてないだけで、
別に技術的負債ではないかもしれないのでは?。

おいしいヒント

とはいえ、
「正解はこうだよ」というのも、
なかなか言えません。

ここでは、プログラミング言語や、
フレームワークエディターなど、
よく触れるツールをイメージしていますが、
他にもあるかもですね。まあ多いですよね。
目の前もカラフル過ぎて大変です。誘惑も多い。

究極、どういうスキルロードを辿るかは
個人に委ねるしかないです。


でも、一つのヒントとして、

目の前の宝庫を見逃すなよ


あとそもそも...

まずは、おいしいチャーハン作ろうよ

ですかね。

f:id:jflute:20180129171949j:image

sunaowamutekisunaowamuteki 2018/04/16 09:28 「お前はお客さんか」っていう後輩や研修生はちょくちょくいる。教える側より教わる側のほうがモチベ低いのは当たり前。でも、教える側の方がロマンを持って取り組めるから得じゃない?あれ、ちょっと偉そうなコメ?

jflutejflute 2018/04/16 12:04 sunaowamutekiさん、こんにちは。
コメントありがとうございます。確かに、教える側の方がすでに色々な経験をしている分モチベーション高くなりやすいですよね(まあ現状維持に行っちゃう人もいますが...)。ロマンを持って取り組めるかどうかってのは重要なキーワードだなと思いました(^^。