チームで考える、フロー効率で考える
この記事はCAMPFIRE Advent Calendar 2023の1日目の記事です。
こんにちは。CAMPFIREでエンジニアリングマネージャーをしている小川です。CAMPFIREのクラウドファンディングの開発チームのEMになって1年半余りが過ぎました。
振り返ってみるとなかなか大変で、開発チームのあり方が試行錯誤を繰り返しながら、大きく変わっていく、そんな1年だったように思います。
新たなメンバーがたくさん入ってくださって、力を発揮していただいたということが大きいのですが、それと共に、組織に対する考え方が大きく変わっていきました。そんな組織への考え方で、今私が大切にしている指針についての話を今回は書いていきたいと思います。
現在のチームのフェーズにおいて、EMとして私が大切にしている指針は2つあります。
リソース効率ではなく、フロー効率で考えること
個人ではなく、チーム単位で考えること
上記2つはチームや開発をとりまく状況が変わってきた中、今の私たちのフェーズで必要とされていることだと思っています。
チームの変化とぶつかった課題
一般的にスタートアップは個人の力をとても大事にします。
ごくごく少人数の優秀なメンバーが一つの機能を(ときには一つのサービスを！)猛烈な勢いで作り上げていくようなイメージです。そこではエンジニアのアサインや進捗の把握も個人単位になりますし、個人が受け持つ裁量の範囲も非常に大きくなります。
プロダクトや組織がまだ固まっていないスタートアップでは、これは多くの場合において最善手と言えるでしょう。(そもそも人がいないからこそ、これしか取りようがない、とも言えますが・・・)
ですが、組織が大きくなってくると、これでは回らない場面が出てきます。CAMPFIREのクラウドファンディング開発チームが去年から今年にかけて直面した課題が正にそれでした。
開発メンバーの人数が増えてきたのと、他方施策の数も増えてきたために個人中心で回ってきた開発プロセスがワークしないと感じられる場面が増えてきました。
大きく分類するとそれらは以下2つが根本にあったように思われます。
並列作業による複雑化
個人中心による属人化
並列作業による複雑化
たとえば機能開発のアサインを考えてみます。
メンバーが多くなり、さらに施策が増えて、並列で走るプロジェクトが多くなると、アサインがパズルのようになってきます。
10月からのXのプロジェクトに2人入ってほしいけどどうしよう。Aさんの仕掛りのYのタスクは急ぎじゃないから、ちょっと止めてもらって入ってもらおう、のように・・・。このようなやり方は2-3人であれば回りますが、人数が増えてくるととても辛くなります。全体の状況の見通しがしづらく、さらに進捗が遅れたりすると破綻していきます。
そして、実際のところは、サービスの開発は多かれ少なかれ、当初の計画通りにいくことはあまりありません。進捗の遅れに伴う関係者の認識あわせや、ロードマップの調整に入ることも多くなりました。
一方、アサインされる側のエンジニアも、並列でタスクを持つことが多くなります。しかしながら、並列で考えることが増えると、ひとつのことに集中できず、効率がよくありません。結果として、思ったように作業を進めづらいような環境が慢性化していきます。
個人中心による属人化
もうひとつ、個人中心のアサインは属人化を招いていきます。
単純に考えると、AさんがXの機能を作ったから、Xの部分の追加開発もAさんにやってもらおうとなりがちです。しかし、長期的に見ると、その箇所のドメイン知識や技術的知識がAさんに偏る傾向を招いていきます。これが極まってくると、Aさんにしか触れない部分が出来上がってしまいます。
また、短期的にみても課題があります。Aさんだけが作っている機能は、もしAさんが行き詰まって他のメンバーがヘルプに入る際も、キャッチアップコストが大きくなります。そもそも、他メンバーも自分がアサインされているプロジェクトもあるので、ヘルプの心理的ハードルが上がってしまう、という点もあります。
フロー効率で考える
このような状況をどう解決していくか？そこで取り入れているのがフロー効率の考え方です。
先ほどふれたアサインの仕方はリソース効率に基づくものといえるでしょう。
リソース効率では、リソースに対してなるべく空きがでないことを重視します。したがって、人的リソースの遊びを極力減らして稼働率100%に近づけよう、ということになります。
一方で、フロー効率はタスクのリードタイムを短くするという観点で考えます。
タスクXがあるとして、フロー効率の考え方では、それをみんなでいかに早く終わらし切るかを考えます。当然リソースの遊びなどは出てきますが、それよりもタスクXにかかるリードタイムを減らすことが重要です。
こうするとアサインや進捗把握の考え方がシンプルになります。なぜかというと、プロジェクトに対し、誰かを常にアサインしなくては・・・という点に重きを置かなくてよくなるからです。眼の前にある一番優先度の高いタスクをまずは終わらせていくことに主眼が移っていきます。
ソフトウェア開発の文脈において、このフロー効率の考え方はスクラムやリーン開発といった開発手法の根幹にある考え方です。
チームで考える
このようなリソース効率を踏まえた考え方になっていくと、自ずとチームでものごとに当たっていこうという考えが大事になっていきます
これこれこういうタスクがあって、タスクZがどうも上手くいっていないからまずはこちらを進めるために終わらし切ろうになっていきます。一人だとそれはできない。だから考える単位がチームになっていくのです。
私自身は、このフロー効率を大事にして、チームで考えるということがとても好きです。
把握をシンプルにするのみならず、価値を最速で届けることに繋がりますし、チームで考えることによって、今までは個人に閉じていきがちだった知識も、チームに伝播しやすくなっていきます。
そして、何より各メンバーがそれぞれに工夫していくのが大事になってくるからです。それはともすれば、(メンバーの資質ではなく、開発プロセスの構造的に)ただアサインされたタスクをこなすことになりがちであったメンバーが、より自律的に動いていくことを促していくことになります。
実際のところはどうなの？
CAMPFIREの開発チームすべてで、このフロー効率やチームに基づく考え方が徹底できているかというと、まだ道半ばといったところです。
フロー効率について、理屈では分かっていても、私も含めたマネージャー層がリソース効率的に思考している場面はまだまだ多いです。
また、並列で色々なプロジェクトが進行していく状況も続いています。アサインに対してチームで取り組むことについても、一部のチームに留まっているという状況です。
一方で大きな手応えもあります。
現在、CAMPFIREのプロダクト開発チームでは、一部チームでスクラムを取り入れており、そこではチームで考えること、フロー効率で考えることが当たり前となっていきつつあります。そのチームがつくった実績や、メンバーの後押しは、とても心強いものです。
まとめ
最後におさらいです。
キーワードとしては、フロー効率とチーム単位で考えるということです。
すきまなくタスクを埋めるのではなく、いかにタスクをみんなで早く終わらせるかを考えて、そのためにチームで取り組むことを大事にしています。
2024年はフロー効率とチーム単位で考えるということを、より多くのチームに広げていければと思っています。そのことはCAMPFIREのよりよいプロダクト開発づくりにつながっていくはずです。
この記事が気に入ったらサポートをしてみませんか？