アカウント名:
パスワード:
実際にやろうと思ったら規模の大きいところほど困難を伴うと思われますが、開発プロセスは個々の能力に合わせて能力別に適用基準を変えられる様にすべきかと考えます。
結局、能力差が多分にある環境において、一番よくあるパターンは、一番低いレベルに基準が合わさってしまうことです。そうすると、能力の高い人にとっては無駄な労力を割くことにしかなりませんから不満が出てきて当然でしょう。見る機会はあまりありませんが、逆のパターンもしかりです。皆が同じ基準で仕事をする時点で、出来る人出来ない人どちらにも不満は出てきます。同じ基準こそが問題だと思います。
その能力をどういう基準でもって判断するのか、等、色々難点はありますが、個人的には試行錯誤して取り組んでいきたいテーマではあります。
一応、とある企業で研究職ですが、下請けに、単純作業をやらせるときに独創性など期待していないと思う。
重要な研究開発は自分たちでやってるし、下請けに投げる仕事っていうのは、基本的に下請けでもできる、鞭を打てばできるような仕事で、仮に失敗したとしてもこっちとしてはリスクに対する保険をちゃんとかけていて、最終的に未納品未払いで終了してもよいわけです。ましてや、要素技術の開発が終わっていて、ただユーザーインタフェース他を組むだけのフェーズならそれをやってくれそうな複数の企業に打診します。
もちろん中間で請け負っている人たちは、それより下流の人たちが仕事を完了させない限り収入を得られないわけなのですが、そんなことは知ったことではありません。80%の確率で成功するという話なのか、50%の確率で成功する話なのか、10%の確率で成功する話なのかを適宜見積もって、利益を最適化すればよいのですから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
個々に合わせる (スコア:2)
実際にやろうと思ったら規模の大きいところほど困難を伴うと思われますが、開発プロセスは個々の能力に合わせて能力別に適用基準を変えられる様にすべきかと考えます。
結局、能力差が多分にある環境において、一番よくあるパターンは、一番低いレベルに基準が合わさってしまうことです。そうすると、能力の高い人にとっては無駄な労力を割くことにしかなりませんから不満が出てきて当然でしょう。見る機会はあまりありませんが、逆のパターンもしかりです。皆が同じ基準で仕事をする時点で、出来る人出来ない人どちらにも不満は出てきます。同じ基準こそが問題だと思います。
その能力をどういう基準でもって判断するのか、等、色々難点はありますが、個人的には試行錯誤して取り組んでいきたいテーマではあります。
ほえほえ
Re: (スコア:0)
一応、とある企業で研究職ですが、下請けに、単純作業をやらせるときに独創性な
ど期待していないと思う。
重要な研究開発は自分たちでやってるし、下請けに投げる仕事っていうのは、基本的に下請け
でもできる、鞭を打てばできるような仕事で、仮に失敗したとしてもこっちとしてはリスクに
対する保険をちゃんとかけていて、最終的に未納品未払いで終了してもよいわけです。
ましてや、要素技術の開発が終わっていて、ただユーザーインタフェース他を組むだけの
フェーズならそれをやってくれそうな複数の企業に打診します。
もちろん中間で請け負っている人たちは、それより下流の人たちが仕事を完了させない限り
収入を得られないわけなのですが、そんなことは知ったことではありません。80%の確率で成功
するという話なのか、50%の確率で成功する話なのか、10%の確率で成功する話なのかを適宜
見積もって、利益を最適化すればよいのですから。
Re: (スコア:0)
バグだらけで保守を受け付けないようなコードを『素早く』仕上げてきて、
自分は能力が高いと勘違いしているアホな開発者がたくさん居るんですね。
全員が無駄だと考えているような作業は本当に無駄なんでしょうが、
まともな開発プロセスを「俺には無駄な作業だ」と考えている開発者は、
開発者自身の能力が低くく、かつ開発プロセスの意義も理解できないアホです。
まずは能力が低くくアホな開発者の能力を上げないと、はじまりませんね。
Re: (スコア:0)
> 開発者自身の能力が低くく、かつ開発プロセスの意義も理解できないアホです。
>
たとえば宇宙産業に用いるべきプロセス、自動車産業に用いるプロセス、
医療産業に用いるプロセス、基幹業務に用いるプロセスなどなど、みんな
異なるものだと思うのですが、ところがどうやら製造業では、トヨタ厨が
役員に多すぎて(そしてコンサルも)自動車産業用のソフトウェアのプロセスが
最もすばらしいと信じてそれを現場に適用しようとするわけです。
ところがそれを民生用製品の開発プロセスに適用しようとすると、無駄が多すぎて
変化に追従しづらい。追従するための負荷が多すぎるということがあります。
あなたが信じる*まとも*は他の現場、人には必ずしも当てはまりませんよ、ということで。
Re: (スコア:0)
そういうのは「まともな開発プロセス」とは言わないね。それ以前の問題。
まともな情報提供や提案ができなければ、役員は「とりあえずやってみろ」というだろうな。
まわりはそうならないように情報提供、提案すべき。
そういう状況になることが分かっていて止められない腰巾着やイエスマンをなんとかしろ!
Re: (スコア:0)
しかし、まともな開発プロセスかどうか以前の問題です。
開発プロセスをつくるプロセスがまともなら、こんなことにはならないでしょうね。
つくっている奴がまともじゃないのかもしれませんけどね。
最低でも、現場の開発者がレビューすべきですね。
開発者がまともならば、これでまともな開発プロセスにできるでしょう。