[書籍レビュー] エンジニア育成現場の「失敗」集めてみた。

エンジニアの育成現場の失敗談なんて、個人的にも辞書ができるほど持っていますし、 他人の話は金を出してでも聞きたい内容！ というわけで、以前の「開発現場の失敗談」の続編でもある、このシリーズ書籍を今回は手に取ってみました。

レビュー

★★★★☆

漫画テイストで読み進められるので、非常に読みやすくわかりやすいこのシリーズ大好きです。 架空の会社なんだけど、なんだかちょっぴりリアルな、開発内容や、中で起きる出来事が、 開発の人であれば、アルアル的なものが多いので、読んでて他人事とは思えない不思議な感覚になる書籍です。 新人エンジニアが入社したところから、その彼の育成に始まり、業務中のトラブルまで、本当に耳の痛い話の連続で、 人の上に立つ人はこうあるべきが書かれている良書ですね。 マイテーマ毎に書かれているまとめの文言をちゃんと理解するだけでも、この本を読む価値がありそうですね。 ただ、まだ部下のマネジメント経験がない人は、理解しずらい（記憶に留めることが難しい）箇所がいくつかあり、 現在、部下マネジメントに悩んでいるエンジニア管理職の人が読むのがいいと思います。

この書籍の学びポイント

いつものように、要約まではいきませんが、個人的に覚えておきたい内容をかいつまんで紹介します。

コーディングをしない技術者育成

システム開発を効率がいいからといって、外注してばかりしる会社は、自社内の技術者スキルが伸びません。 社内にいる技術者は、多少のスキル保持者として、害虫との技術の仕様極めをしたり設計構築をするだけで、実際にコードを書かないことから、スキルが伸びません。 そんな外注し放題の会社の内部教育体制は、技術力を持たない技術者を育てることが、会社で当たり前になってしまいます。 こうした会社はおそらくは技術者が短年で退職してしまう、退職率の高い会社になっていることでしょう。

やる気のたらい回し

中小規模の会社では、部署異動はしょっちゅう発生します。 エンジニア部門に限らず、新人は「いろいろな経験をさせる」という名目で、たくさんの部門に短期間でたらい回しにされてしまうケースが多いようです。 会社ではとにかくやる気と素直さが求められ、新人はこれらに合致するのと、スキルアップという名目で、このたらい回し業務に従事させられてしまいますが、短い期間で次々の業務をさせられると、その業務を覚え始めたあたりで別の作業に移ってしまうため、まるでスキルがたまりません。 多くの場合は、マネジメント担当者というよりも、経営者が将棋盤のコマを並べ替えるかのように、従業員の配置をどんどんその時の思いつきで並べ替えていく、ボードゲームさながらのゲームを行っているのが原因かもですね。 自分もこうした場面は何度も見かけたことがあります。 間違いなく、こうした会社も従業員退職率は極めて高い傾向があるんですよね。

ダメになるまで報告しない「ホウレンソオウ」

何か問題が起きたら、上司に連絡するのは、仕事のあたりまですが、本当は問題が起きる前に報告する方がいいに決まっています。 このままいけば、大きな問題に発展すると感じた部下や担当者は、そのまま報告すればいいとだけ思うのが上司だけで、 現場は「問題が起きる前になんとかなるだろう」的に考えています。 こういう風にならないために、上司と部下は親密な心の通ったコミュニケーションをしておかなければいけないのですが、 組織間のコミュニケーションがチャットだけなどの場合に、「問題は隠したがる」心理に陥ります。 リスクはなるべく隠して、「自己評価が高くなる報告をしたくなる」のも、人として当然の真理ですからね。 ホウレンソウは、報告が重視されていて、「早く言ってよ！」と上司として思っている人は、大きな勘違いをしていて、 「相談」が一番重要であるという点ですね。 相談も無しに、リスクの報告ってあり得ませんからね。 心の通った上司に対して、リスクを相談すること自体が、報告なんですよね。

計画を見直すだけのPDCA

Plan - Do - Check - Action で、お馴染みの "PDCA" ですが、見直しをせずに、回すだけのPDCAが行われガチです。 回し方を知らないと、やる意味がまるでないので、PDCAのタイミングなど、適切に理解していつもより余分に回してあげましょう。

「必殺技」を持つ技術者を育てよう

人は誰でもそれぞれの長所を持っているし、自分でやりたい事というモノがあります。 上司はそれらを伸ばすために、部下にあだ名をつけるといいらしいですね。 この本には、「ヒットメーカー」や「いいかげん技術者」というあだ名が紹介されていましたが、 悪口ではなく、これらを特性にその技術者の特性が一言でわかるため、周囲の人も、そのエンジニアの扱い方がわかりやすくなるのもわかります。 それをさらに、「ネットワークの魔術師」みたいなあだ名をつけると、もはやインフラが得意だろうな・・・というのもわかるし、 その道のプロになるお膳立てが整うことにもなるでしょう。

業務の目的を伝えない上司

「これやっといて」とだけ言って、仕事を他人（部下など）に丸投げする上司がいます。 なんのためにやるのかという、目的も伝えずに、「言われた通りにやっとけ」的な仕事をすると、間違ったものが出来上がっても何も文句は言えないでしょう。 こうした時のお決まりのセリフとして「わからないことがあったらなんでも聞いて」と言い捨てることです。 でも実際に、少しわからないことを聞いただけで「こんなこともわからないの？」みたいな怪訝な対応をされたら、もはや信頼関係はゼロになってしまいますよ。

会社ないのアイデア発送会という名の地獄会

新人のアイデアは、まだ会社に染まっていないから「斬新なアイデアを思いつくに違いない」という思い込みで、新人だけで、アイデア会を開催する会社は跡をたちません。 そして、その会社のキャパや軍資金を無視したアイデアが続出し、アイデア止まりになってしまう、単なるブレスト会になるケースが少なくないようです。 個人的にですが、新規事業のアイデアを募集して、会社の新たな軸を作ろうと模索する会社が増えているのか、別の会社の「新規事業担当者」という人によく出逢います。 アイデアというのは、よく「発想」という風に思うかもしれませんが、実際は、「様々な知識の組み合わせ」によって起こるのがアイデアだと考えられます。 ということは、人生経験の多い、知識量の多い人の方が、斬新なアイデアって生まれやすいはずなんですよね。 これを新人に押し付けるようなアイデア会は、その会社がダメと言っているようにも聞こえるので、新人が新規事業部門にいる場合は、その会社のスタンスを疑ってみてもいいかもですね。

マルチランゲージは日本語、ドイツ語でチェックせよ

この書籍には、「チェックせよ」とは書いていませんでしたが、ECサイトなどのようにお金を扱ったり、数値を表示するシステムを構築する際に、 日本やアメリカでは、1000円を、"1,000"とカンマ付きで数字を書きますが、 ドイツでは、"1.000"と、ピリオド区切りの数値になります。 勘のいい人ならお察しだと思いますが、小数点の場合は、次のようになります。

日本 : "1,000.00" ドイツ : "1.000,00"

これを知らずに、金額を数値に変換する時に、カンマとピリオドを、文字列として処理しようとしたら、不具合につながります。 こうならないために、ライブラリなどを使って行えばいいのえすが、そもそも技術者として、こうした知識も必要という事ですね。

一匹狼エンジニア上司

「今時の若者は、」は、いつの時代もこすり倒されている、老害擁護です。 今現在のシニアエンジニアは、多くの技術を自分が本で読み、業務で経験して学んできたケースが多いでしょう。 その経験を自負して、新人エンジニアに対して、

C#が書けるのに、オブジェクト思考を知らないの？ サーバーを立てたことがない？ コマンドラインも知らない？

こんな風に、マウントをとりたがる上司が少なくないです。 最近では、技術系の専門学校なども増えてきて、そこでも多くやっているメンター制度というのが今時の師弟制度です。 ペアプロなどを通して、OJTを行うのは、非常に学習効率と実務効率のいいやり方になっているようですね。

最新技術のキャッチアップができていない「伝統技術の継承者」

「ウチの会社は、これだけやっとけばいい」という開発部門がよくあります。 いまだにサーバーモジュールが古いバージョンのソフトウェアを使っていたり、 数十年来、ほぼアップデートされていないフレームワークを使っているシステム開発だったり・・・ CTOがまるで最新技術キャッチアップができない会社などもあります。 エンジニアは、自分の将来目標や、仕事のやりがいを、「自己スキルアップ」と考える人が多いんです。 それを、他社でまるで通用しないその会社だけの技術なんて、やりたがる新人エンジニアなんて、ほぼいませんからね。

より良いチームの6要素

①目標：意義のある高いミッションがあり、目標が明確になっている ②役割：各自の役割が明確で、必要な権限が委譲されている ③オープン：オープンでフラットなコミュニケーションができる ④学び：新しい技術を学ぶ機会が与えられている。失敗から学びカイゼンできる ⑤安心：目標を達成するまでチームが壊されない。失敗を許容するゆとり、あるいは仕組みがある ⑥ 特別感：チームに属することの特別感（ロイヤリティ）がある

成果がはっきりしない「ほんわか目標設定」

多くの会社組織で、評価制度というのを導入していて、KPIに基づいて査定などを行なっていると思います。 その際に、"成果"が明確にならない目標を設定しているケースがエンジニア組織には多い傾向があります。 「このプロジェクトを完了させる」とか「便利なツールを1つ作る」 こんな目標を立ててしまって、目標の結果の場面で、 「プロジェクトは完了させたけど、バグがいっぱい残ってしまっている状態」 「ツールは作ったけど、便利かどうかはわからない・・・」 要するに、定量目標になっていないのが問題なのです。 営業部門は、売り上げ目標という明確な定量目標が存在しますが、バックオフィスや、技術系、研究系、デザイン作業、コンテンツ制作・・・ これらのような数値で表すのが難しい業種に関しては、明確な数値はちょっとしたコツがあります。 この書籍には、「動詞の成果目標には要注意」と書かれていて、「作る」「完成させる」という動詞だけの目標は、あやふやになりがちだと説明されていました。 どの動詞でどうなったらプラスで、どういう状態がマイナスなのかを明確にするというのが、コツのようですね。 作文能力も少し必要になるかもしれませんね。 とはいえ、「成果主義」になりがちな日本文化ですが、チームとしての指標や頑張りは、評価に値するケースもあるので、その辺は、上司であるマネジメント担当者の評価につながるということですね。

すべての無駄を排除する「やりすぎDX化」

働き方改革という、徹底的な無駄を排除する思考は、本当に人を幸せにするのでしょうか？ 個人的には、仕事時間外の作業の方が開発作業が捗るといった経験はこれまで何度も経験してきました。 「残業をしてはいけないけど、業務時間は何が何でも会社に来て仕事をする」 こんな会社は、本当に無駄を無くせているんでしょうか？ フレックスタイムという、裁量労働制で、その人の一番効率のいいタイミングで仕事ができるという働き方改革ができている会社が、そこで働く人が成果を出せて、満足度も高く保てる会社なんじゃないかと思うんですよね。 書籍には、「無駄が必要」というまあまあ尖ったことが書かれており、

・思考する時間 ・休憩する時間 ・知識をインプットする時間 ・知識を共有する時間 ・失敗する時間

これらが必要なのだそうです。

管理職の資質チェックリスト

管理職に向いているかどうかを測るチェックリストが書かれていました（筆者考案）

組織全員の顔と名前を知っている 自分の部下の顔色を把握している（今日は気か、疲れていそうか） 自分の部下のキャリアプランを理解している 自分の部下が今何をしているのか知っている 自分の部下の長所や得意技を理解している 職場に昼食を一緒に取る友人がいる 雑談をよくする

ポイントは、「人を好きになれるかどうか」なのだそうです。

面接で探すべきは「普遍的な長所」

企業における採用活動は、重要な人材確保のための活動でもあります。 慣れない面接で大変な思いをしたエンジニアも多いと思いますが、 次のポイントを踏まえておくと、困ることが少なくなるかもしれません。

・健康で前向き ・自分で考え、自分で行動できる ・人の話を傾聴できる、コミュニケーションが取れる ・ロジカルで地頭力がある ・向上心があり、学ぶ力を持っている ・ストレスに比較的強い ・自分のやりたいことや希望、夢を持っている ・ソフトウェアを組んだことがある（可能なら）

個人的には、これに加えて、以下のポイントを加えてよく面接をしています。

・ギャンブルをしない ・タバコを吸わない ・運動が嫌いじゃない ・楽しい話ができる ・好きになれる一面を持っている

あとがき

人は「失敗」をして、色々な事に対する気付きを得ることができます。 失敗をしたことがない人って、魅力も何も感じません。 だって、成功した話ばかりする人と、失敗談を話す人って、どっちが好感が持てるかと言ったら、圧倒的に後者になるはずです。 好きな人や推しの人の成功話は聞いても面白いと思いますが、 初対面や、コミュニケーションの場での成功話は、単なる「自慢話」にしか相手に届きません。 「人を上から見下す人」と「いつも腰が低い人」 「過去の事ばかり話す人」と「未来の希望を話す人」 「暗い話し方をする人」と「失敗を明るく話す人」 どれも、他人から好まれるのは、かなりハッキリとしていると思います。 いつも残念に思うのは、他人から好まれない振る舞いをしているのに、本人が気がついていない「裸の王様タイプ」の人です。 今回の書籍では、そういうタイプの人と自分を置き換えて色々とイメージできたいい経験が体験できるいい書籍でしたね。