Tweet
Tweet

Slide 1

Slide 1 text

⽂化的負債との戦い: ⽼舗ソフトウェア開発会社で アジャイル変⾰を仕掛けた8年間 DevOpsDays Tokyo 2021 2021年4⽉15⽇(⽊) ウイングアーク１ｓｔ株式会社 ⾼橋裕之、内藤靖⼦、荒川健太郎

Slide 2

Slide 2 text

本⽇、お伝えすること 我々は、⽼舗ソフトウェア開発会社で溜まっていた「⽂化的負債」の利息 を解消すべく、 「ソフトウェアプロセス改善」(Software Process Improvement, SPI) というアプローチを取ってきました。 と⾔っても、CMMIとかPMBOKとかSAFeとか……デッカイ何かを導⼊して 苦労した話しではありません。 現場で起きるひとつひとつの問題や課題に向き合いながら 「プロセス」で解決しよう！ という発想を⼤事にしてきました。 これまでの8年間で得た経験と学びについてのストーリーを発表者3⼈で紡 ぎたいと思います。 2

Slide 3

Slide 3 text

はじめに：⽂化的負債とは 技術的負債 • システム設計、ソフトウェアアーキ テクチャー、ソフトウェア開発、技 術の選択などの技術的な決定が最終 的に⽣み出すもののこと ⽂化的負債 • 採⽤や解雇の決定、コミュニティの 基準の制定や施⾏、組織の階層構造、 価値観といった⽂化的な決定が最終 的に⽣み出しているもののこと 3 “いつか返済しなければいけないし、負債の原因となっ ている問題を⻑期に渡って⼿付かずにしていればいるほ ど、利息が蓄積して、将来負債から抜け出すことが難し くなる” Effective DevOps ―4本柱による持続可能な組織⽂化の育て⽅（ Jennifer Davis (著), Ryn Daniels (著), 吉⽻ ⿓太郎 (監訳), ⻑尾 ⾼弘 (訳), オライリー・ジャパン, 2018）

Slide 4

Slide 4 text

キラキラしたDevOpsではなく、⽣々しいストーリー • 複数⼈で対話したり、教え合ったりすることを⼤切にしながら、特定の結果に向かってものを 作っていくプロセス コラボレーション • チーム間の関係を構築し、組織の共通⽬標を念頭に置いて個々のチーム⽬標の違いを乗り越え、 共感を育て、他のチームの⼈たちからも学習するプロセス アフィニティ • 加速装置 • ただし、価値、規範、組織構造の問題点をきちんと検証できていないと、⽂化的な負債が増え るうちに、⽬に⾒えないエラー要因を⽣み出す ツール • 企業がライフサイクルを通じて発展、成⻑、進化すること • 組織の規模が異なれば、技術的にも⽂化的にも考慮すべきことは違ってくる スケーリング 4 Effective DevOps ―4本柱による持続可能な組織⽂化の育て⽅（ Jennifer Davis (著), Ryn Daniels (著), 吉⽻ ⿓太郎 (監訳), ⻑尾 ⾼弘 (訳), オライリー・ジャパン, 2018）

Slide 5

Slide 5 text

⾼橋裕之 / SPQI部 部⻑ 兼 製品品質管理責任者 l ソフトウェア業界31年⽬、福島県⽣まれの⼄⼥座 l 組込みエンジニアとして交換器やルーターなどの通信インフラ ソフトウェア開発、コンシューマー向けデジタルカメラ・カム コーダー開発のプロジェクトリーダーを経て、SEPG、PMO、 PPQA（SQA）マネジャーに従事。 l ウイングアーク１ｓｔには2013年3⽉⼊社、6度⽬の転職 l ソフトウェアプロセス改善コーチ、アジャイルコーチ l 派⽣開発推進協議会（AFFORDD）監査（http://affordd.jp/） l Management 3.0 ライセンスファシリテーター l 翻訳レビュー「リーン開発の本質（2008年⽇経BP）」 「Effective DevOps（2018年オライリー）」「プロダクトマネ ジメント ―ビルドトラップを避け顧客に価値を届ける（2020 年オライリー）」

Slide 6

Slide 6 text

6 内藤 靖⼦ / SPQI部SPI G グループマネージャ l ソフトウェア業界21年⽬、千葉県⽣まれの射⼿座 l 組込みエンジニアとしてプリンタドライバ開発、コンシュー マー向けデジタルカメラ・カムコーダー開発を経て、SEPG、 PMOに従事。 l ウイングアーク１ｓｔには2015年8⽉⼊社（5年8ヶ⽉） l ソフトウェアプロセス改善エンジニア、アジャイルコーチ l CSM（認定スクラムマスター） l A-CSM（アドバンスド認定スクラムマスター） l CSPO（認定スクラムプロダクトオーナー）

Slide 7

Slide 7 text

7 荒川 健太郎 / SPQI部 SPI G 兼 Automation T l ソフトウェア業界22年⽬、兵庫県⽣まれの牡⽺座 l 受託プログラマー、受託QAエンジニアを経てウイングアーク1stに⼊社。 現在ひとりで勝⼿にSEPIT（Software Engineer in Proccess Implovement & Test）を名乗り、⾃社プロダクトのプロセス改善エンジニアリングを邁進 中。 l ⼊社5年⽬。今⽇お話しする8年の冒険に帯同したのは直近2年。 l CSM（認定スクラムマスター） l CSD（認定スクラムデベロッパー） l 会社ブログ＆YouTube よろしくおねがいします

Slide 8

Slide 8 text

9 帳票・⽂書管理ソリューション事業

Slide 9

Slide 9 text

10 帳票・⽂書管理ソリューション事業

Slide 10

Slide 10 text

12 データエンパワーメントソリューション事業

Slide 11

Slide 11 text

⽼舗 13

Slide 12

Slide 12 text

沿⾰ 14 ೥ɺཌྷγεςϜ͔ΒӦۀৡ౉

Slide 13

Slide 13 text

沿⾰ 15 ෳ਺ͷࢠձ͕ࣾ߹ྲྀ

Slide 14

Slide 14 text

⽼舗 16 प೥ प೥ प೥ प೥

Slide 15

Slide 15 text

⽼舗 → Cloudにシフト 17 प೥ प೥ प೥ प೥ ほとんどの プロダクト が クラウド サービス化

Slide 16

Slide 16 text

プロダクトの歴史が⻑い（ザ・派⽣開発） 複数の⼦会社からワンカンパニーへ（異⽂化統⼀） クラウドサービスの波（案の定Dev vs Ops vs QA） 背景（ポイント） 18 まーまー、⾊々あった

Slide 17

Slide 17 text

19 uCase1︓カオス uCase2︓静かすぎるオフィス uCase3︓要件の合意レベルが低い uCase4︓⽬的不明の会議＆⼈数が多すぎ uCase5︓プロジェクトの始まりがない uCase6︓仕事の流れを理解していない uCase7︓作るものを⾒失う uCase8︓信頼ゼロからのプロセス改善 uCase9︓エンゲージメントが低い uCase10︓⾃動テストがない uCase11︓外部研修が歓迎・推奨されない uCase12︓マイクロマネジメント uCase13︓QAがボトルネック uCase14︓MVVが浸透していない FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020 Agenda

Slide 18

Slide 18 text

Case1 カオス 20 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 19

Slide 19 text

【Case1】課題：カオス 「ボス、この会社のプロセスってなんか⾒える形あります？」 「あるよ」 21

Slide 20

Slide 20 text

【Case1】イワン・マルコム博⼠のカオス理論 22 Jurassic Park (1993) - Chaos Theory Scene (2/10) | Movieclips https://youtu.be/n-mpifTiPV4 「しかしきみは、島をよくみたことがないじゃない か。われわれの設備をみてもいないじゃないか」 「たしかに。だが、⾒るまでもないんだよ。ディ ティールは関係ない。カオス理論によれば、この島 の予測不可能性は急速に進んでいく」 ジュラシック・パーク（上）マイクル・クライトン（著）酒井昭伸（訳）

Slide 21

Slide 21 text

【Case1】課題：進まないプロセス改善 私が⼊社したのは2013年3⽉であったが、2011年ごろからBOSS は、開発⼦会社に対し標準プロセスを制定しようと奮闘していた。 ↓ ⼦会社の反応 「複雑すぎてめんどくさい」「スピードが遅くなる」 「今とくに問題ない」 ↓ 2年経ってもまったく「標準プロセス」なんてなかった 23 「なぜ？」それをやるのか、が説明不⾜ 作ってある資料は「こうあるべき」なものばかり 現場エンジニアとの⼤きな乖離（よくある）

Slide 22

Slide 22 text

【Case1】そもそも何を改善したいのか？ • プロセス改善とは、 1. 個⼈の習慣を変えること 2. 組織の⽂化を変えること • 個⼈の習慣… • 習慣として⾝についたものを、 PFDを使って変化させ、 シミュレーションで安定させる • 組織の⽂化… • 組織習慣の変化と継続を仕掛けることで組織の⽂化を変える • 褒める習慣の定着を図る • コミットメントの実現 24 清⽔吉男さん(1949年4⽉18⽇ - 2017年11⽉22⽇) 個⼈も組織も変化に強くする

Slide 23

Slide 23 text

【Case1】とりあえず現実のプロセスを⼀枚の絵にしてみたら 25

Slide 24

Slide 24 text

【Case1】課題：回ってない要件管理 • とある掲⽰板ツールを使っていたが、マネジメント・プロセス がないために常に緊張と硬直状態。調整会議が週２回、計4時 間。 26

Slide 25

Slide 25 text

【Case1】「イシューからはじめよ」 27 根気よく「なぜ、それを⾏うか？」を説明したら カイゼンがまわりはじめた

Slide 26

Slide 26 text

ぼやき：「プロセスやツールよりも個⼈と対話を」で失ったモノ “Manifesto for Agile Software Development”には共感してます。 ツールの話しばっかりするのもどうかと思います。 でもね？マニフェストに出てくる「プロセス」とは「形骸化したプロセス」や「考え なしに持ってきたフレームワーク」だと思うんです。 個⼈の対話と同じぐらいプロセスも⼤事です。 なのに「プロセス」がかっこ悪い・タブーな⾵潮出来ちゃってますよね。 試しに、いま現役エンジニアに「いまどんなプロセスでモノ作ってんの？」て質問ぶ つけてみてください。 半分ぐらいは、⾃信持って答えられないはずです。 本当にあった怖い回答： 「ウォーターフォールでもない、アジャイルでもない独⾃のプロセス」 「イテレーション⾵のプロセス」 29

Slide 27

Slide 27 text

Case2 静かすぎるオフィス 30 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 28

Slide 28 text

【Case2】課題：静かすぎるオフィス 「ひとりひとりがスペシャリストであれ」という⽂化 各⾃が得意分野を持ち、1⼈ですすめることを良しとする 他メンバーとの交流少なく、フロアがびっくりするぐらい静か レビュー⽂化なし 31 エンジニアの「⼀蘭」化 https://www.getreadyhk.com/lifestyle/hot-pick-restaurants/item/451-ichiran-ramen

Slide 29

Slide 29 text

【Case2】課題：いつも Mission: Impossible 32 Mission: Impossible (1996) - Close Call Scene (5/9) | Movieclips https://youtu.be/ar0xLps7WSY 個の限界にぶちあたる ü プロジェクト後半もずっと追加要求、仕様変更が発⽣する ü 機能開発とリリース済みのサポート対応の並⾏作業 ü リリース後に重篤なバグが⾒つかり、パッチリリースやリマスターの発⽣ ü 狭まるリリース間隔、増えるリリース回数

Slide 30

Slide 30 text

【Case2】個⼈の総和が組織の能⼒にならない 33 “ある情報処理能⼒をもった1⼈の能⼒と⽐較して、同じ能⼒をもっ た10⼈の組織の情報処理能⼒では、単純計算では10倍の情報処理能 ⼒をもつはずです。しかし、実際にはそういった線形的に能⼒が増 えることはありません。⼈数が増えるほど、徐々にその想定とは乖 離していきます。” エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング（広⽊ ⼤地(著),技術評論社, 2018）

Slide 31

Slide 31 text

【Case2】「スペシャリスト」依存はリソース効率依存 34 This is Lean: Resolving the Efficiency Paradox（ Niklas Modig (著), Par Ahlstrom (著), Rheologica Publishing, 2012） “The most obvious difference is the time it takes for diagnosis: forty-two days versus two hours. As much as anything, this time difference increased the amount of worry one of the two women felt. The forty-two days of not knowing causes Alisonʼs worry to escalate considerably. Even though Sarah was worried, she spent considerably less time not knowing.” “最も明らかな違いは、診断にかかる時間で42⽇と2時間です。 何よりも、この時間差は、2 ⼈の⼥性のうちの1⼈が感じる不安の量が膨らみました。 結果が分からない42⽇間、アリソ ンの⼼配をかなりエスカレートさせます。 サラは⼼配していましたが、結果が分からない 時間はかなり少なくなりました。”

Slide 32

Slide 32 text

【Case2】組織は数多くのプロセスで構成されている 35 This is Lean: Resolving the Efficiency Paradox（ Niklas Modig (著), Par Ahlstrom (著), Rheologica Publishing, 2012） “Processes are the cornerstones of all organizations; these are where organizations do what they do. It is through processes that flow efficiency is created.” “プロセスはすべての組織の礎です。礎としてのプロセスが、組織が成すべきことを成す場 所なのです。フロー効率が⽣み出されるのはプロセスを通じてなのです。”

Slide 33

Slide 33 text

【Case2】個の限界を突破するために • バックログやスプリントレビューに より透明性が確保し、合意形成や協 ⼒をしやすくする • スプリントプランニングで頻繁に計 画の⾒直しを⾏い、変更に対応する • フィードバックを得る機会（イベン ト）が、たくさんあり⽇々学習とカ イゼンが進む 36 チームで協⼒し、追加・変更に柔軟に対応する

Slide 34

Slide 34 text

【Case2】コミュニケーションの活性化 • イベントを通じて（半ば強制的に）チームの対話が⽣まれる • ただし、スクラムを導⼊しただけでは⾃⼰組織化されない • 我々はチームの学習を⽀援し、カイゼンを助ける 37

Slide 35

Slide 35 text

【Case2】個の限界を突破するために 1. Confluence/JIRAの活⽤ 2. ふりかえりの実施 3. カンバン・デイリーMtgの導⼊ 38 ⽂化として定着した

Slide 36

Slide 36 text

ぼやき：スクラムマスターの振る舞い 39 Super Scrum Master - the power of scrum- ⽇本語字幕版 https://youtu.be/NcWDx-XXISY スクラム界隈では有名なビデオ。スクラムマスターの１⽇を楽しく誇張し説明。 あるキックオフで、ウケ狙いでこのYoutubeを流した。 「⾼橋 ！！私 ⾔ ！！」 願 本気

Slide 37

Slide 37 text

Case3 要件の合意レベルが低い 40 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 38

Slide 38 text

【Case3】課題：要件の合意レベルが低い • PdMの視点 • お客様の要望、ステークホルダーからの要望のすべてを把握している • 管理プロセスは明確ではなく、システム化もできていない • 複数のMy要望管理Excelが存在するプロダクトも… • 開発メンバーの視点 • PdMからは主に会議や⼝頭で要件が伝えられる • 決定事項のみで、「なぜ」がわからない • 担当者間で個別にやりとりされ全体像が⾒えない • ステークホルダーの視点 • リリース直前にならないと、⾃分たちの出した要望は実現されるのか不明 • 他にどんな要望が上がっているのか、開発チームが何を作ろうとしているのか全体 像が⾒えない 41 ソフトウェア黎明期から繰り返される、アレ…

Slide 39

Slide 39 text

【Case3】課題：要件の合意レベルが低い 42 顧客が説明した要件 プロジェクトリーダの理解 アーキテクトの設計 プログラマの実装 ベータ版テスターの受難 営業の表現・約束 プロジェクトのドキュメント 実際の運⽤ 顧客への請求 得られたサポート 広告 顧客が本当に必要だったもの http://www.projectcartoon.com/

Slide 40

Slide 40 text

【Case3】課題：要件の合意レベルが低い 43 ベータ版テスターの受難 営業の表現・約束 広告 顧客が本当に必要だったもの 戦 慄 ！ ﹁ 顧 客 が 本 当 に 必 要 だ た も の ﹂ 問 題

Slide 41

Slide 41 text

【Case3】「要件管理」とは関係者が「合意」出来る仕組み • 混乱の過半数は「要件」に関するもの • 仕様モレ、誤解釈、無節操な仕様の変更… • 関係者全員で「要件管理」を維持しようと いう認識が不可⽋ • 仕様変更を発する可能性のある⼈全員に対して、 要件管理のトレーニングを実施すること • 組織の中で権限を有する者が、⾝勝⼿な要 件の変更を発することがある。 44 清⽔吉男さん(1949年4⽉18⽇ - 2017年11⽉22⽇) 要件を「合意」できるためには ü 要件を適切に仕様化する必要がある ü 仕様化の程度…“Specify(特定)”できる状態 ü 要件がレビュー可能であること

Slide 42

Slide 42 text

【Case3】作りたいもの（仕様）はどう出てくるの？ 45 要求 仕様 背景 問題や課題 （なぜ実現してほしい のか＝理由） 実現してほしいこと （曖昧、抽象的） 特定された実現⽅法 （具体的な解決策）

Slide 43

Slide 43 text

【Case3】作りたいもの（仕様）はどう出てくるの？ 46 要求 仕様 具体的な実現⽅法を考える • 漏れがないようにする • 実現可能か調べる • 曖昧さがないようにする 背景 どうすれば問題や課題が 解決できるか「理由」と 共に考える どうすれ ば問題や 課題が解 決できる か考える 具体的な 実現⽅法 を考える

Slide 44

Slide 44 text

【Case3】ツールの適切なカスタマイズとプロセス運⽤ 1. SPAのバックログ作成 2. SPAの要望管理プロセス構 築(FY2015〜) 3. SVF Cloudの要望管理プロ セス構築 4. SPAのいろいろなJIRA統合 5. Motion Boardの要望管理 プロセス構築(FY2020〜) 47 • 関係者へのヒアリング、JIRAの構築、プロセスの構築、運 ⽤説明会、運⽤後までを担う • プロダクト横断で要望管理プロセスが揃いつつある

Slide 45

Slide 45 text

【Case3】「要件管理」とは関係者が「合意」出来る仕組み 48 スクラムには要件を「合意」できる仕組みが巧みに組み込ま れている

Slide 46

Slide 46 text

Case4 ⽬的不明の会議＆⼈数が多すぎ 49 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 47

Slide 47 text

【Case4】課題：⽬的不明の会議多すぎ＆⼈数多すぎ • 会議が多い • ⾊々ない • アジェンダがない • 決定事項がない • 次のアクションがない • 議事録がない • ⼈数が多い • 同じ部⾨から複数メンバーが参加 • 会議中に⼀回も発⾔しないひと、内職者多数 • みんないたほうが良い場（キックオフ、出荷承認会議）には主 要メンバーがいない 50 https://youtu.be/bQSQ009k4tE

Slide 48

Slide 48 text

【Case4】そもそも会議とは何か？何をやっている？ • スクラムのイベントを思い出してみる • 開発系の会議ってこれらセレモニーをごった煮で「定例」と呼 んでいるだけでは？ 51

Slide 49

Slide 49 text

【Case4】ファシリテーション視点の会議設計 52 株式会社エレクセ・パートナーズ 永禮 弘之さん ⼀⾒、簡易的なファシリテーション講 座に⾒えるが部⾨間連携や合意形成の ために、どう会議（討議）を設計し、 運⽤するかまで踏み込んだ充実のセミ ナー

Slide 50

Slide 50 text

【Case4】コミュニケーション計画ベースの会議設計 • 社内で開催されている会議の4つの 分類で仕分け • 情報交換型 • 洗い出し型 • 分析・考察型 • 意思決定型 • ⽬的不明の会議と⽬的重複の会議を 淘汰し、必要最⼩限のものだけ運⽤ • 会議の関係と討議対象の情報（JIRA チケットなど）を整理し、グランド ルールと共にConfluenceで公開 53

Slide 51

Slide 51 text

【Case4】しばらくすると、改善がまわりはじめる 1. 会議設計 2. 議事録⽂化の浸透 3. 事前のアジェンダ募集の浸透 4. タイムボックスの浸透 5. ファシリテーション/ グラ フィックファシリテーション の実践 54

Slide 52

Slide 52 text

【Case4】しばらくすると、改善がまわりはじめる • グラフィックファシリテーション • 対話を⾒える化することで場の活性化や相互理解を促す 55

Slide 53

Slide 53 text

【Case4】しばらくすると、改善がまわりはじめる • Lean Coffeeでのディスカッション • 事前準備なしのミーティング形式 • ミーティングのはじめに全員で話し 合いたいことを書き出し、投票等で 話し合う順番を決めます。 • １テーマにつき、7-8分のタイム ボックスを設定してディスカッショ ンを⾏います • 時間がきたら同じテーマでのディス カッションを継続するか、違うテー マに移動するかを全員で投票し、多 数決で決めます。 56 短時間でたくさんのテーマについてディスカッションできる https://youtu.be/-QuCbT0e34A

Slide 54

Slide 54 text

Case5 プロジェクトの始まりがない 57 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 55

Slide 55 text

【Case5】課題：プロジェクトに始まりがない • 関係者の共通認識がないまま開発が進んでいく • 計画（という名のタスク⼀覧）はあるが、チーム外からは中⾝も状況もよくわからない • プロジェクト・プロダクトマネジメント教育がない • エンジニア出⾝のマネージャーほど、何をどうしたらよいかわからない 58 GOALも現在地もよくわからない…

Slide 56

Slide 56 text

【Case5】プロダクトマネジメントを確⽴する • WAのプロダクト開発において、プロダクトマネジメント観点 の役割定義とマネジメント⼿法を確⽴する • 合わせて開発プロセスをよりアジャイル型へシフトさせる 59 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング（広⽊ ⼤地(著),技術評論社, 2018）

Slide 57

Slide 57 text

【Case5】登⼭に似たソフトウェア開発がある 60

Slide 58

Slide 58 text

【Case5】登⼭に似たソフトウェア開発がある 61 GOAL START 樹海

Slide 59

Slide 59 text

【Case5】登⼭に似たソフトウェア開発がある 62 GOAL START • ゴールを⽬指す意思 • カイゼン活動 問題領域 問題領域

Slide 60

Slide 60 text

【Case5】登⼭に似たソフトウェア開発がある 63 http://fujisan.rash.jp/2012/05/120524-4.html

Slide 61

Slide 61 text

【Case5】ソフトウェア開発の本質 64 64 • リスク＝不確実性 リスクがある • 予期しない事態の発⽣（計画通りに⾏くことはない） 完全予測は不可能 • どれくらいのスピードで計画からずれているか 状況と変化を⾒据えた活動

Slide 62

Slide 62 text

【Case5】プロダクトマネジメントの⽀援 • インセプション・デッキ作成 • 計画⽴案・更新 • リスクマネジメント • キックオフミーティングの浸透 • ステークホルダーマネジメント • 開発チームのチーム⼒向上 • プロジェクトの⽴て直し 65 計画を⽴てる、キックオフを するが「当たり前」になった

Slide 63

Slide 63 text

【Case5】ナレッジサイトの構築 • WAの暗黙知を表出し、プロダクト毎にバラバラに形式知化されていたナ レッジを統合し、ナレッジサイトに蓄積する • エンジニアはナレッジサイトの知識を⾃分たちのプロダクト開発に再活⽤ し、実践・体験を通じて理解を深め、新たな知⾒(暗黙知)を得る • これがぐるぐるまわることで、エンジニアひとりひとりがキチンとした開 発⼿法を⼿に⼊れ、アジャイルなマインドセットも⾝に着けプロダクト開 発に反映する 66 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング（広⽊ ⼤地(著),技術評論社, 2018）

Slide 64

Slide 64 text

【Case5】 DevOpsの構成要素CLAMSでカテゴライズ • Culture（⽂化）：コラボレーションコ ミュニケーションを加速させる • Lean（リーン）：無駄を減らし、早く リリース可能にする • Automation（⾃動化）：⼿作業をなく す • Measurement（測定）：計測し、デー タを活⽤する • Sharing（共有）：他者が学べるように 経験・ナレッジを共有する 67 約1年で58のナレッジと5つの動画を公開

Slide 65

Slide 65 text

Case6 仕事の流れを理解していない 68 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 66

Slide 66 text

【Case6】課題：仕事の流れを理解していない • 部⾨や役割で分断されていて、プロジェクト開始されてからリ リースまでの全体の流れを理解している⼈がいない • この頃、我々は部⾨のSPIからプロダクト横断での活動にスケー ルしたが、各プロダクトの状況がわからない 69

Slide 67

Slide 67 text

• Value Stream Mapping • 全体像を理解して、カイゼンの最初の⼀歩を決める 【Case6】現状を⾒えるようにする 70 4. 未来のマップを実現する 3. 未来のマップを描く 2. ボトルネックを発⾒する 1. 現状のマップを描く ü最初のINPUTがなにかわからないまま 仕様が決定されている ü線がつながらない ü線がぐちゃぐちゃ ü出荷につながらない成果物が存在する ü複数で似て異なる成果物を作っている ü天の声が度々登場する

Slide 68

Slide 68 text

• Value Stream Mapping • 全体像を理解して、カイゼンの最初の⼀歩を決める 【Case6】現状を⾒えるようにする 71 4. 未来のマップを実現する 3. 未来のマップを描く 2. ボトルネックを発⾒する 1. 現状のマップを描く ü要望管理がされていない ü特定の⼈しかできない作業が明らかに なる üオンプレ・クラウドの連携部分の開発 プロセスが混沌としている

Slide 69

Slide 69 text

72 少しずつボトルネックを解消中 【Case6】ワークの様⼦

Slide 70

Slide 70 text

Case7 作るものを⾒失う 73 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 71

Slide 71 text

【Case7】課題：作るものを⾒失う • 新規開発で、POとの要件合意 レベルが低いまま進んでいき、 スプリントレビューではPOか らのNOが続く…. • メンバーの焦りだけが募り、 何を作るのか⾒失ったまま空 回りがつづく 74

Slide 72

Slide 72 text

【Case7】ユーザーストーリーマッピング • 現状の⾒える化 • 要件の洗い出し • 要件の認識合わせ • 要件の⾒積もり • 今後の作業の優先順位決め • リリース計画 75

Slide 73

Slide 73 text

76 • ⽴ち⽌まり、関係者間での対話を作り出す • 最初は時間かかるが、共通理解が⽣まれると前に進む 【Case7】ワークの様⼦

Slide 74

Slide 74 text

Case8 信頼ゼロからのプロセス改善 77 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 75

Slide 75 text

【Case8】課題：信頼ゼロからのプロセス改善 • 2015年頃の開発チームは「プロセス」や「カイゼン」に馴染み がなかった • チームは「何か⾯倒くさいこといわれそう」、「仕事増えそ う」と不安に思っていた（と思う） • 信頼関係がない状態ではキョリをとられ、コンフリクトすら発 ⽣しない 78

Slide 76

Slide 76 text

【Case8】 Leaders Effective Training（L.E.T） • 臨床⼼理学者トーマス・ゴードン博⼠が提唱す るゴードン・モデルを統合した、リーダーやマ ネジメントのための対⼈関係での効果的なコ ミュニケーションと他者と対⽴した場合の対⽴ 解決のためのスキルを実践形式で習得するワー クショップ*1) • ゴードン・モデル • 問題は⼈間関係の中で発⽣する。つまり、お互いのコ ミュニケーションの⽅法によって起こる。 • 相⼿の⾏動によって不都合や問題が⽣じた場合におい て、5つの主要なスキル「アクティブ・リスニング」 「対決的I-メッセージ」「ギア・シフト」「メソッド Ⅲ」「価値観の衝突のオプション」を⽤いることで直 ⾯している問題や状況を整理し、解決へと導く 79 *1) https://gordontraining.jp/ http://www.lc-t.jp/ Dr. Thomas Gordon

Slide 77

Slide 77 text

80 信頼関係がない中のコミュニ ケーションにはとても有効 チームの価値観や考えを引き出す ことができる 【Case8】 ⼼理的なキョリを縮める

Slide 78

Slide 78 text

Case9 エンゲージメントが低い 81 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 79

Slide 79 text

エンゲージメントとは 「ここで働き続ける理由」 82

Slide 80

Slide 80 text

【Case9】エンゲージメントとは • 従業員満⾜度 • 職場環境や給与、福利厚⽣など への満⾜度＝組織が与えるもの • モチベーション • ⾏動を起こすための動機＝個⼈ が感じるもの • ロイヤルティ • 組織に対する帰属意識、忠誠⼼ ＝上下関係が⽣み出すもの • エンゲージメント • 主体的・意欲的に取り組んでい る状態＝相互の対等な関係に基 づくもの 83 引⽤元：組織は「⾔葉」から変わる。ストーリーでわかるエンゲージメント⼊⾨ ⿊⽥ 天兵 (著)朝⽇新聞出版 (2020/2/20)

Slide 81

Slide 81 text

【Case9】エンゲージメント 84 引⽤元：組織は「⾔葉」から変わる。ストーリーでわかるエンゲージメント⼊⾨ ⿊⽥ 天兵 (著)朝⽇新聞出版 (2020/2/20)

Slide 82

Slide 82 text

【Case9】 SPQI の平均スコア変移 85 74 2018/11 就任 63 ★2019.11 組織変更 64

Slide 83

Slide 83 text

【Case9】仮説と実験 • 「64」という数字がいったい何をを表しているのか、このとき は正直さっぱりわからなかった • 就任したてなこともあり、まずは以下の施策に注⼒した • まず、⾃分を知ってもらう • みんなを知る（リーダーズ・アクライメーション実施） • GMGの⼒量を測り、育成を開始 • 1on1が⼀度も⾏われていなかったので、週次で開催 • 単純に「残業が多い」と怒られていたので、 働き⽅の分析を⾏った 86 リーダーズアクライメーションの⾵景

Slide 84

Slide 84 text

【Case9】残業バランスから⾒える組織の問題 残業⿇痺ライン ＝45〜60h 「認知の歪み」ゾーン

Slide 85

Slide 85 text

【Case9】 SPQI の平均スコア変移 88 74 2018/11 就任 63 ★2019.11 組織変更

Slide 86

Slide 86 text

【Case9】仮説と実験 • 1ポイント下がった「63」になってしまった。 • 正直「うっ」とはなったが、実際エンゲージメントを⾼める施 策は「何もしていない」のでスコアが上がるはずもないと考え 直した。 • 前期の調査でわかったこと • 部としての⼀体感がまったくない。 • 部としての⽬標もない（のろしは上がっても⾃分ごとではない） • QAという、おなじ知識・技術ドメインの仕事をしているにも関わらず、 グループ同⼠（GMG同⼠）の関わりがまったくない。ので、技術の流 通もない。（すべては、前任のBOSSを通さないとダメだった） • とりあえず、上記をカイゼンするだけでもスコアはあがるので はないか？ 89

Slide 87

Slide 87 text

【Case9】合宿をやった

Slide 88

Slide 88 text

【Case9】合宿をやった • ⾃分たちで、組織⽬標を考える（ワールドカフェ） ① 強いQAチームを作るには ② プロダクト連携時代のQAとは ③ クラウドファースト時代のQAとは ④ QAとしてやりたいこと • メンバー全員に「パフォーマンス⽬標」を⽴ててもらった • http://nexcf.1stg.local/pages/viewpage.action?pageId=103172393 • このときの様⼦はブログに書いています • The New Normal https://link.medium.com/NgDNtq7VZ7 91

Slide 89

Slide 89 text

【Case9】合宿！その時荒川は。 92 マネージャー陣の狙いなどお構いなしに初の札幌をおおいに楽しむ ワーク楽しい あの公園 夜パフェ セコマ ※合宿も真⾯⽬に取り組みました（次ページ）

Slide 90

Slide 90 text

【Case9】合宿で起きた変化 93 ・OKRで ⾃分の⽬標出し ・ムービングモチベーターズ ・ワールドカフェ 「強いQAチームとは」etc. ・モチベーショングラフ ・ワールドカフェ 「組織⽬標」 他律的 ⾃律的 ⾃分は何に喜びを感じるのか ⾃分たちはどうありたいか ⾃分はどうありたいか DAY1のワーク DAY2のワーク

Slide 91

Slide 91 text

【Case9】合宿で起きた変化 94 部の仲間が⾃発的に⾃⼰の⽬標設定を⾏った

Slide 92

Slide 92 text

【Case9】 SPQI の平均スコア変移 95 74 2018/11 就任 63 ★2019.11 組織変更 71

Slide 93

Slide 93 text

【Case9】仮説と実験 • スコアが「71」にジャンプアップ！しかし… • 新しい「部⾨⽬標」に沿った活動をするメンバーと、従来のやり⽅を 変えないメンバーがはっきりと⾒えてきた（スコア分布が歪） • 相変わらず、残業時間が多いメンバーが変わらない （特にグループマネジャー） • エンゲージメントも、極端にスコアが⾼いグループがある。だが良い 取り組みをしているわけではなく「アドレナリン・ジャンキー」的な 雰囲気が漂っている。 • やったこと • 残業多いひとへの業務カイゼン指⽰ • 組織変更をした 96

Slide 94

Slide 94 text

【Case9】 SPQI の平均スコア変移 97 74 2018/11 就任 63 ★2019.11 組織変更 71 67

Slide 95

Slide 95 text

【Case9】仮説と実験 • スコアが「67」に下がる • 前期⾼かったグループが、逆張りの急降下 • 開発部⾨との関係性低下 • 仕事を指⽰され、こなすだけ…の傾向が強いグループは、開発側の状 況に多⼤な影響を受ける • マネジメントラインを⾒直して、組織⽬標を⾃律して具現化す るライン構築を⽬指した • ⼀部のメンバーからは、猛反発があった • 丁寧に向き合ったつもり • 他部⾨のマネジャーからクレームもあったが、丁寧に説明して理解を 得た 98

Slide 96

Slide 96 text

【Case9】 SPQI の平均スコア変移 99 74 2018/11 就任 63 ★2019.11 組織変更 71 67 72

Slide 97

Slide 97 text

【Case9】仮説と検証 • 「72」に復活した。最新は「76」 • 組織変更で⼀部の反発が強かったものの、新体制のチームビル ディングを経て、各グループのエンゲージメントスコアは総じ てアップした。 • 全体的な底上げを⽬指し、SPQI部へのインナーブランディング を開始した。 • 「⾔葉づくり」を丁寧に • 企業レベルのMission、Vision、Valueを部⾨やチームレベルに落とし込む作業が 割とむずかしい件・後編 • https://link.medium.com/OYSo7s1VZ7 • 全員でOKRを利⽤した⽬標管理 • ブログによる発信を推奨（部⻑が率先して） • 定⽯集の「GROW」サイト⽴ち上げ 100

Slide 98

Slide 98 text

101 【Case9】OKRでやり遂げる⽬標を⽴てる OKRの筆者Christina Wodtkeは、⽴てた⽬標などを 「 なぜ、やり遂げることができないのか」について • ゴールに優先順位を付けていない • 熱意を持って漏れなくゴールを伝えていない • やり遂げるためのプランがない • 重要事項のための時間を空けていない • 繰り返さずにやめてしまう

Slide 99

Slide 99 text

102 【Case9】OKRでやり遂げる⽬標を⽴てる • じぶん戦略を考え⽬標を達成する。パ フォーマンス⽬標とも⾔います • アジャイルで良く使われている 「ユーザーストーリー」で書けます。 • 「誰」や役割（〜として）、 • 「何」やアクション（〜したい）、 • 「なぜ」やビジネスのメリット（そ れは〜のためだ） • Acceptance Criteria には何をすれば⽬標 に近づけるかを書きます KR O(Objective)

Slide 100

Slide 100 text

【Case9】OKRでやり遂げる⽬標を⽴てる • 部下の⽬標（四半期ごと）をコミッ トさせ、後押しする。 （⾦、アサインメント） • フィードバックする。 • 達成に障害があったら取り除く。 • ↑ これを毎週1on1で実施する。 ※ 1on1（週次）は「雑談ツール」で はなく「⽀援ツール」 • ⽴てた⽬標（四半期ごと）をやり遂 げられたか？は、わかりやすい評価 要素となる。 103

Slide 101

Slide 101 text

【Case9】最新のエンゲージメント 104

Slide 102

Slide 102 text

Case10 ⾃動テストがない 105 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 103

Slide 103 text

【Case10】課題：⻑きに渡る⼿動時代の泰平（泰平していない） • 下流での⼿動テストのみが品質に向き合う時間 106 「今⽇ビルドされてテスト開始する予定だったけどビルド遅れそうだってさ」 「ま、しょうがないよね。開発だって頑張ってるし」 〜数⽇後〜 「上⻑さんすみません。休⽇出勤申請出します」 • ストップウォッチ⽚⼿に性能測定 「（ボタンをクリック）えいっカチっ！（画⾯が表⽰された）えいっカチっ！」 QA⻑時間労働 ストレスフルな仕事の結果、品質も上がらずバグは市場に流出 https://youtu.be/mS7O4oawVMo

Slide 104

Slide 104 text

【Case10】 Agile Testing の4象限 107 http://www.informit.com/articles/article.aspx?p=2253544&ranMID=24808 Examples A/Bテスト (最初に書かれた)ストーリーテスト UXテスト プロトタイプ シミュレーション 探索的テスト ワークフロー システムインテグレーション ユーザビリティテスト UAT（ユーザー受⼊テスト） 単体テスト コンポーネントテスト 接続性テスト パフォーマンステスト ロードテスト セキュリティテスト 品質特性（〜性テスト） 開発チームを⽀援する ビジネス⾯ 技術⾯ Q2 Q3 Q1 Q4 ⾃動と⼿動 ⾃動 ⼿動 ツール 製品を批評する

Slide 105

Slide 105 text

【Case10】 Agile Testing の4象限 http://www.informit.com/articles/article.aspx?p=2253544&ranMID=24808 Examples A/Bテスト (最初に書かれた)ストーリーテスト UXテスト プロトタイプ シミュレーション 探索的テスト ワークフロー システムインテグレーション ユーザビリティテスト UAT（ユーザー受⼊テスト） 単体テスト コンポーネントテスト 接続性テスト パフォーマンステスト ロードテスト セキュリティテスト 品質特性（〜性テスト） 開発チームを⽀援する ビジネス⾯ 技術⾯ Q2 Q3 Q1 Q4 ⾃動と⼿動 ⾃動 ⼿動 ツール 製品を批評する 108

Slide 106

Slide 106 text

【Case10】 Agile Testing の4象限 http://www.informit.com/articles/article.aspx?p=2253544&ranMID=24808 Examples A/Bテスト (最初に書かれた)ストーリーテスト UXテスト プロトタイプ シミュレーション 探索的テスト ワークフロー システムインテグレーション ユーザビリティテスト UAT（ユーザー受⼊テスト） 単体テスト コンポーネントテスト 接続性テスト パフォーマンステスト ロードテスト セキュリティテスト 品質特性（〜性テスト） 開発チームを⽀援する ビジネス⾯ 技術⾯ Q2 Q3 Q1 Q4 ⾃動と⼿動 ⾃動 ⼿動 ツール 製品を批評する 109

Slide 107

Slide 107 text

【Case10】Automationチーム 荒川のアプローチ 110 まだまだ少ない機会の中、前期の1年間で数プロダクトの ⾃動テストが稼働開始した。 開発とコラボ！ 学びを⽌めない！ ⾃動テストの損益分岐点 「何が起きるのが嫌ですか？」 Dev + QA はじめの⼀歩はベイビーステップ 開発との コラボレーション アプローチ Collaboration with developer ターゲットを限定 型にこだわりすぎない ⾃動化のハードルを下げる テーマ

Slide 108

Slide 108 text

クライアント クライアント インターネット サーバー ⾃動テストが実装できる箇所はたくさんある 全部やりたいのはヤマヤマだが・・・ 【Case10】「何が起きるのが嫌ですか？」

Slide 109

Slide 109 text

「新しいビルドで、画⾯が崩れたり、 ボタンが押せなくなったりすることがイヤ。」 【Case10】「何が起きるのが嫌ですか？」

Slide 110

Slide 110 text

「じゃあ、今回はここのテストをしましょう。」 実現可能で意味のあるテストを特定し ツールやフレームワークを選定する 【Case10】「何が起きるのが嫌ですか？」 クライアント クライアント インターネット サーバー

Slide 111

Slide 111 text

【Case10】はじめの⼀歩はベイビーステップ 完璧を⽬指さず、まず⼩さな⼀歩を踏み出すことが重要 そして半歩半歩でも⼩さなステップを積み重ねていくことを考える いやUIレイヤーが ⼤きくたっていい︕ そこから醸成された習慣・⽂化が最適なものに向かっていく 意味のあるものであれば原理原則にとらわれすぎない

Slide 112

Slide 112 text

【Case10】⾃動テストの損益分岐点 115 https://www.amazon.co.jp/dp/B006RUFM5A/ref=cm_sw_r_tw_dp_x_s9nMFb3XDQK1W ⾃動化に対する考え⽅のハードルを下げる およそ4回の実施で、 ⼿動テストと⾃動テストの コストが逆転する。

Slide 113

Slide 113 text

【Case10】そして⼤切にしていること 116 開発と同じ⾔語・⽂脈で話せること Dev + QA DevOpsを志向してSET的な動きをするのであれば、 DevとQAのスキル範囲はシームレスな状態を⽬指すべき 学習・研鑽を続ける

Slide 114

Slide 114 text

【Case10】活動の経過 117 E2E⾃動テストが4プロダクト あるE2E⾃動テストの効果 CIサイクルに組み込んたWebAPI⾃動 テストが1プロダクトで動作中 他にも、 開発に代わって⼀部ユニットテストも 書いてみた ストップウォッチ体制も無事脱却

Slide 115

Slide 115 text

Case11 外部研修が歓迎・奨励されない 118 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 116

Slide 116 text

【Case11】課題：外に出ていかないエンジニア ・外部研修があまり歓迎されない空気感 1⽇かかる研修は、 「実業務のリソースー1⽇」 という⽂化・空気感 休⽇の研修参加 ＝業務扱い ＝代休取得が必要 ＝1⽇⽳を空ける ＝周りが困る ・⼈材育成のための予算を計上していない部⾨がおおい ・エンジニアが常に忙しい

Slide 117

Slide 117 text

【Case11】なぜ、予算がないのか？ 120 ᶄݱঢ় ᶃ7JTJPO ʢͳΓ͍ͨ࢟ ᶅΪϟοϓΛղফ͢Δํ๏ Ϊϟοϓ ઓུɾઓज़ ༧ࢉ

Slide 118

Slide 118 text

【Case11】研修を企画する 1. スキルマップを作成する • ⾃⾝やメンバーの強化したいスキルを明確にする 2. 情報収集 • トレーニング、研修、カンファレンスの選定・予算計上 • ときには、開発チームの分も計上 3. 社外から講師を招いて集合研修を企画する • 部⾨の集合研修を企画・実施（FY2016-FY2018） • 開発や他部⾨も巻き込んで研修やトレーニングを実施（FY2019〜） • 企画書、集客、運営、事後アンケートなど裏⽅作業全般を担当 4. 開発職新⼈研修を企画・実施する • 新⼈が各部⾨で数週間ずつ研修を⾏う 121 • 他部⾨から集合研修⼀緒にやろうって声をかけられる • 新⼈研修のリクエストをいただく

Slide 119

Slide 119 text

【Case11】SPQI 発⾜後 122 周りも少し変わってきた 「研修？いってこい！」 「イベント？いってこい！」 「⾦は出す！」 認定や トレーニング ブログ 外部発表 ブログなどで社内展開 外部イベントで発表 部内の研鑽⽂化の向上を⽬論む 部内の研鑽⽂化は根付きつつある

Slide 120

Slide 120 text

Case12 マイクロマネジメント 123 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 121

Slide 121 text

【Case12】課題：官僚型の組織 指 揮 命 令 報 告 指示待ち 抱え込み 無茶な指示 指示がないから帰る… やらされ感 フォロー不足 つまらない 恐れと非難 細かい指示 部下が不安 全ての報告を求める 時間がない 苦しい 思考停止 BOSS

Slide 122

Slide 122 text

【Case12】官僚型から⾃⼰組織化へ 指 揮 命 令 報 告 指示待ち 抱え込み 無茶な指示 指示がないから帰る… やらされ感 フォロー不足 つまらない 恐れと非難 細かい指示 部下が不安 全ての報告を求める 時間がない 苦しい 思考停止 ⾃⼰組織化 ⾃⼰組織化が進むと、チーム の問題を⾃分ごととして捉え ることができるようになりま す 明確なゴールと目標 モチベーションの理解 よく考える 積極的 自分たちで決める ナレッジの整備 エスカレーション ふりかえり 適切な権限移譲 Build the Trust フィードバック BOSS

Slide 123

Slide 123 text

【Case12】バランスの両⽴ 階層型 ネットワーク型 バランス （両⽴） 特化（専⾨化） 効率性（予測可能で安定） 集中化（無駄・コスト低下） 活⽤ 汎化（イノベーション） 有効性（複雑で変化が早い） 分権化（意思決定が迅速） 探索

Slide 124

Slide 124 text

【Case12】課題：権⼒の象徴＝情報 BOSS すべての情報 はワシを通す のじゃ！

Slide 125

Slide 125 text

【Case12】コミュニケーションの複雑性 • ⼈数が増えるとコミュニケーショ ンのオー バーヘッドが増えます。 • そこで規模拡⼤が必要な場合、チーム内の ⼈数を増やすのではなくチームの数を増や すほうが良いとされています。 • なぜなら、全員が知っている状態が作りや すいので、たとえ全員が同じ場所にいなく ても同じ情報を知っているならだいたい同 じ判断が下せるからです。 • これが意思決定のスピードアップにつなが ります。 • この図をみると、せいぜい5⼈ぐらいが限 度に⾒えます。 https://churchhealthwiki.wordpress.com/2015/07/05/teamwork-the-rapid-complexity- that-arises-when-your-team-or-small-group-exceeds-10-people/ コミュニケーションパスの 複雑性をなるべく最⼩に

Slide 126

Slide 126 text

【Case12】メドラーズゲーム 129 https://management30.com/practice/meddlers/ 現メンバーを活⽤しどういった組織を作るか、⼈数のバラン スをどうするかなどをシミュレーション

Slide 127

Slide 127 text

【Case12】組織改⾰のポイント 130 a. 組織のMissionを⾃分の⾔葉として語れるリーダーを配置する b. マイクロマネジメントから卒業しリーダーにはメンバー育成を期待する c. カルチャーバブルを発展できるリーダーを⾒極めバランスよく配置する d. 1つのチームはなるべく5⼈以下とする e. チーム内の個⼈スキルが偏らないようにする。 f. 困難に⽴ち向かい成⻑できるレジリエントな組織体制を⽬指す g. リエゾンタイプの⼈材を⾒極め、組織の潤滑油とする h. 経営陣からの期待と部⾨Missionの実現にコミットする

Slide 128

Slide 128 text

【Case12】成⻑志向か？ • メタスキル習得の⼤部分は「⾃分の仕事経験」といえる。 • では、仕事で経験して学びを得るとは？ • 部下がチャレンジしたい仕事をアサインしてあげることが⼤事。 これは上司にしか出来ない。 131 優れたマネジャーを調査したところ、成⼈の学びとは― 70% ⾃分の仕事経験から 20% 他者の観察やアドバイスから 10% 本を読んだり研修を受けたりすることから ーから得ている マイケル・ロンバルド&ロバート・アイチンガー Career Architect Development Planner, 5th Edition - 2010

Slide 129

Slide 129 text

【Case12】 Certified Agile Leadership(CAL1) • ハイパフォーマンスな組織に成⻑するためのリーダーシップモデルを学ぶ • 組織カルチャーが変わるとき、構造と意識の両⽅が変わる • カルチャー （カルチャーバブル）を作るのはリーダーであり、リーダー ⾃⾝が⾃分のマインド、振る舞いから変える。そうしていけば周りもよい 影響を受ける • https://shift314.com/certified-agile-leadership-training-cal-1/ 132 https://medium.com/wingarc/50f550e675b2

Slide 130

Slide 130 text

【Case12】Management3.0 • 複雑な状況において有効なマネジメントを学び、メンバーを⾃⼰組織化に 導く。楽しく論理的なプラクティスが多数。 • ムービングモチベーターズ • メンバーのやる気スイッチを知れば、やる気すいっちがONになる働きかけ⽅ができ るようになる。何より考え、価値観をしれて楽しい。 • デリゲーションポーカー • チームの仕事の種類と意思決定の権限委譲レベルを明確にする • 「上司がやってくれるはず」、 「チームに任せた！(けどできてないじゃん…)」 といった思い込みやすれ違いをなくし、⾃律的に動きやすくなる 133

Slide 131

Slide 131 text

【Case12】反射関係における権限委譲 134

Slide 132

Slide 132 text

【Case12】ワークで起きた変化・気づいた効果 135 期待される ゴールの 明確化 WHAT：明確 HOW：委譲 セルフ マネジメント 信頼に 応えたいという モチベーション これらの要素は、約２年後に突如始まる フルリモートワーク体制へのスムーズな移⾏ にも深く影響を与える デリゲーション ポーカー チームの⽅向性と個⼈の役割が明確に 意思決定のスピードアップ 個⼈のモチベーション向上

Slide 133

Slide 133 text

Case13 QAがボトルネック 136 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 134

Slide 134 text

【Case13】課題： QAが出荷のボトルネックと思われている 137 ゲートキーパー型QA

Slide 135

Slide 135 text

【Case13】課題： QAが出荷のボトルネックと思われている 138 分析 開発 テス ト QA/デプロイ バグ検出数が⽢いから 品質が上がらないんだ テストやりすぎてるん じゃないの？ 実装が⼤変だがら テストしてるヒマがない Dev Ops

Slide 136

Slide 136 text

【Case13】課題： QAが出荷のボトルネックと（まだ）思われている 139 我々のスループットを増やす努⼒は続けるが… …もっと、Dev⼯程の問題を解決する必要がある ü 計画を変えないか、そもそもない ü 仕様がない ü Dev⼯程のテストが⾜りてない ü Dev⼯程の遅れで時間が無くなる 引⽤：⻄村直⼈,⾓⾕信太郎. アジャイルサムライ達⼈開発者への道

Slide 137

Slide 137 text

【Case13】戦術：シフト・レフト、シフト・ライト 計画 実装 ビルド テスト リリース デプロイ 運⽤ Shift Left Testing Shift Right Testing シフト・ライト・テスト • 運⽤中にもテストを⾏い品質を監視するとで常に 品質を保証し続ける サポート情報分析によるフロントローディング 分析してパターン化して再利⽤して開発を成⻑させる シフト・レフト・テスト • ライフサイクルの早い段階でテストを開始できる • 開発完了後に⾏っているテスト実⾏を、もっと早 い段階でかつ⾃動的に継続的に実施する • 早い段階でテストを実⾏するために、コンポーネ ントがそろわない状況でもE2Eテストを実⾏でき るようにする • GUI経由の機能テストをAPIレベルで⾏うテストが 実⾏できるようにする

Slide 138

Slide 138 text

【Case13】現状の共通認識を促す 141 開発とコラボ！ 学びを⽌めない！ 現状の共通認識を促す 施策1 「QAがボトルネックと思われている」 「テストで品質は上がらない」 「開発とQAに溝がある」 をはっきりと繰り返し、告げられ共通認識になる

Slide 139

Slide 139 text

【Case13】グループ⽬標の⽴案 開発とコラボ！ 学びを⽌めない！ 部⾨⽬標の達成につながるグループ⽬標の⽴案 施策2 部⾨⽬標の達成につながるグループ⽬標の⽴案 シフト・レフト・テスティング、開発との融合を促進する

Slide 140

Slide 140 text

【Case13】QA・AutomationTとの連携 143 プロセス改善活動 要件管理プロセス構築、プロジェクト計画⽴案・更新サ ポート、リスク管理・追跡サポート、チームビルディング、 ふりかえり 施策3

Slide 141

Slide 141 text

【Case13】兼務の強み 各プロダクトの PdM・開発チーム 課題発⾒ SPI活動（課題発⾒のトリガー）： ・チームビルディング、ふりかえり SPI 内藤・荒川 実⾏フェーズへ カイゼンポイント発⾒フェーズ N A 課題分析 施策検討

Slide 142

Slide 142 text

【Case13】兼務の強み コラボレーション アフィニティ 実⾏フェーズ or ＋ SPI N A QA A Automaiton A 打ち⼿の選択肢の拡張 施策開始までのスピード向上 各プロダクトの PdM・開発チーム

Slide 143

Slide 143 text

【Case13】現在 146 ・SPQI部に共通認識が⽣まれる ・共通認識を持つことで進む⽅向が決まり、⾏動できる ・開発・QAの対話が増え、相互理解が進む

Slide 144

Slide 144 text

Case14 Mission・ Vision・ Value が浸透していない 147 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 145

Slide 145 text

【Case14】課題：Mission・ Vision・ Value が浸透していない • ⼈は何か困難に出会ったとき、なんらかの「判断」を下してい る。組織の場合、その判断の礎はMission・ Vision・ Valueであ るべきだ。これが無いと、スピードが遅くなったり間違った⽅ 向へ進んでしまう。 • ところが、ハイパフォーマーが必ずしも企業⽂化を理解しているとは 限らない 148

Slide 146

Slide 146 text

【Case14】コアバリュー・セッション 149

Slide 147

Slide 147 text

【Case14】課題：Mission・ Vision・ Value が浸透していない • 組織の末端まで浸透しているとは限らない… 150

Slide 148

Slide 148 text

3. 社会に提供する価値 2. なりたい 姿 【Case14】⾔葉を分類するためのフレームワーク 社会の未来像 4. 顧客に約束する価値提供 5. 戦略、戦術 6. 理想的な⾏動 7. ⼤切にしたい価値観、⽂化、強み 1. 現状 (外部・内 部の環境) 組織は「⾔葉」から変わる。ストー リーでわかるエンゲージメント⼊⾨ ⿊ ⽥ 天兵 (著)朝⽇新聞出版 (2020/2/20)

Slide 149

Slide 149 text

3. 社会に提供する価値 2. なりたい 姿 【Case14】⾔葉を分類するためのフレームワーク 社会の未来像 4. 顧客に約束する価値提供 5. 戦略、戦術 6. 理想的な⾏動 7. ⼤切にしたい価値観、⽂化、強み 1. 現状 (外部・内 部の環境) Vision Mission Value Employee Principles WHY

Slide 150

Slide 150 text

【Case14】たぶん認知は上がっている 153

Slide 151

Slide 151 text

未来へ そして⼈⽣はつづく 154 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020

Slide 152

Slide 152 text

【未来へ】内藤靖⼦の決意 • まわりを変えたかったらまずは⾃ 分が実践する • 数年間の活動を経て、カルチャーバブ ルは確実に広がっている • フィードバックを得ること、受け ⽌めて変わリ続ける • ⾼橋さんは私たちのよきコーチ • 私も誰かのよきコーチになれるように 励みます 155

Slide 153

Slide 153 text

【未来へ】荒川健太郎の「⼈⽣はつづく」 156 2年 8年 でも、 少しづつ 変わってきてる なかなか うまくいかない 銀の弾丸 なんてない まだ DEV QA 終わりのない 学び ⽂化を変えるのは 終わりのない 営み 毎⽇何か動いていこう！

Slide 154

Slide 154 text

【未来へ】⾼橋裕之の覚悟 157 “今ある仕事の「壁」から逃げるな。 逃げ癖が付くと、⼈⽣に⽴ちはだかる「壁」も越えられな くなる。仕事に⽐べたら⼈⽣の「壁」の⽅が何倍も⾼い” 清⽔吉男

Slide 155

Slide 155 text

まとめ 「⽂化的負債」の利息を解消するには、 「ソフトウェアプロセス改善」 (Software Process Improvement, SPI) というアプローチが⼤事。 「プロセス」で解決しよう！ 158

Slide 156

Slide 156 text

͝ਗ਼ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ʂ 159