ソフトウェアの設計手法を学びたい。チームに浸透させたい。

Question

###前提・実現したいこと
ソフトウェア開発をする上で、コーディングよりも設計が重要であると思っています。しかしながら、体系化されたよい設計手法を学びたい・知りたいと思うもののなかなか設計手法の習得ができずにいます。
また、チームで設計を行い、情報を共有して進めたいのですが、皆様はどのようにして設計手法を学び、チームに浸透しているのでしょうか？
良い学習方法や情報元などありましたら、教えていただきたいのですが、いかがでしょう？

Answer 1

設計、という、分野においては、正直「学習」で何とかなる部分と、そうでない部分があるかと思います。

まず「学習」でなんとかなる部分については、さまざま書籍などもありますし、そもそもの設計思想的な話についても（それこそアジャイルか、ウォーターフォールか）という事は、いろいろネットなどを読むと、いろいろ学ぶ所は多いかと思います。
また、設計用のツール的な面でも（UMLとか）、いろいろな道具がありますので、いろいろ調べてみて、自分で気に入った物をまずは、勉強するのがよいかと思います。

そして「学習」では何ともならない部分、というのは「経験」です。
こればかりは、机上ではどうにもなりません。
経験ではなく知識と思われている方も多くいらっしゃいますが、

たとえば、自動車の運転をきっちり学んだとしても、実際に公道にでると、さまざまな予期せぬ事が起こりますよね、実際に運転をすることで、予期せぬ事が予想できるようになる（ここって人飛び出しそうとか）、、、
プログラムも同じです。設計通りに作っても、実際には使うユーザーはさまざまですし、環境もいろいろ、、、つまり完全にすべてを予期することは不可能です。でもこの部分も、多くの設計や、コーディングに関わることで、（きっとこんな変な使い方するやついるよな？と想像してみたい）いろいろな想定ができるようになります。

つまり、よくいわれる設計では、機能設計的なアプリケーションに近い部分の設計をどうしても重視されがちですが、実はその裏方の、リスク管理とか、先の拡張性の見極めとか、、、見えない部分の設計に相当力をかけていかないと、設計した物が、とりあえず動く物がでてきたけど、結局バグだらけ、とか、拡張性がなくて、手が入れられないとか・・・そんな物ができてしまいます。
なので、やはり、経験がかなり必要かと思います。

あと、コーディングよりも、設計が大切なのは、確かによくわかりますが、コーディングについて（そして自分で実装にかかわらないなら、実際のコーダーの実力とか）も、それなりの知識を持っておく必要があると思っています。
たとえば、ろくにコーディングもできない、SEが設計したプログラムを実際にコーディングしはじめたら、矛盾だらけで、設計やりなおし！とか、よく有る話です。

さて、だらだら書きましたが、まずは、以下について確認しながら設計をしていくのがよいかと思います。
そして、可能であれば、その道のエキスパートさんに、途中途中で確認をしてもらい、突っ込みを入れてもらう、コーダーさんとも時々キリのいい段階で、レビューして、突っ込みをいれてもらう。

・要求仕様
まずは、これ重要です。何がやりたいのか、誰が対象のサービスなのか？

・概要設計
ここで、要求仕様を実際の設計図の概要に落としていきます。
必要な機能をどうやって実装するのか？モジュール、ブロックはどのようにわけるのか？
など、実際のコーディングまで踏み込みませんが、コーディング（コーダーのレベル）も意識した設計が必要です。

・詳細設計
実際のプログラミングのIFの定義や、モジュール間のやりとりなど、細かい部分をつめていきます。
（実は私が絡んでいるプロジェクトではこの詳細設計は、コーディングと平行または、後で、行います。
というのは、どちらかというと、アジャイルに近い形で進めることが多く、概要設計でさえ、途中で修正を行いながら実装をしますので、先に設計書を確定が、難しいためです。）

と大きくこの３段階ですが、先にも書きましたとおり、

体系的にうまく設計したい、

と言うことはよく理解できますが、なかなか机上では難しいと思います。
実際に、設計という作業を何度もおこなっていくうちに、それなりの力がついてくるかと思います。

とにかく、経験かと（手法とかは、書籍などで学んでくださいね、）。
エンドユーザさんと、そして関係者（コーダーやデザイナー、営業さん、そして会社、経営者さん）にどれだけ、優しい設計ができるかという所かと思います。

Comments

[ShinichiMukai]

丁寧なご回答ありがとうございます。
つっこみをいれてもらうというのは、必要かと思います。ぜひともそうしたいですが、突っ込みを入れてもらえる人をどのようにして確保するのか（能力の高い人が周りにいない）も実は難しい問題だという気がしています。
もし差支えなければ、どのように経験を積んでこられたか教えていただけると助かります。突っ込みを入れてもらえる人をどのようにして確保したらよいかご意見いただけたら幸いです。

[ItoTomonori]

私の場合は、プログラミングの学習が先行で、プログラムを書き始めて、かれこれ３５年。トホホ。。。IT業界で実務としての仕事は、２０年ほどの経験となります。

その２０年ほど前に入ったIT企業は、ベンチャー的な要素が強く、機能毎に、個人に設計＆実装をまかされる、というスタイルが多く、全体の組み立て段階で、必然的に他のメンバーに迷惑をかけないような、そんな設計が必要となりました。
これはかなり、いい勉強になりました。誰が突っ込むというより、設計がタコだと、相手方が使いにくいとか、拡張できない、という具体的なクレームが出てくるため、その都度設計変更をしていました。

その後、さまざまな設計業務や、実装業務を行っいながら、成長してきた、という所でしょうか。その中で、特に、大きい会社さんとの仕事などの場合には、設計書とかの精度を高く求められたりしましたので、そのような時には、その会社さんの設計書のひな形などをもらったいと、、、いろいろ勉強素材は、苦労しなかった所もあります。

ということで、すいません、人間が古いため、IT業界の流れにそのまま乗っていたという、あまり苦労せず、な経験者であります。

さて、突っ込みを入れてくれる人ですが、
これは、メンバー内にいらっしゃなないのれあれば、
・外部人材を投入してサポートしてもらうか、
・社内プロジェクトであれば設計のしきたりとか無視して突き進むとか、
そんな所ではないでしょうか。

外部委託をすると、お金はかかりますが、いい人にあたれば、かなり有用です。
「設計委託」
ではなく、
「設計支援委託」
という形で、条件（使える言語とか、ホニャララ経験者とか）をつければ、いがいと人材はいるかと思います。

ただ、「いい人」にあたれば、という所なので、よく、人柄、スキルを見極めるために、面接するとか、食事するとか、スタートはじっくりされたほうがよいかと思います。

[ShinichiMukai]

丁寧なご回答ありがとうございます。
設計支援委託という形を検討してみたいと思います。
経験については、やはりお互いで突っ込みあいながら切磋琢磨するといった感じで進めていくのがよいように感じました。
ありがとうございました。

Answer 2

唯一体系的な方法があるとすれば、情報処理試験ではないでしょうかあまり役に立つものではないかもしれませんが、往々にして体系的な方法というのは、すぐに役に立つものではなかったりします。少し遅れ気味に対応しますが、網羅的にはなっているので、基本的な間違いをしなくなったり、用語を正しく使えるようにはなるはずです。

また、それを浸透させるには、レビューをおいて有用なものはありません。有資格者の一人の意見よりみんなでブラッシュアップした意見のほうが説得力や浸透のしかたが違います。慣れてきたら、社内のＳＮＳやメールなどでやってもいいですが、たくさんの意見を拾うために最初は、みんなで時間をとってやるのがいいです。

ついでですが、高度情報処理試験問題に出てくる仕様書などの資料は、超一級品にわかりやすい資料です。ここまでわかりやすい資料をかける人は見たことがないと思っていますので、一度ご覧になってください。

Comments

[ShinichiMukai]

高度情報処理試験問題の仕様書を見てみるようにします。
ご回答ありがとうございました。

Answer 3

方法論や、書籍は色々ありますが、
まずは、
＠IT > 自分戦略研究所 > エンジニアライフ > Press Enter■
http://el.jibun.atmarkit.co.jp/pressenter/all_entrylist.html
高慢と偏見（1）隣は何をする人ぞ
から、読んでもらって、（コメント欄も必読。）
各物語毎に、何が不味いのか、如何すれば良いのかの、
社内や、チームでの合意を作ってみる事から、始めるのもありかも。
⇒コメント欄が荒れている部分なども、何故、どうしてそうなっている？
何がコミュニケーションの祖語を生んでいるのか？
などの、検討に使えるはずです。

Comments

[ShinichiMukai]

コメントありがとうございます。
じっくり読ませていただき、皆で考えてみようと思います。