事業会社がシステム開発ベンダーに依頼する前にやっておいたほうがいいこと

こんばんは。it-daxです。

システム開発ってなんだか難しそうだから専門のベンダーに丸投げしちゃうんだよねという事業会社の担当者の方が多いです。
実はそれ、危険です。

開発ベンダーの企業規模の大小関係なしに、システム開発に失敗したという話はよく聞きます。
以前プロジェクトの失敗のほとんどは開発ベンダー側のPMのせいという記事を書きましたが、PMにもピンからキリまであるのです。
企業規模でそれは変わりません。

思っていたものと違う、機能が足りない、これなんのための機能だっけ、みたいなことを防ぐには事業会社の方の努力も必要です。

では、システム開発ベンダーに依頼する際にどのような事前準備をしておけば良いのかをご紹介します。
※「なぜやるのか」「なにをやるのか」「どのような効果を期待しているのか」みたいな企画は既に完了していることを前提にしております。

システム開発の知識がなくてもできるのでご安心ください。

作成物

  1. ターゲット

  2. ターゲットの行動

  3. システムに求める機能

  4. システムイメージ

  5. 用語集

これらを自分たちで整理するだけでシステム開発の失敗リスクは大きく下がります。
今までは開発ベンダーに要件定義として依頼していた内容になりますが、ベンダー側が主体なので依頼者とベンダーの間でコミュニケーションに不足や齟齬があれば当然いらないシステムが出来上がります。
また、ファクトのないジャストアイデアが多発するので、この機能ミスったなーということも多発します。

依頼者側で事前にこちらの作成物レベルで整理しておくことで、本当に欲しいシステムが依頼者側も整理できて、開発ベンダーにも伝わりやすいのです。

ターゲット

システムを取り巻く人物を整理します。
ステークホルダーマップというもので整理するとわかりやすいです。

広い画で申し訳ありませんが、登場人物とそれぞれが提供/受領する価値を整理します。
開発するシステムと使う人は色をつけるなど一目でわかるようにしましょう。

https://uxdaystokyo.com/articles/wp-content/uploads/2019/09/ex-stakeholder-map-2.png

ターゲットの行動、システムに求める機能

システムを利用するターゲットがシステムを利用する際の行動を整理して、システムに必要な機能を洗い出します。
ユーザーストーリーマッピングというもので整理するとわかりやすいです。

あくまで自分たちのイメージを整理して書き出すので、システムとしての実現可能性などは排除して考えてください。
1日あれば作れると思います。
しかし不思議なことに作ったものを見直すと過不足が出てくるものなので、3回ほどメンバーを変えて見直ししてみると良いです。

Miroというツールで整理することをお勧めします。
それぞれの枠に詳細な説明を書き込むことができるので、機能に対して細かい説明やメモが必要なときに便利です。
解決したいビジネス課題があれば、機能にメモでこのような課題を解決したいためこのような機能が必要などメモしておくと尚良いです。

システムイメージ

ここまでできると大体システムがどんな機能を持っていて、どんな画面があるか見えてきます。

そして次は紙やホワイトボードにどんな感じのシステムかイメージを書いていきます。
メインの機能の部分や、こだわりたい部分だけでもいいです。

気をつけたいのは、あまり良いものを作ろうとしなくて良いということです。
なぜなら良さそうなイメージがでてくると開発ベンダーがそれに引っ張られてしまいますので、考えることを辞めてしまいます。
高いお金を払う意味がなくなりますね。

あくまで依頼者側としてシステムに必要な機能を整理してファクトのないジャストアイデアでシステムを作らないようにしたいのが目的です。

https://www.will-commu.co.jp/blog/wp-content/uploads/2017/07/932fe2f5fdbaaac4a19044ec32414dde-1024x768.jpg

こちらも広い画で申し訳ありませんが、このくらいラフで構いません。
実際のデザインにはデザインライブラリやデザインテンプレートという既存の優れたデザインを少し変えて使い回すことが多いので、そこらへんは開発ベンダーに任せた方が良いです。

用語集

https://cdn.mainichi.jp/vol1/2021/07/16/20210716ddn008020023000p/9.jpg?3

こちらはそのままの意味です。
社内で使用されている用語が一般的とは限りません。
なるだけ出てくる単語は用語集として整理しておくことで、開発ベンダーとの認識齟齬を防ぐことができます。

おわりに

システムのことを知らなくても全然できそうですよね。
実際できるはずです。
最低限このレベルで整理しておくことで、開発ベンダー側としても本来よりシステムを良くするための提案に時間を割けるのでwin-winだと思います。

開発する内容次第で別でこういうのもあったほうがいいなどあるので、TwitterのDMでラフにメッセージいただけたらアドバイスできます。

ウチだとこういうの作ってる、とか、この資料あると助かるとかご意見あればコメントお願いします。

この記事が気に入ったらサポートをしてみませんか?