“仕様が決まってから設計して”って、それ無理ゲーでは？ ━ ソフトウェア工学チャンネル

ソフトウェアプロダクトの開発において仕様を決める工程（要求定義、要件定義）は簡単ではありません。そんな仕様を決めるフェーズにおいてよく議論になるような話題を扱いました（参考：“仕様が決まってから設計して”って、それ無理ゲーでは？）。

ソフトウェア開発の「あるある」な悩み [01:04]
ウォーターフォールモデルへの「思い込み」を見直す [05:30]
ウォーターフォールモデルのメリットも理解する [07:55]
変化への対応と手戻りの許容 [11:07]
解決策：仕様と設計の同時並行議論とアーキテクチャードライバーの把握 [13:58]
まとめ：柔軟な開発プロセスを目指して [18:06]
おまけ）おすすめ記事のご紹介

ソフトウェア開発の「あるある」な悩み [01:04]

「仕様が決まってから設計して」という指示は、多くのエンジニアが経験する「あるある」な状況かもしれません。仕様に関する議論が続いているにもかかわらず、設計担当者はその議論を聞きながら、後工程のことを考える必要があります。しかし、関係者間で情報共有がうまくいっていないと、「今は仕様の議論をしているから、設計は後でね」といった話になりがちです [02:02]。

このような状況では、以下のような疑問や不安が生じます。

仕様が固まらないと設計できないのか？ [02:19]
設計工程を考慮しない仕様で大丈夫なのか？ [02:27]
技術的な制約が議論された上で仕様が決定されているのか？ [03:11]
一度決まった仕様は変更できないのか？ [04:08]

特に、プロジェクトの規模が大きくなればなるほど、これらの不安は増大します [03:26]。

ウォーターフォールモデルへの「思い込み」を見直す [05:30]

「仕様が決まってから設計する」という考え方の背景には、ウォーターフォールモデルに対する「思い込み」があるかもしれません [05:35]。ウォーターフォールモデルは、開発プロセスを段階的に進める分かりやすいモデルですが、提案当初から「手戻りが発生するため、このモデル通りに進むのは難しい」と指摘されていました [06:17]。

しかし、その分かりやすさから多くの書籍や文献で引用され、あたかも「要求定義が完了してから設計に進む」という一方通行のプロセスが正しいかのように誤解されている可能性があります [07:21]。

ウォーターフォールモデルのメリットも理解する [07:55]

一方で、ウォーターフォールモデルにはメリットもあります。特に大規模プロジェクトにおいては、プロジェクトの進捗が分かりやすいという利点があります [08:11]。アジャイル開発のように成果物が早く出ることで進捗が分かりやすい側面もありますが、ウォーターフォールモデルでは「今どの工程にいるのか」が明確になり、特にソフトウェア開発に詳しくない関係者にとっても理解しやすいという特徴があります [09:12]。

近年では、アジャイルとウォーターフォールを組み合わせたハイブリッドなプロジェクト進行も多く報告されており、ウォーターフォールモデルの良い点も再評価されています [10:07]。

変化への対応と手戻りの許容 [11:07]

実際の開発現場では、要求定義や要件定義の段階で全ての決定を完璧に行い、後戻りなく進むことは非常に困難です [11:17]。技術的な制約や検討漏れなど、設計を進める中でどうしても手戻りが発生することは避けられません [11:51]。

また、「仕様が決まってから設計する」というプロセスでは、市場の変化や競合の動向など、予期せぬ事態への対応が遅れるという問題点もあります [12:38]。プロジェクトが長期化するほど、開発中に業界全体で大きな変化が起きる可能性も高まります [13:11]。

解決策：仕様と設計の同時並行議論とアーキテクチャードライバーの把握 [13:58]

では、どのようにこの課題を解決していけば良いのでしょうか？

仕様・要求・要件の議論と設計の議論を並行して実施する [14:06] 要求や要件を決定するプロセスは、本質的に非常に難しいものです [14:34]。ソフトウェア開発だけでなく、ドメイン知識、マーケティング、経営、デザイン、認知科学など、多岐にわたる知識が求められます [15:09]。これら全ての知識を持つ人はいないため、関係者間で丁寧に議論を重ねることが不可欠です [16:03]。
アーキテクチャードライバーを把握する [16:39] アーキテクチャードライバーとは、システム全体のアーキテクチャに大きな影響を与える要求のことです [16:58]。新しい仕様を検討する際に、「これを実現するには、システムのアーキテクチャを大きく変更する必要がある」といったケースがこれに当たります [17:15]。

このようなアーキテクチャードライバーに気づくためには、システムを理解しているソフトウェアエンジニアが、仕様や要求の議論に初期段階から参加することが重要です [17:42]。仕様が固まってから設計に着手するのでは、手戻りが大きくなってしまうため、早い段階で影響の大きい要求を特定し、議論に含めることが求められます [18:43]。

まとめ：柔軟な開発プロセスを目指して [18:06]

「仕様が決まってから設計する」という考え方ではなく、仕様・要求・要件と設計は、必要に応じて一緒に議論を進めることが重要です [18:21]。特に、アーキテクチャに影響を与える要求（アーキテクチャードライバー）は、ソフトウェア開発の専門家が初期段階から関与することで、後からの大きな手戻りを防ぐことができます [18:31]。

要求定義や要件定義の工程は、本質的に難しく、多様なバックグラウンドを持つ人々が議論を重ねる場です [19:08]。お互いの知識ベースの違いを理解し、目線を合わせながら丁寧に議論を進めることが成功の鍵となります。UMLなどのモデルやフレームワークを活用することも、議論を円滑に進める上で有効です [19:41]。

柔軟な視点と協力的な姿勢で、より良いソフトウェア開発プロセスを築いていきましょう。

www.youtube.com