エス・エム・エス BPR推進部 キャリア横断開発グループ データ基盤チームの手塚と申します。2024年9月に当社に入社し、早くも半年が経過しました。
この記事では、私自身が実際に感じたことを「仕事の進め方」と「文化」の2つの観点からご紹介します。SIer・SES企業から転職を検討している方、またはエス・エム・エスに興味をお持ちの方にも、参考になる情報をお届けできれば幸いです。
経歴
前職ではSESエンジニアとして、BI画面開発やデータ連携（ETL）の開発業務に携わっておりました。SES（System Engineering Service）とは、契約期間に基づき、クライアント企業に対してエンジニアの技術力や専門スキルを提供するサービスです。具体的な働き方としては、お客様の要望や課題をヒアリングし、それを基にシステム開発を行い、納品、運用、保守まで一貫して担当していました。
SESと自社開発（エス・エム・エス）の違い
仕事の進め方
仕事としての関わる範囲・人
まず、入社して感じたことはエンジニアとしての役割が非常に広い点です。
私の所属するデータ基盤チームでは、「社内のデータ活用の推進」を目的の一つとして、日々多種多様な案件に対応しています。例えば、半日で対応可能な簡単な案件から、1年以上を要する大規模プロジェクトまで、案件の規模は様々です。
また、キャリア横断開発グループに所属していることから、担当する案件も単一のサービスに留まらず、エス・エム・エスが展開する多岐にわたるサービス群に及びます。そのため、社内外の多くの関係者と連携しながら業務を進める必要があり、関係者との調整や意思決定に苦労する場面も少なくありません。ですが、その分、自らの仕事が会社全体の事業に貢献しているという当事者意識と、大きなやりがいを感じることができます。
（オレンジ箇所がキャリア横断開発グループとして対応しているサービス領域）
一方、前職のSESでの働き方は、プロジェクト全体のごく一部分のみを担当することが多く、担当領域が限定されていました。そのため、関わる社内外の関係者や部署も固定化され、プロジェクトによっては、リーダー層の方のみがお客様と直接コミュニケーションを取り、現場のエンジニアは、プロジェクト開始時と終了時の挨拶以外、お客様と直接会話する機会がほとんどないケースもありました。
開発手法・仕様の決まり方
開発手法も異なっていました。前職ではウォーターフォール開発が主流で、要件定義→設計→開発→テスト→リリースと必ず前工程が完了してから次の工程に進んでいました。
対して、データ基盤チームではアジャイル開発を採用しており、一連の開発工程を短期間で繰り返します。ウォーターフォール開発は、経験の浅いエンジニアにとっては、各工程でやるべきことが明確で進めやすいというメリットがあると感じていました。しかし、開発に時間を要するため、成果物がなかなか目に見える形にならない点や、リリース直前にお客様からのフィードバックによって大幅な手戻りが発生し、モチベーション維持が困難になる点が課題でした。
アジャイル開発では機能単位のリリースで改善が実感でき、ユーザ側にも成果物の共有がしやすく、反応が感じられる点が非常に良いなと感じてます。
また、仕様の決定プロセスも大きく異なります。前職では、仕様は基本的にクライアントからの要求に基づいて決定されるため、私たちから積極的に提案を行う機会は限られていました。しかしながら、エス・エム・エスのような自社開発企業では依頼者が身内なこともあり、直接業務担当者とコミュニケーションを取りやすく、仕様についても柔軟に決定することが可能です。データ連携の仕様についてもエンジニアから提案する場面をよく見かけます。
キャリア横断グループと前職の仕事の進め方の違いをまとめると以下の表のような感じです。
| キャリア横断グループ | SES（私の前職） | |
|---|---|---|
| 関わる範囲 | 複数サービス | プロジェクトの一部 |
| 関わる人 | 複数の担当者 | 固定の担当者 |
| 開発手法 | アジャイル | ウォーターフォール |
| 仕様の決まり方 | 柔軟に決定 （こちらからも提案） |
基本的にクライアントからの要求で決定 |
文化
企業文化として重要視していること
企業文化についても、前職とエス・エム・エスとでは大きな違いがあると感じています。
まず、最も大きな違いとして感じたのは、業務において重要視していること（目的）です。前職のSES企業では、SIer・SES企業ではよくあることかもしれませんが、「開発すること」自体が目的化しており、お客様からの要望に「いかに応えるか」に焦点が当てられていました。また、SES契約という契約期間に制約がある働き方であったことも影響し、プロジェクトに関わるフェーズによっては、プロジェクトの成功よりも「納品すること」が目的となり、お客様がそもそもなぜシステム開発を依頼したのか、という根本的な課題にまで目を向けることが難しかったと感じる場面もありました。
エス・エム・エスでは、目の前の案件に対し、本質的な解決を目指す姿勢が強く感じられます。例えば、MTGでエンジニアが「この課題は、必ずしもシステム開発をしなくても、スプレッドシートの機能だけで解決できそうですね」と発言し、実際に開発せずに課題解決を目指す場面がありました。その時は、非常に感銘を受けました。
私の所属するBPR推進部のミッションは、「成長と変化を促進するビジネス基盤を構築することで、価値提供先の本来業務への集中を実現し、会社と事業の成長に貢献する」ことです。そのため、開発という手段に固執せず、ユーザー自身で解決できる課題は、その方向でサポートするという姿勢を目の当たりにし、前職との文化の違いを強く感じました。 前職では、お客様の要望によって仕様が決まる場面が多く、その要望に対し「既に決まっていることなので」と、半ば思考停止の状態で業務を進めざるを得ないこともありました。（いつしか自分自身もその状況に慣れてしまい、このままではいけないと感じたのが、転職を考えたきっかけの一つです。）
社内コミュニケーション
社内コミュニケーションの質に大きな違いを感じています。
前職では、Teamsが導入されていたものの、活用方法は業務連絡が中心で、雑談などのコミュニケーションはほとんどありませんでした。原因として、エンジニアが別々のプロジェクトに派遣される働き方のため、コミュニケーションが同じプロジェクトのメンバーに限定されていたことが挙げられます。また、他のメンバーの業務内容やコミュニケーションは、上長クラスでなければ把握できない状況でした。
そのため、プロジェクトは異なっていても同様のツールを使用しているケースがあるにも関わらず、情報共有がスムーズにいかないことがありました。社内全体として、勉強会や共有会などの活発な情報交換の場を設けづらい環境だったと、今振り返ると思います。
一方、キャリア横断グループのエンジニア内では、雑談から仕事の相談まで、活発なコミュニケーションが行われています。Slackのオープンチャンネルを通じて異なる部署のやり取りを知ることができ、他部署のメンバーにも気軽に質問できる場面が多く見られます。
また、データ基盤チーム内のコミュニケーションも活発です。朝会の「100の質問」や、レトロスペクティブ、勉強会など、定期的な共有の場が設けられています。そのため、他のメンバーの業務内容が見えやすく、情報共有が非常に円滑だと感じています。
私自身、入社して4か月後に他部署の人を交えて読書会の開催ができました。このような活動ができたのも、キャリア横断グループの活発なコミュニケーション文化のおかげだと感じています。
キャリア横断グループと前職の文化の違いをまとめると以下の表のような感じです。
| キャリア横断グループ | SES（私の前職） | |
|---|---|---|
| 重要視していること | 課題解決にフォーカス | クライアントの要望にフォーカス |
| コミュニケーションレベル | 雑談～仕事の相談まで | 基本的に業務連絡のみ |
| コミュニケーションの頻度 | 複数回/週 勉強会も定期的に開催 |
不定期 |
さいごに
自社開発企業とSESとの違いを仕事の進め方や文化という観点から違いを述べさせていただきました。個人的に感じた最も大きなギャップは、重要視していることが「課題解決」であるのか「お客様の要望」であるのかです。課題を解決できれば手法にこだわらない姿勢は自社開発企業に合っている方だと感じますし、エス・エム・エスには楽しめる環境が揃っていると思います！
また、エス・エム・エスは新しいメンバーを募集しています。 私達データ基盤チームでは、データ基盤の運用から、データパイプラインの開発、データマートやダッシュボードの開発、AIを用いたソリューションの提供など様々な業務を通して事業を支援しています。これまでの取り組みは別記事でも発信しておりますので、以下ページもご覧いただけると幸いです。
tech.bm-sms.co.jp tech.bm-sms.co.jp tech.bm-sms.co.jp
エス・エム・エスの事業に携わってみたい方、BPR推進部へ興味のある方は、ぜひこちらのページものぞいてみてください。
