炎上プロジェクト プロジェクト

・PM、PMOの不在
・正確な現状把握をPMがしていなかった。
・そもそも見積もりが甘すぎた
・現場要員間で不満多すぎ、文句多すぎ
・設計からPGへの移行判定会議をしなかった　条件をみたしてないならPGフェーズに入るべきでなかった
・社内プロジェクト（時間にルーズ）と、ウォーターフォール型での外注（時間かかけるとお金が発生しちゃう）の
異なる２つのプロジェクト管理をいっしょにしちゃった
・API設計がまずかった。繰り返し箇所以外は同一の深さにすべき
・DBの構造をAPIに反映すべきでなかった（DB変更あるたびにAPI変更発生しちゃう）
・DB設計がまずかった。不要なTBL多すぎ
・DB設計書を作成すべきだった。つくらないとねではなくて、いつまでに？と具体日程におとしこんですべき
・参照制約前提はよくない
・上位レイヤーの仕事で変更があればあるほど、下のレイヤーがあれる
・業務システムでどうせ長く使う（５，６年は使う）のでＤＢ設計書などちゃんとしてから次にすすむべきだった
・設計書がないので問い合わせが多数発生しすぎ。その対応に追われて仕事にならない。
・スケジュールあいまいなのは、融通はきしのではなく、自分を守るため
・アジャイルは、設計者のスキルが高いのが前提。低いと荒れる
・設計者のスキルが低いとＰＧ工程地獄
・保守工程で仕事あげるから、pg工程単価低くしてというのは飲んではいけない。
ブラック現場の場合がある。
・人が増えれば増えるほど、問い合わせが多く発生する。その分のコストを考慮する必要ある
環境つくらないといかんしね
・スケジュールがタイトだと、他人におしつけるようになる。
・モックアップを作成しそれをベースに進行すべきだった。sampleじゃなくて、１つの機能としてね（ちゃんとつかう、search insert update delete）
・設計フェーズが、基本設計、詳細設計に分けられていなかった。設計フェーズ終了してるのに内容としてDB設計すら終わってない状態
・core側/wrap側と分ける必要なかった。手間増えただけ
・SQL文を１箇所でなく、複数個所で少しつづくみたてて非常にわかりづらい
・デザインチームに人増やしすぎ。増やすほどスケジュール伸ばせなくなり自ら首をしめた形。あとタイミングもあかん。