はじめに
こんにちは。SANACHANです。
ソフトウェアの開発で、「ソフトウェア設計」とか「アーキテクチャ検討」を行います。
そもそも、何のために行っているのでしょうか。「設計」と「アーキテクチャ」は何が違うのでしょうか。
今回は、設計とアーキテクチャの目的や違い、そしてQCDとの関係について書いていきます。
こんな方におすすめ
- ソフトウェアにおける「設計」や「アーキテクチャ」の意味・目的が分からない。
- ソフトウェアにおける「設計」と「アーキテクチャ」の違いが分からない。
- 優れたアーキテクチャの効果を知りたい。
語句の説明
ソフトウェア開発における「設計」
Wikipediaによると、以下のように記載されています。
ソフトウェアのための問題解決と計画の工程である。ソフトウェアの目的と仕様が決定した後で、ソフトウェア開発者が設計をしたり、専門の設計者が開発計画を立てる。細かいコンポーネントやアルゴリズムの実装だけではなく、アーキテクチャ的観点での検討も行われる。
ソフトウェア開発における「アーキテクチャ」
Wikipediaによると、以下のように記載されています。
コンピュータ・プログラムから見た機械の標準化され文書化された仕様であり、個々の機種やモデルに特有な実装は含まれていない。コンピュータに関する構造や設計全般に「アーキテクチャ」の語が使われるようになった。
ソフトウェア開発における「QCD」
Wikipediaによると「生産技術」のことを指し、以下のように記載されています。
製造業はQCDの三つの柱で成り立っているとされる。 Qは品質 (Quality)、Cはコスト (Cost)、Dは納期 (Delivery) を表す。 そのため、製造業を営む企業ではQCDそれぞれの責任部門として、品質管理部門・生産技術部門・製造部門を置いているのが普通である。
設計とアーキテクチャの違い
ソフトウェア開発において、「設計」と「アーキテクチャ」は何が違うのでしょうか。
結論から言うと、「目的は何も違いなく、粒度に違いがある」です。
少し例を挙げて説明します。
例えば、建築における設計とアーキテクチャ
例えば、新しい家を設計する建築家（アーキテクト）で考えてみましょう。
家におけるアーキテクチャとは、家の形、外観、正面図、部屋の空間やレイアウトを意味します。
しかし、建築家が作成する図面には、膨大な量の詳細情報が書き記されています。例えば、寸法、扉の回転角度や排気口、さらには電気のスイッチやコンセントの位置まで分かるようになっています。トイレの排水溝や、壁の厚さ、基礎の構造までも図面には詳しく書き込まれています。
つまり、上位レベル（アーキテクチャ）の決定に従い、詳細が全てわかる下位レベル（図面）が存在しているのです。
ソフトウェアにおける設計とアーキテクチャ
ソフトウェアの設計も、基本的には家の設計と同じです。
上位レベルの構造（アーキテクチャ）と下位レベルの詳細（設計書）は、ソフトウェア全体の「設計」です。
この２つを合わせて開発するシステムにおけるソフトウェアの振る舞い・責務を定義します。
しかし、どこまでが「構造」で、どこからが「詳細」になるのか、それを明確に区別することは困難です。
そのため、「アーキテクチャ」は下位レベルの「詳細」から切り離されて考えられますが、実際の「アーキテクト」の思考を考えると、「アーキテクチャ」と「設計」の使い分けにはあまり意味が無いことに気づきます。
ソフトウェア設計・アーキテクチャの目的とは
では、ソフトウェアの開発に「設計」や「アーキテクチャ」が必要なのはなぜなんでしょうか？
何を目的として行われるのでしょうか？
目的とは？
求められるシステムを構築・保守するために必要な工数を最小限に抑えること。
例えば、ソフトウェア設計の品質は、顧客の要求を満たすために必要な「工数（＝コスト）」で計ることができます。必要な工数が少なく、何世代も含めた製品のロードマップ全体で少なく保たれているのであれば、その設計は「優れている」と言えるでしょう。
逆に、次世代機種を開発するごとに工数が増えていくなら、その設計は「優れていない」ということです。
ソフトウェア業界の実態
では、実際に「優れた設計」を行えているのでしょうか。
ここでは、以下の著書「Clean Architecture - 達人に学ぶソフトウェアの構造と設計 -」で紹介されている事例で解説します。
紹介されているのは、実在する企業のデータから、グラフ化・考察を行ったものです。
ソフトウェア部門の人員
まずは、コストに関わる「ソフト開発部門の人員増加」を見てみましょう。
上図のとおり、製品の新たな機種を開発するごとに人数が増えているのが分かります。
ネットワーク機能やスマートフォンとの連携機能など、年々ソフトウェアで実現する機能が増えている。その機能を実現するため、開発者を増やしているのだと同意してくれる人は多いと思います。
人員増加と同時期の生産性
あれだけの人員、つまり人件費（コスト）を投入したのだから、さぞかし生産性は良いのだと思います。
下図に示すように、ソースコードの行数（開発規模）で計測したグラフで生産性を測ります。
明らかに何かが上手くいっていないことが分かりますでしょうか。
問題点
開発者は増加しているが、ソフトウェアの開発規模は横ばいになっているのです。
つまり、「コード1行当たりのコストが急激に増加している」ということで、「著しく生産性が悪い」ということです。
生産性の悪い企業の末路
もう分かりますね。
この生産性の悪化を見ると、この事業の持続性が低いと言えます。いくら利益を上げたとしても、人件費で全て吹き飛んでしまします。倒産まではいかないにしろ、企業の成長を大きく失速させるでしょう。
何が生産性を悪化させているのか？
例えば、チームで何かを行う場合、そのチームの生産性や成果は何によって決まると思いますか？
個人のスキル？ 人間関係？ それとも、環境でしょうか？
チームの成果を決めるのは、チームリーダーのリーダーシップです。
どんなに優秀なメンバーを揃えても、その力を最大限引き出すリーダーシップが無ければチームの成果に繋がりません。
ポイント
ソフトウェア開発では、「リーダーシップ」に相当するのが「アーキテクチャ」です。
「すべての開発者が知っておくべき、ソフトウェアアーキテクチャに関する5つのこと」でも紹介されている通り、優れていないアーキテクチャは開発、機能拡張、保守、全てにおいて生産性を悪化させます。
ゲームのジェンガで想像してみましょう。
綺麗に整っている最初のうちは、1本のブロックを抜き取るのは容易です。しかし、ガタガタに崩れた状態になると、1本のブロックを抜き取り、上段に積み上げるのには時間がかかりますね。
つまり、ガタガタのアーキテクチャに従ってソフトウェアを開発すると、工数が肥大化し、不具合を作りこんで品質を悪化（Quolity）させ、機能拡張や保守にかかる工数をも雪だるま式に肥大化（Cost）するということです。結果、納期を遅らせる（Delivery）ことになります。
おわりに
ソフトウェア開発の生産性を上げるには、開発工数を最小化し、アウトプットを最大化するアーキテクチャを構築できる優れたアーキテクチャとは何かを知る必要があります。
優れたアーキテクチャについては、別の記事で紹介することにします。
以上、「【ソフトウェア】優れたアーキテクチャがQCDを決める！」でした。