技術の詳細を伝えるには勉強会が分かりやすく、やりやすい。そのためには自分自身も説明できるぐらいの知識は必要だけど「エバンジェリスト」であれば学ぶのも苦ではないはず。勉強会の参加者募集は多くに呼びかけもしたけれど、来てほしい方々には「個人的な接触」で説明もした。
来ていただいた方には「感謝を伝える」事も忘れずに。

勉強会は学んで終わりにならないように、「次のアクション」について話をする時間を設けた事は良かったと思う。ただアクションの決め方や持続性については課題があった。

あらゆる角度で検討しても「やってみる」まで分からないことが多い

勉強会が終わった後、実際にやってみると良い点も悪い点も経験できる。初めから上手くいくとは思ってないけど、思った以上に上手くいかないこともあるし、しっかりと効果が出ることもあった。上手くいかなかった部分が準備不足なら反省すべきだし、実践しないと分からなかったのであれば喜んでも良いと思う。何にせよ、やって終わりにならないように

「やってみる」まで実践したので次はふりかえり

今後は「ふりかえりの時間」を設けて、継続するかどうかも含めて話をしていきたいと思う。そして、「体験談の共有」をして「みんなを巻き込む」ことが出来て「成功の匂い」が伝わると徐々に広まっていくんだと思う。

「定期的な連絡」が出来てなかった

本を読み返してみて勉強会参加メンバーに定期的な連絡をするべきだったと思うので、今回のふりかえり結果も含めて連絡する。

さいごに

書籍で登場するパターンがまとめられたページがあるので思い出すときにとても参考になる。
48のパターンのチートシートを作りました。 - kawaguti’s diary

2019-01-26

UXをエレベーターピッチで説明した

結局UXとは何なのか

UXを学んでいくためには一緒に学んでくれるメンバーが必要だと思っていて、メンバーを集めるためには「UXとは？」、「UXをデザインする事で良くなる事とは？」を話せる必要がある。と思ってる。

じゃあ、「UXってなんなの？」って聞かれても答えられない。結局、何なのだろう。

「UXとは」を調べてみよう

「UXとは？」を自分なりに回答できる状態にしたいので、色々調べてみた。

ユーザーエクスペリエンス - Wikipedia

ユーザーエクスペリエンス（英: user experience）とは、人工物（製品、システム、サービスなど）の利用を通じてユーザーが得る経験である。しばしば「UX」と略される[1]。「ユーザー経験」「ユーザー体験」などと訳される。

私もこの理解で間違ってはないと思うけれど、抽象的で何する事なのか「うーん、うーん」だ。

UXとは | UX TIMES

UX（ユーザー体験）は「ユーザーのタスク＋コンテキスト」と解釈すると理解しやすいでしょう。

以前参加した勉強会で説明があった内容。さっきよりも具体性が高くなった。「ユーザーは何をするのか(タスク)」と「どんな環境、状況で製品に触れるのか(コンテキスト)」を考える必要がある。

UXって結局何なんですか？大学生が専門家に聞いてみた | UX MILK

人が想いを伝えるための「モノ」と、場所や時間などの「コト」を作り、それに対するフィードバックを得てまた「モノ」と「コト」を改善していく、それ全体がUXデザインです。伝えたつもりになってしまわないことが一番大事で、そうならないための「伝わる仕組み」を考えることがUXデザインなのです。

先ほどの「ユーザーのタスク＋コンテキスト」に「想い」が足されていて、UXをデザインする事で何が良くなるのかが分かりやすい。

意味不明なことばかり言ってるUXデザイナー達の代わりに「UXデザインとは何か」を端的に説明しよう | hajipion.com

すなわちUXデザインとは、
「みんなでちゃんと企画すること」です。
単純でしょ？

分かりやすい。難しい言葉が削ぎ落とされている。詳細はリンク先を見た方が良いと思うが、「みんな」が大切。企画職だけでなく、デザインもエンジニアも企画に参加すること。
「UI」と「UX」は別々なのになぜ「UI/UXデザイナー」と一緒に語られるのかも納得いった。僕も「ソフト/UXエンジニア」という肩書きで名乗れるのを目標に学んでいこう。両方できる人はいると思うが、この肩書きを名乗ってる人は少ないと思うので唯一無二の存在になれるのでは！

結局UXとは何なのか

UXとはユーザー体験のことで、その体験を良くする行為がUXデザインだ。
今回調べた内容を元にアジャイルサムライで紹介されているエレベーターピッチを使ってUXデザインを説明してみる。

製品に込めた想いをユーザーに伝えたい
開発に関わる全ての人向けの、
UXデザインという言葉はユーザー体験に注目した企画/開発するための考え方です。
これは想いが正しく伝わる製品を開発する事ができ
施策や数値だけを見て企画する方法とは違って
ユーザー体験に関わるあらゆる観点とユーザーからのフィードバックをもとに製品を改善し続ける考え方が備わっている
※記事を読んで頂いた方から間違いを指摘頂いたので修正した版です。

企画/設計して製品に込めた想いをユーザーに伝えたい
開発に関わる全ての人向けの、
UXというフレームワークは
ユーザー体験に注目した企画/開発するための考え方です。
これは想いが正しく伝わる製品を開発する事ができ
施策や数値だけを見て企画する方法とは違って
ユーザー体験に関わるあらゆる観点とユーザーからのフィードバックをもとに製品を改善し続ける仕組みが備わっている
※こちらが修正前です。

ソフト/UX エンジニアに向かって

UXデザインって何ですか？を簡単に答えられるエレベーターピッチができたと思う。しかし、実際にどういったことをデザインするのかはまだまだこれから。前回の勉強会でも一人でなくチームで話すことが大切だと伺っているので興味ある人を探しながら学んでいきたい。

参考

アジャイルサムライはアジャイルを学んでいる人なら読んだ事も多い書籍だと思う。

アジャイルサムライ−達人開発者への道−

作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
出版社/メーカー: オーム社
発売日: 2011/07/16
メディア: 単行本（ソフトカバー）
購入: 42人クリック: 1,991回
この商品を含むブログ (257件) を見る

前回の勉強会はこちら。
iucstscui.hatenablog.com

2019-01-17

GoogleスライドでAzusaテーマを使う方法

勉強会

Azusaは、おしゃれな Keynote テンプレート

勉強会用にスライドを作ろうっと思ったときにデザインに困った。3色を使って、ベースカラー(70％)、メインカラー(25％)、アクセントカラー(5％)の比率でスライドを作ると良いとの事だが、それでも悩むし困る。

簡単に良い感じのスライドが作れないかなぁと考えていた時に出会ったのが「Azusa COLORS」だ。
sanographix.github.io

AzusaはKeynote用に作られたテーマで、使うと大体いい感じになる。Googleスライドで使う方法を調べたのでまとめておく。

PowerPoint用の「Azusa Colors 改」からインポート

GoogleスライドはKeynoteのテーマをそのままインポートする事ができなかった。しかし、PowerPointのテーマはインポート可能なので、PowerPoint用のAzusaを探した。すると、作られている方がいて無事にインポートできた。ありがたい。

・紹介ページ
miki73.com

・ダウンロードページ
drive.google.com

ダウンロードページからPowerPointをダウンロードし、Googleスライドを作成する際に、「テーマをインポートする」からダウンロードしたファイルをアップロードすることで使用することができた。

これでいい感じのスライドが作れる

スライドは作りなれていない事もあって、とても時間がかかる。デザインも内容も考え出すと一向に完成しないので、スライド作りに慣れるまではデザインが大切なことも理解しつつ、内容に重きを置いて作っていきたい。

2019-01-10

「コンテキストの理解と実践」UXワークショップ　に参加した

UX 勉強会

UXを学ぶスタートラインに立てた

UXを学ぶには何からどう手を付けたら良いのか分からなくて「うーむ、うーむ」と悩んでいた時にちょうど大阪で開催される勉強会を見つけて参加してきた。

uxdt.connpass.com

「UXはユーザー体験」ぐらいしか知らない状態で参加したので学び多き時間だった。これでUXのスタートラインに立てたと感じたので、このまま止まらずに学び続けたい。得た知識は社内に展開してチームで学んでいきたい。

コンテキストは文脈、環境、状況

本勉強会のタイトルに入っているコンテキストとは文脈、環境、状況のことを指す。例えば、テレビを見ている状況を考えると「部屋でソファーに寝転んでだらだらしている」がコンテキストとなる。「テレビを見る」という行動は「ユーザーのタスク」と呼ばれる。そして、UXを設計する場合はこの二つを考えることになる。
UX＝「ユーザーのタスク」＋「コンテキスト」

ワークショップでは何枚かの写真を見てコンテキストとは何かを考えて、意見を出し合った。人によってコンテキストの意見が異なっていたが、どの意見も正しかった。特定の場面から多くのコンテキストを見つけ出す力はUXにおいて重要だと感じた。

また、コンテキストの理解を深めるために全9回のコンテキストの資料を各グループで分担して読んで、要約を発表しあった。
コンテキストの落とし穴コンテキストを理解する(プロローグ) | UX TIMES

コンテキストは奥深く簡単に理解できるモノではなかったので、知識を増やして経験を積まないと理解できたと言えないだろう。

普段使っているサービスもUXを意識して使うと使いにくさに気づく

ストーリーテリングからユーザータスクとコンテキストを見極めるワークショップを行った。とある夫婦が両親と弟夫婦で旅行に行く計画を立てていて、旅館を探しているストーリーだった。(かなり要約している)

その後、同じストーリを使ってユーザータスクを満たす旅館を普段行っている方法で探すワークショップを行った。旅館に対する要件が多くて普段使っているサービスでは時間内に見つけることができなかった。細かな部分で使いずらさを感じてUXの大切さが実感できた。

UXの道具と使い方は調べていきたい

今回はカスタマージャーニーマップやペルソナなどUXを設計する際に使用するツールの説明はなかったが、本質を理解せずにツールを使うと間違った使い方になる旨について説明があった。気をつける。

集中、熱中できる勉強会だった

登壇者からの話を聞くだけの勉強会ではなく、座学の時間でも意見が求められたり、ワークショップがあったりして集中して参加できた。2時間はあっという間に過ぎていった。

次の一歩を踏み出す

今回の勉強会で得た内容を社内で共有して、一緒にUXを学びたい仲間を集めたい。難しく一人で勉強しても続く気がしないのと、複数人で勉強すれば製品に活かしやすいと思う。そして、チームで勉強会などに参加していきたい。

今年の春に「UX DAYS TOKYO 2019」が開催されるらしく、参加したいな。

2019-01-05

今年も走り続けるために。～2018年のふりかえりと2019年の抱負～

抱負

2018年は走り出した1年

2018年8月18日からブログを始めて「ほぼ」週1のペースでブログを続けることができた。ブログを始めた理由や良かったこと等は過去記事に書いたので割愛するが、改めてブログを始めて良かった。
iucstscui.hatenablog.com

ブログだけでなく社外勉強会も定期的に参加でき、2018年は14回参加して内2回は登壇する機会を頂いた。2017年と比べると大幅アップ(2017年は参加も登壇も0回だったと思う。当たり前だがブログの記事も0。)

積極的に勉強会やブログを始めたきっかけは、仕事で「スクラムを採用したほうが良い」と感じたことが大きい。そこから情報収集や相談がしたいと思い、定期的に社外勉強会へ参加するようになり、podcastを聞き、ブログを始めた。
その後、社内勉強会の主催などを経て私が所属するチームでスクラムを実践している。チームのコミュニケーションがとても良くなったと感じているが、まだまだ私の力不足で目指した効果が出せていないと感じているのでアジャイルに関わらず、エンジニアリングやプロセスやチームビルディングを身につけて、誰から見ても明らかな効果を出したい。

2019年はペースを維持しつつ結果に拘る

2018年は色々と新しいことを始めて、行動することで変えられることが分かった。しかし、そこに実力が伴わないと悪影響を及ぼす可能性もあるので、始めるだけでなく結果にこだわる必要がある(せっかく始めたスクラムも悪い結果を残すと、私のせいで「スクラムはダメ」になりかねない)

それらを考慮して今年の抱負を立てた。
Google re:Work - ガイド: OKRを設定するにOKRでは「気後れするくらいの高いレベルの目標」を設定するとのことで、高い目標を設定した。

ブログは週一更新を継続し、アクセス数は去年以上

去年のページビュー数は8月18日からの4ヵ月半で「1200」だった。
同じペースで1年間書いていたとすると「3200」になるので、今年は「5000」を目指す。

アジャイル支援できる実力をつける

アジャイルコーチと名乗れるぐらい成長したいけどまだまだ力不足。成長するためにもアジャイル開発の知識を中心に色々なチームを支援して成果を出していきたい。まずは今のチームで効果を出すために、幅広いアジャイル開発に関する知識(エンジニアリングやプロセスやチームビルディングなど)が必要なので継続的に学び成長し、実践していく。

おまけの抱負

今までの流れと関係はないが、過去のブログの文章が固いと感じているので少しずつ書き方を変えていきたい。
まだ定まっていないので、記事によって雰囲気は変わると思う。

2018-12-29

エンジニアリング組織論への招待を読んだ

アジャイル本

はじめに

エンジニアリング組織論への招待を読みました。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

作者: 広木大地
出版社/メーカー: 技術評論社
発売日: 2018/02/22
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

自分の中で感覚的になっていた事が上手く言語化されていて、「なるほど、なるほど」「そうだ、そうだ」と感じながら読んでいました。知らなかった事も満載でとても良い本でした。

また、定期的な例え話が的確で理解の手助けになりました。

特に良かった部分についてまとめていきます。

内容

分からないことは大きく2つ

人間にとって、本質的に「わからないこと」はたった2つしかありません。それは、「未来」と「他人」です。

「そうだ、そうだ」となった部分です。この2つの「わからないこと」を軽減するための策はモダンアジャイルで言うところの「高速に実験＆学習する」「安全を必須条件にする」なんだろうなと思いました。

カレー作りの寓話

本書に書かれていて、Qiitaでも掲載されているカレー作りの寓話は心が痛くなるような話でした。

コミュニケーション能力の正体と「カレー作りの寓話」 - Qiita

二人でカレーを作るのですが役割や情報の違いから失敗に終わる話です。
力もあって一生懸命しているのに、情報が共有できていなかったり、相手に対する思いやりが欠けていたりして上手くいかないことは常に起こる可能性がある思います。普段は出来ていても色々な状況で周りが見えなくなって起こることもありそうなので、この話をチームで共有して同じような状況になったとき、誰かが「カレー作りの話みたいになってるよ」っと落ち着かせられると良いなっと思いました。

メンタリングの技術

私はマネージャーという立場ではありませんが、皆と楽しく成長出来る状況や場を作れるようになりたいなと思っています。でも、凄く難しくて、全然できてません。「メンタリングの技術」の章はそのためのヒントが満載でした。この章に書かれている事がサラリと出来るようになれば、そういった状況や場を作れる人物に近づけると思うので、読み返しながら身につけていきたいと思います。

さいごに

マネージャーやマネージャーを目指す方は特にお薦めできますし、マネージャーでなくてもチームで働く事がある方は読むと学ぶポイントがたくさんあると思います。
アジャイルコーチをしている方はこれらを理解して行動されているんだろうなぁと思うと勉強する事がまだまだあります。
頑張らないと。

2018-12-17

textlintを使って文章を自動でチェック！

プログラミング

はじめに

textlint というオープンソースの文章チェックツールを知りましたので早速試してみました。
今回は使っただけで使いこなせていませんが、ブログ書くときだけでなく、設計資料とか文章を書くときは便利になりそうです。

github.com

インストールの前に

textlintを使う場合はNode.jsが必要になります。
Node.jsは以下のサイトからダウンロードできました。

nodejs.org

textlintのインストール

コンソール(私はWindowsなのでPowerShell)でコマンドを実行するとインストール完了です。

npm install textlint --global

しかし、textlintをインストールしただけではルールがなく、校正ができません。
ルールは自分でも作ることができますし、公開されているルールを使うこともできます。
私は公開されているルール(textlint-rule-preset-japanese)を使用しました。
Collection of textlint rule · textlint/textlint Wiki · GitHub

ルールの適応

PowerShell でコマンドを実行してルールのダウンロードをします。

npm install --global textlint-rule-preset-japanese

その後、「.textlintrc」という設定ファイルを作ってルールを記載します。
※今回のような拡張子だけのファイル名をWindowsで作成する場合は「.textlintrc.」と末尾に「.」を付けると良いです。
　(困って調べました(Windows上で拡張子だけのファイルを作成する方法 | エンジニアの休日))

設定ファイルの中身は以下のように使いたいルールを記載してtrue/falseを設定します。

{
  "rules": 
  {
    "preset-japanese" : true 
  }
}

実行

textlint <ファイル名> を実行することでチェックができます。

textlint .\XXX.md

結果

前回の記事をチェックしてみたところ、3件のエラーが見つかりました。
ゲーミフィケーションで熱中するお片付け - はんなりと、ゆるやかに

6:57  error  一つの文で"、"を3つ以上使用しています preset-japanese/max-ten  
26:48  error  一つの文で"、"を3つ以上使用しています preset-japanese/max-ten  
39:85  error  一文に二回以上利用されている助詞 "に" がみつかりました。 preset-japanese/no-doubled-joshi
✖ 3 problems (3 errors, 0 warnings)

preset-ja-technical-writingという技術文書向けのルールで実行した結果、17件のエラーが見つかりました。

2:36  error 弱い表現: "思う" が使われています。 preset-ja-technical-writing/ja-no-weak-phrase
6:57  error 一つの文で"、"を3つ以上使用しています preset-ja-technical-writing/max-ten
6:19  ✓ error 一つ => 1つ 数量を表現し、数を数えられるものは算用数字を使用します。任意の数に置き換えても通用する語句がこれに該当します。 preset-ja-technical-writing/arabic-kanji-numbers
16:60  error    "一つ" が連続して2回使われています。 preset-ja-technical-writing/ja-no-successive-word
20:32  ✓ error 十回 => 10回 数量を表現し、数を数えられるものは算用数字を使用します。任意の数に置き換えても通用する語句がこれに該当します。 preset-ja-technical-writing/arabic-kanji-numbers
23:31  ✓ error 一つ => 1つ 数量を表現し、数を数えられるものは算用数字を使用します。任意の数に置き換えても通用する語句がこれに該当します。 preset-ja-technical-writing/arabic-kanji-numbers
26:48  error 一つの文で"、"を3つ以上使用しています preset-ja-technical-writing/max-ten
29:28  ✓ error 一つ => 1つ 数量を表現し、数を数えられるものは算用数字を使用します。任意の数に置き換えても通用する語句がこれに該当します。 preset-ja-technical-writing/arabic-kanji-numbers
35:37  error 弱い表現: "思います" が使われています。 preset-ja-technical-writing/ja-no-weak-phrase
36:3   ✓ error 一つ => 1つ 数量を表現し、数を数えられるものは算用数字を使用します。任意の数に置き換えても通用する語句がこれに該当します。 preset-ja-technical-writing/arabic-kanji-numbers
36:5   error "一つ" が連続して2回使われています。 preset-ja-technical-writing/ja-no-successive-word
36:58  error 弱い表現: "思います" が使われています。 preset-ja-technical-writing/ja-no-weak-phrase
39:85  error  一文に二回以上利用されている助詞 "に" がみつかりました。 preset-ja-technical-writing/no-doubled-joshi
40:3   ✓ error 一つ => 1つ 数量を表現し、数を数えられるものは算用数字を使用します。任意の数に置き換えても通用する語句がこれに該当します。 preset-ja-technical-writing/arabic-kanji-numbers
40:5   error "一つ" が連続して2回使われています。 preset-ja-technical-writing/ja-no-successive-word
40:56  error 弱い表現: "思います" が使われています。 preset-ja-technical-writing/ja-no-weak-phrase
43:34  error  弱い表現: "かも" が使われています。 preset-ja-technical-writing/ja-no-weak-phrase

✖ 17 problems (17 errors, 0 warnings)

さいごに

textlintを使って静的解析すると自分では気づかない間違いに気づけます。
すでにあるルールを使うことで実行も簡単なので今後も継続して使っていきます。
※この文章もtextlintを実行して、指摘がなくなるようにしました。