SIer出身のプロマネが語る、事業会社のアジャイル開発現場で感じたリアル
はじめに
こんにちは、横浜銀行アジャイル開発チームのKJです。
私はこれまでSIerでウォーターフォール型のシステム開発に携わってきました。
いわゆる「元請けSIer」と呼ばれる立ち位置に属することが多い会社に所属していたため、上流工程やプロジェクトマネジメント業務がメインでしたが、現在はアジャイル開発チームにエンジニアとして入社し、実際に手を動かして開発に携わっています。
本記事では、「SIerから事業会社へのキャリアチェンジ」や「ウォーターフォールからアジャイル開発への移行」という文脈で、私が実際に内製化の現場に入って感じた変化をまとめています。SIerと事業会社の違いに関心のある方や、似たようなキャリアチェンジを検討している方の参考に少しでもなれば幸いです。
SIerから事業会社へ移っての気づき
コミュニケーションが速い
比較的大規模なシステム開発では、マルチベンダ方式が採用されることも多く、SIer同士のコミュニケーションが発生します。その際、やり取りが責任分界に関わることもあるため、回答はスピードよりも正確性が重視される傾向があると感じていました。
私が携わっていたプロジェクトは階層構造が明確で、簡単な相談であっても「委託元SE → 委託先チームリーダー → 委託先エンジニア」と経路が長くなることが一般的でした。そのため、どうしてもスピード感のあるコミュニケーションが難しい場面が多かったと感じています。そうした環境で育った私にとって、横浜銀行に入ってまず驚いたのはコミュニケーションの“速さ”でした。チャットでは通知がテンポ良く飛び交い、小さな疑問や課題があっという間に解決していく——そのスピード感に衝撃を受けました。
横浜銀行が採用しているアジャイル開発では、状況に応じて「発言内容の正確さ」よりも「課題の早期解決」や「プロダクト価値の向上」を優先する場面があります。このバランス感覚が、結果としてコミュニケーションの速さにつながっているのだと感じました。
チーム全体の学びと成長への意識が高い
SIerで働いていた頃、エンジニアは「人月」という単位で管理され、プロジェクトのフェーズに応じて人員が増減するのが一般的でした。開発フェーズでは一気に人が投入され、IT(結合テスト)、ST(システムテスト)、UAT(ユーザー受入テスト)と工程が進むにつれて人数が減っていく——。必要な期間が終われば、多くのエンジニアは次のプロジェクトへ異動していきます。
そのため、個々のエンジニアを長期的に育成するという視点を持つことが難しく、「今のプロジェクトを滞りなく進めるためのリソース」という捉え方になりがちでした。私自身、忙しい時期には育成や知識共有を後回しにせざるを得ないことも多かったように思います。
一方で、事業会社のアジャイル開発では状況が大きく異なります。同じチームでプロダクトを継続的に育てていくため、メンバー全員のスキル向上がそのままプロダクトの質の向上に直結します。その結果、自然と「チーム全体で知識を高めていこう」という文化が根付いていると感じました。
横浜銀行でも、設計や仕様理解など“チーム全体が把握しておいたほうが良い領域”に関しては、勉強会やモブプログラミングを取り入れるなど、ナレッジトランスファーを重視した取り組みが頻繁に行われています。個人のタスクをこなすだけでなく、「どうやってチーム全体のスキルを底上げするか?」「数ヶ月後もこのチームが成長し続けられるようにするには?」といった視点が日常的に存在している点は、SIer時代にはなかった大きな違いでした。
SIer出身者は事業会社のアジャイル開発で活躍できるのか
同じシステム開発とはいっても、SIerと事業会社では働き方や文化に大きな違いがあります。では、SIer出身者が事業会社へ移った場合、どのような点が武器になり、どのような点で苦戦するのか。ここでは、私自身が感じたことをもとに整理してみます。
ステークホルダーとの調整
事業会社での内製開発とはいっても、外部システムとの調整やステークホルダーへの報告は必ず発生します。元請けSIerでは調整業務は避けて通れず、会議に臨む際には入念な準備や、相手の反応を先回りした回答の整理が必要になります。
- 相手の立場に合わせて伝える力
- 論点を整理して簡潔に説明する力
- 議事進行や合意形成のスキル
といったSIer時代に培ったこれらのスキルは、事業会社においても多くの場面で活きると感じています。むしろ、事業会社では意思決定への巻き込み方がプロダクトの進むスピードに直結するため、SIer出身者の“調整力”は重要なスキルといえるのではないかと思います。
スケジュール・リスク管理の意識
私が経験したSIerのプロジェクトでは、プロジェクト全体のタイムラインや工程間の依存関係を常に把握し、遅延が出れば即座に影響範囲を見直す必要がありました。アジャイル開発であっても当然ながら納期は存在し、「スプリントで区切っているから余裕がある」というわけではありません。むしろ継続的に計画を立て続ける必要がある点では、場合によってはウォーターフォール以上にシビアだと感じる場面もあります。
事業会社のアジャイル開発では、スケジュールやリスクに専任の担当を置かないケースも多く、チーム全体で意識して動くことが求められます。そうした環境の中で、SIer時代に身についた「工程のつながりや影響を自然と気にする視点」は、思いのほか役に立つと感じています。
例えばテスト工程では、シナリオは整っていても実行計画の細部が曖昧な部分がありました。そこで「もう少し具体的に計画しておくと安全かも」と提案し、必要な準備や実行順序をチームで確認するきっかけをつくることで、後工程のリスクを減らせたと感じています。「全体の見通しを持つ姿勢」は、SIerでの経験が自然と表れた部分だと思います。大げさな改善ではなくても、こうした小さな気づきがチームの安心感につながる場面は確かにあります。
まだ参画して日が浅く探りながらの日々ではありますが、SIerで培ったプロジェクトを俯瞰する視点は、アジャイルの現場でも確かな価値を発揮すると感じています。
苦労している点
これはあくまで私個人の経験であり、SIerでも現場開発に継続的に携わってきた方には当てはまらないかもしれませんが、開発現場からしばらく離れていた身としては、第一線のエンジニアたちと一緒に開発を進めることに、最初は少し苦労しました。
基本的な開発知識は持っていたものの、これまでの現場では開発自体を委託先に任せることが多かったため、実際に手を動かして参画するとなると、想像以上にギャップを感じる場面がありました。特にスクラム開発では、スプリント単位で成果を示す必要があるため、限られた期間でスピード感を持って作業を進めることが求められます。このペースに慣れるまではやや大変でしたが、横浜銀行ではペアプロやモブプロなど柔軟な支援体制が整っており、チームで助け合いながら進められる環境が大きな助けになっています。
さいごに
本記事では、SIerでの経験と事業会社のアジャイル開発に参画して感じた違いを中心に紹介しました。コミュニケーションの速度やチーム全体の学びに対する意識、スケジュールやリスク管理の考え方など、両者には文化や重視されるポイントに違いがあることが分かります。
ただ、どちらが優れているという話ではありません。SIerと事業会社では求められるスキルや働き方が異なるだけで、本質的に「価値のあるプロダクトを作る」「チームで成果を出す」という目標は共通しています。どちらの現場でも、工夫しながら課題に向き合い、学び続ける姿勢が大切だと感じます。
私自身は、SIer時代に培った経験がアジャイル現場でも少しずつ役立つことを実感しています。一方で、まだ学ぶことも多く、日々新しい発見があります。
この記事が、SIer出身の方が事業会社で働くことに興味を持ったり、キャリアチェンジを検討したりする際の参考になれば幸いです。また、働き方や文化の違いに関心がある方にとっても、何か気づきのきっかけになれば嬉しく思います。
Discussion