ちょっとヤバいって、このプロジェクト。(；´・ω・`)
( ﾟДﾟ)「この設計でお願いします」
(#´^ω^`)「こんな設計のはずがない！！」
ずっとこんなことやってる。(；´・ω・`)
(#´^ω^`)「こんな設計のはずがない！！」
僕のこれは極めて重要なことやってるんやで。
これ、その辺のタワケが実装していたら、腐った設計がそのままズルズル行ってしまうでな。
僕が止めているから進捗が進まんのだけど、僕が止めなければ破滅や。(#´^ω^`)
( ﾟДﾟ)「ウズマスの野郎、うるせーな。仕事増やしやがって」
じゃねーぞ。
ここで止めなければ来月破滅する。
今止めれば、デスマで乗り切れる。
断固として止めなければならん。
本当に勝負所。(；´・ω・`)
土日も仕事してるけど、この設計書では進捗上がらないぞ。(；´・ω・`)
説明が曖昧なのよね。
僕が作っているのはcsvファイルを読み込んでＤＢに登録するバッチなんだけど、設計書にこんな記述がある。
新規契約の場合のみ、入力可能。じゃあ、新規契約以外の時は？？？
正解はこう。
当たり前っしょ？
支払方法が「銀行引き落とし」か「クレジットカード払い」か？ それは新規契約の時に決める項目であり、解約処理の時にそんな値が来るのはおかしいから、そんなデータが来たらエラーにして処理を止める。
それがこの設計には載ってないんだよな～。
まあ、ハッキリ言って僕は１～１００まで指示して貰わねば実装出来ないわけじゃない。上記みたいな所があれば、「ああ、書き忘れてるんだな」と自分で気付く。
「そこまで詳細に書かなくても理解出来るでしょ？」くらいの話には応じられる。
しかし、エラー番号とその文言は設計者に決めて貰わねば絶対無理じゃない？
つまり、この設計は記述を簡略化しているんじゃない。ただ抜けているだけ。
「省略」と「欠落」は違う話なのよ。
ただ記述を端折っているだけの部分と、本当に記述が欠落している部分が入り乱れている。全ての記述がチープだから本当に難解。
(´・ω・`)「果たしてこれは設計者が意図してわざわざこのような設計にしているのだろうか？ ただ考慮してないだけであろうか？」
こんなこと考えながら実装してたら時間がいくらあっても足らんわ。
流石にキツいって、これは。(´・ω・`)
やっぱりキッツいよ、このプロジェクトは。(；´・ω・`)
こういう時、僕は「進捗ヤバいなら、なおさら少しでも作業しなきゃ！！」ではなくて、「少し落ち着こう」と考えるタイプだね。
作業に集中していると色々とクラッシュしてくる。整理フェーズを時々設けないと。
まずよ～、やっぱりこれ、設計が……。50点だよ、これは。
初回案という程度には出来ているけど、このままでは作業出来ないから、僕が査読して手直ししなければならない。
事実上、僕はプログラマーであると同時に、設計のレビュアーでもあるんだ。
しかし現実は実装に専念してやれやれ、という進捗。そこに50点のシロモノのレビューが乗ってくるのはキツいキツい。
って言うか、そもそも月末までに設計が終わるんかしら？
月末時点でそもそも設計が未完成だったら、実装どうこうじゃないわな。進捗管理されてないからその辺の見通しもよく分からない。
と考えると、実装を続けるべきだろうか？
つまり、「自分はこのプロジェクトではプログラマーの立場だから」という前提を取り消し、僕が設計と進捗管理に本格的に介入するのが正解ではないか？
「進捗が遅れているから頑張らなきゃ！！」じゃなくて、プロジェクトの前提に立ち戻って、広い視野で物事を考えるべき時が今なんじゃないか。
本来それを考えるのはマネージャーなのだが、このプロジェクトはマネージャー見習いが経験積む為にやってるだけから、こういう視点など持ってるはずが無い。
僕が「自分はプログラマーだから」と、愚直に作業に専念していたらプロジェクトが死んでしまう。
どう立ち振る舞うべきか。このまま現在の立場を維持するべきか、僕がプロジェクト全体を仕切る方向に切り替えるべきか。
前者だとプロジェクト自体がヤバい。
後者は人間関係に角が立ち、かつ僕個人の責任も重くなるのがリスクだ。
どう振る舞うのが正解なのかなぁ。
風呂にでも入りながらじっくり考えるか。
やっぱり人生で大事なのは、作業遂行能力が高いかどうかではなく、正解の選択肢を選ぶことが出来るかどうか、だよね。
難しいなぁ。(´・ω・`)
やれやれ、ようやく設計チームから「設計完成」の連絡が来たぞ。(；´・ω・`)
この一言さえあれば僕が動ける。
この自称完成した設計、ハッキリ言って間違いだらけなんだけど、僕にはどこが間違っているか分かるからな。
(｀・ω・´)「この設計書のこの部分はおかしい。本来こうあるべきものを書き間違えているでしょう？」
という指摘を出しまくれば、それは僕が書いているのと同じだから、今度こそ本当に完成する。
本来、プログラマーってのは設計書に書かれている内容をその通りに実装するのが仕事だが、現実はそうじゃないのよ。
間違った設計書が降りて来るのが常だから、プログラマーが自発的に気付いて差し戻さねばならん。
「設計書の間違いに自ら気付くことが出来るか？」はプログラマーの腕前の一つよね。
ま～、とにかく、ここからが本番だ。(´・ω・`)
画面１０画面、バッチ１０本、この全てが設計完成度２０～６０％なんだよなぁ。(´・ω・`)
完全完成しているものが一つも無い。要は設計者が実力不足で良く分からんから、分かる範囲内をポロポロ書いてるだけなのよ。
だから進捗０～６０％までは頑張って進むかもしれないが、６１～９９％の間でパタッと手が止まるのが目に見えている。
その６０％ってのも、「上の方の６０％はＯＫだが、下の方の４０％は未着手」というように整理されているわけではなく。
全体的に歯抜け。「全体的に６０％くらいは埋まってるけど、全体的に４０％くらい不均一に歯抜けや間違いが散りばめられている」という。
それは実質的にはゼロと同じなんや。ふざけんなよ、本当に。(#´^ω^`)
設計書が全てデタラメ……と言うか未完成で萎え。(´・ω・`)
未完成のページとデタラメのページの見分けがつかん。
たぶん、全部未完成だと思うのだが。
まだ書いている途中のものに対して「これ、間違ってますよ」とは言えんからな。しかし気になって仕方が無い。
でも設計書の完成を待ってたら納期間に合わないから、勝手に実装してる。
「設計書には書いてないけど、要件の辻褄を考えれば本来こうなっているはずだ」
勝手に設計を予測して実装してる。ってか、そうとしかならんもん。
ＤＢ設計とCSVファイル設計が完了した時点で、残りは深く考えるまでもなく、自ずとそう帰結するようにしかならんような話やがや。
何をやっとるんや？(´・ω・`)
このプロジェクト、結構ヤバいな。(；´・ω・`)
ヤバいと言っても、所詮は小規模プロジェクト。小規模ならば何とでもゴリ押し可能ではあるのだが。
弊社社長と僕の２人でゴリ押しは最終手段。
その最終手段が発動になる気配、ギリギリ感を感じて来た。
って言うか、設計やってる若い衆、ギブアップしろ。
お前らの力量ではもう追い付かない。ベテランに全部丸投げする以外に打開する手段は無いんや。僕は実装チームだから設計チームに苦言する立場に無い。自分で気付け。
一体どういうスケジュールでプロジェクトを終わらせるつもりや？
10月末に実装完了のスケジュールなのに、このままでは10月末に設計も終わっとらんやろ。
お前らは「見通し」という概念が欠落しとる。
「いや、これちょっとヤバいんじゃない？」と現状を振り返る観点が無い。
だから感じるべき危機感を感じず、漫然と作業し続けられるんや。
所詮は小規模プロジェクト。
泣き付けばベテラン陣でフォロー可能だが、泣き付くべき時は今なんやぞ。
月末に進捗を問われて窮するみたいなオチは観ているこっちがやるせないからやめてくれ。
今すぐギブアップしろ。
熟達しろとは言わん。
「自分の手に余るかどうか」は自分で理解するべき。(´・ω・`)