プロダクトの使いやすさ、操作性の検証、いわゆるユーザビリティ評価を簡単に体験してみましょう、というセッションです。

ユーザビリティ評価とは

ユーザビリティ評価にはざっくり2つのアプローチがあります。

a) 本物のユーザに試してもらうユーザテスト

• ユーザさんにプロダクトまたはプロトタイプを操作してもらう
• あらかじめ設定した操作内容（タスク）を行ってもらう場合が多い
• 定量評価：達成度や達成時間を測定する（想定時間内に終わるか、前バージョンや競合と比較してどうか等）
• 定性評価：つまづいた点や発話（つぶやき）、事後コメントを記録、観察する
• 費用や時間がかかりがち、動くものがない段階で検証ができない、情報漏洩リスクなどが障壁

• プロの頭の中にある"仮想"一般ユーザを使って評価
• 仕様書レベルでもやろうと思えば評価できる（早い段階で問題点を発見できる）
• 初心者VMの脳内エミュレーション精度には心理学的限界がある（通常、開発者はそのプロダクトにもっとも詳しく、初心者からもっともかけ離れた存在である）
• エミュレーション精度を挙げるチェックシート的なフレームワークも存在する（ヒューリスティック評価法など）

どちらにも一長一短があり目的や開発フェーズに応じて使い分けるのが良いとされていますが、コロナ禍でテストルームに多くのユーザを招いて調査をすることが難しくなってきた昨今、せめて後者を頑張ろうといった動きが目立ってきたように感じます。

どちらも「なんかここがわかりづらそう」といった現象／箇所は発見できるのですが、その理由を説明づけるには専門的な知識が必要になります。特に後者は定量的なエビデンスが得られないので、蘊蓄勝負な色合いが強いです。専門用語や過去の類似例で武装することで説得力を生むことが必須になってきます。

本セッションの狙い

本セッションではユーザビリティ屋がよく使うキーワードを簡単に紹介し、実際に身の回りで感じた使いやすさ／使いにくさを例にとって、それらのキーワードで語ってみるトレーニングをしてみたいと思います。つまりユーザビリティを語るための語彙力を鍛えてみようという試みです。「使いやすさ」を説得力ある言葉で語ることは、チームでプロダクトを開発するのにとても重要です。現状にケチをつけるわけですから、しっかりした根拠が伴っているべきですし、その方が円滑にコミュニケーションできるでしょう。

ユーザビリティ専門家が使うボキャブラリーを学び、にわか専門家を気取ってバシバシっと使ってみませんか？（オトナのキッ〇ニア）

予告動画 : https://www.youtube.com/watch?v=ymZnqdUQ8DE&feature=youtu.be

数度目のアジャイル開発戦争が勃発。
内製開発企業と受託開発企業ではそれぞれのビジネスと命運をかけて防御壁を展開、エンジニア獲得の勢力図がうごいていた。

Scrumの加護をうけし組織となるために工作を展開する企業。
それに反発し自由と共同を求めてオープンなコミュニティをつくりあげるものたち。

終わりが見えない戦争に希望を見出すため、各組織では次世代の旗手をみつけ育成する作戦が遂行された。
そしてミレニアル世代が第一線に配属され、時代はひとつの転換を向かえようとしていた・・・

我々は誰に"価値"を届けるのでしょうか？

エンドユーザー？自動車メーカー？事業部長？？

大企業はPOからエンドユーザーまでが遠すぎます。

そして、POと開発チームの間にも距離感を感じている方もいるのではないでしょうか？

では、"価値"とはなんでしょうか？

ユーザーの求める価値＝ステークホルダーの求める価値でしょうか？

ステークホルダーの求める価値＝POの考える価値でしょうか？

そして、POの考える価値＝開発チームの考える価値でしょうか？？

また、"価値"とはどうやったら生まれるのでしょうか？？

失敗に成功した！

私のチームはとあるWebアプリ開発をスクラムで取り組みました。

結論を言うと、プロジェクトは予定通りリリースできました。が、その道のりは失敗の連続でした。

このセッションでは、とあるプロジェクトを通して私たちが経験した失敗談をお届けします。

しかし、結果的にこの失敗のおかげで私たちはアジャイルの原則に立ち返ることができ、開発チーム、PO、ステークホルダー、プロジェクトに関わった全員が大きく成長できました。そう、私たちは失敗に成功したのです！

皆さまには、プロジェクトの中で価値を生み出し続けるための明日から使える具体的な提案と、愛という"価値"をお届けするセッションになればと思います。

努力・根性・忍耐がとにかく嫌い。そのうえ弱虫。
余計な一言で周りをドン引きさせるくせに、
社会性を求められると、すぐにお腹がグルグル痛くなり出勤すらできない。
人生のほとんどをネガティブに過ごし時間を無駄にする。

そんなダメ人間の僕が10年に渡って開発チームを率いたら、
なぜか優秀で面白くてキャラが濃い人がいっぱい集まって
めちゃめちゃ優秀なチームが出来上がった！
しかも働き方改革もリモート勤務もダブルワークも可能なチーム。
そんな僕の体験から導き出した、アジャイルがもっと美味しくなる(かも知れない)話。

• ダメ人間は本当にダメなのか？
• なぜか上手く行く不思議な価値観
• バラバラのメンバーが実は一体となる秘訣
• チームの能力を最大限にする方法
• 個性的なチームを育てた(自ら勝手に育つ)チームビルディング
• 最弱のマネージャーが最高のチームを作るには

この説明を読んで、
『ふざけてんの？』こいつアジャイルやスクラム舐めてるよね？っていう人にも、
自分よりダメ人間を見つけたから少し安心できるかもって人にも、
なんとなく変わった話だなって思った人にも、
ダメ人間のダメダメ感を楽しみつつ、
優しくちゃかしてもらいながら進めれれば嬉しいです。

このセッションに参加すると

努力と根性と忍耐がとにかく嫌いな弱虫がなぜ

• 高いスキルを持った人達と共に歩めたか？
• 尖ったチームが育つ環境を作れたか？
• スキルの高くないメンバーも活躍できるチームを作れたか？
• 自分の思考のリミットを解除し続けれたのか？

が、わかるだけでなく
次の日からすぐに実践できちゃうかも知れません。

誰にでも合うとは言いませんが

経験だけでなく社会心理学的な要素も取り入れた内容になっています。

背景

努力と根性と忍耐がとにかく嫌い(無理)。
協調性も薄く、コミュニケーションも苦手。
社会性やルールを押し付けられると、すぐストレスで死にそうになる。
(お腹ピーピーになったりして動けなくなる)
そんな僕は10年ほど前、リーマンショックの煽りを受けて失業していた。
理解されることもなく、何かを成し遂げることもなく、
お金もなく、虚しく人生を過ごす恐怖。
悩みに悩んでソフトウエア業界を離れる決心をした時、
ふとした縁で入った会社は当時社員が10人にも満たない零細SIerの
株式会社オンザロード。

アジャイルやスクラムを全く知らなかった僕が10年にわたって、
地道にチームビルディングとプロダクトマネジメントを続けた結果、
個性的なメンバーが自由に働ける環境が出来上がり、
洗練したスクラムのチームも生まれ、
お客様とも信頼関係を築くことができていました。

今回Home Automationという新たな夢に向かって退社したことをきっかけに、
株式会社オンザロードで起きた奇跡的なマネジメントを振り返り、
自分のバックグラウンドや大切にする一つの価値観に社会心理学的な根拠も付け足しながら、
皆さんに共有する事で、自分自身がさらなる覚悟を持って進んでいきたいと考えています。

Mackerelというプロダクトはローンチから5年が経ちました。ぼくはそのほぼすべての期間、このチームに在籍していて、うち3年間はマネージャーとしてチームを運営しています。5年間運用されたチームではさまざまなことが起こりますが、いくつか事例をご紹介しながら、長く安定的に続くチームづくりについて考えていきたいと思います。

なんやて！このセッションおもろそうやな〜。

だから大阪好っきゃねん。