よし！転職しよう 番外編①
地方在住の元ソフトウェアエンジニアのAKIRAです。この記事は本編の番外編ということで１回目の転職後に感じた事などダラダラと書いております。お暇つぶしになれば幸いです。
【番外編①ベンチャーの落とし穴と対処法】
ベンチャー企業に入社してからの落とし穴（対処法）については、転職と関係ないのですが簡単にまとめてみました。１０年以上前の情報なので対して役に立たないかもしれませんが、もしご興味があれば暇つぶしに読んでいだければと思います。
箇条書きで記載するとこんな感じです。
年俸制の罠！
ベンチャーは自転車操業？
資格の取り方
新人の育て方
システム開発の勘所
儲からない仕事…
ベンチャー企業とひと括りにしてしまうのは危険ですが、中小零細企業の話だと思って下さい。およそ十数年前の事になります。
【年俸制の落とし穴】
今もあるのか解りませんが、当時は年俸制のベンチャー起業がちらほらと見られました。ソフトウェアエンジニアは、そのスキルや経験を評価されるため、年俸制は一見合っているかのように思います。
ただし、労働条件次第では地獄のような働き方を、余儀なくさせられる場合があります。いわゆる裁量労働といわれる、みなし残業込みの労働条件の場合、年俸がいくら高く見えても月の労働時間が過労死ラインと言う事が、この時代にはあったのです。
私は、ほぼ毎日12時間から15時間労働でしたので、月の稼働時間が休憩をお昼と夜に１時間づつ差し引いたとしても、200時間から260時間は働いていました。土日も出勤する事があったので、ひどい時は月300時間近く働いたこともありました。
ベンチャー起業には多くの場合、労働組合は無いのではないかと思います。あったとしても社員会という形が一般的でしょうか。そのため、36協定を厳密に守っていない事もあるように思います。
今では考えられないですが、よく異世界転生もののライトノベルでソフトウェアエンジニアが過労死して転生というパターンがありますが、あれはそうなってもおかしくない働き方が実在した証拠とも言えるのかもしれません。
また、ボーナスというものは存在しません。年俸制なのでこれもコミコミです。年末に業績によって寸志として数万円出る事はありました。よく【おもち代】などと言われていましたね。
景気の良い会社では、ボーナスが2.5カ月だとか、3カ月だとかいうニュースがあってもまるで別世界のお話です。これは単純に入った会社が儲かっていないだけかもしれませんね。
ただ、元々底辺の派遣社員だった私は年収が低かったのでそこには不満はありませんでした。また、技術力も経験も浅かったので時間をかけられることは良い面もありました。
最近はホワイト企業が増える一方でスキルアップできていない若手も見かけますので良し悪しがあるなとも思います。働き方が見直されるのは良い事ですが、若手は独自に勉強しないと技術力も経験も浅いままになりそうです。
【ベンチャーは自転車操業？】
これも、あるあるなのかもしれませんが、ベンチャー企業はメインの事業が軌道に乗るまで、自転車操業になりがちだと思います。
企業は、会社の運転資金を銀行から借りたり、VCから出資を受けたり・上場して集めたりと、とにかくお金が必要になります。ソフトウェアは多くの場合、フロー型の収入なので完成してから支払いを受けて売上が立ちますが、完成まで数ヶ月・数年と言うこともありますので、お金が入るまで時間がかかるためキャッシュフローが安定しません。
そのため、短期のプロジェクトも日銭を稼ぐためには必要になりがちで、本業と離れた仕事も時には受託開発として受けることもあります。
例えば、金融関係がメインの会社が、自分たちの畑違いの物流やWebシステムに手を出すような事も当時はありました。当然ノウハウが無いのでは効率的ではありませんし、そういった畑違いの仕事を専門の会社ではない会社に頼む顧客は予算が少ないか、システム特性が解っていないことが多いですのでなかなか苦労します。
会社として新たにその業界に、進出するのであれば良いのですが、多くの場合は営業マンが自分の売上達成のためや知り合いから頼まれてというきっかけが多いように思います。営業マンも大変でしょうが、経営戦略的にどうかと思う事も多々あります。
時として、それがうまく行って継続的な仕事になるといった当たりを引くこともありますが、多くの場合は単発で終わり、労多くして実りが少ないというパターンか、最悪失敗して赤字になる可能性の方が多いのではと思います。
最初に運転資金を借りているので、利息も払わなければなりません。新たな借り入れをするためには、将来の見通しとして仕事が多く受注できる事が予測できないといけませんので、無理してでも仕事を取ってくる必要があります。こうして自転車操業が始まって終わりが見えなくなっていくのではないでしょうか。
うまく行っている会社は、早々にストック型の、ビジネスに乗り換えています。受注生産ではなく、サブスクリプション型のクラウドサービスに移行できた企業や、最初からそれをビジネスモデルに創業した会社はこんな事にはなっていないように思いますが、どうなんでしょうね。
【資格の取り方】
私は派遣社員時代にも情報処理の試験を受けたことがありましたが、最初の試験では合格出来ませんでした。転職後、仕事の忙しさは格段に忙しくなったのにも関わらず、基本情報処理とソフトウェア開発す技術者を連続で合格する事が出来ました。
学生時代も勉強は好きではありませんでしたし、必要最低限しかしたくなかったので、合格に必要な80%（今は60％らしいですが）の正答率を意識した勉強しかしていませんでした。お気づきの通り、それで合格できるほど簡単ではありませんよね。たぶん合格できない人は私と同じように、合格ラインを目指してしまっているのではないでしょうか。
学生時代に真面目に勉強した記憶が無い私にとっては、どの程度まで勉強すれば何点とれるのかという肌感覚は無いに等しく、参考書と問題集を一通り暗記すれば行けるものだと安易に考えていました。
しかし、私と正反対で難関資格の合格経験のある妻に言わせると、資格試験は【過去問10年分を三回解けば確実】とのアドバイス（それだけ勉強できる才能がすごい）をもらい、さすがに凡人の私には10年分の過去問を攻略できなかったので6年分を二回（難易度に応じて期間と回数を調整すれば良い感じです）ほど解いて合格出来ました。この方法でその後、必要になる資格はだいたい取れましたが、過去問が出回っていない試験は難しいですね。
【新人の育て方】
ベンチャー企業でSEとして働き始めた頃に、チームをどのように作っていくか悩みました。既存の社員はそれぞれの仕事があるので忙しく、外部の派遣会社に相談して来てもらうか、もう一つの選択肢として新人を育てるという選択肢があるかと思います。（外部の派遣を育てるというのもありましたが）
私の開発手法はOSSの活用とアジャイル式の開発手法でしたので、既存の社員には抵抗がまだあった時代でした。そこで、新人教育を兼ねてOSSの活用とアジャイル式の開発手法を広める事にしたのです。
自分の時間を費やしてまで新人教育をしたがる人は少ないと思いますが、リソース不足を補うのと新しい開発手法を広めるためにもせざるをえなかったというのがきっかけでしたが、そう簡単ではないというのが数年間続けて解ってきました。
結論を先に行ってしまうと、ある種の型にはめてしまうという意味では、新人教育のタイミングから開発手法なども含めて教える事は有効だと思います。ただし、会社としての技術選択などの戦略とリンクさせないと効果が薄いのと、成果は新人達のやる気次第なのでどうやってやる気を出させるかが鍵かと思います。しかし近年の若者の出世欲の低下によって難しい時代になってきたように思います。
そして、いつまでも自分一人で仕事をかかえないようにするためにも必要な事だと思いますので、私は新人教育や部下の育成はやって損は無いと思います。私の行った新人教育の方法は以下の通りです。
環境構築から初級プログラミングまでを参考書で徹底的な基礎勉強
まずは「はじめてのJava」的な参考書をしっかり全部書いている事が理解できるように短期間で詰め込みます。当時は動画コンテンツが無かったので図付きの親切なものを購入してやってもらいました。
最初期は資料を自作してましたが手間がすごくかかるのでアウトソースでいいでしょう。解らないところはググってもらい、ググり方から覚えてもらい。最終的には答え合わせをする方式です。
言語仕様の理解
ここが重要で、言語は構文の暗記ではなく理解が重要なので、言語特性（何に向いている言語で他の言語とどうちがうのか）という事を説明しました。
例えばJavaであれば、ガベージコレクションのおかげでメモリ管理がC言語ほど厳密にしなくてもいいけど自動的にメモリ開放されるように作法を守っておかないとメモリが開放されないといった内容で、それが開発上のどういう利点・欠点があるのかなどです。これが解っていないとダメなソースを量産する可能性があります。
ロールプレイによる要件定義から設計・実装・テストの演習
プログラムだけ作れても意味が無いので、要件定義書の書き方・設計書の書き方、テスト仕様書の書き方、ドキュメントに最低限何をどの程度書かないといけないのか、そして簡単なシステム（TODOリストなど）を完成させるといった事をやりました。いきなり顧客向けのソースを作らせるわけにもいきませんので。
恐らくそんなに他でも変わらない手法かと思いますが、それぞれに意味があります。基礎勉強に参考書を使うのは自分で学ぶ力を養うためです。例え新しい言語が出ても参考書で勉強できるようになれば、新しい言語を自学することができると思います。
言語仕様は、言語の目的や理念、そもそも何のためにその言語が開発され、どういった利点や欠点があるのかを知った上で使いこなさなければ、間違った使い方をしてしまう事になります。やりたい事に応じて適した言語というのは違いますし、流行を見つつも現実的で長く使える言語選定は難しいので新人のときからそれを見極めるヒントくらいは持っておいて損はしません。
ロールプレイは本格的な開発前に失敗のためのプロジェクトをやっておくためのものです。失敗する事は良い事ですが、どうやってリカバリするかも含めて最初に学んでおくためにも、ロールプレイでたくさんの失敗を経験しておけば、本番のプロジェクトでのミスは格段に減ると思います。なのでロールプレイが最も重要だと感じています。
ロールプレイはまずはウォーターフォールにで進めます。ウォーターフォール式が全て悪いわけではありませんし、日本はそれでなければ作れない体質・風土的なものを感じます。本当の意味でのアジャイル式の開発は、オーナー側がその意識を持たないと成立させ難いので、新人にはまずはウォーターフォール型で初期開発を行わせ、途中から仕様変更や不具合修正を行うフェーズでアジャイル式に移行させるのが効果的だと思います。
【システム開発の勘所】
私がベンチャー企業で数多くのシステム開発に携わり、失敗や成功を繰り返す中で大事な事をまとめると以下の通りです。これはこの後の転職でも再現性があったので大きくは外れていないのではと思います。
契約
案件の契約時点で失敗していることが多々あります。まずは要件がどの程度明確に固まっているのか。開発範囲・責任分解点は明確か。作業内容と見積もり根拠をお互い理解し合意できているか。想定外の事象への対処方法（例えば期間の延長、追加予算、途中解約など）が明確か。開発後の保守やシステムのライフサイクルは考えているかなども確認が必要です。
可能なら顧客からRFP（提案依頼書）を出してもらい、提案書にて明確にするのが定石ですが、RFPを書けない顧客が多いので、その場合は一緒にRFPを作ってあげるしかないかと思います。顧客が自分たちの業務の事を定義できていない事は多いと思います。日本だけなのかわかりませんが、非効率な会社も多く無茶苦茶な内容も少なくありません。（何をシステム化して、何をシステム化しないかを一緒に決めまるのが大事かなと思います。）
アーキテクチャー
案件に適応可能な実績のあるアーキテクチャーを保持しておく必要があります。案件がWEBシステムならWEBシステムのベースとなるフロントエンドとサーバサイドのフレームワークと各種ライブラリやDB・インフラ管理周りのツール類（キャッシュ、レプリケーション、バックアップ、レストア、セキュリティ）の実装方針など一式のノウハウが必要です。ノウハウの無い業種のシステムは厳しいですよね。
特殊な連携や機能については、実装可能性の調査や、新しいアイデアについてはPoC（概念実証）を通してどこまでできるのか実現可能性を把握しておく必要があります。（契約にもPoCは完成基準にしないほうが良いので、準委任で契約を分けるなど配慮が必要）
チームビルディング
最も大事な事は、同様の案件を実施したことのあるチームを育てて置くことで、役割分担や仕事の進め方、誰がどのくらいのスキルや経験を持っているのかお互いに把握できていることが重要だと思います。
会社は大きくなると特に、良いチームを壊すときがあります。誰かの昇進や退職などをきっかけにメンバーを入れ替えてみたり、組織変更や人事異動の際に、ローテーション（他の部門を経験させるため）をしたりと・・・。ソフトウェアの会社では少なくともチームのリーダーに相談なくチームメンバーを変えるとチームが壊れますのでプロジェクト失敗のリスクが高まります。
小さい会社は組織力がそもそもないので、個人への依存と属人性が高く、その人が辞めると同じ仕事は続けられないといった事もあるように思います。
今は時代が変わり、あまり受託開発というものをしなくなってきているかもしれません。様々なクラウドサービスが出てきているので、自社の業務フローに固執せず、サービスにうまく適合して業務を見直せる会社が生き残るのかもしれません。そうなってくると昔ながらの受託開発は減っていくように思いますので、【システム開発の勘所】といっても時代遅れかもしれませんね。もう生成AIでプログラムソースも書ける時代ですから。
【儲からない仕事…】
もうすでに、お気づきの方も居るかもしれませんが、ここまで書いてきたような、短期（１年未満、半年や数ヶ月）の受託はあまり儲かりません。受ける側としては投資対効果が見合わないからです。
昔はそこそこ儲かっていたので、日本には大小多くのSIerが存在していたのだと思います。今はかなり数が減って、クラウド系企業に人材を吸収されているのでは無いかと思いますが、単純にオンプレからクラウドにプラットフォームを移しただけのビジネスも陰りが見えてきている事かと思います。
今は、SNSやクラウドの時代になっていますので、フリーランスなどの個人でバリバリ開発できるエンジニアにきちっと仕様を伝えて作って貰う方がコスト的にはメリットも大きく早い気がしますので、中小のSIerや人材派遣業の会社が苦しい時代かと思います。
ただそのフリーランスの方も生成AIがより積極的にシステム開発などで使われはじめると、生成AIに一部の仕事（コーディングやデザインやテスト）は持っていかれるかもしれませんね。
ベンチャー企業は大企業に比べて機動力があることがアドバンテージではないかと思いますので、儲からない仕事には見切りをつけて、儲かる仕事にどんどん挑戦できるようだといいなと思います。
転職に関係ない話を挟んでしまいましたが、【番外編①】という事でご容赦ください。
今回はここまで、また次回。
この記事が気に入ったらサポートをしてみませんか？