「エンジニア育成現場の「失敗」集めてみた」という育成現場での失敗例をまとめた本を読んだので、その感想をまとめていきます。
「ソフトウェア開発現場の「失敗」集めてみた」の続編となっており、前作がコミカルなキャラクターベースで解説が進んで非常に分かりやすかったため、今作もきっといいだろうと思い、期待しながら読み進めました。
自分はまだリーダー的な立場は未経験なのですが、今後リーダー経験を求められていく可能性が高いため、マネジメントスキルも事前に身に付けていきたいと思ったことも、この本を手に取るきっかけとなっています。
全体的に今回も勉強になる点が山ほどあったのですが、Chapterごとに印象に残った点を挙げながら、学びになったことを記載していこうと思います。
Chapter 1：「新人研修」で失敗
新人が入って来たばかりの時に行う研修での失敗を集めた章。
自分が新卒の会社で起こった出来事を思い出しながら読みました。
例えば「Episode5：完璧な報告を強制する「賢者のレポート」」は自分でも思い当たる部分があります。
新人の時にレポートや議事録を何度も何度も書き直させられて、研修が進められないという事態が発生したのです。まさにこのエピソードで取り上げられていることが、そのまま自分の身にも降りかかりました。
特に議事録に関しては、たまたまその時私が担当になってしまって、他の人はメインの作業を進めているのに、自分だけ会議で話された全てのニュアンスを完璧に表現できるまでいつまでも書き直させられたのです。
結果、OKが出るまで3日も掛かってしまい、研修にも遅れが出る結果に。この時かなり自信を無くしましたし、こうなるなら業務の目的やゴールをしっかりとこちらに伝えて欲しかったな……と悲しくなった記憶があります。
この会社は1年もせずに辞めてしまったのですが、今考えると、この辺りから不信感が募っていたのだと思います。後輩指導をする時は気を付けなければ……と、改めて噛み締めました。
Chapter 2：「OJT」で失敗
表題通り、OJTでの失敗を集めた章。
これは経験したと思うものから、こんなことも起こり得るのかというエピソードが揃っていました。
例えば「Episode16：テスト不要で機能を通す「裏口リリース」」ですが、今の現場が仕様は全てオープンになっており、設計書のレビューやコードレビューを行う体制も整っているため、隠し機能を入れたりしたら即バレるため、このような事案が発生するイメージがすぐには付きませんでした。
しかし、前にいた会社では非エンジニアがほとんどのベンチャー企業だということもあり、開発ノウハウがほとんど溜まっておらず、フローも整っていなかったため、そうなると、このような勝手な機能を盛り込むエンジニアが発生してもおかしくないかも……となりました。むしろ、いなかったことの方が奇跡……。
途端に冷汗が出てきたので、事細かく開発フローを整えておく必要性を改めて感じました。
Chapter 3：「チーム編成」で失敗
チームの配属やチームの形成についての失敗を集めた章。
こちらも新卒の会社でのことですが、「Episode21：コロコロチームが変わる「社内フリーター」」内で書かれていることがまさに起こりました。
研修が終わり、最初に配属されたチームの業務を少しずつ任されるようになったのですが、先方の遅れで新人に振れる仕事がしばらくないという理由によって、2週間ほどでこのチームを抜けることになってしまったのです。
その後、他のチームへの配属が決まるまでのつなぎとして、更に2週間ほど最初のチームと関連したチームで設計書の修正などをすることになり、その後、全く違った業務内容のチームに配属。結果、1ヶ月ちょっとで3つのチームをたらい回しにされることに。
最初に話したキャリアプランにも全く沿わすことなく配属を転々とさせられたので、不信感も更に強くなり、入社して数か月でかなり疲弊してしまいました。
本書では最低でも3年と書かれており、本来だったらこのくらい長い期間が必要と思いつつ、会社都合でリーダーになってもコントロールできない箇所はあるため、せめて新人の時は1年だけでも安定的に同じチームに関わらせてほしいなと思いました。そして、自分自身も新人がたらい回しをされそうになっている場面に遭遇したら、新人の話をちゃんと聞きつつ説得ができるようなリーダーになりたいです。
Chapter 4：「評価」で失敗
評価については、評価をされる側もする側もそれぞれ大変だろうことが想像つくので、自分が今まで評価されてきた側に立ちつつ、評価する側に立った時はどうするか、とイメージしながら読み進めました。
「Episode27：チームの成果を独り占め「エース技術者推し」」でも取り上げられていましたが、画一的な視点で評価をし、特定のメンバーのみ持ち上げるというシチュエーションは、新卒で入った会社でも目撃しました。
評価する側に立った際、どうしても優秀なエンジニアにのみ目が向いてしまうのはわかるのですが、メンバーそれぞれがチームの目標達成に寄与しているのにも関わらず、それを蔑ろにしてしまうのは今後の仕事に対するモチベーションが下がってしまいます。私も評価される側でそれをやられたことで、会社を辞める一つのきっかけになりました。
チームの中での頑張りを認められたうえで改善点を伝えられた方が、もっとこの会社に貢献していこうと考えられるようになるので、評価する立場になったとしても、この気持ちを忘れずに部下たちを評価していけたらなと思います。
Chapter 5：「コミュニケーション」で失敗
リーダーとメンバー間のコミュニケーションの失敗を集めた章。
全体的に読んでいて本当に頭の痛くなる章でした……。
なぜかというと、前職でとあるチーム編成になった際、リーダーになった人がこの話に登場するダイ・カチョーさんのように部下に対して圧を掛けてくる人だったからです。
毎日朝会をしていたのですが、一日のスケジュールを「10:00～12:00は〇〇のコーディングをする」「12:00～12:15は〇〇さんのレビューをやる」というように細かく伝えなければならず、時間区切りで何をやっているのかを監視されている状態になっていました。
それでも、どうしても臨時のタスクは発生するもの。そうすると、最初に組んだスケジュールを見直さなければならず、その際逐一リーダーにスケジュールを変更する旨を伝えていたのです。
しかし、こんなの窮屈で仕方ない。時間通りに進めないといけないという緊張感で、どんどん委縮するようになり、作業効率も下がってしまいました。
「Episode31：すべてのムダを排除する「やりすぎDX化」」に書かれているように、業務の間に発生する「無駄な時間」というものが仕事には必要です。今の会社では朝会で作業報告はするものの、一日の時間単位で細かく管理されるみたいなことはないので、本当に作業がしやすくて助かっています……！ ありがたい！
自分がリーダーの立場になった際も、この辺りは気を付けて、のびのびと部下たちが仕事できる環境を整えていきたいです。
Chapter 6：「採用」で失敗
自分はまだ採用を担当したことがないのですが、選ぶ側も大変だろうことは容易に想像が付きます。
「Episode38：スキル重視の新卒採用「スペック偏愛採用」」では、面接者のスキルのみを重視して、チームに馴染めない人を採用してしまったエピソードが載っていますが、やっぱり一緒に働く人を選ぶとなると、最終的にはチームに合う人物像が重要になってくるのだなと実感しました。
面接をされて選ばれる側だと、こんなにスキルがマッチしているのに、どうして不採用になっちゃったんだろう……とショックを受けてしまいますが、チームを円滑に動かしていくとなると、スキルだけではどうにもならない部分が大きいですよね。間違った人を採用して、新人も含めたメンバーがどんどん退職してしまったら業務も回らなくなるし、何よりも辛いし……。
チームに誰が入るかによって雰囲気がガラッと変わることは私も経験済みなので、そのことを忘れず、もし採用担当になったら、採りたい人物像をまとめてから面接に挑みたいなと思いました。
まとめ
全体的に新人を辞めさせず、どう組織に馴染んで戦力となってもらうか、という視点で書かれている印象を受けました。
誰もが新人だった時がありつつも、経験を重ねていくうちに、初めての環境や仕事で戸惑った経験を忘れてしまいがちです。
忘れていなかったとしても、リーダーとしてこうしたいという想いと、実際に目の前で起こっていることのギャップなども頻繁に発生してしまいそうです。
リーダーになったら葛藤も多々ありそうですが、その中でもこの本で学んだ内容を忘れず、時には読み返すことで、新人教育の基礎に返りたいなと思います。