アカウント名:
パスワード:
穿ったコメントが多いけど,上から目線で見れば裏も表もない本音ではないでしょうか。内製でなければトラブル(納期延伸とか社外事故)のときに身動きが取れませんから。
「おい,君,例の事故,どうなっていいるんだ?客が怒鳴りこんで来たぞ。」「すいません。下請けに逃げられてしまって。ほとほと困ってます。」「困ってますじゃないだろう。どこにやらせたんだ。呼びつけろ。」「A社なのですが,契約が切れていて。どうにも。」「うちで直せないのか?」「ソースコードを貰っていないので無理です。」「やれやれ。とにかく,早くどうにかしろ。」「はい。次の案件をちらつかせながら,どうにかA社におねがいしてみます。然し,何にせよ,相手次第なので。」
「おい,君,このプロジェクト,いつになったら閉じるんだよ。ずるずるずるずる,いつまで伸ばす気だ?」「すいません。下請けのB社のスキルが低くて。ほとほと困ってます。」「バグの件数が青天井だ。いったい,何をやっているんだ。」「どうも,すいません。」「うちから人を出して指導することは出来ないのかね。」「それをすると偽装請負いになってしまいますので。」「そもそも,なんであそこを使ったんだ。」「金額の都合であそこしか無かったのです。明日,B社に行って社長を怒鳴りつけてきます。」「しっかりしてくれよ。」
中間管理職はこういう言い逃れ(時間かせぎ)をするので。
「若いときにはプログラミング」というのも当然ですね。プログラミングを知らずにプログラミングを管理するのは無理だし,プログラミングする人を管理,あるいはプログラミングする人を管理する人を管理するとしても,自分でプログラミングを知らなければごまかされても分からない。年を取ってからもプログラミングで食って行けるなどとは言っていません。
>中間管理職はこういう言い逃れ(時間かせぎ)をするので。
原理的には、言い逃れになってないようですが。そういう言い訳はよくあるのでしょうが、「言い訳」としては、中間管理職の上から、スルーされると思います。
要するに「遅れてる」こと自体の言い訳になってなくて評価を下げてることだけは間違いのないところでしょう。
時間稼ぎにも、実際にはなってないと思いますけどね。。だって実際に遅れてるわけで、その「遅れ」に対する対処じゃないのは誰の目にも明らかでしょう。
>「若いときにはプログラミング」というのも当然ですね。
そういう方針自体は否定しませんが、、、上から目線の単なるコーダーって意味あるんですかね。
だって失敗しても「自分の仕事じゃないよね」と思える環境なわけでしょ。そんな環境で自分の力として蓄積できるとは思えないんですが。
私の経験からいうなら、ひとつの「意味ある」(と思える)仕事を任されて成長するものだと思いますが。
NTTデータぐらいの規模の会社ならば、もうそこら辺は無視していいと思うのですけど。。。
どっかのゼネコンでも、そんなことはしないのでは。違うのかな。
もはやSIerとしての、「管理」能力を付けるか。プログラミング全般の「開発」能力を付けるかはは分断していいと思ってるのですが。
> 原理的には、言い逃れになってないようですが。
遅れに対する処置になっていないから「言い逃れ」なのです。会社が違えば思い通りにならないというのは常識です。では,なぜ敢えてリスクを冒して外注に出すのか。リスクとコストのトレードオフです。多数のプロジェクトを外注に出して利益を上げている中で,特定のプロジェクトが火を吹くのはやむをえないというのは常識的な思考です。でも,NTTDの社長は,それは良くない,コストを抑えたまま内作にしたい,そのために製造工程の自動化や海外拠点に投資すると言っているのです。
> 単なるコーダーって意味あるんですかね。
プログラミングを経験するのは有能な管理者になるための手段ですから,有能なコーダーになる必要はありません。むしろ,プロジェクトを爆発させる方が後のために良い経験になるやも。それを自分で鎮火させなくても良い。鎮火させる能力を持っている人を探し出して丸投げするのが有能な管理者の心構えです。あるいは,追い込まれたきにテストをサボるということを身を持って知り,その手口を覚えることも大事です。
>コストを抑えたまま内作にしたい,そのために製造工程の自動化や海外拠点に投資すると言っているのです。
ふ~ん。て感じですね。お手並み拝見という感じですか。私自身は懐疑的ですが。
製造の自動化は、単なる夢物語だし海外拠点に投資した場合の投資効果は、実際のところ不明だからです。
>プログラミングを経験するのは有能な管理者になるための手段ですから,
???それがよく分からない。それだと、プログラミングをなめてますよね。「プログラミング」は表面上で文法をなぞったって「出来た」と言えるものではありません。「経験した」とさえ言えるかどうか怪しいです。
通常、「プログラミング出来た」と言えるのに10年ほどかかります。しかも、ただ10年過ぎればいいってことではありませんし。
>あるいは,追い込まれたきにテストをサボるということを身を持って知り,その手口を覚えることも大事です。
追い込まれたきにテストをサボる理由自体は小手先のものではありません。本来必要なテスト工数を削ることで「追い込んで」いるのだから、その意味では、どんな手口を使ってもサボることになります。その多様さはありとあらゆる理由が付きます。
本質的には「追い込んではいけない」と肝に銘じるべきであって追い込んだ後の手口なんぞ覚えても無意味です。
個々のことはともかく、プロジェクトマネージメントはまず「王道」が重要で、プログラミングなどの小手先の技術を自らがやってみる必要があるとは思えません。
しかも単に自分(PMは全責任を持っているのだから、部下の見積もりミスは自分のミスなのだ)がテスト工数を見積もれなかったからと言って「追い込んだ」後の結果の手口(の一つ)なんぞ知ってても疑心暗鬼になるだけで、何かを好転することはありません。
「王道」の基礎が10年で出来ると思えないんですけどね。
製造の自動化が夢物語だというのは私も同じ意見です。そもそも,製造という言葉が良くない。日立のソフト工場の残滓でしょう。でも,普通の人は製造といえば自動化や海外移管でコスト低減となるのです。
> しかも単に自分(PMは全責任を持っているのだから、部下の見積もりミス
部下じゃなくて外注(請負い)だったら?
工数管理は受注側の責任です。PMが全責任を持っているというは顧客に対してであって,外注先に対してではありません。
> 本質的には「追い込んではいけない」と肝に銘じるべきであって
本質的には「(プログラミングで)バグを作りこんではいけない」と肝に銘ずるべきであって....
と言われたら何と答えますか。管理も同じです。先ず,誰かが何処かで追い込まれていることに気が付くこと。そして,納期を延伸するなり,人員を増強させるなり。(納期延伸は受注側から見ると入金遅延になる)
人員を増やすのは逆効果と主張する人が多いけど,テスト担当を増やせぱ確実に効果が出ます。増やした人員にレグレッションをやらせるだけでもよい。
SIer社内で上司と部下の会話という想定です。客が下請けと会話するというのは完全に想定外です。そんなことを許せば商権を流しかねません。
人を出して指導しろというのは,下請けの現場に乗り込んで末端の担当者に檄を飛ばして来いというくらいの意味ですが,上司の意図と部下の理解は微妙に違うかもしれません。上司が言いたいのは「どうにかしろ」,それに対する部下の答えは「もう少し待ってください」なので,実際の会話の細部は重要ではありません。でも,キーワードは「下請け」です。この手の会話が要約されて幹部に届くころには「下請けが悪い」となるのは想像するに難くありません。ならば,下請けに依存している当社の体質が良くないという結論が自然に出て来ます。
> 「はい。次の案件をちらつかせながら,どうにかA社におねがいしてみます。然し,何にせよ,相手次第なので。」
A社も当時の派遣社員・委託先との関係が切れていて、結局どうにもならないというパターンのような気がする・・・。
#瑕疵担保期間過ぎる前でもそういわれてどうにもならなかったケースが・・・。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
上から目線 (スコア:2, すばらしい洞察)
穿ったコメントが多いけど,上から目線で見れば裏も表もない本音ではないでしょうか。内製でなければトラブル(納期延伸とか社外事故)のときに身動きが取れませんから。
「おい,君,例の事故,どうなっていいるんだ?客が怒鳴りこんで来たぞ。」
「すいません。下請けに逃げられてしまって。ほとほと困ってます。」
「困ってますじゃないだろう。どこにやらせたんだ。呼びつけろ。」
「A社なのですが,契約が切れていて。どうにも。」
「うちで直せないのか?」
「ソースコードを貰っていないので無理です。」
「やれやれ。とにかく,早くどうにかしろ。」
「はい。次の案件をちらつかせながら,どうにかA社におねがいしてみます。然し,何にせよ,相手次第なので。」
「おい,君,このプロジェクト,いつになったら閉じるんだよ。ずるずるずるずる,いつまで伸ばす気だ?」
「すいません。下請けのB社のスキルが低くて。ほとほと困ってます。」
「バグの件数が青天井だ。いったい,何をやっているんだ。」
「どうも,すいません。」
「うちから人を出して指導することは出来ないのかね。」
「それをすると偽装請負いになってしまいますので。」
「そもそも,なんであそこを使ったんだ。」
「金額の都合であそこしか無かったのです。明日,B社に行って社長を怒鳴りつけてきます。」
「しっかりしてくれよ。」
中間管理職はこういう言い逃れ(時間かせぎ)をするので。
「若いときにはプログラミング」というのも当然ですね。プログラミングを知らずにプログラミングを管理するのは無理だし,プログラミングする人を管理,あるいはプログラミングする人を管理する人を管理するとしても,自分でプログラミングを知らなければごまかされても分からない。年を取ってからもプログラミングで食って行けるなどとは言っていません。
Re:上から目線 (スコア:2, 興味深い)
B社(子会社)の社長には親会社の役員クラスが転籍されていて、
課長ごときが行ったところで「何か文句でも」と一蹴されることがよくあります。
Re:上から目線 (スコア:1)
>中間管理職はこういう言い逃れ(時間かせぎ)をするので。
原理的には、言い逃れになってないようですが。
そういう言い訳はよくあるのでしょうが、
「言い訳」としては、中間管理職の上から、スルーされると思います。
要するに「遅れてる」こと自体の言い訳になってなくて
評価を下げてることだけは間違いのないところでしょう。
時間稼ぎにも、実際にはなってないと思いますけどね。。
だって実際に遅れてるわけで、その「遅れ」に対する対処じゃないのは
誰の目にも明らかでしょう。
>「若いときにはプログラミング」というのも当然ですね。
そういう方針自体は否定しませんが、、、
上から目線の単なるコーダーって意味あるんですかね。
だって失敗しても「自分の仕事じゃないよね」と思える環境なわけでしょ。
そんな環境で自分の力として蓄積できるとは思えないんですが。
私の経験からいうなら、ひとつの「意味ある」(と思える)
仕事を任されて成長するものだと思いますが。
NTTデータぐらいの規模の会社ならば、
もうそこら辺は無視していいと思うのですけど。。。
どっかのゼネコンでも、そんなことはしないのでは。違うのかな。
もはやSIerとしての、「管理」能力を付けるか。
プログラミング全般の「開発」能力を付けるかは
は分断していいと思ってるのですが。
Re:上から目線 (スコア:1)
> 原理的には、言い逃れになってないようですが。
遅れに対する処置になっていないから「言い逃れ」なのです。会社が違えば思い通りにならないというのは常識です。では,なぜ敢えてリスクを冒して外注に出すのか。リスクとコストのトレードオフです。多数のプロジェクトを外注に出して利益を上げている中で,特定のプロジェクトが火を吹くのはやむをえないというのは常識的な思考です。でも,NTTDの社長は,それは良くない,コストを抑えたまま内作にしたい,そのために製造工程の自動化や海外拠点に投資すると言っているのです。
> 単なるコーダーって意味あるんですかね。
プログラミングを経験するのは有能な管理者になるための手段ですから,有能なコーダーになる必要はありません。むしろ,プロジェクトを爆発させる方が後のために良い経験になるやも。それを自分で鎮火させなくても良い。鎮火させる能力を持っている人を探し出して丸投げするのが有能な管理者の心構えです。あるいは,追い込まれたきにテストをサボるということを身を持って知り,その手口を覚えることも大事です。
Re:上から目線 (スコア:1)
>コストを抑えたまま内作にしたい,そのために製造工程の自動化や海外拠点に投資すると言っているのです。
ふ~ん。て感じですね。お手並み拝見という感じですか。
私自身は懐疑的ですが。
製造の自動化は、単なる夢物語だし
海外拠点に投資した場合の投資効果は、実際のところ不明だからです。
>プログラミングを経験するのは有能な管理者になるための手段ですから,
???それがよく分からない。それだと、プログラミングをなめてますよね。
「プログラミング」は表面上で文法をなぞったって「出来た」と言えるもの
ではありません。「経験した」とさえ言えるかどうか怪しいです。
通常、「プログラミング出来た」と言えるのに10年ほどかかります。
しかも、ただ10年過ぎればいいってことではありませんし。
>あるいは,追い込まれたきにテストをサボるということを身を持って知り,
その手口を覚えることも大事です。
追い込まれたきにテストをサボる理由自体は小手先のものではありません。
本来必要なテスト工数を削ることで「追い込んで」いるのだから、
その意味では、どんな手口を使ってもサボることになります。その多様さは
ありとあらゆる理由が付きます。
本質的には「追い込んではいけない」と肝に銘じるべきであって
追い込んだ後の手口なんぞ覚えても無意味です。
個々のことはともかく、プロジェクトマネージメントは
まず「王道」が重要で、プログラミングなどの小手先の技術を自らが
やってみる必要があるとは思えません。
しかも単に自分(PMは全責任を持っているのだから、部下の見積もりミスは
自分のミスなのだ)がテスト工数を見積もれなかったからと言って
「追い込んだ」後の結果の手口(の一つ)なんぞ知ってても
疑心暗鬼になるだけで、何かを好転することはありません。
「王道」の基礎が10年で出来ると思えないんですけどね。
Re:上から目線 (スコア:1)
製造の自動化が夢物語だというのは私も同じ意見です。そもそも,製造という言葉が良くない。日立のソフト工場の残滓でしょう。でも,普通の人は製造といえば自動化や海外移管でコスト低減となるのです。
> しかも単に自分(PMは全責任を持っているのだから、部下の見積もりミス
部下じゃなくて外注(請負い)だったら?
工数管理は受注側の責任です。PMが全責任を持っているというは顧客に対してであって,外注先に対してではありません。
> 本質的には「追い込んではいけない」と肝に銘じるべきであって
本質的には「(プログラミングで)バグを作りこんではいけない」と肝に銘ずるべきであって....
と言われたら何と答えますか。管理も同じです。先ず,誰かが何処かで追い込まれていることに気が付くこと。そして,納期を延伸するなり,人員を増強させるなり。(納期延伸は受注側から見ると入金遅延になる)
人員を増やすのは逆効果と主張する人が多いけど,テスト担当を増やせぱ確実に効果が出ます。増やした人員にレグレッションをやらせるだけでもよい。
偽装請負 (スコア:0)
B社を下請けに使っており、お客様から直接B社に業務命令が
出ているのなら、それこそ偽装請負になる筈です。
Re:偽装請負 (スコア:1)
SIer社内で上司と部下の会話という想定です。客が下請けと会話するというのは完全に想定外です。そんなことを許せば商権を流しかねません。
人を出して指導しろというのは,下請けの現場に乗り込んで末端の担当者に檄を飛ばして来いというくらいの意味ですが,上司の意図と部下の理解は微妙に違うかもしれません。上司が言いたいのは「どうにかしろ」,それに対する部下の答えは「もう少し待ってください」なので,実際の会話の細部は重要ではありません。でも,キーワードは「下請け」です。この手の会話が要約されて幹部に届くころには「下請けが悪い」となるのは想像するに難くありません。ならば,下請けに依存している当社の体質が良くないという結論が自然に出て来ます。
Re: (スコア:0)
> 「はい。次の案件をちらつかせながら,どうにかA社におねがいしてみます。然し,何にせよ,相手次第なので。」
A社も当時の派遣社員・委託先との関係が切れていて、結局どうにもならないという
パターンのような気がする・・・。
#瑕疵担保期間過ぎる前でもそういわれてどうにもならなかったケースが・・・。