システム開発業界の常駐神話について斬ってみる。

2019/09/09

筆者は、お客様企業だけではなく、同業の方からもお声掛けをいただく機会があります。しかしほとんどが「常駐」案件のため、お力になれずもどかしさを感じることが多々あります。当社のメンバーは、随時何らかの案件に携わっているため「常駐」という希望に応えられないからです。今回のコラムでは、その「常駐」の是非について迫ってみます。

エンジニアに「常駐」を求めるのは、そもそもどんな人なのか

筆者が同業の方から相談を受けた場合は「毎日のフルタイムは無理でも、週数回のペースなら現場に伺うことができるが、それならどうか？」と、一応はお聞きはしています。しかし結論「平日は朝から晩までフルに来て欲しい」が殆どです。相手の方も上からの商流に従って動いており、この条件に融通が効くことは殆どありません。

ところで「毎日朝から晩まで現場に来て一緒に仕事をして欲しい」という要求は一体誰が発しているのでしょうか？

ちなみにこの要求を分解すると、物理空間と時間の2軸がありそうです。いや、同じ場所にどれだけの時間そこに居続けるか、という価値観が根本にあるのかも知れません。

なお筆者が知る限り、事業部門のお客様の場合、常駐を求められることは殆どありません。エンドユーザーの立場としては、頼んだ仕事が完成さえすれば、作る人がどこで作業しようが、どれだけの時間を費やそうが、極端なところ興味が無いからです。それはそうです。自分たちが消費者として、誰かにモノを作って欲しいと頼んだときには、自分が期待した納期に予め約束された料金で完成すればそれで良いわけですから。

どうも筆者の感覚では、IT部門あるいは、お客様から委託を受けたITベンダさんからの要望事項として「常駐」が多いと感じます。ITに知見のある発注サイドには、なぜか常駐を求める傾向があるということです。知見があることが、作業プロセスを管理したいという事情につながっているのかもしれません。

語られることが殆どない「受入側における常駐のデメリット」

客先常駐については提供側、受入側の双方にとってメリットがある一方、実は問題が多い業務形態であることが様々に指摘されています。（以下参考として、外部リンク）

客先常駐エンジニアの抱える問題点。働き方改善の方法を解説
 IT業界の客先常駐とは | 一般派遣との違い・将来性
 IT業界が長い人間としてレビューしておく「ここ最近の客先常駐の実情」

上記はほんの一部の意見で、紹介した以外のところでも、提供側のデメリットについては、労務管理や自社への帰属意識の面で多々語られています。その一方で受入側の視点からの論調が見受けられないのが意外です。

確かにエンジニアを受け入れる側としては、被雇用人材を任意に調達できる、同じ物理空間に居てインタラクティブに業務指示ができるのでスムーズに協調できる、玉石混淆のメンバーを一律一定に管理できるなど、良いことづくめなのかも知れません。
しかし受入側にとっての常駐は本当にオールマイティな手法なのでしょうか？

次より他所で語られない「受入側目線でのデメリット」について見ていきます。

「常駐」によって受入側が失うもの

日本企業が、自社スタッフも外部スタッフも一緒に肩を並べて仕事をすべきという発想の裏側には、相手方に対して「あうんの呼吸」、「同質化」を求めるという行動習慣があります。「何となくそこは察して欲しい」というのが、同じ空間に居る時間が長ければ叶うことが増えてくるものです。

また同じ空間で過ごすことで、外部スタッフが常駐先の文化に慣れ親しんできて「風潮」と「論調」が同一化されてきます。このことは受入側のスタッフとしてはコミュニケーションコストを下げつつ、一定の会話品質を維持できる点で、一見はメリットに映るに違いありません。

しかしこのメリットは実は諸刃の剣と言わざるを得ません。チームで仕事をするにあたって「異質性」が大事といいます。異質なメンバーをうまくまとめることでアタマ数以上のパフォーマンスを出すのがチームワークの神髄で、特に外部スタッフとのコラボでは、自社からは出てこない発想を折り混ぜて昇華させるかが重要なのです。しかし外部スタッフにまで、同質化を求めてしまっては異質性が損なわれてしまいます。

おそらく受入先の本音は、自社スタッフの延長として、普段自分たちの開発ピークとして確保できないリソースを、そのプロジェクト期間だけキープしたいという思いがあって、その外部の人たちは暫定的に集めるわけなので、コンプライアンス的に見れば、自分たちの目が届くところに置きたい、ということなのでしょう。それ自体は良く分かります。

しかしビジネスとしては、それは良くありません。常駐は一般に高コストであり、ただでさえ見合うリターンが乏しいからです。そこに来て外部スタッフと協調することによって得られる付加価値まで殺してしまっては元も子も失います。

このことは、開発フェーズだけではなく、もっと上位工程の、たとえば調査や企画フェーズにおける「客観性」や「俯瞰性」が損なわれることにもなります。調査段階でのヒアリング能力についても然りで、何を聞くか、どう聞くかによって、調査の質が決まり、企画や要件定義の品質が決まります。ずっと同じ空間で同じ空気を吸うことと、企画や要件定義の品質が決まるわけではありません。自社のスタッフだけでは収まらない、外部の第三者を招いての最も大事な声を活かせないということなのです。

エンジニアに常駐を求めることと、優秀なエンジニアを確保したいという要求は相反する

さらにもうひとつ受入元にとっての盲点があります。エンジニアに常駐を求めるという行為と、優秀なエンジニアを確保したいという要求は矛盾するということです。そもそも優秀で周りからもそのように評価されているエンジニアは常に何らかの仕事を抱えており、フルタイムで身体が空いている人材はそもそも、自分たちが望んでいるような優秀なエンジニアである可能性は低いのです。

プログラミング作業は、能力によって生産性に差が出る、品質までを含めるとテストから手直しの手間を考えるとさらに乗数倍のインパクトがあり、まさに一騎当千の世界なのです。優秀なエンジニアのスキルを確保したいなら、企業は常駐させて空間と時間を管理するという考えを改めるべきでしょう。さらには「この仕事に週何時間ほど割けますか？」という質問もまったく無意味です。

「常駐」と「一昼夜におけるワークショップ」は似て非なるもの

ちなみに朝から晩までずっと打ち合わせが必要というなら、それはもはや「常駐」でなくて「ワークショップ」と定義すべきでしょう。何もかも常駐という概念の箱に収めて一緒くたにすべきではありません。

さらにいえば常駐の現場で、受入元と外部スタッフとが連日の朝から晩まで喧々諤々とディスカッションするようなシーンを私は見たことがありません。どちらかといえば熱いセッションはせいぜい半日くらいで、後は粛々と仕事をしていて、たまに思い出したように「そういえばあの件はどうですか」と呟いて、同じ空間に居る人がボツリと応えるというのがせきのやまでした。同じ空間でずっと過ごしていれば口数もどんどん減っていくのは仕方が無いことです。常駐を求めた割には、拍子抜けするくらい現場は粛々だったのです。

この議論のモデルケースとして、1970年に酸素タンクを損傷したアポロ13を地球に帰還させるというミッションの例はどうでしょうか。残された時間も、物資も限られた状況で、地上の管制官たちが力を尽くし合いました。このケースでは、お互いに顔を見ながらああでもない、こうでもないと、お互いの知恵をぶつけあって解決策を見出しました。同じ空間で議論するということが極めて大事であることに全く異存はありません。

しかしこのことは、来る日も来る日も朝から晩まで一緒に過ごすということとは、全く別軸なのです。つまり昼夜をまたぐようなワークショップと常駐を混同すべきではありません。

「量的」なマネジメントを要する案件は、実はほんの一握りかもしれない

ちなみに大勢が動くプロジェクトでは、知的活動の付加価値より、作業量で評価するほうが分かりやすいという事情もありそうです。玉石混交にならざるを得ない大規模体制で、でたらめや不正を防ぐためには、能力やモラルが低いほうに基準を合わせたマネジメント手法のほうが向くのかもしれません。

すなわち「量的」な管理をすべき案件では物理的に拘束したほうが好都合でしょう。しかしこのようなマネジメント手法はメガバンクのシステム再編など2次3次の委託先が500社以上集まるような巨大プロジェクトに当てはまるものです。大手元請ベンダが生み出した「常駐」という作業スタイルと「人月売買」の商習慣を、何も中堅以下のプロジェクトで周到する必要も無いわけです。

おそらく10億円以下のプロジェクトでは、常駐管理が正当化される理由は無さそうです。この辺のセグメントに融通が効くようになれば、IT業界はかなり風通しの良い業界になると思います。

この記事を書いた人について

谷尾薫

オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。