「受託感」という言葉の正体

Webサービス企業においてありがちな言葉

「受託感が出てきた」

という言葉。受託のビジネスをされている方からすると受託感ってなにDisっってんの？と思われることでしょうが、現実的に、いろんな面接を通じて他社さんの話でも、どうしても出てきがちな言葉なのです。

これは何かと言うと、

・Nヶ月先を見通せない
・先を見た時の行動選択に対する裁量がない

と未来に対する裁量がないということにストレスを感じる時に出てきがちなのかなと思ったりします。

Webサービスでエンジニアをする人たちは、自らの選択可能性に対するプライドを持っていることが多いですし、組織としてもそれを期待しています。主に技術選択やソースコード等の品質、運用効率改善などがそれに該当しますし、当社のエンジニアリングマネージャであれば、チーム構成を成立させるための採用計画、採用したい人のスキルや人柄についても裁量を持ちます。（例えば、候補者の方が社で求めらる水準と完全にマッチしなくても、マネージャがどうにかしていくモチベーションが高ければ、その人の責任に賭けて採用することもあるわけです）

一方で、「どんなビジネスをする」とか「どんなサービスにする」という部分においては、ビジネスチームだったり、プロダクトマネージャの決定に委ねることが多いですし、そこにそもそもエンジニアがサービス設計等に参加する能力や興味があるかどうかは人によります。人によっては「なんでも作るから決まってから言ってくれ」という職人肌の人もいるわけです。

しかし、そういう中でも、情報の見通しが悪く、スケジュールや仕様が押し付けられがちみたいな状態になると、この受託感という言葉が出てきます。

特に受託の経験者で苦々しく思っているのは、プロジェクト全体の都合で、仕様に対する無茶な納期がすでに決まっていて、それをどうにかする裁量がないまま「言われたことを、ただ作る人」みたいに扱われることだったりします。正確には、スケジュールよりも仕様に対する納得感が得られていない、そして「もう決まってるから」と、ひっくり返すことができないことが「受託感」という言葉を使う原因なのではないでしょうか。

プロの一次請けの受託の人からするととばっちりみたいな表現ですが、業者の階層構造や、多重請負的なスキームにおいて一番嫌われている部分でもあると思います。

とはいえ、Webサービス企業においても、全員がすべての仕様決定やビジネスの決定に参加することは不可能です。例えば経営陣が決めたことを社員がひっくり返すというのは議論してよほどの穴でも存在しない限り、そのまま事業方針として進むことになるわけで、受託における発注主との関係とどこか近しいところはあるわけです。またパートナー社との契約においてスケジュールが定められていて、どうにかそこに間に合うように開発をしなきゃいけないということもまた存在します。

そもそも、それぞれのスキルが一致しないからこそ、チームが存在するわけで、プロダクトマネージャのプロダクト思想を、それ以外のデザイナーやエンジニアが理解できないことは多々あるわけです。

しかし、そういう現実があるからこそ、エンジニアやデザイナーには主体性を持って、このサービスをよくしていくために、その機能開発をするんだという気持ちを、プロダクトマネージャ、ビジネス、エンジニアリングマネージャ一同を通じて、しっかり握っていく必要がありますし、エンジニアリングマネージャ本人においても、未来の計画実現のためにどういう採用計画を実現することでチームを作っていくんだということを主体的に考え、行動していくことこそが、採用に対する力の入り具合にもつながっていくことを期待します。

組織設計においては、その先の見通しを全メンバーにどう抱いてもらうか？ということを考えていく必要があります。それぞれの趣味趣向で考えなくてもいい立場なら別にそれは各人におまかせしますが、少なくともエンジニアリングマネージャにおいては、まず自らが「受託感モード」に陥らないためのサービス全体の未来に対する状況把握を自らやっていく必要がありますし、それをメンバーに対してしっかり血を通わせていく努力をせねばなりません。

特に組織が大きくなってきた時に、見通しが悪いよねと思われてしまうのは、組織のアーキテクチャ設計と運用において絶対に避けなくてはなりません。常に「未来に対する裁量がないように見えてるのでは？」ってのは自問自答してみてはいかがでしょうか？！