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

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

«前のページへ 1|2|3|4|5 次のページへ»
投稿者投稿内容
こくぼ
大ベテラン
会議室デビュー日: 2003/08/11
投稿数: 229
お住まい・勤務地: 国境の南、太陽の西。
投稿日時: 2004-03-14 03:03
こんにちは。

＃素人のたわ言なのであまり深く考える必要はないと思いますが
＃ストレッチ感覚で読んでいただければ幸いです。
＃(というかがるがるさんとの話し合いとダブってしまうのですが^^;

設計技術というと何かしっかりとしたモノを作らないといけないように
感じてしまうのですが、
そもそもシステム設計者という人は誰のために存在していて、
誰に対してどのような結果を出すことを期待されているのでしょうか？

開発プロジェクトという組織の中で設計者である自分が
　・どのような位置づけにあるのか？
　・自分と関わる人にとって自分はどのような存在なのか？
　　(どのような役割を持っているのだろうか？)
　・自分と関わる人に対して自分は結果を出せているのだろうか？
　・自分が取り扱う情報すべてに対して、責任を負う覚悟があるだろうか？
　　(それだけの心意気で自分は情報を扱っているだろうか？)
　・やりとりする情報に対して、コミュニケーションの取り方に関して
　　何か改善すべき点はないか？
　・これらに対して特定の技術でどのようなカバーがはかれるだろうか？

(これはもちろんバランスの問題になってしまいますが)
学問としての技術ならその純粋性(正確な方法、正確な結果、妥協なき姿勢)
が大事だと思いますが、ビジネスとしての技術ならば
自分と関わりのある誰かに対して結果を出す(もちろんそれら全員に対して)
ことを最重要視するという考え方が大前提として
あってもいいんじゃないかと思います。

勉強をするときは、自分はいま学問としての知識を学んでいるのか
ビジネスに活かすために学んでいるのかを意識するやり方も良いのかなと
さいきん思い始めました。


学問とビジネスというふうに２つに分けた考えをすることが
正しいことなのかどうかわかりませんが、
実際にソフトウェア開発の業務に携わっている方の意見として
率直な意見を聞かせていただければ嬉しいです。


---------ちょっと話変わりますが

自分が昨年の秋の国家試験に情報セキュリティアドミニストレータを受けたときに
情報セキュリティの大前提として、
『企業が目指す極限はどこにあるのか？(企業は何のために存在するのか？)』
ということがあると書いてある情報を読んで
セキュリティってこんなところから始まるんだ〜と、
関心してしまったことがありましてそれでこのようなことを考えてしまいました。

＃あ〜いつものように抽象的でおかしな理想論を言ってる。。。(+_+)
＃自分が素晴らしい結果を出してるわけでもないのにー。


追記：
こんなことを考えてる時点で自分はまだまだ学問の人間なんだな、と感じました。
f(^^;


[ メッセージ編集済み 編集者: こくぼ 編集日時 2004-03-14 03:30 ]
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2004-03-14 10:10
unibon です。こんにちわ。

引用:

こくぼさんの書き込み (2004-03-14 03:03) より:
(これはもちろんバランスの問題になってしまいますが)
学問としての技術ならその純粋性(正確な方法、正確な結果、妥協なき姿勢)
が大事だと思いますが、ビジネスとしての技術ならば
自分と関わりのある誰かに対して結果を出す(もちろんそれら全員に対して)
ことを最重要視するという考え方が大前提として
あってもいいんじゃないかと思います。

学問とビジネスが、それぞれ設計とプロジェクトマネージメントに対応するのかな、と感じました。
理想的な善いものを作ることを究めるならば、それを目指して設計に没頭すべきでしょう。しかしそれではビジネスとしては成功できません。かといって、関わる人すべてに迎合していては、システムは一貫性や主張がない無難なものしかできません。
関わる人というのが実際にその出来上がったシステムを使う人(か、その人を管理する人)ならばまだ救われますが、たんに口を出すだけでシステムができた後はそれっきり関わることがないような人だと報われません。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-03-14 12:15
はにまるです。

　まだ、思考中ですが議論し、再考した方がより良い答えが
　出ると思い返答いたします。

　まず、前半文書の所感です。、
　「学生で、何故ここまで考えれるのか？」不思議です。

引用:

自分と関わりのある誰かに対して結果を出す(もちろんそれら全員に対して)
ことを最重要視するという考え方が大前提として
あってもいいんじゃないかと思います。

今、私にとっての一重要課題です。

商売を考えた場合、利害関係者をどこまで考えるか重要なポイントですが、
本当に数年前は、「メンバー、上司」がお客様で済みました。
それから一気に、「自社の売上先→売上先の売上先／仕入先→自社の仕入先→社会」と
ここ僅か数年で、お客様の定義が広がっていると思います。

プロジェクト管理では「スコープ管理」のカテゴリーで扱われる個所ですが、
ただ、これがプロジェクト管理書に記述されているとしても、
一個人として「どこまで考え、行動すべきか」非常に悩ましい所です。
（今は、許容範囲内で考えている状態です。つ、疲れる。　＾＾；）

引用:

学問とビジネスというふうに２つに分けた考えをすることが
正しいことなのかどうかわかりませんが、
実際にソフトウェア開発の業務に携わっている方の意見として
率直な意見を聞かせていただければ嬉しいです。

「学問」と「ビジネス」をオブジェクト指向で考えた場合、
「利用する、利用される」、「含む、含まれる」、「親、子」等、
すべての関連図が書けると思います。

じゃー「一緒でいいじゃん！」となるのですが、
ただ、このままだと手も足も出ない状態になる為、
「学問」と「ビジネス」を、自分達の状況によって都合よく
その関係を組替える（つまり別ける）必要があると思います。

最初は、「利用する、利用される」の関係と思います。
そして、「学問」と「ビジネス」のクラスが確りと整った個所については
一つ複合クラスとして処理出来る状態になるのでは無いでしょうか。
その複合クラスに新たな「学問」や「ビジネス」を含めたり、親子関係を持たせる。
その繰り返しと思います。
そして、複雑になって、再構築かな？

好きな言葉で言えば、道を極める際に出てくる「守破離」の考えと思います。
# 猪木さんを思い出した．．．

まとめた方が良いと考えている個所があれば、
その個所は、そろそろ「破」のタイミングかもしれません。

既存の考えを変えよう（「破」）と一歩踏み込めば、
また基本（「守」）に戻ると思います。（これは体験談）
# 「離」は遠い．．．１・２・３・ダーのダーまでいけない。

# あれ、おいらも抽象的だ　
こくぼ
大ベテラン
会議室デビュー日: 2003/08/11
投稿数: 229
お住まい・勤務地: 国境の南、太陽の西。
投稿日時: 2004-03-15 13:41
unibonさん、こんにちは。


引用:

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

学問とビジネスが、それぞれ設計とプロジェクトマネージメントに対応するのかな、と感じました。
理想的な善いものを作ることを究めるならば、それを目指して設計に没頭すべきでしょう。しかしそれではビジネスとしては成功できません。かといって、関わる人すべてに迎合していては、システムは一貫性や主張がない無難なものしかできません。


ぼくが考えているのは、システム開発に関わる利害関係者すべてに
ビジネス上の利益をもたらす(結果を残す)ことを
(ビジネス面での)技術習得では基礎というか、大前提に考えるべきだということです。

迎合というニュアンスとは微妙に異なるかもしれませんf(^^;)
クライアントの迎合するべきところとすべきでないところをはっきりと見極めて
相手に利益をもたらすことができるのがＳＥだと仕事の一つだと
ぼくは勝手に思っているんですけどどうなんでしょう(^^;;)

引用:

関わる人というのが実際にその出来上がったシステムを使う人(か、その人を管理する人)ならばまだ救われますが、たんに口を出すだけでシステムができた後はそれっきり関わることがないような人だと報われません。


そういう人もいるんですか。。。それは困りますね。
むむむ。
こくぼ
大ベテラン
会議室デビュー日: 2003/08/11
投稿数: 229
お住まい・勤務地: 国境の南、太陽の西。
投稿日時: 2004-03-15 14:08
はにまるさん、こんにちは。

引用:

はにまるさんの書き込み (2004-03-14 12:15) より:

　「学生で、何故ここまで考えれるのか？」不思議です。



素人の直感ですからあまり気にされない方が良いですよf(^^;)

引用:

商売を考えた場合、利害関係者をどこまで考えるか重要なポイントですが、
本当に数年前は、「メンバー、上司」がお客様で済みました。
それから一気に、「自社の売上先→売上先の売上先／仕入先→自社の仕入先→社会」と
ここ僅か数年で、お客様の定義が広がっていると思います。

プロジェクト管理では「スコープ管理」のカテゴリーで扱われる個所ですが、
ただ、これがプロジェクト管理書に記述されているとしても、
一個人として「どこまで考え、行動すべきか」非常に悩ましい所です。
（今は、許容範囲内で考えている状態です。つ、疲れる。　＾＾；）



どこまでが関係者かという明確な定義を仕出したらキリがないと思うので
「心がけ」として持っておく。という方が現実的かもしれません。
(だからといって、もちろん何かあったときは責任をすべて負う覚悟で。)

引用:

「学問」と「ビジネス」をオブジェクト指向で考えた場合、
「利用する、利用される」、「含む、含まれる」、「親、子」等、
すべての関連図が書けると思います。
...省略


ちょっとばかり書いてある内容が難しく感じてしまいましたm(_ _)m
ぼくの場合は、

「とりあえず、技術は学問のための技術とビジネスのための技術があるんだぞ。
　学習するときは自分が今どちらの技術の学習をしているのかをハッキリ
　意識しておこう。後は自分の潜在意識にお任せ。。。」

というなんともアバウトな考えです。


＃ぼくから見ればはにまるさんのように仕事をしながらも
＃向上心を持ち続けれる方の方がよっぽど凄いと思いますけど。。。


unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2004-03-15 14:46
unibon です。こんにちわ。

引用:

こくぼさんの書き込み (2004-03-15 13:41) より:
迎合というニュアンスとは微妙に異なるかもしれませんf(^^
クライアントの迎合するべきところとすべきでないところをはっきりと見極めて
相手に利益をもたらすことができるのがＳＥだと仕事の一つだと
ぼくは勝手に思っているんですけどどうなんでしょう(^^;

たしかにおっしゃることはSEの王道だとは思いますが、それは設計技術からは離れてしまいます。たとえば、

引用:

はにまるさんの書き込み (2004-02-20 10:22) より:
またまた、実話です。
先輩：「はい、基本設計書、後宜しく」
私　：「ん？画面設計だけ？この項目データはシステムに存在しないですよ？」
先輩：「そこも、含めて考えてよ！」
私　：（要件定義から調査する私．．．）
私　：「このデータを保持する外部システムもありません。」
先輩：「じゃ〜、そこの機能追加して」
私　：「要件定義では、その機能は保持しないと記述しているのですが．．
　　　　追加するなら、サブシステムを追加のと同じインパクトのある問題ですよ？」
先輩：「じゃ〜、こっちの設計書を先にやって！」
私　：（見た目ばっかり設計しやがって．．．）

の「先輩」になってしまうのではないかと思うのです。
＃これは極端な例でしょうけど。
こくぼ
大ベテラン
会議室デビュー日: 2003/08/11
投稿数: 229
お住まい・勤務地: 国境の南、太陽の西。
投稿日時: 2004-03-16 09:22
unibonさん、こんにちは。こくぼです。

返信ありがとうございます。
興味深い内容なのでお時間よろしければお聞かせください。

引用:

こくぼさんの書き込み (2004-03-15 13:41) より:
迎合というニュアンスとは微妙に異なるかもしれませんf(^^
クライアントの迎合するべきところとすべきでないところをはっきりと見極めて
相手に利益をもたらすことができるのがＳＥだと仕事の一つだと
ぼくは勝手に思っているんですけどどうなんでしょう(^^;


ということがどのようにして

引用:

はにまるさんの書き込み (2004-02-20 10:22) より:
またまた、実話です。
先輩：「はい、基本設計書、後宜しく」
私　：「ん？画面設計だけ？この項目データはシステムに存在しないですよ？」
先輩：「そこも、含めて考えてよ！」
私　：（要件定義から調査する私．．．）
私　：「このデータを保持する外部システムもありません。」
先輩：「じゃ〜、そこの機能追加して」
私　：「要件定義では、その機能は保持しないと記述しているのですが．．
　　　　追加するなら、サブシステムを追加のと同じインパクトのある問題ですよ？」
先輩：「じゃ〜、こっちの設計書を先にやって！」
私　：（見た目ばっかり設計しやがって．．．）


の先輩に繋がってゆくのでしょうか？
結果重視の設計にこだわってしまって技術からは遠のいてしまう、
ということなのでしょうか？


------自分の意見を補足

ぼくが言いたいのはなんでもかんでも結果を出せばよいというものではなくて
技術を学ぶときの大前提として、
ビジネスとして活かす(結果を残す)ことを意識して学ぶ必要がある。
ということです。
(設計技術に関わらずに技術全般の話になってしまいますが)
(そして、そうやって学んだものとしては、しっかりと結果として残していくべき)
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2004-03-16 23:17
unibon です。こんにちわ。

引用:

こくぼさんの書き込み (2004-03-16 09:22) より:
結果重視の設計にこだわってしまって技術からは遠のいてしまう、
ということなのでしょうか？

はい。そうです。
もとの、はにまるさんのご質問中にある(スレッドのタイトルにもある)、「設計技術」には、プロジェクトマネージメントの結果やそれに至る過程は含まないと思うからです。
＃いわゆるスレタイから外れるからダメとか、そういう意図ではないです。

もちろん、結果は大事ですが、結果は結果でしかありません。と書くと、なんのこっちゃ良く分からなくなりますが、ようは「設計技術」を磨くことは結果のためのひとつの手段でしかないです。
«前のページへ 1|2|3|4|5 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）