俺の失敗を乗り越えろ！～ほんわかチームマネジメント編 拡大版～

若手技術者の離職やモチベーションの低下は、リーダーにとって大きな悩みの種です。 そんな育成に悩むリーダーの皆様に、良いソフトウェアチームを支える6要素（目標、役割、オープン、学び、安心、特別感）を基にした、チームマネジメントや人材育成に必要なエッセンスを、筆者自身の失敗からご紹介します。

Transcript

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