任せられるって?
o その一: 自分の道具は使いこなす
o その二: 三割でも仕組みに突っ込む
o その三: 三割でもビジネスに突っ込む
o その四: 全体を把握しようとする
o その五: ベストタイミングほうれん草
o その六: 隣の人を助ける
o その七: 答えやすい質問をする
ここでのディベロッパーは、システムの開発現場で業務プログラミングをしている、まさしく現場のITエンジニアを指します。
マネージャーとかリーダーとかアーキテクトとか、どちらかと言えば何か特別な立場ではなく、まさしく最前線で戦っている開発者。(もちろん兼任してることはあるだろうけど)
jfluteと一緒に仕事してきた優秀なディベロッパー、jfluteが他の人から伝え聞く優秀なディベロッパー、jflute自身の長年のディベロッパー経験、これらのことから、「任せられるディベロッパーってなんだろう?」というのを、ちょっとまとめてみました。
その一: 自分の道具は使いこなす
任せられるディベロッパーは、IDE やテキストエディタはもちろん、使っているフレームワークもしっかり押さえる。
「入社までになんちゃらツールを勉強してきました」
「自分この辺弱いからいま猛勉強してるんですよね」
というセリフを平気で言う。完璧は無理でも、必要最低限ちゃんと把握して使おうとする。
だから、"知ってりゃすぐ解決するのに!" っていう問題でハマったりはしない。へんてこりんな回避策でお茶を濁さず、フレームワークの思想に沿ったスマートな実装をする。わからなければ検証するし、有識者に質問する。
ショートカットキー、補完は当たり前のように使って、自分の作業からノイズを減らす努力を惜しまない。
見ていて気持ちが良いのでぜひ一緒に仕事がしたい。
その二: 三割でも仕組みに突っ込む
任せられるディベロッパーは、仕組み部分のコードも追っかける。
さすがに全部は追っかけられないにしても、いま直面している問題の解決を探るために、焦点を定めてフレームワークのコードを追うことに躊躇はない。オープンソースに対する姿勢もよくわかってる。
=> ドキュメントを無料(タダ)だと思っている?
だから「自己解決力が段違い」である。エラーメッセージやスタックトレースから、しっかりと分析と推論ができる。だから読む。
=> エラーメッセージ読め読め大合唱
フレームワークの空気を読み取って、求められている自然なコードを実装する。なのでレビューする側も力まなくて良い。
わからなくても三割突っ込んでるので、質問されても話が早い。すぐに相談は終わる。少し難しい問題でも、人の手を借りながらも、自己責任的に解決ができる。
話してて違和感がないのでぜひ一緒に仕事がしたい。
その三: 三割でもビジネスに突っ込む
任せられるディベロッパーは、ただ作ってと言われたものを作るだけじゃない。
その作ろうとしているプログラムが、業務的にどんな役割を持っているのかが気になる。なので、変な要求が来ても疑問を呈して、業務のレビューワーにもなってくれる。
「この機能を作って欲しいのですが...」
「了解です、でもこっちの機能のほうが 先にできた方がうれしいですよね?」
ディベロッパー自らが業務的な優先度を調整できる。実装をお願いしても間違った方向に突き進む心配が少ない。
安心ができるのでぜひ一緒に仕事がしたい。
その四: 全体を把握しようとする
任せられるディベロッパーは、全体のことを考えて判断をしようとする。
局所的な最適と全体的な最適のバランスを掴むために、全体を把握しようとする。ぜんぶは無理でも、できるだけ。
そして、わからないにしても、"全体がわかってないから判断できない" という判断をし、要因を周りにヒアリングしてから判断する。
局所で勝手な判断をしないようにしているようだ。
見習いたいのでぜひ一緒に仕事がしたい。
その五: ベストタイミングほうれん草
任せられるディベロッパーは、"状況を知りたい!" って思ったくらいに連絡が来る。
「このタイミング状況を報告してください」
と言われるまでもなく連絡が来ることが多い。
「大丈夫ですか?ハマってたりしないですか?」
と言われるまでもなく相談が来ることが多い。
自己解決と他力本願の絶妙なバランスを知ってて、教えるコストも少なければ放置してハマるリスクも少ない。「実は何時間もずっと原因わからなくて悩んでたんですよ」なんてことはほとんどない。
気づいたら変な実装や成果物になってしまっていて...書き直してもらおうか...いやでも手戻りだなぁ。うーん...双方ともイヤな気分になる...なんてことはほとんどない。
恐らく、自分が...
o 何が実装できて何が実装できないか?
o 何が判断できて何が判断できないのか?
をよくわかっている。
それがわかってる理由は、三割仕組みに突っ込んで、全体のことを知ろうとしているってことも影響しているように思える。
頼もしいのでぜひ一緒に仕事がしたい。
その六: 隣の人を助ける
任せられるディベロッパーは、隣の人が困っていたらフォローしてくれる。
チームで開発しているという意識が強く、他に困っている人いるんじゃないかと共有もしてくれる。"個人個人がバラバラで同じ質問と悩みを相談してくる" という、よくある現象を軽減してくれる。
もちろん、すべての人をフォローするのは無理でも、隣の席に座った人とは気軽に情報交換をしてくれる。フォローされた方も影響されて、能動的な姿勢になる。
羨ましいのでぜひ隣に座りたい。
その七: 答えやすい質問をする
任せられるディベロッパーは、質問された側が答えやすい質問をする。
質問自体を分析するコストが少ないので、聞かれることに対してイヤな気持ちが全く生まれない。
なぜ、彼らは答えやすい質問ができるのか?単に "人に気を使っている" というのもあるだろうが、しっかり普段から三割でも突っ込んでいるし、全体のことを知ろうとしているので、質問者自身の分析が進んでいるってのがあるだろう。
// 質問のコツその一: なんでその質問してるのか?も伝えよう
http://d.hatena.ne.jp/jflute/20170611/askingway1
良い質問は楽しくなるのでぜひ聞かれたい。
マネージャー不足の時代?
ちょっと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