『DevOps実践ガイド』読書メモ(2)

DevOps実践ガイド

パート 2 どこから始めるべきか

組織内で DevOps 変革に向けた最初の一歩を踏み出すにはどうすればよいでしょうか? 誰が参加する必要がありますか? チームを形成するにはどうすればよいですか? チームメンバーがエネルギーを確実に投資し、成功のチャンスを最大限に高めるにはどうすればよいでしょうか? この章では、これらの質問に答えます。

このセクションでは次のトピックに焦点を当てます。

エントリポイントとして適切なバリューストリームを選択します。
変換されるバリューストリームの作業を理解する。
コンウェイの法則を参考にして組織構造を設計します。
バリューストリーム内の機能チーム間のより効果的なコラボレーションを通じて、市場指向の成果を達成します。
チームを保護し、力を与える

どのような変革も最初は不確実性に満ちています。私たちが計画している旅には素晴らしい目的地がありますが、途中のステップはほとんどすべて未知です。次の章は、思考と意思決定をガイドし、実行可能な対策とケーススタディを提供することを目的としています。

5. エントリーポイントとして適切なバリューストリームを選択します

DevOps 変革に適切なバリューストリームを選択することは、慎重に検討する価値があります。それは変革プロセスの難しさだけでなく、変革プロセスに参加する人々も決定し、チームの編成方法だけでなく、チームとそのメンバーが変革プロセスに最もよく参加できる方法にも影響します。

5.1 グリーンフィールドプロジェクトとブラウンフィールドプロジェクト

テクノロジーの世界では、グリーンフィールドプロジェクトとは、まったく新しいソフトウェアプロジェクトを指します。このようなプロジェクトは多くの場合、計画または実装の初期段階にあり、多くの制約なしでまったく新しいアプリケーションやインフラストラクチャを構築する機会を提供します。特にプロジェクトの予算やチームがすでに整っている場合、グリーンフィールドソフトウェアプロジェクトを開始するのは比較的簡単です。さらに、ゼロから始めるので、既存のコードベース、プロセス、チームについてあまり心配する必要はありません。

DevOps グリーンフィールドプロジェクトは通常、パブリッククラウドまたはプライベートクラウドソリューションの実現可能性を証明するため、または自動導入ツールや関連ツールの導入を試みるために使用されるパイロットプロジェクトを指します。

DevOps ブラウンフィールドプロジェクトは、何年、あるいは何十年にもわたって顧客にサービスを提供してきた製品やサービスです。このようなプロジェクトは通常、自動テストが行われていない、メンテナンスされていないプラットフォームで実行されているなど、多くの技術的負債を抱えています。ブラウンフィールドプロジェクトは、特に自動テストがない場合、または密結合アーキテクチャによりチームが独立して開発、テスト、デプロイできない場合、変革時に大きな障害に直面する可能性があります。

5.2 記録システムと対話型システムの両方を考慮する

バイモーダル IT とは、さまざまな種類のサービスの進化をサポートする企業の能力を指します。デュアルモード IT では、従来の記録ベースのシステムとは、ERP に類似したシステム (MRP システム、人事システム、財務諸表システムなど) を指し、そのトランザクションとデータの正確性が重要ですが、対話型システムを指します。電子商取引システムやオフィスソフトウェアなど、顧客または従業員向けの対話型システムに

記録システムは通常、変更が遅く、規制要件やコンプライアンス要件 (SOX など) があります。Gartner は、このタイプのシステムを「タイプ 1」と呼んでおり、「正しく行うこと」に重点を置いています。

インタラクティブシステムは、顧客のニーズを満たす最適な方法を見つけるためにフィードバックや実験に迅速に対応する必要があるため、すぐに変更されることがよくあります。Gartner は、このタイプのシステムを「タイプ 2」と呼んでおり、「迅速に実行する」ことに重点を置いています。

このような分割は利便性をもたらすかもしれませんが、「正しく行うこと」と「迅速に行うこと」の間には長年の矛盾があり、DevOps はこの矛盾を効果的に解決できます。

ブラウンフィールドシステムを改善するときは、複雑さを軽減し、信頼性と安定性を向上させるだけでなく、システムをより速く、より安全に、より簡単に変更できるようにする必要があります。グリーンフィールドインタラクティブシステムに新しい機能を追加するだけでも、それが依存するブラウンフィールドレコードベースのシステムの信頼性の問題が発生することがよくあります。下流システムがより安全な変更を行えるようにすることで、組織全体がより迅速かつ安全に目標を達成できるようになります。

5.3 革新に最も意欲的なチームから始める

どの組織でも、チームや個人が異なれば、イノベーションに対する姿勢も異なります。キャズムを越えるということは、障害を克服し、イノベーターやアーリーアダプターよりも大きなグループを見つけることを意味します (図 5-1 を参照)。
ここに画像の説明を挿入します
言い換えれば、イノベーターとアーリーアダプターは新しいアイデアをすぐに採用する傾向がある一方、他の人はより保守的です（アーリーフォロワー、レイトフォロワー、ラガードに分けられます）。私たちの目標は、DevOps の原則と実践を信じ、既存のプロセスを革新し改善する意欲と能力を備えたチームを見つけることです。理想的には、これらのグループが DevOps 変革のチャンピオン (チャンピオン、チャンピオン) になるでしょう。

私たちは、特に初期段階では、保守的なグループを改宗させることに多くの時間を費やしません。代わりに、成功を生み出し、リスクをいとわないチームに努力を集中し、そこから徐々に範囲を拡大してください (このプロセスについては次のセクションで説明します)。トップレベルのサポートがある場合でも、「ビッグバン」アプローチ (つまり、どこからでも始める) は避け、代わりにいくつかのパイロット領域に焦点を当て、それらが確実に成功することを確認してから、徐々に拡大してください。

5.4 DevOpsの範囲の拡大

どのようなエントリーポイントを選択するにしても、できるだけ早く結果を示し、積極的に宣伝する必要があります。大きな改善目標を小さな段階的なステップに分割します。そうすることで、改善の速度が向上するだけでなく、間違ったバリューストリームの選択を早期に検出できるようになります。エラーを早期に発見することで、チームは迅速にロールバックして再試行し、新しいエクスペリエンスに基づいて異なる意思決定を行うことができます。

達成された成功に基づいて、DevOps 計画の適用範囲を段階的に拡大します。リスクの少ない手順に従って、系統的に信頼性、影響力を高め、賛同を獲得します。

イノベーターとアーリーアダプターを発見する
サイレントマジョリティーを獲得する
「釘世帯」を特定する

組織内で DevOps を完全に実装することは簡単な作業ではありません。変革は、個人、部門、組織全体にリスクを引き起こす可能性があります。

5.5 概要

DevOps 変革のエントリポイントを慎重に選択することで、組織全体に取り返しのつかない影響を与えることなく、組織の特定の領域で価値を実験、学習、創造できます。同時に、このようにして強固な大衆基盤を構築し、組織内で DevOps を推進する機会を獲得することで、より多くのサポーターからの認識と感謝を得ることができます。

6. バリューストリームを理解し、視覚化し、適用する

DevOps の原則とパターンを適用するバリューストリームを特定したら、顧客に価値を提供する方法、つまりどのような作業が行われているのかを深く理解する必要があります。誰がやるの？プロセスを改善するにはどのような手順を踏む必要がありますか?

この章では次に、顧客価値の創造に必要なチームを決定する、必要な作業を視覚化するために価値ストリームマップを作成する、チームが顧客価値をより適切かつ迅速に創造できるようにするためのガイドとして価値ストリームマップを使用する、というステップについて説明します。

6.1 顧客価値の創造に必要なチームを特定する

DevOps パイロットアプリケーションまたはサービスを選択した後、顧客のための価値を共同で創造する責任を負うバリューストリームのすべてのメンバーを特定する必要があります。一般的には以下のようなメンバーが含まれます。

プロダクトオーナー: ビジネス側の代弁者として、システムが実装する必要がある機能を定義します。
開発チーム: システム機能の開発を担当します。
QA チーム: 開発チームにフィードバックを提供し、システム機能が要件を満たしていることを確認します。
運用および保守チーム: 運用環境を保守し、システムが適切に動作することを確認する責任を負います。
情報セキュリティチーム: システムとデータのセキュリティを担当します。
リリースマネージャー: 運用環境の展開およびリリースプロセスの管理と調整を担当します。
テクニカルリードまたはバリューストリームマネージャー: (リーン手法の定義による) 「バリューストリームの出力が最初から最後まで顧客 (および組織) の期待を満たす、またはそれを超えることを保証する」ことに責任を負います。

6.2 チームワークのためのバリューストリームマップを描く

バリューストリームでは、最初の作業は顧客のニーズやビジネスのアイデアを決定することであり、これは製品所有者によって行われ、次に開発チームが引き継ぎ、プログラミングを通じて関連機能を実装し、コードをバージョン管理システムに送信します。次に、本番環境に似た環境で機能を統合してテストし、最後に、(理想的には) 顧客に価値を生み出す本番環境に機能をデプロイします。

バリューストリームマップを作成する目的は、すべてのステップと詳細を記録することではなく、バリューストリームの迅速な流れを妨げるリンクを特定し、それによってリードタイムを短縮し、信頼性を向上させることです。理想的には、ワークショップに参加する全員が、自分の担当部分を変更する権限を持っている必要があります (全員の時間は貴重であるため、情報の詳細レベルを制限することが重要です)。

バリューストリーム参加チームから提供されたすべての情報に基づいて、次の 2 種類の作業の分析と最適化に重点を置く必要があります。

運用環境のような環境の準備、変更承認プロセス、セキュリティレビュープロセスなど、数週間または数か月の待ち時間を必要とする作業。
大幅なやり直しを伴う作業を開始または処理します。

バリューストリームマップの初期バージョンには、重要なプロセスモジュールのみが含まれている必要があります。複雑なバリューストリームの場合でも、参加グループは通常、5 ～ 15 個のモジュールを含むバリューストリームマップを数時間以内に作成できます。各モジュールには、少なくとも作業項目のリードタイムと処理時間 (図 6-1 のそれぞれ LT と VA <場合によっては、処理時間は付加価値時間 (Value added Time) とも呼ばれます>) を含める必要があります。下流の消費者によって測定される%C/A

バリューストリームマップの指標は、改善の取り組みの指針として使用できます。
ここに画像の説明を挿入します

図中の付加価値時間 VA が 0 になっている作業リンクもありますが、これは処理時間が 0 であるという意味ではなく、その作業が顧客やバリューストリームに付加価値を与えていないことを意味します。

リーダーは、改善目標の特定を支援し、仮説と対策をブレインストーミングし、実験を通じてさまざまな仮説を探索し、結果を分析して仮説が正しいかどうかを判断するようにチームを導きます。継続的な反復を繰り返しながら、チームは新たに得た経験を次の実験や検証に活かします。

6.3 専任の変革チームを編成する

DevOps 変革に固有の課題は、企業の現在のビジネスとの衝突です。これは避けられず、企業が順調に成長するための自然な結果です。長年（数年、数十年、さらには何世紀にもわたって）うまく運営されてきた組織は、製品開発、注文管理、サプライチェーンの運営など、独自の実践方法と運営メカニズムを確立しています。

これは現状を維持するのには最適ですが、市場の変化に適応するには、多くの場合、働き方を変える必要があります。これには破壊と革新が必要ですが、現在日常のビジネスや社内プロセスを担当しているグループとの衝突は避けられず、多くの場合、後者が勝利します。

専任の変革チームを編成し、日常業務を担当する部門から独立させる必要があります (前者を「専任チーム」、後者を「パフォーマンスエンジン」と呼びます)。最も重要なことは、このチームが、明確に定義され、測定可能なシステムレベルの目標 (例: コードの提出から運用環境へのデプロイメントまでのリードタイムを 50% 削減する) を達成する責任を負う必要があることです。これを行うには、次の措置を講じる必要があります。

変革チームのメンバーを DevOps 変革の作業に専念させます (以前の作業を続けさせるのではなく、時間の 20% を DevOps 変革に費やします)。
複数の分野に精通したジェネラリストをチームメンバーとして選択します。
他部門と良好な長期的な関係を築く人材をチームメンバーとして選択します。
可能であれば、チーム用に独立したオフィスエリアを見つけて、メンバーができる限り相互に交流し、他の部門から適切な距離を保つことができるようにします。

専任の変革チームを結成することは、チーム自体にとってだけでなく、「パフォーマンスエンジン」にとっても有益です。独立したチームに新しいプラクティスを試行させることで、組織の残りの部分はイノベーションの潜在的なリスクから保護されます。

6.3.1 共通の目標を持つ

改善計画の最初の要素は、今後 6 か月から 2 年間の測定可能な目標を設定することです。目標を達成するには、チームは多大な努力を払う必要があり、目標の達成は組織全体と顧客にとって大きな価値を生み出す必要があります。

目標と期間は経営者が設定し、組織内の全員に伝達する必要があります。さらに、組織や経営陣に過大な負担を与えないよう、同時にあまりにも多くの改善取り組みを制限する必要があります。改善目標の例をいくつか示します。

製品サポートと計画外の作業にかかる予算を 50% 削減します。
変更の 95% については、コードの送信からバージョンのリリースまでのサイクルが 1 週間またはそれよりも短くなることを確認します。
営業時間内にサービスを中断することなく公開できるようにする。
必要なコンプライアンス要件を満たすために、すべての情報セキュリティ検証の取り組みを展開パイプラインに統合します。

全体的な目標が明確になったら、チームは作業を改善するための詳細な計画とリズムを作成する必要があります。製品開発の取り組みと同様、変革の取り組みも反復的かつ段階的に実施する必要があります。通常、各反復は 2 ～ 4 週間以内に完了します。反復ごとに、チームは価値を生み出し、長期的な目標に近づくことができる一連の小さな目標を策定する必要があります。各反復の終わりに、チームは進捗状況を確認し、次の反復の新しい目標を設定する必要があります。

6.3.2 小規模なスパンの改善計画を維持する

DevOps 変革プロジェクトでは、スタートアップ企業が製品開発や顧客開発を行うのと同じように、小規模なスパンの改善計画を維持する必要があります。数週間 (最悪の場合は数か月) 以内に目に見える改善や使用可能なデータを得るように努める必要があります。

計画期間と反復間隔を短縮することで、次のことが可能になります。

優先順位を再計画および変更する能力と柔軟性。
作業の実装と有効性の間のラグタイムを短縮し、それによってフィードバックループを強化すると、望ましい行動が強化される可能性が高くなります。最初の成功は投資の増加につながる可能性があります。
反復からより早く経験を獲得し、それを次の反復に適用します。
より少ない労力で改善を得ることができます。
日々の業務において、有意義で差別化された改善をより迅速に達成します。
プロジェクトが成果を達成する前に終了するリスクを軽減します。

6.3.3 技術的負債を削減するために、開発時間の 20% を非機能要件のために確保する

優先順位を適切に設定する方法は、プロセス改善の取り組みにおける一般的な問題です。結局のところ、プロセスを改善する必要があるほとんどの組織には十分な時間がありません。これは、技術的負債を返済する必要がある技術組織にとってはさらに当てはまります。

技術的負債を積極的に管理するには、開発および運用時間の少なくとも 20% を、リファクタリング、自動化の取り組み、アーキテクチャの最適化、および保守性、管理性、拡張性などの非機能要件 (「品質属性」と呼ばれることもあります) に費やすようにしてください。信頼性、テスト容易性、展開可能性、セキュリティなど (図 6-2 を参照)
ここに画像の説明を挿入します
この 20% の投資を通じて、開発者と運用保守担当者は日常業務で遭遇する問題を解決することができ、特定された問題に対して長期的な対策を講じ、技術的な安全性を確保します。負債が迅速かつ安全な開発と運営を妨げることはありません。同時に、従業員の技術的負債のプレッシャーを軽減することで、仕事の燃え尽き症候群も減らすことができます。

6.3.4 作業の可視性の向上

チームが目標に向かって進んでいるかどうかを判断できるようにするには、組織内の全員が仕事の現在のステータスを理解する必要があります。ステータスを視覚化する方法はたくさんありますが、最も重要なことは、最新のステータスを効果的に表示し、チームが最新の進捗状況を確実に認識できるように常に改訂することです。

6.4 ツールを使用して期待される動作を強化する

私たちの目標は、開発者と運用担当者が同じ目標を共有するだけでなく、同じタスクリストも共有することを強調することです。理想的には、タスクリストは共通の作業システムに保存され、統一された用語が使用され、グローバルに優先順位を付けることができます。

このようにして、開発者と運用スタッフは、別のツールを使用する代わりに、共有作業キューを作成できます。この大きな利点は、本番環境のインシデントが開発者の作業システムに表示されると、そのインシデントが他の作業にいつ影響するかが明確になることです。これは特にカンバン図を使用する場合に顕著です。

共有キューのもう 1 つの利点は、タスクリストを統合することで、全員がグローバルな観点から最も優先度の高いことを考え、組織にとって最も価値のある作業、または技術的負債の返済を最大化する作業を選択できることです。技術的負債を発見したときに、すぐに対処できない場合は、タスクリストに追加できます。未解決の問題については、非機能要件のために確保されている時間の 20% を使用して問題を修正できます。

共通の目標を強化するために、IRC チャネル、HipChat、Campfire、Slack、Flowdock、OpenFire などのチャットルームを使用することもできます。チャットルームを使用すると、(事前定義されたワークフローを通じてフォームを処理するのではなく) 情報を迅速に共有したり、オンデマンドで他の人をチャットに招待したり、チャットの内容を自動的に記録して事後に分析したりすることができます。メカニズムを確立し、チームメンバーが互いに助け合えるようにし、さらには他のチームのメンバーも助け合えるようにします。これは驚くべき変化をもたらします。人々が情報を入手したり、仕事を完了したりするのにかかる時間は、数日から数分に短縮されます。さらに、すべてが効果的に記録されるため、後で他の人に助けを求める必要はなくなり、チャット履歴を検索するだけで済みます。

6.5 概要

この章では、バリューストリームをサポートするチームを特定し、バリューストリームマッピングを通じて顧客に価値を提供するために必要な作業について学ぶ方法について説明します。バリューストリームマップは、現在の作業状況の基本的な全体像 (リードタイムや %C/A などの指標を含む) を示すだけでなく、チームが将来の改善目標を特定する際にも役立ちます。

これにより、変革チームは迅速に反復し、実験を通じて効率を向上させることができます。チームは、既知の欠陥を修正し、非機能要件などを含むアーキテクチャ上の問題に対処するために十分な時間を割り当てます。バリューストリームの問題を特定し、技術的負債を継続的に返済することで、リードタイムや品質などの面で大幅な改善を達成できます。

7. コンウェイの法則を参考に組織構造を設計する

「システム設計は、組織自体のコミュニケーション構造によって制限されます。組織が大きくなるほど、柔軟性が低下し、この現象がより顕著になります。」「ソフトウェアのアーキテクチャは、ソフトウェアチームの構造と一致しています
。率直に言うと、「4 つのチームに同じコンパイラを開発させた場合、コンパイラの実行ステージは 4 つになります。」

7.1 組織の原型

意思決定科学の分野では、機能、マトリックス、市場という 3 つの主要なタイプの組織構造があります。これらは、コンウェイの法則を使用して DevOps バリューストリームを設計するための参考として役立ちます。

機能的な組織構造は、専門スキルの向上、分業の最適化、またはコストの削減に重点を置いています。これらの組織は専門スキルに重点を置いており、キャリアの向上とスキル開発の促進に役立ち、多くの場合、複数レベルの組織構造を持っています。運用部門は多くの場合、この組織構造を使用します (つまり、サーバー管理者、ネットワーク管理者、データベース管理者などがすべて別々のグループに分割されます)。
マトリックス組織構造は、機能タイプと市場タイプを組み合わせようとします。しかし、マトリックス組織を管理したり、マトリックス組織に関与したことのある多くの人が見てきたように、そのような組織構造は非常に複雑であることがよくあります。たとえば、従業員が 2 人以上のマネージャーに直属する場合があります。マトリックス組織では、機能構造または市場構造のいずれかの目標を達成できない場合があります。
市場志向の組織構造は、顧客のニーズに迅速に対応することに重点を置いています。このタイプの組織は、複数の機能横断的な部門 (マーケティング部門やエンジニアリング部門など) で構成されるフラットな構造であることが多く、組織全体に冗長性が存在する場合があります。DevOps を導入している多くの優れた組織は、この構造を採用しています。極端な例を 2 つ挙げてください。Amazon と Netflix では、各サービスチームが機能の提供だけでなく、サービスのサポートも担当しています。

上記の 3 つのタイプの組織構造を理解した後、コンウェイの法則が予測するように、過度の機能指向 (特に運用部門) がテクノロジーのバリューストリームに悪影響を与える可能性がある理由をさらに探ってみましょう。

7.2 過剰な機能指向（「コスト最適化」）の危険性

問題をさらに複雑にするのは、作業を実行する人々が、自分の作業がバリューストリームの目標にどのように関連しているかをよく理解していないことです (「誰かが私にそうするように言ったから、このサーバーを構成した」)。これでは、従業員が創造的かつ積極的に行動することが妨げられます。

運用部門の各機能チームが同時に複数の価値ストリーム (つまり、複数の開発チーム) にサービスを提供する必要がある場合、すべてのチームの時間は貴重であるため、問題はさらに悪化します。

この状況は、長い待ち時間やリードタイムの延長につながるだけでなく、不十分な引き継ぎ、大規模な手戻り、配送品質の低下、ボトルネック、遅延を引き起こす可能性もあります。

この行き詰まりにより、組織はコスト削減の希望をはるかに上回る重要な目標を達成できなくなります。

7.3 市場志向のチームの形成（「スピードの最適化」）

一般的に言えば、DevOps を達成するには、機能指向のマイナスの影響 (「コストの最適化」) を軽減するだけでなく、市場指向の効果をより有効に活用する (「速度の最適化」) ことも必要です。チームは安全かつ独立して効率的に作業し、顧客に迅速に価値を提供できます。

極端な場合には、市場指向のチームは、機能開発だけでなく、アプリケーションのライフサイクル全体を通じて、実稼働環境のテスト、セキュリティ、展開、運用にも責任を負います。これらの部門横断的なチームは独立して運営できるため、他のチームに依存することなく、ユーザー実験の設計と実施、新機能の構築と提供、運用環境でのサービスの展開と実行、欠陥の修正ができるため、迅速な対応が可能になります。

7.4 機能指向を効果的にする

前のセクションでは、市場指向のチームを形成することを提案しましたが、機能指向も効率的な組織につながる可能性があることに言及する価値があります (図 7-1 を参照)。部門を超えた市場指向のチームを形成することは、迅速なフローと信頼性を実現する 1 つの方法ですが、これが唯一の方法ではありません。バリューストリームの全員が顧客と組織の目標を認識している限り、組織内のどこにいても、機能指向を通じて期待される DevOps の結果を達成できます。
ここに画像の説明を挿入します

左側は機能指向です: すべてのワークフローは集中化された IT 運用および保守チームを通じて行われます。右側は市場指向です: すべての製品チームがセルフサービス方式で疎結合コンポーネントを実稼働環境に導入できます。

7.5 テスト、運用、情報セキュリティを日常業務に統合する

高いパフォーマンスを発揮する組織では、人々は共通の目標を共有しています。品質、可用性、安全性の確保は特定の部門の責任ではなく、全員の日常業務の一部です。

「私が今使っている例え話は、Ops がオフェンスラインマンで、Dev が重要なポジション (クォーターバックやワイドレシーバーなど) を担当するということです。Dev の仕事はボールを急ぐことであり、Ops の仕事は、Dev がボールを攻撃するのに十分な時間を確実に確保することです。前に進め、急げ。」

7.6 チームメンバーをゼネラリストにする

解決策の 1 つは、チームメンバー全員をゼネラリストにすることです (表 7-1 を参照)。エンジニアに、担当するシステムの構築と実行に必要なスキルを学び、定期的にさまざまな役割をローテーションする機会を与えます。現在、フルスタックエンジニアという用語は、一般的に、アプリケーションスタック全体 (コード、データベース、オペレーティングシステム、ネットワーク、クラウドなど) に精通している、または少なくとも大まかに理解しているジェネラリストを指します。

表 7-1 エキスパート、ゼネラリスト、E 型人材

タイプI（エキスパート）	T型（ジェネラリスト）	タイプE
ある分野を極める	ある分野を極める	特定の分野に精通している
他の分野のスキルや経験がほとんどない	多分野のスキルを身につける	複数の分野での実務経験、高い実行力、継続的なイノベーション能力を有する
すぐにボトルネックに遭遇	ボトルネックを突破できる	無限の可能性
下流の廃棄物や影響の影響を受けにくい	下流の廃棄物や影響に敏感
柔軟な計画や変動する計画に抵抗する	柔軟で変更可能な計画の策定を支援する

E型人材とは、経験、専門知識、探求能力、実行能力の4つの側面において優れた人材を指します。

私たちは、従業員の学習を奨励し、従業員が学習不安を克服して関連スキルを習得できるように支援し、従業員が明確にキャリア計画を立てられるようにしたいと考えています。そうすることで、従業員の成長マインドセットを育むことができます。結局のところ、学習する組織には学習意欲のある人材が必要です。すべての従業員に学習を奨励し、トレーニングとサポートを提供することで、最も持続可能でコスト効率の高い方法で強力なチームを構築します。

7.7 プロジェクトではなくサービスと製品に投資する

高いパフォーマンスを達成するもう 1 つの方法は、安定したサービスチームを構築し、戦略と計画を実行できるように継続的な資金を提供することです。これらのチームには、機能、ストーリー、タスクなど、社内または社外の顧客に対する特定の約束を実現することに専念するエンジニアが必要です。

製品ベースの投資モデルは、労力 (時間と労力、コード行など) を最小限に抑えながら、組織のパフォーマンスと顧客の成果 (会社の収益、顧客の生涯価値、顧客の導入など) に焦点を当てます。これは、プロジェクトが確立された予算、時間、範囲内で完了したかどうかなどの従来のプロジェクト指標とは大きく異なります。

7.8 コンウェイの法則に基づいてチームの境界を設定する

不合理なチーム編成は悪影響をもたらす可能性があり、これはコンウェイの法則の副作用です。これには、機能ごとにチームを分割する (開発者とテスターを別のオフィスの場所に配置する、またはテスターを完全にアウトソーシングするなど) ことや、アーキテクチャ層ごとにチームを分割する (アプリケーション層、データベース層など) ことが含まれます。

理想的には、ソフトウェアのアーキテクチャは、小規模なチームが独立して動作し、相互に完全に分離できるようにすることで、不必要なコミュニケーションや調整が過剰に避けられるようにする必要があります。

7.9 疎結合アーキテクチャを作成して生産性とセキュリティを向上させる

密結合されたソフトウェアアーキテクチャでは、小さな変更でも大きな障害につながる可能性があります。したがって、特定のコンポーネントを担当する開発者は、さまざまな複雑な変更管理プロセスを経るなど、他のコンポーネントを担当する開発者と常に調整し、通信する必要があります。

サービス指向アーキテクチャ (SOA) にはこの特性があります。サービス指向アーキテクチャの概念は 1990 年代に提案され、サービスの独立したテストとデプロイをサポートするアーキテクチャアプローチであり、その典型的な特徴は、境界のあるコンテキストを持つ疎結合のサービスで構成されることです。

疎結合アーキテクチャとは、他のサービスを更新せずに、実稼働環境でサービスを独立して更新できることを意味します。サービスは他のサービスや共有データベースから分離する必要があります (データベースサービスは共有できますが、共通のデータベーススキーマを持たないようにする必要があります)。

境界付きコンテキストの背後にある考え方は、開発者がピアサービスの内部ロジックを知らなくても、サービスのコードを理解して更新できる必要があるということです。サービスは厳密に API を介して対話するため、データ構造、データベーススキーマ、またはオブジェクトのその他の内部表現を共有する必要はありません。境界付きコンテキストにより、サービスが明確に定義されたインターフェイスを備えた独立した部分に確実に分割されるため、テストも容易になります。

チームを小規模に保つ (「ピザ 2 枚の原則」)
2002 年、Amazon は、単一コードベースからの移行を試みる際に、チームを小規模に保つために「ピザ 2 枚の原則」を使用しました。つまり、チームのすべてのメンバーにはピザ 2 枚で十分です。チームは通常5人から10人で構成されます。

コンウェイの法則は、望ましいコミュニケーションパターンに基づいてチームの境界を設定するのに役立ちますが、同時にチームの規模が小さくなり、チーム間のコミュニケーションが減り、チームの専門領域を小さく限定的に保つことも奨励します。

このスケール制限には、次の 4 つの重要な機能があります。

これにより、チームメンバーがシステムについて明確に共通の理解を得ることができます。チームが大きくなるにつれて、全員がシステムの状態を理解するには、伝達する必要がある情報の量が飛躍的に増加します。
開発中の製品やサービスの成長率が制限されます。チームの規模を制限すると、システムが進化する速度も制限され、チームメンバーがシステムについて同じ理解を得ることができます。
それは権力を分散させ、自律性を可能にします。Two Pizza の各チームは、可能な限り自律的に作業します。チームリーダーは経営陣に直接報告し、経営陣はチームの責任に対する主要なビジネス指標（フィットネス機能とも呼ばれます）を決定し、それをチームの実践の全体的な評価基準として使用します。その後、チームはその指標を最大化するために自律的なアクションを実行できるようになります。
Two-Pizza チームを率いることは、従業員がリーダーシップの経験を積む方法です。このような環境では、失敗しても致命的になることはありません。

7.10 概要

アーキテクチャと組織設計の大きな影響がわかります。コンウェイの法則がうまく利用されれば、チームは安全かつ独立して開発、テストし、顧客に価値を提供できますが、下手に利用すると、望ましくない結果をもたらし、セキュリティと俊敏性の破壊につながる可能性があります。

8. 運用と保守を日常の開発作業に組み込む

私たちの目標は、市場主導型であり、小規模なチームが迅速かつ独立して顧客に価値を提供できるようにすることです。しかし、多くの開発チームの異なるニーズに対応する必要がある、集中化された機能指向の運用チームでは、この目標を達成するのは困難です。その結果、運用保守作業の納期サイクルが長く、作業の優先順位を何度も調整する必要があり、導入結果は常に満足のいくものではありませんでした。

開発チームに強力な運用能力を与えることで、より市場志向のビジネス成果を生み出し、最終的には効率と生産性を向上させることができます。

一元化された運用チームが市場主導の結果を達成する方法。ここでは 3 つの一般的な戦略を示します。

開発者の生産性向上を支援するセルフサービス機能を構築します。
運用および保守エンジニアをサービスチームに統合します。
運用保守担当者の人数が不足している場合は、運用保守連絡型を採用することも可能です。

8.1 共有サービスを作成して開発生産性を向上させる

運用保守部門が市場志向の結果を達成したい場合、1 つのアプローチは、一元化されたプラットフォームとツールセットサービスを作成し、すべての開発チームがこのプラットフォームとサービスを使用して、運用環境のような環境の構築、展開などの生産性を向上できるようにすることです。パイプライン、自動テストツール、実稼働環境テレメトリコンソールなど。これにより、開発チームは、運用環境での機能の提供とサポートに必要なインフラストラクチャを取得する代わりに、機能の構築により多くのエネルギーと時間を費やすことができます。

理想的な世界では、運用および保守によって提供されるすべてのプラットフォームとサービスが完全に自動化され、開発者が作業指示書を提出して運用および保守チームが手動で処理するのを待つ必要がなく、オンデマンドで利用できるようにする必要があります。メンテナンスも顧客にならないのがネック

内部共有サービスチームは、組織内で広く使用できるツールチェーンを引き続き探索し、集中プラットフォームを通じて提供できるツールチェーンを決定し、誰もが利用できるようにする必要があります。一般に、実績のあるツールを見つけてその使用を拡大することは、それらの機能をゼロから構築するよりも成功する可能性が高くなります。

8.2 運用保守エンジニアをサービスチームに統合する

市場主導の結果を達成するもう 1 つの方法は、オペレーションエンジニアを統合して製品チームを自立させ、それによって集中化されたオペレーションへの依存を減らすことです。これらの製品チームは、サービスの提供とサポートに対して全責任を負います。

運用エンジニアを開発チームに統合することにより、運用エンジニアの仕事の優先順位は、自分自身の問題の解決に焦点を当てるのではなく、ほぼ完全に製品チームの目標によって決定されます。その結果、運用エンジニアは社内および社外の顧客とのつながりが強化されます。さらに、製品チームはこれらのオペレーションエンジニアを雇用するための専用の予算を用意していることがよくありますが、従業員の一貫性と質を確保するために、面接と雇用の決定は依然として集中管理されたオペレーションチームによって行われる場合があります。

新規の大規模開発プロジェクトの場合、立ち上げ段階で運用・保守エンジニアをプロジェクトに組み込むことができます。彼らの仕事には、何をどのように行うかについての意思決定の支援、製品アーキテクチャへの影響、内部および外部のテクノロジー選択の支援、内部プラットフォームの新機能の作成の支援、さらには新しい運用および保守機能の生成が含まれます。製品の発売後、運用および保守のエンジニアは、開発チームが運用および保守の責任を引き継ぐのを支援できます。

このパラダイムには重要な利点があります。開発チームと運用および保守エンジニア間の緊密な協力とコラボレーションは、クロストレーニングを通じて運用および保守の知識をサービスチームに統合する非常に効果的な方法であり、運用および保守の知識を段階的に自動化することもできます。コードの信頼性を高め、より広く再利用可能にする

8.3 各サービスチームに運用保守担当者を割り当てる

さまざまな理由 (コストやリソースの不足など) により、各製品チームに運用保守エンジニアを割り当てることができない場合がありますが、各製品チームに運用保守担当者を割り当てることができます。同様の結果も得られます。

集中管理された運用チームは引き続きすべての環境 (運用環境だけでなく運用前環境も) を管理し、その一貫性を確保する責任を負います。派遣される運用保守技術者は、以下の事項を理解する責任があります。

新製品にはどのような機能があり、なぜこの製品を開発する必要があるのか?
どのように機能するか、操作性がどの程度であるか、拡張性と監視機能がどの程度あるのか (図解を強く推奨します)。
指標を監視および収集する方法、およびアプリケーションが適切に機能していることを確認する方法。
アーキテクチャとパターンは過去に行われたものと異なりますか、またそうする理由は何ですか。
インフラストラクチャに対する追加の需要があるかどうか、またその使用がインフラストラクチャの容量にどのような影響を与えるか。
機能のリリーススケジュール。

運用エンジニアと保守エンジニアを統合するモデルと比較して、運用担当者と保守担当者を割り当てることで、より多くの製品チームをサポートできます。私たちの目標は、運用が製品チームにとってボトルネックにならないようにすることです。運用担当者の作業負荷が高すぎるために製品チームが目標を達成できないことが判明した場合は、各担当者がサポートするチームの数を減らすか、運用エンジニアを特定の製品チームに一時的に統合する必要がある場合があります。

8.4 運用および保守エンジニアを開発チームの会議に参加するよう招待する

私たちの目標は、運用エンジニアやその他の非開発者が現在の開発チームの文化をより深く理解し、計画や日常業務に積極的に参加できるようにして、運用チームが運用機能を製品チームにうまく組み込めるように支援し、関連作業を実装できるようにすることです。製品が発売される前に。

8.4.1 運用および保守エンジニアを毎日のスタンドアップミーティングに参加するよう招待する

毎日のスタンドアップの目的は、チーム全体で情報を共有し、現在行われている作業とこれから行われるすべての作業を理解することです。チームメンバーが互いに情報を共有できるようにすることで、困難なタスクを特定し、相互扶助によって解決策を見つけて全体の作業を進めることができます。さらに、チームリーダーの存在により、優先順位とリソースの競合の解決が迅速化されます。

一部の情報は開発チーム内に分散しており、これはよくある問題です。運用エンジニアが会議に参加することで、運用部門は開発チームの活動を完全に理解できるようになり、より適切な計画と準備が可能になります。

8.4.2 運用および保守エンジニアをレビュー会議に招待する

運用エンジニアは、振り返り会議中に次のフィードバックを提供できます。

「2週間前、私たちは監視の盲点を発見し、チームはそれを解決する方法について合意に達しました。問題は現在解決されました。先週の火曜日、監視システムは警報イベントを受信し、私たちはすぐに障害を特定しました」顧客サービスに影響が出る前に対処してください。」
「先週の導入は今年最も難しく、時間がかかりました。改善のためのアイデアをいくつか紹介します。」
「先週実施したマーケティングプロモーションは、予想よりもはるかに困難でした。同様のプロモーションを二度と実施すべきではありません。販売目標を達成するには、実際にいくつかの他の解決策を試すことができます。」
「前回の展開時の最大の問題は、運用環境のファイアウォールルールにすでに数千行があり、変更するたびに非常に困難でリスクが伴うことでした。ネットワークトラフィックの制御ルールの再設計を検討する必要があります。」

運用チームからのフィードバックは、製品チームが下流チームに対する決定の影響をよりよく認識し、理解するのに役立ちます。マイナスの影響が生じた場合には、今後同様の事態が起こらないよう適切な変更を加えなければなりません。同時に、運用および保守チームからのフィードバックは、より多くの問題や欠陥を発見するのに役立ち、チームが特定のアーキテクチャ上の問題を発見するのにも役立ちます。

チームの振り返りでは、バグ修正、リファクタリング、手動操作の自動化などの改善点を特定することもできます。

8.4.3 かんばん図を使用して運用保守作業を表示する

運用作業はバリューストリームの一部であるため、製品の配送に関連する他の作業とともにカンバン図に表示する必要があります。このようにして、チームはコードを実稼働環境にリリースするために必要なすべての作業をより明確に確認し、製品サポートに関連するすべての運用および保守作業を追跡できます。さらに、チームはダッシュボードから、どの運用および保守作業が妨げられているのか、どの領域を改善する必要があるのかを確認できます。

カンバンチャートは、作業を視覚的に管理するための理想的なツールです。視覚化は、運用の取り組みを製品の価値の流れに統合するための鍵となります。これをうまく行えば、組織構造の変更に関係なく、市場主導の成果を達成することができます。

8.5 概要

この章では、運用を開発チームの日常業務に統合する方法と、運用を視覚化する方法について説明します。これを行うには、共有サービスを作成して開発の生産性を向上させる、運用および保守エンジニアをサービスチームに統合する、運用および保守の連絡先を各サービスチームに割り当てる、の 3 つの方法があります。最後に、この章では、毎日のスタンドアップ、計画会議、振り返りへの参加など、運用エンジニアが開発チームの日常業務にどのように適応するかについて説明します。