俺の失敗を乗り越えろ！メーカーの開発現場での失敗談と乗り越え方 ～ゆるゆるチームリーダー編～

ソフトウェア開発はチームで取り組むものです。そしてチームは、リーダーの影響を大きく受けます。
リーダー次第で、メンバーの働きやすさも生産性も大きく変わってくるのです。
そこで、登壇者自身の失敗経験を踏まえながら、チームマネジメントや技術人材育成に必要なエッセンスをご紹介します。
あわせて、ソフトウェアチームを支える6つの要素、「目標」「役割」「オープン」「学び」「安心」「特別感」について解説していきます。

Transcript

1. 俺の失敗を乗り越えろ！ メーカーの開発現場での失敗談と乗り越え方 ～ゆるゆるチームリーダー編～ Developers Summit 2026 出石聡史（でいしさとし） © 2026 Satoshi Deishi 1
2. © 2026 Satoshi Deishi 2
3. 自己紹介 • コニカミノルタ株式会社センシング事業本部 の開発部にて、ソフトウェアリーダー（管理職） でした → 現在ぷー太郎 • ソフトウェア開発の各ゲートにおける承認責任者 • 技術者やリーダーに向けた教育、育成 • これまでやらかした失敗をもとに出版 • 『ソフトウェア開発現場の「失敗」集めてみた。』 （2024年6月出版） • 『エンジニア育成現場の「失敗」集めてみた。』 （2025年6月出版） © 2026 Satoshi Deishi 3 色測定機器 開発 今日はこちら
4. 記憶喪失 オフィス事業 センシング事業 成功例もあるのです 4 失敗した分、成功もするかもね 研究開発 1989入社 2008 2013 2023 P2Pネットワーク セキュアネットワーク クラウド対応 次世代複写機 インターフェース ハーフトーニング カラーマネジメント CA-410 CM-26dG CM-M6 1成分現像プロセス CM-36dG CM-17d MYIRO-1 Magicolor 2300 Magicolor 1600 DiMage Scan Dual Ⅱ CS Remote Care © 2026 Satoshi Deishi
5. 失敗か成功かではない © 2026 Satoshi Deishi 5 失敗の上に、成功がのっかってくる 成功か失敗かを選 ぶものではない
6. 「失敗本」に対する思い • 成功しないと儲からない • ソフトウェア開発に従事して約30年。ソフトウェアの管理職で18年。これ までやらかした多種多様な失敗を、若手技術者の皆さんに生かしてもら いたい。失敗から立ち上がる力になりたい • あらかじめ失敗を知ることによって、「悪いにおい」をかぎ分ける力を付 けてほしい 悪いにおい © 2026 Satoshi Deishi 6
7. 本日のターゲット • 主にリーダークラスの技術者や技術系管理職の方 （もしくは目指している方） • 体験談から管理職やリーダーがおかしがちな失敗を知り、 職場の「悪いにおい」をかぎ分ける力を付けたい • 職場でチームマネジメントや人材育成に悩んでいる方 • 楽しく元気な職場づくりのヒントが欲しい • 若手技術者にやりがいをもって働いてほしい © 2026 Satoshi Deishi 7 リーダー目線で 話をします
8. 本日持って帰っていただきたいこと • 失敗から学ぶ • ダメ技術者が失敗から、どういう学びを得たのか、得なかったのか • 失敗から立ち上がって欲しい • プロジェクトは絶対どこかで、なにか失敗する • 課題がなければプロジェクトにはならない • 倒れたままでは成功につながらない • なにかを変えて、もう一歩 • 何もしないのが失敗への近道 © 2026 Satoshi Deishi 8
9. 良い職場、良いチームが技術人材を育てる • 良いチームは成果が出る • 実績が自信に繋がり、モチベーションややりがいを得られる • 良いチームは素早く失敗し、乗り越える • 失敗により学び、成長する • 様々なケースに対応できる応用力が付く • コミュニケーション力がつく • 自分の強み弱みを認識し、協力して問題を解決する力が付く • 自立行動できるようになる © 2026 Satoshi Deishi 9 乗り越えるべき課題があり、 安心して自分の強みを発揮できる環境があることが技術人材を成長させる 良いチームって なに？
10. 「良いソフト開発チーム」の6要素 © 2026 Satoshi Deishi 10 目標 役割 オープン 学び 安心 特別感 1. 意義のある高いミッションがあり、 目標が明確になっている 2. 各自の役割が明確で、 必要な権限が委譲されている 3. オープンでフラットな コミュニケーションができる 4. 新しい技術を学ぶ機会が与えられている 失敗から学びカイゼンできる 5. 目標を達成するまで チームが壊されない 6. 失敗を許容するゆとり、 あるいは仕組みがある 7. チームに属することの特別 感（ロイヤリティ）がある 生産性の高い ソフト開発チーム
11. 本日のお品書き（失敗事例） © 2026 Satoshi Deishi 11 目標 役割 オープン 学び 安心 特別感 • 成果がはっきりしない 「ほんわか目標設定」 • 権限を持たせない 「人間将棋の駒」 • ダメになるまで報告しない 「しなびたホウレンソウ」 • また責められる 「怖い会議」 • 失敗の経験を与えない「一流技術者のメッキ」 • 悪いのは部下 「つるし上げの連鎖」 • チームでひとりぼっち 「疎結合配属」 生産性の高い ソフト開発チーム おまけ 謎なものを作ってくる 「異世界仕様」
12. 成果がはっきりしない「ほんわか目標設定」 • リーダーにとって評価は最も憂鬱なイベント • 高い評価を付ければ、上司から根拠を尋問され • 低い評価を付ければ、部下が納得するまで面談バトル © 2026 Satoshi Deishi 12 目標 役割 オープン 学び 安心 特別感 評価があいまいだと、部下のモチベーション低下を招く 面倒を避けるため、ほんわかした目標を設定し、ほどほどの評価をくだす。
13. 「動詞」の成果目標に要注意 • 【失敗事例】目標を明確にせず、期末の雰囲気で評価する © 2026 Satoshi Deishi 13 上司に成果のエビデンスを示せず、良い評価を出せない 目標シート ファームを 開発する あやふやな 目標 やりました。 どこまで やったの？ ？
14. 成果主義の悩ましさ • 評価基準が不明瞭（成果って何？ 何ができたら成果なの？） • 業務による差（プログラマーと庶務はどっちが高評価？） • タイミングの問題（まだ開発途中なので失敗しかない） • 個人主義（チーム全員で頑張ったのに、なぜリーダーだけ高評価？） • 評価対象以外の業務を軽視（やっても評価されないことはしない） • 結局相対評価（原資がかぎられているから全員高評価はムリ） • 働きすぎ（量で成果をアピール） • 元からできない目標（これぐらいできないとプラス評価はやれん！） • 評価者によるバイアス（あいつはダメなやつだ） • 被評価者と評価者のずれ（成果出したVSそんなの成果ではない） © 2026 Satoshi Deishi 14
15. 期初から評価は始まっている • 成果物と完了の定義を行い、プラス評価の目安をすり合わせる • 測定可能な成果目標にする • 期待を伝える © 2026 Satoshi Deishi 15 評価に納得感と、チャレンジするモチベーションがUP 目標シート α版完了 （重要機能動作確認） α版仕様書 動作確認結果レポート （β版の日程見直しができれ ばプラス評価） α版出来たけど まだ課題が残ってます 重要機能が十分動作して いるので目標達成！ β版の作成日程も作って くれたのでプラス
16. 権限を持たせない「人間将棋の駒」 • なんちゃって権限委譲 • 仕事だけが与えられて、裁量がない（やり方まで指示される） • 仕事だけが与えられて、責任をとらされる（失敗は許さない） • 仕事だけが与えられて、時間がない（自分で考えることができない） • 仕事だけが与えられて、お金がない（上司の承認が必要） • 仕事だけが与えられて、人がいない（予算も人事権もない） © 2026 Satoshi Deishi 16 目標 役割 オープン 学び 安心 特別感 自由にできるモノがないのに、仕事は降ってくる
17. つい作業指示をしてしまう • 【失敗事例】開発用ツールの機能作成を指示する • 目的と達成目標をつたえ、課題を解決する方法を考えてもらうべき • ツール作成は目的を達成するための一手段 © 2026 Satoshi Deishi 17 自分で考える機会もなく、失敗から学ぶこともできず、 やりがいも持てない 結局なんども作り直しが発生。 役に立たないとか、使えないとか 悪い評価が立ってしまった。
18. Z世代の退職理由 © 2024 Satoshi Deishi 18 https://hatarakigai.openwork.jp/posts/53087776 1位 キャリア成長が望めない 3位 仕事内容とのミスマッチ
19. 自由にできるモノを渡す © 2026 Satoshi Deishi 19 メンバーそれぞれの役割に応じた権限委譲 作業 作業 作業 資源 目標 資源 目標 資源 目標 目的 やり方は 任せて！ この作業 お願い ちょっと時間 ください 計画 ※役割に応じた目標と自由になる資源を提供する 失敗を想定した計画化と、サポートを行う 失敗した！ 次こうします 目的 計画 作業していれ ばいいか ※作業だけ割り振っていると、自分で考えなくなる
20. ダメになるまで報告しない 「しなびたホウレンソウ」 • 職場が怖い • 失敗を報告すると叱責される。連絡したら面倒が増える。相談しても取り 合ってくれない • ダメなやつだと烙印を押される © 2026 Satoshi Deishi 20 目標 役割 オープン 学び 安心 特別感 報告も連絡も相談もせず、悪い情報を隠蔽し リスクを放置してしまう
21. また責められる「怖い会議」 • 【失敗事例】進捗会議で担当者を問い詰める • 犯人は誰だ • 「なんで遅れたんだ？ それでどうするんだ？」 • 対策をとることでさらに遅れが拡大し、また怒られて、 また対策案を考えて……（無間地獄） • 四面楚歌 • 誰も助けてくれない • 味方だと思った上長からも撃たれる © 2026 Satoshi Deishi 21 報告せずに黙っていた方が面倒が少ない 目標 役割 オープン 学び 安心 特別感
22. 心理的安全性のある「ゆるい」チームを作る • リーダーが先にダメになる • 「ごめん、俺今週自分の作業進んでなくて……最近雑務多くない？」 • ダメな自分を見せてメンバーを参謀ポジにつけ、意見を募る • おやつを配る • 会議におやつを持ち込むだけで会話量2倍（当社比） • 食べることは生きること →生きるためのエネルギーをくれる場所 © 2026 Satoshi Deishi 22 このチームでリスクをとっても殺されない＝心理的安全性 ゆるゆるチーム リーダー
23. 金曜日のお茶会 • 毎週金曜日の18:00から、おやつを食べる会を勝手に開催 • 実施要領 • 食堂でおやつを並べてもぐもぐしているだけ • 一応メールで案内をだす • おやつは自分の食べたいものを持ってくる（そのうち差し入れてもらえるように） • 通りがかった人を無理やり誘う • 効果 • 毎回「はじめまして」という出会いを演出できた • 業務の問題が解決することもあった • 知らないおやつと出会えた • 太った © 2026 Satoshi Deishi 23
24. 失敗の経験を与えない「一流技術者のメッキ」 • 技術力を持たない技術者を育ててしまう • 自分の手を汚させない • 若いうちから派遣技術者や外注のコントロール業務のみ • 作業指示だけ与えて、自分で考えさせない © 2026 Satoshi Deishi 24 目標 役割 オープン 学び 安心 特別感 作られた成功体験が戦力外人材を育てる コスト 成功重視 納期 若手への 配慮
25. 少し難しい技術課題を任せる • 失敗して学ぶゆとりをプロジェクト計画に盛り込む • 育成のコストを組み込む © 2026 Satoshi Deishi 25 自分で考えたやり方を試す時間と権限を与える 業務1 業務2 教育 ゆとり ゆとり わからないこ とが…… ベテラン技術者の若手教育のための時間 若手が失敗し学んで解決するためのゆとり時間 どれどれ
26. 人類に必要なムダ 1. 思考する時間 2. 休憩する時間 3. 知識をインプットする時間 4. 知識を共有する時間 5. 失敗する時間 © 2026 Satoshi Deishi 26 仕様作成 設計 実装 ムダ 仕様不足 × × × 仕様作成 設計 〇 理解不足 理解不足 仕様不足 理解不足 設計不足 ムダ 〇 ムダなし ムダあり 全部中途半端 設計まで出来た 「必要なムダ」を意識する
27. 悪いのは部下「つるし上げの連鎖」 • 権限はないが責任は取らされる • 「で、どうするの？ これ？」と上司から詰め寄られる • 「で、どうするの？ これ？」と部下を問い詰める © 2026 Satoshi Deishi 27 目標 役割 オープン 学び 安心 特別感 問題の原因を部下に求め、対処も部下に丸投げ 遅れ どうする？ 自分のせいっス。 解決案：休日出勤 遅れ どうする？
28. リーダーが自分の問題と捉える • チームの問題はリーダー自身の問題として扱い、自らアクションす ることで、「つるし上げの連鎖」を断ち切る © 2026 Satoshi Deishi 28 権限をメンバーに与え、責任をリーダーがとる 俺が窓口を しよう 私が部門間で 調整します 他部署から予定外 の依頼が多くて 解決案：依頼窓口一本化
29. 失敗はリーダー同士協力して立ち向かう • 責任をとる＝失敗から立ちあがること • 始末書を書くことではない • 担当者より、リーダーの方が権限が広い • 解決に向けての選択肢が多い © 2026 Satoshi Deishi 29 責任 協力 予算確保します。 コンポーネントの コード買おう。 テスターさん も確保しよう。 責任 ガクさんの予 定確保します。 設計ミスによる 大量バグ ガクさんと修正 箇所特定します。 問題 リーダー同士互いに助け合う風土が、リーダーにとっても 「チームの責任は自分が取る」と言える心理的安全性に繋がる
30. チームでひとりぼっち「疎結合配属」 • ソフト開発における問題の原因はほとんどがコミュニケーション • チームの人間関係が良くないと、ソフトの品質もよくない • 必要な情報が得られず、協力も得られない • 暗黙知やドメイン知識も共有されない • 各自バラバラの設計で、インテグレーションテストで地獄を見る • 問題を他人のせいにして、効果的な対応を行わない © 2026 Satoshi Deishi 30 モチベーションダウン、技術力ダウン 組織に対する不信感や薄れる帰属感 目標 役割 オープン 学び 安心 特別感
31. 形式知だけでは分からないことがある • 【失敗事例】チームに配属された新人に、業務だけ与えて放置 • 新人が1か月かけて考えた内容は、すでに検討済みだった • 必要な資料は共有されていたが、読み解けない • 聞けばすぐに分かることも、誰に聞けばいいのかわからない • リモートワークが続いて、ムダ話も出来ていない • ドメイン知識も得られず、問題の本質も見えてこない © 2026 Satoshi Deishi 31 無駄な作業による疲労感、役に立てない絶望感 なのに誰も助けてくれない孤立感
32. なかよしチームでいいんじゃない？ © 2026 Satoshi Deishi 32 失敗や苦労を共にし、目的を達成する仲間を大事にする （チームに所属する特別感） お互い疎な関係のチーム なんででき ないの？ 業務がわからない。 誰に聞けばい いのか不明。 これしていい のかな？ 怒られる。 特別感があり、結束力が高いチーム このチームで 働きたい。 なんでも 聞ける。 生産部のキー マンはね。 面白い技術み つけたよ。 その業務の 目的はね。 これやって みたい。 楽しい。
33. チームに所属する「特別感」をもたらす裏ワザ • チームメンバーを「共犯者」にする • イケナイことした仲間同士は、結束が固い特別なチームになる • チーム全員で会社をさぼってBBQ • チーム全員で会社をさぼってボーリング • チーム全員で会社をさぼってカラオケ © 2026 Satoshi Deishi 33 【注意】チーム外との断絶が大きくなる
34. 「良いソフト開発チーム」の6要素 © 2026 Satoshi Deishi 34 目標 役割 オープン 学び 安心 特別感 1. 意義のある高いミッションがあり、 目標が明確になっている 2. 各自の役割が明確で、 必要な権限が委譲されている 3. オープンでフラットな コミュニケーションができる 4. 新しい技術を学ぶ機会が与えられている 失敗から学びカイゼンできる 5. 目標を達成するまで チームが壊されない 6. 失敗を許容するゆとり、 あるいは仕組みがある 7. チームに属することの特別 感（ロイヤリティ）がある 生産性の高い ソフト開発チーム
35. リーダー（管理職）の資質 • 人を好きであること • チームメンバーが楽しく生きることで、結果的に良い製品ができる • チームメンバーが自分の生きがいを見つけられるように • チームメンバーが仕事に楽しさが見つけられるように • チームメンバーが成長できるように • チームメンバーが健康であるように © 2026 Satoshi Deishi 35 メンバー個々の人生より大事なものはない 志 技術力 人が好き 技術リーダーの資質
36. 『エンジニア育成現場の「失敗」集めてみた。』 収録エピソード（失敗）例 • すべてが最優先「FIFO型業務依頼」 • 完璧な報告を強制する「賢者のレポート」 • 謎のコメントで迷宮入り 「ダイイングメッセージ型コメント」 • アレと同じに作って「現物合わせ仕様」 • チームでひとりぼっち「疎結合配属」 • 俺は独りで学んできた「一匹狼エンジニア」 • キャッチアップできない「伝統技術の継承者」 • 過保護がやりがいを奪う「上っ面ホワイト育成」 • すべてを知りたがる「メトリクスコレクター」 • 採用応募者をやりこめる「技術学会面接」 など全42篇 © 2026 Satoshi Deishi 36
37. 「委託・受託開発」の失敗 • 自分史上最大の失敗が「委託開発」 • 年単位での遅延、億単位での予算超過、足りない機能、 崩れたアーキテクチャー、大量の残バグ、非機能要件未達 © 2026 Satoshi Deishi 37 「売れない」 「売らない」商品 委託・受託企業間 の関係悪化 足りないコミュニケーションが招く悲劇
38. ソフトウェア開発における問題の原因は ほぼ「コミュニケーション」に起因する © 2025 Satoshi Deishi 38 自分との「距離」が遠いほど失敗しやすい チーム 他部署 他社 地球外 コミュニケーションコスト 大 小 自分との近さ 遠 近
39. 謎なものを作ってくる「異世界仕様」 • 世界に当たり前なんてない © 2025 Satoshi Deishi 39 仕様書に書いていないこと、あいまいなことは自由に解釈 委託 受託 ファイル ホーム 共有 表示 ★クイック PC file1.dat file2.dat file3.dat file4.dat file5.dat file6.dat file7.dat file8.dat file9.dat file10.dat file11.dat file12.dat - □ × - □ × ファイル アプリケーション file1.dat エクスプローラーで 複数ファイルを選択して 作ったアプリにドラッグアンドドロップ なんで、file1.dat だけなの？
40. 委託側と受託側で見かけ上ミッションが異なる • 委託側ミッション • 顧客の課題を解決する • 受託側ミッション • 契約書の通りに成果物を納品する © 2026 Satoshi Deishi 40 ソフトウェアを「なぜ」作るのかを共有する 顧客の課題を 解決できない と意味がない
41. 早めに軌道修正する • 成果物をイテレーティブ（反復的）にリリース、確認の機会を設ける © 2026 Satoshi Deishi 41 リリース キックオフ ゴール ギャップ 全然出来て いない！ 最終リリース リリース1 ギャップ ちょっとずつ フィードバックを 受けて直そう。 リリース2 リリース3 リリース4 キックオフ 仕様は必ず間違って伝わっている。と思っておく
42. 『ソフトウェア受託現場の「失敗」集めてみた。』（仮） • 目次（仮） • 見積もりは予算に合わせる「できます症候群（進行中）」 • たとえ技術がなくても「できます症候群（重篤化）」 • あえて仕事は増やさない「戦略的未仕様」 • テストが通ればいいんでしょ「はりぼて構造設計」 • 淡雪のように溶けていく内部構造「デスファクタリング」 • 品質の考え方に違いがある「ベストエフォート品質」 • などなど42エピソード © 2025 Satoshi Deishi 42 ※上記の内容は予告なく変更になる場合があります。ご了承ください。
43. おしらせ © 2026 Satoshi Deishi 43 • 20-B-4 • 同じお題をどう描く？ IT漫画家3人に学ぶ “技術を伝える”技術 • サイン会 • 3F 書籍販売コーナー
44. © 2025 Satoshi Deishi 44 ご清聴ありがとうございました 開発組織の原動力は人。