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