ある分野に長らく従事している人でも、かなり素朴な質問を投げかけられるとその答えに詰まってしまうということは少なくありません。たとえば当たり前のように使用している言葉や、作業している工程に関してもです。
皆さんは「設計とは何ですか？」と聞かれて、その答えを明確に伝えられるでしょうか？「設計とはシステムや機械を作るために作成する図面のことだ」と答えたのなら、それでは不十分です。設計が持つ本来の意義をしっかりと捉えきれていないと、設計としての役割を果たせず、多くの問題が生じてしまいます。
本稿では、そんな設計についてその意味と定義を改めて理解していきたいと思います。
設計とは何ですか？
ソフトウェア開発を進める上では、提供するサービスやシステムに関する「要件の把握」、全体がどのように機能するべきかを定義した「基本設計」、各処理を細かく規定する「詳細設計」が必要になります。開発手法自体は、ウォーターフォール型やアジャイル型など、昨今では様々な開発フレームワークが存在しているものの、共通して言えることは目的達成に向けてどのようにシステムを構築すれば良いかを定義していくことになります。
つまり、まずは顧客が必要としている事項や課題、それらを解決するための方法を理解し、実現のために求められる機能を定義していくことから始めます。その機能要件を定義する上では、顧客の要望を整理し、実現方法や解決方法を提示、システム化の難易度やスケジュール、コスト感なども加味して総合的に判断していくことが大切です。
つまり、設計は単にソフトウェア開発の下地にするのではなく、システムを実現するための手順を明確にするものでもあります。そのため設計の段階で開発中や開発後のことを想定し、論理だてて手順が明確になるよう設計しなければいけません。
また、これらの手順を踏んで作成された設計書には、ソフトウェアの品質を保証するエビデンスとしての役割を持つことになります。顧客は設計された内容を見て、ビジネス上の課題を解決するものかどうかを判断します。
このように設計とは、単に図面を書くことではなく「顧客の意図をくみ取り、必要な機能を導入でき、システムを実現するための手順を明確にし、かつ品質を保証すること」が設計の本質だと言えます。
“設計力”とは何か？
設計に続いて“設計力”についても解説します。皆さんが思う設計力とは何でしょうか？中には「技術の高さだ」と答える方もいるでしょう。しかし、設計の基本に立ち戻って考えてみると、設計力とは単に技術の高低ではないことがわかります。
たとえばとある業務アプリケーション開発が手掛けるソフトウェア開発会社が、ECサイト構築のための技術やAI(人工機能)開発技術を身に付けたとしても、それは「設計力が高まった」ということにはなりません。技術は設計力のごく一部の要素に過ぎないのです。
では設計力とは何か？それは大きく分けて3つあります。
1. 顧客のニーズを満たす力
顧客のニーズを満たすために中核となる技術を解決することは設計にとって最も基本的な力です。たとえば業務アプリケーションならば、既存業務をシステム化してプロセスを効率良くするために必要な機能を備えることが中核技術です。顧客がより高い効率化を求めるのならば、それを実現するための技術が無ければ設計もできません。
2. 設計に根拠を持たせる力
設計ではコストや機能などの目標値を設定しますが、それらの値は根拠のあるものかどうか？たとえばある業務アプリケーションを100万円で開発すると決めたと仮定します。果たしてその100万円というコスト目標値は正しいものなのかどうか。もしも同じ業務アプリケーションを99万円で開発するような会社があれば、その時点で負けとなります。そうしたことを見通してコストや機能の目標値に根拠を与えることはとても大切です。
3. 設計目標値を達成する力
これは設計段階で設定した目標を達成し、顧客側で何1つ不具合が発生しないように設計をやりきる力です。たとえばソフトウェアの不具合と聞くとバグが発生したり、データの受け渡しが上手くいかなかったりといった問題を連想しますが、これらはすべて設計目標値の未達が形になった表れたものです。つまり「何1つ不具合を出さない」ことをやりきることも、設計力の1つです。
こうした設計力はビジネスを生みます。ソフトウェア開発を安心して任せられない企業に顧客は依頼しません。どんなに高い技術力を持っていてもです。その一方で「これくらいのシステムならば、この会社に依頼すると一切不具合が発生しない」と考えられる企業は、技術力がたとえ低かったとしても多くの依頼が発生します。
[RELATED_POSTS]設計の平準化が大きな課題に…
皆さんの会社の設計は、現在どういった課題を持っているでしょうか？設計現場によくある課題は次のようなものです。
- 設計書の記述ルールやフォーマット形式が統一できていないため、設計者がごとに異なる設計書が出来上がる
- 設計書の修正対象が複数発生し、すべてに対応すると別の不具合が発生する
- ソフトウェアの仕様変更時のメンテナンスや変更管理等の作業が複雑になる
こうした課題を解決するのが「設計の平準化」なのですが、これを実現できている企業は非常に少ないでしょう。なぜなら社内ルールだけで設計書の記述やフォーマットを縛ることは事実上不可能であり、必ずどこかで設計者独自のものが組み込まれてしまいます。ほんの少しでもそうしたケースがあれば、設計の平準化はできません。
設計を正しく理解する
ソフトウェア開発では設計よりも実装段階が大切だと考えている方は多いでしょう。しかし、設計段階で正しい設計を行うことで、顧客ニーズを満たしたり、運用段階で発生し得る生具合を大幅に抑制することができます。本稿の内容を踏まえて「設計とは何か？」を改めて考えてみてください。設計について正しく理解すれば、今まで以上に質の高いソフトウェア開発が行えるはずです。
