seri::diary

日常

テキストチャットにおけるコミュニケーションの難しさについて #remoteadvent

この記事はリモートワーク Advent Calendar 2015の13日目の記事です。

tl;dr

  • リモートワークにおける主要なコミュニケーション手段は「テキストチャット」
  • テキストチャットでなかなか意思疎通ができない時のストレスはかなり大きいが、少しの工夫でかなり改善できる
  • お互い思いやりを持ってテキストチャットを使うことでストレスの少ないリモートワークライフを

前情報

  • 筆者はwebエンジニアでフルリモートで仕事をしていました
  • 普段の業務にSlackなどのテキストチャットツールを使用していました

チャットで全ての業務上のコミュニケーションを賄うということについて

リモートワークをしていると「それで問題は起きないのか?」という質問を今でもいろんな人から聞かれますし、リモートワークを始める前まで自分も疑問視していました。

なので、リモートワークを始める前は、実際の業務はビデオチャットとかを多用して口頭でのコミュニケーションが多いんだろうなーと思っていましたが、実際は業務上のコミュニケーションはテキストチャットで大体何とかなっていました。

エンジニアという仕事は、テキストでのコミュニケーションが多い職種です。仕様はドキュメントに記載され、成果物も一種のドキュメントであるソースコードだったりインフラ作業のログだったりします。だからもともと相性がいい、といえばそうなのかもしれません。もちろん、複雑な仕様を説明したりするときには、テキストや画像だけでは限界があるのでビデオチャットを使います。

質問が難しい

しかし、テキストチャットで長文のやり取りを続けるのは、会話よりもずっと労力がかかります。少なくとも自分は、50文字ぐらいの文字数で伝えなければならないことであればチャットより口頭で会話した方がずっとラクだと感じます。

特につらいと感じるのは1回で伝わらない時で、その場合以下のようなやり取りが行われます。

  1. メッセージを送信する
  2. 相手からの受信を待つ
  3. 相手に意図が正しく伝わらなかった模様
  4. 再度メッセージを送る
  5. やっぱり伝わらないので再度伝え直す

2の「相手からの受信を待つ」というのは、場合によるがその間何も出来ないということを意味します。

作業を再開しても再開後1分で返事がきてまた中断されるので、この間うまくチャットと自分の作業の間で自分の意識を行き来するスキルが要求されます(あるいはすぐに返事しなくてもいい情報を見極めるスキル)。慣れたとしてもやはり作業を細切れに中断されるのはなかなかにつらいものがあります。 逆もまたしかりで、相手からの質問の意図をこちらが読み違えると同じやりとりを今度は相手にも強要することになってしまいます。普段物理的に会うことが少ない関係で、すぐに口頭でフォローすることも難しいので、こういうやり取りはお互いのストレスの原因になる可能性があると思っています。

具体例として、自分がよく直面したエンジニア同士のうまくいかないパターンのコミュニケーションでは以下の様なものがありました。

エンジニアAとエンジニアBのチャットである。

  • エンジニアA「@B これは何でしょうか? https://github.com/xxxx/yyyy/pull/4169/files#diff-fd8ab12
    ※URLはgithub上のPRのdiff上のとある行を指定している
  • エンジニアB「@A ああ、この修正を入れた意味ですか?それは○○が×××で(中略)△△です。」
  • エンジニアA「@B いやそうじゃなくて、□□なのに(中略)という意味で聞いたんですが。」
  • エンジニアB「@B ああ失礼しました。それは■■の場合(中略)です。」
  • エンジニアA「@B なるほど了解です。理解しました。」

なんてこともない話ですが、エンジニアA→エンジニアBからの質問が1回で正しく伝わっていればやり取りは1往復で済んだはずです。

また、2往復になるにしても、エンジニアB→エンジニアAへ回答する前に、質問の内容に不明瞭な点があるなら一度そこで質問して不明瞭な点を確認することでエンジニアBは2回説明する手間を省けたはずです。

ビジネスメールの基本に解決策がありそう

この問題を解決するためにいろいろ試行錯誤した結果、自分が行き着いたのはいわゆる「ビジネスメールのマナー」でした。(筆者は新卒でSIerに入社していて、当時は社内外のコミュニケーションには主にメールを使っていました)

自分が新卒の時に新卒研修で教わっていたことを思い出すと、以下の3点のことが重要だと教えられました。

  • 最初に「相手にどういう行動を起こして欲しいか」を完結に書く
  • 1行は長すぎず、かつ過不足無く
  • 最後に相手をねぎらうような言葉を入れる

これを元にさきほどのやり取りを改善するならこんな感じになるでしょうか。

<質問の仕方を修正する>

  • エンジニアA「@B ちょっと確認したいんですが、この修正はこのPRの別の部分と重複してるように見えたので不要かなと思ったんですが、どうでしょうか? https://github.com/xxxx/yyyy/pull/4169/files#diff-fd8ab12
  • エンジニアB「@A ■■の場合に(中略)です。」
  • エンジニアA「@B なるほど。理解しました。」

<回答する前に質問の意図を明確にする>

  • エンジニアA「@B これは何でしょうか? https://github.com/xxxx/yyyy/pull/4169/files#diff-fd8ab12
  • エンジニアB「@A すみません一応確認ですが、この修正の意図が分からないという質問でしょうか?」
  • エンジニアA「@B はい。□□でやってるから不要じゃないかなと。」
  • エンジニアB「@A なるほど。それは■■の場合に(中略)です。」
  • エンジニアA「@B なるほど。理解しました。」

前者の例はやり取りが1回になって時間短縮になりました。 後者の例ではやり取りの回数は同じですが、エンジニアAが2回説明していない分、エンジニアAの手間は少く、スムーズに回答できるのでお互いのレス待ちの時間も短くなることが期待できます。

このように、ほんのわずかな言葉の使い方次第でテキストチャットでの質問をスムーズに行うことができるようになります。 言われてみれば当然ですが、普段業務で忙しいと省略してしまうような言葉をほんの少し添えるだけでお互いの時間をかなり節約することができます。そのことに気づいてからは私はテキストチャットで質問するとき、される時は常に気をつけるようにしています。

テキストチャットもまたビジネスコミュニケーションである

テキストチャットはメールほど形式張ったものではないのでついカジュアルな文章で書いてしまいがちです。これはテキストチャットの良いところでもありますが、仕事上で重要な事は確実かつ迅速に伝える必要があります。

エンジニアにとっては、設計について議論するとき、コードレビューで指摘するとき、質問るときに発生するコミュニケーションは、すべて仕事上での重要なコミュニケーションです。同じチーム内であれば、「ビジネスメール」ほどの格式張った形式は不要だと思うしそんな文化になって欲しくはないと思いますが、仕事上のコミュニケーションにおいては確実に要件を伝え・伝えてもらえるコミュニケーションスキルを身につけておくべきだと私は感じます。

日報 2015-12-03

午前中にやったこと

  • 今年一発目のアドカレを予約投稿して拡散した

serihiro.hatenablog.com

  • 引っ越しの荷造り続き
  • 艦これ秋イベE-5乙ラスダン

[WIP] Erlang勉強

資料

今日の成果

  • [done]第二章 moduleの定義
  • [wip]第三章 関数の構文 ガード句まで

log

qiita.com

  • repl中のcurrent path移動はcd(PATH)
  • erlangjvm上で動かすerjangという言語もあったとか。。
  • repl上でコンパイルするときは compile(MODULE) 又は c(MODULE)
  • :tada:

github.com

  • 次はマクロだ -define([MACRO],[VALUE])
  • 関数節マジ :cool:
  • 見た目はメソッドオーバーロードだけど実体はswitch文にちかい
  • 引数でパターンマッチだと!許せる!
25> useless:greet(male,"Tarou"). 
Hello, Mr. Tarou!ok
26> 
26> useless:greet(female,"Tarou"). 
Hello, Mrs. Tarou!ok
27> 
27> useless:greet(femal,"Tarou").  
Hello, Tarou!ok
  • これ前にnaoyaさんがelixerで処理書くときに呼び出すcallbackを引数の内容で決められるとか言ってたやつかな qiita.com

  • erlangのガード句にはユーザー定義の関数が使えない。うーむ

岩手と栃木でエンジニアしてた所感 #ruraladvent

この記事は地方在住ITエンジニア(元・地方在住も可) Advent Calendar 2015の3日目です。

岩手県と栃木県でそれぞれリモートワークをして暮らしていた時の所感について書きます。

「地方でエンジニアとしてリモートワークして東京のクライアントと仕事したい」という人の参考になれば幸いです。
なお、地方で一人暮らしでリモートワークという暮らし方をしていた理由については長くなるので本ブログの別エントリーでいつか書きますが、特に深い家庭の事情とかはありません。一言で言うなら「好奇心でやってみた」程度です。
また、地方に引っ越す前は神奈川県川崎市で3ヶ月ほどリモートワークをしていた時期があります。

岩手県盛岡市での一人暮らし編

2014年10月~2015年4月末まで岩手県盛岡市でアパートを借りて一人暮らししていました。

北国ぐらしは車が必須だった

長らく首都圏で暮らしていたので車は持っていませんでした。なので、最初から車がなくても生活が成り立つような利便性の高いところに住んでいましたが、結論から言えばやっぱり車があった方が良かったです。

岩手県盛岡市という土地柄もありますが、盛岡市街地でも冬は最低気温-10℃、最高気温が0℃とかになって、1日中外出したくなくなるくらいの気候の日が多く、その中を徒歩で出かけるのもなかなか厳しいものがありました。そのため、歩けば10分、自転車で数分のような距離の場所ですら外出が大変でした。引っ越すに当たり、車を買わないことは織り込み済みだったので車がなくても生活できる利便性の高い場所(一人暮らしが多い岩手大学周辺)を選んだのですが、それでも厳しいレベルでした。

私は岩手大学出身で、盛岡で4年間「自転車+徒歩」だけで生活できていた経験があったので、車がなくても問題無かろうと思っていたんですが、流石に歳を取ったのか、はたまた在宅で仕事が出来てしまうということからの甘えからか、外出するのになかなかの思い切りが必要でした。

では地元の人はどうやってこの問題を回避しているか?というと、やはり自家用車を所有することでした。。というか自分も何度も車を持つことを勧められましたが、ずっと盛岡に住み続けるか分からなかったのと、維持費の問題で車を持たない決断をしていました。が、無理してでも車を持っていればまた状況はいろいろ変わっただろうなと思います。

平日の夜をどうやり過ごすか

大学を卒業してからも、盛岡を中心に趣味の活動をしていたこともあって、盛岡に知り合いは結構いましたが、朝9時から遅い時は夜11時まで自宅にこもって仕事をしている私と地元の企業に務める知り合いとではどうしても生活のリズムが合わず、平日に会うことは非常に難しくなります。

土日は趣味の活動等で会うことが多くなりましたが、平日はどうしても会うことが出来ないので孤独に夜を過ごすことになります。この辺、今考えればもう少し工夫できたような気もしますが、当時は仕事が忙しい時期だったことも重なって引きこもりがちになってしまっていました。

もし今同じような環境で暮らすとするなら以下の様な対策を取ると思います。

  • 遅くまで仕事をしないように時間を仕事の調整する
  • 仕事関係なく外に出て夜間に参加できるコミュニティで出会いを求める
  • 誰かと共同生活してずっと1人でいる状態を避ける

ちなみにこの問題、都市部でリモートワークしてても同じ問題が発生するのでは?と思われるかもしれませんが、都市部だと遅くまで仕事をしてその後飲みに行く生活スタイルの友人が結構いたので、夜にお互いの仕事が終わってから都内で合流して飲むとか、勉強会に行ってそこで会うとかが簡単に出来たので、そこまで暇をもてあますようなことはありませんでした。

なお唯一良かった点として、家から徒歩15分ぐらいのところにカラオケがあって、平日の夜はいつも空いていたので1人で行ってギターを思う存分弾くことができました。住んでいたアパートは壁が薄すぎて日常生活の生活音ですら全て筒抜けという恐ろしい状態だったので、近所にカラオケがあったのは本当に助かりました。

栃木県栃木市での実家暮らし編

2015年5月~2015年11月末まで栃木県栃木市の実家で親と同居していました。

とりあえず車はなくても何とかなる

実家暮らしなので、ということもありますがすぐ近所にコンビニやスーパーがあり、少し歩けば駅まで行けるので車がなくても普段の生活には困りませんでした。徒歩+電車で十分自分が必要とする行動範囲を移動できるようになったので、移動の問題は解消されました。

東京に日帰りで行けるのは大きい

例えば栃木から渋谷までだと2時間半程度で行くことが出来ます。なので土日の勉強会や、都内の友人に会いに行くぐらいは余裕でできるようになりました。なんだかんだで東京は便利で、岩手に行く前の自分は「ネットがあればもはやリアルTokyoなぞ不要!Amazon万歳!ネット万歳!」とか思ってたアホな私ですが、勉強会はどうやったって東京が圧倒的に多いし、著名な人に会って話を聞こうと思ったら東京に行くしか無いケースが多いのが現実です。 もともと自分も渋谷javaという勉強会を定期的に主催していた身なので、またその勉強会の運営に関われるようになって、再びいろいろな知見を得られるようになったのも良かったです。結局のところ、まだ自分は東京で学ぶことがたくさんあったんだなということを思い知らされました。

ギター弾き放題!!!

一戸建てでかつご近所もめっちゃ離れてるような環境なので思う存分ギターが弾けます。これは本当に良かったです。音楽活動するなら地方に拠点を持つのがベストなんじゃないかと思うくらい、早朝から深夜まで弾けます。好きな時間に楽器を弾くなんてのは就職してからずっと出来ていなかったので、この点を考えるとホントに地方の一戸建てに住むのはベストな選択です。

技術書難民

まぁAmazonで買えばいいんですが、地元の本屋が淘汰されつくされてしまい、私が読むようなIT系の技術書が地元で全く買えないような状態になっていました。盛岡では運良くエムズエクスポ盛岡店が出来ていて、わりと新し目の技術書にありつくことができたので思う存分立ち読みができた購入できたので良かったのですが、栃木市には残念なことにオライリー本のようなマニアックな本を売ってる本屋がありませんでした。 仕方なく基本Amazonで全部買ったり東京に行った時に(なんだかんだで週1は東京に行っています)大きめの書店に寄ったりしています。あと最近はkindle版の技術書が増えたのでkindle版がある場合は積極的にそちらを活用しています。あとはbookscanのプレミアムライト会員にもなっているのでamazonで中古で買ってそのままbookscanに配送してスキャンしてもらう、なんてこともやっています。

地方でリモートワークしてみてどうだったよ

こうやって書いてみるとメリットよりもデメリットの方が多くなってしまった印象を受けるかもしれませんが、首都圏と比べると生活環境の良さは地方が圧倒的でしたし、人と会わない時間が長くなることで自分のこれまでの人生や将来についてなどの普段考えないことを思索する時間を取れたり、趣味に没頭できたりといろいろと利点もありました。

いろいろ振り返って思うのは、常に人とのコネクションを切らさないようにすることだと思います。私は首都圏で働いていた時は、基本仕事での人間関係でしたが、仕事外でも会うような仲間が常にいましたし、孤独を感じるようなことはありませんでした。

それが地方に行ってできなくなったのは、自分が地方でコネクションを作る努力を怠った為だと考えています。今考えれば、地方にいる間はいろいろ理由を付けて新しい場所や分野で人と会うことを避けてしまっていたような部分もあり、今後も同じことを繰り返してしまう可能性があるので、もう少し自分の興味の幅を広げて新しい人脈を常に広げていくよう心がける必要があると感じました。

そのことを学ぶことができただけでも、この1年半地方でリモートワークを続けてきた意味はあったのかなと思います。

日報 2015-12-01

[WIP] Erlang勉強

資料

今日の成果

  • [done]evmを使ってerlang実行環境構築
  • [done]第一章読んでREPLで実行して確認
  • [wip]第二章 moduleの定義まで

log

  • erlangの文末はピリオドで終わる。REPLの場合はピリオド+スペースで行末を表す。
  • erlang= はパターンマッチ演算に使用される。代入演算子ではない。
  • パターンマッチ演算の左辺の変数がunbindな場合のみ左辺の変数に右辺の値を束縛する。
  • _ は常に未束縛の変数として機能し、パターンマッチングではワイルドカードのように振る舞う
  • タプルの第一要素にアトムを含むタプルを タグ付きタプル と呼び、型チェックみたいな使い方ができる(でもそれエラーになってプロセス死ぬんだけど。。erlangの死んだ奴は生き返らせるな理論に基づくとそれでいいのかな?)
  • ファッ!?
36> [97, 98, 99]. 
"abc"
  • リスト内包表記!そういうのもあるのか
  • リスト内包表記の生成式ではパターンマッチングの時のerrorは無視されて単純に式に渡されないだけになるだと!なるほどこの場合はタグ付きタプルが効果を発揮するな!
  • リスト内包表記で生成式にバイナリを使う場合はファットアローを使う

[WIP] Clojure勉強

資料

今日の成果

  • [done] Leigngenが入ってなかったのでbrewでインストールした
  • [done] Leigngenでプロジェクトを作ってInteliJIDEAでimport出来ることを確認した

その他

  • 新宿御苑行った
  • マンションの鍵を受け取って試しに開けに行った
  • 忘年会に出た

目標がないならまずは地味なエンジニアを目指してみるのもいいかも?という話

ワカモノは悩んでいるらしい

自分は今年で旧エヴァミサトさんと同い年という感じで若くないせいか、たまに自分より年下の知り合いに会うと、仕事の悩み相談みたいな展開になることが多い。

会社もバックグラウンドも年齢もそれぞれ違う彼らの悩みは多種多様であるように聞こえていたのだが、最近ある共通点に気づいた。「このままじゃいけない」と無意識に思い込んでいる点である。

今以上にスキルをつけなければいけない、成長しなければいけない、ユニークな仕事をしなければならない、など人によって異なるのだが、なぜか「~なければいけない」の思いを持っていた。

そしてもう一つ共通しているのが、その「~なければいけない」の目的が見えないという点である。何となく焦っているのは分かるのだが、その焦って行動した結果によって自分が何を得たいのか。これまで色んな悩み人と会ったが、共通してそれが見えてこなかった。それとなく中長期的な計画を訪ねてみても、明確な答えが帰ってきたことは一度もない(それが分からないから悩んでるんだろうけど)。

とりあえず今を生きるのは精一杯、しかし現状に対して不満や不安を感じている。少し前の自分もこんな感じだったので人のことは言えないのだが、まぁそういう傾向がある人が自分の周りには多かった。

「地味なエンジニア」のススメ

そんな感じなので、悩み相談とはいうものの結局は彼らの職場の愚痴を聞いてやることしか出来てない訳なんだけど、今何かアドバイスするなら、いきなり凄いことをやることを目標にするんじゃなくて、今目の前に積んであるタスクを一生懸命やって、結果を積み上げ続けて信頼されるようになりなさいよ。以上。

…平凡過ぎる、この老害が、ダメエンジニアが、万年草なしgithubアカウントが、と罵りの声が至る所から飛んできそうだけど、決してブログだからといって適当なことを言ってる訳じゃなくて、マジでこれをちゃんと続けられない人が多いんだってばよ。

オッサンに片足突っ込んだ自分がこれまでのキャリアを振り返ると、長く生き残ってて周りから信頼されてる(ここがミソ)エンジニアって、まず目先のことに最大限取り組んで、ちゃんと結果を出して、それを積み上げて今がある人ばかりだった。逆に、消えていった人や、歳だけ取って成果を出せない人はその逆が多かった。

どんなに地味な仕事、例えばwebappのtemplateファイルを1行修正するだけの文言変更とか、デザイナーの代わりに1日中延々とデザイナが作業した修正分をmasterマージし続ける仕事とか、1日中SQL打って本番データを調査するとか、そういう地味な仕事だって誤字も無くつまらないバグもなく確実にこなしてる。で、時々客観的に見てもすごいと思われる重要な仕事しっかりこなして、周りから賞賛される。けど、普段は大体地味で目立たない仕事を嫌な顔せず淡々と続けてる。だから結果的に周りから凄く信頼されている。

そういう「淡々と」頑張るエンジニアがチームを支えているという構図を何度も見てきた。もちろんその人だけがチームを全て支えている訳ではないが、そういう精神的屋台骨的な、困ったときの駆け込み寺みたいなポジションの人が必ずチームにはいたし、エンジニア、非エンジニア問わず信頼されていた。

もし今自分の目標がないならば

別に、すべてのエンジニアが、今自分がいるチームから信頼されるようなエンジニアになりたいと思ってる訳ではないと思う。誰にも真似できない技術を身につけてそれを元に食っていくことが目標だったり、1人で密かにすごいものを作って一発当てることが目標、みたいな人もいると思う。あるいはエンジニアは新卒入社から2~3年で辞める予定で、将来は企画とかプロマネとかコンサルとかにジョブチェンジしたいという人もいると思う。(なお新卒時の自分はSEを経てITコンサルになるつもりだった)

目標は自由であっていい。そりゃ自分の人生なんだから。

けど、もし今、何の目標もなくて何となく焦ってしまっているようであれば、まず自分の目の前に置かれている、退屈かも知れない仕事をこなすことに集中して、それを積み上げていくことに集中してみても、きっと損はないよということを言いたかった。

自分にしても、プログラミング自体ちゃんとやるようになって5~6年だし、未だに大した技術力もアタマもないのにここまでやってこられたのは、目の前のタスクをこなすことにいつも全力で集中してきたからだと自負している。積極的に新しいことを勉強してきた訳じゃないけど、目の前の課題を解決するためにあれこれ模索してきた結果として、それなりにスキルもついてきている。途中、全く悩みがなかった訳ではないけど、目の前のタスクに全力で取り組んで結果を出して今自分がいられる場所を形成し続けることがこれまでの自分の生存戦略だった、とも言えるかも知れない。

2015夏休みの記録

8/24~8/26まで夏休みをもらっていたのでその時の活動記録を記す。

TL;DR

  • 8/24-8/25は一泊二日で平泉・松島へ行って寺見たり景色見たり移動時間は本読んでコード書いてた。
  • 8/26は病院、美容室、MGSV:GZ、艦これなどして過ごす。
  • 旅は普段考えないことを考える時間を強制的に作るための時間。なので正直遠ければどこでもいい。

8月24日(月)

午前

地方都市にありがちなやたらとでかくて平日はガラガラの地域交流センターで電車待ちしてる

着いた

  • 徒歩で中尊寺へ。20分ぐらい上り道を歩く。

平泉仕様のほか弁

  • 中尊寺入り口から本堂や金色堂がある場所までずっと山道を登る。

結構登る

本堂

  • 拝観料800円払って金色堂見た(撮影禁止なので中の写真無し)

金色堂外から

午後

岩手南牛丼的な

松島海岸

Instagram

Instagram

ここで一句

  • 松島海岸沿いの絶景の館にチェックイン。

  • 夕飯は近所に食べに行きたい店がなかったので(海鮮かラーメンぐらいしかなかった)コンビニでパン買ってきて済ませた。

  • ゲーセンも無いし近所に何も娯楽施設はなくて暇なので温泉入って22時頃就寝。

8月25日(火)

  • AM4:00に目が覚めたので散歩に出かける

Instagram

Instagram

Instagram

Instagram

8月25日(火)

  • 朝食は宿で。内容は普通なのにどの品も味が濃すぎて辛い。特にイカの刺し身的何か(塩辛とかそういう類ではなさそうだったが)が最高に塩辛くて食べられたものではなかった。東北だとこれが普通の味付けだろうか?関東人には辛い。
  • 8時過ぎにチェックアウトして松島海岸駅へ。と思ったら次の電車までタイミング悪く50分待ち。松島海岸沿いの公園のベンチでひたすら読書して待ち、仙石線で仙台駅へ。
  • 仙台駅で降りて帰りの新幹線の予約をする。
  • そのあと仙台天文台で開催されていた 宇宙兄弟展に行こうとしたのだが下調べ不足で自爆した
    • 仙台から愛子駅へ行ったが、愛子駅から天文台までのバスが1時間に1、2本しかなく、しかも昼12時台には1本もない。仙山線も1時間に1,2本程度。という状況が悪い方向にコラボして、帰りの新幹線に間に合わないことが移動中のバス内で時刻表を調べていて発覚した。
    • この辺、完全に東京の感覚で予定を立てていて予め調べていなかった自分のミス)
    • 天文台までとりあえず到着したものの、結局時間がなく何もせずに5分でUターンしてまたバスに乗った。地方ではバスの時刻まで詳細に把握しておかないといけないということを身をもって体験した。
  • そのままバスで仙台駅へ。牛タンでも食べるかと思ったが駅前はめちゃくちゃ混んでてどこも入れず、疲れていてあまり歩きたくないメンタルになっていたこともあって松屋で済ます。
  • その後適当にアーケードをぶらついたりして時間潰して東京行きの新幹線へ乗車。
  • 宇都宮駅 - 東武宇都宮駅 - 栃木駅と行きと逆のルートで帰宅。

8月26日(水)

  • 朝から市内の病院へ。過敏性腸症候群らしい症状が2週間近く治らない旨を説明すると、原因は良く分からんが通常の食事が出来ているならすぐ死ぬことはないだろうし今の段階だと原因分からんからとりあえず整腸剤飲んどけという感じだった。
  • その後予約していた美容室で髪を切る。最近のweb業界の動向やテレビ視聴スタイルの変化などについて美容師と話した。
  • 帰宅してからは家に引きこもってネット見てたら、MGS5:TPPが9/2発売というのを知り、今更ではあるがsteamでMGS5:GZを購入してやってみた。PCだと操作性に若干難があったのでXBOX360のコントローラーでプレイ。
  • ニコ動で有名な儀式の人のようにはいかず、見つかりまくって途中からめんどくさくなったので無双した。
  • 艦これやったり昼寝したりしてたら夜になった。ダメ人間ぽい。

道中読んだ本

Inspired: 顧客の心を捉える製品の創り方

  • 長い本なので最後まで読み終わらなかったが、9章まで読み終えた。
  • ここまで読んだ限りでは「プロダクトマネージャーの必要性と役割に関する説明」と「プロダクトマネージャーを実際にチームにアサインする方法について」という大きく2つのテーマを扱っていたように思う。
  • 前者は割とどこかで読んだようなHow google worksとかにも書いてある内容だったが、後者は実践的な内容で、特に8章~9章で取り扱っている「チームの中からプロダクトマネージャーを探す方法」は興味深かった。何もエンジニアやデザイナーだけがなるものではなく、バックグラウンドが問題ではなくプロダクトマネージャーとなる人は一定の指向性の傾向が必要で、その傾向を持つのであればバックグラウンド関係なしにプロダクトマネージャーになれる可能性があるという記述のもと、具体的に社内でプロダクトマネージャーを探しだしてアサインして成功された筆者の体験が述べられている。
  • 実際の体験だけあって、実際にプロダクトマネージャーになった人の人間性や普段の仕事での振る舞いが詳細に書かれていて、どういう人がプロダクトマネージャーに向いているのかという具体的イメージを掴める。この辺を読むと実際のプロダクトマネージャー像が見えてくるというか、実際にプロダクトマネージャーを採用したり社内からアサインする時の参考になりそうだと思った。

余談

  • プロダクトマネージャーのアサインという話で言えば、rebuild.fmのepisode98 でもプロダクトマネージャーの話題が取り上げられており、伊藤直也氏がとある2人の実在するプロダクトマネージャーのバックグラウンドについても語っていたりして(40:00~50:00ぐらいの間)、これも普段なかなか聞けないエピソードで非常に面白いので、プロダクトマネージャーに興味がある人は聞いてみると良いと思う。
    • 因みにその2人とも自分は知っている人なので聞いていてニヨニヨしたw
    • ところでepisode98はrebuild.fmの最近のエピソードの中でも一つのテーマをかなり深堀していて、かつそれが机上の空論的な議論ではなく宮川氏と伊藤氏の2人の実際の経験に基づく話が多くて非常に勉強になるし面白い回だったと思う。アニメとかゲームとかapple製品の話も良いのだが、自分は仕事でこういう話を聞ける機会が皆無なのでどんどんこういう話を聞いていきたい。

恋は雨上がりのように

  • 電車で移動中に2chまとめサイトをダラダラ読んでいたらこの作品の広告が目に入ったので移動中にkindle版購入してダウンロードして読んでみた(今更だけど、どんな山奥でもネットさえ繋がっていればすぐにエンターテイメントが手に入る今の世の中ってすごい)
  • 内容的には17歳の素直クール女子高生がバイト先のファミレスの店長である45歳の冴えないオッサンに何故か惚れるという、どっかで色々使いまわされた感のある超わかりやすいネタをモチーフにした話
  • 作中ではなぜ45歳のオッサンに惚れたのか一切描かれていないのに何故か「好き好き」言っていて素直クール女子高生に感情移入しにくい(ワシがオッサンだから?)という難点はあるものの、ラブコメ系少女漫画でよくある台詞ではなく登場人物の表情や仕草だけのコマを多く入れることで非言語的に物語を描画するシーンが多く、この辺の演出のレベルは高いと思った。
  • 普段は無愛想な女子高生、というキャラだからこそ言葉で語らせるより、思わず出てしまう表情や仕草でオッサンへの愛情を表現したりするのがよい感じにマッチしている、ということなのかもしれない。
  • 絵は若干癖があるので人を選ぶかも知れないが、まぁ少女漫画だとよくある絵柄だし、萌系に慣れきってブヒブヒいうのが至高の楽しみという人でもなければ大丈夫なんじゃないだろうか。amazonのレビューも1巻、2巻ともに☆4、5の評価が過半数なので悪くないのではないだろうか。

道中書いていたコード

  • https://github.com/serihiro/gulp-learning
  • ひたすらgulp,browserifyの勉強をしていて、手元で色々と試すためだけにコードを書いていただけなので成果物はほとんど無い。
  • 本当は今の仕事で使っている gulp + webpack + bower + coffeescriptの構成を実現するためにwebpackについても調べたかったけどそこまで時間がなかったので今後学習を進めたい。
  • gulp, browserifyのdocや関連するエントリーを延々読んでいた。この辺は後で別エントリーとしてまとめておきたい。

総評

  • 仕事を忘れるために久々に1人で遠出したが、まぁそれなりにリフレッシュできたのではないかと思う