そもそもソフトウェア設計って何なの？

システム開発

だよなあと思うけど… - Kowの日記という記事から言及されたので、もうちょっと考えてみた。

それがダメなのかといえば、それでいいと思う。建築家が製図だけしてとび職やらないみたいに、そういうのはうまくやれればうまくいく方法なのだと思う。
設計をどういう粒度でやるかってことにバラつきがあるから、時に意味不明な設計書を渡されることがあるってだけで、それはやっぱり設計書の書き方が標準化されきってないことにまつわる課題かなという気がします。
だよなあと思うけど… - Kowの日記 (引用者が一部編集しています。)

システム開発は建築に例えやすい。けど、違う。その違いはどこにあるのかを考えることで、SI業界では何故建築家ととび職のように対応できないのか考えた。建築家ととび職の関係は、SEとPGとの関係にでも、元請と下請との関係にでも、スーツとギークとの関係にでも解釈できると思う。

で、検討するベースとして丁度良さそうな記事があったので、引用します*1。

建築デザインの3つの要素

右の図は,設計って難しそう、端から見ていても、良く解らない・・・と言う方の為の建築設計のプロセス図（説明図）です。
設計って簡単に言うと、 - 建築設計のプロセス

上記記事の右の図では、建築デザインのベースとなる要素を「シーズ」「ニーズ」「理想」に分けているらしい。シーズは制約、ニーズは要件とも読みかえられる。

  • シーズ：「ハッキリさせる」
    • 物理的制約
      • 環境的制約
        • 敷地の大きさ、形
        • 自然
      • 技術的制約
        • 材料的な制約？
        • 工法的な制約？
    • 法規的制約
      • 建築基準法とか、関連法規は多分いっぱい。
      • 建築申請とか構造計算とか、関連手続きは多分いっぱい。
  • ニーズ：「当てはめる」
    • 機能
    • スペース
    • コスト
  • 理想：「選ぶ」
    • コンセプト
    • 芸術的追求
    • 哲学的追求

ソフトウェアデザインとの対応

上記の3要素を、ソフトウェアデザインに対応付けてみる。

  • シーズ
    • 物理的制約
      • 環境的制約
        • メモリはどれだけとか
        • ディスク容量はどれだけとか
        • 計算能力はどれだけとか
        • ネットに接続できるかとか
        • 携帯端末しか使えないとか
      • 技術的制約
    • 法規的制約
  • ニーズ
    • 機能
      • いわゆる機能要件で、普通にある
    • スペース
      • ソフトウェアにはスペースという概念は機能に含むだろ
    • コスト
      • 他の類似案件との比較か、複数業者の入札で決まる
  • 理想
    • コンセプト
      • UIとか？
    • 芸術的追求
      • UIとか？
    • 哲学的追求
      • SIに哲学的観点を見出すのは変態

「シーズ：ハッキリさせる」ということは、つまり「制約は明確に定義しなければならない」ということになる。
物理的制約のうち、環境的制約はハードウェアやネットワークなどインフラの制約と解釈でき、技術的制約としてソフトウェア的な制約と解釈できる。ソフトウェア的な制約にはベースとして数学的要素があり、言語的要素、フレームワーク的要素が絡む。例えば「あるスペックのサーバをあるネットワークに接続した状態（環境的制約）で、LAMP（技術的制約）でサービスを動かした場合、1秒当たりどの程度のリクエストを処理できるか」が、ソフトウェアデザインにおける物理的制約になる。

ただ、これはあくまでもソフトウェア屋からの視点で、ネットワーク屋やハードウェア屋の視点では、ソフト屋の環境制約が技術制約にもなり得るはず。

で、無理やりまとめると

ウダウダになってきたので、すっ飛ばしてまとめる。

  • 機能要件の定義だけではなく、制約条件の定義も明確化すべき
    • つまり、ハードウェア、ネットワーク、ソフトウェア環境を事前に明確化すべき
    • 明確化できないならば、設計は未完成と判断すべき
    • その制約条件でその機能要件が実現できると判断できない場合、設計ミスと判断すべき
      • 実現できないと判断できる場合、ではないことに注意
    • 技術的制約の定義には、ソフトウェア設計と実装の技術が必要
      • つまり、その環境でプログラムを作成できることが必要
      • その技術で何ができるのか、それを実装するにはどれくらい手間がかかるのかを判断しなければならないので
  • 技術的制約の定義には実績の蓄積が必要
    • 枯れた技術バンザイ！
    • 新技術導入は技術的制約が改善するかも知れないし、悪化するかもしれない
      • つまり、危険
      • 新技術導入はリスクが少ない場面で。失敗しても取り戻せる程度に小規模で、期間的余裕がある案件でどうぞ
        • とはいえ、皆さん合間を見つけてチュートリアルとか試してるだろうけど、それも立派な試験導入だと思う

とりあえず

「設計者にはプログラムの素養が必要である」に一票を投じることになりそうです。しかも、「設計者には、その環境でのプログラムの素養が必要である」という、より強い条件付きです。

とはいえ、全ての設計者にその素養が必要ではなく、設計グループの一員としてプログラムの素養がある設計者がいるという状況でも、多分大丈夫。設計成果として、その制約を定義できるかどうかがポイントなので。

*1:引用のお知らせに、ブログの最新記事にトラックバックします。「設計」とは何かを考えるにあたり、かなり参考になりました。ありがとうございます！！