TECH PLAY

ニフティ株式会社

ニフティ株式会社 の技術ブログ

517

はじめに この記事は、 ニフティグループ Advent Calendar 2022 1日目の記事です。 急に冷え込んだと思ったら、なんともう12月です!年末になると1年を振り返りたくなりますね。 スクラムでは、一定期間(スプリント)ごとにふりかえりを行うことをレトロスペクティブと呼びます。 このレトロスペクティブですが、私たちのチームでは、メンバーが交代でファシリテートをし、毎回いろいろなやり方を試してきました。 以前レトロスペクティブのおすすめを何点か紹介した記事をかきましたが、 レトロスペクティブのおすすめアクティビティ 今回はいろいろなケース別に、良かったふりかえり手法を紹介していきたいと思います。 リモートでも話しやすい場づくり リモートワークも増え、オンラインだとミーティングが盛り上がりにくい、ファシリテーターや一部の人ばかりが話してしまうという話をよく聞きます。 ながら作業で聞いている人や、ゲスト気分で参加している人に、このふりかえりの場に意識を向けてもらうための取り組みをしましょう。 一言だけ話す 最近買ったものは何?とか、無人島に持って行くなら?とか、そういった気軽な質問をします。 アイスブレイクとして一人だけでしゃべってしまう人もいますが、できる限り全員になにか答えてもらうことがお勧めです。 こういったアクションはメンバーが打ち解けることを目的とされやすいですが、実際、MTGの数分で打ち解けることはなかなか難しいです。(何回もアイスブレイクや雑談を積み重ねて打ち解けていくものかと思います) ふりかえりの始まりとしては「なんでもいいから本題に入る前に声出しをしてもらえればOK」くらいの気持ちで取り組んでみましょう。なんなら、あいさつだけでもかまいません。 簡単に体を動かす 参加人数が多い時や、あまり雑談が浮かばないときは体を動かすこともお勧めです。 「みなさんカメラをONにしてください。椅子から立ち上がって、大きく伸びをしましょう」 と言うだけでOKです。 一度作業から離れて、このふりかえりの場に意識を向けてもらえればじゅうぶんに「場がつくれた」と言えると思います。 十分に打ち解けて親しいメンバーばかりだとしても、一度この場に意識を向けてもらうという意味で、なにか話すなり体を動かすなりということから始めることをおすすめします。 さまざまなふりかえり手法 いくつかのふりかえりアクティビティを、40-50分ほどで収まるようなやり方になるよう紹介しています。 チームメンバーを知る ふりかえりというよりは1時間かけられるアイスブレイク手法となります。 価値観ポーカー https://wevox.io/valuescard 詳しいルールは上記サイトをご確認ください。 メンバーがどんな価値観を大事にしているかがわかります。 手持ちの価値観で、優先度が高くない価値観カードをどんどん捨てて行く必要があるので やたらインパクトのある絵面になり、盛り上がりやすいです。 できたばかりのチームではもちろん、もう長く過ごしているメンバーでも、こういうタイプだと思っていたことと、本人が大切にしてる価値観にどれだけギャップがあるかを埋めることができます。 地元トーク 過去に住んでいたところ周辺のおすすめポイントや、自分がそこで当時どう過ごしていたかをGoogle mapのストリートビューをつかって持ち回りで紹介していきます。 地方特有のチェーン店や、気になる不思議な建物、ここの桜が綺麗など、がんばって話を振らなくても話題が尽きにくいです。 自分の過去について話すことは、相手に対して自己開示をしやすくするひとつの足がかりになると思います。 チームの状態を客観視する アジャイルの車輪 SCRUMMASTER THE BOOKのエクササイズを参考にしています。 書籍では「個人個人がどのくらいアジャイルに適応できているか」という検査や他者との比較を目的として行うことになっていましたが、今回レトロスペクティブに取り入れるにあたって 「チームがどのような状態にあるか確認する」 と言う目的にし、みんなで話し合いながら書いてみるというスタイルでやってみました。 上の図では、青色が現在、黄色が半年後になっていたい姿です。 特に意識的にやっていきたい項目に丸をつけています。 ポイント グラフの目盛り表現にはそこまで厳密さを求めない。今(または半年後)どの状態にあるかを話し合うことが、このアクティビティの主題。 すべての項目を半年後に伸ばす必要があるわけではない。半年では伸ばせない項目が何かを知ることも大事 あまり何回もするふりかえりではなく、半年ごとに1回するくらいでOK 熱気球 気球を自分達のチームとみなして、 気球(チーム)にとって上昇気流・追い風になったこと 気球(チーム)にとって荷物・足を引っ張る要因だったこと 気球(チーム)にとって、将来的に嵐・混乱させる要因になりえること を書いていきます。上昇気流と荷物は現在の状況を示し、嵐は将来の予測を示します。 ポイント なにか大きめのリリースに向かっている「途中」に行うと良い 「嵐」を避けて晴れた日に向かうために、できることはなにかを考える 「荷物」が重すぎて動けなくなった時にどう対応するかも考える 人ではなく物事にフォーカスして振り返る ×私の作業が遅くて、みんなの足を引っ張ってしまった ○不慣れなタスクに時間がかかってしまった ふりかえり手法を毎回変えるとチームはどうなるか いくつかふりかえり手法を紹介しましたが「なぜ毎回レトロスペクティブの方法を変えるのか」と聞かれることがあります。 マンネリ防止という観点もありますが、さまざまな視点で振り返るほうがチームの成長につながると思います。 レトロスペクティブはチームの定期検診だと考えています。 定期検診で体重だけを測り続けたとしたら、気づける病気はかなり限られてしまいますよね。 それと同じように、チームの長所や問題も、同じふりかえり方=同じアングルから見ていても限られた情報しか得ることができません。誰しも考え方や視点にはクセがでてしまうものです。 自分の感情にフォーカスしてみる、他人の不安にフォーカスしてみる、チームを客観視してみるというように、あらゆる角度からふりかえって行くことで、チームの本当に良いところや、根深い問題が見つけやすくなります。 また、物事をよりよくするためには、各自が自主的に工夫を凝らすことも必要です。 私たちのチームではスクラムイベントのファシリテーターを持ち回りにしています。 レトロスペクティブは前回と同じふりかえり手法にはしない、と決めておくと「今回のふりかえりはどんな手法がいいかな」「このふりかえりはチームに合いそうだな」というように、各々がいまのチームの状態を見つめるきっかけにもなります。 チームの関係性をよりよくしていったり、問題を早く解決するためには、今までにやっていなかったなにかをしたほうがいいケースが多いです。慣れ親しんだ対処方法を繰り返しても、一定ラインから成長は鈍化します。 ふりかえり手法を毎回変えたときのメリット・デメリット メリット チームの問題が大きくなる前に早くみつけやすい チームの成長をずっと続けることができる 飽きない デメリット あまりうまくいかないふりかえりが発生することもある 準備に少し時間がかかる ふりかえり手法を変えない時のメリット・デメリット メリット 準備の時間が短い 慣れ親しんだ方法なので戸惑わない デメリット マンネリ化しやすい 観点に偏りが出てしまって、新たな問題に気づきにくい 一定ライン以上は成長できない チームの問題に早期に気づき成長を加速するためにも、いろいろなふりかえり手法を試してみることは効果的な取り組みだと思います。 レトロスペクティブという定期検診を多角的に行って、チームの健康と成長を保ち続けましょう。 明日は、 tatsuya-miyamoto さんの ニフティトップページの運用メンバーで障害対応ロールプレイングをやってみたよ! です。 お楽しみに! We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
有志によるスクラム本がでました! N1! 制度でスクラムエバンジェリストを担当している西野です。 9/11にオフライン開催された技術書典13にて、ニフティ有志で執筆したスクラム本の頒布を行いました! スクラムマスターの話を中心に、いろいろなチームのスクラムとの戦いの記録が読めます。 以下からDLできるので、まだ読んでいない方はまずDLしてからこの記事を読んでください! ニフティのスクラム:ニフティ – 技術書典マーケット 発刊記念イベントしてみた! 喜ばしいことに想像以上のDL数があったので、この本を出すにあたってのバックグラウンドトークイベントを 「ニフティのスクラム」執筆者が語る! 〜スクラムぶっちゃけ話〜 と題して行いました。 ↓アーカイブ動画はこちらから↓ 「ニフティのスクラム」執筆者が語る! 〜スクラムぶっちゃけ話〜 – youtube 「ニフティのスクラム」執筆者が語る! 〜スクラムぶっちゃけ話〜のサマリー 登壇者 スピーカー:西野 香織(N1!スクラムエバンジェリスト・マイニフティチーム スクラムマスター) スピーカー:畑谷 啓志(オプションサービスチーム スクラムマスター) スピーカー: 小浦 由佳(社内プラットフォーム チーム スクラムマスター) ファシリテーター: 高田 渉(入会システムチーム スクラムマスター) 登壇者LT ニフティのスクラム」をなぜ出したかと概要紹介 2つのスクラムチームを合体させるとどうなるか? 「ニフティのスクラム」p41 同タイトルの概要紹介 超属人化組織の情シスでスクラム 「ニフティのスクラム」p32 同タイトル記事の概要紹介 スクラム一問一答 〜NIFTY Tech Talk編〜 「ニフティのスクラム」でもスクラム一問一答というコーナーがあるのですが、今回、3人のスクラムマスター同士で本には載せられなかったスクラムに関する疑問について答えてみました。 過去に行った社内スクラムマスターの情報共有会や、お互いに聞いてみたかった内容を質問として取り上げています。 システムを熟知している人の負担が大きくなりがちだけどどうしてる? システムを熟知している人ばかりに仕事の負担が大きくならないよう、属人化解消をどう進めているか 小浦 チームメンバーができる程度の粒度までタスクを分解する 誰でもとれるようなSBIには頭に★をつけて見やすくしている 業務共有やマニュアル化を徹底する もともと、それぞれのメンバーが専任的にプロダクトを担当していたので、自分の担当ではなかったプロダクトのタスクを取るよう工夫している 違う業務をどのくらいの割合担当したかの検査 畑谷 モブプロを実施して属人化を解消している タイトルにあるぶっちゃけ話的にいうと、もともと属人化が進んでいた なんでもモブプロにするわけではなく、コアの部分だけを対象としてモブプロ モブプロだとコードを書く効率自体は上がるわけではないが、レビュー時間が短縮されるため、トータルでかかる工数はそこまで変わらない 西野 システムを熟知している人の理解度を100%だとして、全員が30%くらいまで理解できていれば、理解度100%の人が1人しかいないことは問題ではない タスクを分解したときに、このタスクについてサポートする人をタスクに明記しておく 畑谷さんのチームと同じくモブプロも導入している システムを熟知している人が最初ナビゲーターをやるシーンが多いとおもうが、みんなが慣れてきたら、その人はナビゲーターもドライバーもなるべくせずに見守るようにする 熟知している人がどこまで離れても大丈夫かを少しずつ測る 急ぎの仕事があると「システムを熟知している人にやってもらおう」となりがちなので、属人化解消期間にはそういう仕事をなるべく入れないような調整も必要 よかったレトロスペクティブある? ファシリテーターである高田から挙げた質問。KPTをよく使うが、ほかの良かったレトロスペクティブを知りたい。 畑谷 アジャイルレトロスペクティブズ に載っている内容が素晴らしいため、ここから実践している 特にタイムラインという振り返りを、データ収集のフェーズでよくやっている スプリントの中でやってきたことを付箋に貼って見える化する 特に(スプリントをまたぐような)大きな開発で、開発着手からリリースまでを振り返るときに、このイベントでテンションが上がった・下がったということを共有できる そこから得たデータで、KPTを考えるといった次のアクションにつなげることができる 西野 レトロスペクティブは毎回変えるようにしている レトロスペクティブについてのqiita記事を書いたのでよかったら読んでほしい https://qiita.com/kanishionori/items/9900c6a8d1e7a4e9dda6 障害がおきたときはフィッシュボーンをよく使う 起きた障害を魚の頭として、そこから魚の骨のように、その障害を起こした要因としてこんなものがあったかも…というのを書いていく レトロスペクティブに限ったことではないが、デイリースクラム以外のあらゆるスクラムイベントでファイブフィンガーをおすすめしている 5本指で自分の満足度を表現すする。とても満足なら5(手をパーにする)、まったく満足していないなら0(手をグーにする) 畑谷さんが挙げていたタイムラインだが、タイムラインを書く時にどんなイベントが起きたかを抽出するのが記憶ベースだと大変。どうやっているか 確かに大変。初めてやったときは、事前にタイムラインを書かせてほしいというような要望が出たりした(畑谷) タイムラインを自分もよくつかっているが、思い出すのが大変なのはすごくわかる(小浦) 小浦 象、死んだ魚、嘔吐 象:見ないふりをしている問題 死んだ魚:早くごめんなさいをしたほうがいい悩みの種 嘔吐:ぶっちゃけ話 チームの中で表出してない課題や、メンバーの率直な気持ちが聞ける 今のプロダクトオーナーにどうやって権限を持たせることができたか? プロダクトオーナーに権限がないと、プロダクトの方向性を見失ってしまうこともあるが、スクラムマスターとしてどのようにプロダクトオーナーの権限を持たせたか 西野 とても難しい問題 PO本人も、どんな権限があるかわかってない事が多い まずはそのチームで決められることを把握する もしPOが決定を渋ることがあれば、それを誰に確認しなきゃいけないかを聞くことで、権限をもっていないことがわかる 権限がない状態がなぜ起きているかを知る 周囲から(そのスクラムチームが)不安に思われていることが要因となって、権限が無くなってしまっていることが多いので、その不安を潰すようなアプローチをかける 例えばリリースを何度も遅延させてしまっていて、なにかするたびに上席にレビューを求められている状態だとしたら、リリースを間に合わせるようにして信頼を取り戻すとか 組織全体がスクラムを理解した状態であれば、POに権限を持たせることは難しくないはず 組織に対するスクラム支援もスクラムマスターの責務のひとつ。POに権限があるとこういうメリットがあると説明し、共感してもらうことはスクラムマスターの頑張りどころ (組織から)スクラムチームが信頼される・信頼できる状態にあることは大事 畑谷 これという答えは出せない 実際POを立てるときにとったアプローチとして、権限をPOに持ってこられるよう上のほうで話し合ってもらった 開発の上長経由で、POの上長にアプローチしてもらう 上のほうで話し合ってもらうときに、スクラムをする(POに権限を持たせる)メリットの説明をするには、結果が出ていないと難しい スクラムをやっている当人はメリットを実感しやすいが、ステークホルダーだとなかなか実感は難しい面もあるかも(西野) 最初から(ステークホルダーを含めた)全員が完全に納得してスクラムを始めるのは難しいかも(西野) 小浦 まだまだ道の途中という感じがある 自分のチームの場合はPOがマネージャーなので、権限がある状態 あるべき状態としては、POとマネージャーは違う人の方がいいと思う。いずれはそうしたい PBI管理を、POから開発者に移管して運用している ルール上はPOしかPBIを動かせないが、スクラムチームで合意がとれているなら、POの権限を開発者に委譲してもいいと思う(西野) POが「開発者はここまでやっていい」と権限を下ろせていたり、POが多忙であったりするならば、(合意をとったうえで)開発者が動かしてもいいという話も聞いたことがある(西野) POに権限をもたせて、さらにスクラムチームで細かい権限を分担していくかたちもありだと思う(西野) PBIを動かすことそのものはあまり問題がないが、プロダクトの行く末を決めるような力がまだ弱いので、そこへの注力や周囲への説明をがんばりたい(小浦) スクラムやっててよかったエピソード・一番しんどかったエピソード 畑谷 よかった:リリースの期間の短縮 スクラムやる前は「2-3ヵ月かかります」とざっくり見積もっていたことが、1ヶ月でできるようになった 集中して取り組むと無駄なくリリースできることが実感できた しんどかった:優先度決め ひとつのチームで、対象ユーザーは同じだがいろいろなプロダクトを扱っている どちらの優先度がより高いかを、プロダクト同士で比較・判断することが難しい (プロダクトが違う中で優先度を決められる)真のPOは誰だという悩みもある 西野 よかった:チームメンバーのモチベーション向上 スクラム導入後のフィードバックとしてもらった意見 リリース回数が増えたことで、特にエンジニアのモチベーションが向上した 今までは自分しかできなかった仕事がほかの人もできるようになったことで、障害対応のときに絶対に自分がいないといけないという不安が拭え、心理的安全性が確保された しんどかった:スクラムマスターがひとりしかいない 今は社内でスクラムマスター共有会というイベントがあるので相談先があるが、自分がスクラムを始めた頃はスクラムマスターが各チームに点在している状態だった スクラムマスターの振る舞いについて悩んでも相談できる先がなかなか無い スクラムマスターが凹んでいるとチームにも悪影響が出てしまうため、スクラムマスターである自身のモチベーションコントロールが難しい 小浦 よかった:属人化解消 スプリントごとに誰がどんなチケットを消化したかを検査している。特に(属人化解消の)成果が出たスプリントは、全員で喜び合っている 日々の会話のなかで、メンバーから「いつもと違うタスクができて嬉しい」「スクラムやってよかった」というコメントがでてくるとニンマリしてしまう しんどかった:スクラムマスターの役割はどこまでなのかわからない ひとりで気張って、いつの間にかお母さんみたいになってしまって、勝手にしんどくなってしまっている チームのリーダーも兼任しているので、スクラムマスターでもあり、リーダーでもあり、お母さんでもあり……という状況に陥って、凹んでしまう women developers summitでその話を西野さんがするそうなので、楽しみ 参考リンク)登壇内容こちら: スクラムマスターが「チームのお母さん」にならないための方法 #devsumi まとめ 同じ会社のスクラムマスター同士とはいえ、チームが置かれている環境や目指すゴールも異なるスピーカー3名でしたが、スクラムについての悩みや課題・喜びは話し合ってみて非常に共感できるものが多かったです。 似たような課題でも解決のアプローチが違うことも知れたので、お互いのスクラムチームの良いところを吸収して、自分のチームの課題解決に還元していきたいと思います。 現場にどのように権限を持たせていくかはもっと掘りがいがあるテーマだと思ったので、また機会あれば スクラムマスター対談はまたやってみたいと思っているので、スクラムに関する質問などあれば、ぜひTwitterでこの記事を引用して質問をお寄せいただければと思います。(関係者一同、ウォッチしております!) We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
ニフティ株式会社でマネージャーをしている元安です。 今回はマネージャーとして業務する上で気を付けていることについて経験談を交えながら書かせていただこうと思います。気を付けていることはいくつもあるのですがいくつも書くと長くなるので今回はまず1つ。 マネージャーだから意識しなければならないものではなくどのような立場でも気を付けたい内容ですが、私自身はマネージャーになり、より一層意識しています。それでは早速紹介していきます。 何があったか マネージャーやリーダーは様々な関連部門や関係者から相談を受けることが多い立場です。私も社内外の関係者から様々な相談を受けることがありますが、マネージャーになってから暫くはその相談事に対する対応を自分一人で抱えてしまうことが多々ありました。 自分自身で業務を抱えてしまう理由としては 自分でやった方が早い チームメンバーが忙しそうだから更に業務を振るのが申し訳ない といったものがありました。 前者はある業務に対して熟練してきた人にはありがちで、自分が詳しい領域なので他メンバーに説明してやってもらうより自分がやった方が早いという思いから業務を抱えてしまう「あるある」な話です。 後者は人事異動により多忙なチームのマネージャーになった際に芽生えた意識でした。新たに赴任したマネージャー兼チームリーダーとしてチームビルドをする中でチームメンバーには注力プロダクトの開発業務や新たな技術習得などに力を注いでほしいという思いがあり、同時にメンバーは皆多くの案件対応を抱えている状況がありました。そしてメンバーの負荷を上げないために自分が一人で抱える業務が増えていきました。 どうなったか 結果として以下のような問題が発生します。 自身が一人で業務をいくつも抱えているため手が回らず進まない業務がでてくる 関連部門からの依頼案件の内容や温度感がメンバーに正確に伝わらず、チーム全体で課題や現在の状況を認識できない 新たな経験を積むことで得られるチームメンバーの成長機会を奪ってしまう そのような状況で短期的に私が取った手段は依頼された案件対応を回すことを第一に考え「自分が更に頑張る」というものでした。残業して自分の業務時間を増やし業務が滞らないよう対応しました。結果として何とか業務は回り、ある開発プロジェクトでは社内的にはよい結果を残すことができました。 しかし、このやり方で良い結果が出せても上に挙げた問題点はほぼ解決されていませんし、この成果はチームとして出した成果ではありません。そして自分自身もどんどん疲弊してしまい、このやり方は限界を迎えます。 私はマネージャーのミッションの大きなものに 「チームとして」成果を上げること チームメンバーを育成すること があると思っていますが、上記のような状態ではとてもそのミッションは達成できません。 どう変えていったか そこで改めて「自分がやろう」のスタンスをやめチームメンバーに頼る範囲を増やしていきました。動きの活発なプロダクトについてプロダクト毎に取りまとめを行ってもらうメンバーを決め一緒に業務に入ってもらい業務をシェア + 権限移譲しました。一緒に業務に入ってもらう際に意識してお話ししたのは以下の点です。 現在の状況 今自分が抱えている業務の状況 率直に、今大変で困っているから助けてほしい 期待のすり合わせ どんなことをやってほしいか、逆に私にフォローしてほしいところはどんなところか? 権限移譲 + 責任の範囲を明確化 業務の中でどの部分をお任せするか そして一緒に業務に入ってもらい段々とお任せする範囲を増やしていき、最終的にサブチームのリーダーとして動いてもらうようになりました。いざお願いする前は「忙しいけどお願いして大丈夫かな?負荷が上がってしまい大変じゃないかな?」など考えすぎていましたが、結果としてお任せしたメンバーは業務を通じて成長し社内でもより信頼される存在になっていきました(もちろん忙しい中頑張ってくれて大変だったとは思います)し、私が業務を抱えすぎてボトルネックになることもなくなったのでチームの動きのスピード感も増していきました。 まとめ マネージャーの役割はチームの力を最大限に発揮し成果を上げることです。変に遠慮や気遣いをして自分一人で頑張ろうとしても会社、チーム、チームメンバー、自分自身、誰のためにもなりません。 弊社のマネージャーとチームメンバーは上司、部下という関係性でもありますが、大前提として同じチームで働く仲間です。仲間を信頼し互いに助け合って成果を最大化していけるようチームワークを発揮した働き方をしたいですね。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントではニフティグループの社員が業務を通じて学んだことを発信しています! 第7回目のテーマは、自社イベントの開催の仕方 〜 NIFTY Tech Day 2022 制作秘話 〜 と題しまして、 先日開催した、NIFTY Tech Day 2022 を裏から支えたメンバーの苦労話や自社開催で得たノウハウについて語っていただきます。 NIFTY Tech Day 2022 のアーカイブ動画はこちら 動画プレイリスト 概要 日程:12月06日(火)12:00〜13:00 配信方法:YouTube Live 視聴環境:インターネット接続が可能なPC/スマートフォン 参加方法 YouTube Liveにて配信いたします。 connpass にて登録をお願いいたします。 YouTube LiveのURLは決定後、connpass内の参加者への情報欄に記載いたします。 こんな方におすすめ ニフティの自分たちでやろうという風土が気になる方 自社イベント開催に興味がある方 配信について興味がある方 タイムテーブル 時間 コンテンツ 12:05 – 12:10 オープニング+会社紹介 12:10 – 12:15 自己紹介 12:15 – 12:25 NIFTY Tech Day 2022 開催概要 12:25 – 12:35 LT: NIFTY Tech Day とシャイな社員 12:35 – 12:45 LT: 「詳しそう」と映像作成担当に任命されたので、撮影から編集まで内製することにしました 12:45 – 12:55 LT: 技術者交流会を開催するまで 12:55-13:00 クロージング テーマ NIFTY Tech Dayの運営の各セクションのリーダーからLT形式で発表を行います。 LT: NIFTY Tech Day とシャイな社員 初めて技術イベント開催するけど、シャイな社員は登壇に消極的!そんなニフティでのセッション完成までのお話。 LT: 「詳しそう」と映像作成担当に任命されたので、撮影から編集まで内製することにしました IT企業で映像制作未経験のエンジニアが映像を内製するはなし LT: 技術者交流会を開催するまで Tech Day 2022にて開催した技術者交流会を開催するまでの苦労話や、どういう流れでそうなったかなどの紆余曲折を語ります! 登壇者プロフィール 田中 星佳(登壇者) ニフティ株式会社 基幹システムグループ サービスインフラチーム NifMoなどの入会系システムの開発・運用を担当しています。 NIFTY Tech Day 2022では、セッションの選定や登壇者との調整を担当しました。 川端 航平(登壇者) ) ニフティ株式会社 会員システムグループ 第一開発チーム 駆け出しSREです。 NIFTY Tech Day 2022では映像の撮影~編集を行う機材班のリーダーでした。 筑木 信成(登壇者) ニフティ株式会社 会員システムグループ 第二開発チーム 技術イベントの企画やキャリア採用を担当しています。 NIFTY Tech Day 2022では技術者交流会・ニフティ分析などの休憩時間コンテンツを担当しました。 伊達 乾(登壇者) ニフティ株式会社 会員システムグループ 第1開発チーム シニアエンジニア @niftyトップページとニフティポイントクラブの開発運用をしているチームのリーダー。 NIFTY Tech Day 2022では運営の統括をしてました。 多田 圭佑(ファシリテータ) ニフティ株式会社 基幹システムグループ 入会システムチーム ニフティの基幹業務システムの開発・運用を担当しています。 NIFTY Tech Day 2022では社内外の広報活動とサイトやバナーなどクリエイティブ制作の調整を担当していました。 ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています! ニフティエンジニアのTwitterアカウントを作りました NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 Tweets by NIFTYDevelopers アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現(外見の性)、性指向 年齢、障がい、容姿、体格 人種、民族、宗教(無宗教を含む) 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生(性的な画像など) 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章はKotlinFest Code of Conductとして公開された文章( https://github.com/KotlinFest/KotlinFest2018/blob/master/CODE-OF-CONDUCT.md )を元に派生しています。 ※本文章はCreative Commons Zero ライセンス( https://creativecommons.org/publicdomain/zero/1.0/ ) で公開されています。
2022年11月2日に  スクラムマスターが「チームのお母さん」にならないための方法  というタイトルで  women developers summit  に登壇させていただきました。 外部イベントでは初めての登壇だったのですが「わかりやすかった」「スクラムをやっていなくても参考になった」という意見もいただけて、登壇してよかったです。 この記事では、登壇で話した内容と、その補足をしていきたいと思います。 スクラムマスターが「チームのお母さん」にならないための方法 自己紹介 ニフティでスクラムエバンジェリストに任命されている西野香織と申します。 このN1! の中で使える費用で、アドバンスド認定スクラムマスターも取得させてもらっています。 写真で掲げている本「ニフティのスクラム」PDF版が以下から無料DLできます! ニフティのスクラム:ニフティ – 技術書典マーケット 登壇を希望した背景 今回公募枠で登壇させてもらったのですが、この話をしたいとおもったきっかけは、社内スクラムマスターの集まりから出た疑問でした。 社内にスクラムチームが10以上 スクラムを導入していこうという動きが会社全体で高まっており、今年はじめて認定スクラムマスターの資格をとった人も多いです。 月1のスクラムマスターの集まり そういう背景もあって、ニフティでは、去年から月1で「スクラムマスター共有会」という集まりを開催しています。 そのスクラムマスター共有会で「チームの自律をうまく引き出せない」という話をよく聞きます。 特に女性のスクラムマスターから「まるで自分がチームのお母さんのようになってしまう」という声があがりました。男性のスクラムマスターも共感していました。 たしかに自分も一時期「私はお母さんか?」という状態になってしまったことがありました。 セッションの対象層 本セッションの対象者は、気を使いがちなスクラムマスターを想定しています。 スクラムをやっていなくても、先輩だとかリーダーだとかで、何かを教える立場になった人や、チームで開発をした経験がある人なら共感できる点があると思います。 スクラムマスターは責任感が強いタイプが多い スクラムマスターは、チームにひとりしかいない役割ということもあってか、責任感が強いタイプが多いなと感じます。 特に「みんなが困っているから」役割を引き受けがちな人 あとは、「誰かリーダーになって」と言われたときに、自分がすすんでリーダーをやりたい、というよりは、みんなが困っている雰囲気を感じて「じゃあ…」とリーダーになるような、献身的なタイプも多い印象です。 スクラムマスターが抱えがちな悩み ここから帽子を被ったネコがちょくちょくでてきますが、スクラムマスターだと思ってください。 自分がスクラムマスターになりたてのころ、お母さんみたいになっていたという状況です。 開発以外の仕事を一手に引き受けている 自分がスクラムマスターになりたてのころ「スクラムをやっていくぞ!」という気負いと「でもスクラムマスターって具体的になにをやればいいんだろう?」という不安から、開発以外の仕事を全部やる人になってしまいました。 チームのお母さんみたいになってしまっている ここでいう「お母さん」とは 誰がやるか明確でない仕事を率先して引き受ける これから問題になりそうなことを先んじて潰す というような、仕事に集中しやすい環境を整えることをやる人、を指しています。 お母さん的な状態になると、なにか問題があると「ちょっとお母さん……じゃなくてスクラムマスター来て!」と、みんながまずスクラムマスターに頼ってしまう、という状態を引き起こしてしまいました。 このセッションで伝えたいこと そういった経験をふまえて、このセッションでは以下の3点を伝えたいと思います。 「よかれと思って」は危険信号 みんなが働きやすい環境をつくらなきゃという思いから「よかれと思って」いろいろな仕事を引き受けると、どのような悪影響があるか スクラムマスターはなんでも屋さんではない スクラムマスターの仕事は、スクラムを回すこと以外は厳密には定義されていないが、そのせいで開発以外の仕事を全部やる人として立ち回ると、スクラムマスターとしてどうなるか 自分がいなきゃ…という欲望からの脱却 このチームには自分がいなきゃだめだという状況は、ある意味で自己肯定に繋がってしまうことがある。そういう執着を手放すために知るべきこと よかれと思っては危険信号 スクラムマスターになりたての頃の悩み とにかくみんなが仕事をしやすい環境を作らなくては……という気持ちから、いろいろな仕事を抱え込んでしまっていました。 かつて自分が製作や開発をやっていた頃、差し込みや調整で作業が中断されてしまうことにストレスを感じていたため、チームメンバーにはそういうつらさを味わってほしくないという思いもありました。 また、1-2年目の人が多いチームだったので、自分はWEB製作のディレクションをしたことはあるが、チームメンバーにはまだそういった経験がないから、自分がやらないとプロジェクトがうまく回らなくなってしまうかも、という不安もありました。 すべてスクラムチームのために「よかれと思って」やっていたことで、これでチームがより良くなるのだろうと信じていました。 どんどんチームのお母さんになっていく そうした「よかれて思って」をつみかさねていった結果、どんどん自分のお母さん化が進んでいきます。 何でも屋さん化 毎日目の前に雑務が積み重なって、スクラムに関する話をチームにすることもどんどん減っていきました。自分は本当にこれでスクラムマスターをやっているといえるのか?という不安も増えていきます。 仕事へのモチベーションが下がる 「誰がやってもいいけど、誰かがやらなきゃいけない仕事」の多くは、明確なアウトプットがないからか達成感も弱く、仕事へのモチベーションが維持しにくくなりました。 チームはそれがスクラムマスターの仕事だと思ってしまう チームもはじめてスクラムをやっている状態なので、自分がそういうふるまいをすることで、スクラムマスターは開発以外の仕事をする役割なのだと思われていました。 最初から「そういうもの」だと思われていると、チームが仕事しやすい環境になるよう尽くしているつもりでも、あまり評価も感謝もされにくかったです。 お母さんが毎日家事をして家を整えていても、それがあまり家族から感謝されなくて悲しくなる状態ってこういうことか……と思ったりもしました。 スクラムマスターはなんでも屋さん ではない スクラムマスターは、スクラムをうまく回していくこと以外に明確にこれをするということがルールとしてないため、なんでも屋さん的になりがちにですが、それは正しい振る舞いでしょうか。 「名前のない仕事」が属人化した弊害 「透明性」がなくなる 「集中」はスクラム価値基準のひとつですが、みんなが仕事に集中できることに目を向けすぎて、スクラム3柱の「透明性」が失われました。 具体的には、プロダクトオーナーと開発者の間で行われるべき調整を、スクラムマスターとプロダクトオーナーだけに閉じて調整している状態がありました。 体調不良などで2日ほど休んでしまったときに、プロダクトオーナーと自分の間で話していたことが開発者に共有されておらず「このタスクはこの方向性でいいんだっけ」と現場を混乱させてしまうこともありました。 チームの状態を見る余裕がない 「明日までに経費申請をしなきゃ」とか「ユーザーから問い合わせが来てたな」ということをひとりで対応していくと、目の前の仕事にばかり意識がむいてしまい、チームの進捗状況やチームメンバーに問題がおきていないかということにも目を配る機会がどんどん減っていきます。 サーバントリーダーシップ=献身的だけど……? スクラムマスターに求められるものとしてサーバントリーダーシップがあげられます。 献身的なふるまいでチームをサポートすることでリーダーシップを発揮するというもので、自分としてはみんながあんまりやりたくない仕事を引き受けることで、献身的にふるまっているつもりでした。しかし消耗するばかりで、なんだかうまくいっている感じがしません。 このままのやり方を続けて、チームメンバーが自己管理や自律ができた状態になっていくイメージがまったく浮かびません。 どこから間違えてしまったのか、あらためてサーバントリーダーシップのあり方について調べ直してみました。 「献身」の方向性を間違えない 今思えば、献身的にふるまうことと、犠牲的であることを履き違えていたように思います。 チームメンバーに献身するということは、誰かにとって面倒なことを代わりにやるのではなく、チームの、その人の成長に身を捧ぐことです。 スクラムガイドにあるスクラムマスターの項目には「支援」という言葉がたくさんでてきますが、自分がやっていたことは、支援・サポートではなくて、代役や代理でした。 犠牲的なふるまいをやめて、チームの成長にフォーカスすることで、チームの得意なことを伸ばし、苦手なことを克服するサポートをしていく、本来のスクラムマスターという役割に戻れた気がします。 デイリースクラムのファシリテーションを分担 絵にあるように、まずはデイリースクラムのファシリテートからメンバーに分担してみました。 自分がファシリテーターを離れたことで「カンバンに載せられなかった作業が実はあって」という感じで、チームに対して相談をしたかったことが話せるようになり、チームメンバーも自分達で仕事を管理していくという意識を持ちやすくなりました。 成長に対して向き合ってみたことで、人に仕事を任せることは負担になることばかりでなく、学びや成長に繋がると実感を持てるようになってきました。 あまり過干渉になりすぎず見守ろう、ということを自分でも意識的にやるようになりました。 ファシリテーションをローテ制にした社内事例 社内で行っているスクラムマスター共有会でも、自分ばかり頑張ってしまうとか、なかなかチームメンバーの方からアクションを起こしてくれない、といった悩みを聞くことがありました。 そういう状況の改善策として、デイリースクラムのファシリをローテ制にしてみるのはどうかという提案をして、実際にうまくいったケースが多いです。 そのときのスクラムマスター共有会には5チームぶんのスクラムマスターがいたのですが、うち半分以上はデイリースクラムのファシリテートをローテーションする文化が根付いていました。 チームが成長する機会を奪い取らない ここでポイントなのですが、気を遣いがちな人は、仕事を人に任せてみようと言われても、実際行動に移す心のハードルが高いと思います。なので、「自分がやってしまうことで、人が成長する機会を奪っているかもしれない」と思うくらいでちょうどいいです。 他律的な状態 自律の対義語として他律という言葉があります。自分にルールがなく、他人にルールを預けてしまっている状態です。 「スクラムマスターの私がうまくまわさなきゃ!」と気負ってしまうと、チームメンバーに「デイリー集まってください」「リファインメントしたほうがいい」というような、指示をするような話し方、いわゆるティーチングの状態になりがちです。 これが続くと、チームメンバーはこの場合、スクラムマスターという他人にいろいろなルールを任せている状態になってしまいます。 自律的な状態 チームの自律を引き出すためにはどうすればいいでしょうか。 自律は、自分で自分のルールをつくって動けること、自分で自分を管理できている状態をさします。 「こうしてください」とは言わずに、問いかけや傾聴を中心としたコーチングをして、自分でトラブル対処できる力をつけてもらうことが自律を引き出す近道でしょう。 そう考えると、今までチームメンバーがハードルに躓く前に取り除いていたことは、成長を阻んでいたともいえます。 スクラムマスターが本当にやるべき仕事は、ハードルを見つけてもらうこと、そのハードルをどう乗り越えるか考えるきっかけを与えることです。 とはいえ、いままでスクラムマスターがやってしまっていた仕事をチームに任せるのは、ただ仕事が増えるように見えてしまい、イヤがられないか心配ですよね。 そのときは、チームがスクラムをどの程度活用できているか、そして次のフェーズはどうなっていくといいか、という観点が持てるといいので、次の章で話していきます。 スクラム活用までの3フェーズ スクラムが浸透するまでをフェーズにわけてみました。 スクラムを導入期、適用期、活用期の3フェーズにわけたとしたら、この3フェーズのなかで、スクラムマスターはティーチングとコーチングの割合を変えていく必要があります。 導入期 チームがスクラムというルールの把握ができるまでです。 この期間は、スクラムとはこういうものであると指示したり教えたりする、ティーチングの割合が多くなります。ここは多少、面倒見のいいお母さん的な振る舞いでも問題ないと思います。 適用期 スクラムイベントに慣れ出して、スプリントごとにリリースも出せるようになってきた時期です。 適用期は「スクラムをやっている」状態ですが、チームや組織が抱える問題解決のために「スクラムを活用できている」状態になることを目指した方がいい状態です。 適用期〜活用期 この時期は、ティーチングの割合を下げてコーチングの割合を増やしていくといいでしょう。お母さん的な振る舞いをやめて、スクラムにおけるコーチや師匠のような振る舞いに変化していきます。 スクラムを学び始めた頃、スクラムマスターは、スクラムを確立させること以外に明確にこれをやれというルールがないのは困るなと思っていたのですが、スクラムの適用度合いやチームの様子をみて、どう振舞うといいかを常に変えていく必要があるから、厳密な定義がないのだと改めてわかりました。 この適用期から活用期に移行するための取り組みとして、スクラムマスターだけがやっていた仕事をチームに分担していくといいです。 チームメンバーには「スクラムがまわってきたので、より上のフェーズにいく」というような説明をあらかじめしておくと良いでしょう。まずはファシリテーションやスクラムイベントの準備・調整などの仕事から分担して、自分達でスクラムをまわしていくという意識を持ちやすくします。 細かい仕事やチーム内外の調整なども「誰かが(スクラムマスターが)やってくれるだろう」というマインドから「私たちがやっていくためにはどうすればいいか」というマインドに変わっていけるように導く必要があります。 スクラムマスターだけができる仕事を無くしていく スクラムマスターだけができる仕事はルール上ないはずですが、さきほど述べたスクラム導入期〜適応期のスクラムマスターは、自分だけがやりがちな仕事を持っていることが多いと思います。 チームメンバーにスクラムを回すことから任せていく 最初にスクラムチームに任せてみることとして、スクラムイベントのファシリテート、特にデイリースクラムがおすすめという話をしました。 ほか、開発外の誰がやるか決まってない仕事をもしスクラムマスターだけがやっていたなら、少しずつチームに戻していきましょう。フォローはしてもいいですが、それをやる機会をチームから奪ってはいけないと基本的に考えます。 仕事しやすい環境を自分たちで作れるようにすることが、チームの自律に必要なことです。 任せた最初は開発が停滞しうまくいかないこともあるかもしれませんが、それ自体はあまり問題ではありません。私たちスクラムマスターが本当にやるべき仕事は、チームの成長を促すことです。 チームメンバーが不得意な仕事を代わりにやるのは、過干渉なお母さんになってしまいます。 こういった仕事をどうしたらうまくいくようにできるか、自分の経験をもとにコーチしていくことが、本来のスクラムマスターの役割・責任といえます。 スクラムマスターがいる意味なくなっちゃう? こうして徐々にスクラムマスターが実務を手放していくと、最初のうちはコーチングすることも多いのですが、だんだん自分がスクラムをまわすために頑張る必要が減っていきます。 チームの自律を考えると本来は良いことですが、自分はなんのためにこのチームにいるのだろう?という気持ちになってしまうこともあるかもしれません。実際問題として、自分は不安な時期がありました。 自分がいなきゃ…という欲望からの脱却 そういえば新入社員のころに、社内報になりたい将来像をというのを書かされたことを思い出しました。 頼られる人になりたい、唯一無二の人になりたいと書く人がとても多いです。人間だれしも、年代問わず、人に必要とされたいという欲求があると思います。 仕事でもなんでも「あなたがいてよかった」って言われると、うれしいですよね。 ただ「君がいないと困る」までくると、スクラムチームとしてはおそらく健全ではない状態です。 スクラムマスターはなぜ1人なのか 「君がいないと困る」状態は健全とはいえませんが、実際問題として、スクラムマスターは一人しかいません。 やっぱり、スクラムマスターの自分がいないと困るのでは……?となりそうですが、スクラムマスターがいないことと、私個人がいないと困る状態は違います。 スクラムをうまく回すテクニックや観点そのものは、個人に属人化させずに、チームに共有していくべきです。 スクラムマスターがチームに1人しかいない理由は スクラムマスターが誰かに感情や意見をひっぱられない中立的な立場をとるため 開発者にもプロダクトオーナーにも属さないポジションの人がチームにひとりいることで、対立を防ぐ という役割もあると思います。 自分もスクラム導入初期に開発とスクラムマスターを兼任していた時期もありましたが、スクラムマスター専任になって少し離れた視点からチームをみてみると、いままで開発者からの意見ばかり聞いていたかもとか、プロダクトオーナーがスクラムチームからやや浮いている状態かもしれないなど、スクラムとして不健全な状態が見えやすくなります。 スクラムマスターはいないと困るかもしれませんが、スクラムマスターをやっているその個人がいないと困る状態にする必要はありません。 スクラムマスターが、スクラムを支援する範囲 でも、スクラムマスターが、自分のチームのスクラムをまわすために頑張る必要が減ってきたということは、本当にスクラムマスターとしての仕事が減ってきたこととイコールでしょうか。 ここでスクラムマスターはそもそもどんな役割だったか、スクラムガイドを読み返してみましょう。 スクラムマスターがスクラムを支援する範囲ですが、スクラムマスターは、プロダクトオーナー、開発者といったスクラムチームに対してのみ、スクラムの支援をするわけではありませんでした。 スクラムガイドには スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである スクラムガイド – ScrumGuide と書かれています。 スクラムチームが健全にスクラムを回せるようになってきたとしても、組織単位だとどうでしょうか。 スクラムが組織に十分に浸透しているといえる状態になるまで、私たちスクラムマスターの仕事は終わりません。 スクラムマスターとはなにか 最後に、スクラムマスターとは一体なんなのか、その目指すところを考えてみます。 直訳すると、スクラムの先生や、師匠という意味が一番近いように思います。 スクラムマスターは、スクラムの理解と教え方を極めるポジションです。 そのため、スクラムマスターがやっていたファシリテーションや、スクラムのノウハウをどれだけチームに伝授したとしても、組織にスクラムをひろめる仕事があります。 なので、今の自分がスクラムについてわかっていることをチームメンバーに伝えても「自分はスクラムをマスターした」さらに「組織全員がスクラムをマスターした」といえるようになるまでは、スクラムについて学ぶことはまだまだあります。 さらに、自分のチームが世界一のチーム、自分の組織が世界一の組織になるまでは、私たちスクラムマスターの仕事は終わりません。 まとめ 「よかれと思って」の先回りは危険信号です 信じて・任せて・フォロー/コーチすることが本当のスクラムマスターの仕事ではないでしょうか。 スクラムマスターはなんでも屋さんではありません スクラムマスターは、スクラムの浸透フェーズに合わせて振る舞いを変えていきます。 何かを任せないという判断は、他者の成長の機会を奪っているのと同じことです。 自分がいなきゃ…という欲望から脱却しましょう 先生、師匠として一歩下がって、チームの成長を見守りましょう。 チームの成長の次は、組織におけるスクラムの成長をサポートしていく仕事もあります。   ニフティ有志によるスクラム本無料配布中! 自己紹介のときに軽く触れましたが、スクラムがうまく行った話、うまくいかなかったけど頑張った話、さまざまなニフティのスクラム話が載っています。 無料ですので技術書典のサイトからDLしてみてください。 ニフティのスクラム:ニフティ – 技術書典マーケット   We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
はじめに こんにちは。入会システムチーム高畑と申します。 ニフティでは打ち合わせ等にGoogle Meetを使用しています。Google Meetで打ち合わせ開始時に誰がいて誰がいないのか、全員参加しているかを確認する時間が発生してしまうため、今回は予め作成したリストからMeet画面に出席していない人を表示するChrome拡張機能を作成しました。 Google Meetでは 出席機能 が提供されておりGoogleカレンダーの参加者情報を元に出席状況を確認できます。しかし、Googleカレンダーに紐付いていなかったり、複数の会議でURLを使いまわしたりしている場合には、Googleカレンダーの参加者リストとは別管理で誰がいないかを確認したい場合があるため拡張機能の作成に至りました。 拡張機能開発概要 Chrome拡張機能はHTML/CSS/Javascriptの知識があれば簡単に作成することができます。 ディレクトリにmanifest.jsonという名前の拡張機能の設定ファイルとHTML/CSS/JavaScript、画像等を配置し、zipにまとめれば完成です。manifest.jsonは以下のように拡張機能の名前や画面右上のアイコンクリック時にポップアップ表示するHTMLファイル名、アイコン画像のファイル名等を指定します。 ポップアップ以外にも設定次第で今タブで開いているページにJavaScriptを追加し内容を書き換えたり、バックグラウンドでJavaScriptを実行したりできるため、翻訳やブックマーク等さまざまな用途に活用できます。 { "manifest_version": 3, "name": "名前", "version": "0.0.1", "description": "誰が居ないかを通知する拡張機能。", "action": { "default_popup": "ポップアップとして表示したいHTMLファイル名" }, "icons": { "128": "アイコンファイル名" }, } この拡張機能でできること この拡張機能ではMeetの参加者から予め作成したメンバーリストに存在しない参加者をリスト表示します。 Meetを開いている際に拡張機能のアイコンをクリックしメンバーリストを入力します。 その後、「不在確認」ボタンをクリックすることで、MeetのHTMLをパースして得た出席者のリストと入力したメンバーリストを照合し、出席していない人のリストを表示します。 メンバーリストはMeetのURL毎にローカルストレージに管理しているため、別のMeetのURLでは別のメンバーリストを持たせることができます。 オプション画面からMeetのURLごとの設定状況を確認できます。不要な設定はこのページで削除することができます。 拡張機能を使いたい Chrome拡張機能として配布していませんが、ソースコードを配布していますのでデベロッパーモードとして導入することができます。導入方法の詳細は以下URLを参照ください。 https://github.com/octop162/dareinai 実現方法 拡張機能の紹介は以上ですが、ここからは実装方法のデータ受け渡し部分について説明します。データの受け渡し部分以外はHTML/CSS/JavaScriptでの開発のため通常のWebページと大差ありません。 Chrome拡張機能には3通りのJavaScriptを当てることができます。 default_popup :Chrome右上アイコンから表示される小さい画面に当てるJavaScript content_scripts :タブで開いているページのHTMLに当てるJavaScript background :開いているページとは別にバックグラウンドで動作するJavaScript 今回は画面右上に表示する小さい画面にタブのMeet画面で表示している内容をもとにしたリストを表示したいため、default_popupとcontent_scriptsの間でデータのやり取りをする必要があります。default_popupの画面からMeetのDOMを直接参照することはできません。 default_popupとcontent_scriptsの間でデータのやり取りをするためにはchrome.tabs.sendMessageを使用することができます( 参考 )。ここではボタンクリック時に{ action: “GET_MEMBERS” }を付加してメッセージを送信しています、結果は非同期で指定した関数(ここではshowAbsentees関数)にコールバックされます。 // popup.js // 不在確認クリック時にmeetのDOMから現参加者を取得する $("#confirm").on("click", function () { chrome.tabs.query({ active: true, currentWindow: true }, (tabs) => { chrome.tabs.sendMessage(tabs[0].id, { action: "GET_MEMBERS" }, showAbsentees); }); }); 送信されたメッセージはchrome.runtime.onMessage.addListenerで受け取ることができます。受け取った{ action: “GET_MEMBERS” }を元にして処理内容を判別し、sendResponseに返したいオブジェクトを入れると元のJavaScriptにコールバックされます。 // content.js /** * ポップアップからメッセージを受け取り、メンバーリストを配列として返す * HTML構造が変化した場合ここのセレクタを修正する */ chrome.runtime.onMessage.addListener(function (message, sender, sendResponse) { if (message.action === "GET_MEMBERS") { switch (message.action) { case "GET_MEMBERS": let members = document.querySelectorAll( "div[role='list'] > div[role='listitem'] > div > div > div > span:first-child" ); sendResponse(Object.values(members).map((member) => member.textContent)); return true; } } }); これで現在の参加者を配列として受けとれますので、あとは元のJavaScriptで照合すれば今回実現したかった不在者のリストを作成することができました。 感想と展望 Chrome拡張機能はデータの受け渡し部分以外は通常のHTML/CSS/JavaScriptの範囲で実装できるためそこまで大変でなく、日々のちょっとした不満の解決策としてとても便利に感じました。 今回はjQueryでサクっと作成してしまいましたが、HTMLの生成部分等が読みづらい箇所があるため、React.jsで書き直したいです。また、機能拡張としては欠席者が表示されるだけで本日お休みなのかたまたま不在なのか判別できないため状況確認できるようになると尚良くなると思いました。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントではニフティグループの社員が業務を通じて学んだことを発信しています! 第6回目のテーマは「ニフティのスクラム」執筆者が語る! 〜スクラムぶっちゃけ話〜。現在、ニフティでは9人の認定スクラムマスターが在籍しており、多数のチームでスクラムを実践しています。 今回は、先日行われた技術書典13にて頒布した「ニフティのスクラム」について、執筆者によるLTと対談を頒布までの裏話を交えながら語ります。 「ニフティのスクラム」は↓から無料でダウンロードできます。   https://techbookfest.org/product/i99SVfgSGa1uSTwcez6H4Y?productVariantID=e3ivMhH8PXCWbtj3VdpiEi 概要 日程:10月27日(木)12:00〜13:00 配信方法:YouTube Live 視聴環境:インターネット接続が可能なPC/スマートフォン 参加方法 YouTube Liveにて配信いたします。 connpass にて登録をお願いいたします。YouTube LiveのURLは決定後、connpass内の参加者への情報欄に記載いたします。 こんな方におすすめ スクラムに興味がある方、携わっている方 悩めるスクラムマスター 他社のぶっちゃけ話が知りたい方 ニフティの開発スタイルに興味がある方 タイムテーブル 時間 コンテンツ 12:05-12:10 オープニング+会社紹介 12:10-12:15 登壇者紹介 12:15-12:30 LTx3 12:30-12:55 【対談】スクラム一問一答 12:55-13:00 クロージング テーマ 【対談】スクラム一問一答 ではこんな話をします。 システムを熟知している人の負担が大きくなりがちだけどどうしてる? よかったレトロスペクティブある? 今のプロダクトオーナーにどうやって権限を持たせることができましたか? スクラムやっててよかったエピソード・スクラムやってて一番しんどかったエピソード 登壇者プロフィール 西野 香織(登壇者) ニフティ株式会社 会員システムグループ 第2開発チーム ニフティのスペシャリストを任命するN1!制度にて、スクラムエヴァンジェリストを担当しています。 2019年〜スクラムマスターとして、ニフティへのスクラム導入を開始。 8チーム、エンジニア約30名以上に対しスクラム導入を支援しています。 アドバンスド認定スクラムマスター(A-CSM)資格所持。 技術書典では「ニフティのスクラム」の編集・レイアウトと一部執筆をしました。 畑谷 啓志(登壇者) ニフティ株式会社 会員システムグループ 第2開発チーム ニフティのオプションサービス全般の開発リーダー、スクラムマスター兼任。スクラムチームの立ち上げから解散までの経験を持つ。認定スクラムマスター保持者。 小浦 由佳(登壇者) ニフティ株式会社 インフラシステムグループ 社内情報システムチーム ニフティの情シス担当者です。主にプラットフォーム、アプリケーションの社内システムを担当するチームのサブリーダー兼スクラムマスターで、技術書典では情シスのスクラムについて書きました。昨年末に認定スクラムマスターを取得しています。NIFTY Tech Talk、NIFTY Tech Dayを始め、社内外のイベントを企画したりもしているニフティのにぎやかしです。 高田 渉(ファシリテータ) ニフティ株式会社 基幹システムグループ 入会システムチーム ニフティの基幹業務システムのサブリーダー兼スクラムマスターを担当しています。 2021年12月に認定スクラムマスター資格を取得しました。 技術書典では、「ビジネス部門との二人三脚」のテーマを執筆。 ニフティグループでは一緒に働く仲間を募集中です 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています! ニフティエンジニアのTwitterアカウントを作りました NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 Tweets by NIFTYDevelopers 「NIFTY Tech Day 2022」を開催します! 技術イベント「NIFTY Tech Day 2022」を11月22日(火)に開催します。 本イベントに事前参加登録いただき、事後アンケートに回答いただいた方の中から抽選で100名様に当社ポイントサービス「ニフティポイントクラブ」のポイント3,000ポイントをプレゼントします。 NIFTY Tech Day 2022 アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現(外見の性)、性指向 年齢、障がい、容姿、体格 人種、民族、宗教(無宗教を含む) 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生(性的な画像など) 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章はKotlinFest Code of Conductとして公開された文章( https://github.com/KotlinFest/KotlinFest2018/blob/master/CODE-OF-CONDUCT.md )を元に派生しています。 ※本文章はCreative Commons Zero ライセンス( https://creativecommons.org/publicdomain/zero/1.0/ ) で公開されています。
概要 サービス開始から35年、ニフティは常に技術者やIT技術と共にありました。 高い好奇心で新しい技術トレンドをいち早く導入し、システムやサービスへの活用を常に模索しています。ニフティが創業時から変わらないのは、好奇心と挑戦し続けること。 この”NIFTY Tech Day”を通じて、私たちの今と未来をお伝えします。 詳細 公式サイト 日程 11月22日(火)13:00〜18:00 配信URL 準備次第掲載いたします 視聴環境 インターネット接続が可能なPC/スマートフォン 参加方法 connpass にて参加登録を受け付けています。 またイベント参加登録時にぜひTwitter投稿をお願いします! タイムテーブル 時間 セッション 13:00-13:20 キーノート 13:20-13:45 ゲストセッション 13:45-14:10 スクラムのハードルの越え方〜リリース数を1.5倍にするまで〜 14:10-14:35 複数プロダクトを抱えて行うスクラム開発のこれまでとこれから 14:40-15:05 クリーンアーキテクチャはこの3年間で私たちのチームに何をもたらしたのか 15:05-15:30 なぜニフティはLeSSを選んだのか。 @nifty MAX光における大規模スクラム開発体験談 15:35-16:00 若手エンジニアによるリモートワーク支援ツールの開発 ①AWS/GCPとSlackを駆使したオフィスの固定電話廃止への取り組み ②オンライン会議を盛り上げる!音声リアクションツール「もじこえ」の開発 16:00-16:25 安心・安全な@niftyメールサービスの裏側 16:30-16:55 セシール事業におけるモノリシックアーキテクチャとの向き合い方 16:55-17:20 CI/CDを導入して変わったモバイルアプリ開発体制 17:20-17:45 深層自然言語処理によるニュース記事要約の手法と実装 17:45-18:00 クロージング アンケート&懇親会ご案内 各セッションの詳細につきましては公式サイトをご覧ください。 ニフティグループでは一緒に働く仲間を募集中です ニフティ株式会社 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています! ニフティライフスタイル株式会社 想像以上を、みつけよう。 をコーポレートメッセージに、“一人ひとり”のライフスタイルを便利で豊かにするため、ニフティライフスタイルのエンジニアは日々開発をしています。 採用情報 や ニフティライフスタイル Tech Blog をご覧ください。 ニフティエンジニアのTwitterアカウントを作りました NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 https://twitter.com/NIFTYDevelopers
はじめに はじめまして。ニフティ株式会社の森田です。前に社内の1dayハッカソンに参加して、WebSocketを利用して用意した音声を同時共有する簡易アプリを作りました。AWSの勉強も兼ねて色々なサイトやサンプルを参考にして、改めて似たような簡易アプリを個人的に作ってみたのでその紹介をしたいと思います。 WebSocketとはクライアント・サーバ間で対話的な通信ができる技術です。HTTPを使ってソケット通信ができるイメージです。スマート家電とかでも使われていると聞きます。今回は、WebSocketを使ってコネクション接続中の全てのクライアントに画像(正確には画像保存先のS3 URL)を共有するアプリをAWSで作成してみました。 構成 AWS構成図はこんな感じです。 AWS API Gateway API GatewayではWebSocket APIも作成できるため、サーバレスでの双方向通信が割と簡単に実現できます。REST APIではパスやメソッドごとにリソースを用意して、それにLambdaなどのサービスを統合します。WebSocket APIでは、接続時 ($connect) や切断時 ($disconnect) などのリソース(ルート)が最初から用意されています。最初から用意されているもの以外は別にルートを作成して、ルート選択式でそのルートに向けれらるようにします。それら各ルートに対してLambdaなどのサービスを統合するという基本的な流れは同じです。 API Gateway での WebSocket API について https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-websocket-api-overview.html AWS Lambda WebSocket接続、切断、など色々なタイミングで、Lambdaに書かれたコードで実際に処理されます。そうするために関数ごとにAPI Gatewayとの統合が必要となります。WebSocket APIで言うと、$connectルートに統合したLambda関数は接続時に動作します。このようにルートごとにLambda関数と統合させます。 AWS DynamoDB API GatewayでWebSocketのサポートをしてくれるとはいえ、コネクションIDの管理は別でやらないといけません。今回はDynamoDBで1つテーブルを作成して、接続してきたコネクションのIDを雑に保存します。接続時にはIDをINSERTして、切断時にはIDを物理削除します。テーブルにIDがあればコネクションが接続中と判断します。 AWS S3 画像の保存用。今回、クライアント側で画像表示をするため、オブジェクトのURLをWebSocketでやり取りするようにします。S3で用意したバケットのバケットポリシーを変更して、外部からアクセスできるようにする必要もあります。今回は以下の3つの画像を用意しました。「いらすとや」の画像を使わせていただいています。 詳細 実際のデプロイについては最後にまとめています。Lambdaの処理内容の説明では、WebSocketを利用した時の処理の雰囲気が伝われば良いなと思います。 Lambda 接続時(onconnect) 処理内容 接続してきたコネクションのコネクションIDをDynamoDBに保存しています。Lambda関数のコードは以下です。 import os import logging import boto3 logger = logging.getLogger() logger.setLevel(logging.INFO) CONNECTION_TABLE = os.environ['CONNECTION_TABLE'] def lambda_handler(event, context): dynamodb = boto3.resource('dynamodb') connection_table = dynamodb.Table(CONNECTION_TABLE) connection_id = event.get('requestContext', {}).get('connectionId') try: # コネクションIDをDynamoDBに保存する connection_table.put_item(Item={'connectionId': connection_id}) logger.info(f'connected id: {connection_id}') except Exception as e: logger.error(e) return {'statusCode': 500, 'body': f'Failed to connect: {e}'} return {'statusCode': 200, 'body': 'Connected.'} Lambda 切断時(disconnect) 処理内容 切断したコネクションのコネクションIDをDynamoDBから物理削除します。Lambda関数のコードは以下です。 import os import logging import boto3 logger = logging.getLogger() logger.setLevel(logging.INFO) CONNECTION_TABLE = os.environ['CONNECTION_TABLE'] def lambda_handler(event, context): dynamodb = boto3.resource('dynamodb') connection_table = dynamodb.Table(CONNECTION_TABLE) connection_id = event.get('requestContext', {}).get('connectionId') try: # コネクションIDをDynamoDBから削除する connection_table.delete_item(Key={'connectionId': connection_id}) logger.info(f'disconnect id: {connection_id}') except Exception as e: logger.error(e) return {'statusCode': 500, 'body': f'Failed to disconnect: {e}'} return {'statusCode': 200, 'body': 'Disconnected.'} Lambda 画像共有(sendimage) 処理内容 11行目の IMAGE_S3_BUCKET_NAME には画像保存用に 作成したバケット名 を記述してください。 クライアントからリクエスト時に送られた選択画像名(selectedImage)から画像を保存しているS3 URLを構成して、コネクション接続中のクライアント(DynamoDBに保存されてる全てのコネクションID)にそのURLを送る処理をします。Lambda関数のコードは以下です。 import json import os import logging import boto3 logger = logging.getLogger() logger.setLevel(logging.INFO) CONNECTION_TABLE = os.environ['CONNECTION_TABLE'] IMAGE_S3_BUCKET_NAME = '' S3_ENDPOINT_URL = f'https://{IMAGE_S3_BUCKET_NAME}.s3.ap-northeast-1.amazonaws.com' def lambda_handler(event, context): dynamodb = boto3.resource('dynamodb') connection_table = dynamodb.Table(CONNECTION_TABLE) DOMAIN_NAME = event['requestContext']['domainName'] STAGE = event['requestContext']['stage'] WEBSOCKET_ENDPOINT_URL = f'https://{DOMAIN_NAME}/{STAGE}' try: # DynamoDBに存在するコネクションIDを全て取得 items = connection_table.scan(ProjectionExpression='connectionId').get('Items') except Exception as e: logger.error(e) selected_image = json.loads(event.get('body', '{}')).get('selectedImage') apigw_management = boto3.client('apigatewaymanagementapi', endpoint_url=WEBSOCKET_ENDPOINT_URL) for item in items: try: # 画像保存先のS3 URLを構成して、コネクションごとにデータとしてそのURLを送る image_s3 = f'{S3_ENDPOINT_URL}/{selected_image}.png' apigw_management.post_to_connection(ConnectionId=item['connectionId'], Data=image_s3) logger.info(f'ConnectionID: {item["connectionId"]}, image: {image_s3}') except Exception as e: logger.error(e) return {'statusCode': 500, 'body': e} return {'statusCode': 200, 'body': 'Data sent.'} デプロイ(AWS SAM) 先ほどの構成図のS3以外はAWS SAMで構築できるように準備しています。template.yamlは AWS公式のサンプル を参考にしています。画像保存用のS3は別で作成しておきます。lambda_function.pyは上で説明したLambdaの処理をそれぞれ記述して下さい。以下のディレクトリ構成でsam deployを実行すればデプロイされます。 コマンド sam deploy --template ./template.yaml --s3-bucket (sam用s3バケット名) --stack-name (CFnスタック名) ディレクトリ構成 / ├── src/ │ │ │ ├──── onconnect/ │ │ │ │ │ └─── lambda_function.py │ │ │ ├──── disconnect/ │ │ │ │ │ └─── lambda_function.py │ │ │ └──── sendimage/ │ │ │ └─── lambda_function.py │ └── template.yaml template.yaml のソースコード https://github.com/mrtmyix/image-change-websocket-test/blob/main/template.yaml クライアント 以下のような簡易な画像表示のHTMLを用意しました。ラジオボタンで選択して送信すると、選択した値を$sendimageに送ります。すると画像は選択したものに表示が変わって、同じく接続中セッションでも同じ画像が表示されるはずです。 HTMLファイルは以下です。 WebSocket URL をSAMデプロイして割り当てられたURLに 変更が必要 です。 クライアント側のHTMLソースコード https://github.com/mrtmyix/image-change-websocket-test/blob/main/index.html WebSocket URLはAPI Gatewayのコントロールパネルから確認ができます。 onopen()は接続が開かれた時に発火するメソッドで、画面上の文字列「未接続」を「接続中」に変更します。onmessage()は先ほど説明した、$sendimageのLambdaでS3 URLが送られてきた時に発火するメソッドで、現在の表示画像を送られてきたS3 URLの画像に変更します。 動作確認 上で説明したクライアントのHTMLファイルをローカルにダウンロードして、ブラウザで開けば動作を確認することができます。Webサーバなどに配置する必要がないため非常に楽です。 以下は4つのウィンドウで動作させた時の動画です。 おわりに 簡単なモノでも作ってみると勉強になりますね。WebSocketを使えばもっと色々な事ができそうだなと思いました。より深く仕組みを知りたければ、AWS公式サイトだったり、多くの方がブログ等で解説しているので見てみてください。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
はじめに 会員システムグループ SREチームの浅見( @rubihiko )です。 ニフティでは、全社的にサービスの品質向上に関わる取り組みを行っています。 トラブルに対して適切で素早い対処を行う訓練の一環として、アマゾンウェブサービスジャパン合同会社様(以下AWS様)協力のもと AWS GameDay を社内開催しました。 今回、私はニフティでは初となる社内開催に向けて調整をしたので、裏方としての観点でレポートしたいと思います。 以前参加した、通常の参加レポート記事はこちらです。 オンラインのAWS GameDayにニフティグループで参加してみました AWS GameDay とは AWS re:Invent などで開催される、実践的トレーニングで、システムを構築し安定稼働させることが目的となります。 スコア形式でランキングがあります。降りかかる課題や、障害に対してチームでいかに対応するか、本番さながらの対応力が求められます。 本来はグローバルなイベントで参加するものですが、今回はプライベート版ということで、ニフティグループ内での開催となりました。 ※ AWS GameDay 開催の経緯 最近の社内トレンドとして、サービスの品質維持・向上があります。 問題が起きた際の素早い復旧と関係者への連携など、対応力向上が求められていました。 また、ニフティではAWSを導入してから4年ほどが経ち、多くのサービスがAWS上で稼働している状態ですが、このトレーニング経験してもらい、AWSへの理解をより深めてほしいという思いもありました。 そんな中、AWS様に協力いただき、この両方を強化できるイベントの開催へと至ったというわけです。 調整 流れはこのような感じです。 何度かAWS様と詳細を詰める打ち合わせをさせて頂き、社内調整を進めていきました。 開催概要について資料の作成 各部署のマネージャーへの説明 開催日・参加者のスケジュール設定 参加者への概要説明・チーム分け ツール準備・設定 賞品の調整 当日運営 振り返り会 参加者集め 今回、ニフティのエンジニア全員に基本参加してほしかったので、 オプトアウト方式 を採用しました。 3ヶ月ほど前から予定を抑えて、無理な方は欠席していただく方針にしました。 参加実績ですが、125名ほどのメンバーに参加いただきました。(ニフティ、ニフティライフスタイルより) 100名超えのメンバーに集まってもらい感謝! この規模はプライベート開催の AWS GameDayではなかなか無いみたいです。 特別ルール チーム編成について、社内開催のため、グローバルとは異なるルールを一部採用していました。 既に過去のAWS GameDayに参加したメンバーもいたため、本来は1チーム最大4名となるのですが、 未経験者4名+経験者1名の5人でチーム を組んで行いました。 経験者には、 ネタバレ・手を動かすことを禁止 し、あくまでオブザーバ、チームリーダーのような役割で動いてもらいました。 事前の勉強会 AWS GameDayでは開催前にAWS様からAWSサービスについての勉強会を開いていただける場合もありますが、今回は事前勉強会は行いませんでした。 参加者からの要望はありましたが、定期的にAWS様より勉強会を開催していただいたり、 社内でもAWS勉強会をしていたため、各自で基本的なサービスの復習をしてもらうようお願いする程度にしていました。 ツールについて 社内開催をする場合、主催者(つまりニフティ)がツールを用意する必要があります。 AWS GameDayの環境はAWS様が用意していただけるため主催者が用意する必要はありません。 主催者側で用意する必須ツールは2つで、チャットツールと、ビデオツールです。 どちらも、AWS様からのサポート部隊のメンバーを招待できる必要があります。(当日サポート頂きありがとうございました。) 今回、 チャットツールは Slack ビデオツールは Google Meet を採用しました。 Gather を使おうかという話も出ましたが、業務で利用しているわけではないので、普段から使っているツールを使い、AWS GameDayそのものに集中してもらうため、この様になりました。 その他チーム内で使うツールについては制限は特にしていませんでした。ホワイトボードを使ったり、Notionを使ったりは自由です。 賞品について 上位者にはなんとAWS様から賞品がでました!ありがとうございます!! また、社内開催ということ、ニフティからも副賞で ニフティポイント をプレゼントしました。 ※ ニフティポイント 当日の様子 ワイワイしていました。 今回開催した、プライベートのAWS GameDayは場合によっては一定の参加人数が求められており、それを満たせるか不安な部分がありました。 しかしながら、ニフティ、ニフティライフスタイルから沢山のメンバーが集まり、無事開催できてホッとしています。 結果発表の様子 振り返り会&アンケート 終了後アンケートと振り返り会を実施しました。 振り返りは非常に重要です。自分たちが解決できなかった部分の復習にもなりますし、新たなアイデアをインプットできる場でもあります。 人数が多かったので、以下のように行いました。 各チーム単位で振り返り・資料をまとめる(事前準備) 全チーム集まりグループに分かれて発表を行う(振り返り会当日) 全員の発表資料はNotionにまとめておく 振り返り会当日は1時間しか取れなかったので、かなり慌ただしくなってしまいましたが、各チームとも色々と学びを多く語ってくれて良き振り返り会となりました。 振り返り会はネタバレありのため、当日参加していないメンバーは参加できません。そこが辛いところではありますが、しかたありません。 社内向けアンケートについても一部共有したいと思います。 総合的な満足度 AWSの知識が深まったか AWSをもっと学びたいと思ったか 障害対応などのトラブル時に役立つ内容だったか 課題だと気が付きがあったか 概ね良い感じで、今回の経験を業務に活かすきっかけとなるアイデアを掴んだ人も多くいた印象です。 また、AWSをより深く学びたいと思う人も多くいました、社内勉強会の需要も高まっているような気がします。 感謝 運営として関わってくれたメンバーに感謝します。今後も社内勉強会やイベント盛り上げていきましょう! 参加していただいた皆様もありがとうございました。この経験を業務で活かしてもらえれば最高です! そして、AWS様には改めて感謝いたします。このような素晴らしいイベントを提供いただきありがとうございました。環境の準備や調整、当日のサポートなどお世話になりました。 最後に 多くの人に参加してもらえるイベントを開催できてよかったのと、無事終わってよかったと思っています。 このような経験がエンジニアとしてレベルアップに繋がると思っています。 今後も社内イベントは開催していきたいと思っているので、よい経験を積むことができました。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
はじめまして。 ニフティ株式会社の出口です。 今回は、私が所属している業務支援チームで行ったちょっとした工夫についてご紹介します。 自己紹介 まずは私の自己紹介です。 入社後、インフラ運用を、長く担当してきました。 入社当時は、小型冷蔵庫の様なサーバでしたが、徐々に小型化され、仮想化環境の導入、クラウド移行、マルチクラウド化と様々な経験をさせてもらいました。 今は、24時間365日、運用監視(サービス、システムの正常性確認)、システム業務支援 (オペレーション代行)を担っているチームでサブチームリーダーをさせてもらっています。 背景 依頼元から提示されたドキュメントの記載内容に沿って作業することが多いため、特定の分野において専門的な知識がなくても、業務を遂行する上で問題がない様になっていますが、 日々の作業で気づいた点はチーム内で共有し、効率化を図っています。 例えば、メッセージ検知後に依頼元へメール報告する際、メール本文のフォーマットを用意していましたが、メッセージが出力されたサービス・システムによって、メール報告先が多岐に渡ります。 このメッセージのメール送信先は?と確認している間に時間が過ぎてしまい、メッセージ出力からメール報告までに時間が掛かりすぎと依頼元から指摘されることもあります。 GASを利用したメール送信 メッセージ出力した際のメール送信先は、依頼元から指定されているので、メール本文とセットになっていれば迷うことなく、短時間で送信できるのにといったチームメンバの何気ない一言がきっかけです。 Google Formsはアンケートなどに利用する場合が多いですが、GASを利用して複数メールアドレスを送信先に指定できることは分かっていたので、試みることにしました。 1.送信メールのテンプレートを決めます。 2.Google Formsでフォームを作成します。 3.スクリプトエディタのコードに記入していきます。 ※「メッセージ出力システム・サービス」選択肢毎にメール送信先を指定します 4.スクリプトエディタのトリガーを設定します。 5.動作確認を実施して、問題なければリリースになります。 さいごに 社内でGASを利用した事例や、ネット公開されているブログを参考にさせてもらいました。 昔と違い、今は欲しい情報が直ぐに入手できますので、困ったことや実施してみたいことがあれば、参考にさせてもらっており、便利な世の中になったとつくづく感じています。 自発的に行った課題解決策に対して、依頼元やチームメンバから前向きな反応があればモチベーションも維持され、更なる要望にも応えたいと次の一手を模索しているところです。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
はじめに こんにちは!新卒入社4年目の小松です。主にお客様が初めて@niftyをご利用になる際の無料ID会員登録システム、いろいろなサービスをご利用になる際のログインシステムの開発・運用を担当しています。 今回はリモート会議のリアクションわかりづらい問題を解消するツール「もじこえ」を作ってみたので、紹介したいと思います。社内でも一部の会議では実際に使われています。 リモート会議はリアクションがわかりづらい 対面での会議と違って、参加者のリアクションがわかりづらいと感じたときはありませんか。 カメラ・マイクがオフの時はもちろん、うなずきや笑い声など些細なリアクションがわかりづらく、伝わっているのか不安になることがあります。 また実際にはワイワイとしている会議も、コメントを拾い忘れたり、盛り上がりに欠けるなと感じたこともあります。 そこで「もじこえ」を作りました。 もじこえ AI音声でコメント読み上げてくれる匿名チャットツールWebアプリです。 使い方は、リモート会議時に参加者が「もじこえ」をブラウザで開いてチャットします。 読み上げ音声は現在3種類で、コメント投稿ごとに切り替えできます。 実際に使ってみないと伝わりづらいかと思いますが、画面はこんな感じです。 まだデザインを考え中なので、プロトタイプになっています。 ちなみに名前の由来は、 GoogleMeet拡張機能の「こえもじ」 というものがありまして、Meetで話した内容を文字起こしして、コメント欄に追加してくれるものです。 その逆(テキスト→音声)もあればと思ったのが始まりでした。 試しに社内に公開してみましたが、意外と反応があり、社内のLT大会や勉強会などでも使われています。ちなみに私が所属する サービスインフラチーム では、毎日使っています。 もじこえ の中身 構成 バックエンドはNode.js + Expressで、Socket.IOを使ってリアルタイムチャットできるようにしています。音声変換はAWS SDKのPollyを使っています。 フロントは生HTMLとJQueryです。デザインはあとまわしにしているので、のちのちReactなどで作り直したいと思っています。 これらをAWSのFargateで動かしています。 後ほど紹介するSlack連携では、Slack Appを作成し、 Lambdaも使用しています。 読み上げ音声はAWSのAmazon Pollyを使用 Amazon Polly はテキストを音声に変換してくれるAWSのサービスです。様々な言語に対応し、日本語にも対応しています。 料金は、100万文字ごとに4ドルなので、そこまで気にせず使えるかなと思っています。今までで最高でも3ドル未満でした。 もじこえ には、3種類の音声を採用 日本語が話せる3種類の音声を採用しました。結構リアルです。 一番人気はマシューです。 ミズキ(女性) タクミ(男性) マシュー(外国籍で日本語も話せる男性) マシューの音声サンプル ソース紹介 まだリポジトリを公開できる状態ではないため、一部を紹介していきます。 テキスト→音声変換 部分 Node.js + Expressのサーバ側で、AWS SDKでPollyを使用します。 import AWS from "aws-sdk"; // この形式のファイルを作って、各自の値で埋める。 // { "accessKeyId": "", "secretAccessKey": "", "region": "" } AWS.config.loadFromPath('config.json'); const textToSpeakUrl = async (text, voiceId) =>{ // 決めた文字数以降は「省略」に変換 text = omitLongText(text); // URLは「URL省略」に変換 text = replacementUrl(text); // Create the JSON parameters for getSynthesizeSpeechUrl const speechParams = { OutputFormat: "mp3", SampleRate: "16000", // 読ませるテキスト Text: text, TextType: "text", // "Mizuki"などが入る。 VoiceId: voiceId }; let speakUrl; // Polly準備 const polly = new AWS.Polly({apiVersion: '2016-06-10'}); const signer = new AWS.Polly.Presigner(speechParams, polly); // 音声URLに変換 signer.getSynthesizeSpeechUrl(speechParams, function(error, url) { if (error) { return "" } else { speakUrl = url; } }); return speakUrl; } getSynthesizeSpeechUrl を使って、テキストを音声URLに変換します。 テキストの省略は、長すぎる文章と、URLは考慮して行っています。 そのままだと、URLは律儀に1文字ずつ読み上げてくれます。 ただし、各クライアント側で表示されるテキストは省略せずそのままで、音声変換時のみ省略されたテキストを使います。 チャット部分 Socket.IOを使ったチャット自体はよくある使い方です。単純にテキストと、音声変換した音声URLを各部屋のクライアント側に送信しているだけです。 サーバー側 io.on('connection',function(socket){ // 部屋入室 socket.on('enterTheRoom', function({roomId: roomId}){ socket.join(roomId); }) // テキストを受信したら、テキストと音声URLを送信 socket.on('speakTextRoom',async function(speakInfo){ const {speakText, voiceId, roomId, channelId} = speakInfo; // テキストを音声URLに変換 const speakUrl = await textToSpeakUrl(speakText, voiceId); const speakData = {speakText: speakText, speakUrl: speakUrl}; console.log(JSON.stringify({roomId: roomId, speakData: speakData})); // channelId があれば、Slack送信します。 if (channelId !== '') { // Slackに送信 postSlackMsg(channelId, voiceId, speakData); } io.to(roomId).emit('speakData', speakData); }); }); ここはシンプルですが、受け取ったテキストを音声URLに変換して、クライアント側に送信します。 channelId があれば、Slackにも送信します。 クライアント側 var socketio = io(); $(function () { // 部屋番号取得 const pathname = location.pathname; const roomId = pathname.split("room/").pop(); let channelId = ""; // 部屋入室 socketio.emit("enterTheRoom", {roomId: roomId}); // 送信 $("#message_form").submit(function () { // 空白、空文字は送信しない。 if ($("#input_msg").val().trim().length == 0 ) { $("#input_msg").val(""); return false; } // Slack連携flgがcheckedなら、channel_idを渡す。 if ((document.getElementById('slack_link')).checked) { // 先頭がCではないと、""に(channelId) if (roomId.slice(0, 1) === 'C') { channelId = roomId; } } else { channelId = ""; } // サーバに送信 socketio.emit("speakTextRoom", { speakText: $("#input_msg").val(), voiceId: $("#voiceId").val(), roomId: roomId, channelId: channelId} ); $("#input_msg").val(""); return false; }); // テキストと音声URLを受信 socketio.on("speakData", function (speakData) { $("#messages").append($("<li>").text(speakData["speakText"])); const music = new Audio(speakData['speakUrl']); // 音量 music.volume = Number($("#volume").val()); music.play(); // 自動スクロールにチャックなければ、 スクロールしない if ((document.getElementById('auto_scroll_flg')).checked) { $('.message_area').animate({scrollTop: $('.message_area')[0].scrollHeight}, 'fast'); } }); }); URLパス( /room/{各部屋番号} )ごとに部屋を分けるようにしているので、各部屋に入室させます。 Slack連携については、後述します。 音声URLの再生はシンプルで、 Audio() を使っています。 Slack連携 Slack連携をするようにした背景は、ニフティでは特定のリモート会議(大人数が参加するイベントなど)ではSlack実況チャンネルというものが存在していて、実況の分断をなくすためです。 現時点では、「もじこえ」、Slackの双方向にコメントがそれぞれのコメントが流れるようにしました。 もじこえ → Slackのチャンネル 部屋番号をSlackのチャンネルIDにすることで、( /room/{SlackのチャンネルID} )でチャンネルIDを取得します。Slack連携にチェックをつければ、サーバ側でwebhookを使ってSlackチャンネルに送信します。 SlackにPOSTするデータは以下です。現状おそらくSlackで音声再生はできないのですが、再生ボタンの絵文字を押せば、音声URLが開く仕組みにしています。 const payload = JSON.stringify({ channel: channelId, username: username, icon_emoji: iconEmoji, attachments: [ { color: "#ffdbb7", text: `${speakText}\n<${speakUrl}|:arrow_forward:>`, footer: `<{ドメイン}/room/${channelId}|fromもじこえ>`, }, ], }); Slackのチャンネル → もじこえ こちらは、Slack Appを作成して、メッセージデータを取れるようにしました。 データの受取先は手軽なAWS Lambda + API Gatewayにしました。 Lambda + API Gateway APIGatewayはLambdaのAPI化に使っただけで、特に珍しいこともしていないので、説明は省きます。 Lambdaソースは以下になります。 import json import logging import urllib.request import urllib.parse logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(data, context): logger.info(json.dumps(data)) if ('challenge' in data): return { "statusCode": 200, "body": json.dumps({'challenge': data['challenge']}) } # もじこえ用 if data.get("event") is not None: subtype = data["event"].get("subtype") # もじこえ など、botから送信されたメッセージは何もせずreturn if subtype == "bot_message": return text = data["event"].get("text") roomId = data["event"].get("channel") mojikoe_direct_posting(roomId, text) return { "statusCode": 200 } def mojikoe_direct_posting(roomId, text): params = urllib.parse.urlencode({'room': roomId, 'text': text}) url = '{ドメイン}/api/direct-posting?%s' %params req = urllib.request.Request(url) urllib.request.urlopen(req) return "ok" SlackのRequestを受け取るにはSlack Appで承認される必要があります。リクエストデータに challenge が含まれていたら、特定のレスポンスを返すようにします。 また双方向の実装するにあたり、考慮する必要があったのが、「もじこえ」→Slackに送信された場合、Slack AppのEventが発火され、「もじこえ」→ Slack → 「もじこえ」のように再び送信しようとすることです。 以下のように、SlackからPOSTされるデータの event の subtype を見ると、 bot_message になっているのがわかったので、ここで判別するようにしました。ちなみに、普通にSlackに投稿した場合は "type": "message" になります。 ~~~ "event": { "type": "message", "subtype": "bot_message", "text": "もじこえ から Slack に", "ts": "1661256966.757159", "username": "Mizuki", "icons": { "emoji": ":woman:" }, ~~~ 「もじこえ」に送信する部分については、「もじこえ」のサーバ側で簡単なAPIを作成したので、それを呼ぶだけです。 まずサーバ側で部屋名とメッセージを受け取り、音声はランダムにして、音声URLを作成し、対象の部屋に送信します。 サーバ側のソース // API app.get('/api/direct-posting' , async function(req, res){ const roomId = req.query.room; const voiceIds = ["Mizuki", "Matthew", "Takumi"] const voiceId = voiceIds[Math.floor(Math.random() * voiceIds.length)]; const speakUrl = await textToSpeakUrl(req.query.text, voiceId); const speakData = {speakText: req.query.text, speakUrl: speakUrl} io.to(roomId).emit('speakData', speakData); console.log(roomId, speakData); res.status(200); res.send("ok"); }); Slack Appの設定 Subscribe to bot events で message.channels を追加すると、作成したSlack Appが追加されているチャンネルでメッセージが投稿されたときに、連携したURLにデータをPOSTしてくれます。 ※外部にSlackメッセージが送信されるので、扱いには気をつける必要があります。 Lambda + API Gatewayで受け取る Request URL に追加して連携します。上で説明した、特定のレスポンスを返す用に実装しておくと承認されます。 準備ができたので、あとは連携したいチャンネルにSlack Appを招待。 「もじこえ」のURLを /room/{SlackのチャンネルID} にして、Slack連携のチェックをいれれば、完成です。 今後やること もともと勉強で作り始めたもので、まだまだやることがいっぱいあります。 フロントをReactなどで書き換える Slack連携のオンオフ制御 社内SSO連携 現在匿名でのコメントになるので、チームで相談してログ整備は必要ということになりました。 Meetの拡張機能にできないか調査 などなど またなにか進展があれば、ブログに書こうかと思ってます! 【告知】NIFTY Tech Dayで「もじこえ」について話すかもしれません! NIFTY Tech Day 2022 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
はじめに こんにちは!新卒入社6年目の添野です。@niftyトップページシステムの開発・運用を担当しています。 先日「レガシーシステムからの脱却」に登壇しましたので、その様子を紹介していきます! イベント概要 NIFTY Tech Talk は、ニフティ株式会社の社員が主催するトークイベントです。 本イベントではニフティ社員が業務を通じて学んだことを発信しています。 第四回目となる今回は、「レガシーシステムからの脱却」に関するテーマで開催しました。 ニフティではさまざまなシステムの刷新やリプレースなどを行っています。今までのレガシーなシステムからモダンなシステムにどんどん切り替えていこうという流れが全社的に強くなっています。 イベントの詳細については こちら の記事でも紹介しておりますので、ぜひご覧ください。 また、今回の Tech Talk のアーカイブを YouTube にアップロードしております。 こちらもご覧いただけますと幸いです。 内容レポート オープニングからディスカッションに至るまでの各セッションにおいて一部抜粋して、どのような内容だったかご紹介したいと思います。 オープニング 今回も前回に引き続きYouTube Liveで開催しました。 はじめにニフティの会社紹介、登壇者の自己紹介から始まりました。 今回も最後にニフティポイントのプレゼントがありました! 今回の登壇者 小松 勇貴:会員システムグループ グループ長 島田 大徳:基幹システムグループ 課金システムチーム 村松 啓寛:会員システムグループ 第2開発チーム 添野 翔太:会員システムグループ 第1開発チーム 清水 利音:基幹システムグループ サービスインフラチーム 固定IP受付システム刷新 まず1つ目は、 @nifty 固定IPサービス の事例紹介です。 Kubernetesを活用してマイクロサービス化を図りながら新環境を構築を進めた話がありました。 レガシー脱却の背景 あるタイミングで新規のIPを払い出す話が浮上した際、前任者がチームを離れてしまったため改修に注力できない状況が生まれたとの話がありました。@nifty固定IPサービスのシステムはモノリスでブラックボックスとなっていたため、作るべきものを見定めた上でイチから作ることにしたそうです。 新環境の紹介 申込受付部分にフォーカスして説明がありました。新環境はEKS、NGINX、Djangoをベースに、 Argo CD なども組み合わせて構築したそうです。 新環境構築を通じて 構築を進めていく中でブラックボックスとなっていたシステムに関して要件が明らかになり、改修がしやすくなったそうです。また開発者のスキルが向上し、モチベーションも上がったそうです。 ニフティニュースの夜明け〜32万超のページをレガシーシステムから救出!〜 2つ目は、 @niftyニュース の事例紹介です。 ストラングラーパターンを利用し、モダンなアーキテクチャーへの段階的な移行について話がありました。 レガシー脱却の背景と目的 コア機能をニフティ独自のモノリスフレームワークで提供しているため、属人化が進みやすい、クラウドのスケーリングメリットなどの恩恵を受けられないという課題に加えて、@niftyニュース特有の課題についても触れられていました。 新環境の紹介 移行方針ストラングラーパターンについて説明がありました。またモダンな開発言語を採用し、オートスケーリングなどクラウドメリットを享受できるようなシステム構成にした話がありました。そして事前のページ出力に関してはSEOを意識してSSRを利用したそうです。 新環境構築を通じて 老舗ポータルサイトの新たなシステムへの挑戦 〜@niftyトップページ〜 3つ目は、筆者のセッションである @niftyトップページ の事例紹介です。 @niftyニュース と同様にストラングラーパターンを利用し、Next.js、AWSを使ってPC版ページの刷新を進めた話をしました。 レガシー脱却の背景と目的 長大なJavaScriptファイルや未使用なコードがあるなどの課題を解決することが目的であるという話をしました。 新環境の紹介 APIデータ連携を実施し、レガシーシステムからの脱却を着々と進めているという話をしました。 Serverless Framework 、改修対象を迅速に把握するために Atomic Design を駆使したアプリケーションの再構築、GitHub Actionsを用いたデプロイを実施していることを紹介しました。 他のGitブランチ戦略の記事 を参考にして策定した、新環境でのブランチ戦略を紹介しました。 新環境構築を通じて 内製で構築を進めたので、システムへの理解が進み、ドキュメントを新しくできていること、また最新技術に触れたことでメンバーのモチベーションが向上したという話をしました。 レガシーなシングルサインオンシステムを完全内製で作り直した話 最後は、ニフティシングルサインオン(SSO)システムの事例紹介です。 100を超えるサービスと連携する状況で、マネージドサービスを活用して問題に立ち向かった話をしていただきました。 レガシー脱却の背景 SSOシステムはスケールイン/アウトしにくいインフラ構成でバージョンアップも厳しいシステムであるという話がありました。またドキュメントが少なくブラックボックス化しているという話がありました。 新環境の紹介 メンバー一丸となり、コードリーディングを進め仕様を把握し、基本設計から作り直したそうです。またインフラはCDKを用いてIaC管理を進め、CloudWatchなどAWSサービスを用いた監視機構を導入したそうです。 新環境構築を通じて 完全内製で進めたことによりナレッジが残せたこと、インフラコストを削減できたことについて話がありました。 ディスカッション 今回は各システムの事例紹介後、登壇者間でディスカッションをする時間を設けました。 以下のテーマに沿って深堀りを進めました。 テーマ1:そもそもレガシーって何?(レガシーへのイメージ) テーマ2:皆さんのシステム、どれくらいレガシーなんですか?(レガシー度合いの自慢) テーマ3:レガシー脱却で苦労した話 テーマ4:レガシー脱却の対応状況 テーマ1:レガシーへのイメージ 今回のテーマである「レガシー」に関して、各自イメージを話しました。 気軽に変更できない、チーム離脱に伴い前任者が持っていた知見が失われている状態などが話に挙がりました。また新環境への構築を進めた我々が未来に負債を残さないという話も挙がりました。 テーマ2:レガシー度合いの自慢 レガシー脱却を進めていた中での苦しみを存分に話しました。何か変更を行う際に影響範囲がしっかりと分からない、何かあってもシステムを再構築できない、そして中にはテストも仕様書もないという悲しみを持つシステムがありました。 テーマ3:レガシー脱却で苦労した話 汎用的なシステムを利用しているがゆえの苦しみ、また知見が失伝されていることによる要件漏れ、連携先や連携要素の多さによるものが挙がっておりました。 テーマ4:レガシー脱却の対応状況 事例紹介の中では触れなかった進捗度合いについて話しました。各システムはおおむね道半ばという状況ですが、新環境での明るい未来の実現に向けてこれからも突き進んでいきたいという話がありました。 まとめ 今回の Tech Talk では、ニフティでのレガシー脱却について事例を交えて紹介しました。 1 時間という短い枠だったので、今回話しきれなかった内容もありますが、参考にできるものがあれば幸いです。 また後半ではディスカッションを行いました。社内の雰囲気を少しでも感じていただけたらありがたいです。 そして今回も質問やコメントをくださった方もいました。ありがとうございました。 今後も NIFTY Tech Talk は継続して実施していきますので、ぜひご参加ください。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
■始めに 初めまして。下屋敷と申します。 ニフティ株式会社に中途入社して5年目になります。 弊社では今AWSのサービスを次々と取り入れてシステム開発をしています。 ニフティでは回線接続サービスを提供していますが、私が担当しているシステムで回線申込時に特定オプションを申し込んだお客様に対して使用可になった際にSMS通知をしたいという要望があったため、Amazon SNSのSMSを用いて対象者へのSMS送信を導入、実装した話をお伝えしようと思います。 単にSMS送信をしたいだけなのですが、ネット検索をしてみてもトピック機能などの記事に寄ってしまっていたり、後述するサポート申請に関する記述が無かったりと、意外とそういった記事が無かったというのも書いてみようと思った理由です。 ■前提として オプションが使用可になった申込ユーザに対しては、ECSクラスターのタスクスケジューリングにて定期バッチ起動をして対象者へのSMS送信をします 特定オプションの申込は月500件想定なので、SMSを500件/月送信する予定です ■AWSコンソール上からSMS送信を試してみる テスト送信してみます ログイン後Amazon SNS(SMS)サービスへ移動 デフォルトはサンドボックス内になっている(詳細は後述)と思うので、先に電話番号を登録して認証します。※登録に関する手順詳細は割愛 ちなみに検証してみたところ「+810X0」形式でも「+81X0」形式でも送信できるみたいです。(boto3経由でも同様でした賢い!) 電話番号認証完了したら「テキストメッセージの発行」から発行してみます 既に登録された電話番号が送信先選択できるので選択して「送信者ID」も指定 届きました! ちなみに送信者ID指定しないと「NOTICE」として送信されます これで送信テストできました! ■Amazon SNS(SMS) を用いたメッセージ送信のソース(Python) awsコンソール上からのSMS送信は確認できました。 バッチからAmazon SNS(SMS)を呼び出して送信をしたいので、実装方法を確認します。 boto3のpublishを用いると送信が可能です( 機能詳細 ) boto3は実行環境にpip installしておきましょう 事前にAWSコンソール上のIAMよりIAMユーザーを作成し、 AmazonSNSFullAccess のアクセス許可を設定しておきます。その際に生成された アクセスキーID と シークレットアクセスキー を控えておきます サンプルソース(Python) 単にSMS送信を実行するだけなら以下のソースで行けるはずです。 実際は複数の電話番号にお送りすることになると思うので、対象の電話番号分client.publishをループする形になるかと思います。 import boto3 client = boto3.client( 'sns', aws_access_key_id='[アクセスキーID]', aws_secret_access_key='[シークレットアクセスキー]', region_name='[リージョン]' ) res = client.publish( PhoneNumber='[電話番号]', Message='[送信するメッセージ本文]', MessageAttributes={ 'AWS.SNS.SMS.SenderID': { 'DataType': 'String', 'StringValue': '[送信者ID]' } } ) こちらのソースでも同じように送信できました! ですが、色々実装・確認をしながらマニュアル等を確認していたところ、後述の制限などがあることが分かったので、 その制限を確認しつつサポートへの申請をしています。 次はそちらを確認していきます。 ■Amazon SNS(SMS) を利用するにあたっての注意 単に特定の電話番号にSMSメッセージ送信をしたかっただけなのですが、実装導入するにあたり、何点か気を付けなければいけないことがありました。 デフォルトの状態ですと、以下の制約があります。 アカウントの毎月毎のSMSの使用料上限が決まっている。デフォルトは$1.00 USD  ( https://docs.amazonaws.cn/en_us/sns/latest/dg/sms_preferences.html ) デフォルトはAmazon SNS サンドボックス内にあるので、SMS内で認証した電話番号(最大10件)以外に送ろうとする場合はアカウントをサンドボックス外に移動申請する必要がある ( https://docs.aws.amazon.com/ja_jp/sns/latest/dg/sns-sms-sandbox.html ) こちらの制約について確認します。 アカウントのSMSメッセージングの使用料上限について ▼日本国内でのコストと上限 執筆時点での日本国内でSMSメッセージを送信しようとしたときのコストは $0.07451 です。 各国のSMS料金 デフォルトの上限は$1.00 USDとのことでした。これは1か月ごとの上限のようです。 アカウントの請求ダッシュボードを参照した際に「Amazon Simple Notification Service APN1-SMS-Price-ROW」が1.00 USDに到達していると、SMS送信不可となります ▼どのくらいのコストがかかるか試算してみる SMS 使用クォータの計算式  大体要約すると以下のような計算式になります。 (1日のメッセージ送信量 × 30日【1か月】) × $0.07451 USD × 【メッセージが長文になって分 割される想定の時何パート分割されるか】 = 1か月の使用量 デフォルトですと、日本国内では短いメッセージでも大体13件くらいまでしか送信できない想定です 余談ですが、日本の大手通信キャリアのSMSの文字上限は1メッセージは670文字(全角)くらいのようなので動作検証は必ず必要ですが、大体のメッセージは1パートで送れる想定です 1か月送信件数 SMS金額 パート * コスト 判定 500 $0.07451 1 $37.2550 × 100 $0.07451 1 $7.45100 × 50 $0.07451 1 $3.72550 × 14 $0.07451 1 $1.04314 × 13 $0.07451 1 $0.96863 〇 12 $0.07451 1 $0.89412 〇 … 2 $0.07451 1 $0.14902 〇 1 $0.07451 1 $0.07451 〇 今回はさほど長文を送るわけではないので、1パートのみのメッセージを想定して試算すると… 月500件くらい送る想定 × $0.07451 × 1パート = $37.255 ▼確認結果 $37 USDと試算が出ました。切り上げて$38とし、こちらを上限として申請しないとダメそうです。 申請後はAWSコンソール上で自分で上限値を上げる必要があるとのこと。 SMS サンドボックス ▼何でサンドボックスがあるの? 過去はSMSのサンドボックス機能は実装されていなかったようです。 ここ最近は新規でアカウント作成するとサンドボックス状態になっています。 サンドボックスは個人的な見解ですが、こういった意図があるのかなと思っています。 最初から不特定多数にSMS送信できる仕組みはサービスとして良くない 最初のうちは本当に送りたい先を登録&認証してその送信先にSMSを送って内容を検証すべき 一旦遊び場(試験場)のような場所を設けておいて、検証できたらそのサービスを公開(サンドボックスからの移動)することで安全を保障する ▼サンドボックス内の機能制限 デフォルトはこのような表記になっていると思います。 サンドボックス内でも大体機能は使えますが以下制限があるようです。 SMS メッセージは、認証済みの送信先電話番号にのみ送信できます。 最大 10 個の認証済みの送信先電話番号を持つことができます。 送信先の電話番号を削除できるのは、認証または最後の認証の試行から 24 時間以上経過後に限られます。 ▼そのままサンドボックス内で要件を満たせるか? 送り先が完全に決まっていて定期送信するような用途でしたらそのままでも良さそうですが、今回はオプション申込されたユーザそれぞれにSMSメッセージお送りしなければいけないので、そのままでは良くなさそうです。 毎度毎度バッチ実行の度に、電話番号登録 → 認証するのは流石にNG(お客様に認証をしていただく手段が無い) しかも認証できたとしても最大10個までしか登録できない 一度登録した電話番号は認証してから24時間以上経たないと削除できない ▼確認結果 サンドボックス内での利用では要件を満たせません。 というわけでAWSサポートに連絡して上記の撤廃申請を出すことにしました。 ■AWSサポートへの申請 デフォルトのままですと、制限により実装機能を満たす使い方ができないということが分かったので、AWSサポートへの申請を出します。 サポートページからの申請 ログイン後  サポートページ  へ Service limit increaseを選択 【 Case details 】 Limit type:SNS Text Messagingを選択し、optionalはどういう用途で制限を撤廃したいのかを記載 【Requests】 「 SMSアカウント使用量のしきい値の増加 」、「 アカウントのサンドボックス外への移動 」が目的なので Requests からそれぞれ追加 【 Case description 】どういう用途・目的で申請を出しているのかを記載 記述内容が不明だったり、情報不備などあればサポートから返信されるので、とりあえず自分がやりたいことを記載してみて申請を出してみるといいと思います。 大体数日以内にはサポートからお返事いただけると思います。(結構早かった) 申請が通るとこのような感じでサポートからお返事を頂けました。 申請通ったのでアカウント情報確認 申請が通ったので変更されているはずです。確認します。 1USD → 38USD AmazonSNSサンドボックスから移動 ▼アカウントのSMSメッセージングの使用料上限 「テキストメッセージングの優先設定」より「アカウントの使用制限」が設定したい上限値になっているか確認(変更されていました) 設定したい上限値になっていなければ変更 ▼SMS サンドボックス ステータスが変わりました これでSMS メッセージを任意の電話番号に送信できるようになりました 「サンドボックスの送信先電話番号」の項目は消えます 変更前はこちらでした ■まとめ これでAmazon SNS(SMS)を活用できるようになりました。 成功、失敗等をもっと詳細に知る必要がある場合は、cloud watch logsに出力する必要がありますが、 今回は簡易的な実装なのでここまでとなります。 AWSの技術、UIは移り変わりが激しいので、ここで共有させていただいた内容も数か月後、数年後には古くなっている可能性がありますが、誰かのお役に立てれば幸いです! ■We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
概要 サービス開始から35年、ニフティは常に技術者やIT技術と共にありました。 高い好奇心で新しい技術トレンドをいち早く導入し、システムやサービスへの活用を常に模索しています。ニフティが創業時から変わらないのは、好奇心と挑戦し続けること。 この”NIFTY Tech Day”を通じて、私たちの今と未来をお伝えします。 詳細 公式サイト 日程 11月22日(火)13:00〜18:00 配信URL 準備次第掲載いたします 視聴環境 インターネット接続が可能なPC/スマートフォン 参加方法 connpass にて参加登録をお願いします! タイムテーブル 準備次第掲載いたします。 ニフティグループでは一緒に働く仲間を募集中です ニフティ株式会社 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています! ニフティライフスタイル株式会社 想像以上を、みつけよう。 をコーポレートメッセージに、“一人ひとり”のライフスタイルを便利で豊かにするため、ニフティライフスタイルのエンジニアは日々開発をしています。 採用情報 や ニフティライフスタイル Tech Blog をご覧ください。 ニフティエンジニアのTwitterアカウントを作りました NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 https://twitter.com/NIFTYDevelopers
はじめに はじめまして。新卒3年目の南と申します。 ニフティではSlackを利用しており、絵文字リアクションも多く利用されています。日々の連絡や相談はもちろんのこと、出退勤連絡やレビュー依頼などでもSlackを利用しています。 そして私はふと思いました。 毎日当たり前に利用しているSlackですが、Slackの機能を活用しきれてないのでは? 入社当時から既にSlackを使い始めているので、改めてSlackの使い方や機能について学ぶ機会がなく案外知らない機能や使ったことのない機能が多いのではないだろうか? Slackを使って、何か業務効率化できないだろうか? そこで今回は、Slackの機能の一つであるワークフロービルダーを活用して日々の業務連絡を少しだけ効率化させた事例をご紹介します。 ワークフロービルダーとは ワークフロービルダーは、定型的なプロセスを自動化して Slack ワークスペースのワークフローに変換できるツールです。コーディングの必要はありません。Slack でのワークフローは簡単なものから複雑なものまで自由に作れます。仕事に使用しているほかのアプリやサービスを連携させることもできます。 https://slack.com/intl/ja-jp/help/articles/360035692513-%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%95%E3%83%AD%E3%83%BC%E3%83%93%E3%83%AB%E3%83%80%E3%83%BC%E3%82%AC%E3%82%A4%E3%83%89 上記の通りコーディングなしで定型的なプロセスを自動化できる非常に便利なツールです! ワークフロービルダーには6つ(2022年9月現在)のテンプレートが存在しています。まずはそれぞれ何ができるテンプレートなのか簡単にご紹介します。設定方法や使い方については ワークフロービルダーガイド をご覧ください。 新しくチームに参加するメンバーに送る心温まる歓迎メッセージのテンプレート 新しいメンバーがチャンネルに参加するタイミングで自動でメッセージを送信するテンプレートです。 ニフティでも歓迎してくれるチャンネルがたくさんあります! リクエストのトリアージ方法 メンバーがチャンネルにリクエストを簡単に送信できるように、ショートカットを追加するテンプレートです。 ニフティでも問い合わせフォームなどで多く利用されています。 毎日のスタンドアップ・ミーティングとチェックイン 日時のスケジュールを使用してチームのリマインダーを設定し、通知するテンプレートです。日付、時間、頻度、繰り返す間隔、終了タイミングなどが設定可能です。 ニフティでも定期的な打ち合わせを知らせたり、定期的に行う作業を忘れないよう知らせたりするリマインダーとして多く利用されています。 情報を簡単に送る方法 誰かが会話に 特定の絵文字 で反応した時にメッセージが自動送信されるテンプレートです。 よく使われる絵文字を指定してしまうとその度に自動送信されるので注意が必要です。 チームのステータス更新 いつオフィス不在であるか、リモートで作業するかといった最新情報をチームが公開できるショートカットを追加するテンプレートです。 ショートカットを追加するテンプレートなので、2つ目に紹介したリクエストのトリアージ方法と同じような設定手順になります。 ゼロから始める 名前の通り、ゼロから自分で設定していく必要があります。まず、ワークフローを開始させる方法から選択していきます。ワークフローの開始方法は下記から選ぶことができます。 ショートカット 「 リクエストのトリアージ方法 」「 チームのステータス更新 」と同じような開始方法です チャンネルの新しいメンバー 「 新しくチームに参加するメンバーに送る心温まる歓迎メッセージのテンプレート 」と同じような開始方法です 絵文字リアクション 「 情報を簡単に送る方法 」と同じような開始方法です スケジュールされた日付と時間 「 毎日のスタンドアップ・ミーティングとチェックイン 」と同じような開始方法です Webhook URLが生成されるので、アプリや他サービスがリクエストを送信すると開始します ワークフローのステップ追加でできること ここまで説明した各テンプレートでは、下記のようなステップの追加も可能です。 ※3つ目以降は、各種アプリと連携することで利用が可能になります。 メッセージを送信 フォームを送信する Add a spreadsheet row スプレッドシートに追記します Delete a spreadsheet row スプレッドシートの特定の行を削除します Select a spreadsheet row スプレッドシートの特定の行の内容を取得します Update a spreadsheet row スプレッドシートの特定の行の内容を更新します More Steps by Zapier Zapier では、Zap というカスタムワークフローを使用して、毎日使うツールの間で情報を自動的に移動します。Zapier アプリをインストールすると、ワークスペースをさまざまなサービスに連携させて、作成した Zap を Slack で直接使用できます。 https://slack.com/intl/ja-jp/help/articles/360002074228-Slack-%E7%94%A8-Zapier 活用事例 ここまでワークフロービルダーについて簡単にご紹介しましたが、ここからが本題です! ニフティでは、出社/在宅のハイブリッドな働き方を導入しており場所が離れていて直接顔を合わせない日もあるので、私が所属するチームではSlackのワークフローを活用して出退勤連絡や残業申請などを行っています。これまでの課題も交えて実際に活用しているワークフローをご紹介します。 出勤連絡 これまでの課題 毎日スレッドに勤務場所と業務内容を手入力する必要があり、業務内容記入以外で毎回同じ記載をしている部分がありました。 改善 業務内容記入は必須ですが、毎回同じ記載をしている「〇〇勤務開始します。」などは絵文字リアクションで自動送信できるようにしたいという思いがありました。全体で利用しているワークフロービルダーのテンプレートは下記の2つです。 毎日のスタンドアップ・ミーティングとチェックイン(元々利用していたテンプレート) 情報を簡単に送る方法 ステップの追加でフォームの送信を追加しました 在宅か出社によって文章が変わるため、それぞれ特定の絵文字で動くワークフローを設定しています。 業務内容入力は毎日異なるためフォーム入力できるようにしてあり、その内容と特定の文章を組み合わせてこれまで動いていたリマインダーのスレッドにメッセージを自動投稿するようにしています。 毎日異なる業務内容の入力まで自動化することは困難でしたが、毎回同じ記載をしていた「在宅勤務開始します。」や「【主な業務内容】」など固定の文章については入力不要となったため、少し手間を省くことができました。 退勤連絡 これまでの課題 明日の勤務状況が2パターンあるだけで、それ以外の「退勤します。明日も〇〇です。」は固定化され毎日スレッドに手入力する必要がありました。 改善 絵文字リアクションで退勤連絡ができるようにしたいという思いがありました。全体で利用しているワークフロービルダーのテンプレートは下記の2つです。 毎日のスタンドアップ・ミーティングとチェックイン(元々利用していたテンプレート) 情報を簡単に送る方法 在宅か出社によって文章が変わるため、それぞれ特定の絵文字で動くワークフローを設定しています。 絵文字リアクションのみで退勤連絡が可能となりました。 残業連絡 これまでの課題 残業する際、スレッドに上司へのメンションや作業内容、残業時間や申請済みかどうかを手入力する必要があり、作業内容や残業時間は変わるものの上司へのメンションや申請済みかどうかは毎回同じ記載をしていました。 メンションすることを忘れてしまったり、作業内容や残業時間の入力を忘れる恐れがありました。 改善 作業内容や残業時間は必須で入力するようにして、上司へのメンションなどは記載漏れがないよう絵文字リアクションで自動送信できるようにしたいという思いがありました。全体で利用しているワークフロービルダーのテンプレートは下記の2つです。 毎日のスタンドアップ・ミーティングとチェックイン(元々利用していたテンプレート) 情報を簡単に送る方法 ステップの追加でフォームの送信を追加しました 作業内容や残業時間はフォーム入力を必須とするように設定し、残業時間についてはリストとして一定間隔で時間を設定して一覧から選択できるようにしました。 フォームに入力された内容を元に自動でメッセージをスレッドに投稿することが実現できたので、全て手入力する手間を省くことができました。 レビュー依頼フォーム これまでの課題 レビュー依頼のショートカットにより投稿されたメッセージに対して、レビュアーは対応のチケットにコメントを記載した上で同じような内容をSlackでも連絡をしているので、二度手間になってしまっていました。 改善 レビューをいつ始めてもらえたかを把握したいという思いや、レビュー結果が問題ない、もしくは、チケットに記載している指摘内容を確認して欲しいという文章を絵文字リアクションで自動送信できるようにしたいという思いがありました。全体で利用しているワークフロービルダーのテンプレートは下記の2つです。 リクエストのトリアージ方法(元々利用していたテンプレート) 情報を簡単に送る方法(2つ) まず、レビューをいつ始めてもらえたかを把握するためにワークフローを設定しました。レビュアーがどの絵文字を使ってリアクションすればよいかも明記しています。 指摘ありかなしによって文章が変わるため、それぞれ特定の絵文字で動くワークフローを設定しています。 レビュアーの二度手間を無くすことができ、レビューの状況も依頼者が把握できるようになりました。 運用作業の時間計測 これまでの課題 チェックやリカバリにかかった時間を自分でスプレッドシートに追記していく必要がありました。 改善 対応者はSlackのみで時間を登録できるようにして、自動でスプレッドシートに追記/集計をできるようにしたいという思いがありました。全体で利用しているワークフロービルダーのテンプレートは下記の2つです。 毎日のスタンドアップ・ミーティングとチェックイン(元々利用していたテンプレート) ゼロから始める 絵文字リアクションでワークフローを開始するようにして、ステップの追加でフォームの送信とAdd a spreadsheet rowを追加しました かかった時間をフォームで入力できるようにして、スプレッドシートにはフォームの入力を行った日付とフォームの入力者、そして入力された時間を追記するように設定しています。 スプレッドシートに移動して追記する手間が無くなり、日付や確認者も別途フォーム入力する必要はなく自動で追記してくれるためとても便利です。 スプレッドシートだと、グラフ化させる設定を入れていれば自動でグラフに追加されていくので可視化できました。 最後に ニフティではSlackの絵文字リアクションを多く活用していることに着目し、絵文字リアクションで開始できるワークフローを活用してみました。 まだまだ有効活用できる方法はたくさんあると思いますし、使い道はたくさんあります。ノーコードで誰でも簡単に設定できるので、是非毎日当たり前に行っている作業を自動化して効率化させてみてはいかがでしょうか? 私も、ワークフロービルダーを使いこなして業務効率化に繋げていきたいと思います! We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
イベント概要 NIFTY Tech Talkは、ニフティ株式会社の社員が主催するトークイベントです。 本イベントではニフティグループの社員が業務を通じて学んだことを発信しています! 第5回目のテーマは「iOS/Androidアプリ開発」。現在、ニフティおよびニフティライフスタイルではさまざまなiOS/Androidアプリアプリが展開されています。 今回はそれぞれのサービスのiOS/Androidエンジニアから、新規アプリの立ち上げからアーキテクチャ選定、チーム開発の難しさなどをLT形式で語っていただきます。 本イベントは ニフティ株式会社 と ニフティライフスタイル株式会社 の共催でお届けします。 概要 日程:9月26日(月)12:00〜13:00 配信方法:YouTube Live 視聴環境:インターネット接続が可能なPC/スマートフォン 参加方法 YouTube Live connpass にて参加登録をお願いします! こんな方におすすめ iOS/Android関連技術およびすべてのソフトウェアエンジニア iOSのCI/CDなどのDevOpsに興味がある方 AndroidアプリへJetpack Composeを導入検討している方 アプリエンジニアのチーム作りに興味がある方 ニフティの現場でどのような技術が使われているか興味のある方 タイムテーブル 時間 コンテンツ 12:00-12:05 オープニング+会社紹介 12:05-12:10 登壇者紹介 12:10-12:25 ニフティライフスタイルのiOSアプリ開発での課題と解消に向けた取り組み 12:25-12:40 マイ ニフティ Android版におけるJetpack Composeの導入と課題 12:40-12:55 マイ ニフティ アプリ開発チームにおける開発スタイルの紹介 12:55-13:00 クロージング テーマ 各プロダクトに携わっている方々に登壇していただき、それぞれLT形式で発表していただきます。 ニフティライフスタイルのiOSアプリ開発での課題と解消に向けた取り組み 累計900万DLの不動産アプリを始めとする「ニフティライフスタイル株式会社」のiOSアプリ開発現場では、「在宅勤務下でのプロダクトレビューが大変」「施策が多く改善活動に時間を割けない」など複数の課題がありました。これらの課題に対して「CI/CD(Bitrise)導入」などの改善を行なってきた経緯など、我々が課題に対してどのように取り組んでいるかをお話しします! マイ ニフティ Android版におけるJetpack Composeの導入と課題 今年リリースしたニフティ会員向けアプリ「マイ ニフティ」Android版では開発当初より画面実装にJetpack Composeを全面的に採用し開発を行っています。 まだ登場して間もないJetpack Composeですが、実際に取り入れてどう良くなったか、また現状抱えている課題などについてお話しします。 マイ ニフティ アプリ開発チームにおける開発スタイルの紹介 ニフティ会員向けアプリ「マイ ニフティ」の開発チームでは、API・インフラのバックエンドを含めたiOS/Androidアプリの開発・運用を行なっています。幅広いタスクを行う中で「アプリ経験が浅い新規メンバーへの技術共有」「タスクの属人化解消」「品質管理」が重要になっています。これらに対する取り組みについて、アーキテクチャなども交えて開発スタイルをお話しいたします! 登壇者プロフィール 中村 伊吹(ファシリテータ) ニフティ株式会社 会員システムグループ 第二開発チーム 新卒入社4年目。ニフティニュースの開発・運用を担当し、最近はモダンなフロントエンド開発を学習中。男女混成チアリーディング元日本代表。 山田 良介(登壇者) ニフティ株式会社 会員システムグループ 第一開発チーム 新卒入社六年目。Web検索(@search)の運用を担当しつつ、社内でのアプリ開発に協力。マイ ニフティではテックリード兼Androidエンジニアとして参加。 川上 倫人(登壇者) ニフティ株式会社 会員システムグループ 第二開発チーム 新卒入社4年目。マイ ニフティアプリの開発・運用を担当し、モダンなアプリ開発の実践に向けて学習中。 齋藤 圭祐(登壇者) ニフティライフスタイル株式会社 システム開発部 アプリ開発チーム 新卒入社4年目。主にニフティ不動産のiOSアプリの開発・運用を担当しつつ、Androidも勉強中。 ニフティグループでは一緒に働く仲間を募集中です ニフティ株式会社 新卒採用、キャリア採用を実施しています。ぜひ リクルートサイト をご覧ください。 ニフティエンジニアが業務で学んだことやイベント情報を エンジニアブログ にて発信しています! ニフティライフスタイル株式会社 想像以上を、みつけよう。 をコーポレートメッセージに、“一人ひとり”のライフスタイルを便利で豊かにするため、ニフ ティライフスタイルのエンジニアは日々開発をしています。 採用情報 や ニフティライフスタイル Tech Blog をご覧ください。 ニフティエンジニアのTwitterアカウントを作りました NIFTY Tech Talkのことや、ニフティのエンジニアの活動を発信していきます。 https://twitter.com/NIFTYDevelopers アンチハラスメントポリシー 私たちは下記のような事柄に関わらずすべての参加者にとって安全で歓迎されるような場を作ることに努めます。 社会的あるいは法的な性、性自認、性表現(外見の性)、性指向 年齢、障がい、容姿、体格 人種、民族、宗教(無宗教を含む) 技術の選択 そして下記のようなハラスメント行為をいかなる形であっても決して許容しません。 不適切な画像、動画、録音の再生(性的な画像など) 発表や他のイベントに対する妨害行為 これらに限らない性的嫌がらせ 登壇者、主催スタッフもこのポリシーの対象となります。 ハラスメント行為をやめるように指示された場合、直ちに従うことが求められます。ルールを守らない参加者は、主催者の判断により、退場処分や今後のイベントに聴講者、登壇者、スタッフとして関わることを禁止します。 もしハラスメントを受けていると感じたり、他の誰かがハラスメントされていることに気がついた場合、または他に何かお困りのことがあれば、すぐにご連絡ください。 ※本文章はKotlinFest Code of Conductとして公開された文章( https://github.com/KotlinFest/KotlinFest2018/blob/master/CODE-OF-CONDUCT.md )を元に派生しています。 ※本文章はCreative Commons Zero ライセンス( https://creativecommons.org/publicdomain/zero/1.0/ ) で公開されています。
初めに こんにちは!Flutterエンジニア(自称)の柴田です。 Flutterは、UIレンダリングエンジンとしてSkiaを採用しています。 しかし、Skiaにはパフォーマンスの問題があり、Flutterはバージョン3.0.0で「Impeller」というUIレンダリングエンジンを実験的に導入しました。 今回はこの「Impeller」を試してみます。 「Skia」とは Skiaは2Dグラフィックスライブラリーです。 特徴として以下の点があげられます。 オープンソース Googleが開発 C++を使用 マルチプラットフォームに対応 Chrome、Android、.NET MAUI(Xamarin.Forms)、Compose Multiplatformなど多くの環境で採用されています。 余談: Xamarinは今後サポート終了し.NET MAUIに引き継がれる予定です。 https://dotnet.microsoft.com/ja-jp/platform/support/policy/xamarin FlutterでもUIレンダリングエンジンとしてSkiaを採用しています。(Flutter WebはSkiaのWebAssembly版であるCanvasKitを使用) https://skia.org/ Skiaの問題点 初回起動時のパフォーマンスが悪い Skiaでは、アプリ初回起動時にシェーダーコンパイルが行われるため、初回起動時のパフォーマンスが良くありません。(60FPSを下回るなど) Andoridはコンパイルの結果が永続化されるため、パフォーマンスが悪いのはアプリインストール後の起動時のみですが、iOSはタスクキルすると廃棄されるため、アプリを起動するたびにパフォーマンスが悪くなります。 Skiaにはこのシェーダーコンパイルを事前にしておくSkSL(Skia Shader Language) warmupという機能があります。これは、事前にSkSL でシェーダーをキャプチャし、それをアプリにパッケージ化することで初回起動時のコンパイルを軽減するものです。しかし、これはアプリを変更するたびに全てのシェーダーをキャプチャする必要があり、開発者の負担が大きいという問題があります。また、キャプチャしたシェーダーが他の端末で使用できる保証がありません。 https://docs.flutter.dev/perf/shader 新しいエンジン「Impeller」とは これらSkiaのパフォーマンス問題はFlutter公式でも認識しており、グラフィックバックエンドの書き換えをおこなっています。それが「Impeller」です。 「Impeller」はFlutterのためのレンダリングランタイムです。 特徴としては以下の点があげられます。 全てのシェーダーのコンパイルをビルド時にオフラインで実行 モダンなグラフィックスAPIを効果的に使用 MetalやVulkanなどの利用可能な機能を使用する(依存はしない) 並行処理を効果的に使用 必要なら単一フレームワークロードを複数スレッドに分配して処理する 現在Impellerが使用できるのはiOSとAndroidのみです。 https://github.com/flutter/engine/tree/main/impeller 「Impeller」を使ってみる 重いと噂のアプリでパフォーマンスの比較を行います。ページ遷移時のレンダリング速度をDevToolsで計測します。 https://github.com/flutter/gallery/releases/tag/v2.9.2 実行環境 MacBook Pro (13-inch, M1, 2020) Flutter 3.0.4 Simulator Version 13.4.1 (977.2) iPhone 13 Pro (iOS15.5) 結果 シェーダーコンパイルにかかる時間の結果です。 Skiaは162.5msかかってるのに対し、Impellerは22.1msとSkiaに比べ7倍以上高速になっています。 体感でもカクつきが明らかに減っています。 しかし、なお60FPSを出すのに必要な16msを上回っています。 今回の計測はdebug buildなのでrelease buildにすればもっとパフォーマンスが良くなると思います。 # Skia flutter run # Impeller flutter run --enable-impeller 終わりに 今回は新たなシェーダーレンダリングエンジンのImpellerを試してみました。Impellerを用いることで、Skiaに比べ7倍以上のパフォーマンスが出ることを確認できました。ImpellerがStableになることを楽しみに今後のアップデートに注目します。 みなさんもFlutterで快適な開発体験を!! We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
はじめに こんにちは。サービスインフラチームの清水と申します。 ニフティではスクラム開発が様々なチームやプロダクトに導入されています。私も現在のチームに配属されてから開発メンバーとして4年ほどスクラム開発を行ってきました。 社内でスクラム開発を導入するチームが増えていく中、スクラムマスターも増やそうといった動きがあり、2021年12月、機会にも恵まれ Scrum Alliance 社主催の認定スクラムマスター研修に参加し、認定スクラムマスターの資格を取得することができました。以来チームのスクラムマスターとして活動しています。 今回は一般エンジニアがスクラムマスターになって、どんなことを考えながら取り組んでいるか、自分のケースを取り上げて学びや試行錯誤についてお話したいと思います。まだまだ新米スクラムマスターですが、少しでも参考になれば幸いです。 サービスインフラチームでは、ID管理・決済・サービス申し込みといったシステムの開発・運用を行っています。詳しくは 基幹システムグループ サービスインフラチームの紹介です – NIFTY engineering をご覧ください! チームを見つめ直そう まずは、スクラムチームがいまどのような状態かを見つめ直すことから始めました。 いち開発メンバーの視点から見ると、私の属するスクラムチームはうまく機能しているように感じていました。各種イベントの実施や定期的なリリース、イテレーションによるチームの成長……。しかし4年という歳月の間にはスクラムガイドの改定も行われ、メンバー間でスクラムに対する認識のズレが生まれていました。そして、メンバーにとって居心地の良い我流のスクラムとなっていきました。 もちろんスクラムガイドには具体的な方法が書かれていないので、チームにフィットするやり方でスクラムを適用するのはむしろ望ましいことです。しかし、私のチームには以下の問題がありました。 マネージャーがスクラムマスターを兼任しすべてやってしまいがち プロダクトオーナーが不在 マネージャーがスクラムマスターを兼任すると、メンバーに声が届きやすくチームビルディングが行いやすい反面、マネージャーに一極集中しやすいという問題があります。これについてはスクラムマスターの権限委譲をしてもらうことで形式上解消されました。その後自分がスクラムマスターとしてうまくチームを機能させられるかどうかについては別の話ですが……。 一方、プロダクトオーナーがいないという点について、これはスクラムガイドに則っていないチーム体制であり、メスをいれるべきものです。 以前よりビジネス部門と連携を取りながら開発を進めていましたが、開発者とビジネス担当者での1対1のコミュニケーションになりがちで、部署間のコミュニケーションにどうしても隔たりが発生していました。そして開発側の調整役はしばしばマネージャーであり、マネージャーがチームにビジネス側の要件を共有するという形になっていました。ビジネスの観点からプロダクトの成長について考えられる人がいない状態、といったところでしょうか。 スーパーマンのマネージャーによって決定や調整、問題解決が行われており、チームとしてうまく機能しているように感じていても、実際は自己管理の意識が弱かったのかもしれません。 スクラムについて学び直す場を設けよう 認定スクラムマスター研修の中で印象的だった話に、LeSS の創始者の1人であるクレイグ・ラーマンが提唱する「 ラーマンの法則 」というものがあります。 組織構造と文化に関する内容ですが、スクラムに当てはめてみると次のようになると言っていました。 「今やっている仕事をスクラムの用語で置き換えてしまい、本来あるべきスクラムチームの形ではなくなってしまう。」 私のチームも、スクラムに対する認識のズレを感じていたものの、それがチーム内の共通認識となっていました。研修でこの話を聞いたとき、まさに自分たちのことのように感じました。 そこで、改めてスクラムを学び直す機会を設けました。具体的には、改定後のスクラムガイドを読んでもらう、認定スクラムマスター研修で学んだ内容を「スクラム再入門」と題してチームメンバーへのアウトプットを行うなどです。 あわせてインプットも積極的に行いました。SCRUMMASTER THE BOOK やアジャイルレトロスペクティブズといったスクラム関連の書籍を読み、研修の内容と照らし合わせながら理解を深めるとともに、スクラム・アジャイル系の勉強会に参加して他社のスクラム事例やノウハウを学ぶ、といった具合です。 ただ、これらは一度やれば良いというものではなく、定期的に行うことが重要に感じています。単純にスクラムについての理解を深めるだけでなく、自分たちの都合のいいようにスクラムを解釈していないか?チームの組織構造はどうか?といった点に気づける機会にもなります。新しいメンバーがジョインしたら勉強会を開いたり、数ヶ月に1回スクラムガイドの輪読会を行うなど、慣れてきたタイミングで改めて学び直すようにしたいですね。 プロダクトオーナーを立てよう 私のチームの問題としてあったプロダクトオーナー不在問題を解消するべく、ビジネス部門の中で以前からメインにやり取りしている方にプロダクトオーナーの打診をしました。お願いをするにあたり スクラムの概要 プロダクトオーナーの役割 具体的にやってほしいこと を説明し、プロダクトのこれからについて一緒に考えていきませんか?といったことを伝えました。 スクラムの各種イベントに時間が取られたり新しい概念を取り入れる必要があるため、いきなりプロダクトオーナーの仕事をすべて任せるのは難しいと考え、まずはレビューやレトロスペクティブなどからイベントに参加してもらうなど段階的にチームにジョインしてもらうことにしました。 話を進めていくと、ビジネス部門も私たちが感じていた組織感でのコミュニケーションなどについて課題を感じていたことがわかりました。プロダクトのこれからの方向性やビジネス側のビジョンなどについても話したいと、ありがたいことにスクラムについて理解を示していただき、プロダクトオーナーも快諾していただけました。 まだプロダクトオーナーがジョインして時間もあまり経っていませんが、プロダクトオーナーの意見をもらえる場ができたことで、今まではなかったビジネスの視点についてチーム全体で考えられるようになっていると実感しています。 私のチームがそうだったように、ニフティの他スクラムチームもプロダクトオーナーが不在という問題を耳にします。ビジネス部門の中にはまだスクラムが浸透できていない部分もあるため、他チームのスクラムマスターと協力して組織の体制なども変えられるよう活動していく必要がありそうです。 スクラムマスターのスキルセットを意識しよう スクラムマスターに必要なスキルでよく言われるものとして、以下の5つがあげられます。 ティーチング ファシリテーリング メンタリング コーチング シチュエーショナリング いわゆるソフトスキルと呼ばれるものですが、エンジニアのキャリアとしてこうしたスキルに触れる機会が少なく感じます。それぞれなんとなく理解できるのですが、いざ実践しようとすると非常に難しく試行錯誤の連続です。 たとえばスクラムイベント1つを取っても、参加する側からファシリテーションする側になったことで、メンバーが発言しやすい場にするにはどうすればよいか考えなければなりません。また、タイムボックス内でスムーズにミーティングを終わらせるために、ミーティングの事前準備がいかに重要か身をもって感じるようになりました。 ほかにも、チームの透明性が担保されているか俯瞰して見る必要があります。今までは、自分たちが作る成果物 (ソースコード・機能など) について集中していましたが、チームが自己管理できている状態にあるのか、チームの障害となっているものは無いかなど、成果物だけでなくチーム全体を見るように意識が変わりました。 このあたりは新米スクラムマスターにとってはなかなか難しいと感じていますが、幸いチームにこういった視点を持ったメンバーがいるため、相談しながら考えることができており非常に助かっています。 今までとは違った能力が要求され大変なことも多いですが、その分今までとは違った分野での成長を実感しています。チームビルディングやマネジメントといった方向のキャリアパスにも興味を持ち始めてきました。個人の選択肢が広がったように感じます。 相談できる場を作ろう スクラムマスターはひとりになりがちです。問題に直面したとき常に明確な答えがあることは少なく、特に新米スクラムマスターは経験も浅いため、一人ではどうすることもできない状況がしばしばあります。 そのため、スクラムマスターとしての悩みを相談できる場を確保しておくことが重要です。 スクラムチームというとチーム内で完結してしまうようにイメージしがちですが、スクラムマスター同士のつながりは非常に大切で、スクラムマスターの協働によって組織が変わっていく、と研修で教わりました。 他のスクラムマスターの経験を知ることもまた自分の経験に繋がります。知り合いのスクラムマスターに相談するのも良いですし、社内外のスクラムコミュニティに参加して他チームの事例などを知るだけでも非常に学びがあります。 ニフティでは社内のスクラムマスターが集まって良かったことの共有や悩みを相談する「スクラムマスター共有会」というものが月に1度開催されています。私もこの会には非常に助けられています。自分の悩みを相談するだけでなく、他のスクラムマスターがどのような悩みを抱えているのかを知る機会にもなるため、ニフティのスクラムマスター全体として集合知、経験が培われる非常に良い循環となっていると感じています。 おわりに 約半年スクラムマスターを経験して感じたのは、これらは一朝一夕で習得できるものではなく、常に意識しながら実践と経験を積み重ねることで培われるということです。 スクラムが経験主義のフレームワークであるように、スクラムマスターもチームとともに経験して成長していくものだと感じました。 新米スクラムマスターの私の経験が、どこか他のスクラムチームの一助となれば嬉しい限りです。 We are hiring! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! ニフティ株式会社採用情報 Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! Event – NIFTY engineering
初めに こんにちは、インフラシステムグループの佐藤です。 皆様は問い合わせ窓口に電話をした際、オペレーターとのやり取りが長引きイライラする、といった経験はないでしょうか? 今回、受電時間を削減するために電話認証番号という仕組みを導入しましたので紹介します。 電話認証番号とは? こちらで告知されています↓ 会員サポート >「電話認証番号」による本人確認運用を開始 : @nifty 簡単に要約すると、 本人確認をIVR(自動音声応答システム)上で行うことで通話時間やオペレーターに繋がるまでの待ち時間を削減しよう という取り組みです。本人確認には事前に登録した4桁の番号を利用します。 既存の本人確認方法 氏名や生年月日、電話番号などを電話口でヒアリングして確認しています。 本人確認後、お客様情報を確認するWEBシステムから契約情報などを閲覧することで問い合わせの対応を行っていました。 IVR上での必要なフロー IVRに電話認証番号用のフローを作成、追加します。 必要なフローは下図の通りです。 電話認証番号の仕組みを導入しても、即座に全てのお客様が利用するわけではありません。 そのため、まずは電話認証番号を持っているか否かで分岐します。 持っていない場合は既存のIVRに復帰します。 持っている場合はそのまま自身の電話認証番号を入力し、認証を行います。 認証では下記のようなSQLを実行します。 SELECT [@niftyID] FROM [テーブル名] WHERE [登録されている電話認証番号] = '[入力した電話認証番号]' [登録されている電話番号] = '[架電している電話番号]' GROUP BY [@niftyID] @nifty IDが返ってくれば認証成功です。 認証に成功した旨のアナウンスを流し、@nifty ID情報を保持します。 認証に失敗した場合、もしくは一定時間電話認証番号を入力しなかった場合は認証に失敗した旨のアナウンスを流します。 その後、成功失敗ともに既存のIVRに復帰します。 オペレーター視点での挙動の違い IVRの終端ではアナウンス後切断するか、オペレーターに繋がります。 オペレーターに繋がった時、CTI連携を行います。 CTI連携とは電話とコンピュータを連携させることで、ニフティの場合はお客様情報を確認するWEBシステムページが起動します。 オペレーターはCTI連携後に電話口で本人確認を行い、お客様情報を検索して契約情報などを確認していました。 電話認証に成功した場合は、本人確認が取れた状態であるため、CTI連携時に@nifty IDのURLパラメータを追加した状態で起動します。 すると@nifty IDに紐づいた情報が表示されるため、オペレーターは初めからお客様の契約情報などを確認することが可能になります。 上図は実際に開くURLの例です。 右側のマスクされた部分に@nifty IDが入ります。 コールフローを作成する 前項までで電話認証番号を実現するために、電話システム上で必要な機能についてまとめました。 ここからは実際にコールフローを作成していきます。 コールフローとは、お客様からの入電を適切に振り分ける流れのことです。 ニフティではコンタクトセンターサービスとして、NTTコミュニケーションズの Arcstar Contact Center を利用しています。 ストラテジを作成する まずは、ストラテジという動作の骨組みにあたる部分を作成します。 下図は先ほどのフロー図での、[電話認証番号_認証]に該当するストラテジ例です。 ストラテジはウィザードというアイコンが結びついて構成されています。 内、下記の中央部分に絞って簡単に解説します。 まず、左のデータベースアイコンの部分でDBに接続、SQLを実行します。 実行に成功した場合は右の緑色、失敗した場合は下の赤色に分岐します。 緑色に進んだ場合は、クリップマークのアイコンにてSQLの実行結果を変数に格納しています。 格納したのち、矢印がクロスしているアイコンで変数を元に分岐させます。 分岐先のFアイコンでは、このストラテジが終了したとき、次に遷移する先を記載します。 上のFアイコンでは認証成功時の遷移先に、下のFアイコンでは認証失敗時の遷移先が指定されています。 値の定義 先ほどFアイコンで遷移先を指定している、と言いましたが、ストラテジはあくまで骨組みなので直接遷移先を記載してはいません。 今回の例では上のFアイコンは遷移先1、下のFアイコンは遷移先2を見に行く、といった形で記載されています。 そのため、実際の遷移先をリストにして定義する必要があります。 [〇〇窓口用の電話認証番号] 遷移先1=XXX 遷移先2=YYY [××窓口用の電話認証番号] 遷移先1=aaa 遷移先2=bbb その他にもアナウンス用の音声ファイルなど、固有のパラメータは同様に定義する必要があります。 利用時の流れ 全てのストラテジを作成、値を定義すれば電話認証番号用フローの完成です。 コールフローに電話認証番号用フローを追加すればそのコールフロー内で電話認証番号が使えるようになります。 電話認証番号を実際に利用する場合は、下記3ステップで行えます。 自身の@nifty IDに電話番号、電話認証番号を登録する 本人確認用の電話認証番号を登録したい Q&A(よくあるご質問) 登録した電話番号から架電し、電話認証番号を入力する オペレーターに繋がった際、電話認証が成功していれば自動的に本人確認が終了している 効果 現在スタートしたばかりのため効果は測定中ですが、一月当たり40万ほどのコスト削減を見込んでいます。 さいごに 今回は電話での受電時間を削減するための取り組みについて紹介しました。 ニフティに問い合わせの電話をかける際は、電話認証番号を登録してみてはいかがでしょうか?   # We are hiring ! ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です! ご興味のある方は以下の採用サイトよりお気軽にご連絡ください! [ ニフティ株式会社採用情報 ] Tech TalkやMeetUpも開催しております! こちらもお気軽にご応募ください! [ Event – NIFTY engineering ]