プロジェクトの納期遅延について

«前のページへ 1|2|3|4|5|6 次のページへ»

投稿者

投稿内容

taku: ぬし; 会議室デビュー日: 2002/11/12; 投稿数: 918; お住まい・勤務地: 墨田区→中野区

投稿日時: 2004-09-07 11:41

　なんか、スレッドの趣旨からそれてますが・・・。

引用:
未記入さんの書き込み (2004-09-07 10:25) より: そういう会社(あなた)は、SE = プログラマなんじゃないんですか？

　ＳＥはあくまでもＳＥであって、プログラマーとは異なるものです。

引用:
設計技術、実装技術を持っている人間が直接ヒアリングを行うから伝言ゲームが発生せずに、システム開発ができるんだと思います。

　ＳＥが設計技術を持っているのは当然ですが、
細かい実装技術まで持っている必要性はないかと・・・。
例えば、ユーザーさんからヒアリングするときに、
ＳＥがプログラマーのように、ＡＰＩレベルのことまで、
知っていても仕方ないですよね。
又、ＳＥがプログラマーに指示を出すときだって、
そこまでの実装技術をＳＥが持っている必要は無いです。
通常、詳細設計書には、
そこまで細かいことは書かないかと思います。
実装に関して、事細かに記載しないと、
プログラムが組めないなら、
それはプログラマーではなく、コーダーですね。
というか、現実のプログラマーの大部分は、
コーダーでは？

この手の話が為さりたいなら、別スレッドを立ててください。

コブラ: ぬし; 会議室デビュー日: 2003/07/18; 投稿数: 1038; お住まい・勤務地: 神奈川

投稿日時: 2004-09-07 12:17

実装技術の骨の髄まで極めてないと、どこがボトルネックで、ソースのどこに改善の余地が
あって、どうしたら改善できるか　の方法論すら組み立てられん。

スループットの見積もり、あるＯＳに特化した部分の洗い出し、、等々・・実装スキルが無い
場合の逃げ口上に「こういう実装レベルの技術はＳＥに必要ない」と切り捨て、「ＳＥ」と
いう空虚な代名詞をブランド化してプログラマーとの差別化を図り、必要以上の高報酬を得る
詐欺的手法。「できない」事が、さも「優秀さ」をアピールするかのような勘違いぶり。
　そもそも、ＳＥをプログラマーと対比させるだけの為にその名前を持ち出す時点で終わっ
てる。市場の固定観念、常識として金がいいからプログラマーよりＳＥをポジション的に上位
に付け、自己満足のオナニー肩書きにしがみ付いてるうちはソリューションは提供でき
まへんな (ｵﾌﾟ

　業務知識だけでＳＥが勤まるなら銀行員だけで銀行のシステムを「設計」し、最善・最適な
ソリューション (ﾌﾟを自らの手で提供できるだろう。部外者は必要無い。餅は餅屋。

コンパイル後のソースの振舞いも、、アトミックな仕組みも知らず、「取り敢えず設計」
ぐらい「誰でもできる。」

mso: ぬし; 会議室デビュー日: 2003/12/04; 投稿数: 496; お住まい・勤務地: 宮城

投稿日時: 2004-09-07 12:26

msoです。

引用:

未記入さんの書き込み (2004-09-07 09:49) より:
引用:

必ずしも業務知識を持っているとは限らないと思います。
自分が得意とする業種とか不得意とする業種ってのがあると思います。

いや「個人」の話をしているわけじゃないですから。ひとりの SE に着目したら
それは知ってる業種、知らない業種があるでしょう。それは当然です。
でも「会社」として「その業種のことは知らない」って開き直るのはまずいですよ。

うちは、出版業、一般流通、製造(工程管理) などなど、業種別に SE を
とりそろえていますよ。そして、顧客の業種に合わせた SE 選定を行います。
また、新しい業種に手を出すときも、かなり神経を使いますね。

顧客にしてみれば、自社特有のことはともかく自業種に関しては
ある程度知っている SE が来ていると考えるのが普通だと思います。

すいません、意味を取り違えていました。
確かに会社として”その業種はわからない”ってのは問題だと思います。
少なくてもわからないのであれば調査をするぐらいは必要ですね。

でも、たまにそういう無責任なＳＥ（っていうか会社？）も
いるみたいです。
自分がそうならないように気をつけなくっちゃ。

未記入: 会議室デビュー日: 2004/08/12; 投稿数: 4

投稿日時: 2004-09-07 12:48

引用:
ＳＥが設計技術を持っているのは当然ですが、細かい実装技術まで持っている必要性はないかと・・・。

設計技術を SE の専売特許のように言う人がいるけど、プログラマだって
当然、設計技術を持っているんですよ。持ってない連中はコーダーだからね。
SE が実装技術も持っていない、業務知識も持っていない、ということになると
SE は完全にプログラマに劣る存在ということになりますね。

引用:
ＳＥがプログラマーのように、ＡＰＩレベルのことまで、知っていても仕方ないですよね。

こんなこと言ってると取り残されちゃいますよ。現在のプログラミング環境は
ライブラリの整備などが進んで、高レベル API を使った開発が主流です。
ナットやボルト(低レベルAPI)を意識して車(プログラム)を組み立てる時代は
終わりつつあって、ハンドルとかタイヤ(高レベルAPI)を組み合わせるだけで
車(プログラム)ができるようになってきています。業務系プログラムとなれば
それはより顕著で、特定業務にフォーカスしたフレームワークなども出てきて
いますね。細かい実装に気を使わずに済み、業務ロジックの実装に集中できる
環境が整いつつあるわけです。このようにプログラマの負荷が減って、
業務ロジックの実装に集中できるようになってくると、おのずと、SE を介さずに
顧客の話を聞きたい、つまり自ら設計をしたい、という話が出てくるわけです。

引用:
というか、現実のプログラマーの大部分は、コーダーでは？

いや、現実はプログラマをコーダーに貶めている SE が多いということですよ。
分かっていない SE が詳細設計で深く掘り下げすぎるから、コーダーとしてしか
振舞えなくなってしまうのです。たとえば、ある排他処理を行わないといけない
場面があったとします。プログラマとしては詳細設計では「排他処理」とだけ
して欲しいんですね。そうすれば必要に応じて、クリティカルセクションでも
ミューテクスでも選択できる。ところが、実際は SE が昔とった杵柄だか知りませんが、
「ロックファイルをどこそこに作成して処理が終わったら消す」とか中途半端に
実装に口出しする SE が多いわけです。となると、プログラマとしては方法論まで
制限されてしまって、コーダーに徹するしかなくなってしまうことも多いんです。
プログラマの可能性を潰しているのは SE ですね。プログラマが設計もできる、
ということを認めたくないから設計裁量を認めずに、コーダーとして貶めているわけです。

引用:
逃げ口上に「こういう実装レベルの技術はＳＥに必要ない」と切り捨て、「ＳＥ」という空虚な代名詞をブランド化してプログラマーとの差別化を図り、

実は、差別化を図っているのは下流工程(プログラマ)とのあいだだけではなかったんですよ。
本来 SE は、業務のシステム化の前段階において、業務改善提案を行うべき存在なんですが、
最近の SE はそれができない。そして出てきたのが「コンサル」という存在です。
SE は「業務改善提案などのエンタープライズはコンサルの仕事だ。SE がそこまで
できる必要はないんだ。ないんだ。ないんだ。」と自分に言い聞かせているわけですね。

プログラムを組む実装技術も持っていない、業務改善提案ができるほどの業務知識も
持っていない、いったい SE って何をする人なんでしょうね？
え？システム構築の邪魔をする人？うん、それが一番近いでしょうね。

きくじろう: 常連さん; 会議室デビュー日: 2004/09/06; 投稿数: 43

投稿日時: 2004-09-07 15:46

色々なご意見有難うございます。

引用:
えー!? SE が業務知識を持っていると期待しちゃいけないの？うそー？

と私も思っています。特殊な業界知識ならともかく、一般的な販売管理の話ですからね。
ましてやある程度の年齢ならある程度期待しますし、提案も期待します。

特異な業種業態を全て知り尽くすＳＥなんて存在しない訳ですから、当然ヒアリングをしながら業務知識を得ていく訳ですが、そういった場合にコミュニケーションが重要になってくる訳ですね。

引用:

「とりあえず～」や「そんなの当たり前でしょ」「そっちでやってくれるんじゃなかったの？」的に済ませていた分のツケは、確実にやってきます（双方に）。
口では何とでも言えるので、物証（書類）を取ることでしょうか。取っていらっしゃいますか？
期日や数字なども、それぞれ明確にしていきましょう。
# 議事録も、回覧して承認まで得るのがベスト、かな

こういったコミュニケーション不足が双方に不足していたのが、混乱の原因だとは思います。そもそもプロジェクトの運営主体は、発注側が取るべきなのでしょうか？
スケジュール管理やプロジェクトの進め方は開発側でないと分らない部分も多いですし。
今回で言いますと、承認云々、ペンディング事項の確認なども、こちらから言わないと出してこないから困ってしまいます。議事録も最近は全然作ってきません。

現在、仕切り直しということで、委託先が仕様の見直しを行っており、その検証を行っています。
先方の狙いは、そこで承認印を押させて、とにかく区切りをつけたいようですが、仕様の不整合や漏れなどがなんでこんな段階で、という位に発生しております。
下手に印をつくと、バグがあっても「印押したじゃないですか」と開き直ってくる可能性もあるかもしれません。

えんぞ@？: ぬし; 会議室デビュー日: 2004/07/06; 投稿数: 271; お住まい・勤務地: はまっこ

投稿日時: 2004-09-07 16:51

引用:
きくじろうさんの書き込み (2004-09-07 15:46) より: そもそもプロジェクトの運営主体は、発注側が取るべきなのでしょうか？スケジュール管理やプロジェクトの進め方は開発側でないと分らない部分も多いですし。

　プロジェクトの規模/内容等にも変わってくると思いますが、事態を収拾させる為にも
発注側が積極的に関与していくべきかなと思います。
スケジュール管理やプロジェクト運用に土足で上がるぐらいの気持ちで、発注先が嫌が
っても少しでも状況を改善させるためにはやむを得ないでしょう。
# 以前、（訴訟問題まで発展したのかな？）携わったプロジェクトでは収集がつかなくな
# ってしまい、進捗管理から要員計画/マネージメント全ての面において発注先が口出しし
# ていました。（異常といえば異常）発注先の人間が受託先へ常駐しておりました。
# もちろん衝突もかなりありましたねー

お互いが納得するためには、衝突して喧嘩するのもありかと。

未記入: 大ベテラン; 会議室デビュー日: 2003/11/24; 投稿数: 121

投稿日時: 2004-09-07 17:20

引用:
そもそもプロジェクトの運営主体は、発注側が取るべきなのでしょうか？

いえ、基本的にはプロジェクトの運営主体は開発を行う受注側でしょうね。
XP開発では顧客もプロジェクトに巻き込むことを推奨しているけど、
それは「運営主体」としてではないからね。

もしかすると、きくじろうさんはもっと口出ししたほうがいいんじゃないか？
と思っているかもしれませんが、やりすぎは良くないですよ。あとで、
責任を押し付けられる結果になりかねないですから。

「ああしろ！こうしろ！」と(具体的な指示ととれるような内容で)口出しするのではなく
「○○についてはどうするんだ？」という(質問・催促という)形で口出しをして、
具体的な行動内容については、相手側に「△△で□□します。」と言わせたほうがいいです。

相手の進捗の悪さや歯切れの悪さで、ついつい、「○○したほうがいんじゃないのか？」と
言いたくなりますが、なるべく我慢。質問と催促だけにとどめて、なるべく向こうに
行動決定をさせるべきです。責任を負わないためにもね。

たーぞう: ぬし; 会議室デビュー日: 2003/08/08; 投稿数: 317; お住まい・勤務地: お花畑

投稿日時: 2004-09-07 17:49

プロジェクトの運営主体がどこになるかは、ケースバイケースですね。

ユーザ企業のシステム部門が主体となることもあるし、ユーザ企業がシステム開発に疎い場合は受注側が主体にならざるを得ないし。

あるいは、ユーザ企業のシステム部門がしっかりしたものであっても、未経験の新技術を利用した開発を行うような場合は大手インテグレータに頼ることもあります。

«前のページへ 1|2|3|4|5|6 次のページへ»

プロジェクトの納期遅延について

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