トップ(最新) | <前 | 次>

nDiki : 見積もり

見積もり (見積り) - estimation

スポンサード リンク

Related term

2004年2月20日 (金)

ThinkPad X31 英語キーボード(08K5073)注文 このエントリーを含むはてなブックマーク

若松にも入荷しなさそうだし別ルートで購入しようと思って調べたら、日本IBMの部品センターから直接購入できるらしい。 しかも、店頭や通販より安い。 ということで注文。

@ 9:00 部品センターへTEL

ThinkPad X31英語キーボードを注文したいと告げると、ThinkPadの型番(2672-PHJ)を聞かれる。キーボードの型番(08K5073)は直接伝える必要なし。

  • 6610円 + 配送手数料1000円 + 税金 = 7990円
  • 「日本語キーボードからの交換ですか?」「はい」「保証がきかなくなりますがよろしいですか」「はい」
  • 現在在庫なし。発注までしばらく時間がかかる。
  • 注文の流れの確認。
  • 名前・電話番号・ファクス番号を伝える。

等のやりとり。 サービス部品購入申込書がファクスされてくるので、指定されている銀行口座に振り込みの上、配送先を記入してファクス返送をすることになる。

自宅にファクスがないので、会社のファクス番号を指定。

@ 10:00 サービス部品購入申込書

会社のファックスに届く。見積もり・簡単な説明・配送先記入欄があるA4一枚。

@ 13:00 振込みを済ませて申込書をファックス

申込書にATMの振り込み控えをのせてコピーし、配送先を記入してからファクス送信。

後は待つのみ。

スポンサード リンク


[ 2月20日全て ]

2004年6月8日 (火)

ソフトウエア開発 55の真実と10のウソ読了 このエントリーを含むはてなブックマーク

いろいろ考えさせられる本。

ウソ5 - ソフトウエアには、もっと開発方法論が必要である。

というのはかなりドキっとさせられる。開発方法論が駄目だとどうすればいいのか。 (状況に応じて)自分なりのパターンを作って適用していくのも意味がないのか。 毎回毎回うんうん唸ってその場限りの作戦を立てなければならないのか…。

よく読むと

筆者の意見は、小文字の m の methodology は善である。 大文字の M の Methodology は悪であり、使う場合は相当の注意を払うべきだ。

とあり、なるほどと。

アジャイル開発エクストリーム・プログラミングに対する話も随所で述べられていて興味深い。

真実23 - プロジェクトが途中打ち切りになる二つの原因のうち、一つは、仕様を凍結できないことだ。

もかなり納得。

技術者もそうだが、ぜひ上層部の人たちに読んでもらいたい。 「見積もり」とか「要求仕様」とか「保守」とか。


[ 書評 ] [ お薦めの本 ] [ コンピュータ書籍 ]


[ 6月8日全て ]

2005年5月16日 (月)

どうみても、そのままでは失敗しそうなプロジェクト このエントリーを含むはてなブックマーク

欲しい機能と完成予定日とを考えると、どう考えても無理なプロジェクトの話が出ているようだ。

真実10. 見積もりは、上層部か、マーケティング部門が実施する場合がほとんどだ。実際にプログラムを開発したり、開発プロジェクトの直接のマネジャーが見積もることはない。結局適切な人が見積もっていないのだ。-- ソフトウエア開発 55の真実と10のウソ p.51

(Fact 10. Software estimation is usuall done by the wrong people.)

まだきちんと見積もりが行われていない。もちろんきちんと見積もるべきである。 きちんとした見積もりを見れば現状の予定は無理すぎ(というか不可能)で、期間をのばして段階的に機能を提供していくべきだということを理解してもらえるであろう。 ……理解してもらえるよね? 不可能がわかっていて無理やり走っていつか闇に葬られるよりいいよね……。

真実9. ソフトウェア開発見積もりは、プロジェクトの開発時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積もることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。従って、見積もり時期として適切ではない。-- ソフトウエア開発 55の真実と10のウソ p.48

(Fact 9. Software estimation usually occurs at the wrong time.)


[ ソフトウェアプロジェクトマネジメント ]


[ 5月16日全て ]

2005年6月28日 (火)

冷蔵庫修理は霜取り温度ヒューズ交換 このエントリーを含むはてなブックマーク

naney:22110525

野菜室・チルドルームがほとんど冷えなくなったシャープ冷蔵庫 SJ-WH40E-C の修理の日。 9:00前に11:00ごろ来るとの連絡があったあと、シャープエンジニアリング株式会社の技術者が10:50ごろ到着。

富士通ゼネラルの技術者と違って、バケツは持ってきていなくてより電器屋に近い感じ。

冷凍庫が冷えていることから、冷蔵側の冷却関連の問題らしい。 作業前に保証の範囲内か聞いてみたがその時点ではわからないとのこと。

@ 作業開始

中の食品やフィルムを取り出して作業開始。

各棚類・冷却パネルを外して核心部へ。普通のドライヤーを使って霜取り。 スチームクリーナーを使った富士通ゼネラルとはここでも違いが。

右から開けたり、左から開けたりと「どっちもドア・ドア」を堪能している様子。 ちなみに作業においては、冷蔵庫はまったく移動されなかった。

@ 見積もり

ばらして状況確認後、口頭で説明。 自動霜取りがうまく機能しなくて霜が大量についた結果、冷気がまわらない状態になっているらしい。冷凍庫側の冷えが弱いのも、これらの関連で冷却を止めている時間があるからのようだ。

霜取り温度ヒューズ部品交換で、12,000円(税別)とのこと。 5年保証の範囲の部品ではなく、1年保証の範囲のものらしいので有償修理。 部品そんなに高いのけー。工賃をあわせると2万円ぐらい?

とはいえ直らないと困るので、修理してもらうことに。

@ 修理

ヒューズ交換とのことなので「原因は何ですか?」と聞いてみたが、なんかはっきりしない答え。

「(この部品が)霜取りの全部を見ていますから」。

意味がわからない。ヒューズが全部見ている? 制御はマイコンか何かじゃないの? サーミスタが壊れたとかで制御がおかしくなったのだがわかるのだけれど、ヒューズなんですよね?

naney:22110528 naney:22144891

@ 完了

霜取り温度ヒューズ1,200円
技術料8,600円
出張料/運送料2,200円
消費税600円

で 12,600円。さっきの金額は部品代じゃなくて、合計か。 見積もり時には正確に話してくれないと。

明細にはやはり温度ヒューズとあった。 温度ヒューズがとんだので交換ということなら、その原因を取りのぞかないとまたとんじゃうんじゃない?

今回の修理箇所分は3ヶ月保証。ちょっと不安だなぁ。

何度か繰り返された「霜取りの全部を見ていますから」という意味不明の説明。 たしかにヒューズが切れれば、それが保護している回路が全部止まるのはわかるんだけれどさ。

サービス満足度低。

@ なにはともあれ冷えるようになった

冷蔵庫が再び冷えるようになった。 これでやっとまたいろいろ食材を買えるぞ。 西瓜も買った。ビールも買った。観測史上6月としては最高の36.2度を記録(東京)したなか、冷えてる冷えてる。

普段は感じない、故障のおかげで感じたささやかな幸せ。

……このささやかな幸せを得るためにかかったコストが、食材廃棄と食中毒の不安と有給休暇消費と12,600円ですか。ふう。


[ 6月28日全て ]

2005年10月14日 (金)

ソフト契約と見積りの基本がよ~くわかる本 このエントリーを含むはてなブックマーク

rimage:ISBN:4798009164

最近契約的な視点での決め事にかかわる事が多くなってきたので先日買ってみた。 見積もりの部分はおまけ程度で、契約契約書の作り方が中心。 ソフトウェア取引の契約について

などがあることやそれらの概要を確認できるという点でなかなか良い。

権利的には

  • 著作権
  • 所有権
  • 使用権
  • 特許権・実用新案権

などかからんでくるのだが、ソフトウェア特有の複雑さがありすぐ混乱してくる。 やっかい。

面倒な世界であるな。

書籍はわかりやすいが、契約(書)例が少ないのが残念。 著作権等がどちらの権利になるかなどについてもう少し解説があると嬉しい。 第三者ソフトウェアがからんできた時の説明も欲しい。

またソフトウェア開発委託契約例はウォーターフォール的なモデルにもとづいており、現場としてアジャイル的なモデルで進めたいと思っても相容れない部分が多い。

それと「図解入門」シリーズということで図がふんだんに使われている。 図があった方がわかりやすいのだが、わざわざ図にする必要のないものを無理やり図にしたり図が間違っていたりするものがあったりする。ちょっと注意。

委託・受託双方にハッピーな結果(と権利関係)が得られる契約が作れるのが一番いいんだけれど、実際のところ

  • 力関係
  • 雛型がある場合、組織の方針・風潮として(全く/あまり)変えられない事が往々にしてある
  • 面倒。時間がかかる。

などなかなか思うようにいかないものである。

この辺りについてカバーされている書籍があれば、ぜひ読んでみたい。


[ 書評 ]


[ 10月14日全て ]

2005年10月19日 (水)

コミットメント・リスト vs ガントチャート このエントリーを含むはてなブックマーク

会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。

 社内にはコミットメントをコアにした管理手法もあり、
 その優位性は十分に認めている。

 しかし、単純にガンチャートがすきなのである。
 特に見た目、がね。

 -- GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より

とのことだ。 コミットメント・リスト派とはまさに私の事である(多分)。 いい機会なので自分の中でも、コミットメント・リストガントチャートについて整理しておこう。

ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。

ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。 「ガントチャートは駄目」だとも思っていない。 以下は試行錯誤を繰り返している中での現在の私見である。

どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。 両方同時に使っているケースもあるであろう。 またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。

@ モデル

コミットメント・リストでは「期日」という点で「成果」をリスト化する。 一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。

  • 作業時間がある程度精度よく見積もれる
  • 作業時間と成果が比例的である

であるような場合はガントチャート計画しやすい。

逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。

@ ガントチャートを利用したマネジメントの特徴

  • マネージャからのトップダウン的なスケジュール向き
  • リソースの多重度を把握しやすい (本来はかけもちさせない方がいいと思うが)
  • 比較的多人数のチームでもいける
  • リソースがタスクに時間を割く割合を設定できる (やろうと思えば)
  • 人月計算/コスト積算できる
  • プロジェクト外からの割り込みの発生によって狂いやすい
  • 成果がみにくい
  • チェックしにくい
    • 「進んでますか?」「はい作業中です」「どれぐらい?」「うーん、30%ぐらい」
  • ぱっと見、計画できている気がする
  • 期間が長いと、チャートが見にくくなる
  • 1日単位で見積もりたくなる
  • 休日が気になりだす

@ コミットメント・リストを利用したマネジメントの特徴

  • 担当の裁量を尊重・重視
  • コミットメントのクロスチェックがしやすい (コミットメント、メジャーメントの明文化)
  • 期日前にせっぱつまりやすい
  • 依存関係が複雑だと把握しにくい
  • 専用のソフトウェアがなくても可能
  • 他のプロジェクトと兼任しているリソースの稼働状況がわかりにくい
  • 線表派からみると計画だと思ってくれないかも

@ 自分がガントチャートでうまくいかなかった点

ソフトウェア開発で線を引いてみたときの感想

  • スケジュールの変更があった時に面倒
  • 現状とあわなくなってくるとだんだん見なくなった
  • 結局だんだんメンテナンスしなくなってしまう
  • 進捗チェック時に、ガントチャートで○○%と入力しても適当で意味がなかった

@ コミットメント・リストでうまくいっている点

  • 成果が達成できているか、そうでないかが明確
  • 達成できていないコミットメントのチェック、フォローができている
  • 担当自身が忘れていたコミットメントもクロスチェックで再認識できる
  • コミットメント一つ達成するたびに「いい気分を味わえる」

@ まとめ

現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。

必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。

ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。 自分が扱っているプロジェクトがそういうものではないのだなと。


[ 10月19日全て ]

2005年10月26日 (水)

ナノパーセント日 このエントリーを含むはてなブックマーク

ミーティングで、あるプロジェクトのスケジュール遅れが議題になった(参加していないプロジェクト)。

リクエスト側と開発側で、仕様の誤解による手戻りが大きな原因のようである。

あたりが問題か。 物理的な距離の壁はデカイ。

それから、β版リリース日がナノパーセント日(あるいはそれよりも前)であった可能性も高いように思えるが、その点はどうか。

(Naney注:リスク図の)曲線の左側が水平になる地点が、「確率がゼロではない最初の日」である。しかし、限りなくゼロに近い。この日までに完成する確率は1ナノパーセント程度なので、この地点をN(ナノパーセント日)と呼ぶ。-- 熊とワルツを, p.65

自分も「これどれぐらいでできる?」と言われると、つい奇跡的最短期間を口にしがちである。 気をつけねば (もっとも、見積もりとは関係なく期日がセットされていて内容で調整ということも多いが)。


[ ソフトウェアプロジェクトマネジメント ]


[ 10月26日全て ]

2005年10月28日 (金)

ソフトウェアかんばん このエントリーを含むはてなブックマーク

naney:57031780

先週金曜日に参加した総会関連のプロジェクトについて KPT 法を用いた評価セッションを実施。

プログラマ間でのコラボレーションが一つの課題になった。 決して悪い状態ではなく比較的いい感じであるのだが、より良くしていこうというわけである。

またこのプロジェクトはリリースを前にまだ開発要素が目白押しということもあり、その辺りの見通しもより明確にして共有したい。

ということで、今回はあらたにソフトウェアかんばんを使ってみることにした。

よく紹介されている方法はタスクカードを「TODO」「DOING」「DONE」というカテゴリ分けされた壁に貼って見える化する方法である。

今回はこれをちょっとアレンジして実践してみることにした。

まずはこれでスタート。

実装しなければならないストーリーがたくさんあることを直観的に、他のスタッフにも理解してもらえる。社長も「まだこんなにやることがあるのか」とプロジェクトの状況を理解してくれたようである。

今後であるが、以下の点をまだ行っていないので順次実行していきたい。

  • イテレーションの設定
  • タスクの見積もり
  • ストーリーの見積もり
  • 全体の見積もり
  • 定期的チェックタイムの設定
  • 貼りやすいプッシュピンの入手

[ ソフトウェアプロジェクトマネジメント ]


[ 10月28日全て ]

2005年12月26日 (月)

サイバーショットをクイック修理サービスで即日修理 このエントリーを含むはてなブックマーク

naney:78665549 以前から DSC-U40 の背面液晶の表示が滲むようになっていて、気になっていたので「ソニーサービスステーション秋葉原」に持ち込んで修理してもらうことにした。

@ 11:25 受付

午前中は窓口も空いていて、待たずに受付。 カウンターで DSC-U40 をさしだすと、お姉さんがそれを持って裏へ。 技術者の方が出てきて、原因の可能性を説明。

  • (ボディ背面を押すと滲みに変化があるので)配線トラブルの可能性
  • 液晶自体の問題があれば部品交換

前者だけならば 7,000円(税別)。液晶交換が必要になると + 6,000円(税別)とのこと。

部品交換が必要なら見積もってもらうことにした。 クイック修理サービスとして今日中の修理を依頼。 PHS電話番号を伝えて、完了の際or見積もりの場合は電話をもらうことに。

コーヒータイムサービスとして、すぐ近くのカフェ コロラド 神田末広町店のコーヒーチケットをくれた。 電話がつながらなかったら、1時間半ぐらい後にくると伝えてセンターを出て食事へ。

@ 13:55 受け取り

結局その後、モスで飯を食べたり千石電商電池を買ったり、はたまたヨドバシカメラへいったりとぐるぐる。 圏外だったのか電話がなかったので、13:40 にサービスステーションへ。

午後になると混雑しているな。呼ばれるまでに15分待ち。 ノート PC を持ち込んでいる人を多くみかけた。

肝心の DSC-U40 の方は、

フレキシブル基板補修致しました。

という処置内容。 税込みで 7,350円也。

本体価格がそんなに高いものではないだけに、部品交換にならなくてよかった。 これからもビジュアル・ブックマークに活躍してもらわねば。

あ、コーヒー飲みそびれた。


[ 12月26日全て ]

2006年1月12日 (木)

Windows でも Linux でも動くタスク管理ツール Task Coach このエントリーを含むはてなブックマーク

仕事をもらさず、先送りせず進めていくには

  1. タスクを書き出して
  2. 実行可能な小アクションに分割

するのがひとつのポイントである。

Palm (To Do / DateBk5 / Progect) であったり、裏紙であったり、方眼ノートであったりに、To Do リストを書き出して終わるとチェックしていく。

Palm を使う場合は繰り返し機能やアラームが使えるが、入力が面倒。電池問題あり。 紙を使うとリストアップが速く、常時表示が可能。しかし階層化書きしていくのが面倒。 それぞれ長所・短所がある。

PC用のツールだとどうだろう。タスクをサブタスクにブレークダウンしていけるもので、WindowsLinux で動くものを探してみた。

rimage:http://www.naney.org/img/2006/screenshot/TaskCoach-2006-01-12-0001-240.png Task Coach が良さそうなので、これを Debian GNU/Linux sidインストールしてみる。

@ Python 2.4 用 wxPythonインストール

Task Coach 0.54 は Python 2.4.1 以上、およ wxPython 2.5.5.1-unicode 以上が必要である。 sidwxPythonPython 2.3 用なので Python 2.4 だとそのままでは使えない。

ということで、まずは Python 2.4 用の wxPython パッケージを作成してインストールするところから。 wxPython2.6-2.6.2.1-1.src.rpm から deb パッケージにする。

一旦 Python 2.4 用の RPMパッケージ

  • wxPython-common-gtk2-unicode-2.6.2.1-1.i386.rpm
  • wxPython2.6-2.6.2.1-1.src.rpm
  • wxPython2.6-devel-gtk2-unicode-2.6.2.1-1.i386.rpm
  • wxPython2.6-gtk2-unicode-2.6.2.1-1.i386.rpm

ビルドし、その後 deb パッケージ

  • wxpython-common-gtk2-unicode_2.6.2.1-2_i386.deb
  • wxpython2.6-devel-gtk2-unicode_2.6.2.1-2_i386.deb
  • wxpython2.6-gtk2-unicode_2.6.2.1-2_i386.deb

に変換してインストールする。

 apt-get install libgtk2.0-dev freeglut3-dev python2.4-dev
 rpmbuild --rebuild --define 'pyver 2.4' wxPython2.6-2.6.2.1-1.src.rpm
 cp /usr/src/rpm/RPMS/i386/wxPython* .
 fakeroot alien *.i386.rpm
 dpkg --purge python-wxtools
 dpkg --insstall *.deb

このままだと共有ライブラリが認識されないので、ld.so.conf を修正。

 echo /usr/lib/wxPython-2.6.2.1-gtk2-unicode/lib > /etc/ld.so.conf
 /sbin/ldconfig

これでいけるかと思ったらなぜかロードできない。なぜ?

確認したらライブラリディレクトリの権限が 700 になっていた。

 chmod 755 /usr/lib/wxPython-2.6.2.1-gtk2-unicode
 chmod 755 /usr/lib/wxPython-2.6.2.1-gtk2-unicode/lib

これでOK。

@ Task Coachインストール

tarball を展開

 tar zxvf TaskCoach-0.54.tar.gz

以上。

 python2.4 TaskCoach-0.54/taskcoach.py

で実行できる。

@ Windows へのインストールの場合

TaskCoach-0.54-win32.exe がインストーラなので、実行するだけ。簡単。

@ 使い勝手

基本的な機能はほぼそろっている感じだ。

リスト表示とツリー表示をタブで簡単に切り換えられるのが良い。

「ツリー表示の方でタスクをブレークダウン」していきそれぞれに期日を設定すると、「リスト表示の方で期日順に並べて表示して上から実行」していくことができる。

Task Coach の特徴として、各タスク毎のストップウォッチ機能がある。 これを使うとどのタスクがどれぐらい時間がかかったかを記録しておけるので、今後同じようなタスクを作成するときの時間見積もりに役立てることができる。

手元の環境だと uim との相性が良くないのか、途中で日本語入力ができなくなることがあるのが今のところ問題。その場合は Task Coach を起動しなおすことになる。

それ以外はなかなかいい感じ。

デスクワークはガンガンこれに突っ込んでアクションに分割していき、淡々とこなしてみますか。


[ 1月12日全て ]

スポンサード リンク

Related web page

404 Blog Not Found:人月を超えるとプログラムしている暇が減る
http://blog.livedoor.jp/dankogai/archives/50919702.html
404 Blog Not Found:Web業界の底上げとか崇高な考えがあるなら、お前ら率先して金取ろうよ
そのレベルが高いはずの君たち -- 僭越ながら、私自身も勘定に入れとく -- 俺たちが、なまじ楽しいからって手弁当イベントばっかりやっていると、どうなるかって考えてみたことある? 最速廃人研究会 - Web業界の底上げとか崇高な考えがあるなら、お前ら率先して廃業しろよ お前ら全然凄くないよ。いい加減自覚しろよ。そんで自重しろよ。イベントだ勉強会だ交流だの、レベ
http://blog.livedoor.jp/dankogai/archives/50874804.html
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― @IT
 日本情報システム・ユーザー協会(JUAS)は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 JUASの専務理事 細川泰秀氏
http://www.atmarkit.co.jp/news/200707/05/juas.html
すごい技術者はすごいマネージャになれるか? - @IT情報マネジメント
見積もりアンチパターン
http://www.atmarkit.co.jp/im/cpm/serial/team04/team04b.html
★SEの残業しない仕事術★ブログ:見積もり≠計画 - livedoor Blog(ブログ)
現場リーダーが陥りやすい間違いの一つに、 <strong>見積もり</strong>と計画を同じものとみなすことがある。 プロジェクトマネージャや、 上級管理職にいたっては、 ほとんどが間違っている。 そして、この間違いは、 プロジェクトにとって、 もっとも悪い影響を与える間違いである。 <strong>見積もり</strong>と計画は、 まったく異なったものである。 似てさえいない。 <strong>見積もり</strong>とは、 その作業にどれく
http://blog.livedoor.jp/gaseidou2/archives/51027051.html
ITmedia Biz.ID:時間の見積もりがうまくできなくて困る【実践編】
仕事がスケジュールから遅れていますが、どのくらいの時間がかかるか見積もれないタカフミ君。ノリオ課長はExcelを使った仕事の<strong>見積もり</strong>法を伝授しますが……。 2006年07月28日 16時10分 更新 ヒロシ主任とタカフミ君は組織上はマサヨシ課長の下で仕事をしているのですが、現在ノリオ課長が推進している部門横断の新規事業プロジェクトにはメンバーとしてこの2人も名を連ねて
http://www.itmedia.co.jp/bizid/articles/0607/28/news061.html
@IT:人月での見積もりがエンジニアをダメにする(前編)
筆者が現役のSEだったころ、“マンパワー”という言葉に抵抗があった。現在でもこの言葉に抵抗がある。IT業界では、プロジェクトを手掛けるときなどに「マンパワーが足りない」とか、「マンパワーは十分だ」という場合がある。その“マンパワー”という言葉だ。そうした言葉を聞くと、往々に「SEはスキルではなく頭数だけが問題とされている」ような気分となる。 さらに
http://jibun.atmarkit.co.jp/fengineer/special/ningetu/ningetu01.html
開発費の実状は「人月単価90万円」 : IT Pro ITレポート(動向/解説)
「開発費の実状は『人月単価90万円』」
http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20050509/160510/
ObjectClub - その他
Use Case Point 法による工数見積
http://www.objectclub.jp/technicaldoc/else/
[ThinkIT] 第4回:見積もりについて (1/3)
&nbsp;&nbsp;&nbsp;<strong>見積もり</strong>の算出方法ですが、まず「分析・調査」、「設計」、「製造」、「テスト」、「本番移行作業」などの工程に分けます。システムの規模によっては分析・調査を設計に含めてしまうことがありますが、おおむねこういう分類です。そして各工程に工数と単価を算出し、見積額が決まります。 &nbsp;&nbsp;&nbsp;工数とは、その作業がどれくらいかかるかという数値
http://www.thinkit.co.jp/free/project/2/4/1.html

■よく検索されるキーワード

perl(62) torrent(54) linux(48) 提案書(47) windows(43) 書き方(41) 使い方(29) アジェンダ(26) x31(25) 充電式カイロ(25) cvs(22) インストール(20) サンプル(20) thinkpad(19) アジェンダとは(19) f-01a(18) wiki(17) c#(16) 感想(16) カイロ(16) usb(16) java(16) 秋葉原(15) debian(15) ヨドバシカメラ(15) subversion(15) 壁紙(15) 作り方(15) 静電気(14) apache(14) グッズ(14) デロンギ(13) フリー(13) sh-01a(13) ganttproject(13) 修理(13) ssh(12) svn(12) ヨドバシ(12) truecrypt(12) ダイソー(11) 手帳(11) activeperl(11) ubuntu(11) ほぼ日手帳(11) firefox(10) mew(10) mp980(10) ドラマ(10) 日本語(10) n-01a(10) google(10) tc-1(10) 評判(10) ツール(10) djunit(9) cgi(9) 動画(9) mp3(9) オイルヒーター(9) docomo(9) rcs(9) 除去(9) centos(9) メモリ(9) エネループ(9) 設定(9) p-01a(9) tortoisesvn(9) 無印(8) ケース(8) 口コミ(8) ミノルタ(8) メール(8) インストーラ(8) 会議(8) xampp(8) 加湿器(8) af(7) 値段(7)

この日記のはてなブックマーク数 Add to Google RSS

Process Time: 0.143209s / load averages: 0.18, 0.52, 0.61
nDiki by WATANABE Yoshimasa (profile)
Powered by DiKicker
Base theme by Nana (for tDiary)