開発組織と効率性のマトリックス

メダップでは、開発戦略や開発組織の生産性を考える上で、「フロー効率性」と「リソース効率性」の概念を扱っています。
また、経営陣や開発メンバー間で開発組織の状態の認識を合わせるために「効率性のマトリックス」というフレームワークを利用しています。

そもそも「フロー効率性」「リソース効率性」「効率性のマトリックス」がどういったもので、それらを利用して開発戦略の生産性を考えることにどういったメリットがあるのかをまとめてみました！

(※ 今回は考え方のシェアで、効率性をどう高めるか？については言及しません)

フロー効率性とリソース効率性

This is Lean という書籍でこうした概念が登場するのですが、
ソフトウェア開発の文脈で簡易的にまとめると以下のように考えることができます。
※ 実際に This is Lean で説明されている概念からだいぶ簡略化しているので、あしからず....(特にフロー効率性)

- フロー効率性が高い状態
  → TODOに入ってからデプロイされるまでの時間が短い
- リソース効率性が高い状態
  → エンジニアが誰もタスク待ち等がなく100%稼働できている

これらはいずれかを達成することが理想的というわけではなく、究極はどちらも高い状態を達成したいと誰しもが考えるのではないかと思います。
ただし、この2つの効率性はトレード・オフの関係になりやすく、フロー効率が上がると、リソース効率が下がるといったことがよく起きます。

そして、開発スタイルとしてよく取り上げられるスクラムやリーン開発は、この概念でいうとフロー効率性が高い状態を指していることが多いです。

効率性のマトリックス

こちらのフレームワークも This is Lean の中で取り上げられている内容なのですが、
「効率性のマトリックス」を利用することで、自分たちの組織がいまどういう状況なのか？を把握することができます。

具体的には、フロー効率の高低とリソース効率の高低を基準に四象限に分類したものが「効率性のマトリックス」です。

上図でいうと誰しもが星(右上)の位置を目指したくなるのですが、なかなか上手くいきません。(フロー効率性もリソース効率性も高い状態)
その原因の一つに「変動」(= 振れ幅) という概念があります。

 ソフトウェア開発における「変動」は、フロー効率, リソース効率でそれぞれ定義できると考えています。
フロー効率に関わってくる変動は、仕様・UI・設計の変更といった開発が差し戻しになってしまうような事象であったり、バグ対応のような機能開発を止める必要がある事象かなと考えています。
リソース効率に関わってくる変動は、メンバーごとのスキル差や守備範囲の違い, 稼働量の差などかなと考えています。

なぜ変動があると、効率性を高めることが難しいのか？

なぜ変動があることで上手く行かないのかを説明するために、よりイメージが湧きやすいリソース効率とその変動を例にしてみます。

リソース効率を100%にしようとすると、存在する開発タスクを常に開発者に振り分ける必要があります。
ここで、フロントエンドエンジニアが1名に対して、バックエンドエンジニアが3名いる開発チームで考えると、
常にフロントエンド:バックエンド = 1:3 の比率でタスクがあれば確かにリソース効率を100%にすることができるのかもしれませんが、現実的ではないでしょう。
また、バックエンド内でも駆け出しのエンジニアの方とベテランの方がいるとしたら、比率以外の制約も入ってきそうです。。
ここから、守備範囲の差分やスキル差があること(= 変動が存在している状態)で常にリソース効率が100%にすることが難しいというのがわかります。

変動がある状態を効率性のマトリックスに当てはめると、上図のグレー部分のように表すことができます。そしてこのグレー部分に組織がいくことはできません。

組織としては、変動をなるべく小さくすることで、少しでも星に近づく(リソース効率性もフロー効率性も高い状態)ことが理想的な動きなのではないかと考えています。

メダップ開発組織のおける効率性の変遷

開発チームで組織として動き始めたのは今年(2021年1月)になってからのことなので、変遷といってもまだまだ歴史は浅いのですが、これまでの開発組織の状態を可視化してみました。

当たり前ですが、まずチーム発足時は、左下の◯にいました。
その後、つい最近まではリードタイム/ポイント(1つのバックログアイテムをリリースするまでの速さのような概念)というメトリクスを定義し、このメトリクスを追い続けた結果、緑矢印のように組織が動いていったかなと思っています。
また、開発中に色々と発覚することも多く、またチームも即席で変動が非常に大きい状態だったと考えています。
そのため、緑矢印のように組織として動きながら、コミュニケーションの質やフローの整備で変動を下げにいくような動きも行っていました。

リソース効率という観点で見ると、まだまだ改善の余地があったと思います。(たとえば、API側の開発を進めているケースで、フロントが待ちになるとか。QAに入って、数名がちょっと暇といった状況が起きがちなど)
ただこれはそういう戦略を取っていたからで、リソース効率性が低い代わりに、まずはフロー効率性が高い組織を作ろうとした結果だといえます。

おかげで、1機能あたりの開発スピードが格段に上昇し、1つのバックログアイテム進めることは、チーム発足当時からすると随分洗練されたと思っています。(つい先日も、月曜日に出した新機能の拡張機能を木曜日にリリースするみたいなことができるようになりました！)

現在は、戦略を少し変えて、青矢印をたどっていけるように全員で認識を合わせながら開発体制の修正・開発フローの見直しをしています。
青矢印部分を言語化すると、これまでに作れたフロー効率性の高さは維持しつつ、徐々にリソース効率性も高めていこうとしている状況です。(並行して取り扱うバックログアイテムを増やすなど)
既にめちゃくちゃ難しいなこれ。。。ってなってますが...w

ここから半年を目安にこの青丸にいける状態を作り上げて、その先はいよいよ変動と戦いながら(実際今も戦ってますが...w)、星に近づいていく黄矢印をたどれるように動くことになると思います。

まとめ

いつもに比べると概念の説明に長く文章を書いてしまった感があります、、
ここまで読んでくださった方、本当にありがとうございます。。。

現在、メダップの開発組織では、こうした効率性のマトリックスを利用して、戦略的に組織としてどういった状態を目指すのか？を定義し、経営陣も含めて全員の認識を合わせ走れる体制を構築しています。

プロダクトを開発していくことで、市場やユーザーの課題を解決していくことはもちろんですが、
こうした開発組織戦略のような概念, 仕組みを考えることに興味がある方がいれば、ぜひ一度お話させてくださいー！(最寄りの馬場にDMください！)

そして、This is Lean はここで書いた内容を数億倍詳しくわかりやすく書いてあるので、興味がある方はそちらをぜひ読んでみてください〜！

■ 求人一覧
エンジニアリングマネージャー
プロダクトエンジニア
デザインエンジニア
フロントエンドエンジニア
業務委託メンバー(Rails/React)