はじめに
ビットキーのSoftware QCチームでは「プロダクト仕様書」を作成する取り組みを行なっています。
この活動は昨年末からトライアルとして始まりました。
現在では、Software QCチームの中にソフトウェアの仕様を明文化するチームが立ち上がり、活動が始まっています。
通常、仕様書はソフトウェアの開発プロセスに関与する関係者によって作成される文書です。
プロダクト仕様書の作成を担当するチームは企業によって異なると思いますが、ビットキーではテストプロセスの支援を行う立場であるQCが担当しています。
そこで本記事では、Software QCチームによる「プロダクト仕様書」の取り組みについてをご紹介します。
1. そもそも「仕様書」とは何か
「仕様書」とは「製品の特性や機能、満たしたいユーザーの要求」を記述した文書の集合体です。
一般的には「要求仕様書」「機能仕様書」「詳細仕様書」の3種類があり、それぞれ記述内容が異なります。
2. 仕様書を包括する仕組みが存在しなかった理由
「アジャイル開発」は「アジャイルソフトウェア開発宣言」により「包括的なドキュメント」よりも「動くソフトウェア」に価値をおきます。
ビットキーはこの価値基準に基づき、顧客へ「動くソフトウェア」を提供することに焦点を当てた開発プロセスを採用しています。
開発者は、関係者とコミュニケーションをとりながら、柔軟に仕様変更することを求められます。
この開発手法をとることは、顧客の体験に価値をおくビットキーの強みでもあります。
ソフトウェアの仕様にまつわるドキュメントは、開発工程の中で開発者によって作成されます。
しかし、ドキュメントを集約する場所や運用が定まっておらず、作成場所が各所に分散されている状態でした。
そのため、Software QAチームにて仕様を確認する際は以下を行う必要があり、情報収集のコストが高いという課題がありました。
- 開発チケットを確認する
- Notionでドキュメントを検索する
- Slackで仕様に関する情報を検索する
- 開発チケットにアサインされている開発者へ質問する
3.「プロダクト仕様書」を作成する必要性
ビットキーは2018年に創業され、創業から6年が経過しようとしています。
組織はスタートアップ当初から順当にスケールし、取り扱うプロダクトの一部は成熟していく過程にあります。
状況の変化に伴い、個人の突破力に重きをおく状態から、関係者との協力によって私たちの足跡を文書化し、組織のアセットとして残す必要性が高まっています。
包括的な仕様書を作成することで、仕様に対する認識を共通のものにできます。
しかし、開発者のリソースを割いてしまうという課題がありました。
そこで、Software QCチームが仕様書を作成する役割を担うことにより、開発の速度を落とすことなく、関係者と仕様の共有が可能になると私たちは考えました。
4. Software QCチームが作成する「プロダクト仕様書」
ビットキーが提供する製品には、bitlockをはじめとするスマートロックの他に、利用者のIDやデジタルキーの情報を管理する複数の「SaaSアプリケーション」が存在します。
「プロダクト仕様書」では、これらの「SaaSアプリケーション」に纏わる仕様を定義します。
一般的な仕様書の概念に当てはめると「プロダクト仕様書」は「機能仕様書」に該当します。
5.「プロダクト仕様書」の価値
QAから見たとき「プロダクト仕様書」は「テストベース」になります。
「テストベース」とは、テスト活動時に参照される情報全般のことであり、テスト担当者とは異なる第三者によって作成される成果物です。
各テストプロセスにおいて「テストベース」を活用することで、より正確な判断を下すことができます。
また、作成した「プロダクト仕様書」はテストプロセスへの活用に限らず、アセットとして開発やビジネスに寄与できます。
各活動の営みにおいて「プロダクト仕様書」を根拠とすることにより、仕様と成果物の間で双方向のトレーサビリティを持たせる効果があります。
6. 「プロダクト仕様書」の取り組み
私たちにとって「プロダクト仕様書」の取り組みは新たな挑戦であり、試行錯誤の中で進んでいます。
まずはファーストステップとして、プロダクトごとに存在する画面を洗い出しながら、各機能における仕様の明文化を進めています。
そのため、仕様の記述のほかにも関係各所と連携し、仕様に対するキャッチアップを行うことが、重要な取り組みのひとつに含まれています。
7. 作成中の「プロダクト仕様書」をご紹介
Software QCチームでは「プロダクト仕様書」を「Notion」というクラウド型のツールを使用して作成しています。
主に以下の構成で成り立ちます。
- 「プロダクト仕様書」トップページ
- プロダクトの仕様ページ
- 機能一覧
- 機能の詳細ページ
7-1「プロダクト仕様書」トップページ
プロダクト仕様書トップページでは、プロダクトを「Home Domain」と「Workspase Domain」に分類して管理しています。
ページをクリックすると、プロダクトの仕様ページに遷移します。
7-2 プロダクトの仕様ページ
プロダクトの仕様ページでは、参照者がページの用途を把握し、使いこなすために必要となる情報を集約しています。
具体的には「目次、ページの使い方、ページの目的、全体構造、各種リンク、機能一覧」をまとめています。
7-3 機能一覧
データベースを用いて、プロダクトの機能一覧を表現しています。
画面ごとにドキュメントを作成することで、参照したい機能を素早く探すことができます。
🌟 画面階層の表現について
機能一覧ではデータベースの「親アイテム」と「サブアイテム」機能を使用し、プロダクトの画面階層を表現しています。
これにより、参照者が機能の構造を簡単にイメージすることができます。
7-4 機能の詳細ページ
ドキュメントをクリックすると、機能の詳細ページに遷移します。
仕様と画面を合わせて記述することで、参照者がそれぞれの関係性を理解することができます。
▲ 補足：製品の「インターフェース仕様」はUI/UXチームさんが定義しています
これらの工夫をまとめると、以下になります。
8. 「プロダクト仕様書に関するお問い合わせ」ページとの連動
ビットキーが取り扱うプロダクトは複数あり、機能の種類も多岐にわたります。
仕様を明文化するにあたり、どの機能から着手するかの「判断基準」や「優先度づけ」が必要であると考えました。
そこで「プロダクト仕様書に関するお問い合わせ」ページを用意し、社内へ向けて公開しました。
ここでは、機能に対する明文化依頼を受付けており、JIRAのような操作感で依頼の起票や進捗の管理を行うことができます。
主にビジネスの現場で顧客とやりとりを行う、カスタマーサクセス部にご利用いただいており、部署を超えたコミュニケーションが実現しています。
「プロダクト仕様書に関するお問い合わせ」ページでいただいた依頼をひとつの判断基準にすることで、明文化において優先度の高い機能が明らかになります。
また、顧客のニーズを可視化し、関係者の間で情報を共有できるといった利点があります。
9. 社内から頂いたフィードバック
「プロダクト仕様書」をご活用くださっている社内メンバーのご感想をご紹介します。
10. 活動を通しての感想
活動を開始した当初は「プロダクト仕様書」の枠組みを考え、作成することから始まりました。
Notionの機能を活用して、ドキュメントを参照しやすい構造にできたのではないかと感じています。
複数のプロダクトに存在する機能をドキュメントとして包括するため「プロダクト仕様書」の取り組みは長期的な活動を見込んでいます。
活動を推進するにあたり、社内において以下の事柄が必要であると私は考えています。
- 「プロダクト仕様書」と「プロダクト仕様書に関するお問い合わせ」ページの存在を周知する
- 取り組みの意図や目的を明確にする
- 想定する効果を発揮するため、長期的な活動が見込まれることをご認識していただく
本記事をきっかけに「プロダクト仕様書」についてご興味を持っていただけたら幸いです。
終わりに
「プロダクト仕様書」の作成は、Software QCチームにとって新しい取り組みであり、関係各所のご協力のもと成り立っています。
まだ発展段階ですが、工夫を重ねながら価値の発揮に向けて着実に進めていきたいです。
以上、Software QCチームによる「プロダクト仕様書」の取り組みについてをご紹介させていただきました。
Discussion