文化的負債との戦い: 老舗ソフトウェア開発会社でアジャイル変革を仕掛けた8年間

DevOpsDays Tokyo 2021
https://confengine.com/conferences/devopsdays-tokyo-2021/proposal/15184/8

Transcript

1. ⽂化的負債との戦い: ⽼舗ソフトウェア開発会社で アジャイル変⾰を仕掛けた8年間 DevOpsDays Tokyo 2021 2021年4⽉15⽇(⽊) ウイングアーク１ｓｔ株式会社 ⾼橋裕之、内藤靖⼦、荒川健太郎
2. 本⽇、お伝えすること 我々は、⽼舗ソフトウェア開発会社で溜まっていた「⽂化的負債」の利息 を解消すべく、 「ソフトウェアプロセス改善」(Software Process Improvement, SPI) というアプローチを取ってきました。 と⾔っても、CMMIとかPMBOKとかSAFeとか……デッカイ何かを導⼊して 苦労した話しではありません。 現場で起きるひとつひとつの問題や課題に向き合いながら 「プロセス」で解決しよう！ という発想を⼤事にしてきました。 これまでの8年間で得た経験と学びについてのストーリーを発表者3⼈で紡 ぎたいと思います。 2
3. はじめに：⽂化的負債とは 技術的負債 • システム設計、ソフトウェアアーキ テクチャー、ソフトウェア開発、技 術の選択などの技術的な決定が最終 的に⽣み出すもののこと ⽂化的負債 • 採⽤や解雇の決定、コミュニティの 基準の制定や施⾏、組織の階層構造、 価値観といった⽂化的な決定が最終 的に⽣み出しているもののこと 3 “いつか返済しなければいけないし、負債の原因となっ ている問題を⻑期に渡って⼿付かずにしていればいるほ ど、利息が蓄積して、将来負債から抜け出すことが難し くなる” Effective DevOps ―4本柱による持続可能な組織⽂化の育て⽅（ Jennifer Davis (著), Ryn Daniels (著), 吉⽻ ⿓太郎 (監訳), ⻑尾 ⾼弘 (訳), オライリー・ジャパン, 2018）
4. キラキラしたDevOpsではなく、⽣々しいストーリー • 複数⼈で対話したり、教え合ったりすることを⼤切にしながら、特定の結果に向かってものを 作っていくプロセス コラボレーション • チーム間の関係を構築し、組織の共通⽬標を念頭に置いて個々のチーム⽬標の違いを乗り越え、 共感を育て、他のチームの⼈たちからも学習するプロセス アフィニティ • 加速装置 • ただし、価値、規範、組織構造の問題点をきちんと検証できていないと、⽂化的な負債が増え るうちに、⽬に⾒えないエラー要因を⽣み出す ツール • 企業がライフサイクルを通じて発展、成⻑、進化すること • 組織の規模が異なれば、技術的にも⽂化的にも考慮すべきことは違ってくる スケーリング 4 Effective DevOps ―4本柱による持続可能な組織⽂化の育て⽅（ Jennifer Davis (著), Ryn Daniels (著), 吉⽻ ⿓太郎 (監訳), ⻑尾 ⾼弘 (訳), オライリー・ジャパン, 2018）
5. ⾼橋裕之 / 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 年オライリー）」
6. 6 内藤 靖⼦ / SPQI部SPI G グループマネージャ l ソフトウェア業界21年⽬、千葉県⽣まれの射⼿座 l 組込みエンジニアとしてプリンタドライバ開発、コンシュー マー向けデジタルカメラ・カムコーダー開発を経て、SEPG、 PMOに従事。 l ウイングアーク１ｓｔには2015年8⽉⼊社（5年8ヶ⽉） l ソフトウェアプロセス改善エンジニア、アジャイルコーチ l CSM（認定スクラムマスター） l A-CSM（アドバンスド認定スクラムマスター） l CSPO（認定スクラムプロダクトオーナー）
7. 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 よろしくおねがいします
8. 9 帳票・⽂書管理ソリューション事業
9. 10 帳票・⽂書管理ソリューション事業
10. 12 データエンパワーメントソリューション事業
11. ⽼舗 13
12. 沿⾰ 14 ೥ɺཌྷγεςϜ͔ΒӦۀৡ౉
13. 沿⾰ 15 ෳ਺ͷࢠձ͕ࣾ߹ྲྀ
14. ⽼舗 16 प೥ प೥ प೥ प೥
15. ⽼舗 → Cloudにシフト 17 प೥ प೥ प೥ प೥ ほとんどの プロダクト が クラウド サービス化
16. プロダクトの歴史が⻑い（ザ・派⽣開発） 複数の⼦会社からワンカンパニーへ（異⽂化統⼀） クラウドサービスの波（案の定Dev vs Ops vs QA） 背景（ポイント） 18 まーまー、⾊々あった
17. 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
18. Case1 カオス 20 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
19. 【Case1】課題：カオス 「ボス、この会社のプロセスってなんか⾒える形あります？」 「あるよ」 21
20. 【Case1】イワン・マルコム博⼠のカオス理論 22 Jurassic Park (1993) - Chaos Theory Scene (2/10) | Movieclips https://youtu.be/n-mpifTiPV4 「しかしきみは、島をよくみたことがないじゃない か。われわれの設備をみてもいないじゃないか」 「たしかに。だが、⾒るまでもないんだよ。ディ ティールは関係ない。カオス理論によれば、この島 の予測不可能性は急速に進んでいく」 ジュラシック・パーク（上）マイクル・クライトン（著）酒井昭伸（訳）
21. 【Case1】課題：進まないプロセス改善 私が⼊社したのは2013年3⽉であったが、2011年ごろからBOSS は、開発⼦会社に対し標準プロセスを制定しようと奮闘していた。 ↓ ⼦会社の反応 「複雑すぎてめんどくさい」「スピードが遅くなる」 「今とくに問題ない」 ↓ 2年経ってもまったく「標準プロセス」なんてなかった 23 「なぜ？」それをやるのか、が説明不⾜ 作ってある資料は「こうあるべき」なものばかり 現場エンジニアとの⼤きな乖離（よくある）
22. 【Case1】そもそも何を改善したいのか？ • プロセス改善とは、 1. 個⼈の習慣を変えること 2. 組織の⽂化を変えること • 個⼈の習慣… • 習慣として⾝についたものを、 PFDを使って変化させ、 シミュレーションで安定させる • 組織の⽂化… • 組織習慣の変化と継続を仕掛けることで組織の⽂化を変える • 褒める習慣の定着を図る • コミットメントの実現 24 清⽔吉男さん(1949年4⽉18⽇ - 2017年11⽉22⽇) 個⼈も組織も変化に強くする
23. 【Case1】とりあえず現実のプロセスを⼀枚の絵にしてみたら 25
24. 【Case1】課題：回ってない要件管理 • とある掲⽰板ツールを使っていたが、マネジメント・プロセス がないために常に緊張と硬直状態。調整会議が週２回、計4時 間。 26
25. 【Case1】「イシューからはじめよ」 27 根気よく「なぜ、それを⾏うか？」を説明したら カイゼンがまわりはじめた
26. ぼやき：「プロセスやツールよりも個⼈と対話を」で失ったモノ “Manifesto for Agile Software Development”には共感してます。 ツールの話しばっかりするのもどうかと思います。 でもね？マニフェストに出てくる「プロセス」とは「形骸化したプロセス」や「考え なしに持ってきたフレームワーク」だと思うんです。 個⼈の対話と同じぐらいプロセスも⼤事です。 なのに「プロセス」がかっこ悪い・タブーな⾵潮出来ちゃってますよね。 試しに、いま現役エンジニアに「いまどんなプロセスでモノ作ってんの？」て質問ぶ つけてみてください。 半分ぐらいは、⾃信持って答えられないはずです。 本当にあった怖い回答： 「ウォーターフォールでもない、アジャイルでもない独⾃のプロセス」 「イテレーション⾵のプロセス」 29
27. Case2 静かすぎるオフィス 30 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
28. 【Case2】課題：静かすぎるオフィス 「ひとりひとりがスペシャリストであれ」という⽂化 各⾃が得意分野を持ち、1⼈ですすめることを良しとする 他メンバーとの交流少なく、フロアがびっくりするぐらい静か レビュー⽂化なし 31 エンジニアの「⼀蘭」化 https://www.getreadyhk.com/lifestyle/hot-pick-restaurants/item/451-ichiran-ramen
29. 【Case2】課題：いつも Mission: Impossible 32 Mission: Impossible (1996) - Close Call Scene (5/9) | Movieclips https://youtu.be/ar0xLps7WSY 個の限界にぶちあたる ü プロジェクト後半もずっと追加要求、仕様変更が発⽣する ü 機能開発とリリース済みのサポート対応の並⾏作業 ü リリース後に重篤なバグが⾒つかり、パッチリリースやリマスターの発⽣ ü 狭まるリリース間隔、増えるリリース回数
30. 【Case2】個⼈の総和が組織の能⼒にならない 33 “ある情報処理能⼒をもった1⼈の能⼒と⽐較して、同じ能⼒をもっ た10⼈の組織の情報処理能⼒では、単純計算では10倍の情報処理能 ⼒をもつはずです。しかし、実際にはそういった線形的に能⼒が増 えることはありません。⼈数が増えるほど、徐々にその想定とは乖 離していきます。” エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング（広⽊ ⼤地(著),技術評論社, 2018）
31. 【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⽇間、アリソ ンの⼼配をかなりエスカレートさせます。 サラは⼼配していましたが、結果が分からない 時間はかなり少なくなりました。”
32. 【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.” “プロセスはすべての組織の礎です。礎としてのプロセスが、組織が成すべきことを成す場 所なのです。フロー効率が⽣み出されるのはプロセスを通じてなのです。”
33. 【Case2】個の限界を突破するために • バックログやスプリントレビューに より透明性が確保し、合意形成や協 ⼒をしやすくする • スプリントプランニングで頻繁に計 画の⾒直しを⾏い、変更に対応する • フィードバックを得る機会（イベン ト）が、たくさんあり⽇々学習とカ イゼンが進む 36 チームで協⼒し、追加・変更に柔軟に対応する
34. 【Case2】コミュニケーションの活性化 • イベントを通じて（半ば強制的に）チームの対話が⽣まれる • ただし、スクラムを導⼊しただけでは⾃⼰組織化されない • 我々はチームの学習を⽀援し、カイゼンを助ける 37
35. 【Case2】個の限界を突破するために 1. Confluence/JIRAの活⽤ 2. ふりかえりの実施 3. カンバン・デイリーMtgの導⼊ 38 ⽂化として定着した
36. ぼやき：スクラムマスターの振る舞い 39 Super Scrum Master - the power of scrum- ⽇本語字幕版 https://youtu.be/NcWDx-XXISY スクラム界隈では有名なビデオ。スクラムマスターの１⽇を楽しく誇張し説明。 あるキックオフで、ウケ狙いでこのYoutubeを流した。 「⾼橋 ！！私 ⾔ ！！」 願 本気
37. Case3 要件の合意レベルが低い 40 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
38. 【Case3】課題：要件の合意レベルが低い • PdMの視点 • お客様の要望、ステークホルダーからの要望のすべてを把握している • 管理プロセスは明確ではなく、システム化もできていない • 複数のMy要望管理Excelが存在するプロダクトも… • 開発メンバーの視点 • PdMからは主に会議や⼝頭で要件が伝えられる • 決定事項のみで、「なぜ」がわからない • 担当者間で個別にやりとりされ全体像が⾒えない • ステークホルダーの視点 • リリース直前にならないと、⾃分たちの出した要望は実現されるのか不明 • 他にどんな要望が上がっているのか、開発チームが何を作ろうとしているのか全体 像が⾒えない 41 ソフトウェア黎明期から繰り返される、アレ…
39. 【Case3】課題：要件の合意レベルが低い 42 顧客が説明した要件 プロジェクトリーダの理解 アーキテクトの設計 プログラマの実装 ベータ版テスターの受難 営業の表現・約束 プロジェクトのドキュメント 実際の運⽤ 顧客への請求 得られたサポート 広告 顧客が本当に必要だったもの http://www.projectcartoon.com/
40. 【Case3】課題：要件の合意レベルが低い 43 ベータ版テスターの受難 営業の表現・約束 広告 顧客が本当に必要だったもの 戦 慄 ！ ﹁ 顧 客 が 本 当 に 必 要 だ た も の ﹂ 問 題
41. 【Case3】「要件管理」とは関係者が「合意」出来る仕組み • 混乱の過半数は「要件」に関するもの • 仕様モレ、誤解釈、無節操な仕様の変更… • 関係者全員で「要件管理」を維持しようと いう認識が不可⽋ • 仕様変更を発する可能性のある⼈全員に対して、 要件管理のトレーニングを実施すること • 組織の中で権限を有する者が、⾝勝⼿な要 件の変更を発することがある。 44 清⽔吉男さん(1949年4⽉18⽇ - 2017年11⽉22⽇) 要件を「合意」できるためには ü 要件を適切に仕様化する必要がある ü 仕様化の程度…“Specify(特定)”できる状態 ü 要件がレビュー可能であること
42. 【Case3】作りたいもの（仕様）はどう出てくるの？ 45 要求 仕様 背景 問題や課題 （なぜ実現してほしい のか＝理由） 実現してほしいこと （曖昧、抽象的） 特定された実現⽅法 （具体的な解決策）
43. 【Case3】作りたいもの（仕様）はどう出てくるの？ 46 要求 仕様 具体的な実現⽅法を考える • 漏れがないようにする • 実現可能か調べる • 曖昧さがないようにする 背景 どうすれば問題や課題が 解決できるか「理由」と 共に考える どうすれ ば問題や 課題が解 決できる か考える 具体的な 実現⽅法 を考える
44. 【Case3】ツールの適切なカスタマイズとプロセス運⽤ 1. SPAのバックログ作成 2. SPAの要望管理プロセス構 築(FY2015〜) 3. SVF Cloudの要望管理プロ セス構築 4. SPAのいろいろなJIRA統合 5. Motion Boardの要望管理 プロセス構築(FY2020〜) 47 • 関係者へのヒアリング、JIRAの構築、プロセスの構築、運 ⽤説明会、運⽤後までを担う • プロダクト横断で要望管理プロセスが揃いつつある
45. 【Case3】「要件管理」とは関係者が「合意」出来る仕組み 48 スクラムには要件を「合意」できる仕組みが巧みに組み込ま れている
46. Case4 ⽬的不明の会議＆⼈数が多すぎ 49 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
47. 【Case4】課題：⽬的不明の会議多すぎ＆⼈数多すぎ • 会議が多い • ⾊々ない • アジェンダがない • 決定事項がない • 次のアクションがない • 議事録がない • ⼈数が多い • 同じ部⾨から複数メンバーが参加 • 会議中に⼀回も発⾔しないひと、内職者多数 • みんないたほうが良い場（キックオフ、出荷承認会議）には主 要メンバーがいない 50 https://youtu.be/bQSQ009k4tE
48. 【Case4】そもそも会議とは何か？何をやっている？ • スクラムのイベントを思い出してみる • 開発系の会議ってこれらセレモニーをごった煮で「定例」と呼 んでいるだけでは？ 51
49. 【Case4】ファシリテーション視点の会議設計 52 株式会社エレクセ・パートナーズ 永禮 弘之さん ⼀⾒、簡易的なファシリテーション講 座に⾒えるが部⾨間連携や合意形成の ために、どう会議（討議）を設計し、 運⽤するかまで踏み込んだ充実のセミ ナー
50. 【Case4】コミュニケーション計画ベースの会議設計 • 社内で開催されている会議の4つの 分類で仕分け • 情報交換型 • 洗い出し型 • 分析・考察型 • 意思決定型 • ⽬的不明の会議と⽬的重複の会議を 淘汰し、必要最⼩限のものだけ運⽤ • 会議の関係と討議対象の情報（JIRA チケットなど）を整理し、グランド ルールと共にConfluenceで公開 53
51. 【Case4】しばらくすると、改善がまわりはじめる 1. 会議設計 2. 議事録⽂化の浸透 3. 事前のアジェンダ募集の浸透 4. タイムボックスの浸透 5. ファシリテーション/ グラ フィックファシリテーション の実践 54
52. 【Case4】しばらくすると、改善がまわりはじめる • グラフィックファシリテーション • 対話を⾒える化することで場の活性化や相互理解を促す 55
53. 【Case4】しばらくすると、改善がまわりはじめる • Lean Coffeeでのディスカッション • 事前準備なしのミーティング形式 • ミーティングのはじめに全員で話し 合いたいことを書き出し、投票等で 話し合う順番を決めます。 • １テーマにつき、7-8分のタイム ボックスを設定してディスカッショ ンを⾏います • 時間がきたら同じテーマでのディス カッションを継続するか、違うテー マに移動するかを全員で投票し、多 数決で決めます。 56 短時間でたくさんのテーマについてディスカッションできる https://youtu.be/-QuCbT0e34A
54. Case5 プロジェクトの始まりがない 57 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
55. 【Case5】課題：プロジェクトに始まりがない • 関係者の共通認識がないまま開発が進んでいく • 計画（という名のタスク⼀覧）はあるが、チーム外からは中⾝も状況もよくわからない • プロジェクト・プロダクトマネジメント教育がない • エンジニア出⾝のマネージャーほど、何をどうしたらよいかわからない 58 GOALも現在地もよくわからない…
56. 【Case5】プロダクトマネジメントを確⽴する • WAのプロダクト開発において、プロダクトマネジメント観点 の役割定義とマネジメント⼿法を確⽴する • 合わせて開発プロセスをよりアジャイル型へシフトさせる 59 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング（広⽊ ⼤地(著),技術評論社, 2018）
57. 【Case5】登⼭に似たソフトウェア開発がある 60
58. 【Case5】登⼭に似たソフトウェア開発がある 61 GOAL START 樹海
59. 【Case5】登⼭に似たソフトウェア開発がある 62 GOAL START • ゴールを⽬指す意思 • カイゼン活動 問題領域 問題領域
60. 【Case5】登⼭に似たソフトウェア開発がある 63 http://fujisan.rash.jp/2012/05/120524-4.html
61. 【Case5】ソフトウェア開発の本質 64 64 • リスク＝不確実性 リスクがある • 予期しない事態の発⽣（計画通りに⾏くことはない） 完全予測は不可能 • どれくらいのスピードで計画からずれているか 状況と変化を⾒据えた活動
62. 【Case5】プロダクトマネジメントの⽀援 • インセプション・デッキ作成 • 計画⽴案・更新 • リスクマネジメント • キックオフミーティングの浸透 • ステークホルダーマネジメント • 開発チームのチーム⼒向上 • プロジェクトの⽴て直し 65 計画を⽴てる、キックオフを するが「当たり前」になった
63. 【Case5】ナレッジサイトの構築 • WAの暗黙知を表出し、プロダクト毎にバラバラに形式知化されていたナ レッジを統合し、ナレッジサイトに蓄積する • エンジニアはナレッジサイトの知識を⾃分たちのプロダクト開発に再活⽤ し、実践・体験を通じて理解を深め、新たな知⾒(暗黙知)を得る • これがぐるぐるまわることで、エンジニアひとりひとりがキチンとした開 発⼿法を⼿に⼊れ、アジャイルなマインドセットも⾝に着けプロダクト開 発に反映する 66 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング（広⽊ ⼤地(著),技術評論社, 2018）
64. 【Case5】 DevOpsの構成要素CLAMSでカテゴライズ • Culture（⽂化）：コラボレーションコ ミュニケーションを加速させる • Lean（リーン）：無駄を減らし、早く リリース可能にする • Automation（⾃動化）：⼿作業をなく す • Measurement（測定）：計測し、デー タを活⽤する • Sharing（共有）：他者が学べるように 経験・ナレッジを共有する 67 約1年で58のナレッジと5つの動画を公開
65. Case6 仕事の流れを理解していない 68 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
66. 【Case6】課題：仕事の流れを理解していない • 部⾨や役割で分断されていて、プロジェクト開始されてからリ リースまでの全体の流れを理解している⼈がいない • この頃、我々は部⾨のSPIからプロダクト横断での活動にスケー ルしたが、各プロダクトの状況がわからない 69
67. • Value Stream Mapping • 全体像を理解して、カイゼンの最初の⼀歩を決める 【Case6】現状を⾒えるようにする 70 4. 未来のマップを実現する 3. 未来のマップを描く 2. ボトルネックを発⾒する 1. 現状のマップを描く ü最初のINPUTがなにかわからないまま 仕様が決定されている ü線がつながらない ü線がぐちゃぐちゃ ü出荷につながらない成果物が存在する ü複数で似て異なる成果物を作っている ü天の声が度々登場する
68. • Value Stream Mapping • 全体像を理解して、カイゼンの最初の⼀歩を決める 【Case6】現状を⾒えるようにする 71 4. 未来のマップを実現する 3. 未来のマップを描く 2. ボトルネックを発⾒する 1. 現状のマップを描く ü要望管理がされていない ü特定の⼈しかできない作業が明らかに なる üオンプレ・クラウドの連携部分の開発 プロセスが混沌としている
69. 72 少しずつボトルネックを解消中 【Case6】ワークの様⼦
70. Case7 作るものを⾒失う 73 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
71. 【Case7】課題：作るものを⾒失う • 新規開発で、POとの要件合意 レベルが低いまま進んでいき、 スプリントレビューではPOか らのNOが続く…. • メンバーの焦りだけが募り、 何を作るのか⾒失ったまま空 回りがつづく 74
72. 【Case7】ユーザーストーリーマッピング • 現状の⾒える化 • 要件の洗い出し • 要件の認識合わせ • 要件の⾒積もり • 今後の作業の優先順位決め • リリース計画 75
73. 76 • ⽴ち⽌まり、関係者間での対話を作り出す • 最初は時間かかるが、共通理解が⽣まれると前に進む 【Case7】ワークの様⼦
74. Case8 信頼ゼロからのプロセス改善 77 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
75. 【Case8】課題：信頼ゼロからのプロセス改善 • 2015年頃の開発チームは「プロセス」や「カイゼン」に馴染み がなかった • チームは「何か⾯倒くさいこといわれそう」、「仕事増えそ う」と不安に思っていた（と思う） • 信頼関係がない状態ではキョリをとられ、コンフリクトすら発 ⽣しない 78
76. 【Case8】 Leaders Effective Training（L.E.T） • 臨床⼼理学者トーマス・ゴードン博⼠が提唱す るゴードン・モデルを統合した、リーダーやマ ネジメントのための対⼈関係での効果的なコ ミュニケーションと他者と対⽴した場合の対⽴ 解決のためのスキルを実践形式で習得するワー クショップ*1) • ゴードン・モデル • 問題は⼈間関係の中で発⽣する。つまり、お互いのコ ミュニケーションの⽅法によって起こる。 • 相⼿の⾏動によって不都合や問題が⽣じた場合におい て、5つの主要なスキル「アクティブ・リスニング」 「対決的I-メッセージ」「ギア・シフト」「メソッド Ⅲ」「価値観の衝突のオプション」を⽤いることで直 ⾯している問題や状況を整理し、解決へと導く 79 *1) https://gordontraining.jp/ http://www.lc-t.jp/ Dr. Thomas Gordon
77. 80 信頼関係がない中のコミュニ ケーションにはとても有効 チームの価値観や考えを引き出す ことができる 【Case8】 ⼼理的なキョリを縮める
78. Case9 エンゲージメントが低い 81 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
79. エンゲージメントとは 「ここで働き続ける理由」 82
80. 【Case9】エンゲージメントとは • 従業員満⾜度 • 職場環境や給与、福利厚⽣など への満⾜度＝組織が与えるもの • モチベーション • ⾏動を起こすための動機＝個⼈ が感じるもの • ロイヤルティ • 組織に対する帰属意識、忠誠⼼ ＝上下関係が⽣み出すもの • エンゲージメント • 主体的・意欲的に取り組んでい る状態＝相互の対等な関係に基 づくもの 83 引⽤元：組織は「⾔葉」から変わる。ストーリーでわかるエンゲージメント⼊⾨ ⿊⽥ 天兵 (著)朝⽇新聞出版 (2020/2/20)
81. 【Case9】エンゲージメント 84 引⽤元：組織は「⾔葉」から変わる。ストーリーでわかるエンゲージメント⼊⾨ ⿊⽥ 天兵 (著)朝⽇新聞出版 (2020/2/20)
82. 【Case9】 SPQI の平均スコア変移 85 74 2018/11 就任 63 ★2019.11 組織変更 64
83. 【Case9】仮説と実験 • 「64」という数字がいったい何をを表しているのか、このとき は正直さっぱりわからなかった • 就任したてなこともあり、まずは以下の施策に注⼒した • まず、⾃分を知ってもらう • みんなを知る（リーダーズ・アクライメーション実施） • GMGの⼒量を測り、育成を開始 • 1on1が⼀度も⾏われていなかったので、週次で開催 • 単純に「残業が多い」と怒られていたので、 働き⽅の分析を⾏った 86 リーダーズアクライメーションの⾵景
84. 【Case9】残業バランスから⾒える組織の問題 残業⿇痺ライン ＝45〜60h 「認知の歪み」ゾーン
85. 【Case9】 SPQI の平均スコア変移 88 74 2018/11 就任 63 ★2019.11 組織変更
86. 【Case9】仮説と実験 • 1ポイント下がった「63」になってしまった。 • 正直「うっ」とはなったが、実際エンゲージメントを⾼める施 策は「何もしていない」のでスコアが上がるはずもないと考え 直した。 • 前期の調査でわかったこと • 部としての⼀体感がまったくない。 • 部としての⽬標もない（のろしは上がっても⾃分ごとではない） • QAという、おなじ知識・技術ドメインの仕事をしているにも関わらず、 グループ同⼠（GMG同⼠）の関わりがまったくない。ので、技術の流 通もない。（すべては、前任のBOSSを通さないとダメだった） • とりあえず、上記をカイゼンするだけでもスコアはあがるので はないか？ 89
87. 【Case9】合宿をやった
88. 【Case9】合宿をやった • ⾃分たちで、組織⽬標を考える（ワールドカフェ） ① 強いQAチームを作るには ② プロダクト連携時代のQAとは ③ クラウドファースト時代のQAとは ④ QAとしてやりたいこと • メンバー全員に「パフォーマンス⽬標」を⽴ててもらった • http://nexcf.1stg.local/pages/viewpage.action?pageId=103172393 • このときの様⼦はブログに書いています • The New Normal https://link.medium.com/NgDNtq7VZ7 91
89. 【Case9】合宿！その時荒川は。 92 マネージャー陣の狙いなどお構いなしに初の札幌をおおいに楽しむ ワーク楽しい あの公園 夜パフェ セコマ ※合宿も真⾯⽬に取り組みました（次ページ）
90. 【Case9】合宿で起きた変化 93 ・OKRで ⾃分の⽬標出し ・ムービングモチベーターズ ・ワールドカフェ 「強いQAチームとは」etc. ・モチベーショングラフ ・ワールドカフェ 「組織⽬標」 他律的 ⾃律的 ⾃分は何に喜びを感じるのか ⾃分たちはどうありたいか ⾃分はどうありたいか DAY1のワーク DAY2のワーク
91. 【Case9】合宿で起きた変化 94 部の仲間が⾃発的に⾃⼰の⽬標設定を⾏った
92. 【Case9】 SPQI の平均スコア変移 95 74 2018/11 就任 63 ★2019.11 組織変更 71
93. 【Case9】仮説と実験 • スコアが「71」にジャンプアップ！しかし… • 新しい「部⾨⽬標」に沿った活動をするメンバーと、従来のやり⽅を 変えないメンバーがはっきりと⾒えてきた（スコア分布が歪） • 相変わらず、残業時間が多いメンバーが変わらない （特にグループマネジャー） • エンゲージメントも、極端にスコアが⾼いグループがある。だが良い 取り組みをしているわけではなく「アドレナリン・ジャンキー」的な 雰囲気が漂っている。 • やったこと • 残業多いひとへの業務カイゼン指⽰ • 組織変更をした 96
94. 【Case9】 SPQI の平均スコア変移 97 74 2018/11 就任 63 ★2019.11 組織変更 71 67
95. 【Case9】仮説と実験 • スコアが「67」に下がる • 前期⾼かったグループが、逆張りの急降下 • 開発部⾨との関係性低下 • 仕事を指⽰され、こなすだけ…の傾向が強いグループは、開発側の状 況に多⼤な影響を受ける • マネジメントラインを⾒直して、組織⽬標を⾃律して具現化す るライン構築を⽬指した • ⼀部のメンバーからは、猛反発があった • 丁寧に向き合ったつもり • 他部⾨のマネジャーからクレームもあったが、丁寧に説明して理解を 得た 98
96. 【Case9】 SPQI の平均スコア変移 99 74 2018/11 就任 63 ★2019.11 組織変更 71 67 72
97. 【Case9】仮説と検証 • 「72」に復活した。最新は「76」 • 組織変更で⼀部の反発が強かったものの、新体制のチームビル ディングを経て、各グループのエンゲージメントスコアは総じ てアップした。 • 全体的な底上げを⽬指し、SPQI部へのインナーブランディング を開始した。 • 「⾔葉づくり」を丁寧に • 企業レベルのMission、Vision、Valueを部⾨やチームレベルに落とし込む作業が 割とむずかしい件・後編 • https://link.medium.com/OYSo7s1VZ7 • 全員でOKRを利⽤した⽬標管理 • ブログによる発信を推奨（部⻑が率先して） • 定⽯集の「GROW」サイト⽴ち上げ 100
98. 101 【Case9】OKRでやり遂げる⽬標を⽴てる OKRの筆者Christina Wodtkeは、⽴てた⽬標などを 「 なぜ、やり遂げることができないのか」について • ゴールに優先順位を付けていない • 熱意を持って漏れなくゴールを伝えていない • やり遂げるためのプランがない • 重要事項のための時間を空けていない • 繰り返さずにやめてしまう
99. 102 【Case9】OKRでやり遂げる⽬標を⽴てる • じぶん戦略を考え⽬標を達成する。パ フォーマンス⽬標とも⾔います • アジャイルで良く使われている 「ユーザーストーリー」で書けます。 • 「誰」や役割（〜として）、 • 「何」やアクション（〜したい）、 • 「なぜ」やビジネスのメリット（そ れは〜のためだ） • Acceptance Criteria には何をすれば⽬標 に近づけるかを書きます KR O(Objective)
100. 【Case9】OKRでやり遂げる⽬標を⽴てる • 部下の⽬標（四半期ごと）をコミッ トさせ、後押しする。 （⾦、アサインメント） • フィードバックする。 • 達成に障害があったら取り除く。 • ↑ これを毎週1on1で実施する。 ※ 1on1（週次）は「雑談ツール」で はなく「⽀援ツール」 • ⽴てた⽬標（四半期ごと）をやり遂 げられたか？は、わかりやすい評価 要素となる。 103
101. 【Case9】最新のエンゲージメント 104
102. Case10 ⾃動テストがない 105 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
103. 【Case10】課題：⻑きに渡る⼿動時代の泰平（泰平していない） • 下流での⼿動テストのみが品質に向き合う時間 106 「今⽇ビルドされてテスト開始する予定だったけどビルド遅れそうだってさ」 「ま、しょうがないよね。開発だって頑張ってるし」 〜数⽇後〜 「上⻑さんすみません。休⽇出勤申請出します」 • ストップウォッチ⽚⼿に性能測定 「（ボタンをクリック）えいっカチっ！（画⾯が表⽰された）えいっカチっ！」 QA⻑時間労働 ストレスフルな仕事の結果、品質も上がらずバグは市場に流出 https://youtu.be/mS7O4oawVMo
104. 【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 ⾃動と⼿動 ⾃動 ⼿動 ツール 製品を批評する
105. 【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
106. 【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
107. 【Case10】Automationチーム 荒川のアプローチ 110 まだまだ少ない機会の中、前期の1年間で数プロダクトの ⾃動テストが稼働開始した。 開発とコラボ！ 学びを⽌めない！ ⾃動テストの損益分岐点 「何が起きるのが嫌ですか？」 Dev + QA はじめの⼀歩はベイビーステップ 開発との コラボレーション アプローチ Collaboration with developer ターゲットを限定 型にこだわりすぎない ⾃動化のハードルを下げる テーマ
108. クライアント クライアント インターネット サーバー ⾃動テストが実装できる箇所はたくさんある 全部やりたいのはヤマヤマだが・・・ 【Case10】「何が起きるのが嫌ですか？」
109. 「新しいビルドで、画⾯が崩れたり、 ボタンが押せなくなったりすることがイヤ。」 【Case10】「何が起きるのが嫌ですか？」
110. 「じゃあ、今回はここのテストをしましょう。」 実現可能で意味のあるテストを特定し ツールやフレームワークを選定する 【Case10】「何が起きるのが嫌ですか？」 クライアント クライアント インターネット サーバー
111. 【Case10】はじめの⼀歩はベイビーステップ 完璧を⽬指さず、まず⼩さな⼀歩を踏み出すことが重要 そして半歩半歩でも⼩さなステップを積み重ねていくことを考える いやUIレイヤーが ⼤きくたっていい︕ そこから醸成された習慣・⽂化が最適なものに向かっていく 意味のあるものであれば原理原則にとらわれすぎない
112. 【Case10】⾃動テストの損益分岐点 115 https://www.amazon.co.jp/dp/B006RUFM5A/ref=cm_sw_r_tw_dp_x_s9nMFb3XDQK1W ⾃動化に対する考え⽅のハードルを下げる およそ4回の実施で、 ⼿動テストと⾃動テストの コストが逆転する。
113. 【Case10】そして⼤切にしていること 116 開発と同じ⾔語・⽂脈で話せること Dev + QA DevOpsを志向してSET的な動きをするのであれば、 DevとQAのスキル範囲はシームレスな状態を⽬指すべき 学習・研鑽を続ける
114. 【Case10】活動の経過 117 E2E⾃動テストが4プロダクト あるE2E⾃動テストの効果 CIサイクルに組み込んたWebAPI⾃動 テストが1プロダクトで動作中 他にも、 開発に代わって⼀部ユニットテストも 書いてみた ストップウォッチ体制も無事脱却
115. Case11 外部研修が歓迎・奨励されない 118 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
116. 【Case11】課題：外に出ていかないエンジニア ・外部研修があまり歓迎されない空気感 1⽇かかる研修は、 「実業務のリソースー1⽇」 という⽂化・空気感 休⽇の研修参加 ＝業務扱い ＝代休取得が必要 ＝1⽇⽳を空ける ＝周りが困る ・⼈材育成のための予算を計上していない部⾨がおおい ・エンジニアが常に忙しい
117. 【Case11】なぜ、予算がないのか？ 120 ᶄݱঢ় ᶃ7JTJPO ʢͳΓ͍ͨ࢟ ᶅΪϟοϓΛղফ͢Δํ๏ Ϊϟοϓ ઓུɾઓज़ ༧ࢉ
118. 【Case11】研修を企画する 1. スキルマップを作成する • ⾃⾝やメンバーの強化したいスキルを明確にする 2. 情報収集 • トレーニング、研修、カンファレンスの選定・予算計上 • ときには、開発チームの分も計上 3. 社外から講師を招いて集合研修を企画する • 部⾨の集合研修を企画・実施（FY2016-FY2018） • 開発や他部⾨も巻き込んで研修やトレーニングを実施（FY2019〜） • 企画書、集客、運営、事後アンケートなど裏⽅作業全般を担当 4. 開発職新⼈研修を企画・実施する • 新⼈が各部⾨で数週間ずつ研修を⾏う 121 • 他部⾨から集合研修⼀緒にやろうって声をかけられる • 新⼈研修のリクエストをいただく
119. 【Case11】SPQI 発⾜後 122 周りも少し変わってきた 「研修？いってこい！」 「イベント？いってこい！」 「⾦は出す！」 認定や トレーニング ブログ 外部発表 ブログなどで社内展開 外部イベントで発表 部内の研鑽⽂化の向上を⽬論む 部内の研鑽⽂化は根付きつつある
120. Case12 マイクロマネジメント 123 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
121. 【Case12】課題：官僚型の組織 指 揮 命 令 報 告 指示待ち 抱え込み 無茶な指示 指示がないから帰る… やらされ感 フォロー不足 つまらない 恐れと非難 細かい指示 部下が不安 全ての報告を求める 時間がない 苦しい 思考停止 BOSS
122. 【Case12】官僚型から⾃⼰組織化へ 指 揮 命 令 報 告 指示待ち 抱え込み 無茶な指示 指示がないから帰る… やらされ感 フォロー不足 つまらない 恐れと非難 細かい指示 部下が不安 全ての報告を求める 時間がない 苦しい 思考停止 ⾃⼰組織化 ⾃⼰組織化が進むと、チーム の問題を⾃分ごととして捉え ることができるようになりま す 明確なゴールと目標 モチベーションの理解 よく考える 積極的 自分たちで決める ナレッジの整備 エスカレーション ふりかえり 適切な権限移譲 Build the Trust フィードバック BOSS
123. 【Case12】バランスの両⽴ 階層型 ネットワーク型 バランス （両⽴） 特化（専⾨化） 効率性（予測可能で安定） 集中化（無駄・コスト低下） 活⽤ 汎化（イノベーション） 有効性（複雑で変化が早い） 分権化（意思決定が迅速） 探索
124. 【Case12】課題：権⼒の象徴＝情報 BOSS すべての情報 はワシを通す のじゃ！
125. 【Case12】コミュニケーションの複雑性 • ⼈数が増えるとコミュニケーショ ンのオー バーヘッドが増えます。 • そこで規模拡⼤が必要な場合、チーム内の ⼈数を増やすのではなくチームの数を増や すほうが良いとされています。 • なぜなら、全員が知っている状態が作りや すいので、たとえ全員が同じ場所にいなく ても同じ情報を知っているならだいたい同 じ判断が下せるからです。 • これが意思決定のスピードアップにつなが ります。 • この図をみると、せいぜい5⼈ぐらいが限 度に⾒えます。 https://churchhealthwiki.wordpress.com/2015/07/05/teamwork-the-rapid-complexity- that-arises-when-your-team-or-small-group-exceeds-10-people/ コミュニケーションパスの 複雑性をなるべく最⼩に
126. 【Case12】メドラーズゲーム 129 https://management30.com/practice/meddlers/ 現メンバーを活⽤しどういった組織を作るか、⼈数のバラン スをどうするかなどをシミュレーション
127. 【Case12】組織改⾰のポイント 130 a. 組織のMissionを⾃分の⾔葉として語れるリーダーを配置する b. マイクロマネジメントから卒業しリーダーにはメンバー育成を期待する c. カルチャーバブルを発展できるリーダーを⾒極めバランスよく配置する d. 1つのチームはなるべく5⼈以下とする e. チーム内の個⼈スキルが偏らないようにする。 f. 困難に⽴ち向かい成⻑できるレジリエントな組織体制を⽬指す g. リエゾンタイプの⼈材を⾒極め、組織の潤滑油とする h. 経営陣からの期待と部⾨Missionの実現にコミットする
128. 【Case12】成⻑志向か？ • メタスキル習得の⼤部分は「⾃分の仕事経験」といえる。 • では、仕事で経験して学びを得るとは？ • 部下がチャレンジしたい仕事をアサインしてあげることが⼤事。 これは上司にしか出来ない。 131 優れたマネジャーを調査したところ、成⼈の学びとは― 70% ⾃分の仕事経験から 20% 他者の観察やアドバイスから 10% 本を読んだり研修を受けたりすることから ーから得ている マイケル・ロンバルド&ロバート・アイチンガー Career Architect Development Planner, 5th Edition - 2010
129. 【Case12】 Certified Agile Leadership(CAL1) • ハイパフォーマンスな組織に成⻑するためのリーダーシップモデルを学ぶ • 組織カルチャーが変わるとき、構造と意識の両⽅が変わる • カルチャー （カルチャーバブル）を作るのはリーダーであり、リーダー ⾃⾝が⾃分のマインド、振る舞いから変える。そうしていけば周りもよい 影響を受ける • https://shift314.com/certified-agile-leadership-training-cal-1/ 132 https://medium.com/wingarc/50f550e675b2
130. 【Case12】Management3.0 • 複雑な状況において有効なマネジメントを学び、メンバーを⾃⼰組織化に 導く。楽しく論理的なプラクティスが多数。 • ムービングモチベーターズ • メンバーのやる気スイッチを知れば、やる気すいっちがONになる働きかけ⽅ができ るようになる。何より考え、価値観をしれて楽しい。 • デリゲーションポーカー • チームの仕事の種類と意思決定の権限委譲レベルを明確にする • 「上司がやってくれるはず」、 「チームに任せた！(けどできてないじゃん…)」 といった思い込みやすれ違いをなくし、⾃律的に動きやすくなる 133
131. 【Case12】反射関係における権限委譲 134
132. 【Case12】ワークで起きた変化・気づいた効果 135 期待される ゴールの 明確化 WHAT：明確 HOW：委譲 セルフ マネジメント 信頼に 応えたいという モチベーション これらの要素は、約２年後に突如始まる フルリモートワーク体制へのスムーズな移⾏ にも深く影響を与える デリゲーション ポーカー チームの⽅向性と個⼈の役割が明確に 意思決定のスピードアップ 個⼈のモチベーション向上
133. Case13 QAがボトルネック 136 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
134. 【Case13】課題： QAが出荷のボトルネックと思われている 137 ゲートキーパー型QA
135. 【Case13】課題： QAが出荷のボトルネックと思われている 138 分析 開発 テス ト QA/デプロイ バグ検出数が⽢いから 品質が上がらないんだ テストやりすぎてるん じゃないの？ 実装が⼤変だがら テストしてるヒマがない Dev Ops
136. 【Case13】課題： QAが出荷のボトルネックと（まだ）思われている 139 我々のスループットを増やす努⼒は続けるが… …もっと、Dev⼯程の問題を解決する必要がある ü 計画を変えないか、そもそもない ü 仕様がない ü Dev⼯程のテストが⾜りてない ü Dev⼯程の遅れで時間が無くなる 引⽤：⻄村直⼈,⾓⾕信太郎. アジャイルサムライ達⼈開発者への道
137. 【Case13】戦術：シフト・レフト、シフト・ライト 計画 実装 ビルド テスト リリース デプロイ 運⽤ Shift Left Testing Shift Right Testing シフト・ライト・テスト • 運⽤中にもテストを⾏い品質を監視するとで常に 品質を保証し続ける サポート情報分析によるフロントローディング 分析してパターン化して再利⽤して開発を成⻑させる シフト・レフト・テスト • ライフサイクルの早い段階でテストを開始できる • 開発完了後に⾏っているテスト実⾏を、もっと早 い段階でかつ⾃動的に継続的に実施する • 早い段階でテストを実⾏するために、コンポーネ ントがそろわない状況でもE2Eテストを実⾏でき るようにする • GUI経由の機能テストをAPIレベルで⾏うテストが 実⾏できるようにする
138. 【Case13】現状の共通認識を促す 141 開発とコラボ！ 学びを⽌めない！ 現状の共通認識を促す 施策1 「QAがボトルネックと思われている」 「テストで品質は上がらない」 「開発とQAに溝がある」 をはっきりと繰り返し、告げられ共通認識になる
139. 【Case13】グループ⽬標の⽴案 開発とコラボ！ 学びを⽌めない！ 部⾨⽬標の達成につながるグループ⽬標の⽴案 施策2 部⾨⽬標の達成につながるグループ⽬標の⽴案 シフト・レフト・テスティング、開発との融合を促進する
140. 【Case13】QA・AutomationTとの連携 143 プロセス改善活動 要件管理プロセス構築、プロジェクト計画⽴案・更新サ ポート、リスク管理・追跡サポート、チームビルディング、 ふりかえり 施策3
141. 【Case13】兼務の強み 各プロダクトの PdM・開発チーム 課題発⾒ SPI活動（課題発⾒のトリガー）： ・チームビルディング、ふりかえり SPI 内藤・荒川 実⾏フェーズへ カイゼンポイント発⾒フェーズ N A 課題分析 施策検討
142. 【Case13】兼務の強み コラボレーション アフィニティ 実⾏フェーズ or ＋ SPI N A QA A Automaiton A 打ち⼿の選択肢の拡張 施策開始までのスピード向上 各プロダクトの PdM・開発チーム
143. 【Case13】現在 146 ・SPQI部に共通認識が⽣まれる ・共通認識を持つことで進む⽅向が決まり、⾏動できる ・開発・QAの対話が増え、相互理解が進む
144. Case14 Mission・ Vision・ Value が浸透していない 147 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
145. 【Case14】課題：Mission・ Vision・ Value が浸透していない • ⼈は何か困難に出会ったとき、なんらかの「判断」を下してい る。組織の場合、その判断の礎はMission・ Vision・ Valueであ るべきだ。これが無いと、スピードが遅くなったり間違った⽅ 向へ進んでしまう。 • ところが、ハイパフォーマーが必ずしも企業⽂化を理解しているとは 限らない 148
146. 【Case14】コアバリュー・セッション 149
147. 【Case14】課題：Mission・ Vision・ Value が浸透していない • 組織の末端まで浸透しているとは限らない… 150
148. 3. 社会に提供する価値 2. なりたい 姿 【Case14】⾔葉を分類するためのフレームワーク 社会の未来像 4. 顧客に約束する価値提供 5. 戦略、戦術 6. 理想的な⾏動 7. ⼤切にしたい価値観、⽂化、強み 1. 現状 (外部・内 部の環境) 組織は「⾔葉」から変わる。ストー リーでわかるエンゲージメント⼊⾨ ⿊ ⽥ 天兵 (著)朝⽇新聞出版 (2020/2/20)
149. 3. 社会に提供する価値 2. なりたい 姿 【Case14】⾔葉を分類するためのフレームワーク 社会の未来像 4. 顧客に約束する価値提供 5. 戦略、戦術 6. 理想的な⾏動 7. ⼤切にしたい価値観、⽂化、強み 1. 現状 (外部・内 部の環境) Vision Mission Value Employee Principles WHY
150. 【Case14】たぶん認知は上がっている 153
151. 未来へ そして⼈⽣はつづく 154 FY2013 FY2014 FY2015 FY2016 FY2017 FY2018 FY2019 FY2020
152. 【未来へ】内藤靖⼦の決意 • まわりを変えたかったらまずは⾃ 分が実践する • 数年間の活動を経て、カルチャーバブ ルは確実に広がっている • フィードバックを得ること、受け ⽌めて変わリ続ける • ⾼橋さんは私たちのよきコーチ • 私も誰かのよきコーチになれるように 励みます 155
153. 【未来へ】荒川健太郎の「⼈⽣はつづく」 156 2年 8年 でも、 少しづつ 変わってきてる なかなか うまくいかない 銀の弾丸 なんてない まだ DEV QA 終わりのない 学び ⽂化を変えるのは 終わりのない 営み 毎⽇何か動いていこう！
154. 【未来へ】⾼橋裕之の覚悟 157 “今ある仕事の「壁」から逃げるな。 逃げ癖が付くと、⼈⽣に⽴ちはだかる「壁」も越えられな くなる。仕事に⽐べたら⼈⽣の「壁」の⽅が何倍も⾼い” 清⽔吉男
155. まとめ 「⽂化的負債」の利息を解消するには、 「ソフトウェアプロセス改善」 (Software Process Improvement, SPI) というアプローチが⼤事。 「プロセス」で解決しよう！ 158
156. ͝ਗ਼ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ʂ 159