なんのはなし？
プログラマー、ソフトウェア開発とか続けているとわかってきますが、やっぱり急にコードを書き始めるとあまり良くないことが起きます。
「コード書く前にやることあるでしょ？」と。
それが「分析」とか「設計」とか言われるものだったりして「設計書は書いたの？」とか言われるものです。
じゃあ「分析とか設計とかって何！？」 「設計書って何？？」となってくるので、ここら辺で一回まとめてみたいと思います。
その前に...
エンジニアの仕事とはいったい何でしょうか。
やることは１つ。 シンプルに言えば『課題の解決』、ただそれだけです。
とはいっても世の中に存在する「課題」というのはとても複雑なものでそれを「解決」するための方法も多種多様です。
一筋縄ではいきません。
さて、そんな複雑な状況でいったい何をどうすればいいのか？
それを華麗に解決するための方法が「分析」と「設計」です。
オブジェクト指向では OOAD といって、Object Oriented Analysis and Design という言い方をするものです
では、１つ１つ見ていきます。
その１． 課題を「分析」する ＝ What を定義する
一言で「課題」と言っても実はその課題が何か？というのは誰もわかっていないことが多いです。
例えば、
- ユーザの○○申請を自動化したい。
という話があったとして、
- 自動化したい申請というのは一体何でしょうか。
- その申請にはどういう情報は含まれていて、申請する前には何をしていて、申請すると何が起きるのでしょうか。
- そもそもなぜ自動化したいのでしょうか。
そんなことを考えながらまずは「課題ってなんだ！？＝What's 課題？」を明らかにする必要があります。
それが「分析」です。
ポイントは、課題は何なのかを定義するだけであってこの段階では解決策については考えていないということです。課題を明らかにする、紐解くだけであって、そこに解析者の意思が入り込んではいけません。
例えば、
- ユーザーと言ってるけどユーザーにも何種類かある。承認者と申請者と…
- 申請書に書かれている内容は？ 名前や日付や部署名… 他には？
- ユーザーと申請書は 1:N の関係になっている
- 申請がおわった申請書は破棄され履歴は不要になるの？
- 申請書は 申請 → 承認待ち → XXX という状態遷移を持っている。却下や取り下げもできる
こういったことを「分析」していきます。
つまり自分たちが解決しなければいけない課題はいったい何なのかを定義していきます。
補足的に言うとこの「分析」というものは専門的には「関心の分離」と表現することがあって自分たちが対処しなければいけない関心事を明確にする作業です。そしてそのときに考え方の指針となる１つが「オブジェクト指向」です。 関心事を、オブジェクトという単位を元にして、分解や分類をすることで、明確にしていく作業になります。
オブジェクト指向の詳しい話は本題ではないので省略
その２． 課題の既決策を「設計」する ＝ How を考える
さて、課題が具体的に何かがわかったところでその課題をどうやって解決するか？を考えます。
それが「設計」です。
自動化対象は○○で、情報としては△△があって、それは夜間に処理される必要があって。。。
という風に分析されたもの対して、色々な解決策を考えてきます。
- こういう情報があるなら、、それは、RDBよりもNoSQLの方が向いている（DB設計）
- 夜間に処理する必要があるならスケジューラを使ったほうがよさそう（システム構成の設計）
- スケジューラを動かすなら24hの体制を作る必要がある（保守設計、運用設計）
- 技術者を集めやすいのでNode.js/ExpressでWebを使った3層モデルでいこう（アーキテクチャ設計）
- CSSはBEMのルールで…（実装設計）
- コーディングの環境はVSCodeでCircleCIでCIをやろう…（実装環境の設計）
他にも様々な設計を行っていき解決策を考えます。
このように様々な視点で「解決策を考える」のが「設計」です。
その３． 設計書を書く
最後に。
せっかく設計を考えたのだから「設計書」を書くのも悪くはありません。
ただこれは設計したものを書き留めておいたり人が読める形にするのが目的であって設計書を書くこと自体は決して目的ではありません。
と言っても「設計書が要らない」と言うわけではないです。
大きく３つの目的が考えられます。
－ 壱． 設計した本人が忘れないようにするため －
設計はとても多岐にわたるのでそのすべてを何年もの間覚えておくことは困難です。
なので「ドキュメント」に残すことで後で読み直すことが可能になります。
－ 弐． そもそも設計するため －
これは壱に近いのですが複雑な設計をするときには設計をしてるそばから忘れていく可能性があります。
例えて言うなら、１ケタの暗算ならできますが１０００ケタの計算は筆算が必要で暗算が出来ないのと一緒です。
（出来る人もいるかもしれませんが……わたしには無理です……）
それと同じで、簡単な設計なら頭の中だけで出来るので紙に頼る必要はありませんが、複雑な設計になってくれば頭の中だけでは整理できないので紙に残しながら行う必要があるのです。
－ 参． みんなに読んでもらうため －
頭の中で考えた設計を共有することはできませんが「ドキュメント」になっていればそれを関係者で読むことができます。
関係者が読むことができればそれによって間違いに気付くことができたり更により良い案を考えることもできます。
いわゆるレビューが可能になります。
品質が上がります。
では設計書は"絶対"にあった方がいいのか？
上のようなメリットが明らかに無いのであれば設計書はいりません。
頭の中で考えられるならそれでいいですし、ホワイトボードに書いてすむならそれでいいです。ソースコードから設計の意図が理解できるのであれば別のドキュメントを作る必要はありません。
ただ逆に、ソースコードから読み取れない意図や背景がある場合や、関係者に何かを伝えなければいけないときには書いてください。
おわりに
ということで、このような分析と設計の違いや、設計書の意味などは、初学者ではなかなか出会う機会がないと思いますので、少し時間あったのでまとめてみました。