スクラムの実践で、上司と部下の関係性をより良くできた話
はじめまして、丸井グループでエポスカード会員向けアプリの担当をしている天崎です。みんなからは「ザキさん」と呼ばれています。
現在進行中のプロジェクトではPdMをやらせていただいていて、新米PdMとして勉強と挑戦の日々をすごしています。これまで丸井グループでは、ウォーターフォール型の開発がメインでしたが、私たちのチームでは最近アジャイルな進行や開発にもチャレンジしていて、実際にスクラムのフレームワークを数カ月間実践しており、今日に至っています。
このたび有志メンバーでアドベントカレンダーをやることになり、私もはじめてnoteのアカウント作成⇒さっそく記事書いてみるという運びになりましたので、日々の挑戦の中でのちょっとした発見を書かせて頂きました。
今回記事にさせて頂いたテーマは、タイトルに書かせて頂いた通り、上司との関係性についてです。スクラムのフレームワークを実践した結果、上司との関係性をよりよくできた！という話をご紹介させて頂きます。
上司って、一般的になんか距離感ある存在？
私たちの上司のＹさんは非常に部下想いの優しい性格ですし、私ももうかれこれ数年間一緒にお仕事をしていることもあり、自分で言うのもなんですが気軽に意見交換できたり、非常に近い距離感で日々会話できているなぁと思っており、とても良い関係値ができあがっていると思います。
一方で、Yさんは丸井グループの役員でもいらっしゃるので、いち社員からすると当然かもしれませんが心理的にちょっと遠い存在ではあったと思います。
メンバーの中には、「Yさんは気軽に意見交換できる相手」というよりは、もしかすると「事を前に進めるための突破すべき壁」と思っていたメンバーもいたかもしれません。笑
私個人としては、そんな状況をなんとか変えたくて、チームのメンバーもYさんともっとより気軽に近い距離で何でもフラットに話せるようになると、より活発な議論も生まれて、結果的にプロダクトのためになるし、Ｙさんもそうゆう部下との関係性を求めているのではないかなーと思っていました。
私にとって上司は相棒的な存在であり、異なる観点や専門性を持ったチームの１メンバーだと思うので、特にビジネス面で高い視座をも持った上司と普段から気軽に壁打ちのコミュニケーションをとることは、プロダクトを良くしてユーザーに価値提供するために、必要不可欠だと考えています。
・・・っていう話はプロジェクト発足当初から、メンバーとも会話していて、おそらくチームのメンバーも頭ではなんとなくわかってくれていたと思います。 とはいえ、精神論やあるべき論だけではなかなかＹさんとメンバーの距離は急激には縮まるはずもなく、悩んでいました。
上司の事を「壁」だと思っちゃうのってなんでだろう？
ではなぜ、上司の事を「相棒」や「仲間」ではなく「壁」や「遠い存在」だと思ってしまうのだろう、というのを分解してみると、すごく当然な構造上の理由も見えてきました。
理由①「決裁をもらわないと次に進めない構造」
何かしらのプロジェクトを進行するとき、たいていの場合に期限があります。例えば「下半期までに新サービスをローンチしなきゃいけない」とか「逆算すると今月までに決裁をもらわなければならない」とか「そのためには仕様をはやく確定させなければ」とか、限られた時間の中で一生懸命頑張るわけなのですが、上司に承認をもらわないと次のステップにいは進む事ができないため、いつのまにか「良いプロダクトを作る」という目的から「上司をなんとか突破する」という目的にすり替わってしい、「どうしたらユーザーに喜ばれるか」ではなく「どうしたら上司にOKもらえるか」という頭になってしまうこともあるかもしれません。
特にこれまでのウォーターフォール型の進め方だと、最初から何をつくるのか全量を決めなければならず、途中で大きな軌道修正もできないため、上司としてもジャッジに慎重にならざるを得ず、なかなか上司の承認が下りずに担当者は焦るという負のスパイラルも発生しやすい構造なんだと思います。
このように、期日までに進めようとするメンバーの真面目さや責任感と、ビジネス上のリスクをなるべく抑えたい上司との間でジレンマが起こっているという事です。
理由②「上司は偉い人というバイアス」
上司にあたる人は、「役員」「本部長」「部長」たいてい役職がついていて、その肩書により無意識的に上下関係が生まれてしまう事があるのではないでしょうか。
現在そのポジションにいるということは、これまで会社や世の中に貢献してきた成果が認められた結果、そのポストについているという事だと思うので、リスペクトは当然すべきだと思いますし、私もそういった方々のことを尊敬や憧れの眼ではみています。一方で役職はただのいち役割であり、偉いか偉くないかで言うと特別偉い訳ではないと思うで、本当はもっと近い関係になれるといいのになと私は考えます。
これも頭ではわかっていたとしても、旧来のウォーターフォール型の進め方だと、意思決定は都度上司に確認して次のステップに進むという構造上「都度ジャッジしてもらう偉い人」というバイアスが自然とできあがってしまうのかもしれません。
こうして見ると、上司の事を「相棒」や「仲間」的な存在ではなく、「突破すべき壁」と思ってしまう事があったとしても自然だなと思いました。
スクラムのフレームワークが解決の意図口に
私たちのプロジェクトメンバーが当初、Yさんの事をどれくらい壁だと思っていたかは分かりませんが、少なくとも現在よりはメンバーと少し距離がある存在ではあったのではないかと思います。
そんな中、スクラムのフレームワークが予期せぬ解決の意図口になりました。
現在、私たちのチームでは、スクラムのフレームワークに習って各スクラムイベントを実施しているのですが１週間を１スプリントとし、期間を細切れに区切って、毎週同じイベントを繰り返しながら成果を積み上げています。
上司のYさんにも、このプロジェクトの責任者として、スプリントレビューにも参加頂いていますが、スプリントレビューはYさんに承認をもらう場ではなく、あくまでも議論の位置づけで、Yさんにもフラットな立場で相談役として特にビジネス目線で対話するための１専門人材としてご参加頂いています。もちろんお金がかかることや、プロジェクトのおおきな方向性のジャッジについては承認をもらいにいくシーンもたまにはありますが、普段は基本的には私たちチームメンバーに権限移譲をして頂いていて、相談やアドバイスはもらうが、ジャッジはしないというフラットな関係性になっています。
スクラムで進行した時のチームメンバーのマインド変化
スクラムでプロジェクトを進行し、約半年が経過した今、チームのメンバーのマインドや上司とのコミュニケーションにも変化がありました。
＜変化１：ユーザーのためにまずはやってみよう！という文化の醸成＞
これまでの従来の進め方だと、答申や報告などの大きなマイルストーンに向けて、進行していたのに対して、スクラムで１週間単位の小さいゴールに向けて、小さい頻度で粗くてもまずはやってみよう、もし間違ってもあとで軌道修正できるから大丈夫！という心理状態で、メンバーはユーザーやプロダクトをいかに良くしていくかという事に集中できるようになったと感じています。
＜変化２：上司含むメンバー間のコミュニケーション量の増加＞
物事の決定についても、今までは上司が都度ジャッジしていたので上司のフィードバックに意識が向いていたのが、現在はスクラムの中で権限移譲していただいているので、メンバー全員の責任感や主体性がより向上したように感じています。また、ユーザーにとってより良いプロダクトにしていくために、「今のアイデアについて、Yさん（上司）のビジネス目線の意見も一回もらおう」というような会話も生まれるようになり、上下の関係ではなく異なる観点を持つ１メンバーとしてフラットに関わる関係性に変化も生まれていて、コミュニケーション量も格段に増えたと思います。結果的に、チームの意識がプロダクトやユーザーにより向くようにもなりました。
結論、スクラムとかアジャイルってすごい
チームでスクラムを回し始めて数カ月ですが、当初はプロダクトの修正に向けて学びと改善のサイクルスピードがきっと上がるんだろうなという、ざっくりとした期待はしていたものの、スクラムのフレームワークがチームの中で上司と部下の関係性にも良い影響をあたえるとは思っていなかったのでびっくりしました。
もちろんスクラムとか仕組みだけでなくて、チームメンバーの日々のやる気と挑戦の積み重ねの賜物だと思っていてメンバーや上司のYさんには本当に本当に感謝しています。
今後もプロダクトの改善だけでなくチームの継続的な進化にむけて、チーム一同今後も挑戦していきたいと思います！
最後まで読んでいただきありがとうございました。また今度。
メリークリスマス！