こんにちは。開発部のマネージャーをやっている mizushimac です。
今回は開発するモノの要件のまとめ方についてペロリ開発部が実践している内容を少しご紹介したいと思います。みなさんの会社やプロジェクトではどうやって開発するモノの要件をまとめていますか？パワポですか？ spreadsheet ですか？ 流れ行く slack や github issue で議論しながらコメントに埋もれていき誰かが箇条書きでまとめますか？ きっとカオスなことが多いかなと思いますのでこのエントリーが少しでもご参考になればと思います。
ちなみに、ペロリはカオスを楽しめる人を求めていますw
開発要件のまとめ方って色々あって難しい
私が学生の時に所属していたベンチャー企業では、数十MBもあるパワポに画面イメージや画面遷移図、コメントで色々と動作の補足が書いてあるものがあってそれをを見て開発をしていました。仕様の行間は企画の人に口頭確認、エラー処理とかは適当、いまも結構あるあるじゃないでしょうか。
次に新卒で入社した某 SIer の研修で出会ったのは、要件定義書という方眼紙のようになったエクセルのテンプレートにほぼフリーフォーマットで記述的に書いていくものです。 その頃、UML とオブジェクト指向に則ったユースケース・ドリブンな要件定義がプロジェクトにちょっとずつ適用され始めた時期で、これでエクセルで文字書かなくて良いのか！的な安易な発想でツール等を使ってユースケース図を書いてみたりしましたが、図だけでは表現もしきれず、大量の補足資料とユースケース記述が昔のエクセルの要件定義書とほぼ同じような内容だったり、結局どうやって要件をまとめればいいのかということの最適解みたいなものはモヤモヤしたまま過ごしていました。
開発効率は要件のまとめ方次第
「このように開発要件はまとめよ」という世の中の標準や明確な流行りがあるわけではないので、事業会社でサービスの開発要件をまとめるときは、企画する人が書きたいように、使いやすいフォーマットで、異なる粒度で、壮大なスコープでやりたいことを必死で表現しているという状況は共感いただけるのではないかと推測しています。
このような状況で開発を進めていると、
- プランニング時に要件とスコープの確認や把握に時間がかかる
- プランニング時に issue 分解や見積もりに時間がかかる
- 要件漏れや要件履き違えが発生しやすく手戻りが発生することが多い
などなど、いずれも貴重なエンジニアやデザイナーの工数を逼迫する要因になり、結果として組織全体の開発スピードが落ちていることが多いと思います。 sprint の振り返りをして計画との乖離が出るときの問題の多くは、要件の把握漏れや要件履き違えなどに起因していたりします。
このリスクを軽減していくためにもう少しいいやり方はないものかと、エンジニアとして、プロダクト・オーナーとして日々考えてみるわけです。
mini spec というものとの出会い
私がペロリに来る前、サンフランシスコの拠点と協業しているときに「mini spec: 〇〇」という google docs を送ってきたエンジニアがいました。彼がやりたい、やるべきだと主張する、とある SDK の新機能（実際には iOS アプリ間のシングル・サインオンの機能）の要件とざっくり設計が書かれていたものでした。内容は、機能の目的、UI のイメージとフローチャート、トークンの種類や処理のイメージ等が含まれ非常に読みやすいもので、他のエンジニアからのコメントがついていて設計の残検討事項があるものの、直ぐに開発に入れるぐらいの具体さがあり、分量も 3 枚程度のものでした。
言語、カルチャーの違いや時差等でコミュニケーションに障壁がある環境だったからこそ、開発するモノの内容を伝える手段として最適なフォーマットにもなっていました。これはきっと、前提となるスキルや知識が異なるエンジニア、デザイナー、ビシネスの人たちとの共通のコミュニケーションツールになるに違いないと感じた瞬間でした。
そのドキュメント見て以来、私は mini spec を書く人間になりました。ここ 3 年ぐらい私が書く mini spec のフォーマットは変わっていませんし、今も継続しています。事業のステークホルダーや発案した企画者、エンジニアやデザイナーと日々話していて、これは開発する必要性が出てきたな、という内容がほぼ決まったタイミングで備忘録的にざっと書きます。そこで得たさまざまな粒度やフォーマットが異なる情報を集めて、情報を整理、自分だったらこう設計するな、という妄想をしながら洗練させていくのです。楽しい時間です。
簡単なものであれば 15 分程度で書き上がります。
ちなみに、「mini spec」で google 検索すると、mac や車の mini なモノのスペックが出てきますので注意してください。完全なる社内用語です。
mini spec はこう書く！
昨年、ペロリに入社してすぐに、私は mini spec という Qiita Team のテンプレートを登録し、早速 mini spec を書きはじめました。すると、自然に「いいね」、「ストック」されるようになり、愛読するエンジニアも現れ、他の企画者や一部のエンジニアも同じように mini spec を書き始めました。
さて、mini spec は以下の項目から成ります。書く内容と私なりのポイントを説明したいと思います。
解決すべき課題（Issue to be Solved）
現在顕在化している課題とその解決のニーズを記載します。
ここで意識するのは、いわゆる論文の前書きのように、である調で理系っぽく客観的に記述するようにしています。そのほうがちょっとカッコいいのと、誰が読んでも、それは大きな課題だなあ、やるべきだよなあ、と少し高めのサービス目線から重要性を感じてもらえるからです。
ユーザーストーリー（User Stories）
ユーザー視点でどうあるべきかのストーリーを、ユーザーが機能に気がつくところから箇条書きで順序を追って記載します。
ここで大事なのは、アクターに漏れがないかです。エンドユーザーだけでなく、コンテンツを運用する人や、分析する人、外部のパートナー等あらゆるアクターのユースケースを書きます。そうしないと、管理ツールってどうするの？みたいなあるあるが後で起きて露頭に迷うので最初から決めます。管理ツールがないなら、エンジニアが redis にデータを投入する等書きます。
そして、ここはストーリーなので特にエンドユーザー向けのユースケースは、ワクワクするような、ユーザー感情も一緒に記載するようにしています。
プラットフォーム（Platform）
Web 上か、アプリか、両方か、どの管理ツールか等を記載します。
Web はどうします？とかアプリの過去バージョンはどう対処しますか？といった予想される部分も決めて記載していきます。特に、MERY のように、PC の Web、スマホの Web、スマホアプリと複数のプラットフォームがある場合には丁寧に書きます。最近、AMP をよく忘れます。。。
また、このセクションは、担当するエンジニアが読者であることを強く意識します。つまりは、開発のスコープとざっくり設計です。ほぼほぼ github のリポジトリーの単位に区切って記載しますが、あくまで、提案として、自分がサクッと作るなら、こんなテーブル用意して、この辺のUIを変更して、サーバーとアプリではこんな処理をする、でもパフォーマンスにちょっと懸念が出るかも、この辺セキュリティー気をつけないとね、もっといいやり方ないでしょうか？といったあたりを簡潔に記載します。
決して担当のエンジニアに、「こう作りなさい」という意図ではなく、「こんな感じで作れると思うけどどう？」というニュアンスでざっくりと書いて伝えます。そのほうが、もっとよい設計や実装になると思っているのとエンジニアリングとして一番楽しいところはとっておきます。
KPI（Purpose）
現状の KPI と目標の KPI、もしくは定性的な目的を記載します。
ここも担当のエンジニアに、「この KPI 必達だからな」ではなく、「こういう KPI を追うからそこを最大化できるように、計測可能なように」ということを伝える感じです。なのであまり詳細な KPI は書きませんし、邪念がないほうがいい UX に仕上がるな、と思ったら「定性的だから追わない」と敢えて書く場合もあります。
リリース希望日（Target Due）
希望なのか、デッドラインなのか、理由も含めて記載します。
誰だって、自分の事業に関係するいい企画は早く仕上げて欲しいので、対応時期の希望を結構無茶なスケジュールで言うと思います。期日の根拠をスクリーニングして、本当に社外的なコミットや外部環境に勝機がある場合は特別扱いし、それ以外は他案件との優先度次第で流動的になるので記載しません。
体制 / 規模感（Team）
ざっくり何人でどれくらいの期間かを記載します。
スクラムで言えばいわゆるストーリーポイントですが、スクラムをまたがるとポイントの基準が違いますし、ステークホルダーには伝わりにくい部分もあるので、何人で何日くらいか、という形で記載しています。ただ、明確にエンジニアが見積もった結果ではないので、あくまでざっくり見積もりです。この段階で 1 sprint 以上かかるような場合は、Phase 分けして mini spec 単位で分割します。
リスク（Risks）
認識しているリスクがあれば記載、かつリスクへの対処法を記載します。
リスクは書き出したらキリがないですが、一番大事なのは許容するリスクを書いておくことです。このリスクは承知で挑むのだ、ということを伝えて腹落ち感が出るようにしています。
ステークホルダ（Stakeholders）
この要件に対してレビューが必要な人を by name で記載します。
Qiita のメンションを飛ばしますが、だいたい無反応なことが多いので slack でこれ読んでおいてください、これで進めますよ。と伝えます。
参照（Reference）
参考資料があれば記載します。
過去の mini spec だったり、既存仕様、ベンチマークにしている他社サービスなど index として並べます。
上記項目を網羅的に書くことによって、要件の確認漏れを自分自身で気がつくこともできますし、より精度の高い開発要件をまとめることができます。そして、それをベースにエンジニアやデザイナー、ステークホルダーからインプットをもらい最適なものに仕上げていきます。
mini spec が完成しているかが開発フェーズに入れるかの基準
MERY には、企画が優先度順に並んだ product back log があるのですが、基本的には mini spec （もしくは同等レベルの情報）が完成していないと開発スクラムの sprint back log には載せないルールにしています。そうでないと企画職でないエンジニアやデザイナーが大きめの要件の確認に工数を使ってしまい、開発の計画や日々の開発作業に、待ちの非効率、ベロシティー計測不能、要件とずれた無駄な実装等が生まれることになります。
また、企画系の会議の場では、優先度が高いにもかかわらず内容がフワフワしていて mini spec が完成していないものは企画の進捗が悪いことを伝える明確な理由になります。ゴールを明確にすることで企画と事前デザインのスピードを上げ、組織全体の開発スピードをあげるのに mini spec は役立つわけです。
仕上がった mini spec は、優先度が高いもの順に開発のプランニングに持ち込み、github の各リポジトリーの issue にスムーズに分解され見積もりされます。
MERY の mini spec は誰が書くか！？キミでしょ！
ペロリでは基本的に開発スクラムのプロダクト・オーナーはエンジニアが務めるようにしていますが、mini spec は、プロダクト・オーナー以外のエンジニアでもどんどん書いていいものだと思います。やはり実装の中身が見えているエンジニアのほうがより精度が高くて無駄のない mini spec が書けると思います。
私は、本社の新卒採用をしているのですが、エンジニア志望だがゆくゆくは企画に関わりたい、企画も技術も両方のスキルを高めたい、という will のある人によく出会います。どうしたらいいですか？ という問いに対しては、積まれている issue は誰よりも爆速で終わらせて、空いた時間に自分がやりたい、やるべきだと思う mini spec を書いて社内やプロジェクトに幅広く発信しなさい、とアドバイスします。黙っていても、企画ド素人のエンジニアに企画の仕事がアサインされることはありません。 mini spec の内容が光るものであれば、コメントも賛同者も増えて勝手に優先度が上がり、部分的にでもその内容が sprint back log に積まれてくるはずなので、そうなったらこれはオレが言い出ししたんだぞ、ってドヤればいいのです。
というわけで、女の子にかわいいをさらに届け、事業インパクトのある mini spec をちょっと書いてみたいエンジニア、募集してます。
あ、次の機能の mini spec を書かなくては。。。