$30 off During Our Annual Pro Sale. View Details »

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

Hiroyuki TAKAHASHI
April 15, 2021
9.9k

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

Hiroyuki TAKAHASHI

April 15, 2021
Tweet

More Decks by Hiroyuki TAKAHASHI

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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 よろしくおねがいします

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  11. ⽼舗
    13

    View Slide

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

    View Slide

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

    View Slide

  14. ⽼舗
    16
    प೥
    प೥
    प೥
    प೥

    View Slide

  15. ⽼舗 → Cloudにシフト
    17
    प೥
    प೥
    प೥
    प೥
    ほとんどの
    プロダクト

    クラウド
    サービス化

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  21. 【Case1】課題:進まないプロセス改善
    私が⼊社したのは2013年3⽉であったが、2011年ごろからBOSS
    は、開発⼦会社に対し標準プロセスを制定しようと奮闘していた。

    ⼦会社の反応
    「複雑すぎてめんどくさい」「スピードが遅くなる」
    「今とくに問題ない」

    2年経ってもまったく「標準プロセス」なんてなかった
    23
    「なぜ?」それをやるのか、が説明不⾜
    作ってある資料は「こうあるべき」なものばかり
    現場エンジニアとの⼤きな乖離(よくある)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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⽇間、アリソ
    ンの⼼配をかなりエスカレートさせます。 サラは⼼配していましたが、結果が分からない
    時間はかなり少なくなりました。”

    View Slide

  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.”
    “プロセスはすべての組織の礎です。礎としてのプロセスが、組織が成すべきことを成す場
    所なのです。フロー効率が⽣み出されるのはプロセスを通じてなのです。”

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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



















    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  64. 【Case5】 DevOpsの構成要素CLAMSでカテゴライズ
    • Culture(⽂化):コラボレーションコ
    ミュニケーションを加速させる
    • Lean(リーン):無駄を減らし、早く
    リリース可能にする
    • Automation(⾃動化):⼿作業をなく

    • Measurement(測定):計測し、デー
    タを活⽤する
    • Sharing(共有):他者が学べるように
    経験・ナレッジを共有する
    67
    約1年で58のナレッジと5つの動画を公開

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  87. 【Case9】合宿をやった

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  100. 【Case9】OKRでやり遂げる⽬標を⽴てる
    • 部下の⽬標(四半期ごと)をコミッ
    トさせ、後押しする。
    (⾦、アサインメント)
    • フィードバックする。
    • 達成に障害があったら取り除く。
    • ↑ これを毎週1on1で実施する。

    1on1(週次)は「雑談ツール」で
    はなく「⽀援ツール」
    • ⽴てた⽬標(四半期ごと)をやり遂
    げられたか?は、わかりやすい評価
    要素となる。
    103

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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
    ⾃動と⼿動
    ⾃動
    ⼿動
    ツール
    製品を批評する

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  117. 【Case11】なぜ、予算がないのか?
    120
    ᶄݱঢ় ᶃ7JTJPO
    ʢͳΓ͍ͨ࢟

    ᶅΪϟοϓΛղফ͢Δํ๏
    Ϊϟοϓ
    ઓུɾઓज़
    ༧ࢉ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  121. 【Case12】課題:官僚型の組織






    指示待ち
    抱え込み
    無茶な指示
    指示がないから帰る…
    やらされ感
    フォロー不足
    つまらない
    恐れと非難
    細かい指示
    部下が不安
    全ての報告を求める
    時間がない
    苦しい
    思考停止
    BOSS

    View Slide

  122. 【Case12】官僚型から⾃⼰組織化へ






    指示待ち
    抱え込み
    無茶な指示
    指示がないから帰る…
    やらされ感
    フォロー不足
    つまらない
    恐れと非難
    細かい指示
    部下が不安
    全ての報告を求める
    時間がない
    苦しい
    思考停止
    ⾃⼰組織化
    ⾃⼰組織化が進むと、チーム
    の問題を⾃分ごととして捉え
    ることができるようになりま

    明確なゴールと目標
    モチベーションの理解 よく考える
    積極的
    自分たちで決める
    ナレッジの整備
    エスカレーション
    ふりかえり
    適切な権限移譲
    Build the Trust
    フィードバック
    BOSS

    View Slide

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

    View Slide

  124. 【Case12】課題:権⼒の象徴=情報
    BOSS
    すべての情報
    はワシを通す
    のじゃ!

    View Slide

  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/
    コミュニケーションパスの
    複雑性をなるべく最⼩に

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  135. 【Case13】課題: QAが出荷のボトルネックと思われている
    138
    分析 開発
    テス

    QA/デプロイ
    バグ検出数が⽢いから
    品質が上がらないんだ
    テストやりすぎてるん
    じゃないの?
    実装が⼤変だがら
    テストしてるヒマがない
    Dev Ops

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  142. 【Case13】兼務の強み
    コラボレーション
    アフィニティ
    実⾏フェーズ
    or

    SPI
    N A
    QA
    A
    Automaiton
    A
    打ち⼿の選択肢の拡張
    施策開始までのスピード向上
    各プロダクトの
    PdM・開発チーム

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide