Yahoo! JAPAN

Learn from the mistakes of others. You can't live long enough to make them all yourself.
（他人の失敗から学びなさい。自分ですべての失敗ができるほど、あなたは長くは生きられないのだから。）
ーー米第32代大統領夫人、Eleanor Roosevelt

引用：エンジニア育成現場の「失敗」集めてみた。 42の失敗事例で学ぶマネジメントのうまい進めかた（翔泳社）

成長には失敗が付きもの……とはいえ、かの有名なフランクリン・ルーズベルトの妻、エレノア・ルーズベルトが残したこの言葉の通り、われわれに与えられた時間は有限だ。

しかも、目の前には締め切りが迫るタスクや失敗の許されない（気がする）作業がずらり。隠された落とし穴があるなら、最初から教えておいてほしいーー

そんなエンジニアたちに絶大な支持を集めた出石聡史さんの著書『ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた』（翔泳社）の、待望の第2弾が2025年6月11日に発売された。その名も、『エンジニア育成現場の「失敗」集めてみた。 42の失敗事例で学ぶマネジメントのうまい進めかた』（翔泳社）だ。

タイトルの通り、今回のテーマは「マネジメント」。新人研修、チーム編成、評価など、開発組織をリードするリーダーやマネジャーたちの悩みの種が、リアルなエピソードで紹介されている、まさにEMたちにとっての失敗の教科書といえる一冊だ。

今回は発売間もない本書より、2つのエピソードを引用して紹介しよう。

目次

はじめに失敗の経験を与えない「一流技術者のメッキ」 ーー問題はすべて先輩が解決全部先輩がやってくれる企業にとって成果以外はすべて負債作られた成功体験が戦力外人材を育てる失敗という礎の上に成功が築かれる失敗するゆとりを計画する権限を持たせない「人間将棋の駒」 ーー作業を指示して動かすだけ謎の作業指示が下りてくる権限って委譲できるんですか？なんちゃって権限委譲自由にできるモノを渡す書籍情報

はじめに

本書で扱う架空の組織とプロジェクトについて

本書ではエンジニアの採用や育成の失敗を追体験できるよう、架空の開発組織とプロジェクトを舞台にしたエピソードを紹介します。また登場人物も明らかにフィクションであるとわかるように、全員ロボットにしています。ただ、それ自体重要な要素ではありませんので、あまり気にせずに読み進めていただければと思います。

失敗の経験を与えない「一流技術者のメッキ」

ーー問題はすべて先輩が解決

新人のころは失敗するのが当たり前、というか失敗するのが仕事だといってもいいでしょう。一方、日本では成果主義の会社も増えており、新人も1年目から失敗の許されない困難かつ重要な課題を与えられてしまいます。そのため、先輩たちもついつい過保護になり、正解をすぐに渡してしまいます。望外の成果を上げさせられた新人は本当の自分の実力と、成果とのギャップに悩むことになります。

全部先輩がやってくれる

ガクさんの同期会では、ドウイチさんやドウニさんが、チームに配属されたけど放置されているとか、先輩から技術を教えてもらえないという話で盛り上がっていました。その話を横で聞いていたドウミさんも、思わず会話に加わりました。

ドウミ：うちは逆に教えてくれすぎるっていうか。先輩が私の課題を全部やってくれちゃうのよね……。

ガク：え、どういうこと？ ドウミさんは企画の部署だったよね。どんな仕事しているの？

ドウミ：そう企画部。新人らしい新事業企画を考えなさいっていうのが業務なんだけど、先輩に指示された内容を資料化して、それで終わり。先輩からこういう事業が面白いかもと言われるまま、報告書にまとめるのが仕事。自分で考えたところはゼロね。あー、資料をまとめるスキルは上がったかもしれないけど。

ドウミさんにもかなり不満がたまっているようで少し毒舌ぎみです。確かに企画部に配属となったからには、自分のアイデアを試せると思うのは当然です。

ドウミ：ツラいのはそうやって作った企画書を褒められることよ。スバラシイ新人らしい観点だ！ とか言われても、それは先輩のアイデアなんですとしか……。しかもその褒められた企画書はそのままお蔵入り。どうして良いと言ってくれたのに採用しないのかしら？ 新人向けリップサービス？

ドウイチ：それは確かに面白くないのもわかるなあ。うちのような完全放置もつらいけど、全部やってくれると自分の存在意義がない。

ドウミ：でしょ。いや新人が即採用されるような企画を立てられるわけがない、というのはわかっているのよ。でも中身に一切自分が関わっていないのは、仕事としても面白くないし。このままここにいても自分に企画力が付くのか不安なのよね。

ドウミさんとはあまり話したことのなかったガクさんは、おとなしめの外見とは裏腹に、彼女がこんなに熱い人だったのかと感心しながら話を聞いていました。

ガク：ハルさんは、どちらかというと失敗をフォローしてくれるって感じだなあ。そもそもシンテクさんなんか、毎日何かやらかして自爆している気がするし。今の職場が楽しいのは、自分で考えて試せるというところなのかも。

企業にとって成果以外はすべて負債

企業活動というものは、直接的だろうが間接的だろうがお金にならないといけません。何事も金だなんて、さもしいやつだと思われるかもしれませんが、企業とはそもそもお金儲けをするために集まった集団であります。お金儲けの結果、社会に貢献し従業員の生活が安定して、みんなが幸せになるのです。

そんなわけで昨今、企業は新人をリクルートするにあたっても、即戦力を求めますし、新人は入社して間もないころから、業務に高い成果を期待されます。経営層から各リーダーに対して「新人に成果を持たせるように」「意義のある業務を任せるように」というプレッシャーがかかることも少なくありません。さらに新人が配属されたプロジェクトに遅れがある場合には、「即戦力として配属したのだから遅れを解消できるはずだ」とか、「新人に成果が出ないのはリーダーの責任だ」「他部署のほうが適しているのではないか？」といった声が下りてきます。

そうはいっても新人はまだ新人なのですから、1年目からそんなにすごい成果を出せるわけがありません。どんなに能力があっても知らないことはできませんし、経験が必要な業務もあるでしょう。

一方、リーダーは上位マネジメント層の期待に応える必要があります。新人にはよい成果を出してもらい、チームから引き抜かれることを阻止しなければなりません。そのためつい過剰にサポートしてしまうことがあります。

作られた成功体験が戦力外人材を育てる

しかし、新人にそのような「作られた成功体験」を持たせてしまうと、様々な弊害を招くことになります。

・自分で考えていないので、技術力が付かない
・自分で考えていないので、達成感がない
・失敗経験が少ないため、未知のトラブルに対する処置ができない

自分で考えたことに取り組む機会が得られず、技術力も向上しない状況が続くと、新人にとっては仕事がどんどん面白くなくなっていきます。その結果、「この組織ではスキルや技術力が伸びない」「先輩が解決してくれるなら、自分がこのチームにいる意味はない」と感じるようになります。こうした状況では、自分が会社に貢献している実感を得られず、モチベーションや組織へのロイヤリティが大きく低下します。

多少失敗しようとも、自分で考えて自分でやったことであれば自分の力にもなりますし、自分のせいで問題が発生したのであれば自分でリカバーしてやろうという気概も生まれます。反対に、考えなくてもいいから言われた通りにだけやっておけ、という指示のもとでは、自分の価値を感じることができず、やる気がなくなります。

ここが今回の失敗のポイントです。課題に対して直接的な答えを与えることで、新人が自分で考え学ぶ機会を奪ってしまいました。新人のときこそ、様々な失敗をし、失敗から学ぶ機会が必要なのに、誰かの力で成果を肩代わりしてしまうと、実力が得られないまま中堅になってしまいます。即戦力として入ってきたはずなのに、困難な業務をこなすスキルも得られず、経験が足りないため直面したトラブルや課題に対して十分に対応できない「戦力外人材」に育ってしまう可能性があります。

ハル：ついつい答えを教えたくなるんだよ。そのほうが楽だもん。でも自分で考えたことを自分でやってみることが、技術者の一番楽しいところだからなあ。

失敗という礎の上に成功が築かれる

実際のところ、失敗を避けては成功をつかむことはできません。世の中、成功か失敗かそのどちらかを選ぶY字路があるわけではなく、成功は失敗の積み重ねの上に築かれます。もしすぎた助力によって課題をクリアし、失敗の経験なく成功体験だけを積ませても、その後自分の力で成功を収めることが難しくなってしまいます。

［図］失敗という礎の上に成功が築かれる

しかし、そんなことは皆わかっていても、組織として実際に失敗を許容する体制や、新人に失敗をさせる仕組みを整えることは、なかなか難しいのが実情です。だいたい、失敗を報告しても次のような感じで失敗をリカバーさせられます。

部下：「 部長！　失敗しました。でも学びになりましたよ。失敗を取り戻す時間が必要なので、リリース延ばしていただけますか？」
上司：「 うむ、よい失敗をしたな。だがリリース日は決まっているので延ばすのは無理だし、予算も決まっているから人の追加も無理だ。すまんが明日までにリカバー案を出してくれ」

口では失敗を許容していても、その実、失敗した人にリカバーさせるというのがよくあるパターンではないでしょうか。つまり実質組織として失敗は許容できない仕組みになっているのです。

失敗するゆとりを計画する

そこで、最初から新人や若手が失敗するゆとりをプロジェクト計画に盛り込んでおくべきです。若手に任せる業務は、ベテラン技術者が携わった場合の1.5倍から2倍の時間がかかる、ぐらいの想定で計画を立てるのです。もちろんベテラン技術者によるサポートも必要ですから、その時間も計画に織り込む必要があります。それだけ育成にはコストが必要であることをリーダーは理解すべきです。

重要なのは、答えそのものではなく、やり方を指導することです。自分で考え、自分でやってみて、素早く失敗し、学んでやり直すというやり方（プロセス）が大切です。リーダーはできるだけ本人が自然と自分で考え、失敗を経験し、自ら学べる機会を計画することです。

とはいえ、さすがに失敗ばかりだとやる気も業務も破綻してしまいますから、早期に小さく成功するためのサポートも大切です。

プロジェクトや組織はこうした教育育成のコストも込みで、費用対効果を計算しなければなりません。今この課題を解決するという視点ではなく、組織が継続して新しい課題を解決でき、よい品質の製品を世の中に出せるチームとして成長し続けるにはどうすればよいのか、という視点を持つことが重要です。

権限を持たせない「人間将棋の駒」

ーー作業を指示して動かすだけ

新人はまだ仕事に関して半人前です。「やれ」というだけでは何をどうしたらいいのかわかりません。そのため、最初は上司から細かく指示を与えることも必要でしょう。とはいえ、作業指示ばかりしていると、肝心の業務目的を理解し、課題を発見して解決のために工夫する力が育たなくなります。その結果、言われたことしか実行できないマシンのようになり、力はあるのに自分では動けない将棋の駒となってしまいます。

謎の作業指示が下りてくる

校正アプリの設計が終わり、ようやく実装に入ることになりました。ハルさんの意向もあり、今回はテストファーストで実装を進めていくことになりました。ガクさんは手始めにファイル保存に関する機能テストのコードを書き始めたのですが、そこへハルさんが慌ててやってきました。

ハル：ごめん。ちょっと仕様を変えるね。ここのUIはウインドウを1つにまとめて、こんな風に変更してほしいんだよ。

ハルさんはそう言ってポンチ絵をガクさんに手渡しました。なぜ急な変更になったのかわかりませんが、まあそういうこともあるのだろうと、ガクさんはUI仕様書を変更し、改めて機能テストのコードを書き始めました。

テストコードがあらかたできあがり、さて機能の実装に入ろうとしていたところへ、またしてもハルさんが申し訳なさそうにやってきました。

ハル：またちょっとお願いなのだけど、ファイルフォーマットを変えたいんだ。こういう変更をお願いできるかな？

そう言って、手書きの修正案をガクさんに渡しました。今ちょうどファイル保存に関するテストコードを書き終えたばかりだったので、作り直しが必要になります。それでも、修正が必要なら仕方ありません。おそらくこれも生産部からの要望だろうと思い、ガクさんは言われるままに仕様書とテストコードを修正しました。さあこれで実装に入れると思ったところ、またまたハルさんがやってきました。

ハル：別件なのだけど、ガクさんに作業をお願いしたいんだ。この基準サンプルを測定して送ってくれるかな？　うん、今の作業は一旦止めて、これ最優先でお願い。この結果次第で、また校正アプリに修正が必要かもしれないんだ。

作り始めてからの修正が多いこと、またその修正がなぜ必要なのかわからないため、さすがにガクさんも気になってハルさんにお願いをしました。

ガク：作業は承りました。ですが、今度生産部から校正アプリの仕様変更要望があったときには、自分も呼んでいただけますか？　なんのためにその変更が必要なのか、何に困っておられるのかを知りたいのです。またそのために仕様をどう変更したらよいのかも、まず自分で検討してみたいのです。

ガクさんの言うことはもっともです。ハルさんはよかれと思い、面倒な会議や要望変更依頼にガクさんを巻き込まないようにしていました。しかし、その結果、ガクさんにとっては上から突然、目的不明の作業が降ってきて困惑しているようです。

ハル：しまったなあ。ガクさんをただの作業者にして、自立した技術者として扱っていなかった。自分の業務なのに自分で判断し実行する権限がないんじゃ、さすがに面白くないよね。

権限って委譲できるんですか？

リーダーになるとよく上司から「メンバーに権限委譲しなさい」と言われるようになります。この言葉、上司から言われ、リーダー研修でも指導されるうえに、時には部下からも「〇〇さんはもっと権限委譲したほうがいいですよ」と言われることさえあります。権限委譲はチームで動く世界の常識なのです。

権限委譲とはチームメンバーにそれぞれ意思決定の権限と、業務を遂行するために必要なリソースを自由に使えるよう割り当てることです。権限委譲によって起こる結果の最終的な責任は「権限の一部を委ねた上司」が負います。

権限委譲を通じて、メンバーはそれぞれが自律的に判断し行動できるようになります。いちいち上司に指示を仰がずとも、現場で課題を速やかに解決することができます。また自分で考え、自分の力で課題を解決したことで、技術者としての自信やモチベーションに繋がります。

……と、こうした概論的なことは理解しているのですが、筆者自身、恥ずかしながらこれまでにきちんと権限委譲を実践できたかどうか、自信がありません。

ハル：この作業は任せた！ と言えば権限委譲になるってもんでもないしなあ。作業と一緒に予算を付けたらいいのかなあ。

なんちゃって権限委譲

自ら判断し、裁量を持って人や物を動かす。そして、たとえ失敗しても、そのやり方を見直し、最終的に課題を解決に導ければ、それは本人にとって大きな達成感や実力の向上に繋がるはずです。自分の力で勝ち取った失敗からの成功体験は、その後も大きな支えとなり、さらなる困難や大きな課題に挑む力を育ててくれるでしょう。これこそが「成長」というものです。考えてみれば、RPGや冒険小説、特撮ヒーローものも同じです。主人公が試練を乗り越え、自らの力で勝利をつかむ胸熱な展開に共感するのは、こうした成長のプロセスに心を動かされるからでしょう。そう考えると、権限委譲には大きな価値があり、絶対に実施すべきだとわかります。しかし、現実にはなかなかうまく権限委譲できていない「なんちゃって権限委譲」の現場が多いようです。

・仕事だけが与えられて、裁量がない（やり方まで指示される）
・仕事だけが与えられて、責任を取らされる（失敗は許されない）
・仕事だけが与えられて、時間がない（自分で考えたことができない）
・仕事だけが与えられて、お金がない（上司の承認が必要）
・仕事だけが与えられて、人がいない（予算がない）

権限委譲といいながら、実際は作業だけが割り振られているケースがほとんどでしょう。委譲された側が自由に意思決定できる要素が欠けており、実質的には体よく仕事を丸投げしているだけだったりします。例えば、「ここは君に任せるよ」と言いつつ、納期が迫ると「このやり方で進めてくれ」と指示を出したり、そもそも解決が難しい課題を与えたうえで「今回できなかった理由を挙げて、対策案を作ってください」と求めたりするケースがあります。口では「任せた」と言いながらも、十分な時間や予算を割り当てず、細かくやり方を指示し、失敗した場合には責任を負わせる。こうした状況は、様々な職場で頻繁に見られるのではないでしょうか。

特に新人の場合には職場での仕事の仕方を学んでいる最中ですから、教育のために、上司からある程度細かくやり方を指示することは必要でしょう。しかしいつまでも業務を任せず、ただ指示に従うような指導を続けていると、自分で考えて行動する自立した技術者からは遠ざかってしまいます。

ここが失敗のポイントです。業務に対する権限を委譲せず、作業指示だけを与えて進捗管理することで、技術者の自立性を阻害してしまいます。自分でやり方を考えていないため、失敗から学ぶ経験も得られず、ユニークな課題に自力で対応できない技術者になってしまいます。また業務のやらされ感から、技術者としてのモチベーションも下がり、将来に不安を感じるようになります。

ガク：機能追加でも課題解決でも、自分で考えて実行できること。これ自分で考えて作った機能だぜ！ と言えるのが技術者としてはうれしいです。

自由にできるモノを渡す

権限委譲をする際は、その人の役割に応じて、やり方、部下、納期、予算など、自由に意思決定できる枠組みを提供することが必要です。「この課題はキミに任せる。この2名がキミのチームだ。予算もこれだけ好きに使っていい。どんなやり方をしてもいいからゴールを目指してくれ！ 責任は俺が取る」と言えるくらいでなければ、権限委譲としては中途半端になってしまいます。

とはいえ、現実には難しい場合も多いでしょう。できるだけ都合できるものは渡したいのですが、ヒト・モノ・カネを一部でも、自由にチームの裁量に任せるためには、権限移譲によって発生する失敗や遅延を組織が許容する必要があります。

［図］役割に応じて適切な範囲の権限を委譲する

これは、失敗を避けるため、単に「できる範囲の簡単な作業を指示する」ことではありません。成長途中の部下に仕事を任せ、失敗を許容し、その失敗を自ら立て直す経験を積ませるという、育成的な要素が重要です。その分の時間的・人的なゆとりを許容しなくてはなりませんが、これを怠ると、中堅の技術者が技術力を身に付けられず、自分で考え行動する力を持たない組織になります。技術者にとって、自分の成長が見込めず、モチベーションも持てない組織では、働く理由も見つけられません。

改めて組織的に権限委譲ができないか検討をしてみてください。新人だろうが中堅だろうが、それぞれの役割に応じて委譲する範囲を適切に設定し、必要なリソースを割り当ててみましょう。

リーダーとして、メンバーそれぞれが自分のタスクを自由に、裁量を持って取り組めるようにサポートすることが肝心です。チームメンバーそれぞれが自分の目標と役割を理解し、自分の考えたやり方で取り組める。メンバー各自がやりがいを持って成長できる、強い自律的なチームを作りましょう。

書籍情報

エンジニア育成現場の「失敗」集めてみた。 42の失敗事例で学ぶマネジメントのうまい進めかた（翔泳社）

「リアルすぎる！」と話題を読んだ失敗の教科書・第2弾！
残念なマネージャーにならないための「育成」アンチパターン集！

人材不足の開発現場において「エンジニアをいかに育成するか」は重大なテーマです。しかし、技術の指導や業務の割り振りだけでは、チームも個人も思うようには育ちません。エンジニア育成には、ソフトウェア開発と同じかそれ以上に繊細で複雑な「マネジメント」の力が求められます。

・優先度をつけずに業務を丸投げする「FIFO型業務依頼」で、キャパオーバーを招いてしまった
・「アレと同じに作って」と曖昧な指示を出した結果、意図と違う成果物があがってきた
・レガシーシステムの担当を任せたら、新しい技術を求めて転職されてしまった

などなど、意図せぬ失敗は数多く潜んでいます。最悪の場合、せっかく採用した人材が早期離職してしまうことも、現代のIT業界では珍しくありません。

本書は、そんなエンジニアの育成・マネジメントの現場で起こりがちな「落とし穴」を集めた失敗事例集です。架空の開発現場を舞台に「新人研修」「OJT」「チーム編成」「評価」などで起こりがちな失敗を42篇収録。著者の実体験をもとにした、フィクションとは思えない臨場感抜群のエピソードの数々を通して、失敗をどうすれば回避できるのかを解説します。

発売日：2025年06月11日

＞＞詳細はこちら

【著者】
出石聡史（@sdeishi）

2023 年3月まで、コニカミノルタ株式会社センシング事業本部LD&CA 事業部のソフトウェアリーダー（管理職）を担当。事業部すべてのソフトウェアにかかわり、開発の各ゲートにおける承認責任者として全プロジェクトの進捗をサポートした。各ゲートにおいては詳細設計や実装だけではなく、システム全体のアーキテクチャや、さらに上流の要求要件分析や企画内容にまで踏み込んだレビューを行い、顧客に刺さるソフトウェア開発を推進した。
また教育や育成にも力を注ぎ、販売や生産も含めたセンシング事業本部全体の新入社員教育や、大学生向けのインターンシップ、さらには基幹技術者向けのリーダー教育を企画・実施。技術者全体のスキルやモチベーションアップに貢献した。現在は会社を退職し、これまで培ってきた技術や経験を、若手技術者や新米マネージャー、ソフトウェアリーダーに伝える方法を模索中。著書に『ソフトウェア開発現場の「失敗」集めてみた。』（翔泳社）がある
■note

本記事は、『エンジニア育成現場の「失敗」集めてみた。 42の失敗事例で学ぶマネジメントのうまい進めかた』（翔泳社）より一部抜粋・転載しております。