はじめに

私事ですが、2023年 4月から別の会社に転職します。

約一年半のキャリアの中で感じたことを書きたいと思います。主にデメリット面。転職時に企業のどんな面を注視すべきなのかはデメリット面から見えてくることが多いからです。デメリットを許容出来るか出来ないかで、自身の満足度やキャリアの方向性との乖離を抑えることができると思います。

いま、転職に悩んでいる方・現職に悩みを抱えている方の参考になればと思います。

はじめに
筆者の簡単な経歴
受託のメリット
受託のデメリット
SESのメリット
SESのデメリット
ウォーターフォール形式による開発は本当に悪か？

筆者の簡単な経歴

2021年11月　受託企業にてITエンジニア（Java）のキャリアをスタート
2022年8月　自社開発会社のSES事業部に転職
2023年4月　自社開発に転職

といった中々きな臭い経歴をもっています（笑）記事を書いた日は2023年3月31日です。

受託では toC(常時アクセス大体200位想定程度)toB のプロダクトを、SESでは toB のプロダクトに参画していました。それぞれ短い期間しかいなかったので、コアな業務に関わる事は少なかったのですがこれまでの受託とSESに感じた技術的なことを、ざっくり簡単に書いてみようかなと思います。

ちなみに、これまで関わったプロダクトは5つ。そのうち炎上した案件は3つ（笑）

なるべく一般論として書いてみますが、あくまで一個人の経験談からなのでバイアスがかかっている事は前提として認識お願いします。

余談ですが、大阪と京都でITエンジニアなどの職種向けの勉強会兼交流会も運営メンバーとして主催しています。京都ではもくもくしたり、ランチしたり緩い感じでやっています。大阪ではLTも行い、テーブルごとの交流をメインでやっています。もくもくなどの作業はせず、といった感じです。どちらも交流がメインです。

ご興味あれば下記からご覧ください。

受託のメリット

色んなプロダクトに関われる
色んな技術に関われる
色んなPM・アーキテクキスト・リーダーに会える
自分次第では早めに良い仕事・ポジションが取れる
顧客・ユーザーと距離が近い

一般的なものとあまり変わりなかったですね。

受託のデメリット

ここからは記述量が比較的てんこ盛りです。大体メリットとデメリットは表裏一体です。

受託したプロダクトを納品し初めてお金がもらえる、という事業形態なので炎上しやすい
上記はPMの実力で大きく影響を受ける。
色んなプロダクトに関われる反面、必ずしも興味の持てるものとは限らない
色んな技術に関われる反面、必ずしも興味の持てるものとは限らない
色んなPM・アーキテクキスト・リーダーに会える
自分次第では早めに良い仕事・ポジションが取れる
顧客・ユーザーと距離が近い
ノウハウを貯める仕組みがない

1. 受託したプロダクトを納品し初めてお金がもらえる、という事業形態なので炎上しやすい

契約不適合責任(旧：瑕疵担保責任)
1. 成果物の質などが契約内容に反する、または満たされない場合に請負人が発注者にとる責任のこと
期間内に納品できればいいや精神が多い。テストコードなし、人力単体テストのみかつ正常系・機能要件の検証しかしないとか普通にある印象です。（本番リリース後、大体バグがユーザーから報告される....）
チームやプロダクトによるとしか言えないですが、開発のみしか契約がない場合そんなん多い気がします。
運用も見据えた契約をしていれば、保守しやすい設計やテストの自動化をしているかと言えばそうではない。
1. 顧客のリテラシーだとか、PM（他、折衝担当）の実力・見識だとか、契約時に必要性を理解してもらえなければ金も時間ももらえません。。。。

2. 上記はPMの実力で大きく影響を受ける。

これだけじゃないけど、以下のいくつかを出来てない案件は大体炎上してた...
もちろんメンバーも当事者意識が必要なので全てPMのせいだというつもりは有りません

最初の要件定義でどれだけ顧客のニーズを言語化出来たのか？
何がマストで何が不要なのかコンセンサスとったのか？
期限・工数・金額・要員数は妥当なものか？
最初の要件定義から変更が必ずある事を理解してもらい、その分のバッファーを設けることができたのか？
PM自体に開発経験はあるのか？
進捗の管理が適切に行われているのか？遅れている場合のリカバリーは？
新規技術など社内にノウハウがないプロダクトはリカバリー案があるのか？
チームの練度にあった設計や技術選定がされているのか？
PMやリーダーが開発メンバーの疑問や質問に明確なレスできるか？不要か必要か、不明ならばいつ判明するのか？
チームメンバーから問題点などを報告しやすいチームビルドができているのか？

3. 色んなプロダクトに関われる反面、必ずしも興味の持てるものとは限らない

4. 色んな技術に関われる反面、必ずしも興味の持てるものとは限らない

レガシーなもの、もはや完全に新規開発では選択されない廃れに廃れた誰も知らない技術なども多々ある
1. 独自FWとか公式ドキュメントが10年以上更新されていないFWなど、、、
全く勉強にならないわけでは勿論ありません。ただし、市場価値として評価されづらい。この辺りは、プロダクトの抱える課題や問題を解決することでカバーするしかないです。まあ関係なくするべき行動ですが。

ちなみに上記にあてはまるプロダクトに当たった結果、プロダクト内でしか活きないナレッジしか蓄積しないことも。以下のように当時ナレッジをたくさん残してたけど、ここからブログに書きたいと思える有益な情報は少なかった。ちなみにほんの一部でしかない。初歩的な内容も、そこそこあったのもあるけど。にしても無かった。

5. 色んなPM・アーキテクキスト・リーダーに会える

当たり外れも多々あります。。。。観測範囲内では開発経験のあるなしで大分ちがいました。
あるべき論をもちつつ現実にフィットできる人が素敵な印象
どこまで拘るか？どこで妥協するか？はチームのレベル、残された時間、いつまでに何の成果が必要か？などに左右されるので何が正解かはわかりません、

6. 自分次第では早めに良い仕事・ポジションが取れる

押しつけられて地獄を見る場合もある。これは主にリソース不足や管理側の杜撰さ故もある
そして上記の多くの場合、問題があった時は助けてくれないし責任を押しつけられる
反面生き延びると、修羅が誕生

7. 顧客・ユーザーと距離が近い

無理難題：保守契約の場合はそれを超えた範疇の機能改修など短い期間で要求される時も
頻繁：プロダクトの性質によりますが、問い合わせが頻繁な場合も
1. ログ調査だとか、特定データの取得でクエリ組むとかは運用において非常に勉強になります
2. ただし、その対応分の開発遅れを許してもらえないのであればイラつくこと間違いないでしょう
近いだけで別に、言われたことの実行しか求められていないことも勿論ある
1. もし、プロダクトや顧客の事業へコミットして行きたいなら、こちらからアプローチするなり工夫が必要
2. かといって自分の会社がそれを求めてるのかは別の話
3. 顧客との関係性は、会社としてどのような統一見解を持っているのか確認した方がいい

8. ノウハウを貯める取り組みをしているところが少ない

ここは、企業に寄る所だと思うのですが、割と受託あるあるなのかなと。
プロダクトごとにまとめていなくても、社内勉強会とかで共有できる場があるとまだいいのですが、その場合はある程度出来上がってからの話しかない。わかる人が抜けたら終わり

パッと思いついたデメリットはこんな感じ

この辺りが自身や周りのプロダクトであったことかなーと。いえる範囲で当たり障りないものですが。
こういった問題が起きない様な組織構造なのか？対策は何をしているのか？組織としてどのような問題意識を持っているのか？などは、転職活動時に確認したほうがいいですね。

問題があるなら解決すれば実績になりますが、そういったことがもとめらてるのか？許される風土なのか？そのためのリソースがあるのか？そもそも評価されるのか？などは、入ってみないと解らない組織が抱える問題だったりします。そもそも放置しても問題ないという認識でそのままにしている所が多いので、当てはまる点が多い企業は避けた方が良い気がします。というか、避けましょう。

SESのメリット

色んなプロダクトに関われる
色んな技術に関われる
色んなPM・アーキテクキスト・リーダーに会える
いろんな企業と関われる
SESは労働に対してのみ責任が発生、成果に対してではない
現場を選べる
企業にとってキャッシュフローが良い
1. 労働力に対して報酬が発生するため、会社にお金がすぐ入ってくる。経営の観点では安定した収入源となる
2. エンジニア本人としてはそういう背景もあることを知っておいた方がいい

受託と大きく違うのは責任ですね。受託は成果に対して報酬が発生しますが、その分成果物に対する質を担保する責任があります。

また、関われるプロダクトも toB に限定されていきます。 toC もないわけではないですが、受託よりは少なくなる印象です。ただし、これも言語によってまた変わる面もあります。Java　であれば toB 向けのシステム・エンタープライズが多いですし、Python ではまた違ったプロダクトがありましたね。

SESのデメリット

受託と同様の点もあります。その点に関しては改めて説明しません、

色んなプロダクトに関われるが、toC 向けのプロダクトは少ない
色んな技術に関われるが、必ずしも興味の持てるものとは限らない
色んなPM・アーキテクキスト・リーダーに会える
SESは労働に対してのみ責任が発生、成果に対してではない
事業成長に関わっている・関わっていけるという実感が得にくい
企業にとっては安定したビジネス、エンジニアのキャリアは無視されれやすいかも
現場を選べるが、それは発注先も同じ
信頼できない営業にあたった場合は大変
年数・経歴・経験内容が重要、未経験や微経験では苦渋の年数が必要かも
現場によっては開発体験が低いこともある
要件定義にないことは、例え良いプロダクトになることを提案しても採用されない

1. 色んなプロダクトに関われるが、toC 向けのプロダクトは少ない

toB や社内システム用だったりが多かったです。
こういったプロダクトで学べないなと感じる点があります。

高アクセス負荷に耐えうる設計や冗長システムの運用や存在そのもの

どんな時間帯にトラフィックが集中し、その対応のために何が必要なのか？?使用人数も決まっていますし、プロダクト機能要件も割と限定的で、実現すべきパフォーマンスが割と緩めだったり

そういった知見は toC の方ではよく見かけますが、toB とくに社内システムではほぼ見かけなかった。割と大規模な10年もののシステムでも、新規開発システムでも。そもそもユーザに高負荷なクエリを発生させないようにしてたり

例えば、検索画面で検索結果は200件までに絞るなど。そうなるように検索条件を設定させる。

2. 色んな技術に関われるが、必ずしも興味の持てるものとは限らない

同上、省略

3. 色んなPM・アーキテクキスト・リーダーに会える

同上、省略

4. SESは労働に対してのみ責任が発生、成果に対してではない

ある意味気楽なわけですが（現場ではそんな態度してたら問題ですけどね）、やはり成果に対して責任がないというのは、期待されないし任されないという意味でもあります。ただ、現場がカツカツの状態で、能力と信用があれば任せられることもありますが。

プロパーさんや管理側としてはやはり、コアな部分をSESの人間に任せるのはリスクヘッジ的にも元々の定義からもあまりよろしくない空気を感じます。まあ、がっつりやってた方もいましたし古いシステムの保守運用とかだと、SESの人間一人で保守担当なんていう現場もありましたが。

5. 事業成長に関わっている・関わっていけるという実感が得にくい

SESの事業形態として、どれだけの人数を抱え現場に派遣しているか？あとは単価と期限の掛け算が収益になるので個人として貢献していく方法は余りない印象です。あるのかな？
また本社の同僚とのコミュニケーションもほぼないのもザラなので帰属意識は芽生えないですね
アルバイト・フリーランスと正社員の大きな違いはこの「事業成長に関わっていく」ことが出来る、という点だともいますがSESはフリーランスに近いので、実感することはあまりないのではないかなと思います。

6. 企業にとっては安定したビジネス、エンジニアのキャリアは無視されれやすいかも

よくあるのが営業さんがエンジニアを「商品」としてしか、見ていない場合です。この場合、エンジニアのキャリアに沿った現場を提案してくれない・面談の場を設けようとしてくれない、なんてことも普通にあります。

黙っていても案件が舞い込んでくるほどのつよつよエンジニアであれば別ですが、大多数はそうではないでしょうから、エンジニアのキャリアも考えてくれる会社ではない場合は自身のキャリアが積む可能性があります。

7. 信頼できない営業にあたった場合は大変

上記と同じな部分もあるのですが、案件を取ってきてくれる営業さんと信頼関係が築けない場合は営業さんを変えてもらった方がいいです。信用できる営業さんがおらず、自身のキャリアとかけ離れた現場しか面談させてもらえず、とかで改善が望めないなら転職した方がいいかもです。

ある意味営業さんがエンジニアのキャリアを大きく左右するので、単に商品としてしかみてくれない場合はエンジニアとしてのキャリアが終わる可能性もあります。

8. 現場を選べるが、それは発注先も同じ

嫌な現場は離脱もできますが、逆に不要だと思われれば切られることもあります。普通に報連相して、ビジネス的なコミュニケートが出来て、分からないことに一人で悩み過ぎず質問するなどしていれば、切られることはないと思います。

とはいえ進捗報告は結構難しいです。ドメイン知識・プロダクトに対する理解も乏しく、技術もそんなにない場合。まず全体の何割が出来ているのか？残タスクにかかる時間はいくつなのか？などは簡単に解りません。それでも管理側からすると、メンバーの進捗状況の良し悪し・悪い場合の原因・現在の課題などが不透明だと気持ち悪く感じるものです。その確認のための手間が発生するとコストがかかる人間だと認識されるので気をつけましょう。

あと、自発的に動ける当事者意識も必要です。いくら成果に対して責任がないと言えど、その意識はお金をもらう限りはどこでも必要です。言われたことだけやるのではなく、必要なことであれば立場や担当・役割に関係なくやっていく姿勢は必要です。勝手にやるのもいけませんので都度確認と承認はとった方が良いですが。

あとわからない時ですが、WBSなどみて納期が間に合うのか？という観点で見れば一人で長く悩むのは無駄です。期限内に終わらせられないのであればわからないことは聞くべきです。何も考えずに即聞くのもどうかと思いますが。せめて、実現したいこと・詰まっている箇所・エラー文・原因に対する仮説と検証結果、くらいは持っていった方がいい気がします。何一つわからず、引き出しゼロみたいな時もあるのですがその時は即聞いてました。

9. 年数・経歴・経験内容が重要、未経験や微経験では苦渋の年数が必要かも

やはりこの業界は未経験には厳しいと思います。

現場のあたり順、という言い方が適切かどうかはさておき、以下の順番であたりだと思います

新規開発
機能追加
保守
テスター
監視？（やったことないので不明）

未経験や一年目はよくても保守が多いです。自分は新規開発に運良く入れました（人手が足りなかったのでタイミングがよかった）が、保守現場しか入れない時もありました。比べるとやはり、経験になるのは新規開発ですね。ですが、そのようなフェーズで求めらるのでは経験年数が長め（= 基本設計・詳細設計・製造・各種テスト・保守などの経験あり）の人材なので未経験はまあ入れないでしょう。

だれか強い人と一緒に抱き合わせで、とかのパターンでしか基本は無理な気がします。

ちなみにテスター経験はなんやかんや大事だと思ってます。世間ではなんやかんや言われてますが、自分はその経験は活きると思っています。

10. 現場によっては開発体験が低いこともある

これは本当にびっくりですが、一番やばかったのでが10年前のタブレット端末（メモリ1GBだった...）で激オモエディタの Eclipse と無数のエクセルファイルを開かないといけなかったのは本当にきつかったです。エクセルファイル開いてちゃんと操作できるのに5分とか、起動して10分は置いておかないと反応しないとか、、、、。

あとはセキュリティ的にネットワークが分かれていて、開発用の端末・報告や会議用の端末・本社の端末などあったりで面倒だったりします。たとえば全く同じ定時報告を端末毎に書く（ネットワークが違うのでコピペも共有も出来ない）とか、製造用の端末は通信禁止なのでエラー文を別の端末に手打ちしないといけないとか。面倒でしたがやるしかない

11. 要件定義にないことは、例え良いプロダクトになることを提案しても採用されない

「UIはこうした方がユーザに親切じゃないですか？」
「業務的に〇〇の機能は要らなくくて、◯◯するための機能が必要じゃないですか？」

こういった提案が合っているかどうかという問題もありますが、合っているとしましょう。大体こう返事が来ます。

「言われてないから」
「仕様にないから」

ということでする事はないです。自分は言われたし、言われてる人も見た事がりますし、知り合いもそれしかないと。勿論そうじゃない場もあります。今、自分がいる場所は自社開発ですが、SESの方の意見をガンガン取り入れています。ただ、そういった場所の方が多いと思います。

これがデメリットとなるかは人次第かもしれません。ただ、良いプロダクトを作りたいと思っている自分としてはかなり歯痒い思いをしました。

ウォーターフォール形式による開発は本当に悪か？

まずは元々のウォーターフォール開発を表す図をご覧ください

ウォーターフォールの原型となった論文（と言われている）においては、フェーズが進むごとに前段階に戻れなくなるという現在のウォータフォールの形を批判しています。逆に、図の様な形でフェーズ間を行き来する開発手法を理想としています。

ウォーターフォール、初出とされている論文はRoyceによる「Managing the Development of Large Software Systems」です。画像はこちらの論文からの引用です。

http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf

ウォーターフォールは変わらないものに向いてるんだろうなと思います。例えば、決済機能とかですよね。逆にもれなく実装できるのではないかと思います。ただ、ユーザーの要望・市場の変化が多様化しサイクルが短縮化していく現状で、現在のウォーターフォールの様な手戻りが想定されない開発手法では、対応できないのは自明の理かと思います。

フェーズが進む過程・周囲の環境変化などで浮き彫りになる課題や要件というものに対して、対応が必要なプロダクトであればアジャイルも選択肢の一つになるのではないかと思っています。ビジネス環境の変化する速度に、システム開発の速度がついていけないのであれば一つの開発スタイルにこだわるのは企業競争力を低下させる原因になりかねません。

ただプロパーの方々の、ステークホルダー間の調整力・遅れや想定外へのリスクヘッジ・ドキュメント作成力・スケジュールやタスク管理能力・全体を俯瞰し都度優先順位を定めながら並行でタスクを進めていく感覚・メンバー管理のシビアさ・炎上時のゾンビの如し労働力、などはウォーターフォールで培ったものなのかなぁという感想があります。とてもきっちりしているし、不明確で不正確なソフトウェア開発においてそれらを「言語化する」という能力はものすごく高いんじゃないかなと思います。

プロダクトの性質によって開発スタイルを柔軟に選択できればいいのかもしれませんが、ウォーターフォール以外の開発スタイルを実行するための教育や環境面のコストの問題、企業間契約におけるウォーターフォールとの親和性、など色々な要因があると思います。

あしたからアジャイルやれと言われて出来るものではないですからね。

悪と言い切るのは良くないんじゃないかと思います。よく言われてますが。単純にそれぞれの開発スタイルにはトレードオフがるので適切に使い分けるがあるべき論でしょうがそれだけで現場は回っていないので、単純にウォーターフォール単体で良し悪しを語ること自体がナンセンスな気がしています。なんちゃってウォータフォール・なんちゃってアジャイルは怠慢の隠れ蓑感は強いですが。