Twitterが出てからブログは廃れたよな
仕事がひと段落つきそうなので、ちょっと振り返ってみる。
今回の案件では俺はPGとして実装だけしてたけど
手戻りが多いのと、要求がチョコチョコ変わって結果的にコストが増えてしまったのは
一年目の俺から見ても明らかだった。
問題点は
・要求が度々変わる
・お客さんの返答が遅い
・実装の負担を分散できていない
ことだった。
でも要求が変わってしまうのは、仕方がないことだと思う。
お客さんからすれば自分の思っていたものと違う！ってだけだろうし
むしろ問題があったのはこっちの設計部分だな。
手戻り発生の大半は、「アレ？この部分、○○の時どうするか決めてなくね？」
って感じだった。そしてそれをお客さんに聞いて返答待ち。そして、その返答は３日後とか。
返答が遅いのは、こっちのやりかたが悪かったと思う。
「来るまで取り敢えずの実装しとこう」とか、すごく無駄だった。
むしろ電話かけまくるくらいで、「お前らの願い叶えるためやってんだぞ」
くらいのスタンスでいけばよかったとおもう。
そして実装の9割はオレ。
というか、実装内容はオレしか知らない。
異常事態だと思うわ。保守どうすんの？ｗｗｗ
一応、現在稼働してるシステムだから、既存の流れを汲んだ実装にしたけど
まぁ酷い。保守性なんて皆無のコードだったよ。
Javaでインターフェースを一切使わず、その場凌ぎのコードしか書いてなかったからな。
あまりにも酷い部分と、今後拡張されるであろう部分はチマチマ直しておいたけどｗｗｗ
最後に振り返って考えると、一番の問題点はやっぱり設計だったかな。
「今こういうふうなシステムに○○って機能つけたいんだけど」っていう要求に対して
現状どういう風に使われているのかってところの調査が欠けていた。
「調査工数が少ないから・・・」とか言い訳してたけど、むしろそこをケチった所為で
クソみたいな手戻りが発生してたんだよな。
実装しちゃってから「あ、既存でこんな機能があるけど影響出てねーよな？ｗｗｗ」
みたいなの。バカかと。今回はまだ小規模なシステムだったから大事にはいたらなかったけど
調査工数をちょっと削っただけで、これだけハイリスクな実装になってんだから。何も言えねーよ。反省しろ。
今回の案件で、上流工程の大切さとそれが及ぼす下流工程への影響を学んだ。
とても勉強にはなったな。「ああ、こういう風に回しちゃいけないんだ」ってね。
自分がPLやる時は先の先まで見据えて行動できるようにしていきたいと思いました。
その為には経験が必要だろうし、そういう意味では意義のある仕事だったかもなｗｗｗ
二度とやりたくねーけどな。
とまぁ、色々問題点があったけど、その反省とかせずに次の案件行くから
俺の今の部署は成長しないんだろうな。前の案件と同じやり方しかしない。
こうやって自分の保身を考えることだけに特化した量産型クソBOTが出来上がるんだろうね。
割りと老舗の会社だから、こういう古い考えのBOTが大半で
実際に会社を回してるのは、必死に色んな案件掛け持ちしてる人なんだろう。
良いように利用されてる感は否めない。
そうはならないようにうまく立ち回りたいと思う。