ソフトウェア開発やプログラミングのスピードを上げる方法はありませんか?


プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいます。
そのため いつもつらい思いをしています。

環境を良くしようとHHKLite2を使い、カスタマイズソフトでホームポジションから離さずにプログラミングしています。
マウスもゲーム用の高精度のものを使っています。
調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。
DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。

出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。
単体テスト、リファクタリングも当然行いますが、余計に開発速度が落ちています。

しかし開発速度は効率化とは無縁だとすら感じています。
仕事を減らすことが優先ではないか?と。

昔から創作活動は好きですが、人より時間がかかる方でした。
最近はプログラマーに向いていないとすら言われます。

どうか私にお力添えをください。
一番参考になった方には500ポイント差し上げます。

回答の条件
  • URL必須
  • 1人5回まで
  • 登録:2008/02/22 17:12:16
  • 終了:2008/02/28 23:30:42

ベストアンサー

id:shikaku No.10

s回答回数12ベストアンサー獲得回数22008/02/27 07:34:59

ポイント500pt

http://www.wankuma.com/seminar/20070602tokyo8/Default.aspx

「R流・職業プログラマー向け生産性向上の工夫」を見てください。非常に現実的な解だと思います。

効率よく高速に作業するには、集中できる時間を作らなければなりません。

テクニックは二の次です。

集中力を上げる方法を以下に記します


  • 人間が1日に集中できる時間は約2時間と言われてます。

 いかにその集中できる時間に難解な作業を当てるかが重要です。


  • 一般には朝ご飯を食べて2時間後が一番頭の回転が速くなります。

 ここに集中タイムとするといいでしょう。

 前日の最後に集中タイムにやることをまとめておくと、この貴重な時間帯を消費しなくてすみます。


  • 集中タイムには割り込み禁止にします。

 できればこの時間だけでもいいので個室にこもるとGoodです。

 人がやってきても追い払ってください。話しかけるなオーラを出すことが重要です。


  • 集中力がきれたなーとおもったら、作業を中断して休みましょう。

 ドリンクタイムにしてもいいですし、打ち合わせや相談、雑談など

 人と絡む作業を入れると切り替えやすいです。


  • 雑談は非常に重要です。作業上悩んでいたことを話しただけであっさり解決したりするからです。

  • 普通のことですが、規則正しい生活が必要です。

 夜型だとしても、生活パターンを一定にしてください。乱すと集中タイムが短くなってしまいます。


  • やればやるほどバグが入ってソースを破壊しだしたら、自分が壊れてきたサインです。

 仮眠を取りましょう。寝る場所がないならトイレでもいいです。


  • 栄養ドリンクをむやみやたらに飲まないようにしましょう。あれは界王拳です。

 瞬間的に力が出てもその後肉体が破壊されます。

 飲むタイミングも重要です。朝からいきなり飲むと、日中倒れます。


  • どうにも眠いときは、栄養ドリンクより「眠眠打破」がオススメです。

 純粋に眠気だけ飛ばしてくれます。

 ただ飲んだ後おなかがかなり緩くなります。


  • 若い人なら性欲処理も忘れずに。ずっともんもんとするぐらいなら、

 ピンクなお店にいくなり、すばやくすっきりさせてください。集中力の妨げになります。


  • 自分の肉体もハードウェアです。

 スペックをしっかり把握して使ってあげてください。


  • 体は様々なサインを出してきます。いつのまにか別なとこを考えていたり、

 気がついたら寝てたり、肩こり、腰痛などなど。

 サインがでたら必ず小休止してください。

 まじめな人ほど無理して使って燃え尽きてしまいます。


  • 一般に頭のいい人というのは、自分の頭に入れられる量を自覚している人を指すそうです。

 普通の人は少ない頭にあふれんばかりに情報をいれるので、オーバーフローします。

 難解な作業はまず自分の頭に入るサイズに切り分けることが重要です。


自分もゲーム屋だったので、状況は理解できます。

「そう見積もらねばならない状況」では、「何か」を犠牲にして効率を上げるしかありません。


若いときの修行としてはいいのですが、こういう状況はいつか崩壊しますので、

体が持たない場合は転職を考えましょう。

自分を環境に合わせる力も必要ですが、自分に合う環境を探す力もまた重要です。

id:toby

id:shikakuさん、

具体的なアドバイスありがとうございます。

これは、テクニック的なものより、

集中する方が結果的に速度が上がるのではないかという問題定義であります。

id:toymanyさんの言われていることに近いと感じました。


多くのアドバイスは、

とにかく、

  • 集中時間を作り、
  • 集中時間を大切にし、
  • 集中時間をいかに伸ばすか?

に集約しているように思えます。


それだけ大切である、ということがうかがい知れます。


いわゆる驚異的な効率、スピードが出せる「神が降りた」という状態は誰にでもあると思いますが、

そのようなものを人工的に、作ることができるとよいですね。


職場に関しては、今のところが一番合っている……というより、

社会不適応者なので(笑)普通の会社だと無理という感じです。

(うつがひどくて突然2週間くらい休んでも、

あたたかく迎えてくれるところは中々ないと思う)

2008/02/28 18:58:49

その他の回答(15件)

id:practicalscheme No.1

practicalscheme回答回数157ベストアンサー獲得回数422008/02/22 18:09:17

ポイント50pt

いくつか問題がこんがらがっているようです。

まず見積りについて。いつも見積りの3倍時間がかかるなら、最初から「このくらいでできそうだ」と思った時間を3倍して伝えれば良いのです。(茶化しているわけではありません。それが誠実な見積りというものです。)

「そんなことできない、(顧客|上司)が許してくれない」というのなら、問題は別のところにあります。

  1. 顧客|上司はあなたの能力を過大評価している
  2. 顧客|上司は仕事の困難さを過小評価している
  3. 他の人ならその時間でできる仕事なのにあなたは3倍かかってしまう

(1)の場合は誤解を解くしかありません。納期に間に合わなくて困るのは先方なわけですから。無理な見積りを言わずに、「確実にやるにはこれだけどうしても必要です」と主張することです。

(2)の場合も最終的には先方にわかってもらうしかないのですが、説明だけでわかってもらうのは案外大変です。類似の事例 (ここでこの機能を実現するにはこれだけ工数がかかりました、のような) があれば理解を得やすいでしょう。そうでない場合、機能をブレークダウンして優先順位をつけ、少数の機能に絞って短期間で開発してみる、という手があります。で、ここでこれだけかかるので、全体ではこれだけかかります、と理解してもらいます。

(3)の場合、あなたが他の人と開発速度で競争する立場であれば、これは大きなハンディキャップです。問題がこのケースの場合はむしろ、開発速度で競争しない戦略をとるのはどうでしょうか。チームで作業しているのであれば、例えば他の手の速い開発者達がめんどうくさがってやりたがらないような地味な作業をこつこつと埋めてゆくとか、個人で請負をするなら同業他社にはあまり見られないユニークな技術に集中するとか。

ひとくちに「開発速度」と言っても、個人の中でさえばらつきは激しいですし(調子の良いときはどんどん書けるけれど、スランプになると全然だめ、とか)、また何を測るのかというのも曖昧です(一日何千行も新しいコードを書くのと、何年にもわたって誰も解決できなかった難解なバグを3日考えて直すのと、どちらが「速い」のか、とか)。

また、ひとくちに「プログラミング」と言ってもその内容は千差万別です。Joel Spolskyが 「5つの世界」

http://japanese.joelonsoftware.com/Articles/FiveWorlds.html で書いていますが、それぞれの分野でプログラムという作業に求められることはかなり違っていて、ある分野で優れた人を別の分野に引っ張ってきて同じくらい高い生産性が得られるとは限りません。

抽象的なまとめになりますが、まずは現在の自分に適したペースをよく知り、次に求められることのなかから自分にできる方向を見つけてそちらを強化してゆく、ということしかないのではないかと思います。

id:toby

質問に多くの情報をつめなかったため、

お手数をおかけします。


> 「このくらいでできそうだ」と思った時間を3倍して伝えれば


本来そうしなければいけないのですが、なかなかできないという現状があります。



「できない」問題に関しては、

部分的に(1)であり(と私が思っている)、大きな客観的事実として(3)があります。


(1)に関してはおっしゃる通りだと思います。

これからは、言わなくてはなりませんね。

問題は(3)なのですが、

人材が少ないため自分の担当の部分は自分以外に代替ができない状態です。

そういう意味あいでは有利?なのですが、

「これは 一週間で終わらせねば困る」という仕様や仕事を「一か月かかる」とは言えない状況です。

3倍の見積もりではプロジェクト自体が計画ができません。

(1か月のところなら 3倍の3か月で、となるとさらに無理です)


しかしながら、結局のところ私のせいで「計画がずれる」ということになれば、

再度、計画しなおさなければならず困るのはお互いですので、

そこは(1)のように「無理な見積もりを言わ」ないようにしなければならないと思います。



教えていただいた「Joel on Software」の5つの中では、

自分の担当は主に「ゲーム」であり、

部分的に「インターナル」(ゲーム用の内部向けツール)であります。

(現在は、PC向けのカジュアルゲームを開発しております)


その中でどんな速度がもとめられているかについては、

まずは最低限、仕様を満たす(動くもの)を求められています。



仕事以外で、その他の開発もしますがそれは「趣味」ですので、

多少遅れたり、途中で中断してもあまり悩むことはありません。


ただ、私自身、1か月相当のものを3か月もかかるということを想像しただけで、

仕事をこなす意欲というものがなくなり果て、

困っている面もあります。


具体的なアドバイス、大変参考になります。

ありがとうございます。

2008/02/22 20:21:33
id:tukihatu No.2

牛乳先生(tukihatu)回答回数180ベストアンサー獲得回数322008/02/22 19:34:19

ポイント50pt

参考になるかはわかりませんが…

見積もりに関しては、見積もり自体が駄目なんだろうと思うので気にする必要はないです。どう見てもSEや営業の責任ですよ。

開発のスピードを上げるには、なんといっても経験値が必要です。

たとえば一つの開発があったとして、そこに到達するためのステップが、経験がある人は1,2でいけるが経験が薄い人は10程度かかってしまう、ということでしょう。

とにかく経験をつむことです。いきなり速いスピードで作れる人なんていないです。最初は自信がないのも当然です。

遅いとか言われたら悔しいでしょうが、それを糧に先輩のコード盗んだり本読んだりして見ましょう。

先輩のコードは非常にためになります。というかそれ流用しただけでも工数がかなり速くなります(自分の力じゃないですけどね…)

もしプログラムがオブジェクト指向の言語だとなおさらですね。

一年ぐらいがんばっていると、以前と比べ物にならないぐらい速くなっていることに気づくと思います。

効率化するのも、もちろんスピードアップにはつながります。

基本的にプログラマに向いてない、というのはないと思います。深く考え過ぎなくても大丈夫です。

あったら便利なスキルは数学と飽きないことぐらいです。

あとプログラマは人に教えるのが苦手な人が多いみたいです。教わるときは要点をまとめてつつくといいです。

http://www.atmarkit.co.jp/farc/rensai2/thinking01/thinking01.htm...

id:toby

すいません、環境を書くことができなく、誤解を与えてしまいました。

見積もりは私も入れて決めていますので、

私の責任でもあるのです。



経験に関しては、私自身プログラミング歴は 10年 以上あり、

プログラミング自体も好きで、一年にひとつ新たな言語を学んだり、

常に新しい情報を仕入れているのですが、

正直、「趣味」での期間が長すぎたと痛感しております。


趣味であっても効率化は常に意識していますが、

スピードや早く仕上げる、

仕様を満たして見せる、

というようなことを意識したことはありませんでした。


おっしゃられる経験値に関しては、

たぶん「仕事」にしなければ、詰めない経験値なのだと思います。


趣味でも、とにかくベータ版のソフトを公開して的な開発はやってはいたのですが、

それともまた別な感じがします。

また、趣味の場合、研究の時間

(新しいライブラリを作ったりといった)

が長くとれるのですが、仕事だとその時間が取れず、

かなり行き当たりばったり的になってしまうところもあります。

かといって、再利用性を考慮しながら組むと、

速度がおろそかになります。



今までの自分の中にある概念を壊し、

仕事としてのプログラミングを再度学ぶ必要があるかもしれません。

また、仕事としての修行がいるのでしょう。


つらいですが、id:tukihatu さんのアドバイスから

今や、これからを乗り越えることが必要なのかと感じました。


残念ながらプログラマーの先輩はいないのですが、

幸いにして後輩が優秀ですので、彼らからも学ぶことにしたいと思います。


趣味と仕事との違いを再認識させられます。

ありがとうございます。

2008/02/22 20:21:53
id:thewizardofoz No.3

thewizardofoz回答回数32ベストアンサー獲得回数32008/02/22 21:09:39

ポイント50pt

元々時間が他の人よりもかかるのであればスピードを上げようと思ってもなかなか上がらないものです。

ここは発想を変えて、スピードそのものを上げるのではなく効率を上げることを考えましょう。

効率と言っても難しいので「できるだけ楽ができる方法をみつける」という風に考えてみるといいです。

「楽な方法」=「ちんたらやっても間に合う方法」ですのでスピードを上げるよりも効果があります。

道具に凝ってもスピードが少し上がれば御の字ですが、何か「楽ができる方法」をひとつ見つけるだけで劇的に見かけのスピードは上がります。例えば何度も繰り返すような事は一度で済むようにするとか再利用できるものは再利用するとか他の人に任せられるものは任せてしまうとか今までのやり方に対して疑問を持ち、それを別の方法でやれないかいつも考えるのです。

http://www.google.co.jp/search?q=%E6%A5%BD%E3%82%92%E3%81%99%E3%...

id:toby

id:thewizardofoz さんありがとうございます。


「効率的」でもなく「楽な方法」、

考えさせられます。


> 何度も繰り返すような事は一度で済むようにするとか

これは、DRY的な要素をコーディングレベル以前の段階で

適用する、ということですね。


> 他の人に任せられるものは任せてしまうと


たぶん、これがキーポイントかな?と感じました。

特にゲーム系でリソースの制作は分離しやすいですので、

できるだけ、自分の分担する部分を減らすことができないか?を

(つまり、プログラム依存部分をいかに減らすか?)

考えて取り組まないといけないのかと思います。

2008/02/23 07:50:03
id:MasaMura No.4

MasaMura回答回数8ベストアンサー獲得回数02008/02/23 17:57:45

ポイント50pt

1.複数新しい試みをしてませんか?

2.ソフトに対して洗練し過ぎていませんか?


(1)

新しいアクションを起こすにはコストが掛かります。

HHKになれるまで、暫くのあいだタイピングの速度は2倍落ちます。(私は挫折しました)

カスタマイズソフトを手に馴染ませるタメには動作を覚え、カスタムして、Helpを読むのに一日潰れます。

私も常に効率化を考えていますが、複数の事を一気にしようとすると大幅に効率が落ちるのでしません。

文章を読む限りでは複数の事を一気に進めようとしてませんか?


(2)

リファクタリングをするのは大切です。

が、アルゴリズムに究極はありません。そして、常に洗練されたアルゴリズムを書くのはナンセンスです。

私はやっつけコードとキレイなコードを見分けるのも大切な事だと思います。

いぜん美しいコードについてBlogを書きました。よろしければ見てみて下さい。

http://d.hatena.ne.jp/MasaMura/20080208


単体テストも大切です。

しかし、テスト技法を学び全て通しテストをするのは現実的に時間がありません。

ある程度までテストすれば後はテスターさんにお任せしてはいかがでしょうか?


thewizardofozさんは、ソフトウェア工学に縛られてませんか?

全てを実践するのは10年以上は軽く掛かると思います。

一つ一つ解決するのが良いと思います。

恐らく私よりも遥かに腕は上と思われます。

なのでどこかで何かをつかむ事が出来るでしょう。

マジメな人が爆発する時は一気に花が咲くと思います。

頑張ってください。

id:toby

> 1.複数新しい試みをしてませんか?

orz 図星です。これはあります。

つい、複数のことを同時進行してしまい、どれもうまくいかないことがあります。

どうもこれは私の性格上のようです。


ご心配をおかけしましたHHKとカスタマイズについては、今は大丈夫です。

HHKは自分の求めていた理想のものでしたし、

キーカスタマイズは数年前に行ったもので今は慣れてしまっています。


ただ、やはり、今でも新しいことをやろうとすると、かなり時間がつぶれるということはあります。

誰でもそういうものだろうとは思いますが、

なるべく、新しいことは常に1つという状態にしたいものです。

> 2.ソフトに対して洗練し過ぎていませんか?

これもあります。


リファクタリングによってよりよいコードを書くことに

目覚めましたが、かなりこだわりすぎな感があります。

昔はもっと、臨機応変に適当なコードを書いていました。

スピードもあったように思えます。

(昔はテストは全く書いてませんでしたので、まずかったですが……)


最近は、Rubyを書いていてもつい自然とgolfをしてしまいます。


病的にまでに、綺麗に書かねばならないと思っている節があるかもしれません。


BLOGのエントリーは興味深く読ませていただきました。

私は、トラックバック先の方と同じような意見を持っていました。

今の現状を考えて、反省せざるを得ない面もあるかと思います。


コードを綺麗に書くにもテストをするにも「適度」が肝心なのでしょう。

その辺の見極めが今後、必要になってくると思います。


id:MasaMura さんにはいくつかの気づきをいただきました。

ありがとうございます。

2008/02/25 00:14:05
id:toymany No.5

ヤマヤタケシ回答回数4ベストアンサー獲得回数02008/02/24 12:27:47

ポイント50pt

自分も、実際の時間は見積もりの3倍以上かかります。

これは、見積もるときには「集中して作業したとしてこれぐらいかかる」と考えるからです。

しかし、実際には、

誰かに話しかけられる、

RSSに興味深いニュースが出た、

お腹が空いた、

トイレに行きたい、

などなど、

さまざまなイベントにより集中状態が切れます。

ソフトウエアを作っているのは動物であり人間である自分自身である。

ということを受け入れることで納得しています。

トムデマルコ氏の「ピープルウエア」が参考になるのではないかと思いました。

http://www.amazon.co.jp/dp/4822281108?tag=toymanspage-22&camp=24...

id:toby

id:toymany さま、

異なった視点でのアドバイス、ありがとうございます。


MAX作業時間で見積もってしまうことは多いように思えます。

これは何時間、これは何時間、だから計何時間かかる、

1日 x時間作業できるから、何日間かかるといったようにです。

人間である以上、集中できる時間は限られている、

ということを自覚して計画を立てる必要がありますね。


前にも同様のブログのエントリーを見た覚えがあります。

今探して残念ながら、見つかりませんでしたが、

以下の方法は参考になるかもしれません。


集中力を高め、仕事に余裕を生む「70%予定管理法」 - ELECTRIC DOC.

http://e-doc.no-ip.com/archives/499


参考図書ありがとうございます。

「ピープルウェア」は読んでみたいと思います。

2008/02/25 15:14:53
id:gm_kou No.6

gm_kou回答回数26ベストアンサー獲得回数12008/02/24 14:32:49

ポイント50pt

見積もりに対して作業時間が3倍かかった.その原因を突き詰めていないからではないでしょうか?

作業項目を細かく洗い出して,それぞれに時間を記録していき,繰り返し見積もりをアップデートしていけば,自ずと精度があがると思います.

http://www.itmedia.co.jp/bizid/articles/0606/27/news003.html

id:toby

> 見積もりに対して作業時間が3倍かかった.その原因を突き詰めていないからではないでしょうか?


遅れる大概の大きな理由としましては、

「予想外のトラブルが起きたり、仕様が増える」という点

(つまり、動的にタスクが次々に増える)と

「予想よりも、単純に実装に時間がかかる」

id:toymany氏の言われているような外的要因や、集中力の持続時間、そもそもコーディングの時間が取れないなど)

という2つの点がほとんどなのですが、

個々のタスクの計測や原因の突き詰めまでは

行っておりませんでした。


全体のタスク自体は、アップデートしながら行っているのですが、

個々の記録は、どの程度かかったか、などを付ける必要があると思います。


URLのGTDは最近、取り入れようとしているところでした。

ただ、GTDのやり方そのものには、少し疑問があり、

4HWW本の Tim Ferris が言っていたように、

タスクを細切れにするよりも、不必要なタスクをそもそも消すことが大切なのではないか?と考えてきています。

(仕様上どうしても必要ではないところは、実装をしないことにする、といったような)

2008/02/25 15:35:25
id:atsushifx No.7

atsushifx回答回数26ベストアンサー獲得回数02008/02/24 18:51:06

ポイント50pt

http://boost.cppll.jp/HEAD/

URLはなんとなく。こういった考え方が大事かなというくらいです。

資産は作っていますか?

この場合の資産は、クラスライブラリやEditorのマクロなど効率を上げるためのソフトです。

似たようなことを繰り返して開発していては効率は上がりません。

自分が同じようなものを開発しているのなら、それを共通化し後で使えるようにブラッシュアップすれば時間が節約されるでしょう。

エディタのマクロも同じです。定型的な作業であれば、マクロにすることで同じ作業をする時間が減ります。

自分の仕事のやり方を見直してみる必要があると思います。

id:toby

id:atsushifx さまありがとうございます。


私は、常に資産を作るように、

なるべく、個別の機能はライブラリ化していますが、

(でないとテストもしにくいからなのですが)

資産を使いまわせるようにすると、かえって開発の時間がかかってしまいます。


ただ、コピペコピペでやろうとした時期もありましたが、

その時は、何故同じ処理を書かねばならないのだろうと、

かなりノイローゼに陥りました。


現場では、資産を作ることはどうしても速度が落ちることにつながります。

その辺のトレードオフの見極めが必要だろうと思います。


エディタの支援機能、スニペット、コード補完などは、

現時点でもフルに活用しています。


実は、メインの言語は Delphi なのですが、

一般のライブラリのポーティングなどがあまり行われないため、

いざ使おうとすると、自分でポーティングしなければならず、

下手をすると、時間だけがかかり、失敗に終わったり、

結局、ライブラリすら使えないという状況に陥ったりします。

(以前は、いい加減、組み込み用のスクリプトの自作はやめようと、

Squirrelを組み込もうとしたのですが、一か月かかって失敗に終わりました)


Delphi は素早くツールを作る分にはよいのですが、

そろそろ限界に近いのかもしれません。

(とはいえ、C++のコンパイル速度は、集中力を途切れさせるには十二分なので、

乗り換え先がなく困っています)


新しいプロジェクトが ActionScript になる可能性があるのですが、

また別の言語環境なので、資産が一からやり直しになり、

今以上に、遅くなるのを非常に恐れています。


私は、言語が違うだけで車輪の再発明をしなくてはならない状況に、

かなり嫌気がさしています。

2008/02/25 15:51:48
id:yo-net No.8

yo-net回答回数266ベストアンサー獲得回数212008/02/26 20:57:30

ポイント50pt

たぶん、あまりにも目標レベルが高いだけの様な気がします。

力は十分にありそうだし。

ただ一つあまりにも美しいプログラム作りに固執しすぎなのかなと感じました。

制作速度を高めるためにちっとやぼったい処理で一時しのぎもいいのかなと感じたりします。

確かに動作速度は落ちる事があるかもしれませんが。

三倍時間がかかると言うことは、納期が三倍遅れてる事になのでこれは結構顧客を怒らせるかもしれません。

美しいプログラムより、バク取りしてとにかく動くプログラムの早期納期に集点を取られたらどうでしようか?

http://www.hi-ho.ne.jp/skinoshita/seki06.htm

id:toby

どうもありがとうございます。


id:yo-net さんのおっしゃられるように


  • 目標レベルが高い
  • 美しいプログラムに固執しすぎ

それは私のプログラムには多いにありうることです。


趣味プログラミングでは、こだわりとなっていたものが、

仕事のプログラミングでは、足かせとなっている感があります。

まざまざと違いを感じさせられます。


やはり、「とにかく動くプログラム」に注する必要があるのでしょう。

2008/02/28 17:23:44
id:fujibar No.9

fujibar回答回数1ベストアンサー獲得回数02008/02/27 00:35:50

ポイント50pt

コードを書くことに着目しすぎていませんか?

あなたがとっているモノは、すべてHOW TOとか物理的なスピードを上げるものばかりです。

コードを書く前に、「何を」作るのか、「何のために」作るのかを考えてから、

コーディングした方が良いでしょう。

プログラミングに必要なものは、論理的に考える力です。

http://www.amazon.co.jp/%E8%80%83%E3%81%88%E3%82%8B%E6%8A%80%E8%...

id:toby

id:fujibar さまありがとうございます。


質問文だけでは読み取れないので、申し訳なかったのですが、

私は、他の人から見ても常に論理的に考える方ですので、その辺に関しては心配はないかと思います。

(その上で、HOW TOなどのテクニックなどを取り入れている、といったところです)

ただ、今までの自分を見るに、その論理的に考える方法が、(効率ではなく)スピードを上げるのに結びつくのか?という点については疑問に思ってしまうのです。

たぶん、私の論理的解法に足りないものがあるのでしょう。


書籍の紹介ありがとうございました。

足りないものを補間できるのでは?という期待とともに、ぜひ、読んでみたいと思います!

2008/02/27 08:38:42
id:shikaku No.10

s回答回数12ベストアンサー獲得回数22008/02/27 07:34:59ここでベストアンサー

ポイント500pt

http://www.wankuma.com/seminar/20070602tokyo8/Default.aspx

「R流・職業プログラマー向け生産性向上の工夫」を見てください。非常に現実的な解だと思います。

効率よく高速に作業するには、集中できる時間を作らなければなりません。

テクニックは二の次です。

集中力を上げる方法を以下に記します


  • 人間が1日に集中できる時間は約2時間と言われてます。

 いかにその集中できる時間に難解な作業を当てるかが重要です。


  • 一般には朝ご飯を食べて2時間後が一番頭の回転が速くなります。

 ここに集中タイムとするといいでしょう。

 前日の最後に集中タイムにやることをまとめておくと、この貴重な時間帯を消費しなくてすみます。


  • 集中タイムには割り込み禁止にします。

 できればこの時間だけでもいいので個室にこもるとGoodです。

 人がやってきても追い払ってください。話しかけるなオーラを出すことが重要です。


  • 集中力がきれたなーとおもったら、作業を中断して休みましょう。

 ドリンクタイムにしてもいいですし、打ち合わせや相談、雑談など

 人と絡む作業を入れると切り替えやすいです。


  • 雑談は非常に重要です。作業上悩んでいたことを話しただけであっさり解決したりするからです。

  • 普通のことですが、規則正しい生活が必要です。

 夜型だとしても、生活パターンを一定にしてください。乱すと集中タイムが短くなってしまいます。


  • やればやるほどバグが入ってソースを破壊しだしたら、自分が壊れてきたサインです。

 仮眠を取りましょう。寝る場所がないならトイレでもいいです。


  • 栄養ドリンクをむやみやたらに飲まないようにしましょう。あれは界王拳です。

 瞬間的に力が出てもその後肉体が破壊されます。

 飲むタイミングも重要です。朝からいきなり飲むと、日中倒れます。


  • どうにも眠いときは、栄養ドリンクより「眠眠打破」がオススメです。

 純粋に眠気だけ飛ばしてくれます。

 ただ飲んだ後おなかがかなり緩くなります。


  • 若い人なら性欲処理も忘れずに。ずっともんもんとするぐらいなら、

 ピンクなお店にいくなり、すばやくすっきりさせてください。集中力の妨げになります。


  • 自分の肉体もハードウェアです。

 スペックをしっかり把握して使ってあげてください。


  • 体は様々なサインを出してきます。いつのまにか別なとこを考えていたり、

 気がついたら寝てたり、肩こり、腰痛などなど。

 サインがでたら必ず小休止してください。

 まじめな人ほど無理して使って燃え尽きてしまいます。


  • 一般に頭のいい人というのは、自分の頭に入れられる量を自覚している人を指すそうです。

 普通の人は少ない頭にあふれんばかりに情報をいれるので、オーバーフローします。

 難解な作業はまず自分の頭に入るサイズに切り分けることが重要です。


自分もゲーム屋だったので、状況は理解できます。

「そう見積もらねばならない状況」では、「何か」を犠牲にして効率を上げるしかありません。


若いときの修行としてはいいのですが、こういう状況はいつか崩壊しますので、

体が持たない場合は転職を考えましょう。

自分を環境に合わせる力も必要ですが、自分に合う環境を探す力もまた重要です。

id:toby

id:shikakuさん、

具体的なアドバイスありがとうございます。

これは、テクニック的なものより、

集中する方が結果的に速度が上がるのではないかという問題定義であります。

id:toymanyさんの言われていることに近いと感じました。


多くのアドバイスは、

とにかく、

  • 集中時間を作り、
  • 集中時間を大切にし、
  • 集中時間をいかに伸ばすか?

に集約しているように思えます。


それだけ大切である、ということがうかがい知れます。


いわゆる驚異的な効率、スピードが出せる「神が降りた」という状態は誰にでもあると思いますが、

そのようなものを人工的に、作ることができるとよいですね。


職場に関しては、今のところが一番合っている……というより、

社会不適応者なので(笑)普通の会社だと無理という感じです。

(うつがひどくて突然2週間くらい休んでも、

あたたかく迎えてくれるところは中々ないと思う)

2008/02/28 18:58:49
id:YOSIZO No.11

YOSIZO回答回数64ベストアンサー獲得回数12008/02/27 15:07:20

ポイント50pt

自分もゲーム業界の端っこで仕事してますが、見積もりの3倍かかるって、割と普通ですよ。

と言うか、見積もりを「何も問題が起きず、雑用も発生せず、全期間で集中して仕事をこなした最速の時間」で考えて、そのまま相手に伝えるから失敗するのです。

それかデバッグ・調整期間を考慮に入れてないとか、企画側の「なんか遊んだ感じがイメージと違うなぁ。こうしない?」攻撃が頻発する職場だったりとか。

特にゲームは予想外の事態が発生しやすい業界ですので、3倍でもギリギリという事も。

まずは普段から3倍の見積もりを出すようにし、仕事の完了後には「実際にかかった時間との差」を意識するようにすれば、本当の見積もりを出せるようになると思います。

ようは慣れです。

http://dummy.com

id:toby

どうもありがとうございます。


私はどうも、予想外のことを考えていなかった気がします。

細かく、実際の作業を作業内容をあらいだせない点も問題としてありました。

(上でも出ていたように、たぶんプロとしての経験値が足りないためかと)


「これは、たぶんこの2つやることがあるからこのくらいだな?」という感じで、

アバウトに見積もってしまいがちでした。


id:YOSIZOさんの言われるように、予想外のことも見積もりに入れるようにして、

自分の実際にかかる、想定される見積もりを出していければ、と思います。

2008/02/28 17:03:27
id:gatas No.12

gatas回答回数1ベストアンサー獲得回数02008/02/27 23:34:27

ポイント50pt

自分の場合常にここで障害が発生したらどうなるのか、

障害が発生した場合に原因の特定がしやすい状態になっているかを

常に頭に入れながら開発してますね。


そうやって製造しているとただ動けば良いと考えて製造している人とは単体テストを

開始する前の段階でプログラムの完成度がかなり違ってきます。

嗅覚が鋭くなるとでも言うのかな。


プログラムの製造はそこそこ早いのにいざ結合テストをしてみると

バグだらけだし、バグを修正してまた新たなバグを発生させたりする人が

私の周りでは結構いたりします。


10年やっててプログラミングのスピードを上げるのは難しいでしょうから

単体テスト前の段階でのバグを少なくする努力をした方が良いのでは。


過去の資産を有効活用するというのもありですよね。

プログラムのソースだったり単体テストの手順だったりデータだったり。


個人的にはプログラムの製造が遅い人よりバグばかり発生させる人の方が

プログラマーに向いていないと思います。


ダミー

http://www.yahoo.co.jp/

id:toby

id:gatas さん、ありがとうございます。


せっかく、お答えしていただいたのですが、

私としては、具体的な手法なりなんなりでなければ、

わかりかねない部分があります。


バグを少なくするために、「単体テスト」なり「結合テスト」なりを導入するものかと思いますが、

「単体テスト前の段階でのバグを少なくする努力」?

というのがちょっとわからない感じです。

(Assertを無意識レベルで挿入するようにするとかの契約プログラミング的な手法を導入するとか?かなと予想)


過去の資産は同意です。

あれば、あるほど早くなると思います。


> 個人的にはプログラムの製造が遅い人よりバグばかり発生させる人の方が

> プログラマーに向いていないと思います。

むむむ。

そういうものなのですかね……。

2008/02/28 17:11:50
id:kekekun No.13

kekekun回答回数13ベストアンサー獲得回数02008/02/28 01:30:06

ポイント50pt

製作の一部分の速度を上げれば、トータルの製作時間も短くなるというように考えているならそれは間違いです。やらなければならないのはトータルの製作時間を短くする事です。

一見時間がかかるような事でもトータルの製作時間に寄与する事であればやるべきですし、キーボードやらショートカットやら一見時間を短縮しているようでも、それが逆にトータルの製作時間を延ばしてしまっていることもありえます。

全体最適化について下記がお勧めです。

http://www.amazon.co.jp/%E3%82%B6%E3%83%BB%E3%82%B4%E3%83%BC%E3%...

id:toby

「トータルの時間」ですか……。

言葉の意味以上の実感、違いがいまいちわからないところがあります。

id:kekekun さんの紹介された書籍を参考にさせていただこうかと思います。


ゴールは興味がありつつも、読んだことがありませんでした。

視点を引いた、全体的な工程管理レベルの最適化だと思うのですが、

面白そうなので読んでみたいと思います。


ありがとうございました。

2008/02/28 17:27:18
id:quocard No.14

quocard回答回数31ベストアンサー獲得回数22008/02/28 09:51:16

ポイント50pt

 開発環境を整えても開発効率が上がるというわけではありませんが、処理待ちなどでのストレスなどが軽減されるのでそれは良しとしましょう。

 まず第1にどの部分で一番時間がかかっているのか?手間取るのか?といった事を洗い出す必要があると思います。

仕様の作成や開発やチェックやバグ取りなど色々とあると思います。

いつも同じ所で時間がかかっているのなら何故そこで時間がかかるのか考えるべきです。

また時間がかかったとしてもそれが適切な時間ならば問題はないかと思いますがそこは予算や会社のつきあいなど色々とあると思います。

 あと個人的な感想ですがプログラムに向き不向きがあると思いますが、言語で見た場合もあると思っています。

同じものを作るにしてもCだとさくさく出来るけど他の言語だと時間がかかるとか・・・。

 ですが最初から上がってくる仕様書や期間に無理があるなら仕方ない場合もありますかね・・・。

http://q.hatena.ne.jp/

id:toby

id:quocard さん、ありがとうございます。


「どの部分で一番時間がかかっているのか?」


いわゆる『パレードの法則』を思い出しました。

「2割の時間がかかっている部分を解消すると、8割の時間短縮が可能である」

といったような……。

もしくは、

「2割の時間がかかっている部分を解消すると、8割の効率改善が可能である」

的な。

実行効率ではなく、開発効率のボトルネック的な部分はあるのかもしれません。

今まで、意識したことがなかったのですが、

意識する必要があるようですね。



言語に関しては適材適所がある、ということに帰結するように思えます。


今使っている言語が、向いていないということになるのかなぁ、と。

(今の場合だと、ゲームにおいてDelphiよりももっと効率のよいものがあるという話)

2008/02/28 17:35:58
id:lichten No.15

lichten回答回数6ベストアンサー獲得回数02008/02/28 10:09:21

ポイント50pt

http://www.aoky.net/articles/jeff_atwood/how_long_would_it_take_...

リンク先で紹介されている、「ソフトウェア見積り―人月の暗黙知を解き明かす」という本を読むのはどうでしょうか。この質問は、ちょっとした返信で解決できる範疇を超えているように思えますので、私はまとまった書籍を読んでみることをおすすめします。

ただ、質問の回答になりませんが、誰でも見積もりより大きくなるものみたいですよ。うろ覚えですが、Rubyの設計者であるMatz氏でさえ、日記で「とりあえず見通しの2倍でスケジュールを伝える。実際そのぐらいになる」と書いていたことがあります。(リンクしたかったのですが、見つけられなくて挫折しました。いい加減な話ですみません)

id:toby

id:lichtenさんが紹介いただいた「ソフトウェア見積り」は内容的に気になるところです。

まとまった書籍というこおで、この質問の回答で出された参考図書は一通り読んでみたいと思います。


> Matz氏でさえ、日記で「とりあえず見通しの2倍でスケジュールを伝える。実際そのぐらいになる」と書いていたことがあります。


私もMatz氏の日記を検索してみたのですが、見つかりませんでした。

本当に あのMatz氏が言われていたら非常に興味深いところです。


回答ありがとうございました。

2008/02/28 18:05:18
id:cergey No.16

cergey回答回数4ベストアンサー獲得回数02008/02/28 15:27:30

ポイント100pt

http://www.hatena.ne.jp

すいません、ポイントはあえて狙いません。ごく気休めな回答を。


昔、新卒でソフト会社に就職して、社員研修の最初の講義で

「我々が言うシステムって何でしょう?」という話が始まって、講師の答えが、

「ある仕事をするための連続した手続きが、有限個にまとまったもの。」

という簡単なものでした。彼は何か業績のあるエンジニアでもなく、普通の中年SEさんでした。


この定義が合っている合っていないかは別として、

ともかく彼が一番強調したのは、「有限個」という言葉でした。

有限個でない手続きが連続したものはシステムでも問題解決でもない、

我々が作るものは必ず有限なものでなければならない、という話でした。


私はこの言葉を聴いてから10年経った今も、このことをずっと心に留めています。

自分に直面した問題を、できうる限り、有限な形にする。どこかに終わりを作ってやる。

たとえつまらない形でも、荒削りなものでもいい。無限をはらんだものよりはずっといい。


無限とはつまり、「矛盾」です。互いに相反する事象が同時に起きようとすることです。

簡単な例なら、現実にできる仕事量より多くの見積りが出た場合。

現実の要求より概念の美しさを選んだり、周囲の要求より自分の要求を押し通した時。

プログラミングが好きなのに、解決案もなく他人から問題を指摘され、向いていないと言われてしまう時(これは失礼な話。)。

そういった時に矛盾(=無限)はよく発生し、自分も周囲も機械も不幸になります。

他人や自分の中に無限というものを見出した時は、これは疫病だと思って避けてください。

(むやみにツールをあさっているような時は、少し無限が発生している兆候がありますよ・・。)


ここからは蛇足です。

見積りを問題にされていますが、見積りは所詮、誰かの概算と希望のモデルで、答えではありません。

かならずそこには問題があります。その問題(矛盾)を先に殺してはいかがでしょうか。

ただ単にモノを作ることよりその方が大事です。


あと、名詞で物事を考えるより、動詞で物事を考えましょう。

勉強熱心なのはいいですが、名詞(技術用語)はいつの時代も早く無限に増加しますが、

動詞の増加はさほど急激ではなく、有限個しか覚えてなくても十分生きてゆけます(笑)。

id:toby

id:cergey さんありがとうございます。

今まさに異なったベクトルの意見をいただき、

とまどいながらも衝撃を受けております。



>「有限個」

仕事の上での直接的な意味では、

仕事を「曖昧」に定義するのではなく、

具現化した具体的な、細分化した仕事にするということが大事だととらえました。


無限であることは、進行管理的にも精神的にも悪いことは、

過去の(趣味での)プロジェクトで経験し実感しているところです。

終わりがないという意味合いでです。


実は、この質問中に GTD の本も読んでいたのですが、

私はかなり日々のタスクを「曖昧」にしていたことに気付かされました。



無限を「矛盾」ととらえた意味に関しましては、

私の場合、矛盾はなかなか回避できないもののようです。

私がよく陥る、「手段が目的になる」といった類も「無限」なのかもしれません。

特に私のこだわりのようなものが、人生の邪魔をしている(つまり無限に、つまり自分を不幸に)ように思えます。


甲野善紀氏のよく言われる「矛盾を矛盾のまま矛盾なく取り扱う」こともヒントになるのかもしれません。

参考URL:「身体を通して時代を読む」ノート

http://www.bekkoame.ne.jp/~topos/siso/sintai/sintai.htm#note2


「無限」「有限個」という言い回しは、独特で聞き慣れなかったのですが、

異なる発想で参考になりました





「名詞ではなく動詞で考える」これは私もよく聞きます。

(私はの場合は何かの自己啓発本かビジネス書だったと思いますが)

言われても理解できない、自分が実感しないと理解できないということがありますが、今こそそのときなのかも?

でも、この質問の問題に適用できるのかが、ちょっとわからないかったりします……。

2008/02/28 18:34:05
  • id:hogege
    「いつも見積もりの3倍時間がかかってしまいます」
    ということは、そもそもその見積もり自体が駄目なのでは?
  • id:dev_zer0
    手戻りを少なくする
    具体的にはバグを少なくすればデバッグする時間は減る

  • id:practicalscheme
    あと、最適化の基本ですが、どこに時間がかかってるかを知ることも役に立つかもしれません。

    + 問題を正確に把握するのに時間がかかるのか、
    + 問題を解決するアイディアを思いつくのに時間がかかるのか、
    + アイディアを実装するのに時間がかかるのか
    + ひととおり実装してみたがうまく動かなくてバグを取るのに時間がかかるのか
    + アルゴリズムがちゃんと動くようになってから、実用レベル(異常系の処理だとか、性能のチューニングだとか)に時間がかかるのか
    + ソフトとして動くものが出来てからデリバリ可能なものに仕上げるまでに時間がかかるのか

    これは扱う分野にもよります。いつもほとんど同じような仕事しかしないのであればおそらく1,2あたりは問題ではないでしょうから、とすると他のコメントにあるように、それまで書いた資産をどううまく流用するとか、バグをなるべく出さずに手戻りを少なくするといった手があるでしょう。

    逆に、最初は問題の細部までが見えておらず、したがってこれといったアイディアもすぐには思い浮かばない仕事もあるでしょう。その場合、1,2に多くの時間がかかることを見込んで、「アイディアを試すためのプロトタイプ」をまず作ることに集中するという手があります。私の仕事はこのパターンが多いのですが、この場合は動くものができてからがスタートラインです。従って「これだけ時間をかければ動かせるだろう」という感覚を外挿して見積りを出すを悲惨なことになります。こういう場合、私は見積り期間中にプロトタイプを作ってしまいます(それが出来ないような仕事は請けません。責任取れませんから)。そこでアイディアが得られればだいたいの見積りははじけますし、まだ曖昧なら機能要件を分割してワンステップづつやるようにします。

  • id:practicalscheme
    ああ、連投になってしまいますが、お返事がついていたので…

    私も趣味でも仕事でもプログラムを書きますが、趣味で80%のものを作るのと、仕事で100%のものを作るのとでは、仕事量として1:10くらいの差があると感じていますよ。だから趣味で書いている感覚に比べて仕事で1/3しか速度が出てないのであればむしろ速いくらいだと思います。
  • id:KUROX
    転職ですかね。

    >自分の担当は主に「ゲーム」

    文面みると、ゲーム特有なものもある感じですね。
    他の分野に行けば、どうですか?
    ほかの分野のプログラマーはまた違いますよ。
    逆に、他の分野のプログラマーは速度遅いと感じるかも。
  • id:popattack
    > 「このくらいでできそうだ」と思った時間を3倍して伝えれば
    >本来そうしなければいけないのですが、なかなかできないという現状があります。


    この考えは間違っていないでしょうか。仕事を受注するために嘘をついているという
    ことですよね?3倍の時間を相手に告げることができなかったら、自分で吸収するしか
    ないと思います。何を使って開発しているかは知りませんが、もっと開発効率がよい
    ものに変えるとか。Ruby on railsとか・・・
  • id:tukihatu
    あわわ、そんな続けてる人とは知らずご無礼を…
    >プログラマーとして生きていこうと決めた
    と書いてあるからてっきり^^;
    自分もまだ一年そこらなので…

    自分の場合は、この時間でできます!って無茶いって、後で3徹とかしてひーひーいいながら何とか納期までに収める、っていう荒業をずっとやっていてスピードがかなり上がりました。
  • id:YOSIZO
    10年選手ですかー。ベテランですね。
    回答ではなんか偉そうに書いちゃいましたけど、自分が言ったような事は既に実践済みなんでしょうね。

    ゲーム業界で10年も生き抜いてこれたのなら、今までのやり方を通せばいいような気もしますが、さらに効率化を考え、開発環境を整備したり、ネットで質問したりと、実際の行動に移されている姿勢は尊敬しちゃいます。

    ここは考えを変えて、「俺は手が遅いよ宣言」をするのはどうでしょうか?

    自分も同じくらいゲ界をウロチョロしてますが、最近は「俺、仕事遅いですから!」と最初に敗北宣言しちゃいます(^^;
    その上で、アイデア出しに積極的に関わったり、社内SE見たいな感じでサーバー構築を買って出たり、新人教育の講師をやったりと、コーディング速度を求められない部分で仕事に関わるようにしています。
    色々と手を広げたおかげで(WebもLinuxもDBもゲームもWindowsアプリもとりあえず何か組めるレベル)重宝がられるのか、お仕事に困った事もないです。

    こんなヘタレプログラマーでも意外と何とかなっちゃうもので、ゲームプログラマーのくせに3Dや物理演算とか苦手で設計も下手くそなのですが、それでもゲーム業界で飯食えてます。
    (そりゃ、常に上を目指したいとは思ってますが、こればっかりは自分の能力がこうなので「ま、しゃーないか」と達観)
  • id:toby
    ぐは。誤解を与えてしまいました。
    プログラマー歴は10年以上ですが、仕事歴はまだ全然ありません
    趣味プロがほとんどです。

    たくさんのコメントありがとうございます。
    コメント欄のレスは後ほどいたします。
  • id:lichten
    見つからないと書いたページが、見つかりました。一応張っておきます。
    http://www.rubyist.net/~matz/20070523.html#p03
  • id:cergey
    わかりにく内容に対して大変丁寧なレスをくださり、ありがとうございました。
    無限=矛盾なんて意味不明!な感じで、
    私もかなりフィーリングで書いてしまったので大変申し訳ございませんでした。

    意味的には、無限=矛盾=現実世界のバグ、です。これはプログラミングのバグと同じ意味のバグです。
    たとえば・・うつ病の人に「がんばれ」と言うとかえって逆効果だといいますよね。
    それは本人ががんばれないから(もしくはがんばっても効果がないから)困ってるのに、
    何も方向性がないのにさらにがんばれば当然問題が拡大するし、
    そしてそれに気づかずがんばり続けると「無限ループ」になり、いつか心身ともに破綻してしまう。
    片や計算機に「整数を0で割れ」と言うと、対策がなければ同じような反応をするかもしれない。
    こういう無限ループ、負のサイクルを、無限と表現させてもらいました。

    創作という行為は、こういう論理の落とし穴との戦いだと思います。
    プログラマは皆、同じように苦しんでいると思いますよ。

    あと名詞より動詞で考えるという件ですが、
    仕事をする時に頭の中に変数やその代入が多いとバグ(間違い)が起き易く、
    頭のメモリ管理も複雑になったり、過度に慎重になったりして大変、というぐらいの意味ですw。
    要するに気苦労で倒れるぐらいなら空っぽの頭でいる方がいいよとw。
    エンジニアは知識商売だと思いますけど、それが重荷になることも多いと思います。
    以上です。
  • id:deadly_poison
    つデュアルスクリーン
    これだけでも結構効率アップしますよ
  • id:kumeuchi
    普段日常会話で話す日本語と同じぐらいのスピードでプログラミング言語を書けるようになれればいいですよね。その為には才能と知識と勉強。
    以前 Delphi で DirectX のゲームを作ったときは、勉強2週間・製作2週間ぐらいでした。

    プログラミングが遅い原因を周辺機器に求めるところなど、問題の切り分けができていないのでは、と思いました。その辺りも開発の遅さの原因でしょうか。
    (辛口ごめんなさい)
  • id:garyo
    私はいつも「自分が思った見積もり時間」×2を見積もりとして提出してますよ。
    100%その仕事だけできるといいですが、たいてい他の仕事の割り込みや、想定外の問題などが発生するのであらかじめマージンを入れておきます。
    見積もりは最初に出す時はある程度融通が利きますが、一度出すと他の工程との連携があるので早めることは出来ても伸ばすことは難しいです。
    そして、実際の作業では遅れることはあっても、早く終わることは少ないです。
  • id:raitu
    色々な手法を導入する「目的」が矛盾している為に起こっている問題に見える

    会社としては「限られた時間内で作成できる、とにかく動く最低限のもの」を作るのが目的
    本人としては「ある程度の質を担保した、リファクタリング済みのもの」を作るのが目的

    で、会社側の目的と本人の目的が噛み合っていない事が問題の本質であって
    手法云々の話ではないように見える。

    本人は「いい仕事」をしたいけれど、それを会社側が時間の都合で許可しないという所だろうか。

    様々な手法を使う「目的」が、早く仕事を終わらす為の手法というより
    「質の高いコード」を生産するために行っている様に見受けられる。
  • id:rurueru
    私はプログラム暦は10年、業務(C++,Linux,リアルタイム,組み込み系)は5年です。
    高校までは趣味で、大学→大学院は情報系で、大学院もソフトウェア工学系でした。

    私も理解するのに業務で3年ほどの経験を要しましたが、
    経験則として最適な工数(95%の確率で目標工数より下回れるような工数)は、
    最もうまくいった場合の3倍ほどはかかるという認識です。
    (一時はすべての工数を記録していましたがだいたいそんな感じでした、多くは見積もりの50%~200%以内に収まりますが)
    私の周りの人もほぼそういった意見でありますので、
    単純に作業時間を積んで言って見積もった時間の2~3倍というのは、統計的に正しいように思えます。
    (根拠は寡聞にしてryですが、ソフトウェア工学でももっと実際的で統計的な研究もたくさんしてもらいたいです)。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません