公式資料
「デジタルオペレーションの現状」独自調査レポート
公式資料 エンジニアの燃え尽きを防ぐ秘訣とは？
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基にしたシステム運用の”今”を解説！→ PagerDutyの資料をみる（無料）
「アジャイル」はソフトウェア開発の世界でよく聞く単語ですが、世のなかには「アジャイル開発」に取り組んでいるといいながらも、実は実態がその意味に即していない組織やチームが存在します。責任者がアジャイルの価値観と重要性を説きながら、実際は技術チームを非常に細かく管理し、アジャイルという名の下にソフトウェア開発者を長時間働かせているケースは少なくありません。その結果、エンジニアは、「”アジャイル”は技術に関する素人が自分たちを巧みに操り、ゲーム感覚でソフトウェア開発を押し付けるために使う言葉だ」と理解し、アジャイル開発には関わりたくないと思うようになります。少しゾッとしてしまう話ですが…こうした事態は実際に発生しており、本来のアジャイルとは異なる「偽のアジャイル開発」といえます。
この記事ではこうした「偽アジャイル」の特徴や、そこでエンジニアがよく経験する3つの「問題」をご紹介します。この記事をご覧頂くことで、ソフトウェア・システム開発で生じるエンジニアの疲弊が実は「偽アジャイル」によって起きているものであり、本来のアジャイルの原則や価値観では発生しえない問題があるということ、そして、そうした問題の解決法のヒントを掴んで頂けますと幸いです。
目次
「アジャイル」とは？
アジャイル開発・スクラム開発
まず、そもそもの「アジャイル開発」の意味をおさらいしましょう。アジャイル開発とは、ソフトウェアの開発手法の一つで、小さな単位で実装とテストを繰り返して開発を進めることが特徴です。ウォーターフォール型の開発をはじめ従来の開発手法よりも開発期間が短くなるため「アジャイル（素早い）」と呼ばれます。優先度の高いものから開発を進めその集合体としたシステムを形成する流れです。仕様変更に対して柔軟で、プロダクトの価値を最大化することに重点を置いています。アジャイル開発の概念は、2001年にアメリカのユタ州に集まった17名のエンジニアによって提唱されました。彼らは、より良いソフトウェア開発手法について議論した内容から「アジャイルソフトウェア開発宣言」という文書をまとめました。この文書では、アジャイル開発とそれに基づく12の原則が記載されており、なかでも次の4つの要素が重視されています。
- 1. エンジニア個人との対話
- 2. 実際に動くソフトウェア
- 3. 顧客とのコミュニケーション
- 4. 変化への対応
これらの内容は一見、従来の開発手法で大切にされてきた、「プロセスやツール」「包括的なドキュメント」「契約上の交渉」「計画に従う」と相反するように見えるかもしれません。しかし、アジャイル開発では、従来の開発手法で大切にされている要素も大切にしつつも、より「動的で高い対応力や柔軟性につながる」ことから、先に述べた4つの要素を重視しています。アジャイル開発とともによく耳にする「スクラム開発」も、アジャイル開発の手法の一つです。スクラム開発では、チームを組んで役割やタスクを分散し、コミュニケーションを取りながら開発するため、アジャイル開発のなかでもよりコミュニケーション能力が大切となる手法といえます。
アジャイル開発が求められる背景
昨今のビジネスやITサービスを取り巻く環境は日々激しく変化し、より複雑になっています。ユーザーのニーズは多様化しているうえにその移り変わりは非常に早いといえます。ニーズや技術、そして市場は、数ヵ月後には大きく変わっている可能性があリます。このような変化の大きい時代にあって、数年先の未来を正確に予測し、そうしたダイナミックな変化を前提にソフトウェア開発を進めることにはリスクが伴います。要件定義が終わって開発に着手するのは、新たなニーズの発生や状況の変化が起きる可能性があります。そのため、現代のソフトウェア開発では新たなニーズや時代の変化に柔軟に対応し、スピーディにサービスの価値を提供することが求められています。そして、それを実現するのがアジャイル開発といえます。
もちろん、すべての開発においてアジャイル開発が最適とは限りません。しかし、アジャイル開発によってプロダクトの価値をさらに高めることが可能なケースがあるのも確かです。従来ウォーターフォール開発が主流だった日本においても、アジャイル開発への関心は非常に高く広がりを見せています。
「偽アジャイル」とは？
そうした背景の元、アジャイル開発の必要性が高まるとともに、アジャイル開発を取り入れる企業やプロジェクトは急速に増えています。しかし、そうした企業においてプロジェクトに参画するメンバー全員が正しくアジャイルを理解していると言い切るのは難しいのではないでしょうか。不十分な理解のままアジャイル開発に取り組むことで「偽アジャイル」が発生するといえます。ここでは「偽アジャイル」の定義とそれによって生じうる問題について説明します。
「偽アジャイル」の定義
ここで「偽アジャイル」とは、アジャイルの原理原則・価値観を尊重しないチームやプロジェクト、組織が名乗るアジャイル開発手法を指しています。例として、アジャイル開発を装ったウォーターフォール開発や、実際には機能不全に陥っているプロセスを「アジャイル」と呼ぶケースがあります。
- 技術チームメンバー・エンジニアが、ユーザーについて話し合ったり観察しない。
- サービスのユーザーから技術チームへの継続的なフィードバックが行われていない。
- MVP（Minimum Viable Product: 実用最小単位の製品）をできるだけ早くリリースしてユーザーから早期のフィードバックを得るよりも、プロジェクト要件をすべて満たすことを優先している。
また、「偽アジャイル」を見抜くツールとして、米国国防総省のガイド「DIB Guide: Detecting Agile BS (英語)」も参考になります。
「偽アジャイル」によって生じうる3つの問題
では、「偽アジャイル」を進めるチームや組織、プロセスにおいて、エンジニアはどのような問題に直面するのでしょうか。本記事では、次の3つの問題について取り上げます。
- 【問題1】「アジャイル」という言葉を悪用する不適切なチームマネジメント
- 【問題2】「見積」を「確約」と捉えることによる時間外労働の強制
- 【問題3】2週間おきの「コミットメント」と長期的プランの対立
【問題1】「アジャイル」という言葉を悪用するチームマネジメント
偽アジャイルにおける最初の問題は、管理者が数多くのプロセスやツールで「アジャイル」という言葉を悪用すること。この場合、エンジニアが「アジャイル」という言葉でプラスの影響を受けるケースはほとんどないでしょう。アジャイル開発における日々の「スタンドアップミーティング（チームメンバーが仕事の進捗状況や課題について話し合う短いミーティング）」を通じて、マネージャーはチームメンバーを非常に細かく管理できてしまう。それがまた、スクラム開発チームのスプリント（作業を行う区切られた期間）に対する彼らのコミットメント・業務を「確約」としてしまい、そのスプリントゴールを達成するためにエンジニアに長時間労働を強いることもできます（【問題2】を参照）。この状況が実際に起きている場合、その原因は「アジャイル開発」ではなく「チームマネジメント」にあります。
では次に、組織がチームマネジメントを適切に運用できているとしましょう。その組織が、アジャイル開発の原則や価値観を正しく取り入れるのに必要なことは何でしょうか？それは、組織がまず全社を挙げて、アジャイルの原則と価値観を理解することです。そのためには、上層部による的確なコミュニケーションそして迅速な社内変革が必要です。もしくは、アジャイルコーチのサポートを受けるという選択肢もあります。PagerDutyの場合は、アジャイルに特化したリーダーシップチームが「システム」「プロセス」「企業文化」を新たに構築し拡大しています。チームが潜在能力を最大限発揮できるよう、組織の効率性改善に絶えず取り組んでいます。これらの内容をもとに、この【問題1】に関するプロセスとツールの観点から、本来の「アジャイル」と「偽アジャイル」のチームや組織の特徴をまとめてみましょう。
アジャイル開発
- プロセスよりも人を大切にする。ソフトウェア開発を管理するのは「人」であって、プロセスやツールではない
- 常に同じプロセスやツールを使用することは、適切なソフトウェア開発方法でないことが多い
- 柔軟性に欠けるプロセスや意思疎通の妨げになるツールに注意する。ガイダンスとガバナンスはまったく意味が異なる
偽アジャイル開発
- 「完成の定義」などのプロセスに関する判断が、トップダウンで技術チームに指示される
- チームが「スクラム」や「カンバン」といったプロセス管理ツールのうち、どれをを使うべきか決めていない
- 管理者がエンジニアを細かく管理する目的で、スタンドアップミーティングやスプリントゴールを利用している
【問題2】「見積」を「確約」と捉えることによる時間外労働
2つ目の問題は、アジャイルの名のもと、意図的に「見積」と「確約」を同義として捉え、エンジニアに時間外労働を強いることです。この問題を2つに分けて考えてみましょう。
【問題2-1】アジャイルという名のもと意図的に「見積」と「確約」を同義として捉える
言葉の定義はチームの取り組み方に大きく影響します。スクラム開発手法の「スプリントコミットメント」について、アジャイル開発のスペシャリストであるマイク・コーン氏は次のように解説しています(引用元)。
“It is important that the team’s commitment not be viewed as a guarantee.（中略） The team’s commitment is to do its best. I’d like to see them make their commitment perhaps 80 percent of the time. It should be something they take seriously and should make most of that time. That’s needed for the business to gain confidence in what a team says it can deliver.”
「重要なのは、チームのコミットメントを確約と捉えられないようにすることです。（中略）チームのコミットメントはベストを尽くすことですが、問題が発生した時のために20%程度の余力は必要です。ベストとは、80%ぐらいの能力を出す状態ではないでしょうか。企業にとって大切なのは、納期を守り信頼を維持することです」
コーン氏の言葉からもわかるように、チームのコミットメントは確約と見なされないようにする必要があります。ベストを尽くしたあとは、アジャイル開発で繰り返される「短期間の開発サイクル（イテレーション）」ごとに、目標に対してどこまで完了したかを振り返り、その状況に合わせてプロセスを柔軟に変更することが大切です。
【問題2-2】エンジニアの時間外労働
エンジニアの時間外労働は、アジャイルというより企業文化の問題です。そもそもアジャイル宣言の基本には「アジャイルなプロセスで持続可能な開発を進める」という考え方があります。その実現のためには、エンジニアの時間外労働は必要ないはずです。技術チームのリーダーやマネージャーに必要なアクションの一つは、チームの適正労働時間を設定することです。例えば、責任者が技術チームに目標労働時間について話す際は、次のような話し方がよいと考えられます。
「皆さんには、週に40から50時間勤務していただきたいと思います。これは、平日の８時間と月7日間のオンコールシフトの時間に相当します。年に2回、時間外労働をお願いできることになっていますが、それは本当に必要な時だけです」
管理者はチームに対して日常的に時間外労働を要求することは望ましくありません。ただし、年に数回発生することは想定しなくてはいけませんが。それでは、この【問題2】において、持続可能な開発の観点から「偽アジャイル」のチームや組織の特徴として以下の現象が例として挙げられます。
持続可能な開発の観点からみた「偽アジャイル」
- 技術チームがスプリントにコミットした場合、それを確約と見なされる
- スクラム開発チームが常にスプリントコミットメントを満たしている
- 技術チームがスプリントコミットメントを満たすために恒常的に時間外労働をしている
【問題3】「2週間おきのコミットメント」と「長期的プラン」の対立
3つ目の問題は、スクラム開発において「2週間ごとにある量の納品物を完成させること」を意味するコミットメントが、ソフトウェア開発の長期的なプランを立てるプロダクトオーナーの考えと対立することです。ここでの「長期プラン」とはプロダクトロードマップを指し、すでに決定されていることがあります。しかし、そのプロダクトロードマップはプロダクトオーナーとエンジニアの双方向で決められるべきものといえます。そのため、プロダクトオーナーが次に解決すべき最重要問題を示しても、チームのエンジニアがそのロードマップに対して異議を唱えたり、他にチームが取り組むべきことがあると判断した場合は断ることができる状況が望ましいといえます。その結果、次のスプリントの計画を立てる際に、スクラム開発チームが最優先だと判断した業務を持ち込むことがあるのです。では具体的に、エンジニアがプロダクトロードマップに意見を述べたり、反対したりするのはどのような場合でしょうか？
- オンコールの呼び出しが頻繁で、心身ともに負担を抱えるチームにとって、インフラの改善が次のスプリントで取り組むべき最重要課題である場合。
- 実装スピードを優先するなかで、放置された修正点や追加作業が増大し、品質確保のためにチームがそれらの対応に集中できるようロードマップを調整する必要がある場合。
- 製品価値の向上に役立つフィードバックをユーザーやステークホルダーから受け、チームがロードマップを変更して指摘された課題解決を最重要業務として優先させる場合。
それでは、この【問題3】について、長期的計画の観点から「偽アジャイル」のチームや組織の特徴をみてみましょう。
長期的計画の観点からみた「偽アジャイル」
- プロダクトオーナーが技術チームに「解決すべき問題」を提供せずに、ソリューションを提供している
- 技術チームがプロダクトロードマップに対して意見を述べる手段がない
アジャイル開発を成功させるために
企業のアジャイル開発を成功させるために必要なのは「組織全体からの賛同」「技術チームの参加」「顧客中心の考え方」といえます。場合によっては、専任のアジャイルコーチの導入が必要になるケースもあると思います。アジャイル開発の原理原則を正しく理解し、その根本的な価値観を十分に理解したチーム・組織とは次のような姿をみせます。
- 「製品エンゲージメント」「収益への影響」「予測等のメトリクス」「組織の健康診断」「チームレトロスペクティブ」を駆使して、エンジニアが組織に前向きな影響力を与える。
- 「スクラム手法」や「カンバン手法」を使用したアジャイル開発チームが、持続可能なペースで業務を行い、顧客に想定された価値を提供し信頼を得ている。
- 最も価値があると納得できることに常に取り組めるようプロダクトロードマップを調整したり意見を述べたりする権限がエンジニアに与えられている。
- さらに、業務から離れて自由に開発に取り組む「HackWeek」などを定期的に開催し、自己裁量で組織にとって最重要な案件に取り組める。
PagerDutyとともに適切なアジャイル開発を実現しましょう！
アジャイル開発においてエンジニアが直面する問題は、実はアジャイル開発が原因ではなく、理解不足による「偽アジャイル」によって発生していることがあります。アジャイル開発は、決してエンジニアを苦しめる開発手法ではありません。「偽アジャイル」を回避するためには、アジャイル開発の原則と価値観への正しい理解が必要です。しかし一方で、本記事で紹介したような「偽アジャイル」ではなく、正当なアジャイル開発手法においても、エンジニアをケアし負荷を軽減する必要があります。エンジニアの負荷が下がれば下がるほど、高い集中力でスピーディなソフトウェア開発の実現性が増します。開発と運用を一手に担うDevOpsエンジニアであれば尚更、負担をケアすることで先進的なシステム開発・運用が可能になるでしょう。
エンジニアのケアや負荷軽減に向けた取り組みをお考えの方は、PagerDutyの活用がおすすめです。PagerDutyによるインシデント対応の自動化やスムーズな対応の実現は、エンジニアの負荷を軽減し、開発へのより高い集中につながります。PagerDutyには、エンジニアの負荷の軽減に関するさまざまな事例があります。PagerDutyを活用してエンジニアの負荷を軽減し、DevOps実現に向けた道筋を立てましょう。まずは14日間の無料トライアルで実際にお試しいただき導入効果を実感ください！
この記事が気になったら
PageDuty公式アカウントをフォロー
この記事の著者
PagerDuty
Manager, Solutions Consulting
ソリューションズコンサルティング マネージャー
PagerDuty
Manager, Solutions Consulting
ソリューションズコンサルティング マネージャー
ネットワーク機器メーカーにて、インターネット・データセンターのインフラ構築に従事した後、CDNベンダーにて主に動画・ゲーム・電子書籍サービスの拡張性ならびに信頼性向上・セキュリティ対策プロジェクトを推進。2022年よりPagerDuty株式会社にて、インシデント対応の自動化等、デジタルオペレーションのモダン化・成熟度向上を支援している。趣味は自家製スモーカーを使ったベーコン等の燻製作り。
SNS
関連ブログ記事
人気記事
検索
タグ目次
