ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

外部の技術コンサルタントの雇い方

新しいものを導入したり、困っていることがある場合に外部の技術コンサルタントを雇う例が増えていると思います。 一方で、外部の技術コンサルタントを使うとお金もかかりますし、その分の成果もきちんとあげなければなりません。 あくまで私見ですが、以下に僕がお客様とか相談してくれた人に推奨している技術コンサルタントの選び方を書いておきますので参考にどうぞ。なお、技術顧問はちょっと毛色が違うので全部は当てはまりません。

  • コンサルタントは銀の弾丸ではないので、雇ったら「なんだか良く分からないけどすごーくうまくやってくれる」なんてわけはないことを認識すること。発注側も実行をコミットする必要がある
  • コンサルタントを使うことを検討する前に、自分たちが何に困っているのか明らかにすること。視点は単なる技術視点でなく、ビジネスレベルでも考えること
  • 何に困っているか明らかにするとき、関係者それぞれの課題が同一とは限らないということを認識しておくこと
  • コンサルタントに期待することに優先順位をつけること
  • 自分たちの課題が解決したらさっさとコンサルタントの契約は終わらせる/更新しないようにすること
  • さっさと契約を終わらせる前提でコンサルタントからスキルを吸収すること
  • 最初から長期契約を求めるコンサルタントは疑ってかかること
  • 成果を保証するコンサルタントは疑うこと。やるのは発注者自身。「絶対」「確実に」とか「○○すればうまくいく」といったセリフをすぐ言っている場合は疑う
  • 実際に契約する前に複数のコンサルタントに相談してみること
  • 普通コンサルタントは一度の相談くらいは営業活動の範疇。ただし営業活動扱いを求めて何度もお金を払わずに相談しないこと(受託開発なんかだとコンペで何度も打ち合わせして提案書を作ることになるが、その分の工数は営業経費として実際の費用に上乗せされることになる。それと同じことが起こるがそれで良いのか?)
  • 相談のときに大勢で訪問してきたら疑うこと。分業でジュニアがアサインされるリスクなど
  • 担当予定のコンサルタントが明確な場合はグーグルなどで検索してみること
  • 相談のときにコンサルタントと相性が合わない/響かないと思ったら契約しないこと
  • 知り合いなどから実際に付き合ったコンサルタントを紹介してもらうのも良い
  • コンサルタント側にメリットのある対案を出さずに値切らない(メリットがないのに値切られたら品質を落とすか付き合うのやめるか、色々想像がつくはず)
  • コンサルタント側からの抱き合わせの割引提案に安易に飛びつかないこと
  • 自分の責任でやるのがリスクがある場合はコンサルタントの提案という形にしてやること

他にも色々あると思うのでぜひ教えてください。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 【我流】プレゼンテーション資料の作り方
次の記事 【資料公開】The Basics of DevOps

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World