継続的計画を探求する
継続的計画は、8 つの DevOps 機能の 1 つです。
継続的計画が必要な理由を探す
2000 年から 2005 年までに政府機関によって開発されたソフトウェア アプリケーションのケース スタディを見てみましょう。 このプロジェクトは、2005 年 1 月に正式に中止された時点で完成に近づいていませんでした。まったくの失敗でした。 1 億ドル以上を無駄にしただけではなく、この失敗によって政府機関と責任者に対する批判が広がりました。
2 つ目のプロジェクトは 2006 年に開始しましたが、同様のひどい結果に終わりました。 この 2 つの取り組みでは、事前の大規模な設計とウォーターフォール開発手法が使用され、昔ながらの計画済一括導入型の稼動開始イベントも含まれていました。 これらは何も達成できず、数億ドルを無駄にして終わりました。
これらの試みはなぜ失敗したのか
- 事前の規模な設計 – 200 人のチームが 6 か月かけて要件を作成しました。
- 優先順位の変動 – プロジェクトの途中で災害が発生して、対象範囲が大幅に変更されました。さらに 300 人のチームが 6 か月を費やし、600 ページの要件が作られました。
- 無駄な作業とやり直しのために、期限に間に合わず、チームは疲弊しました。記述された 700,000 行のコードが書き直されました。
2010 年 12 月に、スクラム スタジオが同じ場所に設置されました。 スタッフは、元のプロジェクトの 400 人から 40 人に削減されました。 設計は、600 ページの要件から 670 のユーザー ストーリーに変わりました。 このチームは 2 週間ごとにコードを提出して新機能のデモを行いました。 何回かのスプリントの後で、大まかなタイムスケールを予測して、漸進的な業務変革を計画できるようになりました。 コードは 2011年 12 月に完了しました。
細部の計画が難しいのはなぜか
Alan Turing が第二次世界大戦中に開発した機械によって、エニグマと呼ばれた暗号機が解読されました。
Turing は命を救うために常に新しい暗号を解読しなければなりませんでした。 Turing は、複雑さが無限のように見えても、あきらめませんでした。細部を解明できれば、大きな成果を出せることがわかっていたのです。
「私たちには少し先のことしか見えませんが、そこには果たすべきことがたくさんあるのです。」
大規模なソフトウェア プロジェクトは常に複雑です。 しかし、複雑さに圧倒されないでください。 代わりに明確な部分を実行します。つまり、短期間ごとに進めます。
OKR (目標と成果指標) に基づき、明確な方向性、フォーカス、および機敏性を備えた、継続的かつ効果的な計画
継続的計画を定義する前に、重要な概念とフレームワークを紹介します。これらは、明確な方向性、フォーカス、機敏性を備えた、継続的かつ効果的な計画を進めるうえで役立ちます。
目標と成果指標 (OKR) は、リーダーによって設定された戦略的な目標と、実行チームの日常的なアクティビティを結び付けるための目標設定フレームワークです。
重要
OKR によって、最適な結果が特定され、本当の成功がどのようなものかが明確になります。
OKR は、通常、フォーカスを絞って機敏性を高めるために四半期ごとに設定されます。
目標は方向であり、主要な結果は測定可能である必要があります。 最後には、議論しなくても、見るだけで、達成したか達成しなかったかがわかります。 Yes か、 No です。 シンプル。 判断は含まれません。
OKR は、位置付けと透明性を示すために組織内のすべてのチームにローカライズされます。
OKR とは何か
OKR の 3 つの重要な側面は次のとおりです。
明確な目標を定義して、組織のあらゆるレベルで意図と方向性を明確にするためのフレームワークを作成します。
測定可能な成果指標によって強化されます。 成果指標とは、成功を測定するための成果です。
アウトカムの考え方の文化を促進し、アウトプットの考え方からアウトカムの考え方に転換できるようにします。
OKR の例
OKR の例を次に示します。
目標: 1970 年までに宇宙飛行士を月に着陸させます。
成果指標:
- 1965 年までに 40000 ポンド未満の宇宙船を建造します。
- 1967 年までに月着陸に備えて宇宙飛行士を訓練します。
- 宇宙船の月着陸が成功します。
- 宇宙飛行士を安全に地球に帰還させます。
この OKR の例では、1970 年までに月に宇宙飛行士を着陸させるという目標つまりゴールが設定されます。
Note
目標は、わかりやすいこと、明確な方向性を定められること、やる気を与えることが必要です。
この例では、成果指標は進捗の測定です。これによって目標の成功が測定されます。
Note
成果指標は、測定可能であり、目標を達成する方法を特定するものであることが必要です。
OKR の主な利点
OKR には 5 つの主な利点があります。
- フォーカス: すべての目標を 1 行に収める必要があります。 成果指標は目標ごとに 5 つまでしか設定できません。
- 位置付け: マネージャーや共同作成者などが、日常のアクティビティを組織全体のビジョンに結び付けます。 この結び付きを表す言葉が位置付けです。この価値は計り知れません。
- コミットメント: 全員による合意を確実に実現できるように、スケジュールとリソースが調整されます。
- アウトプットからアウトカムまで OKR を追跡することが、目標別の管理が一流の企業に広く普及している理由です。 すべての OKR は、作成時に設定されたメトリックを介して追跡できる必要があります。
- 拡張: OKR によって組織は本質的に後押しされ、可能と考えられていたことよりも少しだけ上を目指そうとします。
継続的計画と静的計画を比較する
継続的計画とは、プランナー、アーキテクト、アジャイル チームが、企業全体で継続的に計画を統合する必要がある方法です。
継続的計画では、スクラムベースの計画方法と新しい設計によって、チームが計画を実行可能なレベルまで改良することができます。
計画の概要が、変更に対する回復力があるが、明確なビジョンと目的に対応できることが重要です。
ウォーターフォール開発手法とアジャイル開発手法のトレードオフの鉄の三角形によって、継続的計画と静的計画の比較が示されます。
静的な方法では、スコープの計画は固定されています。 プロジェクトにかかる時間とかかるコストを決定します。
継続的計画の原則を使用するアジャイル手法では、時間はビジネスの目標を達成するために固定されます。 交渉の余地があるのはスコープだけです。
通常、鉄の三角形では、時間、リソース、機能が示されます。 Gartner は、この図に品質を追加しました。期間とコストは相関しますが、品質が見逃されることが多いためです。
しかし、これら 2 つの実践方法の成功率はどうでしょうか。
アジャイル プロジェクトの方が成功している理由の 1 つは、小規模なバッチ リリースによって知識を得る機会が増えるためです。
次の 4 つのことに注意してください。
- ビジネ スニーズは、常に変化しており、突然に変化します。
- アジャイルには、ビジネスの変化に対応するための計画メカニズムがあります。
- 高パフォーマンスのチームは、間違った方向にすばやく簡単に進む可能性があります。
- 知識を得ることでリスクが軽減されます。
ウォーターフォール手法とアジャイル手法には両方とも課題があります。 ただ、アジャイルは 30% 以上の確率で成功しています。
継続的計画の 6 つの原則を探求する
継続的計画には 6 つの原則があります。
- わかりやすさを尊重
- アジャイル ソフトウェア開発宣言
- 設計の考え方
- 反復的なインクリメンタル型開発
- リーン管理
- 推定精度
継続的計画の原則 #1: わかりやすさを尊重
継続的計画の最初の原則は、わかりやすさを重要視することです。
「もし、ものごとを簡単に説明することができないのであれば、十分に理解していないということだ。」
-Albert Einstein
継続的計画の原則 #2: アジャイル ソフトウェア開発宣言
継続的計画の 2 番目の原則は、アジャイル ソフトウェア開発宣言です。
この宣言はソフトウェアの提供に関するものです。 ソフトウェア開発に関するものであり、プロジェクトの管理や設計に関するものではありません。 これは継続的計画および DevOps の根底にあります。
これを実践すること、および他の人が実践するように支援することで、ソフトウェアを開発するより優れた方法を明らかにしています。 この取り組みを通じて、次の価値観に到達しました。
- 個人および対話 (プロセスやツールよりも)
- 動作するソフトウェア (包括的なドキュメントよりも)
- 顧客とのコラボレーション (契約交渉よりも)
- 変化への対応 (計画に従うことよりも)
継続的計画の原則 #3: 設計の考え方
継続的計画の 3 番目の原則は、設計の考え方です。
設計の考え方では、イノベーションに対して人間中心のアプローチを採用しています。 これは、存続可能性、実現可能性、望ましさが交差する部分に焦点を当てて、境界を確立し、無駄を減らします。
継続的計画の原則 #4: 反復的なインクリメンタル型開発
継続的計画の 4 番目の原則は、反復的なインクリメンタル型開発です。
場合によっては、何が得られるのかわからないという心配があります。 反復的な開発では、反復的なフィードバック ループで利害関係者に要件や優先事項をゆだねることで、この問題が解決されます。 各反復は、完了しており、使用可能であり、ユーザーにとって役立ちます。 さらに機能が追加されますが、できれば重要な機能から先に追加します。
継続的計画の原則 #5: リーン管理
継続的計画の 5 番目の原則は、リーン管理です。
価値は、エンド カスタマーの観点から定義されます。 このプロセスでは、バリュー ストリームが特定され、価値が顧客に提供されないステップは無駄として識別されて削除されます。
プロセスが再び開始し、継続的改善を使用して完璧な状態を目指します。
継続的計画の原則 #6: 見積もりの精度
継続的計画の 6 番目の原則は、見積もりの精度です。
見積もりとは、何かを行うための所要時間、かかるコストの金額、または提供可能な機能数について分析的に予測することです。 2 つの属性 (精度と有効桁数) がありますが、これらの間にはまったく関係がありません。 見積もりはエンジニアリング チームによって所有されます。
ターゲットとは、どれくらい時間をかけるのか、どの程度コストをかけるのか、どれくらいの機能を提供するのかという、ビジネス ニーズの提示です。 ターゲットはビジネスによって所有されます。
コミットメントは、特定の期日までに機能と品質を提供する約束です。 コミットメントは共同で所有されます。
重要
継続的計画で目指すのは、見積もり、ターゲット、コミットメントの間の均衡を維持することです。 そうしないと、組織内外の期待に応えることはできません。
OKR とスクラムの関係を説明する
OKR の 理由と内容だけでなく、継続的計画についてもある程度理解したところで、2 つの関係について見ていきましょう。
OKR のような手法を使用して作業を構造化すると、少なくとも短期的には不確実性が低下します。 OKR はカスケード形式で定義されるため。最初に変わるのは、マネージャーが管理スタイルをどのように示すかということです。
OKR のような手法は、権威主義的な管理スタイルから脱却するためのすばやく効果的な方法です。
