スローガンやバズワードから行動や価値へ
CEOがズキズキするこめかみをさすっています。デジタル・ディスラプションが彼の頭痛の種になっているのです。デジタルトランスフォーメーションの話や、競合他社が新しい「DevOps」の働き方でビジネスを奪っているという話ばかりです。――「DevOps」が何を意味するのかはともかくとして――このようなトランスフォーメーションのことは気にせず、IT部門が何ヶ月も前から約束してきた新しいIT製品を市場に提供できれば彼は喜ぶことが出来るでしょう。
さらに、チームが自宅で仕事をしていても納品しなければならないという状況はより悪化しているように見えます。
CEOは、オフィスの壁に貼られた「DASA DevOpsの原則」のポスターを見ています。彼はそれを読んで、これは壁に貼られたただのスローガンやバズワードなのか、それとも行動を促す価値観を表しているのか」と自問しました。
CEOは自ら遠隔地のPhoenix Projectのオンラインシミュレーションセッションを聴講し、チームのパフォーマンスを確認しました。それは「Go to Gemba」、つまり実際のプロセスを見に行くというものでした。彼は原理原則の文章を見て、自分が聞いていること、見ていることと照らし合わせて見ました。
原則 1: 顧客中心の活動
「…. 現在、実際の顧客やエンドユーザーとの短いフィードバックループを持ち、IT製品やサービスを構築するすべての活動が、これらの顧客を中心に行われることが必須となっています。このような顧客の要求に応えるためには、DevOps組織は、リーン・スタートアップとして行動する熱意が必要です。継続的に革新を行い、個々の戦略が機能していない（あるいは機能しなくなった）場合にはピボットを行い、最大レベルの顧客感動（Customer Delight)を得られるような製品やサービスに常に投資をします。」
「顧客感動！」。CEOは納得しました。それは、彼がいつも聞いている、リリースの遅れや動作しないものについての苦情とは違うものです。
CEOが見たもの:
彼は、プロダクトオーナーやビジネスマネージャーが、最新の「お客様」向け機能の導入を主張しているのを聞きます。それは本当に市場が求:めていることなのでしょうか？と自問しています。また、あるチームメンバーによると、バックログ上に「技術的負債」があり、それが「また」無視されようとしています。もし自分が顧客だったら、あまり嬉しくないだろうな」とCEOは自分に言い聞かせ、プロダクトオーナーとチームが実際にフィードバックを得るためにどれだけの時間と努力を費やしたかを考えました。「そんなことをしている暇はない！」という酷い声がたくさん聞こえてきました。(フィードバックの収集について）。CEOは、この原則が、戦略がうまくいかない場合の「ピボット」についても言及していると考えました。彼は、チームは戦略が何であるかを知っているのか疑問に思いました。ふりかえり:
CEOは、シミュレーションワークショップの最後に、チームがいくつかの発見をし、原則を行動に移すためのアクションを獲得したことを喜んでいました。- 顧客やユーザーと定期的に関わり、本当のニーズが何であるかを確認します。新たなイノベーションと現在使用しているものの観点です。： ニーズを把握、可視化し、優先順位をつけます
- 戦略がどのように顧客ニーズの実現を可能にするのか、顧客ニーズの変化がどのように戦略決定に影響するのかを理解します。 ：戦略目標を可視化し、目標達成を可視化します
- 優先順位付けと意思決定の仕組みが、これらの戦略目標に沿っていることを確認します
原則 2: 目標を意識した創造
「…. 組織は全体像を見渡すことなく各ユニットや個人が特定の役割や機能のためだけに働くウォーターフォール型やプロセス指向型のモデルから脱却する必要があります。組織は実際の顧客に販売される実用的な製品の構築に明確に焦点を当てた、プロダクト焦点型組織として行動する必要があり、すべての従業員は、それらの製品を構想し実現するために実際に必要とされるエンジニアリングマインドセットを共有する必要があります….」
CEOが見たもの:
CEOはチームがバーチャルボード上の「やるべきこと」のオンラインバックログを埋めていく様子を見ていた。彼らは、製品を実現するための「バリューストリーム」における「フロー」の最適化について話していました。CEOには、彼らが「価値のあるアイデア」よりも「機能を実装する」ことや「ビルドや実装」の流れについて多くを語っているように見えました。 CEOの頭の中には、仕事の種類と価値の種類の絵が浮かび始めていた。「ユーザー機能」のような価値を生み出す仕事、「欠陥」や「技術的負債」対応のような価値を流出させる仕事、「阻害要因」や「無駄」を排除するような改善の仕事。しかし、彼はチームが可視化したこれらのもの全てをを見ることができなかった。彼は、ボードに書かれた彼らの指標である「リリース数」や「リリースまでの時間」を見て、いくつの機能がリリースされたのか、どの技術的負債が解決されたのか、あるいは無視されたのかを確認しました。彼は増え続けるバックログを見て、これらすべてがどのようにビジネスゴールやビジネスバリューの最適化に関連しているのかを考えました。彼はこのボードの全体像を見失っていました。これでは状況を把握することもできないし、これらの作業に優先順位をつけるための正しい判断もできない」と彼は思った。恐らく、この活動の中にビジネスは含まれていないでしょう。所謂、これはDevOpsと呼ばれるものであり、BizDevOpsではないのです。このことから、彼は原則1について改めて考え、戦略がうまくいかない場合にはピボットすることができるようにしました。仕事と戦略の間に適合性がなければ、どうやってピボットのタイミングを知ることができるだろう」と彼は考えました。..ふりかえり:
今回もCEOは、シミュレーションの最後に、チームがいくつかの発見をし、原則を行動に移すためのアクションを獲得したことを喜んでいました。- エンドツーエンドの価値の流れを理解し、流れを最適化して障害や無駄を取り除く ：価値の流れをマッピングし、無駄や障害を取り除く優先順位を決める
- 流れが必要な作業の種類を理解し、それらがどのように価値創造（例：新機能）に貢献するか、また価値の漏出（例：技術的負債、欠陥）をしているか、そしてアジャイルであることを可能にし、ピボットができるようにする作業（例：改善）を理解する ：バックログにある作業の種類を分類する。戦略的目標とこれまでの目標達成度をチェックする
原則 3: エンド・ツー・エンドの責任
「…. 従来の組織では、ITソリューションを開発し、それを運用に渡して展開と保守を行っていましたが、DevOps環境では、チームはコンセプトから墓場まで完全に責任を負うように垂直に組織されています。これらのチームが開発、提供したIT製品やサービスは、安定したグループの責任下にあります。また、これらのチームは、製品の寿命が尽きるまでパフォーマンスサポートを提供し、これにより責任感と製品の品質を大幅に向上します。」
CEOが見たもの:
CEOは、組織がサイロ化されていることに気づいていました。プロダクトオーナーと開発チームは、「ユーザー機能」（顧客中心）と「製品の構築」（フィードバックが少ない状態）に集中していました。彼らは「製品の動作」の優先順位を下げており、「技術的負債」、「欠陥」や「障害物」の除去を優先していませんでした。運用担当者は、「製品の動作」、「停止」、「SLA」について話していました。CEOは、それがまだサイロな考え方であり、サイロ化された各チームがそれぞれ守るべきKPIを持っていることに気づきました。彼らはエンド・ツー・エンドで創造していなかったのです。ふりかえり:
今回もCEOは、シミュレーションの最後に、チームがいくつかの発見をし、原則を行動に移すためのアクションを獲得したことを喜んでいました。- コラボレーションには、「共有されたゴール」（例：戦略的ゴール）だけでなく、「サイロ化されたゴール」（例：リソースが共有され、他のゴールを持つチームへのハンドオフが発生する場合）も理解する必要があります ： 課題を特定するために、目標、共有、チーム、スプリントゴールを可視化します。
- 仕事の種類と優先順位のバランスを取ります ：目標の可視化と現在の目標達成度を用いて合意形成します。-課題に対処するための明確な意思決定とエスカレーションの権限を確保します。
- 優先順位付けがエンド・ツー・エンドで行われ、効果的な意思決定を可能にするために情報が正確かつ完全に可視化されていることを確認します ：エンド・ツー・エンドのツールで、作業を受け渡す際に優先順位が明確になっていることと、必要な選択が明確に視覚化されていることを確認します。
原則 4: 機能横断的な自律型チーム
「…縦割りで完全に責任を負うチームを持つ製品組織では、ライフサイクル全体を通して完全に独立している必要があります。そのためには、バランスのとれた一連のスキルが必要であり、テスト、要件分析、コーディングなど特定の知識やスキルしか持たない旧来のITスペシャリストではなく、T字型のオールラウンドな知識やスキルを持つチームメンバーの必要性が強調されています。このようなチームは、個人の発展と成長の温床となります。….」
CEOが見たもの:
CEOは、チームが仕事の量に悩んでいることに気づきました。彼は、障害物やボトルネックによる制約を目にしましたが、そのうちの1つがスキルと引き継ぎに関連していました。しかし、チームがWIP（Work-in-Progress）と呼んでいるものは、顧客中心主義という短期的な目標を達成するために、増え続ける機能のバックログを減らすことに焦点が当てられており、長期的な目標（エンド・ツー・エンド）には焦点が当てられていないようでした。「機能横断的なチームを作ってハンドオフを減らさなければ、継続的に苦労することになる」そして「阻害要因に焦点を当てなければ、無駄や技術的負債とその影響は増え続けるだろう」とCEOは考えていました。チームには、WIPをどのように使うかを選択する自律性がないように思えました。自分たちは機能実装のスループットを最大化するためにプロダクトオーナーと正しいことをしていると思っていたのです。それは、「エンド・ツー・エンド」を持った開発と成長の温床ではありませんでした。バランスのとれたスキルセットが必要になります。技術的なスキルの組み合わせのことだけではありません。CEOは、チームが新しいエンド・ツー・エンドの仕事のやり方に苦労しているのを見ていました。エンド・ツー・エンドのバリューストリームで働き、自律的に行動し、継続的な学習と改善を行い、効果的なコミュニケーションとコラボレーションを行うことは容易ではありませんでした。お互いにフィードバックを与えたり、成長を助け合ったりすることも出来ていませんでした。すべてのチームが同じスピードで学習し、成熟できるとは限りません。チームが発展・成長し、新しい行動様式を定着させるためのコーチングも行われていないようでした。
ふりかえり:
今回もCEOは、シミュレーションの最後に、チームがいくつかの発見をし、原則を行動に移すためのアクションを獲得したことを喜んでいました。- チームのスキルとボトルネックのバランスを理解します。：必要な知識とスキルの成熟度（DASAのQuick Scanなど）を自己評価し、継続的な学習と改善のための時間を確保します。
- 新しい仕事のやり方を学ぶには練習と実験が必要です。：チームが改善できるようにコーチングを行い、コーチングのスキルを身につけます。
- フィードバックに対してオープンであり、安心して実験やフィードバックを行う必要があります：フィードバックをする練習をして、それを学習と改善のために使用します。お互いを非難する事はやめましょう！！
- プロダクトオーナーが業務内容のバランスを取り、学習と改善のチーム文化をサポートします ：プロダクトオーナーの役割と責任を変更します。DASAプロダクトオーナートレーニングの受講を検討してください。
- マネージャーは、自律的なチームを強化し、フィードバック、学習、改善の文化を形成する役割であることを理解します。そのためには、リーダーシップのスタイルや行動を変える必要があります。：DASAのリーダーシップ研修やOBM（組織行動管理）の受講を検討してください。
原則 5: 継続的改善
「エンド・ツー・エンドの責任とは、組織が変化する状況（お客様のニーズ、法律の変更、新しい技術の登場など）に応じて継続的に適応する必要があることを意味します。DevOps文化では、無駄を最小限に抑え、スピード、コスト、デリバリーのしやすさを最適化し、提供する製品/サービスを継続的に改善することに重点が置かれています。そのため、実験は重要な活動として定着させ、失敗から学ぶ方法を開発することが不可欠です。その点では、「痛いならもっとやってみる」という良いルールがあります。」
CEOが見たもの:
CEOはチームの内省を見ていました。無駄を省き、より多くのフィードバックを集め、クロストレーニングを行うなど、改善の必要性を明確に認識していました。彼はチームが自分たちでこのことを発見していることに喜びを感じていましたが、その改善のために確保されたWIPの時間はほとんどありませんでした。チームが実践し、実験し、改善するためのコーチングにもほとんど時間が割かれていませんでした。またしても「顧客中心主義」や「顧客の即時性」ではなく「機能」という誤った感覚やビジネス上で課せられたKPIが、間違った行動を刺激していたのです。欲求不満、他責の感覚、改善に必要な時間の不足は、リーダーシップへの信頼を損ない、実験の意志を抑えていました。もし「ピボット」の必要性があったとしても、「戦略が機能していない」のであれば、改善する能力が重要になります。ふりかえり:
今回もCEOは、シミュレーションの最後に、チームがいくつかの発見をして、いくつかの行動を取ったことを確認して喜んでいました。-
- エンド・ツー・エンドの内省、議論、改善を確実に行う ：エンド・ツー・エンドの関係者と共に改善のニーズを把握し、可視化する時間を確保します。これらに取り組むための時間を確保します。
- エンドツーエンドのバリューストリームにおける阻害要因と無駄を特定します ： バリューストリームと無駄をマッピングします。
- 非難のない環境で、継続的な学習、実験、改善の文化を育む ：プロダクトオーナーとマネージャーは重要性を強調し、チームに改善のための時間とリソースを与えます。
原則 6: 自動化できるものはすべて自動化
「…サイクルレートの高い継続的な改善文化を採用し、エンドユーザーや顧客からのフィードバックを即座に受け取るIT組織を作るためには、多くの組織がかなりの無駄を排除しなければなりません。幸いなことに、ここ数年、IT開発や運用において大きな成果を上げることができるようになりました。ソフトウェア開発プロセスの自動化（継続的インテグレーションや継続的デプロイを含む継続的デリバリ）だけでなく、インフラをバージョン管理してコードと同様に扱うことができる次世代コンテナベースのクラウドプラットフォームを構築することで、インフラ全体の自動化を考えてみましょう。自動化はチームがサービスを提供する方法を刷新する推進力と同義です。」CEOは、継続的な学習や改善への投資が不足していることや、フィードバックが不足していることが、無駄の特定や排除に役立っていないことをすでに認識していました。これは、迅速なPivotを行う上でのリスクでもありました。CEOは、チームが多くのアイデアを持っているが、それらがバックログにないことに気づきました。彼は、CICD、バリューストリーム、Infrastructure as Code、自動テストなど、自動化を利用してスピードを上げ、無駄を省く方法についての提案を聞きました。しかし、チームはこれらを全体像にマッピングし、ビジネスケースを作ることができませんでした。繰り返しになりますが、製品の機能と、収益、顧客満足度、四半期目標を達成するためのKPIが優先順位を決定していました。もし私たちが本当に「エンドインマインド」で業務を行うということは、長期的な価値のために短期的な価値を犠牲にしなければならないことを意味します。
- 余計な労力により多くの時間が無駄になっています。：それは反復的な手動タスクとミスからのやり直しなどです。：無駄な無駄な時間の量を可視化する必要があります。：無駄な時間を減らし、ミスを避けるために自動化する方法を検討します（自動テスト、コードとしてのインフラ、CICDなど）。
- チームが個々のチームのニーズを解決するためにツールに投資するため、ポイントソリューションへの投資が多くなっています。：エンド・ツー・エンドのバリュー・ストリームと特定された阻害要因を利用して、自動化できる領域を探り、バリュー・ストリームをサポートし実現するためのツールをマッピングします。
- 多くの良いアイデアが失われたり、無視されたりしています ： 阻害要因のバックログに、自動化によって可能になる改善点を追加します。 バリューストリームの各ステップをサポートするエンドツーエンドのツールを検討し、ハンドオフを自動化できる場所に合意します。
- 多くの場合、作業が中断したり、不足している情報を収集するために上流に戻ったりします ：上流と下流の情報ニーズを確認し、これらをエンドツーエンドのテクノロジーソリューションに組み込みます。IT4ITの概念を成功要因として捉えます。
今回のオンライン・シミュレーション・ワークショップでは、さまざまな収穫がありました。短期的な目標に戻ってしまうのか、それとも “エンドインマインド “を意識して行動するのか。”エンドインマインド “がどのようなものか、我々は全員が同じ戦略的ビジョンを持っているのでしょうか？