ソフト開発における「設計」とは何なのか。（その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）

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

今回はその続き。

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

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

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

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

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

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

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

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

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

今日はここまで！

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

ソフトウェアを開発してると、「設計って何をやればいいの？」とか「どうやるべきなの？」という話が出てくると思う。 場合によっては「設計っていらなくね？」とかも。

自分もこれまでにいろいろ考えてきたので、設計や開発プロセスに関して「こうやるとよさそうだ」という現時点での考えを書いてみたい。

製造業へのたとえ

ソフトウェアの開発プロセスはよく製造業の開発プロセスにたとえられる。

すなわち、製造業だとまず企画を立てて、そのあと設計書を作り、それに基づいて実際の製品を製造するわけだけど、ソフト開発も同様に、まず要件定義をおこない、設計書を書いて、それに基づいてソースコードを書くと。

対応付けしてみると以下：

工程	製造業の成果物	ソフト開発の成果物
企画・要件定義	企画書	要件定義書
設計	設計書	設計書
製造	製品	ソースコード

これはそれっぽい説明で分かりやすいので、ソフト開発をしたことがない人には受け入れられやすい。 その結果として、製造＝プログラムを書くのは設計書に基づいて手を動かすだけだから簡単だと勘違いされやすい。

でも実際にソフト開発をしたことがある人なら、プログラムを書くのがそんなに簡単でないことはすぐに分かる。 というか、プログラムを書くことこそが知的な生産活動の中心で、設計であるともいえる。

実際、ソースコードとは「ソフトウェアの設計書」なわけだし、ユーザに使ってもらうのもソースコードそのものではなくそれをビルドして作られるソフトウェアなわけだから、上記の対応はおかしい。

正しく対応づけるなら、以下のようになる：

工程	製造業の成果物	ソフト開発の成果物
企画・要件定義	企画書	要件定義書
？？？		設計書
設計	設計書	ソースコード
製造	製品	ソフトウェア

ソフト開発における製造はもはや人間の仕事ではなくて、コンパイラなどコンピュータの仕事。 人が実際に手を動かさないといけない製造業と違い、機械が勝手に工程を実施してくれるので、工程として見えにくいんよね。

ただ、そうなると「じゃあソフト開発における『設計書』ってなんなんだ？」というのが問題になる。 ソースコードこそが設計書なのだとしたら、それとは別に作る「設計書」というのは一体何を設計してるというのか。 それこそ、ソースコードさえあれば設計書は不要なのでは？と考える人も出てきそう。

このあたりの混乱を解き明かしていきたい。

今日はここまで！

着る毛布を買ってみた。

Amazonで着る毛布を買って、これがけっこうよかったので紹介。

動機

元々けっこう重さのある着る毛布を使っていたんだけど、いくつか不満があった：

• 重たいので取り回しにくい
• 前にボタンや紐がないので留めておけない
• 丈が足の先まであるので着たまま部屋の移動がしづらい

とくに最後の項目が大きくて、暖房をつけられない廊下とかでこそ着る毛布を使いたいのに使えないというのがあった。 ただでさえ寒い廊下へ着る毛布なしで出なければならないというのはかなりの地獄。

失敗した着る毛布

そんなわけで、軽くて前を留められて丈もちょうどいい感じのよさげな着る毛布をAmazonで探し、最初に買ってみたのがこの着る毛布：

AQUA (アクア) 着る毛布 かいまき 男女兼用 冬 あったか 3Way 襟付き ハイネック タイプ 足元まであったか ロング丈 ブラウン mofua (モフア) プレミアムマイクロファイバー ルームウェア モフモフ ふわふわ レディース メンズ 家事がしやすい 袖口ゴム仕様 静電気対策強化 (旧社名:ナイスデイ) 45488406

ただ、この着る毛布は失敗だった。

ものとしてはもちろんいいんだけど、男女兼用ということもあり、体格が大きめな自分にはキツかった。 これは胴回りではなく腕や背周りのキツさだったので、それなりに体格のある男性だとけっこう引っかかりそう。

そんなわけで、この着る毛布は返品。 デザインもよさげだと思ってたので残念。

そのあと、ニトリの着る毛布も店舗に行って確認してみた。

ただ、これらも腕や背周りがキツくてダメ。 写真だと男性も着ていて腕周りに余裕ありそうに見えるんだけどね。

成功した着る毛布

ダメだったのはいずれも男女兼用で、とくにボタンが右前になってたりと、どちらかというと女性をメインターゲットにしている感じがあった。 そこで、男女兼用ではなく、男性用の着る毛布で検索してみて、引っかかったのがこれ：

[Yoimira] 着る毛布 メンズ ルームウェア 大きいサイズ 着る 毛布 部屋着 冬 静電気防止 洗える

色がちょっと好みではないなぁというのはあったけど、これがちゃんと要件を満たしてくれるものになってた：

• 軽いので取り回しが楽
• 前をボタンで留められる（ちゃんと左前で男性向けデザイン）
• 丈が膝下までなので着たまま部屋を移動できる

薄いので十分な暖かさがあるのか不安だったけど、大丈夫だった。 結局、体の熱がどんどん空気中に逃げてしまうのが寒く感じる原因なので、その熱が毛布に貯められるようになるだけで十分に暖かい。 実際、これまでは室温が20度を切ると寒く感じてきて暖房をつけようかなとなってたけど、これを着るようになってからは16度くらいでも暖房なしでいいかなとなってる。

朝寒いとお布団から出たくないとなるけど、着る毛布を使うと、お布団に入ったままいろいろ活動できるようになるイメージ。 めっちゃいいでしょ？w

ただ、いくつか難点はあって、最初に着たときはちょこちょこと毛が抜けたりした。 まぁ安いのでそれ相応って感じ。 あと、レビューだとポケットの縫合が甘くて使えないというのもあったので、ハズレを引くとそういうのもあるのかも（自分は大丈夫だった）。

ちなみにトイレに行くときは裾をポケットに突っ込んでおくと一々脱がずに済むのでよかったw 毎回脱いでると大変だからねw

今日はここまで！

[Yoimira] 着る毛布 メンズ ルームウェア 大きいサイズ 着る 毛布 部屋着 冬 静電気防止 洗える