システム開発の納期遅延のリスクや原因は開発プロセスのあらゆる
ステージに存在します。
一般的に開発プロセスは以下の通りです。
１．要件定義
システムの目的ややるべき仕事を明確にしシステムイメージを確立
２．設計
プログラム化するための機能、論理、ＤＢ、インターフェースを定義
３．プログラム化／単体テスト
環境を整えコンピュータ言語でプログラムを製作とテスト
４．検査
正しく動くか機能、性能などをチェックする
まあこんな感じですか。
上流工程の間違いはそのまま下流まで影響し修復に時間がかかるのは
自明の理であり上流の間違いは極力無くすのが基本です。
では納期遅延のリスク要因をまずはこの工程に沿って思いつくまま
列記してみましょう。
要件定義編
・お客様とのヒアリング、打ち合わせの時間がなかなか持てない
またはよく変更になる
・会議の欠席者が多い、特にキーメンバー
・やるべきタスクが明確でなく責任の所在がはっきりしない
・エビデンスをつくらない
・どうともとれる表現が多い、あやふやなまま放置してある
・まだまだ時間がある、危機意識が希薄に陥る
・お客様との関係が気まずいまたは逆に馴れ合いの傾向
設計
・分担設計の場合、方式、基準を明確にしていない（画面など）
・全体を把握するキーマンが存在しない
・相互レビューの時間を持たない
・要件定義との照合を割愛する
・疑問点をメンバー共有する仕組みが無い
プログラム化
・単体テストをおろそかにする、検査エビデンスもとらない
・進捗報告を％で報告
・コーディング基準が存在しない
検査
・シナリオパターンが単純、あらゆるケースを想定しない
・第３者チームを編成せず、最悪はプログラム担当者が実施
・不具合修復とその確認のプロセスが明確化されてない
ほとんどあたり前の話ですが結構これに陥るケースが多いです。
これを避けるプロジェクト管理は大変重要になります。
次にお客様への対処の問題です。
仕様変更／仕様追加は必ず発生しますがその対処のまずさは致命的です。
・納期やお金の裏づけの無いまま全て無条件で受けるまたは全て断る
検討時間がもったいないのか極端なケースで対処しているのが多々
見受けられます。
受ければ納期やコスト増、受けなければ信頼関係にヒビがはいる。
会社としてプロマネとして腕の見せ所です。
システムはお客様のものですから要望通りに動かなければ意味がないので
いずれは対処しなければなりません。問題はその受け方です。
納期や追加費用の合理的な材料を準備して対処できれば良いのですが
決着を誤ると双方に大きな傷が残ります。
さらに遅延の理由として後で挙げても通用しません。
私が昔よく使った手が次です。
・恩を売る、恩を返してもらうのトレードオフ
それほど大勢に影響の無い仕様変更は快く引き受け、その代わり自分達
の不都合との交換条件に利用しました。
さらに綿密で頻繁な進捗報告とその裏づけ資料を要求するお客様の
存在も結構大変です。
管理者のみならずメンバー各位にも余分な作業が多く発生します。
結果として想定外の余分な工数が出てしまい納期遅延に至ります。
お客様よりは会社としての進捗報告ルールを定めてそれで納得して
もらうのが一番です。
ケースバイケースで進捗報告ルールが存在しない会社は納期遅延の要因に
なりかねません。
いずれにしてもお客様から自分達を信頼していただくことが
何よりも重要です。意思の疎通に戸惑う関係は情報の共有などの点で
納期遅延の要因になりえます。
最後に「人」です。これが最大の難物で納期遅延に直結します。
逆に素晴らしい技術者は上記で述べたリスク要因をことごとく回避
できます、
私的には４つの要素で「人の集合、プロジェクト」を分析します。
・やり抜こうとするモチベーション
・見合った技術力、
・納期に対する危機意識
・相互補完のチームワーク
詳しくは各アイテムいろんな具体的ケースがあります。
プロジェクト全体として満遍なくパーフェクトが理想ですがそれは
ありえません。
全体としてこの一つでも欠けるあるいは欠けた強烈な個人が存在すると
結果として納期遅延発生の要因になります。
