プログラマーとして生きていこうと決めたのですが、いつも見積もりの3倍時間がかかってしまいます。
そのため いつもつらい思いをしています。
環境を良くしようとHHKLite2を使い、カスタマイズソフトでホームポジションから離さずにプログラミングしています。
マウスもゲーム用の高精度のものを使っています。
調べ物にもタブブラウザを使い、拡張し続けて効率化をしています。
DualCoreマシンを使いメモリもたくさん積み、障害がないように心がけがけています。
出始めのころから効率化のためにエクストリームプログラミングも取り入れていました。
単体テスト、リファクタリングも当然行いますが、余計に開発速度が落ちています。
しかし開発速度は効率化とは無縁だとすら感じています。
仕事を減らすことが優先ではないか？と。
昔から創作活動は好きですが、人より時間がかかる方でした。
最近はプログラマーに向いていないとすら言われます。
どうか私にお力添えをください。
一番参考になった方には500ポイント差し上げます。
No.10
12
2
500pt
http://www.wankuma.com/seminar/20070602tokyo8/Default.aspx
「Ｒ流・職業プログラマー向け生産性向上の工夫」を見てください。非常に現実的な解だと思います。
効率よく高速に作業するには、集中できる時間を作らなければなりません。
テクニックは二の次です。
集中力を上げる方法を以下に記します
いかにその集中できる時間に難解な作業を当てるかが重要です。
ここに集中タイムとするといいでしょう。
前日の最後に集中タイムにやることをまとめておくと、この貴重な時間帯を消費しなくてすみます。
できればこの時間だけでもいいので個室にこもるとGoodです。
人がやってきても追い払ってください。話しかけるなオーラを出すことが重要です。
ドリンクタイムにしてもいいですし、打ち合わせや相談、雑談など
人と絡む作業を入れると切り替えやすいです。
夜型だとしても、生活パターンを一定にしてください。乱すと集中タイムが短くなってしまいます。
仮眠を取りましょう。寝る場所がないならトイレでもいいです。
瞬間的に力が出てもその後肉体が破壊されます。
飲むタイミングも重要です。朝からいきなり飲むと、日中倒れます。
純粋に眠気だけ飛ばしてくれます。
ただ飲んだ後おなかがかなり緩くなります。
ピンクなお店にいくなり、すばやくすっきりさせてください。集中力の妨げになります。
スペックをしっかり把握して使ってあげてください。
気がついたら寝てたり、肩こり、腰痛などなど。
サインがでたら必ず小休止してください。
まじめな人ほど無理して使って燃え尽きてしまいます。
普通の人は少ない頭にあふれんばかりに情報をいれるので、オーバーフローします。
難解な作業はまず自分の頭に入るサイズに切り分けることが重要です。
自分もゲーム屋だったので、状況は理解できます。
「そう見積もらねばならない状況」では、「何か」を犠牲にして効率を上げるしかありません。
若いときの修行としてはいいのですが、こういう状況はいつか崩壊しますので、
体が持たない場合は転職を考えましょう。
自分を環境に合わせる力も必要ですが、自分に合う環境を探す力もまた重要です。
No.1
15742
50pt
いくつか問題がこんがらがっているようです。
まず見積りについて。いつも見積りの3倍時間がかかるなら、最初から「このくらいでできそうだ」と思った時間を3倍して伝えれば良いのです。(茶化しているわけではありません。それが誠実な見積りというものです。)
「そんなことできない、(顧客|上司)が許してくれない」というのなら、問題は別のところにあります。
(1)の場合は誤解を解くしかありません。納期に間に合わなくて困るのは先方なわけですから。無理な見積りを言わずに、「確実にやるにはこれだけどうしても必要です」と主張することです。
(2)の場合も最終的には先方にわかってもらうしかないのですが、説明だけでわかってもらうのは案外大変です。類似の事例 (ここでこの機能を実現するにはこれだけ工数がかかりました、のような) があれば理解を得やすいでしょう。そうでない場合、機能をブレークダウンして優先順位をつけ、少数の機能に絞って短期間で開発してみる、という手があります。で、ここでこれだけかかるので、全体ではこれだけかかります、と理解してもらいます。
(3)の場合、あなたが他の人と開発速度で競争する立場であれば、これは大きなハンディキャップです。問題がこのケースの場合はむしろ、開発速度で競争しない戦略をとるのはどうでしょうか。チームで作業しているのであれば、例えば他の手の速い開発者達がめんどうくさがってやりたがらないような地味な作業をこつこつと埋めてゆくとか、個人で請負をするなら同業他社にはあまり見られないユニークな技術に集中するとか。
ひとくちに「開発速度」と言っても、個人の中でさえばらつきは激しいですし(調子の良いときはどんどん書けるけれど、スランプになると全然だめ、とか)、また何を測るのかというのも曖昧です(一日何千行も新しいコードを書くのと、何年にもわたって誰も解決できなかった難解なバグを3日考えて直すのと、どちらが「速い」のか、とか)。
また、ひとくちに「プログラミング」と言ってもその内容は千差万別です。Joel Spolskyが 「5つの世界」
http://japanese.joelonsoftware.com/Articles/FiveWorlds.html で書いていますが、それぞれの分野でプログラムという作業に求められることはかなり違っていて、ある分野で優れた人を別の分野に引っ張ってきて同じくらい高い生産性が得られるとは限りません。
抽象的なまとめになりますが、まずは現在の自分に適したペースをよく知り、次に求められることのなかから自分にできる方向を見つけてそちらを強化してゆく、ということしかないのではないかと思います。
質問に多くの情報をつめなかったため、
お手数をおかけします。
> 「このくらいでできそうだ」と思った時間を3倍して伝えれば
本来そうしなければいけないのですが、なかなかできないという現状があります。
「できない」問題に関しては、
部分的に(1)であり（と私が思っている）、大きな客観的事実として(3)があります。
(1)に関してはおっしゃる通りだと思います。
これからは、言わなくてはなりませんね。
問題は(3)なのですが、
人材が少ないため自分の担当の部分は自分以外に代替ができない状態です。
そういう意味あいでは有利？なのですが、
「これは 一週間で終わらせねば困る」という仕様や仕事を「一か月かかる」とは言えない状況です。
3倍の見積もりではプロジェクト自体が計画ができません。
（1か月のところなら 3倍の3か月で、となるとさらに無理です）
しかしながら、結局のところ私のせいで「計画がずれる」ということになれば、
再度、計画しなおさなければならず困るのはお互いですので、
そこは(1)のように「無理な見積もりを言わ」ないようにしなければならないと思います。
教えていただいた「Joel on Software」の5つの中では、
自分の担当は主に「ゲーム」であり、
部分的に「インターナル」(ゲーム用の内部向けツール)であります。
(現在は、PC向けのカジュアルゲームを開発しております)
その中でどんな速度がもとめられているかについては、
まずは最低限、仕様を満たす（動くもの）を求められています。
仕事以外で、その他の開発もしますがそれは「趣味」ですので、
多少遅れたり、途中で中断してもあまり悩むことはありません。
ただ、私自身、1か月相当のものを3か月もかかるということを想像しただけで、
仕事をこなす意欲というものがなくなり果て、
困っている面もあります。
具体的なアドバイス、大変参考になります。
ありがとうございます。
No.2
18032
50pt
参考になるかはわかりませんが…
見積もりに関しては、見積もり自体が駄目なんだろうと思うので気にする必要はないです。どう見てもSEや営業の責任ですよ。
開発のスピードを上げるには、なんといっても経験値が必要です。
たとえば一つの開発があったとして、そこに到達するためのステップが、経験がある人は1,2でいけるが経験が薄い人は10程度かかってしまう、ということでしょう。
とにかく経験をつむことです。いきなり速いスピードで作れる人なんていないです。最初は自信がないのも当然です。
遅いとか言われたら悔しいでしょうが、それを糧に先輩のコード盗んだり本読んだりして見ましょう。
先輩のコードは非常にためになります。というかそれ流用しただけでも工数がかなり速くなります（自分の力じゃないですけどね…）
もしプログラムがオブジェクト指向の言語だとなおさらですね。
一年ぐらいがんばっていると、以前と比べ物にならないぐらい速くなっていることに気づくと思います。
効率化するのも、もちろんスピードアップにはつながります。
基本的にプログラマに向いてない、というのはないと思います。深く考え過ぎなくても大丈夫です。
あったら便利なスキルは数学と飽きないことぐらいです。
あとプログラマは人に教えるのが苦手な人が多いみたいです。教わるときは要点をまとめてつつくといいです。
http://www.atmarkit.co.jp/farc/rensai2/thinking01/thinking01.htm...
すいません、環境を書くことができなく、誤解を与えてしまいました。
見積もりは私も入れて決めていますので、
私の責任でもあるのです。
経験に関しては、私自身プログラミング歴は 10年 以上あり、
プログラミング自体も好きで、一年にひとつ新たな言語を学んだり、
常に新しい情報を仕入れているのですが、
正直、「趣味」での期間が長すぎたと痛感しております。
趣味であっても効率化は常に意識していますが、
スピードや早く仕上げる、
仕様を満たして見せる、
というようなことを意識したことはありませんでした。
おっしゃられる経験値に関しては、
たぶん「仕事」にしなければ、詰めない経験値なのだと思います。
趣味でも、とにかくベータ版のソフトを公開して的な開発はやってはいたのですが、
それともまた別な感じがします。
また、趣味の場合、研究の時間
（新しいライブラリを作ったりといった）
が長くとれるのですが、仕事だとその時間が取れず、
かなり行き当たりばったり的になってしまうところもあります。
かといって、再利用性を考慮しながら組むと、
速度がおろそかになります。
今までの自分の中にある概念を壊し、
仕事としてのプログラミングを再度学ぶ必要があるかもしれません。
また、仕事としての修行がいるのでしょう。
つらいですが、id:tukihatu さんのアドバイスから
今や、これからを乗り越えることが必要なのかと感じました。
残念ながらプログラマーの先輩はいないのですが、
幸いにして後輩が優秀ですので、彼らからも学ぶことにしたいと思います。
趣味と仕事との違いを再認識させられます。
ありがとうございます。
No.3
323
50pt
元々時間が他の人よりもかかるのであればスピードを上げようと思ってもなかなか上がらないものです。
ここは発想を変えて、スピードそのものを上げるのではなく効率を上げることを考えましょう。
効率と言っても難しいので「できるだけ楽ができる方法をみつける」という風に考えてみるといいです。
「楽な方法」＝「ちんたらやっても間に合う方法」ですのでスピードを上げるよりも効果があります。
道具に凝ってもスピードが少し上がれば御の字ですが、何か「楽ができる方法」をひとつ見つけるだけで劇的に見かけのスピードは上がります。例えば何度も繰り返すような事は一度で済むようにするとか再利用できるものは再利用するとか他の人に任せられるものは任せてしまうとか今までのやり方に対して疑問を持ち、それを別の方法でやれないかいつも考えるのです。
http://www.google.co.jp/search?q=%E6%A5%BD%E3%82%92%E3%81%99%E3%...
id:thewizardofoz さんありがとうございます。
「効率的」でもなく「楽な方法」、
考えさせられます。
> 何度も繰り返すような事は一度で済むようにするとか
これは、DRY的な要素をコーディングレベル以前の段階で
適用する、ということですね。
> 他の人に任せられるものは任せてしまうと
たぶん、これがキーポイントかな？と感じました。
特にゲーム系でリソースの制作は分離しやすいですので、
できるだけ、自分の分担する部分を減らすことができないか？を
（つまり、プログラム依存部分をいかに減らすか？）
考えて取り組まないといけないのかと思います。
No.4
80
50pt
１．複数新しい試みをしてませんか？
２．ソフトに対して洗練し過ぎていませんか？
（１）
新しいアクションを起こすにはコストが掛かります。
HHKになれるまで、暫くのあいだタイピングの速度は２倍落ちます。（私は挫折しました）
カスタマイズソフトを手に馴染ませるタメには動作を覚え、カスタムして、Helpを読むのに一日潰れます。
私も常に効率化を考えていますが、複数の事を一気にしようとすると大幅に効率が落ちるのでしません。
文章を読む限りでは複数の事を一気に進めようとしてませんか？
（２）
リファクタリングをするのは大切です。
が、アルゴリズムに究極はありません。そして、常に洗練されたアルゴリズムを書くのはナンセンスです。
私はやっつけコードとキレイなコードを見分けるのも大切な事だと思います。
いぜん美しいコードについてBlogを書きました。よろしければ見てみて下さい。
http://d.hatena.ne.jp/MasaMura/20080208
単体テストも大切です。
しかし、テスト技法を学び全て通しテストをするのは現実的に時間がありません。
ある程度までテストすれば後はテスターさんにお任せしてはいかがでしょうか？
thewizardofozさんは、ソフトウェア工学に縛られてませんか？
全てを実践するのは１０年以上は軽く掛かると思います。
一つ一つ解決するのが良いと思います。
恐らく私よりも遥かに腕は上と思われます。
なのでどこかで何かをつかむ事が出来るでしょう。
マジメな人が爆発する時は一気に花が咲くと思います。
頑張ってください。
> １．複数新しい試みをしてませんか？
orz 図星です。これはあります。
つい、複数のことを同時進行してしまい、どれもうまくいかないことがあります。
どうもこれは私の性格上のようです。
ご心配をおかけしましたHHKとカスタマイズについては、今は大丈夫です。
HHKは自分の求めていた理想のものでしたし、
キーカスタマイズは数年前に行ったもので今は慣れてしまっています。
ただ、やはり、今でも新しいことをやろうとすると、かなり時間がつぶれるということはあります。
誰でもそういうものだろうとは思いますが、
なるべく、新しいことは常に1つという状態にしたいものです。
> ２．ソフトに対して洗練し過ぎていませんか？
これもあります。
リファクタリングによってよりよいコードを書くことに
目覚めましたが、かなりこだわりすぎな感があります。
昔はもっと、臨機応変に適当なコードを書いていました。
スピードもあったように思えます。
（昔はテストは全く書いてませんでしたので、まずかったですが……）
最近は、Rubyを書いていてもつい自然とgolfをしてしまいます。
病的にまでに、綺麗に書かねばならないと思っている節があるかもしれません。
BLOGのエントリーは興味深く読ませていただきました。
私は、トラックバック先の方と同じような意見を持っていました。
今の現状を考えて、反省せざるを得ない面もあるかと思います。
コードを綺麗に書くにもテストをするにも「適度」が肝心なのでしょう。
その辺の見極めが今後、必要になってくると思います。
id:MasaMura さんにはいくつかの気づきをいただきました。
ありがとうございます。
No.5
40
50pt
自分も、実際の時間は見積もりの３倍以上かかります。
これは、見積もるときには「集中して作業したとしてこれぐらいかかる」と考えるからです。
しかし、実際には、
誰かに話しかけられる、
ＲＳＳに興味深いニュースが出た、
お腹が空いた、
トイレに行きたい、
などなど、
さまざまなイベントにより集中状態が切れます。
ソフトウエアを作っているのは動物であり人間である自分自身である。
ということを受け入れることで納得しています。
トムデマルコ氏の「ピープルウエア」が参考になるのではないかと思いました。
http://www.amazon.co.jp/dp/4822281108?tag=toymanspage-22&camp=24...
id:toymany さま、
異なった視点でのアドバイス、ありがとうございます。
MAX作業時間で見積もってしまうことは多いように思えます。
これは何時間、これは何時間、だから計何時間かかる、
1日 x時間作業できるから、何日間かかるといったようにです。
人間である以上、集中できる時間は限られている、
ということを自覚して計画を立てる必要がありますね。
前にも同様のブログのエントリーを見た覚えがあります。
今探して残念ながら、見つかりませんでしたが、
以下の方法は参考になるかもしれません。
集中力を高め、仕事に余裕を生む「70%予定管理法」 - ELECTRIC DOC.
http://e-doc.no-ip.com/archives/499
参考図書ありがとうございます。
「ピープルウェア」は読んでみたいと思います。
No.6
261
50pt
見積もりに対して作業時間が３倍かかった．その原因を突き詰めていないからではないでしょうか？
作業項目を細かく洗い出して，それぞれに時間を記録していき，繰り返し見積もりをアップデートしていけば，自ずと精度があがると思います．
http://www.itmedia.co.jp/bizid/articles/0606/27/news003.html
> 見積もりに対して作業時間が３倍かかった．その原因を突き詰めていないからではないでしょうか？
遅れる大概の大きな理由としましては、
「予想外のトラブルが起きたり、仕様が増える」という点
（つまり、動的にタスクが次々に増える）と
「予想よりも、単純に実装に時間がかかる」
（id:toymany氏の言われているような外的要因や、集中力の持続時間、そもそもコーディングの時間が取れないなど）
という2つの点がほとんどなのですが、
個々のタスクの計測や原因の突き詰めまでは
行っておりませんでした。
全体のタスク自体は、アップデートしながら行っているのですが、
個々の記録は、どの程度かかったか、などを付ける必要があると思います。
URLのGTDは最近、取り入れようとしているところでした。
ただ、GTDのやり方そのものには、少し疑問があり、
4HWW本の Tim Ferris が言っていたように、
タスクを細切れにするよりも、不必要なタスクをそもそも消すことが大切なのではないか？と考えてきています。
(仕様上どうしても必要ではないところは、実装をしないことにする、といったような)
No.7
260
50pt
URLはなんとなく。こういった考え方が大事かなというくらいです。
資産は作っていますか？
この場合の資産は、クラスライブラリやEditorのマクロなど効率を上げるためのソフトです。
似たようなことを繰り返して開発していては効率は上がりません。
自分が同じようなものを開発しているのなら、それを共通化し後で使えるようにブラッシュアップすれば時間が節約されるでしょう。
エディタのマクロも同じです。定型的な作業であれば、マクロにすることで同じ作業をする時間が減ります。
自分の仕事のやり方を見直してみる必要があると思います。
id:atsushifx さまありがとうございます。
私は、常に資産を作るように、
なるべく、個別の機能はライブラリ化していますが、
（でないとテストもしにくいからなのですが）
資産を使いまわせるようにすると、かえって開発の時間がかかってしまいます。
ただ、コピペコピペでやろうとした時期もありましたが、
その時は、何故同じ処理を書かねばならないのだろうと、
かなりノイローゼに陥りました。
現場では、資産を作ることはどうしても速度が落ちることにつながります。
その辺のトレードオフの見極めが必要だろうと思います。
エディタの支援機能、スニペット、コード補完などは、
現時点でもフルに活用しています。
実は、メインの言語は Delphi なのですが、
一般のライブラリのポーティングなどがあまり行われないため、
いざ使おうとすると、自分でポーティングしなければならず、
下手をすると、時間だけがかかり、失敗に終わったり、
結局、ライブラリすら使えないという状況に陥ったりします。
(以前は、いい加減、組み込み用のスクリプトの自作はやめようと、
Squirrelを組み込もうとしたのですが、一か月かかって失敗に終わりました)
Delphi は素早くツールを作る分にはよいのですが、
そろそろ限界に近いのかもしれません。
(とはいえ、C++のコンパイル速度は、集中力を途切れさせるには十二分なので、
乗り換え先がなく困っています)
新しいプロジェクトが ActionScript になる可能性があるのですが、
また別の言語環境なので、資産が一からやり直しになり、
今以上に、遅くなるのを非常に恐れています。
私は、言語が違うだけで車輪の再発明をしなくてはならない状況に、
かなり嫌気がさしています。
No.8
26621
50pt
たぶん、あまりにも目標レベルが高いだけの様な気がします。
力は十分にありそうだし。
ただ一つあまりにも美しいプログラム作りに固執しすぎなのかなと感じました。
制作速度を高めるためにちっとやぼったい処理で一時しのぎもいいのかなと感じたりします。
確かに動作速度は落ちる事があるかもしれませんが。
三倍時間がかかると言うことは、納期が三倍遅れてる事になのでこれは結構顧客を怒らせるかもしれません。
美しいプログラムより、バク取りしてとにかく動くプログラムの早期納期に集点を取られたらどうでしようか？
どうもありがとうございます。
id:yo-net さんのおっしゃられるように
それは私のプログラムには多いにありうることです。
趣味プログラミングでは、こだわりとなっていたものが、
仕事のプログラミングでは、足かせとなっている感があります。
まざまざと違いを感じさせられます。
やはり、「とにかく動くプログラム」に注する必要があるのでしょう。
No.9
10
50pt
コードを書くことに着目しすぎていませんか？
あなたがとっているモノは、すべてHOW TOとか物理的なスピードを上げるものばかりです。
コードを書く前に、「何を」作るのか、「何のために」作るのかを考えてから、
コーディングした方が良いでしょう。
プログラミングに必要なものは、論理的に考える力です。
http://www.amazon.co.jp/%E8%80%83%E3%81%88%E3%82%8B%E6%8A%80%E8%...
id:fujibar さまありがとうございます。
質問文だけでは読み取れないので、申し訳なかったのですが、
私は、他の人から見ても常に論理的に考える方ですので、その辺に関しては心配はないかと思います。
（その上で、HOW TOなどのテクニックなどを取り入れている、といったところです）
ただ、今までの自分を見るに、その論理的に考える方法が、（効率ではなく）スピードを上げるのに結びつくのか？という点については疑問に思ってしまうのです。
たぶん、私の論理的解法に足りないものがあるのでしょう。
書籍の紹介ありがとうございました。
足りないものを補間できるのでは？という期待とともに、ぜひ、読んでみたいと思います！
No.10
122
ここでベストアンサー
500pt
http://www.wankuma.com/seminar/20070602tokyo8/Default.aspx
「Ｒ流・職業プログラマー向け生産性向上の工夫」を見てください。非常に現実的な解だと思います。
効率よく高速に作業するには、集中できる時間を作らなければなりません。
テクニックは二の次です。
集中力を上げる方法を以下に記します
いかにその集中できる時間に難解な作業を当てるかが重要です。
ここに集中タイムとするといいでしょう。
前日の最後に集中タイムにやることをまとめておくと、この貴重な時間帯を消費しなくてすみます。
できればこの時間だけでもいいので個室にこもるとGoodです。
人がやってきても追い払ってください。話しかけるなオーラを出すことが重要です。
ドリンクタイムにしてもいいですし、打ち合わせや相談、雑談など
人と絡む作業を入れると切り替えやすいです。
夜型だとしても、生活パターンを一定にしてください。乱すと集中タイムが短くなってしまいます。
仮眠を取りましょう。寝る場所がないならトイレでもいいです。
瞬間的に力が出てもその後肉体が破壊されます。
飲むタイミングも重要です。朝からいきなり飲むと、日中倒れます。
純粋に眠気だけ飛ばしてくれます。
ただ飲んだ後おなかがかなり緩くなります。
ピンクなお店にいくなり、すばやくすっきりさせてください。集中力の妨げになります。
スペックをしっかり把握して使ってあげてください。
気がついたら寝てたり、肩こり、腰痛などなど。
サインがでたら必ず小休止してください。
まじめな人ほど無理して使って燃え尽きてしまいます。
普通の人は少ない頭にあふれんばかりに情報をいれるので、オーバーフローします。
難解な作業はまず自分の頭に入るサイズに切り分けることが重要です。
自分もゲーム屋だったので、状況は理解できます。
「そう見積もらねばならない状況」では、「何か」を犠牲にして効率を上げるしかありません。
若いときの修行としてはいいのですが、こういう状況はいつか崩壊しますので、
体が持たない場合は転職を考えましょう。
自分を環境に合わせる力も必要ですが、自分に合う環境を探す力もまた重要です。
id:shikakuさん、
具体的なアドバイスありがとうございます。
これは、テクニック的なものより、
集中する方が結果的に速度が上がるのではないかという問題定義であります。
id:toymanyさんの言われていることに近いと感じました。
多くのアドバイスは、
とにかく、
に集約しているように思えます。
それだけ大切である、ということがうかがい知れます。
いわゆる驚異的な効率、スピードが出せる「神が降りた」という状態は誰にでもあると思いますが、
そのようなものを人工的に、作ることができるとよいですね。
職場に関しては、今のところが一番合っている……というより、
社会不適応者なので(笑)普通の会社だと無理という感じです。
(うつがひどくて突然2週間くらい休んでも、
あたたかく迎えてくれるところは中々ないと思う)
No.11
641
50pt
自分もゲーム業界の端っこで仕事してますが、見積もりの3倍かかるって、割と普通ですよ。
と言うか、見積もりを「何も問題が起きず、雑用も発生せず、全期間で集中して仕事をこなした最速の時間」で考えて、そのまま相手に伝えるから失敗するのです。
それかデバッグ・調整期間を考慮に入れてないとか、企画側の「なんか遊んだ感じがイメージと違うなぁ。こうしない？」攻撃が頻発する職場だったりとか。
特にゲームは予想外の事態が発生しやすい業界ですので、3倍でもギリギリという事も。
まずは普段から3倍の見積もりを出すようにし、仕事の完了後には「実際にかかった時間との差」を意識するようにすれば、本当の見積もりを出せるようになると思います。
ようは慣れです。
どうもありがとうございます。
私はどうも、予想外のことを考えていなかった気がします。
細かく、実際の作業を作業内容をあらいだせない点も問題としてありました。
（上でも出ていたように、たぶんプロとしての経験値が足りないためかと）
「これは、たぶんこの2つやることがあるからこのくらいだな？」という感じで、
アバウトに見積もってしまいがちでした。
id:YOSIZOさんの言われるように、予想外のことも見積もりに入れるようにして、
自分の実際にかかる、想定される見積もりを出していければ、と思います。
No.12
10
50pt
自分の場合常にここで障害が発生したらどうなるのか、
障害が発生した場合に原因の特定がしやすい状態になっているかを
常に頭に入れながら開発してますね。
そうやって製造しているとただ動けば良いと考えて製造している人とは単体テストを
開始する前の段階でプログラムの完成度がかなり違ってきます。
嗅覚が鋭くなるとでも言うのかな。
プログラムの製造はそこそこ早いのにいざ結合テストをしてみると
バグだらけだし、バグを修正してまた新たなバグを発生させたりする人が
私の周りでは結構いたりします。
１０年やっててプログラミングのスピードを上げるのは難しいでしょうから
単体テスト前の段階でのバグを少なくする努力をした方が良いのでは。
過去の資産を有効活用するというのもありですよね。
プログラムのソースだったり単体テストの手順だったりデータだったり。
個人的にはプログラムの製造が遅い人よりバグばかり発生させる人の方が
プログラマーに向いていないと思います。
ダミー
id:gatas さん、ありがとうございます。
せっかく、お答えしていただいたのですが、
私としては、具体的な手法なりなんなりでなければ、
わかりかねない部分があります。
バグを少なくするために、「単体テスト」なり「結合テスト」なりを導入するものかと思いますが、
「単体テスト前の段階でのバグを少なくする努力」？
というのがちょっとわからない感じです。
(Assertを無意識レベルで挿入するようにするとかの契約プログラミング的な手法を導入するとか？かなと予想)
過去の資産は同意です。
あれば、あるほど早くなると思います。
> 個人的にはプログラムの製造が遅い人よりバグばかり発生させる人の方が
> プログラマーに向いていないと思います。
むむむ。
そういうものなのですかね……。
No.13
130
50pt
製作の一部分の速度を上げれば、トータルの製作時間も短くなるというように考えているならそれは間違いです。やらなければならないのはトータルの製作時間を短くする事です。
一見時間がかかるような事でもトータルの製作時間に寄与する事であればやるべきですし、キーボードやらショートカットやら一見時間を短縮しているようでも、それが逆にトータルの製作時間を延ばしてしまっていることもありえます。
全体最適化について下記がお勧めです。
http://www.amazon.co.jp/%E3%82%B6%E3%83%BB%E3%82%B4%E3%83%BC%E3%...
「トータルの時間」ですか……。
言葉の意味以上の実感、違いがいまいちわからないところがあります。
id:kekekun さんの紹介された書籍を参考にさせていただこうかと思います。
ゴールは興味がありつつも、読んだことがありませんでした。
視点を引いた、全体的な工程管理レベルの最適化だと思うのですが、
面白そうなので読んでみたいと思います。
ありがとうございました。
No.14
312
50pt
開発環境を整えても開発効率が上がるというわけではありませんが、処理待ちなどでのストレスなどが軽減されるのでそれは良しとしましょう。
まず第1にどの部分で一番時間がかかっているのか？手間取るのか？といった事を洗い出す必要があると思います。
仕様の作成や開発やチェックやバグ取りなど色々とあると思います。
いつも同じ所で時間がかかっているのなら何故そこで時間がかかるのか考えるべきです。
また時間がかかったとしてもそれが適切な時間ならば問題はないかと思いますがそこは予算や会社のつきあいなど色々とあると思います。
あと個人的な感想ですがプログラムに向き不向きがあると思いますが、言語で見た場合もあると思っています。
同じものを作るにしてもCだとさくさく出来るけど他の言語だと時間がかかるとか・・・。
ですが最初から上がってくる仕様書や期間に無理があるなら仕方ない場合もありますかね・・・。
id:quocard さん、ありがとうございます。
「どの部分で一番時間がかかっているのか？」
いわゆる『パレードの法則』を思い出しました。
「2割の時間がかかっている部分を解消すると、8割の時間短縮が可能である」
といったような……。
もしくは、
「2割の時間がかかっている部分を解消すると、8割の効率改善が可能である」
的な。
実行効率ではなく、開発効率のボトルネック的な部分はあるのかもしれません。
今まで、意識したことがなかったのですが、
意識する必要があるようですね。
言語に関しては適材適所がある、ということに帰結するように思えます。
今使っている言語が、向いていないということになるのかなぁ、と。
(今の場合だと、ゲームにおいてDelphiよりももっと効率のよいものがあるという話)
No.15
60
50pt
http://www.aoky.net/articles/jeff_atwood/how_long_would_it_take_...
リンク先で紹介されている、「ソフトウェア見積り―人月の暗黙知を解き明かす」という本を読むのはどうでしょうか。この質問は、ちょっとした返信で解決できる範疇を超えているように思えますので、私はまとまった書籍を読んでみることをおすすめします。
ただ、質問の回答になりませんが、誰でも見積もりより大きくなるものみたいですよ。うろ覚えですが、Rubyの設計者であるMatz氏でさえ、日記で「とりあえず見通しの2倍でスケジュールを伝える。実際そのぐらいになる」と書いていたことがあります。（リンクしたかったのですが、見つけられなくて挫折しました。いい加減な話ですみません）
id:lichtenさんが紹介いただいた「ソフトウェア見積り」は内容的に気になるところです。
まとまった書籍というこおで、この質問の回答で出された参考図書は一通り読んでみたいと思います。
> Matz氏でさえ、日記で「とりあえず見通しの2倍でスケジュールを伝える。実際そのぐらいになる」と書いていたことがあります。
私もMatz氏の日記を検索してみたのですが、見つかりませんでした。
本当に あのMatz氏が言われていたら非常に興味深いところです。
回答ありがとうございました。
No.16
40
100pt
すいません、ポイントはあえて狙いません。ごく気休めな回答を。
昔、新卒でソフト会社に就職して、社員研修の最初の講義で
「我々が言うシステムって何でしょう？」という話が始まって、講師の答えが、
「ある仕事をするための連続した手続きが、有限個にまとまったもの。」
という簡単なものでした。彼は何か業績のあるエンジニアでもなく、普通の中年SEさんでした。
この定義が合っている合っていないかは別として、
ともかく彼が一番強調したのは、「有限個」という言葉でした。
有限個でない手続きが連続したものはシステムでも問題解決でもない、
我々が作るものは必ず有限なものでなければならない、という話でした。
私はこの言葉を聴いてから10年経った今も、このことをずっと心に留めています。
自分に直面した問題を、できうる限り、有限な形にする。どこかに終わりを作ってやる。
たとえつまらない形でも、荒削りなものでもいい。無限をはらんだものよりはずっといい。
無限とはつまり、「矛盾」です。互いに相反する事象が同時に起きようとすることです。
簡単な例なら、現実にできる仕事量より多くの見積りが出た場合。
現実の要求より概念の美しさを選んだり、周囲の要求より自分の要求を押し通した時。
プログラミングが好きなのに、解決案もなく他人から問題を指摘され、向いていないと言われてしまう時（これは失礼な話。）。
そういった時に矛盾（＝無限）はよく発生し、自分も周囲も機械も不幸になります。
他人や自分の中に無限というものを見出した時は、これは疫病だと思って避けてください。
（むやみにツールをあさっているような時は、少し無限が発生している兆候がありますよ・・。）
ここからは蛇足です。
見積りを問題にされていますが、見積りは所詮、誰かの概算と希望のモデルで、答えではありません。
かならずそこには問題があります。その問題（矛盾）を先に殺してはいかがでしょうか。
ただ単にモノを作ることよりその方が大事です。
あと、名詞で物事を考えるより、動詞で物事を考えましょう。
勉強熱心なのはいいですが、名詞（技術用語）はいつの時代も早く無限に増加しますが、
動詞の増加はさほど急激ではなく、有限個しか覚えてなくても十分生きてゆけます（笑）。
id:cergey さんありがとうございます。
今まさに異なったベクトルの意見をいただき、
とまどいながらも衝撃を受けております。
>「有限個」
仕事の上での直接的な意味では、
仕事を「曖昧」に定義するのではなく、
具現化した具体的な、細分化した仕事にするということが大事だととらえました。
無限であることは、進行管理的にも精神的にも悪いことは、
過去の(趣味での)プロジェクトで経験し実感しているところです。
終わりがないという意味合いでです。
実は、この質問中に GTD の本も読んでいたのですが、
私はかなり日々のタスクを「曖昧」にしていたことに気付かされました。
無限を「矛盾」ととらえた意味に関しましては、
私の場合、矛盾はなかなか回避できないもののようです。
私がよく陥る、「手段が目的になる」といった類も「無限」なのかもしれません。
特に私のこだわりのようなものが、人生の邪魔をしている（つまり無限に、つまり自分を不幸に）ように思えます。
甲野善紀氏のよく言われる「矛盾を矛盾のまま矛盾なく取り扱う」こともヒントになるのかもしれません。
参考URL:「身体を通して時代を読む」ノート
http://www.bekkoame.ne.jp/~topos/siso/sintai/sintai.htm#note2
「無限」「有限個」という言い回しは、独特で聞き慣れなかったのですが、
異なる発想で参考になりました
「名詞ではなく動詞で考える」これは私もよく聞きます。
（私はの場合は何かの自己啓発本かビジネス書だったと思いますが）
言われても理解できない、自分が実感しないと理解できないということがありますが、今こそそのときなのかも？
でも、この質問の問題に適用できるのかが、ちょっとわからないかったりします……。
hogege
2008/02/22 18:05:29
3
1
2
5
2
11
11
dev_zer0
practicalscheme
KUROX
popattack
牛乳先生(tukihatu)
YOSIZO
はなげ
lichten
cergey
deadly_poison
kumeuchi
garyo
raitu
rurueru
id:shikakuさん、
具体的なアドバイスありがとうございます。
これは、テクニック的なものより、
集中する方が結果的に速度が上がるのではないかという問題定義であります。
id:toymanyさんの言われていることに近いと感じました。
多くのアドバイスは、
とにかく、
に集約しているように思えます。
それだけ大切である、ということがうかがい知れます。
いわゆる驚異的な効率、スピードが出せる「神が降りた」という状態は誰にでもあると思いますが、
そのようなものを人工的に、作ることができるとよいですね。
職場に関しては、今のところが一番合っている……というより、
社会不適応者なので(笑)普通の会社だと無理という感じです。
(うつがひどくて突然2週間くらい休んでも、
あたたかく迎えてくれるところは中々ないと思う)