@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

設計技術の基礎、基本を勉強し直したい...

投稿者投稿内容
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-03-17 15:26
はにまるです。

 建築設計の話が出たので。
 (って、建築設計の「け」の字も知らずに勝手に記述していますよ〜ん)

 昔は、設計と言えば、
  「木材で家を作ると火に弱く、強度が低いですが、室内の湿度を一定に保ちます。」
  「これだけ広い部屋を作るには、中心に柱が無いと強度が保てません。」
 など、家の概念が皆一緒だった為、専門的なお話をすれば良かったと思います。
 (職人スタイルで習えるレベルの設計技術のお話ですね)

 ところが、小さな土地や、家の概念が変り、
  「窓が多い家にしてって言ったけど、冬は暖房費が掛るじゃ無い!」
  「こんな駐車場では、運転の下手な嫁では無理だよ!」
 等、家の目的に対する要望が増えてきました。
 (業務要件あたりですかね...)

 そして極めつけ
  「売る時に高く売れるような家にしてよ...」
  「年取った時の事、考えて欲しかったな...バリアフリーって知らないの?」
 等、要望の視点が多様化しています。
 (情報化戦略あたりですかね...)

 御客と接する設計者は、このレベルの話を全て一人で対応する事が
 日常茶飯事では無いでしょうか?

 「設計て何?」、「私は何?私は神じゃ無いのよ!」と言いたい所ですが、

 でも、自分達が家を建てるなら、確かにこのレベルの注文を
 一人の建築設計者に言うんでしょうね。

 あ!一戸建ての家を買うお金が無かった!(爆

シ、、システム設計者に愛を...
愛より金かな?
Beatle
ぬし
会議室デビュー日: 2003/06/09
投稿数: 394
投稿日時: 2004-03-17 15:30
引用:


 現状では、そのケースバイケースの部分が多すぎて、設計技術などというものは
実務の中で身に付けていくしかないのではと考えました。
まさか、学問として、いろいろなパターンを想定して勉強するのはおそろしく効率が
悪いですよね?




個人的な意見ですが、「設計」(設計書のほうが良いかも)というものの位置付けは
実行モジュールに対するソースコードのようなもので、システムの実体が実行モジュール
設計書がソースコードのような位置付けで考えてます。

で、「設計技術」そのものを学術的に定義するのは難しいと思いますが、最初のほうで
議論されていた「設計の目的」という面では学術的な面もあります。
例えば、設計の目的というのを、
・自分自身の考えを整理、まとめるもの
・開発プロジェクト関係者への伝達の為
・お客様への伝達の為
・未来の改造、置換え等の技術者への伝達の為
というような目的を考えると、1つめではシステムや処理を構築する為の技術であったり
考え方の整理学であったりします。2つめ以降のように第3者への伝達という意味では
人に解りやすい設計書の書き方、図、文章の書き方等というように細かい分類のものが
寄せ集まっているものと考えると学術論として語れない訳ではないでしょうね。
(もちろんベースにはITのテクニカル技術という面もありますが)
この中で、UML等の設計手法に関しては、ひとつの答えまたは例ということになるのか
なぁと。つまり設計技術そのものではなくて、表現方法のひとつという感じですかね。
ラフィン
ぬし
会議室デビュー日: 2002/05/23
投稿数: 809
お住まい・勤務地: 外野
投稿日時: 2004-03-17 15:33
引用:

りばぁさんの書き込み (2004-03-17 13:54) より:
社会人1年目で、いきなりSEを名乗って設計の仕事をやらされることはありませんよね?
通常、下積みとしてプログラマーを経験しつつ、徐々に設計にも参加する事になると思います。

なぜそうなのかといえば、いろいろなプログラムを作っていく過程で、設計技術の基礎を
身に付けていくものだからではないでしょうか?



 センスがよければ1年目でもSEやらせてますよ。
 期待通り伸びてくれれば2年目ではPLやらせられます。
 3年目には営業サポートでしょうか...

 「プログラムを作っていく過程で、設計技術の基礎...」はその通りだと思います。ただ、逆も真なりではないのではないかと思います。つまり優秀なプログラマの下積みとして設計だの営業だのを一通り経験しておくのもよいということです。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷        良回答(20pt)
投稿日時: 2004-03-17 19:28
unibon です。こんにちわ。

引用:

はにまるさんの書き込み (2004-03-17 13:33) より:
この枠を打破したかった。それには基礎を勉強する。つまり、
こくぼさんの仰る「学問」に戻る必要性を感じたのですが、戻り方が解らなかった。


この学問は「アプリケーションエンジニア」の範疇ではないでしょうか。情報処理技術者試験の試験区分にもありますよね。あるいは「アプリケーション開発」や「システム開発」(システムはちょっと外れるかも)でしょうか。題名にこれらの言葉が付く書籍を探されてはどうでしょうか。システム設計とか、はたまたシステムエンジニアにいたっては、遠い彼方でしょう。
ちなみにいまどき「アプリケーション」って言っても、ちょっと高尚さが感じられない言葉ですね。でも設計が必要なソフトウェアの多くはアプリケーションのはずです。
七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2004-03-18 10:21
引用:

unibonさんの書き込み (2004-03-17 19:28) より:
unibon です。こんにちわ。

引用:

はにまるさんの書き込み (2004-03-17 13:33) より:
この枠を打破したかった。それには基礎を勉強する。つまり、
こくぼさんの仰る「学問」に戻る必要性を感じたのですが、戻り方が解らなかった。


この学問は「アプリケーションエンジニア」の範疇ではないでしょうか。情報処理技術者試験の試験区分にもありますよね。あるいは「アプリケーション開発」や「システム開発」(システムはちょっと外れるかも)でしょうか。題名にこれらの言葉が付く書籍を探されてはどうでしょうか。システム設計とか、はたまたシステムエンジニアにいたっては、遠い彼方でしょう。
ちなみにいまどき「アプリケーション」って言っても、ちょっと高尚さが感じられない言葉ですね。でも設計が必要なソフトウェアの多くはアプリケーションのはずです。



そういったことがいいたかったのか初めてわかったような気がする。

あるいはソフトウェア開発技術者試験ですね。でも個人的にいわせてもらえるとこれらの
試験範囲の要素をしらずにいままでやってきたのかな?と考えてしまいます。
そうだとすれば設計技術の基礎を学びたいという気持ちもよくわかる。もちろん仮定の話ですが


はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-03-18 11:29
設計技術に求めている事は、「こんな感じです.」と言う事で
私が書き留めている設計概論を提示します。

下記内容は、業務設計をする者であれば、基礎的な設計技術レベルと思いますが、
実際にはxxxxxって感じですよね。(xxxxは、貴方にお任せ!)

しかし、私自信がどれだけ解ってんの?と思います。
別の設計技術を求めるべきか...むむむむって感じです。

-- 設計概論 --------------------------
ここでいうシステムはコンピュータのみで無く、
「仕事の手順」や「組織」も含めます。


1.集計処理について

  「A情報→(集計)→B集計」の流れを持つ場合、
  「AとBの整合性」が重要となります。

  この様な場合、一般的に(集計)の規約に従いAに対し制限を掛けます。

  これとは別の話で、情報の信憑性を確保する為、
  Bとは別のルートで発生したC情報を用いて
  B情報とC情報をマッチングし「A情報」、「(集計)」、「B情報」が
  正しい事を証明する行為が一般的に発生します。
  この際にB情報とC情報が不一致する事があります。

  不一致の理由がAの間違であれば、
  Aに対する制約を解除し、Aを訂正し「再集計」が出来る機能が必要となります。
  ただ、時間経過の問題でAやBを訂正出来ない場合、
  A情報に対する別集計が存在する場合、単純再集計を取れない場合があります。
  この際は、
  次回の(集計)処理で処理するか
  差分のみをB’情報として集計する必要があります。

  AとBの整合性を無くすと、コンピュータ・システム仕様では楽になりますが、
  Bの信憑性はシステム上弱くなり、また「A情報」、「(集計)」の信憑性も弱まり、
  システムの品質基準を保持できない場合があります。


2.情報の時系列について

  マスタは特定期間の情報を保持します。これにより、

  1.実社会で状態変化が起きたタイミングと同一タイミングで
    コンピュータ・システムに状態変更を指示する必要がある。

  2.過去のトランザクションを参照した場合、マスタが現時点の状態で
    不整合や誤った情報になる。

  この状態では利便性が悪く、危険性であり、なにより
  時間を追う毎にコンピュータ・システム内部のデータが不整合を起し信憑性を損ないます。

  これを回避する為、
  1の対策として「マスタの更新予約」、
  1と2の対策として「マスタの履歴(世代)管理」
  があります。
           :
         (以下省略)

スキルアップ/キャリアアップ(JOB@IT)