前回、私が転職を考え始めたきっかけを書きました。
その中で述べたように、私の場合残業削減が主目的です。
ただし残業削減のみが目的であれば現在の会社で対応する選択肢もあります。
・プロジェクトを変える
・部署を変える
・残業しないで済むよう上司に掛け合う
：
ここではこれらのことを考えなかったのか、
なぜ考えなかったのかを書いていきます。
現職での業務内容
私が働いている会社（転職前の会社）は主に受託開発を行っていました。
その中でも私は業務系システムの開発を主としていました。
様々な業界の会社へシステムを提案し、見積もり、開発、納品まで一貫して行います。
請負った業務は主に自社内でプロジェクトチームを作って開発します。
開発メンバーは社員のみで構成されることはまれで、社員＋BP（パートナー会社）社員で構成されることがほとんどです。
この業界では社員＋BPでの開発が当たり前の構造となっています。
まず１次受けの会社がユーザ企業から開発業務を請け負います。
１次受けの会社は２次受けの会社に協力を要請します。
２次受けは更に３次受けに、
３次受けから４次受けに
：
と続いていきます。
BP社員をメンバーに組み込む理由は二つあります。
・業務量の増減に対応するため
・原価を安くするため
常に一定の開発業務がある訳ではありませんので、
請負量が減った際にBP社員を調整することで対応するのです。
また一般的には自社社員よりBP社員の方が単価が安いため、
BP社員が多い方がプロジェクトの原価率は良くなります。
その他にも社員のみでは対応できない技術要素がある場合に、
その技術を持っているBP社に依頼することもあります。
（大手になる程、社員は開発を行いません。
設計まで行い開発以降はBP社に依頼し管理のみ行います。
従って社員で開発スキルを持った人間はいなくなります。）
また開発期間もまちまちで1か月ほどの短期から、長いものだと2、3年ということもありました。
（1年以上続くものはまれですね。）
稼働が高くなりやすい
前述したように開発業務量は一定ではありません。
そして常に複数の開発が並行して進みます。
よほどの大きなプロジェクトであれば別ですが、
１つのプロジェクトのみでは部署の売り上げは達成できません。
そのため新たな提案、見積もりを常に行う必要があります。
新規引き合いが突然やってくることもあります。
その間にも開発がスタートした業務も進めなくてはなりません。
そのサイクルが常に複数プロジェクトに渡って行われます。
時期が上手くずれてくれれば良いのですが、
実際は中々そうもいかずほぼ重なります。
納品間際でバタバタしている所に新規引き合いが来て、
提案と見積もりを急がなくてはならない、、などです。
このような状況になると稼働を上げて対応することになります。
スキルが蓄積されない
主に社員＋BPでの開発体制でプロジェクトが構成されることを前述しました。
さらに開発スパンも短いため同じメンバーでの開発が続くことはまれです。
このような構造では業務スキル、技術スキルの蓄積が行われません。
プロジェクトが上手く継続できた時は同じメンバーで続けることができますが、
そうでない場合はBPメンバーの移動が発生します。
再度類似案件が来た場合でも、必ずそのBP社員がアサインできる訳ではないため、
再度一から仕様を覚えてもらうことになります。
またBP社員のスキルもまちまちです。
言い方は悪いのですが、実際は当たり外れも多く、
BP社員のスキルの良し悪しは開発を行ってみないとわからない
半分ギャンブルのような感じになっています。
受託開発での限界
このように受託開発という業態である以上、
残業は発生せざるを得ない構造になっています。
したがって
部署を変える、
プロジェクトを変える
という選択をしたとしても、
一時的には改善するかもしれませんが、
どこかで同じ状況になる可能性が高いです。
そう考え私は転職する、という選択をしました。
次の会社で残業が少なくなるのか、
仕事内容は合うのか、
人間関係は良好にできるのか、
給料はやっていけるのか、
など、当然不安は尽きません。
しかし自分で決断した事なので覚悟を決めてやっていきます。
併せて他の記事もどうぞ
コメント