前職は受注して仕事をする立場だった。
仕事の半分は断ることであり、
“やるならオイクラ万円になります~”ってノリ。
そこでできるだけお金をふんだくってこれる人が偉かった。
受注金額 - 実際にかかったお金 = 利益 なわけで。
そりゃそういうビジネスモデルなんだろうけど、
なんか夢がないなぁって思ってのも転職の理由のひとつ。
んで、その後。だいぶ変わった模様。
XXをXXにできれば、たぶんXXくらい儲かりそう。
んじゃなんとかXXできなかなぁ。
そんなんがいきなりボーンって。
今までなら持ち帰り検討して、
次回の定例ミーティングで~とか言って。
XXをやるとXXもXXもやらなきゃいけないから
XX人月かかって~、みたいな話をするのが定石だった。
今はそこに思いっきりスピードを求められる。
できない理由を並べても仕方なくて、
工夫してなんとかやりくりしてできる方法がないか考える。
すっ飛ばすところは、すっ飛ばす。
もしくは、後から土壇場でなんとかするか、
誰かに頼み込んでなんとかしてもらう。
俺が立てたWBSなんてボロボロで。
タスクは半分くらいしか洗い出せてなかった。
でも、なんとかなりそう。てか、なんとかする。
別に実装~テスト工程のスピードは前職と変わらない。
むしろ、いろいろと整備されていない分、遅いくらい。
でも、いわゆる上流とか言われてるところはもの凄く早い。
そういう流れの中にいると、目的意識が強くなってきて。
システムなんて手段であって、目的ではないから。
別にアーキテクチャが美しくなくてもいいんじゃねぇか?とか。
前の会社にいたころは、思いっきり技術志向で。
XX規模の案件のアーキテクチャ設計がしたい!
最新技術使って、かっこいい開発がしたい!
とか、心の底から思ってたんだけど。
逆に今はRailsとかSeasar2とか、
ビジネスロジックの記述に専念できてあとはヨロシクやってくれる
フレームワークたちが今までとは違う意味で素晴らしく思える。
もし、それが遅いんだったら、それを補える箱で動かしたり、
たくさん箱を並べたりすればいい。
それ以上に費用対効果があるんだったら。
もし、ORマッパーで実現できない業務仕様があるんなら、
ちょっとくらい不便でもその仕様を
とりあえずORマッパーで実現できる形にしちゃってもいい。
それで2週間かかるDAOが2日で作れるんなら。
でも、スーツ(※)にはなりたくない。
※人月計算とExcelとスーツの世界より/Struts脳の恐怖とRails
そうだ。明日はプログラムを書こう。
他にも、いろいろ変わったのかもしれません。。
こんなん焚いてます。ん~、いいにおい。
(たぶんキャラじゃない・・・)
コメント