新着 の記事一覧

みなさま、こんにちは。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ペイメントゲートウェイ採用ページ 

GMOインターネットグループの開発者向け新卒技術研修【GMOテクノロジーブートキャンプ】（以下GTB）は、グループ横断で精鋭の講師40名超が登壇し、新卒パートナーのための研修カリキュラムを作成しています。今回は、Webアプリケーションフレームワークの研修を担当した6名の講師チームにインタビュー！オンラインの研修をつくる難しさをどう解決したのか、チームで研修をつくるノウハウを赤裸々に語っていただきました。GMOペパボ株式会社EC事業部 ECグループ CRE/QAチーム　遠藤　太徳ホスティング事業部 ホスティンググループ 顧客獲得チーム　手島　尚人EC事業部 ECグループ CCXチーム　牧野　弘幸ホスティング事業部　ホスティンググループ　CRチーム シニアエンジニア　髙橋　邦彦ホスティング事業部 ホスティンググループ CRチーム　望月　眞喜GMOインターネット株式会社システム本部 お名前.com開発部 お名前フロントエンド　橋口 巧 新卒研修を初のフルオンラインで実施した2020年 チームメンバーはどんな経緯でアサインされたのか 遠藤弊社VPoE柴田からSlackでメッセージが流れてきまして、『Laravel教材で研修を設計したい人いますか』と。とてもフランクな声掛けがきっかけでしたね。そこで、Laravelを触っていたこともあり、ぜひやってみたいということで僕と手島さんが手を挙げました。 そこから牧野さん、望月さん、高橋さんもSlack上で巻き込みました。ものの2～3分で5名が集まり、話が上がったその日にチームとして結集しましたね。手島 研修をつくるために議論したこと 遠藤チームで研修をつくっていく上で、まずWebアプリケーション開発に関する理解のゴールをどこに置くのかを検討しました。基礎知識としてAPI、HTTP、プロトコルなどをどこまで盛り込むのかなどは議論しましたね。 エンジニアなので、どこまでも説明したい欲があるのですが……笑講義進行において必要でないものについては積極的に削る方向で、あまり難しくなりすぎないようにというところは意識しましたね。高橋 牧野GTB全体の話に広げると、グループ横断で研修を受ける貴重な機会で、最終課題ではグループを超えてともに成果物をつくります。これは業務でグループシナジーを発揮してプロダクトをつくることに通じるので、講義の中で経験として積んでいただけたらとも思っていました。 1年目、初のオンライン研修で残った課題 全員が同じ内容/課題を遂行すること 手島昨年は講義を進める中でスピードやレベル感にばらつきが出たため、最終的に設定や環境がうまくいかないチームと、問題なく進めることができたチーム2チームに分けて実施に切り替えました。結果的にはどちらも満足のいくサポートができたのですが、本来1つの道筋で遂行することが理想だったので講師陣の課題として残りましたね。 1つのチームで進行することになぜ僕らがこだわっているかというと、失敗のやつまずきの事例をみんなで共有できることこそが研修の意義だと思っているからです。成功した筋だけをなぞるなら、講義である必要も同じ空間で研修を受ける必要もないと思うんですね。1つでも多くの学びや発見を見いだす場を提供する必要があると思っていました。牧野 リモートでのサポート体制 遠藤講義の進行以外で、具体的にはWindowsのソフトウェアが起動しないなどの事象が起こり環境面のサポートにもかなりリソースが取られました。そこで、2年目もリモート環境で研修実施になるのであれば、知見を兼ね備えたサポーターを増やすをいうことは急務でした。 先にお伝えした通り、当初1チームで講義進行を予定していたため、急遽2チームに分かれたことで講師の布陣が変更となりました。どんなトラブルが起こるのかやってみないとわからないところがありますが、それを想定して講師を確保することが大事だと感じましたね。高橋 昨年の研修詳細については以下をご参照ください。GTB2020 Webアプリフレームワーク入門/REST API入門 前編GTB2020 Webアプリフレームワーク入門/REST API入門 後編 2年目もフルオンライン開催が決定 インターネットから橋口さんが参戦！ ペパボ5名の講師チームに助っ人としてアサインされた橋口さん。グループ横断チームへのジョインについて正直な思いをお聞きしました。 橋口グループ会社連携でペパボチームに参加させていただきました。すでにチームとして完成されている中に入ることになったので、最初はアウェーかなと思っていたんです。でもチームが本当に和気あいあいとしていて、そんな雰囲気の中で過ごすうちに『自分もペパボの人間なのでは……？』と思うことが増えていましたね。 今このタイミングで改めて橋口くんの思いを聞けてうれしい！！！笑手島 橋口チームで研修をつくる経験ははじめてでしたが、いかに完成したチームに溶け込むか、自分が求められている役割を全うできるかを意識して参加していました。実は去年もGTBの講師として参加していたのですが、1人講師だったので、ゴールや目的の精査・ワークショップの設計・資料の落とし込みをすべて1人で行いました。とにかく1人は大変で。笑研修をチームでつくれることの心強さは誰よりも実感していましたね。 1年目の課題を踏まえた研修のアップデート 全員が同じ内容/課題を遂行すること 手島今年は昨年の反省も踏まえて、あらゆる想定の上で以下の通りチーム内での役割を決めました。結果、今年はチームとして目標としていた『1つのチーム』で全カリキュラムを終えることができました。とても自走力の高いチームであることが我々の強みだと自負していますが、それぞれの得意分野を生かし、足りないところを補い合いながら調整してきた結果だと思っています。 2年目から参加している僕から見ていて、結論昨年の課題はクリアになっていたのではと思います。メイン講師が率先して参加者が発言しやすい雰囲気づくりをしており、サブ講師がチャットで進行をフォローしていたりと講師1人1人が役割を全うできていたと感じます。橋口 リモートでのサポート体制 2年目のオンライン研修をつくってきたチームとして培ってきたノウハウ・リモート環境におけるサポート体制のポイントをお聞きしました。 ライブ感のあるチャットの活用参加者が主体的に講師として活躍できる進行 牧野講義の本質ではなく、関連することについてチャットで質問が来ることもあります。そういったものについては、全体進行は止めず、サブ講師がチャットでフォローしました。というのも、YouTubeやニコ生などではこうした関連内容が、本編と並行してチャット上で飛び交うというのはスタンダードなんですよね。それって、知識の定着としてもより深めることができると思うんです。ある程度参加者が、いろいろ忙しいくらいの感覚が楽しく見れたりするのかなと思っています（実は昔ニコ生の放送主をやっていたこともあるので）。 たしかに！あと、講師6名対新卒パートナーの講義構成にしないというのもとても有意義なオンライン研修をつくるポイントだと思います！躓いた箇所を確認するため全体に画面共有をすることがありますよね。そういった場面で、もちろん講師は確認するのですが、早く進行している新卒パートナーたちが率先して解説してくれたり、意見を交わしたりする時間が生まれます。去年講義内容を深めることができた要素の1つだと思いましたので、今年は意図的に仕掛けをつくろうということは考えていました。高橋 今年の研修詳細については以下を参照ください。GTB2021 Webアプリフレームワーク入門/REST API入門アップデート編 チームで研修をつくるむずかしさと楽しさ 同じペパボ社内でも事業部が違うので通常絡みがないんです。事業部、そしてグループ会社を越えたメンバーと同じ目標を持ち、目線を合わせて0→1を生みだしていくことはとても楽しいと感じますね。遠藤 望月私は立場的にも助けてもらう立場だったので、研修をつくる過程を通して、チームメンバーから技術的に学ぶことが多くプラスしかなかったですね。楽しい、ためになるという感覚でした。個人的には新卒メンバーと近い立場から意見が言い合えるという、知らないが故のみたいなところが期待されていたところだと思っていたのでそこを意識して取り組みました。 1人でコンテンツをつくると、自分の考え方や知識で形づくられてしまいますよね。でもチームだと常にレビュアーがいるという点で、うまく機能すれば有益な経験と優れたコンテンツを生み出すことができると思います。私たちはこの先も意見を出し合い、最適解を見出し続けることができるチームでありたいと思っています。高橋 望月ペパボの文化でわたしたちが大切にしている3つのことの中の1つに、『もっとおもしろくする』という指標があるので、迷ったらできるだけ楽しめるほうを選択します。そしてとにかく納得のいくまでしゃべり続けますね。笑　そういった姿勢がチームにプラスに影響していると思いますし、楽しいところです。 チームの輪に入ってみなさんが徹底的に熱い議論を交わしているのを初めて目の当たりにしたときは、ちょっとびっくりしました！橋口 牧野自分ひとりだと想定通り以上のものは生み出せないですが、チームでつくることで多方面に考え方や軸が展開されます。それを整理しまとめることが難しくもあり、おもしろいことであるなと思います。自分の利害や好みを超えたところで、『最高の研修をつくる』という共通目的を持ち議論できることが楽しいですよね。 GTBに期待すること 橋口新卒の方目線での話ですが、研修が終わり実業務に入るとわからないこと、つまづくこともあると思います。そんなときにGTBが立ち返れる原点であればと願います。そのために、講師はよりよい講義を提供する必要があると背筋が伸びる思いです。 GTBはとても有意義な取り組みであると思っています。いろいろな方と仕事をしていく上で大切なHRTを学べる場です。『価値観から入り、手を動かし、ものをつくる』この経験自体が配属後も活きるものであると思います。グループ会社横断で選りすぐって講師がアサインされているので、講義の質も非常に高く、チーム開発において自分がどう立ち振る舞うのかに気付くきっかけにもなります。GTBでは、その重要性や経験をお伝えしていけたらいいなと思います。望月 手島『講師として教える』ではなく、気づきのきっかけを提供する立場でありたいと思いますね。僕らの研修を通して1つでも多くの学び、気づき、GMOインターネットグループの文化に肌で触れ、受講者にはインデックスとして持っておいていただきたいです。配属後も価値ある経験となれば幸いです。 さいごに GMOインターネットグループ横断でつくる新卒研修『GTB』では、様々なコンテンツを扱っています。2年連続で、オンラインという限られた環境においての研修となりましたが、いかに伝えるべきか、楽しく学べるか思考を止めず改善を重ねた講義が今後の新卒パートナーのキャリア・業務における糧となることを願います。 さいごまでお読みいただきありがとうございました。

GMOインターネットグループでは、新卒エンジニアへの研修として「GMOテクノロジーブートキャンプ」をリモートで実施しております。今回講師陣は昨年の振り返りを元に、研修内容をアップデートいたしました。詳細は下記内容をご確認ください。 GMOテクノロジーブートキャンプ GMOインターネットグループではGMOテクノロジーブートキャンプ（以下GTB）と題して、各社の先輩エンジニアが新卒エンジニアへ研修を行う仕組みがあります。 2021年も2020年から引き続き、約40名の新卒エンジニアに対してリモートで研修を行うことになりました（去年の内容についてはGTB2020 Webアプリフレームワーク入門/REST API入門 前編・GTB2020 Webアプリフレームワーク入門/REST API入門 後編をご覧ください）。 研修内容をより良くするための工夫 研修を行うにあたって、まず最初に講師陣でキックオフを行いました。話し合いを進める中で、講師ひとりひとりから「去年のふりかえりを元に研修内容をもっとよいものにしたい」という熱い想いが伝わってきました。アップデートすることになった内容のうち例を挙げるなら、ハンズオン資料の更新やセキュリティに関するパートの追加、使用するフレームワークのバージョン選定などです。しかしながら講義時間は9時間と、去年と比較して3時間も短くなっていました。そのような中で研修の内容を減らすことなく、むしろボリュームアップした研修を行うために取り入れた工夫をかいつまんでご紹介いたします。 続きは以下から…… https://developers.gmo.jp/technology/9088 https://developers.gmo.jp/technology/9693 https://developers.gmo.jp/technology/10059

少し前までは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触ってみた"の記事に進む...かなと。

ISUCON11にプラチナスポンサーとして協賛いたします！是非ご参加ください。 ISCONとは ISCONは「Iikanjini（いい感じに） SpeedUp Contest」の略で、お題となるWebサービスを、決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです。当初60名で始まった2011年の開催から、年々規模を拡大し今回で11年目となるそうです。GMOインターネットグループでは、プラチナスポンサーとして本イベントを全力応援いたします！ 今回プラチナスポンサーとしての協賛ですが、2018年に実施されたISUCON8ではインフラスポンサーとしてConoHaのサーバーをご提供したこともあります。 https://developers.gmo.jp/technology/9607 イベント概要 参加受付開始2021年6月28日（月）10:00からを予定 オンライン予選2021年8月21日（土） オンライン本選2021年9月18日（土） 運営：LINE株式会社 さいごに 「ISUCON事前講習」や「メンバー募集告知」などが公開されていますので、是非公式ブログをチェックしてみてください！ ISUCON公式BLog　https://isucon.net/

こんにちは。デベロッパーリレーションズチームの村上です。皆さんリモートワークされていますか？今回は東京-福岡-ベトナムと拠点をまたいで開発を行っている私のチームで、普段どのようなツールを使ってコミュニケーションを取っているのか紹介していきます。 はじめに コロナ禍になって以降、リモートワークされている方が増えましたよね。弊社は国内の上場企業としてはもっとも早く大規模なリモートワークを開始しました。参考プレスリリース：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の構成はかなりオススメですね。

25回目のGMO Developers Nightは、GMOインターネットグループで行われている新卒エンジニア向けのグループ合同研修（GMO Technology Bootcamp）の内容をお届けします。テーマは「Web基礎」です。 イベント概要 開催日　：6月29日（火）時間　　：20:00-21:30開催方法：オンライン主催　　：GMOインターネット株式会社 こんな方のご参加大歓迎 Webについて学びたい学生基礎をキャッチアップしたい若手エンジニアGMOインターネットグループに興味のある学生または若手エンジニア タイムテーブル 時間コンテンツ19:55開場20:00オープニング20:03講義・ワークショップ21:20質疑応答21:30クロージング 申込方法 以下ページからお申込みください。 GMO Developers Night＃25　プログラミング基礎研修申し込みフォーム 講義トピックス WebとはなにかURI概要HTTP概要HTML概要 講師プロフィール 成瀬 允宣＠nrslibGMOインターネット株式会社デベロッパーエバンジェリスト　プログラマ 業務システム開発からキャリアをはじめ、ゲーム、Web と業種を変えながらアプリケーション開発全般に従事。得意領域はソフトウェア開発設計全般。2021年のGMOインターネットグループ合同研修では「Web基礎」「オブジェクト指向」「フロントエンド」を担当。 著書「ドメイン駆動設計入門　ボトムアップでわかる！ドメイン駆動設計の基本」（翔泳社） 参加者特典 申込者限定特典：アーカイブ動画視聴2週間！ フォームから申込登録いただいた方のみ、イベント後２週間限定配信のアーカイブ視聴が可能です。 参加者特典：合計¥30,000分のアマゾンギフト券！ 実施後のアンケートにご回答いただいた方の中から抽選で10名様にアマゾンギフト券3,000円分をプレゼントいたします。 申込方法 以下ページからお申込みください。 GMO Developers Night＃25　プログラミング基礎研修申し込みフォーム