ITシステムの発注時、小規模でも伝えた方がいいこと

IT活用

こんにちは。SEタケです。

ITシステムを発注するとき、どういう風に依頼しようと考えておられますか?

何をどう伝えていいか、迷っているうちに時間が過ぎてしまっていませんか。あまり悩み続けていても先に進めませんので、とりあえずわからないなりに相談してみるのもありかと思います。どういうことがしたいのかが伝われば、何かしら提案があるかもしれません。

ただ、既にわかっていることがあるなら、最初に伝えた方がスムーズに話はすすみます。何がわからないか、も含めて、伝えておいた方がいいです。

もちろん、あいまいなままでも依頼先のエンジニアがうまく質問して引き出してくれることも多いのですが、エンジニアはほとんどの場合ビジネスに精通しているわけではありませんので、経験のない分野だったりすると勘違いが起こる場合もありえます。

要望がしっかり伝わっていない状態で思い込みで開発が進んで、出来上がってから、思ったのと違うとか、ここもうちょっと変えてよとかなったら、時間もかかりますし、機能追加ですから別途お金くださいとか、そういう話になると残念な気持ちになりますよね。

ですので、できる限りで構いませんから、これからお伝えする内容を踏まえてご相談いただいたほうが無難ではあります。

ちなみに、これからお伝えする内容は、準備していなくても結局あとで訊かれることも多いと思います。どうせなら初めから用意しておいた方が手間が省けますし、複数の事業者に相談する場合も同じものを渡せばいいので便利です。

今回の内容は、システム開発の発注でよく使われるRFP(提案依頼書)というものを元にしています。RFPを本当に作成するとなると結構大変ですし、小規模な発注でそこまで必要ではないと思いますので、大切なところだけ抜き出して簡略化しています。興味がある方は、RFPがどういうものか、一度目を通しておかれるのもいいかもしれません。

スポンサーリンク

依頼の要旨

事業内容、解決したいビジネスの課題、それに対して現状はどうなっているのか、システム化によってどのように課題を解決したいのか、などです。

依頼内容とは直接関係ないことであっても、少し広い範囲で詳しめに伝えておきましょう。例えば、「リピート購入を促す為に顧客への〇〇な価値を提供する」とか、「〇〇の業務がボトルネックになっているので改善する」などです。

全体としてどのような価値を提供しているビジネスなのか、その中でどのような役割を担うシステムなのか、そのためにどのような機能が必要なのか、そういうことが伝わていると、お互いの認識のずれも少なくなります。

また、優先されるべきところや、実はこうしたほうがいのでは?など、エンジニアの視点から気づくこともありますし、よりいい感じの提案が出てくるかもしれません。エンジニアのモチベーションも変わってきます。

システムに求める機能

業務要求

システムで実現したいこと、システムに必要な機能です。

解決したいビジネスの課題に対して、システム化で解決するために必要と思われる機能を、できる範囲で伝えておきます。

必要な機能を発注の段階で全て把握することは難しいかもしれませんので、システムの発注先で提案してほしいことがある場合は、それも記載したほうがいいでしょう。

完璧に仕上げようとする必要はありませんが、こういう案があるというのを記載しておけば、それらを踏まえて実現可能な方法を考えてもらえますし、何か制約があってできない場合も、代替案を提案してもらえるかもしれません。

業務フロー

発注したいシステムの周辺の業務を含めた、業務の流れ(フロー)を伝えておきます。

業務フローを伝えておくと、そのフローに便利になるように最適化できます。画面レイアウトをフローの各業務で入力しやすいように構成したり、次の業務の人に通知をしたり、各業務で操作できる人を制限する、などということが考えられます。

システム内だけではなく、その前後の業務フローがわかっていると、システムに対するインプットとアウトプットの情報や、前後の業務への連携もスムーズにすることができます。

業務フローは、正式な書式でなくても、誰が何をするのか、というのを時系列で記述すればOKです。

例えば、下記のような感じです。

  1. 営業担当が受注情報を入力する
  2. 発注担当者が受注情報を確認して発注する
  3. 商品が届いたら受け入れ担当者が確認
  4. 発送担当者が発送する

技術要求

システムを構築する際の、技術的な制限事項です。

例えば、下記のような内容になります。

  • ITインフラに関する要求
    • ネットワークの構成
    • 使用する機器やツール
    • 連携が必要な他のシステム
  • システム能力に関する要求
    • 利用者の数
    • 利用頻度
    • 扱うデータ量
  • セキュリティに関する要求
    • データ漏洩を防ぐ仕組み
    • アクセス権
  • 障害対策に関する要求
    • 障害発生頻度と復旧方法
    • バックアップ

運用要求

運用面でサポートしてほしいことがあれば伝えます

システムは日常的に使用するようになるまでが大変です。作ったはいいけど使われなかった、ということのないように、サポートが必要であれば可能かどうか確認しましょう。

  • 保守に必要な、システム仕様についてのドキュメント提供など
  • 保守のサポートはしてもらえるかどうか、アウトソースなど代替案はあるか
  • マニュアルの作成、利用者への説明や研修
  • 既存システムからの移行が必要であれば、移行作業

予算

想定外の規模にならないように、目安を伝えます。

伝えておくと、予算を大きく外れないように提案してもらえますし、要望通りの内容は無理であっても、目的に適った代替案があるかもしれません。

期間

システム開発は、結構期間がかかります。目途感を伝えておくことで優先的に対応してもらえるかもしれませんし、無理な場合も、段階的な導入など提案してもらえることもあります。

特記事項

その他、伝えておきたいことがあれば記載します。

担当者の連絡先や部署、担当している業務、システム導入の体制、などが考えられます。

 

以上です。

あまり時間をかけすぎないように、でも少しだけ整理してから発注してみてください。

 

要求事項については、こちらの記事も参考にしてください。

システムは機能があるだけではダメ、導入時に非機能要件を考慮すべき理由

 

システムの導入がスムーズに進み、あなたのビジネスが前進できることを願っています。

最後までお読みいただきありがとうございました。

コメント