人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

PM/アーキテクト/SE/プログラマ…その他システム開発に従事する方々へ質問です。

先程、下記のアンケートで次のようなご意見を頂きました。
# アンケート<<http://q.hatena.ne.jp/1156927032>>
> 「設計書がどの程度役に立ちったか%で回答とか」とか
> 「設計書は正確でしたかとか」
> 「設計書は役にたちましかとか」
> だと面白い回答が得られたと思います。

なるほど!という感じです^^
そこで
『いままでに経験した良い設計と悪い設計』
というものから
『私は見た!こんな笑える設計』
的な、設計にまつわる子ネタ話や
『設計なんかいらねぇYO!』
『本当に設計って必要なの?』
といった破壊的御意見
『こうすれば設計は良くなる!役に立つ!』
といった建設的御意見などなど...etc
回答をお願いしたいと思います。

宜しくお願いしますm(_ _)m

●質問者: keisen
●カテゴリ:コンピュータ ウェブ制作
✍キーワード:ETC pm SE しかと アンケート
○ 状態 :終了
└ 回答数 : 17/17件

▽最新の回答へ

[1]あなた プログラムを作って taknt

といわれて 何を?となります。

そのときに、ここに書いてあるものを 作ってとなり、これが設計書というものになるわけです。

ちゃんとした形になっていなくても、漠然とした設計があるかもしれません。それを形にしたものが設計書でしょう。

頭の中にちゃんと設計書が作る人の頭にある場合、それを 外に他の人がわかる形にしなくても プログラムは作れますが、作る人が別の場合は、その人にわかる形のものにしないとダメです。


設計書がいらない場合は、作る人の頭の中に設計書が入っている場合です。

それ以外は、設計書がいります。


[2]基本的な設計思想が明確になっているプロジェクト paffpaff

実現するにあたってのポリシーが明確になっていて(カリスマPMだった)

みんながほぼ同じ方向を向いているプロジェクトでは

詳細な設計書はありませんでしたが

ソースも非常にきれいで見やすくて

仕事しやすかったです


逆に

詳細設計書は後付けで(ソースから作成する設計書のみ)

プロトタイプがたたき台じゃなくてなんとなくそのまま製品にとりこまれちゃう

その上細かい(画面のこれをちょっと動かして・・・みたいな)変更指示が頻繁にあるようなプロジェクトは

すごくやりにくかったです


ポリシーがはっきりしてないと

設計もちゃんとされないので苦労するってことでしょうか


[3]いろいろな設計書 kurukuru-neko

1. 何もない設計書 有効度 0%

目標が例えば、”家”を建てると事とした場合。

どんな家を建てたいのかが気になるところですが、

書いてあることは、家の種類や、家の建築方法

等が延々とあります。

肝心の立てる家のことがありません?

最後に数行、期間と、詳細はxx参照とあります。

しかし・・

xxがありません。

代わり出てきたのは、提案書と頑張って、まかせたの一言

2. 完璧な設計書 有効度 50%

システム設計資料が膨大、最低でも数十冊は読む必要あり。

各種付帯資料も多数。 各種約束資料もてんこ盛り。

あまりにも多量で高度で複雑過ぎて、できる人以外が脱落、

開発遅々として進まず、実績のないソフト、実績なしの技術

、最新OS、新規開発中機能を前提、案の定トラブル頻発


[4]>3 なるほど keisen

2番は開発規模が大きいところでよく見ますね^^;

始めは

「よいシステムを作る。開発を成功させる。」

という目的の達成のために良い設計書の構成を考えていた筈が、

いつのまにか

「完璧な設計書を作る。」

が目的になってしまったパターン(涙)

「程度」っていい言葉だなぁと思う今日この頃(笑)


[5]>2 たしかに keisen

> 詳細な設計書はありませんでしたが

> ソースも非常にきれいで見やすくて

> 仕事しやすかったです

個人的に

「設計書は詳細なものを残すべし!」

と普段考えてますが、

仕事がしやすく、かつ問題が起きないのであれば

極端な話、

「設計書が無くても良い」

というのもアリですか。

うぅ?ん、、私もそのプロジェクトに行ってみたかったです^^;


> ポリシーがはっきりしてないと

> 設計もちゃんとされないので苦労するってことでしょうか

結局、問題起こすのはいつも人ですしね^^;

みんなが同じ向きを向いていないプロジェクトはやりずらいし、

火を噴くのを待ってる感じがします(笑)


[6]>1 なるほど。しかし keisen

> 設計書がいらない場合は、作る人の頭の中に設計書が入っている場合です。

> それ以外は、設計書がいります。

極端な話、、、

その"頭の中に設計書が入っている人"はシステムが存在、稼動する限り、

・長期間の病欠をしてはいけない

・鬱などを理由に休職してはいけない

・退職してはいけない

・たとえ事故でトラックに轢かれても死んではいけない

という状態になるような^^;

設計書は保守/運用や仕変でも使うと思いますが

この点をふまえると如何でしょうか?


[7]とあるプロジェクトでの設計書(経験談) Ark-is

私が経験した経理システム開発プロジェクトでの設計書です。


「これ、作って」と上司に渡された設計書は一枚の紙でした。

(この時点でおかしい。一枚でInput/Process/Output/Layout etcを盛りこめるワケがない。)


パッと見て、書いてあったのはたった2行。

それは、帳票の名称と「担当者に確認のこと。」という文言のみ。

担当者の名前すらない。

この紙のフォームの上部にしっかりと「外部設計書」と書かれていて、これの他に設計書はないとのことです。


「これだけでは設計できない」と上司に言ったら、「じゃあプロジェクトから出てけ」と。逆ギレですよ。

ひと悶着の後、彼は面倒臭そうに、旧システムで使用していた同類の帳票のサンプルを私によこして「じゃ、これと同じようなの作って」と。

実際にお客様側の言い出しっペ担当者を紹介してもらったのはその日の夜(残業中)のことでした。


後から他の先輩に聞いてみたら、決して嫌がらせじゃなかったんですね。

デスマーチプロジェクトで、上司自身も一杯一杯だったようで。


[8]>6 そのような運用の場合は、設計書が必要ですね。 taknt

つまり、頭の中に入っている場合は、その人がそれで困らない程度のものなのです。

その人が、作ってその人が 使う。

ほかの人に 使わせても プログラムの修正は その人が 行う場合ですね。

違う人が プログラムの修正をする場合は、プログラムを見て理解できる人なら 設計書は いりませんが、基本的には 必要でしょう。

といいつつ、設計書なしで(みないで)修正する場合が多いですけどね。


[9]>7 それは客先との打合せからやれ ということだったんですね。 taknt

忙しいのは わかるけど、仕事の割り振りが うまくできない上司なんですね。

仕事を 抱えすぎかな。

きちんと 割り振って自分は その結果を 確認するぐらいにしないと ダメだな。


[10]オープンソースソフトウェアの場合 sukeshi

設計書ってあるんでしょうか?


[11]>8 わはは^^ keisen

> といいつつ、設計書なしで(みないで)修正する場合が多いですけどね。

「見も蓋もなぁーーーい!」

と突っ込みたいところですが、確かにその通りですね^^;

たまには見ることもあるので、

その「たまに」のために必要だとは思いますが(笑)


[12]>7 その上司。 keisen

> 「これだけでは設計できない」と上司に言ったら、

> 「じゃあプロジェクトから出てけ」と。逆ギレですよ。

凄い。名台詞ですね^^;

「山田君!座布団3枚持ってって!!」

という感触でしょうか(笑)


> デスマーチプロジェクトで、上司自身も一杯一杯だったようで。

真面目に、こうなってしまうと悲惨ですよね。


[13]>11 設計書が必要なのは taknt

仕様を知らない人間に、プログラムを作ってもらうためじゃないのかと思います。

新規開発の時は、設計書がないと困ります。

一度、作られたプログラムは、それ自体が仕様(設計書)みたいなものなので、それを見たほうが、メンテナンスされていない設計書より大いに役に立つんでしょうね。


[14]>13 なるほど。 keisen

仰る通り、新規で設計書が無いのはお話になりませんね^^;

# 無いまま作ってしまうプロジェクトも結構あるようですが。

ただ、設計書がメンテナンスされていないのがそもそもの問題なんですよね。

これが何とかならんのか!と。

ソースコードが仕様書といっても、基本、人間に理解できる量には限界があります。

すると、ある程度の規模からはどうしてもドキュメントが必要になってくる。

担当者が入れ替われば、もう確実にドキュメントが必要になる。

特定の人に依存しないで保守/運用するのが理想的なので、

そこを何とかするためには、

やっぱり設計書のメンテナンスって必須だと思うんです。

--

うぅ?ん、、

次は設計書のメンテナンスで質問を。。。


[15]>14 一番怖いのは kurukuru-neko

本当に動いているバイナリー以外何もなくそれも基幹システムの場合。

作った人も既に存在しない、操作資料以外の資料は何もないか既に破棄

されている。

しかし、動いている・

どう動いているかはしらないが、結果は出ている・・・・・・

止まると業務に支障がでるのでだれも触れない。

当然ハードも変更できない。

不幸の先送りでだれかがババを引くのを待っている。


[16]>9 カウンターもあてられる場合もある kurukuru-neko

> 「これだけでは設計できない」と上司に言ったら、

あるプロジェクトで外注が逃げて、後始末することがありました。

設計資料どうりは作ってはありますが楽しい実装処理で

保守不可能な構造。

引き継いで(後始末)くれと言われたとき、こんなもの不可能と

引継ぎ拒否を宣言して、逆パターンで切れたことはあります。

>「じゃ、これと同じようなの作って」と。

設計資料は、それなりにあったので「じゃ、これと同じようなの作って」になり。

よくある全面的につくり直しパターンになりました。

全面置き換えをすると関係者のモチベーションがさがるので開発中は

メンバーにばれないように物理隔離されましたが。


[17]最悪な設計書 kuramao

以前、ある外注から引き継いだ業務の設計書を見たところ仕様に矛盾だらけ・・・。

ソースと設計書もリンク取れてなくてバグだらけ・・・。

課題を洗い出してその外注に確認したら「もう関係ない!」と逆ギレ・・・。

課長は一気に白髪が増え、隣の同僚は軽いうつ病、私は血尿が出ました。

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ