新着 の記事一覧

技術研究チームの活動の一環で、スクラムを体験するワークショップを開催しました。本シリーズではそれらの実施方法や様子をお届けします。第３回のテーマはピンポン玉を使ったスクラムワークショップです。 シリーズ一覧 https://developers.gmo.jp/technology/3750 https://developers.gmo.jp/technology/5571 ▻Vol.03_ｲﾏｺｺ https://developers.gmo.jp/technology/10479 https://developers.gmo.jp/technology/13055 はじめに みなさんこんにちは。成瀬（@nrslib）です。 前回はマインクラフトを使ったオンラインのスクラムワークショップについてお話しました。リモートワークなどでメンバーが遠隔地で分散されているチームがスクラムを学び始めるのに適したワークショップでしたね。 今回は時系列が前後しますが、レゴやマインクラフトを使った手の込んだワークショップを実施する前に、より簡易的なスクラムワークショップを実施したのでそちらをご紹介します。（ワークショップは2020年11月に実施したものです） 今回の題材は「ピンポン玉」です。 手軽にスクラムを体験したい スクラムは、見聞きした情報だけで実践するのは難しいです。各種スクラムイベントには一定の正解があるわけではなく、確固たる目的意識がないと趣旨を見失いやすいからです。 OJTと称して、実践しながら学ぶのもお勧めできません。多くのスクラムイベントは大抵１スプリントにつき１回です。スプリントは１週間や２週間といった期間になるため、それぞれがどういったもので、どういった立ち位置かを学ぶまで長い時間がかかってしまいます。 スクラムは百聞は一見に如かずという言葉が似合います。言うは易く行うは難しでもよいでしょう。座学で学ぶよりも、経験をしたほうが圧倒的に早く理解が進みます。そのため、ワークショップを実施するのがスクラムの理解や導入に役に立ちます。 本連載で紹介してきたレゴスクラムやマインクラフトスクラムはスクラムの理解や導入に最適ですが、その内容はとても重厚なワークショップです。レゴやマインクラフトなどの初期費用を無視したとしても、準備にかかるコストが高く、ワークショップを気軽に実施してみたい場合にはふさわしくありません。 私たちもスクラムのワークショップをするにあたって、どの題材がいいか調査しました。結果、「最初からレゴスクラムするのは得策でない」として、いくつか別の題材で実施してから、本格的なスクラムワークショップをすることにしました。 というわけで一番最初に実施することにしたスクラムワークショップのテーマは…… ピンポン玉です。 ピンポンゲームスクラム ピンポンゲームはピンポン玉を使った簡単なゲームです。そのピンポンゲームを題材にスクラムを体験するワークショップがピンポンゲームスクラムです。 ゲーム自体が単純なので、実施するのが難しくないワークショップです。 ワークショップ概要 ピンポンゲームはピンポン玉にメンバーが触れた数をスコアとするゲームです。ピンポン玉に触れるといっても、ただ触れればよいのではなく、ルールがあります。ルールは次の通りです。 チームメンバー全員が触れるボールは宙に浮かせて受け渡す それほど難しくないですね。これらのルールにしたがって、一定時間のうちにどれだけスコアを稼げたかを競うゲームです。 なお、私たちの実施したワークショップでは、これらのルールに加えて、次のルールを加えました。 最終的にピンポン玉をゴール（バッグ）に入れる 要するに「全員が手渡し以外でピンポン玉に空中で触れながらバッグに入れたら１点」です。 準備するもの ワークショップを実施するにあたって準備するものは次のとおりです。 ピンポン玉（１チームにつき１００個）バッグ・袋（１チームにつき２個） シンプルです。ピンポン玉の金額はピンキリですが、１セットにつき2,000円程度と思っておけばよいです。 バッグ・袋はピンポン玉が１００個入るサイズです。ピンポン玉に付属しているのであれば、もうひとつ大きめのバッグを用意するとよいでしょう。 設備 特別必要なものはありません。床さえあれば実施できます。 とはいえ、あるとベターといったレベルで設備を挙げるなら次のリストになります。 ホワイトボードプロジェクタ ホワイトボードはスコアの予測と結果を記入するために利用します。 プロジェクタはルール説明用資料投影とタイマーの表示に利用します。 参加者 ワークショップに欠かせないのが参加者です。このワークショップは予備知識が不要なので、だれでも参加できます。１チームにつき少なくとも３名程度が必要です。 今回はデヴェロッパータスクフォース（技術研究チーム、以下DTF）のメンバーと、システム本部の若手に参加してもらって実施しました。 ピンポンゲームに馳せ参じたメンバー ワークショップ解説 ワークショップを実施する際には、参加者に趣旨やルールを事前に説明します。 ワークショップは次のスプリントを繰り返します。 戦略を考え、スコアを見積もる（60秒）実行（120秒）スコアを計測・片付け（60秒）振り返り（60秒） 今回、私たちは５回実行しました。最低３回こなせば十分かと考えます。 なお、今回のピンポンゲームのスクラムワークショップはDTFメンバーの中川くんが企画してくれたので、彼が趣旨やルールを説明してくれました（成瀬は一般参加枠です）。 趣旨を説明する 戦略を考え、スコアを見積もる（60秒） ひとつのスプリントで最初にやることは、戦略を考えることです。 ピンポン玉片手に真剣に戦略会議を行う参加者 120秒という制限時間の中で、できるだけ多くピンポン玉を運べる方法について、メンバーで話し合い戦略を決定します。 戦略が決まったら、チームごとにどれくらいのスコアになるか予測をします。 それぞれのチームの予測 成瀬が所属した「Team Japan」は強気の120個予測です。実際、このときは完璧な作戦を考案したとメンバー全員が思っていました。 ちなみに100個すべて移し終わったら、元のバッグへ移していきます。バッグからバッグへ往復していくイメージですね。 実行（120秒） 実際に考えた戦略を制限時間の間、実行します。 「世界の高道」チームの初回実行の様子 「Team Japan」の初回実行の様子 画像でみるとそれぞれのチームの戦略の違いがみえますね。 なお、このとき、いくつまでスコアが伸びたのか把握する必要があります。ピンポン玉が足りなくなり、リユースする場合には正しくスコアリングするように注意しましょう。 スコアを計測・片付け（60秒） 実行が終了したらスコアを計測し、元に戻します。 片付けの様子 急いだり、作戦次第ではピンポン玉が床に散らばっていきます。このタイミングで元に戻して次のスプリントに備えましょう。 今回はバッグに移すと１点というルールがあるため、落としてしまったピンポン玉は加算しないようにしてスコアリングしていきました。 「Team Japan」は97個 我らが「Team Japan」の初回実行では、予測120個に対して97個と、かなり予測を外してしまいました。 「世界の高道」チームは80個 それに対して「世界の高道」チームは80個予測に対して実績80個と予測通りの結果でした。素晴らしいですね。初めて行う作業の見積もり予測は難しく、ほとんどの場合は正確でないので、かなり珍しいケースです。 振り返り（60秒） スプリントの最後には振り返りをします。 振り返りの様子 今回の実行でよかったこと、よくなかったことを短い時間で振り返りましょう。 私たち「Team Japan」も初回の戦略が最強に思えたのですが、実際にやってみると改善点が見つかって、どんどん戦略が変わっていきました。 既定の回数繰り返す これらの一連の流れを最初に決めた規定回数に達するまでくり返し実施します。 振り返りの実施 ワークショップが終わったら、ワークショップ自体の振り返りをしましょう。各チームがそれぞれの回でどのような戦略を立て、変化させていったかについて披露します。 振り返りの様子 このワークショップはスクラムよりも改善活動の重要性を体験するものなので、その点留意しながらしっかりと予測と作戦、振り返りの重要性を確認します。 ワークショップレポート すでに初回分についてはワークショップの解説の流れで紹介しましたので最終的な結果からワークショップのレポートをします。 最終スコア 各チームの最終的なスコアは次のようになりました。 最終的なスコア いずれのチームも初回以外はスコアを飛躍的に伸ばし、また安定しています。特に「世界の高道」のスコアは驚異的です。 このようにくり返し改善していくことで、同じ作業であっても効率が高くなっていくのがよくわかりますね。 ただ予測の精度はあまり向上しませんでした。これはどちらかというと、戦略を毎回変えていったため、「常に初めての戦略」をすることになったため、スコアが安定しなかったのだと考えます。 各チームの戦略 「世界の高道」チームの最終実行 「Team Japan」の最終実行 両チームとも最終戦略はピンポン玉を受け渡すというより、ピンポン玉を手に当ててバッグに流し込むという戦略です。奇しくも同じ戦略にたどり着いたようです。 こうなってくると大変なのは、正確なスコアリングです。もはや成功した数を数えるのではなく、落とした数を数えてたりします。実はこのスコアリングにも改善の力が働いていたのです。 所感 最初の戦略を練った時点で「最強の戦略」が生み出せたと思っていました。そのため、５回は多すぎると思っていました。これはほかの参加者も同じことを思っていたようです。 しかし、実際にやってみると改善できることは尽きることなく、それはそのままスコアに反映されていきました。 このように振り返りをすることで、各メンバーが実行中に感じた課題が共有でき、次の戦略に生かされるといったループが発生します。このカイゼンループは一度は体験しておくべきものでしょう。 反対に、本格的なスクラムを体験したい場合はこのワークショップは適していないと感じます。スクラムを体験するにはパーツを省きすぎているからです。 本ワークショップの立ち位置としては本格的なスクラムのワークショップを実施する前にコミュニケーションもかねて実施する試験的なワークショップの位置づけがよいのではないかと考えます。 おわりに 本ワークショップは正味１時間もあれば実施できます。かなり軽量なワークショップで気軽に開催できます。 チームに新たなメンバーが加入したときなど、オンボーディングをスムーズにする目的でもお使いいただけるのではないでしょうか。

GMOインターネットグループは、開発者向けテックカンファレンス「GMO Developers Day 2021」を、2021年9月16日（木）・17日(金)にオンラインにて開催いたします。今回のテーマは「Embrace change.」。"変化を楽しもう。あなたは必ず変化する。人は気持ちで変化する。"です。1995年に創業して以来、大切に受け継ぎ、培ってきた「スピリットベンチャー宣言」の一文です。世界が大きな変革を迎えている2021年、私たちGMOインターネットグループが取り組む事業やサービスは日々変化し続けています。最先端の技術とスピードをもって“自ら作る”ことにこだわる私たちは、エンジニア自身がその変化を楽しみ、常に新たな領域へのチャレンジを行っています。ご参加くださる皆さまの気持ちにもなにか変化が起きることを願っています。 開催概要 日時：2021年9月16日(木)～17日(木)時間：13:00-17:00場所：オンラインイベントサイト： https://developers.gmo.jp/developersday/ 参加方法 以下のページより事前にお申込みをお願いいたします。 ▼イベント詳細/申し込みはこちらhttps://developers.gmo.jp/developersday/ セッション一覧（一部抜粋） KEYNOTE ・GMOが考えるNFT革命・CTO対談 スピーカーセッション ・銀行APIトップランナーのGMOあおぞらネット銀行が見据える未来の金融・日本初SA方式ローカル5Gの舞台裏・GMOペパボのサービスと研究開発を支えるデータ基盤の裏側 トークセッション ・チームで取り組むサービス開発のフロントエンド・SREエンジニアが語る大規模サービスの裏側・ネクストリーダーズ～次世代を担うエンジニアたち～ ハンズアップセッション 今年から社内公募制度によるセッションを募集導しました。多くの応募の中から選ばれたセッションをハンズアップセッションとして公開いたします。 視聴特典 LIVEまたはアーカイブでセッションを視聴し、アンケートに答えてくださった方を対象に豪華景品が当たるキャンペーンをご用意しております。 さいごに みなさまのご参加、心よりお待ちしております！https://developers.gmo.jp/developersday/ 昨年の様子 https://developers.gmo.jp/665/

GMOペパボでは、「いるだけで成長できる環境」をコンセプトに、エンジニアの育成にも力を入れています。今回のイベントでは、これからエンジニアを目指している皆さんや、エンジニアとして働き始めた方などを対象に、異業種や未経験からペパボのエンジニアになったメンバーと、育成に携わるメンターが登壇します。 イベント概要 イベントタイトル：ペパボエンジニアとメンターが語る、「エンジニアとして働くということ」開催日：2021年8月26日（木）開催時間：19:00～21:00開催方法：オンライン問い合わせ先：GMOペパボ株式会社　福場麻美 ∞∞━━━━━━━━━∞∞━━━━━━━━━∞∞■イベント詳細・お申込みはこちらhttps://pepabo.connpass.com/event/221513/∞∞━━━━━━━━━∞∞━━━━━━━━━∞∞ タイムテーブル 19:00 オープニング19:05 理学療法士としてrails newしたあの頃 @k2_yoshikouki19:15 異業種からエンジニアになった僕が憧れの会社に飛び込むまで @r_nakamine19:25 学んだことに自信が持てなくて転職活動を始められなかった私の転職秘話 @mochi5o_maki19:35 一歩踏み出す @UsaMomokawa19:45 SIerから転職してきて良かったこと・大変だったこと @takapi8619:55 休憩 -20:00 Special talk @komagata /株式会社フィヨルド20:20 学ぶ場所としてのコミュニティ @june2920:40 エンディング20:45 質疑応答・相談会※任意参加 ∞∞━━━━━━━━━∞∞━━━━━━━━━∞∞■イベント詳細・お申込みはこちらhttps://pepabo.connpass.com/event/221513/∞∞━━━━━━━━━∞∞━━━━━━━━━∞∞ 登壇者 吉本 康貴@k2_yoshikouki コロナ禍真っ只中の2020年6月にGMOペパボへ入社、理学療法士からWebエンジニアへ未経験転職する。入社日前日には第一子の愛娘が爆誕。娘の年齢=エンジニア経験年数。CTO室 鹿児島エンジニアリングチーム所属。 仲嶺 良@r_nakamine Web制作、サーターアンダギー屋さん等さまざまな業種を経てエンジニアに転職。 Sierや飲食店向けのスタートアップで働いた後、2021年7月ペパボに入社。 現在は技術部プラットフォームグループに所属し、主にSREとしてカラーミーショップの運用に携わっている。 望月 眞喜@mochi5o_maki 小売業界・販売→医療法人・広報→船舶代理店・貿易事務といろんな業界や職種を経て2019年11月ペパボにエンジニアとして未経験で入社。 エンジニア転職のきっかけは広報時代にWeb制作に興味を持ってプログラミングスクールに通ったことから。 ペパボに興味を持ったのはDAIMYOエンジニアカレッジでペパボのエンジニアさん達と接して憧れたから。 現在ホスティング事業部CRチームでロリポップ！などのお問い合わせ調査や業務改善を行っている。 小松 ももか@UsaMomokawa 2018年8月、大学在学中にフィヨルドブートキャンプと出会い、2020年4月にペパボへ新卒入社。 技術部コーポレートエンジニアリンググループに所属。 髙橋 雄紀@takapi86 EC事業部ECグループDXチーム エンジニアリングリード 公共事業を手がけるメーカー系SIerを経て2016年10月にGMOペパボへ第一期ペパカレ生として入社。 現在はEC事業部のセキュリティ、レガシー環境の改善を担当しています。 大和田 純@june29 minne事業部シニアエンジニアリングリード。2015年6月入社にWebアプリケーション開発者として入社し、現在はエンジニアリング・マネージメント領域を担当している。趣味の活動として「おつかれシャワー」「キマグレエフエム」で動画や音声を継続的に配信中。 駒形 真幸@komagata 株式会社フィヨルドの代表兼プログラマー。Rubyが大好きで怖話、フィヨルドブートキャンプなどを開発している。 ＜Special Guest: 株式会社フィヨルド＞フィヨルドブートキャンプは、プログラマーとして就職を目指せるだけのスキルを身につけることを目標としたオンラインプログラミングスクールです。就職を目指せるスキルを弊社では「現場の人間にとって、戦力になるプログラマー」としています。具体的には、一人でWebサービスを作ることをゴールとした課題をやるのですが、それだけでなくチーム開発も経験できます。 ∞∞━━━━━━━━━∞∞━━━━━━━━━∞∞■イベント詳細・お申込みはこちらhttps://pepabo.connpass.com/event/221513/∞∞━━━━━━━━━∞∞━━━━━━━━━∞∞ さいごに たくさんのみなさまのご参加をお待ちしております！

こんにちは、GMOインターネットの吉田です。UI/UXディレクターのお仕事とプロジェクトの流れについて、引き続き連載でお伝えしていきます。 プロジェクト全体の流れ 前回エントリーでは、「企画/調査」フェーズまでをご紹介しました。 何を開発して誰にどんな風に使ってもらうのか、少しずつ作るものの全容が見えてきたところです。 それでは続きのフェーズを解説していきます。 要件定義 「要件定義」のフェーズでは、「企画/調査」フェーズを元に開発する内容を資料にまとめます。 開発する内容がだいたい固まってきたところで、プロジェクトメンバーを募ってキックオフMTGを開催するので、参加者とプロジェクトの概要について認識合わせをするための資料づくりというイメージです。 要件定義の資料には、主に以下を記載します。 開発の背景や目的解決すべき課題ターゲット期待効果開発の概要や要件スケジュール GMOインターネットは事業会社なので、企画から開発まですべて社内で完結します。そのため、一般的な「要件定義」の内容とは少し異なるかもしれません。開発仕様の詳細についても「要件定義」の段階では確定している状態ではなく、次の「設計」フェーズで開発メンバーと一緒に議論しながら検討を進めていくことが多いです。 ちなみにGMOインターネットには「手をあげる」文化があるので、希望者は社歴や経験は問わずプロジェクトに参加できます。入社1〜2年目でも、比較的大きなプロジェクトを任せてくれるので、積極的にチャレンジしていきたいですね。（もちろん先輩社員がちゃんとバックアップしますよ！） 設計 「設計」のフェーズでは、具体的な開発の仕様を検討します。大きく分けると「機能設計」と「画面設計」があります。 「機能設計」には、API設計、ファイル仕様、DB設計などが該当しますが、基本的には開発エンジニアのメンバーを中心に検討を進めてもらいます。 「画面設計」では、主にUI設計をしますが、まずディレクターがワイヤーフレーム、モックアップ、プロトタイプを作成します。ディレクターの草案を元に、さらにデザイナー、開発エンジニアと議論しながら詳細な仕様を決めていきます。 Adobe XDで作成したモックアップの例 画面設計時の使用ツールは、「Adobe XD」をメインに使っています。 「Adobe XD」は、作成した画面イメージをかんたんに共有しやすい点が便利です。プロジェクトの規模や内容によって、その時に合ったツールを選択しているので、過去にはmoqups、Skecth、Figma、InVision...なども使用していたことがあります。 また、画面設計をするうえで「企画/調査」フェーズで作成した「ペルソナ」がとても役に立ちます。（ペルソナの詳細はUI/UXディレクターのお仕事とプロジェクトの流れ Vol.1を確認してください。）例えば、クリックして別のページに遷移するUIを検討する場合、お名前.com のペルソナは、「比較的年齢層が高めでITスキルは低〜中程度」を考慮して、アイコン表示だけではなく、アイコンとテキストを表示して何の機能なのかを認識しやすいようにしています。 評価 「評価」のフェーズでは、「ユーザビリティテスト」を実施します。「ユーザビリティテスト」とは、ユーザーが迷わずにタスクを完了できるか観察するもので、Adobe XDで作成したプロトタイプを使います。テストで課題が見つかると、改善→テスト→改善→テスト…を繰り返します。 Adobe XDで作成したプロトタイプの例 GMOインターネットでは、基本的に社内の人にテスターとして参加してもらい、テストを実施しています。（リサーチ会社を使って、テスターをリクルートする場合もあります。） 「テストはリリースしてからやればいいのでは？」と思うかもしれませんが、開発実装する前の段階でテストすることがとても大事です。 一般的にテストを2回実施することで不具合を50%軽減できる。と言われていて、テストすることで開発の手戻りを防ぐことができます。また、検証フェーズでは機能の不具合を見つけることができますが、ユーザビリティの問題を解決するのは難しいです。自分たちが設計した画面でお客様が迷わず操作できるかどうかの確認をするためにも、評価フェーズの段階でユーザビリティテストを実施することが重要です。 おわりに 次回いよいよ怒涛の「開発」フェーズに入ります。ディレクターは開発作業はしないですが、開発段階で色々な問題が判明することが多く...実はけっこう忙しいフェーズです。 続きはまた次回のブログで！ 連載記事はこちら https://developers.gmo.jp/technology/9080 https://developers.gmo.jp/technology/11603 https://developers.gmo.jp/technology/12838

こんにちは、GMOインターネット株式会社の斉藤です。OpenStackでは拙作のnovasshというツール使うと、IPアドレスの代わりにインスタンスにつけたネームタグ(名前)で接続することができます。OpenStackをベースにしているConoHaでも使えますので、今回はこれをご紹介したいと思います。 はじめに クラウドなどを使ってたくさんのインスタンスを立てると、ssh接続するときに「あれ？サーバーのIPなんだっけ？」となったりします。普通はWebの管理コンソールなどにログインして確認するか、APIを叩いて調べたりします。 ただ、とくにAWS方面ではec2sshなどの便利ツール/スクリプトがすでに多くあります。これらのツールを使うと、IPアドレスが不明でもサーバーの名前でssh接続ができます。 Amazon EC2インスタンスに簡単にSSHできるようになるツールec2sshを公開しましたec2sshとpecoでsshログインを楽しもうGoで複数のAWSアカウントの全リージョンのEC2の情報をもってくるコマンドを書いた 一方で、OpenStackでは拙作のnovasshというツール使うと、IPアドレスの代わりとしてインスタンスにつけたネームタグ(名前)で接続することができます。 hironobu-s/novassh: A client program that connects to OpenStack(Nova) instance.https://github.com/hironobu-s/novassh デモ インスタンスにSSH接続する pecoと組み合わせる 使い方 OpenStack環境か、OpenStackベースのパブリッククラウドで動作します。簡単に試すならConoHaが良いでしょう。https://www.conoha.jp/ 1. novasshのインストール GitHub releaseからバイナリをダウンロードして使います。以下をご覧ください。 インストール方法 2. インスタンスに名前をつける インスタンス名の付け方は以下のような感じで。 自前OpenStackの場合はInstance Name インスタンス起動ダイアログの「Instance Name」で指定します ConoHaの場合 サーバー作成画面にある「ネームタグ」で指定します。 3. 認証情報の設定 環境変数にOpenStackの認証情報を設定します。 export OS_USERNAME=[username] export OS_PASSWORD=[password] export OS_TENANT_NAME=[tenant name] export OS_AUTH_URL=[identity endpoint] export OS_REGION_NAME=[region] この環境変数名は、オフィシャルのCLIツールなどでも使われていてオープンスタッカー御用達です :)https://wiki.openstack.org/wiki/OpenStackClient/Authentication 4. インスタンスに接続する novasshの基本的な使い方は、以下のようにインスタンス名を引数に渡すだけです。 novassh [instance-name] 基本的にsshコマンドのラッパーなので、ユーザー名の指定やオプションの指定なども同じようにできます。 novassh username@instance-name ポートフォワードする場合 novassh -L 8080:internal-host:8080 username@instance-name その後接続が確立したら通常のsshと同じように使うだけです。 4-2. シリアルコンソール接続を使う OpenStackはインスタンスへのシリアルコンソール接続をサポートしています。コンソール接続は仮想マシンのシリアルコンソール端末に直接接続されるため、インスタンスをリブートしても接続が切れたりせず、OSのブートシーケンスなども確認できます。カーネルをいじったりするときに便利です。 使い方は--consoleオプションをつけるだけですが、OS側でシリアルコンソールが有効になっている必要があります。最近のUbuntuやCentOSはデフォルトで無効になっているので個別に有効化する必要があります。 novassh --console [instance-name] 接続に成功すると、以下のようにOSのログインプロンプトなどが表示されます。接続を切る場合はCtrl+[ qと入力します。 # novassh --console ubuntu-dev Connected. Type "Ctrl+[ q" to disconnect. 接続を切る場合は Ctrl+[ q と入力して下さい Ubuntu 15.10 personal ttyS0 ubuntu login: おわりに novasshは日常的なsshコマンドの代わりに使える便利なツールです。OpenStackの環境でサーバー管理などをされている方はぜひ使ってみてください。 ソースコードはGitHubにあります。 hironobu-s/novassh

こんにちは。GMOインターネットの平山です。本エントリーでは、弊社で取り入れている新卒研修のカリキュラム、CS（カスタマーサポート）研修（以下CS研修）について簡単なレポートとCS研修の必要性について紹介していきたいと思います。 はじめに 過去GMOインターネットではビジネス職、エンジニア職関係なく、新卒メンバーの研修カリキュラムにCS研修を組み込んでいました。近年、さまざまな事情で開催できずにいましたが、2021年約5年ぶりに実施いたしました。 2021年度カスタマーサポート研修について 今回のCS研修は実際に対応いただいている東京拠点、仙台拠点の2拠点で開催しました。 緊急事態宣言中ではありましたが、出発前、帰着後のPCR検査、現地での感染対策の徹底を行い、全員感染なく研修を終えました。 CSのおもな業務内容 アウトバウンド：主に契約獲得などの営業的要素インバウンド：お客様からの入電からお困りなことや各種手続きの案内を行うなどのサポート的要素 研修の目的 CS研修の主な目的は以下です。 お客様の声を直接聞くことで温度感や細かいニュアンスを知る開発チームとは違った視点を得ることで担当するサービスの全体を把握する 研修の内容 今回の研修期間は2週間で、弊社で提供している「GMOとくとくBB」の本契約を獲得するための架電業務（アウトバウンド）を実際に行ってもらいました。 事前の座学研修やお客様を想定した電話対応の練習（ロールプレイング）を一生懸命している姿が初々しかったです。 目標設定 ただ電話を掛けるいう作業にならないよう、研修ではあるものの責任をもって業務に携わる姿勢を持っていただくため、目標を決め取り組んでもらいました。 獲得率「90%」と目標を設定し、結果は見事「93.5%」と目標を達成してくれました！ 研修が始まった当初はすごくおどおどした表情だった新卒のみんなが研修後半にはすごく凛々しい表情をしていて、成長を感じました。 研修をしていただいた、東京、仙台の両拠点のCS担当者のみなさん、ありがとうございました。 なぜエンジニアにとってカスタマーサポート研修が必要か？ 簡単ではありましたが、研修レポートはここまでとし、ここからが本題。なぜエンジニアにとってCS研修が必要なのか？を私なりに解説したいと思います。 そもそもCSという業務とエンジニアの開発業務がどのようなフローでサービス改善に結びつくのかを以下フローにてまとめておきます。 CSでの業務がエンジニアの開発業務に密接であることは、フロー図からも理解できると思います。私の考えるカスタマーサポート研修の必要性3点は以下です。 1．お客様からの生の声が聞けるチャンス これはカスタマーサポートでしか得られないことですね。お客様がどんなことに困っていたり、弊社のサービスを使ってどんなことをしたいのかなどを聞くことができます。また同時にお客様が抱えている「真の問題」を聞くための傾聴力や論理的思考も必要になります。 2．エンジニアとカスタマーサポートは密接な関係性 弊社だけに限らず、多くの企業もエンジニアとカスタマーサポートは密接な関係だと思います。 お客様の声をダイレクトに聞けるカスタマーサポートが得た情報をエンジニアにフィードバックしてサービスの改善や新サービスを作る際のヒントにしたりなど、お客様の声というのはサービスの質向上のための改善などで活用させていただいています。 エンジニアとカスタマーサポートというのは相互に理解し、「真の問題」に同じ目線で向き合い、話し合いができないと、フィードバックも弱くなり、結果としてよいサービスが作り上げることが難しくなると考えます。 3．サービス開発に活きる経験 前述した1,2の集大成とも言えるべき内容ですが、自身が主力となりサービスを開発する時に、お客様の目線というのが必ず必要になります。作り手であるエンジニアがお客様目線を持ってサービスを作ることで、いいサービスが出来上がり、結果としてお客様の笑顔を増やすことができるのです。 カスタマーサポートにおいてお客様の声を直接聞くことができる機会を経験することが、開発業務に従事する際に必ずプラスになると確信しています。 まとめ 今回は普段のエンジニアの業務とは少し視点を変えた内容になりましたが、エンジニアがカスタマーサポート研修を受けることについて、私はとても意義があると考えています。 サービス開発、機能やUIの改善の目的はお客さまが使いやすいもの/求めていることが大切です。 その意見やフィードバックに耳を傾け、改善を実現するために思考することができるエンジニアこそ市場価値の高い人財になりえるからです。 我々北九州のほか、宮崎、仙台などサービス開発に関わる部門が多拠点化していいます。顔も知らない人とのコミュニケーションが増えていく中、このように新卒の早い時点で直接お客様の現地へ赴き、コミュニケーションの向上を行うことの重要性も改めて感じました。 今回、実際に引率をさせてもらいましたが、私自身改めてカスタマーサポート研修の重要性を再認識しましたので、来年も開催できればと思っております。

FPGAに機械学習モデルを順序回路として実装し、パイプライン化しています。性能向上にはつながりませんでしたが、同期動作で扱いやすくなりました。詳細は下記内容をご覧ください。 順序回路化・パイプライン化 以前の記事で実装したランダムフォレスト回路を順序回路化・パイプライン化します。 https://developers.gmo.jp/?p=10086 結論から言うと、性能向上には繋がりませんでしたがクロックに同期して動作することで扱いやすくなりました。 入力が変化すると即座に出力を変化させる組み合わせ回路としてランダムフォレストを実装しました。しかしこの方法では木の深さが深くなったり、分岐条件が他ビットになったりすると遅延が大きくなります。こうなるとランダムフォレスト回路を制御したり結果を使用して処理をしたりする回路との連携が少々厄介になります。多くのシステムはクロックに同期して動作する順序回路ですから、ランダムフォレスト回路もこれに合わせたほうが都合がよさそうです。 ランダムフォレスト回路を順序回路として実装 今回はランダムフォレスト回路を順序回路として実装します。さらにスループットを向上させるためにパイプライン化を試みます。

FPGAで機械学習の推論部分を高速に処理する方法を調べた結果、シンプルなサンプルコードは存在しないことが分かりました。そこで、HDLを使ってランダムフォレストをFPGAに実装しソフトウェアと比較しております。詳細な検証方法や使用した環境は下記内容をご確認ください。 FPGAに機械学習モデルを実装する方法とは 「FPGAに機械学習の推論部分を実装し高速に処理を行う」という技術は耳にしたことがありましたが，漠然としたイメージがあるだけで実際にどのように実装していくのかということは知りませんでした。調べてみると，高位合成を用いた手法や，学術研究として開発されたアクセラレータとしてのアーキテクチャは存在するようですが，シンプルなサンプルコードの形で存在するものはないようです。 検証 今回はHDLを使って機械学習モデルをFPGAに実装することにしました。まずはシンプルに定番の「ランダムフォレストを用いたMNIST手書き文字のクラス分類（画像の手書き文字を当てる）」をFPGAに実装して推論を行い，ソフトウェアの実装と比較してみます。結果を先に書くと，組み合わせ回路を用いたランダムフォレストの推論器をIntel Cyclone Vにて120個のALMで実装でき，入力・出力間の遅延（処理時間）は約22ns（ソフトウェアは1.4ms）となりました。 検証に際して用意した環境は以下です。 FPGAボード：Terasic社　DEO-CV / Intel Cyclone V E 5CEBA4F23C7NFPGA開発環境：Quartus Prime Lite 20.1FPGA開発言語：Verilog HDLシミュレータ：ModelSim Intel FPGA Starter Edition 2020.1PC:CPU AMD Ryzen 7 1700x / RAM 32GB / SATA SSDソフトウェア・ライブラリ：Windows 10 / Python 3.6.2 / scikit-learn 0.23.2 では実際にどのように検証したのか詳しくみていきましょう。 続きはこちらから…… https://developers.gmo.jp/technology/10288

これまで紹介してきた、Power Automate、Power Automate Desktopは日常の業務を効率化するためのフロー作成ツールとしてとても安価で優れた機能を提供しています。フローを作成する以外にも、Power Automateにはフローを管理や共有するための様々な機能も用意されています。個人レベルの業務でフローを活用することによって確実に効率化の効果は期待できます。それ以上に企業においては組織的にフローを活用することで、より大きな効果が期待できるのです。開発したフローを効率的に管理して、様々な場所や部署で稼働させるにはフローの共有が有効です。今回はTipsの一つとしてPower Automate、Power Automate Desktopのフローの共有方法を紹介してゆきます。 Power Automate クラウドフローの共有 まずはPower Automateクラウドフローの共有方法です。4つの共有方法を紹介します。 「所有者」として共有 所有者として共有したいメンバーを追加することで、実行だけでなく、フローの編集も可能になります。Power Automateのフローの管理から「マイフロー」を選択して共有するフローを選択します。もしくは、カーソルをフロー上に移動して「共有」を選択します。 「所有者」-「編集」を選択します。 所有者に共有するメンバーのアカウントを追加します。 所有者として追加するためフローと接続に対してのすべての権限が割り当てられるという注意が表示されます。 共有されたユーザー側で確認すると、「マイフロー」-「共有アイテム」内に所有者として追加されたフローが確認できます。共有元では、「クラウドフロー」から「共有アイテム」にフォローが移動しています。 所有者からユーザーを削除することで、共有を停止できます。 所有者を削除しても、フォローは「共有アイテム」内に残ります。このままでも動作に支障はありませんが、「クラウドフロー」に戻したい場合は、「名前を付けて保存」を選択して別名で「クラウドフロー」内に保存します。コピーとして保存後、「共有アイテム」内のフローを削除して、元の名前に変更する必要があります。 コピーしたてのフローは“オフ”状態となっているので、“オン”にして有効にしておく必要があります。 「実行のみのユーザー」として共有 先ほどの所有者としての共有とは異なり、実行のみ許可されたユーザーとして登録してフローを共有する方法がこちらになります。ただし、こちらの共有方法が利用できるのは手動で実行する“インスタントクラウドフロー”だけに限定されています。 フローの管理メニューから「実行のみのユーザー」の編集を選択します。（“インスタントクラウドフロー”以外は「実行のみのユーザー」メニューが表示されません。） 共有するユーザーを登録します。画面下の「保存」を選択します。 「実行のみのユーザー」として登録されました。 登録されたユーザー側ではメールが確認できます。フローを実行するには「Get Button」を選択します。 Power Automateのフロー管理画面が表示されるので、「続行」を選択します。 「フローの実行」を選択します。 フローが実行されました。 「実行のみのユーザー」として共有されたフローは「マイフロー」には登録されません。毎回先ほど届いたメールから起動することになります。共有元のフローも「共有アイテム」とはならず、元のまま「クラウドフロー」内で確認できます。 共有元の「実行のみのユーザー」からユーザーを削除することで共有が解除されます。 エクスポートして共有 クラウドフローは共有方法の1つとして、パッケージファイルをzip形式で保存することがきます。保存したパッケージファイルはインポートして再利用が可能です。フローの編集から「エクスポート」-「パッケージ（.zip）」を選択します。 パッケージの詳細を入力して「エクスポート」を選択します。 共有するユーザー側の「フローの管理」から「インポート」を選択します。 はじめてインポートする場合は操作アイコンを選択して、「インポートの設定」で“新しく作成する”を選択します。 こちらの内容でインポートを実行します。 インポートされました。直後は“オフ”になっているので“オン”にして実行できるように設定しておきます。 コピーの送信で共有 コピーの送信はメールに添付する形式でフローを共有できます。 フローの編集から「コピーの送信」を選択します。 タイトル、説明（25文字以上）、送信先を設定して送信を実行します。 送信されたユーザー側ではメールが確認できます。「マイフローの作成」を選択します。 テンプレートとして共有されているので、「フローの作成」を選択します。 フローが作成されました。 コピーを送信されたフローは、送信元と受信側の両方での「テンプレート」-「自分と共有」で確認することができます。 送信元からこのテンプレートを選択して削除することが可能です。 テンプレートとして送信で共有 「コピーの送信」はプライベートなテンプレートの送信といった感じの共有方法でしたが、「テンプレートとして送信する」はPower Automateのパブリックなテンプレートとして登録して、フローを共有する方法となります。 この方法はPower Automateのギャラリーで承認された場合にテンプレートとして掲載されることになります。 フローの編集から「テンプレートとして送信する」を選択します。 必要な情報を入力して送信を実行します。 （テストなので実行していません。） 承認されればこちらのテンプレートに掲載されフローが共有可能となります。 Power Automate Desktop　デスクトップフローの共有 次にPower Automate Desktopデスクトップフローの共有方法です。2つの共有方法を紹介します。 共有する相手の追加 デスクトップフローの共有設定は、インストール版のPower Automate Desktopからでは設定できないようになっています。Microsoft365にログインして、Web版のPower Automateの管理画面から、「マイフロー」-「デスクトップフロー」を選択して、共有するデスクトップフローを選択します。 「共有する相手」から「アクセス権を管理する」を選択します。 共有するユーザーを追加します。 アクセス権として、実行権限のみの“ユーザー”もしくは、管理権限を持つ“共同所有者”のいずれかを選択して共有を実行します。 共有されたユーザー側で確認すると、デスクトップのアプリケーションからでも「共有アイテム」として確認することができます。実行ユーザーとして共有されたので、フローの編集自体はできなくなっています。 共有した側のWeb版のPower Automateの管理画面とPower Automate Desktopアプリケーションの共有アイテムには共有されているはずのデスクトップフローは確認できませんでした。 コードのコピー＆ペーストで共有 デスクトップフローはコピー＆ペースでコード自体をテキストで取得することができるようになっています。この特徴を利用してメモ帳やメールにコード自体をテキストで張り付けてデスクトップフローを共有することが可能となっています。 Power Automate Desktopアプリケーションから共有するフローを選択して、コードを表示します。 “Ctrl+A”でコードすべてを選択して、“Ctrl+C”もしくはマウスの右クリックメニューで「コピー」を選択します。 メモ帳などに張り付けるとデスクトップフローのコードが取得できます。 共有される側のPower Automate Desktopアプリケーションからフローの新規作成を選択します。 空白スペース上で“Ctrl+V”もしくはマウスの右クリックメニューで「貼り付け」を選択します。 フローが張り付けられました。 このまま共有されたフローを利用できるようになりました。 フローの共有方法のまとめ Power Automate クラウドフロー 共有方法保存場所所有者として追加するマイフロー　－　共有アイテム実行のみのユーザーとして追加する（インスタントフローのみ）メールエクスポート　/　インポートマイフロー　－　クラウドフローコピーの送信テンプレート　－　自分と共有テンプレートとして送信する（承認された場合）テンプレート Power Automate Desktop デスクトプフロー 共有方法保存場所共有する相手を追加する（ユーザー or 所有者）Power Automate Desktopアプリケーションの共有アイテムコードのコピー＆ペーストマイフロ―　－　デスクトップフローPower　Automate Desktopアプリケーションのマイフロ― 以上が、Power AutomateとPower Automate Desktopのフロー共有方法となります。 企業内で開発されたフローを有効的に共有することによって、開発効率のアップにつながります。また、共有によるフローの集中管理を実現することで、メンテナンス性のアップやセキュリティー対策にも役立てることが可能です。個人の利用においても、デスクトップフローはテキストベースでのコピー＆ペーストが可能なので、手軽に共有することが可能です。開発テクニックの共有もつながりますので個人レベルでのスキルアップにも十分役立てることができます。 このように、Power Automateには様々なフローの共有方法が用意されているので、利用用途によって使い分けることがフロー活用の重要なポイントなります。

こんにちは、GMOインターネットの稲守です。新卒技術研修「GMOテクノロジーブートキャンプ（以降GTB）」についてお届けします。前編の記事では8年目となった本研修の企画概要や二度目となる完全オンライン研修の課題解決などをご紹介しました。後編となる本記事ではその成果などをお伝えしようと思います。 アウトプット開発の様子 前編記事の通り、本研修では幅広い知見を得てもらうため幅広いカリキュラムを実施しています。最終週にはアウトプット開発と題し、チームごとにプロダクト開発を行ういわゆるハッカソンを実施しています。 今年の特徴としては全チームが短い期間で動作するアプリケーションを完成させたということです。例年では何チームか実装で苦戦した結果、動作しないで最終日を迎えることがままありましたが、本年度に関しては全チームがゴールし、開発を完遂させました。 https://developers.gmo.jp/technology/9088 成果物プレゼンテーションの様子 アルゴリズムによるチーム分けの成果 新卒パートナーたちが各種研修でインプットしたものをアウトプットしてもらうことをゴールとし、チームバランスに偏りが少ない最適なチーム分けになることを狙ったアルゴリズムによるチーム分けを本年度から採用しました。チーム分けの詳細については以前の記事を参照ください。 https://developers.gmo.jp/technology/6894 結論から話すとアルゴリズムを活用したチーム分けについては、前述のとおり全チームが実装まで完遂したことも含めて成功したと思います。 前提として以下の成果、事実があります。 全チームが動作するプロダクト(アプリケーション)を作り上げ、目的達成ができたチームによってはUIデザイン職等を専攻するメンバーが居ないチームがあったが課題解決しフロント実装まで仕上げている成果物の審査は、成果発表会に参加した開発メンバーや事務局メンバーを含む数十名による審査を行い偏りの少ない審査を実行 考察としてアルゴリズム自体が最終的な成果物に大きな影響は与えず、各メンバーの「成長」「チームワーク」など数値化されにくい部分が影響を与えたのではないかと考えています。 成果 優秀賞の紹介 優勝チームのアウトプット作品は、ブラウザ上で動作するチャットアプリケーションでした。また2位のチームもプレゼンを盛り上げるアプリケーションで、リモート時代におけるコミュニケーション課題が成果に繋がったようです。オンライン上での限られた環境における開発でしたが、様々なコラボレーションツールを活用することで、互いにコミュニケーションをとりながら開発を進め、見事に優秀作品として選出されました。 匿名チャットサービス「Lively」画面キャプチャ 開発の進め方や、工夫したポイントについては優勝チームのメンバーが記事を書いています。ご興味のある方はぜひご一読ください。 匿名チャットサービス「Lively」を新卒研修で開発しました【GMOテクノロジーブートキャンプ参加レポート】 アウトプット作品ブログ 最優秀作品以外のアウトプット作品についても以下にてレポートしております。 忘れ物防止アプリ「Prepasy」をゼロからつくる【GMOテクノロジーブートキャンプ参加レポート】 エンジニアの話す難しい専門用語を音声から自動翻訳する「エンジニンガル」の開発【GMOテクノロジーブートキャンプ参加レポート】 さいごに 各チームが開発をゴールまでもっていくことができたことはもちろん、クオリティの高いアウトプットに仕上がっていることを嬉しく思っています。 一方で順位付けをしますので悔しい結果になったチームがいたことも事実です。新卒研修を実施した時期における瞬間を審査員によって順位付けをしましたが、あくまでも新卒1年目の春の一瞬を切り取った順位であり、本当のゴールは数年後の努力の積み重ねではないでしょうか。 当社グループに入社いただいた新卒パートナーの皆さんをはじめ、私自身も初心忘れるべからずだということをここに記しておこうと思います。今後も研鑽を積み重ね、社会に役立つプロダクト開発を今後も続けていきたいと思いを馳せたところで今回のエントリーを締めたいと思います。