エンジニアとして働く場所が変わっても、私の中で変わらない軸があります。それは「最終的に誰のために作るのか」を忘れないこと。事業会社にいても、開発支援の立場にいても、この問いに向き合い続けることがエンジニアの本質だと、今は確信しています。
ずっと事業会社のエンジニアだった私が、開発支援の世界へ
Photo by Priscilla Du Preez 🇨🇦 on Unsplash
私はキャリアの大半を、いわゆる「事業会社」のエンジニアとして過ごしてきました。自社サービスのコードを書き、ユーザーの反応をデータで追い、プロダクトの成長を肌で感じながら開発する日々です。リリースした機能がユーザーに使われる瞬間の手応えは、今でも忘れられません。
そこから開発支援という形で外部のプロジェクトに関わるようになったとき、最初に感じたのは「構造の違い」でした。事業会社では、エンジニアは事業の当事者です。KPIを共有し、ユーザーインタビューにも顔を出し、「なぜこの機能を作るのか」を自分ごととして考えます。一方、開発支援の現場では、要件はクライアントやPdMから渡されることが多く、エンジニアはその実現を担う役割として位置づけられがちです。
ただ、少し経験を積んでわかったのは、構造が違うだけで、本質は変わらないということでした。どちらの現場でも、最終的にそのプロダクトを使うのはエンドユーザーです。その人たちの課題が解決されなければ、どれだけ美しいコードを書いても意味がない。この当たり前のことを、改めて言語化できたのは、開発支援という立場に移ってからでした。
エンジニアの本質は「誰のために作るか」にある
Photo by Kaleidico on Unsplash
開発の現場では、さまざまな「依頼者」が存在します。PdMが機能要件を定義し、クライアントがビジネス要件を持ち込み、エンジニアはその間でコードを書く。この構造の中で、エンドユーザーの存在は意外と遠くなりがちです。
あるプロジェクトで、こんな経験をしました。クライアントから「この画面に項目を10個追加してほしい」という依頼が来たとき、私は一度立ち止まりました。追加される項目のほとんどは、管理側の都合で必要なデータであり、実際にその画面を使うのは現場スタッフでした。10項目を一度に入力させることで、現場の作業負荷が大幅に増えることは明らかでした。
そこで私はクライアントに確認しました。「この画面を使う方の業務フローを教えてもらえますか？」と。結果として、10項目のうち6項目はバックエンドで自動補完できることがわかり、現場スタッフが入力するのは4項目だけになりました。クライアントの要望は満たしつつ、エンドユーザーの負担は最小化できた。このとき、「エンドユーザーを起点に考える」ことの具体的な意味を実感しました。
PdMやクライアントが間違っているわけではありません。それぞれの立場で、それぞれの情報と責任を持って判断しています。ただ、エンジニアが「実装の専門家」として加わるとき、エンドユーザーの視点を持ち込める人間がいるかどうかで、プロダクトの質は変わります。その役割を担えるのは、実際にシステムの動きを把握しているエンジニアだと私は思っています。
開発支援という立場でも「物申す」エンジニアでいたい
Photo by Kelly Sikkema on Unsplash
言われた通りに作るだけでは課題は解決しない
「要件通りに実装する」ことは、エンジニアの仕事の一部です。でも、それだけでは課題解決にはならないことがあります。要件そのものが、本来の課題を正確に捉えていないケースがあるからです。
開発支援の立場では、クライアントの意向に従うことが基本姿勢になりがちです。それは関係性を維持するうえで大切なことでもあります。ただ、「従う」と「思考停止」は違います。要件を受け取ったとき、「これを実装するとエンドユーザーはどう感じるか」「この仕様で本当に課題は解決されるか」を自分なりに考え続けることが、外部のエンジニアとしての誠実さだと私は考えています。
クライアントへの提言と、エンドユーザーへの誠実さを両立する
「物申す」といっても、批判や否定ではありません。私が心がけているのは、代替案とセットで伝えることです。「この要件には懸念があります」だけでは、クライアントにとっては困惑でしかありません。「こういう理由で懸念があり、こういう実装の方がエンドユーザーにとって使いやすいと思います。いかがでしょうか」という形で伝えることで、提言は建設的な対話になります。
このスタンスを続けていると、クライアントから「また相談したい」と言われることが増えてきました。技術的な実装力だけでなく、「この人に話すと視点が広がる」と感じてもらえるようになると、関係性の質が変わります。エンドユーザーへの誠実さが、結果としてクライアントとの信頼につながる。この循環を実感しています。
事業主の課題を理解することがエンジニアの競争力になる
Photo by Vitaly Gariev on Unsplash
技術力だけでなく「事業理解」が差別化につながる
開発支援の市場では、純粋な技術力だけで差別化することは難しくなっています。同等のスキルを持つエンジニアは多く、AIツールの普及によってコーディングそのもののハードルも下がっています。
そのなかで私が感じる差別化のポイントは、「事業主の課題を理解する力」です。クライアントがなぜそのシステムを作りたいのか、どんなビジネス上の問題を解決しようとしているのか。この文脈を理解したうえで開発に関わると、提案の質が変わります。
事業会社でのエンジニア経験は、この点で大きな財産になります。KPIを追いながら開発した経験、ユーザーの声を直接聞いた経験、機能の優先順位をビジネス視点で判断した経験。これらは、外部のエンジニアとして関わるときに「事業の言語で話せる」強みになります。
技術的な実装力と事業理解の両方を持つエンジニアは、クライアントにとって「外注先」ではなく「一緒に考えるパートナー」として機能します。この違いは、長期的な関係性にも、報酬にも、仕事のやりがいにも影響してくると感じています。
まとめ：場所が変わっても、軸はブレない
Photo by Jefferson Santos on Unsplash
事業会社から開発支援へ。働く環境が変わり、関わる人が変わり、プロジェクトの構造が変わっても、私の中で変わらないことがあります。それは「エンドユーザーの課題解決を起点に考える」という姿勢です。
PdMもクライアントも、それぞれの役割で大切な仕事をしています。エンジニアはその中で、実装の専門家として、そしてエンドユーザーの視点を持ち込める存在として関わることができます。言われた通りに作るだけでなく、「本当にこれでいいか」を問い続けること。それが、どんな立場にいても変わらないエンジニアとしての誠実さだと思っています。
場所が変わっても、軸はブレない。このシンプルな言葉が、今の私の働き方の根っこにあります。もしこの記事を読んで、自分のエンジニアとしての軸を少し見直すきっかけになったなら、書いた甲斐がありました。
よくある質問（FAQ）
事業会社エンジニアと受託・SESエンジニアの本質的な違いは何ですか？
構造上の違いは確かにあります。事業会社では事業の当事者としてKPIや戦略に関わりやすく、受託・SESでは要件を受け取って実装する役割になりやすい。ただ、私は「本質的な違い」はそこにはないと思っています。どちらの立場でも、最終的にプロダクトを使うエンドユーザーのことを考えながら開発できるかどうか。その姿勢の有無が、本質的な差だと感じています。
開発支援・受託開発の現場でエンドユーザー視点を持つにはどうすればいいですか？
一番シンプルな方法は、「誰がこの画面を使うのか」を具体的にイメージする習慣を持つことです。要件を受け取ったとき、その機能を実際に操作するユーザーの業務フローや感情を想像してみる。可能であれば、クライアントにエンドユーザーの業務を教えてもらう機会を作るのも有効です。外部のエンジニアだからこそ、「教えてください」と聞きやすい立場でもあります。
PdMやクライアントの意向と、エンドユーザーの利益が対立したときどう対処しますか？
「対立」と捉えるより、「情報の非対称性」として捉えるようにしています。クライアントやPdMがエンドユーザーにとって不利な要件を出すとき、多くの場合は悪意ではなく、エンドユーザーの実態が見えていないことが原因です。そのため、私は「こういう使われ方をするとこんな問題が起きそうです」という形で情報を補う役割を担うようにしています。最終的な判断はクライアント側にありますが、判断材料を増やすことはエンジニアにできる誠実な行動だと思っています。
事業会社出身のエンジニアが開発支援・フリーランスに転向するメリットは何ですか？
事業会社での経験は、開発支援の現場で「事業の言語で話せる」強みになります。KPIや優先順位の判断、ユーザーの声を踏まえた開発経験は、クライアントとの対話の質を上げます。また、複数のプロジェクトに関わることで、さまざまな業界・事業モデルへの理解が広がるのも転向後の魅力の一つです。ただし、自己管理や営業面での課題もあるため、メリットだけを見て判断するのは慎重にした方がよいと思います。
「物申すエンジニア」として信頼を得るためにはどんなスタンスが必要ですか？
私が大切にしているのは、「代替案とセットで伝える」「相手の立場を理解したうえで話す」「批判ではなく問いとして投げかける」の3点です。「この要件はおかしい」と言うより、「この要件だとエンドユーザーにこういう影響が出そうですが、こういう実装ではいかがでしょうか」と伝える方が、対話が生まれやすい。信頼は一度の提言で得られるものではなく、こうした積み重ねの中で育まれるものだと感じています。
