QUO CARD Digital Innovation Lab Tech Blog

クオカード デジタルイノベーションラボの技術ブログです

リモートでのユーザビリティテスト実施

こんにちは。

今まで対面で実施していたユーザビリティテストを初めてリモート環境で実施したので、ブログでご紹介します。


実施の背景

現状では対面での実施が難しく、リモートでの実施を検討することとなりました。


実施までの準備

スクリーニングアンケートの作成配信、評価項目、テストタスク、全体スケジュールなどの準備は通常通り進めましたが、操作してもらうUIをどのように用意するかと進行方法については悩みました。弊社はデザインにFigmaを利用しているので、Figmaでプロトタイプを作って操作してもらうのも検討したのですが、被験者の方にアプリをインストールしていただいたり、スマートフォンの環境によってはうまく動作しなかったりといったことが想定され、実施や実施準備への影響が懸念されたので、今回は採用しませんでした。(別のプロトツールですが、過去に在籍した企業でそのような経験もしたので。。。)代わりに画面キャプチャを貼り付けたスライドを用意し、被験者の方に口頭で操作する場所を発話してもらい、こちらで画面を切り替えて擬似的に操作していただくこととしました。普段のユーザビリティテストで行う脳内で考えていることを出来るだけ声に出して操作してもらう延長のイメージです。 調査は準備が重要と言われていますが、今回はリハーサルが本当に重要でした。もし今までと同じ感じでリハーサルを軽くしていたら、、、1人分の結果を無駄にしていた可能性が大きかったです。


実施

Zoomを利用して既存UIと新規UIの評価を上記のとおり紙芝居形式で実施しました。


対面との違いで感じたこと

今回の形式は、実際にご自身で操作できないため、普段よりも考えて操作することになるので、操作に行き詰まった時に色々と探して操作する部分を拾いづらい場合がありました。また、同じ空間に居ないので、感情を感じ取るのが難しかったです。なので、色々と聞き出すために普段よりもこちらが話すことが多かったように感じます。もちろんペーパープロトなので説明なども多いので意外と喉が乾きました。こまめに喉を潤わす準備も忘れずにしたいです。


実施して良かったこと

初めての試みだったので、少し不安を感じていましたが、課題を抽出でき、改善案の検討に繋がった活動になりました。絶賛開発中ですので、お楽しみにしていただけると嬉しいです。また、過去に実施した際は都内で開催していたのですが、今回はお住いの場所に限らず、より幅広くご参加いただけたと思います。 インタビュー調査はすでにリモートで実施ていましたが、ユーザービリティテストもリモート実施の実績ができたので、現在の対面が難しい状況がいつまで続くか分からないですが、生成的調査、検証的調査を状況に応じて使い分けながらプロダクト開発を進めていけるということが確認できました。見学する人数が多くても被験者の方に圧迫感を与えずに済むのもメリットとしてありそうでした。


最後までお付き合いありがとうございました。以上となります。

Kotlin で Java15 の sealed class をいじってみたけど、 Kotlin は 2020 年 10 月頭の段階で Java15 対応が入ってないので失敗した話

こんにちは、 クオカードデジタルイノベーションラボの Kotlin おじさんこと 持田 です。 Java 15 がリリースされたので、さっそく触ってみました(Kotlin で)。

続きを読む

GitHub Actions の composite run steps action を 試してみた

こんにちは、デジタルイノベーションラボで ビルドおじさんを担当している もちだ です。ここ最近の開発言語は HCL です。

今回はちょっと前(2020 年 8 月 7 日)に公開された GitHub Actions の composite run steps action を 試してみました。これは Dockerfile や node js のコードを書かなくても(書けなくても) 通常の GitHub Actions のワークフロー YAML が書ければ、 action を作成・公開できるという仕組みです。

f:id:quo-digital:20200925182049p:plain

続きを読む

デジタルイノベーションラボのチーム構成

今回はデジタルイノベーションラボのチーム構成について書きます。

現在以下の4チーム体制になっています。

  • QUOカードPayチーム(3名)
  • QUOカードPay ECチーム(2名)
  • 新規プロジェクトチーム(5名)
  • 運用チーム(3名)
  • UI/UXチーム(2名)

UI/UXと運用チーム以外はスクラムで進めており、コーディング作業はペアプロ/モブプロを中心に進めています。

QUOカードPayチーム

QUOカードPayのサービスイン前後からいる古株が集まったチームです。 主に以下の開発を行っています。

サービスインに向けて急ぎ作った箇所もあるので、今後の長期の運用に耐えられるよう、新しい技術を取り入れる等して、自動化やブラッシュアップを進めています。 例えば、最近ではCircleCIからGitHub Actionsに完全移行するなどしました。

モバイルアプリで利用している技術 (https://quo-digital.hatenablog.com/entry/2020/01/27/124302)

バックエンドで利用している技術 (https://quo-digital.hatenablog.com/entry/2020/01/20/131409)

QUOカードPay ECチーム

QUOカードPay オンラインストア(https://pay.quocard.jp/)を担当しています。QUOカードPay オンラインストアは最初は外注で構築し内製化をしました。経緯はこちら(https://quo-digital.hatenablog.com/entry/2020/07/03/130141) ゼロから社内で構築したものはKotlinで作っていますが、こちらはJavaで構築したものを徐々にKotlin化しようとしています。また技術的には色々と改善したいものが残っている状態なので、機能追加や仕様変更の対応を行いつつ徐々に改善を進めています。

一般のECサイトとは少し異なり、法人の顧客の方が多く生のフィードバックも得られやすいため、仕事の成果が目に見えて実感できます。 現在、QUOカードPay ECチームはスクラムの開発チームとしては最小とされる3人を下回っているため、一緒に働くメンバーを募集しております。

新規プロジェクトチーム

QUO カード Pay のバックエンドを改善・再構築して QUO カード Pay ビジネスを柔軟かつ迅速に進化するために日々躍進しているチームです。しかし、今のところ大した成果を上げていないので日陰者のような生活をしています。 基本的には他のチームと同様に、Kotlin アプリケーションを Terraformで構築した ECS クラスタ上で動かすようなシステムの構成になる予定です。 これまたほかのチームと同じですが、2 週間のスクラムをチーム全体の仕掛中の作業が複数にならないようにモブプログラミング・モブ作業の形態で取り組んでいます。モブ〜の取り組みについては、以前書いた記事(https://quo-digital.hatenablog.com/entry/2020/09/09/121233) を参照していただけると詳細がわかると思います。

運用チーム

QUOカードPayに関わる様々な運用作業を担当しているチームです。 定期的な作業や非定期な依頼をはじめとして、各部署やQUOカードPayをご利用されている企業様からのお問い合わせや、システムの障害にも対応しています。 運用チームのモットーは「安全・安心・確実」と「運用改善」で、「縁の下の力持ち」を目指して日夜奮闘中です。 突発的な業務が多く、現在はカンバンのような形で進めていますが、将来的には各スクラムチームに合流する予定です。

UI/UXチーム

QUOカードPayのユーザー体験の改善をするために、ユーザーへの調査を実施し、調査より浮かんできた問題点や改善点を明確化し、より良い体験へアプローチするデザインを作りエンジニアと二人三脚でサービスに落とし込んでいくチームです。 ユーザーの声を幅広く知るため、コールセンターとも連携し、お客様の声を汲み取り、より良いサービスデザインを目指します。 また、企業のプロモーション企画にQUOカードPayを採用してもらうための企業調査や、マーケティングチームとの連携もしていきます。

クオカードでは現在エンジニアを募集しています。

quo-digital.jp

リモートでモブプロをやってみて

クオカード デジタルイノベーションラボの飯島、小林、持田、森です。7月末から1月半ほど本格的にリモートでのモブプログラミング・モブ作業を取り入れてみたので、やってみてわかったことを共有します。ちなみに、この記事もモブプロ(モブ作業)で書いています。

背景

入社してからまだ数ヶ月のメンバーがいたこともあり、業務知識を共有するためにペアプロが自然と行われるようになっていました。その流れで、流行のモブプロを導入してはどうかという提案もあり、取り入れることにしました。なお、メンバーにモブプロ経験者はいませんでした。

モブプログラミングとは『モブプログラミング・ベストプラクティス』 から概要を取り上げると、三人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していく手法です。2000 年代には考えられていたが、当時はペアプロの方が主流で、顧みられていませんでした。2015 年くらいにWoody Zuillさんが開発手法として再発見しました。

導入にあたっての不安

モブプロを導入するにあたって、次のような不安がありました。

  • 一つの作業をみんなでやって本当に効率いいの?
  • スキル不足でチームの足を引っ張るのではないか?
  • 個人の成果がだせなくなる(評価)のではないか?

これらの不安がありましたが、いざやってみるとその不安を上回るメリットがあることに気づきました(後述)。

現在の進め方

1日のセッションは次のようなスケジュールで行っています。

  1. 10:30 ~ 10:45 朝会
  2. 11:00 ~ 12:00 モブプロ(20 * 3)
  3. 14:00 ~ 16:40 モブプロ (20 * 4 + 休憩 + 20 * 4)
  4. 16:40 ~ 17:00 反省会

朝会(デイリースクラム)

以前はメンバーがそれぞれ下記に示す内容をデイリースクラム前に Slack で報告して発表するスタイルでした。しかし、モブプロが始まってからは、各自の内容が被ってしまうため、今は朝会の場で参加者全員で確認するスタイルになりました。

  • 前日の成果の確認
  • 当日の目標の確認
  • スプリント計画を達成できそうか確認

モブプロ

このようなルールでモブプロを行なっています。

  1. インターバル20分
  2. 1周したら10分休憩
  3. 役割を定めて行う
    • ドライバー: ナビゲーターに言われたコードを書く
    • メインナビゲーター: ドライバーにやってもらいたいことを言う
    • その他メンバー: アイデア出し、タスク管理(Google docs

インターバル20分

初期は時間を決めていませんでした(キリのいいところまでやっていました)が、人によって時間が偏ってしまうという問題が発生したので時間を区切るようにしました。最初は30分でしたが間延びしている感じがあったため、20分にしてみたところ、スピード感が出ているように感じています。20 分だと時間が短いという意識が入るので、早く交代しようと思うようになりテキパキと開発を進められているからです。

1周したら10分休憩

意外と脳を使っているようなので、休憩しないと集中力が下がって生産性が下がってしまうように感じています。

また、モビングセッションが長時間に渡ってしまい問い合わせがその間に来ていることがあり、その問い合わせに対応するため、この休憩時間を使って Slack を確認(本業である twitter を確認)しています。

役割

モブプロを始めた頃は特に役割を決めておらず、ドライバー(タイピスト)が書いたコードを他のメンバーが追承認するような形になっていました。これはこれでよかったかもしれませんが、議論を活性化したいので、なるべくタイピストの意思で入力しないようなルールをモブプログラミング・ベストプラクティスを参考に定めました。

反省会(レトロスペクティブ)

初期はなにもしていませんでしたが、学習している感覚がなく成長している実感もありませんでした。毎回のモブセッションが改善されていくようにしたかったので、モブプログラミング・ベストプラクティスを参考に反省会を実施してます。

  • 事実の確認(数字で語る)
    • 例:4 つのインターバルで Terraform で設定すべき内容を明らかにできた
  • 肯定的な感想
    • 例 : 実験的なリソースを作成すると Terraform に落とし込みやすい
  • 批判的な感想(人の批判をしない/仕組み的な部分を批判する)
    • 例 : インターバル 30 分は長い/ドライバーの交代がもたついてしまう
  • 建設的な問題解決(解決方法を考えて合意を得る)

モブプロ以外の時間は、調べ物をしたりしています。モブプロでやるべきコーディング作業とかはやりません。

使っている便利なツール

  • くじ五郎
    • モブプロの順番は、自作のくじ五郎という Slack bot を使って朝会の前に決めています。
    • ランダムで mob の順番をシュッと決める

f:id:quo-digital:20200909120824p:plain

メリット

約1ヶ月半、モブプロを継続する中で下記のようなメリットを感じています。

  • コードを共有している感覚が生まれた
    • PR やっている場合に比べて、コードに対する理解度が向上した
    • 個人への依存がなくなり、チームとして保守性が向上した
      • ◎◎さんがいないと対応できないという状況がなくなり、チームとして生産性が向上した
  • プレッシャーが軽減された
    • Terraformによるインフラの構築などを実行する
    • 本番環境へのアプリケーションのデプロイ
  • チームとして幅広い技術を身につけられる
    • 情報共有だけでなく、質問もしやすくなった
    • 他メンバーのツールやショートカットの使い方を知ることができた
    • チュートリアルをモブでやることで、理解度が上がる
      • 一人だとわかった気になって飛ばしちゃう
    • AWS / Terraform / Kotlin / TypeScript / Reactの技術を共有できた
    • クロスファンクショナルなチームがなりつつある

長期的な視野で見ると、突然の出来事にも強く、生産性が落ちない組織になっているように思えます。

最初に書いた通り、始める前にいくつか不安がありましたが、実際にやってみてそれを上回るメリットがあるように感じます。例えば、一つの作業をみんなでやって本当に効率いいの? という不安に対しては、特定の人に任せようみたいなことがなくなり、誰かがいなくても仕事が回るようになりました。

また、スキル不足でチームの足を引っ張るのではないかという不安ですが、質問しやすい雰囲気でモブプロできており、詳しい人もいるし失敗しても取り戻せるという感覚があります。

個人の成果がだせなくなる不安に関しては、チームで成果を出せれば良いと言う上司の理解があり、実は元から解決していました。

デメリット

始めたときには想定していなかった以下のようなデメリットがあることもわかりました。

  • モブプロが終わると結構クタクタになっている
    • 最初は緊張して疲れていたが慣れてきて軽減した
  • プロダクトオーナーが寂しそう(モブプロに遊びに来た)
  • 他のチームとのコミュニケーションが減少した

これらの改善が今後の課題です。

書ききれなかった感想

  • 他の人のコーディング作業を見るのが単純に楽しい
  • 『モブプロ』(kindle) を読むと良い
    • 「誰かの頭に浮かんだアイデアをコンピューターに送り込むためには、まず誰かほかの人の手を通らなければならない」(Llewellyn Falco) に挑戦中
  • 議論がまだまだ足りてない感じがある
  • フルリモートでも、問題なくモブプロできている
  • 慣れるまでは結構疲れる
    • 初日はやばかった、今はちょっとくらい
  • メンバーは4人 ちょうどいい人数

我々はモブプログラミングに対して概ね満足しており、今後も続けていきたいし、より良くしていきたいと思っています。

クオカードでは一緒にモブプロしたいエンジニアを募集しています。フルスタックエンジニア志向の方、今持っているスキルを世に広めたい方などのご応募をお待ちしております。

quo-digital.jp

プロダクトバックログの作り方

クオカード デジタルイノベーションラボでプロダクトオーナーをしている齋藤です。

今回はどのようにプロダクトバックログを作っているかを説明します。

f:id:quo-digital:20200803184638p:plain
プロダクトバックログを作っている図

主に以下のような情報をもとにプロダクトバックログを作成しています。スピード感を大切にしつつ、一部の声の大きい意見のみに左右されることが無いよう、ユーザーテストなどで本当にその機能を実装した方が良いか確認しながら進めるようにしています。

生成的リサーチ

想定ターゲットにインタビューを行い、現状のペインポイントやゲインポイントとなる部分を確認し機能案を作成します。その後改めてその機能が有用なものかの調査を行う場合もあります。

狩野モデル

不定期にアンケート調査を行い、優先順位づけや実装可否など意思決定のインプットにしています。

社内からのフィードバック

経営陣や営業社員など、社内外からの要望がプロダクトオーナーにSlackで届くようになっているので、こちらもインプットとして利用しています。

エンドユーザーからのフィードバック

コールセンターやアプリのレビューなどを確認しています。

開発チームからの改善提案

テストツールの導入など、主にシステム面の改善提案が上がってきます。開発中に気づいたバグの中で、緊急度が高いもので工数が大きくかからないものはスプリント内で20%程度はスプリント外の作業をすることにしているのでそこで対応、そこで吸収できないものはプロダクトバックログに記載し優先順位を付けて対応しています。

主に上記のインプットをもとに、何をすれば競争優位性が高まるか、また自社のポジショニング的に内部化する必要があるかなどを検討し実現可否や優先順位付けを行なっています。例えばQUOカードPayは個人でも購入できますし個人の方からの購入は大歓迎ですが、メインのターゲットはセールスプロモーションを行う企業になります。その為機能の優先順位を付ける場合はまずセールスプロモーションを行う企業のペインポイントやゲインポイントを考慮し進めています。

作成したプロダクトバックログはジャストインタイムで詳細化しており、長期的なロードマップは作成しないという方針で進めています。競争環境が変化する為、随時優先順位を組み替えて行くべきという背景でそうしています。

失敗した点

「非技術系のステークホルダーにとって、バーティカルスライスは一般に理解したり確認したりするのが容易で、ビジネス価値を評価しやすいものである。バーティカルスライスはチームにとって、リリースを早め、実際のビジネス価値とリアルなユーザーフィードバックを実現するための選択肢を増やすものとなる。」

Steve McConnell. More Effective Agile ソフトウェアリーダーになるための28の道標 (Japanese Edition) (Kindle Locations 2351-2353). Kindle Edition.

上記のようにMore Effective Agileで書かれている通り、スクラム導入時にホリゾンタルスライス(エンドツーエンドで開発を進める形)で進めようとしましたが、今までの進め方がバーティカルスライスだったためスムーズに移行ができませんでした。そのためプロダクトバックログバーティカルスライスを意識したものになってしまっていました。現在は極力バーティカルスライスで進めるようにしています。

工夫した点

全ての作業をプロダクトバックログで管理する形にすると開発中に見つけた細かいバグや問い合わせなどの対応が全て翌スプリントになってしまうので、スプリントの20%程度はそのような作業に充てる事にしています。ツールやライブラリの調査もその時間を使えるようにしています。

社内Terraform勉強会を行いました

クオカード デジタルイノベーションラボの齋藤です。

先日社内でTerraform勉強会を行いました。

現在エンジニアが15人程所属していますが、それぞれアプリやバックエンド、インフラ等強みが異なっています。 今までTerraform修正等インフラ作業は主にインフラエンジニアが行なっていましたが、バックエンドとインフラ担当者間で認識の齟齬や連携漏れ、特定の部分でボトルネックが発生するような事がありました。 ボトルネックの発生や連携漏れなどを減らしていくためできるだけ各メンバーが複数の役割を担える事にしたいと考え、社内でTerraform勉強会を行うことにしました。

今まで全くTerraformを触った事が無いメンバーもいるので基本的な所からはじまり、現在のコードを理解する為に必要な知識について下記の通り説明してもらいました。

  • terraform のインストール
  • terraform の各コマンド
  • tfstate ファイルの扱い
  • モジュールの構成の仕方
  • tf ファイルの書き方

以下資料です。

https://qiita.com/kobayashi-m42/items/247cf9708044db8a234e

現在全員フルリモート勤務となっているので、Zoomで行いました。 リアルタイムでリアクションや質問があったので、オンラインでも進めやすかったそうです。

このような感じで、ラボでは月に 1 回くらいは勉強会を開催したいと思っています。クオカードではエンジニアを募集しています。フルスタックエンジニア志向の方、今持っているスキルを世に広めたい方などのご応募をお待ちしております。

https://quo-digital.jp/