capsctrldays - erase_render_results で render をキャンセル , 人月の価格調査 , 給与とコストで人月計算 , あなたの会社を潰さない最後の戦略..
1 erase_render_results で render をキャンセル ビジネスロジックが複雑になってきたのでafter_filterでいろいろフィルタリングするようにして、問題があったら RecordNotFound を raise するようにしたところ、render2回やっちゃダメって言われたので、「erase_render_results」をつけた。こんなのあったんだーというメモ。 class ApplicationController < ActionController::Base rescue_from ActiveRecord::RecordNotFound, :with => :record_not_found protected def record_not_found erase_render_results # コレ render :file => File.j
人月を超えるとプログラムしている暇が減る : 404 Blog Not Found
2007年09月26日16:15 カテゴリArtMoney 人月を超えるとプログラムしている暇が減る 人月が銀の弾(たま)ではないことが知られて久しいのに、「人月伝説」が衰えないのは、誰が悪いのだろうか? 矢野勉のはてな日記 - プログラマなら人月なんかさっさと超えろ 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 実は、プログラマー自身なのではないだろうか。 実は人月というのは、発注者側だけではなく、プログラマーにとっても楽なのだ。人月見積において、プログラマーが考えなければならないことは、「それを作るのにどれくらいの時間がかかるか」ということだけだ。「それを完了するのに何と何と何が必要で、それぞれこれくらいの手間がかかる
Web業界の底上げとか崇高な考えがあるなら、お前ら率先して金取ろうよ : 404 Blog Not Found
2007年07月18日23:30 カテゴリMoneyArt Web業界の底上げとか崇高な考えがあるなら、お前ら率先して金取ろうよ そのレベルが高いはずの君たち -- 僭越ながら、私自身も勘定に入れとく -- 俺たちが、なまじ楽しいからって手弁当イベントばっかりやっていると、どうなるかって考えてみたことある？ 最速廃人研究会 - Web業界の底上げとか崇高な考えがあるなら、お前ら率先して廃業しろよ お前ら全然凄くないよ。いい加減自覚しろよ。そんで自重しろよ。イベントだ勉強会だ交流だの、レベルの低い連中で集まっても何の意味もねーよ。なまじ仕事になって給料とかもらえてしまうから、ダメなことに気付かないんだよ。凄い人々しか、業界で食えなくなるんだよ。 すると何がおこるか、といえば、業界が育ちにくくなるんだよ。 仮に、「凄い人」と「凄くない人」の給与が10倍あるとする。このとき、「凄い人」が月200
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
すごい技術者はすごいマネージャになれるか？
すごい技術者はすごいマネージャ？ 技術の分からないダメマネージャよりはうまくやる？ Gさんは30歳代前半の実装技術者として、まさしく経験豊富で優秀な人物です。フレームワークからアーキテクチャ、インフラからアプリケーション、要件からテスト・運用……。システムのすべてを経験し、それなりの造詣を持っています。会社でもエースの技術者として扱われてきました。そして、いままでの立ち位置は、いわゆる「技術頭」でした。何人か部下というより後輩を抱え、チームメンバーをプロジェクトごとに面倒を見てきました。いわゆるリーダークラスといえるでしょう。 そんな彼に、いままでの部下を連れて、次のプロジェクトではマネージャになるよう指示があったのです。彼にも、いままで散々多くの技術の分からないダメマネージャを見てきて、自分ならうまくやれるという自負もありました。彼は快諾し、次のプロジェクトを待っていました。顧客との打ち
見積もり≠計画 : SEの残業しない仕事術
2007年03月11日23:51 見積もり≠計画 カテゴリプロジェクトマネジメント gaseidou2 Comment(0)Trackback(0) 現場リーダーが陥りやすい間違いの一つに、 見積もりと計画を同じものとみなすことがある。 プロジェクトマネージャや、 上級管理職にいたっては、 ほとんどが間違っている。 そして、この間違いは、 プロジェクトにとって、 もっとも悪い影響を与える間違いである。 見積もりと計画は、 まったく異なったものである。 似てさえいない。 見積もりとは、 その作業にどれくらいの時間を要するかの、 予測であって、結果を保証するものではない。 見積もりは、 誰が実行するか、 どれぐらいの工期でやるか、 さまざまなパラメータによって変動する。 したがって、 見積もりはある前提をもとに、 成り立つものである。 前提がなければ、 見積もりとは言えない。 見積もりに手心を
＠IT：人月での見積もりがエンジニアをダメにする（前編）
日本のIT業界に巣くう大問題 人月での見積もりがエンジニアをダメにする（前編） 馬場史郎（グローバル ナレッジ ネットワーク） 2002/8/2 何げなく聞く“マンパワー”という言葉の裏に、ITベンダをむしばむ“人月問題”が横たわる。日本のIT業界に深く根を張ったこの問題が、エンジニアをダメにすると筆者はいう。人月問題とは何か、そしてそれを改善する方法とは？ 筆者が現役のSEだったころ、“マンパワー”という言葉に抵抗があった。現在でもこの言葉に抵抗がある。IT業界では、プロジェクトを手掛けるときなどに「マンパワーが足りない」とか、「マンパワーは十分だ」という場合がある。その“マンパワー”という言葉だ。そうした言葉を聞くと、往々に「SEはスキルではなく頭数だけが問題とされている」ような気分となる。 さらに、プロジェクトでは「このプロジェクトは30人月掛かります。従って3000万円となります」
開発費の実状は「人月単価90万円」
日本情報システム・ユーザー協会（JUAS）が、ユーザー企業のシステム投資案件の実態を調査した。投資額を含めた大規模な調査は国内では、これが初めて。4月に人月単価や生産性などの分析結果を公表した。これらを基準値に、ユーザー企業がプロジェクトを評価できるようにするのが狙い。 JUASが調査・分析したのは、開発コスト（生産性）、品質、工期の三つの指標値。結果は、開発コストが「人月単価90万円」、品質は「不具合の発生率は開発コスト500万円（約5.6人月規模）当たり1個以下」、工期については「プロジェクトに投入した全人月の立方根の2.7倍」―という実態が明らかになった（図[拡大表示]）。 今回の調査は、2004年10月初旬から2005年1月下旬にかけて、JUAS会員を中心としたユーザー企業40社を対象に実施し、133件のプロジェクト・データを収集した。その実績データをJUASが想定するプロジェクト
- その他
ここでは、オブジェクト指向に関する様々な記事を紹介します。他のカテゴリに当てはまらないものを集めました。 Use Case Point 法による工数見積 Geri Schneider の書籍「Applying Use Cases(ユースケースの適用:実践ガイド)」で紹介されている， Gustav Karner による見積法．Excel 版 と PDF 版を用意しています． Excel ワークシート(zip圧縮)[15.9KB] PDF[15.1KB] Python 社内勉強会 資料 (株)永和システムマネジメントが社内でおこなっている有志勉強会で、Python入門をやったときの資料です。「Pythonひとめぐり(python.pdf)」で全体像をざっと説明してから、「実習資料(practice.pdf)」を見ながらハンズオンで勉強しました。 Pythonひとめぐり[PDF 111KB] 実
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
