業務に感情を持ち込む

よく「業務に感情を持ち込むな」って言うと思うんですけど、最近業務にもどんどん感情持ち込んだ方が良いと思ったので、なぜそう思ったか書く。
ただし負の感情、テメーはダメだ。

なぜそう思ったか

今の会社で仕事している中で、全く感情を入れないような完全に論理的だけで仕事される方が何人かおられるんですけど
その人と一緒に仕事していると周りの人が結構しんどそうにしているのをみて、入れないことって本当に良いことかわからなくなりました。
そしていやむしろ入れた方が良い仕事できるんじゃね？笑ってる方が良いじゃん。むしろ積極的に入れていくべき。と言う考え方に変わってきました。

仕事しているのは人

やっぱり人間なので、全く感情もなしに良い仕事することってできないと思うんですよ。
ただコード書くだけでも、淡々とコード書くよりも気分乗せて書いた方が進みは良いと思うし、音楽とか聞いて集中しやすくするのも感情入れてるのだと思います。
疲れているときに良い考えが浮かばないのも、気分が落ち込んでいるときに良い仕事できないのも感情が入っていることで問題になるのかもしれないですが、
このときに感情を排除して仕事するよりちゃんと休んでから仕事に戻る方が良い判断だと思います。

人と仕事している

一人で仕事しているならともかく隣や周りに人がいるわけで、無表情で話すより笑いながら話した方が相手も身構えないしリラックスできるんじゃないかと思います。
好意で仕事を決めるのはダメですが、チームでも雰囲気とかあるわけで
良い雰囲気を作るためにも良い感情を積極的に入れていった方が良いと思います。

感情を入れてはいけないタイミング

判断する時

仕事中にはどんどん感情を入れていくべきだと思うのですが、何か物事を判断するときは良い感情でも悪い感情でも入れてはいけないです。
ここは完全に計測した数字や説明できる内容で決めるべきです。
判断に感情を入れてしまうと、よくないものに対して「この人の意見が良いと思うから」「いや頑張ってたから」という理由だけで決めてしまって
誰も得しない結果になってしまうのが見えています。

負の感情を持っているとき

そもそも負の感情は絶対に入れてはダメで、チームの雰囲気悪くするわ心身ともに疲れるわで良いことは全くないです。
強いて言えば、やってはいけないことをやっている人に対して、怒りの感情を少しだけ込めるか無感情で怒るかだと前者の方が良いかなと思うくらいです。
また、自分が負の感情を持っているときに無理やりポジティブに感情入れて仕事しようとするのも良くないです。そういう時はちゃんと休む。
あと、これは自然なのか機嫌悪いのか判断つかないんですけど、舌打ちと貧乏ゆすりする人はマジでやめてほしい。
やっている人には誰も近づかなくなるし雰囲気悪くなるしで良いことない。
「気持ちを整えるためです」なんていうならそのやり方を変えた方が良い。

まとめ

どんどん感情入れてやっていこう。
そして良い感情を入れて良い成果をあげましょう。

"なぜなぜ分析"は炎上が落ち着いてから実施しよう

炎上してる時って、何もかもうまく進まないですよね。そもそも炎上させるなって話なんですけど
まあやってしまったものはしょうがない訳で、炎上した時はまず炎上を収めるために愚直に動くのが一番良いと思っています。

その時にやってしまった失敗に対して、その失敗は次回同じ失敗をしないように原因を洗い出す必要はもちろんあるんですけど
その原因を洗い出す時にやるなぜなぜ分析を炎上中にやるのはやめておこうという話です。

炎上中になぜなぜ分析してはいけない理由

余裕がない

炎上中は余裕がありません。次から次へとタスクが降ってくる状態です。
そんな状態でなぜなぜ分析をやっても、正しい分析はできません。当事者はその時間を次の作業にあてたいと考えます。
ただでさえ毎日遅いのに、これでさらに遅くなることで良い思いする人はいません。
同じ作業をする時も、なぜなぜ分析するより失敗を繰り返さないようにするだけが精一杯だと思います。

受け入れられない

炎上中は余裕がありません。気持ち的にも辛い時期です。
その状態で失敗したとなると、さらに余裕は無くなります。
だいたい泣きそうになってます（主観）
その状態でのなぜなぜ分析はたとえ感情が入っていなくても、責められるように感じてしまいます。
結局落ち着いていない状態でやることになっちゃうので、上手に洗い出しはできない、
なぜなぜ分析の結果を受け入れることも難しいです。

炎上が落ち着いたら分析をしよう

炎上が落ち着いて、チームが上手く回るようになったタイミングで
なぜなぜ分析をしましょう。
その分析は必ず次回に活かせるし、それが成長することになります。
なので、なぜなぜ分析をしないのもNGです。せっかくやらかした失敗なんだから活かさないともったいない。

ちなみに、なぜなぜ分析をする際に感情を持ち込むのはどうなのかという話がありますが、
私は怒り以外の感情は持ち込んだ方が良いと思っています。
その失敗が個人のミスだったのか、キャパオーバーだったのか、防げない事故だったのかで
当人の受け入れ方も変わりますし、防げない事故で怒られても理不尽なだけです。
全く感情を入れずになぜなぜ分析をすると逆に怖いという印象を与えてしまう可能性があるので、
それはそれで受け入れられなくなると思います。

まとめ

分析は絶対に必要ですが、やるタイミングは見極めましょう。

関西Node学園を立ち上げました。

4月20日にさくらインターネットさんのイベントスペースをお借りし、関西Node学園を開催しました。 開催に至った経緯と、立ち上げについて書きました。

Nodeの勉強会を関西でやりたい

当方関西住まいであることから、ずっと関西の勉強会を充実させたいと考えていました。
その中でも、普段から業務で使用しているNodeの勉強会を社内でやりたいという話は何度かやっていて、どこかで機会があればと思っていました。
特に知見共有をする機会がないので、一口にNodeといっても

• ECMAやらTypeやらFlowなど何で書くか
• ReactやらVueやらAngularなど何を使うか

などなど話を聞きたくなるようなことが多くあると思っていて、交流する場が欲しいと思っていました。

東京とその他の格差

以前より、勉強会はまだまだ東京一極集中で、それ自体は人が多いから仕方ないとは思っていて
でもやっぱり関西でも同じように勉強会をやって格差を減らしたいと思っています。
一言で言うと「関西のエンジニア業界を盛り上げたい」です。

企画開始するまで

2月にfreeeの方にお会いした時にNodeの勉強会をやりたいんですよね〜と軽い感じで話をしたら、関西にいるNode学園祭の実行委員の方を紹介できるとのことだったので
勢いで紹介してもらい、言い出したからには一回は必ず実現させたいと息込んで、同僚も巻き込んで開催することを決めました。

Nodeの勉強会なら知名度や参加率上げるためにもNode学園を冠したいと思ったので、古川さんにも確認を取っていただいてスタートしました。ほぼ勢いだけで二ヶ月動いて開催まで色々とやってました。

準備

会場は無料で貸していただけるところでさくらインターネットさんに連絡して、新しく始めるなら学園だし4月が良いということで空いているところを抑えていただきました。
同時に、登壇者が全く集まらなかったら企画倒れになりますので事前に登壇できる方を探してお願いして、connpassページを作成して登壇者も合わせて募集開始しました。

あとは、当日の受付や会場設営をどうするかなど考えることはありましたが基本的に宣伝するだけで、
connpassで登壇希望が集まらなかったら改めて声かけして集める想定でしたが、幸いにも登壇したいと声をあげていただけたので
あまり動くことなく開催できそうな感じになりました。

どうだったか

無断キャンセルはあったものの、40人以上ご参加いただいて
登壇者もみんな盛り上げてくれたので、個人主観ですが大盛況で終われたと思います。
登壇者で声かけした方の中には東京から参加していただいた方もいらっしゃって、本当に感謝したいです。
時間がおして予定通りに終われなかったり、東京から参加いただいて満足にお礼を言えなかったのは運営が未熟でドタバタだったからです。ごめんなさい。。
せめて懇親会は予定しておくべきでした。

ただこれなら、次回以降もやっていけそうだと思ったのですでに企画を進めています。尻すぼみにならないよう定期的にやっていって、
Node学園は関西でも参加できるんだぞって認知されたいです！

まとめ

漠然とやりたいなーと考えていても、やっぱりきっかけは大事で
実際きっかけができるまで動くことはなかったですが、動き始めるとすぐで
そのきっかけがあれば深く考えるよりもまず行動するのが一番良いと思います。
許可を求めるな謝罪せよってやつですね。迷惑かかるようなことはダメだと思いますがそこをちゃんとケアすればどんどんやっちゃうべき。
ただし絶対に一人ではできないと思います。特に登壇者探すときは自分一人のネットワークだと限界があるし、当日も一人では回らないので一緒にやってくれる人は絶対必要です。

あとこれは会場でも話させていただいたんですけど、関西Node学園とした件について
これから関西いろんなところでNode学園やっていきたいと思います。私も京都で仕事していることもあって
大阪にしてしまうと毎回大阪になるのも辛いし、京都でもNode学園やりたいと思っているので
ぜひ（無料で）会場お貸しいただけるところを切望しております！

言いたいことはそれくらいです。関西だってやれるんだ目指すは東京レベルの盛り上がりだということで
改めてみなさんお疲れ様でした！次回もよろしくお願いいたします！知見共有しましょう！登壇してね！！

マネジメントを言語化する

最近、お仕事の比率でマネジメントすることが増えてきた。自分はマネジメントについて人より優れているとは思っていないけど、見ていてこれはもうまずいと思うところで口出ししてきた結果フォローに入ることになるケースが多い。
そこで、マネジメントできてない人はどうしているのか、できる人とできない人の違いはなんなのか、自分はどうしているかを考えることが比例して増えてきて、これはブログに書けるんじゃないかと思うので書いてみる。
ちなみに先日あった情報処理技術者試験のプロジェクトマネージャとは特に関係なかったりする。たまたまタイミング被っただけです。

マネジメントとは

ejje.weblio.jp

経営，管理，支配

マネジメントは特殊な能力か

例えば、マネジメントはプロスポーツ選手のような一部の人にしか仕事にすることができない作業なのだろうかというと、そういうものではない。資格は必要なく、やろうとすることは誰にでもできる。
ただしマネジメントスキルは存在し、このスキルは身に付けることができると思う。
つまり、マネジメントスキルは特殊ではないが、ちゃんと身に付ける必要があると言える。

間違ったマネジメント

この時、マネジメントスキルをつけていない人がマネジメントポジションにつくとどうなるか、容易に想像がつくと思う。
だいたい失敗する。もしくはデスマーチ化する。
こういう人でも上手く行く場合はだいたいチームメンバーに優秀な人がいる。つまりそのマネージャーの功績ではない。
以下は、プロジェクト進行時に私がよく見るマネジメントスキルをつけていないと思う例である。

カレンダー見るだけの人

プロジェクトを進めている中で、各メンバーのタスクを確認し、そのタスクがスケジュール通りに進んでいるか確認するだけのマネージャー。
これがなぜ間違いかというと、時間を管理することはできないからである。
つまり、マネージャーがスケジュールを見たところで、現状を何も変えられないのである。
仮にスケジュールに遅れが出た場合にマネージャーのやることは、遅れた原因を調査し、その問題を取り除くことである。
ただスケジュールを延ばすだけでは、また同じように遅れるだけである。

依頼と丸投げを間違えている人

プロジェクトメンバーにタスクをお願いするが、完了報告を受けたものや出てきたものについて全く確認をしないマネージャー。
チームメンバーからの「できました」報告を受けていたものが、実はできていなかったことというのは往往にしてある。
チームメンバーの責任でもあるのだが、マネージャーは報告を受けたものに対して確認をしないといけない。
これはエンジニアの作ったものに対してマーケターが管理している際によく見られる。成果物に対して責任を持つのはプロジェクトマネージャーの役割である。

自分のマネジメントのやり方

じゃあ、マネジメントはどうやれば良いのか。

自分が意識していることは下記の二点である。

• まず、何をマネジメントする必要があるのか、マネジメント対象を認識する。
• そうして、どうなればマネジメントしなくて良い状態にまでなるのか、ゴールを見極める。

マネジメントとは「管理」である。じゃあ、「何を」管理するのかを把握する。
プロジェクトだと、そのプロジェクトが達成するために何をしないといけないかを洗い出し、洗い出したタスクについて各メンバーに渡せるレベルにまで分解した上でそれぞれ時間を計画する。
自分が管理するのはそのタスクだと考える。

それでもできないという人へ

マネジメントが苦手という人もいると思う。その時に考えて欲しいのが、ほとんどの人が「体調管理」というマネジメントを普段からしていることである。
今元気かどうか判断する、疲れていると感じたら早めに寝るなど、得手不得手はあるかもしれないが生きている以上はマネジメントできているのである。
また、上記とは違った自分なりの体調管理法を持っているはずで、それは自身のマネジメントの練習の成果なのだと思う。
つまり、誰にだってマネジメントはできるはずだと思う。

最後に

だいぶ雑に書いた感があるし、言いたいことの半分も言えていないような気がするが、上手く伝われば幸いです。

WebRTCを使ってニコ○コ生放送みたいなiOSアプリを作る

はじめに

タイトルは釣りです。多分もう古くて今動画配信といえばInstagramとかTikTokとかライブフリマとかだと思うんですけど
おっさんなので許してください。

概要

WebRTCという技術を知って、今なら無料のサービスだけでこういうの作れるよなとずっと考えていて
去年11月にあのサービスもWebRTC技術を使うことを発表したこともあって、先にやってみました。

パフォーマンスを下げないためのリモートワーク

これを書いているのは今日の日中である。なぜ日中にこんなもの書いている暇があるかというと、体調不良で欠勤しているからである。ちゃんと休めよという指摘を受ける前に、今回体調不良になって思ったことをまとめておく。

先週末に人の集まる場所に行ったからか、月曜日から風邪をひいてしまった。ピークは月曜日でこの日は半休とらないときついレベルで体調が悪く、薬を飲んでゆっくり寝ていた。火曜日からは仕事できるくらいまで回復はしたんだけど、月曜にはなかった喉をやられてしまった。
これの厄介なところは自分では働けるレベルまで回復してるつもりだけどとても辛そうに見えることと、ミーティングに参加できなくなることだ。水曜にあったミーティングでは参加したけど話すことができず、聴講者にしかなれなかった。電話がかかって来てもまともに話せなくて、この日も早退した。

問題は今日である。朝起きた時点では出社できると思っていた。実際に通勤のために駅まで歩いていた。最寄り駅まで歩いて15分である。しかし、歩いている途中で咳き込む自分を見て、考え直すことにした。

• 咳き込むことで周りに不快な思いをさせるんじゃないか
• （環境的な意味で）会社の空気が悪いので、喉だけ酷くなるのではないか
• 今日風強いしこれ出社させる気ないんじゃないか

結局途中で引き返し、欠勤連絡をして寝ることにした。けど、今寝れていないのでこれを書いている。 ここで考えたのは、今日家なら仕事できたんではないかということである。うちはまだリモートワークの環境が整っていないので、リモートで仕事することはできない。

今回仕事を休むことになったのは、自分が出勤することでチームのパフォーマンスを下げると思ったからである。裏を返せば、チームのパフォーマンスを下げなければ仕事はできるわけで、その課題はリモートワークという選択肢で比較的簡単に解決できるのではと思ったことが今回このブログを書くきっかけである。
もちろん、体調が悪いのであれば素直に休めよという意見もごもっともである。ただ、単に体調が悪いと言っても1か0かで語れるものではないし、単に有給を消化するのも面白くない。常に元気100%で働けるもんでもないし、今回の件も自分で働けると判断したので、選択肢があれば働いていたと思う。パフォーマンスを下げないために、環境を整えることは大事だと思うし、その選択肢にリモートを加えることはありではないかと思った。前々から、リモートは賛成ではあったが、今回の件でさらに推進していきたいと考えている。

「それリモートワーク導入じゃないと解決できないの？」というご意見のために、他の解決策も考える。

咳き込むことで周りに不快な思いをさせるんじゃないか

これは自意識だけで実際に聞いたわけではないが、自分なら嫌だなと思う。うつることも考えるし、単純にうるさい。咳き込むか咳き込まないかで言えば絶対に咳き込まない方が良い。これの解決策は自分が風邪を治すしかないので、環境でどうにかなるものではないと思う。 なお、周りのパフォーマンスを下げるのは咳き込むだけではない。机を叩くことや貧乏ゆすりも同様である。ついでに書いておきたい。

（環境的な意味で）会社の空気が悪いので、喉だけ酷くなるのではないか

これはリモートワーク以外に、下記の選択肢があると考えている。

1. 会社（の場所）を変える
2. 空気をよくする機材を導入する
3. 会社を変える

1については常に言い続けているが、すぐに変えられるものでもない。
2については導入済み
3については検討するレベルではある。ちなみに今日は空が青くなかった。

今日風強いしこれ出社させる気ないんじゃないか

今日に関しては出社できるもんではなかった。なので今日休んだこと自体は後悔していない。

リモート以外にも解決策はあったが、一番手軽なのはリモート許可ではないだろうかと思う。 ちなみに、リモートにすると真面目に働いているかわからない！と言った意見もあると思うが、出社したところで必ず真面目に働くわけでもないし、監視してれば真面目に働くってどんだけ傲慢やねんとも思うので、この意見は却下させていただく。

だいぶ雑に書いて、あんまりまとまってないけどとりあえず出す。
ブログを毎月書く目標も達成できて、体調不良ながら久々にバリューを出せた気でいよう。

追記

一番書かなければいけないことを書くのを忘れていた。自分はフルリモートにしたいわけではないです。リモートワークにはメリットもデメリットもあると思っていて、一番のデメリットは対面で働けないことですぐに解決できる問題が無駄に時間かかったりとか効率が落ちたりすることがあって、もちろんそれにも解決策はあるんだけど、やっぱりフェイスtoフェイスに勝るものはないと思っているので、一時的なリモート賛成派です。

エンジニア学ぶこと多すぎ問題

最近技術に関わらずいろんなジャンルの本を読んで勉強しているのですが、技術だけでも覚えることいっぱいあるなあと思うことがあるので言語化してブログにしようと思いました。あまりまとまってないけど雑に書きます。

学ぶことが多い

一口にエンジニアと言っても、インフラ・ネットワーク・アプリ・Web・IoTなどなど種類がありますよね。Webサービスを出したいってなったときに多少はインフラの知識が必要だとか、アプリ作るにしてもWebAPIも作らないといけないとかでなかなか一人で全部やることって難しいと思います。
一つのことだけで働き続けるのって可能ではあるけどできることなら多方面に強いエンジニアの方が小回りはきくと思っていて、自分もそっち方面で目指してます。
覚えること多いのって昔からではあると思うんですけど、やっぱり昔より増えてるんじゃないかと思うんですよね。言語とか分野とか。

全てを網羅するエンジニアは少ないと思う

で、全て網羅している人ってほぼいないレベルだと思います。やっぱり、どれだけ賢くてどれだけ優秀でもここちょっと弱いとか、ここまだキャッチアップできてないとか、今勉強中とかってのはあると思ってます。ない人はごめんなさい。私の認識不足です。

エンジニア同士で話すとき、自分の話が相手の知らないことである可能性

簡単なものからその技術に精通していないと知らないような技術まで、自分が知ってて相手が知らないことってほぼ絶対あると思います。例えばエスケープシーケンスは改行しか知らないとか、HTMLの特殊文字で書く必要があるとか。小さいことなんですけどその時どうするかというと、自分が知らないときはすんなり受け入れて覚えようとするんですけど、相手が知らない時にどう反応するかってのは、意識しておかないとまずいなと思うことがあります。

その時どうするか

自分はよく「あ、これ知らないんだ。ふーん」と思ってしまうんですけど、これってちょっとマウント取りが入ってると思うんです。悪くいうと下に見てしまう。これとてもよくないと思っていて、日々直そうと努力中です。
自分自身も知らない時期ってのはあったはずで、それを覚えた経緯とかはもう全く覚えてないですけど、そのときに知ったというのは多少なり嬉しい気持ちはあったと思います。
サービスって大きくしようとすればするほど一人ではできないし、チームで動くのに同じ人が10人いるよりも違う力を持った人が10人いる方が多分捗るし、そのときお互いが知ってること知らないことってのが出来上がるので、そこでドヤ顔して良いこと一つもないなと思うわけです。 勉強会が初参加者を歓迎するのも同じだと思っていて、もしかしたら初めてくるその人は自分の知らないことを知っているかもしれない、教えてくれるかもしれないです。そんな初心を忘れないようにしたいなって話です。

初心を忘れないようにしよう

今年もう一ヶ月終わっちゃいましたけど、初心を忘れないようにするってのも今年の目標の一つです。自分が知ってて相手が知らないことがわかったら「ええやん！」って思うようにしたい。
また、今日同僚に「taminifさんはまだ下回りというか、プロトコルというか、ネットワークの仕組みについて弱いと思う。というのが僕の評価。」って言われたんですけど、こういうこと言ってもらえるのもありがたいと思うし、実際その通りだと思うので、せっかく教えてもらったので低レイヤー層の勉強もしようと思います。 自分の思考を言語化する技術の向上も目標ですね。もっとブログとか書いて磨いていければ。