• 2018年12月28日金曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/2018/12/blog-post_28.html

大転換

ふい~。今日は納会だった。これで今年の仕事は終わりだ。

今年もよく労働したわい。(´・ω・`)

が、そんなことよりも、だ。
例の崩壊プロジェクトが救済されるかもしれんぞ!!


大縮小

何と、プロジェクトがモック作成のみに縮小される可能性が出てきた。

納会の最中、社長の機嫌が良かったからダメ元で言ってみたんだよね。


(´・ω・`)「社長。このプロジェクトって実際、先に画面モックだけ作るってことに変更出来ないっすかね。その後のことはそれから考えても良いと思うんですよ。って言うか実際、そっちの方がむしろ良い感じにやれるんですよね」
(゚Д゚)「おお!! ええよ、ええよ。計画作って~や」


ええんかい!!
いや、こんな提案は最初の最初にしているんだけど、その時はNGだったからもうプロジェクトを大崩壊させるしか無いって腹積もりだった。

しかし、ウチの社長って忘れっぽくて、数ヶ月経った今になってもう一回同じ事を言ったら今度は通った。

まあ、既に予算を随分とドブに捨ててしまっているが、この時点でも転換出来るならその方が遙かに良い。


従来のプロジェクト計画
  • 仕様は現行踏襲
  • 要件不明瞭
  • 大規模
  • 短納期

再考プロジェクト計画
  • とりあえずモックだけ作ってくれ!!


これならやりようがあるぞ!!

今までは画面モックも無ければサンプルイメージも無く、実装者が現行システムを見て仕様も推察し似たような雰囲気になるよう全部作ってくれとか、そんなレベルだった。

しかし、方向転換すれば、「とにかくモック、サンプルHTMLだけ作ってくれ」になる。
そのサンプルHTMLは実装者のセンスに丸投げすることになるが、サンプルHTMLだけなら後からアレがダメだ、これがダメだ、この機能も追加しろ、みたいな対応は可能だからね。
っていうか、それが要件定義だし!!

とにかく、とりあえず担当者のセンスと直感レベルで良いからサンプルHTMLを全部作る。
それが全部出来上がってきたら社長、営業、コンサル、その他全員掻き集めて、

  • ここのボタンを押すと何が起きるんだ?
  • このテーブルはどういう順番でソートされているんだ?
  • この数値ってどういう計算式で算出するものなんだ?
  • 日本語おかしくないか? こんな表記でエエんか?
  • そもそも機能が全部足りとるんか? 何か忘れておらんか?

と、一画面一画面、モックを見ながら寝掘り葉掘り全部確認するわけよ。
この作業は大地が腐り果てるまででも続ける。
「こんなことまで聞かなきゃ分からんのか!!」と怒鳴られたら「聞いても分からんくらいじゃわ、ボケ!!」と怒鳴り返し、とにかく全画面全項目がどうなっていて欲しいのかを確認する。
この作業は大地が腐り果てるまででも続ける。
これが要件定義だ。

ここまでやっても「知らなかった」「言うのを忘れていた」とかフザけた話が出てくるのが常だが、それはしゃーない。妥協だ。
妥協ではあるが、それでも最低限の及第点のシロモノは達成出来る。

  • 要件定義は完璧にならない限り、大地が腐り果てるまででも続けなければならない。
  • それだけやって、ようやく60点のシステムが出来上がる。

大規模システムってのはこういうものなんだ。
エンジニアはそういう哲学と言うか、プロジェクトの要所ってものを骨で分かっていなければならない。
それが分からんヤツを若手、ペーペー、三流プログラマーって言うんだ。

ともかく、これでチャンスが出てきたな。
新年が明けたら早速、大転換計画を立てて調整に入らねば。

まあ、計画と言ってもスコープを「モックを作るだけ!!」に縮小するって話だから、二時間もあれば資料を作り終わる程度の造作も無い話である。

問題は社長だな。
とにかく忘れっぽくて気分屋だから、年が明けたら気が変わっててスコープ縮小の話は無くなるかも。

しかし、ここで話が通らなかったら、もうこのプロジェクトはおしまい。一か八かでも良いからやるだけやってみて損は無かろう。

ちょっくらやってみるか。(´・ω・`)

0 件のコメント:

コメントを投稿

iOS系端末でコメント出来ない場合があります。
その場合はお手数ですが他の端末からコメント下さい。m(_ _)m