- 締切済み
設計書の書き方について
設計書の書き方について幾つか疑問があります。 IT業界で設計の仕事をしていると、Excelを用いて設計書を書くのが慣習のようになっている気 がするのですが、正直、使い辛くてたまりません。 箇条書きやアウトラインが使えないし、入力する時も一々セルを選択して…という感じです。 どう考えてもWordの方が使いやすいし、列幅を狭くして、使わないセルの方が多い時点で使用 価値はないと思うのですが。レイアウトも見難いです。 もう一点は、よく「設計がちゃんとしていれば…」みたいな書き込みを見るのですが、本当に そうなのだろうか？ということです。 最終的な品質というのは、PGの腕次第で、設計者の技量ではないと思います。 設計が完璧でもPGがスキル不足、或いはその逆でも良いものはできないと思うのですが。 それ以前に設計書を読んで存在価値を感じた物がありません。そんなものなくても、 コードを読めば理解できるのが技術者というものではないでしょうか？
- corps2003j
- お礼率29% (8/27)
- その他([技術者向] コンピューター)
- 回答数8
- ありがとう数7
- みんなの回答 （8）
- 専門家の回答
みんなの回答
- maura
- ベストアンサー率46% (48/104)
私もいろんな会社を渡り歩いていますので なんとなくお気持ちが判るような気がします。 まず、設計書はPGの為のものでなく、最低限 お客さんに提出し理解していただけるものであればいいもの だと思う方がよいかと思います。
- don_go
- ベストアンサー率31% (336/1059)
＞ちゃんとした設計というのは、どういうものをいうのでしょう？ 納期や予算、テスト方法、客先への納品物に含まれるか 否か等の条件によっても変わりますし、完璧な物という のは有り得ないので、とりあえずの所は、プログラムの 作成に必要な情報が、仕様書の中に過不足なく記述され ている物といった所でしょうか。 ＃ソースリストを解析しなければ必要な情報が入手でき ＃ないのは不可。 ワープロソフトなどもなく、仕様書も全て手書きで作成 していた頃に作られたソフトの再構築の作業をした事が ありますが細部まできっちりと設計してあるのに感心した 事が有ります。 私の中で基礎となっているのは、オフコンメーカーが販社 やソフト会社・客先向けに作成したパッケージソフトの 仕様書と、メーカー(FA制御系－重機)で仕事をした時の 仕様書です。 それに、以降の仕事で他社が作成した仕様書を見たり、 客先との打ち合わせ等で自分が有った方が便利だと思った 個所を自分流にアレンジして追加・削除していった物を、 適宜組み合わせて利用しています。 従って、残念ながらどこかのサイトを見れば判るといった 物ではありません ＞リンクなどご教示頂けるとありがたいです。 最近はどこかのサイトを見れば、それだけで問題が全て 解決するといった勘違いをしている人が多い様ですが... 少なくともシステム開発に携わる者は、既に有る物で 利用可能な物があれば利用して無駄な作業を省き、ない 場合は自分で創り出すというのが基本で有ると思います。 そもそも検索するだけで自分の欲しい物が手に入るので あればシステム開発者など必要とされないのですから。 ＞自分で調べたりもするのですが、そこに載っているサンプル等は、 ＞本当にこんなんでいいのか？と思わされるものばかりです。 それなら、どこが不満に思っているのか、こうすれば 良くなるのにといった個所を探して、改良してみては？ 現状に満足しているだけ、不満に思っているだけで何も しなければ何も変わりません。 第一、仕様書の書式だけ変えたり、表面的な所だけ真似 してもあまり意味はありません。 少なくとも現状に満足していないのであれば、それを 改善する事で前進する事が可能になります。 ＃現状に満足して何も努力しないよりよっぽどまし。 いろいろ有る設計手法も全てを網羅した完成品という訳 ではないのですから、実際の作業の中で取捨選択を行って 自分にとって良い方法を創造していって下さい。 ＃ネタ帳みたいな物を作って日々の作業の間に感じたり ＃考えたりした事を書いてみては？ ＃(最低限１日１ネタは必ず作る事にして) 自分で、仕様書を作る時に注意している点としては ・見る人によって解釈が異なる様な曖昧な表現は避ける。 ・難しい専門用語・業務用語等は極力使用しない。 (必要によっては用語解説を併記する) ・文章で判りにくい場合は、図解した補助説明を追加 する。 ・半年・１年後、数年後の自分は他人だと思って、他人 に判ってもらう為に作る。 補足 ＞SE（設計者）がPG（製造者）より、立場が上（威張っている）理由 ＞が分からないのです。 「驕れる人も久しからず」とも言いますし、そのうち 自滅するか淘汰されるかすると思いますので、暖かい 目で見守ってあげて下さい。 ＃本当に努力もしないで威張っているだけならですが...
- don_go
- ベストアンサー率31% (336/1059)
＞現場にいると、圧倒的にそのような人材が多いです。 私も現場にいる人間なんですが.... それも多分corps2003jさんより経験年数及び内容は上だと 思います。 ANo.4でも書きましたが ＞ちゃんとした設計者と出会った事が無い様ですね... ちゃんとした設計書をこれまで一度も見たことが無いとは.. ここまでくると、悲劇としか言いようが無い様な気がして きました。
ここまで来ると質問者の境遇が不幸なだけな気がしてきてしまいますね。 少なくてもうちの会社では、SEやPGのレベルは評価しており、単金の交渉に使ったりしてますよ。 会社の境遇と本人の待遇に差がある場合は、引き抜きも考えてますしね。
- don_go
- ベストアンサー率31% (336/1059)
＞Excelを用いて設計書を書くのが慣習のようになっている ＞気がするのですが Wordで書くところもちゃんと有ります。 個人的にはWordはバージョンの差異によるファイルの互換性 がExcelファイルに比べて低い印象が有るため、Excelを使用 する方が好みですが。 ＞最終的な品質というのは、PGの腕次第で、設計者の技量では ＞ないと思います。 最終的な品質とは、客先が要求した要件がどれだけ満たされて いるかで有り、どこまで作成するかを最初に客先に示して承認 を得ておく必要があります。 そうしておかないとプログラムが完成してから、意図していた 物と違うとクレームをつけられる(つける)原因となります。 ＃客先及びPGに対して(特に外部に委託した場合)、「言った」 ＃「言わない」「聞いてない」の水掛け論になります。 そういう事にならない様に、意志統一をさせる為にも設計書が 必要になりますし、それを上手く説明し理解させられるか否か が設計者の力量の差としてはっきりと表れます。 ＞それ以前に設計書を読んで存在価値を感じた物がありません。 ちゃんとした設計者と出会った事が無い様ですね... ＞コードを読めば理解できるのが技術者というものではないで ＞しょうか？ 客先から仕様に関しての問い合わせが有る度にいちいち、該当 の記述がどこに有るかソースリストを探し、モジュールを探し してコードを解析・理解するのでしょうか？ 自分が全てのプログラムのコーディングをしたのならともかく そうでなければ、ちゃんとした設計書無しでの理解は無理です。 ＃意図不明のコーディングをするPGも相当数いますし.... 第一、設計書がなくコードの記述のみに頼るしか無いという事 は、コーディング内容の正誤を確認する術が無いという事です。 計算式を間違えていた時などに、どうやって間違っている個所 を第三者が指摘し証明できますか？
補足
根本的な疑問なのですが： 「設計書が必要ない」という視点で意見をされているようですが、 そんなことは書いていないです。 PGした人間じゃないと、修正箇所が理解できないということも 書かれていますが、それは設計においても同様です。 意味不明な設計書は、後で余計な混乱を招きますし、PGが設計書を 元に問題箇所を探ろうとする時に、何の役にも立たず、かえって 時間がかかります。 自分の意見としては、PGがまともにできない人間が設計に関わるのが どうかという疑問をぶつけたかったのです。 現場にいると、圧倒的にそのような人材が多いです。 当然、そのような人間の設計は意味不明になります。「設計書」とは 名ばかりで、本人にしか理解できないただの「メモ」です。
>IT業界で設計の仕事をしていると、Excelを用いて設計書を書くのが慣習のようになっている気 がするのですが、正直、使い辛くてたまりません。 特に決まってはいないと思いますが。システム毎や会社の方針があるので従ってください。 >最終的な品質というのは、PGの腕次第で、設計者の技量ではないと思います。 では作るものは誰が決めるのでしょう。PGがしっかりしてればいいとは、PGが設計しながらコーディングしてされにドキュメントを残していないってことですよね。よくある後からシステムメンテナンスが出来なくなる駄目システムの典型的なパターンな気がしますが。。。 さらにSEとPGじゃ単金が違いますから、設計できる人がコーディングしてたら、人件費がかさみますね。 また、お客さんとのレビューはどうするのでしょう？機能要件が満たされているかをコードを読みながら話すのでしょうかね。 技術者はコードくらい読めと言われても、他人の書いたコードなんて読みたくないし、コードがシステム全体でどのような意味を持っているかを理解できていないとちょっとの変更で大きなバグを出しますよ。 まあ、設計書があれば全て解決するわけではありませんけどね。。
お礼
ご回答ありがとうございました。 ＞システム毎や会社の方針があるので従ってください。 否定するわけではないですけど、こういう考えの人が多数いるので、 仕事がやりにくいです。提案を聞き入れるという気持ちはないので しょうか？ このような考えのSEさんが、技術的に優れていれば問題はないのです が、はっきり言って、明らかにそうでないケースの方が多いです。 何でも、コストの面から考えたり、品質よりも仕事の手順を要求 したり。意見を否定されると： 「じゃあ、自分で会社でも作れば？」 と言ってみたりで。
- asuncion
- ベストアンサー率33% (2127/6289)
設計書のテンプレートをWordで作成して、 全社で採用するように働きかけてみてはいかがでしょうか。 改善提案のアイデアとしては悪くないと思います。
お礼
ご回答ありがとうございました。 そのような提案も考えてみましたが、現在の案件の職場は一切提案を 受け入れない態勢のようです。 会社が数社入っているのですが、自分達の作ったルールを外部から 来た人間に変えられるのが面白くないようです。困ったものです…
- okg00
- ベストアンサー率39% (1322/3338)
>Excelを用いて設計書を書くのが慣習 そんなの初めて聞きました。Excelのセルを細分化してレイアウトしやすくしている人はいますが、慣習にはなっていないですよ。 >最終的な品質というのは、PGの腕次第で、設計者の技量ではない PGさんがみんな質問者さんほどの能力があれば良いのですがね。尤も、設計書と異なる製造をされると困りますが。 >設計が完璧でもPGがスキル不足、或いはその逆でも良いものはできない まったくそのとおりです。しかし、設計段階で品質が低ければ(仕様漏れ、設計ミスなど)製造段階でそれをリカバーできないです。「仕様書と成果物が同じ」これが大原則です。 >設計書を読んで存在価値を感じた これはどうでしょうね。設計者と製造者が同じならば必要ないです。その後、一生メンテナンスしてくれるならね。 >コードを読めば理解できるのが技術者 それは最低限度の求められる能力ではないかと。コードが最新とは限りませんし、どの段階で不具合が出たかを探るためにも仕様書は必要かと。 数十人月～数百人月あるような大きいシステムだと、仕様書はないときついなあ。もっとも、仕様書をメンテナンスするのも大変ですが。 あとは、発注者からお金をもらいやすくするための方便という見方もありますね。
お礼
ご回答ありがとうございました。 少し誤解があるようなのですが、自分は別に設計書がいらないと 言っている訳ではないのです。 今までまともな設計を見たことがないだけかもしれないのですが、 設計書を見て必要だと思ったことがないのです。 酷いものになると、画面の画像を貼り付けているだけだったり、 意味不明な独自のフォーマットを強制されたり… SE（設計者）がPG（製造者）より、立場が上（威張っている）理由 が分からないのです。 じゃあ、自分が設計すれば？みたいな論理に当然なると思いますが、 そういう提案を露骨に否定されることが多いのです。 一つの会社で長く同じ現場にいると、自分達のやり方が正しいと 思って、違う現場で色々と経験を積んで来た人間の言うことを 聞き入れない人が多いような気がします。
お礼
ご回答ありがとうございます。 ちゃんとした設計というのは、どういうものをいうのでしょう？ できれば、リンクなどご教示頂けるとありがたいです。 自分で調べたりもするのですが、そこに載っているサンプル等は、 本当にこんなんでいいのか？と思わされるものばかりです。