5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

要件定義良い本あったら教えて

1 ::2001/07/04(水) 12:41
要件定義が難しいです〜。
いい本やURLやツールなどありましたら教えてください。
また、どの程度きっちりやっていますか? きっちりできるものですか?
きっちりできる場合は、どうやればできますか? など議論きぼーん。

2 :おいらも質問:2001/07/04(水) 13:45
DOA(データ指向アプローチ)って、IBMは力いれてるらしいけど他社ではどうなんですかね?
個人的には、注目してるんですけど。

3 :FJ:2001/07/04(水) 14:19
要件定義ってほんと難しいよね。
俺は他プロジェクトの要件定義書を集めて勉強してる。
簡潔で分かり易かったり、ごちゃごちゃして良く分からなかったりと
結構参考になるよ。

答えになってないね。ごめん。

4 :わたしも質問:2001/07/04(水) 16:37
要件定義が難しいからXPって騒がれてるのかな?

5 :非決定性名無しさん:2001/07/04(水) 16:38
>>2
DOAと要件定義って関係あるの?

6 :おいらも質問:2001/07/04(水) 17:11
企業全体のデータ構造

業務エリア毎のデータ構造

システム構築範囲でのデータ構造の詳細化

業務プロセス分析→プロシージャ−へというのではなく、
業務上の情報構造からのアプローチ

購買・生産・販売・会計・人事
などハイレベルの業務構造とそのデータ構造から、トップダウン的に
落とす事もあるし、あらかじめ対象範囲が決まっているならボトムア
ップアプローチもできるだろうし・・・・・・

7 :FJ:2001/07/04(水) 17:36
満足のいく要件定義書できた試しがないな。
完璧と思っても、プロジェクトが終わって見返すとダセーとか思ったり。
問題なく終わってるんで、事足りてたとは思うけど。

皆さんは、”完璧”な要件定義書作れますか?

8 :非決定性名無しさん:2001/07/04(水) 22:48
>>6
それは、要件定義ではなく、要件分析になるのでは?

9 :PGの方が偉いの決定!:2001/07/04(水) 23:51
けっ、要件定義もろくに出来ないのにSEっていばってるんだな。
PGにえらそうにいうのやめろぼけ。(藁

10 :非決定性名無しさん:2001/07/05(木) 00:26
>>9
交渉力のない高卒or専学卒は黙ってなさい

11 :奈々氏:2001/07/05(木) 00:38
>>9
完璧とは言えないが、コーディング前まで設計したのに
その努力を無駄にするのは、いつもPG。
PGは替えがイッパイいるので、君程度だと首切られるよ。
SEより。

12 :PGの方が偉いの決定!:2001/07/05(木) 01:39
>>10
黙ってなさいと偉そうに抜かすおぬしに、交渉力があるようには思えないが。
黙ってもよいので、おぬしの要件定義の方法を披露してくれ。ろくに仕事
できないくせに。
>>11
ばーか。何で、程度がわかるんだよ。おまえら、ワインバーグの「要求仕様の
探求学」読んだことあるのか? 読んだことあるんなら、さくっと引用して、
1の質問に答えてやれよ。それもできないのに偉そうに抜かすな。ぼーけ。

13 :奈々氏:2001/07/05(木) 02:15
>>12
がんばれPG君、替わりはいくらでもいるぞ(藁
何歳までPGやってるんだ?能力がないだけか?

14 :非決定性名無しさん:2001/07/05(木) 02:21
>>6
それってER分析じゃないの?
要件定義って、ビジネス・プロセスの抽出と新ビジネス・プロセスの取りこみを行うことじゃないの?
もちろん、データ分析はやるけどさ。

15 :非決定性名無しさん:2001/07/05(木) 02:58
>>14 DOAだろ

16 :PGの方が偉いの決定!:2001/07/05(木) 03:20
>>14
本当にわかってないの? よくそれでSEやってるね。(藁

>>13
あんたの変わりもたくさんいそうだね。どうやって要件定義してるのか書いて
みろよ。そしたら認めてあげようではないか!どうせ無理だろうけど。
ベンダー系のSEぐらいしかしっかりとした要件定義ってやってないんじゃ
ないかな。俺はもとベンダー系SEで、つまんないからPGをやっているけど
設計もやってるよ。これからは設計もプログラミングもできるような人材に
ならなければ品質の良いものはつくれやしない。と、思う。
このスレで、まともな回答がでないのが、日本の力のなさの象徴と言えるだろうね。(藁

17 :奈々氏:2001/07/05(木) 04:08
>>16
PG頑張れ。分かったつもりの奴が、システムをおかしくするんだが。
PGいつまでやってられるかね?(藁

18 :非決定性名無しさん:2001/07/05(木) 04:13
>>15
ERWinなどでやるER分析をDOAというなら、広解釈でDOAかもね。

19 :非決定性名無しさん:2001/07/05(木) 05:22
大まかにはこんなもんかな、、、

1)システム化していいものと悪いものとを現状のプロセスから見つける
2)システム化していいものについて、各種手法により要件分析をする
 してはいけないものを分析するのは時間のムダ
3)分析が終わったら、どの程度カネが出そうか考えて、
 あんまりカネのでなさそうな部分は切り捨てる
 カネのでない部分を要件に入れてしまうなんてソン
4)システム化して悪いものは頑強につっぱねる
そんなものをシステム化すると全体像が汚れる
 最悪やらざるを得ないときは、必ず限定条件をつける
5)営業と客にきっちりネゴっておく

20 :非決定性名無しさん:2001/07/05(木) 05:24
分析手法をあれこれする前に、
現状のプロセスが、どういう経緯で作り上げられたか?
を知っておくのもいいだろうね。
うまくいけば、分析手法が見落としてしまう穴に気付いて、
その分のフォローを要件に入れることも可能だろう。

21 :非決定性名無しさん:2001/07/06(金) 01:58
要件定義がまともにできるSEは滅多にいないでしょうね。
だから、泥沼プロジェクトが多いわけです。で、XPに楽を求めて逃げると。

22 :非決定性名無しさん:2001/07/06(金) 10:12
用件定義も含めて、上流工程の殆どはコミュニケーション能力
を持っているかいないかで随分と違うと思います。

23 :非決定性名無しさん:2001/07/06(金) 10:36
やっぱ用件定義って「これだ!!」って言うもんが無いのかぁ。

24 :非決定性名無しさん:2001/07/06(金) 10:40
IBM、富士通、NECなどのベンダーの方からの意見希望!

25 :仕様書無しさん:2001/07/06(金) 10:48
>>1
基本的かも知れんが、結構参考になると思う。
http://village.infoweb.ne.jp/~fwgf2942/process/Proc.Require.html

26 :おいらも質問:2001/07/06(金) 11:36
↓データ総研からのコピぺだけど。。。。

DOAとPOA




コンピュータは、はじめは「業務を機械化」する道具でした。したがって、必要な画面、必要は帳票が定義されると、まずプログラムを設計。それから、プログラムを動かすためにデータが設計されました。

こういったプログラム優先のシステムは、ごく小規模な間は快調に動いたものでしたが、徐々に問題を生み出す温床になってゆきます。

プログラム間でデータの共有が困難。情報流通が疎外。冗長、不整合が発生。
プログラムは、業務の手順を写しとったもの。このため、業務側の変更のインパクトが大きい。メンテが多発。メンテのたびにスパゲッティ化。保守地獄。
これは何かがおかしい。データ総研のコンセプトはここから始まりました。

データは、本来共有しあうべきものではないのか?
手順が変わったのなら、手順だけメンテする方法はないのか?
この問いへの追求が、DOA(データ中心アプローチ)へと結実してゆきます。従来の方式を、POA(プロセス中心アプローチ)としてフォーカスしながら。

DOAのキーワードは「データの共有、データ部品の再利用」です。コンピュータは、情報を共有、活用するための道具なのだ、という発想に立ちます。このため、システムづくりは、はじめに画面帳票が定義されると、まず必要な共用データの設計がはじまります。さいごに、画面帳票とデータをむすぶために、プログラムをRADする。

こういったデータ優先のシステムは、大規模でロングライフな業務で、特にその真価を発揮します。

データは、はじめから、共有資源として存在。それゆえ、情報流通が促進され、冗長性が生じてきた、あらゆるコストを解消。
データは、業務の目的を写し取ったもの。それゆえ、業務側の変更要件のインパクトを最小限にとどめる。一方で、画面/帳票、プログラムはRAD。いわば使い捨てなのでメンテは最小となる
情報処理の時代から、情報流通の時代へ。それゆえ、POAからDOAへ。情報システム構築のパラダイムの移行は、歴史の必然なのです。

27 :おいらも質問:2001/07/06(金) 11:51
例えば、ステァリング・コミッティなんかで「事業部門別業績管理の強化」なんかが経営課題であがったとするでしょ?
それを実施・評価する為の、管理手法、指標(KPI)、管理レポート(P/L構造)なんかが必要となって・・・・・
KPIのデータ収集、P/Lレポートのプリントアウトをシステムでやると決まりました。
ここまでは、「目的展開図」なんかでやるわけね。
で、例えばKPIの1つに「在庫回転率」なんかがあったとしたら、
在庫回転率=在庫金額/月商
とか定義され、それをさらに細かく分析し・・・・・

最終的なアウトプットデータの構造からそれを得る為に必要な情報構造へと落として
いくというのが、DOA(の1つの例としての)イメージなんだけど。。。。
おいらも勉強中なんで、間違ってたらスマソ。
別に従来のプロセス分析を完全否定するわけでもないし、平行して活用できたら効果大かな?
と思ってるんですけど。

28 :非決定性名無しさん:2001/07/06(金) 12:28
>>27
分析は、色々あると思います。分析を始める前の要求仕様をどのように作るか
>>1 は言っているのでは?
現在は、要求仕様作成と要求分析が同時並行的に進んでしまっているような
やり方をしている人が多いのではないでしょうか?
それゆえに、要件定義・整理が曖昧になり、分析も曖昧、設計も曖昧、
そして作られるものは、顧客が望んでいたものとは違ってしまうということが
頻繁に起きているように思います。そして、開発がわは、問題が起きた時に
トラブルを防ぐために、契約を重視する方向にあると思われる。
そういった状況を抜け出すための一つの解として、XPが騒がれてはいるが、
それも複雑なシステムだといたずらに開発期間がずるずると延びることにな
リ兼ねないので、慎重派が多くいると。結局のところ、要求仕様をしっかり
と作れない限りは、抜け出せないのだが、本質的に複雑さを管理するのが
難しいので、みなさん苦労している。

29 :非決定性名無しさん:2001/07/06(金) 18:19
「要求仕様の探求学」 G.M.ワインバーグ著
他に、同じ著者で、
「コンサルタントの秘密」、「スーパーエンジニアへの道」、
「ライトついてますか」
「ザ・ゴール」ゴールドラット著
「ひとを動かす」デール・カネギー
「7つの習慣」フランクリン・コビー


30 :非決定性名無しさん:2001/07/06(金) 18:22
要求仕様の探求学 G.M.ワインバーグ著
ライトついてますか 同著
コンサルタントの秘密 同著
ザ・ゴール ゴールドラット著
7つの習慣 フランクリン・コビー

31 :非決定性名無しさん:2001/07/06(金) 18:31
要求工学の恩恵を得る
Capturing the Benefits of Requirements Engineering
Pete Sawyer, Ian Sommerville, and Stephen Viller

IEEE Software, Vol. 16, No. 2, March/April 1999

Keywords: requirements engineering, software process
improvement model
あまりにもしばしば, ソフトウェア製品は重大な顧客要求を
満たすことができず, 開発者は既存のソフトウェアプロセス
改善 (Software Process Improvement)モデルに助けを求める
. 著者らは, SPIだけでは要求工程を実施あるいは改善するのに
十分ではないことを示す. 彼らは, 標準的なSPIの実施と優れた
要求の慣習に基づいた手法を開発した. これにより, 要求の獲得
と管理を適切に扱うことが確実になる.

32 :非決定性名無しさん:2001/07/06(金) 23:42
DOAから派生した、DORTIAでは、要件定義手法があるみたい。
「3層クライアント/サーバ 要件定義技法」共立出版。

ところで、DOA関係の日本語で話ができるメーリングリストってありますか?

33 :非決定性名無しさん:2001/07/07(土) 05:22
要は宴会の式次第なんだってば。

汎用化できる手法なんて、ホントはどこにもねーよ、この日本じゃな。

34 :非決定性名無しさん:2001/07/07(土) 16:51
>>33
「宴会の式次第」ってどういう意味? タイポ?

35 :非決定性名無しさん:2001/07/07(土) 23:23
>>34
「あってないようなもの」とかそういうことでは?

36 :非決定性名無しさん:2001/07/08(日) 01:27
そうかな〜
DOAで上手く行かなかったプロジェクトは、DOAの概念について行けない人が多かったからでしょ。
DOAプロジェクトでは、支援部隊として、DOA手法Q&A対応担当要員がいたりする。
皆が理解できれば、こんな無駄要らない。

37 :非決定性名無しさん:2001/07/08(日) 21:23
要件定義や基本設計をちゃんとしたって、pgがてきとーなpgmつくってるから
だめなんだyo!
システム業界はほんとに土建やとかわらないよ

38 :非決定性名無しさん:2001/07/08(日) 22:10
>>37
ちゃんとしたこともないくせに。偉そうに。

39 :非決定性名無しさん:2001/07/08(日) 22:31
つうかどのフェーズもちゃんとしてない場合が多いよな

個人のセンスで仕事する人多すぎ
しかもそれを他人に説明できないから関わる人数増えるほど
火吹き率UP

40 :非決定性名無しさん:2001/07/08(日) 23:11
>>39
それぐらい、ソフトウェア工学も要求工学もまともに身に付けていないソフト
技術者や管理者、経営者が多いっていうことなんでしょうね。

41 :非決定性名無しさん:2001/07/08(日) 23:23
>>40
何かおすすめの本あります?
属人的資質で仕事をしている業界だというのは感じています。
自分の為に勉強しなおしたいのですけど。

42 :非決定性名無しさん:2001/07/08(日) 23:32
>>39
>個人のセンスで仕事する人多すぎ

でも、センスが無い奴は、DOAなぞ理解できないし、要件定義も出来ないよ。

43 :40:2001/07/08(日) 23:58
>>41
要求工学は、情報処理学会の会員でなければまずなって、過去の論文を辿るのが
良いです。といっても日本ではそれほど活発ではないので、その後海外の論文を
あさる必要があると思います。
本では、すでに紹介として上がっているワインバーグの本が良いでしょう。
ソフトウェア工学は、焦らず概論から入って、少しずつ学ぶのが良いです。
すでに知っていることでもきっと考えが整理され数年後にはかなり力になって
いるはずです。多分数学も学ぶことになると思います。がんばってください。

44 :41:2001/07/09(月) 22:40
>>40
レスありがとうございます。
ワインバーグの本をとりあえず読んでみようとおもいます。
途中煽りがなければ、良いスレになりそうなんだけど。

45 :非決定性名無しさん:2001/07/10(火) 11:45
要件定義なんて先輩のやり方いっぺん見れば分かるでしょ?

46 :仕様書無しさん:2001/07/10(火) 18:59
>>45
ちゃんとした先輩にあたるとは限らんぞ。

47 :非決定性名無しさん:2001/07/10(火) 20:39
>>45
小さくて単純なシステムばっかり扱ってるんだろうね。自分のやっていることが
全てと思うようじゃ、おばかSE決定だ。(藁

48 :非決定性名無しさん:2001/07/11(水) 08:10
こうして設計できるのは業務仕様だけなんでは・・・?
実装からめないと結局は使い物にならない。

実装に関する工学も欲しいね

49 :45:2001/07/11(水) 23:34
>>47
そんな小さくも無いけど、会社で技法とか書式とか標準化されてるもんで。
まとめ方は、センスというか常識の問題だし、コンピュータの知識も大して
いらないから、新入社員でも研修後OJTすれば、みんなそれなりにできるよ。

50 :おいおい:2001/07/11(水) 23:46
>>45
いや、君の言う事もわかるけど、ここでは他の人の意見を聞いて見識を深めたり
経験的に得た知識に理論だった裏づけを求めようとしている人たちの集まりなん
だから。
議論をすぼめるような事は言わないで、建設的な発言をもとめる!!

51 :非決定性名無しさん:2001/07/12(木) 00:57
>>49
出来れば詳細がうれしいが、大体の流れや大雑把な説明だけでもうれしいので
その標準化されている内容を教えてください。

52 :非決定性名無しさん:2001/07/12(木) 01:21
>>49
いや、それなりに成功しているから、というのは
慣れるまでの話で、次のステップとしては
もっといい方法があるのではないか、と疑問を
持とうよ。結果としては今の方法が最善なのかも
しれないけどさ。やり方とかはいろいろあるし
検討の余地はあるでしょ。
向学心ないと周りからとりのこされちゃうぞ。
会社が古くさくなったって、君まで付き合う必要はない。

53 :非決定性名無しさん:2001/07/12(木) 10:52
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20010702/1/
要件定義にしても,設計にしても,あらかじめきっちりと決めることなど,
そもそも不可能である。青木氏は前出の著書で,(1)利用者の要求仕様は
永遠に確定しない,(2)開発者の設計仕様も永遠に確定しない,(3)ソフト
ウエアは完成することがない,という3点をオブジェクト指向のソフトウ
エア開発の「大前提」として挙げている。
つまり,XPが漸進的なアプローチをとるのは,「ソフトウエアは本来,
そのようにして開発すべきものだから」なのである。

54 :非決定性名無しさん:2001/07/12(木) 11:03
新しいソフトウエア開発手法 マーチン・フォウラー
http://www03.u-page.so-net.ne.jp/dc4/tnaka/fowler/newMethodology_j.html
だいたい仕様を予見できたことがない
私は問題のあるプロジェクトに突っこまれたことがたくさんあるが、
どこでも必ず耳にする言葉がある。開発者たちは私の所に来て
「このプロジェクトの問題点は要求仕様がコロコロ変わることなんだ」
と言う。それはあたりまえのことであって、みんなが揃ってそのこと
を何かとんでもないことのように言うのが、私には一番不思議だ。
ビジネスに関わるソフトウエアを開発するなら、要求仕様が変わる
ってことは、ノルマくらいに考えるべきだ。問題は、それにどう対応
するかだろう。
要求仕様は変化するものだ?・・・甘い、甘い。要求仕様は変化する
べきなのだ。

55 :非決定性名無しさん:2001/07/12(木) 15:29
>>54
自分で開発もやるなら、いくらでも仕様変更するがいいさ。
自業自得だからね。
他人に開発してもらうなら、迷惑をわきまえなよ。

56 :非決定性名無しさん:2001/07/13(金) 05:49
age

57 :FJ:2001/07/13(金) 10:06
要求仕様が変化するのは分かるけど、程度の問題だよね。
それまでの要求が、根本から変ってしまうと辛いよ。
納得できるような説明でもされれば、違うんだろうけど。

58 :非決定性名無しさん:2001/07/13(金) 10:50
>>54
ソフトウェア開発はXP的なやり方が向いているとしても、
世の中の多くのビジネスとは違うプロセスである所が、問題として残る。
そういう開発が出来ているところはすでにやっているとも言え、今まで
そういうやり方を出来なかったところがXP的な開発プロセスでビジネス
をしていけるかどうかが問題ということ。特に、受託開発をXP的な開発
プロセスでやっていけるのかどうかが、おおきな問題だと思う。
ここら辺解を持っている人がいれば教えてください。

59 :非決定性名無しさん:2001/07/14(土) 12:18
>>58
http://piza.2ch.net/test/read.cgi?bbs=tech&key=989482113
ここで議論してる。

60 :非決定性名無しさん:2001/08/12(日) 17:40
age

61 :非決定性名無しさん:2001/08/12(日) 18:04
要件定義は手法に関しては、情処テキストレベルで十分。
それより、顧客のレベルやPJへのスタンスに大きく左右される。
基本的に「業務分析」そのものではないからね。
とくに、明確なコンセプトややりたいことをもってるクライアント
ばかりじゃないし。其のときは、コンサルなのか、提案なのか、要求定義なのか
わかんなくなる。
最終的には、顧客の納得感や理解度をいかに上げるかが目的だから、
場数踏むことが一番。

62 :非決定性名無しさん:2001/08/12(日) 18:07
思念はaushebenしうる
まぁ、当たり前のことではあるな。

63 :仕様書無しさん:2001/08/13(月) 19:09
>>62
>思念はaushebenしうる
意味わからんので解説きぼん。

aus|he・ben(*)
[アオス・ヘーベン](他動詞)
【1】〔溝・堀など(4格)を〕堀って作る
【2】〔…(4格)を〕(手入れによって)逮捕する;〔隠れ家(4格)を〕手入れする
【3】〔ドアなど(4格)を〕(持ち上げて)ちょうつがいから外す

まさかaufhebenのtypoじゃないよね。

64 :非決定性名無しさん:01/09/04 23:06 ID:H9qe75VA
おれもキボンヌ。
弁証法の止揚?

65 :出張32:01/09/05 00:28 ID:zWnlqsFE
言葉のあやとして、「要件定義」と「要件分析」を区別している方が数名いらっしゃいますね♪
さてさて、現実問題として区別出来るのでしょうかね。(笑

それと、未熟な技能者が手法論を前面に論理展開されるのは結構なんですけど、
所詮は未熟なるが故の方便であることを知るべきですね。
対人折衝はそんな簡単なものではありませんよ。

66 :非決定性名無しさん:01/09/05 14:54 ID:oVC4uBkA
>出張32
いいたい事もいってることもわかるが、結論がスレ違いだぞ。

67 :出張32:01/09/05 15:31 ID:c4KFUuIk
>>66
> いいたい事もいってることもわかるが、結論がスレ違いだぞ。

そりゃ失礼。 m(_ _)m

じゃ、少しだけ助言しとくね。
「要件定義する為の良い本」って存在するのですか?
要件定義を難しく感じる要因を挙げたところで、どれだけ習得出来るのか疑問です。
そもそも、要求が何を指しているかを理解出来てないのでは?
「要求を理解する」を単に「目的を理解する」と捉えているようではダメですよ。

要求が出される背景を知る。 ==> 何故そんな要求をするのですか?
貴方が問題視している事例を挙げて下さい。 ==> 何処に問題があると思いますか?
人為的要因ですか?、手法的要因ですか?
....
....

結局、「要求を理解する」為には聞き出す能力・多角的視野で疑問視する視点・対話能力・対人感性を踏まえた論理的思考・整理整頓・関連関係重み配分等々
の総合力を付けるしかないと思われます。

貧弱な材料をどのように配置したところで「納得のいく要件定義」は出来ません。
まあ、配置が良ければ「みてくれ」と「ユーザー側に責任を転嫁する」ことは出来るけどね。

# キャンパスに配置することより、配置する材料を豊富にする努力をしましょう。

68 :非決定性名無しさん:01/09/05 15:43 ID:kPQCRsJk
まったくそのとおりなんだが、そいつはようけんていぎの
げんかいをしめしているだけで、いいようけんていぎのほん
おしえてのこたえになっていないと、>>66はしてきしている。
ぶつりのいいさんこうしょおしえて、ととわれて、ぶっしつの
せいしつをべんきょうしても、じっさいのせかいはぶつりの
ちしきのみでははかれないといってるようなもので。
やはりせいかくわるいなぁ、とさいかくにんさせられる。

69 :出張32:01/09/05 16:00 ID:c4KFUuIk
>>68
やっぱ性格悪い? (汗"
自分としては結構大事な部分を説明してるつもりなんだけどね♪
って、やっぱ私の発言を聞いたら「やる気を失う」のかなぁ?
多分失うんだろうなぁ....(笑

# 根性で頑張れ! (良い本無いけど...)
# めくら状態ならば、本屋行って適当に単純そうなのを2,3冊買っとけ!

70 :非決定性名無しさん:01/09/22 07:38
あげ

71 :非決定性名無しさん:01/10/05 13:17
今度帳票の要件定義を行なうのですが、基本設計は初めてなのでこちらのスレにきました。
私の想像してたところ、顧客の要件を聞いてそれをいかにシステムに落とすか
(具体的な仕様にまとめるか)っていう作業を想定してたのですが、
普通は要件分析まで含むんでしょうか。

出張32さんは確かに重要な話をしてらっしゃるんでしょうが、実際問題として
問題解決のための具体的な指針には欠けるような気がします。

要件を聞いて仕様にまとめることならやったことあるけど、
要件分析なんて自分には荷が重いような気がするよ・・・。

72 :非決定性名無しさん:01/10/05 13:21
>>71
????
帳票だったら、ユーザに何を
メッセージとして伝えるかってことだけが
全てなんじゃないの?
質問がファジーでわからん

73 :出張32:01/10/05 13:59
>>72
まあ、そうだよね。
あとコストパフォーマンスと利便性の兼ね合いで帳票の多目的利用の程度を考える位かな?

# 出力タイミングが重要なのは言うまでもないよね。

74 :非決定性名無しさん:01/10/05 14:26
あげ

75 :非決定性名無しさん:01/10/05 14:52
>>73
太田道灌

76 :出張32:01/10/05 15:01
>>75
徳川家康

77 :非決定性名無しさん:01/10/05 17:57
要求分析っつうのがチエの出しどころであるわな。
>>67
>>要求が出される背景を知る。 ==> 何故そんな要求をするのですか?
>>貴方が問題視している事例を挙げて下さい。 ==> 何処に問題があると思いますか?
ここが肝だわさ。
ここが判れば、ユーザが当初考えてた解決施策(とシステム)が
もしかすると違ってたということにもなる訳だわさ。

78 :出張32:01/10/05 21:06
>>77
ってか、そんな抽象的アドバイスはダメらしいです。
手取り足取り型で思考しないバイブル書を求めているらしい..(汗"

# うーん、おめえらぁ甘えるなよ!!!(立腹

79 :77:01/10/05 22:36
>>78
ふーむ、なるほどね。
その背景にあるのは、「ユーザが言ったことを
そのままシステム化する」ことがSEの仕事だと思ってる
家畜根性じゃないの?

言い過ぎか?

80 :非決定性名無しさん:01/10/05 22:50
「要求仕様の探検学」って訳が下手。読みにくい。

81 :要求仕様の探検学:01/10/05 23:00
>>80
それ俺のHN。本は「探求学」。

82 :要求仕様の探検学:01/10/05 23:39
>>81
…と思ったら、探検学で合ってたな(ゴメソ

83 :非決定性名無しさん:01/10/05 23:45
で、その本いいわけ?>>82

84 :要求仕様の探検学:01/10/05 23:59
>>83
一読する価値はあるのでは?

85 :83:01/10/06 00:02
>>84
ありがと

86 :非決定性名無しさん:01/10/07 23:28
71です。質問がファジーですみません。
要件定義といった時にすでに分析は済んでいてただ仕様を煮詰めるだけという
仕事を想定していたので、要件分析まで含むものなのかな?と思ったわけです。
何しろよくわかってないので・・・

本質を勉強するのはもちろん重要ですが、最初は最低限仕事をするのに困らない
体裁(知識)を整えたいというのも人情では(汗。
甘えててすみません。

87 :出張32:01/10/07 23:42
>>86
ってか、体裁を整えること自体良いことだし大いに主観で話し合えば良いと思うよ。

88 :非決定性名無しさん:01/11/22 07:47
保全あげ

89 :非決定性名無しさん:01/11/22 10:32
>>86
僕のイメージだと、要件定義→要件分析→設計→プログラム
と言う感じなんですが。

90 :非決定性名無しさん:01/11/26 17:04
「要件定義」って難しいね。同感。

で…、スレの主旨「要件定義」についての「お勧め本」は、
リックテレコム「SEの基礎知識 システムの開発と運用」
定価2,600円(ISBN4-89797-026-1)

著者はIBMのSE。内容は少し古いが、基礎がキチンと書かれているので一読をお勧め

91 :結樹:01/11/26 17:08
情報提供感謝します。

92 :名無しさん:01/11/26 22:19
要件定義の期間って普通何ヶ月くらいですか?
1ヶ月当たりのクライアントとのミーティング回数と時間はどのくらいですか?
規模と人数も併記して頂けると幸いです。

93 :非決定性名無しさん:01/11/26 23:16
>>92
そんな質問する奴は要件定義しちゃ駄目なの。
知らなくていいことってあるのよこの世の中には。

立場上どうしてもしなきゃなんないって言うのなら、
首つって死ね、その立場になるまでそんな事も知らずに
過ごしてきたお前が馬鹿なの。

94 :え?:01/11/26 23:19
長谷川君?

95 :結樹:01/11/27 01:50
>>90
調べてみましたが、この本はもう販売されていないようです。
感謝取り消します。

96 :出張32:01/11/27 06:43
打ち合わせ時間は長くても1回に付き2時間ってとこでしょうね。
それ以上はムダです。
打ち合わせ間隔は最小で週1回程度でしょうね。
それより短いと準備不足になってしまい非効率ですね。
コミュニケーションも大事だけど、実証推測可能な資料を用意してもらう事が大事ですよ。
そこから得られる情報は貴重ですからね。

97 :90:01/11/28 14:18
>>95
先の本ですが、調べてみたら取り扱いしていないみたいですね。
申し訳ないです。また、良い本があったら紹介します。

要件定義について参考になる記事↓
(基礎を知らない日本のソフト産業に未来はあるか?)
ttp://www.atmarkit.co.jp/news/200111/28/software.html

98 :sage:02/01/24 02:48
   |■\
   |´Д`) ダレモイナイ・・オドルナラ イマノウチ
   |⊂
   |



    /■\  オニギリワッショイ!
    ( ´∀`∩
    (つ   ノ
 ((   ヽ  ( ノ  ))
     (_)し'



     /■\
     (´∀` ∩ オニギリワッショイ! ワッショイ!
     (つ   ノ
  ((   ( ヽノ  ))
     し(_)


99 :名無しさん@Emacs:02/02/18 01:10
あげ

100 :非決定性名無しさん:02/02/18 02:12
煽りもあるけど おおむね 良擦れですね 参考になります

いままで 紹介された本

「要求仕様の探求学」 G.M.ワインバーグ著
「コンサルタントの秘密」G.M.ワインバーグ著
「スーパーエンジニアへの道」G.M.ワインバーグ著
「ライトついてますか」G.M.ワインバーグ著
「ザ・ゴール」ゴールドラット著
「ひとを動かす」デール・カネギー
「7つの習慣」フランクリン・コビー
「SEの基礎知識 システムの開発と運用」リックテレコム定価2,600円(ISBN4-89797-026-1)
「基礎を知らない日本のソフト産業に未来はあるか?」ttp://www.atmarkit.co.jp/news/200111/28/software.html


101 :非決定性名無しさん:02/02/23 04:44
コバーンの「ユースケース実践ガイド―効果的なユースケースの書き方」
http://www.amazon.co.jp/exec/obidos/ASIN/4798101273/qid%3D1014406860/250-7360180-4389818
なかなか結構でした。ホント実践的。
UML標準なユースケースから外れるところはあるが。

102 :非決定性名無しさん:02/02/23 23:18
http://www.atmarkit.co.jp/fjava/devs/redge01/redge01.html
要求仕様の決定に時間を割かない結末は?
http://www.atmarkit.co.jp/fjava/devs/process01/process01.html
従来の開発プロセスと現場が抱える課題
http://www.atmarkit.co.jp/fjava/survey/survey0202/survey0202.html
読者アンケート結果
〜ソフトウェアの危機とRUP/XP/UML〜


103 :非決定性名無しさん:02/03/25 01:10
102のつづき
http://www.atmarkit.co.jp/fjava/devs/process02/process02_1.html
新しい開発スタイル「RUP」と「XP」
ていうか要件定義とは離れてるんでは?


104 :非決定性名無しさん:02/04/11 02:09
>>100 ホントに、良スレですね

105 :非決定性名無しさん:02/04/20 21:11
IDEF0について勉強したいと思っているのですが、本など良い物があれば紹介してください。

106 :非決定性名無しさん:02/04/22 22:48
age

107 :age:02/05/07 23:19
とりあえず良スレぽいので


108 :出張32 ◆.XJ8VXow :02/07/01 22:09
要件定義や分析で大事なことをまとめて置きます。

1)お客様の要望事項を系統別に箇条書きにして整理する。
2)現状調査の基本として各種使用帳票を収集しどのような運用が為されているのか具体的に書き出す。
3)上記で作成した書類から疑問点や矛盾点・不足点を系統別に書き出す。
 (用語の使われ方に注意して一般的で無いものは必ず確認を取る)
4)疑問点や矛盾点・不足点に付いて自分なりに推測し要因候補を取りまとめておく。
5)疑問点や矛盾点・不足点を顧客に明示して解決案を作成する。
 (この時、要因候補を提示することにより場当たり的な解決案にならない様導く)
6)解決案策定時に必要があれば現地調査を実施する。

------ ここまでで基本的な要件定義が完成する。 -----

7)上記で作成した要件定義の運用効率と運用コストに視点を置きベストバランスなポイントを
自分なりに検討し修正案を策定する。(同時に導入効果も明示する)

8)修正案を提示し最終的な要件定義を取り纏める。


って感じですね。

大事な点は、体裁に拘らず上記の項目をしっかりと処置して十分な検討を行うことです。




109 :非決定性名無しさん:02/07/05 00:53
良スレ救済age

110 :非決定性名無しさん:02/08/02 14:06
良スレ救済age2

111 :非決定性名無しさん:02/08/02 18:25
良スレ救済age3




112 :非決定性名無しさん:02/08/04 23:22
>>1
納得したのか?

>>108が書いたことは特別なことでなく、大体このレベルでの方法は知ってる
ものの顧客に合せて具体的な項目に落とす等、実践していくための業界やら
業務、理論の知識を身につけられなくて困ってるやつが多いのが実態だと思うが




113 :出張32 ◆.XJ8VXow :02/08/05 04:42
>>112
そう、その通りです。
決して特別なことではありません。
但し、実践するとなると簡単なことでもないのです。
各要素において思考の深さや推理推測及び整理力が問われているのですからね。
熟練度や技量が乏しいと、自身の能力不足を全て他者のせいだと勘違いされるケースも多く
そのような状況に陥った人は進歩も期待出来ないのが実情だと言えます。

人は他者との競争に置いて優位に立つべく、ともすれば「特別」なものに焦点を合わせ過ぎるのです。
極普通のことが普通に出来るってことはある意味「特別」であることを知るべきだと考えますね。

114 :出張32 ◆13vnLlb. :02/08/05 05:09
>>113
>各要素において思考の深さや推理推測及び整理力が問われているのですからね。
異論は無いんだが、普段の発言を見ているとそう言ったベースの能力が
無い人間に見えるんだけど。>出張さん。

>人は他者との競争に置いて優位に立つべく、ともすれば「特別」なものに焦点を合わせ過ぎるのです。
>極普通のことが普通に出来るってことはある意味「特別」であることを知るべきだと考えますね。
はぁ?競争ねぇ…馬鹿っぽいけどその点は流して。
有る意味特別なんて事は、みんな分かってるから「要件定義の本教えて」と言うスレッド
が立つわけなんだよね。分かってる?誰も要件定義って何?なんて聴いてないよ。


相変らず言葉見つけて来て話していると思うな。

要件定義の技術的な部分を具体的に話してみて欲しいな。
話は、てか、あんたがこの板で発言するのはそれからだ。

115 :出張32 ◆.XJ8VXow :02/08/05 06:29
>>114
全然判ってないね。
そりゃ業務知識も大事たけどね、それ以前に自身の頭で解釈し理解する技量を身につける以外に
どんな有効な手段があるのか聞かせて欲しいわ。

知識も各人各様に解釈されていて完全に統一などされていないことを知って下され。
つまりは、どれだけ自身の仕事に拘りを持ち必要とされる以上に物事を掘り下げ自分なりに
整理理解するかが大事なのであり近道などありゃしない。
体系的に覚えるにしても各人の押さえ方はバラ付きがあり自身の特徴を知った上で処方箋を描くしかなかろうに...

# 具体論等腐るほどあるが、それを示したところで役に立たないことは明白と言える。
# そりゃ、ヨチヨチ歩きのお手伝い位にはなるけどね。

116 :出張32 ◆13vnLlb. :02/08/05 06:34
>>115
視野が狭すぎるよ。可哀想だなぁ…
整理整頓の方法を具体的に述べれば、箪笥を使う場合も有れば、INDEX作る方法も有れば…

そー言う事なんだけどね。
あぁ、恐ろしく馬鹿に伝える言葉が無いや。やっぱり日本語が通じないなぁ。

相変らず教科書みたいな人間だね。

117 :出張32 ◆.XJ8VXow :02/08/05 06:44
>>116
手法論等幾らでもあるだろうし、これが最高ってものなどありえない。
既成で全てが収まるのならこれほどに手法論が乱立することすらありえない。

そんなことぐらい君にも判るだろう?
「ヨチヨチ歩きのお手伝い」を幾ら論じたところで優秀な人材が形成される訳じゃない。

# はっきり言わせて貰えば、「好きな道なればもっと真剣に取り組め!!」ってことさね。

118 :出張32 ◆13vnLlb. :02/08/05 06:48
>>117
>手法論等幾らでもあるだろうし、これが最高ってものなどありえない。
そうだよね、合う合わない、取捨選択でしかないよ。道具なんて物は。

で、初学者が手法論を知りたくてスレ立ててるのに、あんたは的外れな返答ばかり。
簡単に言えば要件定義が出来てないんだよ。寒いよ。


119 :出張32 ◆.XJ8VXow :02/08/05 07:05
>>118
笑わせるんじゃない!!
自分なりに考え工夫した上で疑問点等を聞くのならいざ知らず、
単に「解説本教えて下さい!」ってレベルに何故に付きあわにゃならんのよ。(泣けるわ
それと、このツリーを読む各階層の方もいる訳だしその人達へ向けたメッセージを
書くほうがどれだけ役に立つことか少しは考えれ。

120 :Hore:02/08/05 07:05
要求定義工学プラクティスガイド
要求定義工学入門
 http://www.amazon.co.jp/exec/obidos/search-handle-url/index=books-jp&rank=+salesrank&field-keywords=%E8%A6%81%E6%B1%82%E5%AE%9A%E7%BE%A9&bq=1/ref=sr_aps_all_b/249-5456223-1075514

3層クライアント・サーバ要件定義技法
 http://www.amazon.co.jp/exec/obidos/ASIN/4320029283/qid%3D1028498579/249-5456223-1075514


121 :出張32 ◆.XJ8VXow :02/08/05 07:21
世の中甘いねぇ!(笑
本ぐらい自分で探しなよ。
そりゃ使えねぇ書物に埋もれて探すのが億劫なのは判るんだけどね♪
しかし、その努力があるからこそ身に付くものがあるんじゃないの?

# もやし君ばかりだと先が思いやられるわ。(溜息

122 :出張32 ◆13vnLlb. :02/08/05 07:25
>>119
ここは貴方の社内じゃないし、ましてやあんたの日記やWebじゃないんだけど
ねぇ。
さて、キチガイは適当に絡んで遊ぶとして。


ちょっと要件定義とはずれてるかもしれないけど、この前読んで面白かった本を紹介します。
知ってる人も多いと思うけど

誰のためのデザイン?―認知科学者のデザイン原論
http://www.amazon.co.jp/exec/obidos/ASIN/478850362X/qid%3D1028499442/249-6258416-3139501
ソフトウェアにもかなりページが割かれていて、要件定義のゴールがここに有ると思いました。
読み物として読めるので、機会があったら読んでみてください。


123 :出張32 ◆.XJ8VXow :02/08/05 07:49
>>122
ありゃりゃ、講釈を垂れ流した挙句にキチガイ扱いとは心外だね。
わたしゃ、取り組む姿勢に付いて語ってるだけなんだよ。

そりゃ、君達にすれば煙たかろうだけど...
取り組む姿勢が出来てこその知識であり、手法も己独自の用法が身に付くものなんですけどね。

まあ、差し障り無く「書物紹介スレッド化」してまったりしたそうなのは判るんだけどね。

124 :Aho:02/08/05 19:18
今のキーワードは要件定義より要求工学
と、書いてみるテスト

125 :非決定性名無しさん:02/08/05 22:12
who,when,where,what,why,how
->who,when,where,what,why,how
->who,when,where,what,why,how
これを、データ項目単位まで繰り返し掘り下げる。

126 :非決定性名無しさん:02/08/06 02:28
お前らのために、漏れが書いてやる。
出版されたら絶対買えYO!

127 :出張32 ◆13vnLlb. :02/08/06 05:09
>>124
綺麗だぁ。座布団一枚。
本当そうだね。

128 :非決定性名無しさん:02/10/26 00:20
「ユースケース実践ガイド」は面白かったけど。

129 :非決定性名無しさん:02/10/26 00:46
というか、「誰のためのデザイン」はユーザインタフェースの分野では
古典に入る有名な本だけど、要求定義のゴールってそういう方向(認知工学とか
HCIとか)なの?

130 :名無しさん:03/01/04 02:19
         / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄\
Λ_Λ  | 君さぁ こんなスレッド立てるから          |
( ´∀`)< 厨房って言われちゃうんだよ             |
( ΛΛ つ >―――――――――――――――――――‐<
 ( ゚Д゚) < おまえのことを必要としてる奴なんて         |
 /つつ  | いないんだからさっさと回線切って首吊れ     |
       \____________________/

(-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ…
(∩∩) (∩∩) (∩∩)

(-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ…
(∩∩) (∩∩) (∩∩)

(-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ…
(∩∩) (∩∩) (∩∩)


131 :山崎渉:03/01/11 11:49
(^^)

132 :山崎渉:03/01/18 14:49
(^^)

133 :山崎渉:03/03/13 14:08
(^^)

134 :山崎渉:03/04/17 09:41
(^^)

135 :山崎渉:03/04/20 04:17
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

136 :非決定性名無しさん:03/05/14 21:22
良スレ
保守age

137 :非決定性名無しさん:03/05/14 21:35
『実践UML』
UMLの本ですが、参考になります。設計をUMLでやることになった
場合にも使えるし、買っておいて損はないですよ。

138 :非決定性名無しさん:03/05/15 16:02
>>122
わざわざ意味のない書き込みを。

139 :非決定性名無しさん:03/05/15 17:39
>>129
ゴールじゃなくて、スターとラインだと思う。
認知頑張れ。ちょー頑張れ。分解しすぎると使えないから、
複雑系な感じでちょー頑張れ。

140 :非決定性名無しさん:03/05/15 17:55
あと要件定義って100%を求めるから大騒ぎになるだと思う。
90%で充分。取りのがした10%の修正コストは高いけど、
100%を目指すコストよりは安い。

141 :あぼーん:あぼーん
あぼーん

142 :山崎渉:03/05/28 14:40
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

143 :非決定性名無しさん:03/07/07 23:00
>140
そうですね。
確かに「全てを」なんて気持ちじゃやってられないですね。

144 :山崎 渉:03/07/12 12:32

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

145 :山崎 渉:03/07/15 12:54

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

146 :ぼるじょあ ◆yBEncckFOU :03/08/02 03:32
     ∧_∧  ∧_∧
ピュ.ー (  ・3・) (  ^^ ) <これからも僕たちを応援して下さいね(^^)。
  =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
  = ◎――――――◎                      山崎渉&ぼるじょあ

147 :あぼーん:あぼーん
あぼーん

148 :山崎 渉:03/08/15 18:45
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

149 :非決定性名無しさん:03/09/02 03:49
「要求仕様の探求学」 G.M.ワインバーグ著
「コンサルタントの秘密」G.M.ワインバーグ著
「スーパーエンジニアへの道」G.M.ワインバーグ著

150 :非決定性名無しさん:03/09/15 15:46
「中国の歴史に学ぶ要件定義、その奥義と伝承」
「秘伝、魔的要件定義」
「帝国主義の逆襲-私は要件定義の最高機密を見た!-」
  (いずれも民盟書房刊)

151 :びゅん:03/09/24 03:38
要件定義って、そこに書いてあることが実行できれば、効果(儲かるか、
節約できるか、etc)をえることができるぞ、っていうレベルになってれば
いんじゃないかと思ってます。
なので、対象業務に対して、コストや品質をヒアリングして調べあげて、
さらに、その原因をさかのぼって、原因結果チャートでもいいので、
ツリーとかつくって、その情報と、新システム構想との対比をする...
っていうあたりまでが、要件定義かなと。

で、分析してみたら、全然費用効果あわないよー!ってなって、そこで
プロジェクトは終了...ってのもありました。(いんですけど)





152 :非決定性名無しさん:03/10/04 00:09
>>151
禿堂。
基本的にはそうですな。
それを色々な方法論等を用いて分析・表現するとでもいうか。

最近、要件定義の言葉だけ浮き上がって、現場に行ってみると
要件定義させてもらえずに外部設計まがいのことをやらされる
ケースが多い。

大体、PMとかに就いてる人でも要件定義自体よく理解してない
偽SEが多すぎる。

153 :びゅん:03/10/08 06:08
>>152
>大体、PMとかに就いてる人でも要件定義自体よく理解してない
偽SEが多すぎる。
たしかに!!
しかし偽SEであっても、仕事もあるし、それなりに客から感謝されてる?
んだから、この業界って、暮らしやすい...って思ってしまいます。
感謝せんといかんですね。

個人的には、要件定義に必要な能力は、
>>67
の意見と同様、洞察力や対人能力が主体と考えてます。
方法論、とくに表現方法の部分って、そこから
アプローチするにはあまりにも、主体とかけはなれてるなと。

なので後輩には「上級SE目指すなら、経営を経験するのが近道だぁ」
って言ってます。
はっきりいって、役にたたねー助言ですが.....


154 :非決定性名無しさん:03/10/08 07:23
みなさんお詳しい・・・
もっと色々参考になるURL教えてください。
お願いします。

155 :制御系:03/10/08 12:19
情報システム(==業務システム)の難しさというのを再認識させられました。
新人の頃に感じた「事務処理という言葉に対する嫌悪感」
はこの「難しさ」が原因だったのか。
とも思います。

156 :非決定性名無しさん:03/10/18 00:08
保全

157 :非決定性名無しさん:03/10/18 18:22
>>155
業務プロセスを標準化する目的でシステム開発が実施されるのなら、
要件定義も楽になるのかな?と、ふと思った。
要するにERP導入案件の要件定義は行き着く先が同じだから楽なのではないか、
業務プロセスがかなり標準化されている欧米の会社での受託開発は日本より楽なのではないかと。

158 :出張32 ◆Rb.XJ8VXow :03/10/18 19:09
>>157
その通りですよ。
「標準化されている」ってことは「業務実態と作業項目が粗一致しており管理形態がそれに見合っている」って
ことですからね。

唯、注意して欲しいことは「標準化により失われてしまう利権も存在する」ってことです。
眉唾で無意味な利権と考えたほうが良いのかも知れないけど、経営がそれらにより維持されているケースも
多いから迂闊に「標準化・合理化・効率化」を武器としてちらつかせるのは不味いです。

そりゃ、「標準化・合理化・効率化」は判り易く単純明快であり構成されるべき仕組みも
突き詰めて行けば行くほど単純なものとなります。
単純なだけに、本質に求められる競争力は大きくなり付帯経費などは削減され「健全」な様相と
なる訳です。

ですが、人や社会がその「健全さ」だけを求めている訳ではないことに注意する必要があると考えます。
一見すれば理想に思えても、成し得てみると単純で味気の無いつまらない社会が築かれていることに
愕然としてしまうのかもね。

159 :非決定性名無しさん:03/10/19 00:23
>>158
「水清ければ魚住まず」ということを言いたいのかもしれないが、

>一見すれば理想に思えても、成し得てみると単純で味気の無いつまらない社会が築かれていることに

では、欧米社会の方が日本社会よりも「単純で味気の無いつまらない社会」ということになるが?
ERPが欧米で生まれてどんどん導入されてるのに、日本では導入が進まず、導入した企業もカスタマイズを
要求しまくって上手くいかないケースが多いのは、欧米では各々の業務プロセスの割と共通標準化されて
いるからだと聞いている。

ちなみに、各企業の業務プロセスの共通標準化は個々の社員の転職のしやすさも意味する。だから欧米社会
では、大半の業種で日本社会よりも転職のモビリティが遥かに高い(つまり職と会社の選択自由度が高い)。
出張32さんよ、あんたはそれなりに「利権」を得られる年齢層の人間じゃないの?
俺はこの点に関しては欧米社会の方がいいと思うぞ。日本社会はあまりにも会社中心過ぎる。

160 :出張32 ◆Rb.XJ8VXow :03/10/19 01:00
>>159
> では、欧米社会の方が日本社会よりも「単純で味気の無いつまらない社会」ということになるが?

はい、ことビジネスにおいては日本より味気ない社会だと思いますよ♪
まあ、私の投稿も少しデフォルメし過ぎた嫌いはあるのだけど用法として間違ってるとは思わない。
君の主張はちと滑稽な方向に歪められていると感じるのだが如何かな?

複雑な商取引慣行が残っている背景に何があるのかを考えたことはあるかい?
歴史や風土、更には人口密度まで複雑に絡み合っているとは思わないかい?

個人主義であることはある意味先進国では理想の姿だと思うが、個人主義が理想の形態を
維持するには西洋風の人権感覚が必要だとは思わないかい?
残念だけど、今の日本にはそれらの風土が育ち切れていないと思う。
つまりは、個人主義ではなく、自分勝手主義が蔓延ってるのでは無いだろうか?


161 :非決定性名無しさん:03/10/19 01:11
>>160
>君の主張はちと滑稽な方向に歪められていると感じるのだが如何かな?

どの点が滑稽な方向にゆがめられているのか具体的に示されると話が進むが?

162 :非決定性名無しさん:03/10/19 01:20
味気ないかどうかの判断は、何を味と感じるかの主観だけに左右されるだろ。
単純に>>160が日本ドメスティックだから欧米の商習慣にあわないだけ

163 :出張32 ◆Rb.XJ8VXow :03/10/19 01:33
>>161
> どの点が滑稽な方向にゆがめられているのか具体的に示されると話が進むが?

私の主張は、
「標準化・合理化・効率化」は判り易く単純明快であり構成されるべき仕組みも
突き詰めて行けば行くほど単純なものとなります。
である筈だよね?

上記を否定するには「単純にはならない」としなければダメしょ?
君が上記を否定せずにそれ以外の要素で反論してるのは滑稽だと思うよ。




164 :出張32 ◆Rb.XJ8VXow :03/10/19 01:49
>>162
「ことビジネスにおいては日本より味気ない社会」に付いては

>>158
>>160
で説明済みです。
もちろん「標準化・合理化・効率化」によるビジネスモデルでのお話です。
だから、「活性化や過渡競争」等の現象面は無視してくださいね♪

更に、>>160では「標準化・合理化・効率化」を受け入れる風土に付いて私なりの考えを
述べてる訳です。

165 :非決定性名無しさん:03/10/19 13:07
ばーかw
お前だって158で157の主張のポイントと全く関係のない話を展開してるじゃねーか。
つくづく思考範囲の狭い人間だな。

166 :出張32 ◆Rb.XJ8VXow :03/10/19 14:02
>>165

何を言ってるのか理解出来ないっぽ。

相手の意見に同意して話題を広げる為に「標準化・合理化・効率化」についての危惧を
展開するのはおかしいことなのですか?

この業界に入り一通りの業務をこなし少しだけ自信がついて来た頃によく嵌るのが
「効率化至上主義思想」だと思うのだけど....

効率化を追求するのは悪いことじゃないのだけど、「顧客の意向を無視して強引な..」って設計を
されがちな未成熟な技術者への助言として話題を振ったつもりですよ。


167 :非決定性名無しさん:03/10/19 14:09
相変わらず土日は2chに常駐して人の意見のあげ足取りか。
いつ見てもつまらない生活だな、出張。


168 :非決定性名無しさん:03/10/19 14:14
書いてる内容からして出張32の年齢は実際には32じゃなくて42前後だと思われ。
その年齢になって2ちゃんねるに入り浸って他人を罵倒して楽しんでる人間の
頭の中を想像してみれ。


169 :非決定性名無しさん:03/10/19 14:47
>>162に対して完全にスルーなのが笑える。
自分に都合の悪い事は絶対に認めないという一貫した姿勢は注目に値する

170 :出張32 ◆Rb.XJ8VXow :03/10/19 15:25
>>169
?
無視している訳ではなく
>>160は「習慣が異なる理由」と考えているだけのことです。

個人主義のベースは「他者を同等として認知する」ことだと思っているからね。
個人が際立たないと個人主義の意味は揺らぐと思う。
自身を輝かしたければ他者を輝かすことが肝要だと思う。
本質を尊重するのなら衣は薄いほうが良かろう?

逆に、曖昧さや奥ゆかしさを大切にするのなら衣は厚いほど良いだろう。

171 :非決定性名無しさん:03/10/19 22:55
いっしょうけんめい論点ずらさずともよいぞ、皆お前の味方なんだよ

172 :非決定性名無しさん:03/10/19 23:41
どうでもいいけど、出張32のようにここまで自分の思考のフレームワークに
頑迷に固執する人間が、優秀なSEであるとはとても思えないけどな(w

173 :出張32 ◆Rb.XJ8VXow :03/10/19 23:57
もちっと論を持って欲しいなぁ〜(これでも結構期待しているのだけど..

# 論なしで喚く人ばかりだとちっと寂しいなぁ〜

174 :非決定性名無しさん:03/10/20 00:15
お前が自分の論理以外を認めようとしないから誰もまともに相手にしないだけw
いい加減に気付けバカ!

175 :あぼーん:あぼーん
あぼーん

176 :出張32 ◆Rb.XJ8VXow :03/10/20 00:51
>>174
> お前が自分の論理以外を認めようとしない


>>158でしっかりと他人の論も認めてる筈だけど?

177 :非決定性名無しさん:03/10/20 19:55
他人の「自分と同じ主張」の間違いじゃないのか

178 :出張32 ◆Rb.XJ8VXow :03/10/20 21:10
>>177
そう思うのは君が「負け犬」だからだろう?
ネガティブな思考で物事を捉える癖が付き過ぎているようですね。

自分の考えと異なる論も認めるべきは認めているさ(笑
それとも君等は無条件に認めるような愚か者かい?
それだと主張の無い無意味な存在か、傷の舐め合いでしか生きれない存在に
なってしまうと思う。(それで良いのか?)

179 :非決定性名無しさん:03/11/23 00:46
出張32を名前でNGワードすると、S/N比があがるよ。

当然、出張32の意見は、ノイズだが。


180 :出張32 ◆Rb.XJ8VXow :03/12/01 17:18
しっかりとした論を持って欲しい。

自論の無さを「お前が自分の論理以外を認めようとしない」と言う言葉に
置き換えて欲しくないですね。

論そのものは、経験則であっても良いし思考の産物であっても良いと思う。
貴方がどのように考え何を大切にしているかを自信を持って発言して欲しい。

# あげとくよ。


181 :非決定性名無しさん:03/12/01 20:46
何で出張32はそんなに偉そうなん?

182 :出張32 ◆Rb.XJ8VXow :03/12/01 23:12
冗談交じりの軽い会話を行うのも自由だし、真面目に持論を展開するのも自由
ではないかな?
真面目に持論展開している方への安易で不真面目なレスは軋轢を生むだけだと思うね。

偉そうに聞こえるとしたら、聞き違いされてるのではなかろうか?

183 :非決定性名無しさん:03/12/01 23:53
>182 自問自答なのか?

184 :非決定性名無しさん:03/12/02 00:14
まだ生きていたか、出張32。

185 :非決定性名無しさん:03/12/02 12:34
プロジェクトリーダーやっている者ですが
良い要件定義は
1.設計以降の見積もり精度が高くできるもの
2.実質設計(概要OR外部設計)を半分くらいやっていて
 作り物が「かなり」見えているもの
だと思います。
うまくいったプロジェクトは、基本計画時点で他プロジェクトの
要件定義レベル、要件定義で概要OR外部設計の荒いものまで
作っています。
うまくいかないプロジェクトは、要件定義が提案資料並OR以下
です。(すごいのは1サブシステム1枚の絵だけ、しかも抜けが激しい)
見積もりがうまくでき、そこに要件を膨らむ要素を加味すれば
かなり良い感じの計画が立てられると思います
で、最後に予算のしばりでぐっと予算&機能を抑えられ、やはりプロジェクトが
大変になってしまう・・・
そんなことのないよう営業としっかり案件を取りましょう!
(実際はなかなか厳しいね)

186 :出張32 ◆Rb.XJ8VXow :03/12/17 00:29
>>185
一般的に、当初の要件定義に機能を盛り込み過ぎる傾向がある。
そのまま設計&構築に移ると水脹れのシステムが完成したりするから
設計の段階で更にスリム化を心掛けるのが宜しいかと...

187 :経験者:03/12/18 20:06
要件定義を見ればプロジェクトの成否はだいたいわかるね。
経営にタッチする人が見て納得しているかだね。
方式論より、基本的なことが大切だと思う。
現実は要件定義の段階で本当に何がやりたいのか明確でない事が多すぎるよ。
経営効率とかコストパフォーマンスとか言いけれど、システム化以前の問題も結構あると思う。誰のためのシステムかという視点で要件定義書を見直して見たいですね。

188 :非決定性名無しさん:03/12/18 20:18
>>186
開発の見積もりはどの時点でどの範囲までするの?
それとも、与えられた金額範囲で規模を調整する仕事のやり方?

189 :出張32 ◆Rb.XJ8VXow :03/12/18 20:24
>>187
おっしゃる通りです。
手法論に眼を奪われがちな時代もあると思うのよね。(それはそれで大事だけど..)
やはり、目的を見失わないよう常に醒めた視点での見直しを心掛けると良いでしょうね。
複雑化した案件ならば、尚更何故?、どうしてをより具体的・実務的な表現で補足するよう
心掛けたい。(その過程で解決策を発見することが非常に多い)

190 :出張32 ◆Rb.XJ8VXow :03/12/18 20:39
>>188
相手(ユーザー)次第ですが、そこは技術屋として落としどころが選べる物件
が良いですね。
その意味で、構想の段階から相談して貰えるとありがたいです。
まぁ、予算や納期が厳し過ぎると落としどころも必然で少なくなりますから...



191 :非決定性名無しさん:04/01/02 23:56
「課題・仕様・設計」
http://www.amazon.co.jp/exec/obidos/ASIN/4844318667/ref=sr_aps_b_/249-2247479-7095540
この本は結構良いかも・・

192 :非決定性名無しさん:04/01/03 21:15
>>191
仕様・設計って時点で変ですね

193 :非決定性名無しさん:04/01/05 21:06
CMMを実践してるとこってありますか?

194 :非決定性名無しさん:04/01/11 14:53
>>193
http://www.sra.co.jp/public/sra/company/profile.shtml
とかそうなのかなぁ?HP見る限りだけども

195 :非決定性名無しさん:04/03/01 23:01
「ソフトウェア要求」
http://www.amazon.co.jp/exec/obidos/ASIN/4891003545/
悪くなかったよ。

196 :非決定性名無しさん:04/03/04 20:06
RUPの本とかソフトウェア工学の本とかアジャイル関連のプロセス本とか、いろいろ読んでみた。
>>195 の『ソフトウェア要求』が、いちばんまとまっていると思う。

アジャイルほどラディカルではなく、
それでいて古い手法はなくバランスよく最近の手法が採られている。

けっきょく、「そんなにうまくいかねえよ」と文句いいながら正論の手法を地道に遂行しつづけるのが正しい。





197 :非決定性名無しさん:04/03/29 23:39
age

198 :非決定性名無しさん:04/05/17 11:59
「超」納税法


基本中の基本でしょ。プロとして。

62 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)