アジャイル開発とは結局何なのか

September 20, 2021

「貴社の開発プロセスはアジャイルですかウォーターフォールですか？」という質問を就職活動中に耳にすることが2,3度あった。質問に対する回答は「そうですね、まぁ、ほとんどアジャイルのような感じで進めていると思います。完全にアジャイルかはわからないですが、えっと、その辺りはチーム毎に工夫していますね。」まぁ大体こんな感じである。

当時の私にはこのような曖昧な回答がいまいち理解できなかった。正直、「これだから日本企業は」などとすら思っていた。当然である。そもそもアジャイルを理解していなかった。アジャイルで行うことは知っているつもりだったが、その目的や恩恵を把握できていなかったのである。全てのチームがアジャイルな開発を行っていると胸を張っていうことは極めて難しく、ウォーターフォールかアジャイルかという二項対立を迫った質問の筋が悪かったのだと気づけなかった。

就職活動から数年が経った今、業務だけであぷあぷすることも少なくなり、チーム運営に目を向けることができるようなったところで、改めてチーム開発のプロセスについて学びたいと思い2冊の本を手に取った。

アジャイルサムライ－－達人開発者への道
 Clean Code　アジャイルソフトウェア達人の技

ここで得られた知識を未来の自分のために記す。

アジャイルソフトウェア開発の原則

アジャイルソフトウェア開発とは何かと聞かれたら下記の開発宣言と原則であるというのが正しかろう。

アジャイルソフトウェア開発宣言

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

引用: https://agilemanifesto.org/iso/ja/manifesto.html

アジャイルソフトウェア開発の12の原則

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客さまの競争力を引き上げます。

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

情報を伝える最も効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。

アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

シンプルさ（無駄なく作れる量を最大限にすること）が本質です。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

引用: https://agilemanifesto.org/iso/ja/manifesto.html

アジャイルソフトウェア開発とウォーターフォール開発

上記の開発宣言と原則がアジャイルソフトウェア開発の全てであり、目的である。ここで明記しておく必要があるのはアジャイル開発は、 小さなチーム のマネジメントを行うための開発プロセスであるということである。アンクル・ボブ曰く大規模アジャイルは存在しない。

アジャイルソフトウェア開発の歴史的背景を鑑みた時にウォーターフォール開発が登場する。共通の目標のために中間目標を設定することで進捗を管理するというアジャイルの手法は直感的なものであり、ウォーターフォールが世を席巻するまで、明確な開発プロセスとして定義されないものの暗黙的に採用されていたプロセスであると考えられる。ところがウォーターフォールが世間に広まり、「分析 -> 設計 -> 開発」という3つのプロセスを手戻りを最小限にして実施していくという開発プロセスが定着した時代にアジャイルな開発プロセスは忘れ去られた(そうだ)。どうやらウォーターフォール開発がまるでうまくいっていないと気づいた1990年台に、先述の中間目標を設定するアジャイルな開発プロセスへの回帰としてアジャイルソフトウェア開発の布教活動が行われたと理解している。そのためアジャイルソフトウェア開発宣言ではレガシーな開発プロセスとの比較によって構成されている。ウォーターフォールの開発フェーズではプロジェクト期間を通して固定とされていた顧客からの要求を可変のものと定義し、それに耐えうるようにイテレーション毎にフィードバックを得るプラクティスを生み出した(再定義した)。

以上より、アジャイルソフトウェア開発が特に特殊な目的を持った開発手法ではないことがわかると思う。 1970-1990年にウォーターフォールを通して得た開発プロセスに対する知見を存分に詰め込んだ直感的な開発プロセスがアジャイルソフトウェア開発である。

アジャイルソフトウェア開発のプロジェクト運営

ここからはアジャイルなチームのプロジェクト運営について言及していく。アジャイルなチームとは開発者やテスター、ビジネスサイドの顧客を含めたグループである。開発者だけのチームではないことに留意されたい。

アジャイルソフトウェア開発の成果物

アジャイルソフトウェアではウォーターフォールで言うところのプロジェクト全体の設計書群や要件定義書のようなものは作成されない。その代わりにアジャイルソフトウェア開発でよく見られれる成果物について確認する。

マスターストーリーリスト、プロダクトバックログ

プロジェクトにおいて開発すべきもののリストをマスターストーリーリストやプロダクトバックログと言う。「開発すべきもの」は要件定義書ではなくユーザーストーリとして記述される。

ユーザーストーリー

ウォーターフォール開発における要件定義書はユーザーストーリーに代替される。アジャイル界隈の人々はどうやら「要件」と聞くと反射的に「ダウト！」とシャウトすることで知られているようだ。

ユーザーストーリーは例えば下記のようなものになる。

期限切れアカウントでのログイン
現状の10秒かかるページの読み込み速度を2秒まで縮める
ウェブカメラでビーチの様子を配信する

また、テンプレートとして

＜ユーザーの種類＞として＜達成したいゴール＞をしたい。なぜなら＜理由＞だからだ

と言う文章を使用することもできる。

INVEST

Independent
Negotiable
Valuable
Estimable
Small
Testable

の頭文字をとってINVESTである。これらを意識してユーザーストーリを作成するようにする。

受け入れテスト

ユーザーストーリーに付与される「完了条件」である。「完了」の条件は必ずテストで記述され、テストは自動化されているべきである。

ストーリーポイントによる見積もり

ユーザーストーリーに対する見積もりである。日数をそのまま見積もりに使っても良いが、ストーリーポイントと言う指標を用いることが多く、どちらの書籍でも推奨されている。

ストーリーポイントは相対的な指標である。アーキテクチャを横断し、プロジェクトを代表するユーザーストーリーを一つ決め、そのユーザーストーリーのストーリーポイントが例えば3だった時にそれぞれのユーザーストーリーのストーリーポイントを相対地として定義する。代表として選ばれたユーザーストーリをゴールデンストーリーと呼ぶ。

ストーリーポイントの見積もり方法はいくつか手法があるので、気になった方は調べてみることをお勧めしたい。

スパイク

ストーリーポイントが皆目検討もつかないという場合も考えられる。その際は該当するユーザーストーリーのストーリーポイントを見積もるための技術検証を行うストーリーとしてスパイクが作成される。スパイクの完了条件は該当するストーリーポイントの決定であり、スパイク自体のストーリーポイントは検討時間として見積もられる時間(そんなものを見積もれるとは思えないが)ではなく、スパイクを完了させるまでの期限であることが多い。

制約

「ホームページは格好良くしてください」などの要求はユーザーストーリーに落とし込むのが極めて難しい。このような要求については制約という枠組みで扱う。

制約は定期的にテストされ、ストーリー全体に占める割合はそう多くならない。

インセプションデッキ

インセプションデッキはプロジェクトを進めていく上での共通認識である。プロジェクトに対する「Why」と「How」の部分をチームで検討する。

インセプションデッキはアジャイルソフトウェア開発においてよく用いられるが必須ではない成果物である。インセプションデッキはプロジェクトの初期に作成され、構築には数日から2週間の期間を見込む必要がある。また、プロジェクトに大きな変更が起こった際などは、再度インセプションデッキを改訂する機会を設ける必要がある。完成したインセプションデッキは全員が見える場所に配置されるべきである。

代表的な課題としては下記のようなものが挙げられる。

我々はなぜここにいるのか？
エレベーターピッチを作る
パッケージデザインを作る
やらないことリストを作る
「ご近所さん」を探せ
解決案を描く
夜も眠れなくなるような問題は何だろう？
期間を見極める
何を諦めるのかはっきりさせる
何がどれだけ必要なのか

これで過不足がないわけでは決してない。チームの状況に応じて質問は追加されたり省かれたりするべきである。

絶対に必要なのはプロジェクトの「Why」を共通認識として持つことである。

次に考えることは「納期」「費用」「品質」「スコープ」の4つのパラメタに対する共通認識の構築である。ここで、重要なのは

「納期」は絶対
「費用」(スタッフの人数)はプロジェクト初期でほぼ固定
「品質」は原則から最大
可変なパラメタは実質「スコープ」のみ

であると言うことだ。

それぞれの固定するべきパラメタと「スコープ」に対してプロジェクト初期から明記できるものについての共通認識を深める。

バーンダウンチャート

一回のイテレーションで消化できたストーリーポイントを「ベロシティ」と呼ぶ(まんま速度って意味だが...)。ベロシティはチーム全員が見える場所に可視化されていることが好ましい。

また、プロジェクトの残りのストーリーポイントについてもイテレーション毎に可視化されているべきである。この残りのストーリーポイントのグラフをバーンダウンチャートと呼ぶ。

バーンダウンチャートがあることで、現在のプロジェクトの進捗が明らかになる。また、ベロシティの低下にもいち早く気づくことが可能であり、知らない間に開発速度が落ち込んでいたと言うことを防げる。

これらは定量化しづらい開発速度に関する貴重なデータである。

イテレーションでのイベント

アジャイルソフトウェア開発において欠かせない取り組みは機体をマネジメントすることと、フィードバックを得ることである。それぞれを行うためのイベントについて確認していく。

開発、実装

ユーザーストーリーの実装を行うフェーズであり、イテレーション期間の大部分を占める。

ウォーターフォールで言う「分析 -> 設計 -> 開発」は全てここに含まれると言う場合もあるが、分析のみは前イテレーションに先んじて行うと言う方法もある。

また、忘れてはならないのが、開発の終わりは受け入れテストをパスしたタイミング以外にないことである。

受け入れテストの準備

受け入れテストはユーザーストーリーの完了条件であるため、ユーザーストーリーの実装が開始されるイテレーションの前には自動テストが実装されていることが好ましい。

テスターはビジネスサイドの人間と連携して先んじて次回スプリントに含まれるユーザーストーリーを把握しておく必要がある。

ストーリー計画ミーティング

ストーリー計画ミーティングはイテレーションの作業準備であり、イテレーションの開始タイミングで行う。

ストーリー計画ミーティングではジャストイン分析の結果を共有する。ジャストイン分析とはユーザーストーリーの完了に対してどのような開発が必要かの調査フェーズであり、ウォーターフォールの分析フェーズと区別してここではジャストイン分析と読んでいる。

その他にも、今回のスプリントにて実装されるストーリーの受け入れテスト条件や見積もりの数値確認を行う。

ショーケース

イテレーションの最後に顧客に対して実装したストーリーをデモする場である。顧客からフィードバックを得ることができ、プロジェクトの方向がぶれていない事を確認できる。

ここでデモするのはモックではなく、実装したコードをデプロイしたものであることに留意されたい。

イテレーション計画ミーティング

イテレーション計画ミーティングでは次回のイテレーションで実装するストーリーを決定する。これまでのベロシティを確認し、現実的に完了可能な量のストーリーを次回のイテレーションのスコープとする。

また、ベロシティなどからチームの健康状態を確認する機会でもある。

振り返りなど

アジャイルレトロスペクティブなどの振り返り手法は多々あるので参照されたい。

デイリースタンドアップ

毎朝立ったまま15分ほどで

昨日やったこと
今日やること
困ったこと

を共有する。スタンドアップなのは短時間で終わらせることを明示するため。

まとめ

それぞれのイベントをまとめたり、やらなかったり、不足と思われるものを追加したりすることは自由に行って問題ない。自分たちのチームに合っていると思う方法に調整していくことが重要である、それこそがアジャイルなチームの醍醐味とも言える。

Q&A

ビジネスの人って誰？

プロジェクトの方向を決める権限を持っている責任者である。これらの役割を担う人物を「スクラムマスター」や「オンサイト顧客」と呼ぶ。意思決定権はビジネスの人にあり、開発者は彼と協業することでプロダクトを構築していく。

必ずこの顧客をチームのメンバーとして扱うことがアジャイル開発の一つの条件であり、それぞれの書籍でどのように彼らを巻き込むかについて様々な方法を述べられている。

完成していないストーリーのストーリーポイント

イテレーションの終了、ショーケースにて完了していないストーリーのストーリーポイントはそのイテレーションに完了したストーリーポイントとして計上しない。半分終わっていようが、9割終わっていようが完了してないものは完了していない。

また、このようなストーリーが頻発する場合は

ストーリーが大きすぎないか
コミットする作業量が多すぎないか

などを疑い、問題があった場合は早急に対応する。

参考

https://www.atlassian.com/ja/agile/project-management/metrics

大規模なリファクタリング

1年前に自分が書いた大量のスパゲッティを見て吐き気を催した場合、それをストーリーに含めるかどうかは議論の的となっている。

基本的にアジャイルソフトウェア開発は顧客に継続的に価値を届けることを目的の一つとしているため、何の機能追加もバグ修正も行わないリファクタリングはユーザーストーリーとして扱うことはできない。リファクタリングは継続的に実施されるべき開発の営みであり、特別に時間を取ることなくそれぞれのユーザーストーリー実装時に少しずつ行われるべきものである。

ただし、顧客が技術的負債について高い理解度を誇り、リファクタリングが推奨される環境ではその限りではないという説もある。

リファクタリングを大々的に行うという決定を下した場合も0, 1でリファクタリングのみに取り組むという決断は下されるべきではないという意見に私は賛成である(私見である)。

リファクタリングを行った期間は価値のある機能提供は断念せざるを得ず、短期的な開発速度の低下に繋がる。一方、技術的負債を放置するとチームのベロシティはなだらかに減少していく。これらのバランスを取れるようにリファクタリングへどの程度舵を取るかはチームで協議する内容であり、リファクタリングの目的は最終的な顧客への価値提供の量で判断されるべきである。

参考

https://www.infoq.com/jp/news/2009/06/stop-and-refactor/

納期のない開発

保守運用が主業務のチームでは納期がないとみなされる場合が多く、この場合どのようにプロジェクト期間を設ければ良いかわからないという問題が生じる。

解決策の一つとしてはイテレーション期間を設けないカンバンのような開発プロセスを採用することが挙げられる。イテレーションで得られる顧客からのフィードバックや、開発速度の可視化を犠牲にする代わりにプロジェクトの管理コストが大幅に減少する。

しかし、一点考えたいことは本当にプロジェクトの期間が存在しないのかということである。会社で仕事をしている限り、年度ごとの予算割り当てや、VCへのピッチイベントがあるはずである。これらをプロジェクト期間と捉えることで適切にイテレーションを回すことが可能となる。

ちなみにプロジェクト期間は長くとも6ヶ月以内が推奨される。

見積もり不要論

https://medium.com/i35-267/%E8%A6%8B%E7%A9%8D%E3%82%82%E3%82%8A-estimate-%E3%82%92%E3%81%97%E3%81%AA%E3%81%84-%E7%B5%B6%E5%AF%BE%E3%81%97%E3%81%AA%E3%81%84-aeee1dadec7f

見積もりをしない派閥もいるらしい。十分に信頼を得ているチームなら進捗を毎度見せる必要もないしベロシティも把握できているという論調である。アジャイル開発はどのような開発プロセスにするか具体的に決定されているものではないので、このような選択も可能である。

アジャイルソフトウェア開発のプログラミング

以降はプロジェクト運営ではなく開発者がプログラミングを行う際や、開発チームが行うべきプラクティスが述べられる。基本的にはXPのプラクティスを列挙しているだけである。

共同所有

コードはチームのものである。個人の資産ではない。自分が作成したコードを誰にも触らせないというようなことがあってはならない。

継続的インテグレーション

コードベースは単一のメインラインを保持し、それ以外のラインは頻繁にメインラインを自身に統合するべきである。また、開発者の使用したラインも可能な限り頻繁にメインラインに統合されるべきである。

ブランチの統合は痛みを伴うものであるが、頻繁に行うことで全体としての痛みを劇的に緩和することできる。

持続可能なペース

燃え尽きてはいけない。気付けば朝だったと誇らしげにいうべきではない。

リファクタリング

以前の節で言及したが、リファクタリングは各開発において意識すべきことであり、リファクタリングのための工数やストーリーというものは確保されない。

継続的インテグレーションで述べたことと同様にリファクタリングも頻繁に行うことで全体として負荷を大幅に減少させることができる営みであるため、コードを修正するたびに目につく部分は全てリファクタリングをしながら開発を進める。

テスト駆動開発

いわゆるTDDである。TDDを行うことでカバレッジは100%に近づき、テスタブルな設計が強制的に行われる。 TDDは以下の3つのルールで構成される。

失敗するテストを書くまではプロダクションコードを書いてはいけない（テストはコードの不足が原因で失敗する）

失敗するテストを必要以上に書いてはいけない（コンパイルの失敗も失敗に含める）

プラダクションコードを必要以上に書いてはいけない（失敗しているテストをパスさせるためだけに書く）

失敗するテストを書く -> テストを通すようにプロダクションコードを書く -> リファクタリングを行う

という短期間のサイクルを何度も続けるという開発手法であり、これは広く一般に知られる開発方法の最適解の一つである。

ペアプログラミング

同期レビューはレビュー待機時間を大幅に削ることができる。生産性が落ちないかって話だが...調査不足なのでそれぞれ調べてみて欲しい。

まとめ

アジャイルソフトウェア開発として様々な具体的プロセスやプラクティスが生み出されている。

スクラム
XP
カンバン

などが知られているが、そのどれもが冒頭に記された開発宣言と原則を実現するための手段に過ぎない。そのため、実際のアジャイルなチームは臨機応変にルールを変えチームをマネジメントして最高のバリューを発揮していく。

ここでまとめたエッセンスがアジャイルな開発の一助となれば幸いである。