外部設計から実装部分まで入っていました。どこにいたかの情報漏洩防止の為一部情報を加工しているので、整合性が合致しない情報があるかもしれません信じるか信じないかは貴方次第です。A社から見て私の会社は5次受けとなります。システム利用者の金融機関を商流に含めれば7次受けという形です。社の所属はいませんでした。非生産的な事に関わってきたので、体験記として記載します。勤怠や勤務態度で他社が口出しする本来勤怠や勤務態度については、他社に言われる筋合いがないのですが、私の場合は有給やその他病欠などについても、E社とD社、C社に報告して承認を得なければなりません。私と同じ現場に入っていた同僚は2ヶ月前に報告していた1日の休みでも文句を言われていました。私はこれについては非常に腹ただしかった記憶があります。他社からそんな事を言われるのか?また、自社の会社はそれについて何のフォローもありません自社のフォローがないのは、現場には社長も営業もいないので事情の把握がそもそもし辛いのと、文句を言えば会社の契約が切られてしまう可能性がある為です。このように会社の力関係が明確で、下流会社は上流に逆らえません。挨拶が出来なかったり遅刻が多い人間はプロジェクトから外されますし、服装についても他社から指摘が入ると外されます。現場と上流の会社のさじ加減で変わります何度も記載しますが、これらの勤務態度や服装規定、有給を何時取得するかなどは自分が雇用されている会社が管理する事で、他社から言われる筋合いのないのですが、上流の会社の基準に従わなければならず、なおかつ自社の会社は一切それについてフォローしてくれません。幸いにして私自身は特に指摘を受けたことがありませんし、指摘を受ける人間もある程度の問題があるのでしょう。安い金額で働かされ、自分が逆らえない状態からこのような事を言われ、自社も守ってくれないのは本当に不愉快でした。設計書のフォーマットが決まっていませんでした。設計書はプロジェクト全体に関わってくるので、設計書は割と重要なのですが、そのフォーマットを決めるのに10人~15人が集まって2日間話し合うという、凄まじく非生産的な会議を経験しました。いった書類のフォーマットについては関係者が多数絡んでくるので、フォーマットの重要度は分かりますが結局決めの問題なので、元受けの会社がある程度決定し各社に指示すればいいだけの話なのですが、全員の意見を取り入れようとした結果、いい大人が長時間話し合うという非生産的な会議を経験しました。全員話を聞いているかというと私を含めて、会議の参加者の半分は終始死んだ魚の目をしていましたこの会議を抜けたくてしょうがなく、言い訳を考えましたが、商流上最下層の会社の最底辺の人間なので有無を言わさず参加させられ魂の抜けた時間を2日過ごしました。全てのミーティングで言えるのが、誰も責任を取りたくないためミーティングは誰が何を決定するかを論じる場ではなく関係者っぽい人間が全員同意したかが重要視されるミーティングでした。結局元請けの企業は大企業なので、出世基準が成果よりミスをしない事が重視されるのでプロジェクトで全員の納得感を出す為に、このようなミーティングが多数設定されているんだと思います。設計書レビューの回数が多く、毎回指摘事項が違う前述した設計書は1つ1つ顧客へレビューしてもらい、承認を得てその後の工程に進みます。この最終の顧客レビューの前に、上流の代理店にもレビューしてもらう必要があるのですが、私は最下層の所属だったので1つの設計書でD社レビュー、C社レビュー、B社レビュー、A社レビューでだいたい4回レビューが必要になります。※E社はマージンの中抜きだけなので、形式上の報告のみここで面倒なのが各社で指摘事項が違う各社で全く逆の事を指摘されるという事があり、何が正解かが全く分からない状態での設計書を作成しており非常に面倒でした。私は面倒だったので途中から間の会社をすっ飛ばして、裏側でA社の担当にレビューしてもらい、ある程度方向性を固めてその後各社にレビューしてもらうような対応をしました。これは間の会社への配慮を怠ると、炎上するリスキーな手でしたが、幸いにしてD社の方も協力してくれたので、なんとか上手く回せましたが、真面目にやっていればただ単なる作業と化しています。大規模開発は紙文化です。設計書などのレビューは紙で印刷した内容を顧客へ提出し、紙で添削をもらいます。この設計書ですが、1回のレビューで20ページ程度必要になります。関係者が2〜3人ならまだ問題ないですが、大体6人以上出てくるので、予備分を含めると毎回7部で140枚印刷し、ホッチキスに止め用意しなければなりません。紙の印刷がなぜ面倒なのかというと、1:印刷した時に分かりぬくい色だと修正が発生する2:縦や横に長い資料の場合、印刷した時に見づらくなり細かい修正が発生3:修正された内容の世代管理しようとすると、どんどん紙が溜まり、過去修正内容の参照が分かりにくい4:紙が物理的に紙で溜まっていくので整理が面倒などです。アジャイル開発でも設計情報をエクセルやその他CMSで残すので設計書自体の作成は問題ないのですが、設計書レビューをいちいち紙で印刷するのはこの開発現場だけしか経験しておりません。これはメチャクチャ面倒です。コードを書く人間が評価されないSI業では基本的に設計する人間の方が給料が高くなります。誰でもコーディングできると考えているので、コードを書くこと自体に価値を感じていません。上流の会社がよく発言し印象に残っている言葉はコードを書くのは誰でもできるしお金にならないです。実際大規模開発の上流の会社は設計だけして、コーディングは丸投げして下請けに作業させる会社が多数なのでコーディング自体が下請けの作業と認識している人間が多いです。コードは動けばいいので、保守性も重視されません。詳細は以下から記載しますコードは動けばいい基本的に作成したコードの指導やリファクタリングは一切行われません。コードの保守性よりも、納期中に設計書通りに動く事の方が重要です。なると良くわからない冗長なコードがかなり発生し、最終的には保守性が損なわれるはずなのですが、納期絶対主義なのでスケジュール内に決まった機能をコーディングする事が必須なので、冗長なコードが多数生まれます。リファクタリングも評価されないので、共通化されていない同じ様な処理も多数生まれます。コードを短く書くことが技術力が高いとは言えませんが、このような動けばいいだけのコードを書いていてもエンジニアとしての力は向上しませんこうなると、歳を重ねてもクソコードを生み出すエンジニアになるので、他社でも通用しなくなり結果SESから足抜けできなくなります。椅子は限られていますし、上流の会社とのコネも必要です。製造工程からトイレ(大)が足りない製造工程(プログラムを書く作業)から更に各下請けから人員が追加されます。なるとプロジェクトの参加人数は膨れ上がり、設計当初は関係者が30名程度だったのに製造工程からは200名くらいまで膨れ上がりました。このプロジェクト全体では数千人の人間が関わっているので、製造工程からは一気に人が増加するので、ビルのキャパがオーバーし、トイレ大が足りなくなり、トイレに行くのにも毎回行列が発生します。下層階への行き来が可能なビルはいいんですが、それが無理なビルの場合はトイレに行列ができます。上流の会社には逆らえないため、自分でコントロールできる範囲が狭いです。元請けに行くには新卒カードが必要なので、中途では元請けの大企業SIには就職できません。未経験では私と同じような下請けSESしか入社できません。研修が充実していても、現場でその研修内容が生かされる事も運次第です。自社サービスの会社に常駐させるSESなどもあり、そういった場合は技術力を上げることが可能です。自社サービス系の企業への参画は人気の為新人やエンジニア歴の浅い人間は自社サービスの現場にはアサインされません。上記からSESで良い現場に当たればいいですが、コントロールできない変数が多いためSESはまさに案件ガチャです。ちなみに私は5次受けでしたが、設計段階から入っているのでSESの業界からしたら、割と花形の職でした。こんな現場でしたがSESで業務システム開発として働き続けるなら恵まれている方でした。本当にツマラナイ苦痛な仕事でした以上になります。体験記なので色々書きましたが、私の実体験としてはこんな感じです。