ユーザビリティの評価手法SUMIとWAMMIとは何ぞや?

SUMIとWAMMIは、用語としてはJSTQBのテストアナリストのシラバスの「使用性テスト」の部分に出てきます。ただ用語は出てくるものの、どういったものかはよく分からなかったので、調べたついでにメモしてみました。
なお、出てくる情報は2019/03時点のものです。

SUMIとWAMMI両方に共通するもの

SUMIもWAMMIもアイルランドのコークカレッジ大学で活動するヒューマンファクター研究グループによって開発されたユーザビリティを評価するための調査方法です。
いくつかのアンケート項目が用意され、ユーザにどの程度同意するか答えてもらうことにより、評価を行います。質問の中には、ポジティブなもの、ネガティブなもの、両方が含まれます。(適当に全部「同意」とかで答えられるのを防ぐためですかね)
SUMIはソフトウェアアプリケーションの評価に使われ、WAMMIはウェブサイトの評価に使われます。

SUMIとは

公式HPはこちら
http://sumi.uxp.ie/index.html
Software Usability Measurement Inventoryの略。シラバスでは「ソフトウェア使用性測定一覧表」と訳されています。

全部で50問の設問があり、「ソフトウェアのレスポンスが遅すぎないか」「同僚にこのソフトウェアを勧めるか」といった問いに対して、「同意する/分からない/同意しない」を答えていくものになります。設問の内容については、以下のサイトで英語版のサンプルが見られます。
http://sumi.uxp.ie/en/
こちらを正式に使うには、最小のプランで200ユーロかかる模様。詳細はメールでの問い合わせが必要なようです。日本語対応済み。

WAMMIとは

公式HPはこちら。
http://www.wammi.com/index.html

Website Analysis and Measurement Inventoryの略。シラバスでは「Webサイト解析と測定一覧表」と訳されています。

全部で20問の設問があり、「ウェブサイトには私にとって興味深いものがたくさんある」「このウェブサイトを見て回るのは難しい」といった問いに対して、どの程度同意するかを5段階で評価するものになります。こちらも、以下のサイトで英語版の設問のサンプルを見られます。
http://www.wammi.com/samples/index.html

WAMMIには日本語版はないようです(少なくともHPには記述がありませんでした)

WAMMIの利点は、世界中で使われている評価法のため、過去のウェブサイトのテスト結果から作られた参照用データベースに照らし合わせた結果を見ることができる点です。魅力、操作性、効率、有用性、学習可能性、そして全体的なユーザビリティスコアの6つの領域で、参照用データベースと比較したスコアを見られるそうです。

以上、調べても日本語情報はあまり出てこなかったので、まとめてみました。何かの参考になれば幸いです。

参考

「Advanced Level シラバス日本語版 テストアナリスト」
「ユーザーエクスペリエンスの測定 UXメトリクスの理論と実践」

ユーザーエクスペリエンスの測定 (情報デザインシリーズ)

ユーザーエクスペリエンスの測定 (情報デザインシリーズ)

第70回 脆弱性診断ええんやで(^^)参加メモ

最近脆弱性診断をGUIからできるOWASP ZAPに興味を持っているとつぶやいたら、お勧めいただいた勉強会に行ってきました。脆弱性診断研究会さんが毎月開いているもので、今回のテーマは「ワタシハCSRFチョットデキル」。
security-testing.connpass.com

OWASPってナニ?

Webアプリケーションのセキュリティの啓蒙活動をしてる団体。公式HPはこちら。
www.owasp.org

OWASP ZAPってナニ?

OWASP Zed Attack Proxyの略。OWASPが公開しているフリーのセキュリティ診断ツール。プロキシとして動作してブラウザとWebアプリケーション間の通信の閲覧および改ざんが行える。
www.owasp.org

OWASP ZAPの基本設定

プロテクトモード以外は使用禁止!ほかのモードだと管理外のサイトへ診断を実行する危険性が高い。基本的な使い方は、こちらのQiita記事が分かりやすかったので、リンクさせてもらいます。
qiita.com

CSRFとは

Cross Site Request Forgeli
偽造
対象のサイトにログインしているユーザが、その気がないのに勝手に他のサイトの操作を強制されてしまう

1. 攻撃者が罠サイトを用意
2. 適当なところに罠サイトのURLを貼る
3. 攻撃対象サイトに利用者がログイン
4.別タブで罠サイトにうっかりアクセス
5. 罠サイトのフォームが送信される→知らないうちに、書き込みが完了している
 
 攻撃者側は待つしかないが、ターゲットがリンクを踏んでしまえば投票や投稿が終わっている
 

CSRFをどのように防ぐか

セッションIDによる認証

 ①IDとパスワードを送信してログイン
 ②セッションIDを発行
 ③ログインフラグON
 ④SetCookie
  →WebアプリケーションのURLが変わらない限り同じCookieを送り続ける
 
 罠サイトに設置されているフォームを送信する際に利用者のブラウザからCookieがWebアプリに送信されてしまう

CSRF対策
  • 対策が必要な機能を洗い出し
    • 回復が難しい操作(パスワード変更、決済処理、退会処理など) ※操作を強制するだけで、結果を攻撃者が受け取ることはできない  
  • 根本的対策を実施
    • 秘密情報(token)をフォームに埋め込む
    • パスワード再入力:本人しか知らない情報を入力させる
    • Reffrerチェック
      • CSRFを経たリクエストは、ヘッダーにReffereがない→その場合は処理しない
  • 保険的対策を実施
    • 対策対象処理時にメール送信(パスワード変更や決済処理のときにメール送信する→ユーザが気づく)

質疑:

1. CSRF-Tokenはユーザは意識してないのか?
 →Yes. Hidden fieldになっているしユーザが意識することはない
  tokenとsessionIDはCSRFについては漏洩を気にすることはない
2. 根本対処としては、tokenとパスワード再入力はどちらがよいのか?
 →効果は一緒だが、パスワード再入力はユーザが嫌がる場合がある
3.対策が必要な機能でログアウト処理は入れるべきか?
 →CSRFとしてはしなくてもよい。うざったいだけで回復が容易なので。
  ただし、ログアウトは別の脆弱性がある場合があるので要チェック

城めぐり ~賀儀城探訪記 乃美宗勝の居城

2018年の城めぐり納めに訪問しました。

お城の概要

写真のこんもりした小山の部分が城跡です。
f:id:yuki_shiro:20181231111939j:plain:w400


忠海港の西にある、海に突き出た岩山に、小早川隆景家臣の乃美(のみ)宗勝(別名:浦宗勝)によって築かれた城です。築城年代は不明ですが、近くにある床浦(とこうら)神社の案内板によると、「神社をもともとあった岩山から浜辺に移す→岩山に築城」の流れがあったようなので、神社の棟札にある永禄年間の前後ではないでしょうか。標高6メートル程度で、規模も大きくないので、さっと見るだけなら15分程度です。

見どころ

標高は低めですが、海側は切り立った崖になっています。海側から攻撃するのは難しそうに見えました。後で調べてから知ったのですが、崖下に少し見えている洞窟は、かつて船隠しだったそうです。杭を打っていた穴などが、今でも残っているとか。行ったときに知っていれば近くまでいったのですが、ちょっと悔やまれます。
遺構は残念ながらほとんど残っていません。第二次世界大戦の忠魂碑のある山頂の広場部分が主郭だったようです。
f:id:yuki_shiro:20181231110855j:plain:w400
結構広い。それなりの人数が詰められそうですね。お城の碑もありました。
f:id:yuki_shiro:20181231111228j:plain:w400
浦宗勝公を追想し~」までは読めるんですが、その先が読めません…。草書体の読解能力が欲しいです。
遺構はほとんど残っていないものの、登ってみるとこの城の狙いは見張りにあったのだろうな、ということが伺えました。近隣の海がばっちり見渡せましたので。見晴らしがよいということは、狼煙をあげる場所としてもよいところですね。
f:id:yuki_shiro:20181231110812j:plain:w400
写真で遠くに見えている橋は、おそらくしまなみ海道多々羅大橋と思われます。訪れた日はお天気も良く波も穏やかだったので、良い景色が楽しめました。
f:id:yuki_shiro:20181231110935j:plain:w400
すぐそばにある砂浜も、小さな船を乗り付けて上陸したり、逆にすぐに海に漕ぎ出したりするにはよさそうです。周りが見渡しやすくて、すぐ海に出やすい砂浜があるあたり、水軍の城としていい立地ですね。お城の東隣は今でも現役で港だったりするので、戦国時代の大き目の船も停泊できたのではないでしょうか。
f:id:yuki_shiro:20181231111122j:plain:w400
砂浜の中央辺りに写っているのが、お城の概要でちらりと出てきた床浦神社です。
f:id:yuki_shiro:20181231110003j:plain:w400
海に向かって立つ鳥居がかっこいい。海の神社らしくていいですね。
f:id:yuki_shiro:20181231110033j:plain:w400
小さな神社ですが、説明版によると四国からも信仰を集めた神社だそうです。
f:id:yuki_shiro:20181231110101j:plain:w400
今はあまり整備されてなさそうなのがちょっと寂しいですね。数年前に本屋大賞を受賞した『村上海賊の娘』の人気で、しまなみ海道の村上海賊関係スポットは色々整備されているようなので、こちらも整備してもらえると個人的には嬉しいです。『村上海賊の娘』には乃美宗勝も登場します。

村上海賊の娘(一?四)(新潮文庫) 合本版

村上海賊の娘(一?四)(新潮文庫) 合本版

今回は訪問できませんでしたが、乃美宗勝菩提寺である勝運寺も近くにあるので、合わせて訪問するのも面白そうです。

「ASTERセミナー標準テキスト」読み合わせと「ソフトウェアテスト勉強会「やってみよう!探索的テスト~ハイクオリティな妄想の高速ループ~」」参加レポート

先日ASTERから公開された「ASTERセミナー標準テキスト」の有志による読み合わせと、「ソフトウェアテスト勉強会「やってみよう!探索的テスト~ハイクオリティな妄想の高速ループ~」」に参加してきたので、その感想レポートです。

ASTERセミナー標準テキスト読み合わせ

「ASTERセミナー標準テキスト」は、こちらからダウンロードできます
http://www.aster.or.jp/business/seminar_text.html

発端

ASTERの資料が公開されたので気になっている、とTwitterで呟いたら、有志による読み合わせ会が発足しました。テストクラスタありがたすぎる。
というわけで、三連休の初っ端からファミレスに集まり、セミナー標準テキストの読み合わせが行われました。今回は初回ということもあり、対象は1章+αくらいで進めました。

やり方

やり方は、時間を決めて各自読み込む、気になったところをそれぞれコメントしあう、という形でやってみました。エクストリームリーディングというそうです。
当日集まったメンバが、組み込み、第三者検証、開発、自社サービスと四社四様だったので、それぞれの立場からの見方があって興味深かったです。

読み合わせで気になったところ

詳しい話は割愛しますが、面白かったのは、ほぼ全員がP18の「テストの目的の拡大(機能充足→目的達成→価値提供)」を気にしていた点です。
f:id:yuki_shiro:20180919011351p:plain
※画像は、「ASTERセミナー標準テキスト」p18のスライドを引用させていただいています。

P18が気になってるのは、私の場合、次のような理由からです。

  • 拡大円の一番外側「ソフトウェア・システムが他の要素と連携し、ライフスタイルやビジネススタイルを変革しているか把握する」まで行きたいけど、どうすれば行けるんだ?
  • 外側から2番目「ソフトウェア・システムが目的を達成し、顧客(利用者)が満足しているかを把握すること」これは、最近気にしていることなので目下の課題。永遠の課題ではあるけど、今個人的には一番力を入れてるところ
  • 外側から3番目「非機能要求を含めてソフトウェアの品質情報を収集し、品質リスクを軽減する・より品質を高めること」については、最近、非機能って何だろう?と少しモヤモヤしているところ。
    • 性能とかセキュリティについては、ほぼほぼ機能では?
    • とはいえ、機能単体だけ見てると漏れる部分ではあるので、別出しになっているのは分かる気はする。
    • 『非機能』という訳語の問題?
  • この図、非常にいい図だと思うので印刷して会社にひそかに貼っておきたいw

あとは気になったページというか、耳が痛いページはP36の「テストの独立性と開発との関係」です。

  • 「対決ではなく、協調姿勢で開始する。全員のゴールは、高品質のシステムであること再認識するとよい。」この通りなのですが、守れていないことも多いので自戒。。

ソフトウェアテスト勉強会「やってみよう!探索的テスト~ハイクオリティな妄想の高速ループ~」

TEF道の中岫さんと根本さんが、JaSST'18 Tokyoで行われたセッションの再演をしてくださったものです。

探索的テストとは

資料はこちらから
http://jasst.jp/symposium/jasst18tokyo/pdf/E2.pdf

探索的テストとは、「「対象を動かしながら、テスト設計~実行~フィードバックを行っていく(ハイクオリティな妄想のループ)対話型のソフトウェアテスト」だそうです。詳しくは、上記の資料をどうぞ!
仕事でも自己流でやってみていますが、私はテストチャータとタイムボックス決めて、気になるところを重点的に動かしてみる、というやり方をしています。

ワークショップ内容

実際に探索的テストを行う対象のサイトを用意していただき、それを実際に動かしてみました。

  • 初めに一人で手を動かして、気になったところを出してみる
  • グループワークで気になったところと、どうしてその気になった点を出せたかについて報告しあう

このやり方を、テストチャータを変えて2度行いました。

ワークショップからの気づき

気になったところは、人によって出せる数が本当に異なるのが面白かったです。気になるところが出せる数が少ない人には、だいたい2パターンくらいあるのではないでしょうか。

  • 経験、知識があまりなく、「そういうものかな」と思ってしまう人
  • 気になるところを見つけてるけど、「仕様って書いてあるし、指摘していいのかな」と遠慮してしまう人

後者の場合、グループワークをやると「あ、それ、指摘してよかったんだ」という契機をもらえるので、後々、気になるところの検出数が上がる気がします。私は気になったところについて、「仕様」とある場合は、あげるべきかちょっと迷ってしまうので、勇気づけられましたw グループワークで、「どうしてその気になった点を出せたのか」をお互いに話せた点も、他の方から素敵な視点をもらえてよかったです。
前者の場合は、どうすればいいんでしょうね? ペアテストしてみる、とかでレベルアップできるんでしょうか。

感想

JaSST'18 Tokyoで、ちょっと出遅れていったら会場が満員で入れなかったので、再演がとても嬉しかったです! ありがとうございました!

ABD「ソフトウェアテスト技法ドリル」に参加してきました

TECiY主催の
ABDで「ソフトウェアテスト技法ドリル」に参加してきました。

TECiYとは

TestEnginner Camp in Yokohamaの略で、
『都内にテストの勉強会は多いけど、横浜には少ない!
 →ないなら作ろう!』ということで、発足した勉強会だそうです。
確かに横浜にはテスト系の勉強会はないので、ありがたいですね!

ABDとは

Active Book Dialogの頭文字をとったものです。
詳しい説明は、公式サイトを見てみてください。
おおざっぱに言うと、
次のような手順で1冊の本をみんなで分割して共有することで
短時間で1冊の本の内容をみんなで理解しよう、ということらしいです。

  • 本を分割する
  • それぞれ担当者を決めて読んでまとめる
  • 各担当者が読んだ内容をプレゼンする
  • 分からなかったところ、深く聞きたいところをお互いに質問する

ソフトウェアテスト技法ドリルをABDで読む

ABDについて手順の説明を受けた後で、参加者が自己紹介を行いました。
自己紹介で、ソフトウェアテストの経験年数も言っていき、
年数の少ない人から、担当する章を選んでいく形式でした。
章によって難易度にばらつきがあるので、この形式はやりやすくて素敵だと感じました。

担当の章を決めてから、実際の読書スタート。
今回のお題の本はこちら。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

今回は読書とまとめる時間は60分でした。
まず最初の30分で読む、残りの30分でまとめる、を目安にやってみました。
集中して読んで、その後迫りくる時間と戦いながら内容をまとめます。

参加者がまとめた結果がこちら。
f:id:yuki_shiro:20180805233754j:plain

まとめきれなかった内容については、
プレゼン時に口頭で補完してもOKでした。
一応読んだばかりの内容なので、各自だいたいの内容は覚えてます。
ほとんどの人が内容を書ききれてなかったので、
章の最後の部分は、口頭で補足する形になりました。

実際にやってみた感想を箇条書きで。
<読み手として>

  • 後で人にわかるような説明が求められるので、集中して読める
  • 自分の理解も進む
  • 3分でプレゼンするので、どこを拾うかの判断が難しい!
  • 30分あっても、他の人にわかるようにまとめるのは難しい! 時間足りない!

<聞き手として>

  • 自分の担当した章の補完になるので、聞きやすい
  • 同じ章を読んでいても、まとめ方が違って面白い
  • 相互質問があるので深められる
  • 参加者がテスト経験者なので、技法の背景などを相互に補完できてよかった

<全体として>

  • みんなで協力して、一冊の本を倒す感じが面白い!
  • 重たい本も協力すれば一日で片付けられそう
  • 言葉の定義とかの共通認識をつくるのにも良さそう
  • アジャイル界隈でこの手法を初めて聞いたのは↑の効果を狙ってたのかな?

最後に

懇親会まで含め、みんなで理解を深めあえて、とても面白い会でした!ありがとうございます!
TECiYの次の勉強会も楽しみにしています!

『感情の問題地図』から、ひとまずTryしてみること

最近イライラしてることが増えたなぁ、感情をうまく処理できてないなぁと思ったので読んでみました。

感情の問題地図 ~「で、どう整える?」ストレスだらけ、モヤモヤばかりの仕事の心理

感情の問題地図 ~「で、どう整える?」ストレスだらけ、モヤモヤばかりの仕事の心理

さらりと読めますが、「怒り」「悲しみ」「落ち込み」「不安」の4つの ネガティブな感情を否定せず、うまく味方につける方法が書かれています。

直近自分にとって対処が必要そうな「怒り」について、ちょっと整理してみました。

怒り

  • 自分はどのような時に怒りを感じるのか=自分は何を大事にしているのかの指標
  • 怒りを感じることと、それをどう表現するかは分けて考える
  • 怒りが攻撃として表れると関係性を壊す
  • 対処法の一つとして関係性を壊すのではなく、作る方向に表現するDSEC法がある
    • Describe 客観的に描写する。事実を述べる
    • Explain 「私は〜」で自分の考えを説明する
    • Suggest 「こうしてもらえると助かる」を提示する
    • Choose 選択を示す、相手に選んでもらう
  • 対処法としては、自分が落ち着く言葉を用意しておき、怒りを感じたときにそれを思い出すリマインダー法もある

DESC法とリマインダー法は、すぐに試せそうなので自分のTry項目として、取り入れてみようと思います。
私のリマインダーには、中国古典『荘子』に出てくるフレーズで、気にいっているものを試験的に採用。
「至人之用心若鏡、不将不迎応而不蔵(至人の心を用いるは鏡のごとし、将(おく)らず迎えず応じて蔵(おさ)めず)」
『外面は相手によって自由に変化するが、内面はしっかりと自分の主体性を守っている』ということだそうです。和訳部分は『実践・老荘思想入門(守屋洋)』より引用しました。

体現するには至ってませんが、一つの在り方として惹かれるものがあるので、なんとなく気に入っているフレーズです。

まずは「怒り」を味方につけられるようDSEC法とリマインダー法を実験してみます。

第11回Ques「IoT時代の品質」参加レポート

第11回Ques「IoT時代の品質」に行ってきましたのでレポートします!TECH PLAYさん初めて行きましたが、オシャレできれいですね。
f:id:yuki_shiro:20180518214128j:plain

AkerunサービスのQA現場

株式会社 フォトシンス 石井大樹さん

役割
会社の紹介
  • akerun入退室管理システムの開発提供
  • スタートアップ
QAの担当

以下すべて内製

IoTサービスの難しさ
  • QAの規模=組合せの掛け算
  • QA用の端末も製造が必要
    • Internet スマフォ、パソコンは作らない
    • Thing 目の前にあるものを検証 → サーバサイドを検証するにも機器が必要
  • Webからの転向の注意点
    • QA用の端末も製造しなくてはならない ハードウェアの作成に時間とお金がかかる
    • →計画が重要!
    • QAに必要な数量は? → 壊す前提で計画する
    • 製造の予算は? → 壊す前提で計画する
    • 製造スケジュールの調整は?
IoTの現場
  • 環境試験
    • 高温、低温、ヒートショック、湿度
      • カタログスペックの検証
      • 本当はどこまで行けるのか(壊れるまでやる)
    • 静電気
  • 耐久性、連続稼働
    • キーワード「自動化」
    • 鍵を開けたり締めたりを100万回以上繰り返す
    • ボタンのプッシュを延々繰り返す ※初期はエンジニアが押しまくってた(手動)
    • ハードの自作っぷりがすごい
ハードの試験も自動化するメリット
  • 生産性上がる!わくわくする
  • →最近は手軽に作れる環境が充実
    • shell/python/golang
    • RasPy
    • 素人でも、ちょっと勉強すれば、手伝ってもらえば作れる!
    • 無料、またはお小遣い程度
チーム作り

Before

  • スーパーエンジニアでも抜け漏れは発生
  • 能力差が出る、非効率

After

  • 開発者と評価の分離
  • 品質基準の策定
  • ステークホルダーの再構築
    • →会社全体でQA、会社全体でドッグフーディング
    • 偉い人からみんなでやろうよと言ってもらう
    • オフィスに設置して実際に入退室管理
    • チーム分けして日替わりで体験
    • →サービスの仕様がみんなに浸透
    • 改善のフィードバックが速い
  • カスタマーサポートにテストしてもらう
    • リリース前に細かい仕様を把握
    • はまりどころのキャッチアップ
    • 「触るの楽しい!」を体験してもらうことで、ポジティブになる
    • ※カスタマーサポートは、普段クレーム処理なのでネガティブになりやすい
  • 社員全員akerunを持ち帰り
    • 設置のしやすさを体験
    • 合鍵発行などのフローも体験
    • 社員に愛着を持ってもらえる
  • 顧客先で張り付き検証
    • ユーザの使用環境・生の声が分かる
    • 先入観がなくなる(こう使われるだろう、と思ったら実際には違う)

組織全体でQA ⇔ 品質意識の向上

  • 専門性の高いドメインは委託
    • セキュリティ会社にライブインタビュー ※登壇中にSkypeつないでインタビューw

  akerunのテストどうですか?
   Q どこが難しい?
    問題が起きた時にWeb系よりもいろいろなこと考慮する必要があり難しい
   Q どこが楽しい?
    切り分けしてどこが問題ってわかったときは面白い
    Web系と観点違って面白い 木材立てて通信遮断とか

  • 外部にテストしてもらうときも楽しんでほしい→プロダクトの魅力が重要
    • →結果的にプロダクトの魅力がさらにあがる! 「わくわく感大事」
  • 魅力あるプロダクトとは
    • 新しく他にない
    • 先端技術
    • 他にない
まとめ
  • IoTスタートアップがQAをする難しさ
    • 範囲が広い
    • ハードの計画も
  • 生産性を上げる = モチベーションの維持
  • エンジニアリングの活用
  • 全社QA体制⇔品質意識の醸成
  • ただし専門性の高いドメインは委託

IoT、ビッグデータ、サーバレス、品質管理

アイレット株式会社 鈴木 宏保さん

会社紹介
  • cloudpackのサービス展開
  • AWSのプレミアコンサルティングパートナー
  • KDDIの子会社化
  • IoTをもう一つの中心事業とする
  • フルマネージドサービスの利用。IoT案件
  • サーバレスアーキテクチャの利用
    • メリット
      • AWS利用料が削減できる
      • 運用保守費用が削減
      • ライセンス費抑えられる
    • デメリット
      • サービスが増える、更新されるのでキャッチアップが大変
      • 管理を任せられる分制限がある
サーバレスについて
  • お客さんからサーバレスでやってくれと言われているわけではない
  • 品質管理:求められている要件を満たしていることを管理
    • 機能要件:従来通り
    • 非機能要件:以下を変えてみた
      • 可用性
      • 性能/拡張性
      • 運用/保守性
      • 移行性
      • セキュリティ
非機能要件の詳細
  • 可用性
  • 性能/拡張性
    • 基本決まっている
    • 上限があるがUPできる(ユーザが設定変更してAWSに申請)
    • →という点を前提に設計を行う。
    • 顧客の合意をとる
    • →従量課金でコストがかかるため、コストのかかり方についても合意
    • インフラの試験は不要(アプリ部分の試験は必要)11
  • 運用/保守性
    • 人の動き
      • 従来通り
      • 障害に対してできることは少ない →AWS頼み
      • ただし、障害はそもそも少ない
    • 運用保守システム
      • 監視バックアップより、AWSの機能で実現
      • →簡単にできて試験いらず
  • 移行性
    • AWSから外へ → あきらめる。
    • AWS内(他アカウントへ)→ ツールが用意されている(うまくいけば非常に低コストで移行が可能)
  • セキュリティ
    • 仮想サーバとサーバレスの責任分岐点
      • 仮想サーバ:OS以上が自分たち
      • サーバレス:アプリとデータが自分たち
サーバレスの今後
  • サーバレスは流行るか?
    • 決済者にはコストダウンが響きそう
  • これからはサーバレスの時代が来る
    • 品質管理、サーバレスの達人になれば売れるエンジニアになれる!

感想

フォトシンスさんのチーム作りのやり方は、周りの巻き込み方が素敵だなと思いました。キーワード「わくわく感」が特に素敵です。
アイレットさんのサーバレスのお話は、サーバレスの非機能考えていかなきゃなー、なところだったので参考になりました。
登壇者、運営の方々ありがとうございました!