人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

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

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

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

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

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

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


●質問者: はなげ
●カテゴリ:コンピュータ 人生相談
✍キーワード:けが エクストリームプログラミング カスタマイズ ゲーム スピード
○ 状態 :終了
└ 回答数 : 16/16件

▽最新の回答へ

1 ● practicalscheme
●50ポイント

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

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

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

  1. 顧客|上司はあなたの能力を過大評価している
  2. 顧客|上司は仕事の困難さを過小評価している
  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か月もかかるということを想像しただけで、

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

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


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

ありがとうございます。


2 ● 牛乳先生(tukihatu)
●50ポイント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◎質問者からの返答

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

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

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



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

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

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

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


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

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

仕様を満たして見せる、

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


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

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


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

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

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

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

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

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

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

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



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

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

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


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

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


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

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


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

ありがとうございます。


3 ● thewizardofoz
●50ポイント

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

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

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

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

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

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

◎質問者からの返答

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


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

考えさせられます。


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

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

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


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


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

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

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

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

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


4 ● MasaMura
●50ポイント

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

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


(1)

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

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

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

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

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


(2)

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

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

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

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

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


単体テストも大切です。

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

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


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

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

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

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

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

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

頑張ってください。

◎質問者からの返答

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

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

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

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


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

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

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


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

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

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

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

これもあります。


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

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

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

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

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


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


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


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

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

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


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

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


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

ありがとうございます。


5 ● ヤマヤタケシ
●50ポイント

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

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

しかし、実際には、

誰かに話しかけられる、

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

お腹が空いた、

トイレに行きたい、

などなど、

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

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

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

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

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


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

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


1-5件表示/16件
4.前の5件|次5件6.
関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ