圧倒的生産性

ちょっとプロジェクトがマジに大忙しで心がブログ書く状況ではないのだが。(; ･`д･´)

11/24(火)から新プロジェクトがスタートしたけど、要件に対して納期がとんでもないな。
12月で開発完了、1月がテストフェーズだぁ？
期間が３倍足らんわ！！

まあ、そういう無理を通すのがエンジニアの腕の見せ所なんだけどね。(´・ω・`)

ともかく、やるだけのことは頑張ろうと今週は突貫工事で頑張っている。頑張っても無理な可能性もあるんだけど、姿勢を見せておく事も重要だからね。
世の中は合理性ばかりではなく、そういう他者へのアピールも計算する必要があるってのが大人の世界ってもんや。

しかし気になるのが、設計書を書いてるヤツ。若手なんだが、まだまだ感覚が鈍いな。

と言うのも、要件はこうなんだ。

ファイルを読み込んで、ファイルの内容に応じて処理して欲しい。

これだけ見れば簡単に見えるだろう。
しかし「ファイルの内容に応じて」って一体何やねん？

これね、経験豊富なベテランじゃないと分からないんだけど、IT業界のシステム開発って、IN/OUTの総量が工数の総量なのよ。

「凄く難しい複雑なロジックを作る」みたいなクールな話は基本無い。

データベースの決まった所から取ってきて、0を1に編集して、また同じ所に戻す。処理なんて殆ど全部こんなもんよ。
問題は「決まった所」ってどこなのか、ということだ。

このプロジェクトの場合、

• 新規契約の場合
• 更新の場合
• 解約の場合
• 追加の場合
• 再送の場合
• 新規契約２の場合
• 更新２の場合
• 解約２の場合
• 追加２の場合
• 再送２の場合

それぞれ取り扱うテーブルのカラムが違うねん。

そりゃ、読み込むファイルは１コしか無いかもしれないよ？
だからバッチ本数は１本だ。
しかし、アウトプット先が１０種類あったら、処理の総量はバッチ１０本と同じである。

今、設計を書いているヤツは、バッチの起動トリガーが物理的に１つであることしか理解してねぇんだ。
しかし、本質的にはバッチ１０本だ。

コイツ、設計書は省略して書いているから気付かないんだろうけど、設計者は同時にテスト担当者でもあるから、テストケースを書く時になったら否応無く気付くだろう。
自分の認識の１０倍の処理が存在している、と。

ともかく、実装担当の僕としては、頑張ってソースを大量生産するしか無いな。(; ･`д･´)

設計者の認識の１０倍の仕事量が目の前に存在している。荒っぽくとも、とにかくこれを力任せに片付けて、細かい問題はテストフェーズでバグという扱いで修正して最終的に納期を間に合わせるしか無い、というのが僕の方針である。(; ･`д･´)

生産量がモノを言うプロジェクトだ。

要件未確定な部分もいくつか混ざっているか、そういうのは横に置いておいて、とにかく前に進めていかないと。

大変なプロジェクトや。(´・ω・`)