【ポエム】「リソース効率 vs フロー効率」― プロダクト開発の現場で見えた課題と気づき
私は現職でいくつかのプロダクト開発の現場を見ていて、リソース効率、フロー効率について考える機会があった。
私見を書き殴っていこうと思う。
リソース効率、フロー効率
以下のブログがわかりやすいので紹介しておく。（決して説明するのが面倒なわけではない）
概ねこのブログに書かれている内容の通り、顧客への価値提供を意識するとフロー効率の方が結果として売上にも繋がるのではないかというのは筆者も賛成である。
とはいえ結局不確実性が高いからこそリソースをフルに使って弾を撃っていく考え方があるのも理解できるし、明確な顕在ニーズが存在していてそれを狙い撃つために考え抜くことが大切なのだ、と言われればそれも正解な気がする。
この話は最早エンジニアの枠組みを越えていて、プロダクト開発に関わる全員で認識が合わない限りどうにもならないだろう。
私が現職でメインで見ている組織はまさにリソース効率だった。
スクラム開発を謳って、スクラムイベントはやっているが、ビジネスが持ってきた粗めの企画要件をデザイナーが体験を考えた上でUIを作り、それをベースに開発含めて仕様を詰めていくスタイルだ。
効率が良いと考えていた時もあるが、以下の問題が発生した。
- ビジネス、デザイン、開発でそれぞれが向かっている時間軸が異なる（開発は目先の事、デザインはその1つ先の事、ビジネスは更に未来の事）
- ビジネス、デザインでドメイン知識が醸成されていき、開発のドメイン知識が醸成されにくい
- ビジネス、デザインで会話を進めるので、実現性の観点でちゃぶ台返しが起きやすい
当時、リソース効率、フロー効率という概念を知らなかった自分は、バックログリファインメントのタイミングで早めに開発が会話に入る等、少しずつでも上流工程に開発が関与できるように、とやってきたが、リソース効率で動いているため常に"デザイン済み開発待ち"のイシューが存在する状態になっている状況ではなかなか満足にフロー効率へシフトすることはできなかった。
以下は有名なリソース効率の動画だ。
概念を理解していなかった時に見ても全く響かなかったが、今ではとても良く分かる。
誤解しないでいただきたいのは、筆者はフロー効率こそが至高であり、リソース効率は全て取り締まろうなんて考えていない。結局手段の話なので、どちらが良い、悪いというより、どのシーンにそれを利用するか、という話でしかない。
ということで、私が置かれている状況ではフロー効率の方が問題が解消されそうだが、リソース効率からフロー効率へチェンジするのはかなり難しく、現在進行形でリソース効率型で進行している。
何故脱却しきれないのか
前述した通り、開発待ちのイシューが積まれている状態だったので、イシューがなくならない限りはどうにもできなかったし、それ以前に組織のカルチャーの問題が強く作用していたのではと思う。
私の所属する組織は元々職能型組織と言われる組織で、新規サービスを専門に開発するエンジニアリング組織だった。
ビジネス組織、デザイン組織がそれぞれ存在していて、ビジネス組織が起案した内容で事業化が決定したらデザイナー、エンジニアがそのプロジェクトにアサインされる形式である。
いくつかのプロジェクトはその中で幸運なことに0→1フェーズから1→10フェーズへ移行することとなり、職能組織も事業組織へと形が変わった。（正確には職能組織が兼務で存在するのでマトリクス組織）
しかし、やはり職能組織の文化は強く、我々のプロダクト開発組織の形ってなんだろう？というのがあまり議論されないまま、今までのやり方で進んでしまっているのが現状である。
これまた誤解しないでいただきたいのが「全員で顧客の課題に対し意見を出しあってプロダクトを作っていこうぜ！」のようなエモい感情論ではなく、リソース効率を重要視すると結果としてプロジェクト型に陥っていくのでは、と思ったのが最近の気づきである。
プロジェクト型、プロダクト型
自分の中ではプロジェクト型の対義語には、プロダクト型という言葉がしっくり来ている。
世間一般にこういう言葉があるのかググってみたが、そんな言葉はないようだ。しかし1件ブログがヒットした。
私が言いたいことが言語化されているように思う。
質を上げるのか、量を作るのか。これはいずれもプロダクトが置かれているフェーズによるだろう。前述した通り、結局はどのシーンでどの手法を使うか、という話でしかない。
なので、ここまで読んでくれた方にはきっとプロジェクト型はクソだ、リソース効率型はクソだ、と先入観を植え付けてしまっているかもしれないがそうではなく、今の私の置かれている状況においてはプロダクト型の進め方が合っているのでは？という話に過ぎない点に注意して欲しい。
プロジェクト型の課題
以上を踏まえ、私が思うプロジェクト型の課題は以下の点だ。
- プロジェクトを乗り越えて、成熟したチームがプロジェクトを終えると解散してしまい、ナレッジが蓄積されづらい、共有されづらい
- 兼任が発生しやすい、主体性が湧きづらい、責任の所在が分かりづらい
- 良くも悪くもゴールが全てでその過程で発見された課題を握りつぶしてしまいがち、その後放置されやすい
これらの要素を積み重ねていった結果がいわゆる技術負債に繋がるのである。
余程筋が悪くない限り、技術負債と今言われているものも始めは「ちょっとした特別対応」みたいなものだったんだと思う。早いうちに芽を摘んでおけばすぐ解決できたものが、長く放置されること解消できない問題まで膨らんだわけである。
どうしても技術という言葉にフォーカスされてしまいがちなので、コードの認知負荷やレガシーな技術の話ばかりにすり替えられてしまいがちだが、組織体制や文化が技術に与える影響は大きく、それらを解決していかないと根本的な解決に向かっていきづらいと言える。
こうして負債が積もりに積もっていった結果、ビジネスチャンスを逃し、会社が弱体化し、会社や組織の魅力が低下し、人が離れていき、と負のループに繋がっていくんだと思う。
ではこのような状態になってしまっている今私達にできることは何なんだろうか。
どのような手段で組織にマインドチェンジを促せるのか
結局自分達で気づくしかない。詰まる所文化作りなのかなと。
この手の話に銀の弾丸のようなものはなく、課題を分割してその文化を地道に作り出すしかない。
私が見ているプロダクトは既に0→1のフェーズは脱却しているプロダクトばかりであり、これから大きく羽ばたいていくものや、更に大きくなろうとしているプロダクトばかりだ。それ故にプロダクト開発の現場ではフロー効率を重視し、プロダクト組織でありたいと思う。
ただ、これはビジネス、デザイン、開発とプロダクト開発の登場人物達が理解しないことには始まらない。
リソース効率で進めてきた組織からすると「フロー効率なんてありえない！私達はやりたいことがたくさんあるんだ！」なんて反感を買いそうではあるが、粘り強く伝えていくしかないんだろう。
と答えのない問題に今日も頭を悩ませるのであった。
Discussion