どーも、MODE, Incでソフトウェアエンジニアをやっている島川です。
本エントリーではMODEの開発体制についてお話をできればと思います。
背景
本題に入る前にかんたんにMODEのざっくりとした紹介をしたいと思います。
- IoTプラットフォームの開発を主に行っている（詳しくは前回のブログエントリ（IoTクラウドとしてのMODEの紹介 - 概要編 - - MODE JAPAN Developer Blog）を参照）
- 2018/9にシリーズAの資金調達を行ったベンチャー企業
- 日米の二拠点開発体制で、アメリカにはCTO含め7人、日本には5人の（主にソフトウェア）エンジニアが在籍しています（2019-11-25時点）。
- 日本とアメリカにそれぞれ開発するプロダクトの軸を据えて開発を行っている。
前回のブログエントリで触れましたが、MODEでは、サービスは基盤となるクラウドサービスと、産業別に特化したゲートウェイ（センサーデータを集め、クラウドに送るためのエッジコンピュータ）を主に開発しています。基本的には、アメリカではクラウドサービスを、日本ではゲートウェイ（及びそのアプリケーションサーバー）の開発を中心にしています。
なお、ベンチャー企業としては平均年齢が割と高め？で、日本ではエンジニアの平均年齢は約40歳くらいです。
開発フロー
次に、前項でお話したように環境下において、具体的にどのように日々開発を行っているか紹介していきたいと思います。
2ヶ月に1度の目標設定
我々に限らず、スタートアップ企業において、やることは無数にあるものの、開発を行う人的リソースは限られているので、適切にやるべきことを絞り、ビジネスを成長させるために一番なことに最大限集中する、ということが運営上の大きな課題になると思います。
我々の場合、それを、2ヶ月ごとに行われる「目標設定」を通じて行っています。
評価制度上、目標設定を組織的に行っている企業も多いかと思いますが、それに近いかと思います。
MODEにおける目標設定は、拠点ごとに全メンバー参加で行い、
- 社全体としてビジネス上最も優先的に進めるべき課題を明確化する
- 誰がその課題を先導するかを明確にする
ということを決定します。
これにより、次の2ヶ月間に誰が何をすべきか、ということがはっきりします。このように大枠の方向性を決めることで、あとの具体的な進め方は各メンバーが責任を持って計画・遂行していく、という流れになります。
目標設定を行った後、1ヶ月後に中間振り返りを行い、進捗状況の確認及び状況変化の共有や目標の見直しを行います。また、2ヶ月の期間が完了した後に、目標に対していの振り返りを行い、改善点等の共有を行います。
かつては、3ヶ月や1ヶ月等のサイクルにもトライしたことがあったのですが、3ヶ月だと長過ぎて小回りが効きづらい、1ヶ月だと短すぎて「成果」を見るのが難しい、という経験から最近では2ヶ月というサイクルが定着しています。
開発プロジェクトの進め方
2ヶ月ごとにゴール設定を社全体として行い、情報共有や目線合わせを行っていますが、一方で、新機能開発等の開発プロジェクトのサイクルは必ずしもこのサイクルとは一致しません。そのため、開発プロジェクトの発足やスコープついては、目標設定に影響を受けますが、開発プロジェクトの進行それ自体は、2ヶ月の目標設定サイクルよりも短い場合もあれば、複数の期間にまたがるような場合もあります。
開発プロジェクト自体の進め方は（おそらく）オーソドックスなもので、基本的には仕様検討 -> 設計 -> 開発/テスト -> リリースのような進み方をします。
特にスタートアップ企業においてはおそらく是非があるかとは思うのですが、MODEでは設計書（社内ではDesign Docと呼ばれる）を作成し、ピアレビューを行うことが推奨されています。設計書に何を書くのか、という点については大まかな指針があるものの、詳細度や内容については、そこまで決まりがなく、それぞれの担当者が特に実装前に他のエンジニアからの意見をもらいたい点や、ディスカッションが必要な点を列挙します。このフェーズでは必要に応じて、プロトタイピングやPoC開発を含むような場合もあります。開発フェーズではGithubを使ったピアレビューをベースにした開発を進めます。
設計デザインに対しての考えは様々だと思いますが、高レベルなアーキテクチャの変更は後続フェーズでは大きなコストになったり、ピアレビューの段階での行き違いを低減させる上で有効に機能していると思われます。余談ですが、ドキュメント作成自体は、すべて英語で書くことがルールとなっており、不慣れなメンバーも多いですが、レビュワーが文法の間違いを指摘してくれたり直してくれたりするので、入社一定期間すると割と英語でのドキュメンテーションに慣れて、英語コミュニケーション力も向上するというメリットがあります。
また、IoTプラットフォームの開発ならではな部分でいうと、センサー等の物理的なデバイスを対象にした開発をすることが多く、ユニットテストだけでは品質を保証し切るのが難しい部分も多く、早期に動くソフトウェアをビルドしていき、ドッグフーディング等の形で早期に現実の世界でソフトウェアを動かして、フィードバックを得ながらプロジェクトを進めていくことも多くあります。
開発文化
以上、大まかな開発フローについてお話してきましたが、次に、もう少しMODEの開発者文化について触れさせていただこうと思います。
MODEではCEOの上田ガクのポリシーで以下のような点を特に重視しています。
- 個人の成果よりもチームプレーを
- 仕事を通じたエンジニアとしての成長
このようなカルチャーのもと、実際の開発プロジェクトの遂行以外に以下のような取り組みを行っています。
- 360度フィードバックの実施
- レビューは個人タスクよりも優先の原則
- 日米のエンジニアによるジョイントプロジェクト
- google meetを利用した日米拠点間の常時接続環境を作り
- 日米のチーム間で定期的に社内（技術/非技術）Meetupの開催
開発拠点はそれぞれ別個に置きつつも、相互のコラボレーションを多くとるようにしています。 これによりチーム間でのサイロ化を防ぎ、また、日本のエンジニアにとっては日々英語力の向上にもつながっています。
以上、簡単ではありますが、MODEの開発のすすめかたについてお話させていただきました。
もしもMODEの開発に興味を持っていただき、もっと話を聞いてみたい、という方はお気軽にお問い合わせください。