バッチ増量

 うげっ……。(；´-ω-`)

設計の矛盾を多数指摘したら、「処理が抜けていました」とかで、バッチが２本追加。

そのうち１本は重い。(；´-ω-`)

これは設計完了じゃないんだって。設計書のレビュー中の間違いでしょ。

指摘するほど自分の仕事が増えていく。

しかし指摘しないわけにもいかない、という……。(；´-ω-`)

読解不能

休日労働中。(´・ω・`)

完成度１００％の設計書を見ながら実装してるんだけど、う～ん。

分かんないよ、これ。空白だもん。エクセルに着色しているだけ。これが完成度１００％かね？

まあ、僕はこれでも一応、ハイスキルエンジニアというポジションにあるから、設計書に空白が目立っても要件や処理の前後関係から本来そこに埋まっているべき記述が何なのかを手繰り寄せるくらいのことはやるんだが。

それでも分かんない部分はある。能力の限界。
だから問い合わせは送ってるんだけど、返事ゼロ。

月曜から実装と並行してテスト開始とか言ってるけど、僕が問い合わせしている設計書の指摘事項３０コを返信してからテスト開始だよね？
そりゃそうだろう。設計書のレビュー指摘事項修正よりも試験開始が優先なんてありえないじゃん。

つまるところ、デタラメで良いなら進捗は進められるのよ。
結合テストに着手すれば、それは予定通りの日付で着手だ。

しかし、必ず結合テストの過程で意味不明になって、結合テスト期間に膨大な設計書修正作業、ソース修正作業が発生する。

結合テストフェーズで設計書の加筆をすることになるんだ。

これをデタラメと言う。

ふざけんなよ、本当に！！

ここでやっかいなのが、こんな状況でも「設計チームがデタラメなのが悪いんだ！！」みたいな姿勢は取れない、ということ。

それは一山いくらの馬の骨のプログラマーの対応策。僕はハイスキルエンジニア、上級職という位置付けだから、幅広い手厚いフォローアップが伴わないと肩書に即さなくなってくる。

しかし、問題の連中はデタラメやってる自覚も無い。自覚が無い人間ほど御し難いものは無いわけで。

自覚さえあれば僕が介入することが出来るんだが、

(・ω・)「オンスケですが何か？」

みたいなぽや～んとした輩に介入すると、逆に僕が悪者になるリスクがある。

どうしたら良いもんか、くそっ。

小室圭合格

 やれやれやれやれ、やっとやってくれたか。(´・ω・`)

• 小室圭さんNY司法試験に合格　３度目の挑戦でついに　23日の眞子さん誕生日前に朗報

いやいや、本当、見ている国民の方が、ね。(；´^ω^`)

日本人にとって皇族というのは特殊なものであるから、その皇族の一人を伴侶に迎えたこの小室圭という庶民が、果たしてその重責に相応しい人材であるかどうか。

そこは何とも評価が難しくて、僕には到底分からん雲の上レベルである。

しかし、難しい話とは言え、無職やフリーターも同然ではいくら何でもちょっと……という感はあった。

眞子様が生活苦に喘ぐとか、イメージもしたくないんだよ！！
プリンセスなんやで！！

しかし、旦那がNY司法試験に合格したことで、何とか面目が立ったな。
これで何とか「ニュースを聞いている国民の方が居たたまれない」という事態はクリアだろう。

僕もホッとしたわ、やれやれやれやれ。。。

しかしこの小室圭という男、何とも胡散臭さが先立っていたけど、司法試験合格でそれも解消に向かうか？
NY司法試験合格ってからには、日本の普通の弁護士よりも上級くらいのランク感あるじゃない？
外国の法律を英語で理解しているってことなんだから。

完全無欠の天才とまでは言えないだろうけど、僕の身近にはいないくらいの秀才だってのは本当なんだろうな。

とにかく、やれやれやれやれ。。。
今後はこの勢いで輝かしいエリート街道を進んで欲しい。

ケチが付いた話なんか聞きたくない。

ディズニーの王子様路線で頼むわ、本当に。

国民の夢を代行しとるんやで。(´・ω・`)

自覚無き者

 状況を問い質してみたら、返事は「一日遅れ」だった。(´・ω・`)

マズいなぁ。そんなはずがないんだよ。

僕の見立てだと一週間遅れている。(；´・ω・`)

どうして見通しの見解に差が生まれるかと言うと、作業を忘れているからだ。

現時点においては、本気で一日遅れだと思っている。

しかし、来週になると、

(; ﾟДﾟ)「あっ、これ忘れてた」
(; ﾟДﾟ)「あっ、これもやらなきゃ」
(; ﾟДﾟ)「えっ、これ重い」

みたいに気が付く。そうなるのが目に見えている。

だが、現時点においては気付いていない。参ったな～。

この手の「自覚無き者」への対処は実に難しい。

無論、見通しが間違っている事を一つ一つ説明することは可能であるが、僕はそれは悪手だと思うんだよなぁ。
現時点において自覚していないのであれば、それをくどくど説明しても煙たがられるだけだ。

(# ﾟДﾟ)「うるさいなぁ。ウズのおっちゃんは」

みたいな感じにしか聞こえないだろう。

困り果て、泣きが入った時でなければ、他人は他人の意見を聞かない。

これが世の中の真実。

( ；Д；)「どうしたら良いんでしょう、ウズさん？」

と、この藁をも掴む思いになるまで待たねばならん。
そうなって初めて人は僕の言う事を聞く。

だが、そこまで待ってるとダメージも大きくなるのも事実であり……。

どうすっかな～。
とりあえず、みんなが見える場所で軽く忠告を入れておくか。軽くね、軽く。

「ああ、ウズさんはもっと前から気付いてたんだな」
「だが、他の人はそれをスルーした」

という雰囲気が醸成出来れば、まあいいだろう。
プロジェクトが負うダメージ部分は、後でリカバリーする。

このプロジェクトは僕が５割増しで労働しなければ成り立たない。
だが、それをやるのは今ではない。

泣いて頼み込まれるのを待ってからでなければ、誰も僕の苦労に気付かないまま終わってしまうどころか、僕が「五月蠅い人」という扱いにされてしまうからな。

トラブってるプロジェクトでは立ち振る舞いに気を付けないと。

やる気はあるけど、悪者にされない為の計算は必要。大人の知恵やな(´・ω・`)

休養

 ちょっと実装への影響が大きい大規模の設計ミスと目される部分があって。(´・ω・`)

ミスにも「規模」があって、パラメータの設定間違いとか、小さいミスならとりあえず実装を進めて後から直せばＯＫ。

「エラー系が全面欠落」とか、こういう巨大な抜けがあると、見切り発車で実装しても全部無に帰すリスクが高い。

というわけで、昨日は指摘事項を整理して送り出し、早めに休憩した。
１０時間くらい眠って体調も随分良くなったわい。

こういう頑張っても仕方が無い時に休んで体力を回復し、戦いの時に備えておくのも大事なスキルよね。

今日はその結果が戻ってくるから、今日は頑張らないと。(´・ω・`)

叩き殺す

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

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

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

違うって。

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

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

と気付く。

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

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

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

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

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

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

全部デタラメや！！

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

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

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

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

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

叩き殺したろか！！

遅延定義

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

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

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

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

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

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

なのよ。アカンって。

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

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

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

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

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

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

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

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

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

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