【植草ﾈﾀ】野村総合研究所 NRI 2nd【ﾂﾏﾝﾈ】

SIerに求められるのは、まず客との調整、要件定義、進捗管理、スケジュール管理とかだろｗ

こっからは俺の個人的な経験からくることで申し訳ないんだがｗ
コーディングスキルとか、プロダクトのスキルとかを誇ってるSIerのほとんどが、
上に書いてある必須のスキルがぼろぼろなのがおおいんだよね
もちろん両方できる人間もいることはいるけど、ほんと少ない…

ナンチャラ管理はツールに任せられる時代になってきてるけどね。。。
言ってることがちょっと古すぎない？

>>828
正直、誰でも出来るスキルだな。
PLの仕事であって、PMの仕事じゃないし。

コーディングスキルが設計スキルに
結びついている奴がSEだな。

>830
何を言ってるんだ？

828が言っていることが誰でも出来るんだったらデスマーチなんて起こらないよ
知らない業界のユーザのところに言って話をしてみろ。何語でしゃべっているのか理解できないぞ
そんなプロジェクトに入って客と要件定義を握ってくるのがどれほど大変なのか判ってないだろ

SEは要件定義を設計に落とすところが仕事で、設計をプログラミングに落とすのはプログラマの
お仕事。

典型的な上の見えない初心者プログラマ君なのね＞830

>831
でも要件定義が一番楽なお仕事だと思うよ。
要件定義してるやつらにその業務にマッチしたクラスの実装やらライブラリを
作り上げる能力ないでしょ。つーか既存クラスを使いこなすことすらできないヤツばかり。
それでも要件定義は日本語ができればなんとかできるお仕事なんですよ。
逆は無理だけどねｗ
君はなんちゃってPLかなｗ

>>831
いろんなスレで反応を確認してきたんだねwww

デスマーチをぽこぽこ起こしている方がおかしいんだって。
戦略的物件以外でデスマーチなんて起こしたことないよ？
工数の見積もりが甘いの一言。

仕様管理なんて当たり前。
例え知らない業界でも要件定義できなければ
私その業界知らないから仕事できませんって
言っているのと同じ。
そんなの勉強しろってだけ。

デスマーチの定義が曖昧では。
ＮＲＩは毎日終電帰りor徹夜のイメージがあるが、それは想定された範囲の仕事量？
利益が上がっても、メンバーに過重な負荷を強いている案件であれば、それはデスマーチという。
たまたま病人が出ていないだけ。

>>834
http://school7.2ch.net/test/read.cgi/job/1147094395/320

＞832
君が単なるプログラマであることは判った。
要件定義は日本語ができるだけじゃ絶対にできない。これはPMやPL（それも一次受けのSIerに限る）を経験していれば判ること。
それすら判っていないとは君は要件定義をやったことがないということは明白だよ。

なんで要件定義とクラスやライブラリの話を同列に扱うのかな・・・・・

はっきり言ってコーディングは中国人でもできるし、クラスの設計やルール策定なんてのは基本設計のレベルのお話。

全て要件定義がしっかりとできていないと業務系のシステムは成り立たない。

工数管理が出来ないからデスマーチが発生するという考え方も内向きな考え方。

要件定義をユーザと詰め、スーテクホルダーと握り、要件変更が発生した際の処理を決定し、
客と握り運用（時には妥協）していくことがデスマーチを防ぐコツだと思う。
前工程と後工程の作業のどちらが楽かは人によって違うから答えはないと思うけど、比較自体がナンセンスだよ（求める人材像も違うしね）

もうちょっと経験を積んでから下記個もしてね

>836
中国人だって中国内で要件定義はできるっしょｗｗｗ
中国人が日本語を読んでコーディングするのはたいしたもんだよ。
836のように知ったかでモノを言ってる人間に比べたらその中国人の能力のほうが上であることは間違いないｗｗｗ
お宅、経験積んでるわりには矛盾したこと言ってない？
とても要件定義の本質をわかっている人間とは思えない。
まっ、そんな調子で明日もがんばれやｗｗｗ

>837
じゃあ要件定義に必要な要素(能力)を書いてみなよ。
日本語(母国語)が出来れば要件定義が出来るなんて考えは経験したことが無い人間のたわごとに過ぎないよ

＞お宅、経験積んでるわりには矛盾したこと言ってない？
とても要件定義の本質をわかっている人間とは思えない。

どこが矛盾しているのか指摘してくれ。
あと、君は要件定義の本質がわかっているみたいだから是非説明してくれ。

逃げるなよ。

ちなみに、日本語の出来る中国人は優秀だよ。彼らをけなすつもりは無い。
仕事の進め方に？　(日本的じゃない)な人がいるからコントロールするのは苦労するが・・・・

両方経験あるが要件定義のが才能と経験がいるよ。
実装は上流の会社に入れるような学歴ある奴なら独学と訓練積めば誰でも出来るようにはなる。
そっち系のスキルに興味ない人が多いけど。
素人相手のヒアリング、システムへの落とし込み、
そして利害関係者の調整、こちらのが難しく感じる。
長い実務経験とセンスがないととてもこなせるとは思えない。

両方経験あるといったが、
実は要件定義の方はシニアな人にくっついて補佐役の仕事をさせてもらってるだけです。

>>837
この議論から逃げるなよ

>>837, 838
後学のために成り行きを期待

837は正論
838はアホ
もうやめとけ

横槍スマソ。
要求定義は大事であることに異論はないな。
ただ、お客さんの世界の専門用語を使っているだけで
なんとなく俺ってばスゲー（あるいは先輩スゲー）的な
錯覚に陥ってる人は結構いて、
そんな人ほど上流に行き過ぎた幻想を抱いている。

お客さんは要求定義してくれてありがとうとか、
設計してくれてありがとうみたいなことは言わない。
全ては動くものを作るためにやっていることであって、
要求定義や設計に時間をかけてすごく立派なワード文章を
仕上げたところでお客さんの望むものが
完成しないのであれば意味が無い。

837は結局逃げたのか？
それとも843で負け犬宣言をしたのか？

>844
ユーザが望むシステムを作って何ぼの世界というのは正論だと思う。

けど、ユーザが望むものを具体化する第一歩が要件定義になるんだよ。
その1歩目が間違った方向に向いていたら後の行程をどんなにがんばっても、
どんなにすばらしいクラス設計(wをしようともまったく意味を持たないものになってしまう。
それこそ仕様変更の雨あられで、デスマーチを招いてしまうプロジェクトになってしまうんだよね。

要件定義というのはシステムの土台となるべきものなので、土台がしっかりと作られないと上に出来上がるものはしっかりとしたものにならない。
その意味を理解している人間が要件定義書を纏め上げることがシステム設計には重要なことなんだよね。
だからこそ、システム作りの行程を理解し、ユーザの業務を理解している事が求められる。
要件定義=すばらしいドキュメントを作るのではなく、
要件定義=ユーザの真のニーズを文書化するという事なんだよね。

837のような日本語が出来るから要件定義を纏めることが出来るなんて人間が要件定義をしたら大変なことになるよ。

ちょっとくどくなっちゃったけどイメージわかるかな？

>>846
別に大変なことにはならない。後戻り工数が増えるだけ。
ま、基本設計時に要件定義の穴は見つかることが多いけどね。

仕様抜けじゃなくて仕様変更が大量発生してデスマになるのは
要件定義じゃなくてPMのコントロール不足。

顧客満足度調査
http://itpro.nikkeibp.co.jp/article/COLUMN/20060803/245049/?P=2&ST=system
おまえのところぜんぜん出てこないよ。なんで？

>>847
なんか君の書き込みをみていると可哀想に思えてくるよ。

後戻り工数が要件定義の変更の方が概要設計や基本設計の仕様変更よりも
大きくなるし、影響範囲や修正範囲が大きくなる。
下手をすれば基本設計の大半を修正しなきゃならない場合も出てくるんだよ。
そうなるとデスマーチへGO!になっちゃうんだよね〜

そういったことを極力発生させない、仕様変更が発生したとしてもいかに影響範囲を限定的なものにするのかユーザーとねごるということもPMのお仕事なんだよ

>>849

そんな大きな後戻り工数が出る要件定義しかできない奴がいるの？
キミだけじゃない？キミ、NRI社員？だったら相当のクズだね。
要件定義で完璧にできると考えている時点で相当あまちゃん。
あるいは上流工程しか把握できないおバカ？

あと、デスマーチ、デスマーチって盛んに叫んでいるけど
そう簡単にデスマーチにならないって。
要件定義が失敗しただけデスマーチになるような組織って
相当腐っているよ？基本設計フェーズ以降お客さんと
何話しているの？って疑問。

上流で仕変を食い止めるようきっちり決めるのが基本だけど、
それができなくてもデスマーチにならないよう予算も
スケジューリングもコテ入れも管理するのがPMでしょ。

>850
要件定義は一人でやるものではない。ユーザがいて初めて成り立つものなんだよ。
いろんな阻害要因があって、仕様変更は発生する。それは個人の能力に依存しないものも多いんだよ。

前にも書いたけど、要件定義レベルでの仕様変更が全体に与える影響が大きいと書いているだけだよ。
基本設計レベルの仕様変更と、要件定義レベルの仕様変更は重さや影響範囲がまったく違うということを理解しなよ。


＞上流で仕変を食い止めるようきっちり決めるのが基本だけど、
それができなくてもデスマーチにならないよう予算も
スケジューリングもコテ入れも管理するのがPMでしょ。

本当に教科書的な反応だね。プロジェクトによっては、期間、予算、人員に制限がつく
なんてのは当たり前の話だよ。その中で最大限努力し、プロジェクトを運営しているのが現実。
多分そんな現実は知らないんだろうけどね。
君のイメージしているPMというのは、プログラマの協力会社のリーダのイメージだよ。
とてもシステム全体のことイメージできているとは思えない。

ちなみに、俺はプログラミングは殆ど出来ない。君みたいなプログラマさんに比べると生産性、制度は数倍も劣るよ。
また、クラスの実装や設計なんかはまったくといって良いほど出来ない。
(最近殆どなくなったけど)プログラマと話をするときにはソースレベルの話をするのではなく、ロジックレベルの会話をするようにしてたよ。
それでも十分プログラマさんと会話することはできたけどね。


あと、日本のSIなんてのは要件定義、概要設計、基本設計の一部さえ出来ちゃえば8割がたは出来ちゃっている。
特に要件定義、概要設計のレベルでユーザ(ステークホルダーを含む)と握ることが出来たら、その時点でプロジェクトの成功は6割以上だと思う(当社比)
ここまでくればプログラマの質が悪かったりしてもユーザの満足いくシステムは作り上げることは出来るんだよ。

>>851

だからさー何度も言ってるけど、
上流の仕変が影響度が高いっていうのは同意しているが、
要件定義レベルの仕変がポコポコ生じるってどういう仕事を
しているの？って聞いているんだってNRIのお山の大将さん。

制限がつくっていうのも当たり前で、その制限がついた中で
どう余裕係数を見積もるか、その余裕係数を削らせないかが
PMなんだって。効率化しか考えてないの？品質保証は？
スケジュール厳守は？デスマーチになって品質が落ちて
困るのはお客さんだよ？それくらいちゃんと交渉しなよ…。
君の言っているのはITコンサルタントレベルの仕事で、
とてもSIerとは言えない！

プログラミングができるかどうかはこの際気にしない。
プログラミングを知っているかどうかの方を気にするしな。
そういう意味であんたの言っていることは正解。

設計書ができていればコーディングまでスムーズにいくか
どうかはその請負会社のレベルによる。中国に出すのであれば
開発標準からコーディング手順まで示さないとどうしようもない
ものができてくる。手順を作っても守らない奴の方が多いぐらいだしな。

何度も言うけどデスマーチなんて戦略的物件以外で起こした
ことはない。要員のモチベーションも下げるし、私生活を壊す。
せっかく育てた人材を放出させる原因にしかならない。
それで利益がでないどころか原価率120%だったらそんな案件
何の意味ももたない。取らない方がまし。

公共分野はフェーズによって会社が別というふざけたこともあるんでね、
そういう状況で一部後戻りしてでも下流フェースで取り戻さなきゃいけない
ことは普通にあるね。


自分が上流しか握れていないことを>>851は肝に銘じておけ。

>>851
とりあえず経験不足だね

＞(最近殆どなくなったけど)プログラマと話をするときにはソースレベルの話をするのではなく、ロジックレベルの会話をするようにしてたよ。
＞それでも十分プログラマさんと会話することはできたけどね。

クラス設計は全然ソースレベルの話でなく、それより上の階層の話。
会話できたって実のない会話しても時間の無駄だからね、

＞また、クラスの実装や設計なんかはまったくといって良いほど出来ない。
クラス設計が全くといっていいほどできないPMって終わってるよ。
コーディングができなくともクラス設計はできないと。

クラス設計がきっちりできていれば、仕様変更による影響は最小限に抑えられる。
その部分をチェックできる知識がないなら効率の悪いPMやってることになるね。

どこまで詳細なタスクの洗い出しができるか、工数見積もりを正確にできるか
ここにPMのセンスが求められる。これがうまいPMは、ほぼ開発を経験してるよ。

>>852
俺がいつデスマーチをボコボコ起こしているといったか？
元もとは君が要求定義は日本語ができればできるくらい楽な仕事だが、クラスの設計や実装はそうじゃないと言ったところが発端になっているんだよ。

それに対しての俺の反論として、要求定義はシステムをつくる上で重要なフェーズだから決して楽な仕事じゃない。
このフェーズでより戻しがあること影響が大きい、だから日本語ができればOKというものじゃないと言っていたんだけどね
その影響の一つとしてデスマーチの話をしただけだよ

あと852でいろいろと書いているが、これが典型的な教科書的な反応なんだよ
プロジェクトによってはが堀が埋まっている状態がスタートポイントだったり、すでにどうしょうも無くなっているところがスタートなんてものもあるんだよ（全てのプロジェクトがそうだといわけではなく、ごく一部にこう言ったケースがあると言うこと）

現実を知らないで教科書的な反応しか見えないから君の底が浅いと思われちゃうんだよね。

で、君は今でも要件定義の方がクラス設計よりも楽だと言う主張は変えていないの？

盛り上がってるなー。ちょっとクールダウンを試みてみよう。

要求定義とクラス設計ってどっちが楽だとか大変だとかみたいに
単純に比較できるものなの？
どっちも良い仕事をするには、それに応じたセンスが必要じゃないかなぁ。

要求定義よりの人が陥りやすい罠は、完全にお客さんの世界の住人になってしまうこと。
つまりお客さんの要求をオウムのように繰り返すだけの人になることだと思う。
「あーもういいよ。こっちが直接交渉するから・・・」
みたいなことをいいたくなる人を実際知っている。

実装詳しい人がハマル罠はお客さんの要求に対して否定から入ること。
それは無理です。みたいな感じでシャッターを下ろしちゃう感じの人がいる。
代替案を示しながらやんわりと否定というかサジェスチョンすればいいのに。

お客さんの世界とSIerの世界の境界で仕事ができるバランス感覚が
求められているんじゃないかな？

>854
>クラス設計は全然ソースレベルの話でなく、それより上の階層の話。
>会話できたって実のない会話しても時間の無駄だからね、
コーディングとクラス設計の階層をあげたいのであればあげればよいけど、どちらも基本設計以降のお話。
(たまにもうちょっと上位レイヤで出てくるケースがあるが)
そのフェーズでは大差が無いし、このような状況でPMが出てきて話をするケースなんてほとんど無い。
大半は所謂若手のSEクラスが出てきて、協力会社さんと細かい話をするんだよ。
このフェーズではPMとしては、スケジュールや進捗状況を管理して、各サブプロジェクトに問題が
無いか、問題があった場合の顧客対応や仕様変更対応などをしていくんだよ。
サブプロジェクトの中の基本設計以下の中身なんか直接見たりはしない。

>クラス設計が全くといっていいほどできないPMって終わってるよ。
>コーディングができなくともクラス設計はできないと。
なんで終わっていると思う？業務設計するのと、クラス設計するのとは違う話だよ。
クラスというのは、あくまでも開発効率、維持管理の効率を上げ、コーディングの人による癖を減らす
とか、使い方の難しいミドルウエアに皮をかぶせて使い勝手をよくするものでしょ？
そんなのがPMに必要な能力とは思えない。

＞クラス設計がきっちりできていれば、仕様変更による影響は最小限に抑えられる。
＞その部分をチェックできる知識がないなら効率の悪いPMやってることになるね。
そんなレベルの仕様変更の話をしているわけではない。もっと上位の業務設計を変更するという
イメージだよ。基本設計以下の変更なんて気にしていないって。

＞どこまで詳細なタスクの洗い出しができるか、工数見積もりを正確にできるか
＞ここにPMのセンスが求められる。これがうまいPMは、ほぼ開発を経験してるよ。
多分イメージ違うんだよね。
プロジェクトとしての工数って、何億、何十億という単位なんだよ。そういった見積もりをするときに
クラスをいくつ作ってとか考えないんだよね。画面数とか、帳票数とかをベースにしてはじくものなの。

考えているレイヤが違うから話が合わない、君の考えているのはあくまでも協力会社のリーダ
レベルの話。一次受けSIerの話ではないよ。
だから安易に一次受けの要件定義の話をしないほうが良いよ。

億単位のプロジェクトでPMがいちいちクラス設計の中身みてる時間なんかないだろ
だとしたらソイツはPMの仕事をしてないよ
もしかしたら小規模なプロジェクトの話をしてるんじゃないの？

>>858

PJの大きさによってPMのやる仕事が違うというのは同意。

ただ数十億レベルのPMは単なる管理職の世界。
環境さえ整えれば誰でも出来るし、いかに環境を整えるかだけが仕事。
そんなくだらない仕事はわざわざ議論する必要性すら感じないな。
君じゃなくても誰もでもできる。数十億レベルのPJはPMというより
会社自身の力だからな。
自分で数十億の仕事を発掘してきてPMしているというなら言ってくれ。
それならちゃんと尊敬する。

あと一次請けSIerだから数十億の案件って決めつけているのも
頭悪いな〜。一次請けの定義を勉強しなおしてきな。


クラス設計の件は手を出せるに越したことはないが必要不可欠の
知識とは思えない。ただ受け入れテスト結果に対する嗅覚を持って
いないPMは使えない。結局最後に責任を持つのは一次請け。
途中で協力会社を切り替えなければならない事態になっても
協力会社任せの引継ぎしかできない奴は会社の体制に甘えている
だけの能なし君。

要件定義とクラス設計どちらが難しいかが根本の話なんだっけ。
上流、一次請けが偉いって言い方しかできないから話が逸れるんだろうが…。

いやー確かに比較する意味が分からんが、うーん何で比較するんだ？

工数で比較するなら下流の設計の方が大きいな。
設計書作成の難易度でいうなら、俺は下流の設計の方が難しいと思う。
（上流設計は信頼関係と業界知識を持っていればどんな客先でも通用する。
　ほかにも上流→下流のキャリアパスは難しいだろ？
　逆に下流→上流のキャリアパスはいくらでも転がっているし、
　実際NRIもそういう下流出身の転職者を受け付けている。
　必要としているからな。）

ただ同じ情報量の重要度で比較するなら、当然上流の設計の方が大きいし、
ストレスも多いにかかる。考える分野も幅広くなる。


で、どっちが難しいかだっけ？どっちでもええんちゃう？ヽ(´ー｀)ノ

>860
>ただ数十億レベルのPMは単なる管理職の世界。
>環境さえ整えれば誰でも出来るし、いかに環境を整えるかだけが仕事。
こういう考え方が間違っていると言っているんだけどね。
環境を整えるという言い方をしている意味が良くわからんが、

プロジェクトをとってくるって話と、プロジェクトを成功に導くというのは別の話。
結局君は最初から最後まで理解できていないんだよ。

>あと一次請けSIerだから数十億の案件って決めつけているのも
>頭悪いな〜。一次請けの定義を勉強しなおしてきな。
頭悪いのは君だよ。数千万クラスのプロジェクトなんて、社員2,3人＋協力会社5,6人くらいでやるから
厳密なプロジェクト管理なんてしないよ。
ただ、こっちの方が見積もりとかは厳密にやるけどね(大規模なプロジェクトは
詳細レベルのぶれはそれほど影響ないけど、数千万クラスだとちょっと間違えるとすぐに赤になるからね)
予算や期間なんかを考えて柔軟に対応するの。

＞要件定義とクラス設計どちらが難しいかが根本の話なんだっけ。
＞上流、一次請けが偉いって言い方しかできないから話が逸れるんだろうが…。
自分の書き込みもう忘れたのか？
それに俺は上流行程が偉いなんて一言も書いていないよ。
君のどちらが楽かということに関しては836で俺の意見は書いている。
よく読みなおしてみろ。

＞いやー確かに比較する意味が分からんが、うーん何で比較するんだ？
君が832で比較してるんだよ。
ちょっと前の自分の書き込みすら忘れちゃうのね。
これからはちゃんと仕様書読んでからプログラミングしろよ。勝手な解釈でコーディングするなよ。

追加

＞工数で比較するなら下流の設計の方が大きいな。
そりゃ下流行程の設計は"作業"だもん。工数的には大きくなるでしょう。
でも工数は多くても上流行程と掛かるコストは変わらないケースも出てくる。
何でだと思う？


＞設計書作成の難易度でいうなら、俺は下流の設計の方が難しいと思う。
＞（上流設計は信頼関係と業界知識を持っていればどんな客先でも通用する。
君の断言した書き方が駄目なんだよ。それが現実が見ていないと俺が言っているところ。
同じ業界でも会社が違えば仕事の仕方は違うし、企業文化は違う。となるとシステムに対する要件も異なってくる。
だからこそ、SIerという存在が必要になってくるんだよ。
特に大手企業を相手にする場合は、上の考え方は捨てた方が良いよ。

＞　ほかにも上流→下流のキャリアパスは難しいだろ？
なぜ難しいか考えたのか？上流→下流のキャリアパスが無いから下流の設計が難しいという考え方もおかしい。
単価だって、上流行程やる人間と下流行程の人間だと倍以上、下手すれば5倍位違ったりするんだ。
それはなぜかを考えたことが無いのか？
ちょっとは考えてみなよ。

君の考え方は
・システムを下流行程からの視点でしか語っていないから上流行程の話をしようとすればするほど薄っぺらくなっている。
・自分の経験=世の中の摂理と考えているから断定的な言い方をしている。→世の中断定できる事象なんて少ないよ。
・いろいろ勉強はしているみたいだけど、自分の経験とMIXさせて話をすることが出来ていないから、軽い、薄い
・考え方が膠着しているきらいがある。物事を多角的に見る、考えることを訓練した方が良い。
という傾向があると思われる。

自分の経験と勉強でちゃんと考えて自分の言葉でしゃべることを覚えてください。

>>862
きみの要件定義は荒々でしょ？
俺以外に少なくとも二人書き込んでいるんだけど？
文章力読解力ないねー。

そちらの方の内容まで俺は責任持てねーな。

（せっかくの休暇中まで書き込んでいるのんだからまともな議論を期待してるよ！）


> プロジェクトをとってくるって話と、プロジェクトを成功に導くというのは別の話。

なーんで決めつけるかなー。おれは営業しなくていいって。
NRIの人事の人が自分で案件を取ってくる意気込みの奴が
足りないって言っていたのがよくわかる。

与えられた仕事を与えられた通りにこなすだけの奴なんだね、君は。
PMはプロジェクト管理をする人なんて当たり前の話をしているんじゃないよ？
会社の与えられた枠で何の工夫も努力もせず、時間だけかけて仕事を
している人が偉いわけもないし、すごいわけもない。会社がすごさを
自分に転嫁して粋がっているだけ。
NRIでたら通用しないから、出されるようなことにならないよう気をつけな。

※名前の178は気にするな。ほかのスレの番号だ（苦笑

> 頭悪いのは君だよ。数千万クラスのプロジェクトなんて、社員2,3人＋協力会社5,6人くらいでやるから
> 厳密なプロジェクト管理なんてしないよ。

キミ本当にPMやってるの？なんか机上論だけの学生に見えてきたなー。
小さいPJ程予算が厳しいからPJ管理能力は要求される。人も足りないしね。
数億のPJの方が幅が広くてやりやすいよ。これ作れあれ作れって二次請けに
指示出してその情報を精査するだけの仕事だし。
細かい作業は協力会社さんがやってくるからねー。


> クラス設計

もう一度、頭を冷やして全部読みなおせ。以上。


> 上流→下流

キミの反論はロジカルファラシーだよ。
なんにも具体的なソースは出さないんだねー。

単価については儲かるからの一言。
儲かるから難しいってわけでもないし大変ってわけでもない。
証明にはなりえない。

> 考え方云々について

多分ほかの人の書き込みも混ざっている。
まず書き込み時間を見ろ。おれは君の反論がないのに
一日に何度も書き込まない。

あと軽い薄いっていわれないため、企業秘密に触れない部分で
色々例示を試みてみたんだけど。
証拠云々なんてロジカルファラシーなので、議論するつもりはない。
キミの琴線に響かなくて残念だ。

まー、君の説の根拠となる具体例を期待して待っているよ。

要件定義のどこの部分でこういうトラブルがあって大変だったとか、
この程度の予算への影響を与えてしまったとか。

体験談、期待してるよ〜♪

「要件定義は日本語が出来れば誰でも出来る」
いまだにこのアホ発言の弁明はなし。
いつの間にか議論に勝つことが目的になってて揚げ足取り、後だしばっか。
これは意図的に話題を逸らそうとしてるのかな？ロジカルファラシーてｗ
ウォチしてたけどこれ以上は不毛っぽいな。

発言もカスならやることもカスだな。

675 名前:就職戦線異状名無しさん[] 投稿日:2007/08/17(月) 09:07:44
NRIの仕事はこんな仕事です｡
↓
http://science6.2ch.net/test/read.cgi/infosys/1147624365/828-

深夜に疲れて帰ってきて､『俺はすごいんだ!』って2chに書き込まなきゃ
やってられない｡こんな仕事ですwwwwwwwwwwwwwwwwwwwww

862,864でもできているんだから十分証明になっているんじゃない？ｗｗｗｗｗｗ
就職板のバカスレにコピペしたのは俺だよ？？
ＳＥは口先ばかりの使い捨ての役立たずばかりって良い証明ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>851
>あと、日本のSIなんてのは要件定義、概要設計、基本設計の一部さえ出来ちゃえば8割がたは出来ちゃっている。

日本のSIはそれでシステム開発出来るけど国外のSIはそれじゃ出来ないってこと？
その差はなんなの？？

>178

>> プロジェクトをとってくるって話と、プロジェクトを成功に導くというのは別の話。

>なーんで決めつけるかなー。おれは営業しなくていいって。
>NRIの人事の人が自分で案件を取ってくる意気込みの奴が
>足りないって言っていたのがよくわかる。
ほらね、日本語能力無いじゃん。
営業しなくて良いよなんてどこにも書いてないでしょ。プロセスとして分けて考えないといけない
と言っているんだよ。PMやPLが営業や提案して案件とってくるなんてのは普段でもある話。
ただ、とってくるという仕事と、とってきた仕事をどう成功させるかは別の考え方で
仕事を進めないといけないといっているだけ。

難しいかな？

続き


>キミ本当にPMやってるの？なんか机上論だけの学生に見えてきたなー。
>小さいPJ程予算が厳しいからPJ管理能力は要求される。人も足りないしね。
>数億のPJの方が幅が広くてやりやすいよ。これ作れあれ作れって二次請けに
>指示出してその情報を精査するだけの仕事だし。
>細かい作業は協力会社さんがやってくるからねー。

これこそ、君が実経験を行っていない証拠だよ。
小さいプロジェクトはスコープが明確になっていることが多い。よって客に無理難題を
押し付けられても断られる(または追加予算や期間を取ることが出来る)ケースが多い。
大き目のプロジェクトだと客も「これだけかね払ってるんだからこれもやって、やれもやって」
とい押し付けられる事が多い。だからプロジェクトの管理という面で言うと、
規模が大きくなればなるほど難しくなるんだよ。
これは要件定義がどんなにまとまっていても発生する話しだから、上記のことを言われると
プロジェクト管理が出来ていないという話ではない。単なる心理学の問題。
また、人数が増えれば見知らぬ人も多くなるし、それぞれの得意分野や生産性なども
見えなくなってくる。担当者が抱えている問題点も見えにくくなってくる。
だから、プロジェクト管理は規模が大きい方が難しいし、厳密なルールを作って管理する
必要がある。

規模が小さいプロジェクトだとプロジェクトメンバーの顔がPM(という言い方すらしないけど)
からよく見える。それぞれが抱えている課題をすぐに拾い上げることが出来るんだよ。

もうちょっと

>> クラス設計
>もう一度、頭を冷やして全部読みなおせ。以上。
>> 上流→下流
>キミの反論はロジカルファラシーだよ。
>なんにも具体的なソースは出さないんだねー。
>単価については儲かるからの一言。
>儲かるから難しいってわけでもないし大変ってわけでもない。
>証明にはなりえない。

君のほうがロジカルファラシーだよ。
儲かるから単価が高いというのはおかしい。
誰でも出来る仕事だったら、価格競争が発生して、単価は下落するでしょ？
SI案件についてのコストダウンは発生している。だけどハードウエアのコストダウン、
プログラマの単価の下落が大きく、上流工程のやる人間の単価はそれほど下がっていない。
これはどういうことなのかを考えてみたまえ。

儲かるというのを前提にしているから考え方がおかしくなるんだよ。

具体的な事象を書かないと理解できない=理解力が無いということがわからんかね？
こういう状況が発生するよということは十分書いているがまだ理解できないのかな？

最後かな

>あと軽い薄いっていわれないため、企業秘密に触れない部分で
>色々例示を試みてみたんだけど。
これが軽いことだってことがわからんかな？
「数億のPJの方が幅が広くてやりやすいよ。これ作れあれ作れって二次請けに
指示出してその情報を精査するだけの仕事だし。
細かい作業は協力会社さんがやってくるからねー。 」
これが君が下流工程から見た視点だよと言っている。
「これ作って、あれ作って」て「これ」とか「あれ」は誰がどう決めているのか判っているのか？
客が全部仕様作ってくれるのか？
「二次請けに 指示出してその情報を精査するだけ」
協力会社が出したものをどう精査するんだ？それが要件に本当に合致しているのか？
合致していない場合はどこがどうあっていないで、どう修正すれば良いのか
どう判断するんだ？
作るものに対して、期間やコストがあっていると判断する基準は何なんだ？

そういったもろもろの仕事があることを「だけ」と片つけている以上、君は経験が無い
プログラマ君だと思われてしまうんだよ。

>日本のSIはそれでシステム開発出来るけど国外のSIはそれじゃ出来ないってこと？
>その差はなんなの？？
日本のSIしか知らないから。国外のSIの事例のサンプルが少なくて判断できないから。

・プロジェクトが大きいから小さいからっていうのに拘っているのは君の固定概念
　
　俺の経験上、数千万のＰＪでも数億のＰＪでも客先の無理難題は変わらない。いくら数字で示してもね。
　数人月のＰＪを除けば体制化するからまとまった数字としてしか上には上がってこない。
　作業量は増えるがＰＪの規模によって難易度は変わらない。
　調整は確かに面倒臭くなるが各サブPJのPMがまとめる分、直接対応する人の数は変らない。

・上流工程のやる人間の単価

　パイを少なくしてるからってことが理解できないかな。
　客先に間接工数としての管理費の見積もりを直接見せているのかい？
　見せていたらほかの所に頼もうかなっておもうかもね。
　以上のことから自分で読解してみな。
　
　君が出来るから高いんじゃないって君自身一番分かっているでしょ？
　分っていないならおめでたいというだけ。
　
・情報について

　きみはここも読み間違いをしている。キミが言っているのはＰＬ。論点をすり替えないでね（はぁ）

　画面数、ファンクションポイント or ステップ数、帳票数、レビュー進捗率、
　バグ件数、予定バグ抽出件数、課題一覧表、仕様変更管理票、…他
　※ちなみに持論だが設計・製造の進捗率ほど信用ならないものはない（苦笑）
　
　これだけ明示してげなきゃ分かんないの？ほんとうーにきみＰＭしてる？
　客先に行ってゴネゴネ話すだけがＰＭなんじゃないよ？
　これで分からなきゃ日本語勉強しなおして来い。

あーだる、抽象論だけ並べていても永遠終わらないわ。
君のしている仕事を全部並べてくれ。それで問題は解決する。

＞ 作業量は増えるがPJの規模によって難易度は変わらない｡
もうやめとけ。取り返しつかなくなってる。あんたのは協力の課長クラスの視点にしか見えない。

単価の話は上流→下流の要員置換は可能。逆は絶対に無理。
上流の方が高くて当たり前。

>876
ちょっと前の自分の書き込みを忘れちゃたのね。

>・プロジェクトが大きいから小さいからっていうのに拘っているのは君の固定概念
865で
>小さいPJ程予算が厳しいからPJ管理能力は要求される。人も足りないしね。
>数億のPJの方が幅が広くてやりやすいよ
って比較してるじゃん。俺はそうじゃないよと書いているだけだよ。

>・上流工程のやる人間の単価

　パイを少なくしてるからってことが理解できないかな。
　客先に間接工数としての管理費の見積もりを直接見せているのかい？
　見せていたらほかの所に頼もうかなっておもうかもね。
　以上のことから自分で読解してみな。

読解した結果
・君は上流工程を理解していない
(理由)
上流工程は管理工数ではなく、工程のひとつである。(当然管理工数をつんでいるが)
なぜならアウトプットが明確に定義されているから。
(例：要求定義書、概要設計書などなど)
よって、上流工程で何をしなければならないかを理解していないという結論になる。

この工程をPMやPL層だけでやるケースが多いから混同してしまっているかもしれないが、
よーく考えれば判る話

あと、「　パイを少なくしてるからってことが理解できないかな。 」
の意味が良くわからん。パイって何なんだ？それを少なくする理由って何なんだ？
よー判らん

続く

傍観者が横槍入れてスマンが、
みんな偉そうに議論するなら番号でもいいから名前入れなさいよ

そもそもなんで2名（自分と相手？）の書き込み限定で話が進んでると思ってるのかと小一時間。

「忘れたのか」とか「さっきも言ってたけど」っていう発言が基本かみ合ってない

そもそも帳票数とか言葉が出てくる時点で
閉じた世界しか見てないなというのが分かるな

続き

>・情報について
　きみはここも読み間違いをしている。キミが言っているのはＰＬ。論点をすり替えないでね（はぁ）
　画面数、ファンクションポイント or ステップ数、帳票数、レビュー進捗率、
　バグ件数、予定バグ抽出件数、課題一覧表、仕様変更管理票、…他
　※ちなみに持論だが設計・製造の進捗率ほど信用ならないものはない（苦笑）
　これだけ明示してげなきゃ分かんないの？ほんとうーにきみＰＭしてる？
　客先に行ってゴネゴネ話すだけがＰＭなんじゃないよ？
　これで分からなきゃ日本語勉強しなおして来い。
>
これって俺が>873で書いたことをさしているのかな？
だと前提を置くと、君は大きく勘違いしている。
協力会社さんに提示してもらう"情報"の定義するのがPMの仕事ではないんだよ。
あがってきた数字が
・そもそも正しいのか？(これはPLクラスの話かな？)
・妥当なのかどうか(指標はあるが、プロジェクトとしての基準を設けないといけないからその基準を策定する必要がある)
・そもそもどの指標を用いて評価を行うのかを策定する
ということを考えるのがPM(一部はPL)の仕事(のひとつ)なんだよ。
つらつらあげてる管理指標の話をしてもしょうがないんだよ。プロジェクト管理をする際には
どの指標をどのタイミングで使うのか？、指標に対して妥当と判断する基準はどこに置くのか？
が重要になってくるの。

あとね、俺が875で書いた
＞「これ作って、あれ作って」て「これ」とか「あれ」は誰がどう決めているのか判っているのか？
客が全部仕様作ってくれるのか？
＞
に答えてよ。これそのものが要件定義(の一部だったり、概要設計だったり)であったり、PMの仕事(の一部ね)であったりするんだよ。

＞あーだる、抽象論だけ並べていても永遠終わらないわ。
君の書き方が抽象論以下のペラペラなものだって気がつきなよ

>>873
＞これこそ、君が実経験を行っていない証拠だよ。
証拠になってない

＞小さいプロジェクトはスコープが明確になっていることが多い。
多いってどこのデータ？

＞押し付けられても断られる(または追加予算や期間を取ることが出来る)ケースが多い。
また多いって脳内比較？

＞大き目のプロジェクトだと客も「これだけかね払ってるんだからこれもやって、やれもやって」
＞とい押し付けられる事が多い。
何のデータも示さず、また多いｗ

＞だからプロジェクトの管理という面で言うと、規模が大きくなればなるほど難しくなるんだよ。
「だから」って理由になってないｗ

＞これは要件定義がどんなにまとまっていても発生する話しだから、上記のことを言われると
＞プロジェクト管理が出来ていないという話ではない。単なる心理学の問題。
また脳内ソースｗ

論拠のないまま、脳内持論を展開し、論理も破綻し意味のないことを語ってる
典型的な無能

なんかマンネリ化してきたね。
ちょっと別のネタ投入してもいい？

Divide and Conquer を突き詰めていくとアジャイル的な
手法にたどり着くことができると思うんだけど、
日本ではアジャイルってどの程度実践されてるものなの？
＃上流思考の人には否定されちゃいそうな予感がするけど。

>>883学生乙

たまたまの通行人です。
各々のステージ、PJで問題意識をもって業務に取り組んでいるのは良いことですね。
外から見るとPJは同じように見えて、中身はまったく違うものが多々あります。
上流は下流の能力も見て、混乱しないようにできるだけ他と同じようにして流すのが仕事。
下流は、上流の決めたことを精査し正しく仕上げるのが仕事。
PLはそのためのコミュニケーションを図るのが仕事。そのための情報収集も重要。
PMは頑張っている人が報われるようにするのが仕事。それだけ。
玉石混合。ケースByケース。
すべてのステージでいかに対処するか、できるかが能力。
そのための、経験、技術、人脈も必要。
この業界の仕事は外から見ていると何をしているのかわからないし、文字を読んでもわからないけど。
難しい仕事ですよ。
定義したりするのは勉強やコミュニケーションのために必要ですが、簡単じゃないですね。
答えも一つとは限らないですね。
短い時間でいろんなことを自ら経験できるわけでもないので、
お互いのポジション、背景も踏まえて肯定的に発展的に議論すると自分のためにもいいですよ。

では去ります。

>>885
これはひどい自作自演

まだまだ突っ込みどころが一杯の回答をもらったけど、
これ以上論点のすり替え合戦をしても意味ないので撤退する。

最後まで下請けとかPGの戯言と決めつけていた根拠が理解できなかった（苦笑）
足りないものがあるなら教えてもらおうとも思ったんだがヽ(´ー｀)ノ
ま、NRIさんとはPMとしての考え方が違うんだろうな。

>>883

アジャイルで開発しているPJは知っているけど、アジャイルで開発していますって
こと自体を売りにするだけで、あんまり効率化できていなかったな。

逆に質問。
・大規模PJに導入する上でどうやってチームを分ける？
　＆　結合・総合フェースは別で設ける？
・Outputはどのレベルまで作る？
　インタフェース仕様書レベル？

プロジェクトのチームに分けるやり方の方針までは示してはいないよね＞アジャイル。
チームに分けた後の開発プロセスとしてXPなどを選択するとかはアリかなと。

オブジェクト指向と同様、
アジャイルも導入しさえすればなんでもOKというわけでもみたいだけど。
http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm

来年から新卒入社しますが
このスレの流れについていけなくて早くも内定ブルーです

欝になった人や自殺した人は周りに居ますか？
どれくらい詰められるのでしょうか？
土日はどれくらい休めますか？
有給は使える雰囲気ですか？
ここで働いても人間らしい生活は送れますか？

教えてください　お願いします

今は何も心配する必要はない
それだけは言える

ZARD

この会社ってクビになるヤツとかいるの？

どんな会社でも無能なやつはクビだろｗ

犯罪おこせば

>>893
人間が 3,000人も集まると、その中には数人、正真正銘の馬鹿が必ずいるよ。
例外はない。どんな企業でも同じ。

どっから3000人が出てきたか不明だが、基本的にクビはない。
なんだかんだ言って終身雇用前提の日本企業。誰でも長く勤めれば上専になる。
だからといって暖かく見守る訳じゃないから、
本人が続けるかは別問題だけど。

仕事がないとこにとばされて、異動の時期のたびに異動になっても
体裁気にせず居座れる人ならずっと居座れるよ
それなりの給料もらえて

こんな儲かってる会社で、能力がないからってクビになる奴なんていないよ。
つぶれそうな会社が「解雇しないと会社がもたない」ってときにクビになるのだから。
つまり >>898 のとおり。
ふつうのクビってのは、横領とかひどいセクハラとか、仕事の能力とは直結しない不祥事による。

市況板で大野さんがニイウスコーの社長になるって読んだが本当なのか
なんだかんだで見切りきれないんだなｗ

貴社は障害者雇用の面はどうなっておりますか？
障害者といってもいろいろおりますけれども。

Webサイトを見れば、障がいをお持ちの方へ、というページがあります

>902
そういう建前でなく、実態のほうを知りたいのですよ。

Webサイトに書いてあるように、一般事務職としての採用なんだから、
大半の社員は接点がないよ。それ以上の情報はここでは無理でしょう。
会社に問い合わせたら？

SEとして活躍したいということだろうか。この会社は激務ですよ。

>>905
ＩＴコンサルでも？

この女子高生痴漢の変態どもが

>>906
なにそのお気楽な推測

うるせーよ女子高生痴漢マニア

>898
居座る根性を養うにはどうすればよいですか？
あてはまるみなさまのコツを教えてください。
よろしくお願いします。

野村ｗｗ

dj：ＤＪ・クラブ［重要削除］
http://qb5.2ch.net/test/read.cgi/saku2ch/1028777996/193

193 名前：誹謗中傷[[email protected]] 投稿日：07/09/03 10:27 HOST:nttkyo703031.tkyo.nt.ftth.ppp.infoweb.ne.jp
対象区分：［個人・三種］優先削除あり
削除対象アドレス：
http://music8.2ch.net/test/read.cgi/dj/1166370414/770-772
削除理由・詳細・その他：
削除ガイドラインの以下に触れています。
１． 個人の取り扱い 削除対象 ＊
個人名・住所・所属：三種：誹謗中傷の個人特定が目的である・文意により攻撃目的である等の場合は全て削除対象になります。
誹謗中傷：三種：個人を完全に特定する情報を伴っているものは削除対象です。
また、私生活情報：情報価値が無く、私事のみの情報・第三者の確認できないプライベート情報は、個人が完全に特定されなくても、対象者に不利益が発生する可能性があれば、一律削除対象とします。

会社名と年齢とイニシャルで個人は特定できてしまいますので、どうか削除の方よろしくお願いいたします。

痴漢上げ。

【銀座ジニアス】part2
http://music8.2ch.net/test/read.cgi/dj/1166370414/770-

体裁を繕った要件定義とやらのむなしいことしかできないやつってかわいそう。
本人はそれで自己満足してるから別にいいけどさ。
でもそれって抽象度の高い仕事ができるとはいわないよねｗ

>>914
言ってはいかんでごわすよ。

スキルのない人間でも最低限のものが出来るのが方法論の良いところ。

この人スリーネーションズリサーチとか言う会社
作ってたがどうなったんだろうか

こんなとこ就職したら休みなく働かされるぞ

今、NRIさんと仕事してるが物凄い優秀な人が多い。
仕事は早いし確実だし提案力もある。

しかし欠点が２つある。
１．仕事終わらせてさっさと飲みに行ってしまうので、夜、質問ができない。
　　毎日飲みに行くのはちょっと控えて欲しい。
２．単価が高い。もう少し安くならないかなあ。
　　値段以上の仕事してくれてるからいいけど。

>>918
単価に文句あるなら他の所に頼めば？NRIは困らないよ？

>>918
社員乙

毎日飲みに行ける暇があるんですか？

NRIは優秀っていうより真面目って印象だな。
とてもすごいということはない。

おまえら一部の人間だけ見て
良いとか悪いとか会社の印象語るなよ

会社の印象は財務諸表を見て語れ

人間見たところで何人いると思ってんだよ
勝手な印象を会社全体に適用するな

木をみて森を水ですね。

過去スレを読んでいない社員がきました。
ちょっとこのスレに居座ります。

質問があればどうぞ。

925です。

どうやら、誰にも必要とされていないようです。

さようなら。

>>922
それけっこう大事なんだよ。嫌になったからって投げ出さない、途中でやめないってのがさ。

>>921
毎日飲みに行けるが休みはないぞ

>>927
真面目でも使えないやつは一杯いるぞ

>>923
お前働いたことないだろ

ﾂﾏﾝﾈ

ﾂﾏﾝﾈ ﾂﾏﾝﾈ

ここって野村證券のシステム会社？

なんかよくストライキやってるよな、野村證券？総研？どっちかしらんけど。
なんかすぐｸﾋﾞになったりするわけ？

あの行列気になるからきいてみたかった。

よっぽど能力不足な連中が即効でｸﾋﾞきられてるだけなのか、
会社がﾌﾞﾗｯｸなのかは知らんが。。
奴隷稼業やってても首なるくらいなら外資いったほうが断然ましだな。

クビにはならん

何年か前の内定者が内定取り消されたのは聴いた
まぁひき逃げじゃしょうがない罠

どっかのスレで契約社員にされて首になるから合法的なようなことが
かいてあったが・・

新３Kといわれているのもよく分かるね。

社員から契約社員になる人なんて聞いたことないけど

who's idea ? --> 何の罰ゲームだよ！

のむそークビ→美女に電車でお触り→ﾀｲ━━━━||Φ|(|´|Д|`|)|Φ||━━━━ﾎ!!

のむそーなんてこの程度（ｗ

横浜ビジネスパークの近所に住んでる者ですけど、朝五時過ぎまで何フロアーか
電気がついてることが当たり前になってるようですが、フレックスタイムで仕事して
あの時間まで居るんでしょうか？それとも朝まで残業してるんでしょうか？

専門業務型裁量労働制に残業という言葉は存在し得ない。まるまる一ヶ月休もうが、
朝の9時から3日後の朝の10時まで働いても、労使協定で決まった時間働いたとして
扱われるだけ。

上流（ここでは要件定義とやらに絞ってのお話）をやるのは結構なことだけどさ
非常に汎用性があって再利用しやすいデータベースの設計もきちんとやってますか？
まさか詳細設計で実装する人に全部責任転嫁してないよね？

詳細設計で実装する人がやったほうが後々面倒がなくて言いに決まってんだろ
そして詳細設計はもちろん詳細な要件定義も実装する人がやれよな

>>945
仕事汁ｗｗｗｗｗ

上流の仕事もっとバリューあげていかんといかんす

日本のあいてぃーに未来はあるのかね

>944
>非常に汎用性があって再利用しやすいデータベースの設計もきちんとやってますか？
要件による

単一システムでcloseするDBだったらそんなことしない。第2正規化位して終わりにする
複数システムで使う場合は専門のチーム立ててそこが要件の取りまとめする。

詳細設計レベルだとDBの項目定義は終わっているよ

×終わっている
○終わらせる

うるせーよ変態ども

912, 941, 950 は同じ人物ｗｗｗ

難しすぎてようわからん。
設計とかって何よ？デザイン屋気取りか

ITの新３Kって何よ？

デザイン屋もいるし、アーキテクトもいるし、多くの人間がいて
システムを作ったりしてるのよ

ビル作るのと一緒だね。
でも必ず設計どおりできるとは限らんぞw
そこがシステムの難しいところであり、おもろいとこなんじゃ

一週間が・・・


テスト
テスト
テスト
テスト
テスト
テスト
○

の日々〜

>>953
日経新聞によると「新３Ｋ（きつい。厳しい。帰れない）職場」のことだそうです。

女子高生の敵

見方によると味方かもよw

>>957
そうなんすか！よっぽど大変なんですね。

きつい、帰れない、給料安いだよ

いずれにしても最低だわ

Mでないとやってられないっすw

M男さんM子さんたくさんいるわけ

逆にプライベートではSでしょwww

どんだけ〜どんだけ〜どんだけ〜Mよ

>>948
至極当たり前すぎてつまらん。

ぶって、ぶって〜

SIerに内部設計は無理

>>969
内部設計はどこがやるんだよ

ぷろぐらまー

>>970
肺まっくすみたいな奴隷外車。

土方は言われたことをやるだけだろう。

>>972
奴隷に設計任せたら
保守性の低いバグだらけの
とんでもないものができあがってしまう

だからいつも「口ほどにない…」と叩かれる。それがパンチラクォリティ！

梅

梅

梅

梅

梅

梅

梅

梅