はじめに
この記事はLinc’well Advent Calendar 2025の6日目の記事です。
私は現在、株式会社Linc’wellでエンジニアとして働いています。
前職ではエンジニア5名ほどの少人数の開発チームに所属し、要件定義から実装、テスト、保守運用まで、文字どおりワンストップで担当していました。
現在は、PdMやSREを含む複数の専門領域が関わり、チーム横断で進めるプロダクト開発に携わっています。
規模だけでなく、働き方・意思決定の流れ・コミュニケーションの前提が変わることで、日々感じる変化も大きくなりました。
この記事では、少人数の受託開発からチーム横断のプロダクト開発へ移ったことで実感した、開発文化の違いを整理します。
前職：少人数の受託開発チームでの働き方
前職はBtoBの受託開発と自社開発を両方行うチームで、エンジニア5人のうち3人は自社開発、私と上長の2人が受託開発を担当していました。
私たちは、自社製品をクライアント向けにカスタマイズする案件を中心に、プロジェクト全体を少人数で回していました。
特徴
-
全工程を一気通貫で担当
私と上長が要件定義から運用までの全工程を担っていた -
自社製品のカスタマイズ中心
自社プロダクト理解と要件調整の両方が求められた -
ウォーターフォールベース
基本はウォーターフォールだが、現場に合わせてプロセスを調整する場面も多かった -
意思決定がシンプルで早い
私と上長の2人で直接話し、その場で方針を決めることが多かった -
評価は社長が行う
少人数ならではのシンプルな評価体制だった
現職：チーム横断で進めるプロダクト開発
現職では、PdM、SRE、各開発チーム、QAなど専門領域が明確に分かれた体制で開発が進みます。
一つのプロダクトでも関わるメンバーが多様で、多角的な視点から議論を重ねながら進行します。
特徴
-
BtoBtoCサービスで、影響範囲が広い
リリース後の反応がエンドユーザーに直結する -
スクラムをベースにした開発プロセス
現職ではスプリントを区切りに計画し、振り返りながら進めるスクラムが採用されている 1 -
PdMとの協働が中心にある
企画背景を共有し、優先順位を議論しながら開発を進める -
全国からフルリモート参加しているメンバーがいる
Slackやドキュメントが中心となり、非同期でのコミュニケーションが多い -
半期ごとの明確な評価制度
評価軸が言語化されており、振り返りがしやすい
意思決定の仕方の違い
前職では、私と上長の2人で判断することが多く、コミュニケーションの距離がとても短い環境でした。
プロジェクトの背景理解も共通しているため、「その場で話してその場で決める」ことが自然でした。
一方、現職では、PdM、SRE、他の開発チームなど関係者が増え、意思決定はより立体的になります。
複数の視点を踏まえて議論する必要があり、その分ドキュメントや非同期での認識合わせが重要になります。
この変化を通じて、私は「個人や少人数の判断」から「組織全体としての判断」へと前提が変わったと感じています。
Slackと情報量の違い
前職では、対面コミュニケーションが中心で、困ったときはまず近くの上長に聞くというスタイルが定着していました。
Slackはあくまで補助的な手段で、情報量もそこまで多くはありませんでした。
現職では、少し席を外すと未読が積み上がっていることも多く、最初はその情報量に戸惑いました。
ただし現職では、
-
チャンネルごとに役割が明確であること
-
ドキュメント文化が浸透していること
-
非同期で議論や情報共有が行われる場面が多いこと2
といった特徴があり、情報が多いのは「多職種で協働するための土台」だと感じるようになりました。
文化の違いを通じて感じたこと
転職を通じて、私は「組織の人数」や「プロダクトの性質」によって、求められる働き方が大きく変わることを実感しました。
少人数の受託開発では、幅広い工程を素早く横断しながら動く力が身につきました。
一方で、チーム横断で進めるプロダクト開発では、プロセスやドキュメントによる再現性、
多様な専門性をつなげるための透明性が求められます。
どちらが良いという話ではなく、
どちらの経験も、私の成長にとって欠かせなかった
と強く感じています。
おわりに
少人数の受託開発で培った全体を俯瞰しながら動く力は、現職でも役立っています。
一方で、チーム横断で進める開発の中では、これまでにない協働の形やコミュニケーションを学ぶ機会も多く、環境が変わることで視界が広がる実感があります。
これからも、両方の文化で得た経験を糧にしながら、エンジニアとしての歩みを進めていきたいと思います。