業務請負での受託開発をされている皆さまへ
ITな分野でサービスを開発して一発当ててやろうと思う人も、
地道に受託開発の規模拡大を行なって利益を出そうって人も、
面白そうな案件に巡り合えたら経験と金のために開発しようって人も、
お金をもらって何かを開発する「受託開発」で一度は失敗したことがあるかと思います。
たとえば、
約束していないのに断れない追加作業を求められて赤字になった。
無理して対応してあげたのに文句ばっかり言われて気分がわるい。
それに加えて対応期間も伸びまくって次の仕事に支障をきたした。
上記はべつに受託開発にかぎった失敗ではないと思いますが、
受託開発のおいて、失敗を防ぐために心がけていることを紹介します。
１．対応できないことは明確に
「やろうと思えばできるけどやらない」ことは最優先で伝えるべきです。
例えば、弊社では客先常駐は対応しない方針なため、最初につたえます。
他社でやっているから、いざとなったらやってもらってあたりまえ、
という認識でいる相手に、後出しで条件を突きつけたらキレられます。
どうしても受け入れられない条件があるなら、それを最初に伝えて、
お互いの価値観に相違がないかを確認しないと本当に辛い経験をします。
２．苦手な分野は正直に
やれなくはないけれどあまり得意ではない分野も最初に伝えるべきです。
例えば、弊社はデザインにはあまり力をいないことを最初につたえます。
得意でも苦手でも仕事を引き受けるからにはベストをつくすのはあたりまえですが、
ベストをつくしてもアウトプットが低いなら、残念ながら何の価値もない。
自分の首を絞めることになるし、
何よりも信頼して仕事を預けてくれた人にゴミを納品することになる。
お金ならいくらでも稼げるけど、
失った信頼を回復するのは骨が折れるので致命傷は避けましょう。
３．対応期間を決める
開発着手後に優先順位や詳細を変えたくなるのは当然です。
微調整幅を過去の経験に基づいて算出することは可能ですが
せっかく少数精鋭でコストを抑えて無駄な動きは省いていいもの作ろう
って話をしているのにミスまで計算にいれて見積もるのはナンセンスです。
最近のアジャイル開発本でよく紹介されている内容とはかぶりますが
チェックポイントと優先順位を定期的に相談しあって
コスト以上の成果を出すことを受託と発注の両側で意識しはじめると、
かなり進みがよくなりますよ。
クライアントは仕事の大切なパートナーです。
プロとしてちゃんと説得しましょう。
４．経験ある現役エンジニアを最初から参加させる
最近開発しなくなって余計感じていることですが、
忙しいからといってエースクラスの開発者の時間をとらずに
自分のちからである程度決めようと思うのは、やめましょう。
判断と技術の両面で強い人材に最初から参加してもらったほうが、
トラブル時のリカバリと比較するとはるかに手間が少ない。
お客さんだけでなく開発チーム全員が安心して仕事に専念できる。
お客さんの安心はお金に繋がることは言わずもがなですが
価値をつくりだすのは開発者が気持よく仕事できるのも大切です。
コストカットするところを見誤っちゃいけません。
まとめ
プロジェクトの失敗はつねにミューチュアルなので、
詐欺でもしないかぎり一方だけ得していることはありえません。
弊社のような営業トークが弱い会社は後々の問題やリスクを軽減するために
あえて相手側の利益を考えながら仕組みづくりする習慣を大切するのです。
ただ
エンジニアリングって難しくって、チャレンジしないと腐るんです。
例えば、同じ事を同じようにずっと進めることが最も進捗も収益も安定しますが、
長期的にみると、大切なエンジニアのエンジニアリング能力が伸びなくなります。
そりゃあ、技術職なのに技術を磨く機会がないとダメですよね。
失敗しない前提で、どうやってチャレンジしていくか？
今回は受託開発における「短期的な失敗」に焦点をあてて対策方法を紹介しました。
次回は、規模拡大の仮定で体験できる「中長期的な失敗」の対策方法を紹介します。
例えば、「人数は増えたけどできることが全然増えない」や
「人数は増えたけど収益自体はそこまで増えていない」などです。