関西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さんはまだ下回りというか、プロトコルというか、ネットワークの仕組みについて弱いと思う。というのが僕の評価。」って言われたんですけど、こういうこと言ってもらえるのもありがたいと思うし、実際その通りだと思うので、せっかく教えてもらったので低レイヤー層の勉強もしようと思います。 自分の思考を言語化する技術の向上も目標ですね。もっとブログとか書いて磨いていければ。

iOSアプリでSkyWay使うときはBitcodeを含まないようにしよう

はじめに

いつも忘れるのでブログに備忘録として残して置きたいと思います。 iOSアプリでSkyWayのライブラリを入れた場合、Bitcodeを含まないようにしましょう。

TL;DR

TARGETS -> Build Settings -> Enable Bitcode -> No

経緯

CocoapodsでSkyWayのライブラリを入れた後Buildすると、Apple Mach-O Linker (id) Error が出ます。
このエラー自体はあまり情報を含んでいないので好きではないのですが、ログを見ると You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE) と出ます。
SkyWayのライブラリを入れるとBitcodeは含まないようにする必要があるのですが、毎回忘れるのでブログに残して置きます。

まとめ

SkyWayのライブラリとBitcodeはセットで設定するようにしましょう。

SkyWayのSFUを使用したサンプルを作成しました。

はじめに

ソースコード

github.com

概要

WebRTCのSFUを一度使ってみたくて、iOSアプリのリハビリも兼ねてSwiftで書いてみました。
SkyWayのiOSのサンプルはObjective-cで書かれているのと、ダウンロードしただけでは動かないこともあって
すぐ動くものを意識して作ってみました。

SkyWayとは

webrtc.ecl.ntt.com

NTTコミュニケーションズさんが運営する、WebRTCに必要なサーバーを提供してくれるサービスです。
一定の通信量までは無料で使えるのでまず登録して使ってみるのが良いと思います。
WebRTCやる上でサーバーに手を出すとその先は沼らしいのでもしサーバーを自分で立てるなら覚悟を決める必要があります。

SFUとは

WebRTCはP2Pで端末同士を繋ぎますが、それだと接続する端末ごとにコネクション数がどんどん増えていき、端末のCPUの負担が倍々になります。
そのため、最初から多人数を接続するために中継サーバーのようなものを置き、各端末はその中継サーバーにP2Pで接続、中継サーバーは各端末に受診している映像を送信します。
そうすることで受診は端末数分のコネクションが必要ですが、送信は中継サーバー一本で対応できることになります。
その仕組みがSFUです。

実装方法

ライブラリのインストール

Cocoapodsを使用して、SkyWayライブラリをインストールします。

pod 'SkyWay'

peerの接続、ルームの入室

peerを接続し、自身のpeerIDを取得します。

// peer connection
let options: SKWPeerOption = SKWPeerOption.init()
options.key = apiKey
options.domain = domain
options.debug = .DEBUG_LEVEL_ALL_LOGS
peer = SKWPeer.init(options: options)

SFUモードでルームを作成し、ルームに入室します。

// join SFU room
let option = SKWRoomOption.init()
option.mode = .ROOM_MODE_SFU
option.stream = self.localStream
sfuRoom = peer?.joinRoom(withName: roomNamePrefix + roomName, options: option) as? SKWSFURoom

受信した映像を表示します。

sfuRoom?.on(.ROOM_EVENT_STREAM, callback: {obj in
    let mediaStream: SKWMediaStream = obj as! SKWMediaStream

    self.lock.lock()

    // add videos
    self.arrayMediaStreams.add(mediaStream)
    self.collectionView.reloadData()

    self.lock.unlock()
})

今回は、映像の表示のためにCollectionViewを使用しました。

つまづいた点

plistの設定

いつも忘れるのですが、自分の映像を取得するためにはカメラとマイクを使用する必要があります。
SkyWayを使う場合でも例に漏れず、カメラとマイクを使うためにplistに設定が必要です。

<key>NSCameraUsageDescription</key>
<string>Use Camera</string>
<key>NSMicrophoneUsageDescription</key>
<string>Use Microphone</string>

離脱した映像の処理

誰かが退室した場合、その映像の受信が止まるだけで映像の削除は自分で対応する必要があります。
そうしないと、動かない映像がどんどん溜まることになります。

まとめ

実装期間約2日、時間にして5〜6時間で作成することができました。
どちらかと言うとCollectionViewに時間を取られたこともあるので、ビデオチャット自体はすぐできると思います。 非常に簡単でWebRTCを深く知らなくても実装できますので、興味ある方はぜひ登録してやってみてください。