色々と失敗事例を見つつ、考えているのだけど。
失敗が殆どの所物語になってしまっていて、イマイチだよなあと思う。
例として
政府システム調達、失敗の本質 - 55億円無駄に、特許庁の失敗：ITpro
そして外野の暴論が様々な形で爆発する。
木村岳史の極言暴論！：ITpro
劇薬の類で、この言うことを聞いてもほぼ死ぬ。
大きなシステムの失敗で言われるのは、テンプレとして以下の通り。
- 情報不足
- その原因としての調査・分析不足
- その原因としての資料不足
- それら全ての結果としての要件定義フェーズの問題
経験としてシステムの成否を決めるのは、
- プロジェクトとして過大くらいに見て考えている場合。
- しっかり要件定義で顧客からの説明がある場合。
- 顧客が困難を理解している場合。
- 体制がしっかり整えられている（ほどに金がちゃんと出てくる）
これらがあればだいたい成功するし、なければ大抵どこかで躓き低空飛行しつつ失敗の方に行くことがある。
大きく失敗する場合には、大体ビジネス上も人間関係が破綻している。
これらはシステム開発一般で言える事。
パッケージ・サービス開発の場合は顧客がパッといない事もある分開発側に要件を考えられる人がいる、とか、あるし、開発手法によっては追加要件を五月雨に聞くことが出来たりするけど。
システム開発の流れに載った場合には、品質だとか納期だとかそれでも問題は出たりするけど、大したインパクトないからねえ。
もうひとついうと、ITIL等で想定されているのは「潤沢なお支払いや迅速な依頼がありかつ十分な準備期間がある事」が前提で、要は行間を読む工数とかも出てたりするんだが。
かつ、海外の場合にはその辺りの行間を読む人間を社員として登用する為、IT投資としてカウントされない部分が実は日本とは違う。
で、多分、この一般論の先にしか学びはないんだよなー。
人間関係の話に執着してしまうと、どうしても「今回はこんな人ではないから」みたいな人間観察がキーになってしまう。
実際の所そんな話をプロジェクト毎に記載しているかというと、そんな訳もない。
特に自分の会社でも説明していてモヤモヤするが、役割分担の所で、「誰が」アサインされるかは気にされるが、「何の役割がある」という所がテンプレ進行になりがちだし。
毎度思うが、分類と分析は違うのだよな。
：
：
なんとかならんものか。
