なんどもご来訪くださりありがとうございます。わたしたちにお手伝いできることはありませんか?ぜひご意見やフィードバックをいただければ幸いです。
チームの成熟度をみるのは難しい
アジャイルやDevOpsでは、「チーム」がとても重要になります。共通の目的とゴール、やり方を共有し、相互補完するのがチームです。それに対して、チームではない集まりを「ワークグループ」という言葉で区別したりすると少しばかりわかりやすくなるでしょう。
チームとワークグループの違いなどはこちらの資料も参考にしていただけるとうれしいです。
チームとは、「同じ景色をみている」と考えると見通しがしやすくなるのでおすすめしています。
さて、チームがどれくらい成熟しているのかをみるのは簡単なことでしょうか?実際には、チームもナレッジワークも目に見えないため、これらの成熟度を見る、測るのはとても難しいです。
目に見えないものをどうみえるようにするのか
目に見えないものに対して、どのようにみえるようにするのかというと、「態度」と「振る舞い」をみていくしかありません。また、「状態」がわかるようになるととてもわかりやすくなるでしょう。
したがって、「状態」を定義して、それらの状態とは、どのような「態度」や「振る舞い」があるのかをカテゴライズできれば、そこから自分たちの「状態」を推し量ることができるかもしれません。
「態度」や「振る舞い」の土台にはおそらく「マインドセット(考え方)」があります。ただ、マインドセットもまた目に見えないものなので、そこは気をつけてください。
DASA DevOpsコンピテンシーモデル
ここでは、そんな指針となる成熟度モデルを紹介します。それが、「DASA 成熟度モデル」です。
私がアンバサダーを務めているDASAでは、DevOpsに関するコンプテンシーモデルを定義しています。
スキルエリア | ナレッジ(知識)エリア |
---|---|
勇気 | アーキテクチャと設計 |
チーム構築 | 事業価値最適化 |
DevOpsリーダーシップ | 事業分析 |
継続的改善 | テスト仕様作成 |
プログラミング | |
継続的デリバリー | |
セキュリティ・リスク・コンプライアンス | |
インフラストラクチャ・エンジニアリング |
また、それぞれに対して、レベル感が定義されています。
- レベル1 - 入門
- レベル2 - 初級
- レベル3 - 中級
- レベル4 - エキスパート
- レベル5 - マスター
スキルエリア、ナレッジエリアのそれぞれについて自分やチームがどのレベルにあるのかを知ることができれば、その後の育成や熟達に役に立つはずです。少なくとも、目標を持って自律的に進めていくきっかけにはなります。
ちなみに、DASAでは、以下のように研修と認定資格が設定されています。
- ファンダメンタル: 全項目で初級(レベル2)
- プロフェッショナル: ファンダメンタル + 各専門領域の項目で中級(レベル3)
- DevOpsチームメンバー全員: エキスパート(レベル4)を目指す
このように、目標をできるだけ定められ、かつ、実効性があるとチームは結束しやすく、相互作用が促進されます。
QuickScan
DASAでは、各自がセルフチェックでどのレベルに達しているかを理解する QuickScan を無償提供しています。これを実施することで、レーダーチャートにてご自身のレベルを知っていただくことができます。英語ですが、5分以内にできるくらい簡潔なものです。
成熟度モデル
先述したように、項目とレベル感がわかったとしても、自分やチームの状態はなかなか判断できないものです。そこで、DASAでは、成熟度モデルを公表しているのです。
Get the DASA #DevOps Maturity Modelhttps://t.co/08v4Xe9Prm
— DevOps Agile Skills Association (DASA) (@dasa_org) December 31, 2018
✅ Helps organizations define demand in a standard way
✅ Clear Definitions for each step in the DASA Competence Model
✅ Clear Guidance of the effects on the Teams and the Leadership pic.twitter.com/O03uTx45nI
先に紹介した QuickScan の結果を PDF で入手ができるようになっていますが、そこからこちらの成熟度モデルの表を入手することができます。
成熟度モデルで重要なのは、項目やレベル感ではなく、どのような状態であるか、そこでの態度や振る舞いがどんなものであるかです。それらをわかりやすくしたのがモデルであるに過ぎません。従って、モデルから推察するより、状態や態度・振る舞いからモデルを理解するのが大切です。
DASAの成熟度モデルをざっくりと振る舞いと態度で提示してみましょう。
スキルエリア
\ | 入門 (L1) | 初級 (L2) | 中級 (L3) | エキスパート (L4) | マスター (L5) |
---|---|---|---|---|---|
勇気 | リスクを回避 | リスクの取り方がわからない | 注意しリスクを積極的に取ろうとしている | 実験をしている | 実験が業務の仕組みに組み込めれていて顧客価値向上に活かされている |
チーム構築 | 分業による個人作業 | 個人作業が限界という認識がある | 立ち位置を理解し、説明責任を果たしたい | 同じ景色を見ている | 景色を改善し、外部にも説明できる |
リーダーシップ | 作業指示待ち | 指示されてふりかえる | 全体を見通せ、リーダーシップを発揮 | プロダクトのオーナーシップを持つ | プロダクトだけでなく、組織も改善する |
継続的改善 | 火消しモード(起こってしまってから考える) | 個人頼み | 現在と望ましい状態を理解して問題解決する | 問題自体を探している | 小さな改善と大きな問題解決が同居 |
チームの成熟度だけでみると、タックマンモデルが有名ですが、DASAのスキルエリアにおける「チーム構築」でみると、[形成期]や[混乱期]は中級(L3)にマッピングできます。また、[統一期]や[機能期]は、エキスパート(L4)にマッピングできます。
ナレッジエリア
\ | 入門 (L1) | 初級 (L2) | 中級 (L3) | エキスパート (L4) | マスター (L5) |
---|---|---|---|---|---|
事業価値最適化 | 事業部門の要求を鵜呑み | 早期に顧客関係構築したいが困難 | 初期フィードバックを設計 | 積極的で頻繁な顧客フィードバックが健全性と開発計画を生むことを理解 | ユーザーと共に価値提供を最適化 |
事業分析 | 事業部門の仕事と認識している | 顧客がバックログを作り、チームが管理する | チームと顧客の共同作業 | サービスのすべての局面(機能・非機能)の意思決定をチームと顧客で進める | チームと顧客の共同責任であり、チームの能力を最大限に活用して価値を最大化する |
アーキテクチャと設計 | アーキテクチャを個別にルール化 | 専任のアーキテクトがいる | アーキテクチャ検討はチームの責任 | 合意したアーキテクチャにより技術的負債を戦略的に対処 | アーキテクチャ検討がチームのプロセスに組み込まれている |
プログラミング | 開発者の(属人的な)責任 | 開発と運用で活かせる言語やプラットフォームを管理する方針が乏しい | 開発と運用のツールやリポジトリを合意し、知識とスキルに投資 | フルスタックを意識してツールとコード化を推進 | 開発文化が組織に浸透(みんなコードが書ける・理解できる) |
継続的デリバリー | DTAP*のパイプラインが曖昧で分離 | バージョン管理と自動ビルドが備わり、自動デプロイできるが、継続的デリバリーの原則は限定的 | CIによるE2Eビルドで単一ビルドの実装が可能であるが、継続的デリバリーの原則は規則的に適用 | インフラ含めほとんどの検証とE2E自動デプロイが可能なパイプラインがある | 「作業完了=本番リリース」の考えで作業し、頻繁に実施できるようにしている |
テスト仕様作成 | テストはテスターで | 静的コード分析と単体テストの自動化 | 定期的に関係者向けのデモを実施、テスト駆動と自動機能テストが定着 | TDDとBDDがチーム主導で実施され、非機能も規則的にテスト自動化できる | テストは必須。ビジネス駆動で自動テストがあたりまえ |
インフラストラクチャ・エンジニアリング | インフラ設定は限定された人だけに許可 | プラットフォームチームが責任 | 冗長化とプロビジョニング設定の自動化(手作業NG) | 状態監視含めセルフサービスポータルを活用。イミュータブルを活用 | インフラをコードで定義し、容易に調整可能なテンプレ化により、セルフサービスで提供される |
セキュリティ・リスク・コンプライアンス | プロセス後に制御ステップとして設けられている | 専門組織が対応 | チームの責任であり、相互作用で定義と実行を行う | アーキテクチャの一部として考える | チームのプロセスに統合されており、チームが外部規制も意識している |
DTAP: 開発・テスト・受け入れ・プロダクション
それぞれを見ていくと成熟度が上がると、チームで当たり前に実施をできるようになっているのがわかります。また、マスターレベルになると外部規制や組織の制約も吸収できる柔軟性が自己組織化と機能横断で培われているのもわかります。
個人で見るものではない
見ての通り、これらは個人でできているかを見てもあまり意味がありません。チームで成熟度を測る方がはるかに建設的です。また、組織がこれらを意識することで、組織や組織文化に変化をもたらすことが期待できます。あなたはどのようにこの成熟度モデルを活かしますか?ぜひ意見を聞かせてください。
日本語版の成熟度モデルをDASAアンバサダーで翻訳しました。現在は、イベントや個別での配布を行なっています。
もしこの投稿を見て日本語版を欲しいと思った方は、個別にリクエストをしてください。
DASA DevOps 研修
私は、DASAアンバサダーでもあり、DASA DevOps 研修の認定トレーナーでもあります。さらに言うと、DASA DevOps ファンダメンタルコースの監修者でもあります。また、サーバントワークスでは、DASAとのトレーニングパートナーシップに基づき、DASA DevOps ファンダメンタルコースを、一社様向け集合研修や、公開研修で提供しています。
DASA DevOps ファンダメンタル認定研修
一社様向け集合研修開催日時 | コース |
---|---|
2024年11月11日 〜 2024年11月12日 (申込み期日: 10月30日) |
|
2024年12月5日 〜 2024年12月6日 (申込み期日: 11月26日) |
|
2025年2月6日 〜 2025年2月7日 (申込み期日: 1月28日) |
|
2025年3月13日 〜 2025年3月14日 (申込み期日: 3月4日) |
本記事の著者:
長沢 智治
サーバントワークス株式会社 代表取締役。NOTA Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。
『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。