アジャイル・スクラム開発に関するよくある誤解
アジャイル開発あるいはスクラム開発といえば、モダンなソフトウェア開発として当たり前のものになりつつあります。
一方で、アジャイル開発・スクラム開発は何かと言われると正確に答えられない人も少なくないのではないでしょうか？
かくいう私も去年くらいまでは、なんとなく素早く臨機応変にリリースしていたらアジャイルなんでしょ？程度の理解しかありませんでした。
そこで、認定スクラムマスターという資格を取ることにし、改めてアジャイル・スクラムを学んでみると、自分も含めて誤解している箇所が多分にあると感じました。
この記事では自分自身も誤解していたアジャイル開発・スクラム開発の思想についていくつかピックアップしていこうと思います。
そもそもアジャイルとは何か？
アジャイル開発と言われるものは、一般に「アジャイルソフトウェア開発宣言」という文章に記された理念に基づいた開発のことを指します。
キーとなる箇所はここでしょう。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
の文章だけだとピンとこないかもしれませんが、IPAがこの背後にある思想について詳しく解説しています。
これをきちんと読み解くと単に素早く臨機応変に、という以上の意味がアジャイルの理念には込められていることがわかります。
スクラム開発とは何か？
アジャイルはかなり漠然とした概念しか定義していません。そこでアジャイルの理念を実現する開発手法がいくつか提案されていて、そのうちの一つがスクラム開発です。
スクラム開発の定義はスクラムガイドといわれるものにまとまっています。
ざっくり説明すると、スプリントと呼ばれる短い周期の中で小さいゴールを設定してそれをフィードバックを得ながら確実に積み重ねることによって複雑な問題に対処しよう、という開発手法です。
これだけだと、単に素早く開発しているだけじゃないの？と聞こえますが、このスプリント中でスクラムの三本柱である「透明性」（作成物を見える状態にする）・「検査」（潜在的に望ましくない問題を検知する）・「適応」（プロセスを調整しプロダクトが正しい方向に進むようにする）を実現するという点が非常に重要です。
スクラムガイド自体はさほど長い文章ではないので興味のある方はじっくりと読み込むと面白いと思います。
今回はアジャイル・スクラム全体の定義に深入りするのではなく、よくある（というか自分が昔はそう思っていた節があった）誤解の部分を中心にこれらの定義を見ていくことにします。
誤解：アジャイル開発においてドキュメントは残す必要はない
アジャイル開発と比較されるウォーターフォール開発では仕様書をガチガチに固めてテスト結果もガチガチに書いて…というイメージがあるためか、アジャイル開発ではドキュメントを残す必要がないという主張をちょくちょく聞きます。
確かにアジャイル宣言では「包括的なドキュメントよりも動くソフトウェアを」と書かれており、一見するとドキュメントは重要でないように見えます。
しかし、それに続く文章をよく見てみましょう。「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」とありますね。
アジャイル宣言は決してドキュメントの価値を否定しているのではないのです。
このような誤解がある背景にはアジャイル宣言では意思疎通の手段としてドキュメントより対面での会話が重視されているというのもあるでしょう。
アジャイル宣言の背後にある原則には以下のように述べられています。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
ただこれは、一方通行になるようなコミュニケーションはやめましょうという話であって、ドキュメントの価値を完全に否定するものではありません。
スクラム開発ガイドにはドキュメント作成については直接の言及はありません。しかしながら、例えばスクラムの柱の一つに「透明性」があります。
透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。
透明性の担保の仕方は様々かと思いますが、メンバー全員に作成物が検査しやすいようにする手段としてドキュメントを用いるということは効果的に思います。
アジャイル開発においてドキュメントの残し方の流儀は定まっていませんが、価値は否定されていないことは留意して適切にドキュメントを活用しましょう
誤解：とにかくたくさんリリースするのがアジャイル開発だ
たしかに、アジャイル宣言の背後にある原則に「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」とあるので短いサイクルでリリースすることはアジャイルにおいて大切なファクターにはなっています。
しかし、これは12の原則のうちの1つでしかありません。
そもそもこの原則は単にリリースをじゃんじゃんしろ、という話ではありません。
この根底には、ステークホルダーの要求は不確実で変化しうるものなので、短いサイクルで成果を提示することでビジネスの舵取りをできるようにしようという考え方があります。
そのため、リリースでは中間成果物ではなく価値に結びつくものを出す必要があります。そして、そのリリースをフィードバックをステークホルダーから得ることで、不確実なものを明確にしていこうというものです。
スクラム開発ガイドではスプリントと呼ばれる短いサイクルでサイクルで製品をリリースする必要があります。しかし、ここでいうリリースは単にコードを書いて納品すればよいという意味ではありません。
スクラムではインクリメントというものを積み重ねることでプロダクトゴールの達成を目指します。各スプリントのスプリントレビューというイベントでステークホルダーとともにこのインクリメントを検査することになります。
つまり、インクリメントはステークホルダーに検査可能な状態である必要があります。コードが書かれてデプロイ可能な状態で、それがステークホルダーにとって価値があるかどうかの議論ができるような状態にする必要があります。
また、この検査するというステップも非常に重要で、この検査を通してプロダクトゴールへの進捗を確認し、次に何をするかを決定することになります。
つまり、単にリリース頻度が高いというだけではアジャイル開発ではなく、そこに対して徹底的に検証が行われてプロダクトゴールに向けて着実に前進していることができてこそ、アジャイル開発の原則のうちの１つを満たせる、ということです
誤解：アジャイル開発においては開発者はコーディングだけやっていればよい
アジャイル開発では従来開発では重視されていた作業の重要性は相対的に下がり、また12の原則のうちの１つに「シンプルさ（ムダなく作れる量を最大限にすること）が本質です」とあるため、非常に効率性が重視された開発のように思えます。
しかしながら、コーディングのような実装作業のみに集中するのがアジャイル開発での開発者の態度として正しくはありません。
アジャイル開発では実はかなりコミュニケーションを重視しており、その部分にそれなりにコストを割かなければなりません。
12の原則の１つに「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです」とあり、対面でのコミュニケーションを重視していることがわかります。
「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」という原則もあり、日々開発者はビジネス側の人間とコミュニケーションを取ることが求められます。
スクラムではスプリントごとに決められたイベントでチーム内でコミュニケーションを取ることが求められます。それぞれのイベントに対して最大何時間かということも定められて必要以上に長くなることは推薦されていません。
しかし、いざ実践してみるとそれなりにこのイベントに時間を取られるのがわかると思います。
他にもアジャイルとその実践であるスクラムの中をしっかり見ていくと、チーム内のコミュニケーションを非常に重視していることがわかります。コーディングだけやって高頻度にリリースしていればいいというものではないのです。
まとめ
アジャイル・スクラムの誤解されやすいと思われる点について解説しました。
実はアジャイル・スクラムではコミュニケーションが非常に重視されているという点は見落とされがちだと思います。また、ドキュメントのような伝統的開発で重視されていたものの価値も完全に否定するものではありません。
今一度、アジャイル開発は何かというのを学ぶというのはいろいろな発見があると思うので、ぜひリンクを貼った資料や他の詳しい解説を読み込んでみるといいでしょう。
Discussion