システム開発の詳細設計について

私は受託開発の会社に2ヶ月前に入社したばかりの新人です。(今までのシステム開発の経験は1年ほどでプログラミングと単体テストしかやったことがないです。)

質問したいのは、詳細設計の作成する方法や書き方を学べる書籍はありませんでしょうか？
またテストケースの作成の仕方やテストの実施についても学習できる本もご教授いただけると幸いです。

よろしくお願いします。

質問者からの補足コメント

• 回答ありがとうございます。私がご教授頂きたいのは、設計をどういった観点で書くべきとか、設計時の注意点などについて書かれた書籍があればと思っております。
  私の説明不足で申し訳ありません。

  No.1の回答に寄せられた補足コメントです。 補足日時：2016/09/17 10:46

No.2 ベストアンサー 回答者： Glory_777 回答日時： 2016/09/17 12:13

30年ほど仕事でやってます。

コンピューターの黎明期から現在まで現役です。

ですので、電子計算機のソフト開発がどのように整理されてきたか見てきました。

この世界で生きていくためには、覚えようとしてはダメです。

いま本になっているモノは引退した人が書いたものだと思いましょう。

しかも、例が書かれているだけであり、そのまま実施するべきではありません。


まず最初に知るべき大きなことは、

プログラミングをしてお金が貰えるわけではないという事です。

お客様はシステムを求めているのであり、プログラムを求めているわけではないのです。

簡単に言えば、最後実施する手段が人手であって、

コンピューターがどこにも介在していなくても良いのですよ。

恐ろしいことにｗ・・・お客様が納得し、手で作業をする場合が多いと思いましょう。

ここを勘違いしていると、プログラマからシステム開発者になれません。

また、人手の他に機械装置でも良いわけです。

お客様の業務を知り、どこが困り具合なのかを指摘し、仕事の段取りを提案する。

ここにお金が支払われます。

勿論、お客様の業務は、お客様の環境（そこにある物や人）に対して最適です。


そこで、

最先端の道具、業務を受け追う受託会社、パッケージや製品を調査する。

それらを使うと業務が楽になるという場合があります。

ただし、大体の場合は道具を最大限に活かしたり、外部へ発注するための準備が必要

になります。

そこまで調査が出来たので、準備作業を新たに行うようにお客様に提案したとします。

しかし、そのまま作業として実施しますと、楽になった分と相殺されてお客様が余計に

苦労する場合があります。

つまり、道具や製品、外部の受託会社を上手に使うためには、

業務の流れから見つめなおし、それに適した形に変えていく必要があります。

勿論道具側もカスタマイズしないといけません。

お客様は、余計な仕事が増えるのではないかと怯えていますから、

良く計算し、実験し、分り易くプレゼンをし、現場と経営者の双方を説得します。

また、技術者が苦労をして、良い塩梅になるように微調整が完了しますと、

その調整値がとても大事になります。

実際に使うときに、これを守りませんと、想定の効率が出ません。

これらは当然ながらドキュメントベースで資料を作成しないといけません。

また、教材を作らないといけませんし、マニュアルを作らないといけないでしょう。

最後は、お客様が技術者の指定どおりに作業をしているか？

定期的にチェックしないといけなくなります。

何時の間にか技術者が悪者になっており、会社の評判が落ちている場合が多くあります。

上手に使いこなしているか？

ここに重点をおいてサポートするのが昨今の流行です。


さて？

ここまで書いただけでも、対人のお仕事が沢山あるとわかります。

そこで、自分が対面せずに、他の人に指示を出してもらう、必要がどうしても生じます。

この人が上手に指示を出すためには、やはりマニュアルやドキュメントが必要になります。


この様に、

システム開発を行いますと、ソースコーディング量を遥かに上回るドキュメントが必要

となります。

その上で、

読む人が人間ですから、誤解の無いように分かりやすく記述していないといけません。


コンピュータを上手に使いこなそうと考えた黎明期から、これらの課題はずっとありました。

先人は、”プログラミングや技術が苦手”と言う初心者の悩みを持っていたのではなく、

プログラムを書いてお金を貰うために生じる、”様々な対人の業務”に悩み、

これらを”ドキュメントにする作業”に悩んでいたのです。

そのために、これまでも、今でも、ドキュメントの量を減らすための工夫をしてきたのです。

このドキュメントも、お客様向け、技術者向けと大別できます。

昨今は、運用保守が委託されるのが普通ですから、運用保守向けのドキュメントが重視されます。

技術者向けのドキュメントは、同業他社向けとなります。

そうしたドキュメントを特に、設計書と呼んでいます。

そうした中でも、対人から遠い、コーディングに近いドキュメントが詳細設計書になります。

システム開発の初心者向けになるのですが、

簡単であるとか、基本である、と言う意味で初心者向けなのではありません。

どちらかというと、誤解が生じても事故に繋がりにくいという意味で初心者向けです。

コーディングに近い部分は、

開発の途中で試験をするので、自分で間違いを見つけやすいからです。


この世界では、バグが一つ残って納品されると、

会社が吹っ飛ぶ額の負債を抱える場合が多いです。

納品が遅れただけで、会社が倒産するとか、良くある話です。

これを良くわきまえていて、

プログラミング作業でも誰にも負けない腕を持つ人を、システム開発者と呼びます。



設計もドキュメント作成業務の一つですから、効率化が必要です。

まずは作るべきドキュメントの数を限定します。

ｘｘ向けのｘｘ用とすれば、ここは定型化できます。

内容についても、目次を予め定めて置き、

穴埋め問題の様にしてしまえば、作る人が楽です。

記号や数字を使ったり、書き方を統一し、不要な記述を残さないように注意をします。

これらは先輩が貯めたノウハウですから、

その会社の規約や標準、ルールとして残されています。

ですので大筋では、会社毎に設計手法とドキュメント記述ルールが定まっています。

その場合であっても、開発の責任を担う人が、

開発が始まる前に、ルールをカスタマイズし、

効率を上げるように配慮します。開発毎に作り直すという事です。

この設計書のカスタマイズルールも残さないといけません。

技術者は、大筋の標準を理解し、カスタマイズ部分を読み、

実際の設計書を書きます。

他の開発に参加する場合も、そこから入り、内容を理解していきます。


そうしたプロが集まって、会社間の齟齬を無くそうという動きがあります。

こうした動きを標準化といいます。

標準化が為されていると、技術者同士が同じ言葉で会話が出来ます。

組織の作り方や、役割分担、命名、検討事項、残すべきドキュメントの大枠が

定まっていれば、スムーズに仕事を引き継げます。

つまり、それ以前では、ｘｘｘ社系、みたいなものが業界にあり、

技術者にとっては不便であったんです。



では設計書というものの本質について言及します。

この概念で最も重要なのは、どう決めたか？　です。

後で解釈が変わる場合は、品質が悪いといわれます。

そこで具体性が大事です。

文章でも、”ｘｘｘのときは、ｘｘｘをする。”と書きますが、

”ｘｘｘ変数が５０のときは、ｘｘｘメッセージのIDを２００とし、ｘｘｘをコールする”

の様に具体性が高いことが大事です。

勿論、お客様の要望が変われば、これらは壊滅です。廃棄になるでしょう。

また、試験によりバグが出た場合は、このドキュメントを直します。

そして、再度コーディングにトライするのです。

プログラミングを先に行い、とりあえず動いたものを決定稿とし、

これを文章にするとマニュアルやドキュメントです。

自分でどうするか先に決めてドキュメントを書き、コーディングした場合は設計書です。

この違いを良く理解して、言葉を使い分けましょう。

詳細設計では、詳細設計に書いていないソースやデータテーブル（カラムまで）、

実装してはいけないという縛りがあります。

気を利かせて、足りない部分を挿入したり、変更したりすると、

バグとして扱われ、（例え動いたとしても）実施者の責任になります。

法的な責任を負う場合もあり、非常に厳しいので注意が必要です。

設計書の通り（例え動かないとすぐに分っても）コーディングをし、

（思ったとおりであっても）バグが出た場合は、設計者の責任と成ります。

プロはここを弁えていないといけません。

つまり、詳細設計書は、

設計書無しで、想定するものを作れる程度の技術がないと出来ません。

「私は普段、こうやっている。多分作れる。

　え、それら全て書けって？

　いやいや、ここは一般的だから、書かないでいいよね？

　え、だめなの？

　えええ、じゃこのソース部分も書くの？

　バカジャン、これじゃドキュメントでプログラミングしてるみたいじゃん。

　意味ねえよ。」

と思うようなモノが詳細設計書です。

「あたまきた、じゃ、ここは普通、Trueで設定するけど書いてやる。」

となり、

「ああ、それも書いておけって事だね。わかったよ。」

となり、最後は、

「おい、そこ設計書にない記述だぞ。どうしてそうしたんだ？」

「え、こうしないと動きませんよ。先輩。」

「そんなの俺だって知っている、

　どうして、設計書に書いてない部分を作ったんだと聞いている。

　どうして、設計漏れではないかと、設計者に問い合わせない？」

となり、何時の間にか詳細設計が出来るようになるんです。

設計書を書く、設計書を読んで実施する。

これは文書の記述方法に極意があるのではなく、

自分がやりたいことを記述し、その通り実践する行為に極意があります。

ですので、作り方に極意を求めると、永遠に分らないままになります。

そして、書き方はお客様が指定するので、毎回違います。



以上、ご参考に成れば。

No.1 回答者： don_go 回答日時： 2016/09/17 10:37

設計書の書式等は、会社毎に異なります。

まずは、上司や先輩に質問する事が先です。
＃自分勝手に書式を作っても、受け取ってはもらえません。