要件定義前に詰めておくべき点(新人さん向け)

要点

  1. 要件定義の前段階は超大事
  2. まずは秘密保持契約(NDA)
  3. 類似事例を調査する
  4. 登場人物(ステークホルダー)を把握する
  5. そのシステムはだれが嬉しいのか
  6. そのデータは勘定科目のどの部分に集約されるのか
  7. あるべき姿は何か

要件定義の前段階は超大事

要件定義の前段階は超大事です。

ここがビシッと決まってないと、
後工程でいくら頑張ってもリカバーできません。

医療業界では「手術は成功した。患者は死亡した」という小話があるそうな。

我々も同じ。
システムは出来たけど使ってもらえなかった、
またはユーザがつかなかったという話は枚挙に暇がありません。

読み進めていくうちに、「それってシステム開発と関係ある?」と思うかもしれん。
あえて言う。「関係あるんです!」

依頼者の方が来たら、だいたいの部分はすでに頭の中にあるので
話はポンポン進むことが多い。
でも言っていない部分にこそ本質があるのだと心して尋ねること。

かなり突っ込んだ話をすることになるけど臆するな。
きちんと敬意を持って聞けば失礼にはあたりません。

一回で終わることもあれば、何回も話を聞くことになることもある。
google先生だけでなく、業界紙にも目を通すし、現地にも行く。

基本的に、その業務のシステムを手掛けた後は、
その業界のことは誰よりも詳しくなっているのが理想です。

まずは秘密保持契約(NDA)

話を聞く前にかならず秘密保持契約書を締結してください。
後で揉まさないためです。
締結前は当たり障りのない話しかしてはいけません。
類似事例なども話してはいけません。

類似事例を調査する

オリジナルのアイデアで独創的だとお客さまが思っていても
お客様が依頼してくる内容はすでに世の中に存在すると思ったほうが良い。

似たような事例があるから駄目という訳ではない。
あまりに独創的だと、そもそも実現不可能だったり法に触れたりすることもある。

逆に、すでに誰かがやってるということは
それだけ社会のニーズに合致しているということです。

あ、会計のシステムをスクラッチで作ってくれと言われたら
既存の会計パッケージへの橋渡しをする仕組みを提案しましょう。
理由は、フルスクラッチだと試験工数が跳ね上がるためです。

登場人物(ステークホルダー)を把握する

座組の話をしましょう。
・決定権者は誰なのか(規模が大きくなると依頼者以外の人であることが多い)。
・スポンサーは居るのか、その場合は誰なのか
・契約主体は誰になるのか

そのシステムはだれが嬉しいのか

大きくで良いので聞きましょう
(例・エンドユーザ・自社従業員・自社管理職)

当然、対象がヒトでないこともあります。
その場合は逐一メモを取り、後でググりましょう。

そのデータは勘定科目のどの部分に集約されるのか

何かをシステム化するのであればその目的は大きく2つしかない。
・売上を上げる
・経費を下げる

たとえ人事や教育の仕組みだとしても
教育コストが下がるのか、離職率がさがるかでどちらかに影響を及ぼすはず。

そして、システムは必ずINPUTとOUTPUTがある。
必ず何かを出力するのが目的になっているはず。

弊社はだいたい企業の方が多いので必ず経理のシステムがあるはず。
出力したものが勘定科目でいうとどれに当たるのかを
ざっくりで良いので聞きましょう。

あるべき姿は何か

ここまで聞き出せると、問題点はほぼ洗い出せているでしょう。

ここからが大事なんだけど、お客さまの言うことをそのまま聞いては駄目です。
「その人の背後にあるものを見よ」です。

お客さま現状の何かに改善の余地があると思っているから相談に来るわけです。
いわばその道のプロフェッショナルです。

我々はそのプロの人が当たり前だと思っていることを
素人の目線で質問するのが仕事です。

そうすることにより「あるべき姿」が見えてくるはず。
ちょっと理想論言い過ぎかも・・くらいがちょうど良いです。

また、システム化しない方が良いという結論が出た場合は、それが正解です。
類似事例の調査で信頼できるパッケージがあることが分かったならそちらを提案する。
規模が大きい場合は他社さまを紹介する、またはコンサルを入れる提案をする。

必ずお客さまのことを中心に考えて提案すること。

その他

まあ、後は以下ぐらいかな。頑張ってください!

  1. その企画の成功条件、失敗条件は何か
  2. 企画書の提出先と期限
  3. 補助金や国の支援制度がないか調査する
  4. ざっくり納期

いままでの話をすっ飛ばして、とにかく、すぐ金額を教えろ、とか
見積書をくれというお客さまは、残念だけど丁重にお断りしてください。