くんぺー @ymdpharm です。
Ubie には1年くらい在籍していて、これまで主にデータサイエンスチーム (DS チーム) と呼ばれるチームでエンジニア or スクラムマスターとして振る舞ってきました。
スタートアップの最重要課題は打席に多く立つことです。この課題に対してどう貢献できるか、技術フォーカスのチームにいて意識してきたことを振り返ります。
3行でいうと、
- 目的不確実性と方法不確実性を明確に区別して
- どのチームで処理するべきかを判断して柔軟に振る舞いつつ
- 最速でデカい山を登ろうぜ
です。
前提
DS チームはその名の通り Ubie のデータアセットの蓄積やアルゴリズムの活用・改善に関心を持つチームです。API を介してプロダクトチームに機能を提供したり、データを収集・分析したり、協働したり、が主なミッションです。医師とエンジニアで8人程度のチーム構成です。
比較的専門性が高いと同時に、ユーザやビジネスと接することが少ないチームでもあります。
よくある話
これまでいくつかの組織でデータサイエンス関連の仕事をしてきて、組織の大きさによって異なる難しさを経験してきました。
数十人規模の独立した大きい R&D 組織に所属していたときは、技術的なチャレンジはできていたものの、プロダクトサイドとのコミュニケーションコストが大きいことの難しさを感じていました。方針決めに時間がかかってしまったり、お互いの前提が異なっていて、本当に必要なものが作れないもどかしさを感じることが多かったです。
反対に、全メンバーで合わせても20人程度の小さいプロダクトにいたときは、意思決定や情報は内部で閉じていて動きやすかったものの、開発面でも保守面でもリソースが足りなくて技術的に高度なことに取り組めないことがありました。
専門的なチームを構成することと機動性を保つことのトレードオフに、同じようなモヤモヤを抱えている人は多いのではないでしょうか。理想のチームを作ることは難しいです。
組織論の話
ここで、参考になりそうな組織論の話を少しつまみ食いしてみます。
まず、エンジニアリング組織論への招待[1] には以下のように書いてあります。
企業という組織は、組織全体を通じて、何かを実現するために、より曖昧な状態から具体的な状態に変化させるということを行っているのだと俯瞰できます。いわば不確実なものを確実なものに変化させる「処理装置」なのです。
マーケット不安やスケジュール不安の両方を構成する大きな不確実性から優先的に対応できるようにするというのが、アジャイル開発の基本的な思想となります。
会社は不確実性を削減する装置であり、WHAT に該当する目的不確実性と HOW に該当する方法不確実性をどちらも削減する必要がある。種類は何にせよ、不確実性の大きいところから順に潰していくのが理想である、という話と読めます。
これはとても納得感があって好きな抽象化です。この本を読んだときには少し世界が変わったのを覚えています。
一方、アジャイルソフトウェア開発宣言[2]はもう少し過激で、
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
顧客の需要を探索すること (目的不確実性の削減) こそが重要だと言っていそうです。専門チームが切り出される前のアーリーなフェーズで、主にエンジニアリング領域を想定した話のようです。
次にチームトポロジー[3]を見てみると、(本の趣旨からすると枝葉にはなりますが) 専門チームとプロダクトチームの関わり方について以下のように書かれています。こちらはより成熟した企業を想定した話のようです。
コンプリケイテッド・サブシステムは ...(中略)... 初期の探索や開発の段階では、ストリームアラインドチームと密接にコラボレーションする。サブシステムが安定してきたら、インタラクションを減らし、サブシステムのインターフェイス、機能の使用状況と進化に集中する
(コンプリケイテッド・サブシステムは専門チーム、ストリームアラインドチームはプロダクトチームのようなものを指します。)
つらつらと引用を並べました。解釈を含めてまとめると以下の様なことが言えそうです。書いてみると当たり前な感じもしますね…！
- 前提として企業・チームは目的不確実性と方法不確実性をどちらも削減する必要がある。アーリーなフェーズでは前者が重要だが、専門の分業が進むと後者の重要性が増す。
- 関心を分離した専門チームは、2つの不確実性のどちらに向き合っているかに応じて他チームとのコミュニケーション方法をスイッチすると良い。
Ubie での話
Ubie は総勢200名を超える規模になってきて、日々取り組むテーマのフェーズは様々です。例えば、新しく立ち上げるサービスに対して構想の段階からデータ関連領域のヘルプに入ることもあるし、すでにある仕組みをより良くすることに注力することもあります。会社としてのフェーズが変わろうとしています。
自分ははたして、前述のような「タスクの不確実性の種類」を意識した振る舞いが出来ているでしょうか。振り返ると、今はそれなりにワークしている実感があります。
理由のひとつには組織の文化があります。
Ubie Discovery では、ホラクラシーなどの仕組みで自分のリソースの割り振りが極力コントローラブルに保たれています。そして、この文化は専門組織の理想的なあり方ととても相性が良い実感があります。
具体的には、各メンバーは「どこでタスクを処理するべきか」を考えて柔軟に振る舞うことができます。つまり、プロダクトチーム側と密に連携するべきと思われるときはいっそ DS チームを飛び出してプロダクトチームのスクラムに属してしまう、ということがカジュアルにできるわけです。どのチームでタスクを処理するかの判断は、前述の不確実性の種類に基づいて考えると良さそうです。目的不確実性が大きければプロダクトチーム側で処理して、方法が重要なのであれば DS チームで引き取って処理するような流れです。
自分の直近の稼働割合をみると、3割がプロダクトチームに混ざって稼働、7割が DS チームで生んだ or 持ち帰ってきたタスクに向き合う、といった感じでした。
この割合はこれからもしばらくは継続していきたいと思っています。会社全体での目的不確実性の削減に貢献しつつ、方法についての知識が重要になるテーマは DS チームに持って帰ってくることで大きな課題にも取り組める、ちょうどいい割合が 3:7 でした。
とはいえ兼任にはデメリットもあります。まずシンプルに疲れます。
チームに所属するということはスクラムに所属することと概ね捉えてもらって問題ないのですが、複数スクラムの兼任は一般的に非推奨とされています。チーム内コミュニケーションやコンテキストスイッチのコストと向き合わないといけません。個人的には、バランスを取るために以下を気をつけています。
- 割り振るリソースの割合を明確に表明する (期待値調整)
- スクラムイベントを任意参加・非同期にすることでスリム化 (コミュニケーション効率化)
- 1日ごとに作業内容をスイッチ (コンテキストスイッチコスト削減)
特に3つめは意識していて、自分はエンジンが温まるのに時間がかかるタイプなので、今日はこのチームでの活動をやるぞーということを決めてしまうととてもラクです。(とはいえ課題感はまだ感じていて、そこは改善テーマ…)
最後に、これは余談ですが、社内には DS チームを飛び出したまま帰ってこないメンバーが結構います。ネガティブな話ではなく、そうすべきと判断した結果であってとてもいいムーヴだと思います。
今後より組織が大きくなったときは、チームトポロジーに書いてあるようにチーム間のコミュニケーションをチームレベルで担保するようになるのかもしれません。それはそれで楽しみですね！
おわりに
目的にも方法にもリソースをベットして、最速でデカい山を登りたいですね！Join us！
Discussion