有限なリソースと機会費用で優先順位を決める
うっちー
はい。じゃあ、naminami.fm、本日も始めていきたいと思います。よろしくお願いします。
swat
よろしくお願いします。
うっちー
はい。今日はトレードオフの話をちょっとしたいなと思っているので、最近育成チームでまとめた考え方を整理したんで、ちょっとその話をしたいです。
swat
はい。お願いします。
うっちー
はい。トレードオフは、この作業を何をやるかっていうことをイメージして考えをまとめたんで、今、何にリソースを使うべきかっていうのの考え方っていうところですね。
で、前提としてはリソース、人の使える時間、人のコースって有限なので、1日に10時間しかないし、そのうち8時間しか働く時間ないし、どれだけやりたいことは無限にあると思うんですけど、
うっちー
そのやれるリソースっていうのは有限なので、何をやるかっていうのを選択する必要があるっていうのがありますね。
例えば、5人人がいたとして、でもやりたいことだったり、やらなきゃいけないことが10人分の10人日、
なんていうの、やらなきゃいけないことが必要だとしたら、半分しかやれないってなると思うんですね。
そしたら、どれを10人日やらなきゃいけないものの中で、どれをやって、どれをやらないかっていうのを配分する、優先順を決めるっていう必要があると思います。
それを単純に上から言われたことだけやってくってなると、本当に必要なことがおろそかになったりとか、やらなきゃいけないことがやれてないっていうことになったりすることがあって、
何かをやったらやれなかったものが発生する。何かをこう選択したら、その選択しなかったものをやれる、なんていうんですか、世界線があったと思うんですけど。
その世界線を選択してないから、もしその選択をしなかったらやれてたであろうことがやれなくなってるんで、そういう何かを選択したら選択できなかったものがあるっていうのを機械費用って呼ばれてますと。
そういった機械費用っていう選択しなかったことによってやれなかったものがあるっていうことを考えておかないと、単純に今選択したものの中で、これはやらないかやったほうがいいかって考えると、多分何でもやらないよりはやったほうがいいと思うんですけど。
優先順位を決めるときにその1個のタスクだったり作業がやる必要があるのかっていうのを考えるだけじゃなくて、他のタスクと比較して相対的に今これをやるべきかっていうのを考える必要があるっていうのが基本的な考え方かなと思います。
時間見積もりと品質改善の打ち切り
あとは1個のタスクだけ見たとしても、どこまでやるかっていうのがあると思うんですよ。
うっちー
こだわりとかを持って、もっと良くしたいって欲が出てきたりとか、コーディングとかだと周りが気になってきて、機能開発していったら周りの違うところも気になってリファクタリングも一緒にやっていっちゃうっていうこともあったりすると思うんですけど、
そこってどこまでやるかっていう話があって、多分どこまででももっと良くしたいって記憶は出てくると思うんですね。そういったときに何を基準に考えるかっていうところの考え方としては、
基本的にはコースというか時間を区切るっていうのは必要かなと思ってて、もう作業始める前にこの作業が何時間までで終わらせるっていうのを先に決めますと。
で、その時間までであれば無限に無限にというか、どこまででも改善していって、早く終わったとしたらもっとやっていってもいいし、ただ時間きたら途中でもうやめるっていうところですね。
そうなると、どこまで改善をしていくのか、プラスアルファでどこまでこだわりを持っていくのかっていうところを区切るためのきっかけが時間として現れるので、
そういった時間を先に決めるっていうのが必要になってくる。それが多分見積もりの考え方だと思うので、見積もりを作業始まる前に決めてそこまでで終わらせるっていうこともそうですし、
それ以上は作業しないっていうのもそういう見積もりの役目かなと思いますね。
うっちー
で、多分プロダクトというかシステムの品質の考え方として、時間かければかけるほど比例して、時間と比例して品質が上がるものではないと思ってて、
最初は時間をかければかけるほど品質も上がっていくと思うんですけど、どこかで時間をかけた割には品質がなかなか上がらないっていうことがあったりすると思うので、
そこまで来てしまうと費用対効果というかコスパが悪くなってくる。時間かけてもあんまり変わらないってなってきたら多分その手前でやめといた方がいいねっていうところになってくるかなと思いますね。
基本はそういう価値、プロダクトの価値だったりとか、どれだけ改善したかっていうことが必要なんですけど、今やってるタスクだけ考えたら、今止めちゃうよりもうちょっと時間かけた方が100より101にはなる可能性があると思うんですけど、
その100から101に変えるのに2日間かかったとしたら、他のタスクに移ったとしてまだゼロのタスクを20まで進んだ方が合計は多くなるじゃないですか。
だから多分工数をかけない、かけた割にあんまり改善しないってなる前に他のタスクに移る、さっき言った他のタスクと優先して今やるべきなのかっていうのを考えるっていうのがそこにも関わってくるかなっていうのがありますね。
研修化の背景と自律的な課題選択
うっちー
はい、そんなところですかね。はい、何か言いたかったところはそんな感じですけど、かかたんさんとかもトレードフとかオニトフに考えてるとこありますか。
swat
トレードフは、そうですね、先に質問いいですか。
うっちー
はい、どうぞどうぞ。
これトレードフの考え方をまとめようってなった経緯とかってなんかあるんですか。
うっちー
そうですね、みんなが作業がパンパンで時間が足りませんっていう状態になってるのを知って、
そこのなんでそういう状態になってるのかっていうところを突き詰めていくと、何でもかんでもやっちゃってる状態になってる人が多いなっていうのがわかったっていうところですね。
で、それはジュニアメンバーだったりする、ジュニアというか新卒だったり入って間もない人だったりすると、なんか上司がいてその人がコントロールしてくれてると思うんですよ。
次これをやってねとか、何か次手が挙げたんで次これをやってくださいみたいな形で、多分やんなきゃいけないことは無限にあるけど、それが見えてない、ジュニアメンバーには見えてない状態になる。
それをコントロールしてるのが上長だと思うんで、上長だったり先輩だったりOJTだったりとかするんですけど、それがだんだん成長していって、自分がリーダーになったりとか、あとはそのパートというか同じチームの中で一番自分しかいないチームもあったりとか、
自分が主者選択をしなきゃいけない状態になってくる、リーダーが上がいないんだったら自分がやるしかないので。で、そうなった時に基本なんかプロダクト開発だったり何でも仕事って多分無限にやれることってあるんですよ。
で、さっき言ったリソースは有限なんで、どっかで諦めないとというか、全部やろうとしてリソース内でできる範囲の簡単な仕事だけじゃないので、無限にある有限のリソースで対応しようとしたら絶対溢れるんですよね、やんなきゃいけないことが。
だからそれを頑張ってがむしゃらにやろうとすると絶対リソース足りませんってなる。でも優先順位をつけたりして、リーダーが今までやってたような役割を自分がやることをするっていうのが必要がある。
それをやらないと本当にリソースが足りないのか、今やるべきではないことに時間かけすぎて本当に必要なことがやれてなくて時間足りないってなってるのかっていうのがわかってくるので、まずは優先順位をつける、今の考え方を守ってもらいたいなっていうのでまとめたっていうのがあります。
swat
ウェーブならではなのか、ちょっと自分が他社さんを知らないのでですけど、ウェーブは結構アジャイルとかスクラムとか自立みたいなワードが結構あって、自分でタスクを取ってくるとか、あと一つのプロダクトだけじゃなくて組織横断で改善チームみたいなのを運用していたりして、
自分が所属するところがチーム以外のところもあったりして、ジュニアの人とかのタスクを城長が全部さばいて割り振ってってやったら多分自分で考えなくてもいいみたいなレースはあるかもしれないんですけど、
自分のところに集まってきたタスクをどの順番でどうさばいていくか、で自分がこれやりますみたいなところにどうタスクを取っていくかみたいなところが求められることが多いというか、そういう場面が多いので、
そうなってくるといろいろ選択肢はあるしタスクはあるんだけど、じゃあどれを今やるんですかっていうところはしっかり持ってないと結構パンパンになっちゃって、大変になっちゃうっていうのはよく見るというか、そういうのはあるなっていうのは確かに思います。
うっちー
コントロールしてないと、なんかその組織改善のところをやってたら本業の部分がおろそかになって、逆に本業ばっかりやってると、なんか手が空いてきてエフェクタリングばっかりやっちゃうみたいなこともあったりして、何を一番やるのが、何の価値を発揮できるかっていうのは考えられるといっしょに。
課題発見から根本解決と新機能へ
うっちー
3級とか4級になってきて求めたいところとしては課題発見の部分なんですよ。1級2級の段階では課題解決っていうところをまずはやる。
例えばそれこそ新規サービスをリリースするためにフルスタックにインフラも含めて開発するっていうところですけど、それはもうやること決まってて、それをどんどん細かいどういうふうにやるのかっていうハウの部分は自分たちで考えるっていうところですけど、
もう何やるかっていうのはだいたい決まってることで、課題発見3級4級に求めてるっていう課題発見っていうのは何をやるかっていう部分を決めるっていう部分なんですね。
それはもうすでにあるんであれば、もうやらなきゃいけないことがあるんだったらそれでいいのかもしれないけど、そのやらなきゃいけないことが不具合修正だったり、技術不再解消だったり、何かが壊れたからそれの対処をするっていう状態だと多分その対処しなきゃいけないのは未来英語に続いちゃって、
機能開発というか新機能の開発に時間使えなくなっちゃうんですね。だからそこをいつまでもその運用保守だけに留まるようなことはしたくないので、
だからその根本解決みたいな不具合だったら不具合が起きにくくなる仕組みを作っていくっていうところで対処をそもそもしなくてもいい状態を作るとか、技術不再解消も何か問題になってから動くというか対処するっていうよりもアーキテクチャを改善していって、
その壊れにくいものにしていくとか、作り直すってものもそうですしっていうのを考えていく必要があるなっていう思ってますね。で、それを何をやるのか、今のその事業ごとのフェーズによって、今はスタートアップだから技術不再解消は後回しにして新機能をだんだん入れてくるとか、
今、例えば決済機能とか最低限の機能を入れたんであればデータ分析とかを駆使して、どういう機能がユーザーが喜ぶのかっていうところを分析するとかいったところで、どんな機能を入れるのかっていうのを見つけていくってところもその課題発見のところかなと思うので、
今どこにフォーカスするのかっていうところも含めて、そもそも今見えてない選択肢を見つけるっていうところもその課題発見という意味で求めている部分ではあります。
AI時代の価値・速度・フロー効率
swat
今そのAIがあって、前まで大変だった実装のコストみたいのが結構なくなってきた、かなり少なくなってきたので、話の中でもあった費用対効果というか、
コース対効果というか、かけたコースに対してどれくらい効果があるかみたいなところで、そこも多分コースは下がってきたので、複雑な機能とかでも入れられるようになったんですけど、
コースがかかった、難しいからじゃあ価値があるのかっていうと、まあそうでもないので、そこのちゃんとどこに価値があるのか、ユーザーに喜んでもらえるのか、負債が解消できるのか、運用が楽になるのかっていうところがしっかり見極めるというか、そこの目を養っていくっていうのはより重要になってきたのかなっていうのが思います。
うっちー
確かに、その価値、その改善の価値だけ考えて並び替えちゃうと、すべて1年かかるものだけが優先順位高いみたいな感じになっちゃいますもんね。1個やったら1年、次やれるのを1年後みたいな形になっちゃうと、スピード感ないので。
見積もりっていうのはそういう意味でも大切で、この価値のものにどれぐらいのコストというかコースでできるのかっていうところを見積もれると、本当に価値高いけどめちゃくちゃ時間かかるんだったら、それをやる前に価値が中くらいですぐに終わるようなものっていうのをいくつかこなしてから大きいのやりたいっていうこともあったりすると思うので、
今AIでコースが3つ、コースが3つ短くなるっていう話がありましたけど、コースっていうのもどれぐらいかかるのかっていうのも優先順位の決めるのを選択肢として、選択肢というか指標として持っておく必要ありそうですね。
swat
確かに私今ちょっと気づいた人の観点というか、効果が出るまでの時間ですよね。1年後に効果が出るのと、1週間後に効果が出るのだと、早めに効果がちょっと小さいけど早めに効果が出る方がいいっていうのは確かにそういうのもありますね。
うっちー
それがアジャイルですもんね。
swat
フロー効率、逆か。リソース効率よりフロー効率がいいのは早く効果が出せた方が福利というか効果の期間が長いので。
うっちー
リソース効率を多分なんかSESとかはリソース効率で、SESとかSIRとか受託開発とかをしてるとリソース効率で考えるんですよ。
それは人月単位でお金をもらったり払ったりしてるんで、その同じ日にちが経っちゃうと、その分空いてる人がいるとアウトプットが出てこない。
うっちー
アウトプットで測るんだったら別にそういうリソースが100%使われてるっていう心配をしなくてもアウトプットが出なければお金ももらえないのでいいんですけど。
人月で働くとそれを100%とか落として、誰も手が開かない状態を目指そうとしちゃう。
そういうところから来るとWAVEはそんなに人月で働いてるわけではないので、それよりも価値をどれだけ早く提供するかっていう方向が必要な考え方なので、
そうなると100%を稼働させるよりも、1個1個のタスクがどれだけ前倒しで終わらせられるかっていうことが必要だったりして、
例えばデザイナーとか各チームに1人ずついなかったりすると、デザイナーが他の作業で手が開かないってなると、
エンジニアが作ったやつ後にデザインをしようとしても、デザイナーのリソース取れませんってなったら、
デザイナーの他の作業が終わるまで待ってないとリリースできませんってなっちゃうので、そこをうまく組み替えて、
必要なものにリソースをね、もうすぐでリリースできそうなものがあればそっちにも先にやるとかも検討するっていうのも優先順位の考え方の1個かもしれないですね。
作らない選択と組織の共通認識
swat
とりあえずこのトレードオフは毎回難しいなと思いながら考えてます。
内田さんがトレードオフで考えるとき、いろんな要素はあると思うんですけど、一番大事にしてるところってあります?
うっちー
一番はそもそもそれをやる必要があるのかっていう部分ですかね。
そこが切れるかどうか。
うっちー
昔からそれをメンバーには言ってたりして、それを逆に何ていうの、やりたくない方向になっちゃうじゃないですか。相手からすると。
そもそもやるべきあるのかっていうコミュニケーションを取ると、提案してきた人に対して、基礎からすると拒否されたみたいな形になっちゃうので、そこのコミュニケーションはすごい大事だというか、うまくやらないとなっていうのは思うんですけど、
そもそもそれをやらなくて問題解決するんだったら、コースゼロで価値を提供できるんで、それの方がいいと思うんですよ。ゼロってことはないかもしれないですけど、
うっちー
提案として、今既にある機能で大体可能であればそれがいいとか、他のやり方を使えば新しく作る必要ないとかっていうものがあったらそっちをやる。
でもそれだと将来的に遅くなっちゃうとかがあれば、今作っとくべきかっていうのもありますけど、そこで無駄に言われたから何でもやります、それをどれだけ早く終わらせるかっていうことを考える前に、
そもそも言われたことに対して、それをやらないでも解決できる方法がないかっていうのを探すっていうのがまず一番、そこを一番大事にしてるかなと思います。
swat
削れるところ、やらなくていいところ、整理するというか、捨てていくところなんですね。
自分はどうして、ちょっと聞きながら自分はどうしてるのかなと思っていましたけど、
でもそうですね、タスクみたいこと、それは本当に意味があるのかは確かに考えちゃいます。
これやる意味ありますって聞いちゃうとちょっと窓が刺すのせい。それはみんなどうしてるのかな。
日頃からそういう考え方はやっぱり常に話しておいて、昨日誰が挙げたかとかは置いといて、
その挙げたアイディアっていうのが本当にやる意味があるのかないのかっていうところ、なければ置いとくっていうところ。
このトレード風についての考え方っていうのをまとめたというところに関して、
みんなが共通認識を持ってるっていうこともすごく大事なんだろうなと改めて思ったんで、
ここら辺の考え方がメンバーみんなが持っていたら、確かにやりやすくなりそうだなって思いました。
うっちー
エンジニアだけじゃなくてデザイナーもですし、エンジニアデザイナーだけじゃなくて企画も含めて、
GDGで言ったら営業も含めてこういう考え方を持ってないと、
うっちー
あれですよね、なんでそんなこと言うんだっていうコミュニケーションミスにつながっちゃいますね。
swat
これをこの考え方は今後研修とかの中で。
そうです。
swat
じゃあ時間が来たので今日はこんなとこですかね。
うっちー
はい。
じゃあ以上ですかね。
はい。
swat
ありがとうございます。