こんにちは！ROXX人事の沼口です。
本日は、2023/7/19に実施したROXX Cafeの内容をお届けします！
※ROXX Cafeについてはこちらの記事をご覧ください

今回はPdM（プロダクトマネージャー、以下「PdM」）スペシャル回をお届けします！
プロダクト開発部から、PdMチーム agent bank担当 粕谷さん、back check担当 松野さん、Records担当 小平さんの三名にご登壇いただきました！
ファシリテーターはCHROの西村さんです。

　　　　　　　　　　　　　左から、松野さん、粕谷さん、小平さん

今回のテーマは「期限を決めて守る」
言葉にすると簡単で、言うまでもなく“いつまでに“、”なにをするか“は仕事の基本ですが、いざやろうとすると何からしたら良いかわからなかったり、想定通りにいかなかったりと、意外と難しかったりもします。
お三方がどうこの基本に向き合っているのか、学ばせていただきましょう！！

テーマは「期限を決めて守る」

自己紹介をお願いします

西村：本日はよろしくお願いします！まずは簡単に自己紹介をお願いします！

松野：back check PdMチームの松野です。昨年の3月に入社し1年5ヶ月ほど経ちます。back check1人目のPdMとして入社し、プロダクトの状況やロードマップの整理をするところから始まり、現在は開発やCS（カスタマーサクセス、以下「CS」）への支援、新規機能開発の施策立案など、来期のプロダクトロードマップを作成したりしております。本日はよろしくお願いします！

粕谷：agent bank PdMチームの粕谷です。入社は一昨年の10月で、もう少しで2年くらいになります。PdMとして要件定義もしつつ、プロダクトオーナー（以下「PO」）も兼務しているので、開発側の優先順位の決定やロードマップの策定、開発の進捗管理も担当しています。よろしくお願いします！

小平：小平涼太です。入社は2015年8月で8年目になります。元々はエンジニア第1号でSCOUTERというサービスの立ち上げをやっていました。2年くらい前まではagent bankの所属だったのですが、Recordsという新規事業開発組織が立ち上がったタイミングで異動しました。そこでは新しいプロダクトを開発する前の段階のユーザーリサーチや、どういうものを作るかを決めたり、その後コードを書いて作る工程を広く浅くやる感じで担当しています。よろしくお願いします！

西村：ありがとうございます！今日も事前に届いている質問をベースに進めさせていただければと思います。
まずは今日参加しているみなさん、夏休みの宿題とかギリギリにやるタイプの人はどれくらいいますか？あ、結構いますね！（笑）
御三方はどうですか？

小平：ギリギリタイプです。やらない、もありましたね（笑）

粕谷：夏休み終わってからやりますよね！（笑）

西村：賢そうな話をしようと思ったのですがやめます（笑）

期限の見積もりが甘くて失敗した話を教えてください

西村：ということで、まず最初に「期限の見積もりが甘くて失敗したな」ということが社会人経験のなかであると思いますが、どんな経験をしてどんなことを学んだのか、失敗談を教えてください！

小平：失敗談ですね。6〜7年くらい前のSCOUTERをリリースして2〜3ヶ月後にプロダクトをリニューアルしようということになっていて、そのリニューアルを私ともう1名とインターン数名とで進めていました。リリース予定日の翌日から会社の合宿があったので、それまでにリリースできるように進めていたのですが、当時は見積もりがどうとか何をどう進めれば期限までに終わるのかみたいなタスクや期限の管理の精度がかなり甘かったんですよね。結果、最後の1週間徹夜してもリリースに間に合わず、合宿は1日遅れで参加した挙句に、合宿中も反省会みたいになって辛い思い出しかなかった、という大きな失敗がありましたね。

西村：ありがとうございます！松野さんはいかがでしょうか？

松野：私は、SIerでプロジェクトに参加してシステムの導入コンサルティングとしてお客様先に常駐してシステムを作る、というのを7〜8年くらいやっていました。
給与系のシステムを担当していた時のプロジェクトなのですが、4月にカットオーバー（新しく開発されたシステムが稼動すること）だったのですが、算定や年末調整のシステムとか何もできてない状態にもかかわらずマネージャーは全然焦ってなくて「大丈夫なんですか？」と聞いたら「大丈夫大丈夫、12月までにあれば大丈夫だから」と言われたのが20代の時に衝撃的でした。どういう意味かというと、保守中に作れば問題ないから、っていうことなんですよね。ちなみに、本当に保守中に作って結局何も問題なく遅れた理由としては違うものを優先したせいだったのですが、そのマネージャーは最初からバッファとして見ていたというのが結構衝撃的で、それからは本当に期限になるものと、遅らせてもなんとかなるものは気にするようになりました。

西村：粕谷さんはどうですか？

粕谷： そうですね、以前やっていた仕事は半分はSaaSのプロダクト開発、残り半分はSIerみたいな感じで、お客様のところに既に納品しているシステムの追加開発を請け負っていました。
そこで開発案件の要件定義をして、見積もりをとって、納品して、みたいなことをやっていたので、毎月数10件の案件の管理をしていると、遅延は小さなものから大きなものまでありました。例えば数百万円の案件が3月末とか期末に出来上がっていませんでしたってなると、計上ずれになるのでまあ悲惨なんですね。社内でも悲惨だし、お客様も年度内の予算で支払いたいのに支払いたくても支払えない、みたいな。
なので、そこを改善するために営業でも開発でもないプロダクトマネジメント的なポジションを後から置いたという背景もあったんですけど、開発チームは短納期でって言われても、他案件もある中で優先順位を変えられないし、営業は営業でせっかく受注してきたのに短納期での受注は嫌がられ、時には怒られる、、みたいな。そういうのはずっと見てきた感じです。

正確な期限を決めるために普段から意識していることを教えてください

西村：松野さんみたいにうまいことやる方法を勉強した方もいれば、期限を遅らせられない場合も多くて、すべてをそのまま守ろうとすると結局期限に間に合わなくなることも少なくないというお話でした。
そういう意味では、正確な期限を見積もるのって結構難しいじゃないですか。
割とよくセンスの問題だみたいな話も聞きますが、それがある程度できるようになってきた理由や、そのために普段から意識されていることがあれば教えてください。
正確な見積もりをするために何を意識しているかという話ですね。
いかがでしょうか、粕谷さん。

粕谷：スコープとマイルストーンの設定の問題があって、期限が決まっているスコープがどこまでなのかという話なのかなと思います。
スコープというのは、例えば、給与計算のシステムって言われたら幅広いんですけど、その中でも、全体に今月納品しなきゃいけない機能はどこまでなのか、範囲をまず正確に把握することです。
その中で、やることをマイルストーンとして抑えていくのですが、それを正確に洗い出し切れているかと、洗い出したものの中にある不確実性が高いものをどれだけ潰せるかが見積もりに一番影響してきます。
洗い出したつもりだけど実はその中身がよくわかっていないとか、その洗い出し方も大事で、例えばお客様から発注書をもらうという粒度だと期日までにもらえない可能性もあり、そのための稟議がどうなっているか、承認する人は誰か、根回しできるのか、など、発注書をもらうという粗いマイルストーンじゃなくて、その中にも不確実性を潰すための要素みたいなのがあるので、それをどこまで具体的にToDoとして洗い出し切れるかと、アンコントローラブルなものをどこまでコントロールできる状態に近づけるかみたいなのが、正確な見積もりをする上でも、また見積もり通りに状況を運ぶ上でも気にしているかなと思います。
あと私は結構カレンダーを見てますね、ずっと。
あと1週間あるって思うのと、5営業日しかないって思うのと、ちょっと気分が違うんですよね。

西村：ありがとうございます。小平さんはいかがですか？

小平：粕谷さんが大体お話してくれた話になりますけど、それ以外でありそうだなと思ったのは、もらう要求って大体がすごいざっくりしてて、それをベースに見積もりをしていくとか、スコープを決めるみたいなことをやっていくことになるんで、そこの要求の解像度をまず上げる、つまり要求を具体的に言語化していくのはありそうだな、いつもやってるなって思いました。
その要求次第では、これいらないじゃんとか、これこうできるじゃんとかっていうのが見つかって、場合によっては見積もりが小さくなったり、不確実性が低いものが見つかったりして、見積もりがぶれにくくなるといった発見ができると思うので、そこの要求をどう解釈するか、どう理解するか、どう受け取るか、みたいなところはかなり時間かけてるところだったなっていうのは振り返って思います。

西村：今、仰っていただいたことって普段の会話でも結構大事ですよね。相手がどういう風に考えているかって、なかなかわかりづらいじゃないですか。

小平：そうですね。
でも多分、要求を出す側にとってその要求を言語化するのは結構難しいと思うんですよ。
私自身も全部の要求を伝えるのって難しいけど、こうですか？っていう問いに対しては、ここが違うっていうのは返しやすいなと思いますし。
なので、プロダクト開発で言うと、例えばすごい精度が高い画面ではないけど簡単な画面とかこういう機能があって、それで要求としてのイメージが正しいかどうか、イエスかノーか、ノーだったら何が違うのか？っていうのを答えやすいようにする感じですね。
それはプロダクト開発だけじゃなくてもできることかなと思います。

PdMの仕事内容について

西村：改めてですが、PdMってどんなお仕事ですか？結構最近出てきたワードだと思うんですけど、私自身もあんまり正確に説明できないんですよね。
ROXXにおけるご自身の役割でも良いです。もしよければ松野さんお願いできますか？

松野：そうですね。皆さんの前で説明するのもおこがましいんですけど、PdMっていう役割が誕生したのは世界的にはここ20年ぐらいと言われています。いろんな書籍で書いてあったり、いろんなプロダクト開発やシステム開発において、それをより良くするための書籍とかが蓄積して、そういうものを扱うんだったらこういう役職、ポジションがいた方がいいよねっていうところから生まれてできたような役割です。
主にやっているのは大きく言うと3つです。市場の調査とプロダクトの開発とプロダクトのデリバリーになります。その3つをさらに細分化するとまだたくさんやることがあるんですが、そこを全体的に担っていきます。なのでほとんどの事業部と連携して動いていくような役割があるので、誰からも何をやっているのかがはっきり見えづらかったりするポジションかもしれません。
私個人としては、プロダクト周りで各チームで人知れず落としそうなところを横串で動いて、拾って解決していくことも意識しています。

西村：ROXXでもagent bankとback check、今は2部門で分かれていますが、結構違いはあるんですか？

松野：先ほどの粕谷さんのお話にもあったんですけども、back checkだとPOが別にいるので、そこの役割に関しては分担しています。なので、PdMはバックログを管理する等の開発の中の部門を一部を担っていない形になります。

西村：agent bankだと、どのように役割分担をしていますか？

粕谷：agent bankだと、PdMは私と髙畠さんの2人しかいないので、今は見るドメインで分けています。ドメインというのが、agent bankというサービスは大きく採用企業様とエージェント様と言う形でお客様が両側にいるので、髙畠さんにエージェント様を見てもらったら、私は採用企業様を中心に見ていこうかな、ぐらい。
ただ、そんなに明確に分けているわけでもなく、私が開発側の優先度管理もしてたりするので、実はそんなに役割を固定的に分けていないところがあったりします。髙畠さんには求職者様への業務管理の開発も見てもらったりとかもしているので、ゆるく分けているけど、実態はそこまで明確には分かれていない感じですね。

西村：新規事業側はどうですか?

小平：新規事業側は、これがPdMだよねみたいなところは、模索中というかそんなに決まっていないというのが現状で、ベースは松野さんがおっしゃっていただいたところにはなるんですけど、今だとそんなに人が多くないので、例えば開発チーム、営業の方、マーケティングの方、などロールいくつかあったときに、そこで拾いきれないものがきたりすることが多かったりしますね。

西村：プロダクトのフェーズだったりチームの大きさによって、PdM業務としてどこまでやるかというのが変わってくるという感じですね。

小平：結構その時々で、事業とかプロダクトを前に進めるために必要なことが変わってくると思うので、それでやることが変わったりするのは今のフェーズだとすごくありますね。

開発のスケジュールの決め方について

西村：プロダクト開発のスケジュールってどうやって決めているのでしょうか。これもチームによって違うんですか？意外とみんな気にしているようで、事前質問にもありましたのでお伺いしたいです。

松野：チームによっても違いますし、内容によっても変わるかもしれないですね。

西村：もしよかったらスケジュールの決め方だったりとか、優先順位も含めて、どういう風に決めているのかというのを教えてください。

松野：スケジュールで言うと、今は基本的にPOの関家さんを中心に開発チームで決めてもらっているので、PdMチームとしてはざっくりとしたロードマップという感じで、月単位ぐらいでどんなことをやっていくのかということを決めています。
そのスケジュールに関しては、ある程度正確っぽく出せるものとそうじゃないものがあって、そうじゃないものはこれまで社内でやったことがないような機能の挑戦だったりすると、ざっくり3ヶ月ぐらいかな、くらいでしか出せなかったりします。
一方で、法改正でこれを絶対やらなきゃいけないとか、不具合があって改修しなきゃいけないみたいなものは期日を決めて頑張ってやるしかないので、そういうのが入り混じって開発のスケジュールが組まれているかなと思っています。

西村：ありがとうございます。agent bankはいかがでしょうか？

粕谷：agent bankは、デッドラインのあるタスクや職業安定法の対応だったり、内部統制上というかシステム監査上必要な比較的やらないといけないことと開発リソースの兼ね合いで半分以上は埋まってしまうみたいなところもあって、やらなければいけないものの期日の近い順にスケジュールを組みます。見積もり自体は開発チームがして、大体の目処は立っている状態なので、残りの時間に優先度の高いものや事業部の要望を差し込んでいっているような感じです。back checkに比べると今のリソース状況や事業フェーズなど割とアンコントローラブルなものが多いイメージかもしれません。

西村：新規事業は不確実性が高い形になりますか？

小平：不確実性は高いですね。
ベースは、事業として成立するんだっけ？みたいなところの検証をプロダクト開発とかもやりながら進めている感じになるので、基本的に事業としていつまでにこういう状態を目指したいよね、というのがあって、そこからの逆算とかっていうのがメインかなとは思います。

西村：それってゴールを決めましょう、みたいな話ですが、新規事業だと、ゴールがなかなか見えないときもあると思います。その時の設計って、どんな手順で考えているんですか？

小平：やるとしたら、全体としてのゴールは決まってなくても、さっき粕谷さんの話にもあった何かしらマイルストーンとしてのゴールを決めて、何故そのゴールを達成しなきゃいけないんだっけみたいなところが設定していくことのが多いかもしれないですね。
中間となるゴールを仮で決めているようなイメージです。

西村：そこにいくか、またいけるか分からないけど、まずここのマイルストーンをちゃんとやろうという話ですかね。

小平：そうですね。

自チームだけで決められない時の人の巻き込み方、進め方について

西村：結構合意プロセス的には、なかなかPdMチームだけで決められない場合もあると思います。そういうときにどういう風に人を人を巻き込んでやっているのか、もし進めるコツとかあれば教えていただけると嬉しいです。
結構難しいと思うんですが、これぐらいでやろうってみんなエイヤで決めてるのか、それとも何かフローを経て決めているのか。

小平：私は全部逆算型かもしれないです。性格的にも、できないだろうなって思ってやるのが合わないというところもあって。論理的に、これが終わらないとこれができないっていうのが整理された上じゃないと気持ち悪く感じてしまうので、それが自分の中でちゃんとクリアになるように逆算して進めるっていうのが一番大きいかもしれないですね。

西村：なるほど。お二方もそんな感じですか？逆算して考えることが多いですか？

松野：逆算というか、一つの機能のリリースのタイミングを見るときに、その次に何をやるのかが分かるのであれば、その次に続くものが実現できる最低限の品質みたいなところはなんとなく考えています。とりあえず動けばいいや、みたいなものだったら割と期限に間に合うので。あとは、そこに品質をどれだけ上乗せするかは常に考えているかもしれません。プロダクトって絶対完成しないし、後で何回も修正がかかっていくものでそこで吸収していくと思っているので、割と、最低限これでいけるしこれぐらいで余力あるから後ろに影響しないだろう、と思いながら進めています。

西村：粕谷さんも同じような考え方ですか？

粕谷：モノによりますね。本当に新機能であれば、今、松野さんがお話しされていた通りの感じです。とはいえagent bankの場合、既に稼働しているプラットフォームで、日々選考が走っているものなので、既存の機能に手を入れる場合はユーザー影響を出せないところもあったりするので、ちょっとした開発であっても割とかっちり品質まで担保して進めている印象が強いですね。

理想から逆算する方法やできるようになったきっかけについて

西村：次の質問です！
例えばトラブルがあったり想定外のことの可能性をどのように考慮してスケジュールを引くべきか、またそれができないという人に対してアドバイスをいただきたいです。
まずは松野さん、いかがでしょうか。

松野：前提として、おそらく苦手な方は多いと思います。PdMチームでも全員がそれぞれ役割を担って同じようなことをやっていく中で、未来を考えて課題やリスクを出したりとか仮説を立てるとかって結構しんどいものです。そうすると、そこに時間を使うのが億劫になるので、同じような課題を抱えているメンバーを集めて、壁打ちしながらみんなで一気にやっちゃいます。例えば、2時間とかかけて徹底的に。そうするとそれぞれが一気に走り出すので、そういう時間の使い方をしていますね。

西村：小平さんは、いかがですか？

小平：私は、これまで中嶋さんや植木さんにずっと「目の前のことはいいけど、理想は何？」というのはよく言われていました。理想を考えた上で、たぶんその理想にすぐには到達できないので、それを削ったのが直近で実現しなきゃいけないことで、恐らく未来って理想を作るためにギャップを埋めていく作業なので、理想から削ると、未来こういうふうなものが必要だよね、こうなるよね、こういうリスクがあるよね、みたいなところが自ずと考えられるようになっていくのはあるかなと思いますね。
私はそれを頭の中だけで考えているケースもあるし、ちょっと目に見えるものにするケースもあるし、全部可視化をしているわけではないですけど、意識的にはそういう考え方をしたいなっていうのは思ってやってますね。

西村：ちょっと興味本位なところもあるんですけど、理想から考えて動く、が昔はできなかったけど、なんで今それができているのか、理由ってわかりますか？

小平：実は、昔は理想なんて遠くのことなんだから考えたくないってスタンスだったんですよ。
そんなの考えてる余裕ないよっていうのがベースの考え方でありました。でも、意思決定をするにあたって、目先のことだけ考えていても、本当にこれでいいんだっけみたいなのを迷うポイントが結構あるんですよ。
将来を考えたらこうすべきなんだけどっていうのも、将来があれば決めやすいんですけど見えている範囲が目の前だけで、遠くを見ていないから目の前の意思決定これでいいんだっけって迷うケースがあって。それだとやっぱり決められないとか不安が残ったり自信がない感じになってしまうので、もうちょっと先を考えたときに何が最適かを決めるようにした、という感じですね。

西村：スケジュールも分からないですもんね。
そういう経験って粕谷さんはありますか？理想から考えていくようになれた経験や、そのきっかけでも良いのですが。

粕谷：プロダクトが1年後、2〜3年後、5年後具体的にどうなっているか、競合はどうなっているか、というのを整理するようになったきっかけは覚えていませんが、以前、お客様の要望に基づいて要件定義をして、ある担当者さんから受注をもらって納品して、その担当者の方がいる間はその機能を使ってくれていたけどいなくなると使われなくなる、みたいなことはよくあったので、売り上げは立つけど果たしてシステムとして正しかったのかみたいなところとか、誰かがすごく欲しいものも大体の場合使われなくなるんだな、本質的にそのビジネスに必要だったのかみたいなことを思うところはありました。それが仕事である限りは売上を立てるという意味ではやっていけるんですけど、本質的ではなかったんじゃないかという反省はどうしてもあったので、例えば2年後もいるんだっけといった、そういう見方をするようにはなったかもしれないですね。

西村：ありがとうございます。松野さんはいかがですか？

松野：きっかけみたいなのは思いつかなかったですね。
SIerのときはクライアントのリクエストに応じてやっていたんですが、その時からパッケージの導入をしていたので、お客様にこれをやったらこう変わりますよ、というビジョンを提案してパッケージに合わせてもらうという仕事からスタートしていたので、それを叩き込まれて自然にやっていたような気がします。

西村：ありがとうございます。

期日にどうしても間に合わない、期限が延びてしまった時のリカバリー方法について

西村：とはいえ、社会人経験のなかで自分ではなかなかコントロールが出来ないときってあると思います。そうした際、想定より期間が延びてしまった、という時もあると思うんですよね。その際のリカバリーをいかにするか、心持ちやアドバイスをご経験踏まえて教えてください。

小平さんから、いかがでしょうか。あ、もちろん徹夜っていうのは無しで（笑）、それ以外の方法でぜひ教えてください。

小平：わかりました。（笑）あるとしたら、やっぱり一人でやってもどうしようもないみたいなときに、それを相談できる環境にあるかというのは気持ち的に楽になるひとつのポイントかなと思います。
結局プロダクト開発とかチームでやっている中で、やっぱり一人が持っているタスクがめちゃくちゃ実は重いタスクで、考慮事項も後からいっぱい出てきて、見積もり通り絶対終わらない、2、3倍かかっちゃって絶対スケジュールまで終わりませんって結構あるんですよ。
でもそれって一人で頑張れば2週間かけてできるかもしれないんですけど、やっている本人的には辛いですし、それをリカバリーできるのがチームっていう単位なのかなと思うので、そこで無理だなと思ったときにすぐ頼って自分だけじゃなくてみんなで考えられる環境があるかどうかで、だいぶ気持ちの持ちようというか、やりやすさは変わってくるかなと思います。
それは私が一人でやっていた時代から、今は人も増えてチームでやるっていうのが当たり前になっているのが差分としては大きいところかなとは思いますね。

西村：ありがとうございます。粕谷さんはいかがですか？

粕谷：アンコントローラブルな状況ですよね。
トラブルの種類にもよるんですけども、もちろん事前に避けられそうなトラブルは避けておくのは前提としてやった上で絶対間に合わないって分かったら、無理なものはまず無理だと思うので、本当に間に合わせなきゃいけないものは何か、デッドラインを越えたときに何が起きるか、など、けっこう見直す余地があると思っているので、スコープを再設定するのか、あるいは期日を延ばすことができるんだったら淡々とスケジュールを引き直す感じですかね。
やっぱり私も開発チームに依頼をする立場なので、自分がコードを書けばリカバリーできるかというとそういう問題じゃないですし、チームに残業をしてお願いしますというのもやっぱり違う、となるとスコープを調整するか期日を調整するかの二択で、私が関与できるのはそれより前の時点で要件の不確実性を減らしておくとか、期日が延びそうっていうのをなるべく早い段階で検知できるようにする、ぐらいですかね。

西村：ありがとうございます！
時間もだいぶ迫ってきていまして、参加いただいている方から質問をいただこうかなと思います！ご質問ある方いらっしゃいますか？

（記事の長さもあるので、今回はお一人だけご紹介します！）

櫻井：agent bankでセールスをやっている櫻井といいます！
先ほど小平さんの仰っていた、質問を投げると要件がはっきりしてくるというところについて、その文脈の中で今非常に迷っていることがあるので質問させてください。クライアント求人企業様にいつまでにどうなってればいいかというのを質問する中で、輪郭をはっきりさせていきたいんですけど、質問が悪いのか「AとBどっちがいいですか？」の質問に対して「どっちも大事だよね、任せるよ」という形で質問が返ってきてしまうことがあります。「え！こっちが決めるの！？」みたいな。これって社内でもありがちなのかな、と。最後の最後で曖昧な回答が返ってきて要件が決まらないみたいな。曖昧さをうまく処理する技術が必要なのか、質問のテクニックで乗り越えられるのか、ぜひ教えていただきたいです！

松野：ヒアリングですよね。なぜなぜを繰り返していくんですけど、そのときに業務であったりとか、心理的なものであったりとか、その人の業務の後ろに何が続いているのか聞いたりとか、その周辺まで含めて理由を聞いていくと、ポロッと「実は、、」みたいなのが出てくるかなと思っているので、そういうのを意識しますかね。
例えば、お客様に「何で、そのKPIなんですか？」とか「何で御社はそれを求めているんですか？」とかどんどん突っ込んでいくと、理由が見えてきたり、法的な要件が隠れていたり、監査が後ろで待ち受けているだとか、大口顧客から何か依頼されているとか、そういう背景が見えると優先度とか全然見え方が変わってくるんだと思うので、そこまでグイグイと聞いていくと、良いのかなと思いますね。

櫻井：ありがとうございます。これまで自分が聞きたいことばかり聞いていたので、参考になりました。

西村：というわけでお時間になりましたので、お開きとします。最後はお三方へ拍手で終了したいと思います。ありがとうございました！

参加者の声をご紹介！

最後に、参加者した方からの感想をご紹介します。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　社内アンケートより

と、ご自身の学びになっていたり、業務を行う上での意識につながっていたりと嬉しい感想をいただいております。
これからも毎月開催予定ですので少しでも興味が湧いた方は、ぜひ参加してみてくださいね。

以上、ROXX Cafe「期限を決めて守る」回のレポートをお届けしました！
少しでもROXX Cafeの良さが伝われば良いなと思います。
ROXX Cafeいいね！と思った方はぜひスキをお願いします。
（またレポートする励みになります！笑）