• 2016年9月13日火曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2016-09-26T05:11:00-07:00&max-results=7&reverse-paginate=true

詳細設計フェーズ

請負案件で詳細設計フェーズが始まり、二週目……。
チーム作りに手応えを感じて、随分と稼働も安定してきた。(´・ω・`)

我がチームの布陣の特徴は明らか。
若手が激烈に多いところ。
総数8人のうち、半分以上が1~3年目や言語経験少で占められている。

「このメンバーでどう詳細設計すんじゃい!!」ってのがこのプロジェクトの課題だな。

僕の考えた作戦としては、まず詳細設計と言っても、

 ・機能分割
 ・設計思想
 ・デザインパターン

こういう抜本的な部分は詳細設計が始まる前から僕が考えて完了させておいた。
ここが腐ってると全体が壊滅するからここだけは僕が責任持って8月に土日返上でやった。ゲポァ。
メンバーに担当して貰うのは画面個別の詳細設計だ。

しかし画面個別の設計と言っても、

「オブジェクト指向って何?」
「ORマッピングって何?」
「リレーションって何?」
「oneToManyって何?」

みたいな感じだから詳細設計の基礎が成り立たねえ。。。
これはもう少しずつ勉強会しかないな。

まず僕にて

「こうやって書け! これで正しい!!」

と見本を置いた上で教えて、本人が分っているかどうかは別として設計作業は進行させる。
ただ本人は意味を理解しないまま見よう見まねで書いているから、全体的な雰囲気は合ってるけど、ちょっと中を見ると設計の辻褄が合ってないことが30秒で分かる。

そういう箇所を僕にてピックアップして、

「こういう風に間違っているドキュメントが散見されるのだが、これは……」

と毎日朝会でレクチャー。

これを繰り返すと、最初の一週間は間違いばっかりで超激務だったが、二週目に入った今週からは落ち着いてきた。

所謂「バグ収束曲線」に乗るようなイメージで混乱が収束してきた感触だ。

これなら何とかなりそうだな。
この「最初から完璧を目指さず、30点からのブラッシュアップ」戦術で今後も進行しようと思う。
  • 2016年8月28日日曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2016-09-26T05:11:00-07:00&max-results=7&reverse-paginate=true

土日自宅作業

最近は仕事が忙しくて、この土日は両方とも自宅での管理作業に長時間を費やしてしまった。(´・ω・`)

9月から新しく詳細設計フェーズが始まるんだけど、その準備がまだ充分ではないのよ。
準備段階で1の手落ちがあると、後続フェーズで10のマイナスになって戻ってくる。

今日サボったら明日2倍やれば良いだけで済む作業者との違いがココにあって、
リーダーは今、頑張るときに無理してでも頑張らなきゃいけないのが辛い。(´・ω・`)

しかしこの土日に頑張ったから、向こう2ヶ月はかなり安定するだろうな。
軌道に乗ったらちょっと休もう。(´・ω・`)
  • 2016年8月21日日曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2016-09-26T05:11:00-07:00&max-results=7&reverse-paginate=true

多忙

今月急がし過ぎ。
全く時間に余裕が無い。(;´・ω・`)
  • 2016年7月31日日曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2016-09-26T05:11:00-07:00&max-results=7&reverse-paginate=true

7月終了

遂に7月も終了。明日から8月か。(´・ω・`)

プロジェクトは余談を許さぬ状況……っていうか、やっぱり別チームの部分は低品質と言うか根っこの思想からして間違っていて休日出勤もしているような状況だが……。

とにかく、何とかギリギリで踏ん張っている感じだ。

及第点には到底及んでいるとは言えないが、客先にそんなことを判断する能力は無いし、何とか基本設計書の納品だけはゴリ押しで済ませられそう。

8月も頑張らねばならんな。
  • 2016年7月14日木曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2016-09-26T05:11:00-07:00&max-results=7&reverse-paginate=true

粛正

ついに問題の工数盗賊に粛正の波が襲いかかろうとしている。

まず、このプロジェクトの要員は約30人だ。それが以下4チームに別れている。

・管理
・インフラ
・アプリ1 ⇒ ウズマスチーム
・アプリ2 ⇒ 工数盗賊

1~2人ならいざしらず、全域の25%が機能しなかった打撃は大きい……。
マネージャーよりも更に上層の会社経営層より、この工数盗賊を粛正するよう命令が下ったようだ。

しかし、一応はSES契約で来て貰っているから契約上はこちら側に主体者としての責任がある。
そこを断罪する為に「工数盗賊の低生産性について客観的に記述した質問書を送る」という戦術を取る。


・アプリ2チームの生産性はアプリ1チームの生産性の半分以下である。
 アプリ1チームと比較し、生産性が大幅に低い理由は何か?
・アプリ2チームの単価はアプリ1チームの1.25倍である。
 アプリ1チームより高度な要員を擁しながら、アプリ1チームより生産性が低い理由は何か?
・客先からヒアリングした要件が設計書に記載されていない。
 設計欠落が多発する原因は何か?
・設計に合理性が無い。合理的な設計が出来ない原因は何か?
・上記のような状況に対し、チームリーダーより報告、相談が無い。
 チームリーダーが報告、相談を行わない理由は何か?
・上記の結果、アプリ2チームの成果は我々が期待した成果の半分にも満たず、予算は大幅に超過している。
 この現状に対し、アプリ2チームの要員を提案した所属会社はどのような認識を持っているのか?
・所属会社は上記問題を改善することが可能か?
 可能である場合、いつまでに、どのような手段を以て改善するのか?
  なお、所属会社は過去に一度「可能」と主張し、結果的に実現しなかった。
  再び実現しなかった場合はどのような責任を負う認識なのか?
 不可能である場合、不可能である理由は何か?


こんな感じの「質問」を送るわけだな。
そして戻ってきた時の言質をベースに粛正が始まる。

こりゃ厳しいな。(;´・ω・`)
  • 2016年7月13日水曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2016-09-26T05:11:00-07:00&max-results=7&reverse-paginate=true

スナップショット

ITリテラシの低い人間と要件定義していると、偶に凄く驚かされる話を聞くことがある。

今日、客先打ち合わせで聞いた話はこれだ。


「自分がシステムを操作中に裏で別の人間に操作されると知らない所でデータが変わってしまう」


なるほど、排他制御の話だな。
Webシステムではよく話題になる話だ。

Webシステムでは基本的に以下の挙動をする。

①対象データを画面に表示する。
②画面でデータを加工する。
③データを保存する。

この操作を複数の人間が同じデータに対して同時に行った場合、大抵は「③データ保存」は後勝ち。
つまり、先に保存した人の作業内容は後に保存した人の内容に上書き保存される。
従って先に保存した人の作業は無かったことにされてしまう。

この問題への対策が「排他制御」だ。
基本的に後に更新した人間が勝つということは変えられないから、同じデータを同時に触らないように何らかの制御を行うわけだ。
やり方は楽観ロック、排他ロックなどいくつかあるが、残念ながら既存システムにその機能は入っていない。
古いシステムだからな。
従って上記のような競合現象が起きる余地がある。


しかし、打ち合わせ中不思議だった……。
確かに競合が起きる可能性はあるけど、そんなに頻繁に起きるはずが無い。
基本的にその情報に触るのはその担当者だけなんだから。
現行システムに排他制御が入っていないのは需要が無いからでしょ?
何で今日打ち合わせしたこの人だけこんなに排他制御のことを気にするのか……。

長く打ち合わせして、ようやく言っていることが分かった。

この人、画面を何日間も開きっぱなしにしているんだ!!

まず最初に画面を開くでしょ。
そして保存ボタンを押すまではその開いた情報が守られていると思っている。
だからまず画面を開き、ちょっと作業して、その後で保存もしなければ画面も閉じない。
退社する時もPCをシャットダウンしないで画面を開きっぱなしのまま維持しておき、一日、二日、三日……。
そしてようやく保存ボタンを押すと、その三日間の間に別の人間が行った作業記録を自分が上書きしてしまう。

「三日間画面を開きっぱなしにしている間に知らない所で誰かがデータを加工していて、自分がそれを潰してしまったからだと怒られた!!」

これを問題視していたんだ!!
これなら確かに競合は起きるわ。

画面に表示されている情報は表示した瞬間のスナップショットに過ぎなくて、裏では色々な処理が動いている。
いつ誰かが更新するか分からないもの。

これは僕にとっちゃ常識だけど、この人にとっちゃそうじゃなかったんだ。

「Excelはファイルを閉じなければずっと自分に見えている情報が最新なのに、オンラインシステムは画面を閉じていないのに勝手に情報が古くなっている!!」

なるほどね、こういう考え方をするんだ。

カルチャーショック。
勉強になったわ。(;´・ω・`)
  • 2016年7月11日月曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2016-09-26T05:11:00-07:00&max-results=7&reverse-paginate=true

低スキル高コスト人材大量投入デスマ

プロジェクトがいよいよヤバくなってきたぜ……。
原因はいくつかあるけど、その一つが「低スキル高コスト人材」、つまり、使えないおじさん集団だな。

まず、この人達はSESで入っている。

「業務知識と経験が豊富」

という触れ込みだったけど、実際は業務知識も無いし頭のキレも無い。
ただ年老いただけの人材だった。

しかも歳取ってるからコストが高い。
平均年齢30歳未満のウズマスチームの1.25倍のコストを費やしているのに、
生産性はウズマスチームの0.5にも届いていない。

しかも人数が多い。

全17人のSES人数のうち、7人がこの「低スキル高コスト人材」で締められている。
全く採算性が取れん。(;´・ω・`)

これ、プロジェクトが長期だったら先月で切られているけど、基本設計の納期が8月末だから何が何でもそこまではこのメンバーで乗り切らなきゃいけないって事情があるんだよね。

そして7人という人数は多い。
7人も入れ替えるのは尋常ではない大手術になるでしょ?

また、この7人の老人集団は元々は5人だったのよ。
5人で進捗が遅れ始めたから2人増員して7人にしたところ、増員した分だけ効率が下がった。

増員によって増員人数以上に効率が悪化した。

増員が裏目。

これをやらかしやがった。


増員が裏目に出るってことはコストを丸々ドブに捨てたって意味だから最悪の展開だよ。

どれだけの赤字が出るんだ、このプロジェクト……。(;´・ω・`)