もくじ
受託開発は本当に素晴らしいのか
先日、私はSES企業はおススメできない理由を記事にしました。
SES企業では、仕事を通してキャリアプランを生成するのは難しいかもしれないという話でした。
経営者であれば、会社が倒産しては元も子もないので、出来る限り利益になるプロジェクトに人を入れたいものです。私が経営者だったとしても、やはり同じことを思うでしょう。
では、受託開発している企業の方がいいのか。
右も左も分からない新卒の状態で、赤の他人から作業指示をされたり、違法な労働に手を染めるくらいなら、上長の目の届く受託開発を行っている企業の方が良いとは言えるでしょう。
ただし、必ずしも受託開発が良いとは言えない理由があります。
受託開発とは
そもそも受託開発とは、顧客が利用するシステムの開発を請け負うことを指します。オーダーメイドの一品モノのシステムであったり、パッケージソフトの改修であったり、パターンは様々です。
しかし、受託開発を行う企業では、SES企業と同じ問題を抱えてしまうことがあります。
受託開発は契約的には請負になりますので、成果物をお客様に納品する必要出てきます。
よって、期限に成果物を納品出来なかった場合は損害賠償請求をされたり、会社にお金が入ってこなかったりするリスクがあります。
準委任契約であれば、成果物の納品義務は無く（と言っても実質何らかの成果物は要求されますけどね）、プロジェクトが炎上した場合は撤退なんてことも容易に出来ます。
これが、受託開発だと、逃げる術はありません。
あらゆる手段を講じて、成果物を納品せざるを得ないため、きちんとマネジメントを行わなければ大きな損失を被ることになります。
かつて、私が自社開発を行っている会社にヘルプで入った時の話と、自社パッケージソフトを販売している企業に勤めているときの話を踏まえて紹介していきます。
ケース1 受託開発
私がその自社開発の会社にヘルプで入ったのは、実は自社の仕事としてではなく、知り合いの伝を使って土日にヘルプで入った仕事でした。
ぶっちゃけると、副業です。まぁ、お金が無かったので（笑）
ただ、参入してすぐに、軽い気持ちでやるものじゃないなと後悔しました。
自社開発を行っているビルはとある雑居ビルの一室にありました。その一室のドアをくぐると、すぐに怒号が飛び交っていました。奥にある部屋からは、机や椅子が激しくぶつかるような音がしました。
そして、そんな騒音も聞こえないかのように、担当者の方が淡々と案件の説明をし始めました。
どうやら、エンドユーザーは誰でも知っているソフトウェアメーカーであり、そのメーカーの業務アプリを、その受託開発を行っている会社が請け負っていたようでした。
後で案件を紹介してくれた方に聞いた話によると、数千万円以上のお金が動いていたとのこと。
社員の規模は数十名といったところでしたが、何故そのような規模の会社がそんな大金を動かせたのかは謎ですが、金額が大きければ大きい程、その会社に対する責任とリスクは大きくなります。
つまるところ、大金を手に入れることになったものの、全然完成の目処が立たなくて猫の手も借りたいといったところでした。
担当者からの説明を終え、開発部屋へ案内されました。
すると、そこには信じられない光景が広がっていました。
リーダーらしき人が自社の社員に怒号を飛ばしていました。
ある人は机に突っ伏していたり、ある人は机の上に缶コーヒーの空き缶を何個も並べて眠気を抑えたり、ある人は床の上に完全に落ちていました。部屋全体がとても、ピリピリした状態でした。おそらく、何日も家に帰っていない人もいるのでしょう。
そんな人達を横目に私は自分の席に向いました。ろくにドキュメントもなく、設計書と言う名の要件定義書を元に担当のモジュールの製造を行いました。
ただ、製造を初めて感じたのは、そんなに実装が難しいモノではないという感想でした。
フレームワークも特別なモノを使用している訳ではなく、インターネット上にいくらでも情報があるようなモノでした。
それでは、何故、こんな阿鼻叫喚な状況になってしまったのか。
答えは単純。
その会社の技術力に見合わない仕事を引き受けてしまった。その一言に付きました。
どうやら会社が持っているスキルに見合わない仕事を引き受けてしまったようでした。
会社…というより社長がそんな大金が動く仕事を受けてしまっては、もちろん下に付く社員達はそれに従うしかありません。
例え、上司が技術について全然分からない人であっても、逃げることは出来ません。（いや、逃げても良いんですけどね！）
社長はリーダーに社員が何としてでも納期に間に合わせるように指示し、リーダーは社員達の尻に火を付ける如く何としてでも働かせようとします。
もう、見ているだけで悲惨過ぎて一秒でも早くこの空間から出たかったです。
たった２日しかいなかった私がそう思うくらいなのですから、毎日出勤している社員達はきっと地獄のような日々だったことでしょう。
正直、２日で月の給料の半分くらい貰いましたが、全く割に合わない仕事だと感じましたので、もう二度と炎上案件のヘルプはしないと心に誓いました。
ケース2 パッケージソフト開発
私は会社の本業はSES業だけれども、自社でパッケージソフト開発も行っている企業に勤めていたことがありました。
基本は客先常駐ですが、社内待機したときはたまに改修作業を行っていました。一応、専任のパッケージソフト開発の担当者は4名程いましたが、エンドユーザーの元で常駐するなど、社内にいないことが大半でした。
ある時、そのうちの一人が会社を辞めることになりました。
何となく、私にはその理由が分かっていました。
そのパッケージソフトはVB6で作られたソフトウェアだったのです。
当時、既にVB.NETが普及しているにも関わらず、VB6で作成したソフトウェアを提供していました。
正直なところ、VB6自体は悪くはない言語ですが、その専任の方は新卒からずっとVB6しか触れていなかったため、自身のスキルに不安を覚えて転職を考えたとのことでした。
また、.NETの技術者もいないため、移植も困難なような状況でした。(自社待機であまりにもやることがないため、私が途中まで独学で頑張って移行していましたが、無理でしたw)
転職された方はまだ20代であったため、いくらでもやり直しがききましたが、これが30代、40代になってから転職を考えていたらどうなっていたことでしょうか。
まず、最新トレンドの開発現場は入られないかと思います。例え独学で学んでいたとしても、30〜40歳まで実務経験が無い人をそうそう使おうと思う会社はありません。
実務経験に勝る経験を独学で積むのは困難を極めます。
自社開発を行っている企業でも、そもそも社内で保有しているスキルが市場的に価値あるモノかどうかは別の話です。
結局、どうすればいいの？
ここまで話しておいて、なんなんだという感じなのですが、明確な答えはありません。
受託開発だと社内の保有スキルによって身に付くスキルが変わってきたり、社内でしか通用出来ない業務を覚えてしまうという弊害はありますし、SESだと案件次第では天国も地獄も運次第です。
私の結論としては、そもそもどっちが良いというよりは、どこでも通じる技術を身に付けられる工夫をすべきだと思います。
受託開発は基本的には自社なので色々融通が利くところもありますので、私が古いパッケージソフトをリプレイスしようとしたように、今使っている技術を他でも通用する技術にするために会社に提案するなど、社内で積極的に動いた方が良いでしょう。
SESであれば、無意味な時間を過ごすようになれば会社と相談してさっさと現場を変えるなり、転職するなりして、スキルアップを図った方がいいでしょう。
結局のところ、どちらも一長一短です。
SEとして、何年もやってゆくには常に考え続けることが一番大事です。