仕様書を浸透させるために何が必要か？
品質の作り込みをしていきたい・仕様を把握するコストが高いので仕様書を書くことを会社全体で浸透させたいと思っていて、そのために書く・読むの負担軽減が重要だと考えて以下をやることにした。
- 仕様書の項目を減らす
- 仕様書フォーマットの統一
- 仕様書の命名規則を決める
- 統一されたフォーマットに沿ったテンプレートの作成
- 管理方法の明示化・単純化
- 仕様書作成・更新・廃止プロセスの明示化
- 仕様書の具体例の作成
- 仕様書を書くときに迷いそうなときに参照するガイドの作成または作成の依頼
実は一回シンプルなフォーマットを決めたのだが、自分の進め方が悪くそれが全く浸透しなかった。その反省を踏まえて上記を考えた。
仕様書の話は、このあたりの話に関係する。
ちなみに仕様書は、Notionで記載している。
実際のフォーマット
解決したい問題となぜやるのか
- 実際に起きている問題を記載する
- 目標となる指標がある場合は、指標も書くと尚良
言語定義
- 仕様書内で利用する言葉を定義し認識を揃える
- 社員なら知っているであろうと思う言葉も記載することを推奨
ユーザーストーリー
- ユーザーストーリーを記載し開発メンバーと何をつくるか認識を合わせ考慮漏れを発見する
- ユーザーストーリーはデータベースで管理する
- データベースのプロパティは任意で追加してもよいが、ステータスが開発が終わった時点で非表示または削除することを推奨
仕様詳細
- システムの制約やロジックを記載する
- 開発者が設計時に作成するもの・お客様やスタッフが知っているべき情報等は、ここには記載しない
システムの制約とロジック
- システムに関する制約や価格の計算方法などのロジックの詳細を記載する
- 文章が長くなる場合は、表にまとめて記載する
- 実例を記載することを推奨
関連
- 仕様書に関連するメンテナンスされないフロー情報やリンクを記載する
- 具体的には、仕様作成時のメモ・FAQ・図・議事録・QA成果物・JIRAやFigmaのリンクなど
決め方
前回の失敗の反省を活かして自分の中でテーマを持って取り掛かった。
複数のプロダクトマネージャーを巻き込む
仕様書を書くという労働に責任を持つのはプロダクトマネージャーなので諸々決めるときに一人で決めずにプロダクトマネージャーと一緒に決めた。例えば、最初に仕様書の項目はプロダクトマネージャーと一緒に仕様書を実際に書いてみてこの項目は必要だねとか話したりしていた。
自分はソフトウェアエンジニアなので、この仕様書は書きやすいとか読みやすいと思ってもプロダクトマネージャーがそう思わない可能性はあってプロダクトマネージャーの意見のほうが重要だと考えたからそうした。話すことでシンプルになったりした。
小さく始める
フォーマットに関する事だと言語定義はユビキタス言語大統一データベースみたいなのを用意したい気持ちになっていたのだけど、まずは始めることを意識してそれは問題にぶち当たったら考えることにした。他にもユーザーストーリーに具体例を用いるとかそれを使ってテストの自動化だとか色々考えたけど今回はやめた。
あとは仕様書に関することを決めるときにプロダクトマネージャーを呼んでいたけど、全員呼ぶと話がまとまりにくそうなのと全員空いてる時間を見つけるのが大変なので全員は呼ばずに詳しそうな人か興味がありそうな人を自分含め3人以上になるように呼んでいた。
継続的にチームで改善していく
対話だ！！変化への対応だ！！
やらなかったこと
仕様書の浸透で必要なことに「心理的負担の軽減」というのも考えていて、仕様書という名前をやめてminispecにするとか考えたのだけど、心理的負担の軽減はチームで取り組むことによって軽減していくのがよいと思って一旦仕様書という名前ですすめることにした。
あと開発チームやプロダクトマネージャーが決めればいいと思うのでレビューの仕方とかも決めなかった。
まとめ
仕様書のあれこれを決めた。しかしこれで終わりではなく始まりだ！！！！！！！！！！！
