フリーランスと正社員のいいとこ取り？HANOWAの開発組織を紹介！
2019年、あなたはどんなふうに働いていましたか？
コロナ禍によってリモートワークが普及し、エンジニアの働き方は大きく変わりました。
通勤や飲み会がなくなり、家族との時間や自分の時間が増えたりストレスが軽減したりと、リモートワークの恩恵を受けている方も多いでしょう。
HANOWA唯一のエンジニア社員である佐々木もそのひとりです。
そして「働き方が変わることの恩恵を体感したからこそ、ほかの業界にも広げたい」との想いを胸に、HANOWAのプロダクトと毎日向き合っています。
今回はそんな佐々木から、今のHANOWAの開発組織の“ありのまま”をお伝えします。
SIerやWeb系ベンチャー、さらにはフリーランスとさまざまな業種や働き方を経験した佐々木だからこそ伝えられる、HANOWA開発組織の姿をみなさんに知っていただければ幸いです。
開発組織のミッションと個人の役割
こんにちは！HANOWAエンジニア社員の佐々木です。
2021年・2023年の資金調達を経て、これからさらにユーザー数が増えていくプロダクトHANOWA。
そんななかでの開発組織のミッションは、プロダクトのブラッシュアップを重ねることでサービスの質を高めていき、ユーザーがより快適に使える状態を実現することです。
それに向け、私を含めた4名のエンジニアが日々開発に励んでいます。
そのなかで私が今取り組んでいることのひとつが死活監視です。
今のHANOWAの仕様ではサービスが落ちてしまったとしても開発側にはその通知が来ません。
そのため、お客さんから「ログインできないです」とご連絡をいただいてはじめて把握することも多いのが現状です。
それを開発側で把握して素早く対応ができる状態を作るために、死活監視体制の整備に向けて取り組んでいます。
開発の進め方
HANOWAの開発組織には、今のところ明確な役割分担はありません。
また、一般的に言われるPMのような役割の人も存在していません。
私が過去在籍していた会社の場合は、PMやPMOがいて彼らがお客さんと要件や開発の流れを決めていました。
そしてその決定事項に応じてPLやサブリーダー、時にはSEが設計書を起こして、プログラマーに依頼するといった流れで開発が進んでいました。
多くの一般的な企業でも似たような流れではないかと思います。
一方HANOWAでの開発の流れはこれとは少し異なります。
COOやプロダクトマネージャーが、デザイナーと協議の上で仕様を決めます。
それに従いエンジニアが開発するという流れではありますが、その決定事項にエンジニアが意見を言うこともあり、あくまで開発に関してはエンジニア全員が決定する立場にあります。
どうやって実装するのか、どんなライブラリやフレームワークを使うのかも、エンジニア自身が決めていきます。
その上でもちろん実装もしますし、リリース作業も行うなどエンジニアの役割は多岐に渡ります。
そのなかで、プロジェクトや自分の稼働状況に合わせてさまざまな役割を主体的に担っています。
もちろん一人ひとりのキャリアや経験値によっても業務は変わってきます。
フロントエンドの経験が豊富な人材の場合は、バックエンド領域にまたがるタスクよりもフロントエンド中心で完結するタスクを行うことが多いですし、エンジニアとしてのスキルが高い人材の場合は、重めのタスクをお願いすることもあります。
また業務が開発組織だけで完結せず、他部署との連携が発生する場合もあります。
やりとりが多いのはデザイナーやカスタマーサポート(HANOWAではカスタマーサクセスと呼称)です。
基本的にはCOOやプロダクトマネジャーが行ってくれていますが、先ほどもお伝えした通り明確にPMがいるわけではないので、エンジニア自身が行うことも日常的です。
この点、部門間の距離が近いことで、エンジニアとして裁量を持って主体的に業務に当たることができます。
技術スタック
2023年5月時点で使っている言語やOSなどは以下の通りです。
サーバーサイド: Ruby on Rails, Ruby
フロントエンド: Nuxt.js, Vue.js, JavsScript
データベース: PostgreSQL, Firestore
インフラ: AWS, Firebase
その他: Git, GitHub, GitHub Copilot, Slack, Docker, CircleCI, JIRA, Notion
また、GitHubでのコード管理やNotionでのナレッジ共有、Slackでのコミュニケーションなど、スムーズかつ効率的に働くためにさまざまなツールを活用しながら業務を行っています。
エンジニアの働き方
HANOWAでは週1で同期型のミーティングを行っているものの、基本的には非同期のコミュニケーションで業務を進めています。
私も開発メンバーの誰かと直接会ったことは一度もないほどで、各々が自分のペースで業務を進めています。
私はHANOWAに入社するまで、フリーランスエンジニアとして活動していました。
働く時間や働く場所が自由な一方で、自分の能力を広げるのであれば社員の方がやりやすいんだろうなと感じていました。
フリーランスの場合は、バックエンドの勉強をしたからといってバックエンドに挑戦させてもらえるかと言うと、そういうわけにはいかないことが多いです。
でも会社であれば、挑戦させてもらいやすいんです。
それがHANOWAに入社した理由のひとつでもあります。
そして始まった久しぶりの会社員生活でしたが、HANOWAはフルリモートかつ働く時間帯もあまり問われないので、実はあまり社員として働いている感覚がないんです。
それなのに経験が浅い領域にも挑戦させてもらえて、「いいとこ取りだな」と思いながら働いています。
なので私と同じようにフリーランスを経験した方であっても、大きなギャップを感じることなく働いていただけるのではないかなと思っています。
今誰が何をしているのかもきちんと明確に提示されているので、リモートワークでよく言われる「誰が何をしているのかわからない」といった問題は起きにくい環境だと感じています。
また、テキストに残す文化が定着しているので、フルリモートであっても入社後もスムーズに業務に入っていただけるかと思いますね。
実際にほかのメンバーからも「オンボーディングが整っている」との声を聞きますし、なかにはセットアップを1日で終わらせて次の日から実務的な開発に入ったメンバーもいるほどです。
開発組織の課題
少し前まではまだまだスタートアップということもあって、開発サイクルも明確には定まっていませんでした。
現在は2週間を1スプリントとして、スピード感を持って開発を進めています。
これにより、期限があるからこそモチベーションを高く保てたりプレッシャーを感じながら働けるようになりました。
その反面、過去の技術負債が足を引っ張ったり、緊急のバグ対応が多く期限通りに進めなかったりといった課題も出てきています。
その解決のためにも、よりスムーズな開発を行う上で必要なルール整備や体制作りをしていかなくてはいけないフェーズです。
ルールで雁字搦めにならないように気をつけつつ、よりよい開発組織にできればと思っています。
今のHANOWAで活躍しやすいエンジニア像
自社プロダクトの開発をしていた方で、特に0→1や1→10のフェーズに関わられていたエンジニアであれば、すぐに業務をキャッチアップできるのではないかと思います。
そこに関わっていないと業務ができないわけではないですが、このフェーズの経験のない方だと優先順位付けに戸惑ってしまうかもしれません。
また開発の進め方の章でもお伝えした通り、現在のHANOWAの開発組織は役割が流動的かつ一人のエンジニアが担う領域も他社さんに比べて広い傾向にあります。
そのため、フルスタックで開発ができる方だと非常にありがたいです。
しかし私もサーバーサイドの知見は深くないですし、まだまだ勉強中です。面接でも「サーバーサイドやインフラ周りの知識は現状ないですが、これからやっていきたいです」と話した上で入社しています。
なので技術が高くなくとも、やりたい気持ちがあれば受け入れてもらいやすい環境だと思います。
一方で、幅広く取り組みたいというよりも「この道を極めたい」「これだけをやっていきたい」といった志向性の方は、今のHANOWAとは相性があまり良くないかもしれないですね。
一定の技術的知見やエンジニアとして開発に取り組んだ経験があって、さまざまなことに挑戦したい方やまだまだ荒削りなプロダクトをより洗練させていくことにやりがいを感じる方であれば、HANOWAで非常に活躍していただけると思います。
もし少しでも興味を持っていただけたのであれば、一度カジュアルにお話させていただけるとうれしいです。
🔻エンジニア社員としての働き方は、社内報ラジオでもお話ししています^^
この記事が気に入ったらサポートをしてみませんか？