記事を書こうと思ったきっかけ
こちらの記事はこのテーマを見たきっかけで書こうと思いました。
エンジニアリングマネージャの活動をしているため、組織やチームについて自分の中にある思考の一部を整理するきっかけになればと考えました。
テーマ概要には
あなたが「組織」や「チーム」の中で実施してきたコミュニケーションに関する実践内容や考え方をぜひシェアしてください！
とあったため、比較的広く募集しているが、「感想」よりは「実践」の結果の知識の共有の方が良いのかなーと、考えたりしていました。
アジャイル開発に書かれた記事を見つけた
その中で、アジャイルに書かれた１つの記事が目に止まりました。
私はアジャイルの考えと手法はとても好きです。
私はアジャイル開発やそれらのフレームワーク、あるいはそれらを取り扱うためのエンジニアリングマネジメントなどに興味を持って知識を学びながら、実践してきました。
ですが、利用方法を間違えると悲しい結果になる様子もよく見てきました。
十分な知識がなく、誤解をしたまま表面的な取り組みをしているとそのようなことになります。
私の考えと少し違うと感じた
どうやら私の知っているアジャイルのデメリットと解釈が違うので、直接記事を上げながら比較することは正直微妙な手段だとは感じつつ、私の今までのアジャイルをチームに導入する中での違いを共有し、相互に見比べることでアジャイル開発の考察を深めてもらえると良いと思いました。
私の考えが合っている！と言うつもりはなく、自分の考えはここに書かれた考えの延長線上にあり、アジャイルを深くチームが辿り着く話だと思っています。
デメリットの解釈の違い
1. スコープの不確実性
アジャイル開発では、要件が頻繁に変更されることが前提となっているため、プロジェクトのスコープが不確実になることがあります。これにより、プロジェクトの全体像や最終的な成果物が明確でない場合があります。
欲張ると、際限なく、やる事が出てきてしまい、結果として、「何も解決しなかった」となります。
アジャイル開発は、要件が頻繁に変更されることが前提ですが、要求は明確です。
価値にフォーカスして変化の受容するからです。
この言及は要求が明らかになっておらず、最終目標が明確でないために成果物が明確になっていないと感じます。
アジャイル開発では「何の価値を得るか？」の要求に対して非常に厳しく認識を合わせ、「どのように解決するか？」の要件は現場の権限に大きく移譲されています。
今まで通り「何を作れば自分の仕事を果たせたことになるのか？」と作るものばかりに目を向けていては、「何の価値を届けるために作っているのか？」は理解が深まることはないでしょう。
2. ドキュメント不足
アジャイル開発では、動作するソフトウェアを重視するため、ドキュメントの作成が後回しになることがあります。これにより、後続のメンテナンスや新しいチームメンバーのオンボーディングが難しくなることがあります。
最初に、共通のドキュメントを作成するのを忘れてしまうと、後から作るのがかなり大変な事になるので、ラフで構わないので、用意しておくことをお勧めします。
アジャイル開発ではコミュニケーションや継続的に動くソフトウェアを維持するためにドキュメントを書くことは当たり前になっています。しかし、必要以上のドキュメントは書きません。
継続的に動くソフトウェアを維持し続けるためにドキュメントが必要なことはここでも書かれている通り明らかです。
つまり、動作するソフトウェアを重視するために、それに必要なドキュメントは書くのです。
ドキュメントを書かないのはデメリットではなく、価値が何にあるか？を議論できていない勘違いです。
最近ではアジャイル開発のスタイルの会社でPRD、Design Doc、ADRなどのドキュメントを書くことを導入する企業も多くなっています。
ここで重要なのは仕様を書き切ることではなく、このドキュメントがもたらす価値が何か？を重視します。
3. チームの依存度
アジャイル開発は、チームの協力とコミュニケーションに大きく依存しています。チームメンバーが分散している場合や、コミュニケーションがうまく取れない場合、アジャイルの効果が減少することがあります。
バックグラウンドの違うエンジニアが集まると、言葉がかみ合わないことがあります。チームメンバー全員が理解するのを待って、タスクを進めようとすると、いつまでもタスクが進まないような事態になる可能性があります。
コミュニケーションの問題はアジャイル開発の問題ではないと思われます。これは問題を先送りしているだけです。間違ってもいいからタスクを進めようとして手戻りが多く発生したり、リリースギリギリになって解釈の間違いが発覚したりするだけです。ウォーターフォールならそれが起きないのでしょうか？そんな事はありません。
チームメンバー全員が同一の知識を持たなければならないと思っているのであればそれも違います。アジャイル開発は多能性を受け入れたコラボレーションを生み出す場です。人の得意なことは自分も得意でないといけないわけではありません。どの様に連携すると一番チームとしての力が発揮できるのかを考えます。
タスクを捌くだけとして成果を考えたときには足し算にしかなりませんが、アジャイル開発はチームの力を掛け算で成果を出すことを期待しています。
4. 顧客の関与が必要
アジャイル開発では、顧客やステークホルダーの頻繁なフィードバックが求められます。顧客が十分に関与できない場合、プロジェクトの方向性が不明確になり、期待に応えられない可能性があります。
顧客の意見を全て聞いていると、本当に聞きたい事と聞いてもあまり意味がない事全てを聞く事になりかねません。もし、顧客が作業を進めるために必要な知識を持ち合わせていない場合は、要点を確認し、不要な話に逸れないようにする工夫が必要です。
「顧客の意見を聞く」の言葉の意味を誤解しているように感じます。
プロダクトマネジメントでも「顧客の声を聞くのが大事」とよく言われますが、言ったことを叶えることがアジャイル開発チームの仕事ではありません。
本当に大事なのは顧客の声を聞いて、「本当の解くべき課題は何か？」を理解することです。
開発現場にいても本当の解くべき課題は見えません。そのため、「顧客の声を聞く」のです。
「顧客の声を聞く」は御用聞きのことではありません。
アジャイル開発チームが何を解くことが最も価値に繋がるかを理解するためです。
顧客に伝える要点を確認するとありますが、まさに「価値」のためのポイントを顧客に伝えることが話が逸れない工夫なのだと感じています。
5. スケジュールの管理が難しい
アジャイル開発では、スプリントごとに成果物をリリースするため、全体のスケジュール管理が難しくなることがあります。特に大規模なプロジェクトでは、全体の進捗を把握するのが難しくなることがあります。
アジャイルが向いているのは、あくまで小規模なプロジェクトです。大規模なプロジェクトでは、プロジェクトを細分化し、アジャイル出来るレベルまで、管理できる規模を小さくする工夫が必要です。
大規模組織向けのScaled Agileのフレームワークも多く生まれており、既にかなりの会社で導入が進んでいます。Scrum@ScaleやLeSS、SAFeなど大規模フレームワークの事例も多くあり、小規模向けのプロジェクトしかできないのは誤解です。ただ、大きな組織をアジャイルな組織に生まれ変わらせることは小さな組織を変えることよりも難しいことは確かです。
スプリントごとの成果物を必ずデプロイしなければならないと思っているならば、それも誤解です。成果物は開発生産したバリューチェーンのどの位置に属するかは場合によります。もちろん小さなチームであれば１つのアプリケーション機能の設計からユーザーが利用できるリリースまでを担いますが、大きな組織や大きな開発はそうとは限りません。半年掛かる開発のとき、ユーザーが使える状態のリリースじゃなければ成果物ではないのか？と言われると、中間成果物はユーザーに使える状態のリリースではないことは分かると思います。
6. 技術的負債の蓄積
アジャイル開発では、迅速なリリースを重視するため、技術的負債が蓄積されることがあります。これにより、後続の開発やメンテナンスが困難になることがあります。
迅速なリリースを重視するため、既にリリースしてしまったものをもとに戻すのが困難になってしまう場合があります。そのため、リリースしたものをバージョン管理し、後日、戻せるようにする工夫が必要です。
迅速なリリースが重視されるため、迅速なリリースが常に可能なように開発を行います。つまり、技術的負債を最小に抑えることが期待されています。
目の前の１回の迅速なリリースを優先せず、変化に柔軟に対応できるための迅速なリリースを維持し続ける仕組みが必要です。そのため、自動テスト、CI/CD、revertの仕組み、roll forwardなど、繰り返しリリースするコストの低減や障害発生時の復旧の時間の短縮も迅速なリリースのために必要な要素です。
継続的な機能開発や機能変更に耐えられるような内部設計のクオリティを維持することも重要です。そのためにDesign Docで議論をしたり、コードレビューを実施し、コードの品質を維持しながらチームの実装ナレッジの共有でチーム全体のレベルを上げることも継続的に行うことが大切です。
アジャイル開発のせいで技術的負債が溜まるのではなく、アジャイル開発を維持するために考えが足りないから技術的負債が溜まっているだけです。みんなで議論してソフトウェアを素早く維持できる環境を作る提案や議論をすることが期待されています。
7. 適用が難しいプロジェクト
アジャイル開発は、すべてのプロジェクトに適しているわけではありません。特に、規制が厳しい業界や、明確な要件が必要なプロジェクトでは、アジャイルの適用が難しいことがあります。
アジャイルでは、当初の要件が、やっているうちに変わってしまう事が良くあります。明確な要件を最初に決めた場合、無理やり要件につじつまを合わせるような事態になってしまい、ちゃぶ台をひっくり返す事態になりかねません。
アジャイルの適応が難しい業界やフィットしないプロジェクトがあるのは正しいですが、規制が厳しい業界や明確な要件が必要なプロジェクトこそアジャイルがフィットする場合もあります。
規制が厳しいからこそ、先にその不確実性を潰してプロジェクトを進めたいと考えるが、不確実性が０になるまで進めないといつまでもプロジェクトが進みません。そのため、ポイントとなる箇所は変わる前提と理解したまま、不確実性が低い開発する箇所を進める柔軟性を持ったまま進めることはアジャイル開発です。
事故が起こると大変なテスラや法規制が厳しい決済事業などの新しい事業はほとんどがアジャイルに開発を行っています。
8. チームのスキルと経験に依存
アジャイル開発は、チームメンバーのスキルと経験に大きく依存します。経験の浅いチームでは、アジャイルの原則をうまく適用できず、プロジェクトが失敗するリスクがあります。
アジャイルという形から入ってしまうと、アジャイルの部分活用になってしまい、結果として、中途半端なものをアウトプットとして提示する事態になりかねません。
アジャイル開発の経験の浅いチームが失敗するのはその通りだと思います！
素人プログラマーが集まってシステムを作ったら上手くいきそうにないのは当たり前です。
なのに、なぜだかアジャイル開発の場合は誰もやったことがないのにやってみたら上手くいくと信じられているようです。
興味を持つというのは１歩目としては非常に大切です。しかし、体系的に学び、実践して身に付けなければプログラミングもなかなかできないように、アジャイル開発も概念がわかればすぐ出来る！というものではないと思っています。始めるのは簡単ですが、上手くやるにはそれなりに知識や経験が必要だと思います。
諦めずに学習と実践をして成長することで使いこなせるようになってくるスキルの１つです。
もし短期間で効果を実感したいのであれば、アジャイルコーチやスクラムマスターを業務委託でも良いので外部から採用する手段も考えると良いでしょう。
(ただし、素人プログラマーがたくさんいるのと同じように、素人スクラムマスターもいるので、どのレベルのアジャイルの文化を導入して欲しいのかに合わせて見極める必要があるでしょう)
9. リソースの過負荷
アジャイル開発では、短期間での成果物のリリースが求められるため、チームメンバーに過度な負荷がかかることがあります。これにより、バーンアウトや生産性の低下が発生する可能性があります。
成果を意識し過ぎて、誰かに過度な負荷がかかることがあり、特定の誰かが燃え尽きたり、プロジェクトから離脱したりするような事態があり得ます。
短期間の成果も求めていますが、中長期的な安定した開発も求めています。
技術的負債の項目にもありましたが、アジャイル開発に期待されることを実践しようとした場合、短期的な目線だけでは実現できないことが多くあります。
アジャイル開発では属人性やトラックナンバーの考え方もよく話題に上がります。それらを含めてチームで話し合うチーム文化の土壌もアジャイルでは期待されています。
10. 長期的な計画の難しさ
アジャイル開発では、短期的なスプリントに焦点を当てるため、長期的な計画や戦略が見えにくくなることがあります。これにより、プロジェクトの全体的なビジョンや目標が不明確になることがあります。
やっているうちに目的が変わるため、当初考えていた事や想定していたことから逸れて、「結局、何がやりたかったんだっけ？」という事態になる事があります。
短期的なスプリント"だけ"に焦点を当てることは間違っています。価値に対して焦点を当てています。
例えばスクラムではプロダクトゴールを定義して、そのためにスプリントゴールを設計することが推奨されています。プロダクトゴールは中長期的な目標です。そもそも「何がやりたかったんだっけ？」という状態になることこそが、アジャイルの本質から外れています。
常に「価値」を問いながら活動することがアジャイルだと思っています。
まとめ
これらのデメリットを理解し、適切な対策を講じることで、アジャイル開発の効果を最大限に引き出すことができます。アジャイルがすべてのプロジェクトに適しているわけではないため、プロジェクトの特性やチームの状況に応じて適切な開発手法を選択することが重要です。
デメリットの解釈に少々の違いは感じましたが、このまとめの言葉は完全に同意です。
アジャイル開発は全てのケースをカバーするものではないです。
しかし、「価値」にフォーカスを当て、柔軟に変化するアジャイル開発の考えが非常に好きです。
その可能性の広さは最初にアジャイル開発を学び始めたころとは違って、とても大きいと感じています。
今までの開発の方法と違うため理解することは難しく、変えることに苦労することもあると思いますが、アジャイル開発を楽しんでもらえると嬉しいと思っています。
最後に
指摘、疑問、質問、相談、感想などがあればコメントなどにいただけると嬉しいです！