 |
|
|
| 前のページ 1 2 3 次のページ
|
|
| 「案件見積もり」フェーズの注意点
|
このフェーズにおいて、以下のような注意点があげられます。
- 見積もりを行う場合に、完全な案件情報を頂けることは稀と考えましょう
- お客様側が行わなければいけない作業と制約条件についても考えましょう
- できるだけ、機能単位（画面、帳票、バッチなど）に、落とし込んだ形で見積もりを作成しましょう
- 決定事項、未決定事項や、不明点など、常に両者が認識できるよう書面に残しましょう
表2：「案件見積もり」フェーズの注意点
我々と同様、お客様側もビジネスを行っているので、お客様側の担当者もシステムに関する予算枠や担当者の上長への折衝、内部検討会議のスケジューリングなど様々な業務に忙殺されています。時間や余裕がないことは珍しくなく、完全なRFPを頂けることは稀です。
案件の業務知識と実現したい内容についてはお客様が「プロ」ですが、システム化についてはプロジェクトマネージャー（以下、PM）や、プロジェクトリーダー（以下、PL）が「プロ」になります。見積もり段階といえども曖昧模糊としたRFP要件に対して、ある程度のシステム化提案を行うことができれば、お客様に信頼して頂けることが多いと感じておられる方もいらっしゃるかと思います。
これに加えて、システム化提案が機能ごとに具体化してあり、なおかつ前提条件をつけてあると仮定しましょう。すると、万一お客様と営業、PM、PLの間にRFPの内容などの相互理解に齟齬があり、要件定義時以降のフェーズで案件にあわない見積もりであることが発覚したとしても、基本設計後の再見積もりなどプロジェクト体制を見直す方向へと話を繋げていくことも無理のある話ではありません。
「だいたいこのような機能を実現して欲しい」に対して、前提条件も無く、見積もり根拠とした内容提示を行わない概算見積もりを提出してしまうと、なし崩し的に開発着手となり、多方面から「こんなはずではなかった」との声があがってくる結果にもなり兼ねません。
最終的にお客様に満足して頂くためにも、見積もり前提条件などの条項を加え、決定していない事項や、不明な点については、常に明らかにし、別途打合せを設けるなどの管理を行う必要があります。
|
| 「案件見積もり」フェーズでの管理手法
|
「案件見積もり」フェーズでは管理ツールよりも「管理手法」の比重が高くなります。用いられる管理手法としては以下のようなものがあります。
- KKD法
- FP法
- COCOMO2
- 機能一覧法（積み上げ式）
- LOC式
表3：「案件見積もり」フェーズで使われる見積もり手法の例
|
| 「要件定義、ヒアリング」と「基本設計」フェーズ
|
誌面の都合上一緒に解説しますが、この「要件定義、ヒアリング」と「基本設計」は、「お客様の業務要件を正しくヒアリングし、最適な課題解決ソリューションを提案」する土台となるフェーズです。
これは見積もりと同等かそれ以上に大事なフェーズであり、ここで正しく相互理解を獲得できなければ、お客様満足度や瑕疵対応、追加案件の切り分けなど、後々のフェーズに大きな影響が出ます。
|
| 「要件定義、ヒアリング」と「基本設計」フェーズの注意点
|
「要件定義、ヒアリング」と「基本設計」フェーズにおいては、以下のような注意点があげられます。
- 体制図を作成するなどの対応にて、お客様と開発側のステークホルダーの整理と担当者（連絡窓口）、責任者、決済権限者を明確にしましょう
- 成果物内容や、責任範囲の切り分けを明確にしましょう。一般的には、「要件定義」後に提出する「要件定義書」、基本設計フェーズ後に提出する「基本設計書」が正式な成果物とされることが多く、責任範囲については、それらの書類内部に記載されることがあります
- 協力会社とも開発契約を結ぶ場合もお客様相手と同様に、RFPや成果物内容、責任範囲の切り分けを明確にしましょう
- お客様との打合せにおいて、本質的な課題を特定し、システムとして最適なソリューションを提案するように心掛けましょう。お客様が想定したRFP上のソリューションと対応策が異なる場合であっても、提案・折衝することで、よりよい解決策に繋がることも多くあります
- お客様に理解して頂きシステム化の最終イメージを共有することが重要な要素なので、成果物を一覧できるように、A3で印刷して協議するなど、細かい配慮も役に立つ事があります
表4：「要件定義、ヒアリング」と「基本設計」フェーズの注意点
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
株式会社システムインテグレータ 安治 理之
物流、顧客管理、生産管理、販売予測、etc対応などの個別システム案件開発から、EC（電子商取引）、LMS（学習管理）、ERPなどのパッケージカスタマイズ開発まで、お客様ごとに異なる案件に対応し続けて幾年月。よりよいオーバーホール手法を求めつつ、現在もフルスクラッチ型案件開発を中心に、稼働を続けるシステムエンジニア。
|
|
|
|
|
|
