が、何とか望ましい方向に落ちたぞ。(´・ω・`)
要件定義兼基本設計
元々の僕の構想としては以下であった。
- プロジェクト全域を請負案件とする。
- 契約を二つに分割し、前半を基本設計とモック作成のみとする。
- 後半で本格製造に着手する。
プロジェクトが要件不明瞭な状態で進んじまわないように基本設計段階でチェックポイントを設け、ここで止める作戦だ。
だが議論が色々紛糾して、転がり、まず一つがコレ。
- プロジェクト全域をＳＥＳ案件とする。
う～ん。
僕が全域を請負案件にしようとしたのは、プロジェクトのコストを固める為であった。
ＳＥＳだと際限無くコストを垂れ流してしまうリスクが残る。
しかし、次にコレ。
- 基本設計書のレビューを全員で行う。
- その時点で変な所があれば修正する。
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
よく言ってくれた。
- 去年前まで行っていた要件定義が何がなんやら分からんが、とりあえず基本設計書を作っちまう。
- 基本設計書のレビューは、コンサル、営業、技術者が全員同席の場で行う。
- そこで見落としとか別の意見が出たら、基本設計書を修正する。
これは要件定義フェーズ２に限りなく近い。
つまり、去年までやってた要件定義は、要件の大まかなヒアリングでしか無いという位置付けになり、
基本設計書レビューで決まるものが本当の確定要件になるのだ。
モックも必要な画面だけは注文に応じて作ってくれると言う。
これは要件の確度という意味ではかなり固いものだ。
何も文句は無い。１００％の賛同である。
それにしても、基本設計書のレビューは技術者が行うのではなく、コンサル、営業、技術者の三者合同レビュー会議で行うなんて、よくぞ言ってくれたな。
レビュー会議が恐ろしく遅延するぞ。
でもまあ、元々それくらいの工数は必要だからね。
無駄なことをするわけではない。
工数はさておき、これで全員集合のレビュー会議で不明瞭な部分があったら逐一全部確認すれば要件は完全に確定するから、要件の確定という僕の目的は達せられる。
要件定義フェーズ復活だ！！
もう一つ都合が良い点として、技術者側の責任が分散されることだな。
本来、設計書なんてものは、技術者がその責任を一身に背負うべきものなんだ。
だから僕はこれだけバトルしているわけだが、その責任を連名にしてくれるんだってさ。
これで何かあったとしても技術者は責任追及から逃れることが出来る。
これは美味しい。
で、基本設計書の執筆はＳＥＳの連中がやってくれるから、プロパーの技術者はそれが出て来るのを待って、レビュー会議で指摘するだけでＯＫ。
楽チンである。
これでみんな救われた。(´-人-`)
残る問題は会社の経営だな。
今日の決定によって社運を賭けたプロジェクトが序盤から遅延しまくるから、会社の経営基盤に大打撃を与えるだろう。
でも、それは元々失敗しているプロジェクトが早々に表面化するだけの話なんだ。
遅延が目に見えて顕在化した時、強引にでも先に進めるか、プロジェクトを一旦止めるか、苦しい決断を迫られることになる。
しかし、それは経営者の仕事だな。
僕の仕事は「不明瞭な要件定義を許さない」という点で完全に完遂し、経営者に早期撤退するタイミングを提供することに成功した。
最大限の働きをしたと思う。
とまあ、これだけ頑張ったんだけど、僕の頑張りを分かってくれる人は恐らく少ないだろう。
耳障りの悪いことを言う人間が煙たがられ、イエスマンが優遇されるのは世の常。
人生なんてそんなもんだからしゃーないか。(´・ω・`)
でも、僕はこんなことには甘んじず、
早く真実の幸福を手に入れねばならんな。(´・ω・`)
0 件のコメント:
コメントを投稿