「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」 #アジャイル

はじめに

◆この記事は何？
アジャイル開発における「要求」や「ユーザーストーリー」を細分化する記事です。

◆対象は？
要求やユーザーストーリーを整理する方
アジャイル開発に関わる方

◆ねらいは？
アジャイル開発に関わる方が、何気なく使っている「要求」や「ユーザーストーリー」の解像度を上げること

「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」は、書籍『テスト駆動開発』に出てくるフレーズです。

そして書籍『テスト駆動開発』の中で、私が最も印象に残っている文章です。

この文章に出会ってから、私は「言われた通りにシステムを作る」から脱却して、「システムを作ってユーザーの体験をどう変えるか？」を考えられるようになりました。システム開発におけるストーリーの重要性を実感できました。

たった一つのフレーズでしたが、私のエンジニア人生に大きな影響を与えました。

「要求」は「何がしたいか？」であり、ソフトウェア開発の課題の根源です。

『MORE EFFECTIVE AGILE』では、次のように言及されています。

プロジェクトの課題や失敗の原因を分析する研究は幅広く行われているが、筆者がソフトウェア開発に携わるようになった最初の25年間に目にしたものはどれも、問題の主要な原因が要求のまずさにあったことを示していた。つまり、要求が完全ではなかったり、正しくなかったり、矛盾していたりする、というのである。

「課題を掘り上げていくと、要求に問題があった」という状況は、多くの開発者が経験されているかと思います。

逆に言えば、開発の関係者が「要求」を理解することで、多くの問題を回避できます。

要求のライフサイクルは「要求の整理」を細分化できます。

アジャイル要求のライフサイクルは次のとおりです。

アジャイル要求は、次のようなストーリー形式で表現します。

私は<ユーザーの種類>として、<利益>のために<目標/要求>を望んでいる

例えば、「私はWikiユーザーとして、同僚と共有するために、ファイルをアップロードする機能を望んでいる」のように表現します。

ユーザーストーリーに関する考え方に、「3つのC」があります。

ユーザーストーリーはストーリー、ルール、完了基準の簡単な説明が記載されたカードに書かれています。

内容を簡潔にするために、わざと小さなカードを使うこともあります。
小さなカードに書かれたユーザーストーリーは、これからの議論のきっかけとなります。

ユーザーストーリーの利点の一つが、対話をもたらすことです。

要件の詳細は、開発者とステークホルダーの間で交わされる対話によって具体化され共有されていきます。

対話を通じて、ストーリーを洗練化させていきます。
例えば、ストーリー間の矛盾に気づいたり、技術知識を使って、新しいストーリーを生み出したり、代替ストーリーを考えたりすることができます。

そのため、開発者とステークホルダーの対話は継続的に続きます。

参考：

ユーザーストーリーには満足条件という形で確認のための情報も含まれます。
「受け入れ条件」といいます。

「受け入れ条件」は、概要レベルの受け入れテストとして表現されます。
開発中に実行されるのはこのテストだけではなく、実際にはもっとたくさんの技術的なテストが実行されます。

ユーザーストーリーに関連する受け入れテストがある理由の一つは、プロダクトオーナーがユーザーストーリーを正しく実装されていることを確認できる点です。

ユーザーストーリーがうまく書けたかを評価するために有用なのが「INVEST」です。

私が理解するまでに時間を要したのが「Negoriable(交渉できる)」です。ウォーターフォール開発の経験をアンラーニングすることで、私は「Negotiable(交渉できる)」の概念を理解できるようになりました。

「Negoriable(交渉できる)」はユーザーや開発者などで話し合いができることを意味します。

ユーザーストーリーは、要件定義書のような形式ではなく、その詳細の交渉をするためのプレースホルダ（一時的なもの）です。これは前述の「対話(Conversation)」と繋がります。

交渉することで、ユーザーストーリーを洗練化できます。

ユーザーストーリーが交渉可能なおかげで、事前に要件定義書が作成されている場合に陥りがちな責任の押し付けを回避しやすくなります。

この記事では、要求の細分化、ユーザーストーリーの表現方法、ユーザーストーリーの評価方法について紹介しました。

アジャイル開発に関わる方の参考になれば幸いです。