半年で１００人月のプロジェクトを管理するには？

こんな規模の開発仕切るの当然初めてなんですが、
何に気をつけるべきでしょうか？

とにかく設計を急がないと、、、、、
これは早い段階で出来る人が３人いるな・・・・

設計を急がないことです。というのは、
設計で失敗をするとバグ取りをする羽目になります。
マジです。ユーザーとシステムの入出力インターフェースと
システム間のインターフェースと、
モジュール間のインターフェースを明確に設計していくことです。
この設計が成功してれば、バグがでても、見積もりに無理がないかぎり、
デバッグに要する時間は比較的短くて済みます。これマジです。
オブジェクト指向設計の真の威力を知るかもしれないですね。

半年で１００と言うことは、１５人×６ヶ月？それじゃ普通の開発だから
１００人月×６ヶ月か？それだと３年目じゃ無理だな。。。。

１００人月×６ヶ月、、、１０年目のベテランでも難しい。

俺は１２年やってるが、ちょっと引くな。１００人いると、頭おかしい奴が２０人くらいはいるからな。
中国人も１０人くらいいるだろうし。いつのまにかメンバーが変わってる外注も３０人位は混じってる。

４年目ですが、15人＊６ヶ月でも、十分ひきますが何か？

早速ありがとうございます。

>>2さん
先輩にも言われました。やっぱり設計急いじゃダメなんですかね〜。
なんせ経験が少ないもんで、不安で不安でしょうがないんですよ。

とりあえず、アウトプットからインプットに向かってさかのぼりつつ、
システム間、モジュール間のインターフェース、テーブル設計を
進めていくつもりです。

>>3さん
１５人×６ヶ月です。普通の開発です。
実際には設計を１５人でやるわけには行かないので、
最終的にはもっと人数が増えると思います。

ただ、この人数に一度に仕事を振ったことが無いので、、、
まずは基本設計段階で数人に設計を投げることになりそうですが、
サブリーダーとのコミュニケーションが不安です。
皆様はなにか気をつけてることってありますかね？

自分は１１年目だけど、１５人×６月なら３年目でも出来るんじゃないかな〜。
（自分とこも３年目位からその程度の規模はやらしてるし･･･）
その開発の難易度が解らんが、３年目でその規模が未経験だと、サブリーダーに
まともな奴を揃えないと難しいかもな？
ちなみに自分とこにいた３年目の小僧は、サブリーダーの人選を誤ったため、開発が
難航して、いやになって出社拒否して山奥へ逃亡したし、挙げ句の果てに信仰宗教に
入ったやつがいたからね。

でも、自分が一番気を付けないといけないのが、ユーザーだと思ってる！
ユーザーは強敵だよ！
ユーザーはリリース直前でもシステム全体にかかわるような仕様変更を
平気で要求するからね。

>>8
リリース直後に
「システム全体にかかわるような仕様変更を平気で要求する」
可能性が大かと思う。

3年目で15人×6月が普通? マジで?

多分俺はできんな〜。そろそろ3年目。

>>8,9
業務分析が甘いとそうなるね。(特にユーザー主導型)
各情報の発生場所と伝達方法が項目別にしっかり押さえられていない場合が殆どですね。
まずは、原因を探し現状との相違点を的確に洗い出すことが必要。
それと時間を無理にでも捻出し再度不足個所の業務分析をする必要がある。

取敢えず、現状のままカットオーバーしてしまうのが正解。(全く制御が異なってる場合を除く)
変更部分はその後に投入しないと痛い目みるよ。

皆様貴重なご意見ありがとうございます。

＞仕様変更
多かれ少なかれ、リリース直前・直後での仕様変更は必ずあるものと
覚悟しています。当然>>11さんのおっしゃる通り、業務分析をしっかりやるのは
大前提ですが、当然納期がありますので完璧には出来ない場合が多いと思います。

自分が気をつけているのは、
「客の決断したことについては必ず文書化し、客の責任者に認証印を押してもらうこと」
かな？
これをやっとくと、金額、納期の面で有利に交渉できますからね。
>>11さんのおっしゃる通り、別注文、別納品に出来ればほとんど問題は
クリアされますから。

＞サブリーダー
実はこれが一番心配。
プログラマとのコミュニケーションに問題が出てくる程度なら乗り切れると
思うんですが、サブリーダーとのコミュニケーションに失敗すると取り返しが
着かないと思うんですよ。
それこそ>>8さんの後輩さんの様に・・・・

現状、サブリーダーに誰がつくかは全然見えていません。
皆様でしたら何を準備しますか？
引き続きご意見をお聞かせください。

時間のかかる順
[設計]=[テスト・デバグ]>=[仕様決定]>[製造]
これと違う不等式でプロジェクトが成功したら人材やお客、
運の良さに感謝すること。

顧客との認識違い防ぐための機能仕様書だよ。
仕様変更があったら、顧客都合なのだから
納期の引き延ばしは普通できるはず。
設計がしっかりしてれば仕様変更など問題にならない。
設計書をたどれば、どこを修正すれば良いのかが
はっきりわかるから。
それに元づいて納期を延ばしてもらえば良いです。

>皆様でしたら何を準備しますか？
設計を失敗を最小限にするため
使うツールのアーキテクチャを理解してる人間を見極める。
システム設計時に余った人材にやってもらう内容を準備する。
補助ツールの選定・開発環境の整備・ツールの理解のための課題など。

SEXを急がないことです。というのは、
SEXで失敗をすると結婚をする羽目になります。
マジです。ナオンとオトコの入出力インターフェースと
前戯と、エッチ後の後戯を明確にしていくことです。
このエッチが成功してれば、SEXが下手でも、セイーキに無理がないかぎり、
SEXに要する時間は比較的短くて済みます。これマジです。
大人のｵﾓﾁｬの真の威力を知るかもしれないですね。

>>12
普通の顧客にそんな態度に出ると、責任とらされるのを警戒して
「本件に関する決定に対して万一変更が発生した場合にも
柔軟かつ迅速な変更対応作業が出来るように設計します。」
と追記させられるよ！。

>>16
>>1の会社と顧客との力関係によるよ。
３年目で100人月ってことは、それなりの規模の会社にいるで
あろうことは推測できる。まともなSIerならデスマーチに陥ら
ないための歯止めぐらい考慮しているんでない？また、外部設
計以前のフェーズについては請負ではなく支援で入るってのが
基本だと思うYO。うちはサービス仕様書と基本仕様書はお客様
がオーソライズすることになってるね。
中小、零細で泣き寝入りしてるとこも知ってるけど、言質取っ
とくのは当然の自衛手段さ。

>>1

　で、今どうなってるかな〜？

比較的短期決戦みたいなので、進捗管理とかの状況把握の
仕掛けをきっちりまわるようにすることも重要だろうね。
以外と無意識でやってるとこあるから。途中で形骸化しがちで
なかなか最後まで機能させるには、それなりの細かなアナウンスが
必要だから。
セオリどおりだけど進捗なら最低１週間レベルで問題発生なら即日レベル
でトレースできる仕組みと、できればソース精査能力のあるサブ頭が２人
は欲しいところでしょう。
ほぼ間違いなく製造中・後の顧客変更要望は発生するので、対応する・しないの
仕分けレベルの方針を顧客とイメージを共有化しておく必要もある。
最初から予防線をはるのはあまりやると野暮。
勿論、製造行程の1割ぐらいは、そうしたバッファとしてよゆう含みで
線表を書きたい。計画が延長せざるおえないクリティカルパスがある
はずなので、それをメンバーや顧客に「まっとうに終わらせるための
前提条件」として焼き付けることが重要だとおもう。マスタースケジュール
も３者（顧客・リーダー・メンバー）で共有できてないではしってる
PJが意外とおおいんですよ。

みなさん紹介します。新メンバーの「王」さんです・・・

てゆーか6ヶ月で100人月ときいて15人×6ヶ月とかいってる奴はエセSEと思われ。

>>21

15*6=95 ≠ 100　だから、計算もできね〜ばかって意味ですか？

（マジ質問します）

ﾜﾗﾀｰﾖ

のちあげ

>>22 ちがいます

>>２１

　説明してくれよ。

　（マジ不明）

>>26
>>3に模範解答があるでしょうに．．．

これからはツマラン突っ込みは無視しましょうね。

終わってね

　　　　　∧∧　　ミ　＿　ドスッ
　　　　 (　 　,,)┌─┴┴─┐
　　　　/'　　　つ 　　終了　│
　　〜′　/´　└─┬┬─┘
　　　∪ ∪　 　 　　││　_ε３
　 　 　 　 　 　 　　 ゛゛'゛'゛

15人×6ヶ月と言うシステム規模がぴんと来ない。
分析設計フェーズも含めて６ヶ月で納品なら、分析設計で３人＊２ヶ月
先行開発最初から始めても３人＊６ヶ月準備万端整って人を集めてドバ
と開発するのが１０＊２ヶ月。テストに１０人１ヶ月
全部足すと、５４人月。この辺りが６ヶ月の限界かと思うのですが？

ずーっとお付き合いのある企業で、サブシステム開発なら、まぁありえるけど
そう言う場合は、君なんかが、仕切っていると思っているのは、
ちょっと…（藁

>>22
15*6=90だがそれはともかくとして、
要件定義とか検収フェーズとかに、製造と同じ人数はいらんだろ。
特に要件定義は客の都合があるので、
こっちの人数増やしても早く終わるとは限らない。
最初から１５人突っ込んで人件費使うと後で泣くぞ。
そんな開発計画は通らんと思うが・・・

このスレ。

ROMったけど、29や30の疑問は漏れも感じていた。ドキュソだから、
どう表現すればわからなかったけど、フェーズ毎のリソースの突っ込み
かたはかなり違うよね。29に禿同なんだけど。

あと、後ろが決まってる仕事やしゃれですまない仕事はリソースの質も
考えないと。「ドリームチーム」が必要な場合もあるよね。重要度はどう
なのだろうか？単純に15*6=90と割りきれる仕事だろうか。
テンプPGだけ適当にそろえればいいのだろうか。社内外の精鋭をかき集め
る必要があるのかとか。

まあ、尻拭い的な仕事にドリームを投入するのは、士気やそのほかの開発
に影響するからできるだけ避けたい。

と疑問がいっぱいありすぎて、想像がつかんなぁ。6ヶ月100人月って
いう数字が。どうも後ろが決まっていて尻拭い的に見えるのだが…。

かわいそうに、デスマーチか・・・

ご無沙汰してます。
貴重なご意見ありがとうございます。

公共の場に晒すリスクを考慮すると
詳しい状況を書けないのが歯がゆいですが。。。。
やはり言葉不足ですよね。

要件定義は一通り完了しているとお考えください。
工数を算出する段階である程度の概要はつかんでいます。
自分が任せられているのは社内的な仕切りです。

ぐふ・・・
リソースが足りん・・・

リソースが足りない時は、要求を切る。
ってモロ切っちゃいろいろやばいから、見えないナイフで切るんだよ。
がんばれ。

>>35
なんか深いッスねそれ

>>1
ほぼ２月たちましたが、何人月消化しましたか〜？


　　　　　∧∧　　ミ　＿　ドスッ
　　　　 (　 　,,)┌─┴┴─┐
　　　　/'　　　つ 　　質問　│
　　〜′　/´　└─┬┬─┘
　　　∪ ∪　 　 　　││　_ε３
　 　 　 　 　 　 　　 ゛゛'゛'゛
（ききたい・・・）

今度（株）アシストのプロジェクト管理研究分科会
http://www.ashisuto.co.jp/kka/solution/bunkakai2002/main.html
に参加し、「管理者向け｣と｢ナレッジマネジメント｣をキーワードに
「システムのプロジェクト管理に対する品質管理面でのアプローチについて」
研究しております。よろしくお願いします。

設計表記法はUMLで。開発プロセスはRUPで。この技術で全員巻き込め。
シアワセになれるぞ。たぶん。

>>35
見えないナイフですか。イイ表現ですね！
見えないナイフのつもりが諸刃の剣になったりして・・・・はう。

>>37
約６人月です。

>>38
今は余裕がないので、ちょっと参加できそうもありません。
このプロジェクトの結果が出たら経験談をお話しできるかと思うのですが。
(そのころ、どうなってるかな？いい方向に想像できない自分が悲しい)

>>39
UML、導入してます。
RUPは私自身、まだ理解できておりません。
お勧め書籍なんて、教えていただけませんかね？
今からでも部分的になら導入できるかも。

ちなみに納期は２ヶ月延びました。感謝！

「半年で１００人月のプロジェクトを管理するには？」

答えの欲しい人は先ず、■プロジェクト管理　で欲しいツール■
http://mentai.2ch.net/test/read.cgi/infosys/1009417487/49
をクリックして下さい。

おいおい。
これじゃあ終わっちゃうよ

1は神

いや、■プロジェクト管理　で欲しいツール■で教わったところ、XPが神らしいよ!

>>41,44
強引な誘導はやめれ

では、代わりの答えをキボン

「半年で１００人月のプロジェクトを管理するには？」
ふつうに管理すれば？
なにが問題なの？

人さまざまだと思いますね。私自身は特定の問題を提起するスタンスはありませんが、
このスレで多くの人からいろいろな問題を教えていただくことは勉強になります。

>>48
>>41, >>44 で強引な誘導をぶっこいている輩が
「私自身は特定の問題を提起するスタンスはありませんが」とは
片腹痛い。
(･∀･) ｶｴﾚ!

だからア、汎用的な解答を求めることに興味があるんですよ。
皆さんも、それを求めていらっしゃるのではありませんか？

例えば、片腹が痛かったら病院へ行くとか、、、

>>50
だからア、(･∀･) ｶｴﾚ!
このスレは、「半年で１００人月のプロジェクトを管理するには？」 という
特定の問題に直面して苦しんでいる１さんを励ますスレなんだぞ。

「多くの人からいろいろな問題を教えていただくことは勉強になります」
なんてとぼけていないで、おぬしも自分の経験を活かして
なにかアドバイスするといいのだがなぁ。

>>42 さんが言うように、バサっと切ってスレを終わらせようとしないでヨ。
"このスレ見れ。これ最強。おしまい" みたいな強引な誘導ではなく、
"最近、どうよ？　あの件は、どうなった？" という盛り上げ方が必須。

>>このスレを支持してくださってる皆様
ありがとうございます・・・(T.T)
これからも可能な限り状況を報告させていただきますので
こんな自分をかまってやってください！！

>>中葉様
と、いうわけで棲み分けと行きましょう！！



Ａ：とりあえず直近二ヶ月はこんなスケジュールで行きましょうか。
Ｂ：そうだな?。今想定できるのはここまでか。
Ａ：あとは外注の顔が見えないと具体的にはスケジュールが組めないですよね・・・
Ｂ：いいんじゃないか？このペースだと納期に間に合いそうだし。
Ａ：はあ・・・。かわいい娘こないっすかねえ。
Ｂ：そうか？俺は出来る人の方がいいぞ！？
Ａ：じゃあ、かわいくて出来る人！！
Ｂ：いや、それも微妙だな・・・・
ＡＢ：はあ・・・・

最近はこんな感じです。(^_^;)

がんばれ>>52！
今何人でやってるん？
要件定義は1月の時点でおわってたんだよな。
基本設計おわったか？

かわいい女の子の外注をよこせといい、セクハラを楽しんでいる
御仁が多いようで。うらやましい限りですな（W

１０人月も１００人月もやり方は同じでしょう

15*6と1.5*6はまるで違います。
前者は管理しなければいけないし。後者は自分で子分を使ってやれます。
工数だけで5000万強、新規ハード別立てだったら億...ま3年目はネタですね。

１００人月　５００万？　安いね
どこの会社？

プロジェクトのやりかた知っていたら１００人月も１０人月も大きく変わらない
別に子分でなくても　　５６はもしかして自分でしないと納得できないタイプ？

だったら早く脱却しないと　リーダになれないよ

確かに１００人月（ホントは１５＊６で９０人月だけど）
で５０００万って安すぎない？
単純計算で５０万／人月って計算になっちゃうよ

漏れのいたとこは某ユーザー系で１１０万／人月
その下の請負開発会社（よくこの板でたたかれてるけど）
でさえ、７０〜８０万／人月だったと記憶してるが・・・

>>57
>プロジェクトのやりかた知っていたら１００人月も１０人月も大きく変わらない
>別に子分でなくても　　５６はもしかして自分でしないと納得できないタイプ？
その意見には同意できないな。１０人で１カ月なら確かにそうだけど、
56が言ってるのは１．５人で６カ月。つまり自分が主担当者で
誰かのサポートが入るというかたちだろ？だったら自分でやるしかないじゃん。

しかし、３年目で半年１００人月ってネタではないにしても正直厳しいね。
漏れが３年目の時は、半年３００人月のプロジェクトの中の、半年５０人月
部分のリーダーをさせられたが、それでもつらかったね、実際。
担当者兼任だったから

をを・・・こんなに反響が・・・

>>53
基本設計はだいたい終わりました。今は３人です。
まあ、はっきり基本設計を枠で決めていないので
だいたいとしかいえませんが。

>>金額
詳しいことは書けませんが、
億は超えてますよ。

ちなみにほんとに３年目です。
今度４年目ですが。
本当の意味でのリーダーは無理なので、
実際、いろいろ先輩にサポートしてもらってます。
すごく勉強になる・・・ありがたいです。

>>59
要件定義が終了しているのであれば、後は簡単です。
唯、ちょっと気になる点があるとすれば「はっきり基本設計を枠で決めていない」
ってとこでしょうかねぇ〜。
それと大きなプロジェクトを完結する為に重要なのはサブリーダとの思考統一なんですわ。
貴方とサブリーダ間の意思疎通が正常に機能すればそれ以下は貴方の管轄外となり
サブリーダが以降を仕切ってくれます。

# サブリーダ間との摩擦を意識するあまり「枠で決めていない」又は
# ユーザー間との摩擦を意識するあまり「枠で決めていない」ってことなら
# 危険度が上がりますから注意が必要です。
# 今、貴方に必要なことは、「嘘でも枠を決める」ことなんです。
# つまりは目標を定め、ルールを確立するってことです。
# 「嘘」は「嘘」だと公言することにより問題は明確になり「嘘」を規定して
# いる訳ですからそれなりに規則正しく「嘘」が反映されることになります。
# この「規則正しく反映される」ってことが「嘘」を「真実」に置き換える工程
# で役にたってくれるでしょう。

56だけど58さんの言うとおり。自分＋誰かの支援で6ヶ月のjob(おそらく最も楽)と
述べ15人のチーム持つのはまったく別の世界。

3年目ということなので、Web上で詳細設計&ＰＧ主体。物は改造＋機能追加ベースで
システムは作り捨てと読んで5000万強と書いたんだけど、億越すなら違いますね。
こりゃまともな案件だ、確かにきつそうだな。
よくわからないな、普通3年目の下に付くのならプログラマーレベルだろうし
どんなチーム構成なんだろうか？

http://www.atmarkit.co.jp/fjava/devs/process01/process01.html
従来の開発プロセスと現場が抱える課題

>>62
それって全ては、技術者の技量不足に起因する事象ばかりであって「開発プロセス」が
間違ってるわけじゃありません。
結局、未熟者に未熟者の為の課題であり処方箋であることを理解してや。

それから、
新しいアイデアとは、新しい場所に置かれた古いアイデアのことだ。
「仕事は楽しいかね？」より
http://www.books-ruhe.co.jp/kako/2001/12/shigotohatanoshiikane.htm
とか、
http://www03.u-page.so-net.ne.jp/dc4/tnaka/fowler/newMethodology_j.html
新しいソフトウエア開発手法
とか、ワインバーグの「スーパーエンジニアへの道」とか
http://www.chienowa.co.jp/frame1/books/Weinberg.html

ピープルウェア 第2版 も良さそうですね。古い友人の松原友夫さんが訳している。
http://www.fukkan.com/vote.php3?no=1366

評判はいかがですか？それを聞いた上で買うかどうか決めようと思います。

所詮、肉体労働者、電子芸者、なのだが、
ワインバーグとかデマルコの著作を読むに連れ、本当の経営ってものを
考えてしまう。何故に経営学の分野からこのような良著が現れないの
だろうか？

>>65
古い友人にお尋ねになるとよろしいかと。

出張32氏に同意するとは、思ってもみなかったけど、確かにどんな手法かが問題じゃなく
誰がやるのかが問題なのかもしれない。

でもせめて銀の弾丸じゃなくても、フールプルーフな開発手順って無いかと思うことは有るな。
ゼロサムゲームのミニマックスじゃ無いけど、システム開発のゲーム値って決まってて
それ以上の利益（金銭だけじゃなく効率とか納期の縮小とか、誰かの利となるものすべて）を
求めれば、リスクの増大は免れないのかも知れない。

で戦略としてリスク最小を選ぶ考えはあるわけで、それに特化した開発手法は、有っても良いような気がする。
つうかそれ（基準値）がないと自分の戦略がどのくらい欲張りなのか、どのくらいリスクがあるかわからないんだよね。

まーそれでも碁・将棋に名人とへぼが有るように、戦略の実現では大きな差がつくんだろうな。

>>68
旧開発手法にも問題点はある訳だけども全てが不味いってことじゃないです。
「試行錯誤的」開発は目標が設定し辛く工数も事前に読めない為スケジューリング
すら絵に描いた餅に成り得てしまう。
かといって、旧開発手法だと「いわゆる痒いとこに手の届かない設計」になる要素を抱えて
いる訳ですから昨今のニーズに合わない場面が多いのも事実なんだわさ。
実装工程でのＸＰ手法導入(部分的)等は上記の問題点を補う上で有益だとも言えますね。

このスレをそのまま今年の新人研修の
マニュアルにしてもよろしいですか？

>67 古い友人にお尋ねになるとよろしいかと。

コメント深謝します。本人はほめるに決まっているので、裏を取りたいのです。
著者や訳者でなく、読んだ人、ユーザーの評価を知りたいのです。

>66さん、その意味でありがとうございました。

age

なんか手法とか色々書いてあるけど，まぁ手法はいろいろとあるのは確かだと思う．でもプロジェクトこれからやろう
という人間がこれから手法を覚えるようでいいの？俺は>>５５ですが工数が多かろうが少なかろうがやり方は同じ
確かに少ない工数だと自分の気心が知れた仲間でできるかも知れないが，それは単に自分の作業の怠慢でない？
多くのＳＥがいてもいなくてもやり方同じでないと．設計工程で全ての仕様を決めること此れは当然のこと，少ない工数
でも多くの工数でも設計工程で仕様をつめないという事はそれ自体が間違っている．
製造工程でも進捗の管理する方法は同じ．

俺が言っているのはやり方を知っていれば多くの工数でも別に怖くない．
但し稼動までの時間は工数に依存するし，資料の量も工数に比例するし．でもやり方は特に変えていない．
でかいプロジェクトするといかに自分が今までサボっていたか自覚した．それを知ってから少ないプロジェクトでも
同じようにしたらうまくいった．

確かにしょぼい兵隊ばかりだと管理は疲れるが．

ところで１００人月って大規模プロジェクト？

＞多くのＳＥがいてもいなくてもやり方同じでないと.
単なる信念表明に聞こえますが。

＞設計工程で全ての仕様を決めること此れは当然のこと
要求仕様決めの難しさ、途中で出てくる仕様変更要求など考えると、
「ウォータフォールは絶対真理だ」って主張するのは単なる信念表明ですね。

>>73 は、例の学生さんでしょうか？
　　背伸びしないで、ご自身の身の丈に合った開発方法を模索された方が、
　　よっぽど有意義だと思いますが。

ウォータフォールだろうがプロトタイプだろうが
やり方知っていれば一緒だと思う．

どのやり方するかはその時に決めればええんとちゃうの？

>>75
相手にするんはあほらしいんでやめよか思ったが
批判するだけやったら誰でもできるんやで．まぁ掲示版なんで
どうでもいいが，まぁだいたいどのプロジェクトでも文句だけいう
奴にろくなんおらん，所詮批判しかできひんレベルなんやね
かわいそうやね．

>>76 違います。

批判はしていないが。被害妄想？

>>74
> 要求仕様決めの難しさ、途中で出てくる仕様変更要求など考えると、
> 「ウォータフォールは絶対真理だ」って主張するのは単なる信念表明ですね。

それは技術レベルの低い方のセリフですわ。
「要求仕様決めの難しさ」なんて言ってるようでは半人前です。
「途中で出てくる仕様変更要求」なんてのは守備範囲で無いとおかしいですよ。
守備範囲(予想範囲)を超えてるのならば、概要設計で顧客との共同歩調が取れていない証拠ですわ。

# ちょっと厳し過ぎたかな？

出張32って　一人の人？　なにもん？

漏れの知ってる、頭のいいほうの出張さんとは別人だと思う。

頭いいほうも悪いほうも知らん

＞「途中で出てくる仕様変更要求」なんてのは守備範囲で無いとおかしいですよ。
だから「手戻り」とか「要求仕様変更」をあらかじめ織り込んだ、
プロトタイピングなり、イテレーションが必要ですね。

ウォーター・フォールは、1970年代に考案された、現実の開発プロセスの一次近似/理念でしかない。

>>80
色々と噂されてるようだけど、一人ですよ。
まあ、可也以前に数回程度騙りさんが居たようだけどね。 (職なくしたとか言ってた奴ね)

それと私はＳＥです。

# 設計者で在るならば、概要段階で読み切って欲しいなぁ。
# オブジェクト指向でやるにしても機能が読みきれなければ機能特化を適性にすることなど
# 不可能であることを知ってくだされ。

どうも理論武装はされているようであるが
実際の現場でバリバリしてるひと？

>>82 出張３２スレに書いたように
　「出張３２」は情報システム板の「ネタ・キャラクター」ですわ。

>>83
プロトタイプは性能試験で使用すれば宜しい。
つまりは、限定利用で目的は、内容によって「概要決定試験」と「詳細確認試験」に分れるだけのこと
結局、基本は何も変わらない。

偉そうな文書を書くときには出張３２って書けばええの？

まぁ、ばれないようにほどほどにねー。

ついでだから>>73の発言に対して感想を一言付け加えて置きます。
基本的に73の言ってることは正しい、但し大規模なシステムになると概要設計までしかコントロール出来なくなります。
勿論、サブＳＥへの指示は的確に行うにしても、そこから先はサブＳＥの技量次第となるので結構大変なのよ。(判ってるとは思うけどね)

>>90
あたりまえやん　いつもいつも有能なサブが付くとは限らん
だからサブがどういうその下をどう管理するかやり方提示すればええやんか
守らんサブやったら外せばええし．

サブの技量に頼らざるを得ないこと自体　管理者が未熟ってことやんか

>>91
人材は有限なんですわ。
そこを理解せんとダメねぇ。

>>90 >>91 のおっしゃっていることは、理念の表明であって、
　それを裏付ける技術が伴った発言には聞こえないのですが。
　ここでいう技術ってのは、
　いわゆる「SE技術」
　つまり事務系中心の大規模開発における「プロジェクト運営」技術
　の事でしょうかね。

>>92
つまり　自分の周りには限られた人材しかおらんって事やね

俺は別におらんでも気にならん，おらんかったら育てるから

>>94
それじゃ間に合わないよ。
そうでは無くて、集まる技術者のレベルに応じた手法を取るのが正解です。
その結果、工数が御高くなるのは現実で仕方ないことなんだわさ。
所詮は総合力ですからね♪

>>95誰も　アクティブなプロジェクトのサブを育てるなんて言ってないがな
２年３年先を見越して育てる．

なんかよっぽど恵まれてへんプロジェクトやってるんやね
工数が高くなる？現実で？　ええ言葉やね．俺も言ってみたい．

所詮は総合力って　何か理論的な人やと思ったが　結局は人頼み
ってことなんかいな

>>96
ありゃりゃ、全くお話が通じないとは思わなかったわ。
こりゃ、私の見込み違いでした。(スマンね)

まあ、君なりの視野で頑張って下され。

>>93
> ここでいう技術ってのは、
> いわゆる「SE技術」
> つまり事務系中心の大規模開発における「プロジェクト運営」技術
> の事でしょうかね。

さあ？
君の頭の中が見えませんのでお答えのしようが御座いません。
設計者に必要な技量を知りたければ、そこらに落ちてる手法論関係の本を読んで下され。
そして、妥協と思われる個所は必要能力と考えて貰えればそこそこ理解出来るやに思いまする。

＞大規模なシステムになると概要設計までしかコントロール出来なくなります
って事なので、このスレで「技術」というのは、
「要求をまとめてシステム化する(概要設計を書く)技術」＋「プロジェクト運営」技術
かと思いましたが。

俺>>96　>>93とは別人

俺の個人的な意見かもしらんが>>97の出張32の
言ってる事って　わかる人いるのかなぁ〜？

まぁ俺の頭わるいだけなのかもしらんが

ただ出張３２に賛同する人っているのかなぁ？
多分少ないような気がする．
俺と同意見の人の書き込み期待します．

出張３２に同意する人でもええが

>>98
> 「要求をまとめてシステム化する(概要設計を書く)技術」＋「プロジェクト運営」技術
> かと思いましたが。

「プロジェクト運営」技術の意味合い次第ですわ。

出張３２専用のスレあるやんか

この人って有名人？
でもこんなに書き込みあるって　仕事してるん？
書き込みが仕事？　てっきりバリバリ現場に出ている人やと
思ったのに　単なる頭でっかちの使えない奴なんか？

>>101
真に出来る人は時間に余裕があるのよ。
そうでないと戦略を考える時間が無くなっちゃうからね。

ここでの会話は頭のリフレッシュですわ。

>>96
育てるという意味では同意。
ただ、アクティブなって話しになると出張３２に同意。
育てるにしてもそれなりに総合力がなければ
育てるどころの話しではない

>>102
自分で言うか　まぁそういうことにしときましょう
なんか真面目に考えた自分があほらしなった

>>103の人もまともに相手せん方がええかもしらんで

>>104 それほど変だともおもわないけどね。

　　単に、意見が違うだけ。

>>104
礼儀を忘れてしまえばそれまでですよ。
ですが、もう少し冷静に読むことをお薦めしとくわ。

設計者たる者、個人プレーであってはいけない。
結果として顧客に被害を齎すのは愚かですからね。
自分の置かれた環境を考えてお仕事するのがプロってとこね。

ご自由にどうぞ

>106 設計者たる者、個人プレーであってはいけない。結果として顧客に被害を齎すのは愚かですからね。

設計者マンセー!　みずほグループにもこういう設計者が欲しかったね。

でも>>106みたいなんがおると
モチベーションさがる

でも設計者の技量を考えた見積りはお客さんには出せんよなあ。
それに見積り出してから要員をアサインする事も多いし。
１回出してしまった見積りで何とかするのが、
ある意味腕の見せどころだと思うよ。

>>109
モチベーションあげとくのとこれとはまた別の事だろう。
たとえ同じ内容の考え方、言ってる内容でも、
言い方、雰囲気作り次第で全然変わってくる。

>>111
まぁ実際に出張３２みたいなんがおったらモチベーション下がる
でも実際にはこんなんはおらんし　おったとしても上がまかせんやろうし

ほんま自分の周りにおらんでよかった

まあ、若者が希望に燃え主義主張をしている処に水を差すような
発言の数々ではモチベーション下がるわな。

助言はその先にあるのだけどね。

お互い、その先まで命があったらね。

でも普通は、老人が先にくたばり、希望に燃えた若者の燃え滓が後に残り、
舞台は最初に戻る。

回る、回る、回転木馬。人生、面白いような、面白くないような。
何じゃ、これは？

>>110
国産牛肉1Ｔ受注したけど、それから仕入れようと思ったら、
外国産しか無いし…

>>114
そんな先の話しじゃないだろ。

>>115
腹痛いほど笑えた。
でもそれも現実。
採算はとれても納期がなあ。。。。

そうですね。人生が終るのは、そんな先の話しじゃないですね。

>>117
いや、ていうか。
その助言っていうのは数時間後、数日後、或いは数ヶ月後っていう事で。
助言するタイミングの事。

age

サゲテ