受託開発歴20年越えのエンジニアがSaaSのスタートアップに転職した話

はじめに

自己紹介

こんにちは、コミューンのUS事業でエンジニアをしています”さわだ”と申します。 今年4月からコミューンにジョインしました。

前職は大手IT企業のソフトウェア開発子会社で20年以上受託案件に携わってきました。
親会社からの大規模案件よりも、数人から多くて10名程度の直顧客案件や研究所関連の仕事が多く、入社後はJava Appletから始まって、OpenGLを使っった3Dアプリ、Webページ、Androidアプリ、はたまた機械の制御アプリなど様々なジャンルの開発をしてきました。

2014年にはアメリカのスタートアップと一緒に開発をしたり、直近では技術調査部門に所属しシリコンバレーに3年間駐在するといったグローバルな経験もしてきました。

アメリカ駐在の頃からスタートアップに興味を持ちはじめ、たまたま日本発の世界に向けたサービスを目指すコミューンがUS事業のエンジニアを募集しているのを見つけ、ジョインしたいと思うようになりました。

現在は前回執筆した”ざびえる”さんと同じチームで多言語化処理を中心にプロダクトのグローバル化を実装しています。

tech.commmune.jp

この記事について

発注をもらって、開発して、納品して… ということを繰り返してきた筆者が、SaaSのスタートアップであるコミューンにジョインしてみて、どんなことを思ったのかを気の向くままに綴ってみました。
あくまで、個人の経験と照らし合わせてのことなので、一般論としての受託開発との比較ではありません。 その辺は「ふーん、そうなんだ」位の軽い気持ちで読んでいただければと思います。

肌で感じたスタートアップのパワー

圧倒的なスピード

受託時代は、基本一度の本番リリースが最終目標でそれに向けて作業をしていました。リリースまでに様々なテストで品質を整え、手動でのデプロイ手順を何度も確認し、そして本番に挑むというのが当たり前でした。失敗したらお客様への報告書だけでなく、社内でも色々と事務作業がまっていました。
とは言っても、いくらやっても失敗はするもので、お客様と全く同じ環境でテストし準備したにも関わらず、夜間作業で更新に失敗し、翌朝の営業開始までにロールバックするというヒヤヒヤ体験もありました。今は良き思い出です。

それに比べるとコミューンではプロダクトのアップデートのスピードがとにかく早いです。 1日に何度もリリースが行われています。一気に変わるというよりも、少しづつ改善されるイメージです。
ぱっと見何が変わったのかわからない場合も多いですが、確実に成長しています。

そんなスピードを支えるためテストの自動化もきちんと整備され、安全にリリースができる仕組みが整っています。 とはいっても、事故は起きてしまうもので、まだまだ改良の余地はありそうです。その辺はSREやQAチームが中心になって日々改善しているのが強みなのだと思います。

また、圧倒的なスピード感の裏にはSlackも欠かせません。E2Eの実行から、各種環境へのデプロイなどもSlackのコマンドで実行し、デプロイ結果もSlackに通知されるので、お互いに今どんな状況なのかも一目でわかるようになっています。

エンジニアがみんなすごい

受託の時は、必要なスキルを持った人を社内や協力会社などから集めるというやり方でした。そのため、ある程度の知識や経験があれば十分で、あとはやりながら覚えていくということが多かったです。プロジェクトを計画する際にも、人材育成計画という項目があったくらいですし…。 そんな中、私自身は休みの日でもプログラミングの勉強をしたりするタイプなので、知っている方の人という立場にあることが多く、何かあったら聞かれる側にいました。

ところが、コミューンでは違いました。コミューンのプロダクトはReactやNode.jsとTypeScriptがベースになります。なので、それらに対しての知識が凄いです。元々その辺に詳しい人が集まったというのもあると思いますが、長い期間同じ技術に触れることでどんどん研ぎ澄まされていっている、そんな印象です。 また、ライブラリ一つにしてもただ使うというより、きちんと理解して使っているという印象を受けました。

正直私からみたら「これ結構な応用テクニックだよな」と思うことでも、当たり前のようにやっているので、凄いなあと感心しつつ、いろいろなテクニックを学ぶチャンスだと思っています。

開発のやり方の違い

ブランチを切るか、切らないか?

受託では納品時に全ての機能が正しく動くことが全てでした。そのため、細かなブランチのマージを繰り返すよりも、一本の開発ブランチに対してみんなで手を入れる、そんなやり方がほとんどでした。 他の人の修正をいち早く取り入れることが重要で、その取り込みが遅れれば遅れるほど、後で大変になるという考えでした。

一方、コミューンでは、先に述べた通り、リリースの頻度が高く常にきちんと動くものが求められます。 そのためには小さな修正をコツコツ積み上げていく必要があり、ブランチを切るという作業が必然となります。 ブランチ切るのに慣れていない筆者はgitのブランチ操作に苦労しました。 入社前にUdemyで学習したりしたのですが、やはり実践経験が足りませんでした。

複雑になったソースコードも、前職ではあるタイミングで一斉にリファクタリングをかけたりしていました。 しかし、ブランチを切って常に動く状態を保持している今は中々そうはいきません。 そのため、コミューンでは「ボーイスカウトルール」というものがあります。修正後は修正前より美しくということで、修正箇所だけでなく、関連するところも含めて少しづつ良くすることが求められます。その小さな改善の積み重ねで全体をよくしていこうという考えです。

対面レビューとプルリクエスト

受託時代は、ウォーターフォールでの開発が多かったので、レビューは工程の終わりに集まって対面で行うことがほとんどでした。そこではレビューされる側が、コードで実現したかったことを説明し、その説明に対して正しく実装されているのかを確認していました。仕様書が正で、またその人の話す内容が正でした。

一方、コミューンでは、GitHubのプルリクの中でレビューが進行し、仕様は色々なところに書かれている情報から判断しています。 プルリクエストのタイトルだったり、説明、ソースの行コメントや、チケットのタスクの説明、修正確認方法、社内の関連ドキュメントなど多岐にわたります。 説明を聞いてレビューすることに慣れている筆者にとっては、結構大変な作業です。 幸い、コミューンのエンジニアはGatherという、RPGゲームのような空間でお互いにいつでも話しのできるサービスを使っているので、聞きたい時にいつでも話ができるようになっています。

Gatherでお話し中

楽になったこと

受託固有の苦労からは解放

実は、受託時代に密かに大切にしていたことがあります。 それは、商談を切らさないことでした。 プロジェクトが終わる頃に次の仕事が決まっていないと仕事がアサインされるのですが、これが恐怖でした。客先常駐のプロジェクトだった場合、長距離通勤か単身赴任が待ち構えています。
なので、私は常に並行して商談獲得に動いていて、自社に持ち帰ってできる商談をキープする努力をしていました。 今は自社サービスなので、そんな心配は無くなりました。

また、今までは受注手続きから工数管理、プロジェクト計画書を作ったり、納品物を揃えたりというのを全部やっていたのですが、ここでは役割分担がはっきりしているため開発に集中できるようになりました。

今後の展望

いろいろと違いを挙げてきましたが、じゃあ、筆者のように受託開発で頑張ってきた人たちがSaaSスタートアップではどのように活躍していけば良いのだろう?を考えてみました。

一番に思いつくのは、品質に関わるところかなと思っています。要因分析から始めて、境界値だとか、異常系だとかしっかりとテストをしてきた経験は財産だと思っています。 例えば、エラーは投げているけれど、実はそれをきちんとハンドルできていなかったり、E2Eは書いているけれど網羅性が足りないのではと思うことが多々あります。そういったところを少しづつ見つけては直していければと思っています。

また、前職では「3ヶ月あるいは半年後に書いたコードを理解できるか」を常に言われ、言い続けてきたので、その辺の知識はうまく広めていければと思います。

最後に

受託開発からSaaSのスタートアップに転職した筆者ですが、何とか頑張っています。 今はまだリリースのスピードに慣れること、ベースの技術力アップをすることに必死ですが、プロダクト・ソースコードの品質向上という部分では貢献できるかなとも感じ始めています。

今回は開発についての違いを色々と書いてきましたが、組織の面でも思うところは多々あります。 その辺は次の機会に触れられればと思います。

meety.net

commmune-careers.studio.site