Kikuchy's Second Memory

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

設計原則に関する英語の語彙を増やしたい

日本語訳される前は何と呼ばれていたのか調べておきたかった。

日本語
単一責任(責務)原則 Single Responsibility Principle
関心の分離 Separation of Concerns
開放・閉鎖(オープン・クローズドの)原則 Open-Closed Principle
拡張に対して開いていなければならない should be open for extension
変更に対して閉じていなければならない should be closed for modification
リスコフの置換原則 Liskov substitution principle
依存性逆転の原則 Dependency inversion principle
インターフェイス分離の原則 Interface segregation principle

他にも増やしたい語彙が見つかったらまた書く。

教養と認識

人間というのは不思議なもので、知っている物事は簡単に認識できても、知らないものはなかなか認識できなかったりします。
知らないもの、というか、意識の外にあるもの、というか。そういうものは簡単には認識できない傾向にあるようです。

例えば私は同僚が髪を切ったとか、そういうことに無頓着だったのでにあまり気づかない人でした(今でも気づかなかったりすることがあります)。

 

人生において色々な物事が自分の脇を通り過ぎていくように思えますが、そのうち認識できているのはどの程度なんだろうか、それを認識できるようになるにはどうしたら良いのだろうか、とふと思ったりするわけです。

 

そういったものを認識するにはそのものを知る必要、もしくは強烈に認知する必要があります。

例えば髪を切ったことに気づくには、「人が髪を切ったことは話題になるし、気付いてもらえると嬉しい」ということをわかっているか、誰かに「あの人、髪を切ったね」と教えてもらうか、とかがそれぞれに該当するかも。

 

かたや、リベラルアーツとか教養の必要性がよくわかられていない、というような話がTwitterでよく見受けられる気もします。

私も大学時代は教養の必要性はわかっておらず、授業のテーマで「なぜ大学や大学院が必要なのか」を考えることになった時に「同等の教育ができるなら専門学校があれば良いのでは」という結論を出したこともありました。

 

今であれば、知らないと気づけないから、予め広い分野において知識を仕入れておくこと、広い世界があるのだと知っておくこと、色々なことに気付けるようになること、それが教養なのだと思います。

 

なので、話の通じない弟には様々な分野の本を読んで欲しい…(奴はラノベしか読まない)

いくら自分に対して思索を深めたところで、自分以外の考え方や世界があることを認めなければ、いつまでも井の中の蛙なのだということをわかって欲しい…

まあ私もまだまだ教養が足りない部類の人間だから、そう言っても行動で示しても伝わらないのかもしれないけれど…

 

自戒を込めて。

エンジニアの育成とマネジメントが難しい(と私は思い込んでしまっている)

年一更新のブログになってしまいそう。

それでは良くないので、思ったことを未整理のままでも書き出してみたりしようかと。

 

職場に新しいエンジニアの方々お二人がいらっしゃって、それぞれのメンターを務めることとなりました。

どちらもお若くて、ほとんど新社会人みたいな感じ。お一方はインドの大学の新卒、もうお一方は高校生インターン。どちらもプログラミングは結構できる方。

 

私は人を育てるということを上手くできた試しもないので、勝手に育ってもらうしかない。

とりあえずどうなりたいのかを聞きつつ、なるべくその要望を叶えられるようにタスクを振ろうと思っているところ。

 

しかし、タスクを振るって言っても、私はタスクマネジメントも苦手なので、そこも上手くできるか自信がない。まずどれだけのことをお任せしても大丈夫なのかわからない。どんな仕事の進め方をしたら楽しんでもらえるのかもわからない。

 

私がガッツリ設計とかモジュールの分け方とか決めて、その後で小さくしたタスク(このクラスをこう作ってとか)をお任せした方が良い?

でもそれだと自由度小さすぎない? 私がそんな振り方されたらマイクロマネジメントだと思う。しかしお二方とも基本的な型というか、「この種のプロジェクトでは、このコードはこう書く」みたいなところまで理解が及んでいるのかわからないし…いやいや、そんなの書いてみてもらってコードレビューするまでわからない。

2〜3年前のペーペーの頃はどう指摘したものかわからなかったけれど、最近の私なら設計原則に関する語彙があるので、理由を説明した上で必要であれば軌道修正ができるかも。

 

そうなると比較的最初から設計の方針を話し合いの上で決めた方が良いのだろうか。

多分そうで、ちゃんと納得の行く進め方をしたいし、そうした方がきっと良い。

 

と、まとまらないまま書き始めてみたら悩みが一つまとまって解決してしまった。

今後も続けていこう。

 

なんだかんだ激動の年だった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億にするのはとてもハードルが高そうですよね。

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



どうしたらいいのやら

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

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

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

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