対話の時間を通してオープンな情報共有を。コアとして大切にしていること

10月に開催された、「ULURU Synapse Award」

うるるが提唱している「シナプス組織論」の浸透を目指し、日々組織と向き合っているコアを表彰するアワードです。

シナプス組織論についてはこちら

blog.uluru.biz

今回ブロンズ・コア賞に選ばれたのは、NJSS事業本部 事業開発部 プロダクト開発課 課長の森山宏啓（もりやま・ひろあき）さん。

受賞理由：

チームのことをとにかく考え行動されているという感謝のエピソードが多く上がりました。

ルールや運営の整備を行いコミュニケーションロス防止に努めた取り組みや、チーム状況を細かく分析しイキイキとしたチームづくり・雰囲気づくりに努めた姿勢がコアラーより評価されました。

プロダクト開発課の課長として個性豊かなメンバーを束ねてくれたと、メンバーからも感謝のエピソードが上がった森山さん。コアとしてどんなことに取り組んだのでしょうか？お話を伺いました。

＜森山さんプロフィール＞

2019年3月にうるるに入社。現在は、NJSS事業本部 事業開発部 プロダクト開発課 課長。エンジニアとして新卒で入社した後、ベンチャー企業に転職。人事、労務、総務、経理、営業といったさまざまな業務を経験。趣味はドライブで特技はショートスリープ。

ー受賞できたのはメンバーのおかげ

シナプスアワードの前に受賞が決まったと伝えられた時には、率直に嬉しい！という気持ちと、メンバーのおかげだなという思いが強かったです。

コアって具体的に何をやったから表彰されるというものでもなくて、メンバーが頑張って活躍してくれているからこそ、コアの役割を果たせたと言ってもらえるんだろうな、と思いました。

今は、「本当に自分がもらって良かったの？」という気持ちも出てきていて。

でもそれは、全くネガティブな意味ではないんです。

自分だけが特別なことをやっていたわけじゃなくて、他のコアの人も当たり前にやっていることを当たり前にやっているだけだなとも思っています。

評価されるのは嬉しい一方、斬新なことを生み出したわけでもないし、全部が全部成功しているわけではない側面もあります。

だから、「本当に賞をもらって良かったのかな」とか「賞をもらったことに満足せず、もっともっと挑戦を続けなければ」という気持ちが、受賞を聞いた瞬間よりは強くなってきていますね。

ーメンバーとの対話の時間を意識的に増やす

受賞理由を見ていると、メンバーがいろんなエピソードに基づいて推薦してくれていました。

その中でも取り組んで良かったのかなと思ったのは、対話の時間を増やしてコミュニケーションの機会をしっかり設けていたのが、メンバーにも喜んでもらえていたこと。

過去のキャリアの中では、いわゆる受託開発や顧客先に常駐して開発をやるような、「決まったものを言われるままつくる」という仕事もありました。

事業会社にいて自社のプロダクトをつくっている時も、営業側が決めた仕様を開発は仕様通りに作るというような経験もあって。

自分たちで決めたわけではないものを言われるがままつくるのって、すごく納得感が少ないんですよね。

なぜそれをやらないといけないのか、なぜ今の段階で優先順位が変わるのか。

エンジニアとしてものをつくる上で納得感は非常に大切だなという実感があったので、自分はできるだけオープンに情報をメンバーに伝えよう、と気をつけていました。

もちろん体制変更など発表まで伝えられない情報もありますが、公開できる情報や「こういう開発をしたい」「こういう目的があってシステムとして実現したい」といった情報はできる限りオープンに、クリアに伝え、納得感を持って仕事に向き合える環境づくりをしています。

他にもNJSSの開発チームは、「N-Devスピリット」という開発チーム全体で大切にしていきたい価値観を決めています。

その価値観を決める際もみんなで話し合いましたし、毎期の方針もメンバーとの会話や部の方向性を元にを決めているんですが、折に触れて「N-Devスピリット」や期ごとの方針を繰り返し伝えるようにしていて、普段の会話の中でも「N-Devスピリット」などが自然と出てくる状態になっています。

大規模なプロジェクトに取り組んでいる中で、終盤に追加要望や突然の仕様変更が入るなど大変な状況になったことがありました。

そんな中でも対話の機会を作り、その背景を理解する場を持つことで、厳しい中でも納得感を持ちながら、ポジティブに進められたと思っています。

こういった事例は「N-Devスピリット」のように共通の価値観を持っていたからこそだと感じています。

ーマネージャーは完璧じゃない。対話の時間を持つ重要性

情報はオープンにする一方で、メンバーそれぞれへの伝え方という部分には細心の注意を払っていました。

「俺はそれ聞いてないけど」「なんであいつだけが知ってるの？」ということがあると、ただでさえ忙しい状況の時に、更なるメンバー不和を生んでしまいます。

とはいえ、急ぎで話さないといけないことがある時に、メンバー全員が揃う機会を待っていたら時間がかかってしまい対応が遅れることも。

これは全体の場で全員に話すべきことなのか、個別に話しておくべきことなのかという見極めは必要ですよね。

もともとスクラム開発という手法を取っているので、毎週1回は全員で集まる機会があるんですが、メンバーそれぞれの状況に合わせて個別に1on1も設定しています。

1on1をスタートする時、最初にメンバーに伝えたのは「基本的にスキップNG」というルール。

リスケはOKだけど、1on1を開催しないのはNGとしていました。

開発が立て込む時期はどうしてもスキップせざるを得ないこともありましたが、基本的には毎週ないし毎月など、決まった周期で1on1を実施していました。

スキップが当たり前になってしまうと、当然ですけど対話の機会が減ってしまう。

それはコアにとってもコアラーにとっても、お互いにメリットがないと思うんです。

「マネージャーは別に完璧じゃない。自分も間違えることはあるから、そんな時はみんなの意見で修正して欲しい」ということをメンバーには普段から伝えています。

1on1はマネージャー（＝コア）からメンバー（＝コアラー）に対して一方的に情報を伝える場ではなく、コアラーからコアに対して、困りごとやこうしてほしいという要望を伝えたり、解決方法を一緒に考えていく場。

だからこそ双方向のコミュニケーションをして、お互いに実りがある時間になるように、対話の機会はすごく大切にしていますね。

ー自分が担当しているコアラーには成長してほしいし、楽しんでほしい

コアとして、マネージャーとして、自分のチームのメンバーと向き合った時に、やっぱりメンバーには成長していってほしいという気持ちが強いです。

その成長は、うるるの中でだけ評価される人材になってほしいわけじゃなくて、うるるでも、エンジニア市場、世の中全体で見た時に評価されるような成長をしてほしいんです。

エンジニアはいわゆる「技術職」と呼ばれる仕事で、技術の知識や経験はもちろん大切ですが、技術しか知らない人にはなってほしくないと考えてます。

私たちはものをつくることが仕事かもしれないけれど、それだけでビジネスは成り立たないですよね。

私たちがつくったものを誰がどうやって売っていくのか、それが会計としてどう反映されて、どう会社が運営されていくのか。

いろんな職種が交じり合うことでビジネス、事業は成り立っています。

私自身がキャリアの中でいろんな職種を経験してきたからこそ、それは実感を持って言うことができます。

メンバーにはエンジニアという狭いスコープの中だけじゃなくて、幅広い視野を持ってほしい。

だから情報を伝えることは惜しまないし、他の職種ともひとつのチームとして動けるような環境をつくりたいと思っています。それがメンバーの成長にきっとつながるから。

プロダクト開発課は、特に「チームであること」を大切にしている組織だと思います。

私自身も「楽しく結果を出せるチームにしたい」という強い思いがあります。

やりたいことだけやってワイワイ楽しいだけでもだめだし、成果だけを追い求めてメンバー間がギスギスして、メンバーがつらい思いをするのもだめ。

両方を取れるチームでありたいんですよね。

例えば社内でつくって顧客にリリースする前に社内でユーザーテストを行うんですが、他部署から「これバグです」という報告が上がってくると、つくった張本人のエンジニアとしては多少なりともダメージがあります。

ちゃんとつくった自負がある分、それが違った時にメンタルがきついです。

でもどれだけ厳しい状況でも、できる限り不具合を解消した状態でないと、お客様に公開することはできません。

もちろん楽しくはないですが、価値あるプロダクトを提供するためには避けられないフローです。

避けられないもので、それでもどうやったら少しでも楽しく向き合えるかなと考えて、ユーザーテストという表現を使わずに「バグ出し祭り」という名前にしたんですよね。バグを1番出してくれた人には景品を出します！と言って（笑）

エンジニアの方も不具合報告が上がってくると「ああ…」って感じはあるんだけど、「これは祭りだから。いっぱい出してもらうことが目的なんだから」っていう伝え方に変えました。

言葉の問題だけって思われるかもしれないんですけど、そういう言い方にちょっと変えるだけでも、稼働時間が増えていて追い込まれているメンバーにとっては、少しでも気が楽になるんじゃないかなと。

実際「バグ出し祭り」の時にもたくさん不具合報告は上がって来ましたが、そこまで開発チームに悲壮な雰囲気はなく、少しは楽しもうという気持ちは持てたかなと思います。

ーこれからもコアとしてチームの成果を追い求め、課題を解決していきたい

私自身もともとは結構ネガティブな性格で、最初に管理職になった時には「森山さんの下で仕事したくないです」って言われたこともあるくらい。苦い経験もたくさんして来ました。

キャリアを積む中で勉強して、考え直して、管理職の経験がある先輩に話を聞いたりしながら、今のスタイルに辿り着いたという感じです。

だからコアラーであるメンバーのみんなには同じ苦い経験をしてほしくない。

中には経験した方がいい失敗もありますけど、しなくていい苦しい思いはしなくていいようにしてあげたいな、という思いがあります。

また、これには反対意見もあると思うんですが、私自身は個人の成果よりもチームの成果を優先したい。

一人だけがすごい成長をして能力が10倍になりましたというより、チーム全体の能力を2倍にする方が後々を考えた時に価値があることだと思っています。

エンジニア組織あるあるかもしれないんですが、仕事が属人化してしまうリスクって結構発生しがちなんですよね。

どれだけひとりの人が技術力をつけたとしても、その人が辞めた時に継続性がないのはチームとしてアウト。

私たちの仕事はつくって終わりではなくて、その後の保守や改修、成長まで継続的に見ていく必要があって、そのためにはチーム全体の力を底上げした方が絶対にいい。

とはいえ個人の成長は無視するのかというと、もちろん違います。

個人の成長やこういうことがやりたいという思いは、1on1など対話の機会の時に聞いて、じゃあどういう仕事をやるのが個人の成長にもつながるんだっけという視点で、働きやすい・成長しやすい環境づくりをしていくことが必要だと思っています。

開発チームはまだまだ課題がたくさんある組織です。

全てが課題で、メンバーのみんなもまだまだ満足していないと思います。

事業が成長する時も個人が成長する時も同じだと思うんですが、成長してひとつ上のステップに進む時は絶対に成長痛があるもの。

今までとは何かを変えなきゃいけなかったり、これまでより負荷の高いことに挑戦しないといけなかったりするのは、大変だししんどいこともあります。

でもその「成長痛」すらも楽しめるように。ひとりではなくチームとして「成長痛」に向き合い、一緒に乗り越えられる、そんな組織をコアとしてこれからもつくっていきたいなと思っています。

今回は素敵な賞をいただき、ありがとうございました。