🏄‍♂️

受託開発会社から自社開発会社に転職して感じた3つの違いと適応戦略

2022/03/10に公開

背景

こんにちは。株式会社ペライチ のフロントエンドエンジニアの藤代です。

今から約 1 年前、 5 年ほど勤めた東京都内の小さな Web 制作会社から現職に転職をしました。

前職では、受託での Web 制作やシステム開発に携わっていたほか、短期的に SES(システムエンジニアリングサービス)などで自社開発会社の現場やオフショア開発の現場なども経験していました。

いわゆる、受託畑の人間です。

本記事では、著者が自社開発会社である現職のペライチ社に入社してから感じた違いをまとめています(違いとはカルチャーショックと言い換えても良いかと思っています)。

そして、それらの違いに対して私自身がどのように適用していったのかという、カルチャーショックへの適応戦略についても自分自身の備忘録的に記載します。

  • 同じ IT 業界にいるけれど、全然カルチャーが違いそう。
  • 応募したい会社のビジョンには共感してるから転職にチャレンジしてみたいけど、カルチャーショック乗り越えられるのだろうか。
  • 周りに自社開発会社の人がいないから相談できないんだよなあ。

上記のような、受託開発会社から自社開発会社への転職を検討している方の一助となれば幸いです。

※本記事は受託開発 vs 自社開発どちらが良いのかという議論をしたい訳ではありません。
※ 20 代後半の Web 系の受託開発会社でチームリーダーくらいを経験したフロントエンドエンジニアが本記事の執筆者という前提もご承知おきください。
※自社開発といいつつ、「受託開発会社からペライチ社に転職して感じた違い」という部分も多分に存在する点はご容赦ください。

受託開発会社から自社開発会社に転職して感じた3つの違い

questionat

私自身が感じた 3 つの違いについて下記 3 つの観点で整理します。

  • 事業理解・顧客理解について。
  • 開発体制について。
  • 仕事と技術への向き合い方について。

(1)顧客解像度がいやおうなしに上がった

ペライチ社には営業がいません。
だからという訳でもないですが、自然とユーザに向き合うという機会と意識が生まれました。

詳しくは私の記事よりも、下記記事をぜひご一読ください。
https://type.jp/et/feature/18000/

過去

社長ないし、営業が受注した案件に対して、いかにして予算と期間内に安全に納品するのか。その点に目線が向かっており、 Web サイトやシステムのエンドユーザへの顧客理解は皆無でした。

むしろ、社長と営業の人となりに対する解像度はとても高くなっていました。

発注していただいたお客様の社内に開発リソースがないからこそ、外部の受託開発会社に相談いただいていた訳です。エンドユーザの顧客解像度が低かったのはいちエンジニアとして反省しきりです。ただ、当時はなかなか顧客解像度が上がりにくい環境であったことは確かな事実かなと感じています。

現在

ペライチ社には営業がいない分、エンジニアが主体となって推進しているプロジェクトが数多くあります。

もちろん、トップダウンでのプロダクト方針が決定されていきますが、ボトムアップで「ユーザ目線をもってプロダクトをよくしていこう」というカルチャーがあります。また、人事制度もそれを後押しする設計となっています。

また、自分自身が携わる機能開発において、営業が回答を持っているわけではないので、回答はユーザにしかありません。したがってエンジニアとしても顧客解像度が高められている、または高めざるを得ない環境になっていると感じています。

(2)アジャイルが実現可能な開発体制であることを知った

「アジャイル開発なんて無理なのでは?」と受託開発の現場にいたときには割と本気で思っていました。でも、ペライチ社ではアジャイル開発できています。

過去

基本的にウォーターフォールモデルでの開発でした。そして、受託で作ったら作りきり、保守があればスポットでという形態が主でした。また、繁忙期・閑散期があり、めちゃくちゃ働いた後しばらく暇になるからまとめて休暇を取る、といったこともあったと記憶しています。

ご多分に漏れず、デスマーチ的な経験もあり、当時は「世の中アジャイルアジャイル言っているけれど、そんなのありえるの?」と割と本気で思っていた記憶があります。井の中の蛙大海を知らずですね。

もちろん、受託開発だからアジャイル開発ができないとは今となっては思っていません。

ただ、当時は「アジャイルでプロダクト価値を高める方法すら知らず、それをお客様と交渉する知識もなく未熟だったなあ」と反省するところではあります。

現在

チーム全体として、基本的に 2 週間のスプリントによるスクラム開発を実施しています。
詳しくは弊社 CTO の香月が書いた下記記事を参照ください。
https://qiita.com/katsukii/items/a37b0afc9cc37d512ecb

もちろんまだまだ成長段階のベンチャーなので完璧なスクラム開発ではありませんが、ユーザに価値を継続的に届けるため、開発体制そのものも含めて日々改善が繰り返されています。

体制含めて、「イケてないと思ったら、開発体制含めて改善することを良しとする」という至極当たりで大切なマインドが共通認識として存在するなと日々感じています。

(3)責任範囲が増えて、 1 つの技術やドメイン知識に対して向き合う時間も増えた

エンジニアが積極的に機能開発をリードするカルチャーがあり、自身の開発プロジェクトに対する自由と責任が与えられていると感じています。

過去

受託開発ということで、ゼロベースでの Web サイト開発やシステム開発多かったため、採用技術についてはクライアントが許す限り自由かつ、負債の返済なども気にすることがあまりありませんでした。しかしながら、開発要件などについては裁量権は少なく、いかにして要件通りの開発を期間内に実施できるのか、という点に目線が向いていたと感じています。

SES なども短期で現場を転々とすることが多く、 1 つのドメイン知識に対して向き合うというよりも、色々な現場を経験できるため、「飽き性な私には割と向いているのでは?」とその当時は思っていました。

現在

ベンチャー企業だからという側面もありますが、手を上げさえすれば、自身が担当するプロジェクトにおいては要件定義から実装まで、担当可能です。小さな規模から、自身のプロジェクトへの裁量(具体的には要件の作成やデザインの作成・開発方法などの方針の決定など)があると感じています。また、各メンバーが PdM や PjM 待ちすることなく各々の関連領域に侵食してプロジェクトを推進しています。

ちなみに、技術については長期間運用されているプロダクトのため、一度採用した技術に対して長期間向き合う環境です。全くのゼロベース開発は受託に比べれば少ないため採用技術の制約が存在するのは自社開発会社の特徴だと感じています。

違いへの適応戦略

koumei

ここまで、違いについてまとめてきましたが、これらの違いは決してネガティブなものでなく、ペライチ社のビジョンである「テクノロジーをすべての人が使える世界に」を達成するために必要な要素だと感じています。

とはいえ。

  • 受託開発自体のように営業解像度ではなく、顧客解像度を高める必要がある。
  • 今までと開発体制が違うチームにどうやってジョインするのか。
  • 自身の開発に対して裁量がある分、自分で決めるところは決めないといけない。

など受託畑から来た自分にはカルチャーショックと向き合っていく必要がありました。
最後に、ここ1年自分がこれらのカルチャーショックに対してどのように向き合ってきたのかを記載して終わりにします。

(1)とりあえずユーザインタビューを見る・出る

ペライチ社ではユーザ様の意見をヒアリングするユーザインタビューの機会が多数設けられています。普段の業務フローでは PO 層やデザイナー層の出席が多いですが、エンジニアにもオープンに場が開放されています。

動画や議事録などのアーカイブなども基本的に全て社内でオープンに共有されています。
業務にある程度慣れてきたタイミングで自身が関わる領域にインタビューにはエンジニアといえども出席し、アーカイブを視聴するようにしていました。

営業目線ではなく、ユーザ目線を養うために日々精進しています。

(2)アジャイル開発はやってみれば慣れるというマインドで参加する

アジャイル開発については、やってみれば慣れるのマインドで向き合うようにしました。

言い換えると、今までの自分の仕事の進め方に固執することなく、まずは波に乗ってやってみるような精神でジョインすることで、チームに馴染むことができたと感じています。
逆に言えば流れに乗るだけでアジャイルできるスクラム開発の仕組みはよくできていると感じています。

また、困ったことがあればすぐにチームの SM(スクラムマスタ)に相談できるので、習うより慣れるのマインドでオンボーディングしました。

なお、弊社のスクラムの進め方については弊社スクラムマスタの東の書いた記事もあるのでぜひご一読ください。
https://zenn.dev/peraichi/articles/01fwx41dntshf0jyt9eezcnvvv

(3)まずは自分が出来る小さな範囲からオーナーシップを持つ

最後はオーナーシップを常に持つように意識したことです。とはいえ、視座を高くしてプロダクトに全体に対してオーナーシップを持つなんてことはできません。

  • まずは自分の担当する小さな機能の領域からエンジニアリングだけじゃなくてユーザ目線で UI / UX を考えて提案してみる。
  • 自分が機能リリースした内容でユーザからバグ報告があればサポート対応をしてみる。

そんな小さなオーナーシップから持つことを意識することで、受託カルチャーから自社開発カルチャーに馴染むことができつつあるように考えています。

まとめ

前職とペライチ社の違いと自分がその違いに向き合うため、実施した適応戦略についてご紹介しました。

入社してから1年、まだまだビジョン達成のために自分のマインドを変えていかないといけないと思いつつも、結果的に現在楽しく開発できているのが一番の成果かなと思っています。

本記事が受託開発会社から自社開発会社への転職を検討している方の何かしらの参考になれば幸いです。


▼採用情報

受託開発から自社開発会社に興味あるなーと思ったそこのあなたに朗報です!

現在エンジニア募集しています!

▼ 選考をご希望の方はこちら(募集職種一覧)。
https://hrmos.co/pages/peraichi/jobs?category=1629135637016141824&utm_source=techblog&utm_medium=referral&utm_campaign=article-01fxprnr3mp75yey0mjz6gxebn

▼ まずはカジュアル面談をご希望の方はこちら。
https://hrmos.co/pages/peraichi/jobs/0000029?utm_source=techblog&utm_medium=referral&utm_campaign=article-01fxprnr3mp75yey0mjz6gxebn

募集中の職種についてご興味がある方は、お気軽にお申し込みください(CTO がお会いします)。

ペライチ

Discussion