着陸態勢

プロジェクトは何とか着陸態勢に入ったか……。(；´・ω・`)

散々グダグダの他チームもどうやら実装可能な設計になったようだ。

この設計ってのが僕のレビュー観点からすると非合理的なのだが、まあそこまでは言及するまい。
僕のスタンスとしては、物理的に可能な設計であれば了承する。効率までは口出ししない。

また、7月1日よりまたメンバーも増えて、現状はこんな構成になった。

・ウズマスチーム：10人、250画面作成
・他チーム：7人：50画面作成

人数比と担当範囲が全然合ってねえ……。(；´・ω・`)
これでオンスケが維持出来なかったらどうしようも無えだろ……。(；´・ω・`)

プロジェクトとしては赤字も赤字だが、まあそこは僕の立場では気にしても仕方が無いな。
我がチームの範囲ではオンスケ黒字を維持するように頑張ろう。(´・ω・`)

弾劾裁判

明日、月曜日は弾劾裁判が行われる……。
まあ、僕は弾劾する方なんだが……。

金曜日にコッソリ呼び出された。

「あっちのチームの進捗状況、どうなってる？」

と。

僕は正直に答えた。

僕はチーム間連携と称して他チームの開発にも深く首突っ込んでるから分かるのよ。
進捗は限りなくゼロに近い、と……。

向こうのチームメンバー自身より僕の方が精密に現状を理解していると言って良い。

原因は、決定的な技術力不足。
Ｗｅｂシステム開発の定石を知らない人が設計している。

ここで言う「定石」とは簡単も簡単。

・画面は保存ボタン1回のクリックで1レコードが保存されるようにデザインするべき。
・画面遷移する際、次の画面の初期表示に必要なパラメータを渡さなければならない。

この程度の話。
しかしあのチームの画面設計やっている人は上流工程しか経験が無いのか、上記のような最低限の技術的知識を有していないみたいなのよ。

だから僕が首突っ込んでチラッとレビューすると、

「この画面を表示する為の情報が足りませんよ」
「この画面デザインだと情報を保存するタイミングがありませんよ」

こういう話がボロボロ出て、もちろんそれは手戻りになる。

正直、他チームの話だし、画面の美的センスがイマイチだってレベルの話ならば僕も敢えて黙っておこうとは思っているけど、上記みたいに『製造不能レイアウト』の場合は、流石に放置は出来ないでしょ？

って感じで山のように修正が入った結果、スケジュールに大幅な遅延が発生している……。

結果、来週月曜に弾劾裁判が開催されることになっちまった。
つまり、


「あなた達、業務遂行に必要となる最低限のスキルが無いでしょ？」


こういう話をしなければならん。
問題は、その有罪判決の根拠となるのが僕の証言だってことよ。

僕は余りそういうシチェーションは得意ではない。
どう立ち振る舞えば良いか……。
参ったな、こりゃ……。(´・ω・`)

熱中症

最近暑くなってきたな。家の中が暑い。(´×ω×`)

昼ご飯食べてゆっくりしてきたら何だか鈍く頭痛がしてくるのよ。
たぶん、軽い熱中症だった。

最近は仕事も忙しいし、疲労との合わせ技でやられたっぽい。

水飲んで寝たら回復したが、土日丸二日、ほぼこんな調子でぶっ倒れてたわ。

回復せねば。(；´・ω・`)

チンプンカンプン親父

基本設計工程で画面設計を進行中～。
我がチームは荒っぽくも奮戦しているぜ。

しかし……。
どうも別チームの方が真剣にヤバい。

設計を行う為の能力が全く足らん……。

と言うのも、画面設計ってのは何でもいいから画面に項目を置けばいいってもんじゃなくて、

「この画面でこのボタンを押すとこのパラメータが飛んでこっちの画面に行く」
「こっちの画面ではパラメータでこれを受け取るから、これをキーに検索してこの画面の情報を出して……」

というように、まず画面間の繋がりを把握出来ていなければ作成出来ないでしょ。
別チームの方はこれが無い。

50歳過ぎの人がやってるんだけど、Ｗｅｂシステムの設計は経験が無いらしくて感覚掴めてないのよ。
だから、

(´・ω・`)「ここに戻るボタンがありますよね？」
(-_-)「ありますね」
(´・ω・`)「クリックするとどうなるんですか？」
(-_-)「前の画面に戻ります」
(´・ω・`)「前の画面ってどの画面ですか？」
(-_-)「さあ……」

って、戻るボタン押した時に戻る先の画面が分からんヤツが画面設計なんか出来るわけ無いだろ！！

答えは、そもそもその画面はトップ画面だから戻り先なんて無い。

トップ画面に戻るボタンが必要無いことが分からんヤツに画面設計なんか出来るわけ無いだろ！！

これはこの担当者がダメと言うより、チーム全体がこの水準なのよ。未経験者集団。
こんな調子で全三ヶ月の工程の二週間が過ぎ去ろうとしている……。


これ、絶対設計書の品質ガタガタと言うか、そもそも設計が成り立ってない設計書が出来上がるぞ。


・ウズマスチーム：設計書の記述が荒っぽいのを統制する為に奮闘中。
・別チーム：設計が成り立っていない。


これ、次元が全然違うからね！！

マジやばい……。

プレイングマネージャー

プロジェクトメンバー10人！！
これは忙しいな！！
しかも炎上寸前！！

まず僕の経歴というかファイティングスタイルはプレイングマネージャーだから、
自分自身が第一のプログラマーであり、平行してプロジェクトのマネージメントも行うというもの。

大体、自分を含めて4人くらいのプロジェクトをこのスタイルで行ってきたが……、
プロジェクトメンバー10人でこれはキツいわ！！

10人という数は管理専門マネージャーを置かなければいけない規模だ……。

とは言え今更マネージャーを追加するのは無い。そんな時期はとっくに過ぎ去っている。
だから僕が個人作業を減らしてマネージメントに注力するようスタイルを変更しなければいけないのだが、
でも今やってる設計は僕の脳内にしか無いんだから僕以外には無理ぽ。(´・ω・`)

技術的に無理なもんは無理なんだから僕がやらねばならん。
oh、キツス……。(´・ω・`)

これはマネージメントの方を外部化しなきゃイカンな。
サブリーダー3人もプレイングマネージャー状態だから混乱しているが、この3人ともっと意識合わせしてマネージャー寄りにしよう。

意識合わせのポイントは妥協だな。

この現場のメンバーは真面目だから、放置するとコストを度外視して品質重視になる。
そりゃ品質重視と言えば耳障りはいいけど、その結果納期にも間に合わず赤字になっては意味が無い。
っていうか、このままだと絶対納期に間に合わなくなってゴリ押しでスピードアップし、「前半は高品質だったけど後半はクソだね」ということになる。

ボーダーラインを決めて、トータルで均等な中品質を目指さなければ。
合計品質がＭＡＸになるのは「多少妥協してトータル中品質作戦」しか無い。

綺麗事ばっか言っていたらプロジェクトの状況は悪化する。

「完璧を目指すな！！」
「コストに見合った品質で妥協しろ！！」
「本当に高品質でなければヤバい部分と、手を抜いてもどうにかなる部分の違いを見分けろ！！」

これしか無え！！

で、この方針がバレると現実を理解しない完璧主義者が文句言ってくるから、口裏合わせも徹底しなければ。


「完璧ではありませんが、総合的に最も高品質となる水準を狙って進行しています！！」


これだな。
これを堂々と言えない弱気なマネージャーは必ずどこかで右往左往して最終的に「総合的な低品質」の結果を招く。
強気で行かねばならん。

いよいよ正念場だな！！(；´・ω・`)

土日有効活用

土日両方とも、13：00～16：00の間で昼寝しちまったぜ。

夜はニンニクを効かせた肉料理と強い酒で火力補給。

これで体調は完璧や。(´・ω・`)

大所帯

うぽぽ……。

今日から10人チームとなったが、やはりこの規模は認識合わせに時間を要する。

何とか初動段階で作業粒度を統率しなければ……。