現場から組織を動かす方法
•Transferir como PPTX, PDF•
0 gostou•581 visualizações
2021年6月15日に開催されたAgile Studio Webinarの講演資料。 現場から組織を動かす方法 大企業と中小企業、それぞれのアジャイル導入から学んだこと
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 現場から組織を動かす方法
Mais de Takuya Okamoto
Mais de Takuya Okamoto (6)
現場から組織を動かす方法
- 1. © 2021 ESM, Inc. Agile Studioウェビナー 現場から組織を動かす方法 ~ 大企業と中小企業、それぞれのアジャイル導入から学んだこと 1 2021年6月17日 株式会社永和システムマネジメント Agile Studio 岡本 卓也
- 2. © 2021 ESM, Inc. アイスブレーク 2
- 3. © 2021 ESM, Inc. アンケートその１ 3 マネージャ ● 経営層 ● 管理職 ● 決定する人 エンジニア ● 開発で実際に手を動かす どちらですか？
- 4. © 2021 ESM, Inc. よわよわエンジニアというパワーワード 4 社長がこれ言うのすごくないですか？
- 5. © 2021 ESM, Inc. アンケートその２ 5 つよつよの人 ● イケてるチーム ● イケてる開発 よわよわの人 ● 普通のチーム ● 普通の開発 ● キラキラした アジャイルに疲れた で、どちらですか？
- 6. © 2021 ESM, Inc. 分類 6 マネージャ エンジニア つよつよ よわよわ つよつよ エンジニア よわよわ エンジニア つよつよ マネージャ よわよわ マネージャ 今日の対象 よわよわな人達の 気持ちを知って欲しい
- 7. © 2021 ESM, Inc. よわよわの人だって話したい 7 つよつよ エンジニア よわよわ エンジニア つよつよ マネージャ よわよわ マネージャ アジャイルとビジネス 自己組織化してxxx クラウドがxxx プラクティスがxxx 自動化でxxx 代表取締役 CTO つよつよエンジニア それ以外の話があってもいい
- 8. © 2021 ESM, Inc. アンケートその３ 8 大企業 ● ジャパニーズ トラディショナル カンパニー 中小企業 ● テック企業 ● ベンチャー ● 自営 ● Not 大企業 どちらですか？
- 9. © 2021 ESM, Inc. 本編 9
- 10. © 2021 ESM, Inc. 期待値調整 ● 技術の話はありません ● Agile Studioの事例はありません ● アジャイルの話も（あまり）ありません ● 大企業ディスもありません 10
- 11. © 2021 ESM, Inc. 今日お話しすること 権限を持っていなくても 組織を動かす方法がある （かもしれない） 11
- 12. © 2021 ESM, Inc. この話をしようと思ったきっかけ 12 アジャイル開発をやりたいのですが 会社が認めてくれません じゃ、独立して あなたが社長になれば良いですよ あははははは あははははは 参加者 講演者 イベントのQAあるある
- 13. © 2021 ESM, Inc. 想定している対象 現場のエンジニア ● アジャイル開発を導入したい ● でも上司を説得できずに苦労している 13
- 14. © 2021 ESM, Inc. 本当の本編 14
- 15. © 2021 ESM, Inc. 今日お持ち帰りいただくこと ヒント 1. 組織の構造 2. ゲームのルール 3. 人を動かす アンチパターン 1. 二重帳簿方式 2. 安全地帯 15 レッツトライ 1. 提案書
- 16. © 2021 ESM, Inc. 目次 ヒント 1. 組織の構造 2. ゲームのルール 3. 人を動かす アンチパターン 1. 二重帳簿方式 2. 安全地帯 16 レッツトライ 1. 提案書
- 17. © 2021 ESM, Inc. 組織の構造を知る 17 我々は誰と戦っているのか？
- 18. © 2021 ESM, Inc. 構造の捉え方を知る ● 組織の構造はそれぞれのケースで異なる ● ここでは典型的なケースを、更に単純化して説明 ● 自分の組織に置き換えたらどうなるか？ 想像してみて下さい 18
- 19. © 2021 ESM, Inc. アジャイル開発がやりやすい組織 テック企業 自社ビジネス 19 経営 現場 エンドユーザ プロダクト サービス 収益 報酬 社内 アジャイル開発による 圧倒的/革新的な 凄いサービス
- 20. © 2021 ESM, Inc. 階層 ミッション アジャイルへの期待 決定権 経営 (ビジネスオーナー) プロダクトを使って 収益を得る ● ビジネスのスピード ● 変化に対応 ● 要求を探索 〇 現場 良いプロダクトを作る ● 正しいものを作る ● 良いものを作る ● 素早く作る ● 成長 ● やりがい ステークホルダの例 20 現場から経営まで、ミッションとアジャイルへの期待がリンクしてお り 説明しやすい＆理解されやすい やりたい OK!
- 21. © 2021 ESM, Inc. プロダクトビジネス （受託ビジネス） アジャイル開発が難しい組織 21 経営 現場 エンドユーザ プロダクト サービス 収益 報酬 開発企業 ユーザ企業 納品 売上 圧倒的/革新的なサービスを 提供したいのだが・・
- 22. © 2021 ESM, Inc. 階層 ミッション アジャイルへの期待 決定権 ユーザ企業 (ビジネスオーナー) プロダクトを使って 収益を得る ● ビジネスのスピード ● 変化に対応 ● 要求を探索 開発企業 経営 会社の利益を拡大する ● 儲かる 〇 現場 良いプロダクトを作る ● 正しいものを作る ● 良いものを作る ● 素早く作る ● 成長 ● やりがい ステークホルダの例 22 経営は別のミッションとアジャイルへの期待を持っている やりたい は？
- 23. © 2021 ESM, Inc. 関心事の不一致 ● 立場が変わるとミッションが変わる ● ミッションが変わると関心事も変わる ● 関心事が合っていないと会話できない 23
- 24. © 2021 ESM, Inc. 構造のバリエーション 24 階層 ミッション アジャイルへの期待 決定権 (ビジネスオーナー) プロダクトを使って 収益を得る ● ビジネスのスピード ● 変化に対応 ● 要求を探索 品質保証 品質厳守 ● 品質プロセス不在 〇 現場 良いプロダクトを作る ● 正しいものを作る ● 良いものを作る ● 素早く作る ● 成長 ● やりがい 品質が決定権を持っている やりたい は？
- 25. © 2021 ESM, Inc. 構造のバリエーション 25 階層 ミッション アジャイルへの期待 決定権 (ビジネスオーナー) プロダクトを使って 収益を得る ● ビジネスのスピード ● 変化に対応 ● 要求を探索 財務 収益改善 ● 開発コストダウン 〇 現場 良いプロダクトを作る ● 正しいものを作る ● 良いものを作る ● 素早く作る ● 成長 ● やりがい 収益が決定権を持っている やりたい は？
- 26. © 2021 ESM, Inc. 階層 ミッション アジャイルへの期待 決定権 (ビジネスオーナー) プロダクトを使って 収益を得る ● ビジネスのスピード ● 変化に対応 ● 要求を探索 経営 会社の利益を拡大する ● 儲かる 現場 マネージャ 上手くプロダクトを作る ● レガシーと同等 〇 エンジニア 良いプロダクトを作る ● 正しいものを作る ● 良いものを作る ● 素早く作る ● 成長 ● やりがい 構造のバリエーション 26 開発部門の中で階層がある やりたい は？
- 27. © 2021 ESM, Inc. 我々は誰と戦うべきか？ 27 構造を知れば戦う話をする相手と関心事がわかる
- 28. © 2021 ESM, Inc. 目次 ヒント 1. 組織の構造 2. ゲームのルール 3. 人を動かす アンチパターン 1. 二重帳簿方式 2. 安全地帯 28 レッツトライ 1. 提案書
- 29. © 2021 ESM, Inc. ゲームのルールを理解する 29 勝利条件は何か？
- 30. © 2021 ESM, Inc. 『野球』というゲーム ルール ● ヒットを打つと出塁する ● ホームまで生還すると得点する ● 3アウトで攻守交替する ● これを9回繰り返す 勝利条件 ● 9回終了時点で得点の多い方が勝ち 30 直接は関係ない事 ● ピッチャーの球速 ● ホームランの飛距離 ● ランナーの走る速さ
- 31. © 2021 ESM, Inc. 『アジャイル開発導入』というゲーム ルール ● 社内のルールには従う ● 社内で与えられた権限の中で戦う 勝利条件 ● 組織がアジャイル開発の導入を決断する 敗北条件 ● 会社をクビになる ● 取返しが付かないくらい信用を失う 31 直接は関係ない事 ● XXXXXXXX
- 32. © 2021 ESM, Inc. 勝利条件 ● 勝利条件と自分の欲求を区別する 32 勝利条件 自分の欲求 ● 組織がアジャイル開発の導入を決断する ● 自分でアジャイルを勉強する ● 自分でアジャイルを実践する ● 社外で実績をアピールする ● レガシーを論破する その行動は勝利条件に繋がっている？
- 33. © 2021 ESM, Inc. 敗北条件 ● 普通はなりません ● 会社には意外に自由がある ○ 『どんな失敗しても命は取られないし、クビにもならない』 33
- 34. © 2021 ESM, Inc. 大企業のゲーム 34 観点 大企業 中小企業 技術力 低い 高い 俊敏性 低い 高い 柔軟性 低い 高い リソース規模 高い 低い 体力 高い 低い 資金力 高い 低い 戦略：凡人が束になって規模で殴る 大企業はここで勝てる ゲームを戦っている
- 35. © 2021 ESM, Inc. 戦い方を選ぶ（混ぜない） 1. 大企業のルールで戦う ○ いまの強みを理解し、それを活かせる土俵で戦う ○ ここではアジャイルがどんな武器になるのか？ 2. 中小企業のルールで戦う ○ いまの強みを捨て、中小企業と同じ土俵で戦う ○ 世の中のアジャイル肯定論はこの文脈が多い 『俊敏』『柔軟』『楽しい』 35
- 36. © 2021 ESM, Inc. ここまで 1. 組織と課題の構造を理解した 2. ゲームのルールを整理した 次は 3. 具体的なやり方を考える 36 構造を捉えて前提条件を整理したら あとはコントロールできるはず ここはエンジニアの得意領域でしょ
- 37. © 2021 ESM, Inc. 目次 ヒント 1. 組織の構造 2. ゲームのルール 3. 人を動かす アンチパターン 1. 二重帳簿方式 2. 安全地帯 37 レッツトライ 1. 提案書
- 38. © 2021 ESM, Inc. 人を動かす 38 社内政治？
- 39. © 2021 ESM, Inc. 人を動かす 39 これは良い本です
- 40. © 2021 ESM, Inc. 良い本過ぎて全部書いてあった 40 人を動かす3原則 ● 批判しない、苦情を言わない ● 誠実な評価を与える ● 人の立場に身を置く 人に好かれる6原則 ● 相手に関心を寄せる ● 笑顔を忘れない ● 名前を覚える ● 聞き手に回る ● 関心のありかを見抜く ● 心から褒める 人を説得する12原則 ● 議論を避ける ● 相手の誤りを指摘しない ● 自分の誤りを認める ● 穏やかに話す ● イエスと答えられる問題から始める ● しゃべらせる ● 思いつかせる ● 人の身になる ● 同情を寄せる ● 美しい心情に呼びかける ● 演出を考える ● 対抗意識を刺激する 人を変える9原則 ● まず褒める ● 遠回しに注意を与える ● 自分の過ちを話す ● 命令をしない ● 顔をつぶさない ● わずかなことでも褒める ● 期待をかける ● 激励する ● 喜んで協力させる
- 41. © 2021 ESM, Inc. エンジニアの勘違い ● 技術的に正しいことだけ言う ○ 『これが正しい』 ● 黙っていても動く ○ 『人を動かすための努力なんて不要』 ● それはマネジメントの仕事 ○ エンジニアが政治に手を出すべきではない 41
- 42. © 2021 ESM, Inc. チョットダケ偉くなる ● 発言権を持てるまで出世する ○ その過程で得られる知見と信用は大事 ○ 異なるポジションを経験してみる ● ポジションと能力は比例する ○ （あるレベルまでは） 42
- 43. © 2021 ESM, Inc. 焦らない ● 組織には慣性モーメントが働く ○ 組織のサイズが大きく、レガシーの期間が長いほど 慣性モーメントは大きくなる ● 正論を語っても急には変わらない ○ すぐに変わらないからと言って焦らない ○ 年単位で取り組む覚悟が必要 43 レガシーは急には曲がれない
- 44. © 2021 ESM, Inc. レガシーに敬意を払う ● ケンカはダメ ● 今の会社を支えているのはレガシー ○ 成功している部分もある ○ 通用する武器もある ● 全否定も全肯定もダメ ○ 極論を言うのは簡単 ○ 中庸の難しさと凄さ 44
- 45. © 2021 ESM, Inc. 目次 ヒント 1. 組織の構造 2. ゲームのルール 3. 人を動かす アンチパターン 1. 二重帳簿方式 2. 安全地帯 45 レッツトライ 1. 提案書
- 46. © 2021 ESM, Inc. アンチパターン 46
- 47. © 2021 ESM, Inc. 二重帳簿方式 47 こっそり アジャイルでやろうぜ きっちりと レガシーでやってます 自分のチーム 社内報告
- 48. © 2021 ESM, Inc. 二重帳簿方式 ● 成功しても怒られる ○ 割と信用を失う ● 持続しない ○ 単発ならやれるかもしれない ● めちゃくちゃ辛い ○ 本人が潰れかねない 48 行くかもしれない
- 49. © 2021 ESM, Inc. 安全地帯から文句を言う 49 レガシーないわー アジャイルやれよー なんでもないでーす ウラ オモテ
- 50. © 2021 ESM, Inc. 安全地帯から文句を言う 50 ● 不満を言う状態が気持ち良くなる ○ 『コンフォートゾーン』 ○ 独立/転職する覚悟はある？
- 51. © 2021 ESM, Inc. 目次 ヒント 1. 組織の構造 2. ゲームのルール 3. 人を動かす アンチパターン 1. 二重帳簿方式 2. 安全地帯 51 レッツトライ 1. 提案書
- 52. © 2021 ESM, Inc. レッツトライ 52 帰ったらやってみて欲しいこと
- 53. © 2021 ESM, Inc. 提案書を書いてみる ポイント ● 言われてないけど作る ● 提案先を想定する ● 相手の関心事で語る ● パワポでOK ● （1回作っておくと永く使える武器になる） 53
- 54. © 2021 ESM, Inc. 【参考】IPA提言 54 共感は発信から 企業や組織そのものに興味や関心をもって もらうために、自分たちの考え方や取り組 みなどを多様な魅力ある表現で伝え続ける。 IPA（情報処理推進機構） トランスフォーメーションに対応するためのパターン・ランゲージ より
- 55. © 2021 ESM, Inc. まとめ 55
- 56. © 2021 ESM, Inc. まとめ ● 解きたい課題の構造を知る ● ゲームのルールを理解する ● 人を動かすことを忘れない ● 二重帳簿でこっそりはダメ ● 安全地帯から文句言わない ● 自分の思いを発信し続ける 56
- 57. © 2021 ESM, Inc. ありがとうございました 57
Notas do Editor
- こんにちは。 それでは、現場から組織を動かす方法というタイトルでお話しをさせて頂きます。 私は、永和システムAgile Studioの岡本と言います。 ちょっと仰々しいタイトルがついている気がしますが、硬い話はありませんので 緩い感じでお聞き頂ければ、と思います。 それではよろしくお願いします。
- まず最初にですね、私が緊張していますので 少しアイスブレークをさせて下さい。 ウェビナーの投票機能というのを使って、皆さんにちょっとしたアンケートを やってもらいたいと思います。 2択の質問が全部で3問あります。あまり深く考えずに直感で答えてください。 解答見て後から指名したりそういう事はありませんので 本当に軽い気持ちでお願いします。
- 第1問です。 どっちですか？ 経営とか管理職とか呼ばれる、いわゆるマネージャなのか 実際に開発しているエンジニアなのか？ プレイイングマネージャみたいなのはどっちだ？とかあるかも知れませんが そういう人はどっち成分が強そう位の間隔で決めちゃってください。
- 次、第2問なんですけど、その前にちょっとこれを見てください。 弊社の社長、平鍋のツイートです。 社長の真意とか内容についてはここでは置いておきますけど、 「よわよわエンジニア募集」って社長が言うの結構すごくないですか？ 自分はこれを見てすごく、へーーーって思った記憶があって すごく印象に残っています。
- で、第2問です。 ご自分はどっちだと思いますか？ 日本人的には、なかなか自分で「つよつよです！」というのは なかなか言わない気もしますけど これ匿名の投票なので、まあ正直に選んでみてください。 だから何だ、っていうのは無いのでそこは安心してください。
- なんでこの質問をしたかって言うと、今回は「現場から組織を変える」 っていう話なので、基本的にエンジニア目線なんですけど その前に、つよつよ or よわよわで分けた場合に こっちのよわよわからの話になるかなと思っています。
- 世の中というか、カンファレンスなんかで発表されるお話って 基本的に、このつよつよの目線が多いのかなって思います。 社長とかCTOみたいな肩書の偉い人が「組織とは」みたいな話をしたり エンジニアだったら、なんか凄い人が出てきてカッコいい話をしたり 凄いなーって思うんですけど、ちょっと疲れちゃったというか それ以外の話をしたり聞いたりする機会があまりないなーと思ってます。 なので、今日は敢えてというか、こっちのよわよわの人の意見として 見たいな話しをしてみたいな、と思いました
- 第3問です。 タイトルに「大企業と中小企業、うんたらかんたら」みたいなのが ありましたけど、あんまり深い意味はないです。 これは会社の規模というよりは、 「ジャパニーズトラディショナルカンパニーかどうか？」 「アジャイル導入に苦労してるかどうか？」 みたいな観点でもいいと思います。
- ありがとうございます。 アイスブレークおしまいです。 今の結果を見て話の内容を変えるとか、そういう器用なことは出来ないので 予定通り喋ります。 ここまででXX分位ですね。 では本編始めます。
- と言いながら、まだです。 最初に期待値調整というか、言い訳というか、予防線というか そういう物を言っておきます。 まず技術の話はありません。 事例もありません。 これは、このウェビナーが終わった後に続いてリモート見学会とか その後に座談会みたいな会話できる時間があるので、興味ある方は そちらに参加して頂ければ、と思います。 あと、アジャイルの話も基本的にないです。 題材として出てますけど、アジャイルとは？みたいな話は出てこないです。 あと、タイトルで若干煽り気味ですが 大企業ディスリというか、だから大企業はダメなんだ！みたいな話もないです。
- 今日お話しすることを最初に一言で要約してみると こんな感じになります。 タイトルが「現場から組織を動かす」ですけど ここでの現場って「決定権を持っていない」という意味があって そういう所からでも、組織とか周りとか動かす方法があるかもよ？ というのを、岡本の考えと若干の経験をもとに お話しさせてもらおうかと思っています。
- すみません、なかなか始まらないですね。 今日の話をしようかなと思った切っ掛けなんですけど 最近参加したオフラインのカンファレンスで、アジャイル導入について みたいなこんな話がありました。 最後のQAの所で、参加者の人からこんな質問が出てたんですね。 実は私も、アジャイルを知ったというか好きになったのって結構前で もう10年以上になるんですけど、その間ずーーと同じことを考えていたというか 同じ悩みを抱えていたんですね。 でこれを聞いて「あー、今でも同じ悩みを持ってるんだなー」と思ったり 「自分の考えてきたことを一度整理して、誰かに話してみたいなー」って 思ったのがきっかけになっています。
- なので、想定している対象は 主にこちらの現場のエンジニアの人達というのを考えています。 それと一方で、そういうエンジニアに向き合っているマネージャの人がいたら エンジニアはこんな気持ちで言ってるんですよ、というのも 何か伝えられたら、と思っています。
- 本当に始めます。
- 今日お話しすることをこんな感じでまとめてみました。 大きく3つに分かれてまして 組織を動かすためのヒントが3つ その時にやらない方が良いアンチパターンを2つ ここまでで、全体的にかなりフワッとした話になっていると思うので 最後に具体的な方法というかご提案みたいなものを1つ あげさせてもらいます。 では行きます。
- まずヒントの1番目。 組織を動かすには、その組織の構造を知ることが大事だよね というお話しです。
- はい。 キャッチコピーがありますけど 我々は誰と戦っているんでしょうか？ アジャイルを導入したいけど、会社が認めてくれないーって言う人 誰と戦うのでしょうか？ というお話しです。
- 組織の構造のお話しになるんですけど、組織って当然ですけど その会社毎にいろいろな形があるので、一概にこの構造だから こうしましょう、という話にはならないと思っています。 なので、ここでは典型的というかかなり単純化した話になりますので 皆さんは「自分の会社だったらどうかな？」と思って ちょっと想像しながら聞いてもらたら、現実味がでるかなと思います。
- まず最初の例として、うまくアジャイル開発ができそうな組織を考えてみます。 いわゆるテック企業とかGAFAとか呼ばれていたり、あとは自社で 直接ビジネスをしている、内製で開発をしている会社、みたいなのを想定しています。 この通り、開発をしている現場と、会社を経営している所と 2つのステークホルダがあると想定してみました。 あくまで例なので、ものすごく単純化して書いていますし そもそも私はGAFAの中の構造を知らないので、モデルとして見てください。
- じゃ、この組織のステークホルダと、 それぞれのミッションやアジャイルへの期待がどうなっているか？ を書いてみました。 この経営のところ、ビジネスオーナの階層ですが、 ここはミッションとしては、良いプロダクトを使って大きな収益を得る アジャイルへの期待は、良く言われている通り ビジネスのスピードとか、変化への対応とか、こういう感じです。 この横の所で、ちゃんとリンクしています。 こっちの現場の階層も、 ミッションは、例えば良いプロダクトを作る、開発ではありますね そしてアジャイルへの期待は、正しく、良いものを、早く作る、 その他に成長できるとか、やりがいがあるとか こっちも良く聞く話です。 ここも横でリンクしています。 更に全体で見た時も、このように繋がりが良くて 組織全体でリンクしているというか、同じ価値観を共有しやすいので 例えば、ここで現場が「アジャイルやりたいです」と言えば 経営もすぐに「OK」となりやすいのだと思います。
- じゃあ次に、アジャイル開発がやりにくい組織の例を考えてみます。 今度はプロダクトビジネスというか、受託ビジネスなのかもしれないですが こんな感じでユーザ企業と、プロダクトを開発する企業が分かれている場合です。 こちらでもこの開発の組織の中に、さっきと同じように 現場と経営というステークホルダがあるとします。
- こっちの場合はどうなっているか、を見てみます。 上のビジネスオーナーの階層はさっきと同じですね。 開発企業の中で、経営と現場という2階層に分かれていて 現場もさっきと同じです。 ただこの真ん中の経営という層が、さっきとは違っていて 例えばここのミッションは、開発企業の利益を最大化するだった場合は アジャイルへの期待って、当然ですけど儲かるかどうか？の視点になります。 こういう構造だった場合に、現場から「アジャイルやりたいです」とか 現場目線のアジャイルの価値を語っても、経営からすると「はあ？」になりますよね。
- まとめるとこういう事です。 更に言うと、決定権が相手にある場合って、つまり相手の方が上位なので こちらが関心事を合わせに行く必要があると思います。 つまり、現場がやりたいのは分かりますが、現場の関心事をいくら言っても 相手には伝わらないですよ、ってことです。
- 繰り返しになりますが、構造とかステークホルダの中身はあくまで例なので 実際にはいろんなパターンがあると思います。 どれが正解とかではなくて、いろんなパターンがありますよ、の例を いくつか考えてみます。 これは、もしかしたら良くある形かも知れないですが、品質部門が アジャイルの導入に反対している例です。 ここでも、この品質保証部門のミッションを考えると、当たり前ですけど品質で アジャイルへの期待というか、この場合不信感かもしれないですが 「アジャイルだと品質が心配」だったりします。 こんな構図になっている所に、現場から現場の価値観で 「アジャイルやりたいです」って言っても、やっぱり「はあ？」ですよね。
- しつこいですけど、別の例です。 せっかくスライド書いたからサラッと行きます。 品質が財務というか収益になった場合。 これも同じですよね。
- これ最後です。 開発の現場で、その中でマネージャとエンジニア階層に分かれる場合もあります。 ちょっと大きめの組織だとありがちかもしれません。 この場合も、マネージャのミッションはエンジニアとは別になっているかも知れません。 エンジニアからすると「マネージャはアジャイルのこと、全然分かってないわ」 みたいな話って、なんか良く聞く話じゃないですか。 そうすると、この階層の間でやっぱり関心事の不一致が起きるので やっぱりマネージャに「はあ？」って言われてしまいます。
- 最後にまとめますけど こに「誰と戦っているのか？」という問いかけは 構造を知って、相手の関心事を知ることが大事じゃないですか という話でした。
- 次行きます。 ゲームのルールというお話しです。
- ゲームのルールっていう言葉を使っていますが そのゲームの勝利条件を考えよう、という話です。
- いきなりたとえ話から始めてしまいますけど。 例えば野球というゲームを考えてみます。 ルールは皆さんご存じの通りこんな感じです。 細かいのはいろいろありますけど、まあこんな感じです。 で、勝利条件は、例えばこの「9回終わって得点の多い方が勝ち」です。 ここが実は大事で、野球には色んな要素がありますけど 例えばここにある とかは、選手の能力としては大事な事かもしれませんが 勝利条件とは直接関係ないです。 ここをごっちゃにしないのがとても大事じゃないかなと思います。
- 『アジャイル開発を導入する』というゲームだと考えてみます。 ルールは、まあ特にないというか、会社の中の活動なので 社内のルールには従いましょう、というのと もう一つは、さっきの組織の話とも関連しますけど 与えられた権限の中でやりましょう、位かなと思います。 で、大事なのはこの勝利条件の方ですが、ゴールというか目的は ここでは『アジャイル開発の導入を決断する』と定義します。 そうすると、さっきと同じようにこの勝利条件には直接関係ない事が 実は割とあったりするので、そこをごっちゃにしていませんか？ というお話しです。 あとさっきは無かったんですけど、ここに敗北条件というのも付けてみて まあこうなるとゲームオーバーかなというのを挙げてみました。 当たり前ですけど、会社をクビになったら終了っていうのと クビまでは行かなくても、社内で取り返しがつかない位に 信用を失うまで行ったらダメかなあ、と思っています。 この話もあとでチョット出てきます。
- まず勝利条件から行きます。 さっきの『直接は関係ない事』の話なんですけど ゴールが「組織がアジャイル開発の導入を決断する」とある場合に そこへ向かって進んでいきたい皆さんの行動というか、欲求というか 普段の活動かもしれないんですけど、区別していますか？ という話です。 この自分の欲求の方に書いているみたいに、アジャイルをやりたいので 勉強する、実践する、実績をアピールする、まあたまにはレガシーの人を 論破するとかあるかも知れません。 これ自体はまあ自然だったり、それぞれに意味があったりするので ダメという訳ではないんですけど、この欲求というか活動それ自体は 勝利条件というゴールに向かって繋がっていますか？ 繋がっていないなら、ゴールに向かうためにはこれ以外に何かやらないと ダメなのかな、と思います。
- 次は敗北条件です。 こっちは簡単です。 冗談っぽく「クビにならないこと」とか言いましたけど 日本の会社に居たら普通はクビになりません。 何が言いたいかというと、会社って多分皆さんが考えているよりも かなり自由があると思っていて、でも普段はそのことに気付いていない場合が 多いと思います。 自分で勝手に枠を作ってしまって、「うちの会社だからこれしかできない」って もっといろいろ出来るのにやらない、ということが多いんじゃないでしょうか。 もう少し言うと、例えば上司に怒られるとかちょっと変な目で見られるとか そういうのはもしかしたらあるかも知れないですけど、それはこのゲームの 敗北条件じゃないので、そうなっても良いか、位に考えると良いんじゃないかと思います。
- あとはゲームつながりでちょっと別の話をしてみます。 例の大企業とか中小企業とかありましたけど、大企業の話です。 なんか物議をかもしそうな表がありますけど、相対的にというか 敢えて高い低いを付けたらこうなるかな？って考えた対比です。 でここで何が言いたいかというと、大企業はここがイケてないから ダメだよねという話じゃなくて、大企業にはこっちの勝てる部分もあって 実はそれを知っているから、ここで勝てるゲームをしているという事です。 超乱暴に言っちゃうと、大企業は「凡人が束になって規模の暴力で殴り合う」 ゲームをやっています。 そういう領域では、絶対中小企業は勝てないと思います。
- じゃあ、今大企業にいてアジャイルをやりたい人はどうすれば良いか？ 選択は2つあると思っていて、 1つ目は、今のルールで戦うです。 今の強みを理解して、それが活かせる土俵で戦う。 アジャイルをやるなら、この土俵でどんな武器になるか？を考えます。 もう一つは、この強みを捨てて中小企業と同じルールに入って戦う。 世の中のアジャイルってここの文脈がほとんどだと思うんですけど ここで戦うなら、今の大企業の武器は捨てることになりますよ、という話です。 まあ普通に考えたら上じゃないかなと思いますが、これを意識することが 大切だと思います。
- ここまでで、組織とか課題の構造を理解して ゲームのルールを整理してみました。 整理というか、整理ポイントを挙げてみたって感じですが。 じゃ、その次は具体的なやり方を考えてみます。 これも最近のカンファレンスで聞いたやり取りなんですけど 構造をとらえて前提条件を整理したら、あとはコントロールできる。 これってエンジニアの得意分野だよね、って誰かが言ってました。
- 出は次の人を動かすに行ってみます。
- はい、人を動かすです。 なんか悪そうな写真が貼ってあります。 実はこの章のタイトルは最初は「社内政治をやる」だったんです。 インパクトがあるかな？って思いまして。 でも思い直して人を動かす、に直しました。
- 人を動かすという言葉は、知っている人もいるかもしれませんが この本からパクっています。 とっても良い本です。 今回資料を作るときに参考にしようかなと思って、パラパラっと 読み直したんですが、読んでビックリでした。
- 何が起きたかというと、良い本過ぎてですね、自分が話そうかなと 思っていたネタがだいたい全部書いてあったんですね。 細かくは読まないですけど 人を動かす方法 人を説得する方法 人を変える方法 人に好かれる方法 って、全部今回の「組織にアジャイル導入を決断してもらう」に 使えそうじゃないですか？ なので、機会があったら是非読んでみてください。 というのと、最初に書いたネタでダブったのは、もう全部捨てました。 で残ったやつの話をします。
- 残り物なので、ちょっとまとまりがないというか、粒度とかバラバラなんですけど。 まず最初は、エンジニアが勘違いしがちな点です。 端的に「正しいこと言ってれば正義」みたいな感覚あるんじゃないでしょうか。 これは正直、自分もそうでした。 これも自分の好きな本というかトムデマルコという人の言葉なんですけど 「ソフト開発の問題はほとんど技術じゃなくて社会学的なものである」 と、技術じゃなくて人間関係なんですね。 これは本当にその通りだと思います。 これの派生として、言わなくてもそう動くべきでしょ、っていうのもあります。 別の言い方をすると、「人を動かすための努力なんて必要ないでしょう」なんですけど そんなことはないです。 あと最後に、これもありがちなんですけど「それはマネージャの仕事」。 なんかエンジニアは政治に手を出したら負けというかダークサイドに落ちたみたいな 謎の価値観があるような気がします。 でも組織を動かすんだったら、エンジニアもこれが必要だと思います。
- 身も蓋もない感じがしますが、組織を動かそうと思ったら やっぱり会社の中でちょっとは偉くなるというか権限が必要です。 なので、言いたい事を言えるだけの発言権が持てるくらいには出世しましょう。 ここで二つポイントがあって、出世する過程で得られる経験って大きいです。 これは絶対に無駄にならないです。 あと、出世してポジションが変わると、劇的に視野が広がります。 あとですね、ポジションの能力はある程度比例します。 年功序列とかいろいろ言われてたり、そういう面もあるとは思いますが 無関係かというとそうでもなくて、少なくともあるレベルまでは比例すると思います。 なので、自分の能力の目安として、ある程度のポジションを目指して頑張るのも ある意味必要かなと思います。
- 次は焦らないです。 見たままですが、組織には慣性モーメントがあります。 大きくて歴史が長いほど慣性モーメントは大きいです。 タンカーの写真がありますけど、タンカーって舵を切ってから 向きが変わるまで１５分くらい掛かるそうです。 これと一緒で、特に大企業だと「アジャイルやるぞー」って言っても 絶対に急には変わりません。 ここで大事なのは、言っても変わらないからといって焦ったり 諦めちゃったりしないということだと思います。 じゃどの位我慢すれば良いかというと、色々だと思いますが 長いと3年とか5年とか、少なくとも年単位で取り組む覚悟が必要です。
- 次、最後です。 レガシーに敬意を払いましょう。 相手を動かすのにケンカ腰はダメです。 「今の会社がレガシーでイケてない」とか思っていたら じゃあ、今の会社を支えているのはレガシーな仕事と それをやっている人です。 その人が皆さんのお給料を稼いでいます。 あと、レガシーでも成功している部分とか、通用する武器もあるはずです。 大事なのは、全否定も全肯定もダメ、ということです。 極論に走るのはスゴイ簡単なんですが、それではダメで 中庸というか、バランス感覚を持つのがとても大事だと思います。
- 次、アンチパターンに行きます。 これは短いので、まとめて行きますね。
- これはやらない方が良いかな、って思う事です。 私自身の失敗も少し入っている、、、かもしれません。 ここはそんなこともあるかも、くらいの軽い気持ちで聞いてください。
- まずは二重帳簿方式です。 ここからスライド手抜きが酷くなるんですが、まあ見たままです。 組織がOKしてくれないけど、どうしてもアジャイルやりたい！って時の 手段の一つなんですけど、組織というか上司というかとにかく外に対しては 決められたとおりのレガシーなプロセスでカッチリやっていますと言いつつ 自分のチームとか内部でコッソリとアジャイル開発をやってしまう方法です。 実はこれ程度問題もあって、例えば朝会やるなんていうのはやってしまっても 全然問題ないし、そこに文句を言う人もあまりいないと思います。 ちょっとマズいのが、例えば決められたプロセスというか手順を守らない ドキュメントやエビデンスを作らない。 作らないと外向けにうその報告が出来ないので、報告用に偽物のエビデンスを 捏造したりし始めます。
- 何でかと言うと。 まず、成功しても怒られます。 これで成功して上司が改心するとか、それはドラマとかそういう世界の話で 現実には100%怒られます。 そして割と信用も失いますね。 これ、前に出てきた敗北条件がヤバくなるのでおススメしません。 あと持続もしません。 単発なら成功というかやり切れるかもしれませんが、だから次からは アジャイルで行きましょう、にはなりませんので、自己満足で終わります。 そして、めちゃくちゃ辛いです。 初めてのチームでアジャイルを回すだけでもものすごいエネルギーを使うのに それに加えてウソの報告を続けるのは、めちゃくちゃ疲れます。 心が折れると思うので、これもおススメしません。
- もう一つは、凄く観念的な話なんですけど。 まあ愚痴を言う、という事です。 表立って意見を言うんじゃなくて、ウラというかある意味無責任な場所で レガシーの悪口を言ってしまうと。 ちょっと言葉がきついカモですが、これは安全地帯から文句だけ言う状態で あまりよろしくない状態だと思います。
- これもダメな理由ですけど。 多分心理学の言葉だと思うんですけど「コンフォートゾーン」っていうのがあります。 これは、ちょっと絵が小さくて見えないですけど真ん中のこの部分で いわゆる安全地帯、自分にとって居心地が良い場所の事です。 居心地が良いと言っても満足しているのとはちょっと違って 現状に不満があって文句を言ってても、その文句を言う状態とか自分が 気持ちよくなってしまうような状態になります。 こうなると、、口では「変えるべき」と言いつつ、じつは変わりたくないというか 現状維持で良いわ、になってしまって、組織を動かすには繋がらないです。 冒頭の会話で、笑い話っぽく話しましたけど、これ講師の人は実際には 「コンフォートゾーンに隠れてない？」っていう皮肉じゃないかな？って 個人的には思いました。
- はい、以上がアンチパターンでした。 最後にレッツトライです。 レッツトライって何やねん？って思うかもしれません。 ここまで、割とフワッとした話ばっかりしてきたので、最後にちょっと 具体的というか、実際に皆さんが手を動かしてやってみたらどうでしょう？ という提案を紹介します。
- なので、もし皆さんが組織を変えてみたいなと思っていたら 会社に帰ってこんなことをやってみたらどうでしょうか。
- 中身は単純です。 提案書を書いてみる、です。 どんな提案でも良いんですが、今回のテーマで行くなら 「アジャイルを導入しましょう」というので提案書を実施に作ってみてください。 ポイントがいくつかあります。 普通会社で提案書を書くっていうと、上司から書いてって言われて作るのが ほとんどだと思います。 言われてないのに提案書作るってなかなかないと思うのですが、ここは勝手に 作ってみてください。 ある意味、自主的に動く練習にもなります。 その時に、ちゃんと提案先、この提案書を読む人が誰か？というのを 想定してみてください。 これは「組織の構造を知る」という話に対応しています。 同時に、自分の意見を整理して、それを相手の関心毎に沿って説明することも 意識してみてください。 形は何でも良いですが、パワポのスライドとかが良いんじゃないかと思います。 エンジニアは「パワポ職人」とか言ってパワポ作る仕事をバカにしますけど 人を動かしたいときにプレゼン能力って絶対に必要です。 あと、何でも良いので発表資料を一回作っておくと、長く使えるというか ぶっちゃけそれだけで1年位ゴハンが食べられるようになることもあります。 これはちょっと別の話になるので、ここでは深く触れません。
- これはIPAというところが出している トランスフォーメーションに対応するためのパターンランゲージ という提言の一部です。 トランスフォーメーションって最近流行りのDXですけど ものごとを変革するためには、こんな方法が良いですよというプラクティス集です。 その中の一つで、「共感は発信から」というのを見つけました。 関心を持ってもらうためには、自分から発信し続けるのが大事ですよ、という話で 今の提案書を書いてみるというのも、まさにこのパターンじゃないかなと思います。
- 長くなったので、最後にまとめます。