技術情報 の記事一覧

こんにちは。GMOインターネットでセキュリティ担当している割田です。今回は、セキュリティ対策でテストに分類される「ペネトレーションテスト（ペンテスト）」を実施するペンテスターのスキルを効果的にアップさせる方法についてご紹介します。 はじめに セキュリティ対策には、色々な段階のものがありますが、一般的に脆弱性の確認手段としては、『診断』と『テスト』があります。 診断網羅的に脆弱性の可能性を確認テスト実際の挙動で脆弱性有無を確認 また、それらテストの中に「ペネトレーションテスト」というものがあります。 「ペネトレーションテスト」とは、対象環境の構成要素を元に攻撃シナリオを作り、そのシナリオと専門知識を武器に、対象環境の様々な脆弱性を深く調査するテストです。 そして「ペネトレーションテスト」の技術者を『ペンテスター』と呼びます。 ペンテスターに関する基礎知識 ペンテスターとペネトレーションテスト環境 ペンテスターが、ペネトレーションテストを学習するためには、テスト環境の準備が必要です。 テスト環境の構成要素 ネットワークを含むインフラ環境アプリケーションデータベースなど ペンテスターへの道 ここからはペンテスターへの道として、スキルアップ方法の課題を記します。 スキルアップ方法一覧 『ペンテスター』のスキルを効果的に向上させるには、サービス環境と同等の環境整備が必要であり、それら環境が無いとシナリオ作成や攻撃方法の幅が少なく効果的な学習ができません。学習環境を利用する方法として大きく分けて下記の3つがあります。 自力構築競技参加外部サービス利用 具体的には以下を指します。 1自力構築ローカル環境やConoHaなどのVPS環境に　●1から構築　●外部提供のものを利用して構築2競技参加外部や内部で開催される競技へ参加する　●ハードニングプロジェクト　●CTF(Capture The Flag)等への競技参加3外部サービス利用環境提供している環境を利用する　●OSCP資格勉強用環境　●Hack The BOX環境 環境構築における課題 しかし、実際問題、自力で環境構築する事は、とても大変です。具体的に以下のようなことが考えられます。 テスト環境自作の難点 ●複合環境の準備　サービス環境と同様の複合環境（OSなど）を用意する必要がある●脆弱性の準備　検証練習をするための脆弱性を持つ環境を準備する必要がある●攻撃シナリオの考慮　効果的に学習できるように複数のシナリオを考える必要がある●難易度の考慮　利用者に合わせた難易度の環境が必要である●初心者への考慮　初心者でも検証方法を理解するための資料（WriteUP）が必要である オススメのスキルアップ方法 上記で記した課題の解決策として、今回私が個人的にオススメしたい方法は、『外部サービスのHack The Box環境を利用する方法』です。 ※Hack The Boxとは、セキュリティをゲーム形式で学習できるオンライン学習　のプラットフォームです。色々な脆弱性を含むサーバ環境が複数用意されてお　り、サーバ環境の管理者権限を取得する事で、点数を得る事が出来ます。 参照：https://www.hackthebox.eu/ オススメするポイントは多くありますが、4つに絞ってご紹介します。 1.いろいろな環境が用意されている 様々なOS（Linux/Windows等）多種多様な脆弱性色々な攻撃が体験できるシナリオが用意されている 2.難易度の範囲が広い 初心者用でも楽しめる環境がある経験者も楽しめる難易度の高い環境もある 3.困ったとき用のWriteUPがある 攻略方法のヒントが公式に記載された資料(WriteUP)がある※動画などが付いているものもあり初心者でもわかる内容になっている。 4.ゲーム要素もあり楽しめる 点数制度があり、ゲーム感覚でクリアを楽しめる簡単なものから難しいものまで幅広く環境があるサイト自体も遊び心がある作りになっていて楽しい ペンテスターがペネトレーションテストのスキルに集中して学習できる。また、初心者から熟練者までが、継続的に楽しみながらスキルアップ出来る良い環境だと個人的に感じています。 余談 実は、夏季休暇中の夜は『Hack the Box』に勤しんでいました。まだまだ遊び足りないので、ライフワーク的に続ける予定です。 弊社では、社内でのハードニングイベントも実施しますので、そちらの環境（内製）にも活かして行きたいと考えています。 おわりに 今回は、ペンテスターの効果的なスキルアップ方法として『Hack The BOX』をお勧めしましたが、興味もって頂けましたでしょうか。 セキュリティエンジニアの仕事は見えづらいものなので少しでも興味を持って頂けたら嬉しいです。

こんにちは、GMOインターネット株式会社の斉藤です。今回はEmacsからVS Codeへの乗り換えについて書きたいと思います。 はじめに 今月は勤め先のお盆休みがあったり、コロナ感染者増で完全在宅勤務への切り替えがあったりでバタバタしている月でした。そしてお盆休み中に自宅の開発環境をM1 Macに移行しました。前からやろうと思っていたのですが、さすがにアーキテクチャ変更を伴う大きな変更になるのでトラブルも予想されます。なので長めのお休みの方にやるのがベターだと判断しました。ステイホームが推奨されていますしちょうど良いですね。 https://twitter.com/hironobu_s/status/1427199287557980160 いろいろトラブルはあったものの、在宅でのお仕事はM1 Mac上で行っています。勤め先からリースされている2018モデルのMacBook Proより全然パフォーマンスは良いですね。 このあたりの乗り換え話はまた機会があれば書こうと思います。 EmacsからVS Codeへ乗り換え 今回は別の乗り換えのお話しです。私は普段Emacsを使ってコードを書いていますが、去年後半から今年に書けてほぼVSCodeへ移行しました。もはやEmacsを使うのは、ターミナル内でちょっとコードを書きたいときくらいになっています。 Emacsから乗り換えるに当たって、数多くの機能拡張のお世話になっています。とくにキーバインドは手に馴染んでいるので今さら変えるのは難しいのですよね。Emacsは独自のキーバーインドを持っており、これが魅力ではあるのですがエディタの乗り換え時には大きな障壁になります。 ちなみに、私は現在以下の機能拡張を利用しています。 Awesome Emacs Keymap https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx vscode-emacs-indent https://marketplace.visualstudio.com/items?itemName=sakapoko.vscode-emacs-indent vscode-emacs-tab https://marketplace.visualstudio.com/items?itemName=garaemon.vscode-emacs-tab Emacs kill-line https://marketplace.visualstudio.com/items?itemName=hiro.emacs-kill-line キーバインドの変更だけでそれなりに多くの拡張を入れていると思います。ただこれでなんとか実用に耐えるキーバーインドを構築することができました。 自作の機能拡張について 一番下のEmacs kill-lineは私が作った機能拡張です。 乗り換えの際に、1つだけ私が常用しているキーバインドで既存のVS Codeの拡張には存在しないものがあったので、仕方なく自前で作りました。 EmacsはCtrl+Kで行を削除したり行の内容をコピーできます。このキーバインドにはkill-whole-lineというオプションがあり、これを非nilにすると行頭でこのキーを叩いたときに改行文字を含めて行全体を削除すると言う挙動になります。これをエミュレートするVS Codeの拡張が存在しなかったのです。 https://ayatakesi.github.io/emacs/24.5/Killing-by-Lines.html 客観的に見て「そんな細かいこと・・・」とは思うのですが、やはり常用しているキーバインドは無くなると非常に困りますし、この拡張は100人くらいインストールされているので、世界にそれだけ困っている人がいたと言うことで・・・。 さいごに VS Codeは機能拡張をTypeScriptで簡単に書けるのが素晴らしいですね。チュートリアルもとてもわかりやすいので、エディタ乗り換えで困っている人は自前で作ってしまっても良いと思います。 Your First Extension | Visual Studio Code Extension API 以前にGo言語向けの機能拡張を作った話もブログに書きましたので、そちらも良かったらご覧ください。 https://developers.gmo.jp/technology/4714 それではまた次回お目にかかりましょう。

こんにちは。デベロッパーリレーションズチームの村上です。今回は私が開発マネージャーを務めるとくとく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