| < 2012/06 | 新 | 2012/08 > | ||||
| 2012/07 | ||||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 01 | 02 | 03 | 04 | 05 | 06 | 07 |
| 08 | 09 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
ビジネスとしてプログラマーをやるのって、めんどくさい。
「ビジネスプログラマー」というのは僕の造語である。おそらくはシステムエンジニアに概念は近い。説明すると、「見積もりが出来るプログラマー」のことだ。手渡された情報からどのぐらいの期間でプログラム製造を完了できるのか正確に判定できる人材のことを言う。
なぜわざわざこんな一週間もすれば忘れ去りそうな新しい単語を作ったのかというと僕自身はプログラマーなのにこの見積もりが相当苦手である、ということに端を発する。つまりは手渡された情報に何時完成できるのか分からない、ということである。個人で作っている分には何の問題もないのだが、ことビジネス的な場面では「何時終わるのか」という見積もりを立てることは実に重要である。この見積もりを元に全体のスケジュールを決めていのだから当然で、これは納期内にシステムを完成できるのかどうか、というところに直接関わっている。見積もりが甘いと暇な時間が出来てしまうし、見積もりが辛いと時間が足りない。時間を取り過ぎることは一年間に作れるシステムの数が少なくなることを意味し、お金を稼ぐことが出来ない。逆に時間がなさすぎることは労働者に残業をしえることに繋がり、赤字が出てしまう。収入が減るか出費が増えるかしてしまうわけだ。ビジネスの場ではどっちも避けたいことである。
見積もりをしてスケジュールを作るのはシステムエンジニアの仕事だ。しかし、細かい場面では見積もりについてプログラマーの意見が尊重される場合が多い。作るのはプログラマーだからだ。ゆえに、僕は見積もりをよく聞かれるわけだが、この見積もりが適正に出せたことは今のところ、ない。大抵が見積もりが辛過ぎて間に合わない。
間に合わなければ残業することになるが……残業をするとその分は支払ってくれるものの、真面目に予算が危ないことになりそうなので出来る限り残業したくない。僕自身も早く帰れるとサイトの製造が出来る上に早く寝ることが出来て嬉しい。うまく行かないものである。
基本的にシステムエンジニアになる気がない僕はしかしながらビジネスプログラマーになれる状態でもなく、ただのプログラマーとしてやっていきたいところである。
何時終わるか分からない作業を延々していく。何時終わるか分からないから作業時間は膨大で。そのほうが気が楽だ。
