技術情報 の記事一覧

こんにちは。デベロッパーリレーションズチームの村上です。今回は私が開発マネージャーを務めるとくとくBBプロダクトチームについて書いていこうと思います。多拠点開発に興味のある方にぜひ読んでいただけたら嬉しいです。 多拠点開発における組織変遷 チーム紹介をする前にまず、多拠点開発ならではのマネジメントの苦悩と、現在のチーム編成に至るまでを簡潔にお伝えできればと思います。組織全体で俯瞰すると複雑になるので、今回は私を主軸として組織変遷を簡潔にお伝えします。 組織改善前 kitaQの開発チームは、『ConoHa、Z.com』、『お名前.com』、『とくとくBB』の開発を担当していました。各サービス毎にマネージャーを配置し、プロジェクトマネジメントとヒューマンマネジメントを行っていました。 プロジェクトマネジメント案件進捗管理、メンバーアサイン、技術フォロー等ヒューマンマネジメント工数管理、チーム内調整、評価など マネージャーの業務としては他の組織と相違ないと思うのですが、改善前の私たちの組織では、マネジメントの役割を拠点で分けて行っていたためマネジメントの工数が無限でした。 3つの商材にまたがってヒューマンマネジメント、とくとくBBに関してはプロジェクトマネジメントも開発業務も行っておりましたため、マネージャーとしてメンバーが気持ちよく開発に集中できる環境を用意することがなかなか難しいことも課題であると感じていました。具体的には以下です。 マネジメント範囲が広すぎて、開発で困っていることをタイムリーに解決できない3つのサービスそれぞれに関わるメンバーの状況をすべて把握する必要があるが、現実的に難しいことがあった 組織改善後 そこで上記で示しているとおり、多拠点にまたがって1つのチームとして稼働していく体制へと改善されたのです。 サービスごとに縦割りにし、ヒューマンマネジメントもプロジェクトマネジメントもすべて1人のマネージャーが請け負うことで、改善前にあげていた課題を少しずつクリアにすることができました。たとえば以下のようなことが改善されました。 マネジメントすべきメンバーがある程度固定されたことでTODOが把握できるようになったタイムリーに困難なことに対応できるようになったマネジメントコストが削減されたことにより、私自身の開発工数が捻出できるようになった上記をもって、開発の質があがった 多拠点開発チームの特徴 ここからは、現在の私のチームについてご紹介します。 特徴としては、メンバー構成が多拠点に跨っていること、構成するメンバーのほとんどが若手が多いことです。北九州に私を含む6名、東京に1名、ベトナムに2名という形で開発を行っています。 メンバーとうまく意思疎通ができるかどうかは非常に大事です。なのでコミュニケーションにかける時間を大事にしています。メンバーのほとんどが新卒という点は、まだまだ課題の方が多くありますがこれからの成長に期待できるかなと考えています。あとは若いメンバーが多いので、自分の知らない分野の話や考え方が聞けたりして勉強になるなと感じる部分も多いです。 主な業務 とくとくBBのnaviと呼ばれる、とくとくBBの会員向けコンパネの開発を行っています。取り扱っているサービスの申し込みや、契約情報の確認ができるサイトです。具体的な業務としては、新サービスを取り扱う際の開発、事業部の施策対応、不具合やCSからの問い合わせ対応を行っています。お客様がよりわかりやすく、使いやすいサイトを作っていってます。上記のサイト管理以外にも、サイトのリニューアル開発も並行して行っています。リニューアル開発とはなにかというと、現在naviはサービス初期から使われている旧サイトから、現サイトへと機能移管を行っています。ただリニューアル開発のスピードより、新サービスの展開スピードのほうが早く、中々移管が進んでいないのが悩みの種だったりします。。 使っている技術 現在使用しているのは「ASP.NET MVC」で言語は「C#」を使用しています。フロント側は「jQuery」を使っています。少し昔の定番のような構成です。JavaScriptのフレームワークといえばReactやVue.jsを使っていないの？って思われるかもしれませんがまだまだ現役で使っています。バックエンドのバッチやAPIと連携する為にSQLでクエリも書きます。ただ作ってから結構な年数が経過しているので、通常の開発と並行して色々とアップデートしたいなと感じています。たとえば実際にコード書いてるとTypeScriptを使うと楽だなと感じる部分が出てきてたりします。 チームのミッション チームのミッションとしては「業務領域の拡大」と「エンジニアの育成」を掲げています。 業務領域の拡大 先ほど、とくとくBBの会員向けコンパネの開発を行っているとお伝えしましたが、メンバーの増えてきたので、さらにkitaQでできる開発を増やそうと考えています。 とくとくBBには入会サイトや申込みサイトが多数存在するので、そこをすべてkitaQで開発できるのが私の野望だったりします。 エンジニアの育成 もう1つはエンジニアの育成です。若手エンジニアには、スキルアップとサービスへの理解を深めてもらいます。とくとくBBは歴史の長いサービスで現在150万以上の会員様がいらっしゃいます。その分だけサービスの数も多いですし、仕様はどれも違ったりするので理解度を深めるというのは非常に大事だったりします。 具体的な施策 下記の施策を行うことで、メンバーの成長の加速させています。 サービス説明 サービスへの理解を深めてもらう為、東京・北九州のチーム合同で古いサービスから最近のサービスまでどういう仕組なのか、裏側のロジックはどうなっているのかというのを説明する時間を設けています。これのおかげで途中からジョインしたメンバーもサービスへの理解を深めることができていると実感しています。 コードレビュー これはどこもチームも当たり前のようにやっていますが、うちのチームではメンバー同士のでコードレビューに加え、最終的には私が必ずコードレビューを行うことで細かな部分への指摘もしっかり行えるようにしています。最初は私だけがコードレビューを行っていたのですが、コードをレビューするのも自分の実力になると思ったので、若手メンバーにもコードレビューをしてもらって、何かしら指摘できるように育ってもらおうとしています。 ペアプログラミング 結構な頻度で取り扱うサービスが増えるので、新規開発する機会が多いです。 若手メンバーによろしく！と振りっぱなしにせず、1枚の画面（オンラインではZoomの画面共有）で一緒にコーディングを進めたりします。ペアプロで開発するのはコストがかかってしまうのでは、という指摘をいただきますがペアプロですすめることで成果物の完成度は断然よくなります。検証中の不具合修正作業量も減っているので、やる価値はあると私は考えます。 まとめ まだまだチーム的にもメンバー的にもこれからではありますが、成長を考えるとこれからが非常に楽しみなチームになっています。若手エンジニアが早く一人前のエンジニアになれるように、私も頑張って支えていこうと思います。

以前、クラウドフローからデスクトップフローを呼び出すハイブリッドフロー（RPAを作りましょう　ハイブリッドフロー編）を紹介しました。プラミアムアクションの「Power Automate Desktopで構築したフローを実行する」を利用することで実現可能となっています。これとは反対にデスクトップフローからクラウドフローの呼び出しは残念ながら現時点では明確なアクションとしては提供されていませんが、いくつかの機能を組み合わせることで実現可能となっています。今回は、ハイブリッドフローリバースということで、デスクトップフローからクラウドフローの呼び出し方を紹介します。今回作成するのは、クラウドフロー側で用意した“Teamsにメッセージを投稿する”というフローをデスクトップフローから呼び出すといったものになります。 ハイブリッドフローで必要なライセンス 前回紹介したハイブリッドフローの作成同様、今回もPower Automateの有償ライセンスが必要となります。最低限「Power Automate per user with attended RPA（1ユーザーあたり￥4,350/月）」が必要となります。 ※参照※ https://developers.gmo.jp/technology/8233 クラウドフローの作成 まずはPower Automateのクラウドフローの作成から。Power Automate Desktopのデスクトップフローから呼び出されるための設定を行います。今回のポイントはクラウドフローのトリガーとして「HTTP要求の受信時」を利用する部分です。 作成するのは「自動化したクラウドフロー」となります。 ここはスキップで進みます。 “http”のキーワードで検索して、トリガーの中から「HTTP要求の受信時」を選択します。 今回のフローはTeamsへメッセージを投稿する機能となるので、以下のJSONスキーマを入力します。 {　　　"type": "object",　　　"properties": {　　　　　"subject": {　　　　　　　"type": "string"　　　　　},　　　　　"message": {　　　　　　　"type": "string"　　　　　}　　　}} 次に、Teamsのアクションから「メッセージを投稿する」を選択します。 先ほどの「HTTP要求の受信時」で入力したJSONスキーマを読み取って、「件名」と「メッセージ」は動的なコンテンツから選択可能となっています。 いったんここまでの内容で名前を付けて保存します。 保存後「HTTP要求の受信時」を確認すると、「HTTP POSTのURL」が発行されているのが確認できます。こちらをコピーして取得しておきます。 URLのデコード 取得したURLはエンコードされているので、この後、Power Automate Desktopのデスクトップフローで利用するにはURLデコードを行っておく必要があります。 UrlEncode.net（http://urlencode.net/）などでもデコードは可能ですし、PowerShellでも以下のようにデコードできます。 $Url = "取得したUrl"［System.Web.HttpUtility］::UrlDecode($Url,［Text.Encoding］::GetEncoding("sjis")) デスクトップフローの作成 続いて、Power Automate Desktopでデスクトップフローを作成します。 アクションの中から「Web」-「Webサービスを呼び出す」を選択します。 以下の内容を設定して保存します。 URL先ほど取得してデコードしたものを入力しますメソッドPOST受け入れるapplication/jsonコンテンツタイプapplication/json要求本文{"subject":"TEST2020", "message":"テストです！"}要求本文をエンコードしますOFF 実行してみましょう！ 上手くいきました！成功です！ 参考までに、デスクトップフローで「Webサービスを呼び出す」の部分を「PowerShellスクリプトの実行」に置き換えることも可能です。 $Url = "取得したURL"$postText = @{subject="TEST2020"; message="テストです！"} | ConvertTo-Json -Compress$postBody = [Text.Encoding]::UTF8.GetBytes($postText)Invoke-RestMethod -Method POST -Uri $Url -Body $postBody -ContentType application/json 以上がデスクトップフローからクラウドフローを呼び出すハイブリッドフローリバースとなります。 さいごに デスクトップフローをクラウドフローが連携することでPower Automateの利便性は確実にアップします。 今回のようにTeamsを絡めてのメッセージングや、デスクトップフローからOneDriveにファイルを保存した後にクラウドフローで処理するなどアイディア次第で色々便利に使えそうです。 これぞハイブリッドフローという使い方を見つけてみてください。

技術研究チームの活動の一環で、スクラムを体験するワークショップを開催しました。本シリーズではそれらの実施方法や様子をお届けします。第３回のテーマはピンポン玉を使ったスクラムワークショップです。 シリーズ一覧 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インターネットの吉田です。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年目の春の一瞬を切り取った順位であり、本当のゴールは数年後の努力の積み重ねではないでしょうか。 当社グループに入社いただいた新卒パートナーの皆さんをはじめ、私自身も初心忘れるべからずだということをここに記しておこうと思います。今後も研鑽を積み重ね、社会に役立つプロダクト開発を今後も続けていきたいと思いを馳せたところで今回のエントリーを締めたいと思います。