Q&A
そもそも「プロジェクトの成功」を定量的に評価する仕組みは整っているのでしょうか。「要件次第」「プロジェクト次第」なところが大きく、他者がどうこう言えないのでは？
ご挨拶
毎度お世話になっております。
また困った客に直面しています。皆様方のお知恵を拝借したく、質問を挙げさせていただきます。
本文の構成は以下の通りです
- 質問 1
- 質問 2
- 質問の背景
- 質問 2 について自分が把握していること
以下本文です
質問 1.
基本設計までデータベース設計ノータッチのプロジェクトに成功の見込みはあるか？
質問 2.
見込みがない場合、無謀なプロジェクトを推し進める顧客を説得するための著書はあるか？
質問の背景
最近参画したプロジェクトはある業務用アプリケーションの大規模改修案件です。画面総数であれば 100 を超えます。
このプロジェクトはデータベース設計を一切せず基本設計完了を宣言してしまいました。自分が参画する半月前のことです。
現バージョンの設計書なし、ER 図なし、CRUD 図なし ... かなり絶望的な状態だと判断しています。
基本設計フェーズでの成果物は、どんな画面を作るのかというイメージのみです。画像の Image です、処理の内容に踏み込んだ「イメージ」ではありません。
このプロジェクトを管理している顧客にリスケを促したいと考えています。もう一度詳細設計フェーズへ移行する前に、せめて CRUD 図くらいは書こうよと言いたいのです。
ただし、ここまでの進捗を顧客に見直させるにあたって、「データベース設計をしていないのは致命的なミスですよ」と主張するための根拠をできれば紙の本に依拠したいです。
※ 相手がおそらく COBOL おじさん ( 悪い見本の方 / 真っ当な COBOL おじ様方本当に申し訳ございません ) である為。
質問 2 について
アートオブプロジェクトマネジメントや SQL アンチパターンは読みましたが、これらの本はウォーターフォールの各フェーズにフォーカスを当てているものではないため、質問 2 の解決策にはならなそうだと考えています。
2021/5/2 19:40 補足 : 成功条件について
上記「成功」とはイージーに「ユーザー企業との契約時点での見積もり工期で、契約した通りの機能を提供できる事」という意味合いで述べました。
採算やその後の他ユーザー企業への展開などは話の内容が発散してしまうため伏せさせてください。
ちなみに「成功したかどうか」は終わった後の評価なので。
パッと見、限りなく危険な感じがしますが、基本設計含む各工程の取り方によるのでは。それぞれの成果物の決めも無い気がします。しかし次がいきなり「製造」となったら作れるはずがありませんね。データの無いUIで使い勝手っぽいところの確認程度で、DBの設計を始めたら手戻りが多そうです。実際に作るにあたって足りない設計部分(TODO)をあげつらうことが定量化へのひとつの方法だと思いますが、まぁ、それも各人の経験からくる勘でしかなく、何らかの論拠を求めてのご質問なのだと思いますが。
設計の段階からきちんと正しい知見を持った人間が介入しなければダメに決まっています。
決定権を持っていて、設計、開発のノウハウを持っている人間が客と直接やり取りしなければ、どんどん失敗する確率が上がります。
現実的には何も知らない営業が客とやり取りして間接的に開発側が意見を伝えるだけといったケースも散見されるわけですが....。
よくわかってないので、勝手な印象でコメントします。
致命的なミスというと許容出来ない人も居るんじゃないかなと思ったりしました。
相手の非や問題を認めさせるのではなく、ただ単にこれから必要な工程を挙げてその工数を飲んでもらえばいいのではないでしょうか。
とりあえずDB設計の見直しが必要なのだから、その分の工数（戻り工数も含めて）、どの程度かよくわかりませんが、乗っければいいだけの話じゃないのですか？
回答3件
0
自己解決
同様の状況に直面した人達のため、その後の顛末を記します
自分は基本設計からやり直しました
改修のベースとなるソースコードを入手できたため、それらを全て読み込み
- どの機能がどのテーブル・どの列を参照・更新しているかリストアップ
- 時系列順に使用する画面を並び替える
- 業務パターン分岐発生分だけリストに幅を持たせる
- どの業務でどのテーブル・どの列が参照・更新されているか、時系列順にまとめた資料とする
- CRUD 図作成
ここまでを改修ベース資料とします
次に改修後イメージの基本設計を作成します
- 上記の 4 に対し、改修で追加される参照・更新を付記、改修後トータルで全業務パターン + 参照・更新対象をまとめた資料とする
ここから先はいつものウォーターフォールと同じです
自分は脳筋なので、基礎でゴリ押すしか闘い方を知りません
自分が担当した部分は無事終わりました。契約満了後の不具合連絡も今のところありません
ただし、何年かぶりに残業時間が80時間を超えました
投稿2021/10/19 12:12
総合スコア7
結局リスケしたんですか？
したのなら、どのような調整をしました？
質問した内容の観点について、どのような経緯を経て解決した方法に決着したかがあると、より役立つと思います。
0
15年以上前に大手ソフトウェア会社でOracle Database で正規化を無視したテーブル設計(テーブル設計はされていたが)が原因でどんどん開発が遅れて、その会社の優秀なメンバーが毎週のように追加投入されて、その誰もが正規化がひどいので正規化からやり直すように提案するが、システムの責任者が何ヶ月も前に抜けたメンバーが設計したテーブルを少しでも変更することを拒否し、破綻したのを思い出す。
3日間会社に泊まり込んで動的SQLを駆使してパフォーマンスが悪いとわかっているコードを書いたけど、使い物にならないのはわかりきっていた。
最後は社長命令でプロジェクトは中止。
プロジェクトを再開する際は必ずまた開発メンバーに呼ぶからと言われたが、声はかからず。笑い
投稿2021/05/02 08:03
総合スコア16417
0
相手がおそらく COBOL おじさんである為。
ならファイルレイアウト位は定義しているんじゃないですか？
それをRDBに落とし込む時間が必要とかで調整してみては？
「データベース設計をしていないのは致命的なミスですよ」と主張するための根拠をできれば紙の本に依拠したいです。
概ねそういった場合は正規化されていない事が多いので、該当する場合は正規化の必要性を訴えれば良いと思います。
その際、開発側ではなく先方の目線での訴えになるように心掛けが必要です。
開発側が困るような事は先方にとって良く分からない事になりがちで、響かない恐れがありますので。
尚、納得する理由があればリスケによるコストの追加を提供してくれる先方であれば、という前提ですが。
投稿2021/05/02 03:35
編集2021/05/02 04:34総合スコア25327
本件のシステムは 10 年以上前の初回リリース時点から VB.net で開発されたものです。
COBOL でのファイルレイアウト相当のものは当該システムの歴史には出てきていないと考えています。
我々の開発チームをまとめているキーマンが KKD で仕事をしてそうな人であり、それを COBOL おじさんと例えました。あまり良くない表現でしたね。お騒がせしました。
> 本件のシステムは 10 年以上前の初回リリース時点から VB.net で開発されたものです。
良く分かりませんが、UIのデザインだけして、テーブルの見直しがされていないという事ですか？
> UIのデザインだけして、テーブルの見直しがされていないという事ですか？
その通りでございます
なんだか響かない返ししかされないので、漠然と思っているだけとの印象しか持てません。
プロジェクトの火消しは幾度となく行ってきた経験から言える事は、課題を提起した人が取り組むのが手っ取り早いですから、頑張ってみて下さい。
あれこれ考えるだけより、そのキーマンにアクションする事です。
あなたの回答
tips
プレビュー
