• 2024年1月11日木曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/2024/01/blog-post_11.html

仕様微変更祭り

はぁ~、疲れたなぁ。(´・ω・`)

プロジェクトはもう終盤で仕事も減ってきているんだけど、詰めの段階で微調整みたいなのが多発して、結局五月雨で色々やってる。

弊社は原理原則的に言えばかなりイレギュラーな開発スタイルをやっているのよね。

前置きから始めると、システム開発には「工程」というものがあり、最初に要件定義がある。
その要件定義の通りに開発を行うのがシステム開発工学の原理原則だ。

弊社の場合はこの「工程」というものが非常に曖昧と言うか、担当者の匙加減でやっている。

まず要件定義はあるけれども、プロジェクトの途中で「あっ、この要件勘違いしてたな」という事態が発生することが予め見込まれている。

「予め見込まれている」ってのが絶妙な匙加減で、「100点は無理だけど、これは80点くらいだからGO」みたいに、担当者たるPM社長が一人で判断して次に行く。

基本設計はノリ。

  • 要件定義と結合テストのPM社長
  • 詳細設計と実装のPLウズマス

このツートップでやるから、中間である基本設計は2人の中で申し合せれば辻褄は合う。
で、実装に行っちゃう。

要件定義は2割デタラメ、基本設計は僕が半分勝手に作る。

これでも8割くらいは正常なものが出来てるのよ。

  • 要件定義は社長1人+秘書
  • 実装はベテラン1人

この体制だとどんなデタラメでも成立する。(´・ω・`)


で、何だ。
プロジェクト終盤の今になって「改めて考えると要件これだと微妙だな。変えよう」って。

これが成り立つのは、PM社長が営業でもあり、客先とネンゴロで、最初の要件と違うものを納品しても結果的に便利であればOKみたいな話が握れているから。

急に仕様変更しても何とかなるのは、僕が一人で実装しているから。小規模は最強やね。(´・ω・`)

で、この3000万くらいの案件を数人で山分けすれば、僕の取り分は3か月で500万くらい

こんなことが成り立つのは、結局は少数精鋭で中規模プロジェクトをゲッツ、根性で完遂」でゴリ押しするから。


いや、とんでもないな。(´・ω・`)


こんなデタラメが成り立つのは、弊社社長PMがNTTの管理職出身で元々は大規模プロジェクトのマネージャーだったから。
だから本当のヤバいラインを見極めて、無理無い程度で線引きしている。
僕も元々は大企業出身でトラブった経験もあるから、自分にリスクが生じない程度の距離感は自分で保つ程度の処世術はある。

「大企業には途方もない巨大が無駄がある」ということを知っていた上で、リスクの低い外周部分だけを少数精鋭で貰っていっちゃう、という。


ウンコに溜まる蠅やね。(´・ω・`)


まあ、大企業って図体が大きくて碌に動けないから。はみ出している脂肪を切り取っていくようなやり方でウマウマと食えるというか。

年収1億みたいな頂点は取れないけど、これでも普通の人の3倍程度の美味しい生活は出来る、みたいな。


我ながらカスやな~。(´・ω・`)


もうちょっとこう、システム開発工学として美学があるやり方をしたいと言うか。
まあ金貰ってるから汚いことも応じてるけど。


社長が死んだらアウツのビジネスモデルだから、今のうちに次の人生も用意しておかないとイカンね。

まずは手堅く資格の増強を……。(´・ω・`)

0 件のコメント: