システム開発のプロジェクトが成功するための事項や条件は
同じことをして必ず成功するとは限らないため（時と状況にも左右されるため）、
ピックアップして次に活用することは少し難しいですが、
失敗する事項や条件は、どのプロジェクトにおいても、
それらが多く一致すると失敗ことは確実になってきます。
よって、システム開発のプロジェクトが失敗しないための事項や条件を
心得集としてピックアップして、活用していきます。
（まだまだかき集め中なので、どんどん追加していきます）
■設計書、コーディングは担当者に依存させてはならない
記述方法がバラバラになると保守性が低下する。（後から統一したり、補正するのはかなり困難）
→開発者依存にならないように基準となる雛形を用意する。
■協力会社メンバーの選定にて、実績のない人（会社として契約するのは初めての人）は避ける
協力会社メンバーの人材で失敗するとフォロー含め無駄工数が多く発生する。（このケースをよく見る）
リーダ（メンバーコントロール）できる人か、圧倒的技術者をアサインする。
→コスト的にこれを確保できるとかなり有効
■コスト削減のためにプロジェクトメンバーのスキルを下げてはならない
スキル要員で単価の安い人や若手でコストを下げて収支を安定させても、品質低下による後からかかるコストリスクが高くなる。
→若手や協力会社のメンバーで、タスクコントロールできる人か、圧倒的技術者を確保できるとかなり有効
■できていないことやスケジュール遅れは隠してはならない
できてるとウソをついたりごまかすと後に必ずドツボにハマる。
（当たり前だが、このケースをよく見る）
→できていないことは正直に報告し、リスケをちゃんと行う。
（当たり前だが、これができていない場面をよく見る）
■品質の指標値を無視してはならない（品質報告は怠らない）
→指標値を意識せずにあとから乖離が発見されると工数が大きくかかる（言い訳など）
■DB項目はすべてNOTNULLにしておくのがベスト。
→難しい場合には必ずnullを考慮した設計＆コーディングを徹底する。
（JavaはすぐにnullpointerExceptionで処理がこける）
■eclipse等の統合開発ツールが保持するチェックツールの使用指針がある場合は無視しない。
→後から補正するのはかなり工数がかかる
■junitを使用する場合は、アサートとログを併用する。（DBunitも可能な限り使用する）
→環境バージョンアップ等での動確やデグレ検証時に工数的にかなり効果を発揮する。
■上流工程で業務バリエーションをマトリクス化できないプロジェクトは危ない
マトリクス化できないため、IT工程以降で炎上するプロジェクトがよくある。
→業務バリエーション（登録→異動→削除→復活 など）は必ず整理しておく必要がある。
■タスク・課題管理を複数個所で行ってはならない
複数のエクセルやチャットツール等で管理するとタスク・課題が埋もれてしまい、漏れが発生する。
→「WBS、課題管理、レビュー管理、周知事項、規約・決まり事、連絡など」をポータルサイトまたはエクセルにて一箇所での管理が必須となる。（チャットツールやメールは連絡のみで使用する）
■セッションを多用しない
→セッションを多用すると保持すべきタイミングや使用すべきタイミング等でバリエーションが必要以上に増えてしまうためバグの温床になる。また、ログへの出力は商用では現実的にでないためトラブル時の解析が困難になる。
◾️期間が少ないときは、まずやらないことを決める
→やると決めたことの品質を担保して、やらないと決めたこともやればこの品質でできることを客にアピールする。
■動くものがない状態で詳細設計しない
実装のイメージがないまま設計すると後で戻りが発生する。（このケースをよく見る）
→手元に動くものは早急に用意する。（上流にてプロジェクトにて使用するフレームワークが決定する時点ですぐに用意するのが望ましい
