学習する組織を目指して会社の垣根を超えて動いた話
こんにちは、シュフティ事業部ディレクターのカネヤマです。
今日は、シュフティ事業部での課題感を解決するために、社外の人も巻き込んで解決しようと動いた話です。
何故、相談にいこうと思ったのか？
ことの発端は、従業員エンゲージメントのサーベイ結果を眺めている人の一言でした。
「なぜ、成長機会の項目が低いままなのだろう…」
その、謎を解明するために我々はアマゾンの奥地へ…行ってる場合ではないので、身近なところで解決をできないかを考えました。
※従業員エンゲージメントについてはこちらを参考にしてください。
さて、成長機会という項目が低いことに対して、良い打ち手が思いつかなかった我々は、藁にもすがる思いで「学習する組織」という書籍を参考にして対策を考えてみることにしました。
※後々になってわかるのですが、直接的に学習する組織を目指すというのが目的にはマッチしていませんでした。しかし、方針が立っていない状態だったので色々な施策を考えるきっかけとしては良かったと思います。
1人で悩んでも仕方がない！信頼できる仲間に相談だ！
さて、この「学習する組織」について学びを深めたいと考えたので、詳しい人に相談に乗ってもらおうと思いとある人物に声を掛けました。
それが、現在、スタディストで人事をされているてぃーびーさんです。
※てぃーびーさんと私は所属しているGrowthfactionというコミュニティ繋がりです。
てぃーびーさんに対して、「今の会社を学習する組織にしていくためには、どうしていけば良いのかを相談をさせていただけませんか？」と尋ねたところ快く快諾していただきました。
※先程も述べましたが、この相談についても的はずれだったのでそれでも最後まで相談に乗っていただけたのはありがたかったです。
さらに、その会話を聞いていたアカツキのVPoEであるゆのんさん（同じくコミュニティ繋がり）が興味を持っていただき、二人にお話を聞く機会を作ってもらうことにしました。
そんな感じで豪華な相談会が開かれることになりました。さすがに1人で話を聞いてくるのも勿体ないと思ったので、シュフティ事業部のエンゲージメント向上担当であるタケハラさんを連れて二人で相談に行ってきました。
余談：アカツキのオフィスへ
これは、アカツキのオフィスについてはしゃぐ私（そこそこ行ったことがある会社でしたがｗ）
毎度のことながら、テーマ性のある素敵なオフィスです。
相談会開始
ファシリテートはてぃーびーさんにおまかせして、現状、シュフティ事業部での課題感を共有するところからはじめました。
今回解決したいと考えていたのは、成長機会という項目がとある時期から低い状態を続けていたことです。
学習することができていないと感じることは、成長ができないということにも繋がるためなんとかしたいという想いがありました。
それが最近上がらないのは何故だろう？ということを考えているといくつかの要因が浮かび上がってきました。
要因1:EMが不在であること
かつては、EMが1on1などを通して、キャリアの方向性や個人の成長を促すということを行っておりました。
しかし、そのEMがいなくなってしまい事業部全体のマネージャーがマネジメントをする現在の形になっていました。
これは、よくある話だと思いますが、マネジメントする人数が多くなると必然的に一人あたりにかけられる時間が足りなくなってしまうので、フォローが薄くなってしまいます（EMという役割が注目されていることからも重要な役割であるのだなぁと実感）
なので、その課題を解決するためには自己組織化をしていくことを目指すというのが案として上がりました。しかし、それは簡単なことではなく、時間もかかる施策です。
長期的に見てそれを行うことは必要だと思いますが、直近の打ち手としてはやはりEMが必要だろうなぁという話に！
ということで話の途中ですが宣伝です。
シュフティ事業部のEMに興味がある方はお声がけください！
さて、宣伝をするべきことは宣伝をしましたので、次の話に行きましょう。
要因2:プロダクトのフェーズが学習することに注力しづらいフェーズになっている
シュフティというプロダクトが狩野モデルでいうところの、「当たり前品質」を追求している状態なので、学びを実感しにくい開発が続いていたのかもしれないという気づきです。
こういう機能はあって当たり前！という機能の開発は、あるべきものをあるべき姿に作っていく開発が多いので学習することが少なくなりがちです。
一方で、当たり前の品質にすることで、確実に機能としてカイゼンされていくので、エンジニアたちの達成感などは高くなっていたということも分析できたので、この仮説は良い仮説なんだろうと思いました。
要因3:アウトプットとインプットはトレードオフの関係になってしまいがち
シュフティ事業部では、リリースのサイクルを高めてスピード感を持って開発をする形を取っています。
それにより、プロダクトのカイゼンが早くなり必要な機能がドンドン出ていく状態になっているので、エンジニアとして成果がでるようになっている状態とも言えます。
しかし、リリースサイクルを短くしようとするとリリースができる範囲の機能にしか挑戦をしなくなってしまうことが起きていました。
動くものをリリースすることに価値があるという考え方で開発を進めているので、リリースにつながらないインプットに時間をかけられていないことが成長機会の項目を下げる要因になってしまったのかもしれません。(ここらへんのやり方で、良い施策を知っている人はお知恵をお借りしたいです！)
そんな状況を総合的に考えて…
ゆのんさんから「そもそもの話として成長機会という項目は果たして今上げるべきものなのか？」という問いかけをいただきました。
たしかに、エンゲージメントの数値というのは高いに越したことは無いとは思います。しかし、現実のプロダクトの状況や各個人のスキルによっては”今すぐ”解決に動く必要が無いのかもしれないということを考えてみることは重要なのだと気付かされました。
我々のプロダクトがどこに向かっていて、今どこにいるのかということに納得感があれば、成長機会という項目が低かったとしても良い方向に進んでいけるはずです。
そのことに気がつくことができました。
まとめ
学習する組織についてはあまり関係無かったですね。※タイトルで釣ってしまったようになってしまいスミマセンでした。
とはいえ、きっかけとなった「学習する組織」の中のシステム思考などを社内に広めていくことは良いと思うのでやっていきます。
あ、私のネクストアクションは…会社の中で失敗をするという経験を積むということです。（リスクを恐れず良いと思うことをやれ！という意味）
失敗はしたくないものではありますが、それを恐れてチャレンジできないことはもっとダメだと思うので積極的に攻めていきたいと思います！
うるるでは一緒に働く仲間を探しています。
もしも興味がありましたら、うるるにお話を聞きに来てみませんか？
特にEMの方！
この記事が気に入ったらサポートをしてみませんか？