株式会社クイックのWebサービス開発blog

HAPPYなサービスプランナー・エンジニア・デザイナーのブログです。

Amazon WorkSpacesの通信量の検証（結果と方法）

AWS Amazon WorkSpaces

こんにちは、インフラエンジニアのまっつんです。 弊社ではAWSを利用して、サイトの構築や運用などを行っています。 サーバーもクライアントもAWSにし、AWS内部で通信が完結できれば制御が楽になってハッピーになれるのではないかと思い、実際にハッピーになれるか検証してみました。

業務でAmazon WorkSpacesの様々な検証を行う機会があり、その中でAmazon WorkSpacesを利用した場合の通信量をWiresharkを使って測定しました。 今回は、その結果と計測方法についてまとめたいと思います。

結論

様々な環境によって前後するため一概に言えませんが、私たちの環境でAmazon WorkSpacesを使用すると、以下のような通信量が発生しました。

  • ネットサーフィン：多くても5Mbps前後、瞬間的に20Mbps
  • ネットで漫画を読む：5Mbpsを中心に前後
  • 動画視聴：7.5～10Mbps
  • Web会議：20～30Mbps

個人的な感想としては、思ったより通信量が多いという印象です。 Amazon WorkSpacesを導入する場合は、契約しているネットワーク帯域を加味しながら導入規模を考えないと、帯域を使い果たして通信ができなくなる状態にならないように気をつける必要があります。

この結論にいたるまでの検証方法を紹介します。

Amazon WorkSpacesとは

AWSが提供している仮想デスクトップ（VDI）サービスで、様々なタイプのスペックを従量課金で使えるサービスです。 画面を転送するので、画面に動きがいっぱいあると通信量が増えます。

Wiresharkとは

結構昔から存在しているパケットキャプチャツールです。 パケットキャプチャというのはネットワーク上で流れているパケットの中で、NICに流れてきたパケットを収集して解析することを指します。 パケットが、どこからどこに、なんのプロトコルで、どのぐらいの量が流れているのかというのが分かります。

①計測環境

計測をする上で、必要な情報をまとめます。

■接続元端末の環境

■Amazon WorkSpacesの環境

Amazon WorkSpaces Clientを使って接続した場合は、通信先のIPアドレスが接続する度に変わります。 IPアドレスで絞り込む場合は、まずAmazon WorkSpacesに接続してWiresharkで通信しているIPアドレスを調べ、それを使って絞り込む必要があります。

調べるのが手間だという場合は、下記ページの「WorkSpaces の IP アドレスとポートの要件」で、通信に必要なIPレンジで絞っても大体の通信量は計測できます。 https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/workspaces-port-requirements.html

今回の場合は

■ヘルスチェックサーバー

  • 18.178.102.247
  • 54.64.174.128

■WSP ゲートウェイサーバー

  • 3.114.164.0/22

を計測できれば大丈夫です。

②Wiresharkでの計測方法

計測したいインターフェース選び

パケットキャプチャしたいインターフェースを選びます。 私の環境だと「イーサネット3」が計測したいインターフェースなので、「イーサネット3」をダブルクリックします。

ダブルクリックした瞬間からパケットキャプチャが始まります。

グラフの準備

ツールバーの「統計」から「入出力グラフ」を選んでグラフを出します。

グラフの準備

入出力グラフが出たら

  • Display Filter：グラフにしたいIP（今回は3.114.164.0/22）
  • Style：Line
  • Y Axis：Bit
  • インターバル：1秒

に変更します。 ※「Y Axis：Bit」にしないとbps（bit per second）での計算が難しくなるので、必ず「Bit」で。

ここまで出来たらOK。 あとは実際にAmazon WorkSpaces上で操作をすれば、実際に使った通信がグラフ化されていきます。

グラフの見方

実際にグラフが出力されるとこのようになります。

グラフの縦軸はBitで表記されているため、bpsに変換して解釈します。

「Bits/1秒」とあるので、bps（bit per second）と同じ意味です。 縦軸に「1・107」や「2・107」とありますが、累乗を計算し直すと 「1・107」 = 10,000,000bit = 10,000Kbit = 10Mbit となるため、それぞれbps換算すると 「1・107」= 10Mbps 「2・107」= 20Mbps となります。

このグラフは、「瞬間的に20Mbpsを出したあとに10Mbps前後の通信をして、途中で5Mbpsを下回ったあとに再度10Mbps前後の通信をしている」ということを意味しています。

③実際の通信検証

実際にAmazon WorkSpacesを使って、様々な状況を想定した通信量を検証してみました。

  • ネットサーフィン
  • ネットで漫画を読む
  • 動画視聴
  • Web会議

ネットサーフィン

ネットサーフィンをAmazon WorkSpaces上でやった場合の通信量です。

  • 画面の切り替えがあった時に通信量が増える
  • 広告などで意図せず動画が流れた時に通信量が増える

という傾向でした。

ただ、基本的なネットサーフィンであれば多くても5Mbps前後の通信量でした。

ネットで漫画を読む

インターネットの漫画をAmazon WorkSpaces上で読んだ場合の通信量です。 ※弊社では看護師さん向けのサイトを運営していますが、その中で漫画も掲載しています。 https://www.kango-roo.com/comic/9084/

  • 漫画の画像をスクロールした時に通信量が増える
  • ネットサーフィンのときよりもグラフの上下が激しい

という傾向でした。

全体的にネットサーフィンより通信量が多くなっています。 平均しにくいグラフですが、5Mbpsを中心に前後する通信量となりました。

動画視聴

youtubeなどの動画をAmazon WorkSpaces上で見た場合の通信量です。

  • 安定して大量の通信をしている
  • 画面全体の動きが激しいと通信量が増える

という傾向でした。

動画の内容にもよりますが、7.5～10Mbpsを間を推移していました。

Web会議

Google meetをAmazon WorkSpaces上で開いてWeb会議をした場合の通信量です。

  • カメラオンの参加者が多いと通信量が増える
  • カメラオンの参加者の動きが多いと通信量が増える
  • 誰かが画面共有すると通信量は減る

という傾向でした。

この時は30人以上が集まるWeb会議だったため、表示されるリモート画面に比例して画面描写が多く、20～30Mbpsという通信量になりました。 会議の最後にお辞儀で頭を下げたりする人が多かったので通信量が増えていました。

あとがき

通信量を実測値として出してるところは少ないので、Amazon WorkSpacesを検討する上で少しでも役に立つといいなと思います。

今回は通信量の検証に絞って書きましたが、Amazon WorkSpacesを使う上で他にも色々な検証をしています！

このあたりは日常的な業務というよりも、新しいことを進める上での挑戦としての意味合いもあります。 一緒に新しいことに挑戦したい人がいれば、いつでもクイック採用窓口にご連絡ください！

クイックでのJenkinsの活用方法について

こんにちは、インフラチーム所属のにっしーです。半年前くらいから体重が5kg増えたのが最近の悩みで、良いダイエット法がないか模索しています。

普段の業務ではAWSやDatadogをよく扱っています。自分はクイックに入社してから初めてJenkinsに触れたのですが、開発・運用の自動化をサポートするツールとしてとても便利だなと感じました。 今回は、そのJenkinsのクイックにおける活用方法について紹介してみたいと思います。

Jenkinsとは

最初に、Jenkinsを知らない人向けに、Jenkinsがどのようなものであるかの簡単な説明をこちらの記事から引用します。 (記事: https://openstandia.jp/oss_info/jenkins/)

Jenkins（ジェンキンス）は、開発作業の自動化を目的としてJavaで実装されたオープンソースのサーバーソフトウェア(CIツール）です。 Jenkins（ジェンキンス）は、主に以下の2つの技術的な実現に役立ちます。

ソフトウェア開発プロセス全体の単純作業を自動化すること

  • 継続的デリバリー(CD)

継続的インテグレーションにより出来上がったソフトウェアを、テスト環境や本番環境に自動的にリリースすること

クイックでは、上記の開発・運用で発生する単純作業を自動化するために、数百以上のさまざまなジョブを日々実行しています。

↓Jenkinsのアイコン（エンジニアの方なら、見たことある方も多いはず）

Jenkinsを使うことのメリット

個人的に感じるJenkinsを使う上での利点として、

  1. オープンソースであるため、誰でも無料で使うことができる
  2. インストール手順などがネット上にたくさん存在するため、インストールが簡単
  3. プラグインシステムにより、簡単に機能を拡張できる
  4. ジョブの作成や実行、実行結果の確認などが全てGUI(ブラウザ)で操作できる

を挙げたいと思います。

特に、「4. ジョブの作成や実行、実行結果の共有などが全てGUI(ブラウザ)で操作できる」が自分の中で最も便利だと感じています。 このように感じる背景として、前職では個人のPCで自動化用スクリプトを実行しており、その場合だと、

といったものは当然チーム内で共有されている状態にありませんでした。 それに比較して、クイックでは自動化用スクリプトをJenkins上で実行することで、上記の各内容がサーバーに保存され、チームメンバーがブラウザからすぐに確認することができます。このように、 「ジョブの作成や実行、実行結果の共有などが全てGUI(ブラウザ)で操作できる」ことで、作業自動化の情報共有をチーム内で速やかに行える点がとても便利だなと感じています。

クイックでのJenkinsの活用方法

クイックでJenkinsを活用する代表的な目的としては、下記が挙げられます。

  • バッチ処理実行
  • デプロイジョブ実行
  • インフラリソースの構築
  • コスト削減を目的とした、サーバー起動/停止

このそれぞれの目的に応じてどのようにジョブを実行しているのか紹介します。

バッチ処理

JenkinsサーバーからWebサーバー/バッチ専用サーバーに接続し、Laravel等で書かれたプログラムを実行しています。 バッチ処理でパラメータを指定する必要がある場合には、Jenkinsのパラメータ付きビルドの機能で指定することが可能です。また、定期実行の設定により、時間を指定してのジョブ実行も可能です。

デプロイジョブ実行

クイックでは主なデプロイツールとしてcapistranoを使っており、

Jenkinsサーバー内でcapistranoによるビルド
↓
WebサーバーにSSH
↓
ビルドで生成されたファイルをデプロイ

といったデプロイ処理をJenkinsジョブの中で実行します。 この仕組みの利点としては、ジョブのパラメータ指定により、

  • 各環境 (Dev/Stg/Prd)
  • デプロイ時のアプリケーションファイルのブランチ
  • デプロイ先のサーバー

などを変えてデプロイすることができます。

インフラリソースの構築

クイックではインフラリソースの構築をJenkinsジョブから実行できるようにしています。 例えば、下記のような処理になります。

  1. EC2インスタンス起動
  2. ミドルウェア設定
  3. アプリケーションファイルのデプロイ
  4. サーバーの動作確認

この際、ジョブのパラメータを変えることにより、PJや役割に合わせて異なるサーバを起動できるようになっています。 Jenkinsジョブで上の処理を行えるメリットとして、複数人でのパラメータチェックを簡単に実施できる、というものがあります。例としては、本番環境のサーバーを起動する場合にパラメータの指定を間違えないように慎重に行う必要があります。JenkinsだとGUI(ブラウザ)から操作できるため、ブラウザを画面共有することでそのようなチェックをスムーズに行うことができるようになります。

コスト削減を目的とした、サーバー起動/停止

DevやStgなど、24時間起動する必要がない環境については、指定時間にサーバーを起動/停止することで、コスト削減を図ります。 具体的には、下記のようなジョブの実行設定になります。

  • 07:00 サーバー起動ジョブ実行
  • 22:00 サーバー停止ジョブ実行

このようにすることで、07:00-22:00以外の業務時間外はサーバーを停止し、サーバー費用を削減することができます。 また、指定時間にジョブが自動で実行されるのとは別で、手動でジョブを実行することにより任意のタイミングでサーバー起動/停止することもできます。

あとがき

最後までお読みいただき、ありがとうございました。 以上、クイックでのJenkinsの活用方法を紹介させていただきました。調べたところJenkinsには自分がまだ知らない機能やプラグインがありそうなので、今後はそういったものについても知識を増やしていけたらと思います。 開発・運用の業務を自動化してみたい方は、一度Jenkinsを試してみてはいかがでしょうか？

＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／

919.jp

SwaggerではじめるOpenAPI開発

こんにちは、ソフトウェアエンジニアのやぎーです。

今回はREST API開発のフレームワーク「Swagger」についてお話ししたいと思います。

こんな人におすすめ

  • RESTful APIをつくりたい
  • Swaggerって聞いたことあるけど触ったことがない
  • APIのドキュメント管理が大変
  • 簡単にモック環境を用意したい

Swaggerとは

まず、SwaggerはRESTfulAPIを構築するためのOpenAPIの仕様に基づいて構築されたオープンソースツールです。 主要な言語のAPIクライアントやモックサーバ、ドキュメントの自動生成などがおこなえます。

RESTful APIを構築するにあたってOpenAPIの記法に沿って定義しておくと、Swaggerを使ってドキュメントの作成・モックサーバーとの連携・コードの自動生成などが行える便利なツールになります。

環境構築

実際に触らないとなかなかイメージ出来ない人もいるかと思いますので、 今回はDocker上で下記の環境を作っていきます。

前提

Docker・Docker Composeの環境構築済み

使用するツール

ツール 概要
Swagger Editor OpenAPIのエディタ・ビューアが一緒になっているツール。画面上で編集した内容がリアルタイムで反映され、構文や仕様のチェックができます。
Swagger UI OpenAPIの定義ファイルをもとに、HTML形式で整形・表示が行える。エンドポイントや、パラメータ・レスポンス定義などが確認でき、設定してあるサーバーに対してリクエストの送信などもできる便利ツールです。
Stoplight Prism OpenAPI定義を渡すだけでモックが作れます。Swagger UIからこのモックに対してリクエストの送信が行えます。

用意するもの

docker-compose.yml

version: '3'

services:
  swagger-editor:
    image: swaggerapi/swagger-editor
    container_name: "swagger-editor"
    volumes:
      - ./openapi.yaml:/openapi.yaml
    environment:
      SWAGGER_FILE: /openapi.yaml
    ports:
      - "8001:8080"

  swagger-ui:
    image: swaggerapi/swagger-ui
    container_name: "swagger-ui"
    ports:
      - "8002:8080"
    volumes:
      - ./openapi.yaml:/openapi.yaml
    environment:
      SWAGGER_JSON: /openapi.yaml

  swagger-mock:
    image: stoplight/prism:3
    container_name: "swagger-api"
    ports:
      - "8003:4010"
    command: mock -h 0.0.0.0 /openapi.yaml
    volumes:
      - ./openapi.yaml:/openapi.yaml

openapi.yaml（サンプル）

下記は/petsに対する一覧取得／作成／ID検索の定義になります。
※書き方に関してはOpenAPI Specificationを参照

openapi: "3.0.0"
info:
  version: 1.0.0
  title: Swagger Petstore
  license:
    name: MIT
servers:
  - url: http://localhost:8003
paths:
  /pets:
    # 一覧取得
    get:
      summary: List all pets
      operationId: listPets
      tags:
        - pets
      parameters:
        - name: limit
          in: query
          description: How many items to return at one time (max 100)
          required: false
          schema:
            type: integer
            maximum: 100
            format: int32
      responses:
        '200':
          description: A paged array of pets
          headers:
            x-next:
              description: A link to the next page of responses
              schema:
                type: string
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Pets"
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
    # 作成
    post:
      summary: Create a pet
      operationId: createPets
      tags:
        - pets
      responses:
        '201':
          description: Null response
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
  /pets/{petId}:
    # ID検索
    get:
      summary: Info for a specific pet
      operationId: showPetById
      tags:
        - pets
      parameters:
        - name: petId
          in: path
          required: true
          description: The id of the pet to retrieve
          schema:
            type: string
      responses:
        '200':
          description: Expected response to a valid request
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Pet"
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
components:
  schemas:
    Pet:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: integer
          format: int64
        name:
          type: string
        tag:
          type: string
    Pets:
      type: array
      maxItems: 100
      items:
        $ref: "#/components/schemas/Pet"
    Error:
      type: object
      required:
        - code
        - message
      properties:
        code:
          type: integer
          format: int32
        message:
          type: string

上記2ファイルを設置してDockerコンテナを起動します。

docker-compose up -d

起動した画面

Swagger Editor

左のエディタでAPIの定義を変更すると、右側のビューアにリアルタイムで反映されます

Swagger UI

画像は一部分の切り出しになりますが、openapi.yamlに記述した内容が仕様として成形して見ることができます。

モックサーバーからの返却値を指定したい場合には「example」を定義することができます。

Pet:
  type: object
  required:
    - id
    - name
  properties:
    id:
      type: integer
      format: int64
    name:
      type: string
    tag:
      type: string
  # ここに定義
  example:
    id: 1000
    name: "Beagle"
    tag: "Dog"

右上の「Try it out」のボタンから、モックサーバーに対してリクエストを送信するとexampleに定義した値が返却されます。

コードの自動生成

Swagger CodegenやOpenAPI Generatorを使用することで、サーバーサイド・クライアントサイドのコードの自動生成にも対応しています。

自動生成されたコードに沿ってビジネスロジックの実装を行うだけなので、実装工数の削減や実装方法の共通化を行うことができます。

まとめ

Swaggerの開発環境構築について紹介をさせていただきました。
まとめとして導入にあたっての注意点やメリットを紹介します。

注意点

  • OpenAPIの知見がない場合の学習コストがそれなりにかかる
  • 既存のAPIを移行する場合にリソース指向アーキテクチャに準拠できていないとOpenAPIでは表現できないことがある

メリット

  • API定義がコードと一緒にGit管理できる
  • Swagger UIを使えば仕様が明確になり共有もしやすい
  • コード自動生成に対応していれば、実装工数削減やサーバー・クライアント間での一貫性を担保しやすい

これからAPI開発を行う方にはメリットも非常に大きいと思いますので、導入候補として検討いただければと思います。

最後までお読みいただきありがとうございました。

＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／

919.jp

イラスト制作で苦手と楽しく向き合う4つのコツ

はじめまして！新卒入社１年目、デザイナー兼イラストレーターのchimiです。 現在はサービス内のイラストを中心に、クリエイティブ制作を担当しています。

クイックに入社して約10ヶ月、学んだことは多くありましたが、自分の中で一番成長を感じた部分は、”苦手で避け続けてきた人間イラストを楽しく描けるようになった”　ことだと思っています。

なので、今回はイラスト制作において私が実行してきた「苦手と向き合い、楽しく付き合っていく4つのコツ」についてお話しできたらと思います！

苦手と向き合う4つのコツ

1.苦手を分析する

苦手克服を目指す前に、まずは自分の苦手を分析してみましょう。 今回の「苦手を分析する」でのゴールは、苦手に対しての「わかんない・・・不安・・・」といったマイナスな気持ちを少し軽くして、「ちょっと描いてみようかな？」と思えるようになることです！

イラスト制作においての苦手って、ぼんやりとした「わからない」をそのままにしていることが大きな原因だと思います。

この漠然とした「わからない」部分を、一つずつ丁寧に洗い出して考えてみることで、どこを集中して練習すべきかが見えてきます。 更に、苦手の具体的な数が分かることで「これくらいならできるかも！」と、やる気にも繋がると思います。

例として、私が以前人間イラストに対して「わからない」と思っていたことを並べてみると、

  • 手の構造が複雑でわからない
  • 関節の位置がわからない
  • 正しい手足の長さがわからない
  • 顔のパーツのバランスがわからない
  • 手足などのパーツの身体への付き方がわからない

といった5つが出てきました！ 苦手な部分が具体的になったことで、少しとっつきやすく感じられてきたのではないでしょうか？

2.目標を立てる

苦手を分析したので早速描いてみよう！となる前に、目標設定を行います。

ゴールのわからないマラソンなんて絶対走りたくないですよね？ ゴールを決めて、できるだけ最短ルートで楽々ゴールテープを切ってやるぜ！という気持ちで目標設定を行いましょう。

「苦手なところもうまく描けるようになるのが目標なんでしょ？」と思うかもしれませんが、もう少し具体的にしたいですね。

  • いつまでに
  • 何を
  • どれくらいできるようになるか

という3つの要素を追加して目標を立ててみましょう！ 達成期限は、ざっくりとでもよいので設定しておくと先延ばし癖が出にくいと思います。

例えば、「半年後には、様々なポーズでの人体のバランスを完璧に取れるようになる」とか、「1年後には、他の得意なイラストと同じ時間で人物イラストを作成できるようになる」とか、自分のレベルに合ったゴールを設定しましょう。

イラストは、正解もなければ上達の上限もないものだと思うので、目標だけでも具体的にすることで進む方向を見失わずに済みそうです。

最終的なゴールを決めたら、次は小目標を立てましょう。 ゴールから逆算して「これならできるかも」という範囲の小さな目標をいくつか設定します。

先ほどの「半年後には、様々なポーズでの人体のバランスを完璧に取れるようになる」を例として小目標を立ててみます。

  • 人体のパーツの比率を覚える
  • 正しい比率で人体のアタリが取れるようになる
  • 資料と同じポーズで人体を描けるようになる
  • 資料を参考にしながら自分でポーズを考え、正しい比率で描けるようになる

こんな感じでしょうか。こちらはあくまで例ですので、目標をもっと細かく刻んだり、小目標にも期限を決めたりなど、自分のやりやすいように設定してみてくださいね。

また、ずっと苦手の練習だけを続けると、自信を無くしてしまう原因にもなるので、好きなイラストを合間に描いたりなど、息抜きの時間も大事にしましょう。

私は、人間イラスト約10点につき1〜2個の小目標を設定して進めることで、小さな成功体験が積み重なり、「苦手を潰すのって楽しいかも！」と思えるようになりました。

3.資料は見れば見るほどえらい

みなさんはイラストを描く時、どのくらい資料を見ていますか？ 資料を見ずにサラサラ描けることをかっこいいと思ったことってありますか？私はたくさんあります！ 資料は大事だと分かっていても、最低限の資料だけ見て制作してしまう癖が私にはありました。

自分のことを棚に上げまくって言いますが、資料は見れば見るほど、調べれば調べるほどえらいのです。ものすごく。

ものの構造や本質をちゃんと理解できていないと、「わからない」や「苦手」という気持ちに繋がります。

本質を理解して、絵に説得力を持たせるためには、ものをしっかり観察したり、資料をよく見ることがすごく大切なんですよね。 そして本質の理解が進むと、苦手な中でも描くのが楽しいポイントが少しづつ見つけられるようになってくるはずです。

資料をよく見て、本質をとことん理解しようとする姿ってめちゃくちゃかっこいいと思います。 検索したり、自分で撮ったりなど、自分のやりやすい形でどんどん資料を集め、よく観察してみてください。

そして、ちゃんと資料を見ながら描いてる自分ってえらい！かっこいい！という気持ちで制作しましょうね。

4.うまく描けたら自分を褒める

今回は「苦手な中の得意を見つける」ことと「自分を調子に乗せる」ことが大切です。

いざ制作してみると、やっぱり初めからうまく描けるようになるわけありませんよね。 思い通りに描けなくて、もやもやしたり凹んだりすると思います。

そんな中でも、「あ、この線きれいに引けたな」とか「目はいい感じに描けたかも」とか、 うまく描けたところが少しでもあれば思い切り自分を褒めてください。

他の人から見て下手くそだったとしても一旦は気にせず、自分の視点を評価基準にして、「意外と描けるじゃん！」と、自分をその気にさせましょう。

苦手な中でも得意な部分を見つけてみると、ちょっぴり制作が楽しくなって、続ける力になるはずです。

まとめ

さいごに、私が業務で人間を描くようになった最初期のイラストと、最新のイラストをご紹介させていただきます。

▲最初期のイラスト

▲最新のイラスト

絵柄はある程度統一していますが、 初期のイラストは関節の描き方などに迷いが見えるのに対して、 最新のイラストの方は、関節や手足のプロポーションが整っていたりなど、説得力があるかと思います。

また、作業スピードも大幅に上がりました。 上下のイラストはどちらもほぼ同じ時間をかけて制作しています。

こうやって見比べてみると、自分の成長に気付けてなんだか嬉しくなりますね。

今回は苦手と向き合うための4つのコツについてお話しさせていただきました。 これらのコツは、あくまで私はこうしたよ！というだけのものなので、ぜひ自分に合った向き合い方を探してみてください。 どんなやり方であっても、苦手なイラストを克服しようと頑張る、それだけで素晴らしいことだということは忘れないでくださいね！

ここまで読んでいただき、ありがとうございました！

＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／

919.jp

ファシリテーターによる振り返りの振り返り

チーム ミーティング スプレッドシート

こんにちは！ねこです。
冬の朝は寒くて眠くて目が開きませんね。

みなさま、ファシリテーターよろしく！と言われて言われた通りの進行だけやってませんか？
ファシリテーターって実は「司会」よりもやることが多いんですよね。
最近ねこはPJの振り返りのファシリテーターを担当して、「やっぱりファシリテーターって奥が深いや」と感じたため、今回行った振り返りの振り返りをこの記事に発散してみようと思います。
具体的な行動をつらつら書いてみたので、ファシリテーターに任命されたけどなにすればいいのかわからない！という人や、他の人のファシリテーションを知ってなにか気付きを得たい人向けです。
タイピングが面倒になってきたのでここから下は「ファシリ」と略します。

ファシリの役割

そもそもファシリとは…？
「司会」を英語にした言葉ではありません。
語源の「facilitate」は「〔物・事が仕事などを〕楽［容易］にする、促進する、円滑に進める、手助けする」という意味の言葉です。
定められたとおりに進行のみを行う司会と違い、下記のような主体的に会議を動かす役割があります。

  • 参加者に発言を促す
  • 話の流れをコントロールする
  • 議題を解決するよう導く

ググってみると「司会とは違うんだぜ！」という記事がたくさん出てくると思います。
気になる方はぜひ調べてみてください。
真面目にやると大変だし技術がいる役割なんですが、それでも本気で取り組んだだけ、「私のおかげで今日いい振り返りができちゃったな……」と達成感があるのでねこはけっこう好きです。

PJ振り返りのファシリとしてやったこと

今回の振り返りは先に「1時間」を設定し、時間内で終わらせる必要がありました。（全員の予定を合わせるのが難しくて…）
そのためそれなりに時間をかけて下準備しました。結構な量の作業ですが、その分当日「全員でアツい話をする時間」を生み出すことができます。

KPTで振り返るぞって決めた

振り返りには様々な手法があります。
今回は「課題を共有・対策を考えたい」「成果を共有・活かしたい」という目的が明確にあったため、課題・成果に着目する「KPT」に決めました。
惰性でKPTをやるのではなく、目的に合わせて振り返りの手法を決めることは「よき振り返り」への第一歩です。

実は準備し始めた当初、ねこは「KPTばっかだしなんか新しいやり方で振り返りしてみたいな〜」という個人的感情があったのですが、 目的と照らし合わせた手法決定は改めてやってよかったなと思います。

振り返りの目的に合わせた手法一覧はvivaさんという方がチートシートを作ってくださっていて、とても参考にさせていただきました。感謝！
qiita.com

KPTあつめ・議題設定

手法を決めたら材料集めです。振り返りまでに下記を行いました。

1. KPT書き出し

全員にスプレッドシートへ書き出してもらいました。
振り返りの時間内に付箋に書き出す方法もよく見ますが、当日書いてと言われて何故か何も思いつかない現象に襲われたり（経験談）、 書き出しきれなくて振り返りが時間内に終わらない（経験談）ことを防ぐためです。

書き出してもらったKPT
こんなかんじ

2. ポイント付け

今回は書き出された全てに対して話し合うのではなく、数を絞ってアツい議論を交わすことを重視しました。
そのため、1.書き出し が終わったあとに全員に「いいね」の感覚でポイントを入れてもらってます。

3. 議題数調整

1で書き出されたKPTは105個、これを40分で全部話し合おうとすると1議題22秒で終わらせないといけなかったので、3pt以上の10個にしぼり、1議題について4-5分話し合えるよう調整しました。
もっと時間があればポイントの幅を緩めたり、また逆に議題数に合わせて振り返りの時間を増やすのもよいとおもいます。

KPTの重要度付け
「アツ度」として議題の温度を比較できるようにしました。

アジェンダとルールづくり

なんとなく共通認識がありそうで、結構ずれてるのがアジェンダとルールです。
テキスト化し、振り返り当日のオープニングで共有しておくとメンバー全員の意識統一ができ、スムーズに進行できます。

この時間どんな割合で時間を使い、どのように進行するかを参加者に共有します。
自分のイメトレにも役立ちます。

振り返りのアジェンダ
ちなみに当日は議論が白熱し、Closingをすっ飛ばすほかありませんでした……無念。反省。

グラウンドルールは会の土台となるルールです。
全員が守り、意義のある時間にしましょうねという誓いとなります。

振り返りのグラウンドルール
リモートでの参加者もいたので内職に関してはド派手にしておきました（自戒込）

元気な進行

振り返りでだれもが下を向き口を閉じ、お通夜モードになってしまうのは何よりも避けたい事態なので、当日は元気よく進行します。

元気の良い振り返り
話しやすい雰囲気めっちゃだいじ

オープニングでは、「グラウンドルールに賛同いただける方は拍手をお願いします！」と言って拍手も導入してみました。
拍手は場が明るくなるのでこまめに挟んでいきたいところですね。

進行中意識していたことは以下4つです。

  • 自分は議論に参加しない
  • 静寂が訪れる前に発言を促すこと
  • 話が逸れそうであれば防ぐこと
  • タイムキープもしながら焦らせない程度に急かしつつうまいこと話を進めること

1番目はねこがすごい自分の意見をしゃべってしまうタイプなので個人的に気をつけていることです……。
ファシリがファシリテートに集中していないと、時間オーバーで議題が最後まで話し合えなかったり、議論が迷子になったりしてしまいます。
難しそうに見えますが、「話が逸れていないか」「抜け漏れがないか」「具体的なアクションに落とし込めているか」等を問いかけるのが仕事です。
メンバーのようすや意見を観察し、必要に応じて発言を促すようにしました。

ファシリへのFBを要求

さいごに、自身のファシリ改善として、参加者に「ファシリへのFB」を閉会後チャットで送ってもらいました。
（これも「プラス／デルタ」という振り返り手法です）

+ よかったこと

  • 振り返りのスコープが明確でよかった
  • オープニングのグラウンドルールや目的など、振り返りに関する前提の共有が良かった
  • 進行の温度感がゆるすぎず厳しすぎず、アツい議論が交わせてよかった
  • 未発言者がいなかった

Δ 改善したほうがいいこと

  • 議事録やタイムキーパーは他のひとに任せてもよかったとおもう

お褒めの言葉が多く、コメントが届くたび笑顔になりまくりでした。本気出したのでうれしいです。
改善点として役割分担についてのコメントをいただき、 ちょっっっっっとねこが慌ただしい様子だったことで集中を削いでしまったのかなと思うと悔しい気持ちです。
タイムキーパーは進行上自然とやりそうなので、議事録は他の人に任せることも次回検討しようと思いました。

振り返りの振り返りの振り返り

こんな文量になる予定じゃなかったのですが、やったことを書き出しただけでも結構な量になりました。
いろいろ考えながら取り組んだことがアウトプットできる機会になってよかったです。

「振り返り」という会は、基本的にそれなりの人数と時間を押さえて行うものだと思います。
そんなにリソースを使ってやるものであればやはり効果は出していきたいものです。
ファシリテーターはやること・考えることがとても多いのですが、 真剣に取り組むことによって、チームや自身に大きな恩恵を生み出します。
これを読んでくれた方に発見や気付きがあり、自身やチームに取り入れられるところがあれば幸いです！

下記、振り返りをするにあたって読んだものたち

＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／

919.jp

日本最大規模のハッカソンに参加して学んだ「ものづくりで重要なポイント3つ」

こんにちは。ソフトウェアエンジニアのじゃがいもです。最近は25年前に発売された不動のバイクを直すということにハマっています。学ぶことがたくさんあって楽しいです。

ということで、本題に入ります。 今回は2022年10月に開催された、日本最大級のハッカソンイベント「Hackday」に出場した経験から感じた、ものづくりで大切なポイントをお話ししていきます。

「ハッカソン」とは

ハック(Hack)とマラソン(Marathon)を掛け合わせた言葉が、ハッカソン(Hackathon)です。 エンジニアやデザイナーなどが集まってチームを作り、特定のテーマに対してそれぞれが意見やアイデアを出し合います。決められた期間内で成果物を作り、その成果を競い合うイベントです。 アメリカで生まれたもので、GoogleやAppleが行ったことで有名になりました。

「Hackday」とは

総勢数百名のエンジニアやデザイナーがチームを作り、最新のテクノロジーを活用して、24時間で開発した作品を発表して競い合う日本最大級のハッカソンです。 毎年1回開催されており、約10年の歴史があります。

テーマは「日本のデジタル化」

これに沿った作品作りが求められます。 チーム構成はエンジニア2人、プランナー2人で挑みました。

Hackdayのルール

詳しい説明は公式ホームページをご覧ください。 hackday.yahoo.co.jp

どんなものを作った？

「バスで幼児置き去り」というニュースを見て、これをITの力で防止できないかと思い、「幼稚園バス幼児置き去り防止」というテーマに決定しました。

作品の名前は「みまもるぞう」

子供たちを「見守る」＋かわいい、安定感がある「ぞう」を組み合わせた名前です。

結果は？

予選では上位10チームに選出され、決勝戦では2位（Silver）になることができ、賞金100万円を獲得することができました。

ここから、イベント中に感じた「ものづくりでの重要なポイント」をお伝えしていきます。

ものづくりで重要なポイント

予選から決勝まで様々な審査員の方や出場者の方にお話を聞いて感じた重要なポイントを「3つ」をお話しさせていただきます。

１、プレゼンテーションには開発と同じ時間をかけること

Hackdayでは24時間という短い時間の中での作業時間だったので、プレゼン準備に時間をかけることができず、本番発表では時間が足りなくなってしまったり、発表資料の質が低いチームがみられました。 ハッカソンでは作品作りに多く時間を使ってしまいがちですが、プレゼン資料作成や発表練習にも時間を多く使い、見ている側がハラハラしない、余裕のあるプレゼンを心がける必要があります。

２、「課題の質」が何よりも大事

ハッカソンでは「使ったことのない技術を使ってみたい」「飛び抜けた技術力を見せつけたい」など、使いたい技術ベースで課題を決めたり、「こんなものあったら便利だな」という軽いアイデアをベースに課題を決めることが多いケースかと思います。
ここでは、ハッカソンで勝つためにはどのように課題を決めたらいいかをお伝えします。

作品決めで一番重要なのは「課題に対する解決策」ではなく、「課題の質」であるということ。 使用している技術のレベルが高くても、課題が弱ければ共感してくれる人も少なくなります。

例えば、「身体情報や天気の情報を使用して、おすすめのレストランを教えてくれるシステム」よりも「利用規約を意訳して分かりやすくしてくれるシステム」の方が、課題としては多くの人が共感してくれると思います。

３、チーム内では遠慮せずに言い合うこと

ハッカソンでは短い時間の中で、一つのものを協力して作っていく必要があります。 少しでも納得がいかないことや、理解できないことがあった場合はその場でお互いが納得いくまで話し合い、目指すゴールを常にすり合わせておく必要があります。

誰かが納得いかない状態で進めていくと、チームの雰囲気が悪くなり、楽しんで開発することはできませんし、開発している作品にも影響が出てきます。

開発した作品説明

バスの入り口にセンサーを搭載したマットを置きます。

子供たちの靴の中敷の下に小さなタグ(rfid)を入れます。

バスに乗降車する時、タグがマットのセンサーに反応し、誰が乗降車したかがウェブサイト上から把握することができます。 置き去りが発生した場合は、幼稚園の事務室等に置かれたスマートスピーカーからアラートが流れたり、親御さんへのline通知が行われます。

システム構成


webデザイン

まとめ

制限時間の中で何かを伝えることや、チーム内で意見をぶつけ合うということは、ハッカソンだけではなくビジネスシーンでも非常に重要なことだと思います。
私も今回のハッカソンで学んだことを日々意識していきたいと思います。

発表した動画はYahoo Hackday公式アカウントから見ることができるので是非ご覧ください。

＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／

919.jp

画面仕様書のツール選定(AdobeXD,Figma,Zeplin)について

こんにちは、デザイナーのFです。

私が参画しているプロジェクト(業務システムの開発・運営)の場合、画面仕様書はXDとZeplinで管理・共有しているんですが、去年AdobeがFigmaを買収してからAdobe XD(以降XD)側の機能開発のペースが落ちているし、Figmaの勢いがどんどん増しています。

いろいろな所から「Figmaが良い」「Figmaだけで完結」という話が多く散見されるのを目の当たりにしています。 この変化の感覚はFlashがなくなる時の「Flash終了」「JavaScriptで出来る」の流れに近く、またもや自分が使っていたツールの終焉を見届けることになるのかと、少し悲しい気持ちになっています。

実際Figmaの機能や更新頻度を見ている限り、私もFigmaがいいと思っています。

XDの単体販売終了のお知らせも有り、このまま行くとXDが使用できなくなり、Figma等に移行する未来があるので、置き換えた場合どうなるのかは想定しておかないといけません。

なので、どのような移行パターンがあるかシミュレートしてみました。
今回はそんなお話です。

現在の画面仕様書のツール選定方法

前提として所属プロジェクトの画面仕様書の要件は
「誰でも齟齬なく正しい情報が読み取れること」
「共有コストを下げ、共有ミスもなくす」です。

誰でもとは書いていますが、一番重要視しているのは、エンジニアが開発時に情報を正しく読み取れるようになっているかです。

そして当時、この要件を満たす画面仕様書を作るにあたってツールを選定したのですが、候補としてあがったのはXD+Zeplinという組み合わせでした。

なぜXDとZeplinになったのか

理由は、作る側がAdobeCCに加入していて既に使っていたからです。 コストの問題もありますが、XDでの画面作成自体に問題はなく、使いやすく、FigmaやSketchに関しても単なる類似の制作ソフトだと思っていました。 そして、当時は機能的にも課金してまで制作ソフトを変える必要はないと感じていました。

次にZeplinについてです。 XDでは画面を作ることはできますが、画面仕様書として管理する場合に、単体だとファイルや画面出力を一元管理できません。Zeplinとの連携はそこの管理・共有部分をうまく補助してくれます。

また、Zeplin上でスタイルガイドを設定すると、それに沿ってCSS等の補足情報をうまく伝えることができ、共有コストを下げ共有ミスも減らすことができるので、ここもプラスでした。

運営的には、必要な画面をXDで作成し、Zeplinにアップしていき、その画面を画面仕様書としてまとめて管理・共有するという形です。

Figmaのみに置き換えてみる

XD+ZeplinからFigmaのみに置き換えると、単純に使用するツールが減るだけではありません。 要件を1つのツールで満たすことができます。

Figmaの機能については詳しくは書きませんが、XDとZeplinでできていたことがFigmaのみで完結できます。 1つのツールで画面を作ることもでき、さらに、制作した画面を画面仕様書として管理する場合でもファイルや画面出力を一元管理できます。 Zeplinのスタイルガイドの機能もFigmaのページやライブラリを利用すれば置き換え可能なので、共有コスト、共有ミスの部分を考えても合格点です。

Figma+Zeplinという考え

現在の構成から考えるとXDがFigmaに置き換わる形になります。

この構成はFigmaのみの構成から考えると余計なツールや管理対象が増えているようにも見えます。 Figmaはオールインワンだから良いのであってZeplinを追加してしまうと、使いやすい制作ツール止まりになってしまうので、良さを引き出せないのではないか？とも考えられますよね。

ただし、今回の場合XD+Zeplinからの移行なので、いままで画面仕様書をZeplinで確認していた人にとっては何も変わりません。制作環境のみ変更という形で済みます。 コストの問題や移行の仕方、規模感によっても変わってくるとは思いますが、この形も候補としてはありだと感じます。

まとめ

いまから新しくプロジェクトを立ち上げる場合はFigmaのみでよいかもしれませんが、現在の構成から移行する場合はZeplinを残す選択肢も十分にあると感じました。 Figmaの更新頻度や勢いを見ていると、Zeplinの機能をすべて網羅したツールに今後なるかもしれませんが、Figmaもいつなくなるかわからないです。

今回結果的には、寿命が短いツール選定になってしまいましたが、要件を満たしていますし、そこまで大きく失敗ではなかったように思います。 しかし、コスト的な部分もありましたが、選定時に決めつけた形でXDを選んでしまったのは反省すべき点だったかもしれません、もう少しまわりの意見や情勢を考慮すべきでした。

まさか、XDがこんな結果になるとは思ってもいませんし、、、
とにかくAdobeXDには早急にFigmaへの移行関係のアップデートをしていただきたいと思っています。

＼\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! /／

919.jp