ソフトウェア開発における分析と設計

何人もの方からプログラミングにはかなり自信を持っているが設計がうまくできないという話を聞ききます。
ここで言う設計とはプログラミングを含む実装設計ではなくて、システムの構成や保守性を考えたソフトウェア構造設計のことを言っています。
そのような人たちは向上心も旺盛で、モデリングデザインパターンなどの設計技術の勉強もかなりされているようですが、なかなか思うようにいかない様です。
よく話を聞いてみたり一緒に仕事をした時に様子を見てみると、どうも分析の問題を設計の問題だと誤認識してしまっているようなケースが多く見られるように思います。
問題事象(ドメイン)分析ができておらず十分な理解ができていないために設計がうまくできないことを設計スキルが不足していることが原因だと考えてしまっている様です。
分析による理解が設計のインプットだとすると、アウトプットが出ないのはインプットが不足していることが原因であるのにもかかわらずアウトプットを出すための技術のことばかり考えていても結果が出ません。
もっとドメイン分析=問題事象の理解を意識することをお勧めしたいと思います。
もし知識の習得を考えるのであれば設計技術と同じぐらい分析のための技術も調査することをお勧めします。


さて、ここで改めて考えてみると分析と設計となにがどう違うのでしょうか?
実は正直言ってこれを書こうと思うまでは私自身もなんとなく考えていて特に意識はしていませんでした。
構造設計とは分析結果に対してシステムの構成や保守性などを考慮して構造を決定することだと考えています。
しかしよく考えてみると、システムの構成や保守性も用件に含めてこれらを考慮して分析を行うと分析結果にこれらの意図を含むことができます。
この点が分析と設計に対する混乱の原因になっている様に思います。
現実的なことを言えば、良いアウトプットが出れば分析と設計の区別なんてどうでも良いことだと思います。
要は分析と設計でクロスオーバーする領域をどう捉えるかということであり、そのような領域は分析か設計かどちらの視点で考えるかというだけの問題です。
もし混乱しているのであれば視点あるいは自分の意識を確認すると良いかもしれません。


本当に設計の能力を身に着けたいのであれば分析の限界を意識することが重要だと思っています。
分析ではうまく解決できない問題、例えばシステムの構成やソフトウェアの保守性などの問題に対して設計者が意図をもって解決することこそが設計行為なのだと思います。
この分析と設計の境界を意識することはアスペクト指向MDAのアイデアを理解し効果的に活用するポイントにもなると思います。
設計の視点でうまくいかないのであれば、もっと限界を見極めるまで分析の視点で考えてみてはいかがでしょうか?
同じものが違って見えてくるかもしれません。