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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

収録エピソード（失敗）例 • 機能がてんこ盛りで実装が間に合わない「全部入りソフトウェア」 • お願いされた機能を断れない「八方美人仕様」 • ユーザーを迷わす自分ルールのUI「オレオレ表記」 • カタログだけで判断する「スペック厨導入」 • 行間を読ませる「文学的仕様書」 • リリース版が復元できない「不完全リポジトリ」 • つい自分でやってしまう「経験値泥棒」 • 修正が新たなバグを生む「バグ無間地獄」 • アクションしない「聞くだけ進捗会議」 • 施策を打ち続ける「カイゼンマニア」 • など全42篇 © 2024 Satoshi Deishi 6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

本日のお品書き（失敗事例） © 2024 Satoshi Deishi 9 目標役割オープン学び安心特別感 • アクションしない「聞くだけ進捗会議」 • 業務の目的を伝えない「指示だけ上司」 • キャリアも希望も関係ない「とりあえず配属」 • 職場が戦場になる「不機嫌なチーム」 • 新しい技術が得られない「伝統技術の継承者」 • また責められる「怖い会議」 • 犯人を追い込む「お呼びでない名探偵」 • コロコロチームを変えられる「社内フリーター」生産性の高いソフト開発チーム

Slide 10

Slide 10 text

業務の目的を伝えない「指示だけ上司」 • ソフトウェア最大の課題は何をつくるか • 作るものを間違えることが最もまずい • なぜそのソフトが必要なのか理解していないと作るものを間違える • これ作って、あるいはこの作業お願い、という指示だけでは、「なぜ」を理解できないし、やる気も出ない © 2024 Satoshi Deishi 10 目標役割オープン学び安心特別感目的を伝える（なぜその作業は必要なのか）

Slide 11

Slide 11 text

Slide 12

Slide 12 text

目的が分かっていないと使えないソフトになる • 【失敗事例】顧客サービス用のソフトが使えない • 生産用ソフトと機能が同じなので横流し→使えない • 製品としてすべて同じものを作るケースと、個別の製品課題に対応するのでは使い方が全く異なる • サービスから要望を聞いて作った→使えない • 開発側がサービスのフローを理解していない • サービス部門が、何をしたいのか伝えられない（機能を要望する） © 2024 Satoshi Deishi 12 機能だけあっても使えない

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

課題を掘り起こし、アクションを起こす © 2024 Satoshi Deishi 17 進捗順調です。進捗 #0155 実装完了です。 #0143 実装完了です。 #0155 #0143 動いていないテストしていない課題技術的な課題と工数不足が課題です。課題 #0155アルゴリズムがおかしい。 #0143テスト未実施。 #0155 #0143 動いていないテストしていないアルゴリズム技術者に協力を頼みます。コーハイさんはシンジンさんのサポートをお願いします！ ※課題が見えない ※早期にアクションする

Slide 18

Slide 18 text

OODAループで変化に対応する • 進捗会議をやめました • OODAベースの変化を捉える会を実施 • 嫌なにおいをかぎ分け、メンバーが自分で最良の決断を下す © 2024 Satoshi Deishi 18 Observe 観察 Orient 状況判断 Decide 意思決定 Act 実行 CPUのピン設定がおかしい！ピン設定が不明！全てのピン設定を調べようやっぱり他のピンも設定できていない協力してCPUのピン設定を調査自立的に判断サポート ※メンバーの自立性に任せてリーダーはサポート共有課題の芽を捉える学びなるほど

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

職場が戦場になる「不機嫌なチーム」 • ソフトウェア開発はコミュニケーションで決まる • 一人では作れない。仕様書や設計書もコミュニケーション • 人間関係の不機嫌さが離職や休職を生む • 隠ぺいしてもいいことはない • オープンでないとソフトウェアは作れない（俺の頭の中にある最強の設計の通りにつくって！） • 課題を隠蔽すると後で大変な問題に発展する（Ex. 自動車業界でごにょごにょ） © 2024 Satoshi Deishi 24 目標役割オープン学び安心特別感心理的安全性を確保する

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

犯人を追い込む「お呼びでない名探偵」 • 【失敗事例】なぜなぜ分析（FIve Whys）の恐怖 • プロジェクトに遅れが出た原因を明確化し、対策案を出せ 1. 不具合が想定より多かった（なぜ？） 2. 設計が悪かった（なぜ？） 3. 他からコピペして作ったので、用途に合っていなかった（なぜ？） 4. 設計に関する知識がたりなかった（なぜ？） 5. 担当者の能力がたりなかった © 2024 Satoshi Deishi 27 対策は「〇〇さんはプロジェクトから外れてもらう」……。ミスの許されない空気怖い。目標役割オープン学び安心特別感

Slide 28

Slide 28 text

Slide 29

Slide 29 text

ファシリテーターがプロセスにフォーカスさせる「今回は見積もりの精度が悪くて、日程を伸ばさざるを得なかったっス。これが一番の課題かな。」「精度が悪かったのはどのプロセスに問題があったと思う？」「最初の要求仕様書の段階で抜け漏れが多かった気がします」「抜け漏れに気づくにはどうしたらいいんスかね？」「例えばシステム仕様ができた段階、いやもっと早く利用シーンが出来たとき、一度販売にレビューしてもらおうか。」 © 2024 Satoshi Deishi 29

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

会議をゆるくする、5分前のエンターテイナー • 会議の5分前に入って雑談する • 転生ものアニメのお勧め • ネットゲームでアメリカ人とパーティー組む話 • コミケで「恐竜家族本」売っていたら、鉄郎のコスプレした人が、恐竜家族のテーマを歌いながら買いにくる話 • なぜか会社に来たら唇が腫れる事件 © 2024 Satoshi Deishi 32 キビシイ会議でも発言しやすくなる職場の雰囲気をコントロールできるのはリーダー

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

コロコロチームを変えられる「社内フリーター」 • 工数は交換可能ではない • 0.5工数貸してくれない？ • 結局2工数分働かされるか、共倒れ • 次はあっちのバグ直して • モチベーションダウン（バグを直したいわけではない） • 技術力ダウン（部分作業に特化すると一から設計できない） • 組織への帰属感が薄れる（考えない、助け合わない） © 2024 Satoshi Deishi 37 製品を企画から出荷、サポートまで担当するチームで働く特別感を持たせる目標役割オープン学び安心特別感

Slide 38

Slide 38 text

工数割り当てゲーム • 【失敗事例】見積もり工数だけ満たしてプロジェクトスタート • 数字上必要な工数を割り当て • 細切れ（0.2と0.3と0.4と0.3工数（0.2多い））スイッチングコストを無視 • スキル無視（頭数があっていればいい） • ゆとりなし。ハッピーケースでつい出来ますと言ってしまう • 優先プロジェクトに短期間助っ人貸し出し • テスト工数かして • バグ修正できる人かして © 2024 Satoshi Deishi 38 各製品で課題が同時発生して、共倒れ技術者のモチベーション低下（将棋の駒あつかい）

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

いいチームのための、やわらかマネジメント技 © 2024 Satoshi Deishi 44 目標役割オープン学び安心特別感 • 顧客価値を書き出し「なぜ」に答える • 課題を掘り起こし、アクションを起こす • OODAループで変化に対応する • キャリア希望を理解して役割を設定する • キャッチフレーズをもたせる • 課題にフォーカスし、プロセスをカイゼンする • リーダーが先にダメになる • 新規技術で遊ぶ会をトップダウンで実施 • 製品出荷までチームを壊さない • 共犯者にする • 非日常に巻き込む生産性の高いソフト開発チーム • 金曜日のお茶会 • 会議5分前のエンターテイナー

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text