DevOpsのテキスト研修
DevOpsでフィードバックの仕組みをどう作るか
顧客からの要求や依頼が絶えず難しくなるIT環境で、DevOpsチームは作業の品質を継続的に高めていく必要があります。そのために、バリューストリームの右から左へ、迅速で途切れず、信頼できるフィードバックループを作ります。
こうしたループがあれば、障害が小さく、費用をかけず簡単に取り除けるうちに対応できます。日々の仕事を通じて、組織に学びの文化を育てることにもつながります。問題が起きたときは、チームで学び、ソフトウェア製品やサービスの品質を改善する機会として捉えます。
DevOpsのフィードバックループで品質を作り込む必要がある理由
ソフトウェアエンジニアリングの経験から、複雑なシステムのすべてを把握できる人はいないことは、すでによくおわかりでしょう。まったく同じ作業を2回行っても、結果が同じになるとは限りません。どの企業もこうした結果の不確実性を受け入れにくいため、チェックリスト、監査、コンプライアンス、品質保証の専門家、細部に及ぶ管理によって、品質保証の統制と信頼性を確保しようとします。それでも、ミスやエラーを防ぐには十分でないことがあります。
品質を工程に作り込む組織を築くには、ミスやエラーが日常業務の一部であることを受け入れるところから始めます。
安全な作業を支える文化を築く
安全に働ける仕組みを組織文化に根づかせます。エラーが小さなうちにすばやく見つけて修正でき、重大な不具合、サービス停止、顧客からの悪い評価といった大きな問題を防げるとわかっているので、DevOpsチームの誰もがミスを恐れずに働けます。
安全な作業を支える文化を築くと、あなた、DevOpsチーム、IT部門と事業部門全体に、次の利点があります。
- システムの複雑さを管理できるため、設計上や運用上の問題をすばやく検出できる。
- 問題は小さいうちにすばやく解決される。問題の解決を通じて、組織に新しい知識や経験が自然に蓄積される。
- 新しい知識と経験が組織全体に広がり、共有されます。
- DevOps組織のリーダーは、安全な作業システムを構築して継続的に改善する次のリーダーを育成する。
問題を発生したときに特定する
フィードバックが遅く、頻度も低く、届く時期も遅ければ、望ましくない結果を防ぐには手遅れになり、費用もかさみます。昔ながらのウォーターフォール型では、アプリケーションを1年かけて作り、初めて顧客に見せた後、また1年かけて作り直すことがありました。今では、そうした仕事の進め方を選べる企業はありません。
目標は、短いフィードバックループを作ることです。作業がバリューストリームの左から右へ進む一方で、フィードバックは右から左へ絶えず戻るようにします。DevOps組織で品質を作り込むには、迅速なフィードバックサイクルが欠かせません。問題が入り込んだら、チームはバリューストリームで最初に発生した時点で特定します。問題をすばやく解消し、社内外の顧客や作業の影響を受ける他のステークホルダーの期待と、それに応えるための実装が合っているかを常に確かめます。短いサイクルで問題をすぐ直せるだけでなく、そこから学び、同じエラーを繰り返さずに済みます。
簡単、迅速、低コストで直せるうちにエラーを修正する
問題をすばやく発見すれば、修正もすばやくできます。そうしなければ、次のことが起こります。
- 修正の費用と労力が指数関数的に増え、技術的負債（回避策の上に回避策を重ねたもの）が蓄積する。
- エラーがバリューストリームの後工程に伝わり、さらに別のエラーを引き起こす可能性が高くなる。
- エラーが最初に混入した作業部門から離れたところで繰り返し発生し、解消にはさらなる修正や作業が必要になる。
- エラーが起きた当初の理由は記憶から薄れ、エラーの発生に関わった状況も変化します。混入してから数か月後に初めて見つかった場合、本当の根本原因は特定できず、何よりそこから学べません。その場しのぎの回避策を施し、次の回避策に移るだけになります。DevOpsが避けたいのは、まさにこの状態です。
自分自身も含め、DevOpsチームが声を上げ、継続的にフィードバックを得てエラーを特定し、すばやく修正できるようにしましょう。誤りのある作業の上に、誤りのある作業を重ねてはいけません。新機能の構築に悪影響を及ぼすエラーは、構築に着手する前に修正します。仕事の品質を絶えず改善し、エラーを発生した時点で取り除き続けることで、対象市場で最良のソフトウェア製品とサービスを作れます。
品質管理の判断は、実際に作業する現場で行う
品質管理の判断を現場から遠ざけると、品質が下がり、デリバリーのリードタイムが長くなり、原因と結果を結ぶフィードバックが弱くなり、ミスから学ぶ力も低下します。
具体的には、次のことを避けます。
- 自動化できる品質管理作業をチームに手作業で行わせる。
- 作業に関する知識がない、または限られている多忙な人に承認を求める。
- 作業の性質上すぐに古くなるような膨大な承認用資料を作る。
- 大量の作業を一括で承認権限者に回す。
DevOpsチームの一人ひとりが、自分で管理できる領域でエラーを見つけて直し、共有し、話し合い、周りに教えます。ペアプログラミング、ピアレビュー、自動テスト、チェックインしたコードの検査、チーム内の確認、頻繁なデモにより、品質保証を専任部署だけでなく、全員が担うようにします。
まとめ
あなたとDevOpsチームは、顧客にサービスを提供することに対して報酬を受け取っていると、常に意識しています。社内外の顧客にとって何が最善かを考えて仕事をしましょう。
バリューストリームの次の工程は、とりわけ重要です。その工程を担当する人の立場で考え、仕事を調整します。迅速で信頼できるフィードバックの経路を一緒に作り、バリューストリームで仕事が速く円滑に、高い品質を保って進むようにします。そうすれば、DevOpsチームは問題をできる限り早く見つけて解決できます。
