グロッキー

今週は仕事の忙しさと暑さのダブルアタックで大変だったな。
金曜日の夜はグロッキーだった。(´×ω×`)

まあ、頑張った甲斐あって、進捗は問題無い。
この辺りで少しゆっくりしたいんだけど、何か他の連中が遅れているみたいだから、表向きには存在しないＨＥＬＰ作業で来週は忙しくなるかも。

なかなか楽させて貰えんわい。(´・ω・`)

ウズマスの野望～ＳＥ風雲録～

色々やることあって忙しいのだが、新しくゲームを買ってしまった。(；´・ω・`)

信長の野望３ＤＳ。
「信長の野望～武将風雲録～」という名前の方が有名だろう。

僕って信長の野望をプレイするのは初めてでね。
三國志が面白かったから、その繋がりで買ってしまった。

３日ほどプレイしてシステムは理解できてきた感があるが、寝る間を惜しんでプレイしていたら疲れてきてしまった。

そんなに慌ててやるもんでもないし、ゆっくりプレイしていきたい。(´・ω・`)

始まらん

実装第一フェーズは6/19(金)で終わり。
第二フェーズは6/22(月)から始まる。

第一フェーズと第二フェーズの違いは何かと言うと、このプロジェクトは要件が固まらんし、設計も間に合わん。
でも納期は短いから、僕の嗅覚で好きに実装しておいてくれ、というのが第一フェーズ。

嗅覚と言っても、仕様とは関係無いプログラムとしての基盤部は作れるし、仕様も大体、察しが付く。
「契約結んだら契約レコードをインサートする」とか、当たり前や。
抜けてるのは、「契約レコードをインサートする一歩手前でデータの整合性チェックを行い、不適合な条件のものは除外する」とか、そういう細かい部分だ。

第二フェーズは、ようやく仕様と設計が追い付いてくるから、次こそは設計書と突合するようにソースを完成させていく、というものだが……。

これは間に合わんな。(´・ω・`)

土日返上で若い衆が今頑張って設計書を書いてる。その途中進行を今ちょっと覗いてみたが……。無理無理無理無理。
こんなペースで間に合うわけが無い。
総量で言えば、明日の朝の時点で執筆されているのは７割が限度だろう。
しかもそれは無レビューのシロモノ。
無レビューで書くだけ書いた設計書が７割、白紙が３割。
これくらいで明日を迎える。

これは若い衆の作業が遅いというより、金曜日の時点であれだけ残っていた以上、もう無理ぽなことは明らかだった。
時間が一週間足らん。無茶振りされてｶﾜｲｿｽ。(´・ω・`)


さて、この状況で、来週はどうすっかなぁ。


これね、立場が逆だったらスケジュール調整に動いている状況だなぁ。

• 6/19(金)：設計完了
• 6/22(月)：製造第二フェーズ開始

と、スケジュール上はそうなっているかもしれないけど、無理なもんは無理ってことは明確にしなきゃいけないし、
また実際のところ、設計書の全てが完成しておらずとも、6/22(月)から製造は開始出来るじゃない？
五月雨式に「設計が完成している部分」から製造を始めて、製造の後半くらいまでに全量が揃えば、最後には辻褄が合うでしょ？

つまり、


( ﾟДﾟ)「設計書は全く間に合いません。が、機能１～１０のうち、１，２だけなら6/22(月)に間に合います。とりあえず機能１、２から製造を始めて頂き、３～は完成次第、という進行で実装して頂けませんでしょうか？」
(´・ω・`)「了解～」


という調整を金曜日のうちに済ませておくのが本来の筋だが、若い衆にそんな調整を要求するのは無理過ぎるだろう。

若い衆の現在の精神状況を推察するに、たぶん今、必死になって少しでも設計書を多く書こうとしている。
と言っても、全然間に合わないことは既に明らかで。
そのまま鬱な気持ちで明日の朝を迎えるだろう。


カワイソス。(´・ω・`)


と考えると、来週は僕の方からその話を持ち出したらなアカンか。

機能１～１０のうち、「完成度の高いもの」と「低いもの」があるはずなのよ。

「完成度の高いもの」を引き取って、実装者の僕がレビューも兼ねる、とすれば、作業は進むでしょ？
そうやって時間を稼いでいる間に「完成度の低いもの」を揉んで貰う。

という風にロードマップを整備すれば、進捗遅延で鬱になっている若い衆の気も晴れて作業に集中できるだろう。

やっぱプログラマーであってもマネージメントの概念は必要や。(´・ω・`)

ぼかし表現

一応、第一フェーズの仮実装完了の目標日。
かつ、後追いで仕様書も作られているので、その読み合わせを行った。

その仕様書も完成していなんだけど、一応の区切りの段階だということで見せて貰ったが……。
やっぱ、特に明確に拠り所となる資料が不足した空中戦だから人に依って理解度に差が出てるね。(´・ω・`)

同じ間違いでも、

• そこそこ理解した上で間違えている
• そもそも理解不足を放置したまま資料を書いている

これって全然違うもので、文面から伝わってくるんだよね。(；´・ω・`)

前者、「そこそこ理解した上で間違えている」のパターンだと、少なくともドキュメントの日本語は明確だし、本人の意識も鮮明なのよ。
だから、


( ﾟДﾟ)「ここでこういう条件でテーブルを検索します」
(´・ω・`)「あれ？　その条件だと一意にならんような？」
( ﾟДﾟ)「えっ？　そうでしたっけ？」
(´・ω・`)「ステータスが1であること、を条件に追加しないといけないような」
( ﾟДﾟ)「確かに、修正します」


って感じに、凸凹しつつも議論が進んでいくのよね。
修正箇所が多いか少ないか、程度の問題でしか無い。
無論、間違いは少ないに越したことは無いけど、間違いが２倍あれば２倍修正すれば終わる。
叩き台なんだから、どれだけ間違っていても構わん。
ゴールまでの道筋は見えている。

ヤバいのは後者「そもそも理解不足を放置したまま資料を書いている」で、


( ﾟДﾟ)「ここで取得します」
(´・ω・`)「何を取得するんでしょう？」
( ﾟДﾟ)「データベースを」
(´・ω・`)「テーブルはどれでしょう？」
( ﾟДﾟ)「えっと……。契約テーブル？」
(´・ω・`)「契約テーブルをどういう条件で検索するのでしょう？」
( ﾟДﾟ)「会員ＩＤ？」
(´・ω・`)「その会員ＩＤはどこから出てきたものですか？」
( ﾟДﾟ)「えっと……」
(´・ω・`)「この処理は会員ＩＤで検索するものではなく、ステータスが１であるものを全件取得するものだと思うんですよ」
( ﾟДﾟ)「確かに」
(´・ω・`)「だから、以降の処理はループ処理です。また、この処理は大量件数になる可能性があるので、負荷についても考慮しておく必要があって……」


って感じ。


本人の意識が混濁してるのよね。

だから資料も「取得する」とは書いているけど、「何をどこからどういう条件で取得する」とは書いてない。
混濁している部分は省略したり、ぼやかした表現にして、次の作業へ。
だからドキュメントの数は揃ってるんだけど、中身はどこから直せば良いのやら、という状況。
これは「間違っている」のではなく、何も書いていないのと同じ。
遭難している。これでは丸１日会議やっても何も進まない。


「間違い」と「意識混濁」は次元が違うのよ。
なかなか厳しいなぁ。(；´・ω・`)

まあ、進めようと思えば、


(´・ω・`)「貴方はこういうことが言いたいんですよね」


と僕からフォローすることで進めることも可能なんだけど、こんなことを繰り返しておっては相手の顔が潰れるでな。(；´・ω・`)

会議の場まで出てきちゃう前に気付いてフォローしてあげたいんだけど、
この手のドキュメントは「執筆途中」にも見えるのよね。
執筆中のドキュメントを指してＮＧを出すのは失礼だし。

相手の脳内を読むのが難しい。(；´・ω・`)

余力

そろそろ余裕が出てきたな～。(´・ω・`)

まだやることは残っているけど、パワーが必要な作業は終わった。

今後は要件定義チームから資料が出され次第、中身をチェックして認識差異を修正していくわけだが、要件定義チームは忙しいみたいだから資料が出てくるのも遅いだろう。

ま、休憩フェーズや。
先週頑張って前倒ししたからな。

１６：３０だけど、もうハイボール飲んどる。
前半は電撃戦で自作業を前倒しで進め、後半は余力を持って優雅に過ごすのが僕のスタイルや。(´・ω・`)

今日から頭脳労働

ふぃ～。(´・ω・`)

先週で肉体労働は終わらせたから、今日から頭脳労働に入れる予定だ。
と言うのも、ＩＴ業界にはＩＴドカタという言葉があるくらい、肉体労働的な側面の強い仕事があるのよ。

例えば、このシステムってＤＢの項目で２００～３００、ＣＳＶの項目も２００～３００。

• ＣＳＶから値を取得し、ＤＢにセットする。

と、ただそれだけの処理でも、この項目数だと変数を定義したり、ゲットしてセットするだけでも凄い重労働で、手が腱鞘炎になるくらいキツい。(；´・ω・`)

が、そのようなパワー労働は先週で一通り終わったことだし、今日からはもうちょっと知的な頭脳労働に移行し、肉体負担は減らせることを期待したい。

今来ている話だと、日付だな。
僕が荒っぽく作ったバッチは、

• フラグが１であるものを更新する。

なんだけど、来ている話を見ると、

• フラグが１であり、かつ日付が過去であるものを更新する。
• 
  

に修正しなきゃいけないっぽい。

「っぽい」ってのは何かって言うと、上の話は値を取得する時の話でしょ？
「その日付項目は、いつどこで値をセットするんだ？」って話が来てない。
つまり、僕の所には情報が５０％しか届いていないってことだ。

この話、取得処理の修正はSQLのWhere句を１つ増やすだけだから、修正は２分で終わる。
でも、取得処理だけ修正しても辻褄が合わんし、辻褄が合わんって事に気付いて、整理し、問い合わせしたり、チャットしたり、Ｗｅｂ会議したり……、というのに時間を要する。

これが頭脳労働だ。

まあ、システム開発の正論を言えば、本来はその辺の辻褄合わせが終わってから実装に入るべきなんだけど、このプロジェクトは逆で、とにかく粗方の実装が終わってから、上記みたいな話が増えて修正していく、というスタイル。

とは言え、「修正」とは「Where句を１つ増やすこと」とかそういうレベルの話。
バッチ全体を修正しなきゃいけないような根こそぎの仕様変更にはならない、という程度の見通しがあるから見切り発車してるねん。

何とかなるやろ。

ともかく、肉体負荷は軽減の見通しや。
返事が来るまでの待ち時間も増えてくるだろう。

少しは楽したいのう。(´・ω・`)

但し書き

仕様書

• 契約日：入力必須項目。但し、契約が成立していない時は必須ではない。

バカヤロ～。
それは入力必須項目とは言わんのや。(´・ω・`)

それに、「契約が成立していない時」は契約日なんて入力禁止ちゃうんか？
「入力禁止」と「必須ではない」をゴッチャにすんな。(´・ω・`)

そもそも、「但し」って何や？　「但し」なんて言葉はシステムに存在せんのや。

• 契約日：①契約済の場合、入力必須とする。②未契約の場合、入力禁止とする。

と書かんかい。

システムはif else if else で成り立ってるってことが骨身で分かってないからこんな日本語を使うことになるんや。
システム抜きでも普通にこの方が分かり易いやろ。
日本語どうなっとるんや。

あと、条件に応じてＣＳＶの構成が微妙に変わるのは、それはフォーマットが２つあるのと同じや。
殆どの項目が重複しているからと言って、２つあるフォーマットを１つの表で書くのはやめろ。(´・ω・`)