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

2017-04-05

任せられるディベロッパー、七つの姿勢

|

o その一: 自分の道具は使いこなす
o その二: 三割でも仕組みに突っ込む
o その三: 三割でもビジネスに突っ込む
o その四: 全体を把握しようとする
o その五: ベストタイミングほうれん草
o その六: 隣の人を助ける
o その七: 答えやすい質問をする

ここでのディベロッパーは、
システムの開発現場で業務プログラミングをしている、
まさしく現場のITエンジニアを指します。

マネージャーとかリーダーとかアーキテクトとか、
どちらかと言えば何か特別な立場ではなく、
まさしく最前線で戦っている開発者。
(もちろん兼任してることはあるだろうけど)

jfluteと一緒に仕事してきた優秀なディベロッパー、
jfluteが他の人から伝え聞く優秀なディベロッパー、
jflute自身の長年のディベロッパー経験、
これらのことから、
「任せられるディベロッパーってなんだろう?」
というのを、ちょっとまとめてみました。

その一: 自分の道具は使いこなす

任せられるディベロッパーは、
IDEテキストエディタはもちろん、
使っているフレームワークもしっかり押さえる。

「入社までになんちゃらツールを勉強してきました」
「自分この辺弱いからいま猛勉強してるんですよね」
というセリフを平気で言う。完璧は無理でも、
必要最低限ちゃんと把握して使おうとする。

だから、"知ってりゃすぐ解決するのに!"
っていう問題でハマったりはしない。
へんてこりんな回避策でお茶を濁さず、
フレームワークの思想に沿ったスマートな実装をする。
わからなければ検証するし、有識者に質問する。

ショートカットキー、補完は当たり前のように使って、
自分の作業からノイズを減らす努力を惜しまない。

見ていて気持ちが良いのでぜひ一緒に仕事がしたい。

その二: 三割でも仕組みに突っ込む

任せられるディベロッパーは、
仕組み部分のコードも追っかける。

さすがに全部は追っかけられないにしても、
いま直面している問題の解決を探るために、
焦点を定めてフレームワークのコードを
追うことに躊躇はない。
オープンソースに対する姿勢もよくわかってる。
 => ドキュメントを無料(タダ)だと思っている?

だから「自己解決力が段違い」である。
エラーメッセージやスタックトレースから、
しっかりと分析と推論ができる。だから読む。
 => エラーメッセージ読め読め大合唱

フレームワークの空気を読み取って、
求められている自然なコードを実装する。
なのでレビューする側も力まなくて良い。

わからなくても三割突っ込んでるので、
質問されても話が早い。すぐに相談は終わる。
少し難しい問題でも、人の手を借りながらも、
自己責任的に解決ができる。

話してて違和感がないのでぜひ一緒に仕事がしたい。

その三: 三割でもビジネスに突っ込む

任せられるディベロッパーは、
ただ作ってと言われたものを作るだけじゃない。

その作ろうとしているプログラムが、
業務的にどんな役割を持っているのかが気になる。
なので、変な要求が来ても疑問を呈して、
業務のレビューワーにもなってくれる。

「この機能を作って欲しいのですが...」
「了解です、でもこっちの機能のほうが
 先にできた方がうれしいですよね?」
ディベロッパー自らが業務的な優先度を調整できる。
実装をお願いしても間違った方向に突き進む心配が少ない。

安心ができるのでぜひ一緒に仕事がしたい。

その四: 全体を把握しようとする

任せられるディベロッパーは、
全体のことを考えて判断をしようとする。

局所的な最適と全体的な最適のバランスを掴むために、
全体を把握しようとする。ぜんぶは無理でも、できるだけ。

そして、わからないにしても、
"全体がわかってないから判断できない" という判断をし、
要因を周りにヒアリングしてから判断する。
局所で勝手な判断をしないようにしているようだ。

見習いたいのでぜひ一緒に仕事がしたい。

その五: ベストタイミングほうれん草

任せられるディベロッパーは、
"状況を知りたい!" って思ったくらいに連絡が来る。

「このタイミング状況を報告してください」
と言われるまでもなく連絡が来ることが多い。
「大丈夫ですか?ハマってたりしないですか?」
と言われるまでもなく相談が来ることが多い。

自己解決他力本願の絶妙なバランスを知ってて、
教えるコストも少なければ放置してハマるリスクも少ない。
「実は何時間もずっと原因わからなくて悩んでたんですよ」
なんてことはほとんどない。

気づいたら変な実装や成果物になってしまっていて...
(書き直してもらおうか...いやでも手戻りだなぁ。
うーん...双方ともイヤな気分になる)
なんてことはほとんどない。

恐らく、自分が...
 o 何が実装できて何が実装できないか?
 o 何が判断できて何が判断できないのか?
をよくわかっている。
それがわかってる理由は、三割仕組みに突っ込んで、
全体のことを知ろうとしているってことも
影響しているように思える。

頼もしいのでぜひ一緒に仕事がしたい。

その六: 隣の人を助ける

任せられるディベロッパーは、
隣の人が困っていたらフォローしてくれる。

チームで開発しているという意識が強く、
他に困っている人いるんじゃないかと共有もしてくれる。
"個人個人がバラバラで同じ質問と悩みを相談してくる"
という、よくある現象を軽減してくれる。

もちろん、すべての人をフォローするのは無理でも、
隣の席に座った人とは気軽に情報交換をしてくれる。
フォローされた方も影響されて、能動的な姿勢になる。

羨ましいのでぜひ隣に座りたい。

その七: 答えやすい質問をする

任せられるディベロッパーは、
質問された側が答えやすい質問をする。

質問自体を分析するコストが少ないので、
聞かれることに対してイヤな気持ちが全く生まれない。

なぜ、彼らは答えやすい質問ができるのか?
単に "人に気を使っている" というのもあるだろうが、
しっかり普段から三割でも突っ込んでいるし、
全体のことを知ろうとしているので、
質問者自身の分析が進んでいるってのがあるだろう。

良い質問は楽しくなるのでぜひ聞かれたい。

マネージャー不足の時代?

ちょっとSIerの現場はわかりませんが、
Webサービス開発の事業会社を何社も見ていると、
マネージャー不足を痛感します。

最初は少人数でやっていたのでマネジメント要らず。
五月雨でどんどん増えてきても、体制が追いつかず。
マネージャーをやりたくて来てないから誰もやらず。
後からマネージャー専門の方を連れてきても合わず。

本当はやりたくないって人がなくなくマネジメントを
やっているのを多く見かけます。
(でも彼らは "やるからにはちゃんとやろう" と、
すごく意気込んでいる素晴らしい方々ですが)

リーダー、レビューワーも同じ

マネージャーってほど大げさでなくても、
「もう最近レビューばっかしてる、コード書いてない」
「実装や設計の指示ばっかしてる、コード書いてない」
「みんなの人生相談ばっかしてる、コード書いてない」
「デバッグフォローばっかしてる、コード書いてない」
そんな話もよく聞きます。

形だけの "プレイングマネージャー" という、
寂しい肩書になってしまっているのもよく聞きます。

でも、彼らが頑張らなければ、
開発現場はチグハグになってしまい、
気づいたら優秀な人こそ立ち去っていく現場に。

たまたま人間性が高くリーダーシップのあるから、
リーダーやらざるを得なくてコード書けなくなって...
しかも、その人が一番実装ができる人だったり...
そういう悩み相談をjfluteは何度も受けてきました。
(もちろん本人は自分がリーダーに向いてるとは
言いませんよ^^。でも見てるとそういうことだなと)

その原因は?

その原因の大きな一つはズバリ、

マネジメントコストの高いディベロッパーが多い

ということです。

// 「マネジャーがコードを書けない」は言い訳だ!
//  伊藤直也×柄沢聡太郎が考えるマネジャーのあり方
// 〜TechLION vol.29レポ
http://type.jp/et/feature/2406

色々と素敵な言葉がたくさんある記事でしたが、
特に印象的な言葉がこちら:

マネジメントが必要となる人材は採用しない

かなり思い切ってますが、本質をついているなと。

マネジメントコストが高いということは、
そのディベロッパーに払っているお金以上に
お金がかかっていると言えます。
(そのコストを凌駕するくらいの特殊スキルが
あれば話は別ですが) いくら実装が速くても、
常に "見張ってないといけない" のであれば、
そういうディベロッパーは実はお金がかかるのです。

よくある矛盾の循環

「優秀なマネージャーを連れてきて、
マネジメントしてもらえばいいんじゃない?」
という言葉を時々聞くことがあります。
jfluteはこう返すようにしています。

「その分、ディベロッパーの給料は減るし、
人員も減るかもしれないけどいいの?」

優秀なマネージャーはそれこそ単価が高いですから、
たくさんのマネージャーを揃えれば揃えるほど、
ディベロッパーには回ってこないです。

...

「マネージャーの方が単価が高いのおかしい」
という言葉を時々聞くことがあります。
jfluteはこう返すようにしています。

「誰もやりたがらないんだから、
需要と供給の論理からいったらそりゃ高くなるよ。
あとまあ、"判断する" ってけっこう精神力使うよ」

なので、"みんながやりたがれば" 下がると思います。
また、どんだけ品質よくても間違った方向に進んでたら、
それは成果ゼロですから、マネージャーの役割は重要です。
一方で、ディベロッパーが自ら良い判断をできるのであれば、
マネージャーの価値は薄れ、
相対的にディベロッパーの価値が上がるでしょう。
(実際、七つの姿勢を持ってるディベロッパーは単価高い)

...

「技術のわからないマネージャーはダメだ!」
という言葉を時々聞くことがあります。
jfluteはこう返すようにしています。

「そりゃそうかもしれないけど、
技術の楽しみを知っているエンジニアが、
マネジメントコストが高い組織でマネージャーを
やりたがるわけがない」

マネジメントにも楽しい仕事とつまらない仕事があります。
低レベルな "おもり" をするような仕事はつまらないでしょうし。
高いレベルの組織を目指していくための仕事は楽しいでしょうし。

有機的なディベロッパー集団

どうしたら、
「快適で継続的で効率的な開発現場」
にしていくことができるのか?

汚れ役のマネージャーをやってくれる人を、
探して連れてくるのに努力はすれど現実的ではない。
現場からマネージャーを作り出していくのは、
現実的ではあるけど実は疲弊する原因の一つでもある。

というか、
あたかも "見張ってる" かのようなマネジメントは、
ディベロッパーのイヤでしょうし、
マネージャーも本当はそんなことはしたくない。

なのでそう、

有機的なディベロッパー集団

ディベロッパー自身が有機的に動くことができて、
たくさんのマネジメントは要らなくなる組織に。
その方が、ディベロッパー自身も仕事しやすいし、
会社としてもその方がコストが少ない。

そうなると逆に、
「開発をやりながらもマネージャー的なこともやりたい!」
っていう人も増えてくるかも。良い循環になるかも。

そのための姿勢が、今日紹介した「七つの姿勢」です。

"そういう人だけを採用する" というのも大切ですが、
いまいるメンバーがちょっとずつそういう風になっていく...
これは十分可能性があることなので、
その一つのヒントになればと、書いてみました。

任せられるディベロッパー

能力ではなく姿勢で変わる。頭が良いとか悪いとか関係ない。
若いとかベテランとかも関係ない。
10年以上の経験がありながらマネジメントコスト高い人もいれば、
2,3年の若手でも任せられる人もいる。その差は、まさしく姿勢。

逆にチャンスだと、jfluteはよく言います。
「プロ野球選手になりたい!」とか、
「オリンピック選手になりたい!」とか、
露骨に恵まれた体を持ってないとなれない...
とか、そんなにハードルの高い話じゃない。

優秀なディベロッパーになるためには、
姿勢を変わればいいんだから。誰にでもチャンスがある。
もし、もっと高いお金が欲しかったら姿勢を変えればいい。

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

f:id:jflute:20170213145131j:image

2017-04-02

ドキュメントを無料(タダ)だと思っている?

|

Closed有償ツール v.s. オープンソース(OSS)

オープンソースはドキュメントがなくて使いづらい」

まあ、ドキュメントないと使いづらいのは事実でしょう。

「オープンソースはドキュメントがないから使い物にならない」

その意見には賛成できないな。

ソースコードを公開せずお金を取って "商売" として、
そのお金でドキュメントを整備して提供する...
オープンソースはそれをやめてソースコードを公開し、
(大抵は)お金は取らないことを選んでいるわけです。
より気軽にユーザーに機能を提供するために。

ソースコードを読めばわかるかもしれない。
コミッタやメーリングリストに聞けばわかるかもしれない。
有償のものはそれが気軽にできないことが多いわけで。

その行動をせずにオープンソースに対して何かを言うのは、
流言飛語と言わざるを得ません。

「そんな行動をしなきゃいけないのか?」

と思うのであれば、オープンソースを使うのを止めて、
お金でドキュメント(があるツール)を買えばいい。
求めているものが違うだけだから。

オープンソースに寄付だってできる。
 => Eclipseに寄付しました (Donate to Eclipse)

ドキュメント豊富OSS v.s. ドキュメント少なOSS

「このツール、ドキュメントが少なくて使いづらい」

まあ、ドキュメントないと使いづらいのは事実でしょう。

「このツール、ドキュメントが少ないから使い物にならない」

その意見には賛成できないな。

ソースコードを読めばわかるかもしれない。
作者やメーリングリストに聞けばわかるかもしれない。
その行動をせずに何かを言うのは、
流言飛語と言わざるを得ません。

もしかしたら...ソースコードを読むことで、
もっと良い機能が見つかるかもしれないし、
コミッタやメーリングリストに聞けば、
あっさり問題解決するかもしれない。
コードは読みやすければ細かいところも発見しやすい。

もしかしたら、トータル的には、
その "ドキュメント豊富OSS" よりも、
その "ドキュメント少なOSS" の方が、
使いやすいかもしれない。

一概にドキュメントだけで、
オープンソースの比較はできない。

オープンソーストレードオフ

OSSの作者がドキュメントを書く時間に対して、
誰がお金を払っているのだろう?

ほとんどのOSSでは、お金をもらっていないでしょう。
OSSのドキュメントを完全完璧に作るとなると、
その作者の人生のすべてを失うでしょう。
「業務仕様書を毎週サービス残業で土日に作ってくれ」
と言う人を尊敬できるでしょうか?

完全完璧なドキュメントがないと使えないのであれば、
現実的ではなく誰もツール作りを提供しなくなります。

ソースコードをオープンにし、
少量のドキュメントとソースコードと属人性の
ハイブリッドでユーザーに使い方を伝えることで、
やっと無料で提供することができるわけです。

少なくとも個人コミュニティレベルでやっている
オープンソースはそうと言えるでしょう。
(ただし、その分コードは綺麗に書かないと!)

その少量のドキュメントの質は確かに重要です。
ユーザーの時間にも限りがありますから、
いかに入り(はいり)がわかるドキュメントを書くかは、
コミッタの永遠の努めでしょう。

でも、仮にドキュメントが一切なくても文句は言えません。
ソースコードがあって自由に使えるだけでありがたいもので、
ドキュメントがあったら「ラッキー」的な感じです。
実際に、一切ないツールを使うことはよくあることです。

また、自分でドキュメントも書けるわけです。
プルリクだって送れる。ないから使えないと言うなら、
自分で作ってみればいい。
多くのオープンソースは互助的な精神で成り立っている。
フリーライダーの割合が多ければ多いほど退廃していく。
それができないのであれば、静かに使わなければいいだけ。
黙ること。

業務プログラムでも

共通ライブラリのクラスを作ったり。
自分たちの中のクラスだからコードは自由に読める。

ドキュメントがないと使い方がわからない?
そこにコードもあるよ。

もちろん、入りがわかるドキュメントは欲しい。
あと間違いを防ぐためのドキュメントは欲しい。
作者はそれ意識してドキュメント作って欲しい。

でも、丁寧なドキュメントを求めれば求めるほど、
お金かかるよ。会社がその勤務時間を払う。

オープンソースの話と似ていると思っています。
(大抵)作者も近くにいて聞けるしコードも読める、
つまりハイブリッドができるわけで。
(ただし、その分コードは綺麗に書かないと!)

聞けばいい読めばいい。その方がお金かからないなら、
営利団体である会社としては正しい判断になる。

それをやらずして、
ドキュメントを完全完璧に作らないと使えないなら、
「コストのかかるディベロッパー」と言わざるを得ない。

...

ただ、コードを読めばってのは程度の話です。

例えば jflute も、MySQL のコードまでは、
さすがに読んだことはありません。
(MySQLJDBCドライバは少し読みましたが)
読むのにさすがにコストが掛かりそうなので、
すでに存在しているドキュメントや、
ブログメーリングリスト勉強会などを使って、
情報収集をしてうまく乗り切っています。

でも、例えば使っている言語が Java であれば、
IDE上でフレームワークソースコードを簡単に辿れます。
そして、同じ Java 言語で読むことができます。
大抵の知りたいことは奥底まで読む必要はありません。
ちょこっとクリックして辿ればわかったりします。
それをやるかどうかが分かれ道だとも言えます。
完全完璧に読もうと言っているわけじゃない。
ほんのちょっとでも全然違う。

伝えていこうと

jfluteも、
もちろんドキュメントあれこれ言うことはあります。
ドキュメントあった方がもっと良いのは事実だし、
ドキュメントないと使いづらいってのも事実だし、
ドキュメントを書いて差別化しようって事実だし。

ただ、お金を一銭も払ってないプロダクトに対して、
ダメダメ言うことは少なくとも今は恥ずかしく思います。
あまりこういうことを深く考えてなかった時代には、
なにかそれっぽいことは言ってしまったかもしれませんが、
気が引けるイメージはずっと抱えていたように思えます。

気づいたらオープンソースの提供者になってたから、
自分を擁護してるように取られてしまうのが怖くて、
あんまりこういうことは書きづらかったのですが、
最近「もういいや」みたいな感じになってきて(^^、
しっかりと伝えていこうと思いました。

だって、jfluteもディベロッパーだもん。
良い判断をするディベロッパーと一緒に仕事がしたいから。
そういうディベロッパーに育ってほしいから。

...

ちなみに、
DBFluteはドキュメント豊富と褒められることが多いです。
最近、わりと追いついてないけど...
あと、逆にあり過ぎてわからないみたいな...><
一時期、完全完璧を目指してものすごい頑張っていました。
でも、やはり思ったのです。

組織化して会社化して利益化していかない限り、
完全完璧なドキュメント作るのは無理だと。
このままでは人生が完全に壊れる。
自分もオープンソースを少し勘違いしてたなと。
もっとオープンソースって意識していかないと。
どのような現実的なドキュメントが書けるだろう?
どのようなOSSならではな伝え方ができるだろう?

ある意味では、jflute自身の整理整頓のために、
書いたエントリかもしれませんね。


# いや、単にDBFlute以外のOSS(LastaFlute)を
# やり始めちゃったから...かも!?笑

f:id:jflute:20170313182232j:image

2017-03-18

マンション管理組合の理事長done

|

マンション管理組合の定例総会おしまい!
三年やった理事長もおしまい!

まあ色々と大変でしたが、
結果的に自分が住みやすくなるような
施策ができて良かったです。
自分として印象的な話題は...

 駐輪場扉の騒音問題 => なんとか回避解決
 ゴミ出しマナー問題 => なんとか改善
 ベランダタバコ問題 => 使用細則で禁煙に
 役員の不公平感問題 => 役員報酬(ひとまず)

ベランダ(共用部)の禁煙は紛糾するかなぁと思ったら、
議案出してみたら「約97%」の賛成でした。
やってみたら、みんな「そのほうがいいよね」って。

管理会社と理事会との情報共有もメールベースに。
理事会の前に事前に共有して時間を削減。
あと、間が空くから何が問題だったか忘れちゃうしね。

理事長どころか理事になろうとする人もいない状況ですから、
「理事やってる人たちの住みやすいようにする」
で、ちょうどいいんじゃないかと。
賛成できなきゃ総会に来たり理事になればいいので。

ということで「マンション管理組合の概念図」を公開。
あくまで全体像を把握するもので、正確とは限りません。
特定のマンションに依存しないように頑張っていますが、
まあベースは自分が理事長やってたとこに寄ってるかと(^^。

クリエイティブ・コモンズの
「表示-非営利-改変禁止」として。
これから理事やる人いたら、参考までに。

※ブログだと画像サイズが。。。ちと見にくい(><
(クリックして "オリジナルサイズを表示" で見やすく)

f:id:jflute:20170318164341p:image

2017-02-11

技術的負債の返済プロジェクトが失敗する 11 のワケ

|

序の口: フレームワークだけが負債だと思ってる
序二段: ビジネスサイドに理解してもらう努力がない
三段目: 技術で遊び過ぎてしまう
幕下: 太り過ぎアーキテクチャ
十両: 過去に目もくれず、現状だって見ない
前頭: 技術に詳しいだけでアーキテクト
小結: アーキテクトの知識と覚悟が足りない
関脇: スパンが長く、モチベーションが続かない
かど番大関: スパンが長く、人の入れ替えでチグハグ
大関: アーキテクチャデザインはどこへ?
横綱: 実は人間的負債だった

序の口: フレームワークだけが負債だと思ってる

みんな、フレームワークが大好き。
とはいえ、さすがにみんな、
「フレームワークが古いことだけが負債」
だなんて思ってないはずだが...なのに多くの人が、
あたかもそのような振舞いと判断をしてしまう。
潜在意識Big Issue だから?

o 信用できないテストデータ負債
o 現場フィットレイヤ こそが負債
o 凶悪な引数リモコンパターン がたくさん
o 本番のログぐちゃぐちゃで役に立たない
o ビジネスロジックがぐちゃぐちゃで直しづらい
o 兎にも角にも、あれこれ散らかってるだけ ☆これデカい

...もっといくらでもある。
フレームワークや言語が古いことは、負債の一部でしかない。
新しければ、より高度なことができる可能性は高いが、
その現場で苦しんでいる原因の多くは実はもっと低レベルだ。
アーキテクトってイメージよりももっと地味だよ。

...

普段の開発みたいに進めてはいけない

技術的負債の返済プロジェクトは、
普段の開発とは優先度と判断が変わる。

普段の開発では出てこないチケットがある。
普段の開発では許される妥協が許されない。
普段の開発とは着手する順番が違う。

リニューアルした後にもう一度リニューアルしたくなる
ようなものを作らないこと、が目的だから。

その現場の技術的負債は何なの?
そして、何を解決したいの?

それもわからず何か作ってるの?

序二段: ビジネスサイドに理解してもらう努力がない

案外、多くの人が努力をしていない。
(努力したからって報われるわけではないけど)

技術的負債が、なぜビジネス的にも負債なのか?

非常に結びつけるのは難しいことですが、
仕事で技術を追求し続けていたいのであれば、
それを追求する姿勢を見せ続けていかないと。
 =>  レビューしやすいコード (Reviewable Code) | jfluteの日記

"技術者がやりたいこと" と "(潜在的に)求められていること"
この二つを両立させてこそプロフェッショナル

それを目指さないのであれば、家で趣味でやればいい。

三段目: 技術で遊び過ぎてしまう

A. 問題を解決したいの?
B. 新しいツールを使いたいの?

どっち?

多少はOK。それも技術追求、回り回って役に立つ。
程度の問題。でも、放っておくとどんどん遊ぶ。
ぼくらはデフォルトでその気質を持っているようだ。

始まるのは、現場との乖離。
現場はそんな機能求めてないのに!

その繰り返しが産むものは...
技術的負債の返済プロジェクトの中断!

「はい、それやめー。
みんな現場入ってすぐに今の仕組みで画面作って」

当たり前だよ、遊んでたら。
ぼくらはいつだって、
プロジェクトを止められる立場にある。

幕下: 太り過ぎアーキテクチャ

ぼくらは理想を追い求めがちである。
これはこう解決できるじゃん、
あれはああ解決できるじゃん、
じゃあ解決しよう!

その繰り返しが産むものは...
仕組み自体のメンテコストが高い仕組み。

解決しなくても大きな問題にならない問題なら、
実は問題ではない。

仕組みを複雑にして、
近づきづらい仕組みができてしまうことの方が、
アーキテクチャを継続していく上で問題だ

ディベロッパーも少しずつ後ずさっていく。

アーキテクトチームって、
どんどん増やしていけるものなの?
(そんなお金があるの?)

もし、それならいいけど、
そんな現場はめったに見たことない。
よく我慢することもあるよ。

十両: 過去に目もくれず、現状だって見ない

過去の仕組みには大きな資産がある。
その現場を必死に支えてきたロジックがある。
その多くはこれからも必要だ。

でも、どうやらアーキテクトにとって、
過去の仕組みを探るのは退屈な作業のようだ。
誰もやらない。聞こうともしない。ソースも読まない。
そして、新しい仕組みを作って何か悩んでる。

「なに三年前と同じことで悩んでんの?」

そのセリフを言わざるを得ない。
まさしくこれだ。
 => 未来しか見ない人は過去に戻りたい? | jfluteの日記

自然デグレも発生する。
前に仕組みで密かに活躍していた機能がない!
しかも、そのデグレに気づかない。
三年前と関わっている人がガラリと違うことが多いから。

「なんで新しいアーキテクチャに、
 それを解決する仕組みないの?」

そのセリフを言わざるを得ない。
もちろん色々な事情で完璧は無理ではあるが...
解決する仕組みがない理由がないのはなんで?

そのアーキテクチャは、誰が喜ぶのか?

前頭: 技術に詳しいだけでアーキテクト

確かに技術に詳しくないと
アーキテクトにはなれないけど、
技術に詳しいだけじゃつらい。

アーキテクトのちから | jfluteの日記

技術力があるのは当たり前。
一方で、技術力は100点じゃなくてもいい。
もっと違うスキルも必要だから、バランスが欲しい。
複数人なら得意分野で互いに補完し合えればいい。

複数人のアーキテクトチームであれば...

o アーキテクトチームに対するマネジメント力
o アーキテクトチームに対する教育力
o 意見が分かれたときにまとめる分析力
o 意見が分かれたときに決断するリーダーシップ

誰か一人はこれができないといけない。
でないと、我の強いぼくらはバラバラになってしまう。

本来、アーキテクトを誰がやるか?非常に気を使います。
本来、アーキテクトチームの構成に非常に気を使います。

...

さらに、忘れてはいけない重要なスキル...

整理整頓スキル

技術的負債は、散らかった部屋のようなもの。
部屋を効率よく快適に過ごせるよう片付けられる人。

絶対に必要。
みんながとっちらかし性格だと、
新しく作った仕組みはまた負債になる。

小結: アーキテクトの技術力と覚悟が足りない

意外に、
技術的負債を返済できるレベルの技術力、
を持ったアーキテクトは少ないものです。

打ち合わせにて、
「さあ、どんどん技術的負債を返済していくぞー」
と、みんな意気込んでいたら...

「あれってこうなの?これってこうなの?」
「いや、これはこうで、あれはああで...」

と勉強会が始まってしまって先に進まない。

でも、案外そういうもの。完璧な人など誰もいない。
ただ、思ったよりもアーキテクトへの教育が必要だ。
最初から現場に、
アーキテクトに適任の人がいるとは限らない。
(というか、そうそういない)

それを見越して、アーキテクトチームを
マネジメントしていかないといけない。
一方で、アーキテクトはそのことを理解して、
土日でも夜中でもなんでも使って勉強しないと。

...

技術的負債の返済プロジェクトなんて、
そんなに経験することじゃない。
慣れてる人なんてほとんど誰もいない。
どのくらいの稼働が必要になるのかよくわからない。
ただでさえ、ビジネス的に理解がされにくいもの。

プラスアルファな時間で稼働していかないと、
技術的負債の返済プロジェクトは成り立たない。
技術的負債の返済プロジェクトはそんなに簡単じゃない。
人をたくさん集めればできるものじゃない。
スキルが足りなければできないだけだけだ。

...

ディベロッパーは平日の昼間は実装している。
アーキテクトは横断的な修正がしたくてたまらない。
土日や夜中はディベロッパーが休んでいる絶好のチャンス。

覚悟はあるか?

関脇: スパンが長く、モチベーションが続かない

技術的負債の返済プロジェクトは、
二年三年と続く、ながーいながーい戦い。

最初は...
「新しい技術にさわれるー、あれもこれも直せるー」
と意気込むものだが、
やってみると地味な作業がかなり多く、
ちょっとずつ熱も冷めてくる。

...

二年前は最新ツールだったけど、いまはもう違う。
でも今からそんな簡単に変えられない。
まだまだ他にやることいっぱいあるし。

「新しい技術にさわれるー、って...あれれ!?」

A. 問題を解決したいの?
B. 新しいツールを使いたいの?

アーキテクトのモチベーション、
時が経てば経つほど、
どんどん化けの皮が剥がれていく。
モチベーションのバランスは?
 => 独学のきっかけ、技術欲、問題解決欲、自己成長欲 | jfluteの日記

何をしたくてアーキテクトになったんだい?

かど番大関: スパンが長く、人の入れ替えでチグハグ

技術的負債の返済プロジェクトは、
二年三年と続く、ながーいながーい戦い。

アーキテクトチームの人も徐々に入れ替わり、
現場のディベロッパーも徐々に入れ替わり...

変わっていくポリシーや価値観。
でもそれまでに積み上がっているものがある。
より一層バランスを取ることが難しくなっている。

なんか色々と混ざってて中途半端!
チグハグが悪いわけではなく、
チグハグがマネジメントされていないことがつらい。

「もはや新しいアーキテクチャ負債では?
 やらないで古いアーキテクチャで
 改善していた方がよかったんじゃない?」

そのセリフを言わざるを得ない。

...

ビジネスサイドの人だって変わるかもしれない。

「その技術的負債の返済プロジェクト、
 なんのためにやってるの?」

ちゃんと価値を積み上げているか?
ぼくらはいつだって、
プロジェクトを止められる立場にある。

大関: アーキテクチャデザインはどこへ?

建築デザインは、〇〇さんに依頼」
「プロダクトマネージャーに、〇〇さんにが就任」

これらは、一般によく聞く言葉だが、

「アーキテクチャデザインを、〇〇さんに依頼」

というのはあまり聞かない。

アプリケーションアーキテクチャは、
ディベロッパーの住む家のようなもの。

アーキテクチャで、ディベロッパーの効率は変わる
アーキテクチャで、ディベロッパーの行動は変わる。
アーキテクチャは、空間である。
アーキテクチャデザインは、空間デザインである。

...

技術的負債の返済の「かたち」は一通りではない。
一つの問題に対する解決方法が一つとは限らない。
誰がやっても同じものになると思ったら大間違い。
優秀な人の解決方法が同じだと思ったら大間違い。

その事実を忘れて、
なんの思想もなくアーキテクチャを作り始めても、
バランスの取れた構造物にはならない。

その技術的負債を、どう返済したいのか?

A という思想の中で最適な手段である B,
C という思想の中で最適とは限らないもの。

アーキテクチャの思想は、
柔軟でありながらも確固たるものでなくてはならない。

...

その現場のアーキテクチャデザイン、誰がやる?

o 太り過ぎず持続的なアーキテクチャになるように
o 説得力と意義のあるアーキテクチャになるように
o 現場にフィットしたアーキテクチャになるように
o 現場から超喜ばれるアーキテクチャになるように

どんな思想で、どんな判断をする?

アーキテクチャ周りの「実装」ができることと、
アーキテクチャ周りの「判断」ができることは、
別のスキルである

横綱: 実は人間的負債だった

最強の理由。

もちろん、多くの問題は、
人の振舞いが問題で負債になるものだ。

ただ、
人間の限界を、技術で解決していくのは前向きだ。
人間の怠慢を、技術で解決していくのは悩み物だ。

先輩と後輩、教育と信頼関係がうまくいけば...
チーム開発、リーダーシップがうまくいけば...
縦割り組織、コミュニケーションを円滑にすれば...
各々のディベロッパースキルがもっと上がれば...
各々のディベロッパーがソースをもっと読めれば...

したら、要らなくなる機能たくさんないか?

人間の「あまりの」怠慢から生まれる変な機能、
作ってるアーキテクチャに入ってないか?
太り過ぎアーキテクチャの大きな要因の一つ。

もちろん線引きは難しい。
わかってても機能で頑張るしかないこともある。
ただ、
「解決策がアーキテクチャだけとは限らない」
ことを理解できないといけない。
組織的な提案もできないといけない。

どんなアーキテクチャも、
人間の「あまりの」怠慢は、
なかなか解決できない。

アーキテクトは、技術屋じゃない。
主に技術に着眼点を置いている問題解決屋だ。
でないと、アーキテクチャを守れない。

...

前のフレームワークも、実は使いこなせてないだけで、
もっと勉強して使えば多くの問題は解決できたりしない?

次のフレームワークの方が良いものだったとしても、
前のフレームワークを使いこなせていない人たちが、
次のフレームワークを使いこなせるか非常に疑問だ。

「使ってみたいから、入れ替えてるだけじゃないか?」

「実は、その技術的負債の返済プロジェクト自体が、
 人間的負債なんじゃないか?」

絶対に、そんな風に言われるなよ。

常にプレッシャーを与える

一つ一つの項目に、
もっともっと深いストーリーとエピソードがあって、
一つの項目だけで一つのブログが書けてしまいます。

もっと具体的なケースで、
どんな判断ロジックがあるのか?
どんなコツがあるのか?

まとめるのは、さすがに時間がかかるので、
機会あれば講演会などで話をしていこうかな。

...

執筆時 jflute は、
二つの現場で技術的負債の返済プロジェクトの
アーキテクチャデザインを任されています。
それぞれ、4,5人のアーキテクトチームの
顧問としてプロジェクトを進めています。

二つ同時って確かにちょと大変ですが...
(メンバーも組織も価値観も違うし)
でも比較ができて客観視がしやすいので、
互いの現場にプラスになっていると思うので、
これはこれで良い経験だと考えています。
アーキテクトたちをアーキテクトとして育てる、
というのにもチャレンジ。一番楽しい教育かも。

このブログに書いた内容は、両方の現場で、
アーキテクトたちに強く啓蒙しています。
ようやく説明資料ができてよかったぁ、みたいな笑。

【追記】
両方とも、Webサービス系の事業会社で、
スタートアップ&インクリメンタル開発の現場です。
運用しながらの改善というのがとても難しいところ。

...

片方の現場は、まだ始まったばかりで、
まさに今日書いたことを、
しっかり気をつけていかなければと。

もう片方は、すでにプロジェクトは進み、
幸いながらビジネスサイドの方からも高い評価を頂き、
jfluteとしても、大きな成功体験の一つとして、
もっと良い判断をしていくための分析対象です。
頑張ってくれたアーキテクトたちと、
献身的な現場のディベロッパーのみなさん、
そして仙人のようなハイパーDBAのおかげです。
本当にありがとう。
もちろん、まだまだ先長いので油断はできません。

さて、
この 11 のことを気をつけていたから成功した...???
いやいや、そういうニュアンスじゃなくて、

これだけのことをやって、ようやく

成功した...しかもギリギリ成功した。
そんな感覚です。
「それだけ大変なことなんだ!」
一層そう思うようになりました。
どんなに頑張ってもダメなときはダメ、
ってこともあるだろうし。

なので、jflute は、
気軽に「今のサービス作り直しちゃいましょ」とか、
気軽に「フレームワークを変えちゃいましょ」とか、
とてもじゃないけど、そんな感じでは言えません。

中途半端に進んで挫折したプロジェクトほど、
負債なものはないんですね。
「だったらやらない方が良かった」って。

場合によっては、
「現状の仕組みのままで改善を進めていく」
という提案をすることもあるかもしれません。
大抵みんないやがるんですけど(jfluteもいやだけど)、
確実に現実的な選択肢の一つです。
現状の仕組みでも考えれば幾らでも改善できるはず。

前に進むんであれば、じゃあ、
この「11のワケ」を覚悟していこうよ。
もう一つワケがあった。
「11の話を聞いても聞く耳持たない」
が12個目だ。

...

そして、なによりも...

「jflute よ、11 のこと常に心に置いてるか?
 一つの判断ミスで信頼は一瞬で崩れ落ちるよ」

と常にプレッシャーをかけているのです。

うわぁー、こんなブログ書いたからには、
もっと気をつけなきゃいけないじゃん(><。

f:id:jflute:20170101194349j:image

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