俺の失敗を乗り越えろ！～やわらかマネジメント編～

Transcript

1. 俺の失敗を乗り越えろ！ メーカーの開発現場での失敗談と乗り越え方 ～やわらかマネジメント編～ 人にやさしい組織マネジメント勉強会(Management 3.0) 出石聡史（でいしさとし） © 2024 Satoshi Deishi 1
2. 自己紹介 • コニカミノルタ株式会社センシング事業 本部の開発部にて、ソフトウェアリー ダー（管理職）でした • ソフトウェア開発の各ゲートにおける承認責 任者 • 技術者やリーダーに向けた教育、育成 • 現在ぷー太郎 • これまでやらかした失敗をもとに『ソフト ウェア開発現場の「失敗」集めてみた。』 出版 色測定機器 開発 © 2024 Satoshi Deishi 2
3. 記憶喪失 オフィス事業 センシング事業 成功例もあるのです © 2024 Satoshi Deishi 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
4. 失敗か成功かではない © 2024 Satoshi Deishi 4 失敗の上に、成功がのっかってくる 成功か失敗かを選 ぶものではない
5. 「失敗本」に対する思い • 成功しないと儲からない • ソフトウェア開発に従事して約30年。ソフトウェアの管理職で18年。 これまでやらかした多種多様な失敗を、若手技術者の皆さんに生かし てもらいたい。失敗から立ち上がる力になりたい • あらかじめ失敗を知ることによって、「悪いにおい」をかぎ分ける力 を付けてほしい 悪いにおい © 2024 Satoshi Deishi 5
6. 収録エピソード（失敗）例 • 機能がてんこ盛りで実装が間に合わない「全部入りソフトウェア」 • お願いされた機能を断れない「八方美人仕様」 • ユーザーを迷わす自分ルールのUI「オレオレ表記」 • カタログだけで判断する「スペック厨導入」 • 行間を読ませる「文学的仕様書」 • リリース版が復元できない「不完全リポジトリ」 • つい自分でやってしまう「経験値泥棒」 • 修正が新たなバグを生む「バグ無間地獄」 • アクションしない「聞くだけ進捗会議」 • 施策を打ち続ける「カイゼンマニア」 • など全42篇 © 2024 Satoshi Deishi 6
7. 本日のターゲット • 主にリーダークラスの技術者や技術系管理職の方 （もしくは目指している方） • 体験談から管理職やリーダーがおかしがちな失敗を知り、 職場の「悪いにおい」をかぎ分ける力を付けたい • 職場でいいチームを作りたいと思っている方 • 楽しく元気な職場づくりのヒントが欲しい © 2024 Satoshi Deishi 7 いいチームって 何？ リーダー目線で 話をします
8. 俺の考える「いいソフト開発チーム」 © 2024 Satoshi Deishi 8 目標 役割 オープン 学び 安心 特別感 1. 意義のある高いミッションがあり、 目標が明確になっている 2. 各自の役割が明確で、 必要な権限が委譲されている 3. オープンでフラットな コミュニケーションができる 4. 新しい技術を学ぶ機会が与えられている 失敗から学びカイゼンできる 5. 目標を達成するまで チームが壊されない 6. 失敗を許容するゆとり、 あるいは仕組みがある 7. チームに属することの特別 感（ロイヤリティ）がある 生産性の高い ソフト開発チーム
9. 本日のお品書き（失敗事例） © 2024 Satoshi Deishi 9 目標 役割 オープン 学び 安心 特別感 • アクションしない「聞くだけ進捗会議」 • 業務の目的を伝えない「指示だけ上司」 • キャリアも希望も関係ない 「とりあえず配属」 • 職場が戦場になる「不機嫌なチーム」 • 新しい技術が得られない「伝統技術の継承者」 • また責められる「怖い会議」 • 犯人を追い込む 「お呼びでない名探偵」 • コロコロチームを変えら れる「社内フリーター」 生産性の高い ソフト開発チーム
10. 業務の目的を伝えない「指示だけ上司」 • ソフトウェア最大の課題は何をつくるか • 作るものを間違えることが最もまずい • なぜそのソフトが必要なのか理解していないと作るものを間違える • これ作って、あるいはこの作業お願い、という指示だけでは、 「なぜ」を理解できないし、やる気も出ない © 2024 Satoshi Deishi 10 目標 役割 オープン 学び 安心 特別感 目的を伝える（なぜその作業は必要なのか）
11. 指示だけして失敗 • データ測定用ソフトに散布図つけて（指示） • 測定データをグラフ化するだけでいいの？？？ © 2024 Satoshi Deishi 11 良品、不良品を振り 分けたい エビデンス 生産ラインの問題点 を探りたい 合格判定機能 合格範囲設 定機能 印刷機能 署名機能 ドリルダウン 他データとの 連携 「なぜ」によって必要な機能が異なる なぜ？ なぜ？ なぜ？
12. 目的が分かっていないと使えないソフトになる • 【失敗事例】顧客サービス用のソフトが使えない • 生産用ソフトと機能が同じなので横流し→使えない • 製品としてすべて同じものを作るケースと、個別の製品課題に対応するのでは使 い方が全く異なる • サービスから要望を聞いて作った→使えない • 開発側がサービスのフローを理解していない • サービス部門が、何をしたいのか伝えられない（機能を要望する） © 2024 Satoshi Deishi 12 機能だけあっても使えない
13. 顧客価値を書き出し「なぜ」に答える 項目 内容 顧客 顧客は誰か 課題 顧客の課題は何か 理由 なぜその課題は未解決なのか 解決手法 どうやって課題を解決するのか 価値 解決手法を導入することで顧客にどんなメリットがあるのか 優位性 その解決手法の優位性は何か 実現性 なぜ自社で取り組むのか。なぜ自社で出来るのか © 2024 Satoshi Deishi 13 なるほど！
14. アクションしない「聞くだけ進捗会議」 • ソフトウェア開発は必ず問題が起こる • ソフトウェア開発もしくはプロジェクトというのは、新しい機能の実 現や、未解決の課題解決を、有期限で実行するもの • リーダーがなにもしないと失敗する © 2024 Satoshi Deishi 14 進捗ではなく、課題を見つけることにフォーカス 課題に対しては必ずアクションを設定する 目標 役割 オープン 学び 安心 特別感
15. 報告を聞いているだけの会議 • 【失敗事例】進捗会議で遅れを見逃す • 実装完了しました（動いたとは言っていない） • 90%出来ました（解決しない問題が残っていますけど） • 今週中にできます（何もしていないけど） © 2024 Satoshi Deishi 15 今週も予定通りです
16. 進捗会議で課題に気が付かない • 課題が挙がってこない • 組織に漂う「言えない雰囲気」 • 課題が挙がっているけど見えていない • 課題の大きさを侮っている「2，3時間あれば動くよね」 • 課題を見つけようとしていない • リーダーが課題を聞いていない「今週は何しましたか？」 • 充分動作確認をせず、そっとタスクを閉じる © 2024 Satoshi Deishi 16
17. 課題を掘り起こし、アクションを起こす © 2024 Satoshi Deishi 17 進捗 順調です。 進捗 #0155 実装 完了です。 #0143 実装 完了です。 #0155 #0143 動いていない テストしていない 課題 技術的な課題 と工数不足が 課題です。 課題 #0155アルゴリ ズムがおかしい。 #0143テスト 未実施。 #0155 #0143 動いていない テストしていない アルゴリズム技術者に協 力を頼みます。コーハイ さんはシンジンさんのサ ポートをお願いします！ ※課題が見えない ※早期にアクションする
18. OODAループで変化に対応する • 進捗会議をやめました • OODAベースの変化を捉える会を実施 • 嫌なにおいをかぎ分け、メンバーが自分で最良の決断を下す © 2024 Satoshi Deishi 18 Observe 観察 Orient 状況判断 Decide 意思決定 Act 実行 CPUのピン設定が おかしい！ ピン設定が不明！ 全てのピン設定を 調べよう やっぱり他のピンも 設定できていない 協力してCPUの ピン設定を調査 自立的に判断 サポート ※メンバーの自立性に任せて リーダーはサポート 共有 課題の芽を捉える学び なるほど
19. キャリアも希望も関係ない「とりあえず配属」 • ソフトウェア開発で最も重要なのは人 • ソフトウェアは人が作る。人のスキルや、やる気次第でダメソフトが 爆誕する • 技術者が、成長しない、楽しくない、先がないとおもったら組織から 離れていく © 2024 Satoshi Deishi 19 目標 役割 オープン 学び 安心 特別感 技術者の希望やキャリアプランにそった組織配属
20. 組織のニーズを優先してしまう • 【失敗事例】組織都合で配属や転部を決める • 例）顧客サービス部門でソフトウェア技術者が必要なので製品開発希 望の技術者を転部させる → 本人のモチベーションダウン → 元居たプロジェクトの日程遅延、その他メンバーの負担増 © 2024 Satoshi Deishi 20 技術者がどんどん離れていく
21. Z世代の退職理由 © 2024 Satoshi Deishi 21 https://hatarakigai.openwork.jp/posts/53087776 1位 キャリア成長が望めない 3位 仕事内容とのミスマッチ
22. キャリア希望を理解して役割を設定する © 2024 Satoshi Deishi 22 現在 5年後 チーム チーム リーダー 設計者 実装者 新卒採用 管理職 管理職 新卒採用 リーダー 設計者 実装者 技術エキスパート 個々のなりたい姿をイメージして現在どうするか考える
23. キャリア希望を理解する、意識する • メンバーにキャッチフレーズを考えてもらう （中二病的に言うと、二つ名をもつ） • 例） • 「もう一度一緒に働きたい技術者」 • 「ヒットメーカー」 • 「いいかげんな技術者」 • 「おわりよければすべてよし」 © 2024 Satoshi Deishi 23 メンバーが自分の長所を伸ばし、自分だけの必殺技をもつ 上長がなりたい姿を理解し、チャンスを作る
24. 職場が戦場になる「不機嫌なチーム」 • ソフトウェア開発はコミュニケーションで決まる • 一人では作れない。仕様書や設計書もコミュニケーション • 人間関係の不機嫌さが離職や休職を生む • 隠ぺいしてもいいことはない • オープンでないとソフトウェアは作れない （俺の頭の中にある最強の設計の通りにつくって！） • 課題を隠蔽すると後で大変な問題に発展する （Ex. 自動車業界でごにょごにょ） © 2024 Satoshi Deishi 24 目標 役割 オープン 学び 安心 特別感 心理的安全性を確保する
25. 誰も助けてくれない • 【失敗事例】各自別プロジェクトに割り当て、他人の業務に関 心を持たせない • 1人1製品を担当。他の製品に口出しする知識もなく、自分も問題を抱 えていっぱいいっぱい © 2024 Satoshi Deishi 25 チームで解決する（1人1製品より3人3製品） 共通プラットフォーム、共有資産化の導入
26. また責められる「怖い会議」 • 【失敗事例】進捗会議で担当者を問い詰める • 犯人は誰だ • 「なんで遅れたんだ？それでどうするんだ？」 • 対策をとることでさらに遅れが拡大し、また怒られて、 また対策案を考えて……（無間地獄） • 四面楚歌 • 誰も助けてくれない • 味方だと思った上長からも撃たれる © 2024 Satoshi Deishi 26 目標 役割 オープン 学び 安心 特別感 報告せずに黙っていた方が面倒が少ない
27. 犯人を追い込む「お呼びでない名探偵」 • 【失敗事例】なぜなぜ分析（FIve Whys）の恐怖 • プロジェクトに遅れが出た原因を明確化し、対策案を出せ 1. 不具合が想定より多かった（なぜ？） 2. 設計が悪かった（なぜ？） 3. 他からコピペして作ったので、用途に合っていなかった（なぜ？） 4. 設計に関する知識がたりなかった（なぜ？） 5. 担当者の能力がたりなかった © 2024 Satoshi Deishi 27 対策は「〇〇さんは プロジェクトから外 れてもらう」……。 ミスの許さ れない空気 怖い。 目標 役割 オープン 学び 安心 特別感
28. 課題にフォーカスし、プロセスをカイゼンする • ホワイトボードに課題（敵）を書き、全員で敵と戦う • 悪いのは人ではなくプロセス © 2024 Satoshi Deishi 28 敵は課題！ 安心 バグ見積もりのや りかた見直そう 自動テスト導入 しましょう
29. ファシリテーターがプロセスにフォーカスさせる 「今回は見積もりの精度が悪くて、日程を伸ばさざるを得なかったっス。 これが一番の課題かな。」 「精度が悪かったのはどのプロセスに問題があったと思う？」 「最初の要求仕様書の段階で抜け漏れが多かった気がします」 「抜け漏れに気づくにはどうしたらいいんスかね？」 「例えばシステム仕様ができた段階、いやもっと早く利用シーンが出来 たとき、一度販売にレビューしてもらおうか。」 © 2024 Satoshi Deishi 29
30. 心理的安全性のある「ゆるい」チームを作る • リーダーが先にダメになる • 「ごめん、俺今週自分の作業進んでなくて……最近雑務多くない？」 • ダメな自分を見せてメンバーを参謀ポジにつけ、意見を募る • おやつを配る • 会議におやつを持ち込むだけで会話量2倍（当社比） • 食べることは生きること →生きるためのエネルギーをくれる場所 © 2024 Satoshi Deishi 30 このチームでリスクをとっても殺されない＝心理的安全性
31. 金曜日のお茶会 • 毎週金曜日の18:00から、おやつを食べる会を勝手に開催 • 実施要領 • 食堂でおやつを並べてもぐもぐしているだけ • 一応メールで案内をだす • おやつは自分の食べたいものを持ってくる（そのうち差し入れてもらえるよう に） • 通りがかった人を無理やり誘う • 効果 • 毎回「はじめまして」という出会いを演出できた • 業務の問題が解決することもあった • 知らないおやつと出会えた • 太った © 2024 Satoshi Deishi 31
32. 会議をゆるくする、5分前のエンターテイナー • 会議の5分前に入って雑談する • 転生ものアニメのお勧め • ネットゲームでアメリカ人とパーティー組む話 • コミケで「恐竜家族本」売っていたら、鉄郎のコスプレした人が、恐 竜家族のテーマを歌いながら買いにくる話 • なぜか会社に来たら唇が腫れる事件 © 2024 Satoshi Deishi 32 キビシイ会議でも発言しやすくなる 職場の雰囲気をコントロールできるのはリーダー
33. 新しい技術が得られない「伝統技術の継承者」 • 実績のある技術しかつかわない • 必要な時、新規技術に対応できない • 技術者のスキルが育たず、将来の不安につながる • 自分で手を動かさない • 業務委託依存 © 2024 Satoshi Deishi 33 目標 役割 オープン 学び 安心 特別感 新規技術探索を仕掛ける
34. 顧客ニーズは突然に • 【失敗事例】工場で使う測定器は、RS-232Cで十分だ！ © 2024 Satoshi Deishi 34 そろそろ無線もヨロシク CM-17d 2024年発売 Bluetooth 無線LAN USB-C(PD) CM-26dG 2016年発売 Bluetooth搭載 備えておかないとニーズの変化に対応できない MYIRO-1 2022年発売 無線LAN
35. ソフトウェア技術に置いて行かれる • 【失敗事例】業務委託のみで自分で開発させない • Gitが使えない • Jenkinsが使えない • オブジェクト指向設計ができない • もう自分でコード書けない（C++17とか20とか23ってなに？） © 2024 Satoshi Deishi 35 技術で遊ぶ機会を設ける
36. 新規技術で遊ぶ会をトップダウンで実施 • なんでもいいから作ってみる会 • カーテンを自動で開けるマシン → 新人が技術で遊ぶ。エレキメンバーのファーム理解 • 組織として取り入れるべき技術の検討会 • 最新USB技術の調査 → PDの採用 © 2024 Satoshi Deishi 36 チャレンジする時間は業務として作る 20%ルールは 使われない
37. コロコロチームを変えられる 「社内フリーター」 • 工数は交換可能ではない • 0.5工数貸してくれない？ • 結局2工数分働かされるか、共倒れ • 次はあっちのバグ直して • モチベーションダウン（バグを直したいわけではない） • 技術力ダウン（部分作業に特化すると一から設計できない） • 組織への帰属感が薄れる（考えない、助け合わない） © 2024 Satoshi Deishi 37 製品を企画から出荷、サポートまで担当する チームで働く特別感を持たせる 目標 役割 オープン 学び 安心 特別感
38. 工数割り当てゲーム • 【失敗事例】見積もり工数だけ満たしてプロジェクトスタート • 数字上必要な工数を割り当て • 細切れ（0.2と0.3と0.4と0.3工数（0.2多い））スイッチングコストを無視 • スキル無視（頭数があっていればいい） • ゆとりなし。ハッピーケースでつい出来ますと言ってしまう • 優先プロジェクトに短期間助っ人貸し出し • テスト工数かして • バグ修正できる人かして © 2024 Satoshi Deishi 38 各製品で課題が同時発生して、共倒れ 技術者のモチベーション低下（将棋の駒あつかい）
39. できるチームを壊す • 【失敗事例】プロジェクト途中で人を引き抜く • 他部署や海外赴任など、組織要望のためできるヤツを引き抜く • 本人のキャリアアップのチャンスを優先 • 代わりの人を入れても、すぐにはチームの生産性は戻らない （人数を補填すればいいわけではない） © 2024 Satoshi Deishi 39 納期や品質未達などの問題、モチベーションの低下 組織へのロイヤリティーの低下
40. 製品出荷までチームを壊さない • このチームで勝ち取った勝利（出荷）を味わう • 苦労したときに俺もそこにいたという「同じ飯を食った」感 © 2024 Satoshi Deishi 40 失敗や苦労を共にし、目的を達成する仲間 （チームの特別感）
41. 共犯者にする • イケナイことした仲間同士は結束が固い。特別なチーム • チーム全員で会社をさぼってBBQ • チーム全員で会社をさぼってボーリング • チーム全員で会社をさぼってカラオケ © 2024 Satoshi Deishi 41 【注意】チーム外との断絶が大きくなる
42. 非日常に巻き込む • 職場にいつもと違う刺激でワクワクを演出する • 会社に炊飯器をもちこんで、レトルトカレー大会 • 発想部屋 © 2024 Satoshi Deishi 42
43. 俺の考える最強のソフト開発チーム © 2024 Satoshi Deishi 43 目標 役割 オープン 学び 安心 特別感 1. 意義のある高いミッションがあり、 目標が明確になっている 2. 各自の役割が明確で、 必要な権限が委譲されている 3. オープンでフラットな コミュニケーションができる 4. 新しい技術を学ぶ機会が与えられている 失敗から学びカイゼンできる 5. 目標を達成するまで チームが壊されない 6. 失敗を許容するゆとり、 あるいは仕組みがある 7. チームに属することの特別 感（ロイヤリティ）がある 生産性の高い ソフト開発チーム 7つの仕掛け
44. いいチームのための、やわらかマネジメント技 © 2024 Satoshi Deishi 44 目標 役割 オープン 学び 安心 特別感 • 顧客価値を書き出し「なぜ」に答える • 課題を掘り起こし、アクションを起こす • OODAループで変化に対応する • キャリア希望を理解して役割を 設定する • キャッチフレーズをもたせる • 課題にフォーカスし、プロセス をカイゼンする • リーダーが先にダメになる • 新規技術で遊ぶ会をトップダウンで実施 • 製品出荷までチームを壊さない • 共犯者にする • 非日常に巻き込む 生産性の高い ソフト開発チーム • 金曜日のお茶会 • 会議5分前のエンターテイナー
45. リーダー（管理職）の資質 • 人を好きであること • チームメンバーが楽しく生きることで、結果的に良い製品ができる • チームメンバーが自分の生きがいを見つけられるように • チームメンバーが仕事に楽しさが見つけられるように • チームメンバーが成長できるように • チームメンバーが健康であるように © 2024 Satoshi Deishi 45 メンバー個々の人生より大事なものはない 志 技術力 人が好き 技術リーダーの資質
46. © 2024 Satoshi Deishi 46 ご清聴ありがとうございました 失敗は成功の教科書だ。