ここ2日ほど、まるっと一日かけてチーム全体であつまってプロジェクトの要求仕様書を皆で作るという作業をしていました。

弊社のチームでは普段の開発ではスクラム開発を実施しているのですが、今回この一気に要求仕様書をつくりあげるというイベントを開催するにあたり考えた事を自分のための整理として残しておきます。

プロジェクトの背景

現在開発しているプロジェクトは新規事業であり、かつ現在のチームでとりくむ事が初となる toB を想定したプロジェクトです。

また、ノーコードでプロダクトの検証をしているマーケティングチームが社内に存在し、ノーコードのプロダクトで実際にマーケティング活動をし、企業に利用してもらってフィードバックをもらったり、市場からのニーズを調査したり、セールスの観点から toB にどのような事が求められているのかを調査をすすめています。

プロダクトは、このノーコード運用チームと密に連携をしながら、今後の事業のスケールにあたってノーコードでは人間の運用コストがかかりすぎてしまったり、適切なプロダクトのチューニングがむずかしくなるタイミングでリリースする事ができるようにネイティブのアプリケーションとしてのファーストリースをめざして開発をすすめている段階です。

プロジェクト初期のすすめ方

インセプションデッキづくり

このプロジェクトをはじめるにあたって、チームでPOと中心に経営メンバーやテックリードである私などをまじえて、

インセプションデッキのたたきを作成し:

プロジェクトの背景、解決したい課題
プロジェクトの座組みや意思決定の責任
プロダクトの経営的な立ちいち
ターゲットとしているユーザーのペルソナ
何をやらないのか
期待する数値目標

等について開発に関連する社内のメンバー全員で議論して、一つの文書にまとめました。

ユーザーストーリーマップの作成とMVPの選定

次に、プロジェクトの背景やペルソナ、解決したい課題等をふまえてユーザーストーリーマッピングを実施しました。

miro.com

このMiroというサービスではオンラインのユーザーストーリーマッピングが簡単にできるので、

Discordで通話しながらユーザーストーリーを時系列順に、おおまかなアクションのカテゴリに階層化ながら、「○○として○○ができる」等の形式でまとめ、
プロジェクトの関係者をあつめて、ファーストリリースで経営観点・ユーザー目線でどのような機能が提供されていればよく、
またどの機能は優先度が低いのか、ファーストリリースから削るのかについて整理しました。

プロジェクトのスコープトレードオフ等についての合意

また、ユーザーストーリーマップの作成と並行して、
このプロジェクトが時間スコープを切ってリリースするタイミングが重要となるか、
機能スコープで切り確実に開発が完了してからリリースするかについて全社で合意を取りました。

ここで、全社で合意をとる事は、先のノーコードチームとして実際にどこまで耐えられるのか、セールス観点でどのように対外的に説明するのか、
会社としてプロダクトリリースに向けてCSとうのコストやメンバー増員、採用計画、他のプロジェクトのオーナーとの開発リソースの配分、
会社の経営的なランウェイをふくめての売りあげ目標等の様々な観点で全員の期待をあわせておく必要があるため非常に重要です。

また、このタイミングで「機能スコープといっても、○○くらいまでには出るよね?」といった隠れた期待や
「見つもりはどのくらいの時期にほしいのか、その精度はどれくらい可能で、どのくらい必要なのか?」
といった事についても話しあいました。

そして:

十分な価値提供を重視したいため「時間スコープでいく事」 -「精緻なみつもりに時間をかける必要はなく、まずは進められるところから進めていってほしい事」

という形での合意になりました。

そのため、チームとしては、進捗の共有をスプリントレビューのタイミングで実施するのは当然として、
スプリント計画のタイミングでチームとしての開発の期間のめやすについて合意をして、
自分たちのベロシティを安定させる事をまずは重視しようという形ですすめました。

スクラムで進めていくなかで直面した課題

当初は、
このユーザーストーリーマッピングをベースに、開発のバックログを並べかえ、
開発のスプリントが近づくにつれて詳細化していくという形をとっていました。

また、「ここはもうすこし市場調査をしてみないとわからない」という部分については、どうしても開発が後まわしになってしまう事もあり、
「ここは確実なはず」という所をまずは優先して進めるという形でやらざるを得ない部分があり、そのように進めていました。

しかし、何度かスプリントを進めていたり、別チームに新しい情報がはいってきたタイミングで連携をとっていると段々と問題が発生しました。

ノーコードによる検証や市場開拓と並行して開発しているため:

セールスの中で顧客獲得のボトルネックになりそうな要求が当初想定していた形とはまったく違った形である事
開拓の価値がありそうな市場をどこに定めるかによって求められるニーズが大きく異ってしまうといった事
そもそも、「ここで、この情報を表示しなければならないなら、この機能の設計が大きく違ってくる」といった話

であったりです。

たとえば:

Pull To Refreshのような更新でも良いかなとおもっていた物がかなりリアルタイム性が高くないといけない事がわかった
サービスの提供価値として「ここは確実保証でなくても多くのユーザーにとっては価値提供できる」と考えていた物が「ほぼほぼ確実にならないと多くのユーザーにとっては価値にひもづかない」という事がわかった

りといった、品質要求の大きな変化や、サービスに求められている提供価値の重心がおおきく変動してしまったりといったケースです。

そのため、開発の中で度々アーキテクチャを見なおしたり、デザインレベルや価値提供を支える機能を考える段階しなおす必要がありそうだとなったりする話があり:

開発を一望して、現在わかっている要求とそれにたいする仕様、そしてわかっていない要求について精緻に分解をし、依存関係を明確にする
市場のなかで要求される箇所について、機能要求だけでなく品質要求についても精緻に分解をする

といった、プロジェクトを俯瞰的に見るタイミングを持たなければ、
機能スコープのみだと理解していても、安心してかつ安定して開発がづつけられず、
おわりの見えないプロジェクトになってしまう危険性を感じるという話がKPTの中で出てきました。

まずは、スコープの認識をあらためて確認

そこで、まずは頻繁な要求の変化に伴う設計の変更によって、
当初チーム内で想定していたよりも開発のおわりが見えない不安な状態になっている事を正直に全社に共有しました。

その上で、あらためて、このまま機能スコープとして期限を気にせず変更があったら必要な分の時間をとって終わるまで進めていく形で良いのか、
会社としてしての期待になんらかのの変化はないのかという話をあらためて話あいました。

そして、「機能スコープとしてでひきつづき問題はない」という事は以前とかわらずですが、

市場調査から共通のニーズが一定わかり、異なるニーズにたいしても会社として
どのタイムラインや優先度で対応していく事が良いかについての目星もある程度ついてきていたため

要求の変更が今後あった時に、日数としてどのくらいの規模の影響がありそうなのかという事を全社で把握しやすいように
要求仕様を俯瞰で見たうえで設計に取りくめるように

の2つの観点から現状認識している要求仕様について網羅的にまとめる機会をつくる事で合意しました。

要求仕様のまとめ方を勉強した

俯瞰して、かつ網羅的に要求と仕様をまとめるにあたって、どのような考え方やフォーマットでまとめると良いのかについて勉強するために
私は『[入門+実践]要求を仕様化する技術・表現する技術』を読みました。

この本を選択した理由は、TDDの和田さんがTwitterでおすすめしていたためです

（要望、要求含め）要件定義ということでしたら、このあたりの本をお勧めしていますhttps://t.co/TzahpZuaKC https://t.co/SoXlFcolVt
— Takuto Wada (@t_wada) 2020年9月7日

そして、この本で書かれている背景などをチームに説明したうえで、
この本で紹介されている手法をベースに以下のフォーマットで要求仕様書をマークダウンドキュメントまとめる事にしました

# 要求カテゴリ1

## 要求サブカテゴリ2

- 要求: ○○が△△の時□□でxxできるようにしたい
  - 理由: 要求が存在するビジネス的デザイン的背景
  - (説明: もし要求に関連する補足情報があったら)
  - 仕様
    - [ ] △△ページに、xxボタンを表示する
    - [ ] △△ページに、OOのxxx情報を表示する

といった形で、

まず要求を大きなカテゴリに分割し
必要に応じてサブカテゴリに分割し
ユーザーストーリーをさらに分解し要求に分け
要求の理由を再確認し
要求を実現するための仕様について議論しながら列挙する

という形式を採用する事にしました。

チーム全員で一日かけて要求仕様書を書きあげた

そして、このフォーマットをベースに、デザインの設計をみながら一つ一つのユーザーストーリーについて分解して要求仕様書に纏める時間をとりました。

クライアントアプリと社外向けの管理画面の要求仕様の整理にまる二日かかりましたが、

集中して一つ一つの機能について、あらためて要求とその背景を確認し、正常系、準正常系、異常系の観点から仕様を検討し、
時には要求や背景から仕様の追加や変更や削除の提案をしたりしながら、

チーム全員でそれぞれの機能を、「その要求仕様書だけ」をみれば曖昧な部分なく迷わずに設計・実装する事ができるかという観点で熟考しながら網羅的で体系的に纏めました。

やってみた感想

まず良かった点としては、

一つ一つの機能についてその要求が存在する背景や目的、
つまりその機能がなぜユーザーにとって価値があるのかについて一つ一つあらためて確認できるのは非常に良い機会となりました。
ユーザーにとどける価値を意識するだけでなく、設計ができる仕様におとすという観点から論理的に考えるため、「その要求をみたすのに、ではなぜその仕様なのか」という事を深く考え検討する事で、チーム全体で一つ一つの機能を「自分たちの物」にできたように感じられました。

そして、『「その要求仕様書だけ」をみれば曖昧な部分なく迷わずに設計・実装する事ができるか』という目線で見て、
「ここに書かれていない事は考慮されない・実現されない可能性がある」とおもって構成していく事で、
正常系だけでなく準正常系・異常系についてもUXの観点から仕様を深く考えていく機会になりました。
これは、ユーザーストーリーマッピングの「What-if」のアプローチと同じだと思います。

また、俯瞰で一気に全体の要求仕様書をつくる機会になったので、終盤に話した要求仕様によって「じゃあ、実は最初に話した仕様の中で、こういうケースを想定しないといけないですね」等があり、前にもどって仕様を追加したり等実際に開発プロジェクトの終盤で発生していたら混乱したであろう事についても事前にかなりの量検討できたかと思います。

逆に悪かった点はというと

正直今の段階だとあまり無いとおもいます、

しいていうならばかなりプロジェクトメンバーの心血を注ぐ事になるので、疲労するという面はあります。
私も2日連続でずっと司会をしながら仕様に分解して、フローチャートを書いて共通理解をつくるための図を書いたり、というのをずっとオンラインでやっていたので、頭と喉がかなり疲れました。

ふりかえり: アジャイルなのか?

一つ、わたしの中にわいた疑問としては「これはアジャイルとして正しいアプローチなのか?」という疑問です。
つまり、いわゆるBig Up Front Designになってしまっていないかという疑問です。
しかし、以下の観点から、今回このような事をしたのは選択は良い選択だったと考えています:

全体のアーキテクチャを根底から覆す可能性のある事について事前に判断ができた
今回の要件定義はこれでスコープを完全に固定化するためのものではなく、むしろ「正しく交渉する」ための準備となった
また、今後も開発サイクル自体は「今週はこの要求を実現しよう」というスプリントゴールベースを立て、全体としても広さから深さにコミットするという形式で進めていく

ため、大きくは外れていないかと思っています。

一番上の「全体のアーキテクチャを根底から覆す可能性のある事について事前に判断ができた」については、

モジュラーリゼーションが完璧なシステムを毎回のインクリメントで作成していれば、どんな変更がきても対応できるはずである

という反論があるかとはおもいますが、

リリースして一気にスケールする事が目的であり、かつtoB領域の既存の商習慣がある市場に切りこんでいくためのアーキテクチャ設計ができるのかという疑問もありますし:

www.infoq.com

完全にアーキテクチャをインクリメンタルに作る事は、「少なくとも現状の僕たちでは無理である」という判断を正直に認めて、

「ベンチャーという限られた人員、お金、期間の中でユーザーに対してもっとも価値を継続的、かつすばやく提供できるアプローチは何か」

について検討した上の判断であると考えています。

Let's write β

プログラミング中にできたことか、思ったこととか

ユーザーストーリーマッピングをベースにプロジェクト全体の要求仕様書をチームで構築した