[レポート]ソラコムの開発プロセスとカルチャー 〜2週間サイクルのリリースを続ける開発スタイル〜 – SORACOM Technology Camp 2020 #SORACOM

2020年11月に開催されたイベント「SORACOM Technology Camp 2020」で行われた以下のセッションに参加しましたのでレポートしたいと思います。

セッション情報

概要

ソラコムでは2015年9月にサービスをローンチして以来、2週間に1回のサービスや機能改善のリリースを欠かすことなく続けており、2020年10月時点で18のサービス、120を超える機能追加を重ねています。これを実現するためにどのように開発をおこなっているのかについて、SORACOMのプロジェクトマネージャ江木がお話しします。

スピーカー

江木 典之 様
株式会社ソラコム
グロースエンジニア

アジェンダ

• SORACOMは2週間1回のリリースを欠かさず継続
• 17のサービス、130を超える機能追加
• そのカルチャー、プロジェクトマネジメント

• 2015年当初は Air と Beam の2つだった。

• リリースはブログと必ずセットなので是非チェックしてください
  • 2週間に1度ブログ出してるので、出てなかったら途切れたんだなと思って。

なぜ2週間に一度のリリース？

• ツイッターやサポートからのフィードバックに応えたい
• リリースの継続でソラコム知ってもらう機会になる
• 知っている人にはより深く知ってもらえる
• 2週間の理由はイテレーションが2週間だから

継続するための姿勢 - プロジェクトマネージャー視点

• プロジェクトマネージャー視点
  • 標準プロセスはない。
  • あると守ろうとしてしまう。
    • 本来やらなくていいことをやってしまう可能性
• 最短距離でやりたい

アジャイルマニフェスト

• アジャイルマニフェスト
  • 右側よりも左側に価値を見出す
  • 右側がが悪で左側が正義？
  • 左側できるならそうすればいいし、真ん中を選んでもいい
  • 複雑性の要因が多そうなら右に寄せてもいい
  • アジャイルかどうかの分かれ目はどっちでもいい。
  • 開発するもの、メンバーによって考えるのがいい

• 判断の基準はリスク
  • リスクは4つに分けられると言われている
• 作ろうとしているものにどんなリスクがあって、どう回避するか、少なくするかによって右か左かを選んでる

開発対象によってプロセスを選択

機能拡張のパターン

• （例として）Beam にプロトコルを追加する、Funnel にクラウド追加するとか
• 典型的なやり方はまず API を定義
• API を介して各コンポーネントを開発できる
• これはシンプルなパターン

新サービス開発のパターン

• 新サービスの開発はもうすこし複雑
  • 架空のプレスリリースを書く
  • 架空のエンドースメントを書くこともある
  • 誰にとって何がうれしいか書くのでユーザー視点でどう見えるか確認できる
  • リーンキャンパスを書くこともある
    • 課題が何で、どういうソリューションがあって、サービス出した後にどういう指標を見るか、どのチャネルを見るか

ドキュメント

• 3つのドキュメントがそろって開発に着手できる
  • ユースケース仕様書、主要なコンポーネント図、シーケンス

継続するための姿勢 - カルチャー視点

• 全員がリーダーという考え方
  • 自分が課題と思っていることに対してどんどん手を動かす文化

• 称賛される行動
  • やってみました。動きました。そんなこともあろうかと！
  • 「動くものができちゃったんでリリースしたいんですけど…」
    • それは大概いいもの

これからのチャレンジ

• 2015年はエンジニア数人だった
  • Air と Beam だけ
• 2020年はエンジニアも3倍くらいに増えた。サービスも増えた。
• 意思決定の時間とかが前よりも掛かるようになってきた

チームを疎結合に

• フレームワークも参考にしつつ
• コミュニケーションを減らしたらどうだろうかと考えた
• 疎結合にコミュニケーションを極力なくせるように
  • 取り組み始めたところなのでこれがうまくいくかどうかはまだ。

• 無駄のないプロセスを意識して、これからも動くものをどんどん作る

質疑応答

• 判断基準のリスクについては何かしら定量的に評価されたりしてますか？
  • まだ定量的にはやってない。リスクは色んな人に聞くことを心がけている。
• 各チームが疎結合だと、チーム間の壁ができるなどのリスクもあると思うのですが、どのような対処を考えていますか？
  • そういうリスクは気をつけるようにしている。
  • もともと属人性を恐れるよりもスピード重視。チームで補える体制を採っている。
  • チーム毎が素結合になって壁ができるのは今は恐れる必要はないと考えている。
  • チームが独立して意思決定を早くできることを優先している。
  • 状況に応じてどんどん変えていきたいと考えている。
• チームメンバー数も増えてきているかと思いますが、カルチャーを維持するために気をつけていることは何ですか？
  • 答えはないと思っている。4半期に一回レビューしている。
  • チーム全員でリーダーシップステートメントを見る。
  • 一番体現した行動は何か皆で考える。振り返ることで「できてなかったな」ということに気付ける。
• 当初のリリースプランにないものを途中で入れる、というの、結構リスク大き目だと思うんですが、入れるかどうかはどう判断しているんでしょうか？
  • リリースプランにはなくてもイテレーションが始まっても、その中に入れるということはしない。
  • リスクが多ければその削減方法を考える。
  • プランに固執することは望ましくないので柔軟に対応できることを心がけている。

資料

最後に

私の普段の業務では関わることのない分野の話だったので、とても興味深い内容でした。特に「リーダーシップステートメントを一番体現した行動は何だったか皆で考える」というのは、個人的にも実践していきたいなと思いました。

以上です。