6週連続社内Webinarやった話

はじめに

今年の2月から社内のアジャイル推進リーダーになりました。
以前から社内外でワークショップやLTをやっていて、
専門家としての1on1講義や、プラクティスの説明、ペーパワータワーなど実施してきました。
why
今回集中的にWebinarを開催しようとした背景として、
アジャイルのすそ野を広げながら、やっても得しないんじゃね？という空気を変えたい意図がありました。
それは、リーダーになって以降のコンテンツ注目度の推移や
問合せや閲覧数から感じていました。
年度も新しくなるし、ここでバシッとみんなが付いてきてくれる研修を提供しようと思いついたのが始まりです。

準備

what-when-howto
何をやるか
シリーズ化はそこまで意識せず、幅広い領域を初級から順にやっていくことにしました。
①アジャイル基礎
②アジャイル基礎の発展
③アジャイルの売り方ワークショップ
④アジャイル×Security
⑤アジャイルプラクティス
⑥アジャイル応用
毎週同じ曜日の同じ時間に開始するようにしました。とは言え、6週間後というのは、
業務予測も難しくて、とりあえず設定しておこうという。
howto
参加しやすいように、案内にも気を配ったつもりです。参加リンクと資料置き場を載せて、(資料は未定)
そのため事前に会議設定と、資料置き場を用意しました。
事前申し込み不要で飛び込み参加okにしました。
想定参加者と、推しポイント(CFP)を記載しました。
webの利点を活用し、周りが分からないように参加できるライブイベントをメインにしました。
大人数や参加者同士の状況が分かると逆に積極的な参加が見込めないと、それまでの実績から実感があったためです。
みなさんの会社も学習に費やせる時間は確保されていますか？
そして、いつもながらワンオペで開催です。
会議進行のプロデューサーも発表もワークのファシリもやります。
1度リハーサルやって、1度本番すればそんなに難しいものでは無いと思っています。
とは言え、最初は心配事が多かったりしますが、初回だけです。
うまくいかなかったこと；Webinar案内は刺さるものにしないと参加数に大きく影響するので、
工夫の余地があります。

全6回の内容に入っていきます。

①アジャイル基礎

これは会社が作成しているテキストがあるので、資料の補足説明の位置付けで実施しました。
テキストはよくある、なぜアジャイル、アジャイルとは何か、スクラム、プラクティス、
アジャイル周辺の概念、会社の認識や目標という建付けです。
私が補足した資料として、
・アジャイル流行ってるぜの裏付けデータ
・アジャイルとは何について、経験主義、Fail Fast、MVP、Value Driven、QCDSの図説
・アジャイルマニフェストの見誤りやすいポイントと、私がなぜ良いと感じたのかWFの失敗経験
・スクラム関連で、The new new product development game、SECIモデル、日本がアジャイルに与えた影響
・スクラムのTerminologyについて3つのロール、5つのイベント、3つの作成物の簡略図
・プラクティスはプランニングポーカー、Kanban、バーンダウン
・周辺概念はBizDevOps、DevSecOps、CI/CD、デザインシンキングの状態遷移、Lean
・組織形態(ヒエラルキーとマトリクス)
というような内容でした。
参考までに資料は目次等も入れて115枚、120分で実施しました。
反省点：元のテキストが読むことを想定されているため、文字が小さくプレゼン向きでなかったのと、
自分自身が文字を読み上げるのが苦手ということ。いくら読み込んでいる資料とは言え、
誰かの作った資料を読み上げて進めるパートは、つまづいた。

②アジャイル基礎の発展

今回メインの1つで、自分の想いをこのセッションに乗せたかったので、構想も練って、
資料も作り込んで臨みました。
孫前の週(上記①)で読み上げTeaching的アプローチは、向いてないと再認識したので、
ここではCoachingのスタイルで実施しました。

(1)データの話

・海外(State of Agile)や、国内(PMI 日本支部アジャイルプロジェクトマネジメント実態調査2021)
またDXやSociety5.0、昨年改定されたスクラムガイド、
改定された書籍「アジャイル開発とスクラム」、「SCRUM BOOT CAMP」、
1つギミックとしてバズっていた、非常に少ない偏った母体数で調査されたアンケート公表値を
引き合いに出して、データダイシング、ドリリング、スライシングの話を交えて、データとはということを問う
・私が約半年間で受けた問合せの内容と社内の習熟度別人数頒布
案件の引き合いや顧客向けトレーニングの相談、社内の学習教材や資格の相談等
ここから私が感じた二極化と習熟を進める際にある壁の存在について
会社全体が進んでいくためには、学習が止まっている層をいかにして進めていくか
アジャイルをやっていない、好きではないと感じている社員も含め、
誰も取り残さない、すなわちD&Iの考え

(2)アジャイルソフトウェア開発宣言12の原則

原則の逆パターンを考えてみる
1.上司や会社に指摘されないことを最優先にし、
完璧な計画、設計書、ﾃｽﾄ結果を納期ピッタリに、
指定されたフォルダに格納します。
2.要求の変更を受け付けるのは凍結期間開始まで
それを過ぎたら取り纏めて次の機会に対応します。
または最初から金額盛ったから余力内はokにしよう。"
3.固まった納品物(大量)をお客様が全てに目を通して頂けるように整形し、
各フェーズの最後に、納品します。顧客からのフィードバックは1回の検収印です。"
4.ビジネス側の人と開発者は、
プロジェクトを通して
報告書と返信コメントを共有するために定期的(週イチ、月イチ)にやりとりしなくてはなりません。"
5.指示に忠実な人々をなるべく多く集めてプロジェクトを構成します。命令とWBSを与えてトラブルが終結するまで彼らを拘束します。
6.情報を伝えるもっとも効率的で暗黙的な共有方法はzip資料や、誰が言ったか明記された議事録をメールに添付し全員をｃｃに入れて送ることです。(さらにFYI)
7.報告書のオンスケ、異常無しのサマリーレポート
こそ進捗の最も重要な尺度です。"
8.アジャイルでないプロセスでは、繁忙期には休日出勤し、閑散期にはいつでも人を貸せるようにしなければなりません。
9.技術的安全性と既存の設計に対する不断の信仰が安定稼働を高めます。
踏襲こそが文化です。"
10.シンプルさ、とは仕様通り(or昔からの決まり通り)か否かです。例えばユーザーが使うか使わないか、組織が変化した等は一切関係ありません。
11.最良のアーキテクチャ・要求・設計は、上司に承認されるかどうかで決まります。
(誰が言ったかとか、自分の過去の経験は特に重要です)"
12.チームがもっと効率を高められるかEVM指標、信頼度曲線を常に監視し、
それに基づいて上がやり方を指示し、チームはそれを遵守します。"
上記でうまく行っていることも多い。否定するのではなく価値を認めながら、これらにならないようにするには
どうするのか考えるのが重要である。

(3)新しいリーダー像

AgilePBL祭り2021で講演した内容を再演
1.こんなときどうすれば良いのか
・どうやってやれば良いか聞かれた→どうやってやれば良いか教えたら何もできない若手になってしまった
・やってみたいアイデアを提案したが断られた→そのまま引き下がったら失敗するチャンスを失った
・選択肢がいくつかあった→迷わずうまくいきそうな方法で進めたら、また迷った
・意見を求められた→真面目そうな回答をしたらチャレンジしやすい環境を失った
2.小学生プログラミング教室で感じた
・自分が考えつかない方法で、子供たちは解決した。プログラミングを修正するのではなく、跳び箱を動かして運用回避した。
・子供たちの考えを支援することに徹したら、全て自分たちで進め、解決し、学んだ
・自分自身の考えが及ばなかったどころか阻害要因になっていた
・気付かないうちに自然と、可能性を狭めている
まとめ
「なぜ」に着目し、目にしたデータ、耳にした情報に従順する前に自分で考える
左か右かではなく、双方の価値を認め、複数の視点を持つ
D&Iをアジャイルにも適用したい
無意識に後輩をダメにしている、後輩は無意識にダメにされているかもしれない

ふりかえり：この回は、うまくいった。自分が伝えたいことを自分の言葉と資料で伝えることができて、
視聴者にも刺さったようだった。終わった後すぐに何名かから連絡をもらった。
時間配分としては、進行スピードも少し早いかなと思いながらも、ちょうど良いペースだった。

③アジャイルの売り方ワークショップ

(1)なぜ売れないのか

・GAFAMがアジャイルを売ったらどうなるか？
・うちの会社がアジャイル売ってどうか
・Saas、マイクロサービス、Low-codeやNo-code、クラウド、DXは売れるか
・アジャイルで失敗したプロジェクトがあるようだが、アジャイルは絶対に失敗しない、
または小さな失敗が延々と続くはず
・アジャイルはお客様に求められているのか？
◆なぜ売れないのかブレークアウトルームで話し合ってもらいました。

(2)なぜ売りたいのか

・契約の話として請負/準委任の話、アジャイルモデル契約の話、実際に工夫して契約した話
・利益はいつどのくらい得られるのか、ウォーターフォールと比較してどうか
・内製化が完了した企業ではどうなるか？
◆なぜ売りたくて、誰が得するのかをブレークアウトルームで話し合ってもらいました。

(3)アジャイルとは何か

・従来からの課題として組織が異なると利益相反しがちである。
・お客様との間に契約が存在すると、買う側はなるべく多く、なるべく安くやって欲しいし、
売る側はなるべく高く売、簡単に作りたい。
・組織のサイロを無くす1つの方法として、買う側はなぜそれが必要か、売る側は何が必要でどうやってつくるかを
お互いに伝え続ける必要がある。
・従来の開発方法と比較すると、例えば注文住宅とDIY可能な賃貸のようなイメージ
注文住宅は設計の時は大変だが、それが終わるとたまに状況確認するだけで良い。
住みながら作っていく方法では、一緒に住んで何が必要か決めて、たまに手伝わなくてはいけない。
・アジャイルはゴール地点が動き続け、ゴールは明確に見えない。(逆にゴール地点が明確に見えて動かない場合は従来のやり方のほうが向いている場合が多い)
・アジャイルは進めていると、ゴール地点が一見遠ざかっていく場合もある。経験として捉え、
ゴールの方向は示し続ける必要がある。
・アジャイルではスコープは最後に決まる(続けている間は決まらない)、短いスパンで仮のゴールを決めてその間の品質を作り込む。
従来のやり方の場合は、スコープやゴールが最初に決まり、その計画に基づいて品質を作り上げていく。
・アジャイルをやると、従来下の立場にいたメンバーがうるさくなる。なぜなら全員が同じ判断ができるようにするために、
個々が必要な情報を要求し、権限を要求し、正解を判断し動き出すため。
・今までは組織中枢(例えば脳)を強化すれば、正しい判断の元、指示通りに各機関(器官)が動けば効率的に目的を達成できた。
アジャイルでは末端機関(器官)が中枢の判断や指示を待つことなく動く。
・正解が1つでは無い状態は、その行動が正しいということを示しづらいため、何をすればアジャイルになっているかを保証することが難しい。
◆アジャイルって〇〇のことだよね、その心はｘｘだからという大喜利をやってもらった

(4)ふりかえりしながら、アジャイルの売り方を考えてもらう

◆感想と質疑応答

ふりかえり：唯一のミーティング型ワークショップ。コアな方々が集まって楽しかった。
特に営業部門、コンサル部門の方が多かったことでターゲットは狙い通りだった。
テーマを決めて話し合ってもらったことで、内部のつながりや、考え意見の交換ができたようだった。

④アジャイルとセキュリティ

(1)社内のアジャイルforセキュリティについて、いくつかの指標や考え方、フレームワークを紹介。

・組織間のサイロがある。例えば開発と運用保守部隊だと、お互いに似たようなことを言っているのに交わらない。
それが監査やセキュリティと、開発組織間でも発生している。
・リリースプランニング、必要なものは先に考えておく必要があるという考え方
・構造分解について。全てのことを分解して考えられるようになるとサイクルで回すこと、柔軟に変更することができるようになる。
フラクタル構造やINVESTの原則、SMARTの法則を紹介。

(2)アジャイルforセキュリティのビデオ鑑賞

・STRAID、シフトレフト、時限爆弾は爆発しない限り安全。
・完璧とは＝完璧では無いということ。YAGNI(You aren't gonna need it)やMVP(Minimum viable product)の観点がある。
・従来の開発手法では、V字モデルやW字モデルのようにテストは対局する局面で行われるが、
予め設定されている正しさを証明することは、盲目的にチェックリストを埋めていくことになりかねない懸念がある。
例えば良く比較されるのが、KPI、MBO、OKRがある。
・メンテしやすいコードにするために、リファクタリングや構造分解したときに、少なからず障害が発生した。
お客様には謝って納得していただいた。やろうとしていたことをお客様に説明し実施していたこともあるが、
爆弾を小さくすることで、小爆発することも多い。これをどう捉えるかは結構重要だと考える。
・リリースプランニングの重要な考えについて。必ず必要になるものは最初から考慮して、最初から充分な分だけやっておく。
UnDone。技術品質と製品品質がある。私は狩野モデルも近いと感じている。

ふりかえり：前日にこのライブイベントの途中でどうしても出なくてはいけない会議(本業のプロジェクト)があり、急遽順序を入れ替えて、
どちらもうまくこなすことができた。ワンオペだといきなり柔軟に対応できるのは良いところかもしれない。
ビデオ上映を組み込んでおいたのは大きかった。スケジュールは結構前もって決めることになるので、
急な変更はなかなか難しいものの、工夫次第で変化に対応できるようになることを実感した。

⑤プラクティスの詰め合わせWebinar

メトロマップに表されているように、プロジェクト開始前から進行中まで多数のプラクティスがあり、
概要と使用例を紹介しました。

(1)リーンキャンバス

・まずは基本の、課題→顧客→価値→解決策→顧客流入元→利益→コスト→計測指標→優位性
・たとえば個人の目標設定に応用すると、
自分(現状、求められていること、強み、弱み)→顧客・組織→スキル(現状＋〇〇＝求められていること)→
(得る)手段→(顧客・組織への)貢献→(顧客組織の)利益→(自分の)労力→計測指標→優位性
・マーケの手法として、ファイブフォース、AIDMA、3C、SWOTとも似ている。

(2)デザインシンキング

・Designとは。Wikiペディアの定義を引用し、デザインとは何かの再確認
・なぜデザインが苦手なのか？ 例えばa.２＋５＝□ の答えは1つですが、
b.２＋□＝７の答えは無限にあるので、考え方の幅をどこまで広げられるかが重要だと考える
・何か」に対してFirst Stepを踏み出すためのThinking(考え方)でMethod(やり方)では無い
「何か」に当てはめるのは何でも良くて、例えば、問題点。例えば、期待すること。
または、新たな通勤ルート、次に買うステキな服、明日のハッピーになる夕食。
今より良くしたいと考えた瞬間がデザインシンキングだと言う人もいる。
・一歩を踏み出すためには、きっと・・「何か」をハッキリさせないといけないし、「なぜやるのか」決めないと、ブレるし、
「どうやってやるのか」知らないと、動けない
・デザインシンキングのマインド4つ
常に相手目線になる。コミュニケーションが前提。なんでも見えるかする。1つの考えに固執しない。
これはアジャイルマニフェストに通ずるものがある。
・デザインシンキングのマインド4つ
共感(Empathize)、問題定義(Define)、アイデア出し(Ideate)、ﾌﾟﾛﾄﾀｲﾌﾟ(Prototype)、テスト(Test)
・OODAループや、リーンスタートアップも近い考え方である。

(3)インセプションデッキ

グループをチームにするプラクティス
・プロジェクト開始前に、全員でディスカッションして、10個の質問に答えて、アウトプットして、いつも見られるところに貼る。
・現在地と方向性の合意
１． 我々はなぜここにいるのか
２． エレベータピッチの作成
３． パッケージデザインの作成
４． やらないことリスト
５． プロジェクトコミュニティ
６． 技術的な解決策の概要
７． 夜も眠れなくなるような問題は何か
８． 期間を見極める
９． トレードオフスライダー
１０．初回のリリースに必要なもの
・これに近いことがキックオフミーティングやプロジェクト憲章になっている。
違いは誰が作ったかということで、もし全員参加で作っていれば問題無いと考える。
事例として、やっていることは、メンバーに「あなたがやりたいこと、なりたいものは何ですか」と聞き、
チームやプロジェクトが目指す方向と合わせる。
それをお客様の価値と合わせる
あなたがユーザーだったら、何が価値かを考えてもらう。
これをする時によく起こりがちなこととして、「プロジェクト成功のためです」「顧客満足のためです」
「仕事だからです」という答えが返ってくることがあるが、個人のやりたいこと、なりたいものを尊重し、
フォーカスすることが重要。

(4)ユーザーストーリーマッピング

製造業発のバリューストリームの考えをソフトウェアに応用した考え方
・カスタマージャニーをユーザーが経験する順に並べる
・構造分解してサブ機能をぶら下げる。(またはサブ機能を全て出してからグルーピングする方法もある)
・価値の軸を加えて、価値の高低によってスライドする
・リリーススライスする

(5)INVESTの原則

この原則を満たしていないと、リリースしても価値がでなかったり、MVPにならなかったりする。
・Independent：独立/疎結合
・Negotiable：調整/交渉
・Valueable：プチ価値
・Estimatable：見積もり
・Sized right：小さく
・Testable：テストできる
例えば英語の上達で考えると、ライティング、リスニング、ヒアリング、スピーキングのどれも欠かすことができない。
目標設定のSMARTの法則
・Specific：具体的
・Measurable：測定可能
・Achievable：達成可能
・Realistic：現実的
・Timebound：期限がある
参考情報として、目標設定のKPI (Key Performance Indicator)、MBO (Management By Objectives)、OKR (Objective and Key Result)
の特徴を比較してみた。

(6)プランニングポーカー

見積もりというより見立てというほうが適切かもしれません
プロダクトバックログアイテムに対して
個人の解像度や認識をチームに共有し
チームとしての共通の解像度や認識にしていきます
1.プロダクトバックログアイテムを一覧に
2.全員にフィボナッチ数が書かれたカードを配る
3.一番簡単そうで皆が分かる項目を2(or1)とする
4.次の項目について2(or1)と比べた数字を各自決める
5.全員同時に場に出す、一致してたら次の項目へ
6.不一致なら最大値、最小値の人が理由を話す
7.全員で見解を共有し、カードを手元に戻す
8．選びなおして再度4.に
9.数回繰り返しても一致しなければ多数決or平均値
10.全部決まったら、未確定事項や前提を振り返り
体験会で良く用いる料理の例や、宿泊予約システムの例を例示

(7)計画ゲーム

ストーリーポイントとビジネス価値の軸でユーザーストーリーを考える
当然、一番簡単で一番価値のあるものから実施する。その一番おいしいところが終わったら、
再度、組みなおして、また一番おいしいところから対応する。これはバックログリファインメントの考え方。

(8)Kanban

タスクのステータスを見える化するもの
１．ワークフロー見える化
２．WIP制限＆Pull方式
３．流れの管理
４．ポリシーを明確に
５．メトリクス
６．実験的な進化
・ToDo(やること) [個人的にReady,unready,Icebox入れたり]
・Doing(手を付けていること) [個人的にambulance緊急ゾーン入れたり]
・Done(完了したこと) [個人的にUnDo, Trush, Parking Lotと入れたり]
これ以外にもScrumbanや、バーンダウンなど見える化のために用いられるツールがある。

(9)Definition of Done、Acceptance Criteria

完成の定義、受入の基準
・完成の定義や受入の基準を決めてから取り掛かること
・ユーザーストーリーやEpicにも繋がる
役割と着目する機能を明確にする xxという状態で、yyしたら、zzになる

(10)デイリーミーティング

1日15分のミーティング
目的はチーム(特にメンバー)の透明性を維持するため。
よく用いられる3つの質問
事例として、私がリーダーだった時に、ファシリテーションをメンバーの持ち回り制にして、
進行も議論もみんなにやってもらった。課題が出たらみんなからの意見で進めてもらった。
私は周りの状況を伝え続けたり、休暇確保をするだけだった。
よくあるアンチパターンとして、進捗管理をするためにリーダーに報告する会になる。
既知の事務連絡をリーダーが伝えるだけ。

(11)クロスファンクショナルチーム

事例として、チーム発足当初は主担当が決まっていて専任から始まった。
次に近所の機能を担当するメンバーをペア、トリオ制にして、作業も報告もそのペアでやってもらった。
そして、その組み合わせを変えるのを繰り返した。
これによって、判断基準や品質が均一化できて、ワンチームになった。
よくあるアンチパターンとして、指示待ちと複数上位の承認を必要としているチーム。

(12)アジャイルテスティング

カギとして、構造化がある。フラクタル構造のように、どんな機能も作業も構造分解できる考え方が重要。
もう一つ、振る舞いという概念も必要になる。構造化と振る舞いの考え方ができるとテスト自動化やリファクタリングが考えられ鵜ようになる。
私はテストを制す者はプロジェクトを制すと考えている。
なぜなら、プロジェクトを構成する全ての作業にテストが行われる。仮説-検査-適応があるということだから。
例えばW字モデルの開発には、必ず対となるテストが存在する。
開発・QA・ユーザーそれぞれ、何を何のためにテストするか考えてみる。
・TDD Test Driven Development (テスト駆動開発)
・BDD Behavior Driven Development (振る舞い駆動開発)
・ATDDAcceptance Test Driven Development (受入駆動開発)
TDDの概念 Refactoring(改修、製造)と Red to Green (失敗から成功に)を組合せて繰り返す
CI/CDやDebOpsとの関係性を考える。
テストコード：プロダクションコードに書き込んでリリースするテスト用のコードのこと
チェックサムや、自己エラー検知のプログラムなどもこれに近い考え方。
テストファーストん尾考え方：
①振る舞い決め どうしたいか
②NGテストコード 正しくない振る舞いを検知できるようにする
③実装 ②のテストで正しくない結果が出たら、正しい結果になるように実装を変更
④OKテストコード 正しい振る舞いを検知している状態にする
簡単なゲーム事例を用いて上記4ステップを考えてみる。
探索テストについて
以下4象限がある。
・Known Given-When-Then xx状態で、yyしたら、zzになる (ジャンプしたら避けれる)
・Tacit こうしなかったら (ジャンプしなかったら・・・)
・Unknown ああしたら (上から踏みつけたら・・・)
・Unawareness of Unknown どうしたら(何ができて、どうなるか)
なにをもって合格(Green)とするか
a：ある立場の人＝okの基準 then 誰がokと言ったかテストをやれば品質は上がる
品質を上げるためにテストする
b：okの基準を全員が合意 then 全員が同じ判定テストは誰がやっても同じ、自動でやってもテストをやっても品質は上がらない
合意できるテスト設計しやすいコードを書く

(13)DevOps

ユーザー企業とシステム会社の関係を考える
ユーザー企業はなるべく安く作って欲しい
システム会社はなるべく高く簡単に作りたい
2つが混ざり合うには、ユーザー側はなぜ必要か、システム側は何をどうやって作るかを伝え続ける必要がある。
もちろん混ざり合うのは簡単なことでは無い。
BizDevOpsや、DevSecOpsは、関係を変えることで成り立つはず。なぜなら立場は違えど、言っていることは同じことが多い。
例えば、うちの組織の仕事には価値がある。他のとこの仕事したくない。うちの仕事渡したくない。パンパンだから人増やして。
組織の融合を妨げるものの一つとして、旧来の強固なピラミッド組織が挙げられる。
中枢や上部を強化するのではんく、各機関や各人の力をつけることが肝要。

(14)Connecting Dots

ジョブズが演説で用いた内容ですが、点と点を繋ぐ考え、そして面にする。最近では面の広さが価値であると考えられている。
ベン図の重なった中央点で勝負する考えもあるし、隣接した領域だけではなく、異なる領域をマスターし立体のような範囲で勝負することもできる。

(15)クネビンフレームワーク

状況の4象限＋１によるタイプ分け
・Simple(単純) 認知→カテゴライズ→対応 因果関係がはっきりしている。正しい正解が1つある。ベストプラクティス。
・Complicated(困難) 認知→分析→対応 因果関係が複雑。正しい正解がいくつかある。グッドプラクティス。対応順を決められる。PDCA。
・Complex(複雑) 仮説検証→認識→対応 因果関係が不明瞭。正しい正解はあるのかないのか分からない。順序は後からできてくる。探索プラクティス。OODAループ。
・Chaotic(カオス) 対処→認識→対応 因果関係が不明。正解の判断すらつかない。何を解決するか不明。何をやりたいか不明。今がマズくてなんとかする。
・Disorder(混乱)
重要なことは、タイプ間違えない。あえて難しくしない。簡単だと見誤らない。
例えばアジャイルで対面する単純や困難な状況もあるし、ウォーターフォールで直面する複雑やカオスな状況もある。
もし、これを誤ると、混乱状態に陥る。

(16)リーダー

個人競技からチーム競技、個人力さえあればプロジェクトをリードできる環境に変化が出てきた。
今までは、あくまでも正解を持つ人が強く、情報を持って、決定を下して、指示型のリーダーが求められていた。
現在では情報に透明性を持たせ、各々が情報を元に判断し決定して行動していく状態が俊敏な動きをもたらすと考えられている。
例えば、リーダーとは、作業指示せず、進捗管理、品質管理せず、答えを伝えたり、会議の主催をしない。
反対に、チームの判断を周りの関係者に伝え調整し、自分しかできないことを減らしチームに権限移譲し、メンバーを信頼し、環境を与える。

(17)ふりかえり

チームで歩んできた結果や出来事について話し合い、経験やカイゼンを行い次に向かうこと。
①KPT(Keep, Problem, Try)
やり方の一例
１．個人でKeep,Problemを考えて
２．順番に共有(くじ引きとかで決める)
３．みんなでTryをディスカッション⇒Agree
４．KPT会の振り返り
※反省会にならないように・・。問題解決会ではない。
②YWT(やったこと、わかったこと、次やること)
やり方の一例
１．個人でY,Wを考えて
２．順番に共有(くじ引きとかで決める)
３．みんなからWの追加をもらう
４．みんなでTをディスカッション⇒Agree
５．YWT会の振り返り
※七夕短冊にならないように・・。空想会ではない。
③仮説検証(仮説、結果、その差はなぜ生まれたか)
やり方の一例
１．予測をしておく、仮説を立てておく
２．結果を計る、気分を見える化する
３．時点、傾向、きっかけ
４．検証の振り返り
※批評会、愚痴にならないように。仮説にも目を向ける
④FDL(Fun, Done, Learn)
3領域のベン図を用いることが多い。
やり方の一例
1人でやる一例
１．今日の自分のF,Dを考える
２．それぞれからLを出す
３．Lの共通点を見つける
４．今日の学びにする
５．アウトプット(発信)する
※毎日やる、午前午後でやる、週末やる、月単位でやる
私が研修などでよく用いるのは、1．今日の研修で面白かったこと 2.今日の研修で行動したこと
3.、この1.2.からそれぞれ学んだこと→学びに共通点を見つけて、ベン図を構成する。
または、今日の研修の中で、そう思ったこと―思わなかったこと、行動に起こせること―起こせないことの2軸で
ベン図を構成する。

(18)リーンシックスシグマ

リーン：主に自動車業界で、ムダを無くす生産方式、管理方式として進化してきた。
シックスシグマ：主に電子部品、家電業界でムラを無くす生産方式、管理方式として進化してきた。
1.顧客の声から活動を始める
・Voice of Customerが品質を決める
・要求以上＝過剰品質、コスト掛かりすぎ
・要求以下＝品質低い
・・・品質って？
２.プロセスに焦点
・事象はプロセスに分解
・Visualize(見える化)
・ムダ、ムラ、ムリを探す
・人は悪くない
３.数学で客観的に判断
・暗黙知を形式知にする
・事実を数字化し客観的根拠にする
４.世界共通の用語
・DMAIC：シックスシグマの５段階改善ステップ
・Voice of Customer：シックスシグマが最初に考えること
・Critical to Quality：顧客満足の必須事項
・Project charter:プロジェクトの色々一覧
・SIPOC：プロジェクトのハイレベルプロセス見える化ツール
・Value Stream:材料から製品になるまでの流れ
・Value Stream Map:どこから誰がプロセスを踏むかフロー
５.組織改革できる人材育成
・チャンピオン
・マスターブラックベルト
・ブラックベルト
・グリーンベルト
プロセスのムダ無く ≒ ジャストな品質プロセスと品質の最高地点での両立。
そのために現場からマネジメントまで、同じ判断できるようやり方もムダ、ムラ、ムリを排除する。

(19)法則の詰め合わせ

・不確実性コーン
・パーキンソンの法則
・二八の法則
・VUCA world
・SECIモデル
・タックマンモデル
・バイ+A354モーダルIT(SoR、SoE)+A422

ふりかえり：前々からプラクティスに集中した内容をやりたかったので、これがようやくできて嬉しい。
単発で伝えることもできるが、プロジェクトの流れに合わせて、普段の業務や仕事に取り入れられるように配慮し説明したことで、
満足度も高かったように感じた。

⑥アジャイル基礎知識発展・応用

Agile、Scrum、CI/CDとTDD、DevOpsとBuisinessの4領域について、更に深い知識をカバーする。

(1)アジャイル

・4つの価値と12の原則
・XPのプラクティスを例に12原則を解説
・AgileのValue drivenの考え方、QCDSの優先順位、人数とフェーズ、ExperienceとFail fast

(2)Scrum

3本の柱(透明性、検査、適応)
透明性とは正の情報が一ヶ所に集められ次の行動が自然と誘発されること。全員が同じ判断をできること。
検査とは潜在的に望ましくない変化や問題を検知するためスクラムでは5つのイベントでリズムを提供している。複数の軸からの仮説検証。
適応とは仮説または偶発から発生した事実を経験として蓄積すること。結果に基づき構成要素を調整する。
5つの価値(確約、集中、公開、尊敬、勇気)
確約とは英語のCommitment KPI, MBO, OKRで言うところのOKR
集中とは何かに集中するということは別の何かに集中しない
公開とは情報や意見を公開すること
尊敬とは個人とチーム、異なる意見や立場を尊重すること。
勇気とは正しいことを正しく実行する。正しくないことを正しくないと実行する。
3つのロール(PO、SM、開発者)
POはプロダクトのビジネス価値の責任者
SMはスクラムについての責任者
開発者はスプリントの責任者
5つのイベント
スプリントプランニングはスプリントの最初に実施される計画
デイリースクラムは毎日15分のチームの透明性を保つためのミーティング
スプリントレビューはスプリントの作成物をデモしたりフィードバックをもらい次のスプリントに反映させる
スプリントレトロスペクティブはチームの活動に焦点を当て、更に良いやり方にカイゼンしていくことを決めるミーティング
スプリントはこれら4つのイベントが入る期間で、スクラムでは最大4週間
3つの作成物
プロダクトバックログは価値を届け続けるために優先順に並べられたリストで、どんな内容も入れられる。INVESTの原則を満たす。
スプリントバックログはスプリントゴールを達成する目的で開発者が作業やりやすいように詳細化するリスト
インクリメントは前回のインクリメント＋今回のインクリメントで構成されスプリント終了時にはDoDを満たしてリリース可能で有効な機能が備わっている

(3)CI/CD,TDD

Continuous Integration / Continuous Delivery
開発とリリース、運用の高速ループ
TDD、完成の定義と、受入基準はプラクティスで説明した内容と同じ。

(4)DevOpsとビジネスフォーカス

BizDevOpsとDevSecOps
XPの計画ゲーム、ユーザーストーリーととINVESTについて

ふりかえり：このパートは何度か実績があり、準備の負担が少なかった。これまでの流れを活かしながら部分的に補足を加え、
1時間のサイズに収まるようにした。少し詰め込んだため、少しスピードが早かったかもしれないが、応用という意味で良かった。

さいごに

6週間Webinarを終えて
まずは参加してくださった方への感謝しかない。想定より多くの参加者がいて、非常に嬉しかった。
全て1時間から1.5時間のコースで資料準備は時間が掛かった。
ある程度既存資料を使いながら、今回用にアレンジして作り直した。
その甲斐あって参加者は毎回10-40名集まり、反応は上々だった。
自分としても知識の棚卸ができたし、開催した実績が、今後類似の説明機械に生かせると感じた。
全体向けのWebinarだったため、質疑応答は受けられたものの、個々の不明点に対しては、
充分に答えられたとは言えない。ただし開催後に個別質問をもらうことも多く、そこでケアできたと考えている。
今後も開催して欲しい要望も多く、続けていきたい。

最後まで読んでいただきありがとうございました。