Kikuchy's Second Memory

技術のこととか、技術以外のこととか、思ったことを書き留めています。

なんだかんだ激動の年だった2018年の振り返り

あけましておめでとうございます。
書き終わる前に年が明けてしまいました。

IMGP4798

2018年はあなたにとってどのような年だったでしょうか。
私にとっては、なんだか色んなことがあって、あっという間の1年だった気がします。
本当に激動の年でした。

発表とか

今までSlideShareを使っていたのですが、Google Slidesで作ったPDFがアップロードできなくなってしまっていたので使うのを止めました。
SlideShareを使っていたのはスマホ用のUIがあって見やすいから、というだけの理由なので、最近SpeakerDeckもスマホから見やすくなったし2019年からはSpeakerDeckにしようと思います。

ということで2018年はGoogle Slidesで散らばしたままでした。

docs.google.com
docs.google.com
docs.google.com
docs.google.com
docs.google.com
docs.google.com
docs.google.com
docs.google.com

海外

なんと2018年はGoogle I/O 2018に参加させていただきました。
Google I/Oの会場入り口モニュメントで慣れないポーズをとるkikuchy


IOであった発表の一つを解説した記事とかも書きました。

medium.com


mixiグループのみなさんと動画レポートを撮っていただいたりしました。
サングラスしながらダウンジャケット着てるのがシュール。(だって日差し強いのに寒いんだもの)

medium.com

プライベートでは台湾行ったりタイ行ったりフィリピン行ったりと、なかなか楽しい旅行ライフを送っています。
体が弱いもので、いつ動けなくなるのかわからない、という不安が強いのです。
そのため、なるべく若い体が動くうちにあちこち行きたいなぁと。アジアが多いのは長時間飛行機に乗ってるのが辛いからです。
国内も行きたい。

執筆

なんと本を書かせていただきました!
Androidアプリ開発をしているひとが自動テストが始めようと思った時に必要な全てがまとまった本、という今までありそうでなかったような本です。
買ってね。Androidエンジニアだったら損しない内容です。

私はJUnit 5をAndroidで使用する話を書かせていただきました。
大変でしたけれども楽しかったです。
Flutterの本の話とかあれば書いてみたいです。お待ちしております。

peaks.cc

👇執筆に到るまでとかの詳しいことは所属会社のブログに書いたのでこちらを見ていただけると。

developer.diverse-inc.com

転職?

所属会社が変わりました。
7月から、株式会社ミクシィではなく、株式会社Diverse社員となりました。
それまではDiverseもミクシィグループでしたが、7月から株式会社IBJ子会社となっております。
事業譲渡です。転職と言って良いのかどうか微妙な気がしています。

元々は株式会社ミクシィに2014年の新卒として入社したので、ミクシィを離れることについては感慨深いものがあります。
ミクシィのエンジニアのみなさまをはじめ、たくさんの方に仲良くしていただいて、お世話になりました。
後ろ向きではないですけれども、離れた理由もそれなりにありまして。

  • 内定当時(2012-2013年ごろ)は、SNS mixiの売り上げが芳しくないため新規事業を立ち上げる力になる人が欲しい、と言われて内定承諾したのに、入社時点(2014年)にはモンスターストライクというゲームがヒットしていて、そもそもやることがあまりなくなっていた
  • Diverseのみなさまには「会社外に情報発信してコミュニティ貢献できるエンジニアになる」という方針を承諾していただいていて、その見返り(?)として会社のエンジニアによる外部発信や採用やらで力になる機会だと思った

今はDiverse社員が私含めて3人もDroidKaigi 2019への登壇が決まったので、それに向けててんやわんやしているところです。
感傷に浸っている時間はなかった。

developer.diverse-inc.com

エンジニアリング

発表資料のタイトルを見ると、どんどんFlutterに偏って行っているのがわかりますね。
今はFlutterやってます。今までiOS/Android両方やってきていて、どちらの知識も活きるので楽しいです。

新しい言語やフレームワーク、仮想DOM的なUIの差分更新だとかの(Reactをやったことなかった人間からすると)新しいパラダイムを学べるのが技術的に楽しいですし、
少人数チームだと人手が足らないので、ワンソースで複数プラットフォームのアプリが出来上がるのがビジネス的には嬉しい。

今のチームとビジネスとしては丁度良いものですし、アメリカとかと比べると開発人員の数が少ない傾向にある日本のWeb系では今後流行っていくのでは、という読みもあって、もうしばらくはFlutterしていこうかなと思います。

個人ではC++触って機能のプリミティブさに今までぬるま湯で育ってきたことを実感し、go触ってgroutineやっぱり便利だしgo getコマンドやっぱり便利だよなぁとぬるま湯に戻ったりしていました。
なぜかWindowsのアプリを作る機会が多いのにMacのまま頑張り続けています。

qiita.com

SurfaceBookか何か買った方が良いかな…でも今のMacBookAirはまだ使えるしなぁ…
まだ手が空かないので、もうしばらく個人のお仕事は受け付けない予定です。

プライベート

あちこちで言いふらしてはいるのですが、事情があって実家を出ることができず、通勤に片道1.5時間かかっています。
事情については時限式なのであと1年ともう少しはこの生活が続くのですが、それまで心が折れないように頑張りたいです。応援してください。

この後の方針

「他人の恋愛に首を突っ込むのが好き」というひねた理由ですがマッチングの業界は好きなので、まだしばらくマッチングサービスの業界にいようかなと思います。

現在の会社内ではかなり外部で発表だとかをしてきた方なので、今している技術広報的なことをもっと推し進めて行きたいところです。

技術的には、今のFlutter化改修とその後のグロースがひと段落するまではFlutterのスペシャリスト目指そうと思います。
DroidKaigi 2019では "All About Test of Flutter"という題でFlutterでの自動テストの始め方や楽にテストするためのHow toについてお話ししますので、ぜひ聴きにきてください。
よろしくお願いします。

おしまいに

2018年中は大変お世話になりました。
2019年もよろしくお願いいたします。
ご飯とかいきましょう!!

やる気の話

Positive Affirmation


私の観測範囲では、という但し書きが付きますが、エンジニアには早起きが苦手という方が多いようです。
私も朝が弱く、昔から親に「早く寝て早く起きろ」と言われるのですが、早く寝ても遅くまで寝てしまって、決して早起きには至りませんでした。

何かモチベーションの高いイベントが待ち受けていれば確実に早く起きられるのか、と言えばそうでもなく、早起き成功率が40%くらい上がるだけ。
半年に一回楽しみに待っているコミケであっても始発の時間から2時間ほど寝坊する始末です。

今の勤め先も、フレックスタイム制コアタイムが12時となってからは、起床の時間が1〜2時間ばかり遅くなってしまいました。

「やる気が足らない」と親にはよく言われたものですが、起きられないものはどうしようもないのです。

やる気って何でしょう?
やる気って制御できるんでしょうか?

やる気はどこから来るのか

マネジメントやコーチングの用語でよく聞く言葉に「内発的動機付け」と「外発的動機付け」というものがあります。

内発的動機付けとは、「誰にインセンティブを与えられることもなく、自分から『やるぞ』という気持ちになる(やる気がでる)動機付け」のこと、
外発的動機付けとは、「自分以外からインセンティブを与えられて『やるぞ』という気持ちになる(やる気がでる)動機付け」のことだそうです。
外発的動機付けは長く続かない上にパフォーマンス劣化を招くので、コーチングによって相手自身にやりたい事を気づかせ、内発的動機付けを促すべし。
というのがよく言われるやつです。

どうやら質は違うようですが、どちらもやる気を生み出す素のようです。

え、外発的動機付けが本当にやる気を生み出すのかって?

一緒に仕事してる仲の良い上司から
「この仕事終わったら一食10万のディナーをご馳走するよ」
とか言われたら一瞬でもやる気出ません?

やる気は制御できるか

「ある程度はできるが、ある程度以上はできない」のではないでしょうか。

内発的動機付け由来のやる気の制御

内発的動機付けについては、動機の原因が個人の内部状態(神経やら内臓やらの状態)に依存します。
神経(つまりは自分の意思)によってやる気を生み出している部分は大きいですが、人間が生物である以上は環境に左右される部分があります。
冬の朝寒い時期に、ぬくぬくポカポカの布団からなかなか出られないように、生物には快適な状態(コンフォートゾーン)から抜け出しにくい性質があります。

もし意思の力がコンフォートゾーンを抜け出すのに十分であれば行動を起こせますが、意思の力もコンフォートゾーンの引力も一定ではないので、場合によることが多そうです。
なぜ一定ではないか、というと、状況によって変わるからです。
いくら仕事が楽しかろうと寒い日は布団から出られなくなる人も、夏の蒸し暑い日にいつまでも布団に潜っていたいかと言えばそうでもないでしょう。
また、布団が恋しい環境であっても、この機会を逃したら二度と手に入らないものがあれば、早起きして買い物に行くかもしれません。


「内発的動機付け由来のやる気の制御=内部状態の制御+外部環境の制御」となり、「外部環境より内部状態の方が比較的制御が容易なため、多少は制御可能」となるかと思います。

外発的動機付け由来のやる気の制御

外発的動機付けについては、動機の原因がほぼ全て自己の埒外、つまり外部環境に依存しています。
外部環境には多少の干渉はできるでしょうが、思い通りにするのは相当な苦労を要するはずです。
例えば仕事内容を変えずに年俸500万から1億になったらやる気は上がりそうです。
しかし給与交渉そのものはできても、いきなり年俸1億にするのはとてもハードルが高そうですよね。

という訳で、「外発的動機付け由来のやる気の制御=外部環境の制御」となり、「外部環境の制御の困難さ=やる気制御の困難さ」「外部環境の制御は困難なので、やる気の制御も困難」となります。



どうしたらいいのやら

内発的動機付けによるやる気は、内部状態であるため一定のコントロールができる可能性があります。
また、外発的動機付けによるやる気も、環境に働きかけることで改善する可能性があります。

仕事に楽しむ理由を見つけたり、自分へのご褒美を与えてみたり、同僚に「褒めて!」とお願いしてみるなり、給与交渉をしてみるなり…

たた、どちらにしたって完璧なコントロールは無理でしょう。
人生は大概思う通りにはならないので…

やる気を出そうと考えすぎない、やる気が湧かなくても仕方ないと思う、というのが良いのではないでしょうか。

エンジニアを取り巻く業界の未来予想

DSC_0154.jpg

エンジニアマネージャーに関する話題や技術広報に関する話題を、よく聞くようになりました。
多分、これからは「エンジニア自身」の需要より、「エンジニアをあれこれできる人」の需要が高くなるのかなぁ、なんて思ったりします。

これまで

(IT系の)エンジニアという職の理解がまだ浅かったからか、エンジニアそのものが希少であったからか、エンジニアを名乗る人全員の価値が高い時期だったのかなと思います。
製品のライフサイクルモデルによれば、ライフサイクルは次の順を辿るといいます。

  1. 導入期
  2. 成長期
  3. 発展期
  4. 衰退期

導入が終わって、成長期が少し落ち着いた頃が今、という気がします。

これから

真に必要とされているのは、(ビジネスの要件にもよりますが)「ビジネス上の要求をよく汲み取り、技術的見地から適切に要求を実現する方法を考え出し、高速かつ安価に成果物を生産し、その成果物が長期にわたって価値を生産し続けるようなものを作り出せる」エンジニアであると広く認知されるようになりました。
いわゆる「優秀なエンジニア」というやつでしょうか。

よく言う「エンジニアが足りない」というのは、「事業が必要とする水準で上記の条件に該当するエンジニアが足りない」ということでしょう。

すると、それに該当するエンジニアというのはかなり数が少なくなります。
今やソフトウェア開発は事業を動かす上で必須なのに、それを開発できないとなると問題です。
また、せっかく要求水準を満たすスペックのエンジニアを雇ったとしても、すぐに愛想をつかされて逃げられてしまってはたまったものではありません。

そこで需要が出て来るのが、エンジニアマネージャーと技術広報だと思うわけです。

エンジニアマネージャー

世はエンジニア大争奪時代。
条件や労働環境、人間関係、チームや会社のビジョンなどが自分の欲するものと合致しなければ、エンジニアはほかの良いところにすぐ移動してしまいます。

採用はタダではできません。
採用したのにすぐ他に行かれてしまっては、採用にかけた金銭的時間的人的コストが無駄になってしまいます。

それに、当該エンジニアが果たしていた役割の穴埋めだって容易ではないでしょう。
特に長くいるエンジニアであれば尚更です。
単にポストに穴が空くだけでなく、事業ドメインに関する暗黙的知識や人間関係における役割も欠ける事になります。
その人が居なくなることで、ほかのエンジニアがジワジワとやる気をなくしていくことだってあり得ます。

そこでエンジニアマネージャーが価値を発揮します。

(私が考えるエンジニアマネージャー像ですが)エンジニアマネージャーは、組織のエンジニアのタスクマネージングのみならず、メンタルケア的な役割を果たします。
また、エンジニアが今後どうなっていきたいのかなどの欲求を掘り起こし(あるいはエンジニア自身が気づいていなかった欲求に気付かせ)、それを叶えるために組織内でできることをします。

これらの活動によって、エンジニアの離脱可能性を低減する。これがエンジニアマネージャーの役割ではないでしょうか。

せっかく雇ったエンジニアを逃さないための役割ですし、プログラミングよりもエンジニアマネージングの方が難しいでしょうから、自然とその価値は高くなると思います。


技術広報

さて、そもそもエンジニアをどう雇いましょう?

エンジニア的に何も魅力が無いところに、エンジニアが突然求職してきたりはしません。
すると必然、エンジニアを雇うためには、エンジニアに向けた魅力の発信が必要になります。

(私が考える技術広報の理想像ですが)技術広報は、事業や会社のミッションの宣伝、労働環境や条件のアピールなどをエンジニア市場に特化して行います。
そうした採用広報の役割だけでなく、組織内のエンジニアの様子を外から見えるようにすることで、採用対象に組織にジョインしてもらった後のことをイメージしてもらったり、自己成長に有効な環境であることなどをアピールしたりします。

こうした活動によって、優秀なエンジニアの採用可能性を高める。そうしたことをするのが技術広報ではないでしょうか。

雇いたいと思えるエンジニアを引きつけることができ、またそうそう上手くできることでもないですから、その価値も高くなるのではないでしょうか。

その他

他にも需要が高まりそう(≒市場価値高そうで儲かりそう)なエンジニア関連の仕事があるのかなと。

  • まだ優秀でないエンジニアを優秀なエンジニアに育てる仕事
    • 現在はCTO業がこの役割を担っている気がする
    • CTOは技術的な目線で経営をするのが仕事なはずなので、教育については専門職化するのかも?
  • 専門外の人に専門職の仕事を啓蒙する仕事
    • エンジニア限らずデザイナーとかマーケターとか、場合によってはバックオフィス系とか
    • アジャイルなチームは誰がどのタスクをこなしても良いはずなので、エンジニアでない人が画面レイアウト組んだりコード書いたりしてもよい
    • それを促すためには相互に仕事内容や用いる考え方やテクニックなどを理解してもらう必要があるはずなので、それを促す
    • 今はスクラムマスターの仕事かもしれないけど専門職化するかもしれない?

「この世は(時間を)奪ったもの勝ち」という状況は変えられるのか

人間という生き物は失うことについて敏感らしいです。
なんでも、「今10ドル失うが将来に25ドル手に入る選択肢よりも、今5ドル手に入る選択肢を選ぶ」ことが多いのだとか。
総合的には前者のほうが得なのですが、本能的に失うことを回避しようとするもののようです。


ところで、人間には時間という、非可逆な財産があります。
時間というのは便利なもので、将来的な自分への投資(勉強)や、他者へ提供することでお金に変える(労働賃金など)ことができるという性質を持っています。


時間は財産であり、他者から奪うこともできるのです。
例えば仕事を他人に押し付ければ、他人の時間を消費させて自分の時間を浮かせることができるわけです。
押し付けられた側にとって仕事から得られるお金が大きな価値を持つのならば、それは「仕事を巻き取ってもらった」ということになるので奪ったことにならないかもしれません。
が、押し付けられた側が、お金より時間に価値を感じていたら、もしくは押し付けられた仕事が何も産まないとしたらどうでしょう。
あるいは、押し付けられたものが仕事ではなくただの苦痛であったら?
価値が釣り合わないのですから、これは略奪、もしくは搾取です。


ところが奪われた時間を取り返すことはできません。
時間には不可逆性があり、何を持ってしても補填することができないのです。
いくらお金を積んだところで、時間は帰ってこないのですから。


(「時間を経過させる」ということは「人の命を削る」ことでもあるので、人間を若返らせる方法が開発されれば、また状況は変わるかもしれませんね! いつになるかはわからないですが)


つまり、奪われれば奪われただけ損が嵩んでいきます。
電気やお金は刑法で財産とされていますが、時間はそうではないので、司法に裁きを求めることもできません。
すると、時間を奪われたことで被った損失は本人にしか補填できないのですから、ますます損は積もっていきます。




この状況、変えられるのでしょうか。
私にはそうそう変えられないように思います。
奪われないようにするにはどうしたら良いのか、という学びを得られて、それだけです。
(または、人から時間を奪う方法の学びかもしれませんね)




奪い返せば良いのかもしれません。
しかしそれは新たな負の連鎖を生みそうでもあります。
それで精神をすり減らすのもまた、避けたい。


できることならこの状況を変えたい。
一体どうすれば、この状況は変えられるのでしょうか。





GPD WinにXubuntuを入れてコーディングする

以前
GPD Winで通勤中にコーディングしたいという記事を書いたのですが、
やっぱりWindows (bash on Ubuntu on Windows)での運用は辛かったのでLinuxに乗り換えることにしました。



何が辛かったのか


satさんが性能比較をしてくださっているとおり、ファイル入出力が遅いのが一番つらいです。

qiita.com


コンソールでvimを使ってスクリプトを書いて…というのがメインだったのですが、
ファイルを開くのも10秒くらい待たされ、保存でも数十秒待たされ、
という感じだったので流石に我慢できなくなって乗り換えを決意しました。

どのLinuxディストリビューションを使おうか

GDP Winは非力なUMPCです。
でもサクサク動いて欲しい。

開発のために色々とプログラムを動かすため、OSなど常駐プログラムがたくさんメモリを食ったりするのは許せません。

そこで、ウィンドウマネージャにXfceを使えばまあ軽量だろう、という安直な考えで、まずはXubuntuを導入することにしました。

じつはその前にManjaro Linuxという、Arch Linuxベースのディストリを導入しようとしたのですが、どうしてもWifiが繋がらずにあきらめてしまいました。
またLinuxの知識がついたり、Debian系で満足できなくなったら、いつかArch系にも挑戦してみたいと思います。
GentooはCPUが非力なのでちょっと…

XubuntuをGPD Winに入れる障壁


GPD Winはそこそこ特殊な端末で、普通にXubuntuを入れようと思っても期待通りに動いてくれません。

  • 画面が横になってしまう
  • Wifiがつながらない
  • 電源ボタンを押しても反応しない

など、いくつかの不具合がコミュニティに報告されています。

その不具合報告をベースに有志の方々がカスタムディストリを作る方法を公開してくださっているので、それを参考にXubuntuをカスタムしました。


カスタム方法はこちらのページを参考にさせていただきました。

[GPD Pocket]GPDPocket向けにUbuntu系ディストリビューションをリビルドできるツール – BOOLEE STREET.net

上記はGPD Pocket向けですが、GPD Winも使用しているWifiモジュールが同じものだったりするので、問題なく使用できています。


当方、母艦はMacなので、まずはXubuntuをインストールした仮想マシンを用意します。
今回はVirtual Boxで作成。

作成した仮想マシン内でrespinしていきます。

$ sudo apt install -y git wget genisoimage bc squashfs-tools xorriso libssl-devel dpkg-dev
$ git clone https://github.com/stockmind/gpd-pocket-ubuntu-respin.git
$ cd gpd-pocket-ubuntu-respin
$ wget (どこか近いところからXubuntu17.04のisoを落としてくる)
$ ./build.sh xubuntu-17.04-desktop-amd64.iso 

仮想マシンだったのもあって時間はかかりました。確か3時間くらい。

あとは適当な方法で出来上がったISOファイルをUSBメモリに焼けば準備完了。

焼きあがったUSBメモリをGPD Winに挿して、Boot MenuをいじってUSBから起動、指示に従ってインストールするだけ!!

今回はWindowsを残さず、全部フォーマットしてLinux向けにパーティショニングをやり直しました。

これで完成。
後はDPIやマウスカーソル速度などを調整して出来上がりです!


出来上がりはこちら。
実機で動いている様子を撮りたかったので画面は見づらいですが、ご勘弁を!

f:id:kikuchy:20171003235513j:plain


IntelliJも動きます。
時々補完の表示が遅いかなと感じる程度で、Kotlinのプログラムもバッチリ書いて動かせます。
問題だったvimもストレスなく動作します。
zshも問題ない速度で補完してくれるので、普段使いにも支障ありません。
これで通勤中もコードを書ける!

さて、何を書こうかな。