【イベントレポート】IoTエンジニア勉強会~人気のIoT機器紹介やIoTエンジニアの魅力や道のりetc~

 

2022年12月16日(金)に開催した「IoTエンジニア勉強会~人気のIoT機器紹介やIoTエンジニアの魅力や道のりetc~」のイベントレポートをお届けします。今回はプロトタイピング専門スクール「プロトアウトスタジオ」の菅原 のびすけさんを講師としてお招きしてIoT情報について語っていただきました!

protoout.studio

iotlt.connpass.com

のびすけさんが個人で主催しているIoTLTは国内最大のIoTコミュニティです。

それでは早速のびすけさんの発表を紹介いたします!

 

IoTエンジニアと他のエンジニアの違いや共通点

のびすけ:まずIoTエンジニアについてですが、例えばWebエンジニアだと、フロントエンドとバックエンドで分かれていました。どちらも出来る人はフルスタックエンジニアと呼ばれたりしています。
IoTエンジニアはそれよりも対応範囲が広いイメージではあるのですが、全ての領域をカバーする必要はありません。ある程度アーキテクチャが分かっていて、ある領域に特化している人同士を繋げれば、仕事として成り立ちます。

IoT年表

続いて私が個人的に作成した“IoT年表”をもとにIoTについて色々お話できればと思います。こちらは個人的な感覚で作ったIoT史です。国内でIoTが流行りだしたのは2014年頃なので、その年代を軸として紀元前と紀元後で分けています。

古代IoT時代について

当時のIoT界隈では【Raspberry Pi】や【Arduino】がよく使われていたかと思います。

【Raspberry Pi】
Linuxが中で動いているほぼパソコンといっても過言ではないです。
みんなが使いたいプログラムをインストールできるので、ソフトウェアのエンジニアでも取り組みやすいです。

【Arduino】
OSが入っているのではなく、プログラムを書き込んでいく形式です。
通信ができなかったので、IoTではなく電子工作というイメージでした。当時はArduino言語というC++を拡張した言語を使わなければならないという縛りがあったので、Webエンジニアは取り組みにくかったかもしれません。

中世IoT時代について

中世くらいになると「ESP8266」という開発ボードが登場します。
シンプルなArduino開発でネットワークに繋がるようになりました。

近代IoT時代について

JavaScriptに関係なく、今のIoT開発ではESP32がよく使われています。
最近はESP32をベースとした別のシリーズ(M5Stack)も登場しました。

現代

最近は半導体不足ということもあり【Raspberry Pi】本体は品薄になっていますが、同じ財団が出している【RP2040】は販売されています。【Raspberry Pi】はシングルボードコンピューターでLinuxを中に入れなければなりませんでしたが、Arduinoのようなマイコンボードを【Raspberry Pi】から出したのです。
安くて高性能なので、最近は【Raspberry Pi Pico】が流行っていますが、残念ながら日本国内では引き続き【Raspberry Pi】の供給難が続いています。
最近人気のIoT機器となると、Raspberry Pi Picoにのっているシリーズと、ESP32系統のものが人気だと思います。

また、オープンソースのCPUアーキテクチャ【RISCーV】も使いながらチップを展開する流れが出てきています。しかし開発環境がまだ整っていないこともあるので、「これから」という感じでしょう。

ここで注目したいのがIoT史の現代のところにある【Matter】というネットワークプロトコル。
スマートホーム向けのプロトコルで、最近注目されており、【Matter】に対応した機器が今後出てくると言われています。ひとことで言うと【標準化規格】という表現が適切ではないでしょうか。

今まではGoogleやアレクサなど、各社のネットワークや機器に対応させてスマートホーム化をしよう!となっていましたが、それはユーザー側からするととても面倒です。
アレクサやAmazon系の製品を選ぶとGoogle系の製品は揃えにくかったりしますよね。
そのため、サードパーティ的な開発ベンダーはすべてに対応しなければならなかったのです。

そこで標準化しようということで、AppleやGoogleなど400社以上が規格を統合して、この先出していくデバイスはMatterに対応しようと決めました。【Matter】に対応しているデバイスは、今のところまだ出ていませんが、iOS16.1から使えるようになっているとのことです。

これからIoTに取り組む方におススメ&IoTエンジニアになるには?

どういった人なのかによりますが、ソフトウェアエンジニアの方などであればこれからIoTに取り組む方にオススメなのは【obniz】です。
特定のESP32系のチップにOSをインストールして制御可能であり、JavaScriptで開発が可能です。ハードウェアや回路の知識がなくても、JavaScriptであらゆるモノの操作や制御できるIoTの入門に最適なコントロールボードだとおもいます。Wi-Fiにつなげばクラウド経由でプログラムを書くことが可能です。電子工作初心者にもおススメといえるでしょう。

今ハードウェアをやっている人で、アプリケーション側をやりたいと考えている人は、JavaScriptを学んだ方がいいと個人的には思います。反対にハードウェアはやっていないという人であれば、まずは電子工作からスタートすると良いので、Arduinoがオススメだと思います。

質問コーナー

すでに役割を終えた「Amazon Dash(一撃注文ボタン)」のような仕組みで、スプレッドシートに記録(例えば筋トレ実績や機器の点検確認など)していきたいのですが、どこから手をつけていけば良いでしょうか?
―Amazon Dash ボタンを持っていれば、再活用できる!ラズパイに繋いだりして、既存のボタンをそれっぽく出来ます。
「ボタンを押したら記録」がやりたいのであれば、obnizを使ってみましょう。IFTTTと繋げばコードを書かずに簡単に作れますよ。obnizは比較的高いので、安く抑えたい場合はM5Stack のATOM Liteがオススメです。こちらはコードを書く必要があります。

初学者が社内業務効率化や個人の趣味範囲でIoT機器を取り入れていく際、学び方や運用の注意点としてどう押さえていけば良いですか? ネットワークに繋がるだけに情報漏洩や脆弱性みたいなトラブルを放置していた…みたいな事に発展したら怖いと感じているのですが。
―「取り扱うデータ」によると思います。そのデータが漏れたとしても問題ないというものから取り掛かってみましょう。電気のオン/オフや電気の使用量など、個人情報と紐づかないデータからまず考えてみましょう。
漏洩したらやばいデータを最初に使うのは避けた方がベターです。

久しぶりにはんだ付けしましたが、めちゃ下手で笑っちゃいました。ブリッジしなかっただけよかったかなと(笑) はんだ付けを上手にやるコツってありますか?
―失敗するのは仕方ありません。
失敗したときははんだを温めて溶かすドライヤー、ヒートガンを使って溶かして、はんだ吸い取り線を使って除去が可能です。上手くやるためには回数をこなすことが一番です。

IoTの電子工作の技量はどれくらい求められますか? 例えば電子工作のキット品は電子部品が何の役割であるか、NGなことは何がNGなのかよくわからない状態で完成できます。電子回路を組む際、Web界隈でいうところのノーコードのように素人でも事故らないようにする方法はあるでしょうか?
―Seeedさんが出しているGrove センサーから始めてください。
(サイトとあわせて分かりやすく紹介いただきました。)

抵抗器の配線で迷うことがあるが、Groveという規格は線を1つにまとめてくれているから、カチッと刺すだけでできてしまいます。Groveシリーズはたくさんあるので、ここから始めるのも良し!

遠く離れた店舗内の基本的なセンサーデータ(計測時刻、室温、人感など)を本部へ送信する場合、「Raspberry Pi」「センサーの拡張ボード」「The Things Network」あたりの準備ができれば特に専門技術なくはじめられるのでしょうか?
―出来ると思います。
ラズパイが問題なく触れるスキルがあれば大丈夫だと思います。Linuxを触るのが初めてであれば、Linuxの知識が必要なのでそこは少し難しく感じるかもしれません。
obnizが圧倒的にラクにできるとは思います。コストを気にしないのであれば、MESHもオススメです。

仕事でまったくもの作りもプログラミングもやらない40代からのエンジニアってどうでしょう?いけますか?(行きたい)
―いけます!作りたいものがあって、実際に作ってみるのがいいと思います。IT業界じゃない人の作った事例をマネしてみるのも面白いかも。日々の生活から自動化していくのは楽しいですよ。
Make も使いやすくてオススメです。ScratchやMicro bit辺りもブロック感覚で作れます。

ラズパイ(Raspberry Pi)とアルディーノ(Arduino)、どっちからやろうかなと悩んでどっちも進められなかった...仕事に追われて...
―頑張ってください!
ムリヤリ仕事に絡めて研究開発的にやれたらいいですね!

IoTの身近な事例を知りたいです。社内事例なんか特に。
―自社オフィスでは、玄関でIoTをしています。
IoTLTの例では、スーパーで働いている人が売上に繋がる商品陳列のレイアウトを調べたい。売り場の一角にカメラを置いて、どれくらいの年代・性別の人が商品をみているかのデータを取って分析するというAIカメラを開発していました。
obniz の事例を見ていくのは面白いと思います。

車のナンバーを取得して、駐車場に止まると店員さんが、ようこそ●●様、と声かけてくれます(事例情報)
―情報ありがとうございます!

IoTに取り掛かったキッカケはなんですか?当時ってIoT何が流行ってましたか?
―2014年、夏ごろ。ラズパイだけでした。アルディーノもありましたが、別の言語という感じだったのでハードルが高かった。OS書き込み済みのSDカードを購入して、コンソールに書き込んでいました。
大学院生のときに先輩が作ったものを披露してきた。物理世界で出来るんだということに気づいて、現実世界のハックができるところに面白さを感じました。

社会勉強でアルバイトされていたんですね!ちなみになぜ居酒屋をえらんだのでしょうか?
―養老乃瀧でハッカソンをして繋がりがあったのがきっかけでした。

dotstud.io

デジタルを推進するためにアナログを学ぶ、これは目からウロコです。そこで得た気付きがあれば教えてください!
―オペレーション業務は特に多く、現場の人はマニュアルに対していかに早く作業するかに頭がいってしまいます。現場の人たちは目の前の仕事で一杯いっぱいですので、効率化しようというところまでに余力がまわせない。上層のところから落としていくところと現場の変えたいという想いの2つがないといけないと感じました。

ということは、ソフト側エンジニアとハード側エンジニアに分かれて、IoTはその両方に足を突っ込む感じですか?
―いいと思います!

いま何が一番面白いですか??(わたし最近M5stack買いました)
―「Kaluma」が面白かったです。RP2040のハックはここから伸びて一大勢力になりそうと予想しています。

ライトニングトークとの相性が抜群って感じていました。いかがでしょう?(動きを見せられるので)あと、最近一番面白かったライトニングトークがあればぜひ見せて欲しいです
―オンラインイベントだと抜群とはいえない…。Webシステムや双方向性のある方がデモとして動かせるので、そっちの方が強いと思います。
最近面白かったのは、総統さん(マッドサイエンティストみたいな方)が「基板の設計図を書いて発注まで行う」というのを5分間でやったのが面白かったです。

一番最近買ったIoT機器を教えてください。
―ブラックフライデーで、ホームキット対応の電球を買いました。まだ触っていませんが、「メロス」というシリーズの電球を買いました。

エンジニアに売れるIoT機器の条件って何でしょう?安さ、見た目、開発し易さ?
―エンジニアからするとAPIやSDKがあることが良いと思います!自分でハックしやすいと人気になりますよね

仕事(営業)をしている35歳の子持ちの非エンジニアがエンジニアになれますでしょうか?アドバイスをぜひ(私じゃないですが、知り合いが悩んでいまして)
―できますが、どうなりたいか次第ですが!エンジニアになる!というのを目的にするのではなく、その先に何をしたいのかが重要だと思います!@n0bisuke までご相談くださいませ。

IoT原理主義!!!ウケる。ネット繋がってなくても、まずは電子工作で楽しめば、その先にIoTチャレンジに繋がるってことですかね?
―そうですそうです。まずは電子工作からはじめてみましょう〜

obniz、買ってみます。
―ぜひ!

のびすけさんがもし働きたいなと思うIoTプラットフォーマーをお選びください理由も・・・ ・IOT-EX ・Symphonict ・SORACOM ・Things Cloud ・それ以外ではどこ?
―難しいですねぇ〜
ArduinoがArduinoクラウドっていうのも最近やっていますがArduinoの中が気になるので働いてみたいかも...です。

エンジニアならMac一択?!
―WindowsでもLinuxでも良いと思いますよ!最近はMac一択って感じでもなくなっている気がしています!

ちょっと営業的な内容で申し訳ありませんが、プロトアウトスタジオさんってどういう風に授業すすめるのかお聞きしてみたいです。会社で良い研修とかなかなか出会えないです。
―作る&発信する
この2つを沢山してもらいます。先生が喋ってハンズオンするだけでは、自分で作るということができない。学んだ技術をもとに何か作ってこようというのをやっています。「作ってみせる、そして先生がフィードバックをする」そういう流れになっています。
(参考)受講生のnote記事
https://note.com/atoms50/n/nab8655a73c75

社内のネットワークにはセキュリティでIoTデバイスが接続できないので、obnizはつかえない
―Wi-Fi使わずにBLE系のデバイスから使ってみると良いかもしれません!あとはLTEに直接繋がる開発ボードとかもでていますよ!

いまって学校の授業で“はんだ付け“ってやらないのかな?
―僕が中学校のころはやっていました!が最近は分からないですね...プログラミングがはんだ付けなどの時間からおき変わっているかもしれません。

BraveとMETAMASKが気になります・・
→BAT貯めていきましょう。

“Grove ⇒ ブレッドボード ⇒ はんだ“って感じ?
→そうですね!その流れで大丈夫だと思います。
ハード側だとさらにいくと、はんだ => ユニバーサル基板 => 基板設計 / 筐体設計
みたいな流れになると思います。

のびすけさんが2023年自動化(IoT化)したい構想ってありますか?
→居酒屋や小売業の現場のハックをやれたら楽しそうって思っています!

IoTデバイスとクラウドサービスでの使い分けの目安ってありますか? (会社だとセキュリティで社内ネットワークが使えないので、SORACOM&AWSの組み合わせが多いです。)
→Wi-Fiが使えるかどうか、電源は取れるかどうか、設置する場所のスペースはどれくらいか
などで考えたりします。あとは予算も。電源もWiFiもスペースも予算もあるならIoTデバイスを買わず、スマホやノートパソコンをがんがん設定するというパワープレイもありといえばありな気がします。

 


いかがでしたでしょうか。IoTの変遷から現代のトレンド機器まで幅広くお伝えいただき、現IoTエンジニアの方はもちろん、これからIoTエンジニアを目指される方にも参考になった内容だったかと思います。
みなさんの参考になれば幸いです。

イベントレポートは以上となります!
次回のレポートもお楽しみに♪

【イベントレポート】UXエンジニア・デザインエンジニア勉強会~TechとCreativeのギャップどう埋める?どんなキャリアを歩んできたの?~

 


こんにちは!TECH Street編集部です!

2022年11月17日(木)に開催した、 「UXエンジニア・デザインエンジニア勉強会」のイベントレポートをお届けします。ITテクノロジーに関する様々な職種やテーマをピックアップして「他社・他の人ってどうしているの?」を学ぶ、TECH Streetコミュニティ恒例の事例・知見共有勉強会。今回はUXエンジニア(UXE)・デザインエンジニアのキャリアや知見を共有しあう勉強会を開催いたしました。

登壇者はこちらの方々

金子広大/パーソルキャリア株式会社 テクノロジー本部 エンジニアリング統括部 サービス開発部 第2グループ エンジニア
藤田 智也/THECOO株式会社 エンジニア
鍜治本 碧/エキサイト株式会社 SaaS・DX事業部 UI/UXデザイナー

まずは金子さんの登壇レポートをご覧ください。

小さなデザインシステム設計のナレッジシェア

金子:まずは私が所属する組織についてのご説明です。
パーソルキャリアではテクノロジー本部に所属していますが、Tech×Creatibeのコラボレーションを推進するデザイナーの会である「UXDIG」に参加しています。社内勉強会を開催しながら、成果物を共有したり社内プロジェクトにも参加したり様々な活動を行っています。そしてUXDIGとして取り組んでいる社内プロジェクトが「MIRAIZ」です。

「MIRAIZ」の概要説明

「MIRAIZ」は自分にとって理想の“はたらく”の実現をサポートするセルフキャリアマネジメントツールで、現状はβ版がリリースされています。製品版をリリースするために鋭意開発中です。
このツールには4つのサービスがあり、開発体制もサブプロジェクトを4つ同時に回すという凄まじい体制になっています。

「MIRAIZ」のプロジェクト体制について

サブプロジェクト内にUI/UXデザイナーがアサインされているので、各々が最善と考えるUXを実現する必要がありますが、サブプロジェクト同士連携することが重要です。「MIRAIZ」として一貫した世界観を実現するために、共通項となるデザインツールやデザインコンポーネントが必要となりました。そこで「MIRAIZ」では「Material UI」を導入いたしました。

「Material UI」とは

「Material UI」はGoogle社が提唱している「Material Design」をベースに開発されたReact用のUIコンポーネントライブラリです。

本プロジェクトでも統一されたUIを複数人で作成できるように、最低限のルールや仕様をドキュメント化して作業効率を上げるために、Maerial
 Designをベースにデザイン領域における最低限の「デザインルール」を作成しました。

デザイナー領域:最低限の共通ルール

それぞれのルールを紹介します。

【Button】

特に複数のデザイナーが関わっている時に重要なのは役割とヒエラルキーです。
どういう時に、どのスタイルを使うか定めないとカオスなことになるため、様々なルールを設定して補強しています。例えば右図/下の赤の”アラート“ボタンが、乱発されないように明確なルールを定めています。

【Color】

複数のデザイナーが関わる場合、放置しておくとカラーがどんどん増えていきます。
用途を定めて一貫性をもたせたほうが良いため、ルールで記載する項目も定めました。
実際にプロジェクト内で、カラー定義にないものがFigmaにあったときは、デザイナーに都度質問する流れにしていました。

【Layout】
拠り所のないサイズ・配置を極力無くす仕組みとしてルールを導入しました。

【Device対応】
対応対象外のタブレット端末でも対応しているように見える設計をしました。

このように各サブプロジェクトで認識の齟齬が生じないように、先行してルールを策定しました。

エンジニアリング領域:共通ルールとTheme

エンジニアの方であればピンとくる方もいらっしゃるかもしれませんが、エンジニアリング領域ではこれまで紹介したような共通ルールをThemeに反映させるようにいたしました。
それによって、システム全体のデザインのデフォルトの値を編集することが可能となりました。

Themeによって

・不要なコードの記述量が減り全体的に工数が減る
・デザインの統一感・再現性が高まる
・色の設定などが煩雑になりづらい

などの作用が期待できます。ただ懸念点として

・強力過ぎてコンポーネントの値などで、どこに影響を及ぼすか把握しづらい

という副作用もあります。

そこで「デザイナーと合意」をもとにしたThemeの設定は「すべてが正になる」としました。多少強引な手口かもしれませんが、懸念していた「影響の範囲」を把握するための有効な手だてとなっています。よってThemeを作るうえではデザイナーとのコミュニケーションは必須です。

・最初に「ColorScript」と「色彩の定義」を見せればよかった
・他コンポーネントでも、Muiに併せて「全体的なデザインの同意」を取れる部分はありそう
・まとめてスプレッドシートにおいて問診票のようにしたら、デザイナーとエンジニアの工数削減が可能

などまだまだ改善の余地はあるのかなと思っております。

エンジニアリング領域:Atomic Designについて

ここでクイズ!つぎのコンポーネントはいくつの集合体だと思いますか?

私の答えは「2」ですが、「1」だと言われても反論できない状態になります。また「1」だと主張しても「2」の人の反論に回答できないと思っています。と言うのもIconButton はIconのコンポーネントに依存しているので、単体では成立しないからです。明確ではないため、チームメンバー間でもお互いの「普通」が衝突して、膨大なコミュニケーションコストが発生いたします。そこで取り入れたのが「Atomic Design」。
Atomic Designとは、パーツ単位でUIデザインを設計する手法のことです。

メンバー間でのコンポーネントの粒度間に共通認識が作れるので、コミュニケーションが円滑に取れるというメリットがあるのですが、一方で各単位の厳密な定義がされていないため分類時に議論が発散しがちというデメリットがあります。(特にAtoms,molecules,organisms)
そこで代わりになる分割単位を考えることにしました。

代わりになる分割単位を考える

考慮すべき条件として
・要素数で考えるのはあきらめる
・Atomsが多すぎる問題にも対応したい
・エンジニアだけが理解できるのはアウト(共通言語であるべき)
Atomsは「Mui(デザインフレームワーク)のリストに載っているもの」で考えてみました。

代わりになる分割単位の紹介:Atoms編

Muiをベースに上記大項目と小項目で構成しました。

代わりになる分割単位の紹介:Organisms編

DBの情報を使用することが前提になっているものとし、デザイナー/エンジニアどちらも共通言語として使えるようにしました。

代わりになる分割定義についてまとめると以下の通りです。

どこにも入らないようであれば、話し合いで解決することにしています。

運用してみて

良かった点としては
・境界線について質問がほとんどなくなる
・「ピクセルパーフェクト」を目指すのではなく「デザイナーの意図を反映させる」ことができた
・共通コンポーネントとして切り出せた。

一方で、まだまだ改善の余地もあります。

同じものでも見る立場が変われば見え方が変わります。
「相手の立場になって考える」はデザイナー経験がないと難しい部分があるので、今回のプロジェクトでは「別の立場から見ると違うものがある」ことを意識しました。どう見えているかはその都度、確認が必要ですが、違うものが見えていることを、受け入れて認めて理解することが重要です。
皆さんがデザインシステムを考える際にはぜひ念頭に置いてみてください。


続いては藤田さんの登壇レポートです。

チームで取り組んだWebフロントエンドのアップデート

藤田:このLTでお伝えしたいことは…Webフロントエンドのモダナイズです!
今回は我々が取り組んだ手法をご紹介いたします。Webフロントエンドに関わるみなさんの今後の参考になれば幸いです!

デザインシステムの導入

デザインシステムとは一般的に、企業のビジョンやブランド・アイデンティティなどから「良いデザイン」を定義するデザイン原則などのドキュメント、それらを具体的にデザイン・実装するためのUIパターンやコンポーネントなどを備えた一連のリソースのことを指していて、私たちは以下の4つが構成要素であると定義しています。

【ブランド・アイデンティティ】は製品の目指す方向性やビジョン、雰囲気、使っているロゴやカラーなどブランドを構成しているデザイン的な要素を明確化したもの。
それらのブランド・アイデンティティをプロダクトに落とし込んでいくときに使用するインターフェースガイドラインが【スタイルガイド】
【パターンライブラリ】はエンジニア寄りのもの。スタイルガイドを実際にアプリケーションに組み込んで実装・運用する際につかうコード。それらのテストやドキュメンテーションを、うまく運用し、更新するための仕組みが【運用のための仕組み】です。

実際に使っているデザインシステムの色の定義

テキストについての定義

デザインシステムを導入するべきか?

そもそも、デザインシステムの利点は“デザイン”にそれぞれ名前をつけて、エンジニアとデザイナーのあいだでコミュニケーションコストが削減されることです。
よって複数のエンジニア・デザイナーのやり取りが発生するプロジェクトなどには非常に有用です。
ただ小規模チームで単一のサービスを開発しているケースや、そもそも小規模なプロジェクトの場合は前途の利点が活かされないため不要と考えられます。

エンジニア視点では、再利用できるコンポーネントライブラリがあらかじめ定義されているので、新しく何かを作るときも1つ1つ作らなくても良いという利点もあります。
※デザイントークンとは、そのデザインで使われている色やスペースの大きさなど、そのデザインを構成する最小構成単位のこと。
以上の利点から「デザインシステムを導入しよう」という結論になった場合、デザインシステムと密接に関わっているのがコンポーネント駆動開発(CDD)です。

右図がまさにコンポーネントを作っていく様子ですが、この開発手法にも4つの利点があります。

品質

1つ1つの構成単位や、それを組み合わせたコンポーネントがそれぞれテストされているので、それぞれの品質が高められている状態であれば、それを組み合わせた最終的な成果物の品質も高まっていきます。

耐久性

1つ1つのコンポーネントが疎結合に作られていて、且つ、そのコンポーネントごとのテストが実施されていれば、最終的なページで何かバグが起こったとしてもトレースが可能です。

開発速度

コンポーネントを組み合わせて作っているので、他のところで使われているコンポーネントは簡単に再利用ができ、それによって開発速度が上がります。

開発効率

コンポーネントをあらかじめインターフェースを定めて、且つ、疎結合に作っていけば、数人のエンジニアがそれぞれ違うコンポーネントを同時に作っていても、同時並行で進められます。

実際に私たちはこの3ステップで行いました↓

Storybookの導入

「StoryBook」とはUIコンポーネントをストーリーという単位で管理できるソフトウェアです。

・コンポーネント単位で見た目・動作確認が可能
・ドキュメント作成

上記のような利点があります。

導入までは何ができるか、どう使うとよいかを検討し、後述のChromaticと組み合わせて運用することで効果が出てきます。

Chromaticの導入

Chromaticは“Storyを簡単に公開できる“という利点の他に

・UIテストで実装ミスを発見できる
・UIレビューで変更の承認ができる

というメリットもあります。


導入までの流れとしては上記利点でできることを調査したのち、GitHub Actionを実装し、実際に動作を確認してみました。

今までのような、全部作ってから「これ違う!」といった手戻り作業の無駄がなくなり効率的なワークフローが実現可能になりました。

その他

そのほかには
・テスト
・リンター、フォーマッター
・TypeScript
・Vue3

これらはまだ完全ではありませんが実施中です。

まとめ

StorybookとChromaticを導入しつつCDDで開発することで開発体験の向上が可能です。デザイナー、エンジニア、PMといったステークホルダーを巻き込んで効率的なワークフローを構築することが重要です。今後、みなさんが開発環境を更新する役に立てば幸いです。

最後に鍜治本さんの登壇レポートです

SaaSのUIができるまで 

鍜治本:そもそもSaaSとは「Software as a Service」の略でありソフトをダウンロードしなくてもブラウザで使えるツールの総称で、GoogleドキュメントやSlack
など、なじみのあるSaaSではないでしょうか。
私は所属するエキサイト株式会社SaaS・DX事業部においてデザイナーを担当しています。
本セッションでは

・デザイナーがどのようなことをしているのか
・エンジニアとの連携やプロダクトにどんな影響を与えているのか

という理解から「デザイナーとはこんな生き物なのか」というのを知っていただき、デザイナーのいないチームにとって、UI/UXを高めるTIPSにつながれば幸いです。

学生時代は卒業研究で<プロダクト初心者に向けたプロトタイピングマニュアル>に取り組むなどUI/UXに関するキャリアを歩んできましたが、エキサイトで働きながらデザインするUI/UXは制作物などの自由度ベクトルが大きく異なると実感しています。
学生時代は表面的な自分の仮説ありきの設計で、見た目の完成度を挙げていれば何とかなりました。ただ、仕事ではエンジニアに渡す設計図でもあるため、ピクセル単位でズレがないようにしています。また、大衆が認識しやすいディティールにもこだわり、組織に還元できるように工夫もしています。
では実際の業務について、SaaS・DX事業部が手掛けるクラウド経営管理ソフト【KUROTEN】をつかって説明していきます。

UIが出来上がるまで

ではUIが出来上がるまでの大まかなフローを見ていきましょう。
進め方としては以下の3ステップです。

➀方針や仕様の議論と大まかなスケジュールをたてる
②裏側の設計とUIの設計を同時進行
③設計図をフロントへユーザーテストも実施

フローごとの詳細
➀…まずはPdmの方針や技術面で実現可能かどうかを、開発ロードマップを立てて、担当者を割り当てながらスケジューリングします。
②…詳細な仕様を詰めながらバックエンドも走り出し、同時にUI設計も着手。
どんなUIがいいかを検討しUIを組み立てて、形にしていきます。
③…設計したUIをフロントとバックエンドとすり合わせ、合間に認識のズレがないかテストします。
具体的にはFigmaのプロトタイプ機能を使って、表現に問題がないか、分かりにくくなっていないかを調べたりします。

また設計する上では

・ユーザーがやりたいことをきちんと達成できているか
→合間に確認していき、具体化のブレがないかを確かめる

・仕様ベースで体験の妥協をしていないか
→デザイナー/エンジニアを含めてどうやったら目的の操作を達成できるか突き詰める

・既存のUIやコンポーネントと大きな差がないか
→初めて触る人が違和感なく操作できるか

・エンジニアに渡すときに見えにくくないか、振り返ったときにわからなくならないか
→Figmaに描き示す方法を統一する、またプラグインなど駆使してサイズ表記をする

主に以上の4つに注意して、設計に取り組んでいます。

デザイナーの仕事とプロダクトへの関わり方

SaaS事業部のデザイナーはクリエイティブ全般に関わりながらUI/UXを高めるように、業務フローの中で積極的にエンジニアと関わっていき、齟齬が内容をすり合わせながらFigmaなどのツールを駆使してわかりやすくなるように突き詰めています。
今回の内容で少しでも皆様にTIPSにつながればと思います。

まとめ

いかがだったでしょうか。
普段なかなか知る機会がない、UXエンジニア(UXE)・デザインエンジニアの知見を垣間見ることができました。少しでも皆様のお役にたてればうれしいです。

質問コーナー

iPhoneのデザイン(UXデザイン)についてどう思いますか?
金子:UI/UXは良いと思うのですが、スマホ慣れしていない人(ガラケーからようやく買い替えた人とか、初めてスマホを持つ子供とか)は年々分かりにくくなっているでしょうね。

専用コンポーネントと、汎用コンポーネント(Atomic Design)をどう考えるのかについては聞きたいです
金子:汎用がAtom、専用がOrganismに当たるかなと思います。ドメインモデルが入っているところが「専用」になるという考えです。

ルール策定は何かを参考にされましたか?気を付ける点なんかのアドバイスもいただければと
金子:エンジニアとして気を付けたのは「テーマの項目を確認→コレとコレがあると嬉しいを投げる」それを基盤に作っていきました。「あまりルールをつけすぎない」というのも気を付けています。

TechとCreativeのギャップをどう埋める?どんなキャリアを歩んできたの? まさにこのテーマについて聞いてみたいです!
金子:最後のスライドの「話し合いが大事」。話し合い、ここを諦めないこと。ギャップは埋まると信じて話す。エンジニア側はとっつきづらい人が多かったりします…私はエンジニアとして、共通言語を使い、難しい言葉はなるべく使わないよう意識しています。

デザインのルールは、見直し頻度はどの程度でしょうか?流行り・時代背景に左右されるような内容はルールに含めないとか...??
鍜治本:流行りで一回上がったものだと、ニューモーフィズムの例とか良さそうですね。流行を取り入れる方針は、結局浸透しなかった時にマイナスの負債だらけになってしまうので、安易にUIには入れないようにしています。逆に、消耗品に近いイベントサムネなどのグラフィックはどんどん新しいあしらいを取り入れるようにしています。

デザイン関連って、広報担当と喧嘩になることとかありますか?(経験あり)
鍜治本:広報担当の方とはまだありませんね笑
デザイン組織がない企業“あるある”ですが、デザイナー=作ってくれる人というイメージが強く、我々が意図して形作ったものと相手方の考えている事柄がズレて、すり合わせが大変な時はあったと思います。やはり対話で綿密に方向を確認していくのが大事そうですね。

デザイン関連の一番のこだわり、テック関連の一番のこだわり 聞いてみたいです
デザイナー回答:デザイン関連では、複雑すぎるルールは避けるようにしていました。明快で汎用性が高いことを心がけています。
金子:とにかく「安く早く良く」プロダクトを仕上げることです。(吉野家の安い早い美味いですね)
納期を守りつつ、後の運用にも迷惑をかけず、ユーザーにも良いものを届けたいです。

デザイナー部署と開発部署のコミュニケーションの上手いコツはありますか?
金子:相手を尊重することかと思います。意見を尊重する、人として尊重することを大事にしています。あと、同じ日本語でも、使用する言語が異なることを受け入れることが大事かと思います。
大学時代の勉強分野で学んだことなのですが、同じ日本人でも住んでいる場所や文化で言葉や成り立ちは変わります。原宿の若者と秋葉原のディープなオタクでは、住んでいる場所は近くても、だいぶ異なる会話の形態になります。そういった部分を尊重することが大事かと。

THECOOさん、いくつかあるサービスって、デザインチームは別ですか?体制なんかも気になります。なんとなく各サービスのロゴ的に雰囲気が異なるのかな?と思ったので。
藤田:デザインチームを別にもっているわけではないです。担当者が変わり、使われる用途(サービス)によって雰囲気が変わっています。

藤田さんはテック寄り・・・ですか?まだお若いかなと思ったので、デザイン関連でのこの先のキャリアについて思いがあれば聞いてみたいなーって
藤田:テック寄りです。
プロダクトの最終的な価値や届けられるものがデザインに左右されることを実感しています。エンジニアとしてプロダクトを作っていく中で、デザイナーの意思をくみ取っていたり、デザインのことも意識できるような、キャリアを積んでいきたいと思っています。

StorybookにしてもChromaticにしても、こういうのを選ぶ、導入ってどこが検証・判断する感じですか?デザインチームがどんどん独断で月進める感じですか?
藤田:チームの中で、いい案を見つけた人が提案。チームとしても「いいね」となったら取り組む、という流れです。独断で取り組むのではなく、実際の運用やプロダクトへの導入はチーム全体で取り組んだ方が良いと思います。

Figmaのようなデザインシステムでもモック作れるかと思いますが、Chromaticでモック作成するメリットってなんでしょうか?
藤田:デザインシステムを作るうえで、3つの確認箇所があります。なかでも一番大事なのはStorybook。実際に動くものに近いモックが作れるので、Storybookを簡単に公開できるChromaticでモック作成しています。
デザイン→エンジニアリングのリレーを実施するうえでのシステム構成・バリエーションにおいて参考にした企業や事例はありますか? 
藤田:pixivのテックブログを読みました。ZOZOの記事も参考にしたような気がします。様々な企業の記事を積極的に読んで情報収集しています。

Figmaのようなデザインシステムでもモック作れるかと思いますが、Chromaticでモック作成するメリットってなんでしょうか?
藤田:デザインシステムを作るうえで、3つの確認箇所があります。なかでも一番大事なのはStorybook。実際に動くものに近いモックが作れるので、Storybookを簡単に公開できるChromaticでモック作成しています。

1人で担当されている?!大変じゃないですか?!上司は?!決裁権限は?!
鍜治本:上司にあたる人がプロダクトマネージャーです。仲良くやっています。決裁権限を全て持っていませんが、細かいディテールなどはデザイナー側で握っているかもしれません。一人でやっているのを気にかけてもらっています。

UXデザインの道を選んだのはなぜですか?どういう意識で取り組んで、どういう意識に変わりましたか?
鍜治本:元々UIUXをやるぞ!というのを考えていたわけではありません。チームで何かを成し遂げたいという想いが強く、ターゲットの為に何かを作りたい・やってみたいという欲求が漠然とありました。

学生時代からUI/UXに携わられた経験が既に相当レアな感じがありますが。UIUXへの関心のきっかけや、学生時代もUIUXの関連スキルを高めようとされたのはどういった動機があったのでしょうか?
鍜治本:学生時代にグループで何かをやるというのは経験してきました。そういう時の算段を考えたりすることが刺激になりました。

良いUIUXの引き出しを積むにあたり、どういった経験が効果的でしたか?
鍜治本:色んな人に見てもらう、触ってもらうことが大切です。「作ってみましたが、どうでしょう?」のフィードバックをどんどんもらってさらに磨き上げるのが良いのかなと思います。

デザイナー側がエンジニアリングに近い部分を理解されるような取り組みなどは行われていたりしますか?(たとえばOOUIとか、HTMLの文書構造を意識するとか)
鍜治本:実はHTMLやCSSを全く知りません...!ただ、分からないのでエンジニアさんに分担してもらっていてその分自分ができる分野に力を入れて取り組んでいます。
最近は検証ツールを開いてみたり、色味やテキストサイズ・位置の指示のCSSと睨めっこしてみたりしています。

画面上のデザインというとUIの要素が強いイメージを持ちますが、UXのデザインとしてはどういった業務に取り組まれていますか? 
鍜治本:ユーザーにインタビュー調査を企画しました。普段会計に近い分野で、ターゲットはExcelやスプレッドシートのヘビーユーザーですので、作業を動画撮影させてもらい、逐一動作を聞きながら言語化するエスノグラフィもしました。

Figma / FigJam で愛用プラグインはございますか?
鍜治本:Spacing Manager:指定していたスペーサーを表示・非表示できる
Redlines:高さや幅などの数値を赤線で表示してくれるサイズ表示系のプラグインが愛用です。

UIの作成や改善におけるインプットとして、ユーザー観察/インタビューなどで得られた定性的なデータがイメージされますが、ユーザーの行動ログなど定量的なデータの分析はされていますか?定量データ利活用の余地・可能性はありそうですか?
鍜治本:まだ定量のデータ集めが追い付いていない状態です。まだ手が回っていないのですが、今後はそういうところも組み込んでいきたいです。

UXデザイン系で過去イチきつかった経験、みなさんに聞いてみたいです
金子:最近は昔に比べたら楽になったなと思っています。Figmaがとても便利
渡されたのがパワポだけというのが辛かった経験でしたね。

藤田:仕事関係だとあまりないです。
個人開発だとはじめに作っていたものから大幅にピボットしました。それをやっていくときにFigmaなど使わず自分の頭よりにしていたのでデザインが崩壊していくという経験がありました…

鍜治本:配属されて半年くらい経った時に初めてゼロからUIを担当した、営業向けの「KUROTEN.for Sales」というプロダクトを担当した時が大変でした。企業が取り扱っている商材を管理したり、確度と呼ばれる指標みたいなものを数値化して売上予想を立てたりできるのですが、自分が知らなかった分野なのも相まって、仕様をイチから理解しながら作っていくのが大変でした。

イベントレポートは以上となります!
次回のレポートもお楽しみに♪

【イベントレポート】「プライバシー・バイ・デザイン」エンジニア勉強会〜プロダクト開発において何故プライバシーが重要なのか〜

 

こんにちは!  TECH Street 編集部です!
今回は2022年10月6 日(木)に開催した、 「「プライバシー・バイ・デザイン」エンジニア勉強会〜プロダクト開発において何故プライバシーが重要なのか〜」のイベントレポートをお届けします。
企業がパーソナルデータを外部に提供し、活用するには個人情報保護法などの法規制を遵守するのはもちろん、ユーザーが安心できるようにプライバシーを十分に保護する仕組みが求められています。今回はプロダクト開発に携わる(サービス設計側)エンジニアだけでなくどの職種でも知っておくべき基礎的なお話です。「プライバシー保護がなぜ重要なのか」セミナーとディスカッション形式で学ぶ勉強会を開催いたしました。

登壇者はこの方々!

栗原 宏平/一般社団法人Privacy by Design Lab 代表理事
海保 雄樹/パーソルキャリア株式会社 リードエンジニア

 

まずは栗原さんより「Privacy by Design」の概要と重要性についてお話いただきました。

なぜこれからのビジネスを考えるにおいて、プライバシーが重要なのか

栗原:本日の講義では下記の3点について学び「Privacy by Design」を導入するためにどんな視点を持てばよいのかについて考えていきたいと思います。
・「Privacy by Design」とは一体なにか?
・「Privacy by Design」はなぜ必要なのか
・「Privacy by Design」を現場で活用する第一ステップ

「Privacy by Design」とは一体なにか?

まず「Privacy by Design」という言葉を聞いたことがありますか?
日本ではあまり普及していない言葉だと思います。

「Privacy by Design」という言葉の誕生ストーリーについてまずはご紹介したいと思います。「Privacy by Design」はカナダのカブキアン博士が、カナダのオンタリオ州でプライバシーコミッショナーとして働いた経験をもとに構想されたアイデアです。
様々なテクノロジーが生まれて便利になっていく中で、今までのように自分たちのデータを提供してよいのか疑問に感じたそうです。そこでシステムやビジネス全体でプライバシーを考えることが必要なのではないかという発想からスタートしました。

関係性としては…以下の通りです。

最近は様々なデータ活用が行われています。そして集めたデータをどのように活かすか、運用するのかがビジネスにおいて重要になってきました。
サービスそのものの価値ではなく、サービスを利用したことで生まれるデータへと価値が移り変わっているからです。今まさにデータ活用について考える過渡期といえるでしょう。
分かりやすい例として、2017年に経済誌「エコノミスト」で書かれた言葉をご紹介いたします。「データはオイルであり、彼らの新しいビジネス資源」だと訴えたことが、データに価値が移っていることの1つの象徴といえます。その一方で、そのデータをやみくもに活用してよいのかという点が疑問としてあがっています。データを活用する前に、データを集めるプロダクトの安全性について考える必要が出てきました。
世界最先端を走ってきた企業でも、データ活用について今まで自分たちがやってきたことは正しかったのかを見つめなおす時代にきています。

プライバシーに配慮したプロダクトデザインはどのようなフローになるのかを簡単に図でご説明いたします。
上図のようにプロダクト構想の段階で「プライバシーを検討」ステップを挟むことでプライバシー問題を回避できる可能性が高まります。
続いてプライバシーに関するサービス開発事例をご紹介いたします。
なぜ「Privacy by Design」が必要なのか、問題が発生してしまった例と回避できた例の2つをあげてご紹介いたします。

「Privacy by Design」はなぜ必要なのか

問題が発生したサービス開発事例

まずは、2009年にカリフォルニアで始まった某ソーシャルメディアサービスについてです。
ゲイの方を対象にしたサービスであり、サービス内では利用者の“センシティブ”な個人情報を共有することもあります。
それにも関わらず、サービス開発企業は取得した個人データをユーザーの同意なく、広告配信のため第三者へ提供していたことが大きな問題になっていました。
結果的に制裁金を課されることになり、サービス開発企業にとっては個人データを活用するために必要な「事前確認」の重要性を再認識させられた事例となりました。

続いてプライバシー問題を未然に予測し回避した事例もご紹介しましょう。
今回のサービス提供者は過去に一度プライバシー問題で大きな損失を経験し、、それを失敗と捉えて改善したケースです。失敗したスマートシティのプロジェクトでは、広告ビジネスをスマートシティでどのように活かすかを検討していたところ、住民からの反対があり、最終的にはコロナの影響や不動産価格の高騰も重なり上手くいきませんでした。住民の個人データをどのように活用するかが不透明なため起こってしまった事例です。

開発チームはそこから学んで一度プロダクト構想フェーズに戻り、プライバシー対策を未然に検討した上でサービス開発に着手するようにサービス設計の手順を変更しました。繰り返しとなりますが、プロダクト開発の前(構想段階)にプライバシーリスクを洗い出し対策することによって、どこかで発生するプライバシー問題の回避に繋がります。これがサービス開発を行う上で重要になってくるのです。

「Privacy by Design」を現場で活用する第一ステップ

プライバシー課題を事前に予測するためには、自社のデータ利用に関する現在値を理解して、将来的にどのようなデータ活用がしたいかをしっかりと描くこと。そして、描いた後にプロダクトに落とし込んでいくことが重要です。
例えば、データの連携が必要なプロダクトの場合、システム的な連携方法(技術的に可能なこと)だけを描くのではなく、データを含めてプライバシーに配慮した連携方法をとる必要があります。

こちらはプライバシーに配慮したプロダクト設計をするためのフロー図です。
チーム内で現在地の把握や問題点の共有を行った上で、「このままいくと〇〇のような問題が発生する」というプライバシーリスクの洗い出しをしましょう。

先ほどから「現在地の把握」について何度かお伝えしてきましたが、どのように把握すればよいのかわからない場合は“データマッピング“と呼ばれる手段がありますので参考にしてみてください。

上図はデータが、今どこにあるのか、どこにデータ送信されているのかをマッピングしたものです。
例えば日本から離れ、安全にデータが守られない危険な地域に送られる可能性があったときには、その地域の特性に合わせたシステム開発環境を事前に準備しておくことが重要になってきます。
サービスを開発する上で、事前にデータがどのような環境でどのように処理されるのかを把握することが重要です。
続いて組織内で問題点の共有をしましょう。

その後はPIA(Privacy Impact Assessment)/リスク評価を実施します。

このようなステップを踏むことで未然にプライバシー問題を回避していきましょう。

明日から取り組めるテーマ

先ほどお話したリスクの話を含め、私たちはどうやってデータを活用するか。それをもとにどんなシステムを作っていくか。考えていきましょう。
例として以下のような議論が必要になってきます。

明日から取り組めるようにまずなによりも一人ひとりが意識的に取り組むことが重要ですが、例えばどういったデータを集めるのか、利用目的は何か、どのように安全に管理するのかといった点を徹底的に洗い出して整理することが必要になります。 開発工程とも密接にリンクしてきますのでその点も含めて説明できるような設計を心がけましょう。

Q&A(栗原 宏平さん/一般社団法人Privacy by Design Lab)

栗原様がこのジャンルに取り組まれようとしたのはどういった事がきっかけでしょうか。またこういったものは学ぶ?情報収集?どのようにされてますでしょうか。
きっかけは、ブロックチェーンなど新しいテクノロジーに興味があって学んだことです。海外の人とも交流しながら勉強するなかで、データの分野について議論が必要だと感じたのがきっかけです。
情報収集について、サービスを考える視点だと、アプリ作成時のポリシー、なぜそのポリシーがあるのか?配慮しているのか?どんなサービスがプライバシーに配慮していくのか?こういった視点が情報を集めやすいです。あとは、Twitterでリストを作ってそこから集めています。英語の方が情報は豊富です。

日本にはPrivacy by Design Labさんのような団体はどれくらいあるのでしょうか。データ活用なんかの団体は多いかと思いますが、そういった団体さんはプライバシー系の意識あるのかしら。
プライバシーに関して議論する団体は多いです。自分たちの団体の問題意識は、まだまだ新しい分野なので、どんなルールだと運用しやすいのかがまだ決まっていない。海外の人たちと新しいルールを作っていく。それによって「データ活用がしやすくなる環境づくり」に励んでいます。他の団体よりはプライバシーに重きを置いていると感じています。

個人情報保護とプライバシー保護の違いがイマイチ分からないです
難しい問題ですが、個人情報保護は守りの話。権利とは結びつきづらい情報。
プライバシーは情報に限らない。例えば、家の中でどういう行動をしているかなど奥行きのある内容。人としての権利をどう守っていくのか、がプライバシーかもしれないです。
個々のデータは個人特定できないが、組み合わせたときに個人が特定されるということもあり得るので、知らず知らずのうちにプライバシーを侵害している可能性もあります。難しい話ですが、ここは今後注意が必要です。

データ活用ということですと、オープンデータなんかは逆にプライバシー意識は必要無いということで合ってますでしょうか。
そもそも誰のためのオープンデータなのかという議論がまずは必要かと思います。データを提供している側がオープンであると判断しているのか、取得した側がオープンであると判断しているのかによってオープンデータの意味合いも異なってくるかと思います(SNSがわかりやすいかと思います)。SNS上で公開されている情報をオープンデータの一例で判断する場合、既にアメリカで判例が出ており、その際にはSNS上で利用者が公開しているデータを勝手に取得して分析した場合に違法性がなかったとの判決が発表されていますが、利用者自ら公開している情報が誰でもアクセスできるオープンな情報として公開されていると認識していない場合は、公開した情報が個人データでなかったとしても気になる方はいらっしゃるのではないかと思います。

プライバシー保護を訴えすぎるとデータ活用へネガティブな印象を与える印象があります。 経営層やプロダクトオーナーにポジティブな印象を与えるには、何を強調するのが良いでしょうか。
この問題は私たちが現在取り組みを始めているところなのですが、やはり政府等の様々なステークホルダーを巻き込みながら、プライバシーに取り組むことがプラスになる制度を作る必要があるかと思っています。こういった動きを民間事業者の方と作っていきたいと思っていますので、よろしければご一緒しましょう。

どこまでがプライバシーデータなのか、その明確なルールというか決めは専門家がいない企業でも読めば簡単にわかるものでしょうか。地方中小企業なんか、専門家もいないでしょうし、コンサル依頼するのも高いかもですし。。。。
Howの部分に関しては万人に受けるものは難しい。ただ、NGパターンを考えてみると良いと思います。自分ゴトにして、あなただったら、あなたの家族だったらこの情報(データ)を使われると嫌じゃないか?という視点を持つと入りやすいと思います。

つまりはそのデータに個人情報があるかないか、無ければひとまず安心しても良いということでしょうか。ただ、どういったものが個人情報なのかも明確には分かってなかったり。。。こういうの企業内だとどういう職種が担当するんだろう
専門職種がないわけではないですが、サービスを作る人・データを使う人が理解している必要があります。ビジネスを考える人たちが最低限のことは知っておく必要がある。ビジネスリテラシーとして大切。

海外でのデータ管理でこの国はリスクがある、なしを判断する際に参考になるようなまとめサイトはあるのでしょうか?
海外の法制度に関する情報は個人情報保護委員会が調査結果を報告しているのでこちらが参考になるかと思います。

令和2年 改正個人情報保護法について |個人情報保護委員会

ただリスクに関しては何を基準にリスクになるかが、事業者によって異なると思うので、まずはリスクになりそうな事象を定義してしまう方が優先かと思います。

昨今のアジャイル開発による将来的な機能追加を考慮すると、プログレッシブプロファイリングといった最小プライバシーを踏まえる必要があると思います。会員登録としてどういった情報を収集するのか?という観点では、どういった点を考慮するとよいのでしょうか?
この辺りはデータの最小化の議論(Data Minimizationと英語圏では呼ばれます)と繋がっていくのですが、まずは何のためにデータを取得するのかを議論する必要があると思います。今日スライドで紹介した駐車場アプリを例に出すと、アプリの利便性としては駐車場の空き状況が可視化されることでサービス価値が担保されるため個車を特定するような情報を取得しなくても良いという結論でデータ収集をおこなっています。そのサービス価値を前提とした際に、GPS等の位置情報技術を利用するのではなく、物理的なセンサーを駐車場に設置してセンサーが車体を感知したか否かのみで判断するようになっています(もちろん車以外の何かが止まってしまってセンサーが反応する場合もありますが、いずれにせよ空き状況がわかれば良いのでそのリスクについては目をつむっているのではないかと推測します)。このようにデータと目的が一致することが必要で、目的達成のために最小のデータを集められれば良いという考え方が重要になるかと思います。会員登録に関しても、何を目的として会員情報(そもそも会員とは一体なのかの議論から始めても良いかもしれません)を取得するのかをまずは議論し、その決定に基づいて必要な情報を必要な期間収集することが必要になるかと思います。


ここからはセミナー講師の栗原さんとパーソルキャリアの海保さんのお二人で参加者の質問に答えながらディスカッションをしていただきました。

ディスカッション/Q&Aコーナー

(右)栗原 宏平さん/一般社団法人Privacy by Design Lab 代表理事
(左)海保 雄樹さん/パーソルキャリア株式会社 リードエンジニア


海保:
プライバシーは個人情報のように明確なものではないので、奥が深いと思います。人によって嫌だと感じる部分も違うと思いますが、そのことをあまり考えてしまうと、サービス開発など新しいことを始める際に大変だなと感じました。この点に対し、どうすればポジティブに考えられるのでしょうか。

栗原:データを活用したことでマイナスになることは、少なからずあると思います。例えば、知らない所から電話があったときなどは嫌な気分になると思いますが、そういったデータの使い方はあまり良くありません。結局は、それに対する配慮をどこまで考えるかがポイントだと思います。ビジネスでは必ず何かしらのリスクが発生すると思いますが、それはデータに対しても同じように言えるので、出来る限り使ってはいけない方法を潰していくために、議論を重ねる必要があります。
サービスを作る前に起こり得る問題をきちんと議論することが、ビジネスの視点で見たときに重要になります。

Mitz(ファシリテーター):実際に、実務で困っていることなどはありますか。

海保:プライバシーという言葉自体が、個人情報保護法と混同されがちです。社内でもプライバシーを重視していないわけではありませんが、そこまで意識が浸透していないと感じています。そういった新しい考えをサービス開発の現場に持ち込んだときに、果たしてきちんと議論できるのかという不安もあります。

栗原:どんな会社にも提供できるような「このようにすればいい」というHowは、残念ながらありません。しかし一方で、「こういう事は嫌だよね」ということを意見を出し合って洗い出すことは可能だと思います。例えば、「自分の家族のデータが使われたらどうか」という視点に立って考えるだけでも違いますよね。
視点を変えて考え「あなただったらどう思うか」ということを受けいれる空気感をどう作るか。それを身近な対象の人に当てはめて考えてみるというのは、あまり難しく考えずにできることだと思います。

海保:サービスによって発生するプライバシーが違うので、決まりきったものはないということですよね。

栗原:そうですね。使えるデータを組み合わせるということが起き始めています。それはクリエイティブにとってはとても重要ですが、中には「混ぜるな、危険」のようなデータもあるはずです。そういったことも議論する必要がありますね。何でも組み合わせれば良いものが生まれるとは限りません。

海保:同意を得ていて、その通りに使っているから良いということではない…。ということですね。

栗原:もちろん同意を得るのは大前提ですが、「何に同意したのか」がポイントです。例えば郵便を配達してほしいから住所を教えたのにDMが届いてしまった、ということがあるように、使い方を間違えてしまうとそれだけで不信感が生まれてしまいます。同意を得ることに重きを置きすぎると利用者にとって想定外のことが生まれがちなので、同意を取っていても議論した方がいいと思います。

Mitz:参加者から企業内ではどのような職種が担当するのかといった質問がありましたが、それはサービス開発の段階で議論を行って、意見を出しあうということで、専門の職種があるわけではないのでしょうか。

栗原:プライバシー専門の職種もありますが、企画・開発・運用などプロダクトに関わる多くの人。そしてデータを扱う人が理解していることが理想です。その上で、例えば法律のことは社内や外部の専門家に聞いてください。プライバシーに対する知見を持っている方が、ビジネスコミュニケーションもよりしやすくなると思います。

海保:弊社では個人情報に対する意識については情報セキュリティや個人情報保護法といった守るべきところについては社内体制もガッチリ取り組んでいますが、プライバシーに対しては社内でもさらに議論を進めていく必要があると思っています。そしてプライバシーに対する理解を広げていくことで、ユーザーにとってより良いサービスが出来てくると考えています。

Mitz:栗原さんから何かアドバイスはありますでしょうか。

栗原:いろいろな産業の方がデジタル化していこうというときには少なからず情報がデータ化されていきますが、そうなると知らないうちにデータを持つことになります。
システムを作るときにはオープンソースなど様々な要素を持ってくると思いますが、デジタルの環境でポイントとなるのは、いろいろな人が協力して新しいものが生まれるということです。デジタル環境に関わる人たちがみんなプライバシーの対策を行えば、自己完結ではなくなります。そういう意味で、デジタルを使う人達が配慮しなければならないと理解する人が社内で増えていけば、新しいものが生まれてくると思います。

海保:理解者を増やすために、企業の取り組みとしてプライバシー関連の活動および対策をしていることをアピールするためには、どうすればいいでしょうか。

栗原:何をもって対策しているとするのかという議論にもなってきます。
1つは、定期的なアップデートの中で取り組みを発信し、それを“見える化“することが大事だと思います。例えばアメリカでは最近プライバシーブラウザが出ていて、どのデータを取るのかを示すようになっています。それによって、どのようにプライバシーを配慮しているのかが利用者にも分かるようになっています。利用者が見えるような設計をするというのは、取り組みとしてもできることですね。
極論を言えば、利用者の方は良いサービスを受けられればいいのだと思います。しかしそのために、自分のデータが違う形で利用されていると不安になるので、その点の配慮の仕方が利用者に伝わるだけでも安心感に繋がると思います。

海保:アピールの仕方は難しいですね…頑張ります。

栗原:大変なことですが、見えることによって信頼にも繋がります。

Mitz:参加者からの質問です。プライバシーポリシーとかプライバシーマークなんかはフワっと聞いたことがありますが、「Privacy by Design」という言葉はこれから当たり前になっていくのでしょうか。

栗原:そうですね。
 “ポリシー”は読み飛ばすものだったと思います。長いし、テンプレなところもあり…
ただ、そこがアプリなどをインストールしたときに最初に通る道です。そこを工夫するだけで、ユーザー体験は大分変わる可能性はあります。「デザイン」という言葉は広いので、独自性を持たせることがいいのかなと思います。

※参考情報ですがこちらがSNSの判決です。
データスクレイピングに適法判断 LinkedIn/hiQ訴訟

cloud.watch.impress.co.jp

Mitz:参加者から「プライバシーの意識について日本と世界の違いはありますでしょうか。」という声もあがっていますが、いかがでしょうか。

栗原:プライバシーという言葉が日本語ではないので、言語として存在するかどうかの違いがあります。共通した思想の有無、環境面など…。
欧米との意識の違いを感じる時があります。日本だと、家族のような信頼できる人には自分のプライバシーも打ち明ける。そこまで親しくない人とは意図的に打ち明ける内容も変わってくる。そういった文化的な違いがあります。欧米だと、「これはプライバシーだから止めてくれ」と断ることもしっかりとできます。日本はまだそこまでのプライバシーへの主張は薄いかもしれません。

Mitz:ありがとうございます。少し話題が変わりますが、コメントで“プライバシーパラドックス”について話題があがっていました。こちらについてはいかがでしょうか。

栗原:プライバシーを重視していると言いながら、実際の行動にはその価値観が反映されていないというギャップを“プライバシーパラドックス”と呼んでいます。ギャップの解消には同意が大事だと言われますが、「何に同意したのか」という点については議論がされていないので矛盾していますよね。例えば恋愛関係で、心が通じ合っていたときは色々と渡していたものを、別れたときには返してほしいとなるときがありますが、企業相手でも同じように、返さなければならない(オプトアウト)時についての議論を行う必要があります。
同意という行為自体に目を向けすぎるよりは、個人と企業の関係性がより流動的になりその中でデータのやり取りがされているときに、そのやり取りが分かりやすく行われる設計ができていると、データもより価値が出てくると思います。

海保:「返してもらえる」と分かっていれば、渡しやすいですよね。

栗原:おそらくその通りです。例えばマイナンバーカードを作る際に、登録後して第三者に自分の番号を教えなければいけない場合に、必要に応じてお渡しした第三者からいつでも自分の番号情報を返してもらえるような設計になっていれば、最初の登録時のハードルはもっと下がっていると思いますね。その点がもっとカジュアルな方が、関係性としては良好だと思います。

Mitz:テクノロジーの進化でプライバシーデザインも変わっていくものでしょうか。コロナ禍での変化や加速なんかもありましたでしょうか。

海保:実は私はコロナ禍で転職してきたので、弊社内のコロナ禍前後のサービスの変化についてはわかりかねますが、前職の際、在宅で仕事をするようになったので、カメラで部屋や顔を写すことに抵抗を覚えましたが、その点への配慮はありました。

栗原:働く環境の変化は大きいですね。プライベートとパブリックの境界線については、これから議論をする必要があると思います。デジタルを使う動きは加速していくと考えていますが、そうなったときに、自分の情報をどこまで見られるようにするのかについては、どこかのタイミングで議論をしなければなりません。コロナはこの動きを後押ししたと思います。「デジタルが便利だ」という社会に変わってきていると思うので、その社会にある自分のデータに関しても考える必要があります。今は、知らない所で自分のデータが流通している、言わば無法地帯です。なので各社が一度立ち止まって考える良い機会だと、個人的には思っています。

Mitz:データ活用のなかで「個人が特定されないデータ環境(データクリーンルーム)」といった話も耳にします。こうした環境は栗原さんとしては「プライバシーが守られている」という扱いと認識されているのでしょうか?

栗原:例えば、「栗原さん」だと個人を特定できますが、「ボーダーのシャツを着ている人」だと個人を特定できない。法律自体を設計しているから守られる部分と、そうでない部分がある。マイナンバーカードは国が全部管理しているわけじゃないとしても、国が信用できないから使わないといった感情論が走ることもある。
プライバシーという視点が入ったときに、どんな目的でどんなデータを使っているかの説明が大切になっていきます。

Mitz:最後にもう一つ参加者からの質問をピックアップしたいと思います。「企業で絶対にNGな事例(特に日本)とか、ここは気を付けろー!なお話をお聞きしたい。」とのことですが、いかがでしょうか。

栗原:人事データは気を付けた方がいい。分析しよう!の流れがあって、それ自体は良いこと。ただ、強制的に導入して、社員の同意がないままそれをしていくのはどうなのかなぁと思うことはあります。

海保:サービスを利用される方が登録した瞬間に、その人が何のために登録するのか認識していることが重要だと思います。そこの齟齬がないようにするためには、ご提供いただいたデータがサービスの中でどのように使われ利用される方々に価値として還元されているのかをわかりやすく説明していくことが重要だと思っています。


イベントレポートは以上となります!
次回のレポートもお楽しみに♪

【イベントレポート】UXデザイン勉強会vol.4~UXデザイン海外最新トレンドと事例LT~

 

こんにちは!TECH Street編集部です!

2022年9月22日(木)に開催した、 「UXデザイン勉強会vol.4~UXデザイン海外最新トレンドと事例LT~」のイベントレポートをお届けします。

UXデザインはコンテンツ、企画、マーケティング、エンジニアリング、カスタマーサポートなどすべての職種で学んでおきたいカテゴリです。今回は最新版「UXトレンドレポート2022」を読みながら、今のUXデザインのトレンドをプロダクト開発にどのように取り込んでいけばいいかを考える羽山さんのセミナーと2人のUXデザイナーによる知見共有セッションを行いました!


登壇者はこの方々!

羽山 祥樹さん/日本ウェブデザイン株式会社
氏家浩史さん/パーソルキャリア株式会社
土田哲哉さん/株式会社Surface&Architecture

 

まずは羽山さんより「UXトレンドレポート2022」を読みながら、今のUXデザインのトレンドをプロダクト開発にどのように取り込んでいけばいいかを発表してくださいました。

 

UXデザインの海外最新「UXトレンドレポート2022」を読んで、考える

羽山:今回は3つのUXデザインに関するレポートを見ていきたいと思います。
まずはオーストリアのUXコンサルティング会社「youspi」さんのレポートです。
世界中のUXデザイナーやUXリサーチャーにアンケート調査して、定点観測を実施しています。今回は最新版である「UXトレンドレポート2022」をみながら、ポイントとなるレポートをまとめてみました。

UXトレンドレポート2022「youspi(オーストリア)」

【調査トピック①】今年、エクスペリエンスデザイン業界でもっともよく耳にしたバズワードは何ですか?

意外だったのは2022年版には“リモート”が入っていないことです。
おそらくリモート調査が当たり前になってしまったのでしょうね。

また、昨年は目立っていなかったのですが…
【オムニチャネル】【シームレス】【パーソナライゼーション】が注目されています。
これらは10年ほど前にweb業界でバズワードでした。

2010年頃は複数のデバイスをまたいで、一貫した体験を提供できるということが話題になっていました。2022年の現在では、コロナ禍でリアル店舗に行けなくなっても、リアルでもネットでも一貫した顧客体験ができることを指していると思われます。

2010年頃はデバイスが異なったとしてもいずれもwebでの話でしたが、2022年現在ではリアルでもネットでも一貫した顧客体験、しかもパーソナライゼーションされた顧客体験を提供することが求められるようになったと理解しました。

【調査トピック②】会社のエクスペリエンスデザイン予算について変化すると思いますか?

こちらは「予算が増える」という認識が過半数をしめています。
これはコロナ禍で多くの企業がレイオフや新規雇用の停止をするなか、UXへの投資予算は増加の見通しをしていることになります。つまり「企業の競争力の源泉はUXにある」という認識が広がっている印象を受けました。

【調査トピック③】来年(2022年)、もっとも重要なエクスペリエンスデザインのトレンドは何でしょうか。

「プレディクティブUX」とは、パーソナライゼーションを機械学習 (AI) の力ですること。ただAIプロダクトのUXデザインを担当している私としては「AIでどんな体験を提供できるか理解しているのか」それをわからずに回答している人が多いのでは?という印象です。

【調査トピック④】UX業界関係者にとって、来年もっとも重要になるトピックは何でしょうか?

こちらも上位に「ビッグデータ&AI」がランクインしていますが、先ほどのエクスペリエンスデザインへのアンケートと同様にAIで何ができるかも分からずに重要なトピックであると回答しているのではないか、という印象を持っています。
さらに目立つキーワードとして“アクセシビリティ”“サスナビリティ”“エシカルデザイン”など人の多様性や倫理観を大切にするキーワードが目立ちました。コロナ禍によるニューノーマールな価値観が広まったことに起因するのでしょう。

【調査トピック⑤】今後、エクスペリエンスデザインの支援が求められるのは業界でしょうか?

また今後エクスペリエンスデザインの支援が求められる業界のアンケート結果でもコロナ禍の影響が予想されます。急拡大したリモートワークにより精神的かつ肉体的に病む人が増えたことにより、オンライン診療などのサービスが急増したヘルスケア業界やオンライン授業が拡大した教育関係の関心が高いことがわかりました。

2022年以降台頭するUI/UXデザイントレンド「UXPin (アメリカ)」

次のレポートは2022年以降に台頭するUI/UXデザインのトレンドについてです。
以下の10項目のデザイントレンドが注目されています。

以上が10のデザイントレンドです。
その中でも3と9について考察していきたいと思います。

3、音声ユーザーインターフェース(VUI)について

音声ユーザーインターフェース(VUI)について、本当に伸びているのでしょうか。
●Discord や Slack Huddle のようにチームコミュニケーションからゲームのエンターテイメントまで、ボイスチャットがなくてはならないものになった。
●音声配信サービス Twitter スペース、 Clubhouse なども拡大した。
このような流れを見ていると、体感としては、注目すべきはVUIよりボイスコミュニケーションのUXではないだろうかと感じています。

9、コンテンツとUXのローカライズについて

英語を中心にインターネットは進化しましたが、世界中を見たときにインターネット利用者の50%は中国語です。日本では5Gが普及していますが、世界的には3Gがベースの回線で一番伸びているのはアフリカです。そのため、今後グローバルな方向に展開していくのは自然な流れになると思います。

2022年のUX時流「UserZoom (アメリカ)」

次にUXの時流について、企業がどのようにUXに取り組んでいるかを調査したレポートのまとめです。
まずユーザーインサイトは製品・サービス改善に活かせていないというのが実情です。

UXリサーチを評価指標として開発プロセスに組み込めば成果がでるのは明白にもかかわらず、40%以上の企業がUXの意思決定をするプロセスがありません。逆に革新的な企業はUXのマネジメントと戦略の責務を執行役員に移行しています。UXの重要性を理解しても、UXチームが「経営層の言葉」を話せるようにならなければ会社全体の意思決定にUXを組み込むことは容易ではないからです。70%以上の企業が「UXリサーチの需要が増加している」と答えているのにも関わらず過半数が「予算が変わらない」と回答していますが、これはダイレクトに経営層へ投資価値を説明できていないことを示しています。また経営層がUXを評価するにあたって“誤った指標”を使っている企業も多いようです。

またUXリサーチに対する障害としてもっとも多かったのは「時間」
「限られたインサイトでより早く開発を進める」か「製品開発を遅らせてでも高品質のインサイトでより深く進む」かの二択になってしまうと、UXチームがうまく貢献できなくなってしまいます。

「UXは大切だ」と多くの人が思い始めているが、それに対してどれくらい投資すればいいのか、何を根拠に投資の判断をすればいいのか、いくら指標が動けば投資判断が適切だったとみなせばよいのか…etc」整理がついていないというのが現状です。

UXデザインの2022年のトレンドまとめ

前途にある通り、まだまだ理解度は不足しているが、需要は高まっているのがUXデザインです。このトレンドを頭において皆様の働く場所でもUXデザインの価値を高めてみてください。

Q&A(羽山 祥樹さん/日本ウェブデザイン株式会社)

海外ではUXリサーチャーやUXデザイナーといった、「UX○○」という専門のポジションは存在しますか?それともUXを意識することは既に当然なこととして認識され専門ポジションは見当たらないことが多いのでしょうか?
羽山:以前、Googleでは「UXはもはや当たり前なのでUXというポジションの職種はなくす」というニュースがありましたが、いま調べてみたところ、GoogleでふつうにUXデザイナーの募集をしていました。また、Meta(Facebook)でも UXリサーチャーを募集していました。 似たようなロールがありました。海外でもふつうに「UX○○」という職種はあるようです。

デザインの嗜好が日本と海外でだいぶ違うのはなぜですか?
羽山:そんなに異なるのでしょうか。たしかに国ごとに文化の異なりによる差異や、民俗性、ローカライゼーションはあります。他方で日本人がゴッホを好きだったり、日本のKawaii文化が海外で人気だったりと、けっきょくは相手とコンテキストの共有がされているかどうかではないか、という気がします。

羽山様のスライドのこだわりは?!フォントも??
羽山:今回のスライドになぞらえていうならば「ハジケ祭り」です(笑)。プレゼンテーションは、まず参加者の人に楽しんでいただかないと、中身に入っていただけません。そのためには、ノウハウの伝授である前に、エンターテイメントであることが必要だと思っています。

デザインエンジニア、UXエンジニア、DesignTechnologistのようなデザインとエンジニアリングを仲介するロールは今後企業から重宝されていくでしょうか?
羽山:デザインとエンジニアのバランスをとって、プロダクトをつくっていく役割の人は、以前から存在しました。Web制作ではディレクター、システム開発ではプロジェクトマネージャーなどと呼ばれてきました。近年では、プロダクトという単位で、デザインとエンジニアのバランスをとって、プロダクトがユーザーにとってどうあるべきかを判断する人材として、プロダクトマネージャーという名称で、そのような人材が求められていることが多くなってきた印象があります。

お話いただいたスライド、欲しいです!
羽山:SlideShareで共有しておりますので、ご参照ください。
https://www.slideshare.net/storywriterjp/uxux2022

今後、UXを推進していくために「経営陣を納得させる」にはどうすればよいでしょうか。羽山さんの過去のご経験で実践されていたことなど差し支えなければお伺いしたいです・・・!
羽山:経験として、ユーザビリティテストを繰り返し、そのユーザビリティテストに毎回、経営陣に同席してもらう、という方法をとることで、事業方針のピボットを促したことがあります。事業方針のピボットのような大きな意思決定の場合、経営陣も部下から上がってきたレポートだけではなかなか決断ができず、身体知として「ユーザーが求めているものと、自分たちが提供しているものが異なる」という感覚をもってもらうことが必要です。そのためには、ユーザビリティテストに何回も経営陣に同席してもらうと、最初は「たまたま今回のユーザーはターゲットユーザーじゃなかったんだ」という姿勢だった経営陣も、何人ものユーザーが目の前でプロダクトにつまづくのを目の当たりにし続けると「ひょっとして自分たちが提供しているプロダクトは根本的に間違っているのでは・・・」という感覚をもってもらうことができます。

社内での一番の壁は何でしょうか?
UXデザインは、ユーザーリサーチをする以上に、それを社内に納得してもらうことのほうが難しいです。羽山はいつも「UXデザインの半分は組織論」と言っています。
失敗しない対策としては、組織論なので、関連部署への十分な根回しや、社内権力(偉い人)の利用、味方を社内につくる、といった地道な社内政治が効果的です。

エンジニアとの連携はどのようにやってますか?お客さんとのコミュニケーションとかもリモートでイケちゃいますか?
はい、コロナ禍になってから、エンジニアとの連携や、お客様(クライアント)との調整、ユーザーリサーチなど、すべてリモートに移行しましたが、とくに大きな課題を感じずに業務をできています。

テクノロジーと人の力、どちらがUX的な効果がでますか?
テクノロジーと人を分けて考えようとしていること自体が、UX目線ではないように思われます。ユーザーから見たとき、あなたのプロダクトやサービスはすべて一貫したもので、どの部分がテクノロジーでどの部分が人的なものであるかは関係ありません。たとえば、最新の家電を購入したとして、故障したときにサポートセンターの人の対応が悪ければ、そのプロダクトのUXは悪かった、とユーザーには感じられますし、仮にサポートセンターの対応がよくても、そもそもプロダクトの機能が求めていたものに満たなければ、やはりユーザーにとって悪い体験であった、となります。
「テクノロジーと人」という分け方自体が、そもそも「提供者側の目線」で、ユーザーの目線(UX)ではそれらは分離されるものではありません。

よいドキュメントの見分け方などはありますでしょうか?
ドキュメントを見た人が、短時間(3秒くらい)で主旨を理解することができ、かつ説得されるようにつくられているドキュメントが、よいドキュメントだと考えます。

チームビルディングする上で心理的安全性を醸成していく工夫などがあれば教えて下さい。
ファシリテーションするときに、「この場はうまくいかないことや失敗したことを責める場ではなく、状況をみんなに共有する場だ」ときちんと宣言しておくようにします。その上で進捗遅れやトラブルの報告については、「報告してくれてありがとう」と感謝を示すことです。また、ファシリーションのなかで、会議の参加者全員に、1回は発言の機会を回すようにします。これを継続すると「安心して失敗を報告できる場」をつくることができます。

日本と海外とで、UXに対する認識にどのような違いがあるでしょうか? 例えば組織のトップから末端メンバーにいたるまでUXを意識した考えができ、企画・提案時も「そのUXは・・・」とUXを意識する頻度も高いでしょうか?
日本と海外というより、企業によって意識の高低がある印象です。海外でもCxOレベルでUXに取り組む企業もあれば、やはり役員がまったくUXに理解のない企業もあると聞いています。これは日本国内でも同じなので、世界中みんなそうなのかな、と思っています。

UX改善を小さく実施して、組織としてUX改善の成果を早く実感したい場合はどうすれば良いでしょうか?また成果が出た場合、UX改善によるものだと断定するにはどういった手法がありますか?
すでにプロダクトがあるのであれば、ユーザビリティテストをして、プロダクトのコンバージョンまでのクリティカルパス上にあるユーザビリティエラーをどんどん減らしていけば、短期的に成果を上げやすいです。また計測も、明確に「この画面のここを修正したらCVRがいくつ上がった」と言いやすいので、わかりやすいです。

社内の各部署がUXを意識して業務に取り組むために効果的な習慣としてどういったものがありそうでしょうか?
理想的にはユーザインタビューやユーザビリティテストにそれぞれの社員に同席してもらい、じっさいのユーザーを目の当たりにしてもらうことです。ただ、なかなか難しいかと思うので、ユーザインタビューやユーザビリティテストで得られた「ユーザーの生の発言」を各チームに共有するだけでも、新しい視点の提供になるかと思います。

効果的でないUX改善業務を発見するにはどうすれば良いですか? UXを追求することには誰も反対しないと思いますが、業務フローが膨れ上がるのもコスト増(工数など)に繋がり、最終的にはサービス提供価値の低迷・UX悪化に繋がりそうです。
UXデザインやUXリサーチも、ビジネスとしてやるうえでは投資対効果を求められます。なので、改善すると投資対効果が高いと思われる課題について、優先的に取り組むとよいと思います。たとえば、すでにプロダクトがあるのであれば、ユーザビリティテストをして、プロダクトのコンバージョンまでのクリティカルパス上にあるユーザビリティエラーを改善することに注力する、というように優先度をつけます。

転職を考えている求職者側から見て「この会社はUX追究に熱心そうだ」と判断つきやすいポイントはあったりしますか?(※応募前から面接までのフェーズにおいて)
まずは社内に「UXテザイナー(UI/UXデザイナーではなくUXデザイナー)」に相当する人がいること、その企業が自社のUXデザインについて積極的に発信しているかどうかで、あるていどの検討はつくかと思います。たとえば freee は社内にUXリサーチチームがあり、ウェブやイベントを通じて積極的な情報発信をしています。SmartHRは一昨年にはじめてのUXデザイナーを採用し、そのあと自社のデザインシステムを公開するなど、やはり積極的な情報発信をしています。

外部パートナー(フリーランスなど)にUX改善業務の一部を依頼するとすれば、具体的にはどういった業務が割り当てられることが多いでしょうか?
むしろ仕事を依頼する企業側の、社内のUX成熟度によって異なると思います。UXデザインの経験がまったくない企業であれば、UXデザインのプロセス全体をお願いしたり、チームがUXデザインを習得できるように継続的な伴走を依頼します。逆に、社内にシニアレベルのUXデザイナーがいるのであれば、社内シニアUXデザイナーが調査の全体像を設計して、人手が足りないリサーチの一部などを外部委託する、ということになるかと思います。

UX改善の失敗事例として、どういったものがあるでしょうか?またそれら失敗事例の共通点として何がありそうですか?失敗しないよう事前に対策することは現実的でしょうか?
いちばん多い失敗事例は、ユーザー体験にとって明らかに不都合が出ているにもかかわらず、社内説得に失敗して、改善プロジェクトを立ち上げることに頓挫するケースだと思います。UXデザインは、ユーザーリサーチをする以上に、それを社内に納得してもらうことのほうが難しいです。羽山はいつも「UXデザインの半分は組織論」と言っています。失敗しない対策としては、組織論なので、関連部署への十分な根回しや、社内権力(偉い人)の利用、味方を社内につくる、といった地道な社内政治が効果的です。

社内外からのUX改善の提案を受けてその採用可否を決めるにあたって、重要な要素としてどういったものが挙げられますか? (予算や納期などUX改善に限らない検討事項は除外)
自社プロダクトのユーザーの本質的な心理や課題を解決する提案になっているかどうかです。これはじつはとても難しい判断です。「そもそもあなたは自社プロダクトのユーザーの本質的な心理や課題を『本当に』理解しているのか」「あなたが自社プロダクトのユーザーの本質的な心理や課題だと思い込んでいるものは、たんに社内のみんながそう言っているだけの先入観ではないか」という問題をクリアできてなければ、他社からの提案の妥当性を判断することはできません。つまり「ユーザーを正しく理解する」というフェーズを経ないで、いきなり「UX改善の施策の提案」を受けること自体が、あまりよろしくありません。
おすすめとしては、まずは他社に頼らず、自社内でガッツリとUXリサーチに取り組んで「これが本当のユーザー心理だ!」といえるところまで調査しましょう。そうすると、どんなUX改善施策が必要かも、自ずと判断がつきます。ただ、社内にUXリサーチのノウハウがなく、リサーチに取り組むのが独力では難しいようであれば「UX改善の施策の提案」ではなく「社内でUXリサーチができるように伴走してもらう」という提案をお受けするとよいです。

サービスを利用した結果、そのユーザー体験に感情が含まれない場合も多いと思います。例えば不満なく利用できても、それで感情をあらわにするほうが稀でしょう。そういったステージのプロダクトにはどんな視点が重要になってきますか?
2つ視点があります。
まず、プロダクトマネジメントとして、そのプロダクトを使うことで、ユーザーにどうなってほしいのか、という視点です。たとえば飲食店の予約アプリがあったとして、馴染みのお店の予約がスムーズにできてユーザーに不満がなかったとしても、もしプロダクトのビジョンが「これまで行ったことのない新しいお店に出会うセレンディピティを提供する」であれば、このプロダクトの目的は達成されていないことになります。
もう1点は、ユーザーのインサイトです。ただプロダクトを使っていても、その背景にはプロダクトを使うに至るユーザーのさまざまな動機があるはずです。あなたのプロダクトは、その動機のすべてを把握したうえで設計することができているでしょうか。自分の目に見えている範囲でニーズに応えているだけではないでしょうか。ユーザーの心理世界の全体像を調査し、把握したうえでプロダクト改善に臨むと、まだまだやることが多い、というケースが多いと感じています。

もう1点は、ユーザーのインサイトです。ただプロダクトを使っていても、その背景にはプロダクトを使うに至るユーザーのさまざまな動機があるはずです。あなたのプロダクトは、その動機のすべてを把握したうえで設計することができているでしょうか。自分の目に見えている範囲でニーズに応えているだけではないでしょうか。ユーザーの心理世界の全体像を調査し、把握したうえでプロダクト改善に臨むと、まだまだやることが多い、というケースが多いと感じています。

最後の評価とかって数値化・ツール使用、などありますか?ポイントありますか?
コンバージョンポイントが明確なプロダクトの場合は、Googleアナリティクスのようなアクセス解析ツールで数値化することができます。また、会社によってはプロダクト内でNPS(ネット・プロモーター・スコア)のアンケートをとって顧客満足度を測っているケースもあるようです。(ただしNPSが本当にUXを計測できているのか、という議論は業界に存在します)

続いてUXデザインに携わる2人のUXデザイナーによる知見共有セッションです。
まずはパーソルキャリアの氏家さんの発表をご紹介します!

Web・UX業界で10年くらい働いてきて最も効果があった標準化の施策

氏家:本日のテーマは「ナレッジマネジメントと少し標準化」です
まず私はUX領域で扱うサービスは規模が大きく組織力が必要になります。
それに対してナレッジマネジメントや標準化が有効だと思い、組織的に取り組んだ事例がありますのでご紹介したいと思います。

【ナレッジマネジメント】→組織の知識を管理・アップデートすること
【標準化】→作り方や評価方法を組織の中で統一すること

これらは実施が大変な割に効果が実感できないものではないでしょうか?
まず実施できていない根本的な問題としては…

この4つの課題に対しての費用対効果が悪いという部分があげられ、うまく運用していかないと、結果として施策が形骸化しがちだと思います。

組織の取り組み

私の組織でやっていることはこちらです↓

実は、これだけやってもまだ不十分という前提はありますが、まずは6つの施策について、それぞれどのようなことをやっているのかをご紹介します。

①ツール・プロセスの標準化

工数はかなり大変…ただいちいち資料を探す手間が省けます。
利用するフォーマットの向上=成果物の品質向上にもつながっています。

②質のよいドキュメントの収集

ツール・プロセス標準化に比べるとMTGで収集するだけですので負担が少ないです。
収集の手間も省けるので実施する価値はあります。

③タスクフォース化

Slackチャンネルを作り、チーム内での定期MTGでやることを決めていきます。評価方法等も含め組織的に取り組む必要があるため、実施難易度としては高いかもしれません。

④月次標準化MTG

様々な視点で収集された<イケてるツール>を選別する会です。様々な視点をもつ数名のエキスパートでの運用が必要ですが、人材が不足して組織的に運用できないと孤独な作業になるため、おすすめはできません。

⑤半期に一度のお掃除会

「④月次標準化MTG」からさらに6か月単位で判別する作業。
こちらも工数はかかりませんが、④同様に孤独な作業になる可能性はあります。

⑥浸透施策

活動を組織外に周知し、ツール活用を促進させる広報役割です。
ただ時間をかけて資料を作成&プレゼンしたとしても、だいたい「へぇ〜すごい」で終ってしまっています。

そして最初にもお伝えした通り、最も効果があった施策は…
実はこの中にはありません!

私が経験した中で最も効果があったのは、「プロジェクトの振り返りミーティング」を誰でも参加可能にしたことです。かなり入念に設計しました。

プロジェクトの振り返りミーティング

「誰でも参加」というのは…

振り返りミーティングの位置付けは「プロジェクトの評価・称賛の場」としています。

・満足度
・プロジェクト評価(コスト、タイム、品質)
・成果物の紹介と評価
・改善点/成功要因

これらをディスカッションしており、決して<深刻な場所>にはしていません。
よいものはよい、悪いものは何が悪かったかをきちんと把握して次につなげるアクションまでを定める場所として関わった人たちを称賛していました。

ではどのくらい成功したかというと…

組織内外問わず評価が高かったという認識です。

なぜ成功したかというと実施前までは「できないのがばれたくない」「めんどうだなー」という顕在化されていなかった一人ひとりの課題が、「やれば楽しい」「やれば評価される」そしてそれぞれの成功事例を吸収できるようになったからだと思います。
結果的に、ナレッジマネジメントや標準化の大枠が達成されるという好循環につながりました。

では具体的に何をしたか?について、「運営の組織化」「MTGの設計」を中心にご紹介します。

運営の組織化について

職能ごとのエキスパート組織があると導入がしやすくなります。もちろん組織化までには工数がかかりますが、フィードバックの仕方で経験が浅い人たちの視座を大きく引き上げることができ、長期的にみればMTGに参加するだけで組織全体で成果物の品質があがっていきます。

MTGの設計

下記3つを準備/義務化しました。

1.フローの義務化

2.ツール・環境の準備

3.ミーティングのアジェンダ作成

特徴的なのは「テーマ討論」を長く設定したことです。

重要なことにフォーカスして、持ち帰れる、実践しやすい学びにして全員にメリットが有るようにしました。ある意味やりっぱなしでも効果を実感することができました。

結果的に、誰でも質の高いMTGが安定して実践できるようになりました。またファシリテーションの訓練にもつながっています。

ハイスキル人材がMTGにコミットするとメンバーをコーチングする効果があります。
重要な箇所に絞ることで工数をあまりかけずに効果を高めることが可能です。
つまり、キックオフミーティングと振り返りミーティングにハイスキル人材にコミットしてもらうことが、ナレッジマネジメントの観点からみても有効であると考えています。

ということで最初の議題にもどると・・・

標準化・ナレッジマネジメントは

費用対効果がわるい✖

実はめっちゃ効果ある○

後日談ですが、MTGのオープン化は効果があったので、社内のほぼすべてのMTG(秘匿性の高い内容以外)がオープン化されました。その結果、メンバーの学習効率が飛躍的にあがったのでぜひ試してみてください。

まとめ

振り返りMTGの設計と実施は標準化・ナレッジマネジメントに効果は絶大です。
堅いMTGは避けて、参加しやすいMTGをつくるまでの工程は少し大変ですが、実施の価値はあると思いますのでみなさんもぜひ実施してみてはいかがでしょうか。

Q&A(氏家浩史さん/パーソルキャリア株式会社)

パーソルさん内はUX意識高い人が多いですか?
氏家:僕は入社して1年未満なのですが、部署内にはUX意識の高い人が多いです。全体では、まだそこまでではないかもしれません。ただ、社内でヨコグシで浸透させていこうという動きはあります。

社員人数が多い企業だとUXリサーチやUXデザインに限らず、上司や役員や経営陣の想いがなんだかんだ優先されがちという先入観があるのですが、そういった場合はどのように折り合いつけているのでしょうか。
氏家:受託から事業会社に転職してその壁にぶち当たっています...!基本的にユーザーに提供したい価値はブレてないはずなので、ユーザーエクスペリエンスを損なわないことを大切にしつつ、自分を含めた実行者が大切にしている思いや考え方に配慮しながら進行していきたいと考えています。

氏家さんが現在担当されているプロジェクトについて教えていただきたいです。既存のサービスに対してなのか、新規サービスを立ち上げるのかでまた少しUXデザイナーとしての社内での動き方が変わると思っていまして。 また、新規と既存、それぞれのプロジェクトでUXデザイナーとして気を付けるべきことがあればお願いいたします。
氏家:「新規」に携わっています。大事なのはチームビルディングです。起案者とプロダクトオーナーがイコールでない場合があります。そのプロダクトへの想いが人によって異なることがあります。チームビルディングの時点で意識あわせを目的としたワークを意識して行っています。

エンジニアとの連携はどのようにやってますか?お客さんとのコミュニケーションとかもリモートでイケちゃいますか?
エンジニアをなるべく早期に巻き込むことを意識してプロジェクトを設計しています。
企画や設計段階、それよりもっと前の段階からコミットしてもらうと、エンジニアも腑に落ちて開発や仕様策定が可能かと。クライアントや社内関わらず、納得して仕事を進められるような配慮をしています。

よいドキュメントの見分け方などはありますでしょうか?
標準化の観点としては以下を大切にしています。
・品質の高さ:内容及び結論に至るロジックと、ハイスキルな人間からの評価
・汎用性の高さ:属人性が少なく、様々な人間が再現できるプロセスになっているか

チームビルディングする上で心理的安全性を醸成していく工夫などがあれば教えて下さい。
社内、社外に関わらず関わるメンバーの人となりがわかるようなワークであったり、そのプロジェクトを通してどのような価値を実現したいか、自分はどういう成長をしたいか、ということをまず最初に明らかにします。
また、ワークスタイル、コミュニケーションスタイル、ライフスタイルも人によって違うので、そのあたりを意識的にオープンにすることを心がけています。

 

最後にSurface&Architectureの土田さんの発表をご紹介します!

 

チームのためのUXデザイン

土田: まず本テーマになっている「チームのためのUXデザイン」についてですが、「受託業務でよりよいチームを作るために、UXデザインで大事にしていること」をお話させていただければと思います。

受託UXデザインにおける課題

受託に限らない課題ではありますが、ビジネス、テック、デザインの向いてる方向が異なります。
本来はユーザー体験のため、3つのチームが1つの方向を向いた結果で、プロダクトの価値を高めていくのがあるべき姿です。UXとは本来、総合的な価値であって「利益、機能、美的、すべてが関わってプロダクトの全体の価値になる」という価値観をチームに関わる全員が持つべきだと考えています。

どうやってデザイナー以外を巻き込むか

ではまずどのようにしてデザイナー以外を巻き込むのか?
特に受託業務においてはタイミングが重要です。

非デザイナーがUXデザインの意識を持ってプロジェクトに参加してもらうための考え方を登山で例えます。

登山ではまず「自分が登る山がどの程度の難易度か、レベルにあっているか」などの情報収集は必要不可欠です。UXデザインでも競合や類似事例、マーケット状況などをリサーチして、ターゲット、コンセプト設定のための情報を収集します。

情報収集後、登山の最大の目標であり、ゴールである「どこが山の頂上か」を定めてからルートを確認します。UXデザインでも特に「ターゲット&コンセプト策定」の部分が重要です。

「登山ルートの決定」はワイヤーフレーム/プロトタイプを作成して画面構成に矛盾がないかを確認します。UXデザインではワークショップを実施し、参加者全員でサービスのターゲットを策定するのが重点ポイントとなってきます。

いよいよ実際に山を登っていきます。メンバーごとにデザイン、開発の実制作に入り、最初に作ったコンセプトやターゲットからズレていないかを確認しながら開発を進行していきます。

「登山」の後は登山の感想や次回につなげるための反省会。UXデザインでは完成したプロダクトのKPIを確認し、改善を行っていきます。

「ターゲット&コンセプト策定」が重要

最初にお伝えした通り、この「登山」過程で最も重要なのは「ターゲット&コンセプト策定」だと思います。
なぜ「ターゲット&コンセプト策定」が重要かというと、ここで作ったものが「チーム全体の価値観」になるからです。
この段階でいかに経営者やビジネス、エンジニアなど関係者を巻き込めるかでチームの価値もあがってくると思います。
どのメンバーもゴールに近づくほど目の前のハードルに注視する必要があるため、このポイントでいかに全員が“自分事化するか、チーム全員が目指すゴールを合わせるかが重要です。

受託UXデザインのポイント

最後に改めて受託UXデザインのポイントをまとめます

これらのポイントを実践することで価値観を共有することによるスムーズなコミュニケーションを得ることができ、クライアントと一緒に作り上げる達成感が生まれます。是非皆様も効果を実感してみてください。


Q&A(土田哲哉さん/株式会社Surface&Architecture)

受託はやはり全く異なるのですね、こんな人は壁になる、ということはありますか?
土田:前提を共有されずに要件だけをお願いされると大変ですね。コミュニケーションの問題が発生してしまうところです。

規模が大きければ大きいほど色々方向性がバラバラ、みたいな感じもアルアルですか?
土田:関わってる案件は大きいものが多いのですが、関係者が多いと自分ゴトにしてくれるチームを作るのが難しいですね。

まきこみ、、、やはり最後には人の問題ということですよね、、、
土田:私たちがお手伝いして、皆さんに意識をもってもらうことが大切なのかなと思います。

経営者を巻き込んで価値観を作っていく。めちゃ大事だと思います!でも経営者の価値観が強すぎて方向性迷子になることが多々あります。そういう時UXデザイナーとしてビシッと説得力あることが言えたらいいのにと思ってます。苦戦中です。
土田:「価値観が強い」が必ずしも悪いことではないですが、ワークショップに参加してもらうとやりやすいと思います。そこに至るまでの考え方なども経営者と共有することが可能です。

最後の評価とかって数値化・ツール使用、などありますか?ポイントありますか?
土田:ツールはGoogle アナリティクスを使っています。あまり変わったものは使っていません。

先程の流れで一番キッツいのはどの箇所ですか?どういう業種でも同じでしょうか?
土田:考えることが大変なのはコンセプト設計のところ。しかし、我々の本分でもあります。設計をひっくり返されるとキツいです…。

社内外からのUX改善の提案を受けてその採用可否を決めるにあたって、重要な要素としてどういったものが挙げられますか? (予算や納期などUX改善に限らない検討事項は除外)
本質的なプロダクトの価値を押し上げるものであるべきだと考えますが、受託側としては予算、納期の縛りが重視されてしまうジレンマを感じます。

チームビルディングする上で心理的安全性を醸成していく工夫などがあれば教えて下さい。
メンバーの意見は常に尊重し、意見を取り入れられない場合でもその理由は丁寧に説明するようにしています。また細かいですがリモートミーティングでは基本常に顔を出して、こちらの表情が伝わるように心がけています。

よいドキュメントの見分け方などはありますでしょうか?
結論が明確で、その後にすべきこと、メリット・デメリットがすぐに分かるものが良いと思います。

社員人数が多い企業だとUXリサーチやUXデザインに限らず、上司や役員や経営陣の想いがなんだかんだ優先されがちという先入観があるのですが、そういった場合はどのように折り合いつけているのでしょうか。
上層部側の判断は経営視点の価値観も含まれていますので、そういった場合はより広い視点をもっている方を優先しています。

テクノロジーと人の力、どちらがUX的な効果がでますか?
「UX的な効果」が何かによりますが、情緒的なものであれば人のちからが重要だと考えています。

エンジニアとの連携はどのようにやってますか?お客さんとのコミュニケーションとかもリモートでイケちゃいますか?
コロナ以降はほぼすべての打ち合わせがリモートでのやり取りになっています。

 

お話いただいたスライド、欲しいです!
下記にアップしました!
https://docs.google.com/presentation/d/1SgBL49qSxoZwK4cg4uu43Ko0VMIjBzxP8IQSxX6eNK4/edit?usp=sharing

デザインエンジニア、UXエンジニア、DesignTechnologistのようなデザインとエンジニアリングを仲介するロールは今後企業から重宝されていくでしょうか?
エンジニアの職能が細分化されていることで、デザインとエンジニア両面を見れる人材は重要になってくると考えています。

デザインの嗜好が日本と海外でだいぶ違うのはなぜですか?
様々なデザインがあるので一概には言えませんが、日本語の文字は情報量が多いのでその影響は大きいと考えています。

サービスを利用した結果、そのユーザー体験に感情が含まれない場合も多いと思います。例えば不満なく利用できても、それで感情をあらわにするほうが稀でしょう。そういったステージのプロダクトにはどんな視点が重要になってきますか?
サービス提供者側がどのようなビジョンを持っているか、サービスを通してユーザーが感じ取れることが重要だと考えています。

UX改善の失敗事例として、どういったものがあるでしょうか?またそれら失敗事例の共通点として何がありそうですか?失敗しないよう事前に対策することは現実的でしょうか?
個人的にはいかにステークホルダーを巻き込むかが重要だと考えています。クライアントにUX改善を自分ごととして考えてもらわないと、小手先の改善で終わってしまい本質的な改善とならないことが多いです。

外部パートナー(フリーランスなど)にUX改善業務の一部を依頼するとすれば、具体的にはどういった業務が割り当てられることが多いでしょうか?
外部のパートナーさんが入る場合はワークショップへ参加してもらったり、そのワークショップを踏まえたワイヤーフレーム制作を担っていただくことが多いです。

転職を考えている求職者側から見て「この会社はUX追究に熱心そうだ」と判断つきやすいポイントはあったりしますか?(※応募前から面接までのフェーズにおいて)
UX関連の情報を社内で共有していたり、勉強会などを定期的に開催している会社が良いと思います。

効果的でないUX改善業務を発見するにはどうすれば良いですか? UXを追求することには誰も反対しないと思いますが、業務フローが膨れ上がるのもコスト増(工数など)に繋がり、最終的にはサービス提供価値の低迷・UX悪化に繋がりそうです。
はじめからすべてのUX改善を行う必要はないと考えています。プロダクトを通してユーザーが利用前、利用後にどう変化するかを定義し、その変化への影響度が大きい(と思われる)ものから順次着手するのがよいと考えています。

社内の各部署がUXを意識して業務に取り組むために効果的な習慣としてどういったものがありそうでしょうか?
プロダクトの各機能、各画面に対してユーザーがどういう気持ちで触れるか、触れることでどう気持ちが変化するかを常に考えるようにしています。

 

イベントレポートは以上となります!
次回のレポートもお楽しみに♪

 

 

【イベントレポート】エンジニアの自由研究発表会vol.7

 


こんにちは!TECH Street編集部です!

2022年9月1日(木)に開催した、 「エンジニアの自由研究発表会vol.7」のイベントレポートをお届けします。このイベントは長期休暇中にエンジニアリングスキルを活かしてユニーク&こだわりの自由研究に取り組んだ成果を披露するTECH Streetの定番イベントです。

今回の登壇者はこの方々!※登壇順に記載

発明家の小栗さん
沖中がいこつさん
豊田 陽介さん
木戸康平さん
airpocketさん

発表者の想いやこだわりが詰まった自由研究の成果をテキストだけで表現するのはもったいない!ぜひ当日参加できなかった人にも見てほしい!・・・ということで今回は当日の動画を中心に紹介いたします。

自分で作ったものを商品化/発明家の小栗さん

youtu.be

小栗さんが開発されたUIクリエーターは「PCをコントロールする、センサー付き自動キーボード」です。キーボード・マウス・ゲームパッドなどがUIクリエイターの中にはいっています。そしてその動作をマクロで組むことができるようになってます。そして動作設計はブラウザーから簡単にできるようになっています。ビジュアルでブロックを積むだけ。いわゆるノーコードで組めるようになっています。

最初にUIクリエイターで「画像を簡単に切り抜くという動作」を実演。そして後半は「Fabrication=ものづくりとアートに境目はない」ということについて語っていただきました!

twitter.com

100日自由研究 アナログスーパー店員の自作アプリが社内導入!/
沖中がいこつさん

youtu.be

続いて沖中がいこつさんの発表は、なんと社内導入もされた!?というアプリ開発のお話です。開発したのは「休憩管理」をするためのアプリ。今回は試験導入ということですが、導入に至るまでの紆余曲折ストーリーは共感する人も多いのではないでしょうか。「現場から声を大切に、めげずに開発することが大事」と再認識することができました!

twitter.com

ブラウザ上でファンタジー・SF的な映像表現に挑んでみる
/豊田 陽介さん

youtu.be

豊田さんの自由研究は「ブラウザ上(JavaScript)の処理でSF的な映像表現」というTwitterでも話題になっていた作品です。
まるで魔法使いになったような豊田さんのデモ映像も合わせてぜひご覧ください!

①透明マント
https://youtu.be/hC7aml8pTa0
②指先に炎が順番に灯っていく
https://youtu.be/wyOzbHk_tVE
③手から出現した円が溶けて流れる
https://youtu.be/sYfiYhNIPUU
④画面が燃える、手から稲妻が発生
https://youtu.be/z6AO_YmTDQo

twitter.com

ドミノ倒しレース/木戸康平さん

youtu.be

続いて木戸さんの発表です。木戸さんは「島でIoT」という自然ネタを発表する予定が、頭の中が「ドミノ倒し」でいっぱいになってしまった!ということで急遽ネタを変更。obniz(オブナイズ)と特別な知識がなくてもプログラミングが体験できるIoTブロックMESHを使ったIoTドミノ倒しに挑戦した話を発表してくださいました!

twitter.com

microbitを使って親子で自由研究/airpocketさん

youtu.be

最後にairpocketさんの発表です。メイカー界隈では有名なコミュニケーションロボットのスタックちゃんをご存じでしょうか?今回はスタックちゃんのようなコミュニケーションロボットをmicrobitを使って親子で自由研究に取り組んだお話を発表してくださいました!

twitter.com

 

発表いただいた5人の個性あふれる発表はいかがでしたでしょうか。TECH Streetの自由研究発表会は春休み明け(5月)、夏休み明け(9月)冬休み明け(1月)と年に3回のペースで開催しています。「発表してみたい!」という方はぜひTwitterDMなどから気軽にお問い合わせください♪

▼TECH StreetのTwitterアカウントはコチラ

twitter.com

【イベントレポート】セキュリティエンジニア勉強会〜社内のセキュリティ環境ってどうしている!?知見・課題を共有〜

 

こんにちは!TECH Street編集部です!

今回は2022年8月18日(木)に開催した、 「セキュリティエンジニア勉強会〜社内のセキュリティ環境ってどうしている!?知見・課題を共有〜」のイベントレポートをお届けします。

はたらき方の変化に伴い、ここ数年で社内の業務フローや業務環境なども変化してきていると思います。​セキュリティ運用担当者はその変化に合わせて常に安全な環境を用意しなければなりません。
イベントではベンダー側と事業会社側それぞれの視点で、各社のセキュリティ運用担当者が環境変化に伴い、どのような課題と向き合い、どのように対応してきたのかなど課題や知見を共有する会を開催しました!

登壇者は
臼田 佳祐さん/クラスメソッド株式会社
柿田 一さん/パーソルキャリア株式会社
月島 学さん/パーソルキャリア株式会社

早速、内容を紹介いたします!

まずはクラスメソッド株式会社 臼田さんの発表です。

AWS環境のセキュリティ、どうやってチェックしてる?

※登壇資料はコチラ

dev.classmethod.jp

クラスメソッド株式会社AWS事業本部のセキュリティチームでリーダーを務めている臼田と申します。今回はAWSのセキュリティ対策にまだ本格的に取り組めていない情シスやセキュリティエンジニアの皆さんに向けて、3つのことを持ち帰っていただきたいと思います。

<持ち帰っていただきたいこと>
・とにかく「最強のAWS基礎セキュリティベストプラクティスを使う」ということ。
・全員巻き込んでポジティブにセキュリティを強化すること。
・中級以降からAWSの知識は必須。

AWSのセキュリティはどこからやるの?

まずはAWSセキュリティをどこからやるのか?についてですが私はクラウド特有のセットアップが重要だと考えます。
最初にやっていただきたいのはIAMユーザーの作成です。AWSアカウントを最初に作るときにできるルートユーザーは使ってはいけないというベストプラクティスがあるため、MFAで使わないように封印しておきましょう。

IAMについて

“IAM”は聞きなれない方々もいらっしゃるかもしれませんが【Identity and Access Management】の略でありAWSにおけるアクセス制御の基本かつ極意です。IAMを知っている人でも突き詰めていくと知らないこともあるので、常に抑える必要があるサービスです。

次に必要なサービスを有効化していきましょう。主要なサービスをピックアップして解説します。

CloudTrailについて

AWSはほぼすべての操作がAPIで実行されますが、そのAPIの実行履歴を記録するサービス=CloudTrailを有効化してログの保存が重要になってきます。

Configについて

AWSの各リソース単位の設定変更を管理できるAWS Configで、変更履歴を管理できるように設定しましょう。

Well-Architectedフレームワークについて

AWSのベストプラクティスを把握してAWSを使うということで、Well-Architected フレームワークを使います。実際にシステムを作る、運用していく上ではこの5つの柱が重要な要素となるので、これらをしっかりと押さえていく必要があります。

Well-Architected フレームワークはスルメのようなもの。
これは膨大な資料で、詳細に書かれた別の資料もあるので、読み込むためにはとても時間がかかります。よって最初は概要レベルでさらっと読み、繰り返し読んでいくことによってだんだんと理解ができるようになっていくとおもいます。
AWSに関わるどのフェーズでも参照できるドキュメントになっているので、スルメのように何度も咀嚼して使うのがオススメです!しかし最初からこのドキュメントを見てもよく分からないのでこういったブログなどの解説を見ながら活用すると良いと思います。

AWS Security Hubを使ったセキュリティチェック

AWSを利用する大前提としてすべてのAWS利用者は、AWSの基本的なセキュリティを理解する必要があります。例えば、社内でAWSのサービスを使う場合には最低限押さえるべき社内のルールを作り、ベースラインを作るためのベーシックな教育プランのコンテンツやドキュメントを用意するといったことが大切になります。

とはいえ、ゼロベースで考えるのは大変…よってAWS Security Hubを使ったセキュリティチェックを活用するとよいと思います。そもそもAWSの良いところはマネージドサービスで“楽“ができるところです。

マネージドサービスとは?

AWSにはある程度の仕組みが用意されているので、やりたいことを実現するためのインフラストラクチャーを利用することができます。
インフラストラクチャーの管理も重要な仕事の1つですが、管理だけを行えばよいというわけではありません。そのインフラストラクチャーを使ってビジネス上の成功をおさめる、ビジネスに貢献することが大事だと思いますので、やらなくても良いことはAWSに任せるなどして他の業務に集中してもらいたいと思います。

セキュリティに関するマネージドサービスはいくつかありますが、その中でも先ほど「AWS Security Hub」についてご紹介します。

対応リソースが38種類もあり、カバレッジが非常に広いのがAWS Security Hubの特徴です。

運用する上でのポイントは…

「AWS Security Hub」を使うと、一括で設定が可能です。あとはあがってきた項目に対応するだけで、セキュリティが向上していくのでとても効率的です。

しかし、「AWS Security Hub」を有効化して終わりではありません。継続的に新しいリソースを作成し、新しい設定をいれると、それが正しい設定なのか、より良い設定が他にないかを「AWS Security Hub」が都度チェックしてくれるようになります。そしてチェック時に新しい問題が起きたことを通知する設定をしておくことも重要です。デフォルトでは通知を飛ばすという機能はついていないので、ご注意ください。
さらに共有&見える化のためにみんなが見える場所に通知して展開することも必須です。担当者だけに通知しても意味がありません。

次に「AWS Security Hub」の直接的な機能ではないのですが、違反項目を自動的に修復するソリューションもあります。ぜひこちらも使っていただくと良いと思います。しかしよく検証してから活用することをおすすめします。

クラウドセキュリティのメリットを最大限享受するには

AWSのセキュリティの考え方として「AWSに関わる人すべてがセキュリティの担当者であり全員でセキュリティの課題に取り組むこと」が重要で役割や対応する範囲などが違うだけで、多かれ少なかれAWSに携わるということは、みんなで協力してセキュリティを担当するべきです。
AWSのセキュリティスコアはみんながチェックできるようにしていきましょう。

周りを巻き込む手法として、セキュリティスコアを関係者に全体通知すると良いでしょう。ただ、残念なことに現在はセキュリティスコアをAPIで直接取得することはできません。取得する方法はこちらで紹介していますので是非参考にしてみてください。

またセキュリティスコアを全体通知する際に重要なのは「セキュリティスコアの高い順に通知して称えあう」ことです。セキュリティスコアが低い順のランキングは経験上何も生み出しません。ネガティブなフローが回ってしまいますので避けたほうが良いでしょう。ポジティブにセキュリティ対策することがとても大事です。

クラウド利用範囲が広範囲になってきたらCCoEなど、クラウドを推進する組織づくりに力を入れる必要もでてくると思います。

様々な部門を早い段階から巻き込むことがポイントとなるでしょう。

まとめ

・基本的なセットアップをやる
・Security Hubを有効化してAWS基礎セキュリティのベストプラクティスを活用する
・全員で取り組める仕組みを作り、周りを巻き込む

この3つがAWSセキュリティに取り組む上で必要になってくると私は考えています。

Q&A(クラスメソッド 臼田さん)

(Q)クラスメソッドさんは様々な企業のAWS導入支援をされていらっしゃいますが、セキュリティ設定の失敗・課題アリパターンなどはこれまでどのようなものがあったのでしょうか。
→細かい例はお話できませんが、運用されないセキュリティが一番課題だと感じています。色んな要素、課題がありますが、入れたはいいけど実際は使っていないということもあります。例えばAWS Security Hub入れたはいいけど、そこから修正など出来ていない。有効化したあとに自動的に上がってくる修正ポイントを是正ができてない点がもったいないと感じています。

(Q)AWSは未体験なのですが、AzureやGCPなどとも共通する、重要ポイントも知りたいです。
AzureやGCPは特に注力していないのでわかりませんが、それぞれ、クラウドに注力しているサービスですね。AWS含め、クラウドは楽しいものだと思っています。従来のITシステムは泥臭い感じのものが多かったです。1つのことをやるのにインフラをしっかり組んだり、工程が多かった。クラウドはオンプレミスに比べると圧倒的に簡単にできるのが良いところです。クラウドだから、良くなっている部分は他のサービスも同様に良いところだと思います。そこに注目して使ってみてください。

(Q)クラスメソッドさんといえばAWSですね。エンジニアとしてのAWS情報はどこで収集していますか?
社内にAWSに詳しいエンジニアが沢山いるので、質問・相談がしやすく環境には恵まれています。自分では、AWSがリリースしている最新情報のRSS( https://aws.amazon.com/jp/new/ )などを眺めています。これは、毎朝必ずチェックしています。その中で自分が注力している分野は、実際に触ってチェックしたりブログに書いたりキャッチアップをしています。ただRSSから直接情報を収集するのも大変なので、まとまったわかりやすい情報として週刊AWSも参考になります

(Q)クラスメソッドさんの体制、エンジニアのなかのセキュリティ担当?の位置付け?知りたいです
うちの会社でも「情報システム部」のような部門があります。会社としてもAWSを活用していますので、私の部署とは別なのですが、社内セキュリティの部門と相談しながらお手伝いすることもあります。

(Q)セキュリティ観点で他に無いAWSの良さ、また、ここもうちょい改善求む、をお聞きしたいです。
(他サービスとの比較はできませんが)個人的に感じる良さは、AWS Security Hubみたいに人が泥臭いことをやらなくても、AWSがうまくやってくれる点です。
他にもAmazon Detectiveではログを分析して自動的に関連性を紐づけしてくれるところが楽になるので助かってます。改善点というかコンセプトの違いですが、AWSのサービスはビルディングブロックとして色んな機能をパーツごとにリリースしているので、自由度が高い反面、組み合わせて使うにはナレッジやコツが必要なところは意識する必要があります。


続いてパーソルキャリア 柿田さんの発表です。


事業会社のITセキュリティ担当のゼロトラスト導入に向けた挑戦


突然ですがみなさん、自社のセキュリティ対策のレベルはどのように評価していますか?
それぞれ課題感や問題意識を持っているからこそ、今回のイベントに参加しているのではと思います。
例えばこのようなサイバーセキュリティ事故を経験された方もいらっしゃるのではないでしょうか?

ITセキュリティの世界においてターゲットにならない企業は存在しません。いかに攻撃者に厄介な相手と思わせるか、攻撃しにくい相手と思わせるかが大切です。
守りの部分で採用している製品や構成の開示は避けたいという企業も多いかと思いますが、今回の発表内容を参考に「まずは試してみよう」と思っていただける方が少しでも増えれば幸いです。

本日はエンジニアリング環境におけるゼロトラスト導入の挑戦についてお話したいと思います。
※前提として「エンジニアリング環境」とは個人情報が蓄積されている環境とは異なる開発用の環境を指します。

ゼロトラスト導入に挑戦した経緯

パーソルキャリアは10年ほど前にエンジニア組織を立ち上げ、テクノロジー本部が立ち上がったのはここ数年です。今でこそ数百名規模のエンジニア組織となりましたが、それまでは外注中心で、内製開発が進んできたのもここ数年の出来事です。その変遷から「エンジニアリング専用の環境が社内にない」ことが課題となっていました。

こちらの図は以前までの社内と外部の構造です。
クラウドファーストと言われる状況ながら、そもそもクラウドにつなぐためにはプロキシサーバを経由する必要があります。しかし、その申請から承認までに驚くほど時間と手間がかかっていました。その結果、生産性もモチベーションも落ちるという由々しき事態に陥っていました。
そこで…そのような状態を解消するためにゼロトラスト導入の挑戦が始まりました。

何のためにゼロトラストを導入するのか

ゼロトラストを導入すること自体が目的とならないように、「何を実現するために
ゼロトラストを導入するのか」をまずはしっかりと定義しました。

やはり開発を進める上でネックとなっていた
1.外部クラウドサービス利用申請の障壁撤廃
2.1による開発効率/柔軟性の低下防止
に重点をおいてCASB(Cloud Access Security Broker)から試そうと判断しました。

CASB導入後の構成
まずCASB導入後の社内と外部の構造はこちらです。

あくまで端末にCASBのエージェントを入れて、そのエージェント経由でもろもろのクラウドサービスを使用するようにしました。内部ネットワークは根本的に変えるのは難しいので引き続き残っていますが、新しく作ったエンジニアリング環境と外部との間には、ゼロトラストによる防御ベースを導入しました。

では「CASB導入に際して難しいプロセスがあったか」というと、以下の2ステップのみです。

・CASB(DLP含む)での制御ポリシーの設定
・対象者端末へのエージェント配布

これ以降は試行利用を続けてもらいフィードバックを受けてチューニングを繰り返しました。
ただ「その制御ポリシーを決めるのが苦労する」という方も多いと思いますので、パーソルキャリアが実装しているポリシーの一部をご紹介します。

弊社では細かく制御はしていません。最低限守りたいというコンセプトを決めたら、それを実現するためのポリシーを設定するようにしています。我々は転職支援のサービスを提供しているので、お客様の個人情報をお預かりしています。この情報は絶対に死守、最も高いプライオリティで守らなければならないので、個人の情報に関しては外部取り扱いをNGとしています。例えば設計書の情報など、これに属さない機微な情報であれば扱って良いという前提になっていますが、それを個人で使っているメールなどに載せてしまうのはもちろんNGです。


CASB以外にもSASEの機能をいくつか採用しています。

みなさんがゼロトラストに挑戦する際に、最初に導入するのは<IDとアクセス制限を管理>できる【IAM】になるかと思います。
認証認可を最初に整備した上で、制御のところを整えるというのが自然な流れになるでしょう。


こちらはCASB導入後の全体図です。
青みがかっているオブジェクトが採用済み、グレーのオブジェクトは未採用となっています。

ゼロトラスト導入時に技術周りで苦戦したこと

参考までにゼロトラスト導入時に技術周りで特に苦戦したことをご紹介します。
ご存知の方もいらっしゃると思いますが、CASBはNetskopeさんの製品を使用しています。
簡単に仕組みを説明するとネットワークのエージェントがデバイス側に入ってきて、そのエージェントがNetskopeのプロキシサーバーを経由して、クラウドアクセスをするという仕組みになっています。
実はこのネットワークのプロキシを経由する段階でNetskopeが元の証明書を複合化して、「自己証明書」を添付します。そのため、サーバ側で個別に証明書を持っている場合は、「Netskopeが発行して添付する証明書もちゃんと信頼してね」という設定を対象にする必要があります。サービス毎に一回設定をすれば終わりではなく、デバイス毎に設定をする必要があるため「正直面倒くさいんですけれども・・」というお話を結構いただきました。
ただ、大変ではありますが、手順書やスクリプトも用意しながら環境を整えることによって、利用者の協力と理解を得ることができました。


私が大事なポイントとして考えているのはエンジニアのプライバシー面、心理的安全性の配慮です。
その上で
・アクセスログは蓄積していること
・不正な情報持出や明らかに業務上無関係なサイトの閲覧時はアラートが生成され、操作内容について確認する可能性があること

この2点に関して事前同意を得ることでゼロトラストの導入が浸透することができました。

まとめ

最後に改めてゼロトラスト導入のポイントをまとめますと

・SASEはツールや機能の導入が目的ではない
・自社のニーズや目的に照らして、段階的に導入することが重要
・導入できるからスモールスタートで「まずやってみよう」というマインドが大事

この3つに重点を置いて皆さんの企業でも導入を検討してみてはいかがでしょうか。

Q&A(パーソルキャリア 柿田さん)

(Q)パーソルキャリアはパーソルテクノロジーさんとかと違うんですよね。グループもデカいですが、セキュリティ関連での連携、情報共有、共通ルールなどありますか?
率直に申し上げると共通ルールなどは設けていないです。
大手のベンダーさんはカンパニー制(事業部制)が多いと思います。我々も似たようなグループ体制を取っていて、グループ会社間の情報共有はあるものの、体系化されているものではありません。
現在の運用としては、パーソルホールディングスが全てのグループ企業の情報を持っているので、必要に応じてパーソルホールディングス側に照会し、グループ会社の担当者を繋いでもらう形を取ってます。

(Q)ZTNAを小規模環境で検証したくとも、本番環境と隔離して取り組めないため進まないことにたいして、どのようにアプローチ・導入すべきでしょうか。 (予算も取りにくいため難儀しています)
実際に我々が取った手法ですが、検証用に新たに端末を数台用意し、そこからインターネット(クラウド)に出て行く部分にSWGやCASBの様にゼロトラストの代表的な機能を挟み、一定期間試行利用してます。
その際、①既存の環境には手を入れない(前述の仕組みであればクラウド側の認証でアクセス元制御が設定されていなければ実施可能。入っている場合はSWGやCASBがプロキシになるので、そこからのアクセスを暫定的に許可。尚、アカウントも検証用に新規に用意)、②試行利用期間として各部署から1〜2名で最低3ヶ月位を設け、現場で問題無いと言う評価をしてもらう、この2点を前提に弊社内は承認をもらっています。
ベンダーさんによりOK/NGはありますが、人数・期間も限定であれば、無償で評価利用をさせて頂けるベンダーさんもあるかと思いますので、そういったソリューションをまずは試されるのも一つのアプローチかと思います。

(Q)境界型からCASBを入れて、それを何ヶ年運用し、どう発展させるべきでしょうか。
実際に利用される方の人数や使うクラウドサービスのバリエーションにもよる部分が大きいですが、弊社の場合(最終的に400人位を対象として4部署宛に展開する事をターゲットとした場合)、最大20名で約半年間の試行利用を経た上で、本展開に移りました。
どうしても四半期や半期に一度といったレアな作業も現場にはあり、そういった作業も含め万全を帰した上で導入をする場合は、半年〜最長でも1年程度の試行期間があると、導入後に予期しない事態の発生は極力減らせると思います。

(Q)説明済みならすみません、CASBの費用、教えてください。
これは実際に導入する製品と、購入単位・利用期間の掛け合わせと、ディスカウント適用有無(ベンダー側目線で見た将来性の有無等)による為、ここでお答えする金額を保証出来るものではないですが、例えばCASB製品の定価ベースだと、数千円/1ユーザー(月額)で利用可能なケースが多いと思います。

(Q)CASBを入れると判断された際、リスクアセスメントの結果は考慮されましたか?またその場合、漏洩等した場合の影響はどのように評価/想定されますか?
導入に際しては、リスクマネジメント部門の担当役員も交えて協議をしています。我々の場合、CASBにより制御を行う環境ではお客様からお預かりしている個人情報は取り扱わないという大前提を設ける結論となりました。
その上で、万一取扱を許可する情報が漏洩するとした場合、それはどういう情報で、その結果どの様な事態が発生するか、例えば設計書等にはどんな情報が記載されていて、それが漏洩・悪用されるとどういう事態が考えられるのかはエンジニアがリスクと対策を整理、セキュリティ的な側面以外にも、例えば開発中で世に出す前のプロダクトの情報を持ち出し、他社で先にリリースされるとどんな損害があり、事業側としてそのリスクを許容出来るかを事業側で整理、それら踏まえて最終的にどんなリスクが残り、それを経営として許容出来るか、こういったプロセスで社内で判断をしております。

(Q)誤検知や、過検知は多かったですか?
CASBの誤検知はほとんど無かったと思います。但しEDRはかなり有りますね。なので、ここは徐々にチューニングをして行ったのと、SIEM導入後はAIベースで真にリスクのある挙動を学習してくれるので、現時点での運用負荷はだいぶ軽減されてきたと思います。

(Q)製造業やサービス業など、拠点内で事業活動する業界・業態におけるZTNAのあり方に悩みます。 クラウドは一部使えど、基本的には閉域網のネットワークでシステムは(一応)まわるため、導入の強い利点を上位層に伝えにくい。
確かに仰る通りですね。
もしそういった中で少しずつその必要性に関する啓蒙を始めるとすれば、サプライチェーン攻撃の事例に触れる所からのスタートになるかと思います。
インターネット接続がなくクラウドは利用せずともメールは利用していますという場合、確かにZTNAのメリットをフルに刈り取る事は難しいと思うのも事実ながら、標的型攻撃メールにより社内ネットワークに侵入されるケースというのは多々発生していて、そういったケースに対してはIdPのみ導入、閉域網のネットワーク内でも都度、他要素認証を含む認証が設けられていたりすると、一定被害を軽減出来るケースもあるのではないかと思います。


セキュリティQ&A

最後にセキュリティ対策に詳しい3名のエンジニアによる質疑応答コーナーです。
勉強会当日にあがった質問に答えてくださいました!

セキュリティ担当するのに、資格は必須になるのでしょうか?(目指したい)

臼田:資格自体は不要ですが、色々と勉強しておくことはいいと思います。情報処理安全確保支援士(IPA)は基礎と応用のバランスもよくカバレッジも広いのでおすすめです。
月島:資格は必要ないですが、セキュリティも大事ですが、事業についても把握・学んでおくといいと思います。
柿田:あくまで個人的な意見にはなりますが、実務経験を客観的に第三者的に見ても担保出来る様にするのが資格だと思っています。要は実務経験の保有が第一で、余裕があれば資格を有していると尚可という様に個人としては捉えています。

セキュリティエンジニアになるまでの道程、きっかけを教えてください

柿田:キャリアの入口はインフラエンジニアで、セキュリティはその中で関連があれば取り組んだり、どちらかと言うとネットワーク周りのエンジニアリングの中で携わってきたのみでした。昨今のコロナ禍による柔軟な働き方の整備や、オリンピックの文脈で在宅勤務環境用意のニーズが爆発的になり、この辺りからセキュリティエンジニアリングが中心になっていきました。
月島:セキュリティエンジニアではないのですが、クラウド推進等やっているうえで、セキュリティは重要です。セキュリティが守れていれば安心して使えるという点で、整備への意識は高かったです。
臼田:学生の時に情報セキュリティの学科に所属したことが転機ですが、原理をたどると子供の頃からゲームの裏技が好きだったというものがあります。
情報セキュリティも脆弱性の仕組みと関連しますが、技術的な探究心(こうしたら、想定外の動きができる)が関連していると思います。

わたしはしがない情シスなのですが別部署のセキュリティエンジニアに頭があがらない。追い付きたいと思って勉強していてもどんどん最新情報変わっていくしついて行けないし、もう5X歳だしw

臼田:年齢は関係ないと思います。エンジニアなので、楽しいと思うところを勉強していけば、自分の推進力に繋がると思います。それは最新情報じゃなくてもよいと思います。
全部を把握、というのは誰も出来ません。私も、AWSの全部はキャッチアップしていなくて、自分の好きなセキュリティに特化してキャッチアップ・全体に共有をしています。
柿田:年齢は関係ないです。逆に様々な経験の蓄積やそれとの掛け合わせは強みになると思います。セキュリティ対策はそれ自体が目的なのではなく、事業を推進/支援する為に必要なもので、そういう意味で、もっている経験値とセキュリティの技術などの掛け合わせで他のセキュリティエンジニアには無い強みが出せるのでは無いかと思います。
一般的なクラウドサービス利用のメリットは、簡単に使えるという利点がありますが、クラウドセキュリティ関連サービスについても、同じく簡単に始められて、管理にも複雑なスキルを必要としない製品が多数ある為、そういったサービスを選定されるのを一つの判断基準にされるのも良いかと思います。

IT業界初心者はどのようにセキュリティの勉強をすればいいですか?

臼田:基礎はすごく大事です。どこかのタイミングで、基礎は必ず勉強しておくとよいです。コンピュータサイエンスの分野は様々な基礎につながっているので、コンピューターがどのような原理で動いているのか把握することは大切です。始めるポイントは自分の興味がある分野の周辺の基礎からで問題ありません。Web系ならHTTPなどのプロトコルやネットワークの原理など押さえていくといいでしょう。IT業界にいる限り、基礎は大切。範囲は広いですが、自分の分野から徐々に押さえていくのが良いと思います。
月島:どう作られているのか、などを把握していくのがいいと思います。そこに脆弱性や攻撃を受けやすいところがあると思います。そこの仕組みや関係者を探っていけるといいと思います。
柿田:ITやテクノロジー系のWebサイトをざっと見るだけでも、サイバーセキュリティや攻撃などの情報は沢山掲載されているかと思います。それを引用し、その際ほんの一言自分の見解(どういう事象で何が原因?これに対して自分はこういう対策があると思う等)を社内向けに共有するだけでも、自分の言葉で表現する為、中身を理解する事につながると思います。

やはり常に最新情報の取得は必要ですか?それを追う担当と、社内をガッチリ見る担当に分かれているチームが良いのでしょうか?

臼田:役割分担はそれぞれ得意不得意がありますのでメンバーの状況により判断するところですが、社内で協力体制を組むのはいいと思います。
月島:組織によっても異なるところですが、一極集中で情報をキャッチアップ、発信するという方法や、それぞれの役割毎でキャッチアップ、発信する方法もあると思うので、組織に合ったやり方でいいと思います。AWSなどはアップデートは多いですし、最新情報のキャッチアップはした方がいいです。
柿田:担当の分離はアサイン出来るリソースにもよる為、難しい場合もありますよね。我々の場合はSIEMを利用する事で最新のセキュリティインシデント情報は自動で取り込まれ、機械的に検知出来るようにしているので、マンパワーに頼らない状態を目指しています。
*ちなみに弊社は現在MicrosoftのAzure Sentinelを試行中です。
最新情報の取得はやはり可能な限りされることをお勧めします。日々新たな脆弱性や攻撃手法が発生し、あっという間に身内もその攻撃に晒されているというのが当たり前の世の中になってきていると思います。
進化するセキュリティ対策と、そのデータを取り扱う作業者のメンタルヘルス対策は、表裏一体だと感じました。
臼田:セキュリティの原理のひとつに、データからなるべく人を遠ざけるという考え方があります。
大事なものを扱う人に心理的負荷は少なからずかかってしまいます。なので、環境を分離して本番環境に人が直接触れないようにしたり、安心できるシステムづくりが必要だと思います。
柿田:この人、こんなサイトを参照しているの?とか、人に対する思いがデータがみえることで変わってくることがあります。またバイアス掛かった見方が時に誤った判断をさせてしまうこともあるかと思います。こういった心理的負担や判断誤りを減らすべく、極力機械的にアラートを発するようにしたり、人を介する回数を減らすという工夫をしています。
月島:とても大事なところですね。権限分掌とか、データを触っている人もちゃんとルールを守っているよという明示ができるといいと思います。

セキュリティ対策を考える際、性善説、性悪説どちらで構築していきますか?

臼田:二極的な話なので、それじゃ収まりませんが…。どちらの方面から始めるかという点では会社の状況にあわせた選択がいいと思います。例えば会社のなかで良い文化が出来上がっていて、不正が発生しづらい雰囲気であるなら性善説よりに、誤操作などでリスクを感じるところから取り組む必要がある。社員が多かったり、複雑になって管理が行き届いていないときは性悪説よりで、不正が起きやすい・起きたらまずいポイントから抑止力も含めて対策していく。大事な資産を守るという感覚はどちらも変わらないと思います。
月島:状況やシーンによります。大事な資産に触れるところで、リスクはあります。
リスクの受容も必要な時はあるので、決断が大切。どちらかで断じるのは難しいです。人はミスするという感覚で、動くといいと思います。
柿田:難しい所ですが、正直ベースでお答えすると「使い分けて」いて、社内に取り組みの内容を発信する際は性善説に立ち、理解を得られる様な説明をしていますが、実際の制御は性悪説に立って設定してます。どうしても内部犯行に対しての対策は昨今取らざるを得ず、特に多いのが悪意は無いが、リテラシー不足に起因するリスク含みのオペレーションに対して、しっかりと対策をする為、性悪説に立っての制御をしています。
臼田:セキュリティ対策は終わりがない。性悪説で捉えなければならないところもあるし、性善説でうまくリスクを受容するところも、やっていかなければ回せない。バランスを取るしかない。

SNS投稿のマナーを学ぶこともセキュリティの勉強の1歩だと思いました。

臼田:うちの会社では、仕事しながらSNS触っていても怒られません。それは常識に則った範囲ですが。ただ、危ない発言には抑止力が働くようにはなっています。SNSで発言することは匿名ではありませんから、自宅や会社の窓から全世界に向けて大声を上げている、という責任の認識は必要ですね
メンバーに是正を促す場合も、ただ良くない、と否定するのではなく、具体的な解決策を提示するようにしています。
月島:定期的にコンプライアンスのラーニングの場があります。事例を取り上げていることもあります。お客様の個人情報を取り扱っているので、そこをどうやって守るのかというところは結構厳しめです!

 

イベントレポートは以上となります!
次回のレポートもお楽しみに♪

【イベントレポート】QAエンジニア勉強会

 

こんにちは!TECH Street編集部です!

今回は各社のQAエンジニアが集まり、実際の実務で得た知見や、課題、改善策などを共有しあう「QAエンジニア勉強会」の様子をレポートいたします。

登壇者はこの方々!
hagevvashiさん/株式会社カカクコム
長友 優治さん/クラスメソッド株式会社
銭丸 莉奈さん/株式会社iCARE

早速内容をご紹介いたします!

食べログのソフトウェアテスト自動化デザインパターン

■登壇資料はコチラ



まず食べログにテスト自動化を導入した背景について紹介します。
食べログではリリースから17年間、QA専門組織が存在せず、開発者が開発とQAを両方おこなってきました。その結果、テスト負担が増加しコード修正後のフィードバックが遅い、テストが再利用できないなどの課題を抱えていました。

そこで、2021年6月にQA専門組織を立ち上げ、テスト自動化を導入してソフトウェア化を進めてきました。

ただ、テスト自動化の導入は闇雲に行ってしまうと失敗しがちです。

(失敗例)
・今ある手動テストを単に自動化してしまう
・テスト実行の部分にしかフォーカスが当たっていない
・長期的にソフトウェアとしてメンテナンスしていくという視点が欠けている


そうならないためにテスト自動化で気をつけるポイントは3つあると考えています。

◆テスト自動化で気をつけるポイント
①最初から成功率100%を目指していないか
②テストケースの追加は簡単にできるか
③テスト実行ごとにテスト結果が同一か

この3つにフォーカスを当て事例と結果を紹介していきます。

Developer Productivityチームについて

内容に入る前に私が所属するDeveloper Productivityチームについて紹介いたします。

我々のチームは「開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する」というミッションを掲げて活動しています。

例えば【実装】や【テスト】など開発者の日々の業務がありますが、【実装】であれば<デバッグ>、【テスト】であれば<テスト結果のレポート>など様々な実行結果やテストレポートなどが開発者にフィードバックされています。開発環境やテスト環境の改善を通して、これらのフィードバックの充実化を図るようにしています。

このようなチームの特性をご理解いただいたうえで、DeveloperProductivityチームによる「食べログのテスト自動化」が、導入後どのような結果になったのか、デザインパターンの概要とともにお見せしたいと思います。

食べログのソフトウェアテスト自動化デザインパターン概要

赤い箱/食べログオリジナルのデザインパターン
白い箱/一般的な引用デザインパターン
箱同士の矢印/適応の順序

上から順にパターンを適用し、「このパターンを適用していくと、テスト自動化が成功しますよ」という風に読み取っていただけるかと思います。

結果的に下記の課題に対してテスト自動化を成功させることができました。

【課題】
・早期フィードバック
・テストの再利用の品質が低い

【結果】
・コード修正後、20分以内のフィードバック
・1日10回実行して成功率90%
・要件追従が2~3日でできる

 

テスト自動化基盤の登場人物とアーキテクチャの概要

続いて食べログテスト自動化基盤の登場人物とアーキテクチャの概要について紹介したいと思います。

今回の発表で説明するのは主にブラウザよりも左側についてです。

テストランナー/Cucumber
Cucumberは【SET】が管理する【Feature/Step/Page Object】といったモジュールで構成されていて、<テスト観点表>というテスト条件を網羅したものによって作られています。

これらのモジュールを構成するもととなるのがページ下段のテスト観点表です。
テスト観点表はテスト条件を洗い出したものとなっていて、ゆもつよメソッドを用いて作っています。

 

デザインパターンの詳細説明

続いてパターンの詳細説明に入りたいと思います。

テスト自動化で気をつける3つのポイントに対するパターンを紹介していきます。

最初から成功率100%を目指していないか
→いきなり100%を目指さない
テストケースの追加は簡単にできるか
→テストの実装容易性とフレームワークの変更容易性
テスト実行ごとにテスト結果が同一か
→安定したテストのためのテストケース自動化設計

<パターン概要①:いきなり100%目指さない>

図の状態としては、これからテスト自動化をプロジェクトに導入するところです。

最初から100%成功率を達成してから運用開始を目指すと、テスト自動化を始めてからアウトカムが出るのが遅くなる、あるいは保守にすごく最初から時間かかってしまう、といった問題でテスト自動化の導入に失敗してしまいがちです。

プロジェクトで実用的に使える、すなわちテスト自動化のアウトカムが出てくるのはスプリントがいくつも経過してからということになってしまいます。そうではなく、最初の1スプリントで95%成功率を達成するような計画を立てて、次からのスプリントで100%を目指して改善していく、というようにします。

「100%を最初から目指さない」ということが重要で、”95%”という数字や”スプリント”という表現というものは、あくまでこのデザインパターンを表現する時はメタファーでしかないので、プロジェクトに合わせて適切なものを選んでください。

ではこの”95%”を改善する仕組みを紹介します。
食べログでは「テスト自動化品質のダッシュボード」としてCircleCIの【insights】を使っています。
この【insights】というダッシュボードの特徴は「過去のテストの統計データ」を可視化してくれるところにあります。

・テストのStep数の推移
・実行ごとのテスト失敗率
・テスト実行時間

上記を可視化してくれて、なおかつ過去のすべてのテスト実施結果からテスト失敗率も計算して可視化してくれます。また、テスト失敗率に基づいてStepをソートして可視化も可能です。上から順に失敗率が高いテストが並んでいるという見方ができるため、これによってFlaky Testの特定が簡単にできるようになります。

ではそもそもこのようなFlaky Testを作り込まないために、どういった工夫をしているのかを次から紹介していきたいと思います。

 

<パターン概要②:容易なテスト実装、変更に強いフレームワーク設計>

テスト自動化のアーキテクチャの要求分析や、設計を完了して自動テストのデモができている状態です。

ここで紹介するパターンは、いわゆるフレームワーク設計のことを示しています。
Cucumberは【Featureファイル】と【Stepファイル】という要素で構成されており、テストコードからテスト手順と振る舞いを【Feature】として切り出すというような設計思想を意味しています。

しかし、これだけではまだ【Stepファイル】には色々な責務が残っています。例えば、ページが受け付けるブラウザ操作や、UIパーツが受け付けるプラウザ操作、またライブラリ依存の集約などです。

これらを別のオブジェクトに切り出していくことがメインテーマとなっております。
では、まず【Browser Automation  API Wrapper】パターンから紹介していきます。

ブラウザ操作を自動化するようなテストでは、テストアクションに機能を追加したいことが多数あります。
「食べログ」で検索するときのことを想像してください。

※シナリオ例
食べログの一覧ページを開く

一覧ページで検索条件を指定して検索ボタンをクリックする

検索結果画面に遷移して、レストランの並び順が1番上の店舗をクリック

店舗詳細を確認する

この一連の操作を、Cucumberを用いたテスト自動化ではテスト条件として定義しますが、一連の操作のどこかでテストが落ちてしまった場合、特定が難しいです。

そうならないためにも例えばクリックなどのアクションの直後に「スクリーンショットを撮る」というような機能を追加する必要性が出てくると思います。
そうすると【Stepファイル】の中に「クリックしてスクリーンショット撮る」という実装が散らばり始め、保守が大変になってきます。そこで「クリックしてスクリーンショットを撮る」というアクションを1か所に集約することによって、見つけやすくします。当然変更をしやすくなり、結果DRYな実装となります。

続いて【Page Object/Component Object】もご紹介します。

ブラウザの操作を自動化するテストにおいて、Stepファイル要素の特定処理というのを、Stepファイルに直接書いてしまいがちです。そうすると要素の一部だけの変更があった時にStepファイルのあらゆる箇所を保守しなければならなくなります。
こういった問題を解決するのが【Page Object/Component Object】パターンです。

【Page Object】や【Component Object】は、テスト対象ページのブラウザ操作を集約したオブジェクトです。また、【Page Object】は他のページと共有のUIパーツを【Component Object】として持っています。ページ、UIパーツ固有の情報を集約したオブジェクトを用意することによって画面仕様の変更時に対象オブジェクトを修正するだけで済むようになる、というのが大きなメリットです。また、一度【Page Object】を作ってしまえば、そのページに対する新しいテストの追加が簡単になり、そのページの保守がしやすくなる、というメリットもあります。

<パターン概要③:安定したテストのためのテストケース自動化>

フレームワーク設計が完了し、効率的にテストを保守できるようになっている状態と仮定します。

この状態になったら安定したテストのためのテストケース自動化設計がおすすめです。Flaky Testを減らし安定したテスト実装ができるようになります。

▼安定したテストのためのテストケース自動化における3つのパターン

JSONデータ駆動テスト
StepにWait処理を書かない
ログインタグ

1、JSONデータ駆動テスト

JSONデータ駆動テストはその名の通り、データ駆動テストを更に発展させたものです。
JSONデータ駆動テストは、データ駆動テストのテストパラメータへのデータパターンの追加が難しいという制限を解決しました。
例えば、図の黒い部分、これは”食べログ”でのレストランの検索のシナリオだと思ってください。

青い部分に2次元表のところでかれたセルのデータが入ってきます。このシナリオでは<都道府県>と<エリア1>という検索条件で検索するシナリオですが、例えば<エリア2>や<駅>という検索条件を追加したシナリオを作りたいとします。そういった時にはまず2次元表に列を追加し、それに伴い、Whenに変数の埋め込みを追加するため、Whenの文章が長くなります。その結果、ステップ関数を修正する必要があります。それは仕方のないことですが、今ある<都道府県>と<エリア1>で絞り込むテストとは別に「<エリア2>や<駅>というものを新たに用意してください」ということになるとStep関数を新たに作って対応する必要が出てきてしまいます。もっと複雑なデータ構造の時も同様にStep関数を増やすことで対応していかなければなりません。その原因は、2次元の表形式というのは、表現にある程度の制限があるからです。

こういった問題に対して、我々はこの”検索条件”や”期待結果”というような、シンプルな2列構造にして、それぞれの中にJSON(オブジェクト)で複雑なデータを表現しました。そうすることで、データの種類の追加削除が起きたとしてもテストの手順を変更せずに済むという非常に良いメリットが生まれます。

2、StepにWait処理を書かない

ブラウザ操作を自動化する自動テストでは「対象の要素がない」というエラーで落ちる可能性があります。落ちたり成功したりを繰り返すと、特定が難しくなってしまいます。そういったFlaky Testの出現を防ぐため、stepファイルに要素表示を待つ実装をしがちですが、実装をし忘れてしまうと特定の難しいFlaky Testを作り込んでしまいます。

確実に要素表示を待ってからテストアクションを実行したいため、要素表示を待つComponent Objectのメソッドの実行が完了するのを待ってからPage Objectのインスタンスを返すFactoryメソッドを作りました。その結果表示を待つ処理の実装漏れによるFlaky Testの作り込みが完全になくなりました。

3、ログインタグ

ログインが事前条件となるようなテストはよく実施されていると思います。
”食べログ”のメディアサイトにおいてはログインをしなくても使える機能が大多数な一方、口コミ投稿やネット予約など、“ログインしなければならない機能”というのが、とても重要です。

よってログインを事前条件とするようなテスト実行をしたいのですが、Cucumberでは実行単位がFeatureファイルであり、Featureファイルをまたいだ事前条件などで絞り込みができない、という課題がありました。そこでCucumberにあるタグの絞り込み機能を活用しました。タグで事前条件として”ログイン”というようなものを表現することで、事前条件のタグで絞り込んでテストができるようになりました。ここではログインタグという名前でパターンを紹介しましたが、ログインタグというのはあくまでメタファーでしかなく、ログインユーザの種別であったり様々な事前条件についてこのパターンを適用できます。

ここまで<テスト自動化で気をつける3つのポイント>をご紹介させていただきましたが、いかがでしたか。
ぜひ皆さんの現場でも役立てていただけたらと思います。

食べログでは現在、一緒にお仕事をしてくれるQAエンジニアを募集しています。
こちらもぜひご覧ください!

 

 

より早い段階からテストを - シフトレフトからその先を目指した考え方 -

www.docswell.com

皆さんはテストに対してどのような認識を持たれていますでしょうか?
私の周りではかなり重要だという認識を持っている方が多い印象です。最近は開発者の皆さんも、テストコードをしっかり書くというのが当たり前になってきているように思います。
実際にテストコードを書くと、フィードバックを早くもらえ、変更した部分をセーフティネットのようにチェック出来る、そういうメリットを感じ取られる方が多くなってテストの知見を持っている方は、すごく増えていると思います。

特にアジャイルでソフトウェア開発が主流になりつつあるいま、テストの自動化というのはすごく意識されているのでしょう。最後の方だけでテストするというのではなく、最初の方からテストを考えながら、ずっとテストし続けるということも、かなり意識されていると思います。

シフトレフトとは

私も最近は色々なイベントで【シフトレフト】という言葉をよく聞くようになりました。

【シフトレフト】とは
「テスト活動をソフトウェア開発ライフサイクルの最初の方にシフトすること」

というのが基本的な考えです。

図のように要件定義、設計、実装、テスト、リリースがある時に、左の方から意識してやっていくことで、【品質】の確認を計画段階から継続的に実施します。
【シフトレフト】のいいところはバグ予防やバグの早期発見ができることです。

私もテストには長く携わっていますが、今でも難しいな…と思うことがあります。
システムを十分にテストしたいと思っても、なかなか予算やスケジュールの関係で現実的に難しいです。ご存じかもしれませんが”テストの7原則”として<テストは欠陥があることは示せるけど欠陥がないことは示せません>や<全数テストは不可能>という原則があり、いろんな意味で頭を使う部分も多々あります。ある意味テストも”創造的な仕事”だと思っています。

 

テストレベルを考える

効果的にテストを作る=実用的といっていますが、そういうテストを考える際、最初に考えることの1つとしてコードの「どの部分」を「どのレベル」でテストするかが大切です。

系統的にまとめてマネジメントしていくテストの活動グループを指した言葉で【テストレベル】というものがあり、皆さんの馴染みのある言葉だと、「ユニットテスト」「統合テスト」「システムテスト」などが【テストレベル】です。
この【テストレベル】ごとにメリット、デメリットがあるので、よく考えてテストしていかなければならず、ここでもやはり頭を使います。

例えば「ユニットテスト」は高速でコントロールしやすくて、簡単に書けるというメリットがあります。ただ見つけられないバグなどがあり現実的でないのがデメリットです。ではシステムの「ある部分」を「どこのレベルでテストする」のかを考えるのか?

そこで参考になるものとして、【テストピラミッド】というものがあります。

【テストピラミッド】を見ると「ユニットテスト」が一番下にあり、大きなウェイトを占めています。「ユニットテスト」はより多く実施するようになってきていて、品質の貢献も増してきており、重要性がより求められています。ただ「ユニットテスト」だけでは、全ての品質を担保するにはなかなか難しいので、「統合テスト」「システムテスト」を使っての品質確認が必要です。

参考としてGoogleでは「ユニットテスト80% 統合テスト15% システムテスト5%」というニュアンスで小・中・大でテストを分けてとらえているようです。

 

テストに期待されること


次にテストに期待されることですが
・効果的かどうか
・体系的である
この2つだと思っています。


最初に「効果的である」ということですが、具体的には小さな労力で発見できるバグの数を多くすることが求められています。

テストはシステムのある一面しか発見できません。不具合が限られた部分しかわからず、結局選ばなければならない場面が出てくると思います。そうした時に効率的なテストというのは「何をテストすべきなのか」というのを知ることを考えることは、すごく大事になってくると思っています。

「体系的であること」ということは何かというと、テスト対象に対して、最近は誰が考えても同じようにテストケースの集まり(テストスイート)が出てくることが求められていると思います。なぜかというと「ユニットテスト」などはQAエンジニアやテストエンジニアではなく、開発者が考えるので、「誰がテストを作ったとしても、より良い効果的なテストが出来てこなければならない」となっています。そこで体系的に「誰がやっても」というのが重要だと思います。

では効果的で体系的なテストを作るには、どうした方がいいのか?テストエンジニアもより【シフトレフト】してどんどん関わっていくというのが大事になってくるのかなと思います。そうすることでバグの探索というのがより進んでいくことになりますし、エンジニアとテストエンジニアがうまく交流することで、テストの知見がどんどん広がっていく…ということがよりよくなっていくためには必要になってくるでしょう。

シフトレフトがどんどん進んでいくと、デリバリーサイクルの早い段階でテストに色々と取り組んでいくことになります。よりシフトレフトが深まって、色々な知見が出てくると、パフォーマンステストやセキュリティのテストなど「色々なテストをやろう」「こういうのをやっていかなきゃねとか」という状況が生まれます。すると「テストエンジニアが【品質】のことを考えればいい!」ということではなく、「品質はチームの責任」となって、チーム全体で様々な品質の確認を行うための適切なテストの知見を身につけることが不可欠になってきています。そうすることで、スピード感を持ってソフトウェアを提供できるようになっていくと思います。

テストもいろんな意味で進化してきており、今後もダイナミックに進化していくということが予想されます。よって新しいものが出てきた時に、考えるべきはテストの原理に立ち返ることがより重要になってくると私は考えています。

★欠陥の検出よりも欠陥の防止
★エンドユーザーの利益を念頭に

この2つを考えて「新しいものが出てきた時に、自分たちでどう取り入れるのか」を意識して動くといいでしょう。
また”品質”を高めるためにはチームの良好な協力関係っていうのを築くことがすごく大事になってきます。効果的なコミュニケーションを皆さんも意識して、どんどんテストの世界に進んでください。

QA経験2年で1人目QAエンジニアになって感じた課題と取り組み

■登壇資料はコチラ

まずはiCAREのプロダクトについてご紹介します。iCAREは健康管理システム『Carely』というプロダクトを開発しており、『Carely』は昨年、HRアワード2021を受賞しました。従業員のスマホからストレスチェックや健康診断の予約と結果閲覧、産業医メンバーとの面談などができる健康管理システムです。紙媒体ではなくてデータで従業員の健康管理ができるプロダクトを提供しています。

チームの成り立ちから現在

私が2021年6月に入社した時にQAEチームが発足して所属することになり、半年後1名追加され現在チームメンバーは2名です。
入社時点ではエンジニアの数が25名程度で、開発チームが3チームに分かれていて、各チームで新規機能のプロジェクトを並行して進めていました。
各プロジェクトのリリース頻度は平均的に1〜2か月に1回のミニウォーターフォールのような開発手法で、QAEチームが発足するまでは、エンジニアがテストを実行していました。

 

取り組みと感じた課題 

QAEチーム発足時は毎週1回の定常リリースに対して、重要項目リストのリグレションテストを実施していました。また各プロジェクトに対して、可能なプロジェクトのみテストを実施。
新機能のリリースに伴う一部ドキュメントの更新なども並行して行い、目の前の仕事を必死にこなしていく中で、いくつかの課題にぶつかりました。
 

 
課題①リリース直前に「この機能のテストできる?」という依頼が多発
→これにより首が回らなくなりました。
課題②定常リリースのリグレッションテストの工数が膨大
→1回そのリグレッションテストを回すのも300ケースありリソース的に苦くなりました
課題③チームメンバーのテストに関する知識が不足、さらに経験も浅く、テスト実施に対して自信が持てなかった
→こちらは知識不足な部分もありますが、バグが発生してCSチームにテストケースのレビューをしていただいても、どこか不安なままテストチェックをしていて、自信が持てないということが続いていました。

そこでこの3つの課題に対してそれぞれ改善策を打ち出しました。

課題①
リリース直前にテスト実施の依頼が多発し業務がひっ迫
 
改善策
「バグを発見ではなく防止」というのがQAEチームの理想だということを全社に対して啓蒙活動をしました。また全てのプロジェクトのキックオフミーティングに参加し、上流工程の段階で、QAEチームがどのようにプロジェクトに対して参加できるかというのをPMと相談するようにしました。
また、QAEチームは「今何やっているのか」がリアルタイムでわかるようにガントチャートを作成し、リソースの見える化を図りました。
 
依頼が来てからキャッチアップするのではなく、キックオフミーティングの上流工程から参加することで概要や進捗が見えているため、計画がしやすくなりました。また啓蒙活動することによって、エンジニア側の関心がテストに対しても高くなり、積極的にテストケース作成に協力してくれるようになりました。
 
結果的に限られたQAEチームのリソースの中で、プロダクトにおいて優先度が高いタスクに着手できるようになりました。

課題②
定常リリースのために毎週実行するリグレッションテストの工数が膨大
 
改善策
ローコードテストツールの『mabl』を導入しました。
このテスト自動化というのは作成やメンテナンスがボトルネックになる要因となりますが、週に1回、1時間は絶対にそのツールを触るという時間設定して、エンジニアも交えながらリグレッションテストの項目を少しずつ自動化していきました。
その結果、300ケースほどあるリグレッションテストの5%にあたる15ケースのテスト自動化に成功しました。今のところ時間的に時間的な効果で言うと、10分〜15分程度削減されただけですが、現在も引き続き自動化の作業時間を確保して進めています。

課題③
チームメンバーのテストに関する知識や経験が浅く、テスト実施に対しての自身が持てない
 
改善策
週に1回1時間、チーム内外のメンバーと勉強会を開催しました。
具体的には『Agile Testing Condensed』という本の輪読会や『ソフトウェアテスト技法の練習帳』を共に実施していきました。
チームメンバーの基礎的な技法の理解と、それを生かしたテストケースの作成ができるようになればと思っています。またQAEチーム以外のメンバーも巻き込むことでコミュニケーションが取れ、品質に対してもエンゲージメントが高まりを期待しています。またエンジニア自身の動作確認の精度向上というところを目指していければと考えています。

これまでの取り組みを通して成長したこと

これまでの取り組みを通して、個人的に1年間として成長した部分として、前職のスマートフォン向けアプリのQAだった時よりも”行動力”がすごく飛躍的に上がりました。
自分の裁量で、いくらでも結果が変わるので、自分がやるしかないという気持ちでいろんなことに挑戦できたと思っています。チームが立ち上がってからしばらくは、私も受け身で開発側からすると「依頼すれば何か発見してくれる」という認識だったと感じていました。しかし最近はエンジニアさん側から自発的に上流工程でのテスト作成に取り組むチームが増えているので、今後は上流工程から開発チームやそれ以外のチームなど全社的に巻き込んでテストを作り上げていきたいです。
また自分とチームメンバーの成長や、社内を巻き込む意味も込めて、勉強会の成果をアウトプットして積極的に情報発信していきたいと思います。

 

◆まとめ
いかがだったでしょうか。テストに携わるQAエンジニアたちのそれぞれの思考や工夫が見えた勉強会だったと思います。ぜひ今後の開発に役立ててください。

 

Q&A

ここからは当日のQ&Aを紹介します◎

 

>>次のページへ

 



(Q)テストケースの管理はどのようにされていますでしょうか? テストマネジメントツールなどが利用されている場合、どのように運用されているか知りたいです。
hagevvashiさん
まず、ざっくり「ゆもつよメソッド」で分析したテスト観点という大きな単位をMiroで管理しています。そこから細分化される個々の自動テストシナリオは、CucumberのFeatureファイルとして管理しています。

長友 優治さん
スプレッドシートやマークダウンで書かれていたり。統一されているというところまではいっていないです。

銭丸莉奈さん
各チームでもっているテストケースもあれば、QAチームでもっているテストケースもあります。

 

(Q)QAエンジニアは他のエンジニアとはココが違う(良い意味でも悪い意味でも)みたいな話ありますか?
長友 優治さん
より良いものをお客様に提供しようと思っているという点から考えても、特に違いはないと思っています。
銭丸莉奈さん
ビジネスサイドと開発サイドのどちらもテストを行うため、違いというよりは他のエンジニアよりもユーザーとの距離が近いのかなと思います。

 

(Q)QAエンジニア業務におすすめのツール・サービスがあればお聞きしたいです。
長友 優治さん
ご自身の携わっているものによると思うので、それぞれの状況で合ったものを探されるといいと思います。私の方から何かおすすめするものは今はないです。
銭丸莉奈さん
デシジョンテーブルや組み合わせテストなど、いろいろなテスト技法を手軽に利用できる「GIHOZ」というツールを重宝しています!
現在は主に社内のテスト技法の勉強会のために使用しています。

 

(Q)QAエンジニアのキャリアについて聞いてみたい
hagevvashiさん
私は元々フロントエンジニアで、QAエンジニアになったばかりです。
QAエンジニアになったきっかけはJSTQBのFoundation Level資格をもっていたので、QAチーム立ち上げのときにお声がけいただきました。
長友 優治さん
QAエンジニアを続ける人もいるし、エンジニアにいったり、プロマネにいったりという道もあります。
自分がやりたい道があれば、選択肢は沢山あると思います!

 

(Q)食べログさん自動化基盤すばらしい。どれくらいの期間でここまでたどり着いたのでしたのでしょうか?過去からの体制なんかも聞いてみたいです。
hagevvashiさん
専門家がいないことによる失敗体験もあり、専門組織ができたことはありませんでした。
自動化基盤は設計が2〜3か月、開発が1か月、追加が1か月です。

 

(Q)カカクコムさんの中でも食べログは特殊ですか?他の有名サービスもあるかと思いますが、共有化とか横連携はありますか?
hagevvashiさん
食べログでも始めたばかりなので、どれだけ使われるか、どれだけ成果が出るかを測ってから、横展開もあるかなと思ってます。
今後に期待したいプロジェクトです!

 

(Q)95%はプロジェクトや期間によって適切な数値に変更するとのことですが、食べログの95%はどのようにして決まったのか教えて欲しいです。
hagevvashiさん
どんぶり勘定で、目途を付けてやりました。結果論として効果が出ているので取り組んでみてよかったと思っています!

 

(Q)テスト観点の粒度を聞いてみたいです。
hagevvashiさん
ゆもつよメソッドでいうとカテゴリ分けします。「入力」というカテゴリにはどういう観点があるんだろうなど食べログで言うと、都道府県が1観点です。
全部揃っているわけではないですが、入力における条件を羅列して、過去の観点や障害報告で挙がったポイントなどを目安に作成しています。

 

(Q)使っているツール、サービス、フレームワークとかも聞いてみたいです。
長友 優治さん
テストはJUnitで書かれていて、CircleCIとか使ってデプロイ時に自動で動くようになっています。テスト設計とかは、チームによっていろいろで、スプレッドシートを使っているところなどもあります。
銭丸莉奈さん
テストケースの管理についてはスプレッドシートで管理しています。
また、回帰テストの自動化のためにローコードテスト自動化ツールの「mabl」を使用しています。

 

(Q)Shift Leftは弊社でも取り組んでいるのですが、炎上するPJTであればあるほど開発者が設計・開発に注力してしまいテストに対する対応がおざなりになってくることが多く。炎上系PJTの特徴として、DevとQAの仲が悪いというのがあります。リモートワークで顔がみえないせいも相まって。 開発者が忙しい中でもQAに時間を割いてもらう、仲をよくする工夫は何かしていますでしょうか?
長友 優治さん
そういう例は幸いないのですが…。
レビューの場にテストの人も入れてもらう。ド素人な質問でもいいのでコミュニケーションをとっていくと、エンジニアさんにも気づきがあるし関係構築もできてくる。
炎上しているエンジニアさんは困っているので、プロマネとの間に入っていってあげたり、寄り添えるところは寄り添ってあげる。テストができる状況であれば、その場でやってあげて、フィードバックを早く返してあげるとか、できることをやってあげるといいと思います。

 

(Q)体系的なテストって、「テスト観点」みたいなことでしょうか。
長友 優治さん
「観点」というより、もっと広いです。セキュリティなども含めて、「全部やるテスト」みたいなものです。
テストの全てについて体系的にみんなが理解できるようなものを作れると良いなと思います。

 

(Q)シフトレフトを意識された具体的な取り組みなどお伺いしたいです!(開発者との関わり方、タイミングなど)
長友 優治さん
QA担当者、私1人しかいないのですが、開発者の人と一緒にやる場面があり、そこでコミュニケーションを取れるタイミングがあった。その関係があったので、テストも早めに実施することができた。
それはすごくよかったです!

 

(Q)2名!がんばってますね!(ウチとおなじだからエールを送りたい)マジきついこと沢山ありますよね?エンジニアチームと仲良いです......?
銭丸莉奈さん
私は仲が良いと思っています(笑)
バグ報告をすると感謝されるので、驚きました!企業文化に温かさを感じています。

 

(Q)仕様などのドキュメントはどうやって管理されていますか?利用されているツール、更新頻度などお伺いしたいです!
銭丸莉奈さん
ドキュメントの管理は、ほぼスプレッドシートを活用しています。更新頻度は月に1回くらいです。

 

(Q)プロジェクトのテストと定期リリースのテストは別のテストスイートを使っているのでしょうか
銭丸莉奈さん
定期リリースについては定常のものがあります。プロジェクトは別途テンプレートがあるので、そちらを使っています。

 

(Q)全社への啓蒙活動、理解を得るのは大変ですよね。具体的にどんな啓蒙活動をされてますか?
銭丸莉奈さん
会社の文化として、各部署によって何を目指しているのか何を行っているのか、月に一度報告をしているので、QAチームの活動や目指すところを発信しています。

 

(Q)リソースの見える化をしたら、無茶振りは無くなりましたか?
銭丸莉奈さん
鋭い...!なくなってはないですが、少なくはなったかなと感じています。

 

(Q)めげずに情報発信、大事!(工夫とか聞きたい)
銭丸莉奈さん
わたし自身経験が浅いのですが、QAに対する知識がない方向けに分かりやすい記事を共有したり、啓蒙活動をしています。

 

(Q)上流工程での巻き込みではどんな取り組みがされていますか?
銭丸莉奈さん
プロジェクトの最初のMTGに参加したり、各チームとコミュニケーションをとって、QAをどうしたらいいか確認しています。

 

(Q)エンジニアさんはとにかくテストしたくない!不具合があったら修正すればいいんじゃない?ということでテストをほぼしないのですがどういう啓蒙からはじめるといいでしょうか・・・(同じくQA1人目です
銭丸莉奈さん
チーム全員で品質担保に対する意識上げを行ったらよいと思います!

 

(Q)手動テストは、スクショのエビデンスがセットですか? 請負系の案件の場合、テスト結果の成果物が必要なイメージなので。。。(自社サービスだと明確なフォーマットが決まってないのかなと感じました)
長友 優治さん
不具合が見つかって報告する場合には取ります。特に問題がないのであれば取りません。
UI系で自動化しているテストでは、最近はスクショより動画を撮っておく方が実際にどのような不具合なのかわかりやすいので、そういうのを取れるといいと思っています。
銭丸莉奈さん
不具合報告や不具合まで行かなくても気になったUIについてはスクショや動画を撮ったりエビデンスに使用しますが、それ以外のテストの成果物についてはスクショは撮っていないです。

 

(Q)プロダクトの仕様についてシステム仕様とサービス仕様があり、システム仕様はUTやテストコード、E2E自動化でのアプローチが有用かと思うのですが、サービス仕様へのテストのアプローチはどのような取り組みをされていたり、気にされてますでしょうか
長友 優治さん
システム仕様、サービス仕様と区分けされているのであれば、それぞれをよく読み、また作られた方々にもいろいろ聞いて、テストを考えると思います。特にサービス仕様だからといったような取り組みの違いはないのかと思っています。お客様の求める品質がどういうものなのか、ご自身たちのイメージとのギャップをなくす。そうしたところからキャッチアップしていくといいのではないでしょうか。
銭丸莉奈さん
サービス仕様についてのアプローチとしては、実際のユーザーの使用例などをCSチームなどにヒアリングを行うことがあります。

 

(Q)皆さん何を成果物としていますか?
長友 優治さん
案件やプロジェクトごとに違います。その案件やプロジェクトで決めたものを成果物としています。最初に何をゴールとするかを関係者で握っておくということが大事になってきます。
銭丸莉奈さん
テスト実施したテストケースも成果物ですが、プロジェクトによってテストケース作成だけを行ったり、開発側で作成されたテストケースをレビューするだけの時もあり、その時々で成果物は違いますね。

 

以上が今回のイベントレポートです!次回のイベントもお楽しみに^^

 

 

Community Members

さまざまなテーマで事例や知見を学ぶ
IT・テクノロジー人材のための勉強会コミュニティ