第23章 より効果的なアジャイル:導入
6つの要素
■ビジョン
■コンセンサス
■スキル
■リソース
■インセンティブ
■アクションプラン
素人的には的を射ていると思いつつ、MECE(ミーシー)なのかというと、ダブりこそあまり感じないがモレはないのだろうか…?となる。他の人の意見が聞きたい。個人的にはカルチャー的な、「挑戦や変革を許す文化」も要るかなーと思ったけど、「要素」ではないのかもしれないとも思った。
MECEかはわからないですね。。。論文か何かを読むと背景がわかるかも?いい整理だなとは思えるくらいの感じ。
アジャイルの導入をとは思うけど、部署内にはほとんどいないので、自分がこれを揃えて示すと考えると厳しい。逆に開発の標準化で自分が納得できない理由がこのあたりにありそうな気がしてきた。
スクラマーフォール(p262中部)
思わず笑ってしまった、皮肉が効いてる
さいきん?(2019くらいからは)これの代わりに、"ハイブリッドアジャイル"って聞くようになったなー
うちの組織はウォーターフォール(実際にはシーケンシャル開発っぽい感じ)でやるって言ってるだけまだましか…
ソフトウェア開発がスキルに基づく知的な作業であることを考えると、ソフトウェア変革に必要なリソースの種類には、トレーニングを受ける機会、コーチングを受ける機会、ツールのライセンスなどが含まれる。
こういった整理をうまくできるようになりたいなーって常々思う。
インセンティブは金銭的なものであるとは限らないし、有形のものである必要もない。(p263下部)
たしかになぁとなった。言葉の印象からして賞与とかそういう系だと言う先入観があった。
これを見えるようにするためにも、お互いの価値観とかふだんの楽しさとか辛さとかを共有できていることって大事だよなーっておもうなどした。
アジャイルチームを支援するのに最もふさわしいリーダーシップスタイルは、目的を定期的に伝えることである。(p264上部)
おおっ、となった。というのも、この前のDevOpsDays Tokyo 2022でクリエーションラインの社長さんとクラスメソッドの社長さんが一番言ってたことだったから。
イノベーション 導入 過程 は 標準 正規分布( 釣鐘 曲線) で ある。 イノベーター は 平均値 から 3 番目 の 標準偏差 で あり、 アーリーアダプター は 2 番目 の 標準偏差 で ある。 これら 2 つ を 合わせ ても、 アダプター 全体 の たった 15% にしか なら ない。
忘れがち。イノベータばかりいる環境で提案して上手く受け入れられて(コミュニティ)、現場に盛っていくと抵抗に遭うというのは、あるある
ただ、単純に現場のコンテキストを正確につかめておらず的外れな提案をしているだけの可能性もある
トレーニング や コーチング は 業務 時間 内 に 行い、 新しい チーム への ロールアウト に 取り組む ため の 時間 を 設ける。
これ、あまり賛同を得られたことがない。
トレーニングは業務外にやりたい人が楽しんでするもの、という風に言われた時、うーんたしかに分からなくもない。。ともなりがち
検査
■ドミノ変革モデル自体、そしてこのモデルが過去または現在の変革イニシアティブにどのように当てはまるのかを確認する。あなたの組織はこのモデルのどの部分で成功しているだろうか。どの部分に改善の余地があるだろうか。
一応、小さな組織として、自分の所属するチーム月面着陸に対して行うと、コンセンサスはすぐに取れる。ただ、それ以外の5つ全てで改善の余地があるように思える。なにか新しいことを導入しようとする時、ビジョンが明確な時とそうでない時がある。スキルは往々にして足りないこと多い。リソースにおいても、チーム外の力を借りるなどといったことができていない。インセンティブは個々が経験になるというくらいしかない。アクションプランはひどく不明確である。
ビジョン 分かるような分からないような(はっきり主張する時と何か濁す時がある), コンセンサス OK, スキル NG(自分以外はスキル不足に苦労している様子はない), リソース OK, インセンティブ あまり考えたことなかったがOK?, アクションプラン OK
ビジョン OK, コンセンサス OK, スキル NG, リソース OK, インセンティブ OK, アクションプラン OK。ただし、スキルのところは現在改善中。
■イノベーションの普及モデルと、このモデルがパイロットチームによる組織の過去の記録とどのように符合するのかについてじっくり検討する。パイロットチームがイノベーターとアーリーアダプターで構成されていることに間違いはないだろうか。それらの人々はあなたの組織をどのように代表しているだろうか。
小さな組織に当てはめると、確かにパイロットメンバーはイノベーターとアーリーアダプターで構成されている。チームメンバー全体に普及するのはなかなかできていない。
おおむねこの形にはなっている。
これはかなり意図的にこの形を会社が作っているのを感じている。ただ、パイロット的な役割を担う人は大体決まっているので、森さんがRSGTで言っていたように太い経験/細い経験の話が出てきがち。
適応
■現在のアジャイル導入とドミノ変革モデルのカテゴリとの間でギャップ分析を行い、それらのギャップに含まれているパフォーマンスを向上させる計画を立てる。
やってみたい、すごくやってみたいが最近の忙しさで手が回らなさすぎる。持ち帰ってはおこう。
日本企業はインセンティブ、リソースの問題が多いなーっていう印象。
観点として持っておくのは面白そうだが、影響やリーダーに対する印象が出ているからと言って、安易に欠如している要素を決め打ちしないようにしたい。
■より後期のアダプターに対する現在の支援とイノベーションの普及モデルの間でギャップ分析を行い、より後期のアダプターに適したレベルの支援を提供する計画を立てる。
適応の1つ目と同じく、手が回らないが持って帰っておこう。
重要だと思うのでぜひやりたい。ある程度思考停止でも船に乗れるように、型を決めて置いた方がいいんだろうなあという感想。
真似をすると安全だという人たちのために、たくさんのモデルやガイドラインを揃えておくことが重要になる。自分での考えた根拠よりも、誰かが考えてくれた根拠に依存したいので。