なんちゃってアジャイルの卒業：経験から学んだ教訓
こちらは、公式アドベントカレンダー2024_A IT技術関連トピック Day.14 の記事です。
公式アドベントカレンダー2024_B 仕事術・キャリア・体験記も毎日記事を公開していますので、ぜひあわせてご覧下さい。
★Day13のアドベントカレンダー記事
「ChatGPTで実現する！マルチエージェントの考え方を取り入れたプロトタイプ開発」（Haruki Takenouchi）
はじめまして、こんにちは！アジャイル型開発経験者の塚田です。
ウォータフォール型開発の現場で約2年間、アジャイル型開発の現場で約12年間、開発エンジニア兼チームリーダーとして経験を積んできました！
アジャイル型開発の現場にいましたが、「ウォータフォール型ほどきっちりフェーズ分けされないものだ」「要望に柔軟に対応してプロダクトを作っていく」くらいの理解で、その理論を学ぶことはなく過ごしてました。
この度、SHIFTへ入社しアジャイルスクラムのトレーニングを受けてみると、「あれ？もしかしてこれまでいた現場ってなんちゃってアジャイルだったのでは？」「もっと改善してチームが良くなる方法あったのでは？」と気付きを得たので、学んだことの整理と合わせて現場における改善案をまとめてみようと思います。
アジャイルを知らないままアジャイル型開発をやっている方や、アジャイル型開発の現場で悩んでいる方の助けになれば嬉しいです。
アジャイルとは
まずはアジャイルスクラムトレーニングで学んだことを挙げていきたいと思います。
アジャイルスクラムトレーニングを受けてまず最初に教わったのはアジャイルソフトウェア開発宣言でした。
アジャイルソフトウェア開発宣言
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
この宣言の背景となるアジャイルソフトウェアの12の原則を要約すると以下のようになります。
可能な限り、動くものを、素早く作る。
できたプロダクトに対して顧客と開発者でフィードバックを行い、価値を高めていく。
自己組織的なチームが効率を高めるために定期的に振り返り、やり方を最適化していくことで精錬されていく。
「アジャイルとは概念だ」と言われますが、概念なだけあって抽象的な内容です。
設計も大事だけど、会話をして方針が決まっているならまずは動くものを作ってしまおう！ということですね。
せっかくなので一般的な開発手法のウォータフォール型開発と比較してみます。
ウォーターフォール型開発
ウォータフォール型開発は、前工程が終わらなければ次工程へは進めない、手戻りの少ない開発手法で、全ての機能がそろってからリリースを行います。
上から下へ滝のように工程が進むことからウォータフォールと呼ばれ、計画的に進めるのに向いてますが、長期化しやすく変更が難しいという特徴を持っています。
上の図で言うと機能①～③が揃ってリリースが行われるイメージです。（機能単位での開発は可能ですが、リリースは必ず１つのタイミングになります。）
アジャイル型開発
アジャイルソフトウェア開発宣言にある通り、アジャイル型開発は短期間でリリースを行っていきます。また、機能単位でリリースを行えますので、全ての機能がそろっていなくても問題ありません。リリースした機能は市場や顧客のフィードバックを受けて、さらに次のリリースへ向けて改善を行っていきます。
「素早い」「機敏な」「柔軟な」の意味を持つ英語の「agile」に由来する通り、変化に対応したスピード感のある開発が可能ですが、計画の不確実性が高く長期的な見通しが立てにくいという特徴があります。
機能単位で計画（＝要求定義～要件定義）からリリースまでを行っています。
※アジャイル型開発はよく循環円で表すことが多いですが、ウォータフォール型との比較を行うためここでは直列で示しています。
比較すると違いがより分かりやすくなりました。
リリースタイミングがバラバラなアジャイルと１回に集約されているウォータフォールは開発スピードやフィードバックをもらうタイミングが異なります。
機能ごとにフィードバックを受け取れるアジャイルは、機能単位でどんどん開発プロセスを回すことができそうですが、ウォータフォールは全てがそろわないと次に進めなさそうですね。 スケジュールや進捗管理は機能単位で動いているアジャイルより、ウォータフォールのほうが優れていそうです。
これらの内容を踏まえ、アジャイルとは
社会の変化に適用し、求められるプロダクトを短期間でリリースし、フィードバックを受け止めながらより良いモノへと成長させ続ける
と私は考えています。
（本当はこんな簡単な言葉で表せないのですが、まず「アジャイルって何」を考えたときのポイントとしてこれを置いています。）
短期間リリースにより社会のニーズに素早く対応していくという部分が、今の社会とマッチングしており、魅力的だと感じる部分だと思います。
よく言われているアジャイルはドキュメント不要！というのはアジャイルソフトウェア開発宣言にある 「包括的なドキュメントよりも動くソフトウェアを」 の部分に焦点が当たったものですが、 「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」 の部分からドキュメントが不要とは言っていないことも忘れないようにしたい部分でした。
スクラムとは
アジャイルと合わせて学んだのはスクラムです。アジャイルの代表的なフレームワークとして語られています。
スクラムについてはスクラムガイドを基に学びました。 学んだ内容を挙げると長くなるので、ここでは割愛いたします。ご興味ある方はこちらをお読みください。
私なりのスクラムの認識としては
スクラムチームという小人数のチームが一丸となることで、より価値の高いプロダクトを生み出していく
スクラムの三本柱を守ることによってプロダクトもチームも改善される
チームが成熟されればされるほど、効率的で価値があるプロダクトを生み出しやすい
「他の人の仕事だから関係ない」「自分に責任はない」ではなく、そのチームみんなが関係者であり責任を持つ
になります。
なんちゃってアジャイルの卒業
この学びから、成功するアジャイルとは何か、アジャイルがうまくいくには何が必要なのかを、実際の経験を交えて考えていきたいと思います。
結論から言うと、次の６つのことが重要だと考えています。
１．アジャイルスクラムの考え方・理論を関係者全員が理解する。
２．チームメンバー含めた全員がゴールのイメージの認識合わせを実施する。
３．完成の定義をはじめとして、全員が共通の認識を持つためのルールを作成する。
４．すべての作業を可視化し優先度付けする。
５．コミュニケーションを活発に行う。
６．振り返り（スプリントレトロスペクティブ）をリリース前に実施する。
なぜ重要か説明していきます。
１. アジャイルスクラムの考え方・理論を関係者全員が理解する
アジャイルスクラムの考え方はこれまでにも私なりの認識を述べましたが、これを全員が理解していないと価値の高いものが生まれないと思います。
私が実際にいた現場では、おそらく誰一人としてアジャイルスクラムを正しく理解していませんでした。それもあってか、
「リリースまでに機能がそろえばいい」
「確認の時間ないし、最初に決めたものを作ってしまおう」
という考えになりがちでした。
アジャイルスクラムの考え方では、プロダクトの価値は何か？どうすればより価値の高いものを生み出せるのかが重要です。
この状況でプロダクトの価値が高まるでしょうか？高まるとは考えにくいですね。
この意識はアジャイルスクラムの考え方・理論を全員が理解していれば、改善するのではないでしょうか？ 少なくとも何でもいいからリリースしようではなく、価値のあるものをリリースしようという考えになると思います。
２. チームメンバー含めた全員がゴールのイメージの認識合わせを実施する
プロダクトのゴールは何でしょうか？スプリントのゴールは何でしょうか？１で挙げた考えはリリースすることがゴールになっているように思えませんか？
リリースは対話の手段です。フィードバックを基に改善に繋げるもので、そのものはゴールにならないですね。
開発者がゴールイメージの認識を持っていないと、リリース＝ゴールとなりやすいように思います。
ゴールのイメージが共有されていれば、こうした部分は改善すると感じました。
３. 完成の定義をはじめとして、全員が共通の認識を持つためのルールを作成する
２にも通じる部分ではありますが、完成とは何か、ルールは何かの認識を合わせるのは重要です。
こんなことはありませんでしたか？
「リリースまで時間がない！ドキュメントはあとにしよう」
「ドキュメントのフォーマットが決まってないから、ここは重要だから書いておこう」
「コードを見ればわかるから詳細まで書かなくていいよね。次の開発期間が始まるし早く終わらせよう」
「ドキュメントを書かない」はよく見るなんちゃってアジャイルの典型ですね。
書いてはあるけど、その内容の粒度がバラバラだった経験はありませんか？ 私は「ここの部分をドキュメントに残しておいてほしかった」と落胆した経験があります。それも一度や二度ではありません。
作って終わり＝完成、ではありません。ドキュメントも揃って完成となると思います。そのドキュメントもあればいい、の考えでは品質がいいとは言えないです。記載内容がルール化されていれば品質も保証されたドキュメントが完成したと判断できると思います。
可視化とも繋がるこの部分の認識があっていれば、効率的で不具合も少ない開発が継続的に行えるのではないかと思いました。
４. すべての作業を可視化し優先度付けする
リリースに関する部分は可視化されているけれど、リリースに関連しない改善業務（例えば、開発環境の改善やこれまで作成したドキュメントの整備）はスプリントバックログに含まれていないという状況があった場合、開発者は開発に専念できるでしょうか？
スプリントバックログの作業の計画はしてありますが、改善業務はそこに含まれていないので、開発者目線では計画にない作業が発生して、本来行う予定であった作業へ影響を与えることになります。そもそも、その改善業務はスプリントバックログを止めてまで割り込むべき作業なのでしょうか？ もちろん、必要な場合もあるとは思いますが、「言われたから急ぎだろうし、割り込みで作業しよう」となることもありませんか？
プロダクトバックログ・スプリントバックログに全ての作業が含まれていれば、優先度で迷うことも、作業の見積もりが大きくずれることも少なくなり、開発に集中する状況が作れるはずです。逆に含まれていないと、計画以上の作業が開発者のタスクとなり負荷が増大する要因になりがちです。
負荷が高い状況が続くと、気持ちにも余裕がなくなり、目先のタスクを消化することで精一杯となり、価値を高めることを考えることができなくなりやすいのですべての作業を可視化するのは重要だと思いました。
５. コミュニケーションを活発に行う
「え？！それ変更になったんですか？」
「同じ機能なのに、プラットフォームの違いで動きが違う。なぜ？」
これはとある日の私が聞いた言葉です。
コミュニケーションが少ないがゆえに、変更が連携されず手戻りが発生したり、いざテストを行う時に挙動の差異を逐次確認することになる、というのがこの言葉が発せられた原因です。コミュニケーションが十分にとれていれば、情報は連携されるので効率的に開発／テストができます。
コミュニケーション不足が検討不足・考慮漏れの原因になっているケースもあります。
というのも、利用シーンを想定せず機能実装を行ったことで、「どうやって使うの？」「意味があるのか？」とリリース目前のレビューで議論が起こったのを見たことがあります。開発者の判断で、検討した機能仕様のレビューを同じ視点を持った開発者間でしか行わず、ユーザー目線で検証を行うテストメンバーを呼ばなかったことから、レビュー時に考慮漏れの指摘が起こっていました。
この状況も、横断的なコミュニケーションがとれていれば改善できるのではないかと思います。
６. 振り返り（スプリントレトロスペクティブ）をリリース前に実施する
リリースから次のリリースまでの期間をスプリントと考えたとき、振り返りをリリースの後に行うとその時には次のスプリントが開始しています。そうすると、改善が次のスプリントに反映しにくく、また実践して良かったことの普及も遅れていきます。
そもそも、アジャイルスクラムではスプリントの終了は振り返りが終わってから行います。先程例に挙げたような状態では、スプリントが終わる前に次のスプリントが開始されている状態で、健全な状態とは言いがたいと思います。
リリースまでを振り返りたい、という考えもあるのは理解できますが、スプリント開発とリリース作業とを分けて考えて、振り返りを実施する方が効果が高いのではないかと感じました。
私の過去の経験を元に、「なんちゃってアジャイル」が「成功するアジャイル」へ向かうための教訓を書いてみましたが、いかがでしょうか。他にももっと出てきそうではありますが、より良いアジャイルへの第一歩として、参考にしていただければ幸いです。
まとめ
簡単に意見を書きましたが、実際の現場に適用するのは難しいとは思います。
だからといって、そのままにしておくと課題ばかりが溜まっていき、目の前の作業に押しつぶされ身動きが取れなくなる、ということもありがちなのではないでしょうか？ 私自身、現場で働いている状態ではこうした改善案を見つけることはできなかったように思います。
広い視野を持ち、そこから課題を洗い出し、まずは簡単にできるところから始めてみるを実践できれば、今よりもっと良い価値を生むことができるはずです。自分たちで難しければ第三者へ依頼する、というのも一つの手ですね！
このまま適用すれば絶対うまくいくというわけではないですし、現場によって必要なものは違うので、あくまで一例としてお読みいただければ幸いです。
アジャイルスクラムの考え方・理論を理解すれば、もっと柔軟に考えられそうなので、私ももっと理解を深めていきたいと思います。
それでは、皆様よいアジャイルライフを！
参考：
アジャイルソフトウェア宣言
アジャイルソフトウェアの12の原則
スクラムガイド
執筆者プロフィール： 塚田千晶
ウォータフォール型開発を経験したのち、アジャイル型開発の現場に長く身を置く。
一念発起し転職。SHIFTへ入社。
アジャイルスクラムを学び、スクラムマスターになるべく日々勉強中。
★関連記事はこちら「スクラムについて学んだこと」
★SHIFTグループ公式アドベントカレンダー2024【A】 IT技術関連トピック Day15は「AWS完全初学者・非エンジニアでも分かる！AWSはじめの一歩」（田代 崚）
お問合せはお気軽に
SHIFTについて（コーポレートサイト）
SHIFTのサービスについて（サービスサイト）
SHIFTの導入事例
お役立ち資料はこちら
SHIFTの採用情報はこちら
PHOTO：UnsplashのNordWood Themes