魂のルフラン

 こりゃヤバい。精神おかしくなってきた。(；´・ω・`)

実装をガタガタガタガタやりながら魂のルフランを繰り返し聞きつつインディアンクラブを振り回しているとか、客観的に普通じゃないよね。

我ながらどうしてこうなっちゃうのか。

本性がちょっと普通じゃない感は自覚してるんだけどね。(；´・ω・`)

一を聞いて十を知る

 一を聞いて十を知る、じゃねえよ、バカヤロ～。このプロジェクト、マジでキツいって。(´・ω・`)

いや、なんかさ、知らんうちにステータスが増えてるのよ。

元々は

• 処理前
• 完了

だったのが、いつの間にか、

• 処理前
• 処理中
• 完了

になってる。

(；´・ω・`)「処理中が増えた！？　ってことは処理完了とそれ以外を読み分ける必要があるからであって、関係ありそうな部分は……」

って思って調べると、実際そっちも修正の必要があるのよ。

( ﾟДﾟ)「ステータス増えました」

じゃねえよ。

ステータスに「処理中」が増えたその要件定義的な理由と、その結果としてシステム全体のどこに改修を加える必要があるのか。
それを網羅していなければ設計とは言えんだろうが。

それを整理して伝達するのが設計チームの責任、その結果をソースに反映するのが実装チーム……と言うか僕一人しかいないから僕の仕事だ。

実際には「ステータス増えました」の言葉も無くて、知らんうちにドキュメントが差し代わってる。
問い合わせたからこの言葉が来た。問い合わせなければほったらかしだった。

つまるところ、プログラマーの僕の視点としては、プログラマーが設計や要件定義の変動を自らキャッチアップして自発的に実装にフィードバックしなければ成り立たないプロジェクト、という状況。

いや、これ、キッツイってマジで。
僕は会議とかにも出席してないんだから。臭いを嗅ぎつけるだけでも高難度クエスト。

って言うか実装だけで既に負荷ＭＡＸ。前工程のお粗末な部分をフォローアップする余力はもう無い。

マジキツいって。(；´・ω・`)

断固たる跳ね返し

 ちょっとヤバいって、このプロジェクト。(；´・ω・`)

( ﾟДﾟ)「この設計でお願いします」
(#´^ω^`)「こんな設計のはずがない！！」

ずっとこんなことやってる。(；´・ω・`)

(#´^ω^`)「こんな設計のはずがない！！」

僕のこれは極めて重要なことやってるんやで。

これ、その辺のタワケが実装していたら、腐った設計がそのままズルズル行ってしまうでな。
僕が止めているから進捗が進まんのだけど、僕が止めなければ破滅や。(#´^ω^`)

( ﾟДﾟ)「ウズマスの野郎、うるせーな。仕事増やしやがって」

じゃねーぞ。

ここで止めなければ来月破滅する。
今止めれば、デスマで乗り切れる。

断固として止めなければならん。

本当に勝負所。(；´・ω・`)

省略設計

 土日も仕事してるけど、この設計書では進捗上がらないぞ。(；´・ω・`)

説明が曖昧なのよね。

僕が作っているのはcsvファイルを読み込んでＤＢに登録するバッチなんだけど、設計書にこんな記述がある。

• 支払い方法：新規契約の場合のみ、入力可能

新規契約の場合のみ、入力可能。じゃあ、新規契約以外の時は？？？
正解はこう。

• 支払い方法：新規契約の場合のみ、入力可能。それ以外の場合はエラーとする。エラーメッセージ「ERROR_0089：支払方法は新規契約以外では入力出来ません」

当たり前っしょ？

支払方法が「銀行引き落とし」か「クレジットカード払い」か？　それは新規契約の時に決める項目であり、解約処理の時にそんな値が来るのはおかしいから、そんなデータが来たらエラーにして処理を止める。

それがこの設計には載ってないんだよな～。

まあ、ハッキリ言って僕は１～１００まで指示して貰わねば実装出来ないわけじゃない。上記みたいな所があれば、「ああ、書き忘れてるんだな」と自分で気付く。
「そこまで詳細に書かなくても理解出来るでしょ？」くらいの話には応じられる。

しかし、エラー番号とその文言は設計者に決めて貰わねば絶対無理じゃない？

つまり、この設計は記述を簡略化しているんじゃない。ただ抜けているだけ。

• 記述を省略して作業を簡略化している部分
• 設計が欠落している部分

「省略」と「欠落」は違う話なのよ。

ただ記述を端折っているだけの部分と、本当に記述が欠落している部分が入り乱れている。全ての記述がチープだから本当に難解。

(´・ω・`)「果たしてこれは設計者が意図してわざわざこのような設計にしているのだろうか？　ただ考慮してないだけであろうか？」

こんなこと考えながら実装してたら時間がいくらあっても足らんわ。

流石にキツいって、これは。(´・ω・`)

正解の選択肢

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

設計指摘

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

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

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

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

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

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

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

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

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

まだら

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

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

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

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

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

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