kazu22002の技術覚書

PHPerでありAWS好きの、うさぎ年のエンジニアの日々

IT業界においてサービス脳と受託脳ってあると思う

IT系での自社サービスを作る人と、受託中心の人とでは考え方にかなり違いがあると思っています。

サービス脳は、自社サービスを中心に仕事をしている人。

受託脳は受託案件が中心で仕事をしている人です。

個人的なサービスと受託の違いです。

納期

受託の場合は、最初に機能と納期を決めています。納期に間に合うように十全の機能でリリースします。

そのため機能が増えることに対して敏感になります。少しの変更でも懸念事項になり、納期に間に合わない可能性がでるためできないと拒否をする必要が重要になります。

また機能についても余計な機能を追加することも難しいです。

サービスの場合は早ければ早いほどいいです。ただし良い物を作れるのであれば、時間を伸ばすことも可能ですし、一部のみリリースして反応をみることも可能です。

自分たちで目安を決める必要がありますが、個人的には速さと根本の機能性が重要だと思います。わかりやすさは反応しだいで良くすることは可能です。

やっぱり違いとしては、機能追加時の反応ですね。

受託の場合は拒否した方がいいことが多く、サービスの場合はすぐやる方がいい。

見積もり

見積もりはいつになったら変わるのでしょうね。

開発がウォーターフォールからアジャイルスクラムの方が採用されているのに、見積もりについては変わることがない。難しいです。

受託は最初に金額しだいで機能が決めます。

そして追加機能に対して、再見積もりや追加見積もりが必要になるから時間がかかりますね。この時間が個人的には無駄にしか見えないため、受託の発注側はぜひお金が発生する覚悟で依頼してください。

サービスの場合は自社の判断しだいです。将来的にペイができれば、作る判断ができます。

ある程度の見積もりで自社内で完結できるので、手間はそれほどでもないと思います。資金に余裕があればですが。

受託の場合は、発注側の意志で、サービスの場合は会社の判断です。

不具合 瑕疵

受託の場合は、不具合をできるだけない状態にして納品する必要があります。納品後に問題があれば瑕疵になります。

試験に時間をかける必要は理解できます。

サービスの場合は、不具合があったとしてもすぐ対応することで問題にならないようにすることもできます。その分、リリースの速さを意識して仕事をする必要があると思います。

不具合が信用問題に繋がるのはどちらも同じですが、サービスのほうは根幹機能に問題がなければ新規機能の追加については改善として見逃してもらえることもあると思います。その分、いいサービスにする必要がありますが、圧倒的にチャレンジできる分野だと思います。

サービス脳と受託脳の違い

受託脳

  • アサインされてからのみ動く(自分の仕事をもってないからね)
  • 言われた通りのところまでしかやらない(やれないの方が正しいかも)
  • 機能追加の話に敏感であり、否定的(同じ工数で仕事が増えるだけだからね)
  • 問題は発注側(自分事ではないからね。発注者が動かないと変えられないことあるしね)

サービス脳

  • 必要や面白いと思ったら動く
  • よりいいものを目指す
  • 機能の内容次第で動く
  • 問題は自分(自分で考えて改善への手がうてるため)

本当は受託案件も一緒にいいものを作るパートナーとして動ければいいですが、お金の問題があるので、難しいですね。

おなじ会社のグループ的なのなら、受託発注の感覚でなく、一緒にサービスを盛り上げるパートナーとして仕事がしたいですね。

個人的には受託脳の人からサービス脳にするのはものすごく難しいです。

意識の違いだけですが、受託として必須の交渉や断る能力の使いどころが変わるためいままでの仕事の仕方が変わるため抵抗がどうやらあるみたいですね。

このあたりは向き不向きがあるとおもっているので、自分の合う方で仕事をしたほうが良いと思います。合わないとおもったら上司に異動を願い出ることをお勧めします。

サービス運営の仕事をサービス脳の人と受託脳の人で行うと、合わなすぎて進まなくなるので早めに撤退していただきたいですね。

合わせられる人はこの違いを理解している人だと思います。

自分に合っている仕事を見つけてください。