TAMINIF’s blog

大阪在住のWebエンジニア。iOSアプリもやってます。勉強会にも参加してます。最近はマネージャー色強め

エンジニアたとえ話

特に技術的な話をエンジニアではない人にするときによく採用する手法なのですが、技術的な内容を理解してもらう必要があるときに相手が知ってそうな内容を使ってたとえ話に置き換えることをしています。
なぜそうするのか、その手法と私の考えるメリットについてブログに書いておきます。
自分はこうしているというまとめ的なものです。

例題

開発工数の見積もりをすぐ出せないということを説明するシーン

Aさん「開発工数ってすぐ出せないものなんですか？」
私　 「出せないですね。だいたいはわかるんですけど」
私　 「たとえば、カレー作ったことありますか？」
Aさん「はい、作れますよ」
私　 「カレーって、だいたい1時間あれば作れるじゃないですか」
Aさん「作れますね」
私　 「でも、それって材料揃ってる前提じゃないですか」
私　 「冷蔵庫開けてみないと材料あるかわからないとか」
私　 「調味料揃ってるか確認しないといけないし」
私　 「もしなかったら調達しないといけない。そうなると1時間では作れない」
私　 「あと、カレーの種類次第では調理時間かかるかもしれないじゃないですか」
私　 「キーマカレーだと1時間で作れないかもしれないから、調べないと答えれない」
私　 「それが見積もり作業です。もちろんこれが全てではないです」

なぜやるのか、そのメリット

相手の土俵に立って説明できる の一点に尽きます。
だいたい自分がやっていることを説明するときは、業界でしかわからない専門用語を使いがちで
わからない専門用語が入ってきた時点で相手はその理解に頭を使うようになって、説明はほぼ入ってこないです。
なので、まずは相手の知らない用語をなくす必要があります。

ただ、専門用語なしで説明できる内容もないと思っていて、じゃあその専門用語を相手が知っている用語に変えれば相手も理解できるようになります。
上記の例で言うと「工数調査」を「材料を探すこと」「調理器具を確認すること」「カレーの種類を聞くこと」としています。
これなら相手も知っているので、そのあとの説明を聞く余裕が出来ます。
また、相手も自分が知っている内容なので想像しやすくなります。口頭だけのコミュニケーションはもっとも辛いと考えているので、
相手が想像できることを意識して説明すると自分にも相手にも優しくなります。

どうやるか

とにかく何かにたとえてみる

まずはたとえ話が出来ないことには始まらないので、たとえ話をやってみましょう。
エンジニアに説明する時でも良いと思います。共通言語があるとはいえ、別の言葉で話してはいけない訳ではありません。
自分の知らないことでたとえるのはやめておきましょう。間違った意味になるかもしれません。
話した結果、相手が理解できてないとたとえない方が良いまであるので、もしかしたら練習も必要かもしれない。

相手も自分も知っていることで話す

たとえて話が出来たとしても、たとえた結果がまた相手の知らない話であれば意味がありません。
自分と相手の共通知識で話すようにしましょう
なので、説明する相手をちゃんと理解することも必要です。
これは副次的かもしれませんが、コミュニケーションをとることにも繋がります。
そのメリットもあるかもしれません。

まとめ

本質的なことは何もかけていませんが、普段私が意識してやっていることを文章化しました。
特にエンジニアからマネージャーに転進するとき、必ずエンジニアじゃない方と話をする必要が出てきます。
そのとき、スムーズなコミュニケーションができるテクニックだと思っていますので、
別業種の人と話をするのに抵抗がある方は、一度試してみることをお勧めします。

iOSDC 2018に参加してきました

登壇してきました記事はこちら

taminif.hatenablog.jp

iOSDC 2018に参加してきました。とても良かった。

とても良かった

iOSDCとても良かった。去年も一昨年も良かったけど今年も良かった。
東京ではわからないですが、iOSエンジニアがあれだけ集まるのはそうそうありません。しかもその人たちが知見を持ち寄ってコミュニケーションを行うのですから、これほど情報密度が高い場所ができることはまず個人では難しいと思います。
会社でできてもごく一部だと思います。
そんな場所にいて情報収集すれば当然のように自分が知らない情報が見つかりますし、エンジニアとしてのレベルアップにつながると思います。
こういうコミニュティはどんどん参加できるようにしたい。

もっとも良かったこと

今回、設計話を多くの方とすることができて、改めて設計は大事だと認識しました（6回目ぐらい
こういう時にはこうすれば良い、この時はこうすると大変になるなど
自分のケースで話をさせてもらったり、他だとこうしてるって話は大変貴重で
かつ、上で書いた情報密度が高いのでどれも新鮮な情報でした。
こういうことは独学では限界があるし、事例を元に辛かった話や良かった話を聞けると説得力が違うと思うので、機会の少ない中で最大限学べたんじゃないかと思います。
おそらく、使える言語の種類を増やすより、一本芯の通った設計構想を持つ方が、今後のキャリアに活かせると思います。

辛かったこと

褒めてばっかりだと信者化するので、一点だけ。
交流する機会が多いのはありがたいのですが、やはり3.5日は多いです。行かなかければ良いという意見もあると思いますが、チケットやセッションのことを考えると勿体無いという意識が出てしまってよくなかったです。
特に、地方遠征組なので、行かなかった時に他に何するかの選択肢がなく
朝起きて「行かなきゃ」と思ってしまったことは辛いことでした。義務感で参加するようになってた。
一年に二回やってくれる方が嬉しいかもしれません。正直わからない。

終わりに

iOSDCはコミュニケーションの場です。これから非公式イベントがそれぞれ開催され、もちろんリモートでも参加できる体制を作ってくれているのですが
やはりリモートだと単方向通信になることから、参加するけど本当の意味での参加にはならないと考えています。
その意味で、自分のiOSDC 2018はこのブログでおしまいとなります。改めて言うけどとても良かった。
いずれ関西でもできると良いけど、関西の方とあまり出会えなかったので・・
関西で布教活動はしていきたいと思います。来年同じ3.5日でも参加したいし、他の人にも参加を促したいです。

iOSDC 2018に登壇してきました

iOSDC 2018に登壇してきました。まだ最終日これからですが無事喋り終えたのでブログに残しておきます。

WebSocketをiOSに持ち込んで辛い思いをした経験がありますか！？ by taminif | プロポーザル | iOSDC Japan 2018 - fortee.jp

speakerdeck.com

発表について

もちろん言えてないことや公に言いづらいこともあるのですが、だいたい練習通り話せたかなと思います。
想定外でもちゃんとレスポンスできて、良い雰囲気にできたんじゃないかなと思います。

序盤で辞書の画面を見せた時に、知ってたら嬉しいですくらいで流そうと思ってたのですがみなさん手を挙げていただいて
私のUXはとてもよかったんですが、聞いていただいている方々に負担かけてしまいました。
手を挙げてアンケート取るスタイルはあまり良くないと個人的には考えているので（しんどいし）話し方を注意しようと思います。

CfPはタイトルや説明部分が弱かったような気がするので、興味を引ける内容を考えれるようにしたい。

反省

一点だけ、記録として残しておきたい反省点があります。
公開用スライドからは削除したのですが、最後に We are Hiring! のスライドを入れたんですけど、ここは笑いを起こせるような構成にすべきでした。
発表内容で盛り上がっても、このスライドで「あーはいはいいつものやつね」的な感じで出しちゃうと最後まで良いとはならないと思うので
出すからには盛り上げれる話し方や出し方をすべきだったと思いました。
次の発表からは、何か一つボケれるようにしておきたいです。

iOSDCについて

まだ終わってないので参加してきましたブログは別で書きます。
すごく楽しいです。体力はギリギリ。

終わりに

最後まで楽しんできます！

　　　　　　　　　　　　　　　　　　　　　　/|
　　　　　　　　　　　　　　　　　_,,..-/_／　|
　　　　　　　　　　　 　 　 /|／　 /　 〃| .|
　　　　　　　　　　　　　 / //／/／／ //l
　　　　　 　 　 　 　 　 /ｨ／　.//　 / ///
　　　　　　　　　　　　 l　j　　//／i ,,.-'"/
　　 　 　 　 　 　 　 　 ', }）､.／// ／／
　　　　　　　　　　　　　l　　 ヽ-‐＜／
　　　　 　 　 　 　 　 　 ヽ-|　　 　 l
　　　　　　　　　　 ＿__,,..∠_　　　　 ＞-.,,_
　　　　　　　　　 r'--､:::::::::::::`ー―‐'::::::::::::|ヽ
　　　 　 　 　 　 l　 　 ＼::::::::::::::::::::::::::::::::::::l ﾉ
.　　　　　　　 　 | #;;:: 　 ∨:::::::::::::::::::::::::::::/ l
　　　　　　　　　| ┃ ┃ r':ﾉ:::::::::::::::::::::::::/　 |
　　　　　　　 　 l　 　┃ l::::::::::::::::::::::::::／　| .l
　　　　　　　　　', 　　;: /:::::::::::::::::::::::/|　　　ｲ
　　　　　　　　　 } ､　; {:::::::::::ニ=-‐{ .|　　　 |
　　　 　 　 　 　 l　l　　l::::::::::::::::::::::::ヽ|､__i__ノ|
　　　　　　　　　|`ー―'|::::::::::::::::::::::::::', 　 　 .|
　　　　　　　 　 |　　 　 |:::::::::::::::::::::::::::i　　 　|

iOSDC 2018に参加と登壇してきます。

表題にある通り、iOSDC 2018に参加します。前夜祭から参加、9/1には登壇します。 iosdc.jp

I will blogを開催前からですが、ブログ書いてたらプレゼントもらえるらしくこういうのに弱いのでブログ書きます。
資料作る前にブログ書いてる。そろそろ尻に火がつく状態。

書くこと

自己紹介

京都で働いてます。エンジニアですが、最近はマネージメントばかりです。そんな中で技術ネタでCfP通ったのでちゃんと技術者としてお話しするつもりです！

自己紹介プレゼン

去年は「英会話サービスのために作成したビデオチャットアプリの技術」という内容で登壇しました。
今年は「WebSocketをiOSに持ち込んで辛い思いをした経験がありますか！？」という内容で登壇します。

speakerdeck.com

iOSDCのどこにいるか / 参加予定

9/1（土）の16:00からTrackCで喋ります。全日参加予定ですが、関西から参加するので基本ぼっちだと思います。関西弁聞きたい方肩叩いてください。きっとボケます。

https://fortee.jp/iosdc-japan-2018/proposal/1e7fe56b-79da-454f-8a2f-08b1a8943aab

気になってるトーク

※まだチェックできてない。

Twitterアカウント

taminif (@sbntaminif) | Twitter

去年から得た知見

おそらく今年もTrackごとに部屋の大きさが違うのですが、去年のクロージングで実行委員長が
「TrackB/C/Dのセッション（部屋の小さいセッション）でも、話を聞きにきてくれた方にベストトーク賞の投稿を呼びかければ賞に入れる数だった」
とおっしゃられていたので（言質は取れていない）今年は実践して呼びかけてみようと思います。
ぜひ聞きにきてベストトーク賞入れてください。検証結果出します。

その他

チャレンジングな夏にしたい。最高の夏にしような

関西Node学園3時限目で登壇しました

概要

表題の通り、関西Node学園3時限目に登壇して来ました。今回はLINE株式会社さんの京都オフィスをお借りして開催させていただきました。
今回私は「LINEで馬券を購入する」というタイトルで登壇してきました。

続きを読む

良い勉強会に参加するとブログを書きたくなる

PHPカンファレンス関西2018に参加しました。用事があったので途中で抜けたんですけど、良い話が聞けて参加して良かったと思いました。PHPの垣根を超えた幅広い話や、ブースの盛り上がりはとても良いと思いました。関西で大きなカンファレンスやることがとても少ないので、開催される際は積極的に参加したいと考えています。

この前後で関西Node学園2時限目を開催し、関西Node学園3時限目を予定しています。3時限目はこれからですが、2時限目がすごく良かった話をまだブログに書いていなかったので書きます。

関西Node学園2時限目すごく良かった

今回、初めてfreeeさんにスポンサーしてもらって、飲み物と食べ物を用意してエンジニア同士の懇親会の時間を設けることができました。自分は結構準備や当日の設置に時間を取られたんですけど、大雨の中来ていただいて楽しんでもらえてるように見えたのでとても良かったと思いました。

関西のエンジニアの交流がひとつできた気がして、関西のエンジニア界隈を盛り上げたいという動機から始めたので、進捗ありましたって感じになりました。 これもスポンサーしてくれたfreeeさんや会場使わせてくれたさくらインターネットさんのおかげだと思うし、今後もっと多くの技術者さんや企業さんを巻き込んで関西で勉強会を盛り上げていきたいと考えています。自画自賛許してください。

関西Node学園3時限目やります。

nodejs.connpass.com

宣伝になるんですけど、間髪入れずに3時限目やります。大阪だけでなく京都でもNodeエンジニアを盛り上げていきたいです。 2時限目に負けず良い勉強会だったと思えるような勉強会にするよう心がけますのでぜひ来ていただきたいです。

良い勉強会に参加した後はブログを書きたい

これに対してなぜかはわからないですし、なぜかを議論するつもりは特になかったりします。良い勉強会に参加した時は帰った後も興奮が収まらずブログに書きなぐってすぐに公開したい気持ちになります。
すぐに書かないと忘れるからかもしれません。他の人に良い勉強会を共有して、教えてあげたいのかもしれません。

でも、ブログ書くことはすごく良いことだと思います。

1時間頑張ってブログを書けば、ブログを書くことで他の参加者や主催者に感想やKPTを教えることができたり、ブログを読んだ人が次回参加してくれたり、自身の勉強会参加した知見をまとめたりできると思います。

最初のきっかけはiOSDC

2017年のiOSDCがすごく良くて、その時はとにかくブログに書きたいという気持ちになりました。よく考えたらこのブログの開設理由がiOSDCのブログを書きたいからで、私のブログ意欲は勉強会駆動なのかもしれません。
iOSDCはすごく良いです。楽しいし勉強になるしエンジニアたくさん集まるしで私がもっとも参加した方が良いと言えるカンファレンスです。今年も開催されるのでぜひ参加しましょう。私も登壇する予定です！

iOSDC Japan 2018

つまり

みなさんも勉強会に参加した後はブログ書いて盛り上がった勉強会をさらに盛り上げましょう。
今日言いたいことはそれくらいです。

puppeteerのHeadless modeの意味

TL;DR

puppeteer.launch のオプションの headless をtrueにするとChroniumのUIが立ち上がり、目視で動作が確認できる

はじめに

puppeteer.launch でbrowserオブジェクトを生成する時にオプションで headless を指定するとどうなるのか

何が起こるか

headless をtrueに設定するとスクリプトを実行した時にUIありでChroniumを実行します。Chrome59でヘッドレスモードが搭載されたのでUIなしにChroniumを動かすことができますが、UIありでも実行することが可能ということです。
これを使用することで、自分の書いたスクリプトがどう動くのか目視で確認することができます。指定した通りにボタンが押されるかや、読み込み完了がどのタイミングなのかを見て確認することができます。

実行パスに注意

同じ puppeteer.launch のオプションの executablePath でChroniumもしくはChromeのパスを指定することができる。Macの場合、Chromeをインストールしていればここに何も指定していなければ普段使うChromeが起動してUIが見れる。

まとめ

実運用する際に設定する機会は少ないですが、実装中に確認しながら作ることは多いと思うので初期は設定して開発することをお勧めします。