13
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

SENSYN ROBOTICS(センシンロボティクス) Advent Calendar 2019 の 25日目 担当の @tayasu です。

センシンロボティクスの開発部の部長をしております。
最初は1人でプロダクト開発をスタートさせ、エンジニアの採用活動を行い、今は15名となるエンジニア組織を作ってきました。
今回は今までにやってきたことを振り返って、どんな考えでスタートアップのエンジニア組織を作ってきたのかを書き殴ってみます。

プロダクト開発

内製化にこだわる

スタートアップはスピードが大切です。作りながら考える、考えながら作る、の連続です。
また、作った機能を再利用して別のプロダクトを作ることも多々あります。
こういったスピードと柔軟性が求められる開発は外注では難易度が高く無理ゲーです。

何でも自前で作らず利用できるものは利用する

内製化にこだわると言ってもリソースは限られます。世の中にプロダクトをどこよりも早くリリースするのが重要です。
そのためには何でも自前で作るのではなく、既存のソフトウェアやクラウドインフラが提供するPaaSなどを活用して短期間で高品質なプロダクトを開発します。

もちろん、自前で作らない場合は様々な制約が発生します。プロダクトが成長してくると制約にしばられてスピードが遅くなったり、できることに制限がかかってしまう事もあります。

最初のコードは今後の指針になるため押さえるべきポイントは考える

最初から完璧なコードや最高の開発環境は作れません。作ってる暇もありません。
しかし、最初のプロダクトがそのチームの文化となって、後から開発する人の指針になります。プロダクトは成長します。「三つ子の魂百まで」ではないですが、後から改善していくのは簡単ではないです。
では何を押さえるべきかというと、僕は開発効率に関わる事だと考えています。開発が効率化されていればプロダクトも早くリリースできるし、技術的負債の返却ハードルも下がります。
開発効率化の観点で以下は最低限用意しました。

  • テストコード
    • バックエンドのテストは極力書きました。がフロントエンドまで書くことはできず。その結果フロントエンドのテストが導入されるまでには1年以上かかりました。
  • 本番と同様なローカル環境
    • できる限り本番環境と同様の環境で開発できるように。開発効率に大きく影響します。
  • CI/CD環境
    • テスト・デプロイの自動化も開発効率に大きく影響します。

リモートワークはしない

リモートワークにはメリット・デメリットがあります。また人によって向き・不向きもあります。僕は今のフェーズではみんなが同じ場所で働くことのメリットが大きいと考えています。

弊社がプロダクトを提供するドローン業界は新しい市場で、顧客のニーズも次から次と新しいものが出てきます。またプロダクトに必要な技術もアプリケーションからドローン、更にはドローンとの通信手段や搭載するカメラの選定など、ソフトウェアからハードウェアまでと幅広い知識とスキルが必要です。
様々なスキルを組み合わせて、世にない新しいプロダクトを、どこよりも早く創るには、すぐに誰かに相談できる、他の人がどんな物をつくっているか確認できる環境が必要だと考えています。

あとは、ドローンの実機を使った確認作業や、ドローンを含めたハードウェアの組み立て、3Dプリンタを使った部品作成など、リモートでは物理的に難しい事が多いという事実もあったりします。

ちなみに、関連会社が働き方改革を推進している会社のため、リモートワークをする環境は整っています(Web会議のセットアップやヘッドセットの支給など)。そのため、家族の面倒を見る必要があるとか、台風などの気象状況とか何らかの理由で出社が厳しい場合はリモートを推奨しています。

マネジメント

できるかぎりフラットな組織

スタートアップは作るものもビジネス環境も流動的で変化に対応しないといけません。そのためには素早い意思決定が必要です。スタートアップが大企業に勝る点でもあります。
素早い意思決定と、それを実現する情報集約のために、マネジメントは限界まで1人でする事にしました。How Google Worksに書いてあった「マネージャーは最低7人の直属の部下をもつこと」という「7のルール」も参考にしています。

もちろん1人ではやりきれない事もだんだん出てきます。その時はタスクを少しづつ委譲しています。
プロジェクトが増えてきたら、細かい進捗管理はプロジェクトごとに任せ、採用活動やメンバー育成はテックリードポジションを作り任せていきます。

開発チームは流動的でプロジェクトごとに作られては解散していきます。こうすることで属人性が多少解消されるというメリットもあります(属人性を無くすことは難しいです)。

目標設定

重要です! 弊社ではMBO(Management By Objective)を取り入れており、半期ごとに目標設定と評価、途中の四半期ごとに目標の見直しを行っています。
MBOはメンバー自らが目標設定を行います。とはいえ何かしらの大きなゴールがないと誰もまとまな目標は作れません。
全社目標をもとにプロダクトロードマップを作り、そこからチーム目標、個人目標と落としこんでいく必要があります。まずは経営層、マネジメント層がしっかりするゴール設定をすること。そこから始まります。
その上でメンバー自らが目標を作ることで、本人もマネージャーも納得したものができるはずです。

更に大切なことは、マスト目標とストレッチ目標を必ず設定することです。目標設定はメンバー育成の場でもあります。みんな言われたことしかやらない、新しい技術にチャレンジしない、といった不満がある組織はストレッチ目標が無いことが原因かもしれません。

また、スタートアップやベンチャーありがちなのは、途中で状況が変わって当初目標と全く別なことをやる事になり、「目標設定意味無い論」が出てきてしまうことです。これは途中進捗確認時のすり合わせと四半期ごとの見直しで軌道修正を丁寧にしていくしかありません。目標設定に意味ないことなんてありませんから。

1on1

これまた重要です。当初は30分を週1で、10名を超えた頃からは隔週で実施しています。目標設定のすり合わせ&進捗確認、意思決定するための情報収集、問題発生時のフィードバックなどなど、1on1はマネジメント業務の中心となります。
最近は人数が増えてきて隔週の実施が難しくなってきたので、これからは1on1もテックリードへ委譲していきマネージャー1on1は月一にしていく予定ですが、本当は回数減らしたくないです。

マネージャーへのフィードバック

メンバーには半期ごとにマネージャーへのフィードバックアンケートを実施しています。アンケートはGoogle re:Workで公開されてるものをほぼそのまま利用しています。アンケート回収後はメンバーみんなの前で回答を公開して、良かったこと悪かったこと改善することを振り返ります。

マネージャー自身がどう評価されているかは絶対に知るべきです。自分の苦手なことが明確になり、また反対に自分が得意なことに気づく時もあります。更にはメンバーの不満を知る機会にもなる貴重なツールです。

採用

採用は永遠の課題です。一緒に働いてくれる人がいないと何も作れません。だからといって誰でも良いわけではないです。当たり前ですが。
採用基準はいくつかありますが自分より優秀な人を採用するというのが重要な基準のひとつです。自分にはないスキルセット、自分にはなかったポテンシャル。人員不足には常に困っていますが妥協はできません。

面接では、コーディングテストやホワイトボードを使ったアーキテクチャ説明をしてもらっています。アーキテクチャの議論がスキルセットが一番見えてくるし、何よりいろんな事例が聞けて楽しいです笑

ついでに弊社センシンロボティクスの採用ページはこちらです。
https://www.sensyn-robotics.com/recruit
技術で社会課題の解決に興味がある方、ぜひご応募ください。お待ちしてます!

おわりに

ここに挙げたことは、変化が大きくこれから伸びていくであろう事業(ドローン事業)でのスタートアップ/ベンチャー企業の今のフェーズのやり方考え方で、会社の規模や事業内容で変わってくると思います。もちろん僕らもずーっと同じやり方考え方をしていくつもりは無いです。
そのため様々な意見もあるとは思いますが、どなたかの参考に少しでもなれば嬉しいです。

13
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?