大学生の春休みみたいな連休をとったらとても良かった

年明けから会社でストレスフルな状況(構造的な、すぐに解決の難しいタイプの問題に対応する日々)が続き、自分自身があまり良くない状態にあるような気がしました。

そこで土日につなげた3日間の有給休暇を取り、旅行など何か特別なことをするのではなく大学生の春休みのように過ごしてみたところ、思った以上にリセットできたのでメモしておきます。

症状

  • 平日・休日問わず、睡眠時間が増えた
    • 特に昼寝の回数が増えた
    • ほぼ寝ているという週末が4週ほど続いた
  • ギター以外の趣味に興味がなくなった
    • チケットを取ってあったライブが3月に3つあったが、すべて行かなかった
  • ギターを弾くのも、楽しみではなく練習という義務感でやるようになった
    • 思い返してみると「つまらなくなった」のではなく、新しい曲に挑戦せず同じ曲を繰り返し演奏するようになるなど自分からつまらなくしていた
  • 人と会話をするのが億劫になり、飲み会の回数が減った
    • おそらくこれもギターと同じような問題の成り立ち
  • ずっとお腹を下していた

やったこと

  • 数週間くらい前に、そのうち5日間ほど休むということをチームに伝えた
  • 2日間たちの悪い風邪で寝込み休んだ後、逆に少し気分が意欲的になったことに気づき、そのまま休暇を取ることにした
  • 複数のスマホを私用仕事兼用で使っていたが、メインの iPhone 以外はすべて会社に置いてきた(これは偶然)
  • iPhone から、通知を送ってくる種類のアプリをすべて削除した
    • メーラ、Slack、Facebook・Instagram等SNS、出会い系、ソシャゲ
  • 好きなときに起きて好きなときに寝て好きなときに食べた

良かった結果

  • 睡眠時間がどんどん減っていった
    • 昼寝は1回1時間だけになった
  • ギターでは自然と新しい曲に挑戦するようになり、気づいたら自然と演奏しているという時間が増えた
  • 自宅にいる間に会社のことを考えることがほとんど無くなった
  • お腹の調子が良くなった
  • 自分自身でコントロールしてリセットすることが可能だとわかった

変わらなかったこと

  • ライブに行く意欲は特に戻らなかった

悪かった結果

  • 昼夜が逆転した
  • この期間だけで1.5キロ太った

こんなふうに休んだのはおそらく大学を卒業してからは無かったと思いますが、とにかくとても良かったので、今後も1年に1回くらいやりたいと思いました。

どんな北米のビジネス本だって、このタイプの休暇を前提にしているような気がします。独身男性が日本でやると、見栄えは悪いですが、たぶんこうなんです。

ダイエットしないと……。あと今は18:07ですが、このまま寝ないで明日の出勤になるのでやはり大学生並に辛い。

Droxxxxigi 2018 に行ってみたときのメモ

1日目しか行ってないし、セッションも3つしか見てないそうとうしょうもないやつなので伏せ字です……。

でも絶対見たいと厳選してたどり着いた3つは最高だったし、ここに書いておかないとメモもなくしてしまいそうということで、講義メモを貼り付け&プラスアルファしておきます。

Androidで動画コンテンツを扱うTips

Abema の人の動画ストリーミングの話!

speakerdeck.com

  • ストリーミングのメタストラクチャ形式が HLS と MPEG DASH なのかー
    • Fragmented MP4 さん HTTP 操っててかっこいい
  • ExoPlayer はえらい
  • 懐かしの RTMP はやっぱりえらい
    • Flash Communication Server ...
    • Socket はりっぱなしだし
    • ヘッダ極限まで小さいし
    • マジなんだなあ

やっぱりライブ動画だよな!

何が何って Flash Communication Server の遺伝子が現代に受け継がれているのがすごい! 思い出したくないのにいろいろ思い出した!

うんこしたい ※(編集注)セッションとは無関係のメモです。

Kioskアプリと端末の作り方

DeNA でタクベル作ってる人の Android で Kiosk 端末を作ろうぜの話!最高!

docs.google.com

満席!

  • Device Owner Mode
    • まず初期化
    • そのあと NFC か adb
  • 特定の Activity をホームアプリ化できる!
    • ホームアプリって PersistentPreferredActivity なのかー
  • サイレントインストール!?
    • Device Owner すげー
  • DevicePolicyManager っていつ使うんだって思ってました

MediaCodecで動画編集をしてみよう

C Channel で動画まわりをやっている漢の人の、端末上で動画加工したりデコード・エンコードしたりする話!すごい!

speakerdeck.com

  • GPU を使うために Open GLES を使うのか…
    • 3D にしてからエフェクトかけてて大変!
  • 行列演算は MVMatrix がやってくれるよ
  • MediaCodec はやればなんとかなるらしい…
    • OpenGL 力が必要らしい…
  • もちろん Service で実行すること
  • MasayukiSuda さんの GitHub を見れば色々ある!
  • presto!
  • Open GL まわりはやはり特定端末で落ちたりするらしい…

わかった、この人、漢だ……。

思ったこと

  • ストリーミング動画をやりたい
  • Kiosk端末を作りたい
  • 動画加工をやりたい(これは今の仕事でやれそう)

自分、影響を受けやすいのです。

うんこ問題

セッションの合間はトイレが混んでて……てかトイレが少ない……とにかくうんこがしたかったです……。今週ずっと激しくお腹を壊していたので……。場所をもっとちゃんと見極めていきたい……って前にベルサール新宿に行ったときも思ったのに、すっかり忘れてました。自分の責任です。

あと会場のキャパいっぱいくらいなのか、導線がきつかった……。合間合間は複数ルームで開場待ちの行列ができてて厳しかったり。でもこれってライブハウスでもサッカーのスタジアムでもまんま一緒で、キャパいっぱいに入ってしまうと導線が破壊されるというのは、ハコ運営の仕事からしたら仕方ないけど、行く方としたらぼちぼちしんどいですね。

プロセス担当としてやっていること

最近、僕が入ったときは3人だけだったチームに少しずつ人が増えて、最初はお昼ごはんやら、夜飲みながらだとか、そういうところで話した内容が、100%とは言わなくとも新しい人に伝わっていないことがあることに気が付きました。

というわけで、自分がチームのプロセス担当としてやってることってなんの目的なのってあたりをまとめます。特にスクラムの話とかではないですし、よく考えたら4年くらい前と内容ほとんど一緒です。

目的

チームに注目した場合
チームみんなで事業の決定性を高めつつ、それまで見えていなかった問題を個々人が能力を発揮して発見・仮説を立て、チームみんなで検証し、問題を解決する

メンバーに注目した場合
誰でもできることを動的なコミュニケーションによって共有しながらチームで解決し、結果としてその人にしかできないことをやってもらう(そのための努力をみんなでする)

決定性

  • Apple のレビューで揉める要因を発見し、対応する。レビューにかかる日数の偏差を小さくする。いつでも見込んだ日数ですぐリリースできるようにする。
  • 「よーし明日リリースするぞ!」「あ、明日俺健康診断なんすよ」「先に言えよ、健康診断はこれから上長のハンコ3つね」ってならないために、いろんなことに考えを巡らせなくてもスクラムなどのごっこ遊びを通じて細かいズレを潰す。
  • ペアプロとか、仕掛りゼロとか、毎日全部のPR片付けてから解散とか

事業プロセスが決定性を増すことで検証のコストが下がれば、発見と解決が促される。発見の部分では特に個々人がスペシャリティを発揮してほしい。

契約(静的なコミュニケーション)

裏側である契約というプロセスを覗くことでよりはっきりさせたい。

  • 決定性が高まるところまで高まった(要因がすべて明らかになり、コントロール下においた。あとはやり続けるだけ)
  • その領域が事業のコアコンピタンスではなくなった

といった場合に契約が使われる。契約なら、外注したり、子会社化したり、ワンストップでその機能を備えた社内の部署にお願いした方が効率的。

自分の所属するチームには、いまのところ契約がその力を発揮できる領域はない。

例えばいつか Firebase が最強になって、事業責任者が全部管理画面でアプリからなにから全て作れるようになれば、その時の競争力の源が何かによっては、エンジニアは外注でよいかもしれない。

昔は文字を打ち込むだけのパンチャーさんっていたけど今はいないですよねとか、サーバサイド開発の人・インフラの人は、今はそれが競争力の差を生めないので、今のフェーズだといないですよねとかという話。

外注・子会社システムはとても効率的で、大人数を動かせるし、メンバーとしても自分と似た興味や専門の人たちと、毎日同じ領域について考えていればいいので楽だが、外注する側もされる側も、イノベーションを生みにくい。というかイノベーションを求められるべきプロセス形態ではない。昨今の多様性の話の逆。

例えばJIRAは契約システム。契約システムとは、自分と他人の責任領域をはっきりさせること。

Osmotic Communication

小さいチームでイノベイティブであるために、自分と他人の責任領域ははっきりさせない。失敗はチームの失敗。成功はチームの成功。

それを契約ベースでやるのはかなり難しい。近くで揉めたり落ち込んだり喜んだりしているのを見て聴いて話して自ずと感じること。それが Osmotic Communication (浸透的コミュニケーション)。

これを大きいチームでやるのもかなり難しい。6〜7人以上なら、あとはアシスタント(縦にスケールアップ)だよ。あるいは別採算事業だよ。というのはそのこと。デザイン事務所とか、アニメ制作とか、クリエイティブ系ってけっこうそうだったり。

「浸透的に伝えない・伝えられない・伝える意味を感じられないなら、浸透的には言えなくなる(同じチームではなくなる)」これがチーム領域の区切り方で、新しいメンバーは誰かのアシスタントに入ったりする。だけど、だからといって別にドライに付き合う必要はまったくない。

Mac 版の Rocksmith 2014 でマウスとキーボードが微妙におかしい

Steam で買った Rocksmith 2014 でマウス(正確にはトラックパッド)とキーボードが微妙に効かなかったりしてました。

症状

  • マウス・トラックパッドでの左クリック(確定操作)が効かない(カーソルは動くのでメニューやボタンにフォーカスは当たる)。
  • Guitarcade でスペースキー以外のキー入力が効かない。ギターをかき鳴らす以外ゲームを開始できない。 Scale Race などの開始前にキー操作が必要なものは開始自体できない(スペースキーでメニューを出したあとの Exit も確定できず、なぜか終了もできない)

自分の問題がある環境

iMac (Retina 5K, 27-inch, Late 2014)
Niz の 75 キー BT
Magic Trackpad 2
Karabinar Elements を使っている

自分の問題がない環境

MacBook Pro (13-inch, 2017, Four Thunderbolt 3 Ports)
Karabinar Elements を使っていない

フォーラムの解決法

Logitech(ロジクール)製品は全部抜け!それでもだめならドライバを完全アンインストールしろ!
ワコムのペンタブを抜け!

(Mac) Guitarcade not recognizing keyboard inputs :: Rocksmith® 2014 Edition - Remastered General Discussions

Steam のフォーラムが一番くわしいです。この問題、2013年から根本的には解決していないんですね。

俺はロジクール製品もペンタブも持ってねえ!

MacBook で問題ないのに iMac でだめなのがなんの理由かわからなかったので、初期化までして検証しました。

使っている Niz のキーボードはマウスとしても振る舞うのでそれが一番怪しかったのですが、今回は違いました。

キーボードの問題の自分の解決法

  • Rocksmith を起動する前に Karabinar Elements を終了する

でした!

マウスの問題

自宅にある Magic Trackpad 1 と Magic Trackpad 2 では左クリックできませんでした。カーソルは動かせます。純正もロジクールもだめで、果たして動く外付けポインティングデバイスはあるのだろうか…有線マウス?

Firebase Developer Day に行ってきた

Firebase Developer Day - HOME

こちらです。先週の金曜日、12月15日の13時半からでした。渋谷でタクシーが捕まらなくて大変だったなあ。

実は Google さんに初めて行きました。社内に段差のついたセッションルームがあるなんて…。

Firebase Developer Day - AGENDA

セッションは2レーンありました。同僚と2人で伺って、基本的に分かれて見たので、自分の感想は半分です。キーノート的な部分で説明があった通り、 Firebase のサービスはおおよそ

  • アプリをさっと作る
  • アプリをグロースさせる

の2つに分けることができるそうです。自分が見ていたのは後者のグロースさせる方です。

Firebase 最新情報

Developer Advocate の Khanh LeViet さん

2017年の Firebase のアップデートの紹介でした。自分は2017年から Firebase を始めたので、そうか、これはこれまでなかったんだ。というような驚きがありました。

Firebase でユーザーを理解しアプリの成長につなげよう

Developer Program Engineer の Morgan Chen さん

グロース側のサービスをざっと紹介してくれました。 FCM まわりで受信確認ってどうやってるのっていう質問があって、そりゃ届いたら届いただよみたいな空気もあったり計測サイドで求められる可用性とかってちょっと違うよなーと思いました。

Firebase A/B testing のご紹介

Developer Advocate の Laurence Moroney さん

俺達の Laurence Moroney 先生のセッションここから2連続。 Firebase のサービスうんぬんというよりは、 A/B テストというものの概要を、実際に Firebase のコンソールを弄りながら楽しく説明してくれた感じでした。

FirebaseとAdMob

Developer Advocate の Laurence Moroney さん

AdMob with Firebase  |  Firebase

Since AdMob is now a part of Firebase, we've made it simpler to use AdMob along with other Firebase services such as Analytics.

そうだったの!? いつのまに!? ということで AdMob がもともと iOS / Android 向けに持ってるカスタムビューの Android の方を実際に実装しながら、広告商品ごとの使い所を説明いただきました。個人的に普段ほとんど追ってない領域なので、この後の後の LIFULL さんのマーケッターさんのお話とここがめっちゃ勉強になりました。これからやっていく土台になった気がします。

Firebase Predictions で実現する最先端のアプリ運営

Mobile Solutions Consultant の Kyohei Mizutani さん

Predictions のご紹介。とりあえず自分が今作ってるアプリも Predictions が有効に動けるだけの PV を稼ぐぞ、といったところです。

Google Analytics for Firebase を使った Growth Hack

Data Architect の Yuki Yoshino さん
THECOO株式会社の Hayato Hoshikwa さん
株式会社LIFULLの Hayasaki Kenichi さん

最初にグロースサイドの機能の関係をざっと Yoshino さんにご紹介いただき、その後はお二人から実際の利用方法についてご紹介いただきました。

LIFULL さんって、ネクストさんなんですね、 HOME'S の。そのマーケッターの方のお話が楽しかったです。特に何が楽しいって Firebase のマーケティングでの実用例ってことで紹介いただいたけど実際 Google Analytics for Firebase は Google の UAC にしか使っていなくて、他のネットワーク・媒体には Adjust を使っているんですよねー Google さんももっとがんばってくさいねーみたいな感じだったところでした。

いやこれ、そうなんですよね…。自分、 Firebase のサービスほとんど使ってきましたけど、明らかに世界が完結しない領域ってマーケティングだと思いました。がんばってほしいです。

以上、よろしくお願いいたします。

2017年の私とYAGNI

2017年は YAGNI でした。

古い話でいえば Ron Jeffries さんのこれになるわけです。

ronjeffries.com

ここには、

  • 考えがずれちゃってるよ、クラスがどうなるべきじゃなくて、どうなりそうか考えるなんて。集中しろよ
  • コードをいじくりまわしてないで、実際の問題を解決して前に進んでる感覚高めていこうぜ
  • 結局いらないかもよ。いらないとしたら書いた時間、読んだ人の時間、保存してた場所、全部無駄になるぜ

などと書いてあります。

これはこれでエモーショナルないい話なのですが、個人的には大好き Martin Fowler さんが書いた

martinfowler.com

こっちのが好きです。こっちには、要求ではなくて推測で作られたコードのもたらすコストってのが書かれていて

  • Cost of Building (作っても誰も使わないメソッドやクラスと、そのテストと、ドキュメントなんかに使うコスト)
  • Cost of Delay (推測で作ったもののために他が遅れた分のコスト)
  • Cost of Repair (半年後に必要になった時、すでに負債となってしまったコードを修正するコスト)
  • Cost of Carry (結局使われたかもしれないが、それまでの期間使われないコードのために増していた複雑性)

なんてふうにまとめられていて、これらが「推測が外れていた」「推測は当たっていたが、間違った実装をした」「推測は当たっていて、正しい実装をした」という状況ごとに適用されます。推測も実装方法も正しかったとしてもコストはあるよ、というのが一番のポイントです。

しかし、なんでもかんでもめんどくさがってヤグニャればいいかということそんなことはなくて

Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.
YAGNI は、推測された特徴のために作られるソフトウェアの能力に対して適用されるものであり、ソフトェアを変更しやすくする努力については適用されない。

と注意も書いてあります。変更可能性を高めておけば、というか高めておくことで「予め用意しておかなかったコスト」を小さくでき、天秤を効率的な方に傾けることができてビジネス的に正当化されます。わかりやすい。ここまでは復習です。

組織のYAGNI

僕これほんと思ったんですけど、これってチームにも適用されますよね。

僕の尊敬する人事の人が「新しい人は『いい人を見つけたから何かやってほしい』とか『他所と比べて少ない気がするから採っておきたい』ではなくて、帰宅途中にふと『これ以上は工夫のしようがない。もう無理だ』って思ったくらいから探し始めればいいよ」って言ってて、なんだか納得感があって、まあ極端ですけど、これ YAGNI ですね。

つまり、実際の要件ではなく推測した要件にもとづいて採用したメンバーというのは、 Martin Fowler が言う4つのコストをチームに対して持ってしまうわけです。

  • Cost of Building (採用活動にかけたコスト)
  • Cost of Delay (採用活動で遅れた制作のコスト)
  • Cost of Repair (まだ仕事がないのに、半年後に仕事があるからといって採用した人が半年間暇してる間にアル中になってしまったので矯正病院に入れたり、解雇したら裁判沙汰になったときのコスト)
  • Cost of Carry (本当に必要になるまでのお給料、人が増えたことによる意見のばらつき、会議室が取りづらくなるとか、WIP・仕掛りが増えてチームが集中できなくなるとか)

うーん、これは渋い。

ちなみに、チームを修正・変更しやすくする努力は最初からずっとやっていていいということです。コードだと主に自動テスト、継続的デリバリーです。つまり人だと…あんまり考えたくないです。

つまり、変更可能性を担保するためにはコードよりもっとずっとリスク回避志向にならないと駄目だよということですが、リスク志向ではなく、リスク回避志向になった結果、上記のコストが目に入りにくくなってとりあえず採用しておこう、みたいな意思決定をしてしまったりするのですから、リスクやらコストの見積もりってつくづく難しいなあって思います。

見送るにせよ見逃すにせよ、失った(と思い込んだ)ことによるコストと、手にしたものが手にした後に生むコストとリターン、そして推測した要件は必ずずれるということを正しく天秤にかけられる人・場面はそうそうなさそうです。もはやよく寝る、とか幸せでいる、とかが大事なんじゃないかなあ。

Firebase Weekly 第4・5号をまとめました

www.getrevue.co

Firebase Dev Summit 2017 があって Predictions が発表されたりなどしました。

個人的には Puffelen おじさんの

stackoverflow.com

Android 版の Cloud Firestore の listener にはライフサイクル感じてもらえるよ、っていう話がいちばん衝撃でした。 Firestore なんとかして仕事で使って深掘ろうと思いました。

まとめてるたびにたくさん出てくるから、影響されて Google アシスタント開発始めちゃいました。

今週の Firebase Weekly はおやすみです

こちら完全に Firebase Weekly お知らせブログとなっておりますが、身内に不幸がありました関係で今週の Firebase Weekly はおやすみさせていただきます。次号は2週分の内容でお送りする予定です。

Firebase Weekly 第3号をまとめました

www.getrevue.co

週に1度のブログ更新です。 Firebase Weekly 3号をまとめました。個人的には、メルカリさんがメルカリチャンネルで Realtime Database 使ってるよ。ってお話が、これからの自分の仕事の仕方を早めに変えてくれて嬉しいなと思いました。ちょっと説得力が違います。

個人的には、 jQueryRails のときのような……、食器洗い洗浄機のような……、ルンバのような……、そういう種類の、業界だけでなく自分のライフスタイルや考え方への強い変化を感じています。

Firebase Weekly 第2号をまとめました

www.getrevue.co

ちゃんと2号も出しました。 Firestore と DevFest Tokyo のおかげです。

DevFest Tokyo は招待いただいてたのに( Firebase の話が全然ねえ)と思って申し込みすらしなかったんですが、結構トークがあったみたいで…。ないと思った僕は何を見ていたんだろうか。何も見ていなかったんでしょう。

まとめてて思ったことは、みんな iOS かブラウザだなってことです。