DevOpsのテキスト研修

DevOpsで作業を円滑に流すには

DevOpsにおけるフローとは、アイデアから本番システムで動くコードまで、ソフトウェアができる一連の流れです。あなたとDevOpsチームは、組織の目標を達成し、それを上回り、対象市場の他の製品やサービスより優れた成果を出すために、安定して一貫性があり、速い流れを作って維持します。

DevOps変革のミッションを定める

DevOpsチームを編成したら、次はミッションを定めます。チームが適切に機能するには共通のミッションが必要です。それがなければ、重要な作業を優先できず、進行を止める重大な問題と日常の雑務を区別できません。ミッションは意欲をかき立てる挑戦的なものであり、同時に、定めた期間内に達成できるものでなければなりません。

ミッションは、自分たちのDevOpsチームに合わせて定めます。組織の特性、課題、そしてチームと関わる社内外の顧客にサービスを提供する目的に基づいて決めます。

DevOps変革を始めるためのミッションの例を挙げます。

• 3か月で、コードのチェックインから本番稼働までの平均リードタイムを75%短縮する。
• 6か月で、依頼から本番稼働までの平均リードタイムを33%短縮する。
• 12か月で、本番環境のインシデント件数を50%削減する。

バリューストリームとは何か。誰が関わるのか。

仕事を改善するには、バリューストリームを把握する必要があります。ITシステムにおけるバリューストリームとは、特定のソフトウェア製品やサービスの設計、構築、運用に必要な一連の活動です。さらに、その流れを支える人材、実践知識、設備やサービス、資材も明らかにします。

複雑な組織では、一人でバリューストリーム全体を把握できる人はいません。DevOpsチームの全員、ステークホルダー、供給業者、顧客の担当者、可能であれば顧客自身も、その把握に参加することが重要です。

バリューストリームマップを作り、改善の余地を見つける

バリューストリームマップによって、ソフトウェアの開発・デリバリー組織で日々の作業がどう進むかを、あなたとDevOpsチームで可視化できます。目的は、作業が終わるまでの一つひとつの手順を網羅的に文書化することではありません。日常の作業の流れを十分に理解し、大きな非効率、制約、問題、時間やリソースのムダがどこにあるかを見つけることです。

ソフトウェアの開発エンジニアと運用エンジニアが初めて同席してバリューストリームマップを作ると、表領域が適切に設定されていないデータベースサーバーが開発チームにどれほど悪影響を及ぼすかを、運用エンジニアが初めて理解する場合がよくあります。同様に、監視、可用性、テスト容易性、設定の機能を組み込まずにソフトウェアを届けるとどうなるかを、開発エンジニアが初めて理解することもよくあります。

引き継ぎ、制約、ムダをできる限りなくす

引き継ぎ、ムダ、制約は、効率に大きく影響するにもかかわらず見落とされがちです。あるチームから別のチームへ作業を引き継ぐと、通知、依頼、日程調整、優先順位付け、優先度の引き下げ、対立の解消が必要になります。

チーム間で作業を引き継ぐたびに情報が失われ、バリューストリーム全体のリードタイムにも悪影響が出ます。

これらの問題には、次のように対処します。

• 各引き継ぎにかかる時間が妥当かを見直す必要がある。 たとえば上のバリューストリームマップでは、テストを通過したコードをデプロイチームが引き取るまで80時間かかります。なぜでしょうか。このプロセスは自動化できないでしょうか。もちろん、できます。
• 繰り返される引き継ぎが生むムダをなくす必要がある。 上のバリューストリームマップでは、テストチームは機能の65%を開発チームに差し戻しています。不具合によっては、テスト担当者が承認するまでに、修正を3回も届ける必要があります。開発チームとテストチームの連携を改善すれば、この繰り返しを速められないでしょうか。不具合が多いのは、開発チームで何かがうまく機能していない兆候です。品質問題の原因を特定し、解消する必要があります。
• 引き継ぎの必要性を見直し、できる限りなくす必要がある。 上のバリューストリームマップでは、要望の内容を詰めてから、承認権限者が処理するまで320時間かかります。なぜ組織にそのような承認権限者が必要なのでしょうか。バリューストリームにどのような価値をもたらすのでしょうか。適切な判断を下すのに十分な情報と全体像を持っているでしょうか。承認権限者が、要望の内容を詰めるチームに加わってはどうでしょう。承認するものをよく理解でき、320時間かかる引き継ぎを一つなくせます。作業の流れを遅らせる制約や障害を取り除かなければ、DevOpsに大きな効果は期待できません。

DevOpsでは、こうした問いを投げかけて現状を変えることが求められます。組織の全員がこうした問いを歓迎するわけではありませんが、そのことも織り込み済みです。

作業の流れを全員に見えるようにする

作業を左から右へ進め、DevOps組織の目標を達成するには、流れを可視化するツールや仕組みが必要です。ITの仕事では、バリューストリーム内の別チームへの作業の割り当ては、クリック一つでできます。しかし、作業が不完全だったり、依存関係に不整合があったり、誤解があったりして、仕事がチーム間を行ったり来たりすることは日常茶飯事です。いわば一歩進んで二歩下がる状態で、進むとしても非常にゆっくりです。

だからこそ、チームだけでなく、関係者全員に作業の流れが見えることが大切です。DevOpsでは、プロダクトバックログ、スプリント計画のバックログ、カンバンボードを使って流れを可視化します。ボードに載せるのは自分たちのDevOpsチームの作業だけではありません。製品やサービスのアイデアが生まれてから、運用、保守、提供終了まで、全体の流れを見えるようにします。こうすれば、仕事が滞ったときに誰もがすぐ気づけます。滞りなく仕事を進めるために障害を取り除くことは、全員が負う責任です。

バッチサイズと仕掛かり作業を制限する

次の大学で行われた研究があります。 Stanford University この研究では、マルチタスクの生産性は、一度に一つのことを行う場合よりも低いとわかりました。また、複数の電子情報の流れに日常的にさらされる人は、一度に一つの作業を終える人と比べて、注意を向け、情報を思い出し、仕事を切り替えることが苦手でした。

DevOpsチームでは、仕掛かり作業を減らし、コードを届ける単位を小さくする必要があります。たとえば開発中の仕掛かり作業を最大6件とし、頻繁なコンテキスト切り替えを避けて、目の前の作業に集中できるようにします。別の方法として、各タスクをフィボナッチ数（0、1、2、3、5、8、13、21、34、……）に基づくストーリーポイントで見積もり、一定期間（スプリント）に扱う合計ストーリーポイント（ベロシティ）に上限を設けます。

デリバリーのバッチサイズを制限すると、品質と生産性が向上し、問題の根本原因をよりすばやく特定して解決できます。タスクを終えたら、共通のコードリポジトリにチェックインし、継続的インテグレーション基盤で検証して、本番にデプロイします。バッチが小さいため、コードを届けたことで生じた本番の問題を見つけやすく、必要な場合のロールバックも簡単になります。継続的に本番へ届けることで、チームは組織のミッションに貢献していることに常に誇りを持てます。この働き方を、8か月間コードを書き続け、本番システムに一行も届けないチームの士気、意欲、技術的な課題と比べてみてください。

時間の20%を技術的負債の削減に使う

組織が技術的負債を減らす時間を確保せず、回避策の上に回避策を重ね続けると、やがて全エンジニアが問題の修正にすべての時間を費やすようになります。借金にたとえれば、利息を払うだけの状態です。

まとめ

この章では、DevOpsにおけるバリューストリームとフローとは何か、なぜ重要か、バリューストリームで作業を円滑に進めるために何をすべきかを取り上げました。