昨今、企業やお店など、様々な所でシステムが使われるようになりました。
それに伴い、システム発注時のトラブルも増えています。
主なトラブルの内容は以下の通りです。
- 思っていたものと違うものができてしまった
- コストが当初より膨らんだ
- 開発期間が予定より伸びた
- 使ってみたら使いにくかった
こういったことが起きた場合、多くの人は「作った企業（人）のレベルが低い！」と受注側に問題があったと思われることが多いのですが、実はそうではありません。
もちろん、場合によっては受注側に問題があることもあるでしょう。
しかし、実際の現場のトラブル状況を見ていると、ほとんど多くの場合は、そもそも「発注」の段階で要件が漏れてしまう、発注側の「発注スキル」の低さが原因であることが多いのです。
ここでは、こういったトラブルを回避するための上手なシステムの発注方法について紹介していきます。
目次
はじめに
まずはじめに、大前提として覚えておきたいのは「伝えていないことは伝わらない」ということです。
システムを発注する場合、発注側はシステムについてあまり詳しくない場合が多く、「全部お任せすればいいや」という受け身スタンスでいることが多いです。
実際にシステムを作る段階では完全にお任せで間違いないのですが、その前段階である「どういうシステムを作りたいのか？」という部分を作り手に伝えることは必要です。
作り手であるエンジニアは、クライアントとの会話の中で、作るシステムの形を把握していきます。
ある程度の内容は一般的な要望や過去の経験から推測することができますが、それらはあくまで推測に過ぎません。
エンジニアにとって、あなたの普段やっている業務は「未知」なのです。
まず、「どういう業務を行なっているのか」「何に困っているのか」「どうしたいのか」といったことを主体的に話してもらわないと、「こういうケースはどうなりますか？」「こういう機能は欲しいですか？」という質問もできなければ、「じゃあ、こうした方が良いのではないですか？」という提案もできません。
まずは相手に自分が望んでいるものをしっかりと伝える。
これが重要です。
自分の要望を相手に伝えるために必要なこと
1.業務の流れを言語化する
まず、自分が普段行なっている業務の流れを言語化することです。
例えば整体院の場合は、
- 電話で予約を受ける
- 紙の予約状況リストで空き状況を調べる
- 空いる日で予約を受け付ける
- 来店日の前日に確認メールを送る
- 来店を待つ
- 初めての来店の場合は問診票を書いてもらう
- ヒアリングをする
- 紙のヒアリングシートに記入していく
- 施術の方向性を決める
- 施術の説明をする
- 施術する
- 施述後の確認をする
- セルフケアグッズを紹介する
- 次回の予約を取る
- お会計
- 顧客台帳に顧客情報を追加・更新する
- カルテをまとめる
- 日報を書く
といった具合に、自分が普段行なっている行動を思い返しながら洗い出してみましょう。
途中で業務が分岐する場合は、「●●が▲▲の場合」「●●が◼︎◼︎の場合」といった風に分岐させていきます。
少なくとも、この「業務の流れ」を言語化して作り手に伝えることができれば、作り手は「この部分でこういったシステムを入れるとこういう効果が期待できますが、どうでしょう？」といった風に、あなたの業務内容にマッチした提案ができるようになります。
2.要望や困っていることを書き出す
業務の流れを書き出したら、次は「やりたいこと」「困っていること」「解決したいこと」を書き出してみます。
同じ整体院の例であげてみると、
- 予約リストで調べて予約するのが大変
→webから予約できるようにしたい - 初めての顧客かどうか調べるのが手間
→紙の顧客リストを電子化して検索できるようにしたい - 店舗によって顧客情報が重複する
→顧客リストを店舗で共有できるようにしたい - 施術の方法を他の店舗と統一したい
→「ケース毎の施術方法」を簡単に共有できるようにしたい - ヒアリングシートを電子化したい
- 会計をもっと楽にしたい
- 日報をもっと楽にしたい
- セルフケアグッズをwebでも販売したい
といった風になります。
ここでは、「●●に困っているから、こういう風にしたいと思っている」まで言えるのがベストではありますが、良い解決方法が浮かばない場合は「●●に困っているから、何か良い方法はないか」と聞くことで、システム作りのプロフェッショナルである作り手の意見も交えながら、最適な解決策を一緒に模索することもできます。
逆に、「この部分はこだわりがあるから変えたくない」ということがあれば、それも相手に伝えておくと良いでしょう。
3.解決の優先順位をつける
要望、困っていること、解決したいことに優先順位をつけていきます。
優先順位をつける際は以下の基準で判断しましょう。
- 今回の開発で解決必須
- 今回必須ではないがなるべく早く解決したい
- 時期にこだわらず、追い追い解決したい
4.期間と予算、開発規模を決める
システムを発注するからには、お金がかかります。
もともとの開発予算とエンジニアに出してもらった見積書を照らし合わせながら、今回の開発規模（どの機能までを作るか）を決定し、開発期間を定めていきます。
この際注意したいのはQCDの問題です。
- Q（quality：品質）
- C（cost：金額）
- D（delivery：納期）
のことで、これらは相互作用があるため、
例えば「品質」をあげるためには「金額」または「納期」に余裕を持たせる必要があり、「納期」を短くするには「品質」を下げるか「金額」を多くかけるかが必要になってきます。
なので、全ての要素において最高を求めるのではなく、自分にとって最適なQCDのバランスをとることが重要になってきます。
あまり無茶な低コストや短期開発を強要すると、システムの品質を下げるしかなくなりますので、くれぐれも無茶を言わない方が賢明でしょう。
エンジニアを選ぶ際に注意すること
エンジニアは一緒に開発を進めるパートナーです。
選ぶ際は、以下の点に注意しながら選ぶと良いでしょう。
単価のやすさに飛びつかない
エンジニアの単価は、企業であれば１人月（人月：１人が１ヶ月開発に参加する場合の単位）100万円になります。
小さい企業や個人規模であれば、50~80万円程度であることもありますが、安い単価であればあるほど、経験が少ないか、できることに限りがある（プログラムは書けるけれど、全体の設計ができない、など）場合が多いです。
これよりも極端に単価が安いということは、独学で勉強・デビューしたばかりで極端に開発経験が浅いか、クオリティを下げてどんどん早く案件を回して稼ぐエンジニアであることが多いです。
求めるシステムが単純かつクオリティの高さを求めない場合は単価が安い方でも大丈夫ですが、複数人で使う業務システムなど、それなりの規模があるシステムをお任せするとなると、少し心許ないですね。
画面の綺麗さと技術力は比例しない
基本的に、画面の見栄えとエンジニアの技術力は比例しません。
見た目部分というのは、流行りのデザインであったり、既存のパーツを使うことによって、技術がなくても綺麗に整えることができてしまう部分です。
どんなに綺麗な見た目であっても、プログラムの中身がボロボロだと不具合だらけで大事なデータが消えてしまったりということも有り得るので、実績の画面キャプチャだけで選ばないようにしましょう。
紹介か、自分で話してみて判断する
一番良いエンジニアとの繋がり方は「紹介」です。
やはり実際に一緒に仕事をしてみてよかった、と思った人を紹介してもらうのが一番確実です。
ただ、なかなかそういったエンジニアを紹介してくれる人がいない場合は、まずは口コミや評価などをしっかりと確認して良いと思った方に直接連絡を取り、自分が実際に話してみて（簡単に相談するくらいなら相談料を取らない場合が多いです。）良いと思った方にお願いするのが良いでしょう。
まとめ
いかがだったでしょうか？
発注スキルといっても、それほど難しい技術を要求しているわけではありません。
発注時に相手に自分の考えを伝える「コミュニケーション」が大事であるということです。
また、実際にシステムを作るのはエンジニアですが、作るもののカタチを伝えたり、出来上がったものに対してフィードバックを行うのはあなた自身です。
すべて受け身の姿勢でいるのではなく、任せる所は任せつつ、相手に伝えたり一緒に考える部分では主体となって行動すること。
あなたとエンジニアの二人三脚で進めていくことが、トラブルなく満足がいくシステムを作る上では重要です。
