エンジニアは皆一度は受託開発をやるべきではと思った話

エンジニアは皆一度は受託開発をやるべきではと思った話
世の中のソフトウェア開発会社には、大きく分けて２種類が存在します。

・WEB系自社サービス開発企業

・システムの受託開発企業（いわゆるSIer）

弊社は言わずもがな全社のWEB系自社サービス開発企業に類するわけで、自分はそこに新卒で入社しひたすらせっせと「自分のプロダクト」を磨いてきた次第です。

お陰様で、プロジェクト立ち上げ当初の利用者数が０社だったころに比べれば利用社数も４桁を超え、弊社の一つのメインサービス（と信じたいと思っている）となったわけです。

そこに対しては自分の力なんて微力だと思いつつも、携わり続けた結果だとなんだかんだ謙遜を含めつつも自信と自負を持つまでに至りました。

そしてありがたいことに最近では、自社サービスの枠を飛び越え、クライアント様とのやり取り含め、受託開発系の案件にもいくつか携わらせて頂いております。

受託開発は、直近での売上インパクトやコスト管理、余談を許さない納期設定、リスク事項の説明責任、ときに自社内では採用し得なかった要望や必須要件をインプットしつつこなすなど、自社サービスとはまた違った趣を持つお仕事でした。

２つの環境を比較しながら、この「プログラミングにより商品開発を行う」という点以外は全く異なる２つの環境の中で、自分の中でのそれぞれ異なる能力値の伸びしろを感じているこの頃です。

そしてその中で考えるようになった

「頼れるエンジニアに育つ環境」とは？

という命題。ここに対して、特に最近持つようになった持論について、備忘的にまとめることとします。ここまでが前振り。なげえ。。。

でまあ、結論から言うと

「エンジニアは皆一度は受託開発をやるべき」

というお話です。なぜそう思ったかという根拠のところは２つ。

根拠１つめ。
ちゃんとした受託開発のプロジェクトには、「エンジニアとして身につけるべき基礎」が一通り詰まっているのでは

ということ。

開発する案件にももちろんよってくるのは承知な上ですが、なんやかんや大なり小なり、受託開発はゼロイチなスタートなわけですから、

環境構築、要件定義、DB設計、アプリケーション設計、納品までのスケジューリング、開発、テスト（いろんな意味の）、セキュリティチェック、ドキュメント作成、納品後の運用引き継ぎ

など、など、改めて「今まで断片的にいろいろやったよな」というものを再度整列してやってきたような感じになりました。しかるに、１つずつの意味をインプットしていけば、自ずとフルスタック的な要素のエンジニア業務が可能になるのでは、というお話です。

根拠２つめ。
「そもそも社会人として約束を守る」というシビアさを自社サービスの開発より感じやすいのでは

ということ。これについては自社サービス系の開発に携わる方からは異を唱えられることを覚悟で言いますが、大前提として

「約束が守れないと会社が潰れる」

がより明確に存在するのが受託開発だと思います。だって納品遅れたらお金入ってこないんだもの。

「自社サービスだって納期遅れたら利益でなくて潰れるわ」

ってまあそりゃそうなんですが、やっぱり「来月クライアントからお金がもらえない」というシビアさには勝てません。※ただし毎月売上を確保しなければならないスタートアップは除きます。

必然、約束を守ることを小さなことから要求されるようになります。

毎日の進捗報告、レポーティング

事前のスケジューリングとその遂行

細かな約束を守ることによって信頼を積み重ねる、ということを学びます。

そしてさらに、「約束して、遂行する」ということを日常的に自らに課していくことによって、
そのプロセスが自分を成長させていることに気づくことになります。これもまた大きい。その身についたプロセスを再現性ていくことで、自ら成長できる自立型人材に成長することとなるからです。

この重要性は自社サービスの開発をするときにこそ進化を発揮するのでは、とも今更ながら思います。

結局、我々はエンジニアである前に社会人である

まあそういうことだったな、と当たり前の事に気づいたわけです。

「いい加減目覚めなさい」

おわり。

あでも、最後らへん書きながら、「これって受託開発後にステップアップできること」が前提じゃね？と思いました。
自社系サービス企業にて、受託開発案件を経験するのが最強、ということ。そういうことだった。