jiigのREDOブログ

やったことや考えたことなどを不定期に書き残していきます

プレゼンテーションのコツ

エヴァンジェリスト養成講座をあらためて読み直す機会があったので、まとめておくことにした。

新エバンジェリスト養成講座

新エバンジェリスト養成講座

この本は、セミナーのセットで購入したのだが、セミナー自体が激オススメです。

プレゼンテーションとは

  • プレゼンのゴールは相手を動かすこと。話すことでも伝えることでもない。
  • 相手を動かすことをゴールにおくと、資料のレビュー観点も変わる。
  • 動かす例
    • 無関心を関心ありにする
    • 協力者になってもらい、自分の支援をしてくれるようになってもらう
  • プレゼンテーションでは仕様より体験、価値を伝える
  • 伝えたいことは何か?をブレークダウンして考える。要言語化。「新商品について伝えたい」はボンヤリしている。

視線誘導について

  • 言葉で視線誘導する。そうできるようにスライドを作っておく。
  • 視線誘導がとても大事。聞いていることと見ているものがズレていると入ってこない。

シナリオを作る

  • 3:7の時間配分。本題7割、その前に課題提起とその回答に3割時間を充てる
  • 相手にどういう行動を期待するかを決め、プレゼン中に語りかける、タイトルやサブタイトルに入れる
  • ポイント
    1. なぜこの話をしなければならないのか?
    2. なぜ私はここにいるのか?
    3. なぜみなさんはここにいるのか?

デマンドを植えつける

  • ほしい!やりたい!使いたい!と思う気持ちを植え付けること
  • ないとどうなるか?どう困るか?を訴えるホラーストーリーが良い

スライド作成のヒント

  • タイトルスライドは長く表示されるのでかっこよくする
  • 1枚の中に同じワードが繰り返されないよう重複排除する

話し方

  • 相手を見てしゃべることが難しい場合、それでは、続いて、そして、実は、なぜなら、といった接続詞のタイミングで相手を見るだけで、顔を見ているという印象になる
  • カウントするときや、順序を説明するときは指を使う
  • 最後のことばはあらかじめ準備しておくと良い
  • 話し始めのことばも考えておくとよい
  • 最初に、終了時間を告げること。相手が集中しやすい
  • スライドにはファクトを書き、プレゼンでオピニオンを添えて読む。「5%というわずかな確率なので気にしなくてもよいでしょう」
  • 絶対時間と相対時間を合わせてしゃべる。3年前の2017年の頃、、。相対時間は身近に感じて行動を促しやすい。
  • 体言止め、質問と回答、魅力の語尾、を使ってプレゼンを単調ではなく魅力的にする
  • 最初のうちに、うんうんとうなずいて聞いてくれる人を見つけ、ペースメーカーにする。

平成から令和になり、うどんからドライヤーにクラスチェンジした話

うどんとの出会い

AirPods Pro買ったのでレビュー

うどんうどんとAirPodsを半ば馬鹿にしていた私ですが、通勤中の英語の勉強や音楽を聴くのに買ってみて、ワイヤレスイヤホンのあまりの便利さにしてやられたと感じました。スマホと耳をつなぐケーブルが実はいかに邪魔で、ユーザー体験を損ねていたのかを思い知ったしだいです。

そんな私が、ノイズキャンセル機能付きのAirPods Proを購入し、ようやく手元に届きましたのでレビューしたいと思います。

令和になりうどんもバージョンアップ

届きました、AirPods Pro! 実は注文したのは昨年の12/16日のこと。最初は11/13日にAmazonでオーダーしたのですが、まてど暮らせど入荷予定のめどが立たず、痺れを切らして公式から注文し直し、Amazonはキャンセルしました。 ですので、欲しい!買うぞ!と決めてから2か月ほど待たされたわけです。

箱はこんな感じですね。 まあいつものアップル製品らしい佇まいです。 というわけでさっそく開封します。 毎回思うのですが、フィルム包装されていますが、はがし始めるところが用意されていて、こんな感じにとても開けやすい。 この気配りが、地味に嬉しいです。最近子どもにDVD(Blu-rayではなく、、)を買ったのですが、フィルムピッチピッチ包装で、開け口もなく爪でカリカリやってフィルムをワイルドにひき裂いて開封するハメになるのですが、実にストレスフルなユーザー体験ですよね。みなさん見習って欲しいのですが、特許でも取っているのか、他社プロダクトであまり見ないんですよね。コストの問題かなぁ。

箱を開けたところです。シンプル。 取り出したところ。 先代より横長のケースの中に、ドライヤーが入っています。慣れるまで、ケースから取り出すのが難しかった。指でつまもうとするのではなく人差し指の腹で押し出すようにしてやると取り出しやすいです。 本当にドライヤーみたいですね。

軸に少し平らになった部分があるのが見えますでしょうか。ここをつまむとカチッとクリックできるようになっていて、再生を開始したり、曲送りしたりと、操作をすることが出来ます。長押しするとノイズキャンセルの有無を切り替えられます。従来のAirPodsではトントンっとタップする操作系でしたが、Proではカチッと感があるので、より分かりやすいように思います。本当にクリックできているのか、ハプティックでそう感じるような仕組みなのかは分かりませんが、Goodですよ。

ファーストインプレッション

とりあえず使ってみました。たまたま洗濯機を回しながらだったのですが、耳に入れてしばらくすると少しトンネルに入ったときのような違和感があり、続けてシーンとがなりました。これには本当に驚き、一瞬何が起こったのわかりませんでした(大げさかもしれませんが、ノイズキャンセルイヤホンは初めてだったので本当に驚いた)。 試しにノイズキャンセルをOFFにしてみたところ、洗濯機はちゃんと回っていました。

これは通勤電車の中や、新幹線車内での使用に期待できそうです。来月は出張で新幹線に乗るので、忘れずに使いまくりたいと思います。

2020/01/14追記 通勤電車の中で使ってみました。高めの音はけっこう聞こえることが分かりました。例えば線路の継ぎ目のガタンという音。対して、ゴーという風切り音はほとんど聞こえなくなります。あえてそういう仕様になっているかも。もしくは、AirPods Proのノイキャンの仕組みは知りませんが、瞬間的に発生する音はキャンセルが難しいのかも知れませんね。

Gitこんなときどうする(GitLab)

社内でGitLabを使い始めました。個人レベルでPC間のファイル同期用途としては以前から使用していたのですが、実務かつ複数人で使い出すと操作に困ることが多かったので、『このときはこう!』というのを書き残していきたいと思います。

そもそものブランチの使い方

これには正解はないが、今のところGitLabFlowをベースにしてこんな感じのルールにしています。

リモートリポジトリにはmasterとstagingとproductionを用意。masterは最初からずっと、stagingとproductionは初回リリース以降はずっと存在し続ける。作業は、masterから要件単位にfeature/xxxブランチを切って行う。

ローカルの作業はfeatureブランチで行い、コミットは各自のタイミングで。単体テスト終わるまではそのまま。テスト完了したものをpushし、masterブランチにマージリクエストする。

ある程度の区切りで、masterブランチをstagingブランチにマージして、ステージング環境での動作確認や顧客デモを行う。

実際のリリースタイミングでproductionにマージしてバージョンタグ(v1.1.0など)を付けています。

このときはこう

ローカルリポジトリで細かくコミットしているが、細かすぎるのでまとめたい

ローカルリポジトリのコミットは個人の自由なタイミングで行っています。ですが、1つのfeatureの実装が終わり、ソースレビューに出すときなどに、細かなコミット多いとログインが汚れるし、レビューする側も見づらいです。

そんなときは、複数のコミットをrebase -i でまとめます。

$ git rebase -i

出力イメージ

pick 9dfab7ac 〇〇機能追加しました

pick c04aced8 レイアウト調整

pick ee35f7dc テストコード追加

エディターが開き、コミットが古いものから順にリスト表示されるので、pickをsに変更する。

 

ブランチ切って開発中に、リリース済みのバージョンに緊急対応が発生したとき

作業中ブランチでは緊急対応しないこと。masterからhotfixブランチを切って、対応してmasterにマージする。masterには、前回のリリース以降に開発した、未リリースのfeatureがマージされている可能性があるので、hotfixのマージコミットだけをcherry-pickして適用する。

 

作業中のブランチに、他の人のコミットを取り込みたいとき 

他の人のコミットをすべて取り込んで、最新のベースに合わせるときは、rebaseをする。

hotfixブランチで対応したものだけを、開発中のブランチに取り込むには、cherry-pickを行う

 

戻したい系

コミットを取り消す

コミットを取り消すには、reset(リセット)を使う

  • コミット操作を取り消す(変更内容を未コミットに戻す)

$ git reset --soft HEAD^

  • コミット内容ごと取り消す(変更内容も無くなる)

$ git reset --hard HEAD^

取り消したことを取り消す(直前のリセット操作を取り消す)

$ git reset --hard ORIG_HEAD

プッシュを取り消す

$ git revert 

$ git push

マージを取り消す
  • マージしようとしたらコンフリクトして編集もしたけど諦めてやっぱりやめたいとき

$ git reset --hard HEAD

  • マージ完了、未プッシュのとき

$ git reset --hard ORIG_HEAD

  • マージ完了、プッシュもして共有済みのとき

$ git revert -m 1 <マージコミットのID>

 GitKraken

Git操作にGUIツールとしてGitKrakenを使っているので、そちらについてもメモ。

リベース操作

GitKrakenでリベース操作をする際に、いつもいつも操作を間違えるのでメモを残しておきます。

dev, topicの2つのブランチがあって、topicブランチで開発中にdevがけっこう伸びてきたのでリベースしたい。topicはまだ開発中なので、マージするのではなく、最新のdevを取り込んでおきたい。

操作
  1. topic/XXXブランチをチェックアウトする
  2. devブランチ上で右クリックし、"Rebase topic/XXX onto dev" を実行する
  3. コンフリクトなどに適宜対応し、完了する

 まだまだカバーしきれていない「こんなときどうするっけ?」がありますので今後も更新していく予定。

SwitchBotで物理スイッチをIoT化

手軽におうちハック

スマートホームだ、コネクテッドだ、とは言うものの、ネットワーク非対応な(コネクテッドでない)機器を全て入れ替えるのはハードルが高いですよね。

そんなとき使えそうなのが、以前紹介したNature RemoのようなWiFi経由でコントロールできる赤外線リモコンです。赤外線リモコンで操作可能な機器はこいつでなんとかなります。

それでもまだ、物理スイッチの操作が必要な機器はお手上げでした。

 

ですが、クラウドファンディングのIndiegogoでそんなお悩みを解決してくれそうなプロダクトを発見したので、さっそく入手してみました。

Switch Botという、物理スイッチを押してくれるガジェットです。

※この記事を書いたのは2年ほど前で、今ではAmazonで普通に買えるようです。

SwitchBot - Your simple switch to a smart home | Indiegogo

 

f:id:jiig999:20171120011152j:image

 

小さい箱がswitch botで、大きい箱にはスイッチリンクというハブが入っています。

switch bot はスマホアプリからBluetooth経由で操作しますので、単体ではリモート操作ができません。リモート操作を可能にするには、オプションのハブが必要です。ハブを設置すると、アプリからリモート操作できますし、IFTTT連携なども行えるようになります。

 

使ってみて

長年、買うだけ買って使い道を見つけられずにいたのですが(じゃあなぜ買ったというツッコミは無しで)我が家では、今では白と黒の2つのswitch bot君が活躍しております。

一つ目は、玄関灯のONOFF。夜になると点灯して、朝に消灯するようにタイマー設定しています。旅行や外出時の治安の面と、夜に仕事から帰ってきたとき、自転車のカギや家のカギが見やすいので、ここに使うことに決めました。

もう一つは、お風呂のお湯張りボタンを押す用途。事前にお風呂のセンをしておく必要はありますが、外出していて思いのほか帰りが遅くなったときなどに、帰ってすぐに子供をお風呂に入れることが出来るようになりました。このありがたさ、子育て世帯なら分かっていただけるのでは無いでしょうか。

 

設置の仕方に工夫が必要な場合もありますが、ハマればとても便利ですよ。

Terraformコマンド備忘録

AWS環境のIaCのために、terraformを初めて導入してみたので、コマンドなどを忘れないようにメモ。ちなみに、CloudFormationとどちらを今後使い込んでいくか迷っているのですが、CloudFormationは数年間に少し触ってすごく面倒だった(当時)ので、遠ざかっていましたが、あれからだいぶたってYAMLにも対応したので使いやすくなっているかも、、。

基本のセット

terraform init
terraform plan
terraform apply
terraform destroy

initは本当の最初に一度だけ実行すると思っていたのだが、新たなproviderを使う構成にしたときなど、ときどき必要になる。

planで現在の状態とtfファイルとを比較して、実行計画を立てる。どこに差分があって、追加するのか変更で良いのか、削除するのか、といったことが計画される。 applyでも内部的にはplan相当のことをやったのちに、本当に実行するかを確認してくれるので、plan→applyの流れが必須というわけではない。 destroyで環境を削除する。

-targetオプションを使用することで、特定のリソースだけを構築したり削除することができる。 terraform destroy -target=aws_instance.web

terraform fmt # tfファイルのフォーマット整形
terraform console

terraform graph | dot -Tsvg > graph.svg
# 依存関係の可視化

便利関数

サブネットのCIDR

cidrsubnet("10.0.0.0/16", 8, 0)
# → 10.0.0.0/24

cidrsubnet("10.0.0.0/16", 8, 1)
# → 10.0.1.0/24

cidrsubnet("10.0.0.0/16", 8, 100)
# → 10.0.100.0/24

ホストのIPアドレス(のCIDR表現)

cidrhost("10.0.100.0/24", 3)
# → 10.0.100.3/32

実際の使いどころとしては、CIDRをベタ書きしたくないときに便利。 VPCのCIDRを基準にして、サブネットCIDRとその中に配置するホストのIPアドレスを表現することが出来る。

# VPC CIDRが10.1.0.0./16とする
cidrsubnet(aws_vpc.vpc.cidr_block, 8, 1)
# →10.1.1.0/24
cidrhost(aws_subnet.public_subnet, 25)
# →10.1.1.25/32

VPCのCIDRを変更したときにサブネットやホストのCIDRを書き換えなくても良いので、IaCが捗ります。

既存の構成のterraformへの取り込み

terraform import

しかし、importコマンドを使うやり方は、手順が多くて、やや面倒くさい。 そこで、terraformingがおすすめ。 全てのリソースには対応していないが、対応しているものはterraformingのほうが使いやすい

SVN信者をGitに改宗させる話

はじめに

最近、社内のバージョン管理ツールを(ようやく)SVNからGitに切り替えたのでその話。

新しいモノに触れようとしない、古い技術にしがみつく層が多く、そんなメンバーに改宗してGitを採用してもらうべくエヴァンジェリストな活動をしました。

やったこと

  1. 座学による概念理解
  2. ハンズオンによる体験と、Gitクライアント環境の個人PCへの導入
  3. アフターフォロー

座学による概念理解

私自身が初めてGitを使い出したときに、SVNとは概念や用語の違いがあって、スッキリ理解するまでに時間がかかったので、メンバーにはそこを一気に飛び越えてもらえるように講義形式でレクチャーしました。 また、今のSVNから移行するにはスイッチングコストがかかるし、Gitは学習コストもそこそこ高いので、慎重派を動かすためには、SVNでのお困りごとがGitなら解決できますよ、という例示が効果的でした。

Gitのメリット

個人単位で任意にローカルコミットできる。

SVNだと、コミットしたコードは全体で共有されるので、ビルドが通らない、開発途中などの中途半端なものをコミットすると、他のメンバーの作業にも影響を与えてしまう。 Gitは個人単位でローカルリポジトリを持っており、そこに対してコミットしていき、ある程度まとめて共有リポジトリ(リモート)に対してプッシュという操作で反映する。 なので、「ライブラリを試してみてダメだったら戻す」とか、「リファクタリング前にいったんコミット」なんかが圧倒的にやりやすい。

(GitLab)コードレビューのための仕組みがある。

マージリクエストという仕組みを使うことで、ソースコードレビューをブラウザ上でできて、指摘コメントなどの記録も残せる。これまではレビュー記録票というExcelシートを使っていました。 マージのコンフリクト時も、ブラウザ上でコンフリクト解消してマージ作業を完結することができる。

並行開発がやりやすい

段階リリースだったり、アジャイルとかイテレーティブな開発スタイルを採用している場合に相性がよい。どのようなブランチモデルで運用するかにも寄りますが、本番稼動しているバージョンのコードには手を付けずに、開発ブランチであれやこれや機能追加して、テストして、ということができる。これの何が便利かというと、開発途中に本番系で緊急対応が必要になったとき、緊急対応部分だけをリリースすることが出来る。ほかにも、並行開発ありきで作られているので、便利なコマンドがたくさんある。

ハンズオン

座学だけでは、いざ使おうというときに、環境構築やらなんやらで結局つまづいたり時間が取られてしまうので、ハンズオン形式で環境構築とGit操作体験まで一気に立ち上げることにしました。 これにより、自分のPCにGitクライアント環境が整うので、いつでも使い始められる状態になり、使い始めるときのハードルを下げることができると思います。

アフターフォロー

困ったときにいつでも気軽に質問してくれていいですよ、というアナウンスと、そのためのチャネル(Slackなど)を用意しました。 さらに、初めて導入するというプロジェクトでは、近くに座るなどして、何か困ったときにすぐフォローしてあげられるようにするのが良いですね。現場コーチっていうんですかね。

最後に

技術のアンテナ張っている人たちは、布教活動はしなくても、ハンズオンだけでも効果ありと思います。しかし、慎重派、現状維持派の人をスイッチさせる(説得する)には、彼らが理解できるレベルで何かしらのメリットを提示する必要があります。 これって、実は普段の仕事でも必要なスキルだと思います。 技術者の興味だけではなかなか新しい技術の採用は難しく、その技術によって何を変えることができるのか、を説明できることって大事だと思います。

シーズベースの新規事業開発について考えてみた

新規事業やサービスのアイデアを考えるとき、ニーズベースとシーズベースに大別できると考えているが、シーズベースにも、種類があると考えている。

 

パターン1 技術シーズをベースとする場合

例えばIoTで何か、とか、この新しい技術を使って何か、といった技術シーズの場合は、そのシーズをもとに、アイデアを考える。アイデアの発想のやり方はいろいろある。

で、よさそうなアイデアが出たら、そのアイデアで、誰のどんな課題が解決できるだろうかということを具体的にことば化する。これで顧客仮説と課題仮説ができあがるので、あとはリーンスタートアップの手法で課題仮説検証をしていけばよい。課題の存在が確認できれば、解決策(ソリューション)は先に考えてあるので、そのソリューション仮説検証をする。

 

パターン2 すでに世にある製品やサービスをシーズとする場合

テレビに関する新規事業、新サービスみたいな文脈のとき。テレビというプロダクトにこだわるか、こだわらなくても良いかによって分岐すると思う。

デザインシンキング、エスノグラフィといったアプローチが使える。ジャーニーマップを書いたりインタビューしたりして、顕在ニーズや潜在ニーズを考えていく。そのあと、そのニーズ(課題)を持つ顧客セグメントを絞り込んで、課題仮説文を作れば、あとはリーンスタートアップに沿えばよい。

ただし、課題仮説が検証されたとして、最適なソリューションを自分たちが提供できるのか、ということが問題になる。例えば、自社がテレビを売っている場合だと、テレビが要らなくなるようなソリューションは採用されにくいだろう(でも、深い顧客課題がそこに存在するなら、遅かれ早かれ他のプレイヤーが現れてテレビを駆逐するでしょう)。

 

パターン3 シーズ無しで行く場合

テーマ領域を決めて、あとはインタビューや観察を先にするもよし、社内でアイデアを出してから課題仮説を検証するもよし。

こちらの場合も、発見した課題に対しての最適なソリューションを提供出来るかどうかは別問題となる。でも、自前でなんとかしようしなければ、たいがいは提供できるだろう。

 

まとめ

・デザイン思考をシーズベースに適用するのは要注意。すでにシーズの利用ユーザがいればなんとかなる。シーズ周辺の現状のユーザー体験をとっかかりとして、そのユーザにインタビューしたり観察したりして、インサイトを得る。

・ニーズベース、シーズベース、いずれにせよ、ユーザー×課題×解決策(+価値提案)が出そろうところまで行けばあとはリーンスタートアップの手法は適用できる