読者です 読者をやめる 読者になる 読者になる

Web就活日記

愛と夢と人生について書きます

常駐型受託開発の経験から

起業

受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 (WEB+DB PRESS plusシリーズ)

受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 (WEB+DB PRESS plusシリーズ)

常駐型受託開発

久しぶりにブログを更新します。「常駐型受託開発」という言葉が正確かどうかも分からないけど、とりあえず取引先のシステムを作ってました@yutakikucです。とある会社様(クライント)の新規事業立ち上げが目的で、そのクライアント様のOfficeにお邪魔しながら約1年程携わらせて頂きました。結論から言うとこの経験が凄く身になってとても良かったと感じました。(※優秀なスタッフさんが沢山いらっしゃる環境で、とても親切にして頂いた事は厚くお礼を申し上げます。)
受託やらないほうが良いぜ!論を当然否定することはしませんし、逆に強く薦めもしませんが、新規事業立ち上げに必要な事を凄く近いところで経験できたのは今後自分が事業を立ち上げる事にもプラスの材料になったと思います。今日はこの開発現場で感じた受託開発とマネジメントについて記録するだけなので、内容的には糞つまらないことかもしれませんが、どなたかのお役に立てればと思います。因に僕の会社には社員がいないので、一人で出向いていました。

常駐型受託で良かった点、残念だった点

良かった点
  • 自分と同じような受託社長さん達と知り合う事が出来た(ここ凄く大事)。また受託開発現場というのを肌で感じれた。
  • 自分の技術力の立ち位置を把握できた。また技術力よりも人間力/信頼力が仕事を得る材料である事も理解できた。
  • 常駐する事で社員さんとのコミュニケーションが密にできたし、認識の大きな間違いも少なかった。
  • 事業立ち上げフェーズから入れてもらえた事で社員さんと同等のStartUPの進め方のノウハウを身につける事ができた。
  • 0からのスタートなので、幅広く必要なシステムの根幹を作り込んだ。またその仕組みをいち早く作れるように考える頭も身につけた。
  • 注文請書、請求書等のやり取り作業を全部自分で経験できた。契約面で質問したい内容があれば直ぐに現場でも解消する事が出来た。
残念だった点
  • 常駐型+時間契約だったので労働時間の対価を得るような内容になってしまった事。またそれによって時間的な拘束が多く発生してしまった事。これにより他社からの開発を受けられなくなってしまった。
  • 受託に重きを置きすぎて自社開発に手がつけられなくなってしまった事。(僕はここの比率を途中で変更してしまったのだが、最初に決めた信念を貫く必要があると感じた。)
  • 決められた方針に反論しづらい、また自分が思った改善策や良いアイディアを率先して現場に浸透させづらい。どうしても所詮受託の意見という考えが浮かんでしまう。
  • イベントや勉強会で直接的な成果を発表しづらい。発表する場合はコアな話は出来なく、概要レベルもしくは一般論に置き換えて話す必要がある。
  • 頑張った事に対する評価についてあれこれ考えてしまう。

受託エンジニアの種別

受託エンジニアと言っても様々な背景を持った人と知り合う事ができたのでそれもプラスの材料になりました。今回の現場では受託エンジニアご本人が別の会社に所属しているか否(独立している)か、採用に紹介会社がいるのか否かという2×2の4パターンありました。凄く失礼な話かもしれませんが、この区分けによりなんとなーくのエンジニア特性が見れて取れたように思います。ここでも書けるような内容としては個人を見た場合、会社所属の人たちは要件の抽出とそれを具体化する力、独立している人達は何かやったるぜー!という野心と個性が強く見れた気がします。マネジメントをする人はご自身で特性を見つけ出して知っておくと良いかもしれません。ここはもっと詳しく書きたいんですがこの辺まで(笑)

受託の人数

現場で社員を雇えない状況で今直ぐ対応する人が欲しい場合は受託の人数を増やすのが手っ取り早いですが、その人数が増えすぎるとマネジメントが確実に行き届かなくなります。これはどんなに優秀な社員マネージャーがいたとしても受託に対する指示を一人ずつに細かく伝えるのは不可能であり、結局のところ一番コミュニケーションが発生するのは社員マネージャと受託では無く、機能担当の社員エンジニアと受託の直接になります。この社員さんのコミュニケーションコストが半端無い。仕様の伝達、ソースコードレビュー、改修依頼等、ただでさえ忙しい社員エンジニアさんもその辺のサポートに相当な工数が掛かってしまいます。今回の経験での一つの指標として、どんなに苦しい状況でも社員エンジニアの数より受託の数を増やすことはNGであり、更に言うと理想的には受託人数が社員数の半分より小さくなるように採用すべきかと思いました。もしそれでも人数対工数の折り合いが付かないのであれば、常駐型だけではなくマネジメントを含めて外部委託会社に依頼する、そもそものリリーススケジュールを見直すか機能の削ぎ落としや簡略化を図るのが得策と思います。大事なので2度言いますが、単純に常駐型受託の人数を増やすのはマネジメントのリスクが大きくなります。あと、受託に重要な機能を任せると後々いなくなってしまった時に大変な事になるので、機能の重要度で委託するかどうかを考える事が必要だと思います。

紹介業者の戦略

僕も最初は受託を1人採用するのは紹介会社1社を経由するケースしか無いのかと思ったのですが、実際には間に紹介会社を2,3社挟むケースもあってその分受託サラリーのマージンが引かれているようです。このケースで美味しい思いをしているのは間にいる紹介業者だけであり、発注元は金額が高くなるし現場で頑張っているエンジニアの労は報われません。人材だけでなく仲介業全般での当然の話なんでしょうけど、このシステムってなんとかならないんでしょうか。受託の士気を上げる為にも常識的なマージンであって欲しいと強く希望します。


紹介会社は既に送り出している受託の人から都度現場状況をヒアリングして、更に人数を増やせるか、そしてどれぐらいのレベルのエンジニアなら長期採用されるのかというのを把握しています。紹介会社としても当然長く現場にいて欲しいという希望があるので、今求められているスキルと新たに送り出せる人のマッチング具合が気になるのだと思います。ある程度の採用単価が保証される事も当然前提の一つですが、ちゃんとした技術基盤があり高い目標を常に持ち続けられるいい環境という情報がうまく紹介会社側に伝われば優秀なエンジニアが来てくれる可能性は高まります。逆に炎上状態やスキル面での低レベル感が伝わると当然紹介会社もハイエンドな人材を送り出したいとは思わなくなってしまう。後者に嵌ってしまうと現場としては完全なる悪循環ですよね。

スポンサーリンク