中小企業の経営者や管理職の皆さまは、外部の開発会社への依頼をどうしたらいいのか悩む場合も多いようです。
僕自身、制作を請け負うこともあるので、この記事ではエンジニア目線で「こういう依頼は困る」「これは嬉しい」などお伝えできたらと思います。
それにより、外部開発会社への依頼の仕方のヒントを得て頂ければ幸いです。（※この記事が絶対ということは全くありません）
Index
- こんな開発依頼は困る
- こんな開発依頼は嬉しい
- これは嬉しい：制作依頼の基本
- おまけ：制作中・制作後の困り事と嬉しい事
- まとめ
こんな開発依頼は困る
余談：「スマホ首」とよく聞きます。スマホを見るためにガックリと首を垂れている状態で、頭の重さがモロに首にかかります。僕はそれは嫌なので、顔はできるだけ真っ直ぐ前を向いて、スマホを持つ手を顔の前に持ってきます。でも時々やっぱり下を向いてしまう時があるんですよねえ。。手に持たなくて良いスマホが作られることを願うばかりです
さて、業務システムを外部の開発会社へ依頼したい、でも業種は IT 業界ではないし、勝手が分からない・・・。
そうなると、どう開発・制作を依頼したらいいか分からないですよね。
そこで、こんな開発依頼が来たらなかなか困るなあ、ということを社内エンジニア経験のある僕の目線でまとめてみます。
①これは困る：曖昧な要件
「なんとなくこんな感じ」といった曖昧な要件です。
これはもう、開発・制作側にとっては大きな難題の一つです。
具体的に何をするのか、機能の一つ一つの目的は何なのか。
明確な要件の明示がないと、エンジニアは何をどう作っていいか分かりません。
家を建てる例で言えば、
「なんとなく北欧をイメージした感じ」
と、建築会社に依頼するようなものでしょう。
（何階建て？部屋数は？窓数は？断熱材は？などなど詰めるべき詳細はたくさんあります）
じゃあどうすれば？【ながにぃの見解】
「曖昧で申し訳ないけど」と自覚表明して頂いた上で、「細かいところは一緒に考えてほしい」と持っていくのは一つの手です。ただ、細かいところの確認は意外と時間もかかり労力もかかるものです。
対価としてコンサル料のような形をとってあげるとモチベーションは上がり、品質も高く仕上がる場合が多いと思います。
②これは困る：無理なスケジュール
開発・制作には時間が必要です。まあ、至極当然のことですよね。
プロジェクトを進めていると予期せぬ問題が発生することもあるので、エンジニアはそれも加味しています。
提示されるスケジュールには理由があるのです。
それを無視して無理なスケジュールを求めると、エンジニアには過度なプレッシャーがかかります。
その影響でパフォーマンスが下がり、品質を損なう可能性さえあります。
家の例で言えば、
「見積りでは 12ヶ月かかると聞いたけど、なんとか 6ヶ月で完成させてくれない？」
と依頼するようなものでしょうか。
無理を要求すれば、どこかで無理が出ます。こうして欠陥住宅が出来上がるのは想像できてしまいますよね。
じゃあどうすれば？【ながにぃの見解】
どうしても納期を早めなければいけない場合があると思います。そうした時は「誠意」が物を言うかもしれません。折り合いをつけて料金の上乗せを提案するのが常套手段と言えます。
ただ、無理な依頼である以上、納期間際のバタバタ感や多少のトラブルは覚悟しておく必要はあると思います。
③これは困る：丸投げ
「すべてお任せします」
これは悪魔の囁きに近いかもしれません。
こういう依頼を出して、一発でうまくいった話しは聞いたことはありません。
依頼する側は実際に使う立場です。
でも外部の開発会社はその業務システムで実際に業務をするわけではありません。
ほぼ 100% といっていいほど、双方の認識は違っています。
「ここが使いづらいので修正してほしい」「この機能は用途が違うから作り直して」
なんて言いたくても、「すべてお任せします」と依頼しているので後の祭りになりかねません。
家の例で言えば、建ってしまった後で「イメージが違う」「部屋を追加してほしい」と言うようなものでしょうか。
建ってしまった後での大きな変更は当然ながら困難が待っています。
じゃあどうすれば？【ながにぃの見解】
仮に開発・制作をすべて投げてしまいたいとしても、なにかと質問して（しかも敢えて質問する）確認を取るのが良いと思います。質問をすることで、自分の整理にもなるし、全く気にしていなかったことにも気付けます。
案外、そうした気づきが重要な事項だったりするので不思議です。
こんな開発依頼は嬉しい
さて、上の「困るなあ」とは逆に、こういう依頼であれば嬉しいという内容をまとめてみます。①これは嬉しい：明確な要件
具体的な目標と期待する結果がしっかりまとめられて、明示してもらえると嬉しいです。
具体的な提示であるほど、エンジニアはスムーズに機能を作っていけるので、より効率的に作業が進みます。
なにも IT 専門用語を使う必要はありません。
こういう画面とこういう画面とがあって、それぞれやりたいことはコレコレで、ということがまとまっていれば充分な場合があります。
家の例で言えば、
「全体は北欧のイメージで、外壁は白系、屋根は一般的なもの、1階は家族が使う部屋をメインに窓は大きめ、2階は個々が使う部屋をメインに窓は大きめだけど腰から上で、可能なら断熱材などを入れて冬は暖かく夏は涼しく・・・」
といったことは伝えられると思います。
②これは嬉しい：目的のある細かい要望
細かすぎる要望は嫌がられるのでは・・・？とお思いでしょうか。
いえいえ、意外と細かく提案してもらうほうが喜ばれます。
なぜなら、機能を付けるには結局のところ細かく落とし込む必要があるからです。
後になって慌てて細かく確認すると、全体的に修正が発生することさえあります。
最初から認識できていれば、考慮した上で進められるので双方にとってメリットです。
家の例で言えば、
「風呂場とトイレの窓は人影が見えないくらい強めの磨(す)りガラスで」
なんて最初に依頼しておけば、後で作り直しや誤発注、再発注といったことが防げます。
なお、どういう目的での要望なのかも併せて伝えると良いです。
「防犯の目的で強めの磨りガラスに」ということが分かっていれば、それに合ったガラスを予め考慮して探してもらえますよね。
③これは嬉しい：制作依頼の基本
上記のことを踏まえて、制作の依頼を出す際の基本事項をおさらいしておきます。・具体的で明確な要件を可能な範囲でまとめておく
・提示されるスケジュールには理由がある
・丸投げせずなるべく最初から一緒に方向性を定める
・細かいことでも最初から伝えておく方が良い
おまけ：進行中・完了後の困り事と嬉しい事
ここまで、制作依頼における部分について書いてきました。最後に、無事制作が進んだ後のことをおまけで書いてみます。困り事：期待と現実のギャップ
プロジェクトの期待値と現実が大きく異なる場合、これは厄介な問題になることがあります。
「北欧のイメージ」と伝えていたのに、「単なる洋風」で出来上がった、などということです。
「話が違う」「いやいや注文通り作りました」などと発注側と開発側でトラブルに発展しかねません。
この期待と現実のギャップが起きる要因。
これは結局のところ、双方の意志疎通・コミュニケーションが不足していることが挙げられます。
制作前、そして進行中、随時確認することが疎かになると起こりがちです。
じゃあどうすれば？【ながにぃの見解】
なるべく初期段階で、少なくとも進行中には双方の認識を合わせていきたいところです。例えば2週間に1回とか定期的に双方で言葉を交わす機会を作るのは一つの手です。
進捗状況をお互いが把握しながら進むことは、後々の認識のズレも小さくすむと思いますので。
困り事：要望の追加・拡大
契約後にプロジェクトが進んでいくと、
「やっぱりアレも追加したい」「実はコレが抜けていて必須だった」
といった要望の追加や拡大が出てきます。
例え小さな、細かい内容だとしても、システム的には大幅な改修が発生する可能性もあります。
エンジニアからすると「最初に言ってくれえ…」と泣きそうになり、時に大きな混乱を引き起こします。
家がある程度建った後に「やっぱり出窓にして」「3階もほしい」と依頼するようなものでしょうかね。
こうなると予定が大幅に遅れるばかりか、追加費用を請求されても致し方ないところです。
じゃあどうすれば？【ながにぃの見解】
「後から追加・後から拡大」問題の予防策としては、やはり最初の段階で要望を伝えておけるのがベストです。結局は、双方のコミュニケーションが鍵になってくるでしょう。
後は追加費用をしっかり出す、ということも大事な部分かと思います。 とにかく最初の段階から、双方の認識をなるべく合致させる努力をお互いにするのが良いですね。
困り事：終わらない修正
何度も何度も同じ箇所の修正を求めたり、「違う、違う」と否定的な修正ばかりを求める…。
エンジニアも人間ですから、モチベーションはどんどん下がり、質も低下しがちです。
AI であれば文句など言いませんが、結局は人間と人間のお話しになりますから、色々難しいですね。
（ AI もそのうち文句を言うパターンも出てくるかもしれませんが）
じゃあどうすれば？【ながにぃの見解】
まあ、結論的には追加で改修費をしっかり払うことで Win-Win になります。特にエンジニアがフリーランスの場合は生計に直結することになります。
エンジニアとしてはしっかり報酬を得られればそれだけ嬉しいし、貴社のために頑張ろうと思ってくれます。
ちなみに修正依頼をする際には、「コレは凄くいいので後はアレがこうなれば完璧」などと前向きな感じで伝えると喜ばれます。
嬉しい事：フィードバックの提供
定期的なフィードバックは、エンジニアにとって非常に有難がられます。
フィードバックには次のようなものがあります。
作業の評価を伝える
プロジェクト進行中、感想でも良いので適宜伝えるのは良い策です。エンジニアによって違うかもしれませんが、良い評価を受ければチベーションにつながり、厳しめの評価を受ければ意識を変えるきっかけにもなります。
改善点の指摘
要望とのズレがある場合は具体的に指摘してしまって良いと思います。エンジニアとの認識のズレを修正するためであり、今後の方針の共通理解に繋がります。
もちろん批判的な言葉遣いではなく、建設的にフィードバックすることが良い関係で進める上では重要です。
感謝を伝える
業務システムの制作は家の建築とある意味同じで、一つ一つ積み重ねて制作が続けられます。ここは目に見えない部分なのでなかなか理解できないかもしれません。
でもそれを汲んで感謝の意を都度示すことで、エンジニアのモチベーションは継続され、時に高まると思います。
そうすれば質の良い成果物ができあがる可能性も高まります。
まとめ
以上、こんな制作依頼は困る、逆に嬉しい、といったことをエンジニア目線を交えて書いてみました。これは FileMaker に限らず、どういう業務システムでも基本的には同じだと思います。
とはいえ、要件定義なんてどうしたらいいか分からないよ、ということがあるかもしれませんね。
JBI の「制作依頼コース」では上述のデメリットが軽減できるサービスになっています。
最初の要件のところから一緒に考え、徐々に、一緒に、作り上げていくスタイルです。
※こちらの記事もよろしければどうぞ→【業務システム開発】FileMaker「制作依頼コース」オーダーの仕方
時間はかかるかもしれませんが、きっとメリットは多いと思います。
気になりましたら、事前の無料ご相談でお聞かせください。
今日も良い一日を♪
Blogger Comment
Facebook Comment