システムを「外注」するときに読む本 細川義洋

ベンダーを使ってシステムを開発したことが無いと、何をすれば良いのか、何をしなければいけないのか全くわからない。

普通、物を買う時、何をすればいいかは売る側が手とり足とり教えてくれる。

家を買う時だって、そんなに買う方が積極的に関与しなくてもいい。

もちろんしたほうが良いんだけど、しなくても家は完成する。

システム開発で怖いのは、買う側が積極的に関与しないと、自分が欲しいものを手に入れられないばかりか、そもそも商品が納品されないにも関わらず費用を請求されて終わる場合もある。

この本は、しょーもないストーリー展開に沿って、システム外注にまつわる主なトラブルを紹介し、その傾向と対策を教えてくれる本。

この本があってもシステム外注をしっかり乗り切れるとは思えないが、少なくとも取っ掛かりとして何に気をつければ良いか、気付きを得ることができる。

第一章 システム作りは業務フロー図から

As-IsとTo-Beの2つの業務フローが必要。
業務フローの段階でシステム化する範囲を決めない。
システム化するのは効果が明確に説明できるところだけ

第二章 発注者がこれだけは知っておくべき最低限のこと

発注者側に責任があってプロジェクトが中断した場合は、たとえ仕事が完成していなくても、
ベンダは作業をした分の請求ができる。
要件定義で最低限確認すべきチェックリスト
1.要件は必要かつ十分であるか
2.要件は十分に詳細化されているか
3.業務の例外や異常を考慮しているか
4.要件が正しく管理されているか
5.体裁・文言
メンバーに「役割、責任、権限、知識」がそろっているか?

第三章 失敗しないベンダの選び方

リスク管理をしてくれるベンダが良いベンダ。
システム開発請負の見積もりでプロジェクト管理工数が5%を下回っていたら、どこかに抜けがある。
ベンダが何の提案も見積もりも出さずに、結果プロジェクトが失敗した場合、損害賠償の対象になる。
逆に発注者側にも、ベンダが提示する変更計画や追加見積もりを受け取って話を聞く度量が必要。
ベンダが自分達の内部で解決すべき問題については、発注者に明かさずに抱え込むケースが多い。

第四章 社内の協力を得るために

システム担当者は、往々にしてエンドユーザーの協力が得られずに孤立する
システム開発の意義や目的について、経営トップからのメッセージングを繰り返す
システム開発も本業である

第五章 リスク管理で大切なこと

技術的な中心を失ったプロジェクトは、いくらその他のエンジニアやプロジェクトマネージャーが努力したところで、成功へ導くのは難しい
ベンダのリスクもユーザと共有すべき
定量的なプロジェクト状況やスキル評価、工数の妥当性のほか、
プロジェクトに合わせて設計した評価軸でベンダのリスクを評価する

第六章 ベンダとの適切な役割分担

ベンダが勝手に作業を進めた段階ですぐやめるように言うか、やらせるなら「手戻り時の費用は払えない」と明言すべき
モヤモヤが消えるまで質問や注文を繰り返す
パッケージコストのメリット:コスト削減、品質確保、他社のいいやり方の吸収

第七章 情報漏えいを起こしてしまったら

機密性の高さと漏洩したときの影響の大きさから分類し、対応方針をきめておく
システム運用はつまらない。モチベーション維持のために、その後のキャリアパスも用意すべき。

スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク