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

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

お手数をおかけします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ありがとうございます。

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

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

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

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

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

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

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

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

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

仕様を満たして見せる、

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

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

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

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

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

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

（新しいライブラリを作ったりといった）

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

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

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

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

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

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

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

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

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

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

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

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

ありがとうございます。

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

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

考えさせられます。

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

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

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

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

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

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

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

（つまり、プログラム依存部分をいかに減らすか？）

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

> １．複数新しい試みをしてませんか？

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

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

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

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

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

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

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

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

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

> ２．ソフトに対して洗練し過ぎていませんか？

これもあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

ありがとうございます。

id:toymany さま、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

過去の資産は同意です。

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

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

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

むむむ。

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

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

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

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

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

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

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

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

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

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

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

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

といったような……。

もしくは、

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

的な。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>「有限個」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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