※回答一覧

 出題者   カテゴリ   作成日

西畑 一馬
JavaScript&jQuery担当 2015-03-29 20:35:07
 問題   ヒント   回答数 
■JavaScritpなどを外部に発注する際の注意点

JavaScritpにかぎらず開発したい機能があるが社内にリソースがない、そういった場合に案として出てくるのが外部のパートナーに開発を依頼する外注です。
ただし外注に発注して問題がなかったというケースは少なく、多くの方がトラブルに見舞われています。発注するときに知っておくこと、決めておくことがあります。

下の内容を考えてみてください。

1. 外注先はどうやって探しますか?

2. 開発したい機能要件以外にはどのような内容を伝えますか?

3. 外注で失敗した経験があれば教えてください。
6

 

メンバーの回答一覧 お疲れ様でした!
※講師コメント詳細は冊子に掲載されています。

なるほど
票数
回答 講師コメント
1 たけ
1. 外注先はどうやって探しますか?
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
さぶみっとのサイト制作マッチングなどで探します。

重めのものでなければ、
ランサーズ、クラウドワークスなどのクラウドソーシングでも、
募集をかけてみると思います。



2. 開発したい機能要件以外にはどのような内容を伝えますか?
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
個人的な経験では、以下の内容も一緒に伝えると、
失敗が少ないかなと感じています。

具体的な内容はシステムの大きさや種類にもよりますが…。

重要なのは「事業の視点から、なぜそのシステムが必要とされているのか」を
具体的にイメージしてもらえるよう、
こちらからわかりやすく説明することかなと思っています。

――――――――――――――――――――――――――――
例:
・システムを必要としている事業は、どういった事業なのか
・そのシステムは誰がどのように使うのか
・そのシステムから得られる「効果」「収益」
・どの程度まで作りこんで欲しいか
 (※「簡易的なレベルで良いのに、作りこみすぎて工数がかかった」などを防ぐ)
・その他周辺情報
 (ありそうなエラーなど。ユーザーはこういう間違いをしそうな人が多いなどを
  伝えてあげると、想定して工夫しやすいように思います)
――――――――――――――――――――――――――――


3. 外注で失敗した経験があれば教えてください。
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
2.で書いたことが、
ほとんどこれまでの自分の失敗を踏まえたものです。


主には
---------------------------------------------------------
「説明不足で、本来は不要な対応に工数をかけてしまった」
---------------------------------------------------------
というパターンが多かったかなと思います。
 

例えば、以下のようなケースです。
---
・実際に利用するユーザーの環境なら、ほぼ発生しないエラーなのに
 わざわざ対処して工数をかけてしまった

・社内向けなのでUIは凝らなくて良いのに、
 機能の実装以上に時間をかけてしまった
---


ただ、色々気をつけて説明している今でも、
時々「これは無駄だった!」という事がよくあります。

作業開始前には理解していても、集中して作業をしているうちに、
どうしても忘れたり思い違いしてしまう事はあるので…。

エンジニアの認識がずれないよう、進捗をこまめに確認しながら、
自分が常にリードして、繰り返し伝え続けるのが大事だなと思っています。
 (西畑 一馬)
「説明不足で、本来は不要な対応に工数をかけてしまった」 これは非常に重要ですね。機能や作業毎に重要度を高・中・低などとすると外注先も切り分けがしやすいいかもしれません。 (重要度 中や低のものが作業コストが掛かりそうなら簡単な方法を提案してくれ等)

1 丸田
1. 外注先はどうやって探しますか?
すでに取引がある人に尋ねて紹介してもらいます。

2. 開発したい機能要件以外にはどのような内容を伝えますか?
・仕様変更が発生したときの費用や納期について相談しておくこと
・受注元が改修の責任を取れること(ネットで拾ってきたプログラムをそのまま使うようなことをさせない)
・他人の著作権を侵害する行為をさせない(した場合、あとから発覚した場合のペナルティを決めておく)

3. 外注で失敗した経験があれば教えてください。
デザインを外注し、当社でコーディングするというやり方での失敗ですが、
当社ではデザインはPhotoshopで作成するのですが、外注先はIllusratorで作成していたため、
コーディングの際にそのまま使えず作り直した、ということがあります。
 (西畑 一馬)
発注者と受注者で統一のツールを使うのは重要ですね。さらにバージョンも合わせておけば不測の事態にそなえることができます。

0 YN
1. 外注先はどうやって探しますか?
検索、知人の紹介。但し、選定前に必ず相見積もりを取り、対応の様子なども含めて総合的い検証し、選定します。

2. 開発したい機能要件以外にはどのような内容を伝えますか?
会社の経営理念やミッション、ブランドイメージ、サービスや商品の特性、顧客の特徴も伝えます。
社内で対応可能な作業範囲、スタッフの技量についても明示し、業者の請負範囲を細部に至るまで明確にしておく必要があると思います。

3. 外注で失敗した経験があれば教えてください。
サイトの構築を業者に依頼した際、「設計」という作業項目に、視覚的なデザイン、レイアウト、ユーザビリティ、SEO対策も考慮に入れたサイトデザインが含まれると思い込んでいたところ、実際は、純粋にプログラミングとコーディングのみを請け負ってくださる業者だということが後になって判明し、結果としてプロフェッショナルな印象のサイトが制作できなかったように思います。

また、基本的な動作確認テストの部分(受け入れテストに至る前段階のテスト)を、発注側の当方で行わなくてはならず、その点は想定外だったため人員の確保に難儀しました。事前に、作業分担についての詳細について話し合っておかなかったことが反省すべき点です。
 (西畑 一馬)
「ここまではやってくれるはず」という思い込みは不測の事態が発生しやすいところですね。 多少面倒でも作業内容や作業分担は事前に取り決めておく必要があるでしょう。

0 yukko
1. 外注先はどうやって探しますか?
知り合いの紹介や現在入っていただいてるコンサルティング様に良い業者さんを紹介していただく。

2. 開発したい機能要件以外にはどのような内容を伝えますか?
内部と外部とでは想いに対して温度差がありますので、ワークフローや納期に感する感覚値を共有したいです。
後は、著作権の侵害など、法的に先方が責任を追えない部分については事前に伝えておくことが必要かと思います。

3. 外注で失敗した経験があれば教えてください。
デザイン製作を外注発注した際に、外注が主導権を握ってしまい、その部分だけ自社の雰囲気や想いからそれてしまい、結局作り直したという経験があります。外注の想いが強すぎてそれをこちら側に合わせる為に結構な時間を要してしまい、コストばかりかかってしまったと記憶しています。
 (西畑 一馬)
デザインに関してはシステム以上にコミュニケーションを密にしないと、希望と要望が合致しないケースが多いです。 ただ、最終的にはデザイナーの力量に依存するところが多いので相性の良いデザイナーを普段から探しておくのが良いかもしれませんね。

0 kamino
1. 外注先はどうやって探す?
知り合い経由で探すか、クラウドワークスなどで探すと思います。

2. 開発したい機能要件以外にはどのような内容を伝える?
最低限、自社のサービスや特徴など、どういうお店で何を取り扱っているかを共有しておきたいと思います。
あと、納期は予定よりも1週間は早く伝えたり、NGなことを先に伝えられたらいいと思いました。

3. 外注で失敗した経験があれば教えてください。
JavaScriptではありませんが、目的がしっかり共有できていなかったことで、
こちらが実装してほしいものと上がってきたものにズレが生じたことはあります。
当たり前のことですが、目的と納期は事前にしっかりと確認しておくべきだったと思います。
 (西畑 一馬)
「納期は予定よりも1週間は早く伝える」「NGなことを先に伝えらる」 これは非常に重要ですね。

0 SUGIMOTO
1. 外注先はどうやって探しますか?
⇒知り合いに相談して、紹介してもらう。もしくは、クラウドワークスなどを利用して提案してもらう。

2. 開発したい機能要件以外にはどのような内容を伝えますか?
⇒なぜ作るのか?(背景)、何のために作るのか?(目的)、作ってどうしたいのか?(ゴール)
を共有するようにしています。そうすることで、こちらが見えなかった改善点や、外注先からの提案も期待できます。
また、金額と納期は先に決めておきます。作ったものが著作権に侵害しないようにするとか、コンプライアンスを守ってもらうということも先に話します。

3. 外注で失敗した経験があれば教えてください。
⇒大規模案件で、開発費削減のため、日本出資の海外の会社に頼んだが、言葉の壁や価値観の違いがあり、こちらの仕様だけではうまく情報が伝わらず、何度も手直しすることになってしまって、結局コストオーバーしてしまった。
 (西畑 一馬)
海外の会社に出すパターンはやはりうまくいかないケースが多いようですね。 言葉の壁や価値観以外にも対面でコミュニケーションができないと難しいケースが多いようです。