DXトレンド⑤ ― アジャイルその２―

前回は、アジャイルの登場や「スピード重視」を実現する特徴についてまとめました。今回は、アジャイル手法の代表的な「Scrumスクラム」について、開発プロセスの内容についてまとめてみます。

【代表的なアジャイル手法】

「アジャイルソフトウェア開発宣言」としてまとめられ発信されるまでにも、ウォーターフォール型開発プロセスの課題に対して様々な手法が提案されてきています。
アジャイル型開発プロセスとしてまとめられるまでの各種手法として、
ＲＡＤ（Rapid Application Development）やユーザー機能駆動開発（ＦＤＤ：Feature Driven Development）、さらには、リーンソフトウエア開発などが挙げられます。前回、自動車の生産方式についても触れましたが、このリーンソフトウェア開発方式は、トヨタ生産方式を研究した結果などを活用して、特に製造業を中心に展開されている方式名になり、少量多品種生産にも柔軟に対応可能な内容とされています。

また、アジャイル型開発プロセスとしては、以下の２つが著名です。

■ＸＰ（Extreme Programming）
XPが台頭した１９９０年代後半にはＥＣサイト（電子商取引サイト）がブームとなっており、開発を短期（半年程度）で完了させて早期にマーケットに投入し、以降も強化を短期で繰り返す開発スタイルが求められていました。
つまり、要件の変更が多く、開発スピードが最優先で求められることより、ＸＰは大きく取り上げられることになったのです。

ＸＰには、開発チームが行うべきいくつかのプラクティスが定められています。その中から、ＸＰを特徴づけるプラクティスをいくつか紹介します。

→反復（イテレーション）：アジャイル開発型プロセスで最も特徴として用いられる用語
全体の開発期間を、イテレーションと呼ぶ１〜２週間の短い期間に区切ります。
各イテレーションでは、設計～実装、テストを行い、一部の機能のリリースを繰り返し、徐々に完全なシステムを構築していく形式をとります。

→ペアプログラミング：XPの代表的な特徴
プログラミングは、二人一組で行うことにし、一人がコードを書けば、もう一人はチェックとの分業制をひきます。通常は、このペアは役割を定期的に交代することになります。このプラクティスによって、常にコードレビューが行われ、品質向上を着実に図ります。

→テストファースト：
前回の説明でも採り上げましたが、実装より前にテスト項目を洗い出して、実装はそのテストをパスすることを目標に行われます。テスト項目を先に作成することで、そのイテレーションで求められる機能の完成形が明確になります。
このテスト項目は、実装される部品の単位での確認と、完成された機能がお客さまの要求を満たしているかの確認から構成されます。

■スクラム（Scrum）
スクラムの特徴は、素早く柔軟に、動くソフトウェアを開発するために、まさに「チーム一丸」となることを整備・実現したところにあります。2019年にはラグビーのワールドカップが日本で開催され「One Team」という言葉が流行しましたが、まさに同じ、ラグビー用語が手法名となっているものです。

具体的には、下の２点を目標として整備されています。

• 小規模で、目標を共有して、自律的に自己管理ができるチームを目指す。
• 進捗や品質についても完全に見える化を目指す。

スクラムでは、産業界での様々なベストプラクティスに基づいており、それらがソフトウェア開発手法としての元となっています。これらのプラクティスは2003年に『アジャイルソフトウェア開発スクラム』としてまとめられています。

これから、スクラムの開発プロセスについて紹介しますが、用語を簡単に説明しておきます。

→反復（イテレーション）：スプリントという一定の期間（タイムボックス）を繰り返して、動くソフトウェアを作っていきます。 

→プロダクトバックログ：
案件管理は、プロダクトバックログという名前で一覧として管理されます。

→タスクによる開発推進：
各開発スプリントにおいて、優先順位の高い項目に対して、開発チームがそのスプリント内で開発できる目標とタスク（開発項目）を設定して、開発が遂行されます。

【スクラム：スプリントによる開発推進】

スクラムにおけるスプリントは、以下のような図で説明が行われることが多くあります。

上図において、

■全体を見ると、
アジャイル型開発プロセスを適用する際に、まず「プロジェクト立上げ」として体制整備やリリース計画策定、開発前に必要な準備を行います。
※立上げ段階で、「準備スプリント」として設定されることも多くあります。

続いて、スプリントの開発サイクルとして開発スプリントを何度か繰り返して、最終的にリリース（デプロイ）されます。
※リリース前に「リリーススプリント」を設定して、最終確認やリリースの合意形成を図ることも多くあります。

■１つのスプリントを見ると、
まずは該当スプリントで実現するプロダクトバックログの項目を選び、スプリント計画を策定、開発、日々の進捗確認などをデイリースクラムで、現物確認を中心に開発スプリントの開発後にスプリントレビューとして行います。

また、開発の際には、ペアプログラミング制が敷かれ、必ず開発中、開発後にペアの相手とレビューが実施されます。
スプリントの最後に、振返りレビューが行われ、今回のスプリントの振返りと次スプリントでの改善項目整理（PDCAサイクルの実践）が行われます。
※スプリントの１サイクルでの成果物は動くものであること複数（サイクル）回、回してようやく動くものになるのではなく、１サイクルで例え画面だけ、１機能だけだとしても、動くことが求められるのです。
※例え予定したタスクが完了しなくても、スプリント自体の期間の延長は行ってはいけません。次のスプリントに回すかどうかの判断を行う必要があります。
※デイリースクラムで使われる、進捗の可視化に係るプラクティスとして、タスクボードがあります。
タスクボードは、壁(またはホワイトボード)に３つの区画を作って、それぞれの区画を、ＴｏＤｏ(未着手)、Ｄｏｉｎｇ(着手)、Ｄｏｎｅ(完了)の状態を割りあてて、タスクを管理するというプラクティスになります。
一番使われているのが、付箋にタスクを書いて、タスクボードに貼っておくというスタイルです。このスタイルだと、作業の状態が完全にタスクボード上で表現されるので、タスクボードを見るだけで、誰が何をやっているかがすぐにわかるわけです。

【ウォーターフォール型に馴れている場合の留意点】

初めてアジャイル型開発プロセスを適用するに当たって、少し戸惑う点があると思います。自分の経験から、つい従来方式を適用してしまいがちな点を３点紹介します。

■要件の整理で使われる用語にまず慣れよう！
プロジェクト立上げ段階では、PMBOKで言うところの「プロジェクト憲章」に対応するものとして、インセプションデッキを整理する作業があります。ざっくりいうと、プロジェクトを貫くポリシーを整理することになります。
※インセプションデッキについては、10の質問に答えることを求められますが、まともに考えると、哲学的な議論にもなりかねず、意外に収拾がつかなくなることもあります。そのためか、世の中でもアジャイル型開発プロセス適用に限らず、インセプションデッキの１０の質問に対して回答するためのテンプレートなども多く公開されています。

その上で、要件はプロダクトバックログとして整理されますが、内容の種類は、

• テーマ（組織やお客さまの目的）
• フィーチャー（提供されるサービス）
• ユーザーストーリー（単にストーリーとも呼ばれる、システムの振る舞い）

という形で具体化されていきます。最後に、ユーザーストーリーは、それを実現するための必要な作業をタスクとして詳細化されます。

プロダクトに対する要件は、テーマ、フィーチャーなどいろいろと議論しながらユーザーストーリーに落とし込まれます。ユーザーストーリーの書き方については、
「【役割】として【行動】がしたい。それは【価値】のためだ。」
などの言い方が用いられます。例えば、「集客力やリピート率を上げたい」という場合を考えると、
「利用者の嗜好にマッチした商品を紹介する、それはお客さま満足度を上げるためだ」
などが挙げられ、この「マッチした商品を紹介する」部分をシステムとして実現することになります。

■見積りの考え方での違和感！
上記のユーザーストーリーに対して、開発チームにて作業量を見積るのですが、その見積り量のことをストーリーポイント（SP）と呼びます。この見積もりの仕方については、従来の「◎◎人月」のような絶対値での見積りではなく、相対的な形で行われます。
この「相対的」という部分が、少し戸惑いを感じるところになるかもしれません。つまり、「単位」として考えられるユーザーストーリーに対して、その他のユーザーストーリーのＳＰ値が何倍程度になるかという形で整理していきます。

その結果、例えば、単体でのＷｅｂ画面１枚だと、大体SP値が１とか、３かな…って感じで設定されることが多くなります。ただ、この辺りが、常に単体Ｗｅｂ画面は１人月だなというような従来見積方式での刷り込みがあると、何やらＳＰ値自体がまだるっこしいと感じてしまうかもしれません。

ただ、アジャイル型開発プロセスにおける開発チームにとっては、特に初めて結成されたチームの場合、生産性についても実績値のないまま、開発に着手することより、一旦、相対的な数値で見積もりを行い、タスク詳細化、並びにタスク/ユーザーストーリー開発の実績を積む中で、改めてこの開発チームの開発力が測定され、実績値として蓄積されてくるわけです。

アジャイル型開発プロセスにおける開発チームは自律性が重んじられることもあり、このように開発実績を通じて自分たちの実力を客観的に把握していくことも非常に重要な経験となる点に留意しておきましょう。

■バグの定義が少し違う！
アジャイル型開発プロセスでのバグとは、あるイテレーション内で発見された不備はバグとしてカウントせず、現在の開発スプリントで仕込まれ、次の開発スプリントで発覚した場合のみを指します。

つまり、計画主導型開発プロセスのように、バグが発覚した瞬間に、その内容に応じて追加レビューやテストを繰り返すような時間はありません。そのため、計画主導型開発プロセスに慣れ親しんだ方にとっては、若干、品質面では手ぬるいと感じる部分もあるでしょう。

勿論、アジャイル型開発プロセスでは、「早期に動くソフトウェアを開発する」との目標の下、進められるわけですが、バグを残したまま、本番に向けてリリースしてしまうことが許されるわけではありません。よって、アジャイル型開発プロセスでも、バグの影響の大きさによっては、各種防止施策の立案と実行が必須になることもある点は、従来とは何も変わるものではありません。ただ、その分、ユーザーストーリーの先送りや削減などを躊躇なく行うことになるでしょう。

※つまり、計画主導型は開発すべき要件が絶対なのに対して、アジャイル型では時間と工数が固定されていて、開発すべき要件が変動するという点が、計画主導型に馴れている場合には、大きなスキーム変動になると言えるのです。

【改めてアジャイル型開発プロセスの適用について】

アジャイル型開発プロセスの適用を考える際の要件として、以下のものが挙げられます。

• 対象システムがミッションクリティカルではない
• 要件の度々の変更が予想される
• 技術や対象システムの領域のエキスパートが参画している

そうすると、必然的に短い期間、少ない人数で、動くソフトウェアを早期に繰り返してリリースしながら、評価を固めていくような進め方がふさわしいということになります。よって、万一失敗したとしても、その被害は最小限に抑えられます。

逆に、アジャイル適用失敗プロジェクト典型例としては、大規模プロジェクトが挙げられるのですが、そこには関与する上位者や要員も多く、その調整だけでも相当な工数と時間を必要とすることが多いわけです。そして、その調整工数も計画に組み込む必要があります。その上で、しっかりと要求分析、設計段階で時間を掛け、プロジェクト関係者全員の合意形成を図り、かつ文書化して残した上で、次の実装を進めることが必要になります。

そのような状況では、「まずは作ってみましょう」と進めたとしても、「聞いてない」とか「イメージが違う」などの声が出ること必定、結果、手戻りが発生してしまうでしょう。
ただ、アジャイル型開発プロセスを大規模プロジェクトにも適用してみようなどの試みも多く行われてきているようです。
どちらにしても、お客さまも含めてチーム一丸となり、多能工や新しい技術（開発技術、利用技術とも）も習得、活用も厭わずにという進取の気性を持って進めることがポイントです。

まずは「やってみませんか…？」です。