
2025.03.07
メール対応担当の8割以上が「カスハラ被害」に クレームのハード化・長期化を防ぐ4つの対策
リンクをコピー
記事をブックマーク
futaba氏(以下、futaba):まずはじめに、SmartHRの開発組織についてkissyさんから紹介してもらおうと思います。kissyさんよろしくお願いします。
kissy氏(以下、kissy):SmartHRでプロダクトマネージャーをしています。kissyと申します。今日はよろしくお願いします。早く乾杯したい気持ちを抑えつつ、本編に先立ち、私からSmartHRの開発体制について簡単にお話しします。
(スライドを示して)プロダクトとチームの構成についての図になっています。プロダクトは、大きくSmartHR本体とプラスアプリに分かれています。
僕たちが所属しているのは、SmartHR本体側の開発組織です。SmartHR本体の役割は労務業務の効率化がメインで、労務業務を通じて集めた従業員情報の管理を担っているプロダクトになっています。一方、プラスアプリはSmartHR本体にアドオンするかたちで提供しているプロダクト群です。本体とプラスアプリに分かれているところだけ、ざっくり伝われば大丈夫です。
開発体制ですが、基本的にはどのプロダクトもスクラムという開発のフレームワークを採用しています。SmartHR本体側はプロダクトの規模も大きいこともあって、スクラムを拡大したフレームワークであるLeSS(Large-Scale Scrum)を採用しています。
先ほど組織図を見ながら「開発に関わっている人数って今どれくらいなんだろう」と見てみたら、今日で49人とか50人くらいになっていて、かなり大所帯な開発組織になってきましたね。プロダクトの組織はこんな感じになっています。
kissy:次のスライドでは僕らが所属しているSmartHR本体の開発組織、開発体制についてもうちょっと補足していきます。ここではLeSSの話は細かくはしませんが、「こういう人たちがいるよ」というところだけ説明します。
SmartHR本体には現在、プロダクトマネージャーが6人いますが、そのうちの1人がプロダクトオーナーを兼務しており、SmartHR本体全体のバックログの優先度の最終意思決定権を持っています。また、開発チームも6チームあり、各チームにPdM、デザイナー、UXライターなどさまざまな職能の人が所属しています。
開発チームはアルファベット順に名前が決まっていて、僕らCチームは「cokeチーム」という名前でやっています。僕らはふだん自分のチームを「cokeチーム」と言ったりするので、この登壇の中でも「coke」と呼びたいなと思っています。この由来や呼び名の決定の仕方などが気になる方は、質問してもらえれば答えられる範囲で答えます。
kissy:最後にcokeチームの構成と役割です。このスライドで私の説明は最後なんですが、ここで自己紹介もしつつ(進めます)。PdMは私がやっています。あとは順番に各職能の役割と自己紹介も兼ねてmiyashitaさんにバトンタッチしてもいいですか?
miyashita氏(以下、miyashita):プロダクトエンジニアのmiyashitaと申します。入社したのが2020年5月で、まもなく2年近くですかね。入社してからずっと本体機能の開発を担当しています。本日はよろしくお願いいたします。
kissy:続いてgennyさんお願いします。
genny氏(以下、genny):cokeチームでQAエンジニアをやっています。gennyと申します。2020年7月に入社したので、自分ももう少しで2年になるかもみたいな感じです。本日はよろしくお願いします。
wentz氏(以下、wentz):プロダクトデザイナーをしています。wentzと申します。入社したのが2021年の4月なので、もうあと数日でちょうど1年になります。本日はよろしくお願いします。
keroyama氏(以下、keroyama):cokeチームでUXライターをやっています。keroyamaと申します。私が入社したのは2021年の1月なので、入社して1年と3ヶ月くらいです。cokeチームではプロダクト上のあらゆる文言やヘルプページの更新、作成など、みなさまに触れる部分の文言に責任を持って活動しています。本日はよろしくお願いします。
kissy:エンジニアはmiyashitaさんを含めて4人いるので、cokeチームは全部で8人の体制で日々プロダクト開発をしています。(スライドを示して)ちょっと右のほうにアジャイルコーチの豊田さんの写真も載せています。今、SmartHRではアジャイルコーチの豊田さんに業務委託でお手伝いいただいています。
cokeチーム専任というわけではないのですが、日々スクラムのアドバイスとかをしてもらい、いい感じの圧を受けつつ日々開発をしています。以上が開発組織とチームの紹介になります。
futaba:kissyさん、ありがとうございました! では本編の雑談パートということで、トークテーマに入っていければと思いますが、お待ちかね、乾杯のお時間がやってまいりました。見ているみなさんもぜひ飲みながら聞いていただければと思います。我々も飲みながら話そうと思います(笑)。あ、カシュっといい音がしましたね。ではでは、みなさま乾杯~!
(スライドを示して)今日はこちらの3つのトークテーマに沿って雑談を繰り広げていければと思います。最初に開発体制の変化です。そのあと、「今はどういうふうに開発をしているのか?」をお話し、「どういうふうにチーム開発を工夫しているか?」や、今後の展望についても触れていければと思います。
今どういう体制になっているかは先ほどkissyさんが教えてくれたとおりでしたが、この2年くらいで、開発体制がアップデートされ続けて今のかたちになっていると聞きました。
cokeチームでは具体的にどう変わってきたのかを教えてもらいたいです。ここは最古参のmiyashitaさんに聞ければと思います! これまでの変遷の図を準備していただいたんですよね。
miyashita:自分が入社したのが2020年5月、約2年前です。今は(開発チームの数は)6チームですが、当時は3チームでした。どのチームもエンジニアだけのチームというかたちで、PdMやデザイナーといった方々は直接チームには所属せず、機能開発で関わる時に一緒に組んでやる構成でした。
当時も機能開発はガツガツやっていましたが、この時の開発フローはまずPdMの方が仕様を考えて、次にデザイナーの方がデザインを整えて、そのあとエンジニアに回ってくるみたいな段取りで主にやっていました。
(この開発フローでは)考えた仕様の共有の負荷とか、あとはデザインを考えてもらっても、いざ開発に入ったら考慮が足りなかった部分があって後戻りのコストが発生したりと、コストがそれなりにかかっていました。
徐々に「1チーム内でもっとスピーディに開発していきたいね」みたいなかたちで、cokeチームだけではなく本体機能全体として、「エンジニア以外の人も同じチームに入って1チーム内でスピーディに開発していけるといいよね」と。エンジニアだけのチームにQAのgennyさんが入ったり、PdMのkissyさんが入ったり、デザイナーのwentzさん、UXライターのkeroyamaさんが入って。
このタイミング(2021年5月)で機能開発に必要なメンバーがひととおり揃って、coke内だけで必要な機能開発ができるようになりました。というかたちで、今はやっています。
futaba:今のかたちになっているのは、この1年弱なんですね〜。
miyashita:そうですね。それくらいだと思います。
futaba:ずっとやっているのかと思いきや最近でした。
futaba:最初、エンジニアの方が4人いる中に、違う職の方が入っていくのってどうだったのかなあと思うんですけど。例えばkissyさんとか、当時を振り返って、PdMという立場でエンジニアやQAの中に入ってみてどうでした?
kissy:「この日からcokeチームです」と明示的に言われたわけではなくて、先ほどもmiyashitaさんも言ってくれていたとおり、開発はずっとcokeチームのエンジニアとQAエンジニアと一緒にやっていたんですよね。
ただ、PdMも各チームの中に入っていくみたいな流れがSmartHR本体側のPdMグループの中でもちょっとあって。徐々にcokeチームのスクラムのイベントとかにも出るようにはなっていったんですけど、言葉が正しいかアレですが、最初はちょっと肩身が狭かったですね。
futaba:そうなんですね(笑)。エンジニアの方々が強かったみたいな感じですか?
kissy:「スクラムイベントの中にどこまで入り込むべきなんだろう」とか。エンジニア中心のスクラムイベントがほとんどではあったので、「どうやって関わっていこうかなあ」みたいなところは試行錯誤というか、手探りしながら参加していたのをうっすらと覚えています。
futaba:およそ1年前ですね~。そうすると、後半の方(さらに後続でチームに入られた方)とかはけっこう肩身が狭かったのかと思ってしまうんですけど……。
例えば最後のタイミングでチームに入ったwentzさんは、馴染むためにやったことはありますか? 馴染めないという前提で話してしまっているんですが、もしなにかやっていたら教えてください。
wentz:入ったタイミングでは既に開発していた機能のデザインがもうできあがっていて、込み入った実装をされているようなタイミングでした。ちょっと馴染みづらいというか、スクラムの中でタスクを持ちづらいなという時も若干ありました。
ただ、そうした中でも、「じゃあチームに溶け込んでいくためにはどうしたらいいかな」って考えて。1つの手段としては、期待値を調整するワークショップをやったりしていました。これはkeroyamaさんと同じ時にチームに参加したので、一緒のタイミングでやりました。
チームから私、私からチームに対して思っていることや期待したいこと、不安とかを最初にダーっと洗い出して、その中でお互いに「このあたりで連携できそうだね」「このへんは教えられるよ」みたいなコミュニケーションが取れるようになってきて。これは、チームに溶け込むのに役立ったツールだったかなと思います。
futaba:すごい。こういうのって大事ですよね。思っていることを知るとか、特に違う職種同士の方だったりすると悩ましいところなのかなと思うので。私自身の仕事におきかえてもすごく勉強になります。
wentz:私はオンラインで入社をして、完全にリモート勤務の状態で1年間cokeにいるんですけど、そういった中でもmiroとかを使ってワークショップをやったり、日々のコミュニケーションをけっこう大事にしています。
futaba:(スライドを示して)「和服への関心」……めっちゃ目を引きました(笑)。そういうものもありつつという感じなんですね。確かに(相手が)何を考えているのかわかって(仕事が)できるというのは、心理的安全性みたいなのもあっていいなあと思いました。ありがとうございます。
(次回に続く)
関連タグ:
2025.03.07
部下へのフィードバックで最初に伝える一言 何度も指摘せずに済むマネジメントの秘訣
2025.03.04
チームが協力しないのはマネジメントの問題 “協働意識”を高めるマネージャーの特徴とは?
2025.03.05
「一人前のエンジニア」になるために必要なこと 未経験からフルスタックエンジニアへの道筋
2025.01.28
適応障害→ニート→起業して1年で年収1,000万円を達成できたわけ “統計のお姉さん”サトマイ氏が語る、予想外の成功をつかめたポイント
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.03.03
大企業で成功したマネージャーが中小企業で苦戦する理由 “指示待ち”部下を主体的に動かす方法
2025.03.05
「はい、わかりました」と返事をした部下が“かたちだけ動く”理由 主体性を引き出すマネジメントの鍵
2025.03.06
細かく指示出し、何度も確認…部下に悪影響をもたらすマネジメント 過干渉にならない「適度な管理」と任せるコツ
2015.11.24
人は食事をしないとどうなるか 餓死に至る3つのステップ
2025.03.12
新規事業を継続するかどうかを見極める2パターンの判断軸 会社の規模別「撤退基準」の設け方