＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
設計技術の基礎、基本を勉強し直したい．．．
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-02-12 12:19
はにまるです。
表題の御相談です。 対象は業務アプリです。 私は、開発者上がりのシステム設計者で、 システム設計技術の正式な教育は受けておりません。 その様な自分でも、 「設計基準書に合わせて記述されただけ」、 「設計という行為を感じ得る事の出来ない」 設計書が多いと感じます。 我に返り、自分自身が設計技術の基礎知識を持っているか？と考えた場合に、 「設計技術って何？」と思い、基本的な所で思考が止まってしまいました。 調べてみると、直接設計技術の話を直接している本は無く、 ツール技術（ＵＭＬやＤＢ等）の話から入る傾向が強く、個人的に疑問に感じます。 # なんか、オブジェクト指向の議論と似ています．．． 正直、私自身もツール経由で幾つかの設計技術を身につけ、その総合技術が 設計技術となっており、「周囲の設計者より優れた設計が出来る」のレベルで 停止している状態です。 上流工程を目指していますが、今一度、基礎、基本技術を見なおし、 地盤を固めて、次に進みたいと思います。 # って開発もいい加減ですが．．． 参考すべき、本やＨＰなどありましたら御教え下さい。 個人的には、過去に遡り時代背景を考慮した設計技術の変移を 理解すると良さそうな感じがしますが、時間が掛かりそうで．．． ＾＾； | ||||||||||||
|
投稿日時: 2004-02-12 12:58
いろいろな考え方がありますが、わかりやすく簡潔に伝える
というのも設計技術の一つです。求めている回答とは方向がずれていますが、 大切な考えかただと思います。そのためにツールがあるというのもいいすぎではないです。 ＵＭＬとかＥＲＤとか ではわかりやすく伝えるにはということでこちらのサイトを参考にしてはどうでしょう？ http://www.ideacraft.jp/index.html [ メッセージ編集済み 編集者: 七味唐辛子 編集日時 2004-02-12 13:06 ] | ||||||||||||
|
投稿日時: 2004-02-12 13:22
私もそう思います。 設計書そのものの良し悪しというより、最近ある設計ツールとか、UML等もそうですが 私には、「設計しやすくするもの」ではなく、「実装しやすくするもの」に思えて しかたがありません。（ある面理解はできるのですが） やっぱり、設計の極意というか根幹は「考える」ところにあると思うのですよね。 いろいろなアイデアや方式等をあれこれと試行錯誤するという行為の部分が。 その結果として設計書というドキュメントで表現するものだと思うのです。ですから 形式とか実装に振り回されて、この試行錯誤部分に手抜きが発生してしまうような ことはできるだけ避けたいところです。（もちろんUMLとて自分のものになってしまえ ばここにも力が注げるのでしょうけどね。） 本来、設計書そのものはサブシステムや処理等の区切りさえはっきりとしていれば、 無いように関しては日本語の文章でダラダラと書いても良いと思うのですが、読む 方からすれば人目でわかるほうが好まれるのも確かですね。 まぁ、あまり形にとらわれずに「考える」部分を重要視して、基準書の内容はとり あえずルールとして作成し、細かい部分は添付資料とか補足資料とかにわかりやす い形でまとめるという形でよろしいかと。 | ||||||||||||
|
投稿日時: 2004-02-12 13:45
ここなんかどうでしょうか。
http://www2u.biglobe.ne.jp/~kurapy/index.html 論理的思考についてや、相手に伝わりやすい文書の書き方などが載っています。 私個人は、まだインターネットの普及していないころに設計をはじめて、 教えてくれる先輩もおらず、自己流でここまできてしまいました。 今は当時とくらべて、インターネットもあるし、書籍も増えてきたので 何がいいのかを模索しつつ、あらためて勉強中です。 おたがいがんばりましょう。 | ||||||||||||
|
投稿日時: 2004-02-13 19:51
七味唐辛子さん
Beatleさん かずどんさん 返答ありがとうございます。 はにまるです。 皆様の意見を読み 設計については「考える事」、「表現する事」が重要である事を再認識しました。 「考える事」、「表現する事」は、重要だろうな．．のレベルで設計をしていましたが、 より意識を上げて、設計に取り組もうと思います。 また、設計業務から離れると設計行為をしなくなると思っていましたが、 設計が「考える事」、「表現する事」であれば、 管理者でもプロジェクトを「考え」、関係者全員に「表現」し、 コンサルタントでも、問題の解決手段や改善の手段を「考え」、その手順を「表現」する つまり、私は一生、何らかの形で設計という行為を行うのであり、 常に設計能力を上げる必要がある事を痛感致しました。 「考える」より「考え続ける」ですね！ また、ツール経由で設計技術を取得する事に懐疑的でしたが、 ツールを単に利用する事によって設計技術のサービスを受けるでは無く、 ツールから設計技術を盗み取る位の貪欲な見方や技術習得が欠けていた 事を自分自身に感じました。 まだ、お教え頂いた参照ＨＰを全て見ておりませんが、勉強させていただきます。 ありがとうございます。 結構、堅苦い文書になりましたが、 それだけの「気付き」があった事を表現したくてこうなりました。 ＾＾ 本当にありがとうございます。 | ||||||||||||
|
投稿日時: 2004-02-13 23:04
浅海智晴さんの著書である「UML & Java」は、分析->設計->実装の一連の流れを解説しているのでお勧めです。
また、分析の中心となるであろうユースケース分析についてはコーバーン氏の著書である［ユースケース実践ガイド」がお勧めです。 たしか、Martin Fowler氏も自身のblikiで薦めてた気がする。 | ||||||||||||
|
投稿日時: 2004-02-15 13:23
M. Fowlerといえば、むかし「architectといえば、建築の世界では建物の完成予想図に噴水とか小鳥を書き込むだけが仕事の能無しどもを指す」「ソフトウェア開発でarchitectなんて本当に必要なのか」なんて事言ってたなあ。
そうじゃないarchitectが増えればいいですね。 | ||||||||||||
|
投稿日時: 2004-02-20 10:22
はにまるです。
実務では、「分析と設計」の溝、「設計と実装」の溝に悩みますので、 参考にさせて頂きます。 # ただ、javaは簡易な命令文しか読めない（書けない）．．．
実話です。 上司：「要求定義（分析）が終わっているから、基本設計から参入して」 私 ：「了解！で？業務分析の資料は、どこですか？」 上司：「はい、議事録」 私 ：（ヒヤリングしただけかよ．．要件定義も大丈夫か？．．．） と言う事が多いので、利用させて頂きます。
またまた、実話です。 先輩：「はい、基本設計書、後宜しく」 私 ：「ん？画面設計だけ？この項目データはシステムに存在しないですよ？」 先輩：「そこも、含めて考えてよ！」 私 ：（要件定義から調査する私．．．） 私 ：「このデータを保持する外部システムもありません。」 先輩：「じゃ〜、そこの機能追加して」 私 ：「要件定義では、その機能は保持しないと記述しているのですが．． 追加するなら、サブシステムを追加のと同じインパクトのある問題ですよ？」 先輩：「じゃ〜、こっちの設計書を先にやって！」 私 ：（見た目ばっかり設計しやがって．．．） | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.