はじめに
ソフトウェア開発では、設計が重んじられる傾向がないだろうか。
私も設計が大事だということは理解しており、「エリック・エヴァンスのドメイン駆動設計」などの書籍を元に、設計手法について勉強してきた。
しかし設計という行為は ある問題に対する解決策を導く作業 であることから、良い設計をするためには ソフトウェアで扱う問題を明確にする作業 が欠かせないと最近では思っている。そしてこの問題を明確にする行為は 分析 と呼ばれる。
この記事では、分析が大事な理由、分析とは何をする行為なのかについて、私が学習した内容をまとめる。
分析が大事な理由
分析が大事なのは 分析なしでは設計ができないから である。
先ほど述べた通り設計とは分析で明らかになった問題に対する解決策を導く行為である。したがって 分析で明らかにできなかった問題に対しては設計作業をすることができない ことになる。
例えば図書館の本貸出サービスでは、以下のようなケースがあることに気づく必要がある。
- 返却を2週間延滞した利用者が貸出予約していた図書が貸出可能になったケース
上記ケースへのアクションとしては「返却を延滞した利用者は延滞した時点で貸出予約を取り消される」や「返却を延滞した場合でも貸出予約は1週間は有効である」などが考えられるが、どの仕様になるかは図書館の業務に依る。
上記ケースに気づけず、実装が仕様と一致していなかった場合不具合となる。そして不具合修正には以下のような問題がある。
-
設計が腐敗する
不具合を発見した工程にも依るだろうが、特にSST(System Simulation Test)以降に発見された不具合の場合、「他の処理に影響が出ない修正案を採用する」傾向が強くなる。この場合一から設計をやり直すことはなく、既存の設計構造の中に不具合を修正するためのその場しのぎのコードが実装されることになり、 当初あった設計意図が失われる ことになる。 -
信用を失う
上記のような簡単なケースについて考慮が足らなかった場合、または難しいケースだったとしても考慮漏れが頻発した場合、その人（最悪のケースでは企業）への信頼は失われる。また、不具合を出した人は再発防止活動など、本来の開発業務とは関係のない作業をさせられる羽目になる。
何すれば良いの
まずは 業務を学ぶ 必要がある。開発者が業務を学ぶと言うと「えっ？」と思う人も多いようだが、ソフトウェアで扱う問題はユーザの業務から生じたものであることから、問題を明確にするために業務を学ぶことは欠かせない。先に挙げた問題（返却を2週間延滞した利用者が貸出予約した図書が貸出可能になったケース）もシステム化対象の図書館の業務について知っていれば問題にはならない。
次に 業務を知っている人と会話をするための言葉を学ぶ 必要がある。英語ができない人が洋書を読んでも内容を理解できないように、業務で使用する言葉を知らない人が業務を理解することはできない。例えば先の例では「図書は書籍と雑誌に分かれる」とあるが、「書籍」と「雑誌」の定義や違いを曖昧なままにして業務を正しく理解できるはずがない。
業務について学ぼうとすると、業務に詳しい人が身近にいないという問題が発生する。そんな場合は他の教材を探すしかない。例えば「利用規約」は業務知識が詰まった良い教材だと思う。
最後に モデルを検証する 。具体的には「モデルの言葉で問題領域について話すことができるか」を検証する。個人的な経験ではこのプロセスを軽視、または実施しない人が多いと思う。その結果実装段階になって、 その場しのぎで モデルを変更することになる。こうなると当初あった設計意図が失われ、ソフトウェアが必要以上に複雑化する。
最後に
良い設計をするためには、業務知識を反映させたモデルを作成する必要があることを述べた。このモデルは曖昧さがなく、開発に関わる全ての人が共通認識できる概念のみで構成する必要がある。