「設計駆動」は当たり前のことだけど、小企業やフリーランスでは疎かになっているケースもある
大中規模の会社でソフトウェア開発をすれば設計行為は当然されるのだが、小企業、フリーランスとなると設計が不十分だったり、そもそも設計書がなく、ひいては設計も甘いものがある。
その結果、「クソコード」 のままリリースされているものを時々見かける。
設計を事前にすることでコーディングにおける思考を事前に行う。それにより、重複の無い分かりやすいモジュールわけ、命名を行える。それをしなかったよりは、おそらく時間の短縮になっていることが多いと思う。少なくとも自分の経験ではそうだった。
プログラミング = ロジック作成 + コーディング ： ロジック作成を設計で
プログラムというのは、ロジックを考えることと、それをコードとして表すコーディングに分けてみることができる。そのロジックを考えることを事前にすることで、手戻りの時間をかなり削減することができる。
小さい企業やフリーランスでは、このあたりがおろそかになっており、品質の低下を招いているように見える。だからこそ、当たり前だけど、「設計駆動」でコーディングすることを意識的にした方がよいと思う。
いきなりコーディングの問題（「クソコード」の発生、無駄の多さ）
フリーランスのプログラマーで設計書を書かない人は何人かみたことある。設計書をかかないことは設計をしてないことに近い。頭に浮かんだものを形にすることで、頭のなかだけでは見えなかったものが認識される。
こうした設計行為をしない場合、行き当たりばったりでコーディングすることになり、無駄なコードが増えたり、意味が重複した命名になったり、重複を避けるために冗長な名前のクラスやメソッドが生まれてしまう。
このまま納品する人もいるかもしれないが、これが**「クソコード」**と呼ばれ、メンテナンスしにくくしてしまう。
一方、それを改善するためにリファクタリングすると、時間がかかり無駄が多いコーディングになってしまう。
設計は事前にデータモデル、処理概要を掴むのに必要
なぜ、前述の問題が起こるかといえば、コーディングを進めていくことで新しいデータモデルや処理に直面し、その都度後付的に命名したり処理を書いていくから。または、リファクタリングも同様で、逐次的・事後的にするので、無駄が多い。
実は、これはコーディングしないとわからないわけではない。事前に設計という行為をすることで、どういうデータモデルが必要か、処理が必要かというのが分かる。これにより、事前に重複を排除したデータや処理の階層も分けられる。
もちろん、事前に設計をしたから完全にリファクタリングが不要にはならない。コーディングしている途中で見落としていたことを見つけることもあるし、追加での仕様変更があるかもしれない。
ただ、全くしていない状態よりはその分無駄が減っていると思う。少なくとも自分の経験からは、設計なしでやるよりは、設計有りきでコーディングしたほうが、モジュールの構成、処理の流れは、統一的で階層がわかりやすくなる。もちろん、リファクタリングの時間は事前に設計で済ましている分だけ短い。
コーディング中のリファクタリングを減らす必要性（テストコードを考慮）
行き当たりばったりでコーディングして**「クソコード」**のまま進むのは論外として、リファクタリングするときメインとなるコードだけでなく、テストコードの書き直しも必要になったりする。
よくテストコードは修正が入ると無駄になるし、時間がかかるといわれるが、それはそのとおりだと思う。だからといって、テストコードなしで製造を進めていくことは品質に関わるだろう。テストコードは、CI前提のデプロイなら自動的に、人間が見落とすところも教えてくれる重要なコードである。それを落とせば、コードの修正時に問題を残したままリリースをしてしまいかねない。
テストコードの修正を皆無にすることはできないが、事前に設計してできるだけ無駄を省くことで、メインのコードだけでなく、テストコードを書き直す手間も減る。
翻って、設計には「テストコード」に該当するものは「レビュー」ぐらいしかない。けど、設計の修正・レビューとテストコードの修正ではどちらが時間がかかるか？「テストコード」だろう。なにせ、動かさないといけないのでそれだけ手間がかかる。
設計書を書くことで設計はより明確になる
設計をするとき頭のなかだけで簡潔するのではなく、どんな形式でもいいので形にする。そうするとで、頭の中だけでは気付かなかったことに気づくようになる。
もっといえば、その書いたものを他人にレビューしてもらう。そうすることで、自分の頭だけではわからなかったことに気づくことができる。
設計は、設計書にしてこそ、より精度の高い成果物をもたらすことができる。
設計書のフォーマットは見落としを減らし、無駄な行為を減らしてくれる
設計書を書くのがめんどくさいというのはある。けど、冒頭に述べたように、設計をしなかったことによる別の問題が発生する。どちらの方がめんどくさいかといえば、動き出してからの問題だろう。
設計書のめんどくささは、問題をはらんだものではなく、ただ個人のストレスの問題。そのストレスを減らすことは大切。
なので、ある程度考えることを減らし、漏れがないように「設計書のフォーマット」を作っておく。
設計書のフォーマットは、都度、設計でいろいろ悩まなくてもいいようにしてくれる指針でもある。設計書のフォーマットは、ノウハウの具現化したものともいえる。
外部設計（ユーザー視点）だけでもしっかりと
外部設計、すなわち、ユーザー視点の設計はしっかりする。どういった処理をユーザーがするのか、どういったデータをユーザーが扱うのか、どういった画面が必要なのか。
そうしたユーザー視点の設計は最低でも作成する。もちろん、それがあればユーザーさんとの意識合わせもできるし、あとでユーザーさんからおかしいといわれることも防止できる。
内部設計（プログラマ視点）のものについては、どういったフレームワークをつかい、統一的な処理の流れやクラス名、関数名の付け方などコーディングの指針を決めたり、モジュールの構成を決めておく。
どうしても内部設計は細かくしても変更を避けられない。なので、方針までを設計書に落とし、あとは、ラフにしておいてもよいと思う。
設計書があればテスト仕様書を並行で作ってもらえる
設計書にしたがってプログラムをつくり、そのテストは設計書を満たしているかを行う。つまり、テスト仕様書は設計書ができていれば、つくってもらえる。その分だけ、作業を並行して進めておける。作業期間の短縮になる。
設計、事後の設計書整理も含めて見積もりを
小企業、フリーランスはそもそもこうした設計をしない傾向があり、それが見積もりの安さにつながっているように思う。
こうした「設計駆動」でのコーディングをすることで、設計や事後の書類整理なども見積もりの視点に入ってくる。
設計書作成は、お客さんとの意志共有にも必要で、結果的に、無駄な手戻りやいざこざを防止する役割にもある。なので、見積もり時にしっかりと設計も意識しておく。そうすることで、見積もり工数自体にも余裕が生まれる。
Markdowで設計書を作成、gitでバージョン管理、Github/Gitlabでレビュー・共有する
設計書というとExcelを使ったものを想像する人が多いと思う。そして、それへの抵抗もあるかもしれない。
けど、かならずしもこれらのソフトを使わなくても設計はできる。
個人的には、ある特定のソフトを必要とするものよりは、汎用的な形式でいろんなソフトで閲覧ができるテキスト形式がよいと思う。
コストの掛け方は自由。無料の方がより多くの人に触ってもらいやすい。そして、テキストベースだとgitでのバージョン管理がしやすい。
また、gitでバージョン管理ができれば、githubやgitlabで設計書を共有してレビューしやすくなる。その履歴も分かる。
Markdownはテキストで形式をかけるし、gitを使っている人なら一般的な形式。ビューワーもVSCodeをはじめいろいろとある。やろうと思えば、自作のビューワーもつくれる。
これに、mermaid.jsなどを組み合わせれば、Markdown + 作図ができる。
いずれにしろ、コーディングの道具をそのまま使えば、設計のストレスも少しは少なくなるのではないだろうか？それに修正も、エディタのまま直せばいいのだから。
コードも設計も同じようなツールで作成、管理、共有すればそれだけストレスも少なくなるはず。