評判の悪いエンジニア

評判の悪いエンジニアっているものです。評判はそれを聞く人の話し方によっては評価が悪いと思えることもあります。評判でも評価でもいづれにしてもとあるエンジニアに対して悪い印象だということははっきりしています。

評判の悪いエンジニアが他部署のエンジニアであれば「そうなんですねー」で流すことも可能だけれど、異動してきたエンジニアの評判が悪いときに向けられる言葉が

「なんとかしてくれ、頼む」

なのはひどい話だと思いませんか。

エンジニアの評判を悪くするには

評判の悪いエンジニアの仕事ぶりを見ているときになることが幾つかちらほらと。

・完了基準が独りよがり
・詰めが甘い
・文章が稚拙
・ボトムアップでロジックがない 

・人の意見を参考程度でも聞かない

完了基準が独りよがり

成果物の完了時のイメージが明確に持っていません。間違っているかもしれないけれど、仮説を置き、作業開始時に関係者と完成時のイメージを持って作業をしないと周囲はどこまでやればいいのかわからないため集中することができません。結果的にまとまらないところを無理やり完了にこじつけようとする際に自分の

「このくらいでいいや」

で決めただろうとたやすく見抜ける程度の出来合いでアウトプットが出てきます。

これが見る人（＝ワタシ）によっては、自分に甘いとしか見えないのです。仕事の、作業の完了基準は作業ごとのアウトプットの品質要求で決まるもので、自分のその時の都合で決めるものではありません。

詰めが甘い

作業ごとのアウトプットの完了基準を自分の都合で調整してしまうので、必然的にアウトプットの詰めが甘いです。別に１００点を取る必要はありませんし、完璧なんて求めていません。高い点数はスキルのレベルの高い人が目指せば良いのであって、評判の悪いエンジニアのレベルが中堅なら中堅のレベル程度のアウトプットがあればいいのです。そうしたレベルでフィルタを下げてもすぐに見つけられる仕事の詰めの甘さを持っています。

文章が稚拙

書き物をしてもらうと知識量や文章力に見え隠れする論理的なものの考え方を伺うことができます。

例えば、資料の構成を見るだけで、スコープの決め方、話の持って行き方をどのくらい情報を集め、界面とカバレッジを押さえ、ロジックを作りながら持っていきたい方に結論を導こうとしているかがわかります。

書き物の文章が稚拙であることが読み取れると、目の前で手に入る情報で都合の良いものだけを選び、まとめてしまう今時のキュレーションメディアレベルのまとめサイトと同じだな、あまり考えていないな、ともうんですよね。

ボトムアップアでロジックがない 

稚拙な文章を書くのは、情報を積み上げていくからです。プロジェクトなどの仕事はWBSに代表されるようにアウトプットの完了イメージがあり、それを構成する部品に分け、部品を作り、作った部品を組み立てるように作業を標準化します。

そうした仕事上の方法論を取っているのですから、その中の作業も同じようにしないとアプローチが違いますから不整合を起こします。

暗黙に、トップダウンの作業プロセスを取っている以上、ボトムアップの仕事をされると手に入る情報で組み立てようとしているように見えるので、カバレッジはないし、ケース漏れはあるしの状態です。こうしてできたアウトプットをレビューするまでもなく、ちょっとした質問をするだけで抜け漏れが見抜け得てしまうのです。

それでも、きっちりとロジックを持っていればまだ救えるのですけれど。

人の意見を参考程度でも聞かない

ちょっとした質問などをすると必ず反応があるのは、

「これまで検討してきたのだから手戻りしたくない」

というものいいです。

「いやいや、あなたの手戻りはあなたの考慮もれなのだし、それは進め方に問題があるからなんだよ」

とは言いませんが、全部ではなくてもアウトプットの要求品質に近づけるためには人の意見のうち、重要だ判断するものだけでも選りすぐって反映した方が後でちゃぶ台をひっくり返されなくていいと思うのですけど。

結局、評判が悪いエンジニアは、自身がとる振る舞いと実際にアウトプットされる成果物が見合っていないのですよね。物を言う割には、そのレベルなんだ、みたいな。

個性として認めるものは理解しますし、その人特有の性格や性質もそう言う人なんだ、と思うのです。ただ、仕事上のアウトプットに対してまでそれを持ち込むから評判が悪くなるのかもしれません。

評判の悪いエンジニアがメンバになったら、それはそれも縁ですから良いところを伸ばす機会を作る、アウトプットに求められる品質を満たしていなければ満たしていないと差戻す、そうしたことを続けるのがお仕事だと思います。

ふりかえりで効果が得られないなら計画を疑え

ここ数年、アジャイル開発などの「ふりかえり」や「KPT」が広く取り入れられてきた感じがするのです。

ウォーターフォール開発などでも、プロジェクトが完了した際に今まではプロジェクト上での進捗上の妨げとなったことをしていたメンバを戦犯のように晒す内向きで気乗りのしない反省会から、プロジェクトを通して得た経験を次に繋げるための外向きの会に様変わりしてきた、というように。

ふりかえりで効果が得られないのはナゼ

とは言え、実際の現場でふりかえりをしているとふりかえりの効果を実感できないケースがあります。よくよく話を聞くと、ふりかえりの対象期間で経験した、

・次も続けること
・次は止めること
・次に挑戦すること

の３つでふりかえりをしているのでKPTの要素は押さえてふりかえりをしているようです。それでも効果が感じられないとするならば、どこに原因があるのでしょうか。

ペインを探せ

一見、セオリーどおりにやっているのに期待する効果が得られないときには、いったん、下がって全体を俯瞰します。

そして、闇雲にあれこれと子細を探さないことです。

探すのは本来得たい効果が得られないというペイン、痛みを取り除くことです。

ペインを引き起こしている原因は

「当事者が当然と思っていることが実は原因だった」

というケースが多いのです。当然と思っているのでそうした事柄は当事者の中では暗黙になっているので見つける対象に入っていないのです。

計画は仮説である

プロジェクトマネジメントを実践していると計画は不確実性の高いものであることを知っています。確実性が得られているなら、プロジェクトマネージャを配置してプロジェクトマネジメントをする必要がないのです。

プロジェクトマネージャを配置し、プロジェクトマネジメントの管理手法をとり、プロジェクトをコントロールしようとするのは、プロジェクトの計画自体が不確実性の高いものであると証左しているようなものです。不確実性が高いから道具を作り、道具で制御しようと工夫しているのです。

その計画の成り立ちも、プロジェクトの目的の一環で得たいアウトプットを作るために行う活動で構成しています。これは、計画自体プロジェクトの目的を得るために、

「こうした作業をすればプロジェクトの目的を達成できるはずだ」

という仮説なのです。仮説であるから不確実なのは当然です。

ふりかえりで計画を疑う

ふりかえりでは兎角、作業にフォーカスしてふりかえりを行います。そうですよね。だって、Keep/Problem/Tryは振る舞いを変えようとしているのですから。

でも、その対象が仮説であり、不確実性の高いものだとは思っていません。計画がうまくいかなかった理由を探していることからも伺えます。

もし、ふりかえりで効果が得られないと感じたとき、計画自体に間違った仮説がなかったかをぶつけてみましょう。

チームの成果が出ていない本当のペインはそこにあるかもしれません。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

チームを変えたいならチーム全員に同じ講座を

ほら、あるじゃないですか。中堅やマネージャになると行かされる外部の集合教育って。教育の専門業者が都心の割とアクセスの良いビルで開いている企業向け研修。

例えば、人間力とか組織活性化とか部下とのツーウエイコミュニケーションとかね。エンジニア向けだとベンダー講座とかシステム開発手法など、どれでも受講料が馬鹿高いですよね。

まあ、無料のものは広告だったり、有償研修の一部のお試し（客寄せ）だったりしますので、ただより高いものはないのですけれど。

研修の評価

企業内研修でもそうですがこうした講座には最後にアンケートがつきものです。そして受講者はみなさん大人なので講座の評価をそこそこ

「有用だ」

と評価します。だって、業務に使えないと思ってそうマークしたら理由の欄にその理由を書かなければならないでしょう。

心から有用だと思う受講者もいるでしょう。受講したその日だけは。

翌日の現場では

週末でなければ翌日、現場で研修前までの仕事を再開するのですが、研修で学習した人間力とか組織活性化とか部下とのツーウエイコミュニケーションの講座のプラクティスを使うでしょうか。

それより、受講してもらってきたテキストはどうしたのでしょう。研修から家に帰ってそのまま本棚あたりに留置しているのではありませんか。よくても仕事場のキャビネの中に直行でしょう。

違うのはベンダーの有償講座で、技術的ノウハウが書かれたテキストは仕事場の机の上に置かれるケースが多いですね。よく見かけますし。ただ、基礎スキル系の○○力や組織開発や意識改革系は見かけたことはないです。

経営者は受講アンケートを見てはいけない

企業内研修で集合教育だと主催者は人事部になります。人事部も、経営課題の解決を経営者から振られるので、今後の企業を背負う中堅の次世代を担うゾーンを狙って改革にふさわしい人を人選するものです（たぶん）。

でも、現実は翌日以降の行動を見れば一目瞭然です。

人事部は受講アンケートをまとめて経営者に報告して振られた経営課題は「対応済み」とするのです。

経営者は、受講アンケートを見ても意味がないことを見抜かなければなりません。本当に調べさせなければならないことは翌日以降の効果測定です。

人、エンジニアに対して投資をしているのですから効果がなければなりません。効果がなければお金をドブに捨てているようなものです。

こうした考え方は、エンジニアの技術研修でも同じです。受講して学習したことを現場で使わなければ高額な受講料は受講者の自己満足で終わってしまうのです。特に、チームビルディングやプロジェクトの運営に関わる講座は。

受講者は誰が適切なのか

翌日の現場でのシーンで学べることは、

「学習したプラクティスを使う環境がなければ学習したことは使わない」

ということです。ましてや○○力などの組織に働きかけるテーマについては、中堅クラスの人が意識を持っても、

「周囲は誰ひとり同じような組織を変えることについて思っていない」

のです。受講者がひとり頑張っても単なる空回りなのです。

組織に変化を求めるのであれば、組織に影響力を与えるほどの権限を持っている人が最有力の候補者です。

もう一つ、

「組織全体に対して変化を受け入れさせる環境を作る」

こともできます。例えば、マネージャとプロジェクトチーム全員が受講したらどうでしょう。翌日、現場に戻るとプロジェクト関係者全員が同じ研修を受けているので、講座の中でチームに取り入れたいことを新たな知識の習得という負担がなく取り込むことができます。

人選するなら組織に対して変化することを持続し続ける権限を持っているか、チームなど組織単位で受講させないと組織もプロジェクト運営も変化は起きません。

「謙虚・尊敬・信頼」より「理解・信頼・対等」がチームに必要な価値観

facebookでここ数週間、「Team Geekを読んでよかったよ」というコメントがTLに流れたのですね。ツイッターほどじゃないけれどTLで目に止まるのは気にかけているからだし、気にかけているのは買ったのに積み本にしているから、なのですけれど。

じゃあ、「読んだら」なんですが、優先して読みたい本があるので、というそういうことも重なって、気にはなっているけれど、というあるあるな状況です。

さて、TLでも出てくるのが「HRTの原則」です。HRTは、

「優れた開発チームでは、謙虚(Humility)、尊敬(Respect)と信頼(Trust)の3つの価値が大切にされる」

というもので、チーム、組織、顧客とプロジェクトを運営する上でこの価値観を共有することで成功に繋げる、というもの。

気になる「謙虚・尊敬・信頼」の順序

読んでいないので、というのは間違っていたらごめんね、なのですが、自分の価値観から言えば、

尊敬＞信頼＞謙虚

何ですよね、ワタシ的には。ただ、尊敬とかは意味合いとしてどうなのかしら、と思うわけです。特に、

その人の人格をとうといものと認めてうやまうこと。

下線を引いた「敬う」という箇所。

dictionary.goo.ne.jp

尊敬ではなく理解ではないか

尊敬という言葉の意味合いを仕事で持つとか、人生で持ったことはないのです。

尊敬とは自分のできないことをできる人に対して持つ感情なのです。だから、無条件に自分ができない技術を持っていると「すごいな」と思うのです。

そして、プロジェクトチームを編成する際には、チームの目的を達成するためのチームとしてのスキルセットが必要になるので、メンバは必ず何かしら「すごい」エンジニアになるのです。

だから、けものフレンズのサーバルちゃんの

「すっごーい！○○が得意なフレンズなんだね」

は価値観が一緒なんですよ。

自分としては、尊敬より「理解」なのではないかと思うのです。

意味としては２番目の方の

「他人の気持ちや立場を察すること」

の方です。

dictionary.goo.ne.jp

○○ができるから信頼する

チームとして必要なスキルセットとスキルのレベルがチームの存在目的を達成するためにあるのですから、メンバには期待する貢献があるのです。

プロジェクトの中で、実際にアウトプットされたものの品質、スピードを確認するとはじめて、

「ここまでなら任せられる」

と信頼できるのです。プロジェクトマネージャの業なのか、性格なのかはわかりませんが、このどこまで任せられるは、どこまで放置しても同じ結果が得られるという信頼に基づいているものです。それを見誤ったら、自分で始末するんだな、という。

謙虚より対等

尊敬ではなく理解、アウトプットに対する信頼。あとは謙虚です。

謙虚は謙虚でもいいのですが、謙虚も辞書を引くと

「へりくだる」

とかあるのが今ひとつ感覚的に違うなぁ、と。

dictionary.goo.ne.jp

プロジェクトチームでは、役割分担をします。プロジェクトの目的を達成するために編成するチームですから、必然と目的達成が見込まれるスキルとレベルを持っているメンバで構成することについては前述したところです。

であればこそ、それぞれが得意なフレンズなのですから、へりくだったり慎ましくする必要はないのです。

ただ、相手を理解することにより、相手の存在を認めるのですから、上下関係はなく横一線に並ぶのです。つまり、チーム内は上下関係はなく、フラットな対等の関係であると思いますし、実際のチームビルディングをする際にはそれを明言しています。

変に気を使って言わなければならないことを言えない環境を作ることは望んでいませんから。

理解・信頼・対等がチームが成功するために持っておきたい価値観です。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

刺激を与えてれくる人が周囲に何人いるかで実現できるかがわかる

エンジニアとして成功するためには何をしたらいいのでしょう。技術を身につけ、プロジェクトで貢献し、ロールを移り、専門的な領域で名前が知られるというようなことかもしれません。

仮にそうした人物像を目指すとして、では、今、目指す人物像を実現できる環境にあるかと問われるとどうでしょうか。

環境の影響は見過ごせない

経験から言えることは、何かを実現したいときにはそれを実現できる環境が必要です。実現するために必要な要素がなければ、無いことを理由にして実現したいことを諦める理由を自ら作ってしまうからです。

自分の実現したいことを真剣に実現したいと望むなら、自分が言い訳するような退路を塞ぐ環境を作り、実現に向けて進めるだけなのです。実現したいと思うなら、思ったときに一歩を進められたかどうかで真剣さを測ることができます。

自分の実現したいことを実現する環境は誰も作れない

エンジニアとして実現したいことがあるなら何が必要かくらいは自分で調べることができます。プロジェクトチームの運営をより良くしたいなら、アジャイル開発系のプラクティスを取り入れることもひとつの方法です。

であれば、自身で学びながら実践している人の経験を聞いたり、相談に乗ってもらうのもひとつのエンジニアとして実現したいことを実現に近づけるための方法です。

そうした環境は誰も自分のためには作ることができません。

なぜなら、エンジニアとして何を実現したかは、自分自身しか知らないからです。

周りに刺激を与える人が何人いるか

環境を変えるために必要なことは、自分にとって刺激を与えてくれる人が何人いるかです。いくら自分で変わりたいと思っても、ひとりでは体験できる時間が短すぎます。ですからそうした経験のうち、周囲の人が体験したことを知ることで自分の体験のように刺激を与えるのです。

エンジニアとして実現したいことがあるのであれば、エンジニアとして使える時間、それは仕事中かもしれないし、オフの時間かもしれないです。いづれにしても自分で自由にできる時間に関係する度合いの高い人から書き出してみましょう。

実現したいことに対して刺激を与えてくれる人が何人いるか

その中に、エンジニアとして自分の実現したいことに刺激を与えてくれる人は何人いるでしょうか。

もし、ひとりもいなければ、刺激を与えてくれる人に自ら会いに行く機会を作らなければなりません。

仕事の中で自分の実現したいことに対して刺激を与えてくれる人がひとりもいなければ、オフの時間と自分のリソースを使う必要があるのです。

そうした機会を作っても、自分の実現したいことに刺激を与えてくれる、刺さる言葉を発してくれる人は限られます。つまり、機会を作れば確実に得られるものでもありません。何度も試行錯誤して、より高い刺激を与えてくれる人と関わりを持つことが必要です。

そのためには、give & takeの関係にならなければなりませんが。

刺激を与えてれくる人を３人作る

エンジニアとして実現したいことに影響を与えるほどの刺激を与える人は何人つくればいいのでしょうか。

経験から言えば、３人が望ましいです。ワタシの場合は元のマネージャが２０代からずっとお付き合いさせていただいていますが、これは会うたびに刺激をもらえるからです。

あとはアジャイル界隈の方。そして気づきを与えてくれるワイフ。

まだまだ実現したいことはあるので、元マネージャとワイフを除き、ステージごとで変わって行くかもしれません。

積み本

これは買ってみよう。Kindleも値段同じなら紙だよなぁ。

でもこれ、年間購読にした方が良いのかも…。

ダイヤモンドハーバードビジネスレビュー 2017年 04 月号 [雑誌] (人材育成)

ダイヤモンドハーバードビジネスレビュー 2016年 9 月号 [雑誌] (イノベーションのジレンマ)

ダイヤモンドハーバードビジネスレビュー 2017年 01 月号 [雑誌] (未来を予測する技術)

低待遇でエンジニアを採用しようとする企業は、教育コストに対する価値観を物語っている

medium.com

ごもっともです。ワタシも是非とも高額で御採用のオファーがあれば考えなくもないです。こちらの前提は、今のポジションと仕事の面白みと残りのエンジニアとしてのキャリア（プロジェクントマネージメントとマネージャの専門性を生かせる）とするならば、ですけど。

優秀なエンジニアって何？

先のエントリを読んで、言っていることはわかる。が正直なところです。ただ、各社の採用する側が

「優秀なエンジニアを採用したい」

という優秀なエンジニアとはどんなエンジニアかは各社によるのです。なぜなら、各社の事業内容や事業の進捗により必要とするエンジニアに多様性があるからです。

では定義できないのかといえば、そんなこともありません。

でも、優秀なエンジニアを各社で共有できるように表現するとすれば、ITSSv3のレベル７の人物像のようなものにならざるを得ません。各社の事業を振り落とし、共通項としてしか表現の仕様がありませんから。

今必要な、優秀なエンジニアを示す

採用する各社も今必要な優秀なエンジニアやこれから３年以内（の中期経営計画など）で必要となる優秀なエンジニアの人物像なら示すことができます、というか示すことができなければなりません。事業をしている側の経営者や採用部門なのですから。

肝心なことは、「今必要な」です。事業を継続することが企業を存続させるために必要なことですから、経年すれば事業ステージも主要な事業も変わっていくものです。

だからこそ、今必要とする優秀なエンジニアの人物像が描けなければなりません。

優秀なエンジニアが採用できない理由

もし、採用で自社が必要とする優秀なエンジニアの採用ができていないとするならば、採用側が必要とする優秀なエンジニアの応募条件を示すことができていない可能性がとても高いです。優秀なエンジニアを必要とする採用側の各社がこのアクティビティの主体者である限り、優秀なエンジニアにリーチし、取り込むところまでが役割分担なのですから。

では、優秀なエンジニアを採用できない理由のうち、優秀なエンジニアが採用したい各社に接触するまでにどのような障害があるのでしょうか。

採用担当ではなくても、応募する側としての視点でも仮説を示すことはできます。優秀なエンジニアを採用できていない理由で想定できることは次のとおりです。

・優秀なエンジニアにリーチできていない
・欲しい人材が持っていなければならない諸元を示すことができていない
・曖昧さ故に、応募側が回避している
・応募があってもミスマッチを起こして不採用となっている
・必要とするスペックを持っている優秀なエンジニアが元々この世に存在していない

採用での低待遇は将来の教育コストを示している

結論から書けば、本来、自社で育成するところをすっ飛ばしていきなり即戦力、それも優秀なエンジニアを欲しいというのは子どものわがままのようなものです。

本来であれば、自社で育成するところの時間と手間を端折っているのですから。

逆にいえば、本来自社で育成し負担する育成コストをどう見ているか、という育成に対する価値観を応募するエンジニア側から探る指標ということができます。

応募する側で注意をしておく点がもう一つあります。本来自社で育成することができないのは自社で育成する力量がない他に事業を進める上で育成している時間をコストとして買っているというケースもあるのでどちらの理由で中途採用しているのか、です。

ただ、いづれにしても優秀なエンジニアを採用したい各社は、事業を進める上で中途採用する他に手段がないのです。

手段がないのであれば、育成または時間を買うのですから、相応の教育コストを盛り込む必要があります。それを含めた待遇となっているかどうかが判断ポイントなのです。

つまり、低待遇で優秀なエンジニアを採用としているとするならば、

「採用後の育成コストに投資するつもりはない」

というメッセージと捉えて良いのです。だからこそ、低待遇では優秀なエンジニアを採用することができないのです。

ワーク・ルールズ！―君の生き方とリーダーシップを変える