はじめに みなさん、こんにちは。エンジニアの山田です。今回は Pharms 開発チームがチームビルディングの一環として行なっている「TGIF」という施策について参加している皆さんに、どのような効果があるのかなどを聞いていこうと思います。 インタビュイー紹介 新居さん 2016 年入社。ソーシャルゲーム開発会社を経て、メドレーへ入社。入社当初はジョブメドレーのプロダクト開発などを担当していたが、2020 年から Pharms で中規模施策の開発を中心に業務を行なう。 小田さん 2021 年入社。大手メーカーで病院や調剤薬局向けの IT システムの開発業務を経て、メドレー入社。Pharms では中規模施策の開発を中心に業務を行なう。 兒玉さん 2018 年入社。2021 年 4 月まで CLINICS オンライン診療のセールス部に所属。その後エンジニアに社内転職し、Pharms の開発に携わる。現在はサーバサイドの開発を中心に担当している。 新倉さん 2021 年入社。不動産テック企業でのデザイン業務を経て、メドレーへ入社。入社時から Pharms のデザイナーとして各種デザインの業務を行なう。 古川さん 2022 年に新卒入社。現在はプロダクトの改善を幅広く担当している。 Pharms というプロダクトについて 山田 : まず「TGIF」について聞いていく前に、Pharms とはどのようなプロダクトなのか教えてもらってもよいですか? 新居 : 一言で言うと、薬局の業務効率化支援システムです。 CLINICS オンライン診療 で診察を受けた患者さんや、直接来院された患者さんからの処方箋などを受けて、Pharms を通して服薬指導や、会計、服薬フォローアップなどを一貫して行なえるシステムになっています。 新居さん 山田 : ユーザーについてですが、例えば、自分が開発を担当している医療介護求人サイトの ジョブメドレー では、お仕事をお探しの求職者の方々と、求人情報を掲載いただく医院・事業所の方々が使用しているシステムなのですが、Pharms はどのような方に使われるのでしょうか? 小田 : CLINICS アプリを通して間接的に患者さんが使っていますが、大きい割合を占めるのは顧客である薬局のスタッフさん（薬剤師など）ですね。 小田さん 山田 : やはり現場の薬剤師さんが使っているサービスという性格が強いんですね。 Pharms 開発チームの TGIF という試みについて TGIF を始める前の課題感 山田 : それでは、いよいよ Pharms 開発チームで行なっている TGIF について聞いていきたいと思います。元々、この言葉はどんな経緯で付いたんですか? 小田 : 元々は英語圏で言われている “Thank God It’s Friday” というのが語源で、そのまま金曜日の夕方に開催されるものだったのでこの名前を付けています。ちょっと昔の言葉で言うと「花金」ですね。 山田 : 「1 週間が終わりだー!」っていう開放感を表わしてるんですね。どういうきっかけでこの TGIF をやっていこうと思ったんでしょうか? 小田 : 一昨年の自分の入社前のタイミングで、Pharms 立ち上げ時のメンバーが別のプロジェクトに集中することとなり、チーム体制がガラッと変わる時期がありました。それ以降、チーム内の情報がサイロ化したり、チームとしての一体感がないという課題を感じていました。この課題を解決するために 雑多に何でも話せるコミュニケーションの場 を作ろうというのが、きっかけでした。 新居 : もちろん、それまでもチームで話す機会が全く無かったわけではなく、開発計画をクォーター単位で作っているのでそのタイミングでディスカッションする場を設けていました。でも もうちょっとコミュニケーションの頻度を増やしたらより良くなりそうだよね という話があり、毎週金曜日の TGIF が誕生しました。 山田 : そういう経緯だったんですね。それまでエンジニア・デザイナーが参加する定例のような会議体はどのようなものがあったんですか? 新居 : クォーター毎のディスカッション以外だと、週一で行なわれる「プロダクト定例」だけでした。こちらは開発メンバーだけではなく、事業部のメンバーも参加してプロダクト開発全般についての共有を目的にしたものです。それ以外で定例の会議体はなく、デイリーで行われるような「朝会・夕会」も Pharms 開発チームでは行なっていませんでした。 山田 : チーム体制の変更後、新しいメンバーの加入もあり、今までのコミュニケーション量では足りなくなってしまったんですね。 新居 : はい。チームの状況が変わって行く中で、 もっと生産性を上げていきたいという思いがありました 。チームが小規模だった頃は隣の席の同僚エンジニアに相談しつつ開発をドンドン前に進めていくことができたんですが、人数が増えてくるとそうしたコミュニケーションも希薄になります。具体的には、開発をしていて設計方針・実装方針などがズレることは多々あると思うんですが、それをさっと会話して軌道修正し、開発を推進していくというのが難しくなってきていました。 TGIF の実際 山田 : では、具体的に TGIF でどのような事を話し合われるんでしょうか? 新居 : まずは今週の振り返りから始まります。前週の TGIF で Try に対して個々がどう動いていくかを決めているので、それに対して振り返りをしていきます。各自コメントを添えて何%達成したのか話していきます。 小田 : その後、今週のチーム全体の動きに対して KPT を実施します。チーム全体として良かった動きや課題などを挙げていき、内容を深ぼったり課題解決に向けて意見を交換したりしています。また、以前はチームの動きとは関係ない個人の話などが挙がってくることが多かったのですが、 チーム全体での生産性の向上ということを目的として考えた場合、それと関連のない個人の話をしても寄与しない ので、チーム全体に関わることをメインにするよう改善し今の形になってきました。 KPT が終わったら、隔週でチーム目標と Problem で挙がったことなども踏まえて各自の来週の Try を決めます。 新居 : 最後に、ちょっとしたことでも良いのでチームに共有したい「気になること」を話していきます。ここは開発に関係する・しないに関わらない話題を出しています。例えば 、Pharms のプロダクト自体や会社の組織的なこと、プルリクエストのレビューのお願いなど雑多な話題ですね。 その中で「ライブラリアップデート」についての課題や進捗などの共有もします。単純にバージョンアップして済むというものであれば良いですが、アップデートの結果、広範囲に影響があったりだとか、そもそもエラーなどで上手くアップデートできないなどがあるので、そうした困り事の共有と解決を目的としています。 山田 : 先ほどチーム目標を隔週で決めるというお話でしたが、こちらはどういう風に決めていくんですか? 小田 : KPT の内容を踏まえて、基本的には Our Essentials (以下 OE) に照らし合わせて決めていきます。そのチーム目標に対して、個人の目標をブレイクダウンして決める形にしています。 固くなりすぎない会を目指して 山田 : なるほど。 OE に合わせて目標設定していくというのは、分かりやすくて良い ですね。話は少し逸れますが、この TGIF では毎回お菓子を持ち寄って行なっているということですが、どうしてなのでしょうか? 小田 : TGIF を行なっている内に、メンバー間での意思疎通の少なさによって、チームの生産性が上がらないという課題は解決していきました。しかし、続けている内に段々と会自体が固い雰囲気になってきて、かっちりとした振り返りの場という感じになってしまいました。元々 TGIF の在り方としてはどういうものだっけという原点に立ち返ると、やはり 「気軽にコミュニケーションができる場」という点が重要 だと再認識しまして、そこからは場の雰囲気を柔らげるためにお菓子を持ち寄り始めました。 お菓子を囲んでの TGIF 山田 : 確かに固すぎると、ちょっと会の名前とそぐわない感じになってしまいますね。 TGIF 運用の秘訣 山田 : 他に TGIF を運用する上での工夫などはありますか? 新倉 : 会の性質上、話が盛り上がって時間がオーバーしがちなので「 TGIF で話す内容はチームの成長につながることに限定する」など、 効率的かつ意味のある運用 になるよう進め方の見直しと実践は日々試行錯誤しています。 新倉さん 古川 : 自分は去年の新卒入社ですので、「言ってもしょうがないかな?」というような事もあるのですが、あえてそういった事を考えずに積極的に発言するようにしています。 実際に発言したために他の方との共有もできますし、学びになるような議論に発展することも多い ので、言って良かったという場合が多いです。 古川さん 兒玉 : ささいな事でも、誰かが チームの為に動いた事に対しては積極的にお礼を言っています 。誰かがちゃんと自分のやったことを見てくれていると認識できることが、チームの雰囲気を良くし、チーム運営の好循環に繋がっているかと思います。 兒玉さん 新居 : ちゃんとチーム全員にとって意味がある時間にするということは意識しています。仮にあまり生産的な時間ではなくなったら TGIF を止めてしまっても良いと思っています。その為には 「チームのために話しをした方がよいことは必ず話す」「本音ベースで建設的に議論する」「出てきた課題は必ずクリアにして次週以降に解決を目指す」 という事を意識しています。 こうして話すとある意味当たり前の事ばかりなんですが、参加者全員がこうした点を共通認識として持っていないと、単に KPT を発表するだけの場となり会自体が形骸化していってしまいます。ですので、きちんとこの共通認識を持って臨めるようにするというのを大切にしています。 小田 : また、TGIF で話が盛り上がるのは良いことなのですが、週に一回のこの場を待たずにもっと会話を活性化する取り組みとして 週の頭に Slack のプロダクトチャンネルにテディベアがリマインダーで現れる ので、そのスレッドで話しをするようにしています。 山田 : へえー!何でテディベアなんですか? 新居 : プログラミングで自分で解決できない問題が出てきたときに、テディベアのぬいぐるみに話しかけると問題が整理されて解決できるというテディベア効果から取っています。 テディベアの リマインダーにコメントが付いている様子 山田 : なるほど、それでテディベアが出てくるんですね。 小田 : TGIF を待つまでの時間がムダだよねっていう話もあって先程の効率化の話も含めて行なっている施策です。 新倉 : これまで TGIF やテディベアが無い時は下手をすると一週間誰とも会話をしていないということもあったんですが、この取り組みをしてから 本当にコミュニケーションが増えました 。 TGIF の利点とこれからについて 山田 : ありがとうございます。既に話にも出ていますが、TGIF をやって良かった点はどういったものがあるか改めて聞かせてください。 小田 : やっぱり格段に「チームでの開発」をしているという意識が高まったことが良いことでした。それまではやはりコミュニケーションなどが不足していたのですが、今は TGIF などのおかげですぐに相談しようという感じにもなって良いチームになってきたなという感触があります。 さらにチームを良くする土壌 にするようにしていきたいです。 新居 : 1 つ目は以前よりお互いのことを知れるようになって心理的安全性が高まったこと、2 つ目はチームとしての方針や共通認識を合わせる場として機能していること、3 つ目は毎週前週からの課題を改善でき、チームや個人の成長を感じられるようになったことです。 全体的にチーム運営にプラス になっていると感じています。 新倉 : 私は TGIF が始まってから半年後にジョインしました。元々はエンジニアの皆さんだけのものだと思ってちょっと尻込みしていたところがあったのですが、蓋を開けてみるとプロダクトやチーム自体についての話が多く、 デザイナーとしても非常に学び があるものでした。全体的にはクォーター毎に目標を決めてそれに向けて動くのですが、その目標までの道のりを埋めるという意味でも、TGIF があって良かったです。 新居 : 時にはエンジニアだけにしかわからない話題などもあったりもしますが、大部分は新倉さんが話したようにプロダクトやチームの改善をいかに行なうかという話題になっているので、そこでデザイナー視点での話が聞けてエンジニアとしても大変助かります。 古川 : 自分は入ってからずっと TGIF があるのである種当たり前の存在なのですが…。チームメンバーの人となりなどが分かるのは大変助かります。また、自分とは全然違う経歴を持っているエンジニアの方などは同じ話題でも、 自分とは全然違う視点を持って話をしていたりするので、すごく勉強になっています 。チームの課題が話し合われるので、以前は自分のタスクが終わったら、「次は何をしよう」という感じになっていたんですが、TGIF のおかげで「チームがここで困っているなら自分がやろう」と客観的に分かるようになっています。また、OE は半年毎の自己評価の際にも体現できているかどうかチェックすることになるので、TGIF での目標達成度がそれに役立ちます。 兒玉 : 一番は心理的安全性が高くなったことです。エンジニアとしての働き方とセールスをしていた時の働き方が全然違うところが多かったので、1on1 で新居さんとそういった差異について聞くという機会しかなかったんですが、今は TGIF があるのでここで皆さんに聞けるようになって様々な視点でのアドバイスを頂けるようになりました。また、エンジニアとしてお勧めの書籍や勉強法など普通に聞こうとすると、 あまり機会がないような部分も気軽に聞けるようになったので、勉強の効率も良くなりました 。 山田 : みなさん、ありがとうございます。それぞれの立場ですごく有用な会なのが分かりますね。 TGIF のこれからについてもお話ください。 新居 : 先ほども少し話しましたが、形骸化してしまい惰性で行なってしまうということになるのが本当に怖いと思っています。運用することが目的になってしまい、本来の目的が達成できないと本末転倒ですし。今もやっていることですが、ちゃんとメンバー構成や状況に応じて運用をアップデートしていくということが一番大切だと思っています。 小田 : 今までエンジニアだけの会から TGIF は始まっていますが、デザイナーの新倉さんが参加してくれたのを始めとして、昨年末から企画職の方も入ってくれるようになったので、裾野の広がりを感じています。こういった立場が別々のメンバーが入ってもスムーズに目的が達成できるように TGIF のアップデートを続けていきたいですね。 新倉 : 色々な役割の人がフラットに発言できる場があるおかげで、プロダクトについて総合的な視点を持つことができたと感じています。実際に自分達が試行錯誤して出した機能が「お客様にこんな風に使われて、こんな感想をもらえた」などすぐに共有してもらえるので、開発のモチベーションにもつながる良いサイクルになっています。 Pharms 開発チームでは、どんな人と一緒に働きたいと考えている? 山田 : ありがとうございます。最後に Pharms の開発チームには、どんな方がジョインされると嬉しいですか? 小田 : いつもチーム内で話をしているのが「 顧客ファースト 」という言葉です。これは Pharms に限った話ではなくメドレー全体の話でもあるのですが、顧客や患者などサービスを使っている人達に対して提供できる価値は何かということをきちんと意識して開発ができる方です。技術や数字だけを見るわけじゃなく、その先の顧客をちゃんと考えて開発ができる人ですね。 新居 : メドレーの事業やバリューに共感があるのは大前提です。また、小田さんが話されたことに加えて、プロダクトをより良くしようと考えてるメンバーと共に、自分はこうしたいという意志も持ちつつ、ときには建設的に議論もしながらプロダクト開発を推進できる人と一緒に仕事ができると嬉しいです。大変なことも勿論ありますが、それを楽しみ、周囲を巻き込みながら技術・技術以外の部分も含め前に進めていける人が良いなと思います。 山田 : TGIF も顧客ファーストの理念から生まれたものということになりますよね。ありがとうございました! さいごに Pharms 開発チームが実践している「TGIF」というチームビルディングの方法についてインタビューしてきましたが、いかがだったでしょうか? 実際に TGIF をしている様子などを見ると、和やかな雰囲気ではありますが、全員真剣にプロダクトについて議論をしている姿が印象的でした。 こんなチームで調剤薬局や患者のためのプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。今回は Pharms 開発チームがチームビルディングの一環として行なっている「TGIF」という施策について参加している皆さんに、どのような効果があるのかなどを聞いていこうと思います。 インタビュイー紹介 新居さん 2016 年入社。ソーシャルゲーム開発会社を経て、メドレーへ入社。入社当初はジョブメドレーのプロダクト開発などを担当していたが、2020 年から Pharms で中規模施策の開発を中心に業務を行なう。 小田さん 2021 年入社。大手メーカーで病院や調剤薬局向けの IT システムの開発業務を経て、メドレー入社。Pharms では中規模施策の開発を中心に業務を行なう。 兒玉さん 2018 年入社。2021 年 4 月まで CLINICS オンライン診療のセールス部に所属。その後エンジニアに社内転職し、Pharms の開発に携わる。現在はサーバサイドの開発を中心に担当している。 新倉さん 2021 年入社。不動産テック企業でのデザイン業務を経て、メドレーへ入社。入社時から Pharms のデザイナーとして各種デザインの業務を行なう。 古川さん 2022 年に新卒入社。現在はプロダクトの改善を幅広く担当している。 Pharms というプロダクトについて 山田 : まず「TGIF」について聞いていく前に、Pharms とはどのようなプロダクトなのか教えてもらってもよいですか? 新居 : 一言で言うと、薬局の業務効率化支援システムです。 CLINICS オンライン診療 で診察を受けた患者さんや、直接来院された患者さんからの処方箋などを受けて、Pharms を通して服薬指導や、会計、服薬フォローアップなどを一貫して行なえるシステムになっています。 新居さん 山田 : ユーザーについてですが、例えば、自分が開発を担当している医療介護求人サイトの ジョブメドレー では、お仕事をお探しの求職者の方々と、求人情報を掲載いただく医院・事業所の方々が使用しているシステムなのですが、Pharms はどのような方に使われるのでしょうか? 小田 : CLINICS アプリを通して間接的に患者さんが使っていますが、大きい割合を占めるのは顧客である薬局のスタッフさん（薬剤師など）ですね。 小田さん 山田 : やはり現場の薬剤師さんが使っているサービスという性格が強いんですね。 Pharms 開発チームの TGIF という試みについて TGIF を始める前の課題感 山田 : それでは、いよいよ Pharms 開発チームで行なっている TGIF について聞いていきたいと思います。元々、この言葉はどんな経緯で付いたんですか? 小田 : 元々は英語圏で言われている “Thank God It’s Friday” というのが語源で、そのまま金曜日の夕方に開催されるものだったのでこの名前を付けています。ちょっと昔の言葉で言うと「花金」ですね。 山田 : 「1 週間が終わりだー!」っていう開放感を表わしてるんですね。どういうきっかけでこの TGIF をやっていこうと思ったんでしょうか? 小田 : 一昨年の自分の入社前のタイミングで、Pharms 立ち上げ時のメンバーが別のプロジェクトに集中することとなり、チーム体制がガラッと変わる時期がありました。それ以降、チーム内の情報がサイロ化したり、チームとしての一体感がないという課題を感じていました。この課題を解決するために 雑多に何でも話せるコミュニケーションの場 を作ろうというのが、きっかけでした。 新居 : もちろん、それまでもチームで話す機会が全く無かったわけではなく、開発計画をクォーター単位で作っているのでそのタイミングでディスカッションする場を設けていました。でも もうちょっとコミュニケーションの頻度を増やしたらより良くなりそうだよね という話があり、毎週金曜日の TGIF が誕生しました。 山田 : そういう経緯だったんですね。それまでエンジニア・デザイナーが参加する定例のような会議体はどのようなものがあったんですか? 新居 : クォーター毎のディスカッション以外だと、週一で行なわれる「プロダクト定例」だけでした。こちらは開発メンバーだけではなく、事業部のメンバーも参加してプロダクト開発全般についての共有を目的にしたものです。それ以外で定例の会議体はなく、デイリーで行われるような「朝会・夕会」も Pharms 開発チームでは行なっていませんでした。 山田 : チーム体制の変更後、新しいメンバーの加入もあり、今までのコミュニケーション量では足りなくなってしまったんですね。 新居 : はい。チームの状況が変わって行く中で、 もっと生産性を上げていきたいという思いがありました 。チームが小規模だった頃は隣の席の同僚エンジニアに相談しつつ開発をドンドン前に進めていくことができたんですが、人数が増えてくるとそうしたコミュニケーションも希薄になります。具体的には、開発をしていて設計方針・実装方針などがズレることは多々あると思うんですが、それをさっと会話して軌道修正し、開発を推進していくというのが難しくなってきていました。 TGIF の実際 山田 : では、具体的に TGIF でどのような事を話し合われるんでしょうか? 新居 : まずは今週の振り返りから始まります。前週の TGIF で Try に対して個々がどう動いていくかを決めているので、それに対して振り返りをしていきます。各自コメントを添えて何%達成したのか話していきます。 小田 : その後、今週のチーム全体の動きに対して KPT を実施します。チーム全体として良かった動きや課題などを挙げていき、内容を深ぼったり課題解決に向けて意見を交換したりしています。また、以前はチームの動きとは関係ない個人の話などが挙がってくることが多かったのですが、 チーム全体での生産性の向上ということを目的として考えた場合、それと関連のない個人の話をしても寄与しない ので、チーム全体に関わることをメインにするよう改善し今の形になってきました。 KPT が終わったら、隔週でチーム目標と Problem で挙がったことなども踏まえて各自の来週の Try を決めます。 新居 : 最後に、ちょっとしたことでも良いのでチームに共有したい「気になること」を話していきます。ここは開発に関係する・しないに関わらない話題を出しています。例えば 、Pharms のプロダクト自体や会社の組織的なこと、プルリクエストのレビューのお願いなど雑多な話題ですね。 その中で「ライブラリアップデート」についての課題や進捗などの共有もします。単純にバージョンアップして済むというものであれば良いですが、アップデートの結果、広範囲に影響があったりだとか、そもそもエラーなどで上手くアップデートできないなどがあるので、そうした困り事の共有と解決を目的としています。 山田 : 先ほどチーム目標を隔週で決めるというお話でしたが、こちらはどういう風に決めていくんですか? 小田 : KPT の内容を踏まえて、基本的には Our Essentials (以下 OE) に照らし合わせて決めていきます。そのチーム目標に対して、個人の目標をブレイクダウンして決める形にしています。 固くなりすぎない会を目指して 山田 : なるほど。 OE に合わせて目標設定していくというのは、分かりやすくて良い ですね。話は少し逸れますが、この TGIF では毎回お菓子を持ち寄って行なっているということですが、どうしてなのでしょうか? 小田 : TGIF を行なっている内に、メンバー間での意思疎通の少なさによって、チームの生産性が上がらないという課題は解決していきました。しかし、続けている内に段々と会自体が固い雰囲気になってきて、かっちりとした振り返りの場という感じになってしまいました。元々 TGIF の在り方としてはどういうものだっけという原点に立ち返ると、やはり 「気軽にコミュニケーションができる場」という点が重要 だと再認識しまして、そこからは場の雰囲気を柔らげるためにお菓子を持ち寄り始めました。 お菓子を囲んでの TGIF 山田 : 確かに固すぎると、ちょっと会の名前とそぐわない感じになってしまいますね。 TGIF 運用の秘訣 山田 : 他に TGIF を運用する上での工夫などはありますか? 新倉 : 会の性質上、話が盛り上がって時間がオーバーしがちなので「 TGIF で話す内容はチームの成長につながることに限定する」など、 効率的かつ意味のある運用 になるよう進め方の見直しと実践は日々試行錯誤しています。 新倉さん 古川 : 自分は去年の新卒入社ですので、「言ってもしょうがないかな?」というような事もあるのですが、あえてそういった事を考えずに積極的に発言するようにしています。 実際に発言したために他の方との共有もできますし、学びになるような議論に発展することも多い ので、言って良かったという場合が多いです。 古川さん 兒玉 : ささいな事でも、誰かが チームの為に動いた事に対しては積極的にお礼を言っています 。誰かがちゃんと自分のやったことを見てくれていると認識できることが、チームの雰囲気を良くし、チーム運営の好循環に繋がっているかと思います。 兒玉さん 新居 : ちゃんとチーム全員にとって意味がある時間にするということは意識しています。仮にあまり生産的な時間ではなくなったら TGIF を止めてしまっても良いと思っています。その為には 「チームのために話しをした方がよいことは必ず話す」「本音ベースで建設的に議論する」「出てきた課題は必ずクリアにして次週以降に解決を目指す」 という事を意識しています。 こうして話すとある意味当たり前の事ばかりなんですが、参加者全員がこうした点を共通認識として持っていないと、単に KPT を発表するだけの場となり会自体が形骸化していってしまいます。ですので、きちんとこの共通認識を持って臨めるようにするというのを大切にしています。 小田 : また、TGIF で話が盛り上がるのは良いことなのですが、週に一回のこの場を待たずにもっと会話を活性化する取り組みとして 週の頭に Slack のプロダクトチャンネルにテディベアがリマインダーで現れる ので、そのスレッドで話しをするようにしています。 山田 : へえー!何でテディベアなんですか? 新居 : プログラミングで自分で解決できない問題が出てきたときに、テディベアのぬいぐるみに話しかけると問題が整理されて解決できるというテディベア効果から取っています。 テディベアの リマインダーにコメントが付いている様子 山田 : なるほど、それでテディベアが出てくるんですね。 小田 : TGIF を待つまでの時間がムダだよねっていう話もあって先程の効率化の話も含めて行なっている施策です。 新倉 : これまで TGIF やテディベアが無い時は下手をすると一週間誰とも会話をしていないということもあったんですが、この取り組みをしてから 本当にコミュニケーションが増えました 。 TGIF の利点とこれからについて 山田 : ありがとうございます。既に話にも出ていますが、TGIF をやって良かった点はどういったものがあるか改めて聞かせてください。 小田 : やっぱり格段に「チームでの開発」をしているという意識が高まったことが良いことでした。それまではやはりコミュニケーションなどが不足していたのですが、今は TGIF などのおかげですぐに相談しようという感じにもなって良いチームになってきたなという感触があります。 さらにチームを良くする土壌 にするようにしていきたいです。 新居 : 1 つ目は以前よりお互いのことを知れるようになって心理的安全性が高まったこと、2 つ目はチームとしての方針や共通認識を合わせる場として機能していること、3 つ目は毎週前週からの課題を改善でき、チームや個人の成長を感じられるようになったことです。 全体的にチーム運営にプラス になっていると感じています。 新倉 : 私は TGIF が始まってから半年後にジョインしました。元々はエンジニアの皆さんだけのものだと思ってちょっと尻込みしていたところがあったのですが、蓋を開けてみるとプロダクトやチーム自体についての話が多く、 デザイナーとしても非常に学び があるものでした。全体的にはクォーター毎に目標を決めてそれに向けて動くのですが、その目標までの道のりを埋めるという意味でも、TGIF があって良かったです。 新居 : 時にはエンジニアだけにしかわからない話題などもあったりもしますが、大部分は新倉さんが話したようにプロダクトやチームの改善をいかに行なうかという話題になっているので、そこでデザイナー視点での話が聞けてエンジニアとしても大変助かります。 古川 : 自分は入ってからずっと TGIF があるのである種当たり前の存在なのですが…。チームメンバーの人となりなどが分かるのは大変助かります。また、自分とは全然違う経歴を持っているエンジニアの方などは同じ話題でも、 自分とは全然違う視点を持って話をしていたりするので、すごく勉強になっています 。チームの課題が話し合われるので、以前は自分のタスクが終わったら、「次は何をしよう」という感じになっていたんですが、TGIF のおかげで「チームがここで困っているなら自分がやろう」と客観的に分かるようになっています。また、OE は半年毎の自己評価の際にも体現できているかどうかチェックすることになるので、TGIF での目標達成度がそれに役立ちます。 兒玉 : 一番は心理的安全性が高くなったことです。エンジニアとしての働き方とセールスをしていた時の働き方が全然違うところが多かったので、1on1 で新居さんとそういった差異について聞くという機会しかなかったんですが、今は TGIF があるのでここで皆さんに聞けるようになって様々な視点でのアドバイスを頂けるようになりました。また、エンジニアとしてお勧めの書籍や勉強法など普通に聞こうとすると、 あまり機会がないような部分も気軽に聞けるようになったので、勉強の効率も良くなりました 。 山田 : みなさん、ありがとうございます。それぞれの立場ですごく有用な会なのが分かりますね。 TGIF のこれからについてもお話ください。 新居 : 先ほども少し話しましたが、形骸化してしまい惰性で行なってしまうということになるのが本当に怖いと思っています。運用することが目的になってしまい、本来の目的が達成できないと本末転倒ですし。今もやっていることですが、ちゃんとメンバー構成や状況に応じて運用をアップデートしていくということが一番大切だと思っています。 小田 : 今までエンジニアだけの会から TGIF は始まっていますが、デザイナーの新倉さんが参加してくれたのを始めとして、昨年末から企画職の方も入ってくれるようになったので、裾野の広がりを感じています。こういった立場が別々のメンバーが入ってもスムーズに目的が達成できるように TGIF のアップデートを続けていきたいですね。 新倉 : 色々な役割の人がフラットに発言できる場があるおかげで、プロダクトについて総合的な視点を持つことができたと感じています。実際に自分達が試行錯誤して出した機能が「お客様にこんな風に使われて、こんな感想をもらえた」などすぐに共有してもらえるので、開発のモチベーションにもつながる良いサイクルになっています。 Pharms 開発チームでは、どんな人と一緒に働きたいと考えている? 山田 : ありがとうございます。最後に Pharms の開発チームには、どんな方がジョインされると嬉しいですか? 小田 : いつもチーム内で話をしているのが「 顧客ファースト 」という言葉です。これは Pharms に限った話ではなくメドレー全体の話でもあるのですが、顧客や患者などサービスを使っている人達に対して提供できる価値は何かということをきちんと意識して開発ができる方です。技術や数字だけを見るわけじゃなく、その先の顧客をちゃんと考えて開発ができる人ですね。 新居 : メドレーの事業やバリューに共感があるのは大前提です。また、小田さんが話されたことに加えて、プロダクトをより良くしようと考えてるメンバーと共に、自分はこうしたいという意志も持ちつつ、ときには建設的に議論もしながらプロダクト開発を推進できる人と一緒に仕事ができると嬉しいです。大変なことも勿論ありますが、それを楽しみ、周囲を巻き込みながら技術・技術以外の部分も含め前に進めていける人が良いなと思います。 山田 : TGIF も顧客ファーストの理念から生まれたものということになりますよね。ありがとうございました! さいごに Pharms 開発チームが実践している「TGIF」というチームビルディングの方法についてインタビューしてきましたが、いかがだったでしょうか? 実際に TGIF をしている様子などを見ると、和やかな雰囲気ではありますが、全員真剣にプロダクトについて議論をしている姿が印象的でした。 こんなチームで調剤薬局や患者のためのプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。今回は Pharms 開発チームがチームビルディングの一環として行なっている「TGIF」という施策について参加している皆さんに、どのような効果があるのかなどを聞いていこうと思います。 インタビュイー紹介 新居さん 2016 年入社。ソーシャルゲーム開発会社を経て、メドレーへ入社。入社当初はジョブメドレーのプロダクト開発などを担当していたが、2020 年から Pharms で中規模施策の開発を中心に業務を行なう。 小田さん 2021 年入社。大手メーカーで病院や調剤薬局向けの IT システムの開発業務を経て、メドレー入社。Pharms では中規模施策の開発を中心に業務を行なう。 兒玉さん 2018 年入社。2021 年 4 月まで CLINICS オンライン診療のセールス部に所属。その後エンジニアに社内転職し、Pharms の開発に携わる。現在はサーバサイドの開発を中心に担当している。 新倉さん 2021 年入社。不動産テック企業でのデザイン業務を経て、メドレーへ入社。入社時から Pharms のデザイナーとして各種デザインの業務を行なう。 古川さん 2022 年に新卒入社。現在はプロダクトの改善を幅広く担当している。 Pharms というプロダクトについて 山田 : まず「TGIF」について聞いていく前に、Pharms とはどのようなプロダクトなのか教えてもらってもよいですか? 新居 : 一言で言うと、薬局の業務効率化支援システムです。 CLINICS オンライン診療 で診察を受けた患者さんや、直接来院された患者さんからの処方箋などを受けて、Pharms を通して服薬指導や、会計、服薬フォローアップなどを一貫して行なえるシステムになっています。 新居さん 山田 : ユーザーについてですが、例えば、自分が開発を担当している医療介護求人サイトの ジョブメドレー では、お仕事をお探しの求職者の方々と、求人情報を掲載いただく医院・事業所の方々が使用しているシステムなのですが、Pharms はどのような方に使われるのでしょうか? 小田 : CLINICS アプリを通して間接的に患者さんが使っていますが、大きい割合を占めるのは顧客である薬局のスタッフさん（薬剤師など）ですね。 小田さん 山田 : やはり現場の薬剤師さんが使っているサービスという性格が強いんですね。 Pharms 開発チームの TGIF という試みについて TGIF を始める前の課題感 山田 : それでは、いよいよ Pharms 開発チームで行なっている TGIF について聞いていきたいと思います。元々、この言葉はどんな経緯で付いたんですか? 小田 : 元々は英語圏で言われている “Thank God It’s Friday” というのが語源で、そのまま金曜日の夕方に開催されるものだったのでこの名前を付けています。ちょっと昔の言葉で言うと「花金」ですね。 山田 : 「1 週間が終わりだー!」っていう開放感を表わしてるんですね。どういうきっかけでこの TGIF をやっていこうと思ったんでしょうか? 小田 : 一昨年の自分の入社前のタイミングで、Pharms 立ち上げ時のメンバーが別のプロジェクトに集中することとなり、チーム体制がガラッと変わる時期がありました。それ以降、チーム内の情報がサイロ化したり、チームとしての一体感がないという課題を感じていました。この課題を解決するために 雑多に何でも話せるコミュニケーションの場 を作ろうというのが、きっかけでした。 新居 : もちろん、それまでもチームで話す機会が全く無かったわけではなく、開発計画をクォーター単位で作っているのでそのタイミングでディスカッションする場を設けていました。でも もうちょっとコミュニケーションの頻度を増やしたらより良くなりそうだよね という話があり、毎週金曜日の TGIF が誕生しました。 山田 : そういう経緯だったんですね。それまでエンジニア・デザイナーが参加する定例のような会議体はどのようなものがあったんですか? 新居 : クォーター毎のディスカッション以外だと、週一で行なわれる「プロダクト定例」だけでした。こちらは開発メンバーだけではなく、事業部のメンバーも参加してプロダクト開発全般についての共有を目的にしたものです。それ以外で定例の会議体はなく、デイリーで行われるような「朝会・夕会」も Pharms 開発チームでは行なっていませんでした。 山田 : チーム体制の変更後、新しいメンバーの加入もあり、今までのコミュニケーション量では足りなくなってしまったんですね。 新居 : はい。チームの状況が変わって行く中で、 もっと生産性を上げていきたいという思いがありました 。チームが小規模だった頃は隣の席の同僚エンジニアに相談しつつ開発をドンドン前に進めていくことができたんですが、人数が増えてくるとそうしたコミュニケーションも希薄になります。具体的には、開発をしていて設計方針・実装方針などがズレることは多々あると思うんですが、それをさっと会話して軌道修正し、開発を推進していくというのが難しくなってきていました。 TGIF の実際 山田 : では、具体的に TGIF でどのような事を話し合われるんでしょうか? 新居 : まずは今週の振り返りから始まります。前週の TGIF で Try に対して個々がどう動いていくかを決めているので、それに対して振り返りをしていきます。各自コメントを添えて何%達成したのか話していきます。 小田 : その後、今週のチーム全体の動きに対して KPT を実施します。チーム全体として良かった動きや課題などを挙げていき、内容を深ぼったり課題解決に向けて意見を交換したりしています。また、以前はチームの動きとは関係ない個人の話などが挙がってくることが多かったのですが、 チーム全体での生産性の向上ということを目的として考えた場合、それと関連のない個人の話をしても寄与しない ので、チーム全体に関わることをメインにするよう改善し今の形になってきました。 KPT が終わったら、隔週でチーム目標と Problem で挙がったことなども踏まえて各自の来週の Try を決めます。 新居 : 最後に、ちょっとしたことでも良いのでチームに共有したい「気になること」を話していきます。ここは開発に関係する・しないに関わらない話題を出しています。例えば 、Pharms のプロダクト自体や会社の組織的なこと、プルリクエストのレビューのお願いなど雑多な話題ですね。 その中で「ライブラリアップデート」についての課題や進捗などの共有もします。単純にバージョンアップして済むというものであれば良いですが、アップデートの結果、広範囲に影響があったりだとか、そもそもエラーなどで上手くアップデートできないなどがあるので、そうした困り事の共有と解決を目的としています。 山田 : 先ほどチーム目標を隔週で決めるというお話でしたが、こちらはどういう風に決めていくんですか? 小田 : KPT の内容を踏まえて、基本的には Our Essentials (以下 OE) に照らし合わせて決めていきます。そのチーム目標に対して、個人の目標をブレイクダウンして決める形にしています。 固くなりすぎない会を目指して 山田 : なるほど。 OE に合わせて目標設定していくというのは、分かりやすくて良い ですね。話は少し逸れますが、この TGIF では毎回お菓子を持ち寄って行なっているということですが、どうしてなのでしょうか? 小田 : TGIF を行なっている内に、メンバー間での意思疎通の少なさによって、チームの生産性が上がらないという課題は解決していきました。しかし、続けている内に段々と会自体が固い雰囲気になってきて、かっちりとした振り返りの場という感じになってしまいました。元々 TGIF の在り方としてはどういうものだっけという原点に立ち返ると、やはり 「気軽にコミュニケーションができる場」という点が重要 だと再認識しまして、そこからは場の雰囲気を柔らげるためにお菓子を持ち寄り始めました。 お菓子を囲んでの TGIF 山田 : 確かに固すぎると、ちょっと会の名前とそぐわない感じになってしまいますね。 TGIF 運用の秘訣 山田 : 他に TGIF を運用する上での工夫などはありますか? 新倉 : 会の性質上、話が盛り上がって時間がオーバーしがちなので「 TGIF で話す内容はチームの成長につながることに限定する」など、 効率的かつ意味のある運用 になるよう進め方の見直しと実践は日々試行錯誤しています。 新倉さん 古川 : 自分は去年の新卒入社ですので、「言ってもしょうがないかな?」というような事もあるのですが、あえてそういった事を考えずに積極的に発言するようにしています。 実際に発言したために他の方との共有もできますし、学びになるような議論に発展することも多い ので、言って良かったという場合が多いです。 古川さん 兒玉 : ささいな事でも、誰かが チームの為に動いた事に対しては積極的にお礼を言っています 。誰かがちゃんと自分のやったことを見てくれていると認識できることが、チームの雰囲気を良くし、チーム運営の好循環に繋がっているかと思います。 兒玉さん 新居 : ちゃんとチーム全員にとって意味がある時間にするということは意識しています。仮にあまり生産的な時間ではなくなったら TGIF を止めてしまっても良いと思っています。その為には 「チームのために話しをした方がよいことは必ず話す」「本音ベースで建設的に議論する」「出てきた課題は必ずクリアにして次週以降に解決を目指す」 という事を意識しています。 こうして話すとある意味当たり前の事ばかりなんですが、参加者全員がこうした点を共通認識として持っていないと、単に KPT を発表するだけの場となり会自体が形骸化していってしまいます。ですので、きちんとこの共通認識を持って臨めるようにするというのを大切にしています。 小田 : また、TGIF で話が盛り上がるのは良いことなのですが、週に一回のこの場を待たずにもっと会話を活性化する取り組みとして 週の頭に Slack のプロダクトチャンネルにテディベアがリマインダーで現れる ので、そのスレッドで話しをするようにしています。 山田 : へえー!何でテディベアなんですか? 新居 : プログラミングで自分で解決できない問題が出てきたときに、テディベアのぬいぐるみに話しかけると問題が整理されて解決できるというテディベア効果から取っています。 テディベアの リマインダーにコメントが付いている様子 山田 : なるほど、それでテディベアが出てくるんですね。 小田 : TGIF を待つまでの時間がムダだよねっていう話もあって先程の効率化の話も含めて行なっている施策です。 新倉 : これまで TGIF やテディベアが無い時は下手をすると一週間誰とも会話をしていないということもあったんですが、この取り組みをしてから 本当にコミュニケーションが増えました 。 TGIF の利点とこれからについて 山田 : ありがとうございます。既に話にも出ていますが、TGIF をやって良かった点はどういったものがあるか改めて聞かせてください。 小田 : やっぱり格段に「チームでの開発」をしているという意識が高まったことが良いことでした。それまではやはりコミュニケーションなどが不足していたのですが、今は TGIF などのおかげですぐに相談しようという感じにもなって良いチームになってきたなという感触があります。 さらにチームを良くする土壌 にするようにしていきたいです。 新居 : 1 つ目は以前よりお互いのことを知れるようになって心理的安全性が高まったこと、2 つ目はチームとしての方針や共通認識を合わせる場として機能していること、3 つ目は毎週前週からの課題を改善でき、チームや個人の成長を感じられるようになったことです。 全体的にチーム運営にプラス になっていると感じています。 新倉 : 私は TGIF が始まってから半年後にジョインしました。元々はエンジニアの皆さんだけのものだと思ってちょっと尻込みしていたところがあったのですが、蓋を開けてみるとプロダクトやチーム自体についての話が多く、 デザイナーとしても非常に学び があるものでした。全体的にはクォーター毎に目標を決めてそれに向けて動くのですが、その目標までの道のりを埋めるという意味でも、TGIF があって良かったです。 新居 : 時にはエンジニアだけにしかわからない話題などもあったりもしますが、大部分は新倉さんが話したようにプロダクトやチームの改善をいかに行なうかという話題になっているので、そこでデザイナー視点での話が聞けてエンジニアとしても大変助かります。 古川 : 自分は入ってからずっと TGIF があるのである種当たり前の存在なのですが…。チームメンバーの人となりなどが分かるのは大変助かります。また、自分とは全然違う経歴を持っているエンジニアの方などは同じ話題でも、 自分とは全然違う視点を持って話をしていたりするので、すごく勉強になっています 。チームの課題が話し合われるので、以前は自分のタスクが終わったら、「次は何をしよう」という感じになっていたんですが、TGIF のおかげで「チームがここで困っているなら自分がやろう」と客観的に分かるようになっています。また、OE は半年毎の自己評価の際にも体現できているかどうかチェックすることになるので、TGIF での目標達成度がそれに役立ちます。 兒玉 : 一番は心理的安全性が高くなったことです。エンジニアとしての働き方とセールスをしていた時の働き方が全然違うところが多かったので、1on1 で新居さんとそういった差異について聞くという機会しかなかったんですが、今は TGIF があるのでここで皆さんに聞けるようになって様々な視点でのアドバイスを頂けるようになりました。また、エンジニアとしてお勧めの書籍や勉強法など普通に聞こうとすると、 あまり機会がないような部分も気軽に聞けるようになったので、勉強の効率も良くなりました 。 山田 : みなさん、ありがとうございます。それぞれの立場ですごく有用な会なのが分かりますね。 TGIF のこれからについてもお話ください。 新居 : 先ほども少し話しましたが、形骸化してしまい惰性で行なってしまうということになるのが本当に怖いと思っています。運用することが目的になってしまい、本来の目的が達成できないと本末転倒ですし。今もやっていることですが、ちゃんとメンバー構成や状況に応じて運用をアップデートしていくということが一番大切だと思っています。 小田 : 今までエンジニアだけの会から TGIF は始まっていますが、デザイナーの新倉さんが参加してくれたのを始めとして、昨年末から企画職の方も入ってくれるようになったので、裾野の広がりを感じています。こういった立場が別々のメンバーが入ってもスムーズに目的が達成できるように TGIF のアップデートを続けていきたいですね。 新倉 : 色々な役割の人がフラットに発言できる場があるおかげで、プロダクトについて総合的な視点を持つことができたと感じています。実際に自分達が試行錯誤して出した機能が「お客様にこんな風に使われて、こんな感想をもらえた」などすぐに共有してもらえるので、開発のモチベーションにもつながる良いサイクルになっています。 Pharms 開発チームでは、どんな人と一緒に働きたいと考えている? 山田 : ありがとうございます。最後に Pharms の開発チームには、どんな方がジョインされると嬉しいですか? 小田 : いつもチーム内で話をしているのが「 顧客ファースト 」という言葉です。これは Pharms に限った話ではなくメドレー全体の話でもあるのですが、顧客や患者などサービスを使っている人達に対して提供できる価値は何かということをきちんと意識して開発ができる方です。技術や数字だけを見るわけじゃなく、その先の顧客をちゃんと考えて開発ができる人ですね。 新居 : メドレーの事業やバリューに共感があるのは大前提です。また、小田さんが話されたことに加えて、プロダクトをより良くしようと考えてるメンバーと共に、自分はこうしたいという意志も持ちつつ、ときには建設的に議論もしながらプロダクト開発を推進できる人と一緒に仕事ができると嬉しいです。大変なことも勿論ありますが、それを楽しみ、周囲を巻き込みながら技術・技術以外の部分も含め前に進めていける人が良いなと思います。 山田 : TGIF も顧客ファーストの理念から生まれたものということになりますよね。ありがとうございました! さいごに Pharms 開発チームが実践している「TGIF」というチームビルディングの方法についてインタビューしてきましたが、いかがだったでしょうか? 実際に TGIF をしている様子などを見ると、和やかな雰囲気ではありますが、全員真剣にプロダクトについて議論をしている姿が印象的でした。 こんなチームで調剤薬局や患者のためのプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。今回は Pharms 開発チームがチームビルディングの一環として行なっている「TGIF」という施策について参加している皆さんに、どのような効果があるのかなどを聞いていこうと思います。 インタビュイー紹介 新居さん 2016 年入社。ソーシャルゲーム開発会社を経て、メドレーへ入社。入社当初はジョブメドレーのプロダクト開発などを担当していたが、2020 年から Pharms で中規模施策の開発を中心に業務を行なう。 小田さん 2021 年入社。大手メーカーで病院や調剤薬局向けの IT システムの開発業務を経て、メドレー入社。Pharms では中規模施策の開発を中心に業務を行なう。 兒玉さん 2018 年入社。2021 年 4 月まで CLINICS オンライン診療のセールス部に所属。その後エンジニアに社内転職し、Pharms の開発に携わる。現在はサーバサイドの開発を中心に担当している。 新倉さん 2021 年入社。不動産テック企業でのデザイン業務を経て、メドレーへ入社。入社時から Pharms のデザイナーとして各種デザインの業務を行なう。 古川さん 2022 年に新卒入社。現在はプロダクトの改善を幅広く担当している。 Pharms というプロダクトについて 山田 : まず「TGIF」について聞いていく前に、Pharms とはどのようなプロダクトなのか教えてもらってもよいですか? 新居 : 一言で言うと、薬局の業務効率化支援システムです。 CLINICS オンライン診療 で診察を受けた患者さんや、直接来院された患者さんからの処方箋などを受けて、Pharms を通して服薬指導や、会計、服薬フォローアップなどを一貫して行なえるシステムになっています。 新居さん 山田 : ユーザーについてですが、例えば、自分が開発を担当している医療介護求人サイトの ジョブメドレー では、お仕事をお探しの求職者の方々と、求人情報を掲載いただく医院・事業所の方々が使用しているシステムなのですが、Pharms はどのような方に使われるのでしょうか? 小田 : CLINICS アプリを通して間接的に患者さんが使っていますが、大きい割合を占めるのは顧客である薬局のスタッフさん（薬剤師など）ですね。 小田さん 山田 : やはり現場の薬剤師さんが使っているサービスという性格が強いんですね。 Pharms 開発チームの TGIF という試みについて TGIF を始める前の課題感 山田 : それでは、いよいよ Pharms 開発チームで行なっている TGIF について聞いていきたいと思います。元々、この言葉はどんな経緯で付いたんですか? 小田 : 元々は英語圏で言われている “Thank God It’s Friday” というのが語源で、そのまま金曜日の夕方に開催されるものだったのでこの名前を付けています。ちょっと昔の言葉で言うと「花金」ですね。 山田 : 「1 週間が終わりだー!」っていう開放感を表わしてるんですね。どういうきっかけでこの TGIF をやっていこうと思ったんでしょうか? 小田 : 一昨年の自分の入社前のタイミングで、Pharms 立ち上げ時のメンバーが別のプロジェクトに集中することとなり、チーム体制がガラッと変わる時期がありました。それ以降、チーム内の情報がサイロ化したり、チームとしての一体感がないという課題を感じていました。この課題を解決するために 雑多に何でも話せるコミュニケーションの場 を作ろうというのが、きっかけでした。 新居 : もちろん、それまでもチームで話す機会が全く無かったわけではなく、開発計画をクォーター単位で作っているのでそのタイミングでディスカッションする場を設けていました。でも もうちょっとコミュニケーションの頻度を増やしたらより良くなりそうだよね という話があり、毎週金曜日の TGIF が誕生しました。 山田 : そういう経緯だったんですね。それまでエンジニア・デザイナーが参加する定例のような会議体はどのようなものがあったんですか? 新居 : クォーター毎のディスカッション以外だと、週一で行なわれる「プロダクト定例」だけでした。こちらは開発メンバーだけではなく、事業部のメンバーも参加してプロダクト開発全般についての共有を目的にしたものです。それ以外で定例の会議体はなく、デイリーで行われるような「朝会・夕会」も Pharms 開発チームでは行なっていませんでした。 山田 : チーム体制の変更後、新しいメンバーの加入もあり、今までのコミュニケーション量では足りなくなってしまったんですね。 新居 : はい。チームの状況が変わって行く中で、 もっと生産性を上げていきたいという思いがありました 。チームが小規模だった頃は隣の席の同僚エンジニアに相談しつつ開発をドンドン前に進めていくことができたんですが、人数が増えてくるとそうしたコミュニケーションも希薄になります。具体的には、開発をしていて設計方針・実装方針などがズレることは多々あると思うんですが、それをさっと会話して軌道修正し、開発を推進していくというのが難しくなってきていました。 TGIF の実際 山田 : では、具体的に TGIF でどのような事を話し合われるんでしょうか? 新居 : まずは今週の振り返りから始まります。前週の TGIF で Try に対して個々がどう動いていくかを決めているので、それに対して振り返りをしていきます。各自コメントを添えて何%達成したのか話していきます。 小田 : その後、今週のチーム全体の動きに対して KPT を実施します。チーム全体として良かった動きや課題などを挙げていき、内容を深ぼったり課題解決に向けて意見を交換したりしています。また、以前はチームの動きとは関係ない個人の話などが挙がってくることが多かったのですが、 チーム全体での生産性の向上ということを目的として考えた場合、それと関連のない個人の話をしても寄与しない ので、チーム全体に関わることをメインにするよう改善し今の形になってきました。 KPT が終わったら、隔週でチーム目標と Problem で挙がったことなども踏まえて各自の来週の Try を決めます。 新居 : 最後に、ちょっとしたことでも良いのでチームに共有したい「気になること」を話していきます。ここは開発に関係する・しないに関わらない話題を出しています。例えば 、Pharms のプロダクト自体や会社の組織的なこと、プルリクエストのレビューのお願いなど雑多な話題ですね。 その中で「ライブラリアップデート」についての課題や進捗などの共有もします。単純にバージョンアップして済むというものであれば良いですが、アップデートの結果、広範囲に影響があったりだとか、そもそもエラーなどで上手くアップデートできないなどがあるので、そうした困り事の共有と解決を目的としています。 山田 : 先ほどチーム目標を隔週で決めるというお話でしたが、こちらはどういう風に決めていくんですか? 小田 : KPT の内容を踏まえて、基本的には Our Essentials (以下 OE) に照らし合わせて決めていきます。そのチーム目標に対して、個人の目標をブレイクダウンして決める形にしています。 固くなりすぎない会を目指して 山田 : なるほど。 OE に合わせて目標設定していくというのは、分かりやすくて良い ですね。話は少し逸れますが、この TGIF では毎回お菓子を持ち寄って行なっているということですが、どうしてなのでしょうか? 小田 : TGIF を行なっている内に、メンバー間での意思疎通の少なさによって、チームの生産性が上がらないという課題は解決していきました。しかし、続けている内に段々と会自体が固い雰囲気になってきて、かっちりとした振り返りの場という感じになってしまいました。元々 TGIF の在り方としてはどういうものだっけという原点に立ち返ると、やはり 「気軽にコミュニケーションができる場」という点が重要 だと再認識しまして、そこからは場の雰囲気を柔らげるためにお菓子を持ち寄り始めました。 お菓子を囲んでの TGIF 山田 : 確かに固すぎると、ちょっと会の名前とそぐわない感じになってしまいますね。 TGIF 運用の秘訣 山田 : 他に TGIF を運用する上での工夫などはありますか? 新倉 : 会の性質上、話が盛り上がって時間がオーバーしがちなので「 TGIF で話す内容はチームの成長につながることに限定する」など、 効率的かつ意味のある運用 になるよう進め方の見直しと実践は日々試行錯誤しています。 新倉さん 古川 : 自分は去年の新卒入社ですので、「言ってもしょうがないかな?」というような事もあるのですが、あえてそういった事を考えずに積極的に発言するようにしています。 実際に発言したために他の方との共有もできますし、学びになるような議論に発展することも多い ので、言って良かったという場合が多いです。 古川さん 兒玉 : ささいな事でも、誰かが チームの為に動いた事に対しては積極的にお礼を言っています 。誰かがちゃんと自分のやったことを見てくれていると認識できることが、チームの雰囲気を良くし、チーム運営の好循環に繋がっているかと思います。 兒玉さん 新居 : ちゃんとチーム全員にとって意味がある時間にするということは意識しています。仮にあまり生産的な時間ではなくなったら TGIF を止めてしまっても良いと思っています。その為には 「チームのために話しをした方がよいことは必ず話す」「本音ベースで建設的に議論する」「出てきた課題は必ずクリアにして次週以降に解決を目指す」 という事を意識しています。 こうして話すとある意味当たり前の事ばかりなんですが、参加者全員がこうした点を共通認識として持っていないと、単に KPT を発表するだけの場となり会自体が形骸化していってしまいます。ですので、きちんとこの共通認識を持って臨めるようにするというのを大切にしています。 小田 : また、TGIF で話が盛り上がるのは良いことなのですが、週に一回のこの場を待たずにもっと会話を活性化する取り組みとして 週の頭に Slack のプロダクトチャンネルにテディベアがリマインダーで現れる ので、そのスレッドで話しをするようにしています。 山田 : へえー!何でテディベアなんですか? 新居 : プログラミングで自分で解決できない問題が出てきたときに、テディベアのぬいぐるみに話しかけると問題が整理されて解決できるというテディベア効果から取っています。 テディベアの リマインダーにコメントが付いている様子 山田 : なるほど、それでテディベアが出てくるんですね。 小田 : TGIF を待つまでの時間がムダだよねっていう話もあって先程の効率化の話も含めて行なっている施策です。 新倉 : これまで TGIF やテディベアが無い時は下手をすると一週間誰とも会話をしていないということもあったんですが、この取り組みをしてから 本当にコミュニケーションが増えました 。 TGIF の利点とこれからについて 山田 : ありがとうございます。既に話にも出ていますが、TGIF をやって良かった点はどういったものがあるか改めて聞かせてください。 小田 : やっぱり格段に「チームでの開発」をしているという意識が高まったことが良いことでした。それまではやはりコミュニケーションなどが不足していたのですが、今は TGIF などのおかげですぐに相談しようという感じにもなって良いチームになってきたなという感触があります。 さらにチームを良くする土壌 にするようにしていきたいです。 新居 : 1 つ目は以前よりお互いのことを知れるようになって心理的安全性が高まったこと、2 つ目はチームとしての方針や共通認識を合わせる場として機能していること、3 つ目は毎週前週からの課題を改善でき、チームや個人の成長を感じられるようになったことです。 全体的にチーム運営にプラス になっていると感じています。 新倉 : 私は TGIF が始まってから半年後にジョインしました。元々はエンジニアの皆さんだけのものだと思ってちょっと尻込みしていたところがあったのですが、蓋を開けてみるとプロダクトやチーム自体についての話が多く、 デザイナーとしても非常に学び があるものでした。全体的にはクォーター毎に目標を決めてそれに向けて動くのですが、その目標までの道のりを埋めるという意味でも、TGIF があって良かったです。 新居 : 時にはエンジニアだけにしかわからない話題などもあったりもしますが、大部分は新倉さんが話したようにプロダクトやチームの改善をいかに行なうかという話題になっているので、そこでデザイナー視点での話が聞けてエンジニアとしても大変助かります。 古川 : 自分は入ってからずっと TGIF があるのである種当たり前の存在なのですが…。チームメンバーの人となりなどが分かるのは大変助かります。また、自分とは全然違う経歴を持っているエンジニアの方などは同じ話題でも、 自分とは全然違う視点を持って話をしていたりするので、すごく勉強になっています 。チームの課題が話し合われるので、以前は自分のタスクが終わったら、「次は何をしよう」という感じになっていたんですが、TGIF のおかげで「チームがここで困っているなら自分がやろう」と客観的に分かるようになっています。また、OE は半年毎の自己評価の際にも体現できているかどうかチェックすることになるので、TGIF での目標達成度がそれに役立ちます。 兒玉 : 一番は心理的安全性が高くなったことです。エンジニアとしての働き方とセールスをしていた時の働き方が全然違うところが多かったので、1on1 で新居さんとそういった差異について聞くという機会しかなかったんですが、今は TGIF があるのでここで皆さんに聞けるようになって様々な視点でのアドバイスを頂けるようになりました。また、エンジニアとしてお勧めの書籍や勉強法など普通に聞こうとすると、 あまり機会がないような部分も気軽に聞けるようになったので、勉強の効率も良くなりました 。 山田 : みなさん、ありがとうございます。それぞれの立場ですごく有用な会なのが分かりますね。 TGIF のこれからについてもお話ください。 新居 : 先ほども少し話しましたが、形骸化してしまい惰性で行なってしまうということになるのが本当に怖いと思っています。運用することが目的になってしまい、本来の目的が達成できないと本末転倒ですし。今もやっていることですが、ちゃんとメンバー構成や状況に応じて運用をアップデートしていくということが一番大切だと思っています。 小田 : 今までエンジニアだけの会から TGIF は始まっていますが、デザイナーの新倉さんが参加してくれたのを始めとして、昨年末から企画職の方も入ってくれるようになったので、裾野の広がりを感じています。こういった立場が別々のメンバーが入ってもスムーズに目的が達成できるように TGIF のアップデートを続けていきたいですね。 新倉 : 色々な役割の人がフラットに発言できる場があるおかげで、プロダクトについて総合的な視点を持つことができたと感じています。実際に自分達が試行錯誤して出した機能が「お客様にこんな風に使われて、こんな感想をもらえた」などすぐに共有してもらえるので、開発のモチベーションにもつながる良いサイクルになっています。 Pharms 開発チームでは、どんな人と一緒に働きたいと考えている? 山田 : ありがとうございます。最後に Pharms の開発チームには、どんな方がジョインされると嬉しいですか? 小田 : いつもチーム内で話をしているのが「 顧客ファースト 」という言葉です。これは Pharms に限った話ではなくメドレー全体の話でもあるのですが、顧客や患者などサービスを使っている人達に対して提供できる価値は何かということをきちんと意識して開発ができる方です。技術や数字だけを見るわけじゃなく、その先の顧客をちゃんと考えて開発ができる人ですね。 新居 : メドレーの事業やバリューに共感があるのは大前提です。また、小田さんが話されたことに加えて、プロダクトをより良くしようと考えてるメンバーと共に、自分はこうしたいという意志も持ちつつ、ときには建設的に議論もしながらプロダクト開発を推進できる人と一緒に仕事ができると嬉しいです。大変なことも勿論ありますが、それを楽しみ、周囲を巻き込みながら技術・技術以外の部分も含め前に進めていける人が良いなと思います。 山田 : TGIF も顧客ファーストの理念から生まれたものということになりますよね。ありがとうございました! さいごに Pharms 開発チームが実践している「TGIF」というチームビルディングの方法についてインタビューしてきましたが、いかがだったでしょうか? 実際に TGIF をしている様子などを見ると、和やかな雰囲気ではありますが、全員真剣にプロダクトについて議論をしている姿が印象的でした。 こんなチームで調剤薬局や患者のためのプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。今回は Pharms 開発チームがチームビルディングの一環として行なっている「TGIF」という施策について参加している皆さんに、どのような効果があるのかなどを聞いていこうと思います。 インタビュイー紹介 新居さん 2016 年入社。ソーシャルゲーム開発会社を経て、メドレーへ入社。入社当初はジョブメドレーのプロダクト開発などを担当していたが、2020 年から Pharms で中規模施策の開発を中心に業務を行なう。 小田さん 2021 年入社。大手メーカーで病院や調剤薬局向けの IT システムの開発業務を経て、メドレー入社。Pharms では中規模施策の開発を中心に業務を行なう。 兒玉さん 2018 年入社。2021 年 4 月まで CLINICS オンライン診療のセールス部に所属。その後エンジニアに社内転職し、Pharms の開発に携わる。現在はサーバサイドの開発を中心に担当している。 新倉さん 2021 年入社。不動産テック企業でのデザイン業務を経て、メドレーへ入社。入社時から Pharms のデザイナーとして各種デザインの業務を行なう。 古川さん 2022 年に新卒入社。現在はプロダクトの改善を幅広く担当している。 Pharms というプロダクトについて 山田 : まず「TGIF」について聞いていく前に、Pharms とはどのようなプロダクトなのか教えてもらってもよいですか? 新居 : 一言で言うと、薬局の業務効率化支援システムです。 CLINICS オンライン診療 で診察を受けた患者さんや、直接来院された患者さんからの処方箋などを受けて、Pharms を通して服薬指導や、会計、服薬フォローアップなどを一貫して行なえるシステムになっています。 新居さん 山田 : ユーザーについてですが、例えば、自分が開発を担当している医療介護求人サイトの ジョブメドレー では、お仕事をお探しの求職者の方々と、求人情報を掲載いただく医院・事業所の方々が使用しているシステムなのですが、Pharms はどのような方に使われるのでしょうか? 小田 : CLINICS アプリを通して間接的に患者さんが使っていますが、大きい割合を占めるのは顧客である薬局のスタッフさん（薬剤師など）ですね。 小田さん 山田 : やはり現場の薬剤師さんが使っているサービスという性格が強いんですね。 Pharms 開発チームの TGIF という試みについて TGIF を始める前の課題感 山田 : それでは、いよいよ Pharms 開発チームで行なっている TGIF について聞いていきたいと思います。元々、この言葉はどんな経緯で付いたんですか? 小田 : 元々は英語圏で言われている “Thank God It’s Friday” というのが語源で、そのまま金曜日の夕方に開催されるものだったのでこの名前を付けています。ちょっと昔の言葉で言うと「花金」ですね。 山田 : 「1 週間が終わりだー!」っていう開放感を表わしてるんですね。どういうきっかけでこの TGIF をやっていこうと思ったんでしょうか? 小田 : 一昨年の自分の入社前のタイミングで、Pharms 立ち上げ時のメンバーが別のプロジェクトに集中することとなり、チーム体制がガラッと変わる時期がありました。それ以降、チーム内の情報がサイロ化したり、チームとしての一体感がないという課題を感じていました。この課題を解決するために 雑多に何でも話せるコミュニケーションの場 を作ろうというのが、きっかけでした。 新居 : もちろん、それまでもチームで話す機会が全く無かったわけではなく、開発計画をクォーター単位で作っているのでそのタイミングでディスカッションする場を設けていました。でも もうちょっとコミュニケーションの頻度を増やしたらより良くなりそうだよね という話があり、毎週金曜日の TGIF が誕生しました。 山田 : そういう経緯だったんですね。それまでエンジニア・デザイナーが参加する定例のような会議体はどのようなものがあったんですか? 新居 : クォーター毎のディスカッション以外だと、週一で行なわれる「プロダクト定例」だけでした。こちらは開発メンバーだけではなく、事業部のメンバーも参加してプロダクト開発全般についての共有を目的にしたものです。それ以外で定例の会議体はなく、デイリーで行われるような「朝会・夕会」も Pharms 開発チームでは行なっていませんでした。 山田 : チーム体制の変更後、新しいメンバーの加入もあり、今までのコミュニケーション量では足りなくなってしまったんですね。 新居 : はい。チームの状況が変わって行く中で、 もっと生産性を上げていきたいという思いがありました 。チームが小規模だった頃は隣の席の同僚エンジニアに相談しつつ開発をドンドン前に進めていくことができたんですが、人数が増えてくるとそうしたコミュニケーションも希薄になります。具体的には、開発をしていて設計方針・実装方針などがズレることは多々あると思うんですが、それをさっと会話して軌道修正し、開発を推進していくというのが難しくなってきていました。 TGIF の実際 山田 : では、具体的に TGIF でどのような事を話し合われるんでしょうか? 新居 : まずは今週の振り返りから始まります。前週の TGIF で Try に対して個々がどう動いていくかを決めているので、それに対して振り返りをしていきます。各自コメントを添えて何%達成したのか話していきます。 小田 : その後、今週のチーム全体の動きに対して KPT を実施します。チーム全体として良かった動きや課題などを挙げていき、内容を深ぼったり課題解決に向けて意見を交換したりしています。また、以前はチームの動きとは関係ない個人の話などが挙がってくることが多かったのですが、 チーム全体での生産性の向上ということを目的として考えた場合、それと関連のない個人の話をしても寄与しない ので、チーム全体に関わることをメインにするよう改善し今の形になってきました。 KPT が終わったら、隔週でチーム目標と Problem で挙がったことなども踏まえて各自の来週の Try を決めます。 新居 : 最後に、ちょっとしたことでも良いのでチームに共有したい「気になること」を話していきます。ここは開発に関係する・しないに関わらない話題を出しています。例えば 、Pharms のプロダクト自体や会社の組織的なこと、プルリクエストのレビューのお願いなど雑多な話題ですね。 その中で「ライブラリアップデート」についての課題や進捗などの共有もします。単純にバージョンアップして済むというものであれば良いですが、アップデートの結果、広範囲に影響があったりだとか、そもそもエラーなどで上手くアップデートできないなどがあるので、そうした困り事の共有と解決を目的としています。 山田 : 先ほどチーム目標を隔週で決めるというお話でしたが、こちらはどういう風に決めていくんですか? 小田 : KPT の内容を踏まえて、基本的には Our Essentials (以下 OE) に照らし合わせて決めていきます。そのチーム目標に対して、個人の目標をブレイクダウンして決める形にしています。 固くなりすぎない会を目指して 山田 : なるほど。 OE に合わせて目標設定していくというのは、分かりやすくて良い ですね。話は少し逸れますが、この TGIF では毎回お菓子を持ち寄って行なっているということですが、どうしてなのでしょうか? 小田 : TGIF を行なっている内に、メンバー間での意思疎通の少なさによって、チームの生産性が上がらないという課題は解決していきました。しかし、続けている内に段々と会自体が固い雰囲気になってきて、かっちりとした振り返りの場という感じになってしまいました。元々 TGIF の在り方としてはどういうものだっけという原点に立ち返ると、やはり 「気軽にコミュニケーションができる場」という点が重要 だと再認識しまして、そこからは場の雰囲気を柔らげるためにお菓子を持ち寄り始めました。 お菓子を囲んでの TGIF 山田 : 確かに固すぎると、ちょっと会の名前とそぐわない感じになってしまいますね。 TGIF 運用の秘訣 山田 : 他に TGIF を運用する上での工夫などはありますか? 新倉 : 会の性質上、話が盛り上がって時間がオーバーしがちなので「 TGIF で話す内容はチームの成長につながることに限定する」など、 効率的かつ意味のある運用 になるよう進め方の見直しと実践は日々試行錯誤しています。 新倉さん 古川 : 自分は去年の新卒入社ですので、「言ってもしょうがないかな?」というような事もあるのですが、あえてそういった事を考えずに積極的に発言するようにしています。 実際に発言したために他の方との共有もできますし、学びになるような議論に発展することも多い ので、言って良かったという場合が多いです。 古川さん 兒玉 : ささいな事でも、誰かが チームの為に動いた事に対しては積極的にお礼を言っています 。誰かがちゃんと自分のやったことを見てくれていると認識できることが、チームの雰囲気を良くし、チーム運営の好循環に繋がっているかと思います。 兒玉さん 新居 : ちゃんとチーム全員にとって意味がある時間にするということは意識しています。仮にあまり生産的な時間ではなくなったら TGIF を止めてしまっても良いと思っています。その為には 「チームのために話しをした方がよいことは必ず話す」「本音ベースで建設的に議論する」「出てきた課題は必ずクリアにして次週以降に解決を目指す」 という事を意識しています。 こうして話すとある意味当たり前の事ばかりなんですが、参加者全員がこうした点を共通認識として持っていないと、単に KPT を発表するだけの場となり会自体が形骸化していってしまいます。ですので、きちんとこの共通認識を持って臨めるようにするというのを大切にしています。 小田 : また、TGIF で話が盛り上がるのは良いことなのですが、週に一回のこの場を待たずにもっと会話を活性化する取り組みとして 週の頭に Slack のプロダクトチャンネルにテディベアがリマインダーで現れる ので、そのスレッドで話しをするようにしています。 山田 : へえー!何でテディベアなんですか? 新居 : プログラミングで自分で解決できない問題が出てきたときに、テディベアのぬいぐるみに話しかけると問題が整理されて解決できるというテディベア効果から取っています。 テディベアの リマインダーにコメントが付いている様子 山田 : なるほど、それでテディベアが出てくるんですね。 小田 : TGIF を待つまでの時間がムダだよねっていう話もあって先程の効率化の話も含めて行なっている施策です。 新倉 : これまで TGIF やテディベアが無い時は下手をすると一週間誰とも会話をしていないということもあったんですが、この取り組みをしてから 本当にコミュニケーションが増えました 。 TGIF の利点とこれからについて 山田 : ありがとうございます。既に話にも出ていますが、TGIF をやって良かった点はどういったものがあるか改めて聞かせてください。 小田 : やっぱり格段に「チームでの開発」をしているという意識が高まったことが良いことでした。それまではやはりコミュニケーションなどが不足していたのですが、今は TGIF などのおかげですぐに相談しようという感じにもなって良いチームになってきたなという感触があります。 さらにチームを良くする土壌 にするようにしていきたいです。 新居 : 1 つ目は以前よりお互いのことを知れるようになって心理的安全性が高まったこと、2 つ目はチームとしての方針や共通認識を合わせる場として機能していること、3 つ目は毎週前週からの課題を改善でき、チームや個人の成長を感じられるようになったことです。 全体的にチーム運営にプラス になっていると感じています。 新倉 : 私は TGIF が始まってから半年後にジョインしました。元々はエンジニアの皆さんだけのものだと思ってちょっと尻込みしていたところがあったのですが、蓋を開けてみるとプロダクトやチーム自体についての話が多く、 デザイナーとしても非常に学び があるものでした。全体的にはクォーター毎に目標を決めてそれに向けて動くのですが、その目標までの道のりを埋めるという意味でも、TGIF があって良かったです。 新居 : 時にはエンジニアだけにしかわからない話題などもあったりもしますが、大部分は新倉さんが話したようにプロダクトやチームの改善をいかに行なうかという話題になっているので、そこでデザイナー視点での話が聞けてエンジニアとしても大変助かります。 古川 : 自分は入ってからずっと TGIF があるのである種当たり前の存在なのですが…。チームメンバーの人となりなどが分かるのは大変助かります。また、自分とは全然違う経歴を持っているエンジニアの方などは同じ話題でも、 自分とは全然違う視点を持って話をしていたりするので、すごく勉強になっています 。チームの課題が話し合われるので、以前は自分のタスクが終わったら、「次は何をしよう」という感じになっていたんですが、TGIF のおかげで「チームがここで困っているなら自分がやろう」と客観的に分かるようになっています。また、OE は半年毎の自己評価の際にも体現できているかどうかチェックすることになるので、TGIF での目標達成度がそれに役立ちます。 兒玉 : 一番は心理的安全性が高くなったことです。エンジニアとしての働き方とセールスをしていた時の働き方が全然違うところが多かったので、1on1 で新居さんとそういった差異について聞くという機会しかなかったんですが、今は TGIF があるのでここで皆さんに聞けるようになって様々な視点でのアドバイスを頂けるようになりました。また、エンジニアとしてお勧めの書籍や勉強法など普通に聞こうとすると、 あまり機会がないような部分も気軽に聞けるようになったので、勉強の効率も良くなりました 。 山田 : みなさん、ありがとうございます。それぞれの立場ですごく有用な会なのが分かりますね。 TGIF のこれからについてもお話ください。 新居 : 先ほども少し話しましたが、形骸化してしまい惰性で行なってしまうということになるのが本当に怖いと思っています。運用することが目的になってしまい、本来の目的が達成できないと本末転倒ですし。今もやっていることですが、ちゃんとメンバー構成や状況に応じて運用をアップデートしていくということが一番大切だと思っています。 小田 : 今までエンジニアだけの会から TGIF は始まっていますが、デザイナーの新倉さんが参加してくれたのを始めとして、昨年末から企画職の方も入ってくれるようになったので、裾野の広がりを感じています。こういった立場が別々のメンバーが入ってもスムーズに目的が達成できるように TGIF のアップデートを続けていきたいですね。 新倉 : 色々な役割の人がフラットに発言できる場があるおかげで、プロダクトについて総合的な視点を持つことができたと感じています。実際に自分達が試行錯誤して出した機能が「お客様にこんな風に使われて、こんな感想をもらえた」などすぐに共有してもらえるので、開発のモチベーションにもつながる良いサイクルになっています。 Pharms 開発チームでは、どんな人と一緒に働きたいと考えている? 山田 : ありがとうございます。最後に Pharms の開発チームには、どんな方がジョインされると嬉しいですか? 小田 : いつもチーム内で話をしているのが「 顧客ファースト 」という言葉です。これは Pharms に限った話ではなくメドレー全体の話でもあるのですが、顧客や患者などサービスを使っている人達に対して提供できる価値は何かということをきちんと意識して開発ができる方です。技術や数字だけを見るわけじゃなく、その先の顧客をちゃんと考えて開発ができる人ですね。 新居 : メドレーの事業やバリューに共感があるのは大前提です。また、小田さんが話されたことに加えて、プロダクトをより良くしようと考えてるメンバーと共に、自分はこうしたいという意志も持ちつつ、ときには建設的に議論もしながらプロダクト開発を推進できる人と一緒に仕事ができると嬉しいです。大変なことも勿論ありますが、それを楽しみ、周囲を巻き込みながら技術・技術以外の部分も含め前に進めていける人が良いなと思います。 山田 : TGIF も顧客ファーストの理念から生まれたものということになりますよね。ありがとうございました! さいごに Pharms 開発チームが実践している「TGIF」というチームビルディングの方法についてインタビューしてきましたが、いかがだったでしょうか? 実際に TGIF をしている様子などを見ると、和やかな雰囲気ではありますが、全員真剣にプロダクトについて議論をしている姿が印象的でした。 こんなチームで調剤薬局や患者のためのプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。今回は Pharms 開発チームがチームビルディングの一環として行なっている「TGIF」という施策について参加している皆さんに、どのような効果があるのかなどを聞いていこうと思います。 インタビュイー紹介 新居さん 2016 年入社。ソーシャルゲーム開発会社を経て、メドレーへ入社。入社当初はジョブメドレーのプロダクト開発などを担当していたが、2020 年から Pharms で中規模施策の開発を中心に業務を行なう。 小田さん 2021 年入社。大手メーカーで病院や調剤薬局向けの IT システムの開発業務を経て、メドレー入社。Pharms では中規模施策の開発を中心に業務を行なう。 兒玉さん 2018 年入社。2021 年 4 月まで CLINICS オンライン診療のセールス部に所属。その後エンジニアに社内転職し、Pharms の開発に携わる。現在はサーバサイドの開発を中心に担当している。 新倉さん 2021 年入社。不動産テック企業でのデザイン業務を経て、メドレーへ入社。入社時から Pharms のデザイナーとして各種デザインの業務を行なう。 古川さん 2022 年に新卒入社。現在はプロダクトの改善を幅広く担当している。 Pharms というプロダクトについて 山田 : まず「TGIF」について聞いていく前に、Pharms とはどのようなプロダクトなのか教えてもらってもよいですか? 新居 : 一言で言うと、薬局の業務効率化支援システムです。 CLINICS オンライン診療 で診察を受けた患者さんや、直接来院された患者さんからの処方箋などを受けて、Pharms を通して服薬指導や、会計、服薬フォローアップなどを一貫して行なえるシステムになっています。 新居さん 山田 : ユーザーについてですが、例えば、自分が開発を担当している医療介護求人サイトの ジョブメドレー では、お仕事をお探しの求職者の方々と、求人情報を掲載いただく医院・事業所の方々が使用しているシステムなのですが、Pharms はどのような方に使われるのでしょうか? 小田 : CLINICS アプリを通して間接的に患者さんが使っていますが、大きい割合を占めるのは顧客である薬局のスタッフさん（薬剤師など）ですね。 小田さん 山田 : やはり現場の薬剤師さんが使っているサービスという性格が強いんですね。 Pharms 開発チームの TGIF という試みについて TGIF を始める前の課題感 山田 : それでは、いよいよ Pharms 開発チームで行なっている TGIF について聞いていきたいと思います。元々、この言葉はどんな経緯で付いたんですか? 小田 : 元々は英語圏で言われている “Thank God It’s Friday” というのが語源で、そのまま金曜日の夕方に開催されるものだったのでこの名前を付けています。ちょっと昔の言葉で言うと「花金」ですね。 山田 : 「1 週間が終わりだー!」っていう開放感を表わしてるんですね。どういうきっかけでこの TGIF をやっていこうと思ったんでしょうか? 小田 : 一昨年の自分の入社前のタイミングで、Pharms 立ち上げ時のメンバーが別のプロジェクトに集中することとなり、チーム体制がガラッと変わる時期がありました。それ以降、チーム内の情報がサイロ化したり、チームとしての一体感がないという課題を感じていました。この課題を解決するために 雑多に何でも話せるコミュニケーションの場 を作ろうというのが、きっかけでした。 新居 : もちろん、それまでもチームで話す機会が全く無かったわけではなく、開発計画をクォーター単位で作っているのでそのタイミングでディスカッションする場を設けていました。でも もうちょっとコミュニケーションの頻度を増やしたらより良くなりそうだよね という話があり、毎週金曜日の TGIF が誕生しました。 山田 : そういう経緯だったんですね。それまでエンジニア・デザイナーが参加する定例のような会議体はどのようなものがあったんですか? 新居 : クォーター毎のディスカッション以外だと、週一で行なわれる「プロダクト定例」だけでした。こちらは開発メンバーだけではなく、事業部のメンバーも参加してプロダクト開発全般についての共有を目的にしたものです。それ以外で定例の会議体はなく、デイリーで行われるような「朝会・夕会」も Pharms 開発チームでは行なっていませんでした。 山田 : チーム体制の変更後、新しいメンバーの加入もあり、今までのコミュニケーション量では足りなくなってしまったんですね。 新居 : はい。チームの状況が変わって行く中で、 もっと生産性を上げていきたいという思いがありました 。チームが小規模だった頃は隣の席の同僚エンジニアに相談しつつ開発をドンドン前に進めていくことができたんですが、人数が増えてくるとそうしたコミュニケーションも希薄になります。具体的には、開発をしていて設計方針・実装方針などがズレることは多々あると思うんですが、それをさっと会話して軌道修正し、開発を推進していくというのが難しくなってきていました。 TGIF の実際 山田 : では、具体的に TGIF でどのような事を話し合われるんでしょうか? 新居 : まずは今週の振り返りから始まります。前週の TGIF で Try に対して個々がどう動いていくかを決めているので、それに対して振り返りをしていきます。各自コメントを添えて何%達成したのか話していきます。 小田 : その後、今週のチーム全体の動きに対して KPT を実施します。チーム全体として良かった動きや課題などを挙げていき、内容を深ぼったり課題解決に向けて意見を交換したりしています。また、以前はチームの動きとは関係ない個人の話などが挙がってくることが多かったのですが、 チーム全体での生産性の向上ということを目的として考えた場合、それと関連のない個人の話をしても寄与しない ので、チーム全体に関わることをメインにするよう改善し今の形になってきました。 KPT が終わったら、隔週でチーム目標と Problem で挙がったことなども踏まえて各自の来週の Try を決めます。 新居 : 最後に、ちょっとしたことでも良いのでチームに共有したい「気になること」を話していきます。ここは開発に関係する・しないに関わらない話題を出しています。例えば 、Pharms のプロダクト自体や会社の組織的なこと、プルリクエストのレビューのお願いなど雑多な話題ですね。 その中で「ライブラリアップデート」についての課題や進捗などの共有もします。単純にバージョンアップして済むというものであれば良いですが、アップデートの結果、広範囲に影響があったりだとか、そもそもエラーなどで上手くアップデートできないなどがあるので、そうした困り事の共有と解決を目的としています。 山田 : 先ほどチーム目標を隔週で決めるというお話でしたが、こちらはどういう風に決めていくんですか? 小田 : KPT の内容を踏まえて、基本的には Our Essentials (以下 OE) に照らし合わせて決めていきます。そのチーム目標に対して、個人の目標をブレイクダウンして決める形にしています。 固くなりすぎない会を目指して 山田 : なるほど。 OE に合わせて目標設定していくというのは、分かりやすくて良い ですね。話は少し逸れますが、この TGIF では毎回お菓子を持ち寄って行なっているということですが、どうしてなのでしょうか? 小田 : TGIF を行なっている内に、メンバー間での意思疎通の少なさによって、チームの生産性が上がらないという課題は解決していきました。しかし、続けている内に段々と会自体が固い雰囲気になってきて、かっちりとした振り返りの場という感じになってしまいました。元々 TGIF の在り方としてはどういうものだっけという原点に立ち返ると、やはり 「気軽にコミュニケーションができる場」という点が重要 だと再認識しまして、そこからは場の雰囲気を柔らげるためにお菓子を持ち寄り始めました。 お菓子を囲んでの TGIF 山田 : 確かに固すぎると、ちょっと会の名前とそぐわない感じになってしまいますね。 TGIF 運用の秘訣 山田 : 他に TGIF を運用する上での工夫などはありますか? 新倉 : 会の性質上、話が盛り上がって時間がオーバーしがちなので「 TGIF で話す内容はチームの成長につながることに限定する」など、 効率的かつ意味のある運用 になるよう進め方の見直しと実践は日々試行錯誤しています。 新倉さん 古川 : 自分は去年の新卒入社ですので、「言ってもしょうがないかな?」というような事もあるのですが、あえてそういった事を考えずに積極的に発言するようにしています。 実際に発言したために他の方との共有もできますし、学びになるような議論に発展することも多い ので、言って良かったという場合が多いです。 古川さん 兒玉 : ささいな事でも、誰かが チームの為に動いた事に対しては積極的にお礼を言っています 。誰かがちゃんと自分のやったことを見てくれていると認識できることが、チームの雰囲気を良くし、チーム運営の好循環に繋がっているかと思います。 兒玉さん 新居 : ちゃんとチーム全員にとって意味がある時間にするということは意識しています。仮にあまり生産的な時間ではなくなったら TGIF を止めてしまっても良いと思っています。その為には 「チームのために話しをした方がよいことは必ず話す」「本音ベースで建設的に議論する」「出てきた課題は必ずクリアにして次週以降に解決を目指す」 という事を意識しています。 こうして話すとある意味当たり前の事ばかりなんですが、参加者全員がこうした点を共通認識として持っていないと、単に KPT を発表するだけの場となり会自体が形骸化していってしまいます。ですので、きちんとこの共通認識を持って臨めるようにするというのを大切にしています。 小田 : また、TGIF で話が盛り上がるのは良いことなのですが、週に一回のこの場を待たずにもっと会話を活性化する取り組みとして 週の頭に Slack のプロダクトチャンネルにテディベアがリマインダーで現れる ので、そのスレッドで話しをするようにしています。 山田 : へえー!何でテディベアなんですか? 新居 : プログラミングで自分で解決できない問題が出てきたときに、テディベアのぬいぐるみに話しかけると問題が整理されて解決できるというテディベア効果から取っています。 テディベアの リマインダーにコメントが付いている様子 山田 : なるほど、それでテディベアが出てくるんですね。 小田 : TGIF を待つまでの時間がムダだよねっていう話もあって先程の効率化の話も含めて行なっている施策です。 新倉 : これまで TGIF やテディベアが無い時は下手をすると一週間誰とも会話をしていないということもあったんですが、この取り組みをしてから 本当にコミュニケーションが増えました 。 TGIF の利点とこれからについて 山田 : ありがとうございます。既に話にも出ていますが、TGIF をやって良かった点はどういったものがあるか改めて聞かせてください。 小田 : やっぱり格段に「チームでの開発」をしているという意識が高まったことが良いことでした。それまではやはりコミュニケーションなどが不足していたのですが、今は TGIF などのおかげですぐに相談しようという感じにもなって良いチームになってきたなという感触があります。 さらにチームを良くする土壌 にするようにしていきたいです。 新居 : 1 つ目は以前よりお互いのことを知れるようになって心理的安全性が高まったこと、2 つ目はチームとしての方針や共通認識を合わせる場として機能していること、3 つ目は毎週前週からの課題を改善でき、チームや個人の成長を感じられるようになったことです。 全体的にチーム運営にプラス になっていると感じています。 新倉 : 私は TGIF が始まってから半年後にジョインしました。元々はエンジニアの皆さんだけのものだと思ってちょっと尻込みしていたところがあったのですが、蓋を開けてみるとプロダクトやチーム自体についての話が多く、 デザイナーとしても非常に学び があるものでした。全体的にはクォーター毎に目標を決めてそれに向けて動くのですが、その目標までの道のりを埋めるという意味でも、TGIF があって良かったです。 新居 : 時にはエンジニアだけにしかわからない話題などもあったりもしますが、大部分は新倉さんが話したようにプロダクトやチームの改善をいかに行なうかという話題になっているので、そこでデザイナー視点での話が聞けてエンジニアとしても大変助かります。 古川 : 自分は入ってからずっと TGIF があるのである種当たり前の存在なのですが…。チームメンバーの人となりなどが分かるのは大変助かります。また、自分とは全然違う経歴を持っているエンジニアの方などは同じ話題でも、 自分とは全然違う視点を持って話をしていたりするので、すごく勉強になっています 。チームの課題が話し合われるので、以前は自分のタスクが終わったら、「次は何をしよう」という感じになっていたんですが、TGIF のおかげで「チームがここで困っているなら自分がやろう」と客観的に分かるようになっています。また、OE は半年毎の自己評価の際にも体現できているかどうかチェックすることになるので、TGIF での目標達成度がそれに役立ちます。 兒玉 : 一番は心理的安全性が高くなったことです。エンジニアとしての働き方とセールスをしていた時の働き方が全然違うところが多かったので、1on1 で新居さんとそういった差異について聞くという機会しかなかったんですが、今は TGIF があるのでここで皆さんに聞けるようになって様々な視点でのアドバイスを頂けるようになりました。また、エンジニアとしてお勧めの書籍や勉強法など普通に聞こうとすると、 あまり機会がないような部分も気軽に聞けるようになったので、勉強の効率も良くなりました 。 山田 : みなさん、ありがとうございます。それぞれの立場ですごく有用な会なのが分かりますね。 TGIF のこれからについてもお話ください。 新居 : 先ほども少し話しましたが、形骸化してしまい惰性で行なってしまうということになるのが本当に怖いと思っています。運用することが目的になってしまい、本来の目的が達成できないと本末転倒ですし。今もやっていることですが、ちゃんとメンバー構成や状況に応じて運用をアップデートしていくということが一番大切だと思っています。 小田 : 今までエンジニアだけの会から TGIF は始まっていますが、デザイナーの新倉さんが参加してくれたのを始めとして、昨年末から企画職の方も入ってくれるようになったので、裾野の広がりを感じています。こういった立場が別々のメンバーが入ってもスムーズに目的が達成できるように TGIF のアップデートを続けていきたいですね。 新倉 : 色々な役割の人がフラットに発言できる場があるおかげで、プロダクトについて総合的な視点を持つことができたと感じています。実際に自分達が試行錯誤して出した機能が「お客様にこんな風に使われて、こんな感想をもらえた」などすぐに共有してもらえるので、開発のモチベーションにもつながる良いサイクルになっています。 Pharms 開発チームでは、どんな人と一緒に働きたいと考えている? 山田 : ありがとうございます。最後に Pharms の開発チームには、どんな方がジョインされると嬉しいですか? 小田 : いつもチーム内で話をしているのが「 顧客ファースト 」という言葉です。これは Pharms に限った話ではなくメドレー全体の話でもあるのですが、顧客や患者などサービスを使っている人達に対して提供できる価値は何かということをきちんと意識して開発ができる方です。技術や数字だけを見るわけじゃなく、その先の顧客をちゃんと考えて開発ができる人ですね。 新居 : メドレーの事業やバリューに共感があるのは大前提です。また、小田さんが話されたことに加えて、プロダクトをより良くしようと考えてるメンバーと共に、自分はこうしたいという意志も持ちつつ、ときには建設的に議論もしながらプロダクト開発を推進できる人と一緒に仕事ができると嬉しいです。大変なことも勿論ありますが、それを楽しみ、周囲を巻き込みながら技術・技術以外の部分も含め前に進めていける人が良いなと思います。 山田 : TGIF も顧客ファーストの理念から生まれたものということになりますよね。ありがとうございました! さいごに Pharms 開発チームが実践している「TGIF」というチームビルディングの方法についてインタビューしてきましたが、いかがだったでしょうか? 実際に TGIF をしている様子などを見ると、和やかな雰囲気ではありますが、全員真剣にプロダクトについて議論をしている姿が印象的でした。 こんなチームで調剤薬局や患者のためのプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! https://www.medley.jp/jobs/

はじめに みなさん、こんにちは。エンジニアの山田です。今回は Pharms 開発チームがチームビルディングの一環として行なっている「TGIF」という施策について参加している皆さんに、どのような効果があるのかなどを聞いていこうと思います。 インタビュイー紹介 新居さん 2016 年入社。ソーシャルゲーム開発会社を経て、メドレーへ入社。入社当初はジョブメドレーのプロダクト開発などを担当していたが、2020 年から Pharms で中規模施策の開発を中心に業務を行なう。 小田さん 2021 年入社。大手メーカーで病院や調剤薬局向けの IT システムの開発業務を経て、メドレー入社。Pharms では中規模施策の開発を中心に業務を行なう。 兒玉さん 2018 年入社。2021 年 4 月まで CLINICS オンライン診療のセールス部に所属。その後エンジニアに社内転職し、Pharms の開発に携わる。現在はサーバサイドの開発を中心に担当している。 新倉さん 2021 年入社。不動産テック企業でのデザイン業務を経て、メドレーへ入社。入社時から Pharms のデザイナーとして各種デザインの業務を行なう。 古川さん 2022 年に新卒入社。現在はプロダクトの改善を幅広く担当している。 Pharms というプロダクトについて 山田 : まず「TGIF」について聞いていく前に、Pharms とはどのようなプロダクトなのか教えてもらってもよいですか? 新居 : 一言で言うと、薬局の業務効率化支援システムです。 CLINICS オンライン診療 で診察を受けた患者さんや、直接来院された患者さんからの処方箋などを受けて、Pharms を通して服薬指導や、会計、服薬フォローアップなどを一貫して行なえるシステムになっています。 新居さん 山田 : ユーザーについてですが、例えば、自分が開発を担当している医療介護求人サイトの ジョブメドレー では、お仕事をお探しの求職者の方々と、求人情報を掲載いただく医院・事業所の方々が使用しているシステムなのですが、Pharms はどのような方に使われるのでしょうか? 小田 : CLINICS アプリを通して間接的に患者さんが使っていますが、大きい割合を占めるのは顧客である薬局のスタッフさん（薬剤師など）ですね。 小田さん 山田 : やはり現場の薬剤師さんが使っているサービスという性格が強いんですね。 Pharms 開発チームの TGIF という試みについて TGIF を始める前の課題感 山田 : それでは、いよいよ Pharms 開発チームで行なっている TGIF について聞いていきたいと思います。元々、この言葉はどんな経緯で付いたんですか? 小田 : 元々は英語圏で言われている “Thank God It’s Friday” というのが語源で、そのまま金曜日の夕方に開催されるものだったのでこの名前を付けています。ちょっと昔の言葉で言うと「花金」ですね。 山田 : 「1 週間が終わりだー!」っていう開放感を表わしてるんですね。どういうきっかけでこの TGIF をやっていこうと思ったんでしょうか? 小田 : 一昨年の自分の入社前のタイミングで、Pharms 立ち上げ時のメンバーが別のプロジェクトに集中することとなり、チーム体制がガラッと変わる時期がありました。それ以降、チーム内の情報がサイロ化したり、チームとしての一体感がないという課題を感じていました。この課題を解決するために 雑多に何でも話せるコミュニケーションの場 を作ろうというのが、きっかけでした。 新居 : もちろん、それまでもチームで話す機会が全く無かったわけではなく、開発計画をクォーター単位で作っているのでそのタイミングでディスカッションする場を設けていました。でも もうちょっとコミュニケーションの頻度を増やしたらより良くなりそうだよね という話があり、毎週金曜日の TGIF が誕生しました。 山田 : そういう経緯だったんですね。それまでエンジニア・デザイナーが参加する定例のような会議体はどのようなものがあったんですか? 新居 : クォーター毎のディスカッション以外だと、週一で行なわれる「プロダクト定例」だけでした。こちらは開発メンバーだけではなく、事業部のメンバーも参加してプロダクト開発全般についての共有を目的にしたものです。それ以外で定例の会議体はなく、デイリーで行われるような「朝会・夕会」も Pharms 開発チームでは行なっていませんでした。 山田 : チーム体制の変更後、新しいメンバーの加入もあり、今までのコミュニケーション量では足りなくなってしまったんですね。 新居 : はい。チームの状況が変わって行く中で、 もっと生産性を上げていきたいという思いがありました 。チームが小規模だった頃は隣の席の同僚エンジニアに相談しつつ開発をドンドン前に進めていくことができたんですが、人数が増えてくるとそうしたコミュニケーションも希薄になります。具体的には、開発をしていて設計方針・実装方針などがズレることは多々あると思うんですが、それをさっと会話して軌道修正し、開発を推進していくというのが難しくなってきていました。 TGIF の実際 山田 : では、具体的に TGIF でどのような事を話し合われるんでしょうか? 新居 : まずは今週の振り返りから始まります。前週の TGIF で Try に対して個々がどう動いていくかを決めているので、それに対して振り返りをしていきます。各自コメントを添えて何%達成したのか話していきます。 小田 : その後、今週のチーム全体の動きに対して KPT を実施します。チーム全体として良かった動きや課題などを挙げていき、内容を深ぼったり課題解決に向けて意見を交換したりしています。また、以前はチームの動きとは関係ない個人の話などが挙がってくることが多かったのですが、 チーム全体での生産性の向上ということを目的として考えた場合、それと関連のない個人の話をしても寄与しない ので、チーム全体に関わることをメインにするよう改善し今の形になってきました。 KPT が終わったら、隔週でチーム目標と Problem で挙がったことなども踏まえて各自の来週の Try を決めます。 新居 : 最後に、ちょっとしたことでも良いのでチームに共有したい「気になること」を話していきます。ここは開発に関係する・しないに関わらない話題を出しています。例えば 、Pharms のプロダクト自体や会社の組織的なこと、プルリクエストのレビューのお願いなど雑多な話題ですね。 その中で「ライブラリアップデート」についての課題や進捗などの共有もします。単純にバージョンアップして済むというものであれば良いですが、アップデートの結果、広範囲に影響があったりだとか、そもそもエラーなどで上手くアップデートできないなどがあるので、そうした困り事の共有と解決を目的としています。 山田 : 先ほどチーム目標を隔週で決めるというお話でしたが、こちらはどういう風に決めていくんですか? 小田 : KPT の内容を踏まえて、基本的には Our Essentials (以下 OE) に照らし合わせて決めていきます。そのチーム目標に対して、個人の目標をブレイクダウンして決める形にしています。 固くなりすぎない会を目指して 山田 : なるほど。 OE に合わせて目標設定していくというのは、分かりやすくて良い ですね。話は少し逸れますが、この TGIF では毎回お菓子を持ち寄って行なっているということですが、どうしてなのでしょうか? 小田 : TGIF を行なっている内に、メンバー間での意思疎通の少なさによって、チームの生産性が上がらないという課題は解決していきました。しかし、続けている内に段々と会自体が固い雰囲気になってきて、かっちりとした振り返りの場という感じになってしまいました。元々 TGIF の在り方としてはどういうものだっけという原点に立ち返ると、やはり 「気軽にコミュニケーションができる場」という点が重要 だと再認識しまして、そこからは場の雰囲気を柔らげるためにお菓子を持ち寄り始めました。 お菓子を囲んでの TGIF 山田 : 確かに固すぎると、ちょっと会の名前とそぐわない感じになってしまいますね。 TGIF 運用の秘訣 山田 : 他に TGIF を運用する上での工夫などはありますか? 新倉 : 会の性質上、話が盛り上がって時間がオーバーしがちなので「 TGIF で話す内容はチームの成長につながることに限定する」など、 効率的かつ意味のある運用 になるよう進め方の見直しと実践は日々試行錯誤しています。 新倉さん 古川 : 自分は去年の新卒入社ですので、「言ってもしょうがないかな?」というような事もあるのですが、あえてそういった事を考えずに積極的に発言するようにしています。 実際に発言したために他の方との共有もできますし、学びになるような議論に発展することも多い ので、言って良かったという場合が多いです。 古川さん 兒玉 : ささいな事でも、誰かが チームの為に動いた事に対しては積極的にお礼を言っています 。誰かがちゃんと自分のやったことを見てくれていると認識できることが、チームの雰囲気を良くし、チーム運営の好循環に繋がっているかと思います。 兒玉さん 新居 : ちゃんとチーム全員にとって意味がある時間にするということは意識しています。仮にあまり生産的な時間ではなくなったら TGIF を止めてしまっても良いと思っています。その為には 「チームのために話しをした方がよいことは必ず話す」「本音ベースで建設的に議論する」「出てきた課題は必ずクリアにして次週以降に解決を目指す」 という事を意識しています。 こうして話すとある意味当たり前の事ばかりなんですが、参加者全員がこうした点を共通認識として持っていないと、単に KPT を発表するだけの場となり会自体が形骸化していってしまいます。ですので、きちんとこの共通認識を持って臨めるようにするというのを大切にしています。 小田 : また、TGIF で話が盛り上がるのは良いことなのですが、週に一回のこの場を待たずにもっと会話を活性化する取り組みとして 週の頭に Slack のプロダクトチャンネルにテディベアがリマインダーで現れる ので、そのスレッドで話しをするようにしています。 山田 : へえー!何でテディベアなんですか? 新居 : プログラミングで自分で解決できない問題が出てきたときに、テディベアのぬいぐるみに話しかけると問題が整理されて解決できるというテディベア効果から取っています。 テディベアの リマインダーにコメントが付いている様子 山田 : なるほど、それでテディベアが出てくるんですね。 小田 : TGIF を待つまでの時間がムダだよねっていう話もあって先程の効率化の話も含めて行なっている施策です。 新倉 : これまで TGIF やテディベアが無い時は下手をすると一週間誰とも会話をしていないということもあったんですが、この取り組みをしてから 本当にコミュニケーションが増えました 。 TGIF の利点とこれからについて 山田 : ありがとうございます。既に話にも出ていますが、TGIF をやって良かった点はどういったものがあるか改めて聞かせてください。 小田 : やっぱり格段に「チームでの開発」をしているという意識が高まったことが良いことでした。それまではやはりコミュニケーションなどが不足していたのですが、今は TGIF などのおかげですぐに相談しようという感じにもなって良いチームになってきたなという感触があります。 さらにチームを良くする土壌 にするようにしていきたいです。 新居 : 1 つ目は以前よりお互いのことを知れるようになって心理的安全性が高まったこと、2 つ目はチームとしての方針や共通認識を合わせる場として機能していること、3 つ目は毎週前週からの課題を改善でき、チームや個人の成長を感じられるようになったことです。 全体的にチーム運営にプラス になっていると感じています。 新倉 : 私は TGIF が始まってから半年後にジョインしました。元々はエンジニアの皆さんだけのものだと思ってちょっと尻込みしていたところがあったのですが、蓋を開けてみるとプロダクトやチーム自体についての話が多く、 デザイナーとしても非常に学び があるものでした。全体的にはクォーター毎に目標を決めてそれに向けて動くのですが、その目標までの道のりを埋めるという意味でも、TGIF があって良かったです。 新居 : 時にはエンジニアだけにしかわからない話題などもあったりもしますが、大部分は新倉さんが話したようにプロダクトやチームの改善をいかに行なうかという話題になっているので、そこでデザイナー視点での話が聞けてエンジニアとしても大変助かります。 古川 : 自分は入ってからずっと TGIF があるのである種当たり前の存在なのですが…。チームメンバーの人となりなどが分かるのは大変助かります。また、自分とは全然違う経歴を持っているエンジニアの方などは同じ話題でも、 自分とは全然違う視点を持って話をしていたりするので、すごく勉強になっています 。チームの課題が話し合われるので、以前は自分のタスクが終わったら、「次は何をしよう」という感じになっていたんですが、TGIF のおかげで「チームがここで困っているなら自分がやろう」と客観的に分かるようになっています。また、OE は半年毎の自己評価の際にも体現できているかどうかチェックすることになるので、TGIF での目標達成度がそれに役立ちます。 兒玉 : 一番は心理的安全性が高くなったことです。エンジニアとしての働き方とセールスをしていた時の働き方が全然違うところが多かったので、1on1 で新居さんとそういった差異について聞くという機会しかなかったんですが、今は TGIF があるのでここで皆さんに聞けるようになって様々な視点でのアドバイスを頂けるようになりました。また、エンジニアとしてお勧めの書籍や勉強法など普通に聞こうとすると、 あまり機会がないような部分も気軽に聞けるようになったので、勉強の効率も良くなりました 。 山田 : みなさん、ありがとうございます。それぞれの立場ですごく有用な会なのが分かりますね。 TGIF のこれからについてもお話ください。 新居 : 先ほども少し話しましたが、形骸化してしまい惰性で行なってしまうということになるのが本当に怖いと思っています。運用することが目的になってしまい、本来の目的が達成できないと本末転倒ですし。今もやっていることですが、ちゃんとメンバー構成や状況に応じて運用をアップデートしていくということが一番大切だと思っています。 小田 : 今までエンジニアだけの会から TGIF は始まっていますが、デザイナーの新倉さんが参加してくれたのを始めとして、昨年末から企画職の方も入ってくれるようになったので、裾野の広がりを感じています。こういった立場が別々のメンバーが入ってもスムーズに目的が達成できるように TGIF のアップデートを続けていきたいですね。 新倉 : 色々な役割の人がフラットに発言できる場があるおかげで、プロダクトについて総合的な視点を持つことができたと感じています。実際に自分達が試行錯誤して出した機能が「お客様にこんな風に使われて、こんな感想をもらえた」などすぐに共有してもらえるので、開発のモチベーションにもつながる良いサイクルになっています。 Pharms 開発チームでは、どんな人と一緒に働きたいと考えている? 山田 : ありがとうございます。最後に Pharms の開発チームには、どんな方がジョインされると嬉しいですか? 小田 : いつもチーム内で話をしているのが「 顧客ファースト 」という言葉です。これは Pharms に限った話ではなくメドレー全体の話でもあるのですが、顧客や患者などサービスを使っている人達に対して提供できる価値は何かということをきちんと意識して開発ができる方です。技術や数字だけを見るわけじゃなく、その先の顧客をちゃんと考えて開発ができる人ですね。 新居 : メドレーの事業やバリューに共感があるのは大前提です。また、小田さんが話されたことに加えて、プロダクトをより良くしようと考えてるメンバーと共に、自分はこうしたいという意志も持ちつつ、ときには建設的に議論もしながらプロダクト開発を推進できる人と一緒に仕事ができると嬉しいです。大変なことも勿論ありますが、それを楽しみ、周囲を巻き込みながら技術・技術以外の部分も含め前に進めていける人が良いなと思います。 山田 : TGIF も顧客ファーストの理念から生まれたものということになりますよね。ありがとうございました! さいごに Pharms 開発チームが実践している「TGIF」というチームビルディングの方法についてインタビューしてきましたが、いかがだったでしょうか? 実際に TGIF をしている様子などを見ると、和やかな雰囲気ではありますが、全員真剣にプロダクトについて議論をしている姿が印象的でした。 こんなチームで調剤薬局や患者のためのプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。今回は Pharms 開発チームがチームビルディングの一環として行なっている「TGIF」という施策について参加している皆さんに、どのような効果があるのかなどを聞いていこうと思います。 インタビュイー紹介 新居さん 2016 年入社。ソーシャルゲーム開発会社を経て、メドレーへ入社。入社当初はジョブメドレーのプロダクト開発などを担当していたが、2020 年から Pharms で中規模施策の開発を中心に業務を行なう。 小田さん 2021 年入社。大手メーカーで病院や調剤薬局向けの IT システムの開発業務を経て、メドレー入社。Pharms では中規模施策の開発を中心に業務を行なう。 兒玉さん 2018 年入社。2021 年 4 月まで CLINICS オンライン診療のセールス部に所属。その後エンジニアに社内転職し、Pharms の開発に携わる。現在はサーバサイドの開発を中心に担当している。 新倉さん 2021 年入社。不動産テック企業でのデザイン業務を経て、メドレーへ入社。入社時から Pharms のデザイナーとして各種デザインの業務を行なう。 古川さん 2022 年に新卒入社。現在はプロダクトの改善を幅広く担当している。 Pharms というプロダクトについて 山田 : まず「TGIF」について聞いていく前に、Pharms とはどのようなプロダクトなのか教えてもらってもよいですか? 新居 : 一言で言うと、薬局の業務効率化支援システムです。 CLINICS オンライン診療 で診察を受けた患者さんや、直接来院された患者さんからの処方箋などを受けて、Pharms を通して服薬指導や、会計、服薬フォローアップなどを一貫して行なえるシステムになっています。 新居さん 山田 : ユーザーについてですが、例えば、自分が開発を担当している医療介護求人サイトの ジョブメドレー では、お仕事をお探しの求職者の方々と、求人情報を掲載いただく医院・事業所の方々が使用しているシステムなのですが、Pharms はどのような方に使われるのでしょうか? 小田 : CLINICS アプリを通して間接的に患者さんが使っていますが、大きい割合を占めるのは顧客である薬局のスタッフさん（薬剤師など）ですね。 小田さん 山田 : やはり現場の薬剤師さんが使っているサービスという性格が強いんですね。 Pharms 開発チームの TGIF という試みについて TGIF を始める前の課題感 山田 : それでは、いよいよ Pharms 開発チームで行なっている TGIF について聞いていきたいと思います。元々、この言葉はどんな経緯で付いたんですか? 小田 : 元々は英語圏で言われている “Thank God It’s Friday” というのが語源で、そのまま金曜日の夕方に開催されるものだったのでこの名前を付けています。ちょっと昔の言葉で言うと「花金」ですね。 山田 : 「1 週間が終わりだー!」っていう開放感を表わしてるんですね。どういうきっかけでこの TGIF をやっていこうと思ったんでしょうか? 小田 : 一昨年の自分の入社前のタイミングで、Pharms 立ち上げ時のメンバーが別のプロジェクトに集中することとなり、チーム体制がガラッと変わる時期がありました。それ以降、チーム内の情報がサイロ化したり、チームとしての一体感がないという課題を感じていました。この課題を解決するために 雑多に何でも話せるコミュニケーションの場 を作ろうというのが、きっかけでした。 新居 : もちろん、それまでもチームで話す機会が全く無かったわけではなく、開発計画をクォーター単位で作っているのでそのタイミングでディスカッションする場を設けていました。でも もうちょっとコミュニケーションの頻度を増やしたらより良くなりそうだよね という話があり、毎週金曜日の TGIF が誕生しました。 山田 : そういう経緯だったんですね。それまでエンジニア・デザイナーが参加する定例のような会議体はどのようなものがあったんですか? 新居 : クォーター毎のディスカッション以外だと、週一で行なわれる「プロダクト定例」だけでした。こちらは開発メンバーだけではなく、事業部のメンバーも参加してプロダクト開発全般についての共有を目的にしたものです。それ以外で定例の会議体はなく、デイリーで行われるような「朝会・夕会」も Pharms 開発チームでは行なっていませんでした。 山田 : チーム体制の変更後、新しいメンバーの加入もあり、今までのコミュニケーション量では足りなくなってしまったんですね。 新居 : はい。チームの状況が変わって行く中で、 もっと生産性を上げていきたいという思いがありました 。チームが小規模だった頃は隣の席の同僚エンジニアに相談しつつ開発をドンドン前に進めていくことができたんですが、人数が増えてくるとそうしたコミュニケーションも希薄になります。具体的には、開発をしていて設計方針・実装方針などがズレることは多々あると思うんですが、それをさっと会話して軌道修正し、開発を推進していくというのが難しくなってきていました。 TGIF の実際 山田 : では、具体的に TGIF でどのような事を話し合われるんでしょうか? 新居 : まずは今週の振り返りから始まります。前週の TGIF で Try に対して個々がどう動いていくかを決めているので、それに対して振り返りをしていきます。各自コメントを添えて何%達成したのか話していきます。 小田 : その後、今週のチーム全体の動きに対して KPT を実施します。チーム全体として良かった動きや課題などを挙げていき、内容を深ぼったり課題解決に向けて意見を交換したりしています。また、以前はチームの動きとは関係ない個人の話などが挙がってくることが多かったのですが、 チーム全体での生産性の向上ということを目的として考えた場合、それと関連のない個人の話をしても寄与しない ので、チーム全体に関わることをメインにするよう改善し今の形になってきました。 KPT が終わったら、隔週でチーム目標と Problem で挙がったことなども踏まえて各自の来週の Try を決めます。 新居 : 最後に、ちょっとしたことでも良いのでチームに共有したい「気になること」を話していきます。ここは開発に関係する・しないに関わらない話題を出しています。例えば 、Pharms のプロダクト自体や会社の組織的なこと、プルリクエストのレビューのお願いなど雑多な話題ですね。 その中で「ライブラリアップデート」についての課題や進捗などの共有もします。単純にバージョンアップして済むというものであれば良いですが、アップデートの結果、広範囲に影響があったりだとか、そもそもエラーなどで上手くアップデートできないなどがあるので、そうした困り事の共有と解決を目的としています。 山田 : 先ほどチーム目標を隔週で決めるというお話でしたが、こちらはどういう風に決めていくんですか? 小田 : KPT の内容を踏まえて、基本的には Our Essentials (以下 OE) に照らし合わせて決めていきます。そのチーム目標に対して、個人の目標をブレイクダウンして決める形にしています。 固くなりすぎない会を目指して 山田 : なるほど。 OE に合わせて目標設定していくというのは、分かりやすくて良い ですね。話は少し逸れますが、この TGIF では毎回お菓子を持ち寄って行なっているということですが、どうしてなのでしょうか? 小田 : TGIF を行なっている内に、メンバー間での意思疎通の少なさによって、チームの生産性が上がらないという課題は解決していきました。しかし、続けている内に段々と会自体が固い雰囲気になってきて、かっちりとした振り返りの場という感じになってしまいました。元々 TGIF の在り方としてはどういうものだっけという原点に立ち返ると、やはり 「気軽にコミュニケーションができる場」という点が重要 だと再認識しまして、そこからは場の雰囲気を柔らげるためにお菓子を持ち寄り始めました。 お菓子を囲んでの TGIF 山田 : 確かに固すぎると、ちょっと会の名前とそぐわない感じになってしまいますね。 TGIF 運用の秘訣 山田 : 他に TGIF を運用する上での工夫などはありますか? 新倉 : 会の性質上、話が盛り上がって時間がオーバーしがちなので「 TGIF で話す内容はチームの成長につながることに限定する」など、 効率的かつ意味のある運用 になるよう進め方の見直しと実践は日々試行錯誤しています。 新倉さん 古川 : 自分は去年の新卒入社ですので、「言ってもしょうがないかな?」というような事もあるのですが、あえてそういった事を考えずに積極的に発言するようにしています。 実際に発言したために他の方との共有もできますし、学びになるような議論に発展することも多い ので、言って良かったという場合が多いです。 古川さん 兒玉 : ささいな事でも、誰かが チームの為に動いた事に対しては積極的にお礼を言っています 。誰かがちゃんと自分のやったことを見てくれていると認識できることが、チームの雰囲気を良くし、チーム運営の好循環に繋がっているかと思います。 兒玉さん 新居 : ちゃんとチーム全員にとって意味がある時間にするということは意識しています。仮にあまり生産的な時間ではなくなったら TGIF を止めてしまっても良いと思っています。その為には 「チームのために話しをした方がよいことは必ず話す」「本音ベースで建設的に議論する」「出てきた課題は必ずクリアにして次週以降に解決を目指す」 という事を意識しています。 こうして話すとある意味当たり前の事ばかりなんですが、参加者全員がこうした点を共通認識として持っていないと、単に KPT を発表するだけの場となり会自体が形骸化していってしまいます。ですので、きちんとこの共通認識を持って臨めるようにするというのを大切にしています。 小田 : また、TGIF で話が盛り上がるのは良いことなのですが、週に一回のこの場を待たずにもっと会話を活性化する取り組みとして 週の頭に Slack のプロダクトチャンネルにテディベアがリマインダーで現れる ので、そのスレッドで話しをするようにしています。 山田 : へえー!何でテディベアなんですか? 新居 : プログラミングで自分で解決できない問題が出てきたときに、テディベアのぬいぐるみに話しかけると問題が整理されて解決できるというテディベア効果から取っています。 テディベアの リマインダーにコメントが付いている様子 山田 : なるほど、それでテディベアが出てくるんですね。 小田 : TGIF を待つまでの時間がムダだよねっていう話もあって先程の効率化の話も含めて行なっている施策です。 新倉 : これまで TGIF やテディベアが無い時は下手をすると一週間誰とも会話をしていないということもあったんですが、この取り組みをしてから 本当にコミュニケーションが増えました 。 TGIF の利点とこれからについて 山田 : ありがとうございます。既に話にも出ていますが、TGIF をやって良かった点はどういったものがあるか改めて聞かせてください。 小田 : やっぱり格段に「チームでの開発」をしているという意識が高まったことが良いことでした。それまではやはりコミュニケーションなどが不足していたのですが、今は TGIF などのおかげですぐに相談しようという感じにもなって良いチームになってきたなという感触があります。 さらにチームを良くする土壌 にするようにしていきたいです。 新居 : 1 つ目は以前よりお互いのことを知れるようになって心理的安全性が高まったこと、2 つ目はチームとしての方針や共通認識を合わせる場として機能していること、3 つ目は毎週前週からの課題を改善でき、チームや個人の成長を感じられるようになったことです。 全体的にチーム運営にプラス になっていると感じています。 新倉 : 私は TGIF が始まってから半年後にジョインしました。元々はエンジニアの皆さんだけのものだと思ってちょっと尻込みしていたところがあったのですが、蓋を開けてみるとプロダクトやチーム自体についての話が多く、 デザイナーとしても非常に学び があるものでした。全体的にはクォーター毎に目標を決めてそれに向けて動くのですが、その目標までの道のりを埋めるという意味でも、TGIF があって良かったです。 新居 : 時にはエンジニアだけにしかわからない話題などもあったりもしますが、大部分は新倉さんが話したようにプロダクトやチームの改善をいかに行なうかという話題になっているので、そこでデザイナー視点での話が聞けてエンジニアとしても大変助かります。 古川 : 自分は入ってからずっと TGIF があるのである種当たり前の存在なのですが…。チームメンバーの人となりなどが分かるのは大変助かります。また、自分とは全然違う経歴を持っているエンジニアの方などは同じ話題でも、 自分とは全然違う視点を持って話をしていたりするので、すごく勉強になっています 。チームの課題が話し合われるので、以前は自分のタスクが終わったら、「次は何をしよう」という感じになっていたんですが、TGIF のおかげで「チームがここで困っているなら自分がやろう」と客観的に分かるようになっています。また、OE は半年毎の自己評価の際にも体現できているかどうかチェックすることになるので、TGIF での目標達成度がそれに役立ちます。 兒玉 : 一番は心理的安全性が高くなったことです。エンジニアとしての働き方とセールスをしていた時の働き方が全然違うところが多かったので、1on1 で新居さんとそういった差異について聞くという機会しかなかったんですが、今は TGIF があるのでここで皆さんに聞けるようになって様々な視点でのアドバイスを頂けるようになりました。また、エンジニアとしてお勧めの書籍や勉強法など普通に聞こうとすると、 あまり機会がないような部分も気軽に聞けるようになったので、勉強の効率も良くなりました 。 山田 : みなさん、ありがとうございます。それぞれの立場ですごく有用な会なのが分かりますね。 TGIF のこれからについてもお話ください。 新居 : 先ほども少し話しましたが、形骸化してしまい惰性で行なってしまうということになるのが本当に怖いと思っています。運用することが目的になってしまい、本来の目的が達成できないと本末転倒ですし。今もやっていることですが、ちゃんとメンバー構成や状況に応じて運用をアップデートしていくということが一番大切だと思っています。 小田 : 今までエンジニアだけの会から TGIF は始まっていますが、デザイナーの新倉さんが参加してくれたのを始めとして、昨年末から企画職の方も入ってくれるようになったので、裾野の広がりを感じています。こういった立場が別々のメンバーが入ってもスムーズに目的が達成できるように TGIF のアップデートを続けていきたいですね。 新倉 : 色々な役割の人がフラットに発言できる場があるおかげで、プロダクトについて総合的な視点を持つことができたと感じています。実際に自分達が試行錯誤して出した機能が「お客様にこんな風に使われて、こんな感想をもらえた」などすぐに共有してもらえるので、開発のモチベーションにもつながる良いサイクルになっています。 Pharms 開発チームでは、どんな人と一緒に働きたいと考えている? 山田 : ありがとうございます。最後に Pharms の開発チームには、どんな方がジョインされると嬉しいですか? 小田 : いつもチーム内で話をしているのが「 顧客ファースト 」という言葉です。これは Pharms に限った話ではなくメドレー全体の話でもあるのですが、顧客や患者などサービスを使っている人達に対して提供できる価値は何かということをきちんと意識して開発ができる方です。技術や数字だけを見るわけじゃなく、その先の顧客をちゃんと考えて開発ができる人ですね。 新居 : メドレーの事業やバリューに共感があるのは大前提です。また、小田さんが話されたことに加えて、プロダクトをより良くしようと考えてるメンバーと共に、自分はこうしたいという意志も持ちつつ、ときには建設的に議論もしながらプロダクト開発を推進できる人と一緒に仕事ができると嬉しいです。大変なことも勿論ありますが、それを楽しみ、周囲を巻き込みながら技術・技術以外の部分も含め前に進めていける人が良いなと思います。 山田 : TGIF も顧客ファーストの理念から生まれたものということになりますよね。ありがとうございました! さいごに Pharms 開発チームが実践している「TGIF」というチームビルディングの方法についてインタビューしてきましたが、いかがだったでしょうか? 実際に TGIF をしている様子などを見ると、和やかな雰囲気ではありますが、全員真剣にプロダクトについて議論をしている姿が印象的でした。 こんなチームで調剤薬局や患者のためのプロダクトを作っていきたいと思う方は、ぜひお気軽にお話をしましょう! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。コーポレートデザイン部でコーポレート IT を担当している清水です。 コーポレート IT では全従業員が利用するネットワークインフラや SaaS といった IT 全般を統括しており、社内で発生している課題について IT を駆使して解決しています。 今回は、こうした課題解決の一例として、「 呼び鈴アプリ 」の開発について背景と実装のご紹介をし、最後に コーポレート IT チーム の業務内容や理念についてご紹介したいと思います。 呼び鈴アプリの開発背景 弊社では、チャットツールである「 Slack 」と「 Google Workspace 」や「 TeamSpirit 」等を連携して、来客者受付システムや 稟議ワークフローシステム 、オフィス空調最適化システム等、チャットをベースにした業務運用（ChatOps）を数多く行っています。 今回はその中でも、サポートを受けたい場合にコーポレート部門の担当者を呼び出しできるアプリ、 通称：呼び鈴アプリ をご紹介しようと思います。 呼び鈴アプリ導入前の困りごと IT 備品や健康保険証等の物の受け渡しや PC トラブルへの対応など、従業員へのサポート対応の際、サポートを依頼した従業員とコーポレート部門との間で、以下のような困りごとが発生していました。 ■ 従業員側の困りごと ・誰に話しかけたらよいかわからない IT 備品や健康保険証等を受け取りにコーポレート部門の座席に来たが、誰に話しかけたらよいかわからず、ウロウロしている方が結構いました。結果、別の部門に話しかけて、別の部門の方が正しい部門に案内するという時間も発生していました。 ・時間調整に手間がかかる PC トラブルへの対応の際は、コーポレート IT の担当者が依頼者の席まで行って作業をしていたため、担当者と依頼者で時間の調整が必要でした。直前で都合が悪くなり、リスケが発生することもしばしばありました。 ■ コーポレート部門の困りごと ・依頼者が見つけづらい 座席表を見て依頼者のところまで行くが、直近で座席変更があって居ると思っていたところに居ないことや、指定の時間に席に居ないといったことが度々発生していました。 ・個人情報が見えると困る 従業員が人事部から健康保険証等の書類を受け取る際、人事部の方は個人情報を扱うため、PC 画面の見える位置まで来られると困るという事情があり、特定の位置で待ってもらいたいというニーズがありました。 ・従業員の氏名確認に手間がかかる 全従業員分の氏名は把握できないため、コーポレート部門に来た従業員本人に名前を聞いて確認し、一旦席に戻って、貸与する IT 備品や健康保険証等を探して渡すという、席を行ったり来たりする状況でした。 ・周りの業務状況に配慮が必要 依頼者の席で PC トラブル対応をすると、周りの人が業務に集中していたり、顧客と電話していたりするため、業務に支障がでないようになるべく小声で話す必要がありました。 ・依頼者への対応が属人化しがち コーポレート部門の担当者と依頼者の間で作業の時間を調整していましたが、担当者が急な打ち合わせやお休みで不在になってしまったときは、他の担当者への引き継ぎ対応が漏れてしまうことがありました。 上記の課題を解決するために、 従業員の方向けにコーポレート部門の担当者を呼び出すアプリ を作りました！ どういったアプリか 呼び鈴アプリは、従業員とコーポレート部門で対面での作業/受け渡しが発生すること（PC トラブルへの対応/落とし物の受け渡し/健康保険証のお渡し等）に関して、iPad で依頼内容に応じた コーポレート部門の担当者を呼び出すことができるアプリ です。 コーポレート部門の近くのカウンターの上に iPad が置いてあり、そこから呼び出してもらいます。 ちなみに、カウンターはこんな感じのスペースで、従業員の方がセルフサービスで IT 備品交換を行えるブースもあります。 アプリの利用イメージ まず、従業員はカウンターまで行き、iPad の呼び鈴アプリから呼び出し依頼を行います。 呼び出し依頼は専用の Slack チャンネルに通知が来るので、各コーポレート部門の担当者が通知内容を確認して、従業員が居るカウンターに行き、対応という流れになります。 画面イメージ 利用方法は、自身の名前を選択してもらい、コーポレート部門への依頼内容を選択するという形です。 導入後の効果 呼び鈴アプリの導入によって、 従業員がコーポレート部門からサポートを受けたり、物を受け渡ししたいときは、 自身が都合の良いタイミングで カウンターの呼び鈴アプリに来れば良く、 利便性が向上した 。 Slack 通知に依頼者氏名が表示されるので、 氏名を確認する必要がなくなった。 コーポレート部門の担当者が 依頼者の席を探して尋ねなくてよくなった。 というように困りごとが改善されました。 また、特定のメンバーが対応するのではなく、呼び出されたタイミングで席に居る全メンバーが対応できるような運用にすることで、PC/IT 備品や健康保険証等の物の受け渡し、PC のトラブル対応等のサポート対応が属人的にならず、離席していても、休暇をとっていても誰でも対応できる体制になりました。 呼び鈴アプリの構成 呼び鈴アプリの開発にあたっては 1. 先述の課題を解決すること 2. コーポレート IT 内でプロジェクトが複数動いているため、他のプロジェクトの進捗に影響がでないように、工数をさほどかけずにクイックに開発できること 3. なるべくランニングコストをかけないこと という要件から、 AppSheet と Google App Script（以降 GAS） で実装することを決めました。 機能検証期間を含めて 1 週間程度で実装できています。 AppSheet は、Google から提供されている、ノーコードでアプリケーション開発ができるツールです。 AppSheet は、エンジニアではなく「現場で働く人が作る」という思想をもとにサービスが開始されました。そのため、プログラミング知識がない人でも、マウス操作のみで簡単にアプリケーションを開発できるようになっています。 サービス連携図 UI を AppSheet で、Slack への通知を GAS で実装しています。 画面構成 画面は依頼者選択画面、依頼内容一覧画面、依頼詳細一覧画面の３画面で構成しています。 呼び鈴アプリの実装 呼び鈴アプリをどのように実装しているか解説していきます。 AppSheet の設定 AppSheet を利用したアプリの作成方法については、Google 公式の How to create an app や Google で AppSheet を検索するといくつか作成例のサイトが表示されますので、今回の機能を実装するにあたり重要な 「依頼詳細一覧画面から Slack 通知」 設定の部分にフォーカスして解説します。 1. Data の設定 Tables と Slices について、それぞれ設定します。 Tables では、アプリケーションの元となるデータを格納する「テーブル」を作成します。 Slices では、テーブルから必要な行と列のみを表示させたり、条件にあうデータのみを表示させたりして、必要なデータを抽出した「テーブルの一部分」を作成します。 1-1. Tables の設定 今回 Table は以下の 5 つを用意しました。 テーブルは、スプレッドシートにテーブルとなるデータを作成した後、AppSheet と連携します。連携方法は Connect your data to AppSheet の動画を参考にしてください。 テーブル名 利用用途 Client 依頼者選択画面で選択されたユーザー名を一時的に保存するテーブル Doorbell 依頼内容一覧画面に表示するテーブル DoorbellDetails 依頼詳細一覧画面に表示するテーブル CallHistory 呼出履歴を保存するテーブル UserList 依頼者選択画面に表示するテーブル 依頼詳細一覧画面と呼び出し機能に関連する、「DoorbellDetails」と「CallHistory」について詳しく説明します。 ・ DoorbellDetails 依頼詳細一覧画面に表示したい内容を一覧で記載します。 分類 ID 列は Doorbell でも同名の列を作成し、そこで設定した値と合わせてください。また、対応 ID は分類 ID 内でユニークになるように設定してください。 対応説明に関しては、任意で入力していただければ大丈夫です。 SlackChannel 列に Slack チャンネルに投稿する用の Webhook URL を設定してください。 Incoming Webhooks 等を使用すると、 Webhook URL が取得できます。 3 行目以降のデータは、 2 行目を参考に設定してください。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 1 分類 ID 対応 ID 対応名 対応説明 SlackChannel 2 receipt 1 入社にあたって貸与物を受け取りたい （通知先チャンネルの Webhook URL を設定） Table での設定例 分類 ID と対応 ID を複合キー（分類 ID と対応 ID に「REQUIRE」を設定）としています。 ・ CallHistory 呼出履歴を保存するテーブルのため、ヘッダー以外の入力は不要です。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 F 列 G 列 1 CH_id CH_分類 ID CH_対応 ID CH_対応名 CH_SlackChannel CH_呼び出し日時 CH_依頼者 Table での設定例 1-2. Slices の設定 次に、Slice の設定を行います。Slice は依頼内容ごとに画面表示を切り替えるために「DoorbellDetails」のデータを元に作成します。 貸与物受け取りに関する Slice の場合、以下のように設定します。 設定項目名 設定値 Slice name 貸与物受け取り Source table DoorbellDetails Row filter condition [分類 ID]="receipt" 2. App の設定 Views について、それぞれ設定します。 2-1. Views の設定 依頼詳細一覧画面について詳しく説明します。 ・依頼詳細一覧画面 依頼内容一覧画面から遷移できるように、依頼詳細一覧画面は依頼内容ごとに準備します。ここでは貸与物受け取り画面を例として設定しています。 設定項目名 設定値 View name 貸与物受け取り画面 For this data 貸与物受け取り View type deck Position ref Primary header _RowNumber Secondary header 対応名 Event Actions(Row Selected) SaveAndMoveToClientForm（Actions の設定後、設定可能になります） 3. Actions の設定 各ボタンを押したときの動作を定義します。 実際には他にもいくつか Action を設定していますが、Slack 通知に関係する Action は以下の 3 つです。 Action 名 利用用途 MoveToClientForm 依頼者選択画面に遷移する SaveCallHistory CallHistory にデータを保存する SaveAndMoveToClientForm CallHistory に保存後、依頼者選択画面に遷移する ・ MoveToClientForm 依頼者選択画面に遷移する Action です。 設定項目名 設定値 Action name MoveToClientForm For a record of this table DoorbellDetails Do this App: go to another view within this app Target ”#view=依頼者選択” ・ SaveCallHistory 「CallHistory」テーブルにデータを保存する Action です。 選択された氏名については「Client」テーブルからデータを取得しています。 また、SlackChannel 列の記載がない場合は、画面に「呼び出し」ボタンを表示させないように設定しています。 設定項目名 設定値 Action name SaveCallHistory For a record of this table DoorbellDetails Do this Data: add a new row to another table using values from this row Set these columns CH_id = UNIQUEID() CH_分類 ID = [分類 ID] CH_対応 ID = [対応 ID] CH_対応名 = [対応名] CH_SlackChannel = [SlackChannel] CH_呼び出し日次 = TODAY() & ” ” & TIMENOW() CH_依頼者 = Client[ご自身の氏名] Display name 呼び出し Only if this condition is true ISNOTBLANK([SlackChannel]) Needs confirmation? True Confirmation Message CONCATENATE(“依頼者：“,Client[ご自身の氏名],"",“呼び出し内容：”,[対応名],"",“担当者を呼び出しますか？”) ・ SaveAndMoveToClientForm 呼出履歴に保存後、依頼者選択画面に遷移する Action です。この Action を依頼詳細一覧画面の Event Actions に紐付けます。 設定項目名 設定値 Action name SaveAndMoveToClientForm For a record of this table DoorbellDetails Do this Grouped: execute a sequence of actions Actions SaveCallHistory MoveToClientForm スプレッドシート の設定 AppSheet からスプレッドシートの「CallHistory」シートに呼出履歴データが登録（行追加）されたら、Slack 通知 GAS を実行するように設定します。 GAS の記述 先程テーブルを作成したスプレッドシートの拡張機能 →Apps Script を開きます。 App Script 上で新しく「.gs」ファイルを作成し、「CallHistory」 のシートが更新されたときだけ、Slack に通知するように GAS を記述します。 function onChange ( e ) { // イベントが"EDIT"の場合のみ実行。 if ( e . changeType === "EDIT" ) { const ar = e . source . getActiveRange (); const sheet = e . source . getActiveSheet (); // CallHistory シートが更新された場合のみ Slack に通知する if ( e . source . getSheetName () == "CallHistory" ) { const inquiry = sheet . getRange ( ar . getRow (), 4 ). getValue (); const slackWebHook = sheet . getRange ( ar . getRow (), 5 ). getValue (); const clientName = sheet . getRange ( ar . getRow (), 7 ). getValue (); notifyToSlack ( slackWebHook , "コーポカウンター呼び鈴" , ":notification_bell:" , // お好きな Slack の絵文字を設定して下さい。 `<!here> ${ clientName } さんが ${ inquiry } で呼び出ししています。` ); } } } function notifyToSlack ( url , username , icon , message ) { const jsonData = { username: username , icon_emoji: icon , text: message , }; const payload = JSON . stringify ( jsonData ); const options = { method: "post" , contentType: "application/json" , payload: payload , }; UrlFetchApp . fetch ( url , options ); } トリガーの設定 スプレッドシートに呼出履歴が登録（行追加）されたら、 onChange() を実行するように設定します。 問題なく動作すると、Slack に以下のようなメッセージが通知されます。 実装する上で難しかったこと AppSheet でアプリを開発するにあたり、ノーコード開発の制約でかゆいところに手が届かず、いくつか工夫して実装する必要がありました。 1. 氏名の選択結果を保持したまま、依頼内容選択の結果を「CallHistory」に書き出すこと AppSheet が複数の選択結果を保持できるような仕組みになっておらず、依頼者選択画面から依頼内容一覧画面に遷移すると選択結果が消えるため、依頼者選択結果をデータとしてどこかに保持する必要がありました。 → 氏名の選択結果を格納する一行だけのテーブル「Client」を作成し、「CallHistory」への書き出し時に「Client」の一行目のデータを読むように設定しました。 2. ボタンの配置と表示が変更できないこと 基本的にボタンに表示されているテキストは変更できず、ボタン位置も自由に変更できないため（画面の最上部か最下部のみ）、画面の設計には苦労しました。 → テキストに関しては、Settings → Views → Localization で「Save」を「次へ」に変更して対応しました。 ボタン位置に関してはどうにもならなかったため、なるべく導線がわかりやすいように画面上に説明を入れるようにしています。 ノーコードがゆえの制約はありますが、AppSheet での開発は簡単かつ迅速にできるため、小規模なアプリケーションであれば、おすすめの環境です。 以上、呼び鈴アプリの開発についてお話しました。 ここからは、コーポレート IT についてご紹介していきます。 コーポレート IT について コーポレートデザイン部は、 「未来志向で社内の IT インフラを含めたオフィス環境をデザインすること」 をミッションに業務しており、現在 2 つのチームがあります。 一つはワークプレイスチームで、ペン一本からオフィス施工に関することまで、オフィス環境全般を担当しています。 そして、もう一つがコーポレート IT チームで、全社で利用する SaaS の管理やオフィスのネットワークインフラ、社内アプリの開発等、全従業員が利用する IT ソリューション全般の企画・開発・運用を担当しています。 コーポレート IT の役割 コーポレート IT としてのミッションは、**「テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図ること」**です。 そのために、単に上流・下流というフェーズ分担ではなく、システム導入だけでもない、全社の組織カルチャーづくりも見据えた全従業員が利用するコーポレート基盤をデザインし、そのデザインに基づいて IT ソリューションを実装、運用していきます。 逆に、各部門のミッション達成、業務目的達成のための個別の IT ソリューションは、ツールゆえ各部門が主管です。コーポレート IT は IT プロフェッショナルとしてアドバイスしたり、システム設計や実装する形で、技術的実現を担うものとして各部門とコラボします。 各部門の IT ソリューションに対する PDCA を各部門がオーナーシップを持つことで、利用時の要望や改善に対して、非常に早いサイクルで実施することができています。 業務内容紹介 コーポレート IT では、日々の従業員への IT サポート以外に、複数のプロジェクトが同時に走っています。以下に記載している業務はほんの一例です。 端末管理アプリケーションおよびセキュリティ製品の企画/導入/運用 オフィス移転でのネットワーク構築（ネットワークの設計、機器選定〜運用まで） 社外来客用受付システムの改修/運用 呼び鈴アプリの企画/開発/運用 従業員向けの情報セキュリティ研修 人事基幹システムの導入支援/各システムとの連携機能構築 etc また、メンバー自ら提案して企画化、予算を確保することもあり、アイデアに対して柔軟に対応しています。 業務を行う上で常に意識していること・大事にしていること コーポレート IT として業務を行う上で大事にしている考え方が、3 つあります。従業員の生産性が向上する環境の構築に必要不可欠と考えており、これらをもとに意思決定しています。 1. システム選定/技術選定の考え方 システム選定/技術選定の原則としては、グローバルトップシェアで、かつ、北米急成長企業が選定しているものを未来志向で活用していくことを意識していますが、その技術やツールを導入して、得たい本来の目的が達成できるかどうかを、広い視点から判断して意思決定しています。 2. ユーザー IT サポートの考え方 老子が言っている『授人以魚 不如授人以漁(人に魚を授けることは、漁の仕方を教えるに及ばない)』ということを大切にしており、「わからない」という人に単に答えを「教える」ことをせず、組織の未来のために、組織全体の IT リテラシーを上げること、スムーズに自己解決できる環境を整えることに努めています。 「ユーザー IT サポートが増え続け、サポート人件費が増大し、高コストな生産性の低いコーポレート IT チーム」とならないよう心がけています。 3. ルールを作らず、仕組み/仕掛けで解決する ルールを覚えなくても、意識しなくとも、狙ったことが自然に進むよう、仕組み/仕掛けによって目的を成す方法を作ることを意識しています。 例えば、高速道路のサービスエリアにある駐車場の逆走を禁止するために斜めに駐車位置ラインを引くといった、意識せずとも行動を一定方向に促す行動設計が望ましく、呼び鈴アプリもそういった仕掛けやプロセス設計の一環です。 さいごに コーポレート IT は全従業員が利用する IT 基盤の維持・改善が求められるため、非常に重要な役割です。また、急拡大する組織の中においては、今までの仕組みが通用しなくなり、未来志向で新たな仕組みを設計し続けていく必要があり、常にコーポレート IT チームの活躍の余地がたくさん存在しています。 そのため、未来志向で #革新と改善を主導 できる方を絶賛募集しております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。様々な業種でスペシャリストを募集しています。興味がある方は是非ご連絡ください。医療という社会貢献性の高い領域へ、一緒に挑戦しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。コーポレートデザイン部でコーポレート IT を担当している清水です。 コーポレート IT では全従業員が利用するネットワークインフラや SaaS といった IT 全般を統括しており、社内で発生している課題について IT を駆使して解決しています。 今回は、こうした課題解決の一例として、「 呼び鈴アプリ 」の開発について背景と実装のご紹介をし、最後に コーポレート IT チーム の業務内容や理念についてご紹介したいと思います。 呼び鈴アプリの開発背景 弊社では、チャットツールである「 Slack 」と「 Google Workspace 」や「 TeamSpirit 」等を連携して、来客者受付システムや 稟議ワークフローシステム 、オフィス空調最適化システム等、チャットをベースにした業務運用（ChatOps）を数多く行っています。 今回はその中でも、サポートを受けたい場合にコーポレート部門の担当者を呼び出しできるアプリ、 通称：呼び鈴アプリ をご紹介しようと思います。 呼び鈴アプリ導入前の困りごと IT 備品や健康保険証等の物の受け渡しや PC トラブルへの対応など、従業員へのサポート対応の際、サポートを依頼した従業員とコーポレート部門との間で、以下のような困りごとが発生していました。 ■ 従業員側の困りごと ・誰に話しかけたらよいかわからない IT 備品や健康保険証等を受け取りにコーポレート部門の座席に来たが、誰に話しかけたらよいかわからず、ウロウロしている方が結構いました。結果、別の部門に話しかけて、別の部門の方が正しい部門に案内するという時間も発生していました。 ・時間調整に手間がかかる PC トラブルへの対応の際は、コーポレート IT の担当者が依頼者の席まで行って作業をしていたため、担当者と依頼者で時間の調整が必要でした。直前で都合が悪くなり、リスケが発生することもしばしばありました。 ■ コーポレート部門の困りごと ・依頼者が見つけづらい 座席表を見て依頼者のところまで行くが、直近で座席変更があって居ると思っていたところに居ないことや、指定の時間に席に居ないといったことが度々発生していました。 ・個人情報が見えると困る 従業員が人事部から健康保険証等の書類を受け取る際、人事部の方は個人情報を扱うため、PC 画面の見える位置まで来られると困るという事情があり、特定の位置で待ってもらいたいというニーズがありました。 ・従業員の氏名確認に手間がかかる 全従業員分の氏名は把握できないため、コーポレート部門に来た従業員本人に名前を聞いて確認し、一旦席に戻って、貸与する IT 備品や健康保険証等を探して渡すという、席を行ったり来たりする状況でした。 ・周りの業務状況に配慮が必要 依頼者の席で PC トラブル対応をすると、周りの人が業務に集中していたり、顧客と電話していたりするため、業務に支障がでないようになるべく小声で話す必要がありました。 ・依頼者への対応が属人化しがち コーポレート部門の担当者と依頼者の間で作業の時間を調整していましたが、担当者が急な打ち合わせやお休みで不在になってしまったときは、他の担当者への引き継ぎ対応が漏れてしまうことがありました。 上記の課題を解決するために、 従業員の方向けにコーポレート部門の担当者を呼び出すアプリ を作りました！ どういったアプリか 呼び鈴アプリは、従業員とコーポレート部門で対面での作業/受け渡しが発生すること（PC トラブルへの対応/落とし物の受け渡し/健康保険証のお渡し等）に関して、iPad で依頼内容に応じた コーポレート部門の担当者を呼び出すことができるアプリ です。 コーポレート部門の近くのカウンターの上に iPad が置いてあり、そこから呼び出してもらいます。 ちなみに、カウンターはこんな感じのスペースで、従業員の方がセルフサービスで IT 備品交換を行えるブースもあります。 アプリの利用イメージ まず、従業員はカウンターまで行き、iPad の呼び鈴アプリから呼び出し依頼を行います。 呼び出し依頼は専用の Slack チャンネルに通知が来るので、各コーポレート部門の担当者が通知内容を確認して、従業員が居るカウンターに行き、対応という流れになります。 画面イメージ 利用方法は、自身の名前を選択してもらい、コーポレート部門への依頼内容を選択するという形です。 導入後の効果 呼び鈴アプリの導入によって、 従業員がコーポレート部門からサポートを受けたり、物を受け渡ししたいときは、 自身が都合の良いタイミングで カウンターの呼び鈴アプリに来れば良く、 利便性が向上した 。 Slack 通知に依頼者氏名が表示されるので、 氏名を確認する必要がなくなった。 コーポレート部門の担当者が 依頼者の席を探して尋ねなくてよくなった。 というように困りごとが改善されました。 また、特定のメンバーが対応するのではなく、呼び出されたタイミングで席に居る全メンバーが対応できるような運用にすることで、PC/IT 備品や健康保険証等の物の受け渡し、PC のトラブル対応等のサポート対応が属人的にならず、離席していても、休暇をとっていても誰でも対応できる体制になりました。 呼び鈴アプリの構成 呼び鈴アプリの開発にあたっては 1. 先述の課題を解決すること 2. コーポレート IT 内でプロジェクトが複数動いているため、他のプロジェクトの進捗に影響がでないように、工数をさほどかけずにクイックに開発できること 3. なるべくランニングコストをかけないこと という要件から、 AppSheet と Google App Script（以降 GAS） で実装することを決めました。 機能検証期間を含めて 1 週間程度で実装できています。 AppSheet は、Google から提供されている、ノーコードでアプリケーション開発ができるツールです。 AppSheet は、エンジニアではなく「現場で働く人が作る」という思想をもとにサービスが開始されました。そのため、プログラミング知識がない人でも、マウス操作のみで簡単にアプリケーションを開発できるようになっています。 サービス連携図 UI を AppSheet で、Slack への通知を GAS で実装しています。 画面構成 画面は依頼者選択画面、依頼内容一覧画面、依頼詳細一覧画面の３画面で構成しています。 呼び鈴アプリの実装 呼び鈴アプリをどのように実装しているか解説していきます。 AppSheet の設定 AppSheet を利用したアプリの作成方法については、Google 公式の How to create an app や Google で AppSheet を検索するといくつか作成例のサイトが表示されますので、今回の機能を実装するにあたり重要な 「依頼詳細一覧画面から Slack 通知」 設定の部分にフォーカスして解説します。 1. Data の設定 Tables と Slices について、それぞれ設定します。 Tables では、アプリケーションの元となるデータを格納する「テーブル」を作成します。 Slices では、テーブルから必要な行と列のみを表示させたり、条件にあうデータのみを表示させたりして、必要なデータを抽出した「テーブルの一部分」を作成します。 1-1. Tables の設定 今回 Table は以下の 5 つを用意しました。 テーブルは、スプレッドシートにテーブルとなるデータを作成した後、AppSheet と連携します。連携方法は Connect your data to AppSheet の動画を参考にしてください。 テーブル名 利用用途 Client 依頼者選択画面で選択されたユーザー名を一時的に保存するテーブル Doorbell 依頼内容一覧画面に表示するテーブル DoorbellDetails 依頼詳細一覧画面に表示するテーブル CallHistory 呼出履歴を保存するテーブル UserList 依頼者選択画面に表示するテーブル 依頼詳細一覧画面と呼び出し機能に関連する、「DoorbellDetails」と「CallHistory」について詳しく説明します。 ・ DoorbellDetails 依頼詳細一覧画面に表示したい内容を一覧で記載します。 分類 ID 列は Doorbell でも同名の列を作成し、そこで設定した値と合わせてください。また、対応 ID は分類 ID 内でユニークになるように設定してください。 対応説明に関しては、任意で入力していただければ大丈夫です。 SlackChannel 列に Slack チャンネルに投稿する用の Webhook URL を設定してください。 Incoming Webhooks 等を使用すると、 Webhook URL が取得できます。 3 行目以降のデータは、 2 行目を参考に設定してください。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 1 分類 ID 対応 ID 対応名 対応説明 SlackChannel 2 receipt 1 入社にあたって貸与物を受け取りたい （通知先チャンネルの Webhook URL を設定） Table での設定例 分類 ID と対応 ID を複合キー（分類 ID と対応 ID に「REQUIRE」を設定）としています。 ・ CallHistory 呼出履歴を保存するテーブルのため、ヘッダー以外の入力は不要です。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 F 列 G 列 1 CH_id CH_分類 ID CH_対応 ID CH_対応名 CH_SlackChannel CH_呼び出し日時 CH_依頼者 Table での設定例 1-2. Slices の設定 次に、Slice の設定を行います。Slice は依頼内容ごとに画面表示を切り替えるために「DoorbellDetails」のデータを元に作成します。 貸与物受け取りに関する Slice の場合、以下のように設定します。 設定項目名 設定値 Slice name 貸与物受け取り Source table DoorbellDetails Row filter condition [分類 ID]="receipt" 2. App の設定 Views について、それぞれ設定します。 2-1. Views の設定 依頼詳細一覧画面について詳しく説明します。 ・依頼詳細一覧画面 依頼内容一覧画面から遷移できるように、依頼詳細一覧画面は依頼内容ごとに準備します。ここでは貸与物受け取り画面を例として設定しています。 設定項目名 設定値 View name 貸与物受け取り画面 For this data 貸与物受け取り View type deck Position ref Primary header _RowNumber Secondary header 対応名 Event Actions(Row Selected) SaveAndMoveToClientForm（Actions の設定後、設定可能になります） 3. Actions の設定 各ボタンを押したときの動作を定義します。 実際には他にもいくつか Action を設定していますが、Slack 通知に関係する Action は以下の 3 つです。 Action 名 利用用途 MoveToClientForm 依頼者選択画面に遷移する SaveCallHistory CallHistory にデータを保存する SaveAndMoveToClientForm CallHistory に保存後、依頼者選択画面に遷移する ・ MoveToClientForm 依頼者選択画面に遷移する Action です。 設定項目名 設定値 Action name MoveToClientForm For a record of this table DoorbellDetails Do this App: go to another view within this app Target ”#view=依頼者選択” ・ SaveCallHistory 「CallHistory」テーブルにデータを保存する Action です。 選択された氏名については「Client」テーブルからデータを取得しています。 また、SlackChannel 列の記載がない場合は、画面に「呼び出し」ボタンを表示させないように設定しています。 設定項目名 設定値 Action name SaveCallHistory For a record of this table DoorbellDetails Do this Data: add a new row to another table using values from this row Set these columns CH_id = UNIQUEID() CH_分類 ID = [分類 ID] CH_対応 ID = [対応 ID] CH_対応名 = [対応名] CH_SlackChannel = [SlackChannel] CH_呼び出し日次 = TODAY() & ” ” & TIMENOW() CH_依頼者 = Client[ご自身の氏名] Display name 呼び出し Only if this condition is true ISNOTBLANK([SlackChannel]) Needs confirmation? True Confirmation Message CONCATENATE(“依頼者：“,Client[ご自身の氏名],"",“呼び出し内容：”,[対応名],"",“担当者を呼び出しますか？”) ・ SaveAndMoveToClientForm 呼出履歴に保存後、依頼者選択画面に遷移する Action です。この Action を依頼詳細一覧画面の Event Actions に紐付けます。 設定項目名 設定値 Action name SaveAndMoveToClientForm For a record of this table DoorbellDetails Do this Grouped: execute a sequence of actions Actions SaveCallHistory MoveToClientForm スプレッドシート の設定 AppSheet からスプレッドシートの「CallHistory」シートに呼出履歴データが登録（行追加）されたら、Slack 通知 GAS を実行するように設定します。 GAS の記述 先程テーブルを作成したスプレッドシートの拡張機能 →Apps Script を開きます。 App Script 上で新しく「.gs」ファイルを作成し、「CallHistory」 のシートが更新されたときだけ、Slack に通知するように GAS を記述します。 function onChange ( e ) { // イベントが"EDIT"の場合のみ実行。 if ( e . changeType === "EDIT" ) { const ar = e . source . getActiveRange (); const sheet = e . source . getActiveSheet (); // CallHistory シートが更新された場合のみ Slack に通知する if ( e . source . getSheetName () == "CallHistory" ) { const inquiry = sheet . getRange ( ar . getRow (), 4 ). getValue (); const slackWebHook = sheet . getRange ( ar . getRow (), 5 ). getValue (); const clientName = sheet . getRange ( ar . getRow (), 7 ). getValue (); notifyToSlack ( slackWebHook , "コーポカウンター呼び鈴" , ":notification_bell:" , // お好きな Slack の絵文字を設定して下さい。 `<!here> ${ clientName } さんが ${ inquiry } で呼び出ししています。` ); } } } function notifyToSlack ( url , username , icon , message ) { const jsonData = { username: username , icon_emoji: icon , text: message , }; const payload = JSON . stringify ( jsonData ); const options = { method: "post" , contentType: "application/json" , payload: payload , }; UrlFetchApp . fetch ( url , options ); } トリガーの設定 スプレッドシートに呼出履歴が登録（行追加）されたら、 onChange() を実行するように設定します。 問題なく動作すると、Slack に以下のようなメッセージが通知されます。 実装する上で難しかったこと AppSheet でアプリを開発するにあたり、ノーコード開発の制約でかゆいところに手が届かず、いくつか工夫して実装する必要がありました。 1. 氏名の選択結果を保持したまま、依頼内容選択の結果を「CallHistory」に書き出すこと AppSheet が複数の選択結果を保持できるような仕組みになっておらず、依頼者選択画面から依頼内容一覧画面に遷移すると選択結果が消えるため、依頼者選択結果をデータとしてどこかに保持する必要がありました。 → 氏名の選択結果を格納する一行だけのテーブル「Client」を作成し、「CallHistory」への書き出し時に「Client」の一行目のデータを読むように設定しました。 2. ボタンの配置と表示が変更できないこと 基本的にボタンに表示されているテキストは変更できず、ボタン位置も自由に変更できないため（画面の最上部か最下部のみ）、画面の設計には苦労しました。 → テキストに関しては、Settings → Views → Localization で「Save」を「次へ」に変更して対応しました。 ボタン位置に関してはどうにもならなかったため、なるべく導線がわかりやすいように画面上に説明を入れるようにしています。 ノーコードがゆえの制約はありますが、AppSheet での開発は簡単かつ迅速にできるため、小規模なアプリケーションであれば、おすすめの環境です。 以上、呼び鈴アプリの開発についてお話しました。 ここからは、コーポレート IT についてご紹介していきます。 コーポレート IT について コーポレートデザイン部は、 「未来志向で社内の IT インフラを含めたオフィス環境をデザインすること」 をミッションに業務しており、現在 2 つのチームがあります。 一つはワークプレイスチームで、ペン一本からオフィス施工に関することまで、オフィス環境全般を担当しています。 そして、もう一つがコーポレート IT チームで、全社で利用する SaaS の管理やオフィスのネットワークインフラ、社内アプリの開発等、全従業員が利用する IT ソリューション全般の企画・開発・運用を担当しています。 コーポレート IT の役割 コーポレート IT としてのミッションは、**「テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図ること」**です。 そのために、単に上流・下流というフェーズ分担ではなく、システム導入だけでもない、全社の組織カルチャーづくりも見据えた全従業員が利用するコーポレート基盤をデザインし、そのデザインに基づいて IT ソリューションを実装、運用していきます。 逆に、各部門のミッション達成、業務目的達成のための個別の IT ソリューションは、ツールゆえ各部門が主管です。コーポレート IT は IT プロフェッショナルとしてアドバイスしたり、システム設計や実装する形で、技術的実現を担うものとして各部門とコラボします。 各部門の IT ソリューションに対する PDCA を各部門がオーナーシップを持つことで、利用時の要望や改善に対して、非常に早いサイクルで実施することができています。 業務内容紹介 コーポレート IT では、日々の従業員への IT サポート以外に、複数のプロジェクトが同時に走っています。以下に記載している業務はほんの一例です。 端末管理アプリケーションおよびセキュリティ製品の企画/導入/運用 オフィス移転でのネットワーク構築（ネットワークの設計、機器選定〜運用まで） 社外来客用受付システムの改修/運用 呼び鈴アプリの企画/開発/運用 従業員向けの情報セキュリティ研修 人事基幹システムの導入支援/各システムとの連携機能構築 etc また、メンバー自ら提案して企画化、予算を確保することもあり、アイデアに対して柔軟に対応しています。 業務を行う上で常に意識していること・大事にしていること コーポレート IT として業務を行う上で大事にしている考え方が、3 つあります。従業員の生産性が向上する環境の構築に必要不可欠と考えており、これらをもとに意思決定しています。 1. システム選定/技術選定の考え方 システム選定/技術選定の原則としては、グローバルトップシェアで、かつ、北米急成長企業が選定しているものを未来志向で活用していくことを意識していますが、その技術やツールを導入して、得たい本来の目的が達成できるかどうかを、広い視点から判断して意思決定しています。 2. ユーザー IT サポートの考え方 老子が言っている『授人以魚 不如授人以漁(人に魚を授けることは、漁の仕方を教えるに及ばない)』ということを大切にしており、「わからない」という人に単に答えを「教える」ことをせず、組織の未来のために、組織全体の IT リテラシーを上げること、スムーズに自己解決できる環境を整えることに努めています。 「ユーザー IT サポートが増え続け、サポート人件費が増大し、高コストな生産性の低いコーポレート IT チーム」とならないよう心がけています。 3. ルールを作らず、仕組み/仕掛けで解決する ルールを覚えなくても、意識しなくとも、狙ったことが自然に進むよう、仕組み/仕掛けによって目的を成す方法を作ることを意識しています。 例えば、高速道路のサービスエリアにある駐車場の逆走を禁止するために斜めに駐車位置ラインを引くといった、意識せずとも行動を一定方向に促す行動設計が望ましく、呼び鈴アプリもそういった仕掛けやプロセス設計の一環です。 さいごに コーポレート IT は全従業員が利用する IT 基盤の維持・改善が求められるため、非常に重要な役割です。また、急拡大する組織の中においては、今までの仕組みが通用しなくなり、未来志向で新たな仕組みを設計し続けていく必要があり、常にコーポレート IT チームの活躍の余地がたくさん存在しています。 そのため、未来志向で #革新と改善を主導 できる方を絶賛募集しております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。様々な業種でスペシャリストを募集しています。興味がある方は是非ご連絡ください。医療という社会貢献性の高い領域へ、一緒に挑戦しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。コーポレートデザイン部でコーポレート IT を担当している清水です。 コーポレート IT では全従業員が利用するネットワークインフラや SaaS といった IT 全般を統括しており、社内で発生している課題について IT を駆使して解決しています。 今回は、こうした課題解決の一例として、「 呼び鈴アプリ 」の開発について背景と実装のご紹介をし、最後に コーポレート IT チーム の業務内容や理念についてご紹介したいと思います。 呼び鈴アプリの開発背景 弊社では、チャットツールである「 Slack 」と「 Google Workspace 」や「 TeamSpirit 」等を連携して、来客者受付システムや 稟議ワークフローシステム 、オフィス空調最適化システム等、チャットをベースにした業務運用（ChatOps）を数多く行っています。 今回はその中でも、サポートを受けたい場合にコーポレート部門の担当者を呼び出しできるアプリ、 通称：呼び鈴アプリ をご紹介しようと思います。 呼び鈴アプリ導入前の困りごと IT 備品や健康保険証等の物の受け渡しや PC トラブルへの対応など、従業員へのサポート対応の際、サポートを依頼した従業員とコーポレート部門との間で、以下のような困りごとが発生していました。 ■ 従業員側の困りごと ・誰に話しかけたらよいかわからない IT 備品や健康保険証等を受け取りにコーポレート部門の座席に来たが、誰に話しかけたらよいかわからず、ウロウロしている方が結構いました。結果、別の部門に話しかけて、別の部門の方が正しい部門に案内するという時間も発生していました。 ・時間調整に手間がかかる PC トラブルへの対応の際は、コーポレート IT の担当者が依頼者の席まで行って作業をしていたため、担当者と依頼者で時間の調整が必要でした。直前で都合が悪くなり、リスケが発生することもしばしばありました。 ■ コーポレート部門の困りごと ・依頼者が見つけづらい 座席表を見て依頼者のところまで行くが、直近で座席変更があって居ると思っていたところに居ないことや、指定の時間に席に居ないといったことが度々発生していました。 ・個人情報が見えると困る 従業員が人事部から健康保険証等の書類を受け取る際、人事部の方は個人情報を扱うため、PC 画面の見える位置まで来られると困るという事情があり、特定の位置で待ってもらいたいというニーズがありました。 ・従業員の氏名確認に手間がかかる 全従業員分の氏名は把握できないため、コーポレート部門に来た従業員本人に名前を聞いて確認し、一旦席に戻って、貸与する IT 備品や健康保険証等を探して渡すという、席を行ったり来たりする状況でした。 ・周りの業務状況に配慮が必要 依頼者の席で PC トラブル対応をすると、周りの人が業務に集中していたり、顧客と電話していたりするため、業務に支障がでないようになるべく小声で話す必要がありました。 ・依頼者への対応が属人化しがち コーポレート部門の担当者と依頼者の間で作業の時間を調整していましたが、担当者が急な打ち合わせやお休みで不在になってしまったときは、他の担当者への引き継ぎ対応が漏れてしまうことがありました。 上記の課題を解決するために、 従業員の方向けにコーポレート部門の担当者を呼び出すアプリ を作りました！ どういったアプリか 呼び鈴アプリは、従業員とコーポレート部門で対面での作業/受け渡しが発生すること（PC トラブルへの対応/落とし物の受け渡し/健康保険証のお渡し等）に関して、iPad で依頼内容に応じた コーポレート部門の担当者を呼び出すことができるアプリ です。 コーポレート部門の近くのカウンターの上に iPad が置いてあり、そこから呼び出してもらいます。 ちなみに、カウンターはこんな感じのスペースで、従業員の方がセルフサービスで IT 備品交換を行えるブースもあります。 アプリの利用イメージ まず、従業員はカウンターまで行き、iPad の呼び鈴アプリから呼び出し依頼を行います。 呼び出し依頼は専用の Slack チャンネルに通知が来るので、各コーポレート部門の担当者が通知内容を確認して、従業員が居るカウンターに行き、対応という流れになります。 画面イメージ 利用方法は、自身の名前を選択してもらい、コーポレート部門への依頼内容を選択するという形です。 導入後の効果 呼び鈴アプリの導入によって、 従業員がコーポレート部門からサポートを受けたり、物を受け渡ししたいときは、 自身が都合の良いタイミングで カウンターの呼び鈴アプリに来れば良く、 利便性が向上した 。 Slack 通知に依頼者氏名が表示されるので、 氏名を確認する必要がなくなった。 コーポレート部門の担当者が 依頼者の席を探して尋ねなくてよくなった。 というように困りごとが改善されました。 また、特定のメンバーが対応するのではなく、呼び出されたタイミングで席に居る全メンバーが対応できるような運用にすることで、PC/IT 備品や健康保険証等の物の受け渡し、PC のトラブル対応等のサポート対応が属人的にならず、離席していても、休暇をとっていても誰でも対応できる体制になりました。 呼び鈴アプリの構成 呼び鈴アプリの開発にあたっては 1. 先述の課題を解決すること 2. コーポレート IT 内でプロジェクトが複数動いているため、他のプロジェクトの進捗に影響がでないように、工数をさほどかけずにクイックに開発できること 3. なるべくランニングコストをかけないこと という要件から、 AppSheet と Google App Script（以降 GAS） で実装することを決めました。 機能検証期間を含めて 1 週間程度で実装できています。 AppSheet は、Google から提供されている、ノーコードでアプリケーション開発ができるツールです。 AppSheet は、エンジニアではなく「現場で働く人が作る」という思想をもとにサービスが開始されました。そのため、プログラミング知識がない人でも、マウス操作のみで簡単にアプリケーションを開発できるようになっています。 サービス連携図 UI を AppSheet で、Slack への通知を GAS で実装しています。 画面構成 画面は依頼者選択画面、依頼内容一覧画面、依頼詳細一覧画面の３画面で構成しています。 呼び鈴アプリの実装 呼び鈴アプリをどのように実装しているか解説していきます。 AppSheet の設定 AppSheet を利用したアプリの作成方法については、Google 公式の How to create an app や Google で AppSheet を検索するといくつか作成例のサイトが表示されますので、今回の機能を実装するにあたり重要な 「依頼詳細一覧画面から Slack 通知」 設定の部分にフォーカスして解説します。 1. Data の設定 Tables と Slices について、それぞれ設定します。 Tables では、アプリケーションの元となるデータを格納する「テーブル」を作成します。 Slices では、テーブルから必要な行と列のみを表示させたり、条件にあうデータのみを表示させたりして、必要なデータを抽出した「テーブルの一部分」を作成します。 1-1. Tables の設定 今回 Table は以下の 5 つを用意しました。 テーブルは、スプレッドシートにテーブルとなるデータを作成した後、AppSheet と連携します。連携方法は Connect your data to AppSheet の動画を参考にしてください。 テーブル名 利用用途 Client 依頼者選択画面で選択されたユーザー名を一時的に保存するテーブル Doorbell 依頼内容一覧画面に表示するテーブル DoorbellDetails 依頼詳細一覧画面に表示するテーブル CallHistory 呼出履歴を保存するテーブル UserList 依頼者選択画面に表示するテーブル 依頼詳細一覧画面と呼び出し機能に関連する、「DoorbellDetails」と「CallHistory」について詳しく説明します。 ・ DoorbellDetails 依頼詳細一覧画面に表示したい内容を一覧で記載します。 分類 ID 列は Doorbell でも同名の列を作成し、そこで設定した値と合わせてください。また、対応 ID は分類 ID 内でユニークになるように設定してください。 対応説明に関しては、任意で入力していただければ大丈夫です。 SlackChannel 列に Slack チャンネルに投稿する用の Webhook URL を設定してください。 Incoming Webhooks 等を使用すると、 Webhook URL が取得できます。 3 行目以降のデータは、 2 行目を参考に設定してください。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 1 分類 ID 対応 ID 対応名 対応説明 SlackChannel 2 receipt 1 入社にあたって貸与物を受け取りたい （通知先チャンネルの Webhook URL を設定） Table での設定例 分類 ID と対応 ID を複合キー（分類 ID と対応 ID に「REQUIRE」を設定）としています。 ・ CallHistory 呼出履歴を保存するテーブルのため、ヘッダー以外の入力は不要です。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 F 列 G 列 1 CH_id CH_分類 ID CH_対応 ID CH_対応名 CH_SlackChannel CH_呼び出し日時 CH_依頼者 Table での設定例 1-2. Slices の設定 次に、Slice の設定を行います。Slice は依頼内容ごとに画面表示を切り替えるために「DoorbellDetails」のデータを元に作成します。 貸与物受け取りに関する Slice の場合、以下のように設定します。 設定項目名 設定値 Slice name 貸与物受け取り Source table DoorbellDetails Row filter condition [分類 ID]="receipt" 2. App の設定 Views について、それぞれ設定します。 2-1. Views の設定 依頼詳細一覧画面について詳しく説明します。 ・依頼詳細一覧画面 依頼内容一覧画面から遷移できるように、依頼詳細一覧画面は依頼内容ごとに準備します。ここでは貸与物受け取り画面を例として設定しています。 設定項目名 設定値 View name 貸与物受け取り画面 For this data 貸与物受け取り View type deck Position ref Primary header _RowNumber Secondary header 対応名 Event Actions(Row Selected) SaveAndMoveToClientForm（Actions の設定後、設定可能になります） 3. Actions の設定 各ボタンを押したときの動作を定義します。 実際には他にもいくつか Action を設定していますが、Slack 通知に関係する Action は以下の 3 つです。 Action 名 利用用途 MoveToClientForm 依頼者選択画面に遷移する SaveCallHistory CallHistory にデータを保存する SaveAndMoveToClientForm CallHistory に保存後、依頼者選択画面に遷移する ・ MoveToClientForm 依頼者選択画面に遷移する Action です。 設定項目名 設定値 Action name MoveToClientForm For a record of this table DoorbellDetails Do this App: go to another view within this app Target ”#view=依頼者選択” ・ SaveCallHistory 「CallHistory」テーブルにデータを保存する Action です。 選択された氏名については「Client」テーブルからデータを取得しています。 また、SlackChannel 列の記載がない場合は、画面に「呼び出し」ボタンを表示させないように設定しています。 設定項目名 設定値 Action name SaveCallHistory For a record of this table DoorbellDetails Do this Data: add a new row to another table using values from this row Set these columns CH_id = UNIQUEID() CH_分類 ID = [分類 ID] CH_対応 ID = [対応 ID] CH_対応名 = [対応名] CH_SlackChannel = [SlackChannel] CH_呼び出し日次 = TODAY() & ” ” & TIMENOW() CH_依頼者 = Client[ご自身の氏名] Display name 呼び出し Only if this condition is true ISNOTBLANK([SlackChannel]) Needs confirmation? True Confirmation Message CONCATENATE(“依頼者：“,Client[ご自身の氏名],"",“呼び出し内容：”,[対応名],"",“担当者を呼び出しますか？”) ・ SaveAndMoveToClientForm 呼出履歴に保存後、依頼者選択画面に遷移する Action です。この Action を依頼詳細一覧画面の Event Actions に紐付けます。 設定項目名 設定値 Action name SaveAndMoveToClientForm For a record of this table DoorbellDetails Do this Grouped: execute a sequence of actions Actions SaveCallHistory MoveToClientForm スプレッドシート の設定 AppSheet からスプレッドシートの「CallHistory」シートに呼出履歴データが登録（行追加）されたら、Slack 通知 GAS を実行するように設定します。 GAS の記述 先程テーブルを作成したスプレッドシートの拡張機能 →Apps Script を開きます。 App Script 上で新しく「.gs」ファイルを作成し、「CallHistory」 のシートが更新されたときだけ、Slack に通知するように GAS を記述します。 function onChange ( e ) { // イベントが"EDIT"の場合のみ実行。 if ( e . changeType === "EDIT" ) { const ar = e . source . getActiveRange (); const sheet = e . source . getActiveSheet (); // CallHistory シートが更新された場合のみ Slack に通知する if ( e . source . getSheetName () == "CallHistory" ) { const inquiry = sheet . getRange ( ar . getRow (), 4 ). getValue (); const slackWebHook = sheet . getRange ( ar . getRow (), 5 ). getValue (); const clientName = sheet . getRange ( ar . getRow (), 7 ). getValue (); notifyToSlack ( slackWebHook , "コーポカウンター呼び鈴" , ":notification_bell:" , // お好きな Slack の絵文字を設定して下さい。 `<!here> ${ clientName } さんが ${ inquiry } で呼び出ししています。` ); } } } function notifyToSlack ( url , username , icon , message ) { const jsonData = { username: username , icon_emoji: icon , text: message , }; const payload = JSON . stringify ( jsonData ); const options = { method: "post" , contentType: "application/json" , payload: payload , }; UrlFetchApp . fetch ( url , options ); } トリガーの設定 スプレッドシートに呼出履歴が登録（行追加）されたら、 onChange() を実行するように設定します。 問題なく動作すると、Slack に以下のようなメッセージが通知されます。 実装する上で難しかったこと AppSheet でアプリを開発するにあたり、ノーコード開発の制約でかゆいところに手が届かず、いくつか工夫して実装する必要がありました。 1. 氏名の選択結果を保持したまま、依頼内容選択の結果を「CallHistory」に書き出すこと AppSheet が複数の選択結果を保持できるような仕組みになっておらず、依頼者選択画面から依頼内容一覧画面に遷移すると選択結果が消えるため、依頼者選択結果をデータとしてどこかに保持する必要がありました。 → 氏名の選択結果を格納する一行だけのテーブル「Client」を作成し、「CallHistory」への書き出し時に「Client」の一行目のデータを読むように設定しました。 2. ボタンの配置と表示が変更できないこと 基本的にボタンに表示されているテキストは変更できず、ボタン位置も自由に変更できないため（画面の最上部か最下部のみ）、画面の設計には苦労しました。 → テキストに関しては、Settings → Views → Localization で「Save」を「次へ」に変更して対応しました。 ボタン位置に関してはどうにもならなかったため、なるべく導線がわかりやすいように画面上に説明を入れるようにしています。 ノーコードがゆえの制約はありますが、AppSheet での開発は簡単かつ迅速にできるため、小規模なアプリケーションであれば、おすすめの環境です。 以上、呼び鈴アプリの開発についてお話しました。 ここからは、コーポレート IT についてご紹介していきます。 コーポレート IT について コーポレートデザイン部は、 「未来志向で社内の IT インフラを含めたオフィス環境をデザインすること」 をミッションに業務しており、現在 2 つのチームがあります。 一つはワークプレイスチームで、ペン一本からオフィス施工に関することまで、オフィス環境全般を担当しています。 そして、もう一つがコーポレート IT チームで、全社で利用する SaaS の管理やオフィスのネットワークインフラ、社内アプリの開発等、全従業員が利用する IT ソリューション全般の企画・開発・運用を担当しています。 コーポレート IT の役割 コーポレート IT としてのミッションは、**「テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図ること」**です。 そのために、単に上流・下流というフェーズ分担ではなく、システム導入だけでもない、全社の組織カルチャーづくりも見据えた全従業員が利用するコーポレート基盤をデザインし、そのデザインに基づいて IT ソリューションを実装、運用していきます。 逆に、各部門のミッション達成、業務目的達成のための個別の IT ソリューションは、ツールゆえ各部門が主管です。コーポレート IT は IT プロフェッショナルとしてアドバイスしたり、システム設計や実装する形で、技術的実現を担うものとして各部門とコラボします。 各部門の IT ソリューションに対する PDCA を各部門がオーナーシップを持つことで、利用時の要望や改善に対して、非常に早いサイクルで実施することができています。 業務内容紹介 コーポレート IT では、日々の従業員への IT サポート以外に、複数のプロジェクトが同時に走っています。以下に記載している業務はほんの一例です。 端末管理アプリケーションおよびセキュリティ製品の企画/導入/運用 オフィス移転でのネットワーク構築（ネットワークの設計、機器選定〜運用まで） 社外来客用受付システムの改修/運用 呼び鈴アプリの企画/開発/運用 従業員向けの情報セキュリティ研修 人事基幹システムの導入支援/各システムとの連携機能構築 etc また、メンバー自ら提案して企画化、予算を確保することもあり、アイデアに対して柔軟に対応しています。 業務を行う上で常に意識していること・大事にしていること コーポレート IT として業務を行う上で大事にしている考え方が、3 つあります。従業員の生産性が向上する環境の構築に必要不可欠と考えており、これらをもとに意思決定しています。 1. システム選定/技術選定の考え方 システム選定/技術選定の原則としては、グローバルトップシェアで、かつ、北米急成長企業が選定しているものを未来志向で活用していくことを意識していますが、その技術やツールを導入して、得たい本来の目的が達成できるかどうかを、広い視点から判断して意思決定しています。 2. ユーザー IT サポートの考え方 老子が言っている『授人以魚 不如授人以漁(人に魚を授けることは、漁の仕方を教えるに及ばない)』ということを大切にしており、「わからない」という人に単に答えを「教える」ことをせず、組織の未来のために、組織全体の IT リテラシーを上げること、スムーズに自己解決できる環境を整えることに努めています。 「ユーザー IT サポートが増え続け、サポート人件費が増大し、高コストな生産性の低いコーポレート IT チーム」とならないよう心がけています。 3. ルールを作らず、仕組み/仕掛けで解決する ルールを覚えなくても、意識しなくとも、狙ったことが自然に進むよう、仕組み/仕掛けによって目的を成す方法を作ることを意識しています。 例えば、高速道路のサービスエリアにある駐車場の逆走を禁止するために斜めに駐車位置ラインを引くといった、意識せずとも行動を一定方向に促す行動設計が望ましく、呼び鈴アプリもそういった仕掛けやプロセス設計の一環です。 さいごに コーポレート IT は全従業員が利用する IT 基盤の維持・改善が求められるため、非常に重要な役割です。また、急拡大する組織の中においては、今までの仕組みが通用しなくなり、未来志向で新たな仕組みを設計し続けていく必要があり、常にコーポレート IT チームの活躍の余地がたくさん存在しています。 そのため、未来志向で #革新と改善を主導 できる方を絶賛募集しております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。様々な業種でスペシャリストを募集しています。興味がある方は是非ご連絡ください。医療という社会貢献性の高い領域へ、一緒に挑戦しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。コーポレートデザイン部でコーポレート IT を担当している清水です。 コーポレート IT では全従業員が利用するネットワークインフラや SaaS といった IT 全般を統括しており、社内で発生している課題について IT を駆使して解決しています。 今回は、こうした課題解決の一例として、「 呼び鈴アプリ 」の開発について背景と実装のご紹介をし、最後に コーポレート IT チーム の業務内容や理念についてご紹介したいと思います。 呼び鈴アプリの開発背景 弊社では、チャットツールである「 Slack 」と「 Google Workspace 」や「 TeamSpirit 」等を連携して、来客者受付システムや 稟議ワークフローシステム 、オフィス空調最適化システム等、チャットをベースにした業務運用（ChatOps）を数多く行っています。 今回はその中でも、サポートを受けたい場合にコーポレート部門の担当者を呼び出しできるアプリ、 通称：呼び鈴アプリ をご紹介しようと思います。 呼び鈴アプリ導入前の困りごと IT 備品や健康保険証等の物の受け渡しや PC トラブルへの対応など、従業員へのサポート対応の際、サポートを依頼した従業員とコーポレート部門との間で、以下のような困りごとが発生していました。 ■ 従業員側の困りごと ・誰に話しかけたらよいかわからない IT 備品や健康保険証等を受け取りにコーポレート部門の座席に来たが、誰に話しかけたらよいかわからず、ウロウロしている方が結構いました。結果、別の部門に話しかけて、別の部門の方が正しい部門に案内するという時間も発生していました。 ・時間調整に手間がかかる PC トラブルへの対応の際は、コーポレート IT の担当者が依頼者の席まで行って作業をしていたため、担当者と依頼者で時間の調整が必要でした。直前で都合が悪くなり、リスケが発生することもしばしばありました。 ■ コーポレート部門の困りごと ・依頼者が見つけづらい 座席表を見て依頼者のところまで行くが、直近で座席変更があって居ると思っていたところに居ないことや、指定の時間に席に居ないといったことが度々発生していました。 ・個人情報が見えると困る 従業員が人事部から健康保険証等の書類を受け取る際、人事部の方は個人情報を扱うため、PC 画面の見える位置まで来られると困るという事情があり、特定の位置で待ってもらいたいというニーズがありました。 ・従業員の氏名確認に手間がかかる 全従業員分の氏名は把握できないため、コーポレート部門に来た従業員本人に名前を聞いて確認し、一旦席に戻って、貸与する IT 備品や健康保険証等を探して渡すという、席を行ったり来たりする状況でした。 ・周りの業務状況に配慮が必要 依頼者の席で PC トラブル対応をすると、周りの人が業務に集中していたり、顧客と電話していたりするため、業務に支障がでないようになるべく小声で話す必要がありました。 ・依頼者への対応が属人化しがち コーポレート部門の担当者と依頼者の間で作業の時間を調整していましたが、担当者が急な打ち合わせやお休みで不在になってしまったときは、他の担当者への引き継ぎ対応が漏れてしまうことがありました。 上記の課題を解決するために、 従業員の方向けにコーポレート部門の担当者を呼び出すアプリ を作りました！ どういったアプリか 呼び鈴アプリは、従業員とコーポレート部門で対面での作業/受け渡しが発生すること（PC トラブルへの対応/落とし物の受け渡し/健康保険証のお渡し等）に関して、iPad で依頼内容に応じた コーポレート部門の担当者を呼び出すことができるアプリ です。 コーポレート部門の近くのカウンターの上に iPad が置いてあり、そこから呼び出してもらいます。 ちなみに、カウンターはこんな感じのスペースで、従業員の方がセルフサービスで IT 備品交換を行えるブースもあります。 アプリの利用イメージ まず、従業員はカウンターまで行き、iPad の呼び鈴アプリから呼び出し依頼を行います。 呼び出し依頼は専用の Slack チャンネルに通知が来るので、各コーポレート部門の担当者が通知内容を確認して、従業員が居るカウンターに行き、対応という流れになります。 画面イメージ 利用方法は、自身の名前を選択してもらい、コーポレート部門への依頼内容を選択するという形です。 導入後の効果 呼び鈴アプリの導入によって、 従業員がコーポレート部門からサポートを受けたり、物を受け渡ししたいときは、 自身が都合の良いタイミングで カウンターの呼び鈴アプリに来れば良く、 利便性が向上した 。 Slack 通知に依頼者氏名が表示されるので、 氏名を確認する必要がなくなった。 コーポレート部門の担当者が 依頼者の席を探して尋ねなくてよくなった。 というように困りごとが改善されました。 また、特定のメンバーが対応するのではなく、呼び出されたタイミングで席に居る全メンバーが対応できるような運用にすることで、PC/IT 備品や健康保険証等の物の受け渡し、PC のトラブル対応等のサポート対応が属人的にならず、離席していても、休暇をとっていても誰でも対応できる体制になりました。 呼び鈴アプリの構成 呼び鈴アプリの開発にあたっては 1. 先述の課題を解決すること 2. コーポレート IT 内でプロジェクトが複数動いているため、他のプロジェクトの進捗に影響がでないように、工数をさほどかけずにクイックに開発できること 3. なるべくランニングコストをかけないこと という要件から、 AppSheet と Google App Script（以降 GAS） で実装することを決めました。 機能検証期間を含めて 1 週間程度で実装できています。 AppSheet は、Google から提供されている、ノーコードでアプリケーション開発ができるツールです。 AppSheet は、エンジニアではなく「現場で働く人が作る」という思想をもとにサービスが開始されました。そのため、プログラミング知識がない人でも、マウス操作のみで簡単にアプリケーションを開発できるようになっています。 サービス連携図 UI を AppSheet で、Slack への通知を GAS で実装しています。 画面構成 画面は依頼者選択画面、依頼内容一覧画面、依頼詳細一覧画面の３画面で構成しています。 呼び鈴アプリの実装 呼び鈴アプリをどのように実装しているか解説していきます。 AppSheet の設定 AppSheet を利用したアプリの作成方法については、Google 公式の How to create an app や Google で AppSheet を検索するといくつか作成例のサイトが表示されますので、今回の機能を実装するにあたり重要な 「依頼詳細一覧画面から Slack 通知」 設定の部分にフォーカスして解説します。 1. Data の設定 Tables と Slices について、それぞれ設定します。 Tables では、アプリケーションの元となるデータを格納する「テーブル」を作成します。 Slices では、テーブルから必要な行と列のみを表示させたり、条件にあうデータのみを表示させたりして、必要なデータを抽出した「テーブルの一部分」を作成します。 1-1. Tables の設定 今回 Table は以下の 5 つを用意しました。 テーブルは、スプレッドシートにテーブルとなるデータを作成した後、AppSheet と連携します。連携方法は Connect your data to AppSheet の動画を参考にしてください。 テーブル名 利用用途 Client 依頼者選択画面で選択されたユーザー名を一時的に保存するテーブル Doorbell 依頼内容一覧画面に表示するテーブル DoorbellDetails 依頼詳細一覧画面に表示するテーブル CallHistory 呼出履歴を保存するテーブル UserList 依頼者選択画面に表示するテーブル 依頼詳細一覧画面と呼び出し機能に関連する、「DoorbellDetails」と「CallHistory」について詳しく説明します。 ・ DoorbellDetails 依頼詳細一覧画面に表示したい内容を一覧で記載します。 分類 ID 列は Doorbell でも同名の列を作成し、そこで設定した値と合わせてください。また、対応 ID は分類 ID 内でユニークになるように設定してください。 対応説明に関しては、任意で入力していただければ大丈夫です。 SlackChannel 列に Slack チャンネルに投稿する用の Webhook URL を設定してください。 Incoming Webhooks 等を使用すると、 Webhook URL が取得できます。 3 行目以降のデータは、 2 行目を参考に設定してください。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 1 分類 ID 対応 ID 対応名 対応説明 SlackChannel 2 receipt 1 入社にあたって貸与物を受け取りたい （通知先チャンネルの Webhook URL を設定） Table での設定例 分類 ID と対応 ID を複合キー（分類 ID と対応 ID に「REQUIRE」を設定）としています。 ・ CallHistory 呼出履歴を保存するテーブルのため、ヘッダー以外の入力は不要です。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 F 列 G 列 1 CH_id CH_分類 ID CH_対応 ID CH_対応名 CH_SlackChannel CH_呼び出し日時 CH_依頼者 Table での設定例 1-2. Slices の設定 次に、Slice の設定を行います。Slice は依頼内容ごとに画面表示を切り替えるために「DoorbellDetails」のデータを元に作成します。 貸与物受け取りに関する Slice の場合、以下のように設定します。 設定項目名 設定値 Slice name 貸与物受け取り Source table DoorbellDetails Row filter condition [分類 ID]="receipt" 2. App の設定 Views について、それぞれ設定します。 2-1. Views の設定 依頼詳細一覧画面について詳しく説明します。 ・依頼詳細一覧画面 依頼内容一覧画面から遷移できるように、依頼詳細一覧画面は依頼内容ごとに準備します。ここでは貸与物受け取り画面を例として設定しています。 設定項目名 設定値 View name 貸与物受け取り画面 For this data 貸与物受け取り View type deck Position ref Primary header _RowNumber Secondary header 対応名 Event Actions(Row Selected) SaveAndMoveToClientForm（Actions の設定後、設定可能になります） 3. Actions の設定 各ボタンを押したときの動作を定義します。 実際には他にもいくつか Action を設定していますが、Slack 通知に関係する Action は以下の 3 つです。 Action 名 利用用途 MoveToClientForm 依頼者選択画面に遷移する SaveCallHistory CallHistory にデータを保存する SaveAndMoveToClientForm CallHistory に保存後、依頼者選択画面に遷移する ・ MoveToClientForm 依頼者選択画面に遷移する Action です。 設定項目名 設定値 Action name MoveToClientForm For a record of this table DoorbellDetails Do this App: go to another view within this app Target ”#view=依頼者選択” ・ SaveCallHistory 「CallHistory」テーブルにデータを保存する Action です。 選択された氏名については「Client」テーブルからデータを取得しています。 また、SlackChannel 列の記載がない場合は、画面に「呼び出し」ボタンを表示させないように設定しています。 設定項目名 設定値 Action name SaveCallHistory For a record of this table DoorbellDetails Do this Data: add a new row to another table using values from this row Set these columns CH_id = UNIQUEID() CH_分類 ID = [分類 ID] CH_対応 ID = [対応 ID] CH_対応名 = [対応名] CH_SlackChannel = [SlackChannel] CH_呼び出し日次 = TODAY() & ” ” & TIMENOW() CH_依頼者 = Client[ご自身の氏名] Display name 呼び出し Only if this condition is true ISNOTBLANK([SlackChannel]) Needs confirmation? True Confirmation Message CONCATENATE(“依頼者：“,Client[ご自身の氏名],"",“呼び出し内容：”,[対応名],"",“担当者を呼び出しますか？”) ・ SaveAndMoveToClientForm 呼出履歴に保存後、依頼者選択画面に遷移する Action です。この Action を依頼詳細一覧画面の Event Actions に紐付けます。 設定項目名 設定値 Action name SaveAndMoveToClientForm For a record of this table DoorbellDetails Do this Grouped: execute a sequence of actions Actions SaveCallHistory MoveToClientForm スプレッドシート の設定 AppSheet からスプレッドシートの「CallHistory」シートに呼出履歴データが登録（行追加）されたら、Slack 通知 GAS を実行するように設定します。 GAS の記述 先程テーブルを作成したスプレッドシートの拡張機能 →Apps Script を開きます。 App Script 上で新しく「.gs」ファイルを作成し、「CallHistory」 のシートが更新されたときだけ、Slack に通知するように GAS を記述します。 function onChange ( e ) { // イベントが"EDIT"の場合のみ実行。 if ( e . changeType === "EDIT" ) { const ar = e . source . getActiveRange (); const sheet = e . source . getActiveSheet (); // CallHistory シートが更新された場合のみ Slack に通知する if ( e . source . getSheetName () == "CallHistory" ) { const inquiry = sheet . getRange ( ar . getRow (), 4 ). getValue (); const slackWebHook = sheet . getRange ( ar . getRow (), 5 ). getValue (); const clientName = sheet . getRange ( ar . getRow (), 7 ). getValue (); notifyToSlack ( slackWebHook , "コーポカウンター呼び鈴" , ":notification_bell:" , // お好きな Slack の絵文字を設定して下さい。 `<!here> ${ clientName } さんが ${ inquiry } で呼び出ししています。` ); } } } function notifyToSlack ( url , username , icon , message ) { const jsonData = { username: username , icon_emoji: icon , text: message , }; const payload = JSON . stringify ( jsonData ); const options = { method: "post" , contentType: "application/json" , payload: payload , }; UrlFetchApp . fetch ( url , options ); } トリガーの設定 スプレッドシートに呼出履歴が登録（行追加）されたら、 onChange() を実行するように設定します。 問題なく動作すると、Slack に以下のようなメッセージが通知されます。 実装する上で難しかったこと AppSheet でアプリを開発するにあたり、ノーコード開発の制約でかゆいところに手が届かず、いくつか工夫して実装する必要がありました。 1. 氏名の選択結果を保持したまま、依頼内容選択の結果を「CallHistory」に書き出すこと AppSheet が複数の選択結果を保持できるような仕組みになっておらず、依頼者選択画面から依頼内容一覧画面に遷移すると選択結果が消えるため、依頼者選択結果をデータとしてどこかに保持する必要がありました。 → 氏名の選択結果を格納する一行だけのテーブル「Client」を作成し、「CallHistory」への書き出し時に「Client」の一行目のデータを読むように設定しました。 2. ボタンの配置と表示が変更できないこと 基本的にボタンに表示されているテキストは変更できず、ボタン位置も自由に変更できないため（画面の最上部か最下部のみ）、画面の設計には苦労しました。 → テキストに関しては、Settings → Views → Localization で「Save」を「次へ」に変更して対応しました。 ボタン位置に関してはどうにもならなかったため、なるべく導線がわかりやすいように画面上に説明を入れるようにしています。 ノーコードがゆえの制約はありますが、AppSheet での開発は簡単かつ迅速にできるため、小規模なアプリケーションであれば、おすすめの環境です。 以上、呼び鈴アプリの開発についてお話しました。 ここからは、コーポレート IT についてご紹介していきます。 コーポレート IT について コーポレートデザイン部は、 「未来志向で社内の IT インフラを含めたオフィス環境をデザインすること」 をミッションに業務しており、現在 2 つのチームがあります。 一つはワークプレイスチームで、ペン一本からオフィス施工に関することまで、オフィス環境全般を担当しています。 そして、もう一つがコーポレート IT チームで、全社で利用する SaaS の管理やオフィスのネットワークインフラ、社内アプリの開発等、全従業員が利用する IT ソリューション全般の企画・開発・運用を担当しています。 コーポレート IT の役割 コーポレート IT としてのミッションは、**「テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図ること」**です。 そのために、単に上流・下流というフェーズ分担ではなく、システム導入だけでもない、全社の組織カルチャーづくりも見据えた全従業員が利用するコーポレート基盤をデザインし、そのデザインに基づいて IT ソリューションを実装、運用していきます。 逆に、各部門のミッション達成、業務目的達成のための個別の IT ソリューションは、ツールゆえ各部門が主管です。コーポレート IT は IT プロフェッショナルとしてアドバイスしたり、システム設計や実装する形で、技術的実現を担うものとして各部門とコラボします。 各部門の IT ソリューションに対する PDCA を各部門がオーナーシップを持つことで、利用時の要望や改善に対して、非常に早いサイクルで実施することができています。 業務内容紹介 コーポレート IT では、日々の従業員への IT サポート以外に、複数のプロジェクトが同時に走っています。以下に記載している業務はほんの一例です。 端末管理アプリケーションおよびセキュリティ製品の企画/導入/運用 オフィス移転でのネットワーク構築（ネットワークの設計、機器選定〜運用まで） 社外来客用受付システムの改修/運用 呼び鈴アプリの企画/開発/運用 従業員向けの情報セキュリティ研修 人事基幹システムの導入支援/各システムとの連携機能構築 etc また、メンバー自ら提案して企画化、予算を確保することもあり、アイデアに対して柔軟に対応しています。 業務を行う上で常に意識していること・大事にしていること コーポレート IT として業務を行う上で大事にしている考え方が、3 つあります。従業員の生産性が向上する環境の構築に必要不可欠と考えており、これらをもとに意思決定しています。 1. システム選定/技術選定の考え方 システム選定/技術選定の原則としては、グローバルトップシェアで、かつ、北米急成長企業が選定しているものを未来志向で活用していくことを意識していますが、その技術やツールを導入して、得たい本来の目的が達成できるかどうかを、広い視点から判断して意思決定しています。 2. ユーザー IT サポートの考え方 老子が言っている『授人以魚 不如授人以漁(人に魚を授けることは、漁の仕方を教えるに及ばない)』ということを大切にしており、「わからない」という人に単に答えを「教える」ことをせず、組織の未来のために、組織全体の IT リテラシーを上げること、スムーズに自己解決できる環境を整えることに努めています。 「ユーザー IT サポートが増え続け、サポート人件費が増大し、高コストな生産性の低いコーポレート IT チーム」とならないよう心がけています。 3. ルールを作らず、仕組み/仕掛けで解決する ルールを覚えなくても、意識しなくとも、狙ったことが自然に進むよう、仕組み/仕掛けによって目的を成す方法を作ることを意識しています。 例えば、高速道路のサービスエリアにある駐車場の逆走を禁止するために斜めに駐車位置ラインを引くといった、意識せずとも行動を一定方向に促す行動設計が望ましく、呼び鈴アプリもそういった仕掛けやプロセス設計の一環です。 さいごに コーポレート IT は全従業員が利用する IT 基盤の維持・改善が求められるため、非常に重要な役割です。また、急拡大する組織の中においては、今までの仕組みが通用しなくなり、未来志向で新たな仕組みを設計し続けていく必要があり、常にコーポレート IT チームの活躍の余地がたくさん存在しています。 そのため、未来志向で #革新と改善を主導 できる方を絶賛募集しております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。様々な業種でスペシャリストを募集しています。興味がある方は是非ご連絡ください。医療という社会貢献性の高い領域へ、一緒に挑戦しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。コーポレートデザイン部でコーポレート IT を担当している清水です。 コーポレート IT では全従業員が利用するネットワークインフラや SaaS といった IT 全般を統括しており、社内で発生している課題について IT を駆使して解決しています。 今回は、こうした課題解決の一例として、「 呼び鈴アプリ 」の開発について背景と実装のご紹介をし、最後に コーポレート IT チーム の業務内容や理念についてご紹介したいと思います。 呼び鈴アプリの開発背景 弊社では、チャットツールである「 Slack 」と「 Google Workspace 」や「 TeamSpirit 」等を連携して、来客者受付システムや 稟議ワークフローシステム 、オフィス空調最適化システム等、チャットをベースにした業務運用（ChatOps）を数多く行っています。 今回はその中でも、サポートを受けたい場合にコーポレート部門の担当者を呼び出しできるアプリ、 通称：呼び鈴アプリ をご紹介しようと思います。 呼び鈴アプリ導入前の困りごと IT 備品や健康保険証等の物の受け渡しや PC トラブルへの対応など、従業員へのサポート対応の際、サポートを依頼した従業員とコーポレート部門との間で、以下のような困りごとが発生していました。 ■ 従業員側の困りごと ・誰に話しかけたらよいかわからない IT 備品や健康保険証等を受け取りにコーポレート部門の座席に来たが、誰に話しかけたらよいかわからず、ウロウロしている方が結構いました。結果、別の部門に話しかけて、別の部門の方が正しい部門に案内するという時間も発生していました。 ・時間調整に手間がかかる PC トラブルへの対応の際は、コーポレート IT の担当者が依頼者の席まで行って作業をしていたため、担当者と依頼者で時間の調整が必要でした。直前で都合が悪くなり、リスケが発生することもしばしばありました。 ■ コーポレート部門の困りごと ・依頼者が見つけづらい 座席表を見て依頼者のところまで行くが、直近で座席変更があって居ると思っていたところに居ないことや、指定の時間に席に居ないといったことが度々発生していました。 ・個人情報が見えると困る 従業員が人事部から健康保険証等の書類を受け取る際、人事部の方は個人情報を扱うため、PC 画面の見える位置まで来られると困るという事情があり、特定の位置で待ってもらいたいというニーズがありました。 ・従業員の氏名確認に手間がかかる 全従業員分の氏名は把握できないため、コーポレート部門に来た従業員本人に名前を聞いて確認し、一旦席に戻って、貸与する IT 備品や健康保険証等を探して渡すという、席を行ったり来たりする状況でした。 ・周りの業務状況に配慮が必要 依頼者の席で PC トラブル対応をすると、周りの人が業務に集中していたり、顧客と電話していたりするため、業務に支障がでないようになるべく小声で話す必要がありました。 ・依頼者への対応が属人化しがち コーポレート部門の担当者と依頼者の間で作業の時間を調整していましたが、担当者が急な打ち合わせやお休みで不在になってしまったときは、他の担当者への引き継ぎ対応が漏れてしまうことがありました。 上記の課題を解決するために、 従業員の方向けにコーポレート部門の担当者を呼び出すアプリ を作りました！ どういったアプリか 呼び鈴アプリは、従業員とコーポレート部門で対面での作業/受け渡しが発生すること（PC トラブルへの対応/落とし物の受け渡し/健康保険証のお渡し等）に関して、iPad で依頼内容に応じた コーポレート部門の担当者を呼び出すことができるアプリ です。 コーポレート部門の近くのカウンターの上に iPad が置いてあり、そこから呼び出してもらいます。 ちなみに、カウンターはこんな感じのスペースで、従業員の方がセルフサービスで IT 備品交換を行えるブースもあります。 アプリの利用イメージ まず、従業員はカウンターまで行き、iPad の呼び鈴アプリから呼び出し依頼を行います。 呼び出し依頼は専用の Slack チャンネルに通知が来るので、各コーポレート部門の担当者が通知内容を確認して、従業員が居るカウンターに行き、対応という流れになります。 画面イメージ 利用方法は、自身の名前を選択してもらい、コーポレート部門への依頼内容を選択するという形です。 導入後の効果 呼び鈴アプリの導入によって、 従業員がコーポレート部門からサポートを受けたり、物を受け渡ししたいときは、 自身が都合の良いタイミングで カウンターの呼び鈴アプリに来れば良く、 利便性が向上した 。 Slack 通知に依頼者氏名が表示されるので、 氏名を確認する必要がなくなった。 コーポレート部門の担当者が 依頼者の席を探して尋ねなくてよくなった。 というように困りごとが改善されました。 また、特定のメンバーが対応するのではなく、呼び出されたタイミングで席に居る全メンバーが対応できるような運用にすることで、PC/IT 備品や健康保険証等の物の受け渡し、PC のトラブル対応等のサポート対応が属人的にならず、離席していても、休暇をとっていても誰でも対応できる体制になりました。 呼び鈴アプリの構成 呼び鈴アプリの開発にあたっては 1. 先述の課題を解決すること 2. コーポレート IT 内でプロジェクトが複数動いているため、他のプロジェクトの進捗に影響がでないように、工数をさほどかけずにクイックに開発できること 3. なるべくランニングコストをかけないこと という要件から、 AppSheet と Google App Script（以降 GAS） で実装することを決めました。 機能検証期間を含めて 1 週間程度で実装できています。 AppSheet は、Google から提供されている、ノーコードでアプリケーション開発ができるツールです。 AppSheet は、エンジニアではなく「現場で働く人が作る」という思想をもとにサービスが開始されました。そのため、プログラミング知識がない人でも、マウス操作のみで簡単にアプリケーションを開発できるようになっています。 サービス連携図 UI を AppSheet で、Slack への通知を GAS で実装しています。 画面構成 画面は依頼者選択画面、依頼内容一覧画面、依頼詳細一覧画面の３画面で構成しています。 呼び鈴アプリの実装 呼び鈴アプリをどのように実装しているか解説していきます。 AppSheet の設定 AppSheet を利用したアプリの作成方法については、Google 公式の How to create an app や Google で AppSheet を検索するといくつか作成例のサイトが表示されますので、今回の機能を実装するにあたり重要な 「依頼詳細一覧画面から Slack 通知」 設定の部分にフォーカスして解説します。 1. Data の設定 Tables と Slices について、それぞれ設定します。 Tables では、アプリケーションの元となるデータを格納する「テーブル」を作成します。 Slices では、テーブルから必要な行と列のみを表示させたり、条件にあうデータのみを表示させたりして、必要なデータを抽出した「テーブルの一部分」を作成します。 1-1. Tables の設定 今回 Table は以下の 5 つを用意しました。 テーブルは、スプレッドシートにテーブルとなるデータを作成した後、AppSheet と連携します。連携方法は Connect your data to AppSheet の動画を参考にしてください。 テーブル名 利用用途 Client 依頼者選択画面で選択されたユーザー名を一時的に保存するテーブル Doorbell 依頼内容一覧画面に表示するテーブル DoorbellDetails 依頼詳細一覧画面に表示するテーブル CallHistory 呼出履歴を保存するテーブル UserList 依頼者選択画面に表示するテーブル 依頼詳細一覧画面と呼び出し機能に関連する、「DoorbellDetails」と「CallHistory」について詳しく説明します。 ・ DoorbellDetails 依頼詳細一覧画面に表示したい内容を一覧で記載します。 分類 ID 列は Doorbell でも同名の列を作成し、そこで設定した値と合わせてください。また、対応 ID は分類 ID 内でユニークになるように設定してください。 対応説明に関しては、任意で入力していただければ大丈夫です。 SlackChannel 列に Slack チャンネルに投稿する用の Webhook URL を設定してください。 Incoming Webhooks 等を使用すると、 Webhook URL が取得できます。 3 行目以降のデータは、 2 行目を参考に設定してください。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 1 分類 ID 対応 ID 対応名 対応説明 SlackChannel 2 receipt 1 入社にあたって貸与物を受け取りたい （通知先チャンネルの Webhook URL を設定） Table での設定例 分類 ID と対応 ID を複合キー（分類 ID と対応 ID に「REQUIRE」を設定）としています。 ・ CallHistory 呼出履歴を保存するテーブルのため、ヘッダー以外の入力は不要です。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 F 列 G 列 1 CH_id CH_分類 ID CH_対応 ID CH_対応名 CH_SlackChannel CH_呼び出し日時 CH_依頼者 Table での設定例 1-2. Slices の設定 次に、Slice の設定を行います。Slice は依頼内容ごとに画面表示を切り替えるために「DoorbellDetails」のデータを元に作成します。 貸与物受け取りに関する Slice の場合、以下のように設定します。 設定項目名 設定値 Slice name 貸与物受け取り Source table DoorbellDetails Row filter condition [分類 ID]="receipt" 2. App の設定 Views について、それぞれ設定します。 2-1. Views の設定 依頼詳細一覧画面について詳しく説明します。 ・依頼詳細一覧画面 依頼内容一覧画面から遷移できるように、依頼詳細一覧画面は依頼内容ごとに準備します。ここでは貸与物受け取り画面を例として設定しています。 設定項目名 設定値 View name 貸与物受け取り画面 For this data 貸与物受け取り View type deck Position ref Primary header _RowNumber Secondary header 対応名 Event Actions(Row Selected) SaveAndMoveToClientForm（Actions の設定後、設定可能になります） 3. Actions の設定 各ボタンを押したときの動作を定義します。 実際には他にもいくつか Action を設定していますが、Slack 通知に関係する Action は以下の 3 つです。 Action 名 利用用途 MoveToClientForm 依頼者選択画面に遷移する SaveCallHistory CallHistory にデータを保存する SaveAndMoveToClientForm CallHistory に保存後、依頼者選択画面に遷移する ・ MoveToClientForm 依頼者選択画面に遷移する Action です。 設定項目名 設定値 Action name MoveToClientForm For a record of this table DoorbellDetails Do this App: go to another view within this app Target ”#view=依頼者選択” ・ SaveCallHistory 「CallHistory」テーブルにデータを保存する Action です。 選択された氏名については「Client」テーブルからデータを取得しています。 また、SlackChannel 列の記載がない場合は、画面に「呼び出し」ボタンを表示させないように設定しています。 設定項目名 設定値 Action name SaveCallHistory For a record of this table DoorbellDetails Do this Data: add a new row to another table using values from this row Set these columns CH_id = UNIQUEID() CH_分類 ID = [分類 ID] CH_対応 ID = [対応 ID] CH_対応名 = [対応名] CH_SlackChannel = [SlackChannel] CH_呼び出し日次 = TODAY() & ” ” & TIMENOW() CH_依頼者 = Client[ご自身の氏名] Display name 呼び出し Only if this condition is true ISNOTBLANK([SlackChannel]) Needs confirmation? True Confirmation Message CONCATENATE(“依頼者：“,Client[ご自身の氏名],"",“呼び出し内容：”,[対応名],"",“担当者を呼び出しますか？”) ・ SaveAndMoveToClientForm 呼出履歴に保存後、依頼者選択画面に遷移する Action です。この Action を依頼詳細一覧画面の Event Actions に紐付けます。 設定項目名 設定値 Action name SaveAndMoveToClientForm For a record of this table DoorbellDetails Do this Grouped: execute a sequence of actions Actions SaveCallHistory MoveToClientForm スプレッドシート の設定 AppSheet からスプレッドシートの「CallHistory」シートに呼出履歴データが登録（行追加）されたら、Slack 通知 GAS を実行するように設定します。 GAS の記述 先程テーブルを作成したスプレッドシートの拡張機能 →Apps Script を開きます。 App Script 上で新しく「.gs」ファイルを作成し、「CallHistory」 のシートが更新されたときだけ、Slack に通知するように GAS を記述します。 function onChange ( e ) { // イベントが"EDIT"の場合のみ実行。 if ( e . changeType === "EDIT" ) { const ar = e . source . getActiveRange (); const sheet = e . source . getActiveSheet (); // CallHistory シートが更新された場合のみ Slack に通知する if ( e . source . getSheetName () == "CallHistory" ) { const inquiry = sheet . getRange ( ar . getRow (), 4 ). getValue (); const slackWebHook = sheet . getRange ( ar . getRow (), 5 ). getValue (); const clientName = sheet . getRange ( ar . getRow (), 7 ). getValue (); notifyToSlack ( slackWebHook , "コーポカウンター呼び鈴" , ":notification_bell:" , // お好きな Slack の絵文字を設定して下さい。 `<!here> ${ clientName } さんが ${ inquiry } で呼び出ししています。` ); } } } function notifyToSlack ( url , username , icon , message ) { const jsonData = { username: username , icon_emoji: icon , text: message , }; const payload = JSON . stringify ( jsonData ); const options = { method: "post" , contentType: "application/json" , payload: payload , }; UrlFetchApp . fetch ( url , options ); } トリガーの設定 スプレッドシートに呼出履歴が登録（行追加）されたら、 onChange() を実行するように設定します。 問題なく動作すると、Slack に以下のようなメッセージが通知されます。 実装する上で難しかったこと AppSheet でアプリを開発するにあたり、ノーコード開発の制約でかゆいところに手が届かず、いくつか工夫して実装する必要がありました。 1. 氏名の選択結果を保持したまま、依頼内容選択の結果を「CallHistory」に書き出すこと AppSheet が複数の選択結果を保持できるような仕組みになっておらず、依頼者選択画面から依頼内容一覧画面に遷移すると選択結果が消えるため、依頼者選択結果をデータとしてどこかに保持する必要がありました。 → 氏名の選択結果を格納する一行だけのテーブル「Client」を作成し、「CallHistory」への書き出し時に「Client」の一行目のデータを読むように設定しました。 2. ボタンの配置と表示が変更できないこと 基本的にボタンに表示されているテキストは変更できず、ボタン位置も自由に変更できないため（画面の最上部か最下部のみ）、画面の設計には苦労しました。 → テキストに関しては、Settings → Views → Localization で「Save」を「次へ」に変更して対応しました。 ボタン位置に関してはどうにもならなかったため、なるべく導線がわかりやすいように画面上に説明を入れるようにしています。 ノーコードがゆえの制約はありますが、AppSheet での開発は簡単かつ迅速にできるため、小規模なアプリケーションであれば、おすすめの環境です。 以上、呼び鈴アプリの開発についてお話しました。 ここからは、コーポレート IT についてご紹介していきます。 コーポレート IT について コーポレートデザイン部は、 「未来志向で社内の IT インフラを含めたオフィス環境をデザインすること」 をミッションに業務しており、現在 2 つのチームがあります。 一つはワークプレイスチームで、ペン一本からオフィス施工に関することまで、オフィス環境全般を担当しています。 そして、もう一つがコーポレート IT チームで、全社で利用する SaaS の管理やオフィスのネットワークインフラ、社内アプリの開発等、全従業員が利用する IT ソリューション全般の企画・開発・運用を担当しています。 コーポレート IT の役割 コーポレート IT としてのミッションは、**「テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図ること」**です。 そのために、単に上流・下流というフェーズ分担ではなく、システム導入だけでもない、全社の組織カルチャーづくりも見据えた全従業員が利用するコーポレート基盤をデザインし、そのデザインに基づいて IT ソリューションを実装、運用していきます。 逆に、各部門のミッション達成、業務目的達成のための個別の IT ソリューションは、ツールゆえ各部門が主管です。コーポレート IT は IT プロフェッショナルとしてアドバイスしたり、システム設計や実装する形で、技術的実現を担うものとして各部門とコラボします。 各部門の IT ソリューションに対する PDCA を各部門がオーナーシップを持つことで、利用時の要望や改善に対して、非常に早いサイクルで実施することができています。 業務内容紹介 コーポレート IT では、日々の従業員への IT サポート以外に、複数のプロジェクトが同時に走っています。以下に記載している業務はほんの一例です。 端末管理アプリケーションおよびセキュリティ製品の企画/導入/運用 オフィス移転でのネットワーク構築（ネットワークの設計、機器選定〜運用まで） 社外来客用受付システムの改修/運用 呼び鈴アプリの企画/開発/運用 従業員向けの情報セキュリティ研修 人事基幹システムの導入支援/各システムとの連携機能構築 etc また、メンバー自ら提案して企画化、予算を確保することもあり、アイデアに対して柔軟に対応しています。 業務を行う上で常に意識していること・大事にしていること コーポレート IT として業務を行う上で大事にしている考え方が、3 つあります。従業員の生産性が向上する環境の構築に必要不可欠と考えており、これらをもとに意思決定しています。 1. システム選定/技術選定の考え方 システム選定/技術選定の原則としては、グローバルトップシェアで、かつ、北米急成長企業が選定しているものを未来志向で活用していくことを意識していますが、その技術やツールを導入して、得たい本来の目的が達成できるかどうかを、広い視点から判断して意思決定しています。 2. ユーザー IT サポートの考え方 老子が言っている『授人以魚 不如授人以漁(人に魚を授けることは、漁の仕方を教えるに及ばない)』ということを大切にしており、「わからない」という人に単に答えを「教える」ことをせず、組織の未来のために、組織全体の IT リテラシーを上げること、スムーズに自己解決できる環境を整えることに努めています。 「ユーザー IT サポートが増え続け、サポート人件費が増大し、高コストな生産性の低いコーポレート IT チーム」とならないよう心がけています。 3. ルールを作らず、仕組み/仕掛けで解決する ルールを覚えなくても、意識しなくとも、狙ったことが自然に進むよう、仕組み/仕掛けによって目的を成す方法を作ることを意識しています。 例えば、高速道路のサービスエリアにある駐車場の逆走を禁止するために斜めに駐車位置ラインを引くといった、意識せずとも行動を一定方向に促す行動設計が望ましく、呼び鈴アプリもそういった仕掛けやプロセス設計の一環です。 さいごに コーポレート IT は全従業員が利用する IT 基盤の維持・改善が求められるため、非常に重要な役割です。また、急拡大する組織の中においては、今までの仕組みが通用しなくなり、未来志向で新たな仕組みを設計し続けていく必要があり、常にコーポレート IT チームの活躍の余地がたくさん存在しています。 そのため、未来志向で #革新と改善を主導 できる方を絶賛募集しております。 https://www.medley.jp/jobs/corporate-design.html メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。様々な業種でスペシャリストを募集しています。興味がある方は是非ご連絡ください。医療という社会貢献性の高い領域へ、一緒に挑戦しませんか？ https://www.medley.jp/jobs/

はじめに こんにちは。コーポレートデザイン部でコーポレート IT を担当している清水です。 コーポレート IT では全従業員が利用するネットワークインフラや SaaS といった IT 全般を統括しており、社内で発生している課題について IT を駆使して解決しています。 今回は、こうした課題解決の一例として、「 呼び鈴アプリ 」の開発について背景と実装のご紹介をし、最後に コーポレート IT チーム の業務内容や理念についてご紹介したいと思います。 呼び鈴アプリの開発背景 弊社では、チャットツールである「 Slack 」と「 Google Workspace 」や「 TeamSpirit 」等を連携して、来客者受付システムや 稟議ワークフローシステム 、オフィス空調最適化システム等、チャットをベースにした業務運用（ChatOps）を数多く行っています。 今回はその中でも、サポートを受けたい場合にコーポレート部門の担当者を呼び出しできるアプリ、 通称：呼び鈴アプリ をご紹介しようと思います。 呼び鈴アプリ導入前の困りごと IT 備品や健康保険証等の物の受け渡しや PC トラブルへの対応など、従業員へのサポート対応の際、サポートを依頼した従業員とコーポレート部門との間で、以下のような困りごとが発生していました。 ■ 従業員側の困りごと ・誰に話しかけたらよいかわからない IT 備品や健康保険証等を受け取りにコーポレート部門の座席に来たが、誰に話しかけたらよいかわからず、ウロウロしている方が結構いました。結果、別の部門に話しかけて、別の部門の方が正しい部門に案内するという時間も発生していました。 ・時間調整に手間がかかる PC トラブルへの対応の際は、コーポレート IT の担当者が依頼者の席まで行って作業をしていたため、担当者と依頼者で時間の調整が必要でした。直前で都合が悪くなり、リスケが発生することもしばしばありました。 ■ コーポレート部門の困りごと ・依頼者が見つけづらい 座席表を見て依頼者のところまで行くが、直近で座席変更があって居ると思っていたところに居ないことや、指定の時間に席に居ないといったことが度々発生していました。 ・個人情報が見えると困る 従業員が人事部から健康保険証等の書類を受け取る際、人事部の方は個人情報を扱うため、PC 画面の見える位置まで来られると困るという事情があり、特定の位置で待ってもらいたいというニーズがありました。 ・従業員の氏名確認に手間がかかる 全従業員分の氏名は把握できないため、コーポレート部門に来た従業員本人に名前を聞いて確認し、一旦席に戻って、貸与する IT 備品や健康保険証等を探して渡すという、席を行ったり来たりする状況でした。 ・周りの業務状況に配慮が必要 依頼者の席で PC トラブル対応をすると、周りの人が業務に集中していたり、顧客と電話していたりするため、業務に支障がでないようになるべく小声で話す必要がありました。 ・依頼者への対応が属人化しがち コーポレート部門の担当者と依頼者の間で作業の時間を調整していましたが、担当者が急な打ち合わせやお休みで不在になってしまったときは、他の担当者への引き継ぎ対応が漏れてしまうことがありました。 上記の課題を解決するために、 従業員の方向けにコーポレート部門の担当者を呼び出すアプリ を作りました！ どういったアプリか 呼び鈴アプリは、従業員とコーポレート部門で対面での作業/受け渡しが発生すること（PC トラブルへの対応/落とし物の受け渡し/健康保険証のお渡し等）に関して、iPad で依頼内容に応じた コーポレート部門の担当者を呼び出すことができるアプリ です。 コーポレート部門の近くのカウンターの上に iPad が置いてあり、そこから呼び出してもらいます。 ちなみに、カウンターはこんな感じのスペースで、従業員の方がセルフサービスで IT 備品交換を行えるブースもあります。 アプリの利用イメージ まず、従業員はカウンターまで行き、iPad の呼び鈴アプリから呼び出し依頼を行います。 呼び出し依頼は専用の Slack チャンネルに通知が来るので、各コーポレート部門の担当者が通知内容を確認して、従業員が居るカウンターに行き、対応という流れになります。 画面イメージ 利用方法は、自身の名前を選択してもらい、コーポレート部門への依頼内容を選択するという形です。 導入後の効果 呼び鈴アプリの導入によって、 従業員がコーポレート部門からサポートを受けたり、物を受け渡ししたいときは、 自身が都合の良いタイミングで カウンターの呼び鈴アプリに来れば良く、 利便性が向上した 。 Slack 通知に依頼者氏名が表示されるので、 氏名を確認する必要がなくなった。 コーポレート部門の担当者が 依頼者の席を探して尋ねなくてよくなった。 というように困りごとが改善されました。 また、特定のメンバーが対応するのではなく、呼び出されたタイミングで席に居る全メンバーが対応できるような運用にすることで、PC/IT 備品や健康保険証等の物の受け渡し、PC のトラブル対応等のサポート対応が属人的にならず、離席していても、休暇をとっていても誰でも対応できる体制になりました。 呼び鈴アプリの構成 呼び鈴アプリの開発にあたっては 1. 先述の課題を解決すること 2. コーポレート IT 内でプロジェクトが複数動いているため、他のプロジェクトの進捗に影響がでないように、工数をさほどかけずにクイックに開発できること 3. なるべくランニングコストをかけないこと という要件から、 AppSheet と Google App Script（以降 GAS） で実装することを決めました。 機能検証期間を含めて 1 週間程度で実装できています。 AppSheet は、Google から提供されている、ノーコードでアプリケーション開発ができるツールです。 AppSheet は、エンジニアではなく「現場で働く人が作る」という思想をもとにサービスが開始されました。そのため、プログラミング知識がない人でも、マウス操作のみで簡単にアプリケーションを開発できるようになっています。 サービス連携図 UI を AppSheet で、Slack への通知を GAS で実装しています。 画面構成 画面は依頼者選択画面、依頼内容一覧画面、依頼詳細一覧画面の３画面で構成しています。 呼び鈴アプリの実装 呼び鈴アプリをどのように実装しているか解説していきます。 AppSheet の設定 AppSheet を利用したアプリの作成方法については、Google 公式の How to create an app や Google で AppSheet を検索するといくつか作成例のサイトが表示されますので、今回の機能を実装するにあたり重要な 「依頼詳細一覧画面から Slack 通知」 設定の部分にフォーカスして解説します。 1. Data の設定 Tables と Slices について、それぞれ設定します。 Tables では、アプリケーションの元となるデータを格納する「テーブル」を作成します。 Slices では、テーブルから必要な行と列のみを表示させたり、条件にあうデータのみを表示させたりして、必要なデータを抽出した「テーブルの一部分」を作成します。 1-1. Tables の設定 今回 Table は以下の 5 つを用意しました。 テーブルは、スプレッドシートにテーブルとなるデータを作成した後、AppSheet と連携します。連携方法は Connect your data to AppSheet の動画を参考にしてください。 テーブル名 利用用途 Client 依頼者選択画面で選択されたユーザー名を一時的に保存するテーブル Doorbell 依頼内容一覧画面に表示するテーブル DoorbellDetails 依頼詳細一覧画面に表示するテーブル CallHistory 呼出履歴を保存するテーブル UserList 依頼者選択画面に表示するテーブル 依頼詳細一覧画面と呼び出し機能に関連する、「DoorbellDetails」と「CallHistory」について詳しく説明します。 ・ DoorbellDetails 依頼詳細一覧画面に表示したい内容を一覧で記載します。 分類 ID 列は Doorbell でも同名の列を作成し、そこで設定した値と合わせてください。また、対応 ID は分類 ID 内でユニークになるように設定してください。 対応説明に関しては、任意で入力していただければ大丈夫です。 SlackChannel 列に Slack チャンネルに投稿する用の Webhook URL を設定してください。 Incoming Webhooks 等を使用すると、 Webhook URL が取得できます。 3 行目以降のデータは、 2 行目を参考に設定してください。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 1 分類 ID 対応 ID 対応名 対応説明 SlackChannel 2 receipt 1 入社にあたって貸与物を受け取りたい （通知先チャンネルの Webhook URL を設定） Table での設定例 分類 ID と対応 ID を複合キー（分類 ID と対応 ID に「REQUIRE」を設定）としています。 ・ CallHistory 呼出履歴を保存するテーブルのため、ヘッダー以外の入力は不要です。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 F 列 G 列 1 CH_id CH_分類 ID CH_対応 ID CH_対応名 CH_SlackChannel CH_呼び出し日時 CH_依頼者 Table での設定例 1-2. Slices の設定 次に、Slice の設定を行います。Slice は依頼内容ごとに画面表示を切り替えるために「DoorbellDetails」のデータを元に作成します。 貸与物受け取りに関する Slice の場合、以下のように設定します。 設定項目名 設定値 Slice name 貸与物受け取り Source table DoorbellDetails Row filter condition [分類 ID]="receipt" 2. App の設定 Views について、それぞれ設定します。 2-1. Views の設定 依頼詳細一覧画面について詳しく説明します。 ・依頼詳細一覧画面 依頼内容一覧画面から遷移できるように、依頼詳細一覧画面は依頼内容ごとに準備します。ここでは貸与物受け取り画面を例として設定しています。 設定項目名 設定値 View name 貸与物受け取り画面 For this data 貸与物受け取り View type deck Position ref Primary header _RowNumber Secondary header 対応名 Event Actions(Row Selected) SaveAndMoveToClientForm（Actions の設定後、設定可能になります） 3. Actions の設定 各ボタンを押したときの動作を定義します。 実際には他にもいくつか Action を設定していますが、Slack 通知に関係する Action は以下の 3 つです。 Action 名 利用用途 MoveToClientForm 依頼者選択画面に遷移する SaveCallHistory CallHistory にデータを保存する SaveAndMoveToClientForm CallHistory に保存後、依頼者選択画面に遷移する ・ MoveToClientForm 依頼者選択画面に遷移する Action です。 設定項目名 設定値 Action name MoveToClientForm For a record of this table DoorbellDetails Do this App: go to another view within this app Target ”#view=依頼者選択” ・ SaveCallHistory 「CallHistory」テーブルにデータを保存する Action です。 選択された氏名については「Client」テーブルからデータを取得しています。 また、SlackChannel 列の記載がない場合は、画面に「呼び出し」ボタンを表示させないように設定しています。 設定項目名 設定値 Action name SaveCallHistory For a record of this table DoorbellDetails Do this Data: add a new row to another table using values from this row Set these columns CH_id = UNIQUEID() CH_分類 ID = [分類 ID] CH_対応 ID = [対応 ID] CH_対応名 = [対応名] CH_SlackChannel = [SlackChannel] CH_呼び出し日次 = TODAY() & ” ” & TIMENOW() CH_依頼者 = Client[ご自身の氏名] Display name 呼び出し Only if this condition is true ISNOTBLANK([SlackChannel]) Needs confirmation? True Confirmation Message CONCATENATE(“依頼者：“,Client[ご自身の氏名],"",“呼び出し内容：”,[対応名],"",“担当者を呼び出しますか？”) ・ SaveAndMoveToClientForm 呼出履歴に保存後、依頼者選択画面に遷移する Action です。この Action を依頼詳細一覧画面の Event Actions に紐付けます。 設定項目名 設定値 Action name SaveAndMoveToClientForm For a record of this table DoorbellDetails Do this Grouped: execute a sequence of actions Actions SaveCallHistory MoveToClientForm スプレッドシート の設定 AppSheet からスプレッドシートの「CallHistory」シートに呼出履歴データが登録（行追加）されたら、Slack 通知 GAS を実行するように設定します。 GAS の記述 先程テーブルを作成したスプレッドシートの拡張機能 →Apps Script を開きます。 App Script 上で新しく「.gs」ファイルを作成し、「CallHistory」 のシートが更新されたときだけ、Slack に通知するように GAS を記述します。 function onChange ( e ) { // イベントが"EDIT"の場合のみ実行。 if ( e . changeType === "EDIT" ) { const ar = e . source . getActiveRange (); const sheet = e . source . getActiveSheet (); // CallHistory シートが更新された場合のみ Slack に通知する if ( e . source . getSheetName () == "CallHistory" ) { const inquiry = sheet . getRange ( ar . getRow (), 4 ). getValue (); const slackWebHook = sheet . getRange ( ar . getRow (), 5 ). getValue (); const clientName = sheet . getRange ( ar . getRow (), 7 ). getValue (); notifyToSlack ( slackWebHook , "コーポカウンター呼び鈴" , ":notification_bell:" , // お好きな Slack の絵文字を設定して下さい。 `<!here> ${ clientName } さんが ${ inquiry } で呼び出ししています。` ); } } } function notifyToSlack ( url , username , icon , message ) { const jsonData = { username: username , icon_emoji: icon , text: message , }; const payload = JSON . stringify ( jsonData ); const options = { method: "post" , contentType: "application/json" , payload: payload , }; UrlFetchApp . fetch ( url , options ); } トリガーの設定 スプレッドシートに呼出履歴が登録（行追加）されたら、 onChange() を実行するように設定します。 問題なく動作すると、Slack に以下のようなメッセージが通知されます。 実装する上で難しかったこと AppSheet でアプリを開発するにあたり、ノーコード開発の制約でかゆいところに手が届かず、いくつか工夫して実装する必要がありました。 1. 氏名の選択結果を保持したまま、依頼内容選択の結果を「CallHistory」に書き出すこと AppSheet が複数の選択結果を保持できるような仕組みになっておらず、依頼者選択画面から依頼内容一覧画面に遷移すると選択結果が消えるため、依頼者選択結果をデータとしてどこかに保持する必要がありました。 → 氏名の選択結果を格納する一行だけのテーブル「Client」を作成し、「CallHistory」への書き出し時に「Client」の一行目のデータを読むように設定しました。 2. ボタンの配置と表示が変更できないこと 基本的にボタンに表示されているテキストは変更できず、ボタン位置も自由に変更できないため（画面の最上部か最下部のみ）、画面の設計には苦労しました。 → テキストに関しては、Settings → Views → Localization で「Save」を「次へ」に変更して対応しました。 ボタン位置に関してはどうにもならなかったため、なるべく導線がわかりやすいように画面上に説明を入れるようにしています。 ノーコードがゆえの制約はありますが、AppSheet での開発は簡単かつ迅速にできるため、小規模なアプリケーションであれば、おすすめの環境です。 以上、呼び鈴アプリの開発についてお話しました。 ここからは、コーポレート IT についてご紹介していきます。 コーポレート IT について コーポレートデザイン部は、 「未来志向で社内の IT インフラを含めたオフィス環境をデザインすること」 をミッションに業務しており、現在 2 つのチームがあります。 一つはワークプレイスチームで、ペン一本からオフィス施工に関することまで、オフィス環境全般を担当しています。 そして、もう一つがコーポレート IT チームで、全社で利用する SaaS の管理やオフィスのネットワークインフラ、社内アプリの開発等、全従業員が利用する IT ソリューション全般の企画・開発・運用を担当しています。 コーポレート IT の役割 コーポレート IT としてのミッションは、**「テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図ること」**です。 そのために、単に上流・下流というフェーズ分担ではなく、システム導入だけでもない、全社の組織カルチャーづくりも見据えた全従業員が利用するコーポレート基盤をデザインし、そのデザインに基づいて IT ソリューションを実装、運用していきます。 逆に、各部門のミッション達成、業務目的達成のための個別の IT ソリューションは、ツールゆえ各部門が主管です。コーポレート IT は IT プロフェッショナルとしてアドバイスしたり、システム設計や実装する形で、技術的実現を担うものとして各部門とコラボします。 各部門の IT ソリューションに対する PDCA を各部門がオーナーシップを持つことで、利用時の要望や改善に対して、非常に早いサイクルで実施することができています。 業務内容紹介 コーポレート IT では、日々の従業員への IT サポート以外に、複数のプロジェクトが同時に走っています。以下に記載している業務はほんの一例です。 端末管理アプリケーションおよびセキュリティ製品の企画/導入/運用 オフィス移転でのネットワーク構築（ネットワークの設計、機器選定〜運用まで） 社外来客用受付システムの改修/運用 呼び鈴アプリの企画/開発/運用 従業員向けの情報セキュリティ研修 人事基幹システムの導入支援/各システムとの連携機能構築 etc また、メンバー自ら提案して企画化、予算を確保することもあり、アイデアに対して柔軟に対応しています。 業務を行う上で常に意識していること・大事にしていること コーポレート IT として業務を行う上で大事にしている考え方が、3 つあります。従業員の生産性が向上する環境の構築に必要不可欠と考えており、これらをもとに意思決定しています。 1. システム選定/技術選定の考え方 システム選定/技術選定の原則としては、グローバルトップシェアで、かつ、北米急成長企業が選定しているものを未来志向で活用していくことを意識していますが、その技術やツールを導入して、得たい本来の目的が達成できるかどうかを、広い視点から判断して意思決定しています。 2. ユーザー IT サポートの考え方 老子が言っている『授人以魚 不如授人以漁(人に魚を授けることは、漁の仕方を教えるに及ばない)』ということを大切にしており、「わからない」という人に単に答えを「教える」ことをせず、組織の未来のために、組織全体の IT リテラシーを上げること、スムーズに自己解決できる環境を整えることに努めています。 「ユーザー IT サポートが増え続け、サポート人件費が増大し、高コストな生産性の低いコーポレート IT チーム」とならないよう心がけています。 3. ルールを作らず、仕組み/仕掛けで解決する ルールを覚えなくても、意識しなくとも、狙ったことが自然に進むよう、仕組み/仕掛けによって目的を成す方法を作ることを意識しています。 例えば、高速道路のサービスエリアにある駐車場の逆走を禁止するために斜めに駐車位置ラインを引くといった、意識せずとも行動を一定方向に促す行動設計が望ましく、呼び鈴アプリもそういった仕掛けやプロセス設計の一環です。 さいごに コーポレート IT は全従業員が利用する IT 基盤の維持・改善が求められるため、非常に重要な役割です。また、急拡大する組織の中においては、今までの仕組みが通用しなくなり、未来志向で新たな仕組みを設計し続けていく必要があり、常にコーポレート IT チームの活躍の余地がたくさん存在しています。 そのため、未来志向で #革新と改善を主導 できる方を絶賛募集しております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。様々な業種でスペシャリストを募集しています。興味がある方は是非ご連絡ください。医療という社会貢献性の高い領域へ、一緒に挑戦しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。コーポレートデザイン部でコーポレート IT を担当している清水です。 コーポレート IT では全従業員が利用するネットワークインフラや SaaS といった IT 全般を統括しており、社内で発生している課題について IT を駆使して解決しています。 今回は、こうした課題解決の一例として、「 呼び鈴アプリ 」の開発について背景と実装のご紹介をし、最後に コーポレート IT チーム の業務内容や理念についてご紹介したいと思います。 呼び鈴アプリの開発背景 弊社では、チャットツールである「 Slack 」と「 Google Workspace 」や「 TeamSpirit 」等を連携して、来客者受付システムや 稟議ワークフローシステム 、オフィス空調最適化システム等、チャットをベースにした業務運用（ChatOps）を数多く行っています。 今回はその中でも、サポートを受けたい場合にコーポレート部門の担当者を呼び出しできるアプリ、 通称：呼び鈴アプリ をご紹介しようと思います。 呼び鈴アプリ導入前の困りごと IT 備品や健康保険証等の物の受け渡しや PC トラブルへの対応など、従業員へのサポート対応の際、サポートを依頼した従業員とコーポレート部門との間で、以下のような困りごとが発生していました。 ■ 従業員側の困りごと ・誰に話しかけたらよいかわからない IT 備品や健康保険証等を受け取りにコーポレート部門の座席に来たが、誰に話しかけたらよいかわからず、ウロウロしている方が結構いました。結果、別の部門に話しかけて、別の部門の方が正しい部門に案内するという時間も発生していました。 ・時間調整に手間がかかる PC トラブルへの対応の際は、コーポレート IT の担当者が依頼者の席まで行って作業をしていたため、担当者と依頼者で時間の調整が必要でした。直前で都合が悪くなり、リスケが発生することもしばしばありました。 ■ コーポレート部門の困りごと ・依頼者が見つけづらい 座席表を見て依頼者のところまで行くが、直近で座席変更があって居ると思っていたところに居ないことや、指定の時間に席に居ないといったことが度々発生していました。 ・個人情報が見えると困る 従業員が人事部から健康保険証等の書類を受け取る際、人事部の方は個人情報を扱うため、PC 画面の見える位置まで来られると困るという事情があり、特定の位置で待ってもらいたいというニーズがありました。 ・従業員の氏名確認に手間がかかる 全従業員分の氏名は把握できないため、コーポレート部門に来た従業員本人に名前を聞いて確認し、一旦席に戻って、貸与する IT 備品や健康保険証等を探して渡すという、席を行ったり来たりする状況でした。 ・周りの業務状況に配慮が必要 依頼者の席で PC トラブル対応をすると、周りの人が業務に集中していたり、顧客と電話していたりするため、業務に支障がでないようになるべく小声で話す必要がありました。 ・依頼者への対応が属人化しがち コーポレート部門の担当者と依頼者の間で作業の時間を調整していましたが、担当者が急な打ち合わせやお休みで不在になってしまったときは、他の担当者への引き継ぎ対応が漏れてしまうことがありました。 上記の課題を解決するために、 従業員の方向けにコーポレート部門の担当者を呼び出すアプリ を作りました！ どういったアプリか 呼び鈴アプリは、従業員とコーポレート部門で対面での作業/受け渡しが発生すること（PC トラブルへの対応/落とし物の受け渡し/健康保険証のお渡し等）に関して、iPad で依頼内容に応じた コーポレート部門の担当者を呼び出すことができるアプリ です。 コーポレート部門の近くのカウンターの上に iPad が置いてあり、そこから呼び出してもらいます。 ちなみに、カウンターはこんな感じのスペースで、従業員の方がセルフサービスで IT 備品交換を行えるブースもあります。 アプリの利用イメージ まず、従業員はカウンターまで行き、iPad の呼び鈴アプリから呼び出し依頼を行います。 呼び出し依頼は専用の Slack チャンネルに通知が来るので、各コーポレート部門の担当者が通知内容を確認して、従業員が居るカウンターに行き、対応という流れになります。 画面イメージ 利用方法は、自身の名前を選択してもらい、コーポレート部門への依頼内容を選択するという形です。 導入後の効果 呼び鈴アプリの導入によって、 従業員がコーポレート部門からサポートを受けたり、物を受け渡ししたいときは、 自身が都合の良いタイミングで カウンターの呼び鈴アプリに来れば良く、 利便性が向上した 。 Slack 通知に依頼者氏名が表示されるので、 氏名を確認する必要がなくなった。 コーポレート部門の担当者が 依頼者の席を探して尋ねなくてよくなった。 というように困りごとが改善されました。 また、特定のメンバーが対応するのではなく、呼び出されたタイミングで席に居る全メンバーが対応できるような運用にすることで、PC/IT 備品や健康保険証等の物の受け渡し、PC のトラブル対応等のサポート対応が属人的にならず、離席していても、休暇をとっていても誰でも対応できる体制になりました。 呼び鈴アプリの構成 呼び鈴アプリの開発にあたっては 1. 先述の課題を解決すること 2. コーポレート IT 内でプロジェクトが複数動いているため、他のプロジェクトの進捗に影響がでないように、工数をさほどかけずにクイックに開発できること 3. なるべくランニングコストをかけないこと という要件から、 AppSheet と Google App Script（以降 GAS） で実装することを決めました。 機能検証期間を含めて 1 週間程度で実装できています。 AppSheet は、Google から提供されている、ノーコードでアプリケーション開発ができるツールです。 AppSheet は、エンジニアではなく「現場で働く人が作る」という思想をもとにサービスが開始されました。そのため、プログラミング知識がない人でも、マウス操作のみで簡単にアプリケーションを開発できるようになっています。 サービス連携図 UI を AppSheet で、Slack への通知を GAS で実装しています。 画面構成 画面は依頼者選択画面、依頼内容一覧画面、依頼詳細一覧画面の３画面で構成しています。 呼び鈴アプリの実装 呼び鈴アプリをどのように実装しているか解説していきます。 AppSheet の設定 AppSheet を利用したアプリの作成方法については、Google 公式の How to create an app や Google で AppSheet を検索するといくつか作成例のサイトが表示されますので、今回の機能を実装するにあたり重要な 「依頼詳細一覧画面から Slack 通知」 設定の部分にフォーカスして解説します。 1. Data の設定 Tables と Slices について、それぞれ設定します。 Tables では、アプリケーションの元となるデータを格納する「テーブル」を作成します。 Slices では、テーブルから必要な行と列のみを表示させたり、条件にあうデータのみを表示させたりして、必要なデータを抽出した「テーブルの一部分」を作成します。 1-1. Tables の設定 今回 Table は以下の 5 つを用意しました。 テーブルは、スプレッドシートにテーブルとなるデータを作成した後、AppSheet と連携します。連携方法は Connect your data to AppSheet の動画を参考にしてください。 テーブル名 利用用途 Client 依頼者選択画面で選択されたユーザー名を一時的に保存するテーブル Doorbell 依頼内容一覧画面に表示するテーブル DoorbellDetails 依頼詳細一覧画面に表示するテーブル CallHistory 呼出履歴を保存するテーブル UserList 依頼者選択画面に表示するテーブル 依頼詳細一覧画面と呼び出し機能に関連する、「DoorbellDetails」と「CallHistory」について詳しく説明します。 ・ DoorbellDetails 依頼詳細一覧画面に表示したい内容を一覧で記載します。 分類 ID 列は Doorbell でも同名の列を作成し、そこで設定した値と合わせてください。また、対応 ID は分類 ID 内でユニークになるように設定してください。 対応説明に関しては、任意で入力していただければ大丈夫です。 SlackChannel 列に Slack チャンネルに投稿する用の Webhook URL を設定してください。 Incoming Webhooks 等を使用すると、 Webhook URL が取得できます。 3 行目以降のデータは、 2 行目を参考に設定してください。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 1 分類 ID 対応 ID 対応名 対応説明 SlackChannel 2 receipt 1 入社にあたって貸与物を受け取りたい （通知先チャンネルの Webhook URL を設定） Table での設定例 分類 ID と対応 ID を複合キー（分類 ID と対応 ID に「REQUIRE」を設定）としています。 ・ CallHistory 呼出履歴を保存するテーブルのため、ヘッダー以外の入力は不要です。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 F 列 G 列 1 CH_id CH_分類 ID CH_対応 ID CH_対応名 CH_SlackChannel CH_呼び出し日時 CH_依頼者 Table での設定例 1-2. Slices の設定 次に、Slice の設定を行います。Slice は依頼内容ごとに画面表示を切り替えるために「DoorbellDetails」のデータを元に作成します。 貸与物受け取りに関する Slice の場合、以下のように設定します。 設定項目名 設定値 Slice name 貸与物受け取り Source table DoorbellDetails Row filter condition [分類 ID]="receipt" 2. App の設定 Views について、それぞれ設定します。 2-1. Views の設定 依頼詳細一覧画面について詳しく説明します。 ・依頼詳細一覧画面 依頼内容一覧画面から遷移できるように、依頼詳細一覧画面は依頼内容ごとに準備します。ここでは貸与物受け取り画面を例として設定しています。 設定項目名 設定値 View name 貸与物受け取り画面 For this data 貸与物受け取り View type deck Position ref Primary header _RowNumber Secondary header 対応名 Event Actions(Row Selected) SaveAndMoveToClientForm（Actions の設定後、設定可能になります） 3. Actions の設定 各ボタンを押したときの動作を定義します。 実際には他にもいくつか Action を設定していますが、Slack 通知に関係する Action は以下の 3 つです。 Action 名 利用用途 MoveToClientForm 依頼者選択画面に遷移する SaveCallHistory CallHistory にデータを保存する SaveAndMoveToClientForm CallHistory に保存後、依頼者選択画面に遷移する ・ MoveToClientForm 依頼者選択画面に遷移する Action です。 設定項目名 設定値 Action name MoveToClientForm For a record of this table DoorbellDetails Do this App: go to another view within this app Target ”#view=依頼者選択” ・ SaveCallHistory 「CallHistory」テーブルにデータを保存する Action です。 選択された氏名については「Client」テーブルからデータを取得しています。 また、SlackChannel 列の記載がない場合は、画面に「呼び出し」ボタンを表示させないように設定しています。 設定項目名 設定値 Action name SaveCallHistory For a record of this table DoorbellDetails Do this Data: add a new row to another table using values from this row Set these columns CH_id = UNIQUEID() CH_分類 ID = [分類 ID] CH_対応 ID = [対応 ID] CH_対応名 = [対応名] CH_SlackChannel = [SlackChannel] CH_呼び出し日次 = TODAY() & ” ” & TIMENOW() CH_依頼者 = Client[ご自身の氏名] Display name 呼び出し Only if this condition is true ISNOTBLANK([SlackChannel]) Needs confirmation? True Confirmation Message CONCATENATE(“依頼者：“,Client[ご自身の氏名],"",“呼び出し内容：”,[対応名],"",“担当者を呼び出しますか？”) ・ SaveAndMoveToClientForm 呼出履歴に保存後、依頼者選択画面に遷移する Action です。この Action を依頼詳細一覧画面の Event Actions に紐付けます。 設定項目名 設定値 Action name SaveAndMoveToClientForm For a record of this table DoorbellDetails Do this Grouped: execute a sequence of actions Actions SaveCallHistory MoveToClientForm スプレッドシート の設定 AppSheet からスプレッドシートの「CallHistory」シートに呼出履歴データが登録（行追加）されたら、Slack 通知 GAS を実行するように設定します。 GAS の記述 先程テーブルを作成したスプレッドシートの拡張機能 →Apps Script を開きます。 App Script 上で新しく「.gs」ファイルを作成し、「CallHistory」 のシートが更新されたときだけ、Slack に通知するように GAS を記述します。 function onChange ( e ) { // イベントが"EDIT"の場合のみ実行。 if ( e . changeType === "EDIT" ) { const ar = e . source . getActiveRange (); const sheet = e . source . getActiveSheet (); // CallHistory シートが更新された場合のみ Slack に通知する if ( e . source . getSheetName () == "CallHistory" ) { const inquiry = sheet . getRange ( ar . getRow (), 4 ). getValue (); const slackWebHook = sheet . getRange ( ar . getRow (), 5 ). getValue (); const clientName = sheet . getRange ( ar . getRow (), 7 ). getValue (); notifyToSlack ( slackWebHook , "コーポカウンター呼び鈴" , ":notification_bell:" , // お好きな Slack の絵文字を設定して下さい。 `<!here> ${ clientName } さんが ${ inquiry } で呼び出ししています。` ); } } } function notifyToSlack ( url , username , icon , message ) { const jsonData = { username: username , icon_emoji: icon , text: message , }; const payload = JSON . stringify ( jsonData ); const options = { method: "post" , contentType: "application/json" , payload: payload , }; UrlFetchApp . fetch ( url , options ); } トリガーの設定 スプレッドシートに呼出履歴が登録（行追加）されたら、 onChange() を実行するように設定します。 問題なく動作すると、Slack に以下のようなメッセージが通知されます。 実装する上で難しかったこと AppSheet でアプリを開発するにあたり、ノーコード開発の制約でかゆいところに手が届かず、いくつか工夫して実装する必要がありました。 1. 氏名の選択結果を保持したまま、依頼内容選択の結果を「CallHistory」に書き出すこと AppSheet が複数の選択結果を保持できるような仕組みになっておらず、依頼者選択画面から依頼内容一覧画面に遷移すると選択結果が消えるため、依頼者選択結果をデータとしてどこかに保持する必要がありました。 → 氏名の選択結果を格納する一行だけのテーブル「Client」を作成し、「CallHistory」への書き出し時に「Client」の一行目のデータを読むように設定しました。 2. ボタンの配置と表示が変更できないこと 基本的にボタンに表示されているテキストは変更できず、ボタン位置も自由に変更できないため（画面の最上部か最下部のみ）、画面の設計には苦労しました。 → テキストに関しては、Settings → Views → Localization で「Save」を「次へ」に変更して対応しました。 ボタン位置に関してはどうにもならなかったため、なるべく導線がわかりやすいように画面上に説明を入れるようにしています。 ノーコードがゆえの制約はありますが、AppSheet での開発は簡単かつ迅速にできるため、小規模なアプリケーションであれば、おすすめの環境です。 以上、呼び鈴アプリの開発についてお話しました。 ここからは、コーポレート IT についてご紹介していきます。 コーポレート IT について コーポレートデザイン部は、 「未来志向で社内の IT インフラを含めたオフィス環境をデザインすること」 をミッションに業務しており、現在 2 つのチームがあります。 一つはワークプレイスチームで、ペン一本からオフィス施工に関することまで、オフィス環境全般を担当しています。 そして、もう一つがコーポレート IT チームで、全社で利用する SaaS の管理やオフィスのネットワークインフラ、社内アプリの開発等、全従業員が利用する IT ソリューション全般の企画・開発・運用を担当しています。 コーポレート IT の役割 コーポレート IT としてのミッションは、**「テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図ること」**です。 そのために、単に上流・下流というフェーズ分担ではなく、システム導入だけでもない、全社の組織カルチャーづくりも見据えた全従業員が利用するコーポレート基盤をデザインし、そのデザインに基づいて IT ソリューションを実装、運用していきます。 逆に、各部門のミッション達成、業務目的達成のための個別の IT ソリューションは、ツールゆえ各部門が主管です。コーポレート IT は IT プロフェッショナルとしてアドバイスしたり、システム設計や実装する形で、技術的実現を担うものとして各部門とコラボします。 各部門の IT ソリューションに対する PDCA を各部門がオーナーシップを持つことで、利用時の要望や改善に対して、非常に早いサイクルで実施することができています。 業務内容紹介 コーポレート IT では、日々の従業員への IT サポート以外に、複数のプロジェクトが同時に走っています。以下に記載している業務はほんの一例です。 端末管理アプリケーションおよびセキュリティ製品の企画/導入/運用 オフィス移転でのネットワーク構築（ネットワークの設計、機器選定〜運用まで） 社外来客用受付システムの改修/運用 呼び鈴アプリの企画/開発/運用 従業員向けの情報セキュリティ研修 人事基幹システムの導入支援/各システムとの連携機能構築 etc また、メンバー自ら提案して企画化、予算を確保することもあり、アイデアに対して柔軟に対応しています。 業務を行う上で常に意識していること・大事にしていること コーポレート IT として業務を行う上で大事にしている考え方が、3 つあります。従業員の生産性が向上する環境の構築に必要不可欠と考えており、これらをもとに意思決定しています。 1. システム選定/技術選定の考え方 システム選定/技術選定の原則としては、グローバルトップシェアで、かつ、北米急成長企業が選定しているものを未来志向で活用していくことを意識していますが、その技術やツールを導入して、得たい本来の目的が達成できるかどうかを、広い視点から判断して意思決定しています。 2. ユーザー IT サポートの考え方 老子が言っている『授人以魚 不如授人以漁(人に魚を授けることは、漁の仕方を教えるに及ばない)』ということを大切にしており、「わからない」という人に単に答えを「教える」ことをせず、組織の未来のために、組織全体の IT リテラシーを上げること、スムーズに自己解決できる環境を整えることに努めています。 「ユーザー IT サポートが増え続け、サポート人件費が増大し、高コストな生産性の低いコーポレート IT チーム」とならないよう心がけています。 3. ルールを作らず、仕組み/仕掛けで解決する ルールを覚えなくても、意識しなくとも、狙ったことが自然に進むよう、仕組み/仕掛けによって目的を成す方法を作ることを意識しています。 例えば、高速道路のサービスエリアにある駐車場の逆走を禁止するために斜めに駐車位置ラインを引くといった、意識せずとも行動を一定方向に促す行動設計が望ましく、呼び鈴アプリもそういった仕掛けやプロセス設計の一環です。 さいごに コーポレート IT は全従業員が利用する IT 基盤の維持・改善が求められるため、非常に重要な役割です。また、急拡大する組織の中においては、今までの仕組みが通用しなくなり、未来志向で新たな仕組みを設計し続けていく必要があり、常にコーポレート IT チームの活躍の余地がたくさん存在しています。 そのため、未来志向で #革新と改善を主導 できる方を絶賛募集しております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。様々な業種でスペシャリストを募集しています。興味がある方は是非ご連絡ください。医療という社会貢献性の高い領域へ、一緒に挑戦しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは。コーポレートデザイン部でコーポレート IT を担当している清水です。 コーポレート IT では全従業員が利用するネットワークインフラや SaaS といった IT 全般を統括しており、社内で発生している課題について IT を駆使して解決しています。 今回は、こうした課題解決の一例として、「 呼び鈴アプリ 」の開発について背景と実装のご紹介をし、最後に コーポレート IT チーム の業務内容や理念についてご紹介したいと思います。 呼び鈴アプリの開発背景 弊社では、チャットツールである「 Slack 」と「 Google Workspace 」や「 TeamSpirit 」等を連携して、来客者受付システムや 稟議ワークフローシステム 、オフィス空調最適化システム等、チャットをベースにした業務運用（ChatOps）を数多く行っています。 今回はその中でも、サポートを受けたい場合にコーポレート部門の担当者を呼び出しできるアプリ、 通称：呼び鈴アプリ をご紹介しようと思います。 呼び鈴アプリ導入前の困りごと IT 備品や健康保険証等の物の受け渡しや PC トラブルへの対応など、従業員へのサポート対応の際、サポートを依頼した従業員とコーポレート部門との間で、以下のような困りごとが発生していました。 ■ 従業員側の困りごと ・誰に話しかけたらよいかわからない IT 備品や健康保険証等を受け取りにコーポレート部門の座席に来たが、誰に話しかけたらよいかわからず、ウロウロしている方が結構いました。結果、別の部門に話しかけて、別の部門の方が正しい部門に案内するという時間も発生していました。 ・時間調整に手間がかかる PC トラブルへの対応の際は、コーポレート IT の担当者が依頼者の席まで行って作業をしていたため、担当者と依頼者で時間の調整が必要でした。直前で都合が悪くなり、リスケが発生することもしばしばありました。 ■ コーポレート部門の困りごと ・依頼者が見つけづらい 座席表を見て依頼者のところまで行くが、直近で座席変更があって居ると思っていたところに居ないことや、指定の時間に席に居ないといったことが度々発生していました。 ・個人情報が見えると困る 従業員が人事部から健康保険証等の書類を受け取る際、人事部の方は個人情報を扱うため、PC 画面の見える位置まで来られると困るという事情があり、特定の位置で待ってもらいたいというニーズがありました。 ・従業員の氏名確認に手間がかかる 全従業員分の氏名は把握できないため、コーポレート部門に来た従業員本人に名前を聞いて確認し、一旦席に戻って、貸与する IT 備品や健康保険証等を探して渡すという、席を行ったり来たりする状況でした。 ・周りの業務状況に配慮が必要 依頼者の席で PC トラブル対応をすると、周りの人が業務に集中していたり、顧客と電話していたりするため、業務に支障がでないようになるべく小声で話す必要がありました。 ・依頼者への対応が属人化しがち コーポレート部門の担当者と依頼者の間で作業の時間を調整していましたが、担当者が急な打ち合わせやお休みで不在になってしまったときは、他の担当者への引き継ぎ対応が漏れてしまうことがありました。 上記の課題を解決するために、 従業員の方向けにコーポレート部門の担当者を呼び出すアプリ を作りました！ どういったアプリか 呼び鈴アプリは、従業員とコーポレート部門で対面での作業/受け渡しが発生すること（PC トラブルへの対応/落とし物の受け渡し/健康保険証のお渡し等）に関して、iPad で依頼内容に応じた コーポレート部門の担当者を呼び出すことができるアプリ です。 コーポレート部門の近くのカウンターの上に iPad が置いてあり、そこから呼び出してもらいます。 ちなみに、カウンターはこんな感じのスペースで、従業員の方がセルフサービスで IT 備品交換を行えるブースもあります。 アプリの利用イメージ まず、従業員はカウンターまで行き、iPad の呼び鈴アプリから呼び出し依頼を行います。 呼び出し依頼は専用の Slack チャンネルに通知が来るので、各コーポレート部門の担当者が通知内容を確認して、従業員が居るカウンターに行き、対応という流れになります。 画面イメージ 利用方法は、自身の名前を選択してもらい、コーポレート部門への依頼内容を選択するという形です。 導入後の効果 呼び鈴アプリの導入によって、 従業員がコーポレート部門からサポートを受けたり、物を受け渡ししたいときは、 自身が都合の良いタイミングで カウンターの呼び鈴アプリに来れば良く、 利便性が向上した 。 Slack 通知に依頼者氏名が表示されるので、 氏名を確認する必要がなくなった。 コーポレート部門の担当者が 依頼者の席を探して尋ねなくてよくなった。 というように困りごとが改善されました。 また、特定のメンバーが対応するのではなく、呼び出されたタイミングで席に居る全メンバーが対応できるような運用にすることで、PC/IT 備品や健康保険証等の物の受け渡し、PC のトラブル対応等のサポート対応が属人的にならず、離席していても、休暇をとっていても誰でも対応できる体制になりました。 呼び鈴アプリの構成 呼び鈴アプリの開発にあたっては 1. 先述の課題を解決すること 2. コーポレート IT 内でプロジェクトが複数動いているため、他のプロジェクトの進捗に影響がでないように、工数をさほどかけずにクイックに開発できること 3. なるべくランニングコストをかけないこと という要件から、 AppSheet と Google App Script（以降 GAS） で実装することを決めました。 機能検証期間を含めて 1 週間程度で実装できています。 AppSheet は、Google から提供されている、ノーコードでアプリケーション開発ができるツールです。 AppSheet は、エンジニアではなく「現場で働く人が作る」という思想をもとにサービスが開始されました。そのため、プログラミング知識がない人でも、マウス操作のみで簡単にアプリケーションを開発できるようになっています。 サービス連携図 UI を AppSheet で、Slack への通知を GAS で実装しています。 画面構成 画面は依頼者選択画面、依頼内容一覧画面、依頼詳細一覧画面の３画面で構成しています。 呼び鈴アプリの実装 呼び鈴アプリをどのように実装しているか解説していきます。 AppSheet の設定 AppSheet を利用したアプリの作成方法については、Google 公式の How to create an app や Google で AppSheet を検索するといくつか作成例のサイトが表示されますので、今回の機能を実装するにあたり重要な 「依頼詳細一覧画面から Slack 通知」 設定の部分にフォーカスして解説します。 1. Data の設定 Tables と Slices について、それぞれ設定します。 Tables では、アプリケーションの元となるデータを格納する「テーブル」を作成します。 Slices では、テーブルから必要な行と列のみを表示させたり、条件にあうデータのみを表示させたりして、必要なデータを抽出した「テーブルの一部分」を作成します。 1-1. Tables の設定 今回 Table は以下の 5 つを用意しました。 テーブルは、スプレッドシートにテーブルとなるデータを作成した後、AppSheet と連携します。連携方法は Connect your data to AppSheet の動画を参考にしてください。 テーブル名 利用用途 Client 依頼者選択画面で選択されたユーザー名を一時的に保存するテーブル Doorbell 依頼内容一覧画面に表示するテーブル DoorbellDetails 依頼詳細一覧画面に表示するテーブル CallHistory 呼出履歴を保存するテーブル UserList 依頼者選択画面に表示するテーブル 依頼詳細一覧画面と呼び出し機能に関連する、「DoorbellDetails」と「CallHistory」について詳しく説明します。 ・ DoorbellDetails 依頼詳細一覧画面に表示したい内容を一覧で記載します。 分類 ID 列は Doorbell でも同名の列を作成し、そこで設定した値と合わせてください。また、対応 ID は分類 ID 内でユニークになるように設定してください。 対応説明に関しては、任意で入力していただければ大丈夫です。 SlackChannel 列に Slack チャンネルに投稿する用の Webhook URL を設定してください。 Incoming Webhooks 等を使用すると、 Webhook URL が取得できます。 3 行目以降のデータは、 2 行目を参考に設定してください。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 1 分類 ID 対応 ID 対応名 対応説明 SlackChannel 2 receipt 1 入社にあたって貸与物を受け取りたい （通知先チャンネルの Webhook URL を設定） Table での設定例 分類 ID と対応 ID を複合キー（分類 ID と対応 ID に「REQUIRE」を設定）としています。 ・ CallHistory 呼出履歴を保存するテーブルのため、ヘッダー以外の入力は不要です。 スプレッドシートへのデータ入力例 行番号 A 列 B 列 C 列 D 列 E 列 F 列 G 列 1 CH_id CH_分類 ID CH_対応 ID CH_対応名 CH_SlackChannel CH_呼び出し日時 CH_依頼者 Table での設定例 1-2. Slices の設定 次に、Slice の設定を行います。Slice は依頼内容ごとに画面表示を切り替えるために「DoorbellDetails」のデータを元に作成します。 貸与物受け取りに関する Slice の場合、以下のように設定します。 設定項目名 設定値 Slice name 貸与物受け取り Source table DoorbellDetails Row filter condition [分類 ID]="receipt" 2. App の設定 Views について、それぞれ設定します。 2-1. Views の設定 依頼詳細一覧画面について詳しく説明します。 ・依頼詳細一覧画面 依頼内容一覧画面から遷移できるように、依頼詳細一覧画面は依頼内容ごとに準備します。ここでは貸与物受け取り画面を例として設定しています。 設定項目名 設定値 View name 貸与物受け取り画面 For this data 貸与物受け取り View type deck Position ref Primary header _RowNumber Secondary header 対応名 Event Actions(Row Selected) SaveAndMoveToClientForm（Actions の設定後、設定可能になります） 3. Actions の設定 各ボタンを押したときの動作を定義します。 実際には他にもいくつか Action を設定していますが、Slack 通知に関係する Action は以下の 3 つです。 Action 名 利用用途 MoveToClientForm 依頼者選択画面に遷移する SaveCallHistory CallHistory にデータを保存する SaveAndMoveToClientForm CallHistory に保存後、依頼者選択画面に遷移する ・ MoveToClientForm 依頼者選択画面に遷移する Action です。 設定項目名 設定値 Action name MoveToClientForm For a record of this table DoorbellDetails Do this App: go to another view within this app Target ”#view=依頼者選択” ・ SaveCallHistory 「CallHistory」テーブルにデータを保存する Action です。 選択された氏名については「Client」テーブルからデータを取得しています。 また、SlackChannel 列の記載がない場合は、画面に「呼び出し」ボタンを表示させないように設定しています。 設定項目名 設定値 Action name SaveCallHistory For a record of this table DoorbellDetails Do this Data: add a new row to another table using values from this row Set these columns CH_id = UNIQUEID() CH_分類 ID = [分類 ID] CH_対応 ID = [対応 ID] CH_対応名 = [対応名] CH_SlackChannel = [SlackChannel] CH_呼び出し日次 = TODAY() & ” ” & TIMENOW() CH_依頼者 = Client[ご自身の氏名] Display name 呼び出し Only if this condition is true ISNOTBLANK([SlackChannel]) Needs confirmation? True Confirmation Message CONCATENATE(“依頼者：“,Client[ご自身の氏名],"",“呼び出し内容：”,[対応名],"",“担当者を呼び出しますか？”) ・ SaveAndMoveToClientForm 呼出履歴に保存後、依頼者選択画面に遷移する Action です。この Action を依頼詳細一覧画面の Event Actions に紐付けます。 設定項目名 設定値 Action name SaveAndMoveToClientForm For a record of this table DoorbellDetails Do this Grouped: execute a sequence of actions Actions SaveCallHistory MoveToClientForm スプレッドシート の設定 AppSheet からスプレッドシートの「CallHistory」シートに呼出履歴データが登録（行追加）されたら、Slack 通知 GAS を実行するように設定します。 GAS の記述 先程テーブルを作成したスプレッドシートの拡張機能 →Apps Script を開きます。 App Script 上で新しく「.gs」ファイルを作成し、「CallHistory」 のシートが更新されたときだけ、Slack に通知するように GAS を記述します。 function onChange ( e ) { // イベントが"EDIT"の場合のみ実行。 if ( e . changeType === "EDIT" ) { const ar = e . source . getActiveRange (); const sheet = e . source . getActiveSheet (); // CallHistory シートが更新された場合のみ Slack に通知する if ( e . source . getSheetName () == "CallHistory" ) { const inquiry = sheet . getRange ( ar . getRow (), 4 ). getValue (); const slackWebHook = sheet . getRange ( ar . getRow (), 5 ). getValue (); const clientName = sheet . getRange ( ar . getRow (), 7 ). getValue (); notifyToSlack ( slackWebHook , "コーポカウンター呼び鈴" , ":notification_bell:" , // お好きな Slack の絵文字を設定して下さい。 `<!here> ${ clientName } さんが ${ inquiry } で呼び出ししています。` ); } } } function notifyToSlack ( url , username , icon , message ) { const jsonData = { username: username , icon_emoji: icon , text: message , }; const payload = JSON . stringify ( jsonData ); const options = { method: "post" , contentType: "application/json" , payload: payload , }; UrlFetchApp . fetch ( url , options ); } トリガーの設定 スプレッドシートに呼出履歴が登録（行追加）されたら、 onChange() を実行するように設定します。 問題なく動作すると、Slack に以下のようなメッセージが通知されます。 実装する上で難しかったこと AppSheet でアプリを開発するにあたり、ノーコード開発の制約でかゆいところに手が届かず、いくつか工夫して実装する必要がありました。 1. 氏名の選択結果を保持したまま、依頼内容選択の結果を「CallHistory」に書き出すこと AppSheet が複数の選択結果を保持できるような仕組みになっておらず、依頼者選択画面から依頼内容一覧画面に遷移すると選択結果が消えるため、依頼者選択結果をデータとしてどこかに保持する必要がありました。 → 氏名の選択結果を格納する一行だけのテーブル「Client」を作成し、「CallHistory」への書き出し時に「Client」の一行目のデータを読むように設定しました。 2. ボタンの配置と表示が変更できないこと 基本的にボタンに表示されているテキストは変更できず、ボタン位置も自由に変更できないため（画面の最上部か最下部のみ）、画面の設計には苦労しました。 → テキストに関しては、Settings → Views → Localization で「Save」を「次へ」に変更して対応しました。 ボタン位置に関してはどうにもならなかったため、なるべく導線がわかりやすいように画面上に説明を入れるようにしています。 ノーコードがゆえの制約はありますが、AppSheet での開発は簡単かつ迅速にできるため、小規模なアプリケーションであれば、おすすめの環境です。 以上、呼び鈴アプリの開発についてお話しました。 ここからは、コーポレート IT についてご紹介していきます。 コーポレート IT について コーポレートデザイン部は、 「未来志向で社内の IT インフラを含めたオフィス環境をデザインすること」 をミッションに業務しており、現在 2 つのチームがあります。 一つはワークプレイスチームで、ペン一本からオフィス施工に関することまで、オフィス環境全般を担当しています。 そして、もう一つがコーポレート IT チームで、全社で利用する SaaS の管理やオフィスのネットワークインフラ、社内アプリの開発等、全従業員が利用する IT ソリューション全般の企画・開発・運用を担当しています。 コーポレート IT の役割 コーポレート IT としてのミッションは、**「テクノロジーと創意工夫で従業員のパフォーマンスの最大化を図ること」**です。 そのために、単に上流・下流というフェーズ分担ではなく、システム導入だけでもない、全社の組織カルチャーづくりも見据えた全従業員が利用するコーポレート基盤をデザインし、そのデザインに基づいて IT ソリューションを実装、運用していきます。 逆に、各部門のミッション達成、業務目的達成のための個別の IT ソリューションは、ツールゆえ各部門が主管です。コーポレート IT は IT プロフェッショナルとしてアドバイスしたり、システム設計や実装する形で、技術的実現を担うものとして各部門とコラボします。 各部門の IT ソリューションに対する PDCA を各部門がオーナーシップを持つことで、利用時の要望や改善に対して、非常に早いサイクルで実施することができています。 業務内容紹介 コーポレート IT では、日々の従業員への IT サポート以外に、複数のプロジェクトが同時に走っています。以下に記載している業務はほんの一例です。 端末管理アプリケーションおよびセキュリティ製品の企画/導入/運用 オフィス移転でのネットワーク構築（ネットワークの設計、機器選定〜運用まで） 社外来客用受付システムの改修/運用 呼び鈴アプリの企画/開発/運用 従業員向けの情報セキュリティ研修 人事基幹システムの導入支援/各システムとの連携機能構築 etc また、メンバー自ら提案して企画化、予算を確保することもあり、アイデアに対して柔軟に対応しています。 業務を行う上で常に意識していること・大事にしていること コーポレート IT として業務を行う上で大事にしている考え方が、3 つあります。従業員の生産性が向上する環境の構築に必要不可欠と考えており、これらをもとに意思決定しています。 1. システム選定/技術選定の考え方 システム選定/技術選定の原則としては、グローバルトップシェアで、かつ、北米急成長企業が選定しているものを未来志向で活用していくことを意識していますが、その技術やツールを導入して、得たい本来の目的が達成できるかどうかを、広い視点から判断して意思決定しています。 2. ユーザー IT サポートの考え方 老子が言っている『授人以魚 不如授人以漁(人に魚を授けることは、漁の仕方を教えるに及ばない)』ということを大切にしており、「わからない」という人に単に答えを「教える」ことをせず、組織の未来のために、組織全体の IT リテラシーを上げること、スムーズに自己解決できる環境を整えることに努めています。 「ユーザー IT サポートが増え続け、サポート人件費が増大し、高コストな生産性の低いコーポレート IT チーム」とならないよう心がけています。 3. ルールを作らず、仕組み/仕掛けで解決する ルールを覚えなくても、意識しなくとも、狙ったことが自然に進むよう、仕組み/仕掛けによって目的を成す方法を作ることを意識しています。 例えば、高速道路のサービスエリアにある駐車場の逆走を禁止するために斜めに駐車位置ラインを引くといった、意識せずとも行動を一定方向に促す行動設計が望ましく、呼び鈴アプリもそういった仕掛けやプロセス設計の一環です。 さいごに コーポレート IT は全従業員が利用する IT 基盤の維持・改善が求められるため、非常に重要な役割です。また、急拡大する組織の中においては、今までの仕組みが通用しなくなり、未来志向で新たな仕組みを設計し続けていく必要があり、常にコーポレート IT チームの活躍の余地がたくさん存在しています。 そのため、未来志向で #革新と改善を主導 できる方を絶賛募集しております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メドレーでは、医療分野の社会課題を IT にて解決するために日々邁進しております。様々な業種でスペシャリストを募集しています。興味がある方は是非ご連絡ください。医療という社会貢献性の高い領域へ、一緒に挑戦しませんか？ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。今回はジョブメドレーアカデミー（以下、アカデミー）の開発の皆さんに集まってもらい、 TypeScript と NestJS を使ったバックエンド開発をどのように行なっているのかをインタビューしました。 以前、アカデミーがリニューアルした際にチームメンバーにインタビューした note もあるので、未読の方はぜひそちらもご覧いただければと思います。 インタビュイー紹介 岸田さん SES 会社で業務システム開発、バングラデシュに支社があるオフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。 熊本さん 2019 年メドレーに新卒入社。半年の研修を経てジョブメドレーの開発に携わる。現在はアカデミーの開発に携わる。大学では機械学習を用いた自動車の自動運転の研究をしていた。 牧野さん 2021 年 11 月にメドレー入社。不動産業界の SaaS を開発している会社でのマネージャー・エンジニアを経験。現在はアカデミーの開発に携わる。 徳永さん 2022 年メドレーに新卒入社。 OJT 期間中からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。 アカデミーのアーキテクチャ 山田 : 早速ですが、現在のアカデミーのアーキテクチャについて話を伺いたいと思います。全体の構成としては現在どんな形になっているんでしょうか。 岸田 : 以前話をしたところから大幅に変わったところはないですが、大まかにはこんな感じになっています。 山田 : ありがとうございます、分かりやすいですね。 (手前)岸田さん・(奥)牧野さん 山田 : Web フロントエンドに関しては Next.js とグローバルの状態管理として Apollo Client を使っていると伺っています。バックエンドは色々あると思うのですが、DB に関しては PostgreSQL を使っているんですよね? 岸田 : はい、ORM としては Prisma を使っています。 山田 : こうした開発環境はどのように決まったんでしょうか?特に、開発言語を全て TypeScript で統一する、という意思決定が先にあってバックエンド側のフレームワークは NestJS にしようとなったのか、逆に NestJS を使おうとして TypeScript になったのかをお聞きできれば。 岸田 : 細かいところまでは記憶にないのですが、TypeScript を使って型で開発をしたいというのが一番大きい理由でした。 山田 : まずは TypeScript からだったんですね。そこから Web フレームワークとしては Express など他の物もあったと思いますが、NestJS を採用した理由は何だったのでしょうか? 岸田 : そうですね、色々選択肢はあったと思うんですが、現実的にサービスを運用するとなると Express と NestJS のどちらかかな、という感じになっていました。 どちらも実開発での経験を持っているメンバーはいなかったんですが、Web 開発で良く使われる Web フレームワークは、基本的な機能やコンセプトについては共通する部分が多いことに加えて、アカデミーも特殊な仕様があるプロダクトではないので、どちらを選んだとしてもメンバーが困ることはないだろうと考えました。 その上で細かい使い勝手などを検討したり GraphQL との親和性の高さや Express という枯れた技術をベースにしていて、 フレームワーク自体の信頼感もあるので NestJS に決めた という感じでした。 熊本 : 絞り込んだ段階で各メンバーが NestJS を試験的に触り、使用感を見てみましたが、大きく問題になる点もなかったので全員一致で決まった感じですね。 岸田 : 前述のように Express をベースにしているので何か困ったら最悪 Express にすれば良いなというのもありました。 牧野 : ここまで実際大きな問題というのは無かったです。 山田 : 今は GraphQL を使って API を作っていると思いますが、REST で作るという選択肢は最初から無かったんですか? 岸田 : はい、GraphQL を使えるメンバーが揃っているという状況であえて REST にするメリットは無いなという事で考えていませんでした。外部公開する API があるとか、パフォーマンスがすごく重要な重い API 呼び出しというのがあったら別だったでしょうけども。 山田 : そもそもの話になってしまうんですが、弊社のプロダクト開発でよく使われている Ruby on Rails を使う選択肢は無かったんでしょうか? 岸田 : 選択肢としてはあるにはあったんですが、プロダクトのフェイズとして現在既に成長をしているサービスであることや、メンバーのスキルセットとして Rails に慣れたメンバーがそこまで多くなかったことを考えると、いかに技術的負債を少なく保ちつつ、機能開発をしていけるかという点が重要になるので、現在の技術構成にしました。 これが既存サービスのリニューアルではなくて、新規で一から全部作っていかないといけないという状況であれば Rails を使うかもしれませんが、やっぱり型があってある程度開発効率が高くなるというのは魅力的だったので、 これからどんどんと機能開発をするには今の構成が良い と判断しました。 (手前)徳永さん・(奥)熊本さん 山田 : DB に関して PostgreSQL ですが、 MySQL などにするということは考えなかったですか? 熊本 : そうですね、リニューアル前のアカデミーが使っていたということがあり、大きく変えるメリットはあまり無かったのが大きいです。 岸田 : あとこれは自分の感覚なのですが、PostgreSQL の方がスマートに処理できることが多いという印象があるというのもありました。 山田 : 元々サービスで使っていたというのは、やっぱり大きいですね。ORM は Prisma ですよね。例えば他に TypeORM などの選択肢もあったと思いますが、こちらはどういった経緯で使うことになりましたか? 熊本 : 色々と触ってみた結果、Prisma が 自分たちの使い方にマッチしてた のが大きかったです。がっつりと SQL を自動生成するなどの手厚い機能は、自分達の使い方では必要もなかったですし。キャッチアップのためにペアプロなどもしましたが、 メンバーも使いやすい ということが確認できました。 山田 : 今ペアプロの話が出ましたが、どのような目的でやっていたんでしょうか。 熊本 : 初期の頃はメンバー間の知識などに偏りもあったので、そういったものを実際にコードを触りながら埋めていく という目的でした。実際に、GraphQL を使ったことがなかったメンバーも早く慣れてくれました。 山田 : なるほど。ある種学習も兼ねていたんですね。最終的に現在このアーキテクチャの使い勝手としては感想としてどうでしょうか? 岸田 : 言葉は違うかもしれないですが「 普通に使い勝手が良い 」という感じです。 もちろんメンバーが習熟してきたので、色々とコード的に改善しようという部分はあったりもしますが、今のところ本当に困った問題というのは無いので、非常に良い選択だったかと思います。 NestJS のテストコードについて 山田 : テストコードは基本書いているんですよね? 熊本 : はい、バックエンドは基本的に Jest で全部書いています。フロントエンドに関しては今まさに E2E テストをどのように実施していくかを試行錯誤しているところですね。 山田 : NestJS でテストコード書くのに何か困ったこととかありましたか? 岸田 : 困っているというわけではないですが、Rails でほぼ必ず使われている Factorybot に相当する機能が欲しいですね…。 山田 : 確かに Node.js だとそういったライブラリを見かけないですね…。 岸田 : 皆さんあんまり困ってないのかな?ということで今は簡易的なものを自作して使っています。 山田 : OSS で作ったら需要があるかもしれませんね。 現状の NestJS での開発の課題感 山田 : ここまで NestJS での開発について聞いてきましたが、プロダクト開発での課題は何かあったりしますか? 岸田 : 先ほども少し話をしたメンバーの習熟度が高くなったことによるコード改善の他には、NestJS というか Node.js が Rails に比べると定番ライブラリが少なめなのがあります。 例えば、 Sidekiq のようなライブラリって便利だと思うんですが、相当するライブラリでデファクトスタンダードというようなものが Node.js だと少ない気がしています。ライブラリが一杯あるのですが、デファクトまでいかないというものが多いという感想です。 山田 : 確かに Node.js だと同じ目的のライブラリが複数あって機能がちょっとずつ違うという感じがありますね。 牧野 : あとは機能開発にリソースを取っているので、細かい部分でのライブラリのアップデートが遅れ気味というのが課題感としてあります。 今のところはとてつもなく遅れているというわけではないのですが、積り積っていくとこういった部分が負債になっていくので、対応したいと思っています。 岸田 : こういったものも含めてプロダクト開発を円滑に回すために、自分も含めた各メンバーのスキルを広げて深くしていかないといけないなというのもありますね。 チームへのオンボーディングについて 山田 : さて、話が変わって現在アカデミーで一番最後にジョインしたのが徳永さんだと思いますが、オンボーディングなどはどのような感じだったんでしょうか。学生時代に NestJS はがっつり触っていたんでしたっけ? 徳永 : いえ、学生時代はチュートリアルをしたくらいで、深く使っていたということはなかったです。ですので、最初は全然プロダクトのコードが分からないというレベルで、ほとんど未経験でした。 山田 : なるほど。ほぼ未経験で新卒研修を経て、アカデミーの開発チームにジョインして困った部分などはありましたか? 徳永 : TypeScript を使っているというのは凄く自分にとって良くて、言語でつまづくということはほとんどありませんでした。 やはり 公式ドキュメントがすごく充実していますし、コミュニティの質の高い情報も多い ので。プロダクトに関しては過去の Pull Request や Issue 上のやり取りなどで、 どういう意図で実装されたものなのかを参照できたのが大きかった です。一方でバックエンドのデザインパターンなどは経験が少なく苦労した部分がありました。その部分はドキュメントで学習したり、周りのメンバーに直接質問しながらキャッチアップしていきました。 山田 : 今年は入社後研修も TypeScript で書く割合が Ruby よりも多かったので、それがもし逆だったら、もっと苦労していたかもしれないですね。 徳永 : そうですね、その可能性は十分にあり得ます。 山田 : あとアカデミーチームは火水木に勉強会を開催していますよね。ジョブメドレーの開発チームでも噂になっています。 岸田 : これは全員で集まる勉強会というわけではなく、 月によって各自テーマを決めて火水木 1 時間ずつスキルアップのために時間を確保し、学んだことなどをアウトプットしていく という形式です。アウトプットしたものは、お互いに確認して知識を深めていこうというものですね。 山田 : それは素敵な取り組みですね。あとは Figma で開発ドキュメントをまとめているのが印象的ですよね。 牧野 : 最初は岸田さんが率先して、開発した部分のドキュメントなんかを書いていたんですが、最近はチームで共有するようなものもほとんど Figma でまとめるようになっています。 熊本 : もちろん永続化しないといけないドキュメントは README なりコンフルエンスなりに書いていくのですが、ちょっとしたものを気軽に Figma にまとめられるのはすごく良いです。 岸田 : 他の人がやっていることなんかも絶対に目につく ので、そういった意味でもドキュメントが散らばらなくて今は良く機能していると思っています。 現状の課題感とアカデミーの開発に向く人 山田 : 最後になりますが、アカデミーに来てほしい人材はどういった方でしょうか? 徳永 : この プロダクトにわくわくできる方に来てほしい と思います。福祉業界に明るい方なんかは大歓迎です! 山田 : なるほど。プロダクトのビジネス面の理解をして楽しんで開発できる方ですね。技術的な部分では何かありますか? 岸田 : 今まで TypeScript と NestJS を中心に話していましたが、実はこれらができる人というのは必須条件ではありません。どの言語でもフレームワークでも ちゃんと Web 開発が分かっている方 であればという感じです。 他には 情報感度が高い人が良い と思います。言語化が難しいのですが、開発環境や言語、ライブラリなどできちんと最新の情報が取捨選択できる方がいると、チームがより活性化すると考えています。 バックエンドでいうとベース部分などもきちんと手を入れることができて、なおかつ人に教えるのが好きな方が入ってもらえると、チームへの知識伝播などもより上手くいくと考えています。 あるとより良いなという所だと、現在アプリは React Native で作られているんですが、React Native でのアプリ開発に強い方だと嬉しいですね。ユーザーに一番使われているのはアプリなので、さらにそのユーザビリティなどを高めるためには、アプリ開発に強い方に入ってもらえるとありがたいです。 山田 : よりアカデミーというプロダクトをドライブさせてくれる方にぜひ来てほしいところですね。本日はありがとうございました! おわりに メドレーの開発チームの中でも野心的なアーキテクチャで開発をしているアカデミーチームについてお伝えしました。 サービスを伸ばすために、適切に言語やフレームワークを選択していき、柔軟性を持って開発していってるんだなというのが伝わってきたインタビューでした。少しでも興味が出た方はぜひ、下のリンクからお話できればと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。今回はジョブメドレーアカデミー（以下、アカデミー）の開発の皆さんに集まってもらい、 TypeScript と NestJS を使ったバックエンド開発をどのように行なっているのかをインタビューしました。 以前、アカデミーがリニューアルした際にチームメンバーにインタビューした note もあるので、未読の方はぜひそちらもご覧いただければと思います。 インタビュイー紹介 岸田さん SES 会社で業務システム開発、バングラデシュに支社があるオフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。 熊本さん 2019 年メドレーに新卒入社。半年の研修を経てジョブメドレーの開発に携わる。現在はアカデミーの開発に携わる。大学では機械学習を用いた自動車の自動運転の研究をしていた。 牧野さん 2021 年 11 月にメドレー入社。不動産業界の SaaS を開発している会社でのマネージャー・エンジニアを経験。現在はアカデミーの開発に携わる。 徳永さん 2022 年メドレーに新卒入社。 OJT 期間中からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。 アカデミーのアーキテクチャ 山田 : 早速ですが、現在のアカデミーのアーキテクチャについて話を伺いたいと思います。全体の構成としては現在どんな形になっているんでしょうか。 岸田 : 以前話をしたところから大幅に変わったところはないですが、大まかにはこんな感じになっています。 山田 : ありがとうございます、分かりやすいですね。 (手前)岸田さん・(奥)牧野さん 山田 : Web フロントエンドに関しては Next.js とグローバルの状態管理として Apollo Client を使っていると伺っています。バックエンドは色々あると思うのですが、DB に関しては PostgreSQL を使っているんですよね? 岸田 : はい、ORM としては Prisma を使っています。 山田 : こうした開発環境はどのように決まったんでしょうか?特に、開発言語を全て TypeScript で統一する、という意思決定が先にあってバックエンド側のフレームワークは NestJS にしようとなったのか、逆に NestJS を使おうとして TypeScript になったのかをお聞きできれば。 岸田 : 細かいところまでは記憶にないのですが、TypeScript を使って型で開発をしたいというのが一番大きい理由でした。 山田 : まずは TypeScript からだったんですね。そこから Web フレームワークとしては Express など他の物もあったと思いますが、NestJS を採用した理由は何だったのでしょうか? 岸田 : そうですね、色々選択肢はあったと思うんですが、現実的にサービスを運用するとなると Express と NestJS のどちらかかな、という感じになっていました。 どちらも実開発での経験を持っているメンバーはいなかったんですが、Web 開発で良く使われる Web フレームワークは、基本的な機能やコンセプトについては共通する部分が多いことに加えて、アカデミーも特殊な仕様があるプロダクトではないので、どちらを選んだとしてもメンバーが困ることはないだろうと考えました。 その上で細かい使い勝手などを検討したり GraphQL との親和性の高さや Express という枯れた技術をベースにしていて、 フレームワーク自体の信頼感もあるので NestJS に決めた という感じでした。 熊本 : 絞り込んだ段階で各メンバーが NestJS を試験的に触り、使用感を見てみましたが、大きく問題になる点もなかったので全員一致で決まった感じですね。 岸田 : 前述のように Express をベースにしているので何か困ったら最悪 Express にすれば良いなというのもありました。 牧野 : ここまで実際大きな問題というのは無かったです。 山田 : 今は GraphQL を使って API を作っていると思いますが、REST で作るという選択肢は最初から無かったんですか? 岸田 : はい、GraphQL を使えるメンバーが揃っているという状況であえて REST にするメリットは無いなという事で考えていませんでした。外部公開する API があるとか、パフォーマンスがすごく重要な重い API 呼び出しというのがあったら別だったでしょうけども。 山田 : そもそもの話になってしまうんですが、弊社のプロダクト開発でよく使われている Ruby on Rails を使う選択肢は無かったんでしょうか? 岸田 : 選択肢としてはあるにはあったんですが、プロダクトのフェイズとして現在既に成長をしているサービスであることや、メンバーのスキルセットとして Rails に慣れたメンバーがそこまで多くなかったことを考えると、いかに技術的負債を少なく保ちつつ、機能開発をしていけるかという点が重要になるので、現在の技術構成にしました。 これが既存サービスのリニューアルではなくて、新規で一から全部作っていかないといけないという状況であれば Rails を使うかもしれませんが、やっぱり型があってある程度開発効率が高くなるというのは魅力的だったので、 これからどんどんと機能開発をするには今の構成が良い と判断しました。 (手前)徳永さん・(奥)熊本さん 山田 : DB に関して PostgreSQL ですが、 MySQL などにするということは考えなかったですか? 熊本 : そうですね、リニューアル前のアカデミーが使っていたということがあり、大きく変えるメリットはあまり無かったのが大きいです。 岸田 : あとこれは自分の感覚なのですが、PostgreSQL の方がスマートに処理できることが多いという印象があるというのもありました。 山田 : 元々サービスで使っていたというのは、やっぱり大きいですね。ORM は Prisma ですよね。例えば他に TypeORM などの選択肢もあったと思いますが、こちらはどういった経緯で使うことになりましたか? 熊本 : 色々と触ってみた結果、Prisma が 自分たちの使い方にマッチしてた のが大きかったです。がっつりと SQL を自動生成するなどの手厚い機能は、自分達の使い方では必要もなかったですし。キャッチアップのためにペアプロなどもしましたが、 メンバーも使いやすい ということが確認できました。 山田 : 今ペアプロの話が出ましたが、どのような目的でやっていたんでしょうか。 熊本 : 初期の頃はメンバー間の知識などに偏りもあったので、そういったものを実際にコードを触りながら埋めていく という目的でした。実際に、GraphQL を使ったことがなかったメンバーも早く慣れてくれました。 山田 : なるほど。ある種学習も兼ねていたんですね。最終的に現在このアーキテクチャの使い勝手としては感想としてどうでしょうか? 岸田 : 言葉は違うかもしれないですが「 普通に使い勝手が良い 」という感じです。 もちろんメンバーが習熟してきたので、色々とコード的に改善しようという部分はあったりもしますが、今のところ本当に困った問題というのは無いので、非常に良い選択だったかと思います。 NestJS のテストコードについて 山田 : テストコードは基本書いているんですよね? 熊本 : はい、バックエンドは基本的に Jest で全部書いています。フロントエンドに関しては今まさに E2E テストをどのように実施していくかを試行錯誤しているところですね。 山田 : NestJS でテストコード書くのに何か困ったこととかありましたか? 岸田 : 困っているというわけではないですが、Rails でほぼ必ず使われている Factorybot に相当する機能が欲しいですね…。 山田 : 確かに Node.js だとそういったライブラリを見かけないですね…。 岸田 : 皆さんあんまり困ってないのかな?ということで今は簡易的なものを自作して使っています。 山田 : OSS で作ったら需要があるかもしれませんね。 現状の NestJS での開発の課題感 山田 : ここまで NestJS での開発について聞いてきましたが、プロダクト開発での課題は何かあったりしますか? 岸田 : 先ほども少し話をしたメンバーの習熟度が高くなったことによるコード改善の他には、NestJS というか Node.js が Rails に比べると定番ライブラリが少なめなのがあります。 例えば、 Sidekiq のようなライブラリって便利だと思うんですが、相当するライブラリでデファクトスタンダードというようなものが Node.js だと少ない気がしています。ライブラリが一杯あるのですが、デファクトまでいかないというものが多いという感想です。 山田 : 確かに Node.js だと同じ目的のライブラリが複数あって機能がちょっとずつ違うという感じがありますね。 牧野 : あとは機能開発にリソースを取っているので、細かい部分でのライブラリのアップデートが遅れ気味というのが課題感としてあります。 今のところはとてつもなく遅れているというわけではないのですが、積り積っていくとこういった部分が負債になっていくので、対応したいと思っています。 岸田 : こういったものも含めてプロダクト開発を円滑に回すために、自分も含めた各メンバーのスキルを広げて深くしていかないといけないなというのもありますね。 チームへのオンボーディングについて 山田 : さて、話が変わって現在アカデミーで一番最後にジョインしたのが徳永さんだと思いますが、オンボーディングなどはどのような感じだったんでしょうか。学生時代に NestJS はがっつり触っていたんでしたっけ? 徳永 : いえ、学生時代はチュートリアルをしたくらいで、深く使っていたということはなかったです。ですので、最初は全然プロダクトのコードが分からないというレベルで、ほとんど未経験でした。 山田 : なるほど。ほぼ未経験で新卒研修を経て、アカデミーの開発チームにジョインして困った部分などはありましたか? 徳永 : TypeScript を使っているというのは凄く自分にとって良くて、言語でつまづくということはほとんどありませんでした。 やはり 公式ドキュメントがすごく充実していますし、コミュニティの質の高い情報も多い ので。プロダクトに関しては過去の Pull Request や Issue 上のやり取りなどで、 どういう意図で実装されたものなのかを参照できたのが大きかった です。一方でバックエンドのデザインパターンなどは経験が少なく苦労した部分がありました。その部分はドキュメントで学習したり、周りのメンバーに直接質問しながらキャッチアップしていきました。 山田 : 今年は入社後研修も TypeScript で書く割合が Ruby よりも多かったので、それがもし逆だったら、もっと苦労していたかもしれないですね。 徳永 : そうですね、その可能性は十分にあり得ます。 山田 : あとアカデミーチームは火水木に勉強会を開催していますよね。ジョブメドレーの開発チームでも噂になっています。 岸田 : これは全員で集まる勉強会というわけではなく、 月によって各自テーマを決めて火水木 1 時間ずつスキルアップのために時間を確保し、学んだことなどをアウトプットしていく という形式です。アウトプットしたものは、お互いに確認して知識を深めていこうというものですね。 山田 : それは素敵な取り組みですね。あとは Figma で開発ドキュメントをまとめているのが印象的ですよね。 牧野 : 最初は岸田さんが率先して、開発した部分のドキュメントなんかを書いていたんですが、最近はチームで共有するようなものもほとんど Figma でまとめるようになっています。 熊本 : もちろん永続化しないといけないドキュメントは README なりコンフルエンスなりに書いていくのですが、ちょっとしたものを気軽に Figma にまとめられるのはすごく良いです。 岸田 : 他の人がやっていることなんかも絶対に目につく ので、そういった意味でもドキュメントが散らばらなくて今は良く機能していると思っています。 現状の課題感とアカデミーの開発に向く人 山田 : 最後になりますが、アカデミーに来てほしい人材はどういった方でしょうか? 徳永 : この プロダクトにわくわくできる方に来てほしい と思います。福祉業界に明るい方なんかは大歓迎です! 山田 : なるほど。プロダクトのビジネス面の理解をして楽しんで開発できる方ですね。技術的な部分では何かありますか? 岸田 : 今まで TypeScript と NestJS を中心に話していましたが、実はこれらができる人というのは必須条件ではありません。どの言語でもフレームワークでも ちゃんと Web 開発が分かっている方 であればという感じです。 他には 情報感度が高い人が良い と思います。言語化が難しいのですが、開発環境や言語、ライブラリなどできちんと最新の情報が取捨選択できる方がいると、チームがより活性化すると考えています。 バックエンドでいうとベース部分などもきちんと手を入れることができて、なおかつ人に教えるのが好きな方が入ってもらえると、チームへの知識伝播などもより上手くいくと考えています。 あるとより良いなという所だと、現在アプリは React Native で作られているんですが、React Native でのアプリ開発に強い方だと嬉しいですね。ユーザーに一番使われているのはアプリなので、さらにそのユーザビリティなどを高めるためには、アプリ開発に強い方に入ってもらえるとありがたいです。 山田 : よりアカデミーというプロダクトをドライブさせてくれる方にぜひ来てほしいところですね。本日はありがとうございました! おわりに メドレーの開発チームの中でも野心的なアーキテクチャで開発をしているアカデミーチームについてお伝えしました。 サービスを伸ばすために、適切に言語やフレームワークを選択していき、柔軟性を持って開発していってるんだなというのが伝わってきたインタビューでした。少しでも興味が出た方はぜひ、下のリンクからお話できればと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに みなさん、こんにちは。エンジニアの山田です。今回はジョブメドレーアカデミー（以下、アカデミー）の開発の皆さんに集まってもらい、 TypeScript と NestJS を使ったバックエンド開発をどのように行なっているのかをインタビューしました。 以前、アカデミーがリニューアルした際にチームメンバーにインタビューした note もあるので、未読の方はぜひそちらもご覧いただければと思います。 インタビュイー紹介 岸田さん SES 会社で業務システム開発、バングラデシュに支社があるオフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。 熊本さん 2019 年メドレーに新卒入社。半年の研修を経てジョブメドレーの開発に携わる。現在はアカデミーの開発に携わる。大学では機械学習を用いた自動車の自動運転の研究をしていた。 牧野さん 2021 年 11 月にメドレー入社。不動産業界の SaaS を開発している会社でのマネージャー・エンジニアを経験。現在はアカデミーの開発に携わる。 徳永さん 2022 年メドレーに新卒入社。 OJT 期間中からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。 アカデミーのアーキテクチャ 山田 : 早速ですが、現在のアカデミーのアーキテクチャについて話を伺いたいと思います。全体の構成としては現在どんな形になっているんでしょうか。 岸田 : 以前話をしたところから大幅に変わったところはないですが、大まかにはこんな感じになっています。 山田 : ありがとうございます、分かりやすいですね。 (手前)岸田さん・(奥)牧野さん 山田 : Web フロントエンドに関しては Next.js とグローバルの状態管理として Apollo Client を使っていると伺っています。バックエンドは色々あると思うのですが、DB に関しては PostgreSQL を使っているんですよね? 岸田 : はい、ORM としては Prisma を使っています。 山田 : こうした開発環境はどのように決まったんでしょうか?特に、開発言語を全て TypeScript で統一する、という意思決定が先にあってバックエンド側のフレームワークは NestJS にしようとなったのか、逆に NestJS を使おうとして TypeScript になったのかをお聞きできれば。 岸田 : 細かいところまでは記憶にないのですが、TypeScript を使って型で開発をしたいというのが一番大きい理由でした。 山田 : まずは TypeScript からだったんですね。そこから Web フレームワークとしては Express など他の物もあったと思いますが、NestJS を採用した理由は何だったのでしょうか? 岸田 : そうですね、色々選択肢はあったと思うんですが、現実的にサービスを運用するとなると Express と NestJS のどちらかかな、という感じになっていました。 どちらも実開発での経験を持っているメンバーはいなかったんですが、Web 開発で良く使われる Web フレームワークは、基本的な機能やコンセプトについては共通する部分が多いことに加えて、アカデミーも特殊な仕様があるプロダクトではないので、どちらを選んだとしてもメンバーが困ることはないだろうと考えました。 その上で細かい使い勝手などを検討したり GraphQL との親和性の高さや Express という枯れた技術をベースにしていて、 フレームワーク自体の信頼感もあるので NestJS に決めた という感じでした。 熊本 : 絞り込んだ段階で各メンバーが NestJS を試験的に触り、使用感を見てみましたが、大きく問題になる点もなかったので全員一致で決まった感じですね。 岸田 : 前述のように Express をベースにしているので何か困ったら最悪 Express にすれば良いなというのもありました。 牧野 : ここまで実際大きな問題というのは無かったです。 山田 : 今は GraphQL を使って API を作っていると思いますが、REST で作るという選択肢は最初から無かったんですか? 岸田 : はい、GraphQL を使えるメンバーが揃っているという状況であえて REST にするメリットは無いなという事で考えていませんでした。外部公開する API があるとか、パフォーマンスがすごく重要な重い API 呼び出しというのがあったら別だったでしょうけども。 山田 : そもそもの話になってしまうんですが、弊社のプロダクト開発でよく使われている Ruby on Rails を使う選択肢は無かったんでしょうか? 岸田 : 選択肢としてはあるにはあったんですが、プロダクトのフェイズとして現在既に成長をしているサービスであることや、メンバーのスキルセットとして Rails に慣れたメンバーがそこまで多くなかったことを考えると、いかに技術的負債を少なく保ちつつ、機能開発をしていけるかという点が重要になるので、現在の技術構成にしました。 これが既存サービスのリニューアルではなくて、新規で一から全部作っていかないといけないという状況であれば Rails を使うかもしれませんが、やっぱり型があってある程度開発効率が高くなるというのは魅力的だったので、 これからどんどんと機能開発をするには今の構成が良い と判断しました。 (手前)徳永さん・(奥)熊本さん 山田 : DB に関して PostgreSQL ですが、 MySQL などにするということは考えなかったですか? 熊本 : そうですね、リニューアル前のアカデミーが使っていたということがあり、大きく変えるメリットはあまり無かったのが大きいです。 岸田 : あとこれは自分の感覚なのですが、PostgreSQL の方がスマートに処理できることが多いという印象があるというのもありました。 山田 : 元々サービスで使っていたというのは、やっぱり大きいですね。ORM は Prisma ですよね。例えば他に TypeORM などの選択肢もあったと思いますが、こちらはどういった経緯で使うことになりましたか? 熊本 : 色々と触ってみた結果、Prisma が 自分たちの使い方にマッチしてた のが大きかったです。がっつりと SQL を自動生成するなどの手厚い機能は、自分達の使い方では必要もなかったですし。キャッチアップのためにペアプロなどもしましたが、 メンバーも使いやすい ということが確認できました。 山田 : 今ペアプロの話が出ましたが、どのような目的でやっていたんでしょうか。 熊本 : 初期の頃はメンバー間の知識などに偏りもあったので、そういったものを実際にコードを触りながら埋めていく という目的でした。実際に、GraphQL を使ったことがなかったメンバーも早く慣れてくれました。 山田 : なるほど。ある種学習も兼ねていたんですね。最終的に現在このアーキテクチャの使い勝手としては感想としてどうでしょうか? 岸田 : 言葉は違うかもしれないですが「 普通に使い勝手が良い 」という感じです。 もちろんメンバーが習熟してきたので、色々とコード的に改善しようという部分はあったりもしますが、今のところ本当に困った問題というのは無いので、非常に良い選択だったかと思います。 NestJS のテストコードについて 山田 : テストコードは基本書いているんですよね? 熊本 : はい、バックエンドは基本的に Jest で全部書いています。フロントエンドに関しては今まさに E2E テストをどのように実施していくかを試行錯誤しているところですね。 山田 : NestJS でテストコード書くのに何か困ったこととかありましたか? 岸田 : 困っているというわけではないですが、Rails でほぼ必ず使われている Factorybot に相当する機能が欲しいですね…。 山田 : 確かに Node.js だとそういったライブラリを見かけないですね…。 岸田 : 皆さんあんまり困ってないのかな?ということで今は簡易的なものを自作して使っています。 山田 : OSS で作ったら需要があるかもしれませんね。 現状の NestJS での開発の課題感 山田 : ここまで NestJS での開発について聞いてきましたが、プロダクト開発での課題は何かあったりしますか? 岸田 : 先ほども少し話をしたメンバーの習熟度が高くなったことによるコード改善の他には、NestJS というか Node.js が Rails に比べると定番ライブラリが少なめなのがあります。 例えば、 Sidekiq のようなライブラリって便利だと思うんですが、相当するライブラリでデファクトスタンダードというようなものが Node.js だと少ない気がしています。ライブラリが一杯あるのですが、デファクトまでいかないというものが多いという感想です。 山田 : 確かに Node.js だと同じ目的のライブラリが複数あって機能がちょっとずつ違うという感じがありますね。 牧野 : あとは機能開発にリソースを取っているので、細かい部分でのライブラリのアップデートが遅れ気味というのが課題感としてあります。 今のところはとてつもなく遅れているというわけではないのですが、積り積っていくとこういった部分が負債になっていくので、対応したいと思っています。 岸田 : こういったものも含めてプロダクト開発を円滑に回すために、自分も含めた各メンバーのスキルを広げて深くしていかないといけないなというのもありますね。 チームへのオンボーディングについて 山田 : さて、話が変わって現在アカデミーで一番最後にジョインしたのが徳永さんだと思いますが、オンボーディングなどはどのような感じだったんでしょうか。学生時代に NestJS はがっつり触っていたんでしたっけ? 徳永 : いえ、学生時代はチュートリアルをしたくらいで、深く使っていたということはなかったです。ですので、最初は全然プロダクトのコードが分からないというレベルで、ほとんど未経験でした。 山田 : なるほど。ほぼ未経験で新卒研修を経て、アカデミーの開発チームにジョインして困った部分などはありましたか? 徳永 : TypeScript を使っているというのは凄く自分にとって良くて、言語でつまづくということはほとんどありませんでした。 やはり 公式ドキュメントがすごく充実していますし、コミュニティの質の高い情報も多い ので。プロダクトに関しては過去の Pull Request や Issue 上のやり取りなどで、 どういう意図で実装されたものなのかを参照できたのが大きかった です。一方でバックエンドのデザインパターンなどは経験が少なく苦労した部分がありました。その部分はドキュメントで学習したり、周りのメンバーに直接質問しながらキャッチアップしていきました。 山田 : 今年は入社後研修も TypeScript で書く割合が Ruby よりも多かったので、それがもし逆だったら、もっと苦労していたかもしれないですね。 徳永 : そうですね、その可能性は十分にあり得ます。 山田 : あとアカデミーチームは火水木に勉強会を開催していますよね。ジョブメドレーの開発チームでも噂になっています。 岸田 : これは全員で集まる勉強会というわけではなく、 月によって各自テーマを決めて火水木 1 時間ずつスキルアップのために時間を確保し、学んだことなどをアウトプットしていく という形式です。アウトプットしたものは、お互いに確認して知識を深めていこうというものですね。 山田 : それは素敵な取り組みですね。あとは Figma で開発ドキュメントをまとめているのが印象的ですよね。 牧野 : 最初は岸田さんが率先して、開発した部分のドキュメントなんかを書いていたんですが、最近はチームで共有するようなものもほとんど Figma でまとめるようになっています。 熊本 : もちろん永続化しないといけないドキュメントは README なりコンフルエンスなりに書いていくのですが、ちょっとしたものを気軽に Figma にまとめられるのはすごく良いです。 岸田 : 他の人がやっていることなんかも絶対に目につく ので、そういった意味でもドキュメントが散らばらなくて今は良く機能していると思っています。 現状の課題感とアカデミーの開発に向く人 山田 : 最後になりますが、アカデミーに来てほしい人材はどういった方でしょうか? 徳永 : この プロダクトにわくわくできる方に来てほしい と思います。福祉業界に明るい方なんかは大歓迎です! 山田 : なるほど。プロダクトのビジネス面の理解をして楽しんで開発できる方ですね。技術的な部分では何かありますか? 岸田 : 今まで TypeScript と NestJS を中心に話していましたが、実はこれらができる人というのは必須条件ではありません。どの言語でもフレームワークでも ちゃんと Web 開発が分かっている方 であればという感じです。 他には 情報感度が高い人が良い と思います。言語化が難しいのですが、開発環境や言語、ライブラリなどできちんと最新の情報が取捨選択できる方がいると、チームがより活性化すると考えています。 バックエンドでいうとベース部分などもきちんと手を入れることができて、なおかつ人に教えるのが好きな方が入ってもらえると、チームへの知識伝播などもより上手くいくと考えています。 あるとより良いなという所だと、現在アプリは React Native で作られているんですが、React Native でのアプリ開発に強い方だと嬉しいですね。ユーザーに一番使われているのはアプリなので、さらにそのユーザビリティなどを高めるためには、アプリ開発に強い方に入ってもらえるとありがたいです。 山田 : よりアカデミーというプロダクトをドライブさせてくれる方にぜひ来てほしいところですね。本日はありがとうございました! おわりに メドレーの開発チームの中でも野心的なアーキテクチャで開発をしているアカデミーチームについてお伝えしました。 サービスを伸ばすために、適切に言語やフレームワークを選択していき、柔軟性を持って開発していってるんだなというのが伝わってきたインタビューでした。少しでも興味が出た方はぜひ、下のリンクからお話できればと思います! https://www.medley.jp/jobs

はじめに みなさん、こんにちは。エンジニアの山田です。今回はジョブメドレーアカデミー（以下、アカデミー）の開発の皆さんに集まってもらい、 TypeScript と NestJS を使ったバックエンド開発をどのように行なっているのかをインタビューしました。 以前、アカデミーがリニューアルした際にチームメンバーにインタビューした note もあるので、未読の方はぜひそちらもご覧いただければと思います。 インタビュイー紹介 岸田さん SES 会社で業務システム開発、バングラデシュに支社があるオフショア開発をしている会社でブリッジエンジニアという経験を経て、2019 年メドレー入社。 その後ジョブメドレーで開発をリード。現在はアカデミーのプロダクト責任者を務める。 熊本さん 2019 年メドレーに新卒入社。半年の研修を経てジョブメドレーの開発に携わる。現在はアカデミーの開発に携わる。大学では機械学習を用いた自動車の自動運転の研究をしていた。 牧野さん 2021 年 11 月にメドレー入社。不動産業界の SaaS を開発している会社でのマネージャー・エンジニアを経験。現在はアカデミーの開発に携わる。 徳永さん 2022 年メドレーに新卒入社。 OJT 期間中からアカデミーの開発に携わる。大学では、対話 AI システム・ AI との対話用プラットフォームの研究開発をしていた。 アカデミーのアーキテクチャ 山田 : 早速ですが、現在のアカデミーのアーキテクチャについて話を伺いたいと思います。全体の構成としては現在どんな形になっているんでしょうか。 岸田 : 以前話をしたところから大幅に変わったところはないですが、大まかにはこんな感じになっています。 山田 : ありがとうございます、分かりやすいですね。 (手前)岸田さん・(奥)牧野さん 山田 : Web フロントエンドに関しては Next.js とグローバルの状態管理として Apollo Client を使っていると伺っています。バックエンドは色々あると思うのですが、DB に関しては PostgreSQL を使っているんですよね? 岸田 : はい、ORM としては Prisma を使っています。 山田 : こうした開発環境はどのように決まったんでしょうか?特に、開発言語を全て TypeScript で統一する、という意思決定が先にあってバックエンド側のフレームワークは NestJS にしようとなったのか、逆に NestJS を使おうとして TypeScript になったのかをお聞きできれば。 岸田 : 細かいところまでは記憶にないのですが、TypeScript を使って型で開発をしたいというのが一番大きい理由でした。 山田 : まずは TypeScript からだったんですね。そこから Web フレームワークとしては Express など他の物もあったと思いますが、NestJS を採用した理由は何だったのでしょうか? 岸田 : そうですね、色々選択肢はあったと思うんですが、現実的にサービスを運用するとなると Express と NestJS のどちらかかな、という感じになっていました。 どちらも実開発での経験を持っているメンバーはいなかったんですが、Web 開発で良く使われる Web フレームワークは、基本的な機能やコンセプトについては共通する部分が多いことに加えて、アカデミーも特殊な仕様があるプロダクトではないので、どちらを選んだとしてもメンバーが困ることはないだろうと考えました。 その上で細かい使い勝手などを検討したり GraphQL との親和性の高さや Express という枯れた技術をベースにしていて、 フレームワーク自体の信頼感もあるので NestJS に決めた という感じでした。 熊本 : 絞り込んだ段階で各メンバーが NestJS を試験的に触り、使用感を見てみましたが、大きく問題になる点もなかったので全員一致で決まった感じですね。 岸田 : 前述のように Express をベースにしているので何か困ったら最悪 Express にすれば良いなというのもありました。 牧野 : ここまで実際大きな問題というのは無かったです。 山田 : 今は GraphQL を使って API を作っていると思いますが、REST で作るという選択肢は最初から無かったんですか? 岸田 : はい、GraphQL を使えるメンバーが揃っているという状況であえて REST にするメリットは無いなという事で考えていませんでした。外部公開する API があるとか、パフォーマンスがすごく重要な重い API 呼び出しというのがあったら別だったでしょうけども。 山田 : そもそもの話になってしまうんですが、弊社のプロダクト開発でよく使われている Ruby on Rails を使う選択肢は無かったんでしょうか? 岸田 : 選択肢としてはあるにはあったんですが、プロダクトのフェイズとして現在既に成長をしているサービスであることや、メンバーのスキルセットとして Rails に慣れたメンバーがそこまで多くなかったことを考えると、いかに技術的負債を少なく保ちつつ、機能開発をしていけるかという点が重要になるので、現在の技術構成にしました。 これが既存サービスのリニューアルではなくて、新規で一から全部作っていかないといけないという状況であれば Rails を使うかもしれませんが、やっぱり型があってある程度開発効率が高くなるというのは魅力的だったので、 これからどんどんと機能開発をするには今の構成が良い と判断しました。 (手前)徳永さん・(奥)熊本さん 山田 : DB に関して PostgreSQL ですが、 MySQL などにするということは考えなかったですか? 熊本 : そうですね、リニューアル前のアカデミーが使っていたということがあり、大きく変えるメリットはあまり無かったのが大きいです。 岸田 : あとこれは自分の感覚なのですが、PostgreSQL の方がスマートに処理できることが多いという印象があるというのもありました。 山田 : 元々サービスで使っていたというのは、やっぱり大きいですね。ORM は Prisma ですよね。例えば他に TypeORM などの選択肢もあったと思いますが、こちらはどういった経緯で使うことになりましたか? 熊本 : 色々と触ってみた結果、Prisma が 自分たちの使い方にマッチしてた のが大きかったです。がっつりと SQL を自動生成するなどの手厚い機能は、自分達の使い方では必要もなかったですし。キャッチアップのためにペアプロなどもしましたが、 メンバーも使いやすい ということが確認できました。 山田 : 今ペアプロの話が出ましたが、どのような目的でやっていたんでしょうか。 熊本 : 初期の頃はメンバー間の知識などに偏りもあったので、そういったものを実際にコードを触りながら埋めていく という目的でした。実際に、GraphQL を使ったことがなかったメンバーも早く慣れてくれました。 山田 : なるほど。ある種学習も兼ねていたんですね。最終的に現在このアーキテクチャの使い勝手としては感想としてどうでしょうか? 岸田 : 言葉は違うかもしれないですが「 普通に使い勝手が良い 」という感じです。 もちろんメンバーが習熟してきたので、色々とコード的に改善しようという部分はあったりもしますが、今のところ本当に困った問題というのは無いので、非常に良い選択だったかと思います。 NestJS のテストコードについて 山田 : テストコードは基本書いているんですよね? 熊本 : はい、バックエンドは基本的に Jest で全部書いています。フロントエンドに関しては今まさに E2E テストをどのように実施していくかを試行錯誤しているところですね。 山田 : NestJS でテストコード書くのに何か困ったこととかありましたか? 岸田 : 困っているというわけではないですが、Rails でほぼ必ず使われている Factorybot に相当する機能が欲しいですね…。 山田 : 確かに Node.js だとそういったライブラリを見かけないですね…。 岸田 : 皆さんあんまり困ってないのかな?ということで今は簡易的なものを自作して使っています。 山田 : OSS で作ったら需要があるかもしれませんね。 現状の NestJS での開発の課題感 山田 : ここまで NestJS での開発について聞いてきましたが、プロダクト開発での課題は何かあったりしますか? 岸田 : 先ほども少し話をしたメンバーの習熟度が高くなったことによるコード改善の他には、NestJS というか Node.js が Rails に比べると定番ライブラリが少なめなのがあります。 例えば、 Sidekiq のようなライブラリって便利だと思うんですが、相当するライブラリでデファクトスタンダードというようなものが Node.js だと少ない気がしています。ライブラリが一杯あるのですが、デファクトまでいかないというものが多いという感想です。 山田 : 確かに Node.js だと同じ目的のライブラリが複数あって機能がちょっとずつ違うという感じがありますね。 牧野 : あとは機能開発にリソースを取っているので、細かい部分でのライブラリのアップデートが遅れ気味というのが課題感としてあります。 今のところはとてつもなく遅れているというわけではないのですが、積り積っていくとこういった部分が負債になっていくので、対応したいと思っています。 岸田 : こういったものも含めてプロダクト開発を円滑に回すために、自分も含めた各メンバーのスキルを広げて深くしていかないといけないなというのもありますね。 チームへのオンボーディングについて 山田 : さて、話が変わって現在アカデミーで一番最後にジョインしたのが徳永さんだと思いますが、オンボーディングなどはどのような感じだったんでしょうか。学生時代に NestJS はがっつり触っていたんでしたっけ? 徳永 : いえ、学生時代はチュートリアルをしたくらいで、深く使っていたということはなかったです。ですので、最初は全然プロダクトのコードが分からないというレベルで、ほとんど未経験でした。 山田 : なるほど。ほぼ未経験で新卒研修を経て、アカデミーの開発チームにジョインして困った部分などはありましたか? 徳永 : TypeScript を使っているというのは凄く自分にとって良くて、言語でつまづくということはほとんどありませんでした。 やはり 公式ドキュメントがすごく充実していますし、コミュニティの質の高い情報も多い ので。プロダクトに関しては過去の Pull Request や Issue 上のやり取りなどで、 どういう意図で実装されたものなのかを参照できたのが大きかった です。一方でバックエンドのデザインパターンなどは経験が少なく苦労した部分がありました。その部分はドキュメントで学習したり、周りのメンバーに直接質問しながらキャッチアップしていきました。 山田 : 今年は入社後研修も TypeScript で書く割合が Ruby よりも多かったので、それがもし逆だったら、もっと苦労していたかもしれないですね。 徳永 : そうですね、その可能性は十分にあり得ます。 山田 : あとアカデミーチームは火水木に勉強会を開催していますよね。ジョブメドレーの開発チームでも噂になっています。 岸田 : これは全員で集まる勉強会というわけではなく、 月によって各自テーマを決めて火水木 1 時間ずつスキルアップのために時間を確保し、学んだことなどをアウトプットしていく という形式です。アウトプットしたものは、お互いに確認して知識を深めていこうというものですね。 山田 : それは素敵な取り組みですね。あとは Figma で開発ドキュメントをまとめているのが印象的ですよね。 牧野 : 最初は岸田さんが率先して、開発した部分のドキュメントなんかを書いていたんですが、最近はチームで共有するようなものもほとんど Figma でまとめるようになっています。 熊本 : もちろん永続化しないといけないドキュメントは README なりコンフルエンスなりに書いていくのですが、ちょっとしたものを気軽に Figma にまとめられるのはすごく良いです。 岸田 : 他の人がやっていることなんかも絶対に目につく ので、そういった意味でもドキュメントが散らばらなくて今は良く機能していると思っています。 現状の課題感とアカデミーの開発に向く人 山田 : 最後になりますが、アカデミーに来てほしい人材はどういった方でしょうか? 徳永 : この プロダクトにわくわくできる方に来てほしい と思います。福祉業界に明るい方なんかは大歓迎です! 山田 : なるほど。プロダクトのビジネス面の理解をして楽しんで開発できる方ですね。技術的な部分では何かありますか? 岸田 : 今まで TypeScript と NestJS を中心に話していましたが、実はこれらができる人というのは必須条件ではありません。どの言語でもフレームワークでも ちゃんと Web 開発が分かっている方 であればという感じです。 他には 情報感度が高い人が良い と思います。言語化が難しいのですが、開発環境や言語、ライブラリなどできちんと最新の情報が取捨選択できる方がいると、チームがより活性化すると考えています。 バックエンドでいうとベース部分などもきちんと手を入れることができて、なおかつ人に教えるのが好きな方が入ってもらえると、チームへの知識伝播などもより上手くいくと考えています。 あるとより良いなという所だと、現在アプリは React Native で作られているんですが、React Native でのアプリ開発に強い方だと嬉しいですね。ユーザーに一番使われているのはアプリなので、さらにそのユーザビリティなどを高めるためには、アプリ開発に強い方に入ってもらえるとありがたいです。 山田 : よりアカデミーというプロダクトをドライブさせてくれる方にぜひ来てほしいところですね。本日はありがとうございました! おわりに メドレーの開発チームの中でも野心的なアーキテクチャで開発をしているアカデミーチームについてお伝えしました。 サービスを伸ばすために、適切に言語やフレームワークを選択していき、柔軟性を持って開発していってるんだなというのが伝わってきたインタビューでした。少しでも興味が出た方はぜひ、下のリンクからお話できればと思います! 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp