要件定義・外部設計

要件定義のポイント

お客さんが要件を把握しているとは限らない

お客さんが、すべての要件を知っていると考えてはいけない。
お客さんもすべてを把握しているとは限らないからであう。

また、お客さんの言葉は「ヒアリング結果」にすぎず、より様々な観点から分析して要件を確定させるべきである。

最終決定権を持つキーマンを把握する

プロジェクト責任者が、すべての権限を持っているとは限らない。
合意した内容が、本当の最終決定権を持つ人に覆されたりすると、時間のロスとなる場合もある。
事前に、最終決定権を持つキーマンがだれかを、把握すること。

ヒアリングの注意点

ユーザーから現行のシステムや業務についてのヒアリングをする際に気をつけること。
ユーザーがシステムのすべてを把握していると考えるのには無理がある。幾度となくシステムが回収され、ブラックボックス化しているケースが大半であるから。
あるべきモデルからシステム要件を導くだけでなく、現行業務や現行システムの調査を綿密に実施することが重要である。
現行調査は軽視されることがあるので気をつける必要がある。なぜなら、ブラックボックス化されたシステムの調査には多くのコストと時間が必要になるからである。

要件定義も請負契約にする場合の注意点

一般的には、要件定義は準委任契約を交わすのがよいとされています。
しかし、開発まで一括での請負契約にする場合は、以下のリスクヘッジ策を契約に盛り込んでおくとよいです。

• スケジュールとシステム化範囲は、要件定義後に見直すことを双方が合意する。
• その見直しのタイミングや方法について、互いに合意する。
  

要件定義の完了条件

要件定義では、ユーザーにヒアリングし、結果を要件定義書にまとめる事も重要です。
しかし、もっと重要なことは、要件定義書に書かれた内容以外に実現する要件はない、ということをユーザーと合意を得ることです。

仕様変更時の影響

顧客からの仕様変更依頼があった時、その変更を実施することによる業務の増加量、コストの変動は十分に見積もる必要がある。

仕様変更依頼を受けた担当者（PMなど）が、自らの判断でできると思っても、実際に設計やプログラム製造を行う現場にどれくらい業務が増えるのか（具体的に何時間増えるのか）などはわかっていないことが多い。
自分ではわかっているつもりかもしれないが、現場の影響を正確に把握できないならPMとしては失格だ。

変更依頼があれば、きちんと現場に持ち帰り、担当者と打ち合わせをして、どの個所にどれくらいの変更が発生し、誰が何時間業務時間の変更を受けるのか、きちんと把握してから、その仕様変更の受け入れ可否などについて判断すべきである。

RFP

RFPで目的、背景、狙いを伝える

参考：「目的・背景・狙い」とは何か？

こちらに参考になる記述があったのでメモ。

目的
なぜシステム投資を行うことになったのか，それによりどのような目的を達成しようとしているのかを，簡潔な一文で表現する。
具体的なことは後述する背景や狙いに書く。

背景
前述の目的で書いた事柄が，なぜ起きているのかその原因を分析したものを記述する。
目的よりはやや具体的に記述するが，個別の具体的な要求ではないので，できるだけ三つか四つ程度に原因を集約して書くとよい。

狙い
システム構築によって，先の背景で挙げた問題点や原因を解決することで，どのような効果を期待しているのかを記述する。
この狙いはまさに投資対効果の「効果」の部分であり，これを具体的に記述しておくことが重要なポイントとなる。

RFPで書くべき三つのこと

RFPでベンダーに伝えるべき三つの基本要求

• 何をしたい(目的)
• いくらでしたい(予算)
  ※予算は伝えない方がよい場合もあるが
• いつまでにしたい(期限)

提案書に書いてはいるが、しっかりと思いがベンダーに伝わらないケースもあります。
なかなか難しいですが、そこはしっかりと克服せねば・・・

参考：趣旨はRFPの「ミッション・ステートメント」

RFPの「特記事項」

RFPを作成するときの「特記事項」について。

この特記事項にて、提案書の様式をある程度指示することによって、ベンダーの提案書の書式がある程度そろうことになる。
結果として、各社の提案書を比較しやすくなる。
【参考】http://itpro.nikkeibp.co.jp/article/COLUMN/20100802/350917/

RFPのレビュー項目

RFPをレビューする際のチェック項目として、参考になるサイトがある。
http://itpro.nikkeibp.co.jp/article/COLUMN/20100802/350891/

RFP提案の辞退の方法

RFPを受け取った後、その提案を辞退したい場合、適当な提案をして失注を狙うやり方は失礼にあたる。
高い値段で見積もりを出すなどして、間接的に辞退する作戦を取ったほうがよい。

提案できる内容がないなどで、提案を辞退する場合は、提案書を書き始める前に辞退を申し入れるのがマナー。

合意形成

ヒアリングでは合意形成を

ヒアリングにおいては、案に対して異論がないか、案に対して納得を示しているかを、意見を聞いて確認する必要がある。
また、「言いそびれても後でいえばよい」「言わなくても分かっているはず」といった理由で発言をしない人もいる。
後になってから、「最初から賛成したつもりはない」「言わなかったが実は反対だった」などと言われないようにするため、ヒアリングの際に「ここで決定したことは後で変えられない」ということを相手に認識してもらう。その際には、後での変更によって、納期遅れや品質の悪化などが発生する事も伝えること。

合意形成プロセスの重要ポイント

• 経営層-業務部門-情報システム部門の方向で合意をとる。
• 部門-他の部門の方向でも合意をとる。
• 部門長-現場の方向も。現場を熟知したキーパーソンの合意をとる。

基本設計

要件定義との関連

基本設計の仕様書では、要件定義でリストアップされた事項との対応関係が明確になっている事が重要である。
（どの要件が、どの画面、操作で実現できるかが明確になっている）

従業員がシステムを使いたくなるような仕掛け

• 利用者ができる人の作業のまねができる、できる人と同等のパフォーマンスを発揮できる仕掛け
• 遊び心を取り入れる、システムを使うことが楽しくなる演出がある。
• 従業員同士をつなげる仕掛けがある、情報を共有できる仕組みがある。

クラウド開発

クラウドを意識した開発をする際、これまでの開発手法とはことなるノウハウが必要になります。
たとえば、負荷テスト、セキュリティ、移行の方法、運用手順などなど。
それらを知るきっかけになる記事です。

参考：分からない点がやはり多いクラウド