【上級】失敗プロジェクトの共通項 最終回
【上級】失敗プロジェクトの共通項 最終回 【性能要件不明確】 “当たり前性能”を算出し，プロトタイプで体感させる ユーザー企業から特に性能要求がなく，性能条件の取り交わしを行わずに，性能について自主目標で開発してしまうと，納入後に品質問題が発覚し，基本設計に遡って開発の大幅な修正を要することになる。情報システム部がしっかりしていればこのようなことはあまりない。しかし，想定プロジェクトのように情報システム部が弱かったり，利用部門から直接口頭で受けたりするケースは増えている。 「これくらいの性能は当たり前」とユーザー側が無意識に考えていることがある。無意識に考えていることは，開発サイドには伝わりにくい。ベンダー側も要求仕様に書かれていること以上の実装は行わない。ユーザーが考える「当たり前性能」を引き出し，要求仕様の“抜け”を開発前に埋めておく必要がある。 プロトタイプで体感してもらう 当たり前
【上級】失敗プロジェクトの共通項
最近，特に目立つのが見積もりミスによる開発コスト/期間オーバーである。受注優先の考えから営業部門の判断で，無理な価格，納期，不利な条件で受注，契約されやすい。結果として納期に間に合わず，稼働後のトラブルも多く発生する。 見積もり審査会を設置する 見積もりミスは，マネージャの努力ではどうにもならないことが多い。全社的な取り組みが不可欠だ。見積もりミスが起きる最大の理由は，営業部門の独断を許す体制である。これを回避するには，社内体制の整備と，その運用にかかっている。 社内の体制としては，見積もり審査会を設置するのが望ましい。プロジェクトが大規模になるほど，リスクの範囲が拡大，多様化するため，個人や担当組織のみでは判断しきれないからだ。担当者からの見積もり提示や安易な概算見積もりの提示をなくすのが，最優先である。 見積もり審査会のメンバーは，理想的には以下の5つの部門で構成する。 (1)プロジェ
【上級】失敗プロジェクトの共通項 第5回
想定プロジェクトでは，多くのサーバーやミドルウエアが使われる。OS，Web/APサーバー，データベース，負荷分散装置などだ。プロジェクト内にこれらの製品のうちひとつでも利用経験者がいなければ，スケジュールは見直しを迫られる可能性が高い。使用方法を取得するのに多くの時間を要するからだ。多くの残業，休日出勤を招くことになり，納期にも影響を及ぼす。 スキルマップの整備が不可欠 プロジェクトと技術者をうまくマッチングするには，社内での分野別スキル保有者リストが欲しい。スキル保有者がいなければ，社内からの協力を仰ぐといった運用が可能になる。 スキル評価の方法は，一般的には大分類から小分類へツリー構造で細分化していくのが使いやすい（図7）。 大分類としては「技術」「業務知識」「マネジメント」の3つが標準。技術なら「ハード」「ネットワーク」「OS」「開発言語」など中分類に分け，さらに開発言語なら「Jav
【上級】失敗プロジェクトの共通項 第4回
【上級】失敗プロジェクトの共通項 第4回 【協力会社のソフト品質不良】 目標，役割，スケジュールを共有し，中間確認も怠らない 開発丸投げは，それ自体が大きなリスクである。協力会社がシステムの品質を損なうケースが頻発している。 品質とは，安定稼働だけを指すわけではない。品質の6特性を漏れなく満たす必要がある。6特性とは，機能性，信頼性，使用性，効率性，保守性，移植性を指す＊7。プロジェクトをトラブルなく遂行するという観点に立つと，特に性能確保，負荷対策，イレギュラーな仕様の品質目標を定量的に明示することが重要である。 想定プロジェクトのケースでは協力会社への発注比率が開発全体の50％と高い。マネージャがユーザー対応や社内の開発管理に追われて，協力会社の管理を怠ると，受入検査時に多くの障害や仕様の食い違いが表面化するリスクがある。 1社ですべての開発を請け負うのが困難な今，外注先のソフト品質マ
【上級】失敗プロジェクトの共通項 第3回
【上級】失敗プロジェクトの共通項 第3回 【ユーザーとのコミュニケーション不足】 進ちょく報告は最低限，業界の知識も必要 最近増えてきた短期開発の弊害が顕著に出やすいのが，コミュニケーション不足である。仕様凍結後にユーザーとの打ち合わせを全く行わないケースもあると聞く。特に恐いのは，ベンダー側の業種/業務知識の不足に起因する思い込みや勘違いで，間違った機能を実装してしまうケースがある。 運輸会社の業務システムは，協力関係にある業者間でデータ交換の標準化が進んでいる。その辺りの事情に疎いままだと，必要な機能と開発した機能にズレが出てしまうリスクがある。場合によっては，無償で修正せざるを得ないだろう。 業界知識の習得は必須 コミュニケーション不足を引き起こす要因は大きく3点ある。 第1に，メールやFAXなどに頼りすぎるのは危険だ。ベンダーは，利用部門や情報システム部門の責任者を含むユーザーとの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
