人の出入りがある前提でチームをどう設計するか？　信頼残高が足りない組織が、持続可能性を高めた「仕組み」

信頼残高が足りない問題の分析

山口隆広氏：人はなんとかなりました。次は組織と信頼残高を積むというところで、まだまだ終わりません。

でもどうしようと。信頼残高が足りないという問題があって、とはいえ課題も把握しなければいけないと思ったので、少しショートカットしようと思いました。

もともと組織にいて、信頼残高がものすごく高くて、ファシリテーション能力も高いメンバーがいたので、その人にいろいろ聞いて、1on1してきてほしいという話をしました。もちろんそのメンバーが密告者みたいな扱いをされると申し訳ないので、ある程度匿名性は担保していいかたちでやりました。

（スライドを示して）結果、こんな話が出てきました。「みんな親なので、優しくて場を乱したくない気持ちが強い」とか。一つひとつ見ると「そんなことが？」と思いますが、こういうのがメチャクチャ積み重なってくると日々つらいんですよね。ずっと我慢しているからつらくなっていくので、こういったものを大物小物問わず、片っ端から倒していきました。

あとは、週次で本部長と副本部長に「このあたりが課題なんですけど、知っていますか？」「解決してくださいね」というレビューを毎週やっていました。そうすることで、「1on1で話してもどうせこの組織は何も変わらないんでしょ？」というところから、「ちょっとずつ良くなってるね」「ちょっと話してもいいかも」というところまで、信頼残高も積めるし、雰囲気も良くなっていきました。

とはいえ、信頼残高でいうと、最後はプレイヤーとして仕事ができるかが大きくて。組織のことをやっている人って、だんだん机上の空論ばっかり言う感じになってしまうので、「別にあの人は戦力じゃないし」と話を聞いてもらえなくなってしまうんですよね。

当時（の僕は）、子どもは1才ちょっとで、育児もしなければいけない、仕事もしなければいけない、さらにマネジメントもするんですかみたいな。ハードワークな感じではありましたが、「やらなきゃしょうがない！」ということで、Androidのコードを書いたり、ひたすらいろいろなことをやってなんとかしていました。

最初にプレイヤーとして入っているので、プレイヤーとして結果が出せなかったら意味がないとなると、入社したての頃にしか間違えられないと思ったので、最初の頃にガンガン間違えて地道にやっていました。

（スライドを示して）おまけに少し「つらみ」について書いたので、ぜひ見てください。

（スライドを示して）ここは大事な話です。僕もメガベンチャーに行ったのでわかるのですが、大きい会社とかから来て「こういうやり方が正義なのでやってください」と言われても、「そもそもお前のこと知らないし、信頼していないし、うるさい」となってしまうんですよね。「お前の言うことはわかるけど、気に食わないので聞きません」となってしまうので、そこは時間をかけてでもきちんとやらないと無理だと思っています。

あと「その言い分に共感はできないんだけど、そう思うことがあるのね」と理解するのはすごく大事です。なので、違いを認めずに1色にしようとすると、すごくハレーションしてしまうと思っています。

信頼残高を積む話をしていますが、それを削ってでもやらなければいけないことがあります。本来は採用でやるべきなんですが、今のユニファ株式会社じゃできないことがいっぱいあったんですよね。

「あるべき開発プロセスがいいです」「デザインシステム極めたい」と言われても、プロダクトを8個出さなきゃいけない状態なので、「それはごめん、今は無理だわ」と、（採用した人が）入る時はその話をして謝ります。

中にいるメンバーへは「悪いけど今はできないんだけど、どう思う？　その後に転職するパターンもあるかもしれないけど」という話を誠実にやっています。これで離れていったメンバーもいますが、最終的にお互いがそれでいいとなったら、問題ないよねという話をしていました。

人の出入りがある前提で、チームの設計をどうするか

次です。人の出入りがある前提のチーム設計をどうするのかという話になってきます。

ユニファ株式会社は優しいので、人が辞めてしまうことなどを大ごととして捉えてしまうんですが、ベンチャーはだいたい2～3年で人が入れ替わります。

でもそうなった時に、「新人受け入れは個人がOJTをメッチャがんばれ」「退職者の引き継ぎは、中にいる人が忙しいかもしれないけどがんばって」だと、みんな死んじゃうんですよ。持続可能ではない、SDGsな組織ではないとなってしまうので、そこも仕組み化して、誰がやってもだいたいはできる状態にしようと思いました。

そこで、みなさんもやっていると思いますが、誰でも再現できるオンボーディングを社内のメンバーと一緒に作ることにしました。これは2021年3月ぐらいに作りました。

どうやって作ったのかというと、PdMのあり方から作ってしまうとえらいことになってしまうので、取り急ぎ、自分を含めた1年前ぐらいから入った人に、入社して困ったことを全部ヒアリングしてみました。

あと、既存メンバーにも、「なんで新人はこんなことも分からないんですか？」と思ってしまうようなことも、たぶんいっぱいあると思うんですよ。その部分をヒアリングをしていきました。結果、「1ヶ月でこういうことをやると良い」というものを作って、展開しました。

リモート下なので、誰が何の担当なのかわからなかったり、普通だと思われていることが何なのかわからなかったりして、期待値がそもそも合ってないんですよね。だから、アサインされていきなりすごい仕事を求められて「無理です」「あの人使えないです」となってしまう。そうするとみんな不幸になってしまうので、そこの交通整理みたいなことをやっていました。

（スライドを示して）目次一覧を紹介します。明日から真似できるので、ぜひやってみてください。

あと、ノウハウとしては、配属部署全員と1on1は絶対にやったほうがいいので、やってみてください。これは強制力があったほうが良いです。「やらされているので……」と言って上司が悪者になれば済む話なので、やってみるといいと思います。

次は引き継ぎに関してです。2020年後半、僕が入って少し経った時のチーム体制は、PdMは5～6人しかいないのにプロダクトはたくさんあるので、1個作ったら解散して、また他のプロダクトに行くということをしていました。

そうすると、人が辞めちゃった時に知見がまるまるなくなってしまう。1個のサービスに1人しかPdMがいない、PdMというか当時はディレクターでしたが、いなくなってしまうので大変な状態になっていて、こんなのは続かないと。

そうなった時に、1人の体制だと人の仕事もわからないし、人を頼れず潰れてしまう課題もあります。あと、入った時に「今はこの案件をやるけど、次に何をやるかはわからない」という感じになっていて、毎回一期一会で超つらい状態でした。

誰かが退職しないとその人の仕事に触れる機会がない状況だったので「そもそも他の人とチームとして一緒に仕事をする機会を作りましょう」としました。誰にも頼れず潰れてしまうことを物理的に避ける狙いもありました。

チームがない頃は部署の仕事を学ぶ、すなわち全てのプロダクト全てを１から学ぶ必要がありましたが、まずはチームの扱う範囲のプロダクトから覚えればよいと言うことになり、オンボーディングの階段も作りやすくなりました。

結果、変更したチーム体制で、カスタマージャーニーが似たサービス、例えば「これは園の先生が使うサービスですよね」「これはだいたい保護者ですよね」ということをまとめて、PdMと組ませてチームを作っていきました。

こうなってくると、1人で仕事をしている時は「ドキュメントをちゃんとやろう」という気持ちにあまりならないと思いますが、他のメンバーもいるので、ドキュメントを作る気持ちが出てきたり、人が入ってきてもチームのみんなで教えたりできるようになりました。

今まで1人のPdMが全部やらなければいけなかったので、人によってブレてしまう部分も、だいぶマシになった体制が作れました。

もちろんサービスで分けるのも良いですが、みんな人なので、人のwillやcanを意識してやらないといけません。「こういうことがやりたい」「こういう方向に行きたい」ということは半年でぜんぜん変わるので、「エスパーせずに聞く」ことが大事です。

あとは、やりたいことが特にない人でも、やりたくないことはあったりするんですよ。「これは絶対やりたくないです」ということもちゃんと聞いておいて、変なアサインをしないことは大事です。結果的に、みんなが能力を発揮できる状態ができます。

つまり、新人なのにリスクの高い新規事業を1人でやらせるのはやめましょう、ちゃんとケアも把握しましょうという話です。

（スライドを示して）「こういうアサインをすると辞めます」ということが書いてあるので、ぜひ参考にしてください。本当に辞めてしまうと思うので、絶対に避けてほしいと思います。

組織改善とプレイヤーを一緒にやるのは無理

最後です。

組織改善とプレイヤーを一緒にやるのは無理です。僕は全部うまくいったみたいにしゃべってますが、全社的に謝るようなこともやっています。担当していた保護者アプリのリリースが9月1日だったんですが、2週間遅れたんです。

他のことを全部カバーしているので、自分が最後になってしまって、保護者アプリのメンバーに大変申し訳ない部分もあったんですが。そういうことを実際に起こしていたり、あと、最初は業務プロセスを標準化しようと言っていましたが、それぞれのやり方があるので、「8個作らないといけないのに何やってるんですか」「今はそれじゃないですよね」ということがあったり、メチャクチャ失敗してます。

最初にHCDサイクル（Human Centered Design）（の話）を出しましたが、あれもたくさん回していて、「これはダメ、これは良い」という評価をすることによって、組織という「ユーザー理解」をだんだん進めていっているのかなという実感はあります。ただ、まだ1年なので、これからもまだまだやることはあるとは思っています。

例えば、実際にリリースした後のグロースフェーズに必要なPdMの組織はどうすればいいのか。そこをがんばらなきゃいけないということはこれからもあります。

タイムラインでいうと、2020年の9月に入って、2021年の9月にアプリをリリースするところまで、1年近くかかっているんですよね。最初の頃は空回りばっかりしているし、「何やってるんですか！」ということもたくさん言われました。なので、信頼残高を積みながら組織を変えていくには1年ぐらいかかるんだなと思っておくと、新しい会社に入った時にも変に焦らなくて済むと思います。

（スライドを示して）「組織改善としてHCDサイクルを回すとこんな感じです」というものを、おまけで貼っておいたので見てください。

仕組みを作ることに取り組むと、けっこう大きな成果を出せる

というわけで、（スライドを示して）明日から真似できるアクションをいろいろ書きましたが、持続可能な方法でものを一気に作っていくには、1人だけでがんばってもしょうがないんですよね。みんなが特定の分野の天才ではなくて、仕組みに乗っかって成果が出せることがすごく大事だと思います。

そういった仕組みを作ることも嫌がらずにやってみると、“組織作りおじさん”と言われたりもしますが、けっこう大きな成果を出せると思うのでおすすめです。みなさんの試行錯誤もぜひ教えてくださいという感じで、私の発表を終わりにしたいと思います。

どうもありがとうございました。