見出し画像
Photo by noriyukikawanaka

プロダクト開発における「仕様」のつまづきを減らす取り組みについて考えてみる

vanilla.dev

はじめに

つい最近新たに、「ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた」という本を読み進めています。
この本における「『仕様』で失敗」という章がやはりプロダクトの仕様を考えたりする自分にとっては大変参考になったため、改めて、仕様のつまづきを減らす取り組みについて記事にしてみたいと思います。

以前、「［入門＋実践］要求を仕様化する技術・表現する技術」という本を読み、要求を正しく言語化する手法について記事にしています。

今回は、前回の内容も含め 2 冊を読んだ学びから自身の考えを総合的に記事にしてみた、という感じになると思います。
前回の記事もぜひ読んでいただけると嬉しいです。

1. 仕様に関する主なつまづきポイント

プロダクト開発における、仕様のつまづきは多岐にわたります。「ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた」で紹介されていたものも含めて、ざっと以下があるかなと思います。

  1. 曖昧な文章で仕様書が記載され、設計ミスが発生する

  2. 仕様書だけを委託先に渡し、期待と異なるものが納品された

  3. 品質について明確に定義せず、期待に満たない成果物が納品された

  4. ステークホルダーとの間に仕様の認識のズレがあり、手戻りを発生させてしまった

  5. 仕様が文書化されておらず、仕様を Slack やメールからたどる時間がかかってしまう

2. 仕様のつまづきを減らすための取り組み

2.1 ユースケース（利用シーン）を仕様書に記載する

2.2 仕様のレビューと検証

  • 多角的なレビュー： 開発者、デザイナー、ビジネス側など、異なる視点からの仕様レビューを行います。

  • プロトタイピングの活用： プロトタイプを作成し、仕様の妥当性を確認します。Figma でプロトタイプを作成するのが自分は好みです。

2.3 変更管理の徹底

  • 変更履歴の明確な管理： 仕様変更の履歴を詳細に記録し、変更の影響範囲を把握しやすくします。Git の管理下に置くと、確実に変更履歴を追うことができますが、仕様書でそこまでやるのも Too Match かと思います。ですので、仕様書の先頭にステータス（策定中 / Fix 済み）や Fix 日時を記載する方法をおすすめします。

2.4 ステークホルダーとのコミュニケーション強化

  • 定期的な進捗共有会議： 仕様の進化や変更について、定期的にステークホルダーと共有する機会を設けます。

  • ビジュアル表現の活用： 図表やモックアップを用いて、仕様をより分かりやすく表現します。

2.5 技術的制約の早期考慮

  • 技術検証の早期実施： 仕様策定の初期段階から技術的な実現可能性を検証します。

  • 開発者との密接な連携： 仕様作成者と開発者が緊密に連携し、技術的な観点からのフィードバックを随時取り入れます。

3. 実践のためのチェックリスト

仕様作成時に以下のチェックリストを活用することで、つまづきを減らすことができるでしょう：

  1. 全てのステークホルダーが合意した目的が明確に定義されているか

  2. 各機能の優先順位が明確になっているか

  3. 非機能要件（パフォーマンス、セキュリティなど）が考慮されているか

  4. エッジケースやエラー処理が適切に定義されているか

  5. 技術的な実現可能性が確認されているか

  6. ユーザーストーリーやユースケースが明確に記述されているか

  7. 仕様変更の影響範囲が分析されているか

  8. テスト可能性が考慮されているか

  9. 法的・倫理的な考慮事項が反映されているか

  10. 将来の拡張性や変更への対応が考慮されているか


いいなと思ったら応援しよう！