ソフトウエア会社の社員を辞めてフリーランスになりました。
ソフトウエア会社の正社員から個人事業主になる決断をするまでの経緯をまとめてみます。
就職したころ
学校を卒業して就職したのはちょうど日本のバブル経済が崩壊した頃です。
電子回路を専攻していたのですが、卒業して就職したのはハードウエアではなくソフトウエアの受託開発の会社でした。
たとえ日本経済の先行きが怪しくなっても、今では考えられないことですがソフトウエア業界には将来性があるように見えたからです。
また、電子回路を制御するために少しだけソフトウエアを学んでいたというのもあります。
ソフトウエアと言ってもアセンブリ言語で記述するとても小さなものでしたが。
しかし、入社試験にソフトウエア知識を問うものはなく、専攻に関係なく採用していたようでした。
新入社員は各事業所に配属される前に東京で一ヶ月程、新人研修を受けました。
名刺の渡し方、電話の取り方、ほうれん草が何たらかんたら……
ソフトウエア研修もありましたが、研修の重点は社会人としてチームで仕事をするためのスキルにおかれていたように思います。
チームの価値
ソフトウエアの受託開発でお金を稼ぐには、難易度の高い開発をこなせるチームを作り、チームの価値を高めることが、やがて会社の価値を高めることにつながり、各社員の年収といった利益に結びつくと考えていました。と考えていました。
少なくとも昔は……
その考えはある時期までは間違ってはいなかったと思います。
多くの社員が末端の1プログラマーから始まり、開発マネージャーになるとチーム作りに邁進しました。
チームメンバと共に大量の技術書を読み、技術論、チーム論を交わしました。
そうしたチームがお金を稼ぎ、会社が成長し社員の年収も上昇するにつれ、チームの価値というものを実感していました。
育成不要のチームメンバ
そんな状況は育成不要のチームメンバが増えると同時に変わり始めました。
育成不要のチームメンバとは系列会社や派遣会社など他の会社から派遣されるメンバのことです。
なぜ育成不要かというと専門スキルを持った人間が派遣されるためです。
また、派遣元の会社には当然社員の育成方針があるため、それに干渉することはできません。
ソフトウエアの原価
会社はこの育成不要のメンバをどんどん増やしました。
理由は「原価率」を下げ利益を増やすためです。
ソフトウエアの原価には開発場所の家賃や開発機材なども含まれはしますが微々たるもので、そのほとんどは人件費です。
つまり、育成が必要な自社の正社員より、育成済で専門スキルを持った他社の社員のほうがなぜか人件費が安いというわけです。
開発マネージャーの仕事
こうなると開発マネージャーの仕事も変わります。
メインの仕事が時間をかけてチームを作ることではなく、短期間に集めた即席チームをまとめることに変わりました。
それらの即席チームは時間をかけて作ったチームより低い原価率で会社に貢献しているように見えました。
しかし、開発要求の実現手段としてより無難な技術を選択するようになっていきます。
他社から来る人間は専門スキルを持っていることが建前ではあるものの、それが本当なら原価は安いわけがないのです。
そのため誰でも実装できる無難な技術を選択し、それゆえに無駄に大きくなったソフトウエアの開発を人海戦術でカバーする、という方向になっていきます。
さらに「こんなに人を投入しますよ」と説明するだけで開発予算を安直に上乗せする顧客の存在が人海戦術に拍車をかけます。
ここまで来ると「開発」マネージャーとしての仕事は「誰でもできる無難な技術を選択するだけ」になります。
誰がやってもできるのですから、開発に必要な延べ工数は簡単にわかります。
あとは開発期間中に述べ工数を消化するには何人必要か計算するだけです。
もはや開発マネージャーである必要すらなく、工数計算さえできればよくなりました。
会社の方針とはいえ、このような仕事にはウンザリしてきていました。
重宝されるフリーランスプログラマ
そんな無難な技術を選択していても技術的な問題が発生することはあります。
問題解決の突破力のあるベテランプログラマが必要な場面です。
自社のベテランであればたとえ別のチームで仕事をしていても、チーム間で調整してアサインすることができました。
しかし、他社から派遣されている社員を別のプロジェクトにアサインすることなどできません。
突破力のある他社のベテランプログラマーをキープするのは無駄なコストが必要でした。
ベテランプログラマには素人同然のプログラマーが「セット売り」されるからです。
そんな状況の中、ある1人のフリーランスプログラマが重宝されていました。
突破力があるのはもちろんですが、組織に属していないため柔軟な契約ができ、無駄なコストがかからないからです。
請負開発の終焉
そして会社では「こんな簡単な開発になぜこんな膨大な工数がかかったんだ？？？」みたいなプロジェクトが増えてきました。
自分達が問題解決できないために膨らんだ工数を顧客にそのまま請求するという安直な手段に出るマネージャーも出てきました。
それでは仮に目先の損失を補填できたとしても顧客の信頼を失います。
その結果は「次の仕事はうちの社内でやってください」というお決まりのパターンです。
要するにもう請負ではまかせられないよ、というわけです。
こうして請負開発は徐々になくなっていき、顧客先での仕事が増えていきました。
それで社員の年収などが上がるようであればまだ納得もできましたが現実は逆でした。
もちろん顧客先での仕事に開発マネージャーなど不要です。
顧客会社の社員が管理するのですから。
転職を考えていくつもの会社の面接も受けました。
痛感したのは他の会社も似たような状況だということです。
昔は請負開発をしていたが今は客先常駐、社員一人あたりの売上は下がった、というパターンです。
ITの個人事業主になった理由
もう昔のようにチームを作り、チームで開発する時代は終わったと思いました。
開発ツールやテスト技術の進歩などで、1人でも規模の大きなソフトウエアを開発できるようになったこともあります。
また、請負開発が終焉を迎えたのはそもそも顧客が請負開発、つまりチーム開発を他社に依頼するのを望まなくなったからです。
自分の会社が寄せ集めチームでの開発に移行したように、顧客が自身で寄せ集めチームを作って開発するようになったということです。
それが時代の流れであれば、顧客の寄せ集めチームで重宝されるプログラマになろう。
そのように考えたのがITの個人事業主になった理由です。