つまづいて気づいた「マネジメント」をアンインストールして「場をつくる」こと
ご覧いただきありがとうございます。
前回投稿してからすっかり間が空いてしまいました。
今回は個人的なつまづきエピソードと気づきを書いていこうと思います。
フラットなチームをめざしてスタート
前回の記事で書きましたが、私たちDX推進室はプロダクトを持っていないチームでありながら、アジャイルな働き方へのチャレンジをしているところで、まさに実験中のチームです。
１０月の下半期スタート時のことですが、うちの会社では半期に一度、メンバーの異動や担当や組織の変更等を踏まえて組織図の見直しをおこない会社へ提出をします。
前期から使っていた組織図は、縦に一列に上からグレード順・年次から並べられているレイアウトで、よくある階層型組織のイメージでした。
そのときチームの中で「管理職だから上に位置づけされるのって何か違和感」「そもそも私たちが目指す新しい働き方に、管理という概念はないのでは？」という意見が出て、みんなで「たしかに！」となり最終的にこんなレイアウトに着地しました。
こういう意見が言い合えるチームになったのも良い変化です！
社内資料の組織図ではあまり見ない自由な布陣です
そしてDX推進室では「開発体制サポート」「業務環境」「人材組織」の３つのチームに分かれ、それぞれのチームをひとつの「プロダクト」と定義してスタートしました。
私は人事部を兼任しているので「人材組織」領域のプロダクトオーナー（PO）を担当し、また別のチームではPOではなくいち担当メンバーとしてスクラムを組み、タスクを進めることになりました。
つまずいた
初心者なのでまずは学んだ知識をもとに型通りにプロダクトオーナーというロールをやってみよう！と思ったものの、いざやってみると難しい。。
２か月ほど経ったときの私の気持ちです。
slackやnotionは見てるけど、今みんなはどうなってるんだろう？
けど、定期的な報告を求めるのはちがう・・
MTGを業務的な進捗共有の場にはしたくない
「困ってることあれば言ってね！」と声かけてみたけど特段なさそう
チームはうまく動いているからいったん良いのか・・？
あれ、こういうときプロダクトオーナーは何をするんだ？
（本を読み返したりWebで調べたりするけど、プロダクトを持っていないので、何だかイマイチしっくり来ない・・）
私いらない？
アジャイルなチームになろう！
わくわくして始まったけど、自分の役割が何だか分からなくなりました。
当たり前をアンインストールする
そんなモヤモヤを抱えながら、私たちDX推進室に伴走してくださっているMutureのそねさんとの1on1で「どうして良いか悩んでます」と相談したときの一言。
「うめさん、心の中ではチームのこと管理したがってるんじゃないですか？」
グサッときました。アジャイルやスクラムに触れて、まずはやってみよう！としたものの根本が変わっていない自分を突き付けられた気持ちでした。
改めて状況を見ると、タスクも見える化されてて、メンバー同士で「これやらなきゃ」「これやっておきますね！」となっている、まさに自己組織的なチーム。
そこに必要なのは、管理ではなくメンバーと同じ場にいることだと気づきました。
ちなみに「場」とはFace to Faceのリアルもあるし、slackの中でのやり取りのオンラインの場も両方です。
同じ場のなかで、メンバーが悩んだり困ったときに優先順位や方向性を一緒に考え、対話していくこと
知りたいと思ったら素直に「教えて！」と聞きに行くこと
もしもチームが停滞してしまう場合は、「これやらないといけないよね、みんなでやっつけていこう！」という状態をチームにつくること
９月に参加したアジャイル研修でも「Do AgileではなくBe Agile」と言っていたのはまさにこれだとハッとしました。
これまでの価値観や自分の中の当たり前をアンインストールできないまま、組織図や役職名称が変わっただけのなんちゃってアジャイルにすぎず、全然本質ではなかったと反省することができるきっかけになりました。
同じ目的に向かうことの大切さを身をもって実感しました
企業文化に広げていくために
そして同時に、アジャイルな組織にしていくためには、働き方というソフト面だけではなく、キャリアや育成・評価などの人事関連の仕組みや制度のハード面も進化していく必要があると改めて実感しました。
丸井グループでは、成長し、グレードが上がるにつれマネジメントの能力が求められます。マネジメントができる人材というのは、会社という大きな組織においては間違いなく必要なスキルであり、非常に重要な役割です。
私もこれまでキャリアを重ねる中でチームをマネジメントすることが増え、それ自体は大事な経験でありたくさんの成長機会でしたが、これから私たちがめざす「メンバーの主体性を発揮する・自己組織的なチーム」になっていくためには、これまでのあり方にとらわれないキャリアやリーダーシップが求められると感じています。（とは言えまだまだマネジメントもうまくできず失敗ばかりです。機会があれば記事にしてみます）
もちろん業務内容の特性やリスク管理上、業務フローや管理者・決裁規定が明確に定められるべき部門や組織もあります。それらも踏まえながら、マネジメントのあり方についても社内で様々な視点から対話がされているので、丸井グループらしい考え方を探索していきたいと思います。
今回お伝えしたのは私個人の小さなつまづき体験でしたが、トライしてみて分かったことがたくさんありました。
気づきをくれたDX推進室メンバーの皆さん、Mutureそねさんに改めて感謝です。試行錯誤していきますのでこれからもよろしくお願いします。
いつも失敗やらつまづきの話ばかりでなんだか暗い（？）感じがするので、今度は明るい記事も書いてみようと思います。
なお、実際にプロダクトを持っているソフトウェア開発チームではないので、一般的な考え方や定義と異なる部分もあるかもしれませんが、私たちなりに解釈して実験しているため、あたたかい目で見ていただけると嬉しいです。
最後までご覧いただきありがとうございました！