- 締切済み
設計書の書き方について
設計書の書き方について幾つか疑問があります。 IT業界で設計の仕事をしていると、Excelを用いて設計書を書くのが慣習のようになっている気 がするのですが、正直、使い辛くてたまりません。 箇条書きやアウトラインが使えないし、入力する時も一々セルを選択して…という感じです。 どう考えてもWordの方が使いやすいし、列幅を狭くして、使わないセルの方が多い時点で使用 価値はないと思うのですが。レイアウトも見難いです。 もう一点は、よく「設計がちゃんとしていれば…」みたいな書き込みを見るのですが、本当に そうなのだろうか？ということです。 最終的な品質というのは、PGの腕次第で、設計者の技量ではないと思います。 設計が完璧でもPGがスキル不足、或いはその逆でも良いものはできないと思うのですが。 それ以前に設計書を読んで存在価値を感じた物がありません。そんなものなくても、 コードを読めば理解できるのが技術者というものではないでしょうか？
- corps2003j
- お礼率29% (8/27)
- その他([技術者向] コンピューター)
- 回答数8
- ありがとう数7
- みんなの回答 （8）
- 専門家の回答
みんなの回答
- maura
- ベストアンサー率46% (48/104)
- don_go
- ベストアンサー率31% (336/1059)
- don_go
- ベストアンサー率31% (336/1059)
- 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/6290)
設計書のテンプレートをWordで作成して、 全社で採用するように働きかけてみてはいかがでしょうか。 改善提案のアイデアとしては悪くないと思います。
お礼
ご回答ありがとうございました。 そのような提案も考えてみましたが、現在の案件の職場は一切提案を 受け入れない態勢のようです。 会社が数社入っているのですが、自分達の作ったルールを外部から 来た人間に変えられるのが面白くないようです。困ったものです…
- okg00
- ベストアンサー率39% (1322/3338)
>Excelを用いて設計書を書くのが慣習 そんなの初めて聞きました。Excelのセルを細分化してレイアウトしやすくしている人はいますが、慣習にはなっていないですよ。 >最終的な品質というのは、PGの腕次第で、設計者の技量ではない PGさんがみんな質問者さんほどの能力があれば良いのですがね。尤も、設計書と異なる製造をされると困りますが。 >設計が完璧でもPGがスキル不足、或いはその逆でも良いものはできない まったくそのとおりです。しかし、設計段階で品質が低ければ(仕様漏れ、設計ミスなど)製造段階でそれをリカバーできないです。「仕様書と成果物が同じ」これが大原則です。 >設計書を読んで存在価値を感じた これはどうでしょうね。設計者と製造者が同じならば必要ないです。その後、一生メンテナンスしてくれるならね。 >コードを読めば理解できるのが技術者 それは最低限度の求められる能力ではないかと。コードが最新とは限りませんし、どの段階で不具合が出たかを探るためにも仕様書は必要かと。 数十人月～数百人月あるような大きいシステムだと、仕様書はないときついなあ。もっとも、仕様書をメンテナンスするのも大変ですが。 あとは、発注者からお金をもらいやすくするための方便という見方もありますね。
お礼
ご回答ありがとうございました。 少し誤解があるようなのですが、自分は別に設計書がいらないと 言っている訳ではないのです。 今までまともな設計を見たことがないだけかもしれないのですが、 設計書を見て必要だと思ったことがないのです。 酷いものになると、画面の画像を貼り付けているだけだったり、 意味不明な独自のフォーマットを強制されたり… SE（設計者）がPG（製造者）より、立場が上（威張っている）理由 が分からないのです。 じゃあ、自分が設計すれば？みたいな論理に当然なると思いますが、 そういう提案を露骨に否定されることが多いのです。 一つの会社で長く同じ現場にいると、自分達のやり方が正しいと 思って、違う現場で色々と経験を積んで来た人間の言うことを 聞き入れない人が多いような気がします。
![その他([技術者向] コンピューター) イメージ](https://gazo.okwave.jp/okwave/spn/images/related_qa/c205_3_thumbnail_img_sm.png)
お礼
ご回答ありがとうございます。 ちゃんとした設計というのは、どういうものをいうのでしょう？ できれば、リンクなどご教示頂けるとありがたいです。 自分で調べたりもするのですが、そこに載っているサンプル等は、 本当にこんなんでいいのか？と思わされるものばかりです。