Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Hiroyuki TAKAHASHI
April 15, 2021
10k

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

Hiroyuki TAKAHASHI

April 15, 2021
Tweet

More Decks by Hiroyuki TAKAHASHI

Transcript

  1. 本⽇、お伝えすること 我々は、⽼舗ソフトウェア開発会社で溜まっていた「⽂化的負債」の利息 を解消すべく、 「ソフトウェアプロセス改善」(Software Process Improvement, SPI) というアプローチを取ってきました。 と⾔っても、CMMIとかPMBOKとかSAFeとか……デッカイ何かを導⼊して 苦労した話しではありません。

    現場で起きるひとつひとつの問題や課題に向き合いながら 「プロセス」で解決しよう! という発想を⼤事にしてきました。 これまでの8年間で得た経験と学びについてのストーリーを発表者3⼈で紡 ぎたいと思います。 2
  2. はじめに:⽂化的負債とは 技術的負債 • システム設計、ソフトウェアアーキ テクチャー、ソフトウェア開発、技 術の選択などの技術的な決定が最終 的に⽣み出すもののこと ⽂化的負債 • 採⽤や解雇の決定、コミュニティの

    基準の制定や施⾏、組織の階層構造、 価値観といった⽂化的な決定が最終 的に⽣み出しているもののこと 3 “いつか返済しなければいけないし、負債の原因となっ ている問題を⻑期に渡って⼿付かずにしていればいるほ ど、利息が蓄積して、将来負債から抜け出すことが難し くなる” Effective DevOps ―4本柱による持続可能な組織⽂化の育て⽅( Jennifer Davis (著), Ryn Daniels (著), 吉⽻ ⿓太郎 (監訳), ⻑尾 ⾼弘 (訳), オライリー・ジャパン, 2018)
  3. キラキラしたDevOpsではなく、⽣々しいストーリー • 複数⼈で対話したり、教え合ったりすることを⼤切にしながら、特定の結果に向かってものを 作っていくプロセス コラボレーション • チーム間の関係を構築し、組織の共通⽬標を念頭に置いて個々のチーム⽬標の違いを乗り越え、 共感を育て、他のチームの⼈たちからも学習するプロセス アフィニティ •

    加速装置 • ただし、価値、規範、組織構造の問題点をきちんと検証できていないと、⽂化的な負債が増え るうちに、⽬に⾒えないエラー要因を⽣み出す ツール • 企業がライフサイクルを通じて発展、成⻑、進化すること • 組織の規模が異なれば、技術的にも⽂化的にも考慮すべきことは違ってくる スケーリング 4 Effective DevOps ―4本柱による持続可能な組織⽂化の育て⽅( Jennifer Davis (著), Ryn Daniels (著), 吉⽻ ⿓太郎 (監訳), ⻑尾 ⾼弘 (訳), オライリー・ジャパン, 2018)
  4. ⾼橋裕之 / 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 年オライリー)」
  5. 6 内藤 靖⼦ / SPQI部SPI G グループマネージャ l ソフトウェア業界21年⽬、千葉県⽣まれの射⼿座 l

    組込みエンジニアとしてプリンタドライバ開発、コンシュー マー向けデジタルカメラ・カムコーダー開発を経て、SEPG、 PMOに従事。 l ウイングアーク1stには2015年8⽉⼊社(5年8ヶ⽉) l ソフトウェアプロセス改善エンジニア、アジャイルコーチ l CSM(認定スクラムマスター) l A-CSM(アドバンスド認定スクラムマスター) l CSPO(認定スクラムプロダクトオーナー)
  6. 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 よろしくおねがいします
  7. 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
  8. 【Case1】イワン・マルコム博⼠のカオス理論 22 Jurassic Park (1993) - Chaos Theory Scene (2/10)

    | Movieclips https://youtu.be/n-mpifTiPV4 「しかしきみは、島をよくみたことがないじゃない か。われわれの設備をみてもいないじゃないか」 「たしかに。だが、⾒るまでもないんだよ。ディ ティールは関係ない。カオス理論によれば、この島 の予測不可能性は急速に進んでいく」 ジュラシック・パーク(上)マイクル・クライトン(著)酒井昭伸(訳)
  9. 【Case1】そもそも何を改善したいのか? • プロセス改善とは、 1. 個⼈の習慣を変えること 2. 組織の⽂化を変えること • 個⼈の習慣… •

    習慣として⾝についたものを、 PFDを使って変化させ、 シミュレーションで安定させる • 組織の⽂化… • 組織習慣の変化と継続を仕掛けることで組織の⽂化を変える • 褒める習慣の定着を図る • コミットメントの実現 24 清⽔吉男さん(1949年4⽉18⽇ - 2017年11⽉22⽇) 個⼈も組織も変化に強くする
  10. ぼやき:「プロセスやツールよりも個⼈と対話を」で失ったモノ “Manifesto for Agile Software Development”には共感してます。 ツールの話しばっかりするのもどうかと思います。 でもね?マニフェストに出てくる「プロセス」とは「形骸化したプロセス」や「考え なしに持ってきたフレームワーク」だと思うんです。 個⼈の対話と同じぐらいプロセスも⼤事です。

    なのに「プロセス」がかっこ悪い・タブーな⾵潮出来ちゃってますよね。 試しに、いま現役エンジニアに「いまどんなプロセスでモノ作ってんの?」て質問ぶ つけてみてください。 半分ぐらいは、⾃信持って答えられないはずです。 本当にあった怖い回答: 「ウォーターフォールでもない、アジャイルでもない独⾃のプロセス」 「イテレーション⾵のプロセス」 29
  11. 【Case2】課題:いつも Mission: Impossible 32 Mission: Impossible (1996) - Close Call

    Scene (5/9) | Movieclips https://youtu.be/ar0xLps7WSY 個の限界にぶちあたる ü プロジェクト後半もずっと追加要求、仕様変更が発⽣する ü 機能開発とリリース済みのサポート対応の並⾏作業 ü リリース後に重篤なバグが⾒つかり、パッチリリースやリマスターの発⽣ ü 狭まるリリース間隔、増えるリリース回数
  12. 【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⽇間、アリソ ンの⼼配をかなりエスカレートさせます。 サラは⼼配していましたが、結果が分からない 時間はかなり少なくなりました。”
  13. 【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.” “プロセスはすべての組織の礎です。礎としてのプロセスが、組織が成すべきことを成す場 所なのです。フロー効率が⽣み出されるのはプロセスを通じてなのです。”
  14. ぼやき:スクラムマスターの振る舞い 39 Super Scrum Master - the power of scrum-

    ⽇本語字幕版 https://youtu.be/NcWDx-XXISY スクラム界隈では有名なビデオ。スクラムマスターの1⽇を楽しく誇張し説明。 あるキックオフで、ウケ狙いでこのYoutubeを流した。 「⾼橋 !!私 ⾔ !!」 願 本気
  15. 【Case3】課題:要件の合意レベルが低い • PdMの視点 • お客様の要望、ステークホルダーからの要望のすべてを把握している • 管理プロセスは明確ではなく、システム化もできていない • 複数のMy要望管理Excelが存在するプロダクトも… •

    開発メンバーの視点 • PdMからは主に会議や⼝頭で要件が伝えられる • 決定事項のみで、「なぜ」がわからない • 担当者間で個別にやりとりされ全体像が⾒えない • ステークホルダーの視点 • リリース直前にならないと、⾃分たちの出した要望は実現されるのか不明 • 他にどんな要望が上がっているのか、開発チームが何を作ろうとしているのか全体 像が⾒えない 41 ソフトウェア黎明期から繰り返される、アレ…
  16. 【Case3】「要件管理」とは関係者が「合意」出来る仕組み • 混乱の過半数は「要件」に関するもの • 仕様モレ、誤解釈、無節操な仕様の変更… • 関係者全員で「要件管理」を維持しようと いう認識が不可⽋ • 仕様変更を発する可能性のある⼈全員に対して、

    要件管理のトレーニングを実施すること • 組織の中で権限を有する者が、⾝勝⼿な要 件の変更を発することがある。 44 清⽔吉男さん(1949年4⽉18⽇ - 2017年11⽉22⽇) 要件を「合意」できるためには ü 要件を適切に仕様化する必要がある ü 仕様化の程度…“Specify(特定)”できる状態 ü 要件がレビュー可能であること
  17. 【Case3】作りたいもの(仕様)はどう出てくるの? 46 要求 仕様 具体的な実現⽅法を考える • 漏れがないようにする • 実現可能か調べる •

    曖昧さがないようにする 背景 どうすれば問題や課題が 解決できるか「理由」と 共に考える どうすれ ば問題や 課題が解 決できる か考える 具体的な 実現⽅法 を考える
  18. 【Case3】ツールの適切なカスタマイズとプロセス運⽤ 1. SPAのバックログ作成 2. SPAの要望管理プロセス構 築(FY2015〜) 3. SVF Cloudの要望管理プロ セス構築

    4. SPAのいろいろなJIRA統合 5. Motion Boardの要望管理 プロセス構築(FY2020〜) 47 • 関係者へのヒアリング、JIRAの構築、プロセスの構築、運 ⽤説明会、運⽤後までを担う • プロダクト横断で要望管理プロセスが揃いつつある
  19. 【Case4】課題:⽬的不明の会議多すぎ&⼈数多すぎ • 会議が多い • ⾊々ない • アジェンダがない • 決定事項がない •

    次のアクションがない • 議事録がない • ⼈数が多い • 同じ部⾨から複数メンバーが参加 • 会議中に⼀回も発⾔しないひと、内職者多数 • みんないたほうが良い場(キックオフ、出荷承認会議)には主 要メンバーがいない 50 https://youtu.be/bQSQ009k4tE
  20. 【Case4】コミュニケーション計画ベースの会議設計 • 社内で開催されている会議の4つの 分類で仕分け • 情報交換型 • 洗い出し型 • 分析・考察型

    • 意思決定型 • ⽬的不明の会議と⽬的重複の会議を 淘汰し、必要最⼩限のものだけ運⽤ • 会議の関係と討議対象の情報(JIRA チケットなど)を整理し、グランド ルールと共にConfluenceで公開 53
  21. 【Case4】しばらくすると、改善がまわりはじめる • Lean Coffeeでのディスカッション • 事前準備なしのミーティング形式 • ミーティングのはじめに全員で話し 合いたいことを書き出し、投票等で 話し合う順番を決めます。

    • 1テーマにつき、7-8分のタイム ボックスを設定してディスカッショ ンを⾏います • 時間がきたら同じテーマでのディス カッションを継続するか、違うテー マに移動するかを全員で投票し、多 数決で決めます。 56 短時間でたくさんのテーマについてディスカッションできる https://youtu.be/-QuCbT0e34A
  22. 【Case5】プロダクトマネジメントの⽀援 • インセプション・デッキ作成 • 計画⽴案・更新 • リスクマネジメント • キックオフミーティングの浸透 •

    ステークホルダーマネジメント • 開発チームのチーム⼒向上 • プロジェクトの⽴て直し 65 計画を⽴てる、キックオフを するが「当たり前」になった
  23. 【Case5】 DevOpsの構成要素CLAMSでカテゴライズ • Culture(⽂化):コラボレーションコ ミュニケーションを加速させる • Lean(リーン):無駄を減らし、早く リリース可能にする • Automation(⾃動化):⼿作業をなく

    す • Measurement(測定):計測し、デー タを活⽤する • Sharing(共有):他者が学べるように 経験・ナレッジを共有する 67 約1年で58のナレッジと5つの動画を公開
  24. • Value Stream Mapping • 全体像を理解して、カイゼンの最初の⼀歩を決める 【Case6】現状を⾒えるようにする 70 4. 未来のマップを実現する

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

    3. 未来のマップを描く 2. ボトルネックを発⾒する 1. 現状のマップを描く ü要望管理がされていない ü特定の⼈しかできない作業が明らかに なる üオンプレ・クラウドの連携部分の開発 プロセスが混沌としている
  26. 【Case8】 Leaders Effective Training(L.E.T) • 臨床⼼理学者トーマス・ゴードン博⼠が提唱す るゴードン・モデルを統合した、リーダーやマ ネジメントのための対⼈関係での効果的なコ ミュニケーションと他者と対⽴した場合の対⽴ 解決のためのスキルを実践形式で習得するワー

    クショップ*1) • ゴードン・モデル • 問題は⼈間関係の中で発⽣する。つまり、お互いのコ ミュニケーションの⽅法によって起こる。 • 相⼿の⾏動によって不都合や問題が⽣じた場合におい て、5つの主要なスキル「アクティブ・リスニング」 「対決的I-メッセージ」「ギア・シフト」「メソッド Ⅲ」「価値観の衝突のオプション」を⽤いることで直 ⾯している問題や状況を整理し、解決へと導く 79 *1) https://gordontraining.jp/ http://www.lc-t.jp/ Dr. Thomas Gordon
  27. 【Case9】エンゲージメントとは • 従業員満⾜度 • 職場環境や給与、福利厚⽣など への満⾜度=組織が与えるもの • モチベーション • ⾏動を起こすための動機=個⼈

    が感じるもの • ロイヤルティ • 組織に対する帰属意識、忠誠⼼ =上下関係が⽣み出すもの • エンゲージメント • 主体的・意欲的に取り組んでい る状態=相互の対等な関係に基 づくもの 83 引⽤元:組織は「⾔葉」から変わる。ストーリーでわかるエンゲージメント⼊⾨ ⿊⽥ 天兵 (著)朝⽇新聞出版 (2020/2/20)
  28. 【Case9】仮説と実験 • 「64」という数字がいったい何をを表しているのか、このとき は正直さっぱりわからなかった • 就任したてなこともあり、まずは以下の施策に注⼒した • まず、⾃分を知ってもらう • みんなを知る(リーダーズ・アクライメーション実施)

    • GMGの⼒量を測り、育成を開始 • 1on1が⼀度も⾏われていなかったので、週次で開催 • 単純に「残業が多い」と怒られていたので、 働き⽅の分析を⾏った 86 リーダーズアクライメーションの⾵景
  29. 【Case9】仮説と実験 • 1ポイント下がった「63」になってしまった。 • 正直「うっ」とはなったが、実際エンゲージメントを⾼める施 策は「何もしていない」のでスコアが上がるはずもないと考え 直した。 • 前期の調査でわかったこと •

    部としての⼀体感がまったくない。 • 部としての⽬標もない(のろしは上がっても⾃分ごとではない) • QAという、おなじ知識・技術ドメインの仕事をしているにも関わらず、 グループ同⼠(GMG同⼠)の関わりがまったくない。ので、技術の流 通もない。(すべては、前任のBOSSを通さないとダメだった) • とりあえず、上記をカイゼンするだけでもスコアはあがるので はないか? 89
  30. 【Case9】合宿をやった • ⾃分たちで、組織⽬標を考える(ワールドカフェ) ① 強いQAチームを作るには ② プロダクト連携時代のQAとは ③ クラウドファースト時代のQAとは ④

    QAとしてやりたいこと • メンバー全員に「パフォーマンス⽬標」を⽴ててもらった • http://nexcf.1stg.local/pages/viewpage.action?pageId=103172393 • このときの様⼦はブログに書いています • The New Normal https://link.medium.com/NgDNtq7VZ7 91
  31. 【Case9】仮説と実験 • スコアが「71」にジャンプアップ!しかし… • 新しい「部⾨⽬標」に沿った活動をするメンバーと、従来のやり⽅を 変えないメンバーがはっきりと⾒えてきた(スコア分布が歪) • 相変わらず、残業時間が多いメンバーが変わらない (特にグループマネジャー) •

    エンゲージメントも、極端にスコアが⾼いグループがある。だが良い 取り組みをしているわけではなく「アドレナリン・ジャンキー」的な 雰囲気が漂っている。 • やったこと • 残業多いひとへの業務カイゼン指⽰ • 組織変更をした 96
  32. 【Case9】仮説と実験 • スコアが「67」に下がる • 前期⾼かったグループが、逆張りの急降下 • 開発部⾨との関係性低下 • 仕事を指⽰され、こなすだけ…の傾向が強いグループは、開発側の状 況に多⼤な影響を受ける

    • マネジメントラインを⾒直して、組織⽬標を⾃律して具現化す るライン構築を⽬指した • ⼀部のメンバーからは、猛反発があった • 丁寧に向き合ったつもり • 他部⾨のマネジャーからクレームもあったが、丁寧に説明して理解を 得た 98
  33. 【Case9】仮説と検証 • 「72」に復活した。最新は「76」 • 組織変更で⼀部の反発が強かったものの、新体制のチームビル ディングを経て、各グループのエンゲージメントスコアは総じ てアップした。 • 全体的な底上げを⽬指し、SPQI部へのインナーブランディング を開始した。

    • 「⾔葉づくり」を丁寧に • 企業レベルのMission、Vision、Valueを部⾨やチームレベルに落とし込む作業が 割とむずかしい件・後編 • https://link.medium.com/OYSo7s1VZ7 • 全員でOKRを利⽤した⽬標管理 • ブログによる発信を推奨(部⻑が率先して) • 定⽯集の「GROW」サイト⽴ち上げ 100
  34. 102 【Case9】OKRでやり遂げる⽬標を⽴てる • じぶん戦略を考え⽬標を達成する。パ フォーマンス⽬標とも⾔います • アジャイルで良く使われている 「ユーザーストーリー」で書けます。 • 「誰」や役割(〜として)、

    • 「何」やアクション(〜したい)、 • 「なぜ」やビジネスのメリット(そ れは〜のためだ) • Acceptance Criteria には何をすれば⽬標 に近づけるかを書きます KR O(Objective)
  35. 【Case9】OKRでやり遂げる⽬標を⽴てる • 部下の⽬標(四半期ごと)をコミッ トさせ、後押しする。 (⾦、アサインメント) • フィードバックする。 • 達成に障害があったら取り除く。 •

    ↑ これを毎週1on1で実施する。 ※ 1on1(週次)は「雑談ツール」で はなく「⽀援ツール」 • ⽴てた⽬標(四半期ごと)をやり遂 げられたか?は、わかりやすい評価 要素となる。 103
  36. 【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 ⾃動と⼿動 ⾃動 ⼿動 ツール 製品を批評する
  37. 【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
  38. 【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
  39. 【Case10】Automationチーム 荒川のアプローチ 110 まだまだ少ない機会の中、前期の1年間で数プロダクトの ⾃動テストが稼働開始した。 開発とコラボ! 学びを⽌めない! ⾃動テストの損益分岐点 「何が起きるのが嫌ですか?」 Dev

    + QA はじめの⼀歩はベイビーステップ 開発との コラボレーション アプローチ Collaboration with developer ターゲットを限定 型にこだわりすぎない ⾃動化のハードルを下げる テーマ
  40. 【Case11】研修を企画する 1. スキルマップを作成する • ⾃⾝やメンバーの強化したいスキルを明確にする 2. 情報収集 • トレーニング、研修、カンファレンスの選定・予算計上 •

    ときには、開発チームの分も計上 3. 社外から講師を招いて集合研修を企画する • 部⾨の集合研修を企画・実施(FY2016-FY2018) • 開発や他部⾨も巻き込んで研修やトレーニングを実施(FY2019〜) • 企画書、集客、運営、事後アンケートなど裏⽅作業全般を担当 4. 開発職新⼈研修を企画・実施する • 新⼈が各部⾨で数週間ずつ研修を⾏う 121 • 他部⾨から集合研修⼀緒にやろうって声をかけられる • 新⼈研修のリクエストをいただく
  41. 【Case11】SPQI 発⾜後 122 周りも少し変わってきた 「研修?いってこい!」 「イベント?いってこい!」 「⾦は出す!」 認定や トレーニング ブログ

    外部発表 ブログなどで社内展開 外部イベントで発表 部内の研鑽⽂化の向上を⽬論む 部内の研鑽⽂化は根付きつつある
  42. 【Case12】課題:官僚型の組織 指 揮 命 令 報 告 指示待ち 抱え込み 無茶な指示

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

    指示がないから帰る… やらされ感 フォロー不足 つまらない 恐れと非難 細かい指示 部下が不安 全ての報告を求める 時間がない 苦しい 思考停止 ⾃⼰組織化 ⾃⼰組織化が進むと、チーム の問題を⾃分ごととして捉え ることができるようになりま す 明確なゴールと目標 モチベーションの理解 よく考える 積極的 自分たちで決める ナレッジの整備 エスカレーション ふりかえり 適切な権限移譲 Build the Trust フィードバック BOSS
  44. 【Case12】コミュニケーションの複雑性 • ⼈数が増えるとコミュニケーショ ンのオー バーヘッドが増えます。 • そこで規模拡⼤が必要な場合、チーム内の ⼈数を増やすのではなくチームの数を増や すほうが良いとされています。 •

    なぜなら、全員が知っている状態が作りや すいので、たとえ全員が同じ場所にいなく ても同じ情報を知っているならだいたい同 じ判断が下せるからです。 • これが意思決定のスピードアップにつなが ります。 • この図をみると、せいぜい5⼈ぐらいが限 度に⾒えます。 https://churchhealthwiki.wordpress.com/2015/07/05/teamwork-the-rapid-complexity- that-arises-when-your-team-or-small-group-exceeds-10-people/ コミュニケーションパスの 複雑性をなるべく最⼩に
  45. 【Case12】組織改⾰のポイント 130 a. 組織のMissionを⾃分の⾔葉として語れるリーダーを配置する b. マイクロマネジメントから卒業しリーダーにはメンバー育成を期待する c. カルチャーバブルを発展できるリーダーを⾒極めバランスよく配置する d. 1つのチームはなるべく5⼈以下とする

    e. チーム内の個⼈スキルが偏らないようにする。 f. 困難に⽴ち向かい成⻑できるレジリエントな組織体制を⽬指す g. リエゾンタイプの⼈材を⾒極め、組織の潤滑油とする h. 経営陣からの期待と部⾨Missionの実現にコミットする
  46. 【Case12】成⻑志向か? • メタスキル習得の⼤部分は「⾃分の仕事経験」といえる。 • では、仕事で経験して学びを得るとは? • 部下がチャレンジしたい仕事をアサインしてあげることが⼤事。 これは上司にしか出来ない。 131 優れたマネジャーを調査したところ、成⼈の学びとは―

    70% ⾃分の仕事経験から 20% 他者の観察やアドバイスから 10% 本を読んだり研修を受けたりすることから ーから得ている マイケル・ロンバルド&ロバート・アイチンガー Career Architect Development Planner, 5th Edition - 2010
  47. 【Case12】 Certified Agile Leadership(CAL1) • ハイパフォーマンスな組織に成⻑するためのリーダーシップモデルを学ぶ • 組織カルチャーが変わるとき、構造と意識の両⽅が変わる • カルチャー

    (カルチャーバブル)を作るのはリーダーであり、リーダー ⾃⾝が⾃分のマインド、振る舞いから変える。そうしていけば周りもよい 影響を受ける • https://shift314.com/certified-agile-leadership-training-cal-1/ 132 https://medium.com/wingarc/50f550e675b2
  48. 【Case12】Management3.0 • 複雑な状況において有効なマネジメントを学び、メンバーを⾃⼰組織化に 導く。楽しく論理的なプラクティスが多数。 • ムービングモチベーターズ • メンバーのやる気スイッチを知れば、やる気すいっちがONになる働きかけ⽅ができ るようになる。何より考え、価値観をしれて楽しい。 •

    デリゲーションポーカー • チームの仕事の種類と意思決定の権限委譲レベルを明確にする • 「上司がやってくれるはず」、 「チームに任せた!(けどできてないじゃん…)」 といった思い込みやすれ違いをなくし、⾃律的に動きやすくなる 133
  49. 【Case12】ワークで起きた変化・気づいた効果 135 期待される ゴールの 明確化 WHAT:明確 HOW:委譲 セルフ マネジメント 信頼に

    応えたいという モチベーション これらの要素は、約2年後に突如始まる フルリモートワーク体制へのスムーズな移⾏ にも深く影響を与える デリゲーション ポーカー チームの⽅向性と個⼈の役割が明確に 意思決定のスピードアップ 個⼈のモチベーション向上
  50. 【Case13】戦術:シフト・レフト、シフト・ライト 計画 実装 ビルド テスト リリース デプロイ 運⽤ Shift Left

    Testing Shift Right Testing シフト・ライト・テスト • 運⽤中にもテストを⾏い品質を監視するとで常に 品質を保証し続ける サポート情報分析によるフロントローディング 分析してパターン化して再利⽤して開発を成⻑させる シフト・レフト・テスト • ライフサイクルの早い段階でテストを開始できる • 開発完了後に⾏っているテスト実⾏を、もっと早 い段階でかつ⾃動的に継続的に実施する • 早い段階でテストを実⾏するために、コンポーネ ントがそろわない状況でもE2Eテストを実⾏でき るようにする • GUI経由の機能テストをAPIレベルで⾏うテストが 実⾏できるようにする
  51. 【Case13】兼務の強み コラボレーション アフィニティ 実⾏フェーズ or + SPI N A QA

    A Automaiton A 打ち⼿の選択肢の拡張 施策開始までのスピード向上 各プロダクトの PdM・開発チーム
  52. 3. 社会に提供する価値 2. なりたい 姿 【Case14】⾔葉を分類するためのフレームワーク 社会の未来像 4. 顧客に約束する価値提供 5.

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

    戦略、戦術 6. 理想的な⾏動 7. ⼤切にしたい価値観、⽂化、強み 1. 現状 (外部・内 部の環境) Vision Mission Value Employee Principles WHY
  54. 【未来へ】荒川健太郎の「⼈⽣はつづく」 156 2年 8年 でも、 少しづつ 変わってきてる なかなか うまくいかない 銀の弾丸

    なんてない まだ DEV QA 終わりのない 学び ⽂化を変えるのは 終わりのない 営み 毎⽇何か動いていこう!