開発のための仕様を曖昧にせず、明確に、具体的に提示する秘訣
Webサービスやアプリの開発を進める際、仕様書が不可欠な要素になります。簡単にいうと、「仕様書」はWebサービスやアプリを作るうえで開発者の説明書になるもの。言い換えれば、仕様書は「どこにどのような機能を持たせるのか」「どこからどのように遷移させるのか」といったプロダクトのあるべき姿を記載したもの。
開発はスケジュール通りに進むように、明確でしっかりした仕様書を提示することが重要です。
開発はスケジュール通りに進むように、明確でしっかりした仕様書を提示することが重要です。
簡潔でわかりやすい仕様書は以下のように特徴を持っています。
- イメージ画像が入っていること
- 画面遷移図がしっかりしていてわかりやすいこと
- シーケンス図が用意されていること
- 細かな部分についても説明がある
この取り組みは、「鉄則:バグを作り込まないで最初から正しく実装する」ことを狙ったものです。
開発の初期段階で、発注元を交えて合同レビューする秘訣
念を入れて仕様書を作成しても、言語の違い、慣習や商習慣の違いから、発注元の意図を正確に伝えられていないことも想定しておく必要があります。これに対処するため、発注元を交えて早期にレビューすることが有効です。
このレビューは、早い段階で行うことがポイントです。受注側の設計書がまだ作成の途中でも、とにかく早めにレビューしましょう。
早期にレビューする狙いは、いわゆる「ボタンのかけ違い」を早めに検出して軌道修正することです。最初に大きな認識違いがあったり、ソフトウェアのアーキテクチャに大きな考慮モレがあったりしたとしても、早期の段階であれば、手戻りは最小限で済みます。
両側の信頼関係を構築する秘訣
の業界でも、信頼関係は事業の成功に至るカギとなっています。オフショア開発も例外ではありません。特に、システム開発を発注するプロジェクトにおいては、言語違いなどの問題が生じる中で、発注先と受注先の関係は重要に位置付けられます。
開発するシステムは両側の共通するものなので、トラブルが発生する場合、発注先も受注先も最適なソリューションを提案し、同意にいたるのが必要です。
オフショア開発を導入する前、受注側企業は第三者機関に技術力を査定してもらい、公平な評価を受けることが重要です。第三者の評価に基づいて同社の強みや弱みを東芝に情報提供し、両社で共有している。そのうえで、両社の弱点を補い、長所を生かす取り組みをお互いで行うことができます。
Source: next-offshore.com
0 Comments
Post a Comment