オフショアリング完全ガイド の商品レビュー
- ネタバレ
※このレビューにはネタバレを含みます
10年ほど前に中国インドなどへソフト開発を発注するオフショアリングがはやったが、それについてのLessons Learnedが書かれている本。日本側の視点だけでなく、発注先企業から見た視点も含めチェックポイントなどが含まれていて非常に参考になる。私自身も現在オフショアリングのプロジェクトのPMとしてはじめての経験をしており、いくつもの壁を経験したが、最初にこの本をよんでおけばよかったと思う。オフショア開発で発生する失敗事例には国内で発生しても同様に起こる失敗が含まれており、問題が顕著に表面化してしまう点と対策が予想以上に困難になる。特に以下のポイントは印象に残った。 ・ローカルなプロセス：発注元である日本企業は開発プロセスの定義の必要性、重要性に気付いていない（例：単体テストの実施内容について内容や記録方法が期待と異なっていた） ・日本独特の商習慣：「発注先は融通を利かせるもの」という先入観が日本企業にはあり、無理なスケジュールを強要したり、人海戦術で期限を守るよう要請したりする ・日本型開発：徐々に仕様を詰めていくという日本型開発により、要求定義確定が遅れたり仕様変更が多発する ・チームワークについても日本では技術や知識はチームで共有するものと考えがちで再発防止策の横展開など期待するが、発注先はそこまで細かい品質意識がない ・コミュニケーション下手：発注元の日本語の仕様書では主語が省略されていたり、依頼をする際に理由を記述しなかったり、業界用語を常識のように使用する等、相手への配慮が足りない 契約時の注意点 ・SOWで成果物にはプログラムだけでなく仕様書、レビュー記録、バグ票、品質・生産性データ等必要なものはすべて含める ・評価の尺度を設定する ・スケジュールが変わるかもしれない場合、余裕をも焦るだけでなく柔軟性を許容するような明記（30日前の通告で変更可能など） ・仕様変更のプロセス ・価格付け方法を明確化：海外ソフト会社は単金契約を好む傾向にある（ｖｓ総額） ・作業基準・手順 ・追加費用なしのバグ修正についての海外ソフト会社の責任の定義 ・技術者に対する要求事項 ・契約終了：予定外の契約終了時における両者の権利保護 実施中の対応 ・現地でのキックオフ（プロジェクトメンバーひとりひとりが発注者の顔と人柄を知っているのとそうでないのとではその後のモチベーションが違う！） ・開発内容の説明 最初にブリッジSEに説明しただけで任せているとその後のQAが多くなって遅れたり、品質が落ちたりする。相手から理解のフィードバックをもらうのも有用。 ・ドキュメントを正確かつわかりやすく 背景目的の説明、業務知識も可能な限り説明、環境は正確なバージョンまで記述、要求性能の定量化、未決定事項の記述、要求項目にIDを付与、日本語の文章は5WIHを明確にし文法を正しくする（翻訳ソフトにかけてみるとわかる） ・品質管理 ー品質の定義と可視化：テスト項目数の定義、バグ数の定義も含めて定義する（例：仕様項目1件、あるいは一行につきテスト項目を1件以上作成する） ー技術指導：結果を記録する帳票を提出、工程ごとに成果物を必ず1度は目を通す、ノウハウ共有化の指導 －影響範囲を制限したりするためのソフトウェアアーキテクチャの工夫、品質を独立して検証できる仕組みのプログラム組み込み、フレームワークの利用 ・リスク管理表 ・異文化の壁を乗り越える －相手国の祝祭日カレンダーの確認（文化の尊重）
Posted by
- 1