技術情報 の記事一覧

これまで紹介してきた、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年目の春の一瞬を切り取った順位であり、本当のゴールは数年後の努力の積み重ねではないでしょうか。 当社グループに入社いただいた新卒パートナーの皆さんをはじめ、私自身も初心忘れるべからずだということをここに記しておこうと思います。今後も研鑽を積み重ね、社会に役立つプロダクト開発を今後も続けていきたいと思いを馳せたところで今回のエントリーを締めたいと思います。

こんにちは。デベロッパーリレーションズチームの村上です。今回は私のチームで行っているリモートでのコミュニケーションについて紹介していきます。昨今リモートワークされるエンジニアの方も多いと思いますので、同じような環境で行き詰ったかたの参考になれば幸いです。 はじめに 前回のブログでは、リモートワークで活用しているツールについてご紹介いたしました。 https://developers.gmo.jp/technology/9568 今回は、リモート環境におけるコミュニケーション方法にフォーカスしてお届けしたいと思います。リモートワークが浸透する一方で、圧倒的に課題としてあげられることが多いコミュニケーション不足。 これは、弊社内でも同様に起きている問題でした。今回は実際にわたしたちのチームで発生した事象とその解決方法についてご紹介いたします。 リモートコミュニケーションについて 元々わたしが勤務しているkitaQでは、全社的にリモートワークが推進される前から、東京～北九州の間でチームを跨いで開発をしていた為、ある意味日々リモートワークのような状態ではありました。 オフィスでは常時接続用のiPadが数台あり、気軽に東京側のエンジニアに声を掛けてコミュニケーションを取ったりしていました。その為、全員が在宅でのリモートワークになっても、そこまで大きな問題は起こらないだろうという想定でした。 発生する課題 ところが、実際に在宅でのリモートワークが始まると課題となるところがいくつも出てきました。 パートナーとの雑談が激減カメラ越しだとその人のコンディションが把握できない在宅が続くことでのモチベーション低下さまざまな要因から作業効率が落ちてしまうパートナーが出てきてしまう オフィスである程度パートナーが固まって業務をしていたときと、確実に状況が違いました。このままではよくないと思い、これまで以上にヒューマンマネジメントにリソースを使っていくことにしました。 マネジメントへの負担増 私はマネージャーとしてマネジメントを主な業務としていますが、もちろん合間で開発作業を行っています。これまではパートナーへの声掛けがしやすいオフィスだった為、開発とマネジメントのバランスが取れていましたが、マネジメントのウェイトが増えてしまい開発作業にも影響がでてきました。これではまずいと思い、チームの再編を含めマネジメントのやり方を見直していくことに決めました。 リモートコミュニケーションの課題解決 課題がわかっているのであれば、解決すれば良い！ということで、以下で紹介するようなやり方を試していくことにしました。 1on1の機会を増やす まずはパートナーと1on1で雑談や相談をすることにしました。 全員が繋がっている場では出にくかった相談や、雑談ができることでパートナーの調子も少しだけ良くなったように感じます。ここで相談されたことは積極的に解決していくようにして、次の1on1で悩み事が解決できているかを確認していきました。 最初はなかなか話題が出てこなかったりしましたが、繰り返し行っていくことでパートナーから話題を振ってくれることも増え、相談してもらえるようになってきました。 みんなが集まる場でのファシリテーション コミュニケーション量を増やす為に、朝会に加えて夕会やチームキープの時間を取るようにしました。ただ集まるだけではパートナー同士でのコミュニケーションは生まれません。なので雑談をベースに話題を振ってパートナー同士のコミュニケーションの促進を行いました。 最初は私が1人で喋ってるだけ（笑）でしたが、しだいに話に乗ってきてくれて有意義な時間を作れたかなと感じています。 負担の少ない常時接続環境 在宅でのリモートワークが始まって一番不安だったのが、在宅だと中々作業効率が上がらないのではという問題でした。 最初は、常に顔を見れる環境が良いと思い、パートナーには常にカメラONで常時接続の環境を作ってもらっていました。ただこれに関しては結構負担に感じているパートナーもいたようで、四六時中見られている感覚があって嫌だったという意見もありました。とはいっても、どんなことが課題になっているのか、即時対応できない環境においては、マネジメントする立場の自分がとても不安でした。 ということで、最終的に行き着いたコミュニケーション方法が、Discordを利用して常時接続してもらうことです。 最初はZoomのカメラOFF運用をしていたのですが、他のチームとのコミュニケーションも課題になりつつあったので、Discordを複数のチームで運用することにしました。Discordだとどこに誰がいるかというのが、かなりわかりやすくなりました。ミーティングも、顔をみて話をしたい時はカメラONにして話すか、Zoomに移動して行うことで、パートナーや私の負担が少なく常時接続環境を用意することができました。 オンラインでできるコミュニケーションタイム 最近取り組んでいるのですが、仕事以外にもなにかコミュニケーションが取れるようにしたいという思いと、相手に対してうまく伝える力を養ってほしいという考えから、チームキープの時間を利用して、オンラインでできるコミュニケーションゲームを取り入れています。 パートナー発案で以下のような企画を実施しました。 パートナーをもっと深く知ろう ～クイズ○○さん～水平思考クイズ町の地図を作成しようお絵かき伝言ゲーム といったものです。詳細は割愛しますが、どれも楽しみながら相手とコミュニケーションが取れ、伝える力をつけることのできる良い企画でした。 一見、エンジニアの業務とは関係のないように思う方もいるかもしれませんが、こうしたレクリエーションを通して、お互いの考えや人柄を知ることで、心理的に安心できるチーム環境を作れたと自負しています。そして、それは結果としてチームワークを深め、より生産性の高い開発へとつながると考えます。これからもこういった業務外の取り組みも継続してやっていきたいと考えています。 まとめ 色々と工夫を繰り返して良いやり方を見つけてきたのと、パートナーもリモートのコミュニケーションに慣れてきてくれたおかげもあって、どんどんチームコンディションは良くなってきているように感じます。 まだまだ取り組めることは沢山ありますので、チャレンジを重ね、良いものを取り込み、チームとして更に良いパフォーマンスが出せるよう努めていきます。

みなさま、こんにちは。GMOインターネット株式会社の斉藤です。前回の記事ではmoshというベンチなOSSツールと、VPSのポート制限のお話しが登場しました。このポート制限は、ConoHaのネットワーク機能に備わっているパケットフィルタを使って実現しています。今回はそれらを簡単に操作できるツールconoha-netをご紹介したいと思います。 ConoHaのパケットフィルタ機能 ConoHaには基盤側にパケットフィルタが備わっており、TCPポートやソースIPアドレスによるフィルタリングが行えます。仮想サーバーが接続されている仮想スイッチでフィルタリングされるので、OSやVPSの設定に依存しないのも特徴です。 なので簡易的なファイアーウォールのように使えますし、フィルタリングルールを「セキュリティグループ」という形でまとめて、複数サーバーにまとめて適用したりもできるので台数が増えたときの管理も楽です。 ただ、設定するにはConoHaのAPIを叩く必要があります。以下の記事が参考になります。 https://impov.hatenablog.com/entry/2016/05/30/210105 これからわかるとおり、複数のAPIを叩く必要があります。これは仕組みとして以下の3構造になっています。 仮想サーバーは複数のポート（=仮想NIC）を持つポートには複数のセキュリティグループを割り当てられるセキュリティグループには複数のセキュリティグループルールを割り当てられる 最初にお話ししたとおりConoHaのパケットフィルタは非常に柔軟な設定が可能です。ただ仮想サーバーや仮想ポートなどのレイヤーが多く、単純な設定をするにも多くのAPIを叩く必要があったりと少し煩雑な面もあります。 これらの手間を解決するためにconoha-netと言うツールを開発しました。開発はだいぶ前なのですが、私も業務で使いますし十分枯れていて使いやすいツールだと思います。 conoha-net conoha-netはセキュリティグループをコマンドラインから操作するツールです。インストール方法や使い方などはGitHubに書いてあります。 hironobu-s/conoha-net: A security group management tool for ConoHahttps://github.com/hironobu-s/conoha-net はじめに、以下を実行してみましょう。 list-group -a gncs-ipv4-sshのように末尾にが付いたものが見えます。 -all, -ssh, -web これらは実はコントロールパネルから設定できる「許可ポート」のことなんです。現状でコントロールパネルから設定可能なセキュリティグループが一覧で出ている状態なんですね。 hiro@personal$ conoha-net list-group -a UUID SecurityGroup Direction EtherType Proto IP Range Port 01c8f7d2-9a61-4158-bec9-882d9ea82c4e gncs-ipv4-ssh egress IPv4 ALL ALL a80a3376-5fff-41f1-b4de-6f975968e5a7 gncs-ipv4-ssh egress IPv6 ALL ALL ee75d97a-fe30-4974-944d-850da19356d9 gncs-ipv4-ssh ingress IPv4 tcp 22 - 22 0c905231-5ac8-4627-89d0-c8bb96b185f7 gncs-ipv6-all egress IPv6 ALL ALL 15962089-aaae-498f-86a9-7df572ce01fb gncs-ipv6-all ingress IPv6 ALL ALL f375fc43-bfab-48cc-a66d-418b6d709a60 gncs-ipv6-all egress IPv4 ALL ALL 1d1b7066-7da5-4694-9e8b-445b01d7df64 gncs-ipv4-all ingress IPv4 ALL ALL 771f3074-4fe8-4051-804e-6f5f7f4860b1 gncs-ipv4-all egress IPv6 ALL ALL b8d81897-4229-4ddf-8325-11a7d0b42efd gncs-ipv4-all egress IPv4 ALL ALL 448761e1-4943-453e-9edb-51d4bf81364c default egress IPv4 ALL ALL 4f505718-d378-4f24-991a-02d20b8285e4 default ingress IPv6 ALL ALL 66619594-8dea-4fc6-8815-5db7ef623930 default ingress IPv4 ALL ALL b950e586-53d5-4944-bdbd-fbba045c2d3d default egress IPv6 ALL ALL 12d97dca-94a2-4b99-938e-ff8be875d8a9 gncs-ipv4-web ingress IPv4 tcp 20 - 20 286a0a55-2c25-4810-9274-021d474126f6 gncs-ipv4-web ingress IPv4 tcp 443 - 443 85421073-7b49-41bf-9da1-d6e48b0f6c88 gncs-ipv4-web egress IPv4 ALL ALL ab501cfa-e67a-4255-9291-382400a45b2b gncs-ipv4-web ingress IPv4 tcp 21 - 21 b73d7eca-06b9-4252-ae9c-adad891dbb88 gncs-ipv4-web egress IPv6 ALL ALL daf58069-fd85-4281-a86e-3a8d23fd389b gncs-ipv4-web ingress IPv4 tcp 80 - 80 05bb817c-5179-4156-99ec-f088ff5c5d8e my-group egress IPv6 ALL ALL 5ecc4a23-0b92-4394-bca6-2466f08ef45e my-group egress IPv4 ALL ALL ↓コントロールパネル コントロールパネルからは特定のポート（22, 80, 443とか）しか設定できませんが、conoha-netを使うと自由に設定できますし、ソースIPアドレスの指定もできるようになります。たとえば、SSHへの接続を133.130.0.0/16からのみにしたい場合はこんな感じです。 hiro@personal$ conoha-net create-rule -d ingress -e IPv4 -p 22 -P tcp -i 133.130.0.0/16 my-group 5697eb75-3517-44a9-bc40-d532a4aedd89 hiro@personal$ conoha-net list-group UUID SecurityGroup Direction EtherType Proto IP Range Port 05bb817c-5179-4156-99ec-f088ff5c5d8e my-group egress IPv6 ALL ALL 5697eb75-3517-44a9-bc40-d532a4aedd89 my-group ingress IPv4 tcp 133.130.0.0/16 22 - 22 5ecc4a23-0b92-4394-bca6-2466f08ef45e my-group egress IPv4 ALL ALL JSON出力もできるので、スクリプトやプロビジョニングツールからも扱いやすいです。 hiro@personal$ conoha-net -o json list-group | jq . [ { "direction": "egress", "ether-type": "IPv6", "ip-range": "", "port": "ALL", "proto": "ALL", "security-group": "my-group", "uuid": "05bb817c-5179-4156-99ec-f088ff5c5d8e" }, { "direction": "ingress", "ether-type": "IPv4", "ip-range": "133.130.0.0/16", "port": { "max": 22, "min": 22 }, "proto": "tcp", "security-group": "my-group", "uuid": "5697eb75-3517-44a9-bc40-d532a4aedd89" }, { "direction": "egress", "ether-type": "IPv4", "ip-range": "", "port": "ALL", "proto": "ALL", "security-group": "my-group", "uuid": "5ecc4a23-0b92-4394-bca6-2466f08ef45e" } ] conoha-netを使うと、セキュリティグループの設定をより簡単に行えるはずです。良かったら使ってみて下さい。 それはまた次回お目にかかりましょう。

GMOペイメントゲートウェイのエンジニア向けオンラインイベント、「Developers Night #24」を開催し、様々な決済手段を一括導入できる総合決済システム「PGマルチペイメントサービス」をはじめ、 未回収リスクをGMOペイメントサービスが負担※1する「GMO掛け払い」や、返金・送金をスピーディーに代行する「GMO-PG送金サービス」、サービス・コンテンツ向け後払い決済「こんど払い byGMO」など、20年近く続くサービスから社会のニーズに合わせて生まれた新規サービスの裏側までお話ししました。 ※1GMOペイメントサービスによる与信審査を通過し、正常に完了した取引が対象 イベント告知：https://developers.gmo.jp/8793/  当日の様子をレポートいたします。  はじめに  こんにちは、GMOペイメントゲートウェイ（GMO-PG）の広報担当です。  今回は4つのテーマについて、GMO-PGと2021年4月にグループジョインしたビュフォート社のエンジニア計9名が登壇しました。  総合決済システムをはじめ、送金・返金、掛け払いや、コンテンツ・サービス向けの後払い決済などのシステムの立ち上げからこれまでの経験により得た教訓などをご紹介しました。  数百名の方にご視聴いただき、それぞれのセッション中に立ち上げや運用のお話しに多くの共感の声をいただきました。  セッション①：PGマルチペイメントサービスのこれまでとこれから  https://www.youtube.com/watch?v=zaxuGVz0NnY 決済手段を一括導入できる総合決済システム「PGマルチペイメントサービス」、通称「マルペイ」に関して、処理件数など具体的な数値と合わせてサービスをご紹介。また、システム構成や体制、見守り方など裏側についてもお話ししました。  また、実際の管理画面を見ながら、マルペイの機能やこれまでのシステム更改についてご紹介しました。若手開発担当者が考える「改善すべきポイント」「楽しいポイント」についての裏話を通して日々改善に取り組んでいることをお話ししています。現在絶賛開発中の「より使いやすい管理画面」の内容もご紹介しています。  ▼GMOペイメントゲートウェイのブログはこちら 前半：https://www.gmo-pg.com/blog/article-037/後半：https://www.gmo-pg.com/blog/article-038/ セッション②：年間3,000億円送金するシステムをサービス停止なしでシステム更改した話  https://www.youtube.com/watch?v=o3Tm4aBbu68 準備期間1年ほどをかけ更改した送金システムに関して、サービスのご紹介と、旧システムにおける課題に対して新システムでどのような対策を行ったかをお話ししました。  企業間取引における与信、請求、入金確認、督促業務を代行し、未回収リスクをGMOペイメントサービスが負担※1「GMO掛け払い」のローンチまで約1年の開発体制や工夫したことなどについてお話ししました。  ▼GMOペイメントゲートウェイのブログはこちら https://www.gmo-pg.com/blog/article-039/ セッション③：「GMO掛け払い」新規プロジェクト立ち上げからローンチまでの軌跡  https://www.youtube.com/watch?v=LGkufGI5RO0 企業間取引における与信、請求、入金確認、督促業務を代行し、未回収リスクをGMOペイメントサービスが負担※1「GMO掛け払い」のローンチまで約1年の開発体制や工夫したことなどについてお話ししました。  ▼GMOペイメントゲートウェイのブログはこちら https://www.gmo-pg.com/blog/article-040/ セッション④：共に成長するパートナーシップで決済サービスを構築する   https://www.youtube.com/watch?v=Ilg6_A27Nng コンテンツ・サービス向けの後払い決済サービス「こんど払い byGMO」のローンチに向け、当時外部パートナーであったビュフォート社の力を借りることで、クラウドネイティブ×マイクロアーキテクチャでの開発を実現しました。委託、受託の垣根を超えて新たな技術に取り組んだ進め方を、GMO-PGのエンジニアリングマネージャーからインタビュー形式で、ビュフォート社のお二人とお話ししました。  ▼GMOペイメントゲートウェイのブログはこちら https://www.gmo-pg.com/blog/article-041/ さいごに  GMO-PGは決済業界のリーディングカンパニーとして、キャッシュレスやDXを進める事業会社や金融機関に対して、各種決済・金融関連のソリューションやプラットフォームの提供、決済インフラの構築などを行っています。  15万店舗以上の加盟店様に、総合的な決済関連サービスや金融関連サービスを提供しており、2021年3月末時点で年間連結決済処理金額は6.9兆円を超える規模となりました。  今後も決済関連サービスや金融関連サービスについてのイベントを開催し、皆様と考える機会を創出できればと考えております。  なお、過去のエンジニアイベントの書き起こし記事を公開しておりますので、ご興味ありましたらご一読ください。  https://www.gmo-pg.com/blog/list.html?ch=ch_engineer GMO-PGでは、社会インフラともいえる決済サービスを安全・安心にご利用いただけるよう、品質向上のため日々エンジニアが自発的に業務に取り組んでいます。  そんな我々と共にサービスを支えてもらえる、仲間を絶賛募集しています。  お問合せお待ちしております！  GMOペイメントゲートウェイ採用ページ 

少し前まではRPAを導入する場合、初期導入で数十万円、月額利用料でも数十万円という費用が必要でしたが、Power Automate ・ Power Automate Desktopを利用することで、月額数千円程度でRPAが利用できるようになりました。ですが、これまでに開発し利用しているRPAが多数に及ぶ場合はなかなか簡単にPower Automate ・ Power Automate Desktopに切り替えるといったことが難しいとも考えられます。今回はRPA導入に関してこれらコストに見合った効果をいかに発揮してゆくのか、その方法や効果測定の指標、RPAの導入効果について考えてみたいと思います。 RPA導入にかかるコスト 初期導入費用 まずは、RPAを導入する場合どれくらいのコストが発生するのかを見てみましょう。どのようなRPAを導入するかによって金額はさまざまですがある一例ということで考えてみます。 項目金額数量RPA本体開発用60 万円1RPA本体実行用30万円1開発費用（外部委託）50万円1RPA実行専用PC10万円1 こちらの例の場合初期導入費用で150万円となりました。 この例以外でも、販売元からの導入支援費用や、初期設定費用など発生する場合もあります。 運用費用 次にRPAを利用することで必要となる月額費用です。こちらも製品やサービスによってさまざまです。RPA1体につき月々ライセンス費用が発生する場合や、本体費用にこれらが含まれている場合もあります。 項目金額数量ライセンス5万円1サポート5万円1※RPA1体につき RPA1体を利用するだけでも10万円ほどの費用が必要となります。稼働するRPAの数が多くなればライセンス必要もそれに伴い追加購入する製品もあります。 教育・研修費用 さらに、RPAを活用するためには利用する側の技術習得も必要となります。独学で開発方法や利用方法を習得することも可能ですが、場合によっては開発セミナーや利用者向け教育プログラムに参加するこが必要となります。 項目金額数量開発者セミナー30万円1利用者セミナー5万円1 RPA技術者採用費用 企業によってはRPA導入を機に専門部署の設立や、RPA開発・運用のための人財を採用することも考えられます。 項目金額数量採用費用20万円1技術者給与（月額）50万円1 単純にRPAの購入代金だけでは無く、初月まで含めると数百万円の導入費用が必要となる場合も考えられます。 RPAを導入することによる人件費削減を目指している一方、RPAを開発・運用するために新たな仕事と人件費が発生することも念頭に置いておきましょう。ただし、RPAの中にはMicrosoft365のPower Automate・Power Automate Desktopなどのように月額数千円から無料でも利用できるものがあります。機能と費用を検討した上でこういった低価格のサービスをうまく利用することも導入費用を抑えるコツとなります。 PRA導入への期待 これら数百万円の費用を投じて、企業が期待できる効果を挙げてみましょう。 作業時間の短縮 RPAの導入効果で一番に実感できるのが作業時間の短縮です。一定の規則にしたがってロボットが人に代わって自動的に作業を処理してくれるので、スピードの優位性は当然のこと、多岐に渡る作業も滞り無くこなしてくれます。 生産性の向上 業務時間の短縮に伴い、処理できる仕事の量も格段にアップします。休憩も無く、深夜までもRPAは稼働し続けることが可能です。人の数十倍、数百倍もの処理能力で生産性の向上が期待できます。さらに、作業時間の短縮や単純作業をRPAに置き換えることで、人でしか出来ない仕事や、より創造的な仕事へシフトすることで売り上げアップなどの取り組みが可能になります。 コスト削減 新たに人を採用して業務の処理量を増やすといった取り組みは、RPAの導入に置き換えることができます。採用費、入社に伴う教育費も抑えることができます。業務時間の短縮は人件費など残業コストの削減にもつながります。 人的ミスの回避 RPAで置き換える仕事として多いのが、データの転記です。Excelのデータを基幹システムへ手入力していた業務を自動化するなどです。その際、人が目で見て手で入力といった作業になるのでどうしても見間違いや入力ミスなどが起こりがちです。こういったミス回避のための二重チェックやデータ修正などRPAを活用していれば不要な業務が一掃されます。 属人化の回避 仕事の中にはその人でしか分からないといった業務がいくつか存在する場合があります。その方がお休みでどう処理してよいか分からないなど困ることもしばしば。退職するとなれば代わりの担当者を採用して引継ぎマニュアルを作成しなければなどと、お金も時間も必要となる場合が多く見受けられます。ある程度の業務をRPA導入により見える化することでこういった混乱を回避できます。 労働環境の改善 一日に数百件のデータを画面をじっと見ながら転記するような単純作業を毎日繰り返す業務は人によってはかなりの負担を生じさせます。精神的、肉体的にハードワークとなり得ます。こういった労働環境を改善するといった役割もRPAは担っていいます。長時間労働やストレス過多など職場に潜在的に潜んでいる悪しき労働慣習なども改善できる可能性があります。 RPAの使いどころ RPA（Robotic Process Automation）はロボットというだけあって人の代わりに何でも仕事を自動的にこなしてくれそうなイメージですが、RPAは得意なことと不得手なことがあります。 得意分野 人が行う画面上の操作の代行ルールが決められたパターン化された作業繰り返しの反復処理長時間作業複数のシステムを組み合わせた処理など 不得意分野 あいまいな情報からの判断ルールが決められていないもの実行環境が整っていない状況での作業など これらを踏まえた上でRPAの効果を最大限に引き出せる環境での活用が必須となります。 「パターン化されているけれどもシステム連携など複雑な反復処理を1日に何度も実行する」など、一番の活躍の場となります。 さらに、RPAは必ずしも既存の業務を置き換えるだけのものではないということも覚えておくとよいでしょう。これまでは業務システムなどはプログラミングのできる専門のエンジニアが担当して作りこむものでしたが、多くのRPAはローコードと呼ばれる簡易プログラミングで開発可能です。ローコードの恩恵によりシステム開発という分野のハードルがかなり低くなっています。何か新しい仕組みやシステムが必要となったとき、自分達でそのシステムをRPAで開発することが可能です。 導入体制 RPAはその高額な費用から会社としては専門の部署や人員が開発～運用までを担うことを想定していると思います。確かに部署間を横断するようなシステムや、全社員向けの人事システムなどは専門部署管轄で開発運用すべきです。 一方、RPAの活躍の場は実は個人の仕事の中に数多く存在しています。こういった1つ1つの案件にRPA部門が開発から運用までを一手に引き受けてしまうとRPAを作れば作るほどRPA部門や開発担当者への負担が増加してゆきます。せっかく現場では効率的に仕事ができるようになってきたのに、RPA部門は毎日残業、人員もどんどん増やさねばという事態もあり得なくはありません。 こういった事態を回避するためにもRPA導入は効果を発揮します。通常のシステムだと、専門のエンジニアが開発～運用まで行う必要があります。一方RPAなら、最初の開発こそRPA部署に依頼をしたとしても、ちょっとしたメンテナンスや修正はローコードのおかげで現場担当者レベルで可能となります。RPA部門にとっても手離れのいいシステムとなるのです。さらに言えば、個人で完結するようなお助けツール程度であれば担当者でもRPAで開発が可能です。RPAを導入した場合の体制としては、会社全体として専門部署を構えることと併せて個人での開発利用も推進すべきと考えます。 RPA導入の費用対効果の測定 RPAの導入費用が算出できたら、その費用に対する効果を検証する必要があります。費用に見合った、もしくはそれ以上の効果を期待しているからこそのRPA導入です。その具体的な効果測定方法は以下の3つとなります。 削減費用 いくら作業時間が削減されたとはいえ、具体的な金額に置き換えてみないと費用対効果の判断は困難です。1つの例としてその金額を計算してみましょう。ポイントとなるのは削減時間と人件費です。具体的には以下となります。 削減費用 ＝（業務1件当たりの削減時間 × 担当者の人件費）× 業務数 + 残業削減コスト この金額と、RPA導入にかかった費用を比較することで費用対効果の有無を判断できます。 生産性向上 RPAの導入で得られる効果はマイナス（削減）だけではありません。プラスに働く効果も必ず測定する必要があります。1つの効果としては処理件数の向上です。これまで100件しか処理できなかった作業が1000件処理できるようになったなど、明確に効果として現れます。さらに、処理時間の削減や創造的な仕事へのシフトなどRPA導入後の売り上げの増加分も効果として含めることができます。 生産性向上 ＝ 業務1件当たりの売り上げ単価 × 増加処理件数 + 売り上げ増分 定性的効果 上の２つは具体的な金額まで落としこみ可能な範囲の効果測定となりますが、RPAの導入効果には数値に表しきれない部分も期待できます。仕事へのストレスが減って働きやすくなったとか、引継ぎが簡単、業務の見える化を実現などさまざまな効果が期待できます。 定性的効果 ＝ 人的ミスの回避 + 属人化回避　+ 労働環境の改善 これら3つの効果測定方法を踏まえてRPAの導入が果たしてどれだけの効果があったのかを判断してみてください。 考察 RPAの導入効果では「作業時間をどれだけ短縮したか」だけに焦点を当てて効果の有無を判断する場合がしばしば見受けられます。もちろん作業時間の短縮も効果として十分期待できる部分ではありますが、残念ながらRPAを導入したからといって、すぐに人を辞めさせて人件費が削減できるといったものではありません。どれだけ作業時間を削減したとしても、いまいる人達で売り上げアップなど生産性の向上に向け取り組まなければRPAの導入効果は道半ばと考えてください。 手の空いた時間をどれだけ生産的な仕事に還元できたとか、人がすべき仕事に時間を振り分けられたなど、1人1人の生産性を上げる取り組みが必要です。 また、生産性を上げるための取り組みがRPAの導入でしか実現できないというのも誤りです。RPAは生産性を上げるための1つの手段でしかありません。RPAを使わなくともExcelの関数やマクロ、仕事のやり方や業務フローの見直しなど費用をかけずとも出来ることはたくさんあります。これらをRPAと組み合わせることでより一層の業務効率化を実現し、生産性を上げることが可能です。 中には、RPAを魔法の道具のように理想を描いてしまい、RPAを導入した時点で満足してしまったり、RPAの稼働数を上げることだけが目的となってしまっているケースも見受けられます。よくよく効果を検証してみれば、RPA導入費用に見合うコスト削減も生産性向上も図れずにいるのにまったく気づいていないという有様です。 使いどころの章でも述べましたが、RPAは必ずしも既存の業務を置き換えるだけのものではないということです。業務担当者自ら仕事を効率化するための道具でもあります。何か新しい取り組みをする際にもRPAを前提に仕事のやり方を考えてみることが必要です。 一人一人がちょっとしたことでも効率的に取り組む姿勢が、集まれば会社全体の生産性の向上へとつながります。RPAの導入がこうした意識改革のきっかけとなることこそ一番の効果と言えるかもしれません。 先日MicrosoftはPower Automate Desktopを無償提供すると発表しました。これまで仕事のスキルとして「Word、Excelは当たり前に使えます」とうのが普通でしたが、これからは、「RPAは当たり前に作れます」といった時代となるでしょう。RPAで置き換えられる仕事はどんどんRPAにやってもらい、人がやらなければいけない仕事により多くの時間を費やすといった効率的かつ創造的な仕事のやり方が今求められています。 以上、RPA導入における効果について考えてみました。

こんにちは、クラウドサービス開発部の郷古です。 今回は気に入ったプロジェクトを見つけたので、ちょっと知ってほしい内容として取り上げます。Cloud Native基盤として提供されているKubernetesをシンプルにしたk3sのHCI (Hyper Converged Infrastructure)の概念で作られた"Harvester"を知っていますか？今回はその最新版について見ていきたいと思います。 クラウド基盤、仮想化基盤、そしてkubernetes kubernetesの有用性とは何なのでしょうか。なぜ、どのような場合に使うべきなのでしょうか？ まず、kubernetesには次の機能があります。 冗長化が標準機能で提供ストレージ（ex: csi）が提供ネットワーク（ex: cni、セキュリティ、ロードバランス）の提供リソースの割当管理（CPU、メモリ）機能の利用が可アプリケーションのスケール設定などのスケジューラー機能の利用可アプリケーションの実行のより安定させるのに役に立つ手法となる機能が活用しやすい（ローリングアップデートの利用によるダウンタイム無しのソフトウェア更新など）Kubernetesの巨大なエコシステム（CRI, helm, csi, cniなどなど）が利用できるため生産性が向上するKubernetesのクラウドネイティブな技術スタックによるワークフローなど新しいことに取り組む姿勢が人材引きつけのとして役立つ これらの利点は、クラウド基盤、仮想化基盤においても必要とされる特徴がいくつもあります。実際、オープンソースクラウド基盤の"OpenStack"において、"OpenStack on Kubernetes（Kubernetes上でOpenStack を動かす）"といプロジェクトの発生でも自動化の仕組みとして活用されています。 アプリケーション、ネットワーク、ストレージを「"アプリケーション"を自動的に動かし続けるための環境としてのKubernetes」をOpenStackのような「インフラア・プリケーション」に適用することで、運用性が向上するということが、すでにいくつかの取り組みにより実現されています。 k3sの発生、Edgeと組み込み また、Kubernetesはgoで書かれていることで、goのライブラリは静的にリンクされて、バージョンアップで機能が統合されると、バイナリサイズが増えていく傾向にありました。 そのような中、k3s(https://k3s.io/ )は元々Rancher Labs(https://rancher.com/)で開発されていたOSSで、2019/02に発表され、使い方を限定することでコードをスリム化を果たして、Kubernetesのディストリビューションとしては40MB以下の軽量バイナリで提供されることが話題となりました。 コンテナの運用をすでにKubernetesで利用しているしているユーザは、同じ手法で小容量対応のデバイス（エッジデバイス; エッジ・コンピューティング、組み込みに対するCI、IoT機器、開発環境など）にコンテナを利用できるようになります。（その後、Rancher LabsはSUSEグループ入りました） k3s.ioのサイトhttps://k3s.io/ k3sそのものの話からは外れますが、Kubernetesと組み込み開発の需要は大きく、自動車部品大手のデンソーが、自動車向けにKubernetesを実行するためのソフトウェア「Misaki」(publickey記事参照 )を発表しています。MisakiはCloudの延長環境として車の中のEdgeを定義して、車の中のコンピューターEdge環境にソフトェアをすべてDeployできる場合も、一部だけDeployして残りはクラウド上にある場合にも、サービスメッシュの機能によって同じようなソフトウェア動作を提供しようという試みがあります。この試みは、車の上に分散配置したEdge環境で、一部のCPUが壊れたとしてもEdgeとCloudを含めて動作を停止しないという自動化を実現しようという試みでもあるようです。 Denso "Misaki" サービスメッシュを活用したCar EdgeとCloudでのサービス動作例 "Misaki" slide : https://www.slideshare.net/KentaSuzuki4/kubernetes-based-connected-vehicle-platform-k8sjpt1-k8sjp 米国の事例となりますが、戦闘機F16にKubernetesとIstioを搭載させる試みが紹介され(publickey記事参照) ています。開発のパーツ単位の共通化やDevOps適用でCIにおいてモダン化された開発のチャレンジをまずやってみたといった話が紹介されていたりします。 F16システムにKubernetesを組み込んで兵器システムに活用できると喜んでいるUSA空軍の求人スライド KubeCon slide youtube F16: https://www.youtube.com/watch?v=YjZ4AZ7hRM0 小さなコントローラk3sとシンプルなストレージLonghorn、VMを稼働するKubeVirtとの出会い: Harvester の登場 そのような中 "Harvester" は登場しました。コンテナにおいて冗長化と自動化を実現するKubernetesの機能性と、CRD(Custom Resource Definition)という拡張性を利用して、小さな仮想化の自動化を実現するソフトウェアにより、"The open source hyperconverged infrastructure （HCI） solution for a cloud native world" いわゆる "HCI : hyperconverged infrastructure" をコンパクトに実現しようというOpen Sourceソフトウェアとなります。 Harvester サイト https://harvesterhci.io/ "Harvester" の中身 (0.2) "Harvester" の中身はどうなっているのでしょうか。 先ほどの小型"k3s（https://k3s.io/）"が全体のコントローラとなるk3os（https://k3os.io）はk3sが入ったLinux軽量OSのKubernetes実行環境となる同じくRancherが開発していたReplica生成型のKubernetes用のストレージcsiである"Longhorn（https://longhorn.io/）"がKubernetes上でストレージをコントロールするKubernetes上でVMの管理を稼働させることのできる仕組みの"KubeVirt（https://kubevirt.io/）"とKubeVirtの運用のためのCRD(カスタムリソース定義)を組み合わせたvmを管理する部分が導入されている"Harvester"初期構成(ver. 0.1)では、Minio（https://min.io）をS3 object storageを使って、vmイメージレジストリとして使用していましたが、Minioの冗長性の問題などからLonghornを利用したvmイメージレジストリに移行する模様仮想マシンを管理できるweb UIがあります。（youtube DEMO動画: https://www.youtube.com/watch?v=wVBXkS1AgHg） Longhorn のサイトhttps://longhorn.io/ "Harvester 0.2" の紹介 今回は、ここまでの説明が長くなりましたので、手短にこの記事を書いている時点のリリース（"2021-4-30"）である"Harvester 0.2"について、大まかな機能と、実現される内容は以下となります。 VM lifecycleを管理できます。ssh KeyのVMへの挿入、Cloud-initの実行、仮想Videoコンソールでの操作、シリアルコンソール操作が可能（"KubeVirt": v0.40.0）VMのlive migrationの実現VMのBackupとRestoreの実現分散ブロックストレージの採用（"Longhorn" : v1.1.1）仮想マシンとcloud-initのテンプレート化Rancherを使った管理の実装とRancherへのHarvester nodeの管理の提供 （"Rancher": v2.5.7）HarvesterのPXE/iPXEでのOS netbootによる起動のサポート（"K3OS": v0.20.4-k3s1r0）認証システムはKubernetesの認証を使用v 0.2以降では、Harvester自身をupgrade可能（"Zero downtime upgrade" ただしOS以外）default として、"flannel CNI"を使い、podのネットワーク疎通を実現"Multus CNI"と"Bridge CNI"により、VLANを扱い、VMに複数NICインターフェースを扱える（"Multus": v3.6）外部イメージとして、ISOとqcow2イメージを取り込み可能Web UIから操作可能以下①～④のような想定される利用方法がある オンプレミスのHCI環境としてEdge HCI環境としてHybrid Cloudの実現コンテナとVMのを同じインフラに動作できる ここまで、機能をざっと見渡しますと、マルチクラウドなCloud Nativeコントローラである"Rancher"から、環境の1つとしてコントロールできるという点がおそらくこのソフトウェアのポイントなのだと目立ちますが、一般的な仮想化の実行環境として必要十分な機能を持っています。 VDIを実行するのがオンプレミスHCIだとすると、たとえば本社 : 店舗システムでの構成で店舗の管理コンピュータのHCIとCloud Native化を進めてDevOpsで更新するようなEdge HCI実行環境や、public cloudとHCIでのHybrid Cloudまたは本社のOpenStack Private CloudとEdge HCIとのHybrid、なども検討できると思われます。 PS. (錦糸町の駅ナカの立ち食いそばも、自動券売機と店舗コンピュータがつながっていて、ネッワークで本部に売り上げを送信されるような、日本的なPOSシステムがあるので、そのうちここにも導入されるのかなぁと、想像したりしていました: 笑) 次回は、"Harvester触ってみた"の記事に進む...かなと。

こんにちは。デベロッパーリレーションズチームの村上です。皆さんリモートワークされていますか？今回は東京-福岡-ベトナムと拠点をまたいで開発を行っている私のチームで、普段どのようなツールを使ってコミュニケーションを取っているのか紹介していきます。 はじめに コロナ禍になって以降、リモートワークされている方が増えましたよね。弊社は国内の上場企業としてはもっとも早く大規模なリモートワークを開始しました。参考プレスリリース：https://www.gmo.jp/news/article/6641/ 私はリモートワークが主流になってからマネージャー職になりました。そのためオンライン上での信頼関係の構築や、開発業務をより効率的に行うためのチームメンバーとの円滑なコミュニケーション方法を模索する必要がありました。 そこで今回は、私がたどり着いたリモート開発に際してより効率的なコミュニケーション方法をお伝えしようと思います。 コミュニケーションツールに関して まずは実際に使ってきたコミュニケーションツールの変遷と特徴を私の所感で書いていきます。 Skype リモートワークが始まるまでは一番使われていました。ちょっと通信品質が良くなかったかなという記憶がありますが、コミュニケーションにおける大きな問題はなかったです。 Zoom こちらはリモートワークが始まってから主流となったツールです。Skypeより優れていると感じる点は、通信品質が良くカメラをつけた状態でも音声の聞こえが良いです。今ではZoomを使うことが主流になっています。バーチャル背景やビデオフィルターみたいなユニークな機能もあって、ちょっとしたコミュニケーションのきっかけになったりすることもあります。 Google Meet 今では有料アカウントが会社から支給されており、何時間でも繋いだままの環境が使えています。無料アカウントしか持っていないときには、リモートワーク中のメンバーを常時接続状態を作るために使用していました。有料アカウントを会社から支給されて以降は、メインツールがZoomになったので切り替えて現在は使用していません。 Microsoft Teams Zoomが使えないときのサブ手段として使っています。Zoomが使えなくなることはあまりありませんが、いざという時に使えないと困るので週一のチームミーティング等で使っています。 Discord こちらは割と最近、開発作業時に使うことが増えてきました。現在主流で使用しているZoomと比較した私の環境を考慮しメリットは、2点あります。 仕様上、作業者の状態がわかりやすい東京のチームと同じサーバーを作成しているので、東京のチームの在籍状況がわかって声をかけやすい あとは基本カメラOFFで通話のみとしているので、常に見られているというプレッシャーを感じなくてよいらしいです。（Zoomのときは基本カメラONで作業にしています）。 各ツールごとに使い込み具合に差はありますが、現時点での私の評価はこんな感じです（5段階評価） 通信品質使いやすさ優れていることSkype☆☆☆☆☆☆☆Zoom☆☆☆☆☆☆☆☆☆カメラONの通話品質の安定感バーチャル背景Google Meet☆☆☆☆☆☆Microsoft Teams☆☆☆☆☆☆☆バーチャル背景Discord☆☆☆☆☆☆☆☆☆☆ボイスチャットコミュニケーションの取りやすさ 円滑な開発/コミュニケーションが実感できたDiscord ここまではリモートワーク開始前～現在に至るまでに活用したツールの紹介をしてきましたが、マネージャーとしてより円滑にコミュニケーションを取るために私の選定したメインツールは2つです。 １.Zoom２.Discord 弊社のメインツールであるZoomのみでも、十分にコミュニケーションを取ることは可能です。ここからは私が実践して感じた、プラスαでDiscordを取り入れるメリット・デメリットをお伝えします。 メリット オンラインでのメンバーのステータスが見えやすい 各チャンネルに人がいるのが見えるので、声をかけやすいです。これはZoomでは実現できない機能なので、これだけでも使う価値があるなと感じています。 複数同時に画面共有ができる 自分が画面共有しつつ、他のパートナーに画面共有してもらってそちらと見比べながら話ができる部分は使いやすいです。Zoomでも複数画面共有は可能なのですが、自分が画面共有をしていると他の人の画面共有を見ることはできません。 Zoomと同時に起動できる これは併用しているならではかと思いますが、Zoomを常設していると会議を別で作ることはできません。オンラインで離れている環境だからこそ、チームメンバーと多くコミュニケーションを取る必要がある私にとっては、mtgを同時に起動できる点は非常に便利です。 他拠点のチームメンバーが入ってきてくれて、雑談等のコミュニケーションが取れる 業務とはそこまで関係ないのですが、リモートワークではなかなか難しい自チーム以外のパートナーとのコミュニケーションが取りやすいです。結構これって重要なことだと私は考えています。今は2チームを含むサーバーなのですが、もう少し大きな範囲でやってみても効果があるはずです。 デメリット 出社時にイヤホンをつけた状態にしてると、貴重なオフラインでのコミュニケーション機会を失ってしまう 役職者や先輩がイヤホンつけてると、周りの人は何か忙しそうだなと感じて声をかけにくいですよね。出社時は常時イヤホンというのは控え、リアルコミュニケーションを心掛けたほうが良いのかなと考えています。 雑談しすぎない配慮が必要 難しいラインだとは思いますが、ZoomよりはカメラがOFFなせいか雑談が生まれやすい空気があると感じています。雑談に気を取られて作業できないパートナーが出るのは良くないので、集中する時はスピーカーミュートをする、集中タイムのようなものを設けてその間は開発に集中する等の対策をしておく必要があると考えます。 実際のサーバーの様子 このような形で運用してます。（うちのチームの若い子が名前隠してくれました） まとめ 如何だったでしょうか。これ以外にも世の中にはたくさんコミュニケーションツールはあります。今回ご紹介したツールは無料で使える（私はZoomは有料アカウントを使用していますが、無料版もあります）ので、まだ使ったことがないツールがあればぜひ試してみてください。私はマネージャーとしてチームをまとめる上で、パートナーに最大効率を出してもらうように環境を作って行く必要があります。良質なオンラインコミュニケーションの環境を作るために、色々なツールや仕組みをこれからも模索します。 さいごに 私がデベロッパーリレーションズチームに所属する前から行っている、福岡のパソナテック様との合同オンラインLTイベントが6/30に開催されます。初回は私が進行とLTの発表を行います。九州のITエンジニアの面白い話が聞けると思いますので、お時間がある方はぜひ参加していただけると嬉しいです。https://hakata-tech-juku.connpass.com/event/214140/

みなさん、印鑑使ってますか？最近は物理的な印鑑を使う機会は減ってきましたね。そんな中「さよなら印鑑キャンペーン」という取り組みが2020年6月25日〜2020年9月30日まで行われました。たくさんのご応募、エピソードありがとうございます。今回は、皆さんから頂いたアンケート・エピソード投稿を分析するシステムをサクッと作った話をします。 さよなら印鑑キャンペーン GMOインターネットグループでは印鑑廃止の取り組みを進めていて、物理的な印鑑を使うことは無くなりました。GMOサインというサービスを展開しており、印鑑は電子サインでOKといった感じですね。 昨年、さよなら印鑑キャンペーンという印鑑に関わるエピソードや、脱ハンコに賛成・反対といったアンケートが2020年6月25日〜2020年9月30日に行われました。僕自身の印鑑に関するエピソードだと、印鑑を使うことは1年に1度あるかどうか...で、それも会社以外の事だけですね。ただ、"紙で自筆・印鑑が必須"という事もあったりすると、自筆をすることもほとんど無くなったので、自分の字の汚さを再認識する事もあったりします。 それは突然やってくる キャンペーンを行っていた事は知っていて、誰か集計を取ったりするんだろうなぁ...と思っていたところ、それは突然やってきました。「集計するのよろしくお願いします」「（何のことすか？）了解です」「至急進めてください」あ、誰かは僕でしたね。 僕の感覚だと"至急=Now"で今すぐ、数日中に結果を求められるといった感覚なので、早速とりかかる事にしました。データがあれば、要望に応じて集計・分析はできるので問題ありません。ただ、個人データが含まれる内容のため、データの取り扱いは慎重に進めました。 そもそも何を集計したいか？ まずはキャンペーンページを見てみた所、次のようなフォーム・データになっていました。 脱ハンコ：賛成・反対エピソード：自由記述エピソードの場所：自由記述 自由記述という事は日本語の文章を解析する必要がありますね。エピソードに関しては次のような内容です（キャンペーンサイト、エピソード賞から抜粋）。 【賛成】重要な契約の捺印ならいざ知らず、数万円の発注書のハンコにも申請書類が必要で、そのハンコを得るのに、上役の個人印をもらいに回るという作業自体が業務効率を著しく下げていることが非常に無駄。また、電子社印の話ではないのですが、勤怠の申請に上司の個人印を押す文化がまだあるので、上司不在の場合には、その上の人の印があればいいとのことで、何も業務も把握していない人にハンコを得るので通る申請ならば確認など不要ではと思ったことが何度もあります。電子印なら社内に上司がいなくても対応ができますし個人印も電子でいいのでは、と思っています。 【反対】私は小さい頃から海外にいて大学になって日本に帰国した際に初めて銀行口座を開くために銀行に行った際、印鑑を持って行かずに銀行員の方々に驚かれた事は今でも私の大切な面白ろエピソードです。家をローンで購入する時や大きな買い物をする時に印鑑を押す時のあの緊張感。その度、今から始まる将来の生活を考えながら一回一回大切に印鑑を押しています。ハンコ不要はなんだか悲しいです。 エピソードには賛成・反対という条件が付いているので、ここで関連性が見いだせそうです。 そして、次にどういった集計を行いたいのか？ 調査してみたところ、具体的な内容・要件はまったく決まっていませんでした。そこで、重要なエピソードの検索・集計・日本語の処理をうまくしてくれるツールを利用して、まずBI(Business Intelligence)として可視化する事が最優先だと判断しました。そこから、企画やマーケ層が見えてくる事も多いでしょう。 分析方法について ここからは、集計をするにあたり利用したツールや環境についてお話していきます。 Elastic・Kibanaを利用 Elasticsearch/KibanaはBIツールとして、実績も多数あって非常に有用ですね。Kuromojiの形態素解析/n-gramがあるので、データを入れておけば、アンケート結果を検索する時も非常に便利です。また、ダッシュボードのUIも非常に便利で「非エンジニアでも誰でも使えるだろう」と思っていたので、とりあえず用意することにしました。個人的には、このElasticsearch/Kibanaの組合せで建てたサーバ・システムはかなりあるので、まぁサクッと出来るだろうな...くらいに思っていました。 ここで集計している内容は次の通りです。 データ件数、エピソード記述有り件数、エピソードの場所の記述あり件数投稿者の都道府県・市区町村のリスト脱ハンコ：賛成・反対の割合エピソード場所のカテゴリ分けエピソードの感情分析（ポジ・ネガ・ニュートラル・混合）エピソードから抽出したキーワードリスト（タグクラウド）時間毎の投稿数のグラフ 特に難しい所はありませんね。環境を準備すれば1日もあれば出来るでしょう。実際に集計したデータから、次のような傾向が見えてきました。(日本の脱ハンコを後押しする「さよなら印鑑キャンペーン」中間報告！から抜粋) これらも環境を用意しておけば、期間・都道府県・市区町村・賛成/反対・場所単位・キーワード...etcで一瞬にして検索・集計して分析できます。 Dockerで環境構築 1日もあれば用意できる、というのは少し間違っていて、環境自体は一瞬にしてできますね。そこから少しデータを整備して...大抵のデータの可視化・最初の分析までは1日もあれば可能なお手軽さがあります。 ちなみに、何かデータから知りたい...という時は、その何かも要件として分からない事が非常に多いので、とりあえずデータを集計・分析・可視化できて、レポート出来るようになっていれば最初の段階はOKでしょう。さらに深い所まで知りたくなったら、その時はデータに対する知見が溜まっているので、「何か知りたい」というのが具体的になって、適宜対応も可能になっている事の方が多いです。 最近はDockerで環境構築がすぐできるので非常に便利です。基本的な「elasticsearch/kibana/制御用のコンテナ」を一つにまとめて、いつでも(飛び込み案件などで)使えるように用意してあるので、少し抜粋して紹介します。 VScode上でプロジェクトを用意している elastic/kibanaと制御するサーバー(ここではUbuntu)は利用する事も多いので、docker-composeにしてまとめています。基本的な部分だけ記載しておきます。ディレクトリ構成は上のVScodeのスクショの通りです。kibanaは立ち上げるだけで、Dockerfileは用意しなくてもOKという事にしてあります。 version: "3" services: elasticsearch: container_name: elastic build: ./elasticsearch environment: - discovery.type=single-node - cluster.name=docker-cluster - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms512m -Xmx512m" ulimits: memlock: soft: -1 hard: -1 ports: - 9200:9200 volumes: - ./elasticsearch/dict:/usr/share/elasticsearch/config/dict kibana: container_name: kibana image: docker.elastic.co/kibana/kibana:7.10.0 ports: - 5601:5601 ubuntu: build: ./ubuntu/ container_name: 'ubuntu' tty: true volumes: - ./ubuntu/src:/src FROM docker.elastic.co/elasticsearch/elasticsearch:7.10.0 RUN elasticsearch-plugin install analysis-kuromoji FROM ubuntu:20.04 RUN apt-get update ADD . /src WORKDIR /src RUN apt-get update RUN apt install -y python3 python3-pip curl RUN pip install --upgrade setuptools RUN pip install -r requirements.txt elasticsearch こんな感じで基本部分を用意しておけば"docker-compose build"でOKですね。kibanaについてはとくに何も用意しないで、コンテナを起動して繋げられるようにしてあるだけです。サクッと使う時にPythonをよく利用するので、requirements.txt でpip経由で入れておきます。 あと、elasticsearchはdictを用意しています。これはシノニムや辞書を登録する時に利用しておけるようにしています。たとえば、カスタム辞書やシノニムを置いておくときに、ホスト側からもサクサク編集・配布できるようにしてあります。 { "settings": { "analysis": { "tokenizer": { "kuromoji_tokenizer_search": { "type": "kuromoji_tokenizer", "mode": "search", "discard_punctuation" : "true", "user_dictionary" : "dict/userdict_ja.txt" }, }, "analyzer": { "kuromoji_analyzer": { "type": "custom", "tokenizer": "kuromoji_tokenizer_search" }, }, "filter": { "custom_synonym": { "type": "synonym", "synonyms_path" : "dict/user_synonyms.txt" } } } } } これに横付けしてDBがあったりデータ連携ができれば一瞬ですね。適当にmappingを用意してデータ連携・投入をすれば、すぐKibana経由で集計・分析が出来るでしょう。アプリで何か制御が必要な時はUbuntu上で処理をサクッとやっておけばOKですね。何も集計・分析したり可視化・レポートする環境が無いとき、サクッとdockerで環境構築、elasticsearch/kibanaの構成はかなりオススメですね。

こんにちは、GMOインターネットの吉田です。ふだんナゾに包まれた（？）UI/UXディレクターのお仕事とプロジェクトの流れについて、連載でお伝えしていきます。本エントリー後半では、GMOインターネットが提供するサービス「お名前.com」UX向上のために作成したカスタマージャーニーマップも紹介いたします。 はじめに 私の所属しているディレクターチームは、現在7名です。 中途採用の人もいれば新卒採用の後輩もいて、前職の経験などバックグラウンドはみんなバラバラです。同じチーム内でも違う役割を担っているため、チーム全員がUI/UXディレクターという立ち位置ではありませんが、ディレクターチームとして目指していることは、"ユーザー体験（UX）を向上して、ブランド、サービスのファンをたくさん作ること"です。 また、GMOインターネットではドメイン「お名前.com」やプロバイダー「とくとくBB」など比較的大きなサービスを提供しているため、「サービスデザイン」の考え方も取り入れながら、売る人、創る人、守る人、お客様など関わるすべての人が満足できる持続可能なサービス設計を心がけています。 プロジェクト全体の流れ ディレクターのお仕事は、ひとことで言うと「デザインと開発（プログラミング）以外は何でもやる！」です。 プロジェクトの内容によっても異なりますが、企画からはじまり、仕様決め、ミーティングの開催、資料作成、検証作業...などなど、果てしなくさまざまです。 それでは、各フェーズごとにディレクターのお仕事を解説します。 企画/調査 「企画/調査」は、まだプロジェクト化する前のフェーズです。 発案はディレクターチームに限らず、事業部（マーケティングやサポート）、開発部、グループ会社から企画が出ることもあります。 このフェーズでは「市場調査/競合調査」、「ペルソナ作成」、「カスタマージャーニーマップの作成」を行なっています。 市場調査/競合調査 情報収集をして、ターゲットとなる市場や競合他社の調査をします。競合とのスペック比較表などを作成して、競合のターゲット層や売り方、強みの部分などを資料化。自分たちのサービスはどこを狙っていくべきかを探っていきます。 調査は比較的しっかり時間をかけて、企画の根拠となる情報をたくさん集めることがプロジェクト成功のカギです。 ペルソナ作成 企画内容がある程度決まったら、「ペルソナ」を作成します。 「ペルソナ」とは、サービスや機能を利用するユーザーの人物像を具体的に表したものです。利用シーンや使い方など、ユーザーの気持ちをイメージしやすくなるメリットがあります。 お名前.comのペルソナ お名前.comのペルソナは、会員情報やアンケートの情報から作成しました。お名前.comのユーザーさんは男性が多く、比較的年齢層が高めでITスキルは低〜中程度の方が多い傾向にあります。 ペルソナは、サービス設計や画面設計を検討する重要な判断材料にもなります。「これ大島さん操作できる？」、「大島さんこのボタンの意味わかるかな？」というように、ミーティング中にペルソナの名前が飛び交ったりします。 ディレクターとしては、プロジェクトメンバーがペルソナに愛着を持って議論してくれるとすごくうれしいです。 カスタマージャーニーマップ作成 ペルソナが完成したら、次に「カスタマージャーニーマップ」を作成します。 「カスタマージャーニーマップ」とは、ユーザー体験を旅に見立てて可視化したものです。サービスの利用前〜利用中〜利用後の状況、行動、思考、感情を1枚のマップにまとめます。 ユーザーが不満に思っている箇所を洗い出し、改善が必要なポイントを見つけることができます。 お名前.com レンタルサーバーのカスタマージャーニーマップ レンタルサーバーリニューアルのプロジェクトでは、複数の社内メンバーに参加してもらい、模造紙と付箋を使って情報をまとめていきました。 感情曲線を見ると申込み後に下降しているポイントがいくつかあります。利用に関する不明点や申込み後の不安感を解消するために、お名前.com Naviやサーバーコントロールパネルではサポートコンテンツの表示や、チュートリアル機能の実装など、改善策として検討した内容を開発していきました。 おわりに 次に「要件定義」のフェーズに入りますが...今回の解説はココまでです。ディレクターのお仕事について、ちょっとだけ興味湧いてきましたか？？ 続きはまた次回のブログで。 連載記事はこちら https://developers.gmo.jp/technology/10336 https://developers.gmo.jp/technology/11603 https://developers.gmo.jp/technology/12838