叩き殺す

 僕は技術力が高いと評価されて今の地位にいるわけだが、違うって。分かって貰いたいのはそこじゃないって。(´・ω・`)

こんなデタラメの設計書を渡されてよ～。

いや、無論、プログラミングが特技であるのは本当で、実装の生産性には自信がある。でもそういう風に言われたら、まるで僕が技術オタクみたいに聞こえるじゃないか。

違うって。

デタラメの設計書を渡されて。

(；´-ω-`)「いや、おかしい。こんな設計で要件が満たされているはずがない」

と気付く。

僕は要件定義のキャッチアップが伴うプログラマーなのよ。
そして、一切説明を受けていないけど、転がっている資料を自分で探して調べて、

(´・ω・`)「設計はこうなっていますが、要件定義書にはこのように書かれています。この場合、この処理のこの部分でエラーが生じた場合、それをオペレータに通知する必要がある。従って、この部分にエラー系を実装し、ＤＢにエラーメッセージを登録する処理が必要ではありませんか？」

と問い合わせるとかさ～。

立場は確かにプログラマーだ。しかし、設計者以上に要件定義に精通し、実装工程から設計工程に情報をフィードバックすることが出来る。

プロマネの素養のあるプログラマーである、という点が最大の長所なのよ。カタワみたいなプログラマーは余ってる。各方面に理解があることが大事になるんだ。

しかし、分かるかね、このストレスが。

全部デタラメや！！

おかしいんやって、こんなことは。

こんなことやってたら本職の実装が全然進まんやろが。口先だけの実装フェーズ、実態は設計レビューが僕の仕事になっとる！！

その辺の単金いくらのプログラマーなら設計書を押し付ければそれを鵜呑みにして実装するのであろうが。

このウズマス様を騙せると思うな！！

この設計は間違っとる！！　要件を網羅出来ているはずがない！！

叩き殺したろか！！

遅延定義

 このプロジェクトは管理が緩くって、要は最終的に問題が起きなければ良いってだけなのよね。(´・ω・`)

しかし、本格的なプロジェクトには進捗管理というものがあり、進捗管理の中にはマイルストーン判定というものがある。

例えば、設計完了とはどういう条件を満たす事を意味するのか？

条件とは、例えば、設計書を一通り書いて、レビューを受け、レビュアーがＯＫを出す。レビュアーがＯＫした事を以て完了とする、とか。
小さなプロジェクトだとこんなもんだけど、大きいプロジェクトだとレビュー時間とか指摘件数とかの査定があって、査定チームからＯＫが出た事を以て完了する、とか。
まあ、定義は色々あるのよ。

では、このプロジェクトの場合は何か？

• 設計完了は、設計担当者が完了と思ったら完了とする。

なのよ。アカンって。

( ﾟДﾟ)「設計進捗100%です！！」
(´・ω・`)「どこが100%や」

アカンって。
僕の観点から見て、この設計書は完成したと言えない。スカスカ過ぎる。

試験項目を作る時に「あれ？　このバッチってこういう時どんな挙動すれば良いんだっけ？」みたいに分かんなくなっちゃって手が止まるのが目に見えている。

後工程で作業が停滞して立ち戻りが必要になる設計書は、完成したものとはいえないだろう。

それもちょっとなら良いよ？　別に１００点満点の設計書を作れと言ってるのではなく、８０点くらいなら吸収出来よう。６０点が最低ラインだ。
でも、この設計書は４０点だ。最低ラインに届いてない。

開発が完了したモジュールでもバグが残っている事はある。しかし、起動すらしないものを完成したとは言うのは無理あるでしょ？
そういうこと。最低水準を満たしていないものは完成と言えないんだよ。

この４０点のシロモノを６０点に引き上げるには、一週間は必要だろう。

つまり、このプロジェクトは実質的には一週間遅延してる。設計担当者が完了したと言えば設計フェーズ完了になるのだろうが、実質的には完了してない。

今は遅延を報告するべき時なんやって。定義が無いから何とでも言えるけど、実質的に遅れてる。オンスケを言い張ったらアカンって。

アカンって。(´・ω・`)

魂のルフラン

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

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

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

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

一を聞いて十を知る

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

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

元々は

• 処理前
• 完了

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

• 処理前
• 処理中
• 完了

になってる。

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

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

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

じゃねえよ。

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

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

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

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

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

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

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

断固たる跳ね返し

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

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

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

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

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

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

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

じゃねーぞ。

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

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

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

省略設計

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

説明が曖昧なのよね。

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

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

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

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

当たり前っしょ？

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

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

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

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

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

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

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

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

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

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

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

正解の選択肢

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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