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

2017-06-23

プログラマーに求められるデザイン脳

|

「デザイン」じゃなくて「デザイン脳」です。
いわゆる「Webデザインもできなきゃね」という話ではなく、

普段のプログラミングの中でも、
Webデザインと同じような脳みそを使うことがある

というお話。

プログラマー (エンジニア) は、
一般的な先入観として「計算能力」...
というか、ここでのニュアンスとしては、

「パズルを解く能力」(言葉が見つからなかった...)

が必要と思われることはあっても、
あまり「デザイン能力」が必要だとは
思われてないように思えます。

「動きを実現する選択肢(かたち)が一つしかない」
とかであれば、
もはやデザイン性はあまり関係ないかもしれませんが、
昨今は特に、動きが実現するための選択肢は増えているので、
プログラマーも「デザイン脳」を、
意識して鍛えていく必要があるだろうと考えています。

様々な場面があると思いますが、
ここでは大きく五つ挙げてみたいなと。

1. 命名デザイン
2. 構造デザイン
3. コメントデザイン
4. DBデザイン
5. アーキテクチャデザイン

1. 命名デザイン: メソッド名、変数名など

最初に、
あまりに当たり前でありながらいつまでも問題を抱える領域、
「名前付け」です。これもれっきとしたデザインです。

だからこそ、いつでも問題を抱えるのでしょうと。

どれだけ構造が良くても、簡単にプログラム負債に
変身させることができるのが「名前」です。

一般に、わりと苦手なプログラマーも多く、
「規約を設けてあまり考えなくてもいいようにする」
ことが多いです。

それはそれで、
プログラマーの "頭CPU" の節約という意義はありますが、
デザインすべきところで "逃げよう" とするのもよくありません。
なぜなら規約作り自体がとても難度の高いデザインであり、
完璧な規約というものは存在しないからです。
(規約というのは複雑なケースバイケースに対応できない)

非常に個人差の激しいところですし、
正解がないから人によって変わるからなお難しい。

ひとつ、大きなコツを挙げるとすれば、これです:

名前を付けようとしているものだけを見て、
その名前を付けることはできない。

つまり、

"周りの名前" や "全体の中の位置付け" を把握して、
初めてその名前を付けられる。

名前って識別子ですから、極端な話、一つしかないのであれば、
(例えば、システムの中にクラスが一つしかなかったら...)
名前を付ける必要もあまりないかもしれません。
たくさんあるから名前を付けて識別したいわけで。

単純に統一性という面もあるし、
統一性よりも優先する特殊な要件があったとしても、
やはり周りの名前の付け方に影響はされるはずです。

この基本を忘れて「こうだ!ああだ!」と言ってても、
何も良い名前は思い付かないし、
それが良い名前なのか悪い名前なのかの判断もできません。

// 任せられるディベロッパー、七つの姿勢
http://d.hatena.ne.jp/jflute/20170405/reliableseven

の「その四: 全体を把握しようとする」の姿勢がない人に、
名前付けを任せることはできないわけです。

2. 構造デザイン: クラス構造、メソッドシグネチャなど

ここは説明するまでもないところかもしれませんね。

別に、ひとつのクラスでベタッと書いても動くは動くわけですが、
でもそうしないのは...
そのソースコードに触れる人が "コードのかたち" で効率が下がる、
という問題を抱えるので、
その問題を軽減するためのデザインが必要なのです。

ここでも大きなコツが一つ。

人のことを考えないと構造デザインはできません。

人がそれを見て解釈する、人がそこに後から手を加える、
だからデザインが必要なのです。
つまり、

人のことを考えて初めて、
良いクラスやメソッドを考えることができる。

プログラマーは、実は人のことをよーく考える職業でした。
先入観と違いませんか?

そしてそれは、そんな簡単なことではありません。

jfluteも、オープンソース活動(DBFlute)の中で、
数え切れないほどクラスをリファクタリングしたり、
メソッドのかたちを変えたりを繰り返してきました。
こうだとこう、ああだとこう、
DBFluteユーザーのこと未来の自分のこと、
いっぱいいっぱい想像して四苦八苦しました。
他のツールソースコードもたくさん読んできました。
本も色々とたくさん読んで理論も学びましたが、
その実践があってこそ活かせるものでありました。

そこまでやって、ようやっと見えてくるものがあるなぁと、
「修練には非常に時間を費やすものである」
というのを実感しています。

そりゃそうなのです。
「これは知識ではなくデザイン力である」
打ち方がわかればホームラン打てるわけじゃないのと全く同じ。

3. コメントデザイン: JavaDoc, DBコメントなど

JavaDocってどう書けばいいですか?」
「DBコメントってどんなこと書けばいいですか?」
相談されることがよくあります。

ある程度は、JavaDocなら @param, @return など、
そういうのに沿って書けばってのはありますが...
そこに何を書くか?フリーテキスト欄に何を書くか?
やはりレールに乗らずに思考しないといけない部分はあります。
さらに、こんなこと書こう、あんなこと書こう、
という方法論的なものはある程度はあります。

ただ、究極は...

何が書いてあったら読む人が嬉しいのか?
を考えないと良いものは書けない。

なぜなら、JavaDocDBコメントなどは、
完全にコンピューターのためのものでないので。

凝った方法論があったとしても、
その気持ちのない人が書いたものは、
どこかで歪を生む可能性があります。
ケースバイケースに対応できないから。

マニュアル通りに振る舞ってさえいれば、
ゲストが喜ぶ接客ができるでしょうか?

4. DBデザイン

要は、DB設計です。DBデザインと言えます。
どんなテーブルにするか?
どんなカラムにするか?
どんなリレーションシップにするか?
どんな制約を付けるか?

これまたたくさんの選択肢がありますよね。
ある程度の規約やポリシーなどはありますが、
すべてが自動的に決まるものではありません。

さらには、DBは(基本的に)振舞いを持ちませんから、
なおさらごまかしも効きづらい領域でありながら、
かつ、あとからの修正がやりづらいものです。
DB負債は、プログラム負債に比べて、
リアルに「3倍つらい」です。

また、

DB以外の領域のことも考えてデザインしないと、
DB自体も良いものにはならない

と言えます。
DBはシステムの中の大事な大事な根幹です。
ゆえにDBが周りのレイヤに与える影響というのは大きいので、
DB以外のことも考慮しないと良いDBとは言えません。

もの(データ)が散らかっていますから、
部屋(DB)のどこにどうしまいますか?

5. アーキテクチャデザイン

アーキテクチャは、
「ビジネス要件の実現」と「ディベロッパーの住処」の
トレードオフに悩む領域です。

むかし、こんなブログを書きました。

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

全体最適が求められるので、局所の議論で決めてもいけないし、
長く生き続けるものなので、いまの議論で決めてもいけないし。

システムはどんどん複雑化していますから、
アーキテクチャに対する高い意識が、
各々のディベロッパーにも求められている時代でしょう。

どこに台所があって、
どこに柱があって、
どこに階段があったら、
住みやすく長持ちする家になるでしょうか?

とにかくバランス感覚

どの領域にしても...

"とある要件" と "別の方向性のとある要件" との
「ちょうどいい」を探す作業と言えます。

どこかしらでトレードオフが発生するわけです。
それは二方向だけとは限らず、三方向四方向になることも。
論理的でも感覚的でも、そのバランスを取る作業、
これがプログラマーにも求められるのです。

これは非常に疲れる作業です。
そして、経験と分析、習得が必要な作業です。

「バランス感覚」というスキルは確実に存在します。

バランス感覚ってどう鍛えるの?

「そこから逃げないこと」

まずはそこだと思います。

非常に疲れますし、本来多くのプログラマーにとって、
あまり得意な領域ではない(と思われる)ので、
ベテランプログラマーであっても、
安易なデザインを出してしまう人がいるように思います。

プログラマーにそういうスキルが求められていること、
それをしっかりと知ること。
その認識すらない人もいるかもしれないから。

「どうして、そういうメソッド名にしたの?」
「どうして、そういうクラス構造にしたの?」
「どうして、そういうコメントを書いたの?」
「どうして、そういうテーブルにしたの?」
「どうして、そういうフレームワークにしたの?」

こういう質問にされたときに、
大正解じゃなくてもいいから、
真正面向いて答えられるか?

そのスタートラインに立ちさえすれば、
スキルアップ自体が得意なプログラマーですから、
おのずとどうすれば鍛えられるのかわかってくるでしょう。

考え抜かれたデザイン

別に立派なデザインじゃなきゃいけないわけじゃないです。
jfluteもそんなものは出せません。
一番良いものじゃなくてもいい。

考え抜かれたデザインは、
何かしら問題にしっかり向き合ったものになってる

と思います。

DBFluteで新しい機能を追加するとき、
そのメソッド名や機能の提供の仕方を決めるのに、
(普段の生活はしながら) 二、三日かけることがあります。

いろいろなことを考えて想定して想像して妄想して、
電車の中でもお風呂の中でも布団の中でも、
悩んで悩んで最後に決めます。
当然、時間の制約があることもあるので、
その時間制約も考慮した上での結論を出そうとします。

もともとプログラマー、考えることは得意なはずですから、
その考える力を、ちょっと違った角度に使っていけばいい。
「もの作り」は「ちょうどいい」を探す旅のようなもの。

それが「デザイン脳」の始まりです。

f:id:jflute:20170623132543j:image

2017-06-11

質問のコツその一: なんでその質問してるのか?も伝えよう

|

はさみストーリー

後輩「はさみ、どこかわかります?」
先輩「えっ、はさみ?
 えーっと、誰も使ってなければあっちの棚の上かな」
後輩「ありがとうございます、さすが先輩!」
先輩「...」

次の日...

先輩「そいえば、はさみあった?」
後輩「えっと、まだいま探してます、徹夜で探してて」
先輩「いやいやいやいや、棚の上は?」
後輩「誰か使ってるみたいなので...誰かっての探してて」
先輩「にしても、はさみを探すだけで徹夜ってまじかよ。
 もう買って来ちゃえばいいじゃん」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、なんではさみ必要なの?」
後輩「A4の紙が切れてて、余ってるA3を切ってA4にしようかと」
先輩「いやいや、したらはさみじゃなくても、
 少ない枚数だったら折って手で切っちゃうとか、
 そもそも多いんだったら裁断機じゃないとつらいでしょ」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、なんでA4じゃないといけないの?B4やB5はあるよ」
後輩「会議の資料がいつもA4だったのでA4じゃないといけないのかなって」
先輩「いやいや、別に伝わればいいでしょ、B5でもいいんじゃない」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、紙じゃないといけないの?
 チャットの添付とかで事前に資料配布して見ておいてもらうとか。
 紙切れだってことで今回はそういう風にさせてくださいって、
 会議のリーダーに了承取れればそういうのもアリかと」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、その会議、なんの会議?」
後輩「来年度の人事戦略の方向性を決める会議です」
先輩「いやいや、今月末でこの会社なくなるから、
 その会議要らなくない?それよりも転職活動した方がいいよ」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

先輩「てゆーか、君、もともと億万長者でしょ。
 ムリに転職活動もしなくて良くない?」
後輩「おおぉ、さすが先輩!そうします。やったー解決だー」

ということで...
最初の質問の "はさみが置いてある場所" は、
「わりとどうでもいい」ことがわかりました。

次の日に、先輩が気になって話しかけてくれたので、
問題分析して解決案を色々と挙がってきたからよかったですが、
もしかしたら、あと三日間くらいずっと、
徹夜ではさみを探し続けたかもしれませんね。

# さて、もちろん、はさみは使った人は、
# ちゃんと元の場所に戻さないとですね。
# つーか、紙切れだったら総務に言えばいい!?

道を踏み外した枝葉の質問

もともとの問題 A があり、
その解決のために B という手段が必要だけど、
それを実現するために C という手段が必要になるけど、
それを実現するために D という手段が必要で...

「Dってどうやればいいですか?」

まあ、Dまで辿り着く道のりが正しければ、
特に問題はないかもしれませんが...

そもそも道を踏み外していたら

Dが解決しても根本解決にならない可能性大です。

質問を受けることが多いjfluteですが、
「まあ、Dはこうだけど、なんでDが必要になったの?」
と聞き返すことがほとんどです。
(jfluteと一緒に仕事してる人であれば、
よく知っているかと思います)

そして、問題を分析していくと、
A から B と来たところで本来 C に行くのではなく、
ぜんぜん違う F の方向へ行くべきだったことがわかって、
解決方法もぜんぜん違うものになったり。

今回の例は非常に単純なので、
普通は自分で気付くだろうと思うかもしれませんが、
例えば、プログラミングの世界だったりすると、
扱う問題が非常に複雑で、
「進む道を間違わない人なんていない」
というか間違うのが当然だと思っていたほうが良いくらいで...

常に疑っているくらいでちょうどいい

と言えます。
(これは、何年経験を積んでも持っておきたい前提です)

でも、プログラミングの世界だけとは限らないでしょう。
世の中は、複雑ですから。

# まあ、あまり本質に戻りすぎると、究極...
# 「おれってなんのために生きてるんだろう?」
# 「地球ってどうしてあるんだろう?」
# とか人類の限界を超える問題になってしまうので、
# ある程度の決めの前提は必要ですけど(^^。

きっかけとなったストーリー

すごく感覚値ですが、受けた質問の3割くらいは、
「枝葉の質問(D)で解決すべき問題ではなかった」
という印象です。
残りの7割も、素直にDというよりかは、
かなり特殊なケースで仕方なくDということで、
その解決の実行も慎重にしないといけなかったり。

そして、その場合、大抵Dは非常に "いびつ" です。
Dで解決とかあり得ない、
このツールでDの機能が必要になるはずがない、とか。
質問聞いた瞬間に「おかしい」って思うことがほとんど。

枝葉の質問(問題、解決案)に捕われていると、
延々に解決しないかもしれません。
変な解決で後でトラブルになるかもしれない。

質問を受けた側が、追求してくれたらラッキーです。
本来、背景にある問題を解決する義務はないわけですから。
それでも背景を聞かれるってことは気を使ってくれてる、
という風にも言えますので感謝しないとですね。
興味のない人が背景を聞いて来ることはないでしょう。

なので、質問するときは...

その質問をするきっかけとなった、
ストーリーも一緒に添えて

本来は「そもそもこういう問題を抱えてまして」
という風に、根本の問題(A)自体にフォーカスを当てて、
質問と言うか相談ができたら最高かもしれませんが、
"必ずそうしないといけない" だと、
ちょっとフットワーク重い気も確かにしますので、
そこまで行かなくても...

後輩「はさみ、どこかわかります?
 会議の資料作りで、A4紙切れでA3切ろうかと思いまして」

このくらい言えたら、
もし変な質問でも、すぐに先輩が突っ込んでくれます。
最終的に、しっかりとあるべき姿で問題が解決できたら、
途中で道迷ってたとしても結果オーライなわけで。
(解決スピードを上げていく努力はまた別として)

# あと、質問者がちゃんと背景を見直すことで、
# 質問する直前に「あっ、そういうことか」と、
# 自己解決するきっかけにもなります。

答えやすい質問のヒント

// 任せられるディベロッパー、七つの姿勢
http://d.hatena.ne.jp/jflute/20170405/reliableseven

で挙げた、
「その七: 答えやすい質問をする」のヒントだったりします。

"いびつ" な枝葉の質問(D)は、
聞かれた側にとっては実は答えづらいです。

単純な Yes-No だとして、
「いや、そもそも "D" が必要になることはない...」
「Yes, と言っても、そう手放しでYesってわけじゃなく...」

背景がないと、
枝葉の質問(D)に答えられないことが多いのです。

なので、一言でも背景のストーリーがあれば、
その枝葉の質問(D)の意義がわかって、
その質問に「ニュアンス」を付けた回答ができると。

# 答えづらい質問は、聞く方にストレスをかけます。
# これが「めんどくさいなぁ、俺に聞くな」
# のきっかけの一つになるわけです。
# 答えやすい質問であれば、めんどうとは思われないわけで。
# 本当に、質問の上手な人の質問は、
# 気持ちがいいほどスムーズに話が進みます。
# これは楽しいのでぜひ質問されたいって思うものです。
# (jfluteも、そういう質問できるように頑張らないと...)

オープンソースの運用でも

DBFluteの質問や要望などでも今まで何度もあったと思います。

「DBFluteで "D" ってできますか?」
「DBFluteに "D" はありますか?」
「DBFluteで "D" の機能を入れてほしいです」

多くの場合、
その "D" に辿り着いた背景はなんでしょうか?
と質問を返させて頂いています。

何も考えずに "D" を実装すると、
DBFlute全体の機能バランスを崩し、
DBFluteの機能デザインがいびつになってしまう
可能性があるから。

何も考えずに "D" だけ教えると、
DBFluteユーザーが本来得るべき解決を、
見逃してしまう可能性があるから。

実際に、
「したら、そもそも C じゃなくて F の機能を実装しますね」
ということで解決したことが何度も何度もあります。

これは、オープンソースプロダクトを
長生きさせていくコツの大きな一つでもあります。

...

まあ、jfluteが新卒のときに、
師匠にさんざん言われたことなんですよね。

その一なので、その二もそのうち書きますね。

f:id:jflute:20170611161928j:image

2017-05-05

DBFlute-1.1.3 Released

|

Java8対応のDBFluteの十三回目のリリース。
DBFlute-1.1.3 です。

DBFlute Top
Change Log

1.1.2 のときに発展した SchemaPolicyCheck
の微調整などが行われています。

また、その他細かい調整が多く入っています。

※久しぶりに元旦じゃない日にリリースができて安心しています。

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