正解の選択肢

 やっぱりキッツいよ、このプロジェクトは。(；´・ω・`)

こういう時、僕は「進捗ヤバいなら、なおさら少しでも作業しなきゃ！！」ではなくて、「少し落ち着こう」と考えるタイプだね。

作業に集中していると色々とクラッシュしてくる。整理フェーズを時々設けないと。

まずよ～、やっぱりこれ、設計が……。50点だよ、これは。

初回案という程度には出来ているけど、このままでは作業出来ないから、僕が査読して手直ししなければならない。
事実上、僕はプログラマーであると同時に、設計のレビュアーでもあるんだ。

しかし現実は実装に専念してやれやれ、という進捗。そこに50点のシロモノのレビューが乗ってくるのはキツいキツい。

って言うか、そもそも月末までに設計が終わるんかしら？
月末時点でそもそも設計が未完成だったら、実装どうこうじゃないわな。進捗管理されてないからその辺の見通しもよく分からない。

と考えると、実装を続けるべきだろうか？

つまり、「自分はこのプロジェクトではプログラマーの立場だから」という前提を取り消し、僕が設計と進捗管理に本格的に介入するのが正解ではないか？

「進捗が遅れているから頑張らなきゃ！！」じゃなくて、プロジェクトの前提に立ち戻って、広い視野で物事を考えるべき時が今なんじゃないか。

本来それを考えるのはマネージャーなのだが、このプロジェクトはマネージャー見習いが経験積む為にやってるだけから、こういう視点など持ってるはずが無い。
僕が「自分はプログラマーだから」と、愚直に作業に専念していたらプロジェクトが死んでしまう。

どう立ち振る舞うべきか。このまま現在の立場を維持するべきか、僕がプロジェクト全体を仕切る方向に切り替えるべきか。

前者だとプロジェクト自体がヤバい。
後者は人間関係に角が立ち、かつ僕個人の責任も重くなるのがリスクだ。

どう振る舞うのが正解なのかなぁ。
風呂にでも入りながらじっくり考えるか。

やっぱり人生で大事なのは、作業遂行能力が高いかどうかではなく、正解の選択肢を選ぶことが出来るかどうか、だよね。

難しいなぁ。(´・ω・`)

設計指摘

やれやれ、ようやく設計チームから「設計完成」の連絡が来たぞ。(；´・ω・`)

この一言さえあれば僕が動ける。

この自称完成した設計、ハッキリ言って間違いだらけなんだけど、僕にはどこが間違っているか分かるからな。

(｀・ω・´)「この設計書のこの部分はおかしい。本来こうあるべきものを書き間違えているでしょう？」

という指摘を出しまくれば、それは僕が書いているのと同じだから、今度こそ本当に完成する。

本来、プログラマーってのは設計書に書かれている内容をその通りに実装するのが仕事だが、現実はそうじゃないのよ。

間違った設計書が降りて来るのが常だから、プログラマーが自発的に気付いて差し戻さねばならん。

「設計書の間違いに自ら気付くことが出来るか？」はプログラマーの腕前の一つよね。

ま～、とにかく、ここからが本番だ。(´・ω・`)

まだら

 画面１０画面、バッチ１０本、この全てが設計完成度２０～６０％なんだよなぁ。(´・ω・`)

完全完成しているものが一つも無い。要は設計者が実力不足で良く分からんから、分かる範囲内をポロポロ書いてるだけなのよ。

だから進捗０～６０％までは頑張って進むかもしれないが、６１～９９％の間でパタッと手が止まるのが目に見えている。

その６０％ってのも、「上の方の６０％はＯＫだが、下の方の４０％は未着手」というように整理されているわけではなく。

全体的に歯抜け。「全体的に６０％くらいは埋まってるけど、全体的に４０％くらい不均一に歯抜けや間違いが散りばめられている」という。

それは実質的にはゼロと同じなんや。ふざけんなよ、本当に。(#´^ω^`)

推測実装

 設計書が全てデタラメ……と言うか未完成で萎え。(´・ω・`)

未完成のページとデタラメのページの見分けがつかん。

たぶん、全部未完成だと思うのだが。
まだ書いている途中のものに対して「これ、間違ってますよ」とは言えんからな。しかし気になって仕方が無い。

でも設計書の完成を待ってたら納期間に合わないから、勝手に実装してる。

「設計書には書いてないけど、要件の辻褄を考えれば本来こうなっているはずだ」

勝手に設計を予測して実装してる。ってか、そうとしかならんもん。

ＤＢ設計とCSVファイル設計が完了した時点で、残りは深く考えるまでもなく、自ずとそう帰結するようにしかならんような話やがや。

何をやっとるんや？(´・ω・`)

危機感

このプロジェクト、結構ヤバいな。(；´・ω・`)

ヤバいと言っても、所詮は小規模プロジェクト。小規模ならば何とでもゴリ押し可能ではあるのだが。

弊社社長と僕の２人でゴリ押しは最終手段。
その最終手段が発動になる気配、ギリギリ感を感じて来た。

って言うか、設計やってる若い衆、ギブアップしろ。

お前らの力量ではもう追い付かない。ベテランに全部丸投げする以外に打開する手段は無いんや。僕は実装チームだから設計チームに苦言する立場に無い。自分で気付け。

一体どういうスケジュールでプロジェクトを終わらせるつもりや？
10月末に実装完了のスケジュールなのに、このままでは10月末に設計も終わっとらんやろ。

お前らは「見通し」という概念が欠落しとる。
「いや、これちょっとヤバいんじゃない？」と現状を振り返る観点が無い。
だから感じるべき危機感を感じず、漫然と作業し続けられるんや。

所詮は小規模プロジェクト。
泣き付けばベテラン陣でフォロー可能だが、泣き付くべき時は今なんやぞ。

月末に進捗を問われて窮するみたいなオチは観ているこっちがやるせないからやめてくれ。

今すぐギブアップしろ。

熟達しろとは言わん。
「自分の手に余るかどうか」は自分で理解するべき。(´・ω・`)

立ち上げフェーズ

 今週はしんどいなぁ。(；´・ω・`)

今週から新プロジェクトが始まってね、僕は常套手段として、プロジェクトの前半ほどフルパワーで働いて、後半に余力を残すというスタイルを取るのよ。

「時間的余力が全てを解決する」の一点張りの男。

だから最初である今週が一番大変。(；´・ω・`)

しかし、何とかペースは上々かなぁ。

何と言ってもこのプロジェクト、形が無い。

まず、機能数不明。
画面とバッチを作って欲しいみたいなんだけど、バッチの総量が分かんない。
まあ、聞いている話から概ねの規模感は何となく察するんだけど、機能一覧としてのリストアップがまだ出来てない。
総量が分かんないから進捗率も算出出来ず。進捗率が見えない以上は、出来るだけ早く進めておくしかやり様が無い。

次に、画面項目不明。
画面に表示する項目が明らかにデタラメなのよ。モックは僕が作ったんだけど、類似システムを参考にそれっぽく作っただけだから、今となってはＤＢに存在しないカラムが画面に出ているような状況。
ただ、主キーだけは正しいから、それを踏まえて作れる部分だけ作ってる。

最後に、スケジュール不明。
実装完了は今月末だが、テストは今月中に開始する。この「テスト」って一体なんなのよ？
僕の実装完了が月末だったらテストの開始なんて出来ないでしょ？
「テストを始めたいから先に完成させて欲しい機能」と「後回しで良い機能」があるはずなんだけど、どれがどれか分からん。

って感じで、とにかく計画みたいなものが壊滅してて。(；´・ω・`)

見習いが経験を積む為にマネージャーやってるから、手に余ってるんだな。

「マネージャーが見習いだから、プログラマーの方にベテランを置く」という布陣。

と言うわけで、とにかくプロジェクトがどう横転しても下流工程で吸収可能な状況に持ち込む必要があって、その為に今週はずっとフルパワーである。

こんなやり方、基本ありえんでな。
プロマネプログラマーのウズ様に感謝せ～よ。(´・ω・`)

マネージャー不在

 そろそろプロジェクトが本格始動なんだけど、既に半分グダってるな。マネージャーどこ行ってしもうた？(；´・ω・`)

と言うのも、若手の育成という観点から、このプロジェクトは若手に仕切ってやって貰おうという意図があるみたいなんだけど、そのマネージャー代理が自分の作業で忙しくてマネージメントまで手が回らなくなっちゃってるような。

だから作業指示もスケジュールも何も無い。(；´・ω・`)

が、まあ、僕はベテランだから、そういうのも汲み上げて作業を進めてしまうんだが、流石に管理が虚無の状況を続けるのも不健全っしょ。

明日は朝に軽く情報交換しましょう、という話をもちかけておいた。その中でスケジュール感や要件定義の角度、優先順位も見えてくるだろう。

プログラマーではあるが、同時にマネージャー補佐であるという、この謎ポジション。

僕みたいなのは何て言えば良いんだろうね。何でも屋が極まってる。(´・ω・`)