＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
設計技術の基礎、基本を勉強し直したい．．．
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-02-20 12:03
どもも。がるです。
んと。参考になるサイトなどは色々と書かれているので、ちょいと 違う方向から。 一つ質問をします。 「設計は何のために、誰に見せるためにするんですか？」 独立した作業ってのは絶対に存在しないと思いますし、また対象のいない 作業ってのも存在しないと思います。 設計なんてめんどくさいものをやらずに、いきなりプログラムを組んでも 別に「法律違反で逮捕」されるわけでも「反逆罪に問われる」わけでも ないです :-P ただ、いきなりプログラムを組むと、多分飛んだ意識が宇宙の端っこまで 到達して帰ってこれなくなるくらいに色々な問題が発生することが 予想されるわけでして。 「だから」設計をするんだと思います。 だとすると。 「設計をしないときの問題点」ってのはなんでしょう？ この辺から色々考察を重ねていくと、設計というフェーズに必要なもの が見えてくるのではないだろうか、と考えてます。 「設計すること」を前提にするのではなく、「設計をしないこと」を 前提に考えてみるのもまた面白いかなぁ、と軽く戯言をいってみつつ。 | ||||||||||||
|
投稿日時: 2004-02-20 12:27
またまた「楽しい御題」をありがとうございます。 
最近、徒歩や自転車に乗っている時、暇なので＠ＩＴで議論されている御題を 考えています。（ブツクサ言いながら） # これが結構楽しいし、気付くと目的地に到着！ この週末に考えてみます。 # 今、考えたら設計が正しくされていない事による # 被害の不満ばかりが出てきました ＾＾； 追記： 先週、「お前、話の進め方が良くなったな」と言われました。 ＠ＩＴでの議論の効果が出始めた？ | ||||||||||||
|
投稿日時: 2004-02-20 19:38
はにまるです。
この質問を見逃していました．．． １．自分の為、考えをまとめて漏れを発見する。 →考えた事をどんどん記述して考えを紙面でマトメています。 ２．設計依頼者の為、目的や要求に対する対処手段を提示します。 →１の内容の内、表面的な部分と、技術的問題点の対策箇所を抜粋し 説明順序事に資料を並べ替え、ストーリーを作成します。 この時、ストーリーの構成上で抜けている資料を追加します。 ３．関連設計者の為、私が担当しているシステム構成の予定を提示します。 →２の内容から、関連設計者に関係する部分のみを抜粋。 ４．実装担当者の為、作りたいシステムを提示します。 →んんん．．ここはどうすれば良いんだ？ より詳細に記述するは、違うな．．． こう記述して見ると、設計手順の考えが１つ増えました！ ただ、「実装担当者の為」の行為がピント来ません．．． ここが私の設計時の弱点でしょうか．．． # そこも宿題．．． | ||||||||||||
|
投稿日時: 2004-02-23 12:05
どもも。がるでございます。
んと、はにまるさんが書かれたものを軽く私なりにまとめつつ コメントなどを。 1.自分の為、考えをまとめて漏れを発見する。 意味合いとしては「整理と覚書」って感じのものですね。 自分は、よく他の書面を書く上でのベースにこれを使ってます。 覚書は、適当な作業ディレクトリに、ファイルが山のように出来上がり 色々とメモが書き込まれています。 整理しておかないと後で大変なのですが(笑 ファイルなので、簡単に時系列に並べることが出来るのが便利です。 2.設計依頼者の為、目的や要求に対する対処手段を提示します。 営業さん経由で渡すときに一番重要になるヤツですね。 私はこれを「対外向け」とよく呼んでますが。 対外向けはまさに「素人さん」が読むものなので、使う言葉の 端々まで気にするようにしています。 「読む人間の予想されうる一番低いレベル」を読み手として常に 想定して作りこみを行うと安全です :-P 自分がよくやるのは ・一番初めに「言葉の定義」を行う 特に「先方の業務用語」は、あらかじめしっかりと確認。 「語外のニュアンス」とかいう怖い発言を認めさせない :-P ・正常系だけを一回まとめて、異常系は別紙や後ろに回す 特におエライさんは異常系までまとめてみせると本人の 処理がオーバフローします :-P ・画像を多用する これが苦手なのですが(苦笑 本当は、こういうときのために「ある程度DTPとか画像処理とかが うまい人」を確保しておくと楽です。 3.関連設計者の為、私が担当しているシステム構成の予定を提示します。 基本的には「対外向け」の各章立てを分解して技術的な補足をかける、 って感じで扱ってます。 対外向けの冊子を渡しつつ「記述部分はメモ参照」っていう手抜きも :-P 技術者向けなので、この部分は実はたたき台程度にしかならず、 後々のメールのやり取りとかのほうが重要だったりもします。 4.実装担当者の為、作りたいシステムを提示します。 究極の手抜きとしては「関連設計者に作らせる」という手段も(笑 おいといて、と。 この部分は、自分の経験的には「会社＆実装担当者の実力によって 様々」ですね。 設計者向けとほとんど変わらないものを渡して「プログラム設計は まかせるし」っていうスタンスのものから、クラス設計、関数設計 までを詳細に書いて「この通りにコーディングして」っていう ものまで。 なにせ実装担当って「SEクラスの設計スキルがある」人から 「自分で関数切り分けすら出来ない」人まで幅が広すぎるので。 まずはその辺を見抜いてから、っていう気がするです。
ちょろっとだけ、私なりの見解を書いてみました。 # どこが「ちょろっと」な文量なのだか(笑 | ||||||||||||
|
投稿日時: 2004-02-23 20:44
はにまるです。
「まとめ」以上の品質で書き上げて頂き、ありがとうございます。 ＠ＩＴ記事と同一以上の情報を受け取りました。
ふと思ったのです。 私にとって、４ステップの中で最も得意とする個所が何故書けないのか．．． 本来、「人間が協力し合って作業する事は、非常に難しい事」であり、 実装者（開発者）と作業をする場合、作業が厳密化されている為、その難しさが解っている。 お客様（ステップ２）や関連設計者（ステップ３）とは表面的な所でのみ協力し合っている為、 簡単に記述出来てしまう．．． と考えてみました。 | ||||||||||||
|
投稿日時: 2004-02-23 21:17
はにまるです。
考えて見ると、個人的に面白い結果になりました！
結論は、 １．「設計」無しでは開発は出来ない。 ２．「設計書」を記述しない場合、オブジェクト指向になる。 １の理由は、 実装者の立場でも、「設計」はするからです。 このループの終了条件は、前に配置しよう！ この変数は、構造体にしよう！ 等、これは広い意味で「設計」行為と言えます。 つまり実装者に設計をさせない設計書を書くと、 変換プログラムでプログラムが出来ちゃう！＝実装者不要となります。 # オブジェクト指向技術で開発していると、設計と実装の境目がより一層 # あやふやに成りそうですね．．．（私はオブジェクト指向開発未経験者） ２の理由は、 設計書を記述しない場合を考えたのですが、 何とこれが効率的な開発のアイディアを生み出す行為になります！ 言われた物を直ぐに作る。（部品化） 変更を容易にする。（部品を疎結合させる） シュミレーションを可能とさせる。（トレース機能、システム単位でのロールバック） 見えない物を見せる。（データ、トレース情報のビジュアル化） 等、設計書を記述しなくても開発出来る手段を考えて行くと色々と アイディアが出てきました。特に設計書を記述しない為、構成単位を機能単位にし 解り易くしようと考える為、その行為がオブジェクト指向になるのです！ 皆様も一度は「お客様と話ながらＧＵＩにより目の前でシステムが出来たらな．．」って 考えた事があっても、多分、夢物語としてとらえ、それをどうしたら出来るか真面目に 考える所まで至って無いと思います。 # 馬鹿な考えも面白いと思いました。 まだ、考え途中ですが面白い一面が見えたので途中報告です。 ＾＾ [ メッセージ編集済み 編集者: はにまる 編集日時 2004-02-23 21:18 ] | ||||||||||||
|
投稿日時: 2004-02-27 15:19
規模にもよりますが、可能だと思いますが、delphiとかＶＢ？がまさしくそれに当たる ツールだと思いますが、今は死語かもしれませんが Rapid Application Development ＲＡＤツールとかいわれてましたからね。 | ||||||||||||
|
投稿日時: 2004-03-01 15:04
はにまるです。
過去、幾度無くＶＢで兆戦しましたが全て玉砕しました。
生産効率が各段と上がるレベルまでは行くのですが、 理想を完璧に実現しようとし理想に近づくと、その壁の高さに挫折します。 ここで勝手に、オートメーション化収穫逓減の法則と名付させて頂きますが、 「オートメーション化のレベル」と「工数と知恵」の関係をグラフで表すと、 きっと反比例すると思います。 目先のオートメーション化は楽に出来るのですが、レベルを上げれば上げる程、 次の一手に必要とする工数と知恵が枯渇し、挫折です。。。 # 実は、、、オブジェクト指向言語で再度兆戦するつもりです．．． # その時、そんな暇あるのかな？．．．
説明：収穫逓減の法則 →投資をして利益を得る際、投資を増やせば「利益額は増える」が「利益率が下がる」事。 # 編集 オブジェクト「思考」になっていたので訂正 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-15 13:54 ] | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.