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

by Satoshi Deishi

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

自己紹介 • コニカミノルタ株式会社センシング事業本部の開発部にて、ソフトウェアリーダー（管理職）でした → 現在ぷー太郎 • ソフトウェア開発の各ゲートにおける承認責任者 • 技術者やリーダーに向けた教育、育成 • これまでやらかした失敗をもとに出版 • 『ソフトウェア開発現場の「失敗」集めてみた。』（2024年6月出版） • 『エンジニア育成現場の「失敗」集めてみた。』（2025年6月出版） © 2026 Satoshi Deishi 3 色測定機器開発今日はこちら

Slide 4

Slide 4 text

記憶喪失オフィス事業センシング事業成功例もあるのです 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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

本日のターゲット • 主にリーダークラスの技術者や技術系管理職の方（もしくは目指している方） • 体験談から管理職やリーダーがおかしがちな失敗を知り、職場の「悪いにおい」をかぎ分ける力を付けたい • 職場でチームマネジメントや人材育成に悩んでいる方 • 楽しく元気な職場づくりのヒントが欲しい • 若手技術者にやりがいをもって働いてほしい © 2026 Satoshi Deishi 7 リーダー目線で話をします

Slide 8

Slide 8 text

Slide 9

Slide 9 text

良い職場、良いチームが技術人材を育てる • 良いチームは成果が出る • 実績が自信に繋がり、モチベーションややりがいを得られる • 良いチームは素早く失敗し、乗り越える • 失敗により学び、成長する • 様々なケースに対応できる応用力が付く • コミュニケーション力がつく • 自分の強み弱みを認識し、協力して問題を解決する力が付く • 自立行動できるようになる © 2026 Satoshi Deishi 9 乗り越えるべき課題があり、安心して自分の強みを発揮できる環境があることが技術人材を成長させる良いチームってなに？

Slide 10

Slide 10 text

「良いソフト開発チーム」の6要素 © 2026 Satoshi Deishi 10 目標役割オープン学び安心特別感 1. 意義のある高いミッションがあり、目標が明確になっている 2. 各自の役割が明確で、必要な権限が委譲されている 3. オープンでフラットなコミュニケーションができる 4. 新しい技術を学ぶ機会が与えられている失敗から学びカイゼンできる 5. 目標を達成するまでチームが壊されない 6. 失敗を許容するゆとり、あるいは仕組みがある 7. チームに属することの特別感（ロイヤリティ）がある生産性の高いソフト開発チーム

Slide 11

Slide 11 text

本日のお品書き（失敗事例） © 2026 Satoshi Deishi 11 目標役割オープン学び安心特別感 • 成果がはっきりしない「ほんわか目標設定」 • 権限を持たせない「人間将棋の駒」 • ダメになるまで報告しない「しなびたホウレンソウ」 • また責められる「怖い会議」 • 失敗の経験を与えない「一流技術者のメッキ」 • 悪いのは部下「つるし上げの連鎖」 • チームでひとりぼっち「疎結合配属」生産性の高いソフト開発チームおまけ謎なものを作ってくる「異世界仕様」

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

成果主義の悩ましさ • 評価基準が不明瞭（成果って何？何ができたら成果なの？） • 業務による差（プログラマーと庶務はどっちが高評価？） • タイミングの問題（まだ開発途中なので失敗しかない） • 個人主義（チーム全員で頑張ったのに、なぜリーダーだけ高評価？） • 評価対象以外の業務を軽視（やっても評価されないことはしない） • 結局相対評価（原資がかぎられているから全員高評価はムリ） • 働きすぎ（量で成果をアピール） • 元からできない目標（これぐらいできないとプラス評価はやれん！） • 評価者によるバイアス（あいつはダメなやつだ） • 被評価者と評価者のずれ（成果出したVSそんなの成果ではない） © 2026 Satoshi Deishi 14

Slide 15

Slide 15 text

期初から評価は始まっている • 成果物と完了の定義を行い、プラス評価の目安をすり合わせる • 測定可能な成果目標にする • 期待を伝える © 2026 Satoshi Deishi 15 評価に納得感と、チャレンジするモチベーションがUP 目標シート α版完了（重要機能動作確認） α版仕様書動作確認結果レポート（β版の日程見直しができればプラス評価） α版出来たけどまだ課題が残ってます重要機能が十分動作しているので目標達成！ β版の作成日程も作ってくれたのでプラス

Slide 16

Slide 16 text

権限を持たせない「人間将棋の駒」 • なんちゃって権限委譲 • 仕事だけが与えられて、裁量がない（やり方まで指示される） • 仕事だけが与えられて、責任をとらされる（失敗は許さない） • 仕事だけが与えられて、時間がない（自分で考えることができない） • 仕事だけが与えられて、お金がない（上司の承認が必要） • 仕事だけが与えられて、人がいない（予算も人事権もない） © 2026 Satoshi Deishi 16 目標役割オープン学び安心特別感自由にできるモノがないのに、仕事は降ってくる

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

また責められる「怖い会議」 • 【失敗事例】進捗会議で担当者を問い詰める • 犯人は誰だ • 「なんで遅れたんだ？それでどうするんだ？」 • 対策をとることでさらに遅れが拡大し、また怒られて、また対策案を考えて……（無間地獄） • 四面楚歌 • 誰も助けてくれない • 味方だと思った上長からも撃たれる © 2026 Satoshi Deishi 21 報告せずに黙っていた方が面倒が少ない目標役割オープン学び安心特別感

Slide 22

Slide 22 text

心理的安全性のある「ゆるい」チームを作る • リーダーが先にダメになる • 「ごめん、俺今週自分の作業進んでなくて……最近雑務多くない？」 • ダメな自分を見せてメンバーを参謀ポジにつけ、意見を募る • おやつを配る • 会議におやつを持ち込むだけで会話量2倍（当社比） • 食べることは生きること →生きるためのエネルギーをくれる場所 © 2026 Satoshi Deishi 22 このチームでリスクをとっても殺されない＝心理的安全性ゆるゆるチームリーダー

Slide 23

Slide 23 text

金曜日のお茶会 • 毎週金曜日の18:00から、おやつを食べる会を勝手に開催 • 実施要領 • 食堂でおやつを並べてもぐもぐしているだけ • 一応メールで案内をだす • おやつは自分の食べたいものを持ってくる（そのうち差し入れてもらえるように） • 通りがかった人を無理やり誘う • 効果 • 毎回「はじめまして」という出会いを演出できた • 業務の問題が解決することもあった • 知らないおやつと出会えた • 太った © 2026 Satoshi Deishi 23

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

失敗はリーダー同士協力して立ち向かう • 責任をとる＝失敗から立ちあがること • 始末書を書くことではない • 担当者より、リーダーの方が権限が広い • 解決に向けての選択肢が多い © 2026 Satoshi Deishi 29 責任協力予算確保します。コンポーネントのコード買おう。テスターさんも確保しよう。責任ガクさんの予定確保します。設計ミスによる大量バグガクさんと修正箇所特定します。問題リーダー同士互いに助け合う風土が、リーダーにとっても「チームの責任は自分が取る」と言える心理的安全性に繋がる

Slide 30

Slide 30 text

チームでひとりぼっち「疎結合配属」 • ソフト開発における問題の原因はほとんどがコミュニケーション • チームの人間関係が良くないと、ソフトの品質もよくない • 必要な情報が得られず、協力も得られない • 暗黙知やドメイン知識も共有されない • 各自バラバラの設計で、インテグレーションテストで地獄を見る • 問題を他人のせいにして、効果的な対応を行わない © 2026 Satoshi Deishi 30 モチベーションダウン、技術力ダウン組織に対する不信感や薄れる帰属感目標役割オープン学び安心特別感

Slide 31

Slide 31 text

形式知だけでは分からないことがある • 【失敗事例】チームに配属された新人に、業務だけ与えて放置 • 新人が1か月かけて考えた内容は、すでに検討済みだった • 必要な資料は共有されていたが、読み解けない • 聞けばすぐに分かることも、誰に聞けばいいのかわからない • リモートワークが続いて、ムダ話も出来ていない • ドメイン知識も得られず、問題の本質も見えてこない © 2026 Satoshi Deishi 31 無駄な作業による疲労感、役に立てない絶望感なのに誰も助けてくれない孤立感

Slide 32

Slide 32 text

なかよしチームでいいんじゃない？ © 2026 Satoshi Deishi 32 失敗や苦労を共にし、目的を達成する仲間を大事にする（チームに所属する特別感）お互い疎な関係のチームなんでできないの？業務がわからない。誰に聞けばいいのか不明。これしていいのかな？怒られる。特別感があり、結束力が高いチームこのチームで働きたい。なんでも聞ける。生産部のキーマンはね。面白い技術みつけたよ。その業務の目的はね。これやってみたい。楽しい。

Slide 33

Slide 33 text

Slide 34

Slide 34 text

「良いソフト開発チーム」の6要素 © 2026 Satoshi Deishi 34 目標役割オープン学び安心特別感 1. 意義のある高いミッションがあり、目標が明確になっている 2. 各自の役割が明確で、必要な権限が委譲されている 3. オープンでフラットなコミュニケーションができる 4. 新しい技術を学ぶ機会が与えられている失敗から学びカイゼンできる 5. 目標を達成するまでチームが壊されない 6. 失敗を許容するゆとり、あるいは仕組みがある 7. チームに属することの特別感（ロイヤリティ）がある生産性の高いソフト開発チーム

Slide 35

Slide 35 text

リーダー（管理職）の資質 • 人を好きであること • チームメンバーが楽しく生きることで、結果的に良い製品ができる • チームメンバーが自分の生きがいを見つけられるように • チームメンバーが仕事に楽しさが見つけられるように • チームメンバーが成長できるように • チームメンバーが健康であるように © 2026 Satoshi Deishi 35 メンバー個々の人生より大事なものはない志技術力人が好き技術リーダーの資質

Slide 36

Slide 36 text

『エンジニア育成現場の「失敗」集めてみた。』収録エピソード（失敗）例 • すべてが最優先「FIFO型業務依頼」 • 完璧な報告を強制する「賢者のレポート」 • 謎のコメントで迷宮入り「ダイイングメッセージ型コメント」 • アレと同じに作って「現物合わせ仕様」 • チームでひとりぼっち「疎結合配属」 • 俺は独りで学んできた「一匹狼エンジニア」 • キャッチアップできない「伝統技術の継承者」 • 過保護がやりがいを奪う「上っ面ホワイト育成」 • すべてを知りたがる「メトリクスコレクター」 • 採用応募者をやりこめる「技術学会面接」など全42篇 © 2026 Satoshi Deishi 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

謎なものを作ってくる「異世界仕様」 • 世界に当たり前なんてない © 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 だけなの？

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

『ソフトウェア受託現場の「失敗」集めてみた。』（仮） • 目次（仮） • 見積もりは予算に合わせる「できます症候群（進行中）」 • たとえ技術がなくても「できます症候群（重篤化）」 • あえて仕事は増やさない「戦略的未仕様」 • テストが通ればいいんでしょ「はりぼて構造設計」 • 淡雪のように溶けていく内部構造「デスファクタリング」 • 品質の考え方に違いがある「ベストエフォート品質」 • などなど42エピソード © 2025 Satoshi Deishi 42 ※上記の内容は予告なく変更になる場合があります。ご了承ください。