00:00
皆さんこんにちは、Rayです。Ray Wow FMの時間がやってまいりました。
皆さん、セールスフォースオートメーションとか、マーケティングオートメーションという言葉を聞いたことありますでしょうか?
SFAMAですね。いわゆるマーケティングであったりとか、営業を自動化していく、
そういったツール、セールステックとか、そういうツールを提供している企業がどんどん増えていく中で、
いろんな業務が自動化されていっているというところなんですけれども、
ある意味、ゆめみのマネジメントのやり方というのは、マネジメントオートメーションだなというふうに思っていて、
マネジメントというのをどんどん自動化していく、本当に最後に残ったマネジメントというのは、
そのマネジメントを自動化していくためのマネジメントになるんですけれども、
まさにそういうことをやっているなというふうに、
思いました。よくあるのが、例えばその稼働調整ですよね。リソースを管理する管理職がいて、マネージャーがいて、
その人が稼働調整をするみたいなことってよくやっていると思うんですね。
ゆめみの場合は、そのマネジメントがオートメーション、自動化されているので、
それをですね、マネージャーの人がやるわけではないんですね。
具体的には、その一人一人がですね、自分がどういうふうな、こう、
稼働ですね、割くことが最適かっていうのを自身で考えて動いていくということをやっているんですけども、
ここはなかなか大変で、そこにたどり着くまでに結構苦労はしたんですけれども、
一番大変だったのは、それまでもなんとなく、
あるいは明示的にプロジェクトマネージャーの人ですね、まあプロダクトマネージャーでもいいんですけれども、
そういうマネージャーの人っていうのはですね、まだまだあります。
そういうマネージャーの人っていうのはですね、まだまだあります。
完全に自動化されていなくてですね
社内のプロフィットマネジメント
プロセスマネジメント
ピープルマネジメントなどは
かなり自動化されてきているんですけれども
プロジェクトマネジメントというのは
特に法人のお客様とのプロジェクトの管理をするので
やっぱり人が実際に切り盛りするというのはあるんですね
そのPMの人がやはりお客さんからのご要望に応じて
どうしても対応していく中では
自分でコントロールできるリソースが必要になってくる
その中でいわゆる社員の人の稼働管理というところをやることになり
それが必然的になんとなくリソース管理はPMだ
来月何をするかもPMの人が決めるもの
みたいな感じで
やっぱりどうしてもなってきてたんですよね
03:00
そうなってくるとやっぱり結局マネジメントというのが
どうしても発生する
特にリソースのマネジメントにおいて
PMが行うみたいなことになってたんですけれども
それだと結局自分としては
PMとしてはお客さんの要望になるべく応えるために
リソースを囲おうとするんですよね
何かあったときに
はいできますよって言えるようにするには
当然囲おうとするんですよね
囲おうとし合うPM同士がある意味コンフリクトというか
競合し合うことになってしまって
連携性というのが失われる
PMの連携性が失われるというのがよくある構造なんですよね
一方で実際に稼働管理されてしまう社員の人
例えばエンジニアの人が
デザイナーの人
プランナーの人などの観点から見ると
自分としては別のプロジェクトの仕事をやりたいのに
囲われちゃってるみたいな
自分は来たタスクをこなすしかないなみたいな感じで
学習性無気力
症候群じゃないですけど
そういう感じになるんですね
無気力になっていくと
もういいやっていう風に
そうなってきて
そうなってきて
そうなってきて
そうなってきて
来るか
いやいやもうちょっと
いよいよ我慢できひんと
俺はもう違う技術
新しい技術学びたいとか
別のお客さんの仕事をしたいみたいな感じで
飛び出すか
そういう飛び出すこともちょっと言えないから
やめちゃうみたいなね会社
なりかねないんですけども
そういう状況っていうところをですね
どういう風に変えていくかっていう中で
結構難しかったなぁと
思うのが
そのリソースのアサインメント権限を
プロジェクトマネージャーは持たないという形で
明示的にしたんですね
でじゃあ誰が持つのって話なんですけど
自分のが何をするか
自分がどういう仕事をするかは
自分で決めますっていう
これある意味当たり前とか
ある意味当たり前だなぁと
思ったんですけども
当たり前じゃない
慣習っていうのがほぼ全ての会社で
実際に行われてるんですね
リソースマネジメントは
ラインマネージャーが行うと
いうのがほぼほぼ全てなんですよね
実質的には
自分でやるっていう形にはなってないんですよね
結局変えたんですね
変えたんですけれども
普通の会社からすると
どうすんのって言うんですよ
06:00
それぞれの人が私これやる
これやらないとか言い出したら
もう会社成り立たないよって思うじゃないですか
お客さんからどうしても
来月までにって言われてる納金に対して
PMの人マネージャーの人お願いしても
いや私やりませんって言われたったら
もう会社成り立たないよ
ビジネス成り立たないわっていう風にですね
これ多くの人は多分持ってしまうと思うんですけども
実際耳の社内でもそういう議論もありましたし
途中警戒においてはそこが困ると
ある意味PMの人メーカーの人も困ると
そういうやりづらさっていうのはありましたし
今でもやっぱり一部はまだありますね
改善の余地はあります
ただそうすることによって
社員の人のキャリアとか
自分がやりたいことをやれるっていうのもありますし
あとはするんですけども自分がやりたいことをやれるっていうのもありますし
自分が自分の稼働を管理するので
じゃあもうその自分としてはですね
来月自分の稼働がちょっともう飽きそうなので
次はどういうプロダクトに関わろうか
プロジェクトに関わろうかとかっていうのをですね
考えたり
ちょっともうずっと同じことばっかりやっているので
自分で積極的に周りに働きかけて新しいことをやる
新しいプロダクトプロジェクトチームに関わっていこうっていうのを
自分で考えていくっていう
そういうですね回転逆回転にですね
モーターが回り始めるというか
歯車が回り始めたんですよね
実際にそういう仕組み仕掛けを作って
社内のツールも稼働管理ツールを作って
実際にそういう稼働管理方針もですね
定めて実施し始めたっていうのが
2019年4月ぐらいからなんですね
でそれをですねさらにシステマチックに
したのが2000年の4月ぐらいなので
ある意味まだ最近っちゃ最近なんですけども
さらにこの1年ぐらいで2021年度になって
より最適化されてきているような状況になってきているんですけれども
これはなかなか大変なことでですね
今までだとひとまとまりのチーム
10名20名とかユニットみたいなところを
管理する人がいてその人がリソースを抑えるっていうやり方
でそのリソースを管理している人同士が横のつながりの中で融通させる
ちょっとミドスが足りないよとか
余ったよみたいな感じで
まあちょっとリソースって言っちゃうとね
これ社内でもですね
人のことをリソースと呼ぶなって話があってですね
じゃあ何と呼ぼうか
フォースと呼ぼうかとか
オソースと呼ぼうか
なんかそんな話もあったりしたんですけども
これはどうしてもあれですよね
産業革命の時代の名残で
機械的な観点でリソース資源っていうことをですね
09:02
管理するっていうのが発達していく中で
リソースっていう言葉がですね
PMの標準におけるピンボックとかでも
明記されているので
これもちょっとなかなか言葉として使いづらい
一般的な言葉としていつも使ってるんですけども
リソースですよね
そのリソースの融通し合うっていうことを
ユニットを管理するマネージャーの人たちが
やり取りしながらやっていくって意味ではですね
ある意味こう
リソース管理っていうのを行う人は
限られてたわけなんですけども
社員全員が自分で自分の管理してやっていくと
その管理する人が何だろう
例えばイメージの場合は200人いたとすると
200人の人がリソースマネージャーになるわけなんですね
ある意味
そしたらやり取りするコミュニケーションコストが
めちゃくちゃ多く大変になるんですよ
そこをまずやっていくのがすごく大変でしたね
それぞれのリソースを
自分のリソースを
管理するんですよっていうのを
お勧めていくのが大変でした
ただ実際のところ
全員が全員
200人がコミュニケーション取ると
コミュニケーションコストが多すぎるので
なので
そのひとまとまり
チームひとまとまり
チームは5名から大体7名ぐらいなので
そのチームひとまとまりの代表者っていうのを
REPと呼んで
代表者が
そのチームにおけるリソースの状況を
まず把握して
その上でその代表者が
その集まる
REP会っていうのがあるんですけど
その定例の会議で
今こういう状況ですよっていうのを
情報同期したりとか
今ちょっと
誰々さん結構大変そうなんで
もしかしたらちょっと
支援お願いするかもです
みたいな程度感をですね
含めて情報同期する
みたいなことをやっているんですけれども
そういうですね
仕組みを作ることによって
コミュニケーションコストを
そこまで多くならないようにする
っていう仕掛けを
やったり
結局のところやはり
そういう何かしらの
情報同期するための仕組みと
それを行うためのREPと呼ばれるような
そういう人っていうのは
やっぱり必要になったわけなんですよね
個人的には最初は
ややもう完全に
そういうですね
人が介在することなく
なんかシステマチックに
本当にオートメーションっていう形で
実現できるんじゃないかな
と思ったんですけども
なかなか難しかったですし
うーん
もしかしたらいずれ
なんかこう
仕組みでプログラム化できるかもしれないですけど
今のところは
まだそこができていないで
まだそのREPと呼ばれる代表者の人が
集まって調整する
っていうのはやっぱり
どうしても必要になっているんですよね
ただそのREPという人がですね
ローテーションで変わっていくんですね
目安として3ヶ月ごとに変わっていくっていう
代表者
あくまで代表者窓口でしかないので
そういった意味ではですね
あの
12:00
特定の人にそのリソースのなんかこう
アサイン権限が
こう偏るみたいなことは
今もない状況になっていて
REPって窓口でしかないので
うちのチーム5人いるけど
ほぼほぼちょっと今
忙しいんですよっていう
窓口役として
他のチームから今どうなってますか
って聞かれたら答えるという窓口であり
まあ他のチームからちょっと手伝ってくれません?
って聞かれたらちょっと分かりました
調整するっていう
そういう窓口の役割でしかないので
あくまでそのあなたね
山田さんこれやってくださいって
それはお願いでしかなくて
命令ではないんですよね
っていうような感じです
でポイントはこの命令ではなく
お願いなんですけども
お願いしかできないってどうするの?
っていう話だと思うんですよね
心配になりますね
普通のマネージャー
今までマネージャーやってた人はね
今までマネージャーやってた人とか営業だと
で実際のところ
人間ってお願いされると
断れない社会的動物なので
理由もですね
ちゃんとあるし
お客様からのご要望とかっていうところを踏まえて
何とかよくしていこうっていう思いで
依頼された場合
分かりましたっていうふうに
なんとかしようっていうふうに
思うのが人間なんですよね
ただそれがずっとこう続く
中でちょっと自分のキャリアっていうのも
犠牲にしてるなっていうふうになれば
そのバランスとして調整していくってだけであって
来月空いてますと
空きますと
ずっと関わってたプロダクトが一応収束するので
来月からはその見通しが立ってないっていう状況の中で
そんな別にやりたくないような仕事っていうのが
あるわけではないので基本的にね
なるほどそういう仕事なんですねっていう仕事が依頼される
こういう仕事どうですかってお願いされた時に
普通に分かりましたってなるんですよね
短期的な観点では少なくとも
ちょっと無理してでも周りの人が困ってたら
助けましょうというガイドラインもあって
だからこそ自分も何かあった時に
助けを求めることができるわけなので
お互い様っていう形でやってるんですよね
長期的な観点ではやっぱり自分のキャリアも大切にしましょう
っていうことなのでローテーションしたりとか
そういうものも推進してるんですね
っていう形で最適な形っていうところを
みんながイメージできるようになると
確かに自分が自分のリソースを決めることができるといったとしても
短期的な自分のおがままだけで振る舞うっていう人はいないですし
いなくなるんですね
例えばそういう人がいたとしても
15:02
周りとうまくいかなくなって
自然に離脱していくってなるんですね
ということで結局リソースの管理っていうのは
自分でやっていくセルフマネジメントっていう風になって
マネジメントの自動化っていう意味で言うと
セルフマネジメント結局してるので
自動ではないんですけれども
いわゆるリソースマネジメントの役割を担うような
マネージャーみたいな人っていうのはいなくなって
そういう人が権限を持つような仕掛け仕組み構造っていうのもなくなって
自分たちで考えるようになって
そうすると決め細かな行動ができるようになるんですね
あるいはキャリアの一番まで難しかったのが
お客さんの要望もありますと
一方で本人のキャリアとかやりたいこととか
そういうところも鑑みてアサイメントしようと
するとこれはこれでPMの人も苦しかったところなんですよね
いや本人やりたいのかなとか
そういうところまで考えてやるとすると難しいですし
いざ本人はやりますって言ったけど
実は心の奥底ではやりたくない
本当はやりたくないのになって思ってるかもしれないけれども
そういうところを気にしながらやっていく
でもそれがマネジメントでしょと
そのピープルマネジメントでしょっていう前提なんですよ
何年か前までもイメミディアは
いやそれはプロジェクト管理っていうのは
ピープルマネジメントもできないとダメだよと
当然その人の普段の状況とか
体調とか心情とかキャリアとか
いろんなことを含めて能力面もちろん
含めて全部考えてアサイメントするんだよと
お客さんからのご要望もそうだし
スケジュール管理もそうだし
それらを全て統合して
自動的に管理するのがマネジメントでしょっていう話だったんですけども
それをやめましたね
そんな全部のマネジメントできる人っているみたいな
いたとしてもしんどいよ
実際に耳の場合はそれでしんどいっていう人が出てきたので
確かにね無理だよねっていうので
どんどんどんどんマネジメントを分業させていって
自動化させていって
っていうような方向になっていて
そういうリソースマネジメントも
セルフマネジメント化して
今までのプロジェクトマネージャーの人から
範囲外マネジメントの範囲外にしていったんですね
こういう形でリソースの管理っていうのを
変えていったんですけども
その時に一人一人がですね
バラバラな判断をしていくと
秩序ある組織の動き方ができなくなるんですよ
ということもあってですね
結構ガイドラインを細かく定めましたね
18:03
ガイドライン
こういう時はこういう行動をしてください
例えば稼働が入った時は
まず他のチームを
自分たちのチームの他のメンバーの人が
忙しければそれを助けてください
自分たちのチームは
おおむねそこまで支援する必要がなければ
他のチームを支援してくださいとか
他のチームを支援することもなければ
委員会活動と呼ばれるような
中期的な組織の成長成熟に向けた活動をやってください
みたいなその1・2・3という優先順位を決めて
その通りに動いてください
というシンプルな原則を決めることで
人が動きやすくしたりとか
そういうのがないと
いざちょっと時間が来た時に
何しようかな
ちょっと勉強しようかな
何しようかな
ちょっと作りたかったものを作ろうとか
ってなっちゃうので
組織が最適な動きをするには
今までだと
どういう
判断をマネジメントの人がしていたか
っていうのを考えて
そのマネジメントの人が
ある意味支持していた
今までだと支持していた
アサイメントの最適な行動原則っていうのを
言語化して明示的なガイドラインに落とし込んで
その通りに動いてくださいっていうのを
トレーニングというか
周知していきながら
一人一人がセルフマネジメントできるようにしていく
一人一人のセルフマネジメントの結果が
組織的には最適な
動き方になるっていう風に
実際に設計して
そういう運用も浸透させてきたんですけれども
そうすることによって
ある意味
なんか知らんけど
一人一人は勝手に秩序を持って
行動しているように
見えると
そういう振る舞いをしているように
外からは見えるという風になるんですけれども
実際のところは
結構きめ細かな
設計やガイドラインや
レレップと呼ばれるような人も
介在しながら
調整を図っているような形になっています
こういう形で
マネジメントコストっていうのは
最終的には
これ減る
減るは減るんですよ
マネジメントコストは減る
減るんですけれども
それ以上に
実際はセルフマネジメントしてるので
一定のマネジメントコストが
かかってるんですけども
それ以上に
最適になってるな
という感覚はありますね
その本人のキャリアとか
いろんなものも含めて
その考慮しているようなものを
仕切れないので
実際のところは
結構どこかで歪みが起きるんですけども
そういう歪みがなく
調整が行われる
誰かが
ちょっともう
そろそろローテーションしたいです
っていうと
引き継がないといけない
引き継ぐっていう
課題が発生して
その課題をどう解決するかっていうので
レップ同士が話し合い
レップ側チームに
こんなローテーション
誰やらさんやら
鈴木さんローテーションするから
代わりにやってくれる人いない
みたいな感じで
レップがチームに持ち寄って
21:01
チームの中で話し合いが行われて
自分ちょっと来月から手すきになるし
手伝うわとかっていう形で
自然に調整が図られる
自然にって言ってるんですけども
なかなかここまで持っていくのは大変で
普通はマネージャーの人が
調整しながらやっていくんですけども
そういうのは必要なくなりましたね
そうすることによって
それってマネージャーのやることでしょう
みたいなことがなくなって
自責的になる
自分たちがやるべきことだよね
っていうふうになることによって
より協力しようとする
そういう意識も働きますし
ある意味本当に
最適な形になってきているなとは思いますね
ただその上で
やっぱり課題なのが
お客様からの要望で
ちょっと来月からどうしても
この機能を開発するために
人員増強したいっていう要望に対してですね
どう機動的に答えるか
顧客もやっぱりビジネススピード
ある意味リードタイム短くして
いち早く市場にプロダクトを出していくっていうのが
ビジネスの生き残りかけて重要な部分だったりするので
そこに答えていきたいなとやっぱりあるんですけれども
そこを機動的にやっていくのが
どういうふうにすればいいかっていうのが
まだまだ悩みどころで
もちろん機動的に採用できればいいんですけども
なかなか採用もそんな機動的にできないので
社内にある意味バッファーを用意しておかないときに
あまりというか
稼働がですね
稼働率をいかにコントロールしていくかっていうのが大切になってきて
稼働に余剰があるといけないし
きつきつで全然余裕がなくてもいけない
じゃあその最適化は何なのかっていうところを踏まえた上で
さらにいつでもですね
じゃあお客さんのご要望に応えて
ちょっと緊急的に対応するけれども
それが一旦終わると
社内の委員会活動のような
間接業務ですね
直接業務ではなくて間接業務
ただ重要な仕事
緊急ではないけど重要な仕事であって
長期的な組織の成熟をしていくような活動っていうところを
また緊急でなくなったらやるみたいな形で
その組織の投資ですね
例えば技術開発とか効率化とか問題分析だったり
さらに
対応とか教育とかそういう活動を10個役割を明確に定めて
委員会活動っていうふうに定義してるんですけども
そういう活動をですね
より行っていくということをですね
なるべくそのバッファーの部分としてやってもらっていて
その部分が例えば全体の稼働の5%ぐらい
委員会活動をやっていると
この5%っていうのはですね
ある意味瞬間風俗的にはですね
ちょっと一旦止めて
委員会活動の稼働を止めて
お客さんの緊急のご要望に応えするっていうのも
24:01
に使えるんですね
このバッファーっていうので
で緊急のご要望がなくなれば
また委員会活動の5%をまた戻すっていう形でですね
例えば稼働率を95%
直接のプロジェクトの稼働を95%にしておいて
委員会活動を5%みたいな形にしておくと
この5%がバッファーとして
お客さんのご要望に応えることができるっていうようになるんですね
これを10%にすると
10%にする
直接の稼働を90%にして
10%を委員会活動にすると
さらにこのバッファーが多くなるので
90%から100%に上げるっていうのは
ある意味10%分
なんていうんだろう
組織が大きくなるというか
上限をですね
増やすことっていうのに意味するので
そういう意味ではですね
10%ぐらいの変動ですよね
実際には11%ですけども
11%の変動幅があると
すごくフレクシビリティ柔軟性が上がるので
そういうことにもつながるんですね
委員会活動10%用意しておくというのは
ただ10%も用意するほど投資していいのっていうのが
また次出てくると思うんですね
ただ一般的にはですね
この委員会活動って
ある意味マネージャー業務なんですよね
本来はプロセスマネジメントと呼ばれる領域で
管理職と呼ばれる人が
社内の問題を分析して業務を効率化して
新しい技術開発を行って
採用教育配置を行っていくみたいなところって
いわゆるプロセスの
配置は関係ないですけども
プロセスマネジメントと
一部ピープルマネジメントも含んでるんですけども
そういう業務なんですね
それをイメミの場合は
マネジャーがいない
オートメーションしてるので
そこさえもそれぞれのグループの人たちが行っていると
エンジニアのグループであれば
エンジニアの人たちが
自分たちの組織の
プロセスマネジメントを行う
っていう形で
委員会活動を行っているんですね
通常はやっぱりプロジェクト
プロダクトも半巻とか
少し山谷があるんですね
稼働の
だから今までだと
空いたときどうしようってなってたんですけども
空いたとき委員会活動をする
つまりマネジャーが行ってた活動を
空いた人がやるっていう形で
そもそもこのマネジメントオートメーションによって
効率化がかなりされてるっていう部分もあるので
さらにこの
なのでその委員会活動っていうところを
やる意味もあるんですね
本来は空いた部分の業務を
やることにもなるし
それはプロセスマネジャーみたいな人
必要としないことにもなって
コスト削減にもなるし
エンジニアの人の空きコースの削減にも
空きコースを効率的に埋めることにもなるんですね
っていう形でですね
定常的にこの委員会活動っていうのをですね
組み込んでいるんですけれども
実際のところまだ全体で言うと
5%もまだいってないぐらいで
27:00
これを10%ぐらいにやっても
投資対効果があるような
そういう委員会活動ができると
よりですね
このバッファーを多く作ることができるので
それができないかなっていうのはですね
ちょっと最近の私の課題というか
悩みというかですね
イシューというか解決すべきテーマになってます
悩みというよりはですね
一つの方法としては
教育なんですね
教育をめちゃくちゃ力を入れる
委員会活動の中に教育が育成っていうのがあるので
そこをすごい力を入れると
それが何だろう
リターンになるっていう風になるケースがあるなと思っていて
どういうケースかというと
最近あったんですけれども
iOSエンジニアですね
iOSのグループの人が
新卒向けの研修課題っていうのをですね
作って
それを
オープンで
オープンソースっていう形で
社外の人にも使えるようにしたんですね
そうすることによって
結構バズってですね
聞いたっていうブログ
技術ブログでバズって
耳の認知ですが広がったと
これはですね
技術広報っていう観点で
採用とかにもつながりますし
そういうですね
リターンがあったんですよね
つまり
委員会活動を強化していって
いい育成プログラム教材
そういうものを作り上げること
そういうものを作り上げたら
上で外部にも公開することによって
耳の認知が上がっていくというような形で
リターンがあるとですね
この委員会にかける
稼働とかコストっていうのが
非常に意味が出てくるので
そういう感じで
なんとかですね
この委員会活動っていうのをですね
効果高くできないかなっていうのが
最近ちょっと考えていることですね
ルンバが起動してうるさいですね
っていうような形でですね
ちょっと今日はですね
長くなっちゃいましたけども
リソースマネージャー
っていうものについての
耳鳴りの試みと考察と
今後の課題っていうところを
お話しさせていただきました
なかなかこのあたりは
他の会社さんと違う試みなので
少し細かめに話したんですけども
また深掘りしてお話しできればなと思っております
