いものやま。

雑多な知識の寄せ集め

ソフト開発における「設計」とは何なのか。（その8）

技術

前回は要件定義のやり方について書いた。

今回はそれに付け加える感じで、ユースケース記述の話。

ユースケース記述

ユースケース記述というのは、システムがどのように使われるのかという一連の流れを書いたもの。

一例を挙げると、たとえば「ユーザがログインする」という場合なら、

  1. ユーザがブラウザで特定のURLにアクセスする。
  2. システムはログイン画面を表示し、ユーザにメールアドレスとパスワードの入力を求める。
  3. ユーザはメールアドレスとパスワードを入力し、「ログイン」ボタンを押す。
  4. システムは入力されたメールアドレスとパスワードで認証を行い、認証ができたらユーザのマイページを表示する。

みたいな。

このユースケース記述というのはシステムを外部から見たときの振る舞いを規定するものなので、要件定義というよりかは基本設計で考えるものではあるんだけど、できれば要件定義の中で追加でやっておいた方がいいと思っている。 なんでかというと、このユースケース記述をお客さんに共有することで、実際に自分がそのシステムを使うときの様子をイメージしてもらうことができるから。 この段階で「思ってたのと違う」というのが分かれば、システムを作り出す前に方向性の修正ができる。

このユースケース記述はシステムの内部の動きについては細かく書かないので、お客さんも理解できるギリギリのところにある設計となっている。 なので、ユースケース記述を共通言語してシステムの振る舞いを積極的に議論しておくといい。

ちなみに、このユースケース記述をちゃんと作れるかどうかが設計の肝なところがある。 というのは、近頃ドメイン駆動設計（DDD）が声高に叫ばれてたりするけど、このユースケース記述の中に出てくる用語や概念、その適切な値、振る舞いといったものが、まさにドメイン知識だから。

ドメイン駆動設計をやろうとして、でも何がドメイン知識なのか分からないみたいな話を聞くことがあるけど、それはドメイン知識を抽出する方法を知らないからだと思っている。 ドメイン知識というのはユースケース記述から抽出するものなんよね。 そして、ユースケース記述から抽出するからこそ、お客さんとの共通言語としての機能を果たせるというのがある。 オブジェクト指向分析設計でこのあたりの知識は語られてるはずなんだけど、なんか抜け落ちてしまっているせいで、テクニックに走りすぎて実際のドメイン知識はスカスカの軽量DDD（というか形骸DDD）が生まれてしまってると思うんだよなぁ・・・オブジェクト指向分析設計がちゃんと復権してくれるといいんだけど。

ユースケース記述のポイント

さて、ユースケース記述を書く上で、いくつか気をつけたいことを書いておきたい。

まずは、個々のユースケース記述をやっていく前に、ユースケースの一覧を用意しておくこと。 一覧で見れるようにしておくことで、ユースケースに抜け漏れがないかを確認しやすくなる。

一つ注意したいのは、このユースケース一覧というのは、システム全体のユースケースじゃなくて、今回の開発対象のユースケースということ。 全部のユースケースを書いてたら、いくら時間があっても足りないので。

そして、ここのユースケース記述をするときに気をつけたいのは、「主語」。 ここでもやっぱり主語が重要。 日本語だとついつい省略しちゃいがちなんだけど、「誰が」何をやるのかをハッキリさせておかないと、あとで「あれ？」ってなることが出てきやすい。

たとえば「毎日9時に在庫情報に矛盾がないか確認する」みたいな記述があると、誰がこの確認をするのかがハッキリしない。 決まった時間という意味ではシステムがやりそうな感じがあるけど、9時という時間だと管理者がやる可能性もワンチャンありそうな。 ましてやこのあとに「在庫情報に矛盾があった場合、修正を行う」みたいな記述が続いてたら、管理者が確認してシステムに修正情報を打ち込むのか、システムが確認して修正できるところを自動で行うのか、みたいになってくる。 いずれにせよ、解釈に揺れが生じて、「思ってたのと違った」となる危険性が高い。

あと、主語を書くときに、ユーザ側については「ロール（役割）」も意識した方がいい。 同じシステムであっても、管理者ができることと一般ユーザができることというのは違ったりする。 なので、単に「ユーザは顧客情報を入力する」「ユーザは使用明細を見る」のように書くのではなく、「管理者は顧客情報を入力する」「一般ユーザは自分の使用明細を見る」のように、どのロールで振る舞った場合のユースケースなのかが分かるような主語になっているといい。

他には、システムがバッチで動くとかなら「いつ」動くのかとかもちゃんと書いておきたいかな。 まぁそんな感じで、システムの外側から見た振る舞いに関して、できるだけ曖昧なところが生じないように書いて合意をとっておけるといい。

一方で、ついやってしまいがちなのが、システム内部の処理を細かく書きすぎてしまうこと。 この条件ではこう計算してとか、ループをどう回してだとか。 ユースケース記述を書くのって、フローチャートを書いてるのに近い感じはあるからね。

ただ、そういった内部の動きはお客さんも言われても困るだけから、書いてもしょうがない。 なので、システム内部の細かい動きには触れず、ユーザとシステムのちょうど境界の部分について書けるといい。

要件定義書に書くといいこと

ということで、要件定義書に書いておくといいことは、以下のような感じ：

  • 開発の目的
    • 顧客が何を望んでいるか
      • 深掘りして、要件に繋げられるレベルにしておく
    • （リファクタリングなら、開発者が何を望んでいるのか）
  • 要件定義
    • 要求を満たすために、開発者は何を行うのか
      • 〜〜機能を新しく作る
      • 〜〜機能を修正する
      • （〜〜機能を廃止する）
      • （開発後にシステムが満たしているべき条件（非機能要件））
    • 検討したけど実施しないことは何か、どうして実施しないのか
  • ユースケース

このレベルでお客さんと合意が取れていると「思ってたのと違った」というのが起こりにくいし、開発者側もドメイン知識の抽出やシステムの作りをイメージしやすくなる。

今日はここまで！

ソフト開発における「設計」とは何なのか。（その7）

技術

前回は、要求と要件の違いは「主語」で、それぞれを考えるときには視点を切り替える必要があることを書いた。

今回はそれを踏まえて要件定義のやり方を書いてみたい。

要求の深掘り

開発はお客さんから「〜〜がしたい」とか「〜〜機能がほしい」とか言われてスタートすることが多いと思う。 ただ、このときそのまま「〜〜できるようにする」とか「〜〜機能を追加する」のように要件にしてしまうのは避けた方がいい。

これにはいくつか理由がある。

まず、本当にほしいものとズレている可能性があるということ。 「顧客が本当に必要だったもの」の風刺画にあるように、本当に必要なものをちゃんと分析して自分で規定することはとても難しい。 もちろん、それはお客さんではなくこちらで考えても難しいことなんだけど。 ただ、お客さんと会話して深掘りしたりモックを見せたりすることで、「思ってたのと違った」というのを早めに潰しておけるならそれに越したことはない。

そして、要求は深掘りしてより深い要求として理解した方が、その要求を満たせる手段の幅も広がるというのがある。 「ドリルの穴理論」の話にあるように、「ドリルがほしい」というレベルの要求の理解だと、それを満たす手段は「ドリルを売る」としかならない。 けど、「なんでドリルがほしいんだろう？」というのを深掘りして「壁に穴を空けたい」という要求が分かれば、「ドリルを売る」以外にも「ドリルを貸し出す」「人を派遣して穴を空ける」などの手段も考えられる。 さらに深掘りして「どうして壁に穴を空けたいんだろう？」というのを聞いてみたら「壁に絵画を飾りたいから」という要求が分かったりするかもしれない。 もうそうなると本当に必要だったのは壁の穴ですらない可能性も出てくる。

あと割とあるのが、単なる思いつきだったという話。 そういった思いつきをそのまま作って提供すると、作ったけど結局使われないままということがよくある。 それでもお金がもらえるならいいんじゃない？という意見もありそうだけど、実は落とし穴がある。 それは作った機能は使われてなくてもメンテし続けないといけないということ。 そうやって使われないゴミ機能が増えてしまうと、他の機能を追加するときの足枷になるし、やる価値のないバグ修正やテストで工数が膨れ上がることになる。

そんな感じで、要求の深掘りは重要。

そして、要求の深掘りをするときに重要なのが、顧客視点になるということ。 要求は主語が「顧客」なので、自分が開発者であることは一旦忘れて、顧客の立場になって、どうして〜〜したいのか、〜〜機能がほしいのかということを深掘っていく。

このとき、とくに意識したいのが「顧客が困っていること」。 困っていることを解消するのはすごく価値が高いというのがまずあるし、困ってることは明確なのでそれを解消するのは要求としてズレにくいというのもある。

逆に「あれば嬉しいこと」は難しくて、実際に作ってみても意外と使われないことも多い。 なくても別に困らない機能って、よほどの嬉しさがないと使わないんよね。

要件の検討

こうして顧客の要求を分析したら、それを満たすための要件を検討する。

ここからは顧客視点で考えていたのを一転させ、開発者視点で考えていくことになる。 顧客の要求を満たせるような手段を開発者として考えて、妥当な点を見つけていく。

この妥当な点というのは、「やりたいこと」と「できること」の均衡点。

「やりたいこと」は顧客が要求するもので、顧客視点では当然最大限満たされることが望ましい。 けど、開発ではそれを完全に満たすことは難しい。 技術的に実現可能かどうかがまずあるし、可能だとしてもコストがとてもかかってしまって現実的ではない場合もある。 なので開発者視点では「できること」に限りが出てくる。 そこで、「やりたいこと」ーー上（顧客）からの力学と、「できること」ーー下（開発者）からの力学とで綱引きが発生して、コストや納期なども踏まえてその綱引きが均衡する点が要件として定義されることになる。

そんな感じで「開発者が」やること、満たすべき条件を要件としてまとめる。 これはその開発でのスコープになる。

気をつけたいのは、これはソフトウェアの要件ではなく、開発の要件ということ。 すなわち、開発で作るソフトウェアの差分についての要件を書くことになる。 なので、「新規に〜〜機能を作る」「従来機能を〜〜に変更する」（場合によっては「〜〜機能を廃止する」）といったもののが要件となる。

ちなみに、ここでは主に機能要件を挙げてるけど、他にも性能やリソースなどの非機能要件もあるので、それらも必要に応じて定義することになる。

「やらないこと」の記録の重要性

あと、要件定義では「やること」だけではなく、「やらないこと」とその理由も実は書いておいた方がいい。

これは、「やること」は実際に開発が進むので明確に残るのに対し、「やらないこと」は開発が行われないので、文書に残しておかないとそもそも検討のテーブルに上がってたのかどうかすら分からなくなってしまうから。

あとになって「現状こうしてるけど、なんでこうしなかったんだろう？」みたいな疑問が浮かぶことはよくあるんだけど、やらなかった理由が文書として残っていれば、その疑問をすぐに解消できる。 そもそも検討のテーブルに上がってなかった（開発当時よりあとに出てきた手法とかだとよくある）のであれば、その方法を新しく検討してみる価値はあるだろうし、検討のテーブルに上がってはいたけど明確な理由があって採用されなかったというのであれば、それを知らずに再検討してやっぱり使えないとなる無駄を避けることができる。 あるいは、上記の力学の都合で採用されなかったり改善が先延ばしになっている場合もあるので、それであれば優先度に応じてその方法に切り替える開発を行うことも考えられる。

そんな感じで、どうしてやらなかったのかの理由はちゃんと書いておいた方がいい。

今日はここまで！

ソフト開発における「設計」とは何なのか。（その6）

技術

前回は以下のようなことを書いた：

  • 開発は「Why（要求）→What（要件）→How（設計）」の順にブレークダウンしていく必要がある
  • ブレークダウンでは複数の選択肢が考えられるので取捨選択が必要
  • 選択した方針が間違ってないかのコミュニケーションが必要で、そのために要件定義書や設計書を書くといい
  • コミュニケーションが不要なら文書はなくてもいい（ただし要件定義や設計自体は必要）

今回は、要件定義を考えていくために、要求と要件について深く考えてみる。

要求と要件の違い

要件定義について考える前に、そもそもの話として「要求」と「要件」の違いが何なのかをハッキリさせておいた方がいい。 「要求と要件の違いって何？」ってあらためて聞かれると、ちゃんと答えられない人は多いと思う。

かく言う自分も、昔はこの違いでかなり悩んだ。 というのも、会社で用意されていた要件定義書のテンプレートで、要求を書く章と要件を書く章が分かれてたから。 要求も要件も同じじゃね？ってなってると、それぞれに何を書いたらいいのか分からないとなる。

要求と要件の違い、それは何かというと、「主語」が違う。

要求の主語は基本的に「顧客」となる。 「顧客は〜〜したい」「顧客は〜〜がほしい」のように、「顧客が」望んでいることが要求であり、その要求を満たすために開発は行われる。

一方で、要件の主語は常に「開発者」となる。 要求を満たすために「開発者は〜〜する」のように、「開発者が」やること（および守るべき条件）が要件となる。

ここで少し補足しておくと、要求の主語は「顧客」以外の場合もある。 たとえば「リファクタリングしたい」とか「ログを出せるようにしたい」とかは顧客ではなく開発者の要求なので。 もちろん、そのさらに奥には「顧客は新規機能の開発速度を上げてほしい」「顧客はバグを踏みたくない」「顧客は問題が起きたときに早く修正が入ってほしい」などの顧客の要求があるわけだけど。

それに対して、要件の主語は常に「開発者」であることに気をつけたい。 要求が何であれ、それを満たすために手を動かすのは「開発者」以外にありえないから。

いずれにせよ、「主語」を意識することがすごく重要。 そしてそれは、要求を考えるときと要件を考えるときでは、視点を変える必要があるということにも繋がる。

その話はまた次にしたい。

今日はここまで！

ソフト開発における「設計」とは何なのか。（その5）

技術

前回は、開発とはソースコードの差分を作ることであり、設計書とはその差分をどう作るか説明する文書であることを書いた。

そのうえで、設計書が本当に必要なのかどうかを考えていきたい。

設計書は必要か？

そもそも「設計書は必要なのか？」という疑問がなぜ生まれてくるのかというと、設計書がなくてもコードは書けるから。 開発で生み出すのが「ソースコードそのもの」であろうが「ソースコードの差分」であろうが、これは変わらない。

で、ぶっちゃけた話、個人開発の場合は設計書を書く必要性はあまりない。 そして、チームでの開発だとしても、実装前に方向性の確認がとれてそれを記録に残せているのであれば、設計書はなくてもいい。

これはなぜかというと、結局のところ文書というのはコミュニケーションの手段にすぎないから。 個人開発の場合はコミュニケーションをとる相手もいないので不要だし、チーム開発だとしても設計書で行うべきコミュニケーションが別の手段でできているのなら不要となる。 設計書という形式にこだわる必要はない。

ただ、その場合も「設計」自体は必要なことに気をつける必要がある。 そして、チームで開発する場合も「別の手段でできているなら」という条件がちゃんと満たされることは滅多にないので、基本的にはちゃんと設計書を書いた方がいい。 じゃないと、結局のところ「設計」がちゃんとされないままにコードが書かれて、コードレビューをしようとなった段階で「なんじゃこりゃ」みたいに発覚、その時点ではもうどうしょうもなくなってるということが起きがちなので。

そもそも「設計」とは何なのか？

ただ、上のように書くと、「そもそも『設計』って何なんだ？」ってなりそう。

  • 「設計書」は不要な場合もあるけど、それでも「設計」自体は必要とは、どういうことなのか？
  • ちゃんとした「設計」がされてないとは、どういうことなのか？

これを理解するには、「Why-What-How」の構造を意識する必要がある。

開発とはソースコードの差分を生み出すことだけど、それを実施するのは何かしらの理由があるからだ。 たとえば新機能がほしいだとか、バグを直す必要があるからだとか、将来の拡張のためにコードを整理する必要があるからだとか。 まぁいろんな理由があるにしろ、理由もないのにソースコードをいじることはありえない。

なので、開発のスタートにはまず「Why」つまり「要求」がある。

その要求を受けて、じゃあ実際に何をやっていくのか（あるいはやらないのか）を決める必要がある。 そうして決まるのが「What」であり、「開発で実現すること」すなわち「要件」となる。

要件が決まったら、今度はそれを実現するための方法を考える必要がある。 そうして得られるのが「How」で、「要件を満たすための方法」すなわち「設計」となる。

  • Why：なぜ開発するのか（要求）
  • What：何を開発するのか（要件）
  • How：どう開発するのか（設計）

これをちゃんとWhy-What-Howの順にブレークダウンしていかないと、「何やってるの？」な開発になってしまう。 たとえば「東京から大阪に行きたいんだけど？」と言われてるのに「名古屋行きの切符を買うことにしましょう」と提案するのは変だし、ましてや「車を借りて横浜まで行きました」と報告されたらもう意味不明なわけだけど、実際の開発だとそういうことが起きがち。

そして重要なのが、1つのWhyを満たすようなWhatはたくさんあるし、1つのWhatを満たすようなHowもたくさんあるということ。 つまり、取捨選択の必要がある。 そして、たくさんあるWhatの中で実施するWhatを決める（と同時に実施しないWhatを決める）のが「要件定義」であり、たくさんあるHowの中で実行するHowを決める（と同時に実施しないHowを決める）のが「設計」となる。

そういった取捨選択をやらず、お客さんに言われたままのことをやったり、とりあえずでパッとコードを変更してしまうと、あとになって方針が全然間違ってることが分かって大きな手戻りが発生する可能性が出てくる。 というか、手戻りできるならまだよくて、大抵はスケジュールに追われて「現状が仕様」のゴリ押しになることが多い。 そうなると、あっという間にゴミだまりのソフトウェア、ソースコードの出来上がりとなる。。。

そういったことが起きないようにするためには、ちゃんと取捨選択ーーすなわち「要件定義」や「設計」ーーを行い、それが間違った方針になってないかをコミュニケーションしていく必要がある。 そのための文書が「要件定義書」や「設計書」となる。

今日はここまで！

ソフト開発における「設計」とは何なのか。（その4）

技術

前回は「ソースコードを説明する文書」は「設計書」ではなく「開発者向けドキュメント」にすぎないという話をした。

では、結局「設計書」とは何なのかというのが今回のお話。

ソフトウェア開発の特異性

ソフトウェア開発では、製造業での開発と全然違う点が1つある。

それは開発がワンショットで終わらないということ。

製造業では一度設計書まで作ったら、あとはそれを製造するだけとなる。 基本的に設計書は使い切りで、細かい修正を入れたり、別の開発で参考にすることはあっても、その設計書にさらに手を加えて新しい設計書にするというのは考えられない。 企画した開発ごとに新しい設計書を書いていくことになる。

これがソフトウェア開発だと違ってくる。

一度ソースコード（＝プログラムの設計書）を書いてプログラムをリリースしたあとも、次なる開発では基本的にはそのソースコードに手を入れて新しいプログラムをリリースしていく。 ソースコードは1回書いたら終わりというわけではなく、ずっと使い回しで更新されていく。 もちろん、どこかで従来のコードを捨てて1から新しく書き直すということもあるけどw

これは「製品」という枠で考えたときに、製造業では開発が1回で終わるのに対し、ソフトウェア開発では開発が複数に分割されているとも言える：

製造業の場合

製品 開発 設計 製造
製品A
製品A開発 製品A設計書 製品A
製品B
製品B開発 製品B設計書 製品B

ソフトウェア開発の場合

製品 開発 設計 製造
製品A
製品A ver.1開発 製品Aソース ver.1 ※新規 製品A ver.1
製品A ver.2開発 製品Aソース ver.2 ※更新 製品A ver.2
... ...（更新が続く） ...
製品B
製品B ver.1開発 製品Bソース ver.1 ※新規 製品B ver.1
製品B ver.2開発 製品Bソース ver.2 ※更新 製品B ver.2
... ...（更新が続く） ...

なので、ソフトウェア開発で作っているものは、実は「ソースコード」ではなく「ソースコードの差分」だったりする （ちなみにこれはver.1の開発のときも同じことが言える；「ソースコードの差分」＝「ソースコード」となっているだけ）。 ソースコードを作ってるんだと勘違いしやすいけど。

そこに気付けばソフトウェア開発における「設計書」が「何の」設計書なのか分かるかと思う。

そう、ソフトウェア開発における「設計書」というのは、開発で生み出す「ソースコードの差分」を設計、説明した文書となっている。

「ソースコードそのもの」ではなく「差分」を説明しているのが肝。 「そのもの」の説明だとソースコードの変化に追従していかないと腐るわけだけど、「差分」であればそれは変化していくものじゃなくて変化の内容それ自体なので、腐ることがない。

ちなみに、「要件定義書」というのも同様で、今回の開発（＝生み出すソースコードの差分）で何を実現するのかを規定している文書といえる。 「ソースコードそのもの」で何を実現するかとなっちゃうと、対象の開発とは関係ない要件や仕様までカバーする必要が出てきちゃうからね。

図解すると次のようになる：

ソフトウェア開発の様子

ここまでを一度まとめておくと以下のようになる：

こうしたときに、それでもなお「設計書」は不要なのかや、必要なのだとしたらどういったことを書けばいいのかについては、次回以降に書きたい。

今回はここまで！

ソフト開発における「設計」とは何なのか。（その3）

技術

前回は、人間には読みにくいソースコードの説明を与えるのが、いわゆる「設計書」ではないかという考えを紹介した。

ただ、この考え方はまた別の問題を生み出してしまう。

腐る設計書？

ソフトウェアは作って終わりというものではなく、作ったあともバグ修正や機能追加が入るのが普通だったりする。 そのとき、ソースコードを調査する必要が出てくるわけだけど、前述のとおり、ソースコードを読み解いていくのは大変。 そこで「そんなこともあろうかと」用意しておいた設計書を読むわけだけど、大抵はそこで絶望することになる。

なぜって、「設計書に書かれている内容と現状のソースコードが乖離している」ことがよくあるから。

ソースコードを書く前に設計書を書くわけだけど、設計書のとおりにはうまくいかず、ちょっと違ったソースコードになるというのはよくあることだし、一度書いたあともソースコードが変更されるということはよくある。 けど、そうやってソースコードに変更が入ったとき、そのフィードバックを設計書にまで反映させるということは大抵されない。 実際、反映させようと思ってもかなり大変だし。

結果として、時間が経てば経つほど、設計書に書かれてる内容は古くて使い物にならなくなっていく。 つまり、設計書が腐っていく。 こうなってしまっては「ソースコードを説明する」役割を果たすどころか、場合によっては「嘘」になった説明が害を与えることすらある。 それでは何のために頑張って設計書を書いてるんだとなる。

ソースコードから設計書を作る？

設計書が腐る原因は、ソースコードの変更に合わせて設計書にもフィードバックが必要だけど、それをやるのは大変で、設計書のメンテがされなくなるということ。

だったら発想の転換で、むしろソースコードに人間向けの説明を書いておき、そこから設計書を生成したらいいんじゃないかというのは自然かもしれない。 そうしておけば、ソースコードを直すときに人間向けの説明も一緒に直せるので、メンテが維持されると。 こういった仕組みは、古くはTeXの実装に使われたWEBとか、Javadoc、Doxygenなどのツールで実現されている。

たしかにこういう仕組みを用意すれば、「設計書」が腐る問題は起きにくくなるだろう。

けど、ちょっと待ってほしい。 それは「設計書」なのか？

設計書はどこに消えた？

こうやってソースコードから「設計書」を生成するのだとすると、ソースコードの前に「設計書」は存在しないことになる。 従来書いていたはずの「いわゆる『設計書』」は何だったのか、そしてどこに行ってしまったのか？

「それでいいんだよ、だってソースコードが本来『設計書』なんだから」という過激派はまぁいるかもしれないけど、それだと「思ってたものと違った」ときの手戻りがとても大きくなるデメリットは出てくる。 だって、もうコードを書いちゃってるわけだから。

ちなみに、大抵はそうなると工数に追われて「もう動くコードがあるから・・・」と実装しちゃったものが採用されることになる。 もっと詰めるべきだった仕様とか設計があったにも関わらず。 で、技術的負債になっていくと。

ここで、ちょっと別の観点でも考えてみたい。

ソフトウェア開発の成果物というとまずはプログラムなわけだけど、実際にはそれ以外にも必要なものがある。 それは「ドキュメント」。 プログラムだけあっても使い方が分からないので、何らかの形でドキュメントが必要になる。

そしてこのドキュメントはソースコードの変更に追従する必要がある。 なので、実際にはソースコードからはプログラムの他にドキュメントも生成されていることになる。 これは、言葉通りソースコードに埋め込まれた内容からドキュメントが作られることもあれば、ソースコードの内容を元に手で書かれたドキュメントの場合もある。

ここまで書けば、言いたいことは分かるかと思う。

そう、ソースコードから生成された「設計書」というのは、実のところ「設計書」ではなく、「ドキュメント」だったりする。 ドキュメントというとユーザ向けのドキュメントが浮かぶわけだけど、開発者向けのドキュメントも存在するわけで、ソースコードから生成されたソースコードの説明というのは、設計書ではなくて開発者向けのドキュメントの一つにすぎない。

「設計書」というのは本来「ソースコード」を生成するためもので「ソースコード」よりも前に存在する必要がある。 それが逆に「ソースコード」から生成されるものになってしまっては、それはもはや「設計書」ではない。 ただの「ドキュメント」だ。

つまり「ソースコードを説明するのが設計書だ」という考え方は、設計書でないもの（ドキュメント）を設計書と勘違いしているだけにすぎなかったりする。

では、設計書とは一体何なのだろうか・・・？

今日はここまで！

ソフト開発における「設計」とは何なのか。（その2）

技術

前回はソフトウェア開発を「製造業へのたとえ」で考えると設計書の立ち位置がよく分からなくなるという話をした。

今回はその続き。

設計書＝ソースコードの説明書？

「ソフトウェアの設計書」は「いわゆる『設計書』」ではなく「ソースコード」という話を書いた。

ただ、ソースコードを読み解くのはなかなか大変だったりする。 というのも、各ソースコードに書かれた内容は断片的で、しかも普通の文章のように順序づけられてないから。 さらにはファイル数自体も多かったり。

そうすると全体像の把握がとても難しく、どこに何が書かれているかを探すのも大変だし、そもそもどこから読み始めたらいいんだとなる。 たとえるなら、ページ番号が入ってないめっちゃ分厚い本の背表紙を破って各ページがバラバラの順序で入っている状態で、その本を読んで理解しないといけない感じ。

もちろん、継続的な開発でソースコードと暮らしているうちに全体像は見えてくるようになるんだけど、それにはかなりの時間と経験が必要になってくる。 それにチームで開発していると自分の知らぬところでコードの内容やファイルの配置が変わってたりすることもあるので、その変更を全部追い続けるというのも無理があったり。

そうなるとソースコードをもっと読みやすい形で表現しておいてほしいとなる。 つまり、機械のレベルではたしかにソースコードが設計書だけど、それだと人間には読みにくいので、人間に読みやすいレベルで表現された設計書が「いわゆる『設計書』」という考え方だ。 さっきソースコードを背表紙の破れた本にたとえたけど、その本に対して目次と各章の概要をまとめたもの、すなわち読み方の説明を提供しているのが「いわゆる『設計書』」と。

この場合、「いわゆる『設計』」は書こうとしている本（＝ソースコード）のアウトラインを作成する作業とも言える。 実際、製造業とかでもいきなり製品の設計図を描き始めるわけではなく、ラフスケッチで製品のデザインや仕様などを詰めていってるはずで、そういった作業に相当するのがソフトウェア開発における「設計」であると。

これは「製造業へのたとえ」での設計の考え方に比べると、だいぶそれっぽい。

ただ、この考え方だとまだ問題があったりする。 それは「設計書が腐る」問題。 これについてはまた次回話したい。

今日はここまで！