リモート勤務で、人の言葉を忘れ始めてしまいました — 九岡 佑介 (mumoshu) インタビュー(後編)

こんにちは id:ymrl です。おととい公開した前編に引き続き、freeeでSREエンジニアとして働く九岡佑介(@mumoshu)さんのインタビューをお楽しみください

mumoshuさんの写真

人の言葉を忘れ始めてしまいました

— ところでmumoshuさんはfreeeでも珍しい、地方からのリモート勤務をされているわけですけど、リモートでのやりづらさはないですか?

最初の数ヶ月は五反田の本社で勤務していたんですけど、いまは完全にリモートで月に1〜2回東京に来る生活をしています。ほとんどの開発メンバーが五反田にいるのでもともと月1回は本社に来るという約束になっていたんですが、いまのところ東京での登壇の予定などがよくあるので、それに合わせて本社に出社しています。

freeeメンバーとのやり取りほとんどがWorkplace上でやっていて、ずっとオンラインでやりとりしてきた人とこのあいだのオフサイト(社員合宿)で初めて会って、顔と名前がようやく一致するなんていうこともありました。やりとりは非同期的なテキストコミュニケーションが多いんですが、自分はついミーティング中に仕事しちゃうタイプなので、都合のいいときに非同期に話が来る状態のほうがやりやすいです。基本的にコミュ障なんだと思うんですよね。

自分みたいなタイプはマネージメントする立場からはやりづらいと思うんですけど、それでもチームの理解があることと、自分がこっちのほうが向いているなと思えること、そして人から指示されて動くような内容の仕事ではないというのが、リモートで仕事ができている理由のように思います。

リモートで働くようになって困ったことといえば、人と喋る機会が減って人の言葉を忘れ始めてしまいました(笑)。もともとあんまり喋らないほうなんですが、リモート勤務だとその傾向がもっと強まってしまって、朝に家族と話して、子どもを保育園に預けるときに先生に挨拶すると、あとはお昼にカレー屋さんでカレーを注文するくらいしか喋らなくなっちゃうんですよね。

そういう話をマネージャーとの1 on 1で話したら「リモートランチ」というのをセットしてもらえるようになりました。毎週いろんな人とビデオ会議を繋ぎながらご飯を食べているんですが、そのたびにそんなに話したことのない人と話せるので助かっています。

やっていき・のっていき

— freeeでの仕事の進め方はどうですか?

自分の所属しているSREチームはそんなに人数が多くないんですが、その中でいくつかのプロジェクトをやっているので、その関係で兼務兼務兼務みたいな感じで話をすることが多いです。

他のチームのエンジニアとは、Kubernetesを導入するプロジェクトで交流することが多いですね。で、デプロイが終わるとそのプロジェクトの人とは仕事上は疎遠になったりします。もちろん寂しさがないわけではないんですが、職人芸を発揮して離れていくというのは業務上の責任は果たせていると思うし、ある意味で理想的だと思うんですよ。

いちおう人なので、人との関わりは持ちつづけたいと思っているんですけどね。人間として矛盾しているかもしれません。日々出会いと別れですね。そんな感じで、常に職人芸を発揮できるものを探しつづけないといけません。

freeeでの仕事は、全体的にやりやすいなと思っていて、とにかくメンバーの「やっていき・のっていき」の精神がこの規模になっても感じられるのはすごいですよね。ふつうは会社の規模が大きくなったら、その人の仕事の範囲を越境したときのインパクトは大きくなるのでやりづらくなるはずなんですけど、そのあたりに貪欲な人が多いなと思っています。こういうのは一人のエンジニアの力ではぜったいに作れない文化で、すごくいいなと思っています。

そういう文化さえあればKubernetesだろうが何だろうが、新しくて良さそうなものなら何でも入れられるなって気がしますね。Kubernetesを入れようっていう話をしても背中を押してくれない人が誰もいなかったし、入社2日目のまだ何もよくわかってないような状態で出たミーティングで、もうKubernetesの導入が決まってしまったんですよ。あれはびっくりしました。

上手くいっているものを変えるのって、普通ならわかりづらいと思うんです。そういうときって「変えないと死ぬ」派と「今うまくいってるならいいじゃん」派に分かれて、前者がベンチャー的だなと思うんですけど、freeeはその二択という感じでもなくて、特徴的だと思います。暑苦しい人ばかりだとコンフリクトしそうだし、バランスがいいのかな。

インタビュー風景

職人が必要でなくなるときのために

— 最後に、mumoshuさんがこれからやっていきたいと思っていることををお聞きしたいんですが、将来目指しているものとかはあったりするんですか?

たぶんひととおりKubernetesの導入が上手くいってくると、Kubernetes職人みたいなかたちでインフラエンジニアがやることって無くなっていくと思うんですよ。いま社内に「Linux担当」っていう人はいないじゃないですか。あまりにもデファクトになった技術ってそうなっていくと思うんですよね。そうするとKubernetes担当の人としては一社では生きていけなくなってくるだろうし、生存戦略として他のこともやっていかなきゃと思っています。

そういう中で、機械学習のプラットフォームを作るのには興味があります。

大学院のときに自然言語処理をやっていて、テキストを解析して機械学習にかけて人間にとって意味のある結果を出す分野のことをやっていました。生データを加工して学習データを作って、それをモデルにして高速に問題を解いたりすることをしていました。

それをプロダクションに載せるっていう夢を持ってWeb業界に入ったんですけど、一転二転してインフラエンジニアやってるんですよね。

最近はどこもかしこも機械学習って言っていて、10年前とはあまりに世界が違うなと。そのわりに面倒臭さって変わってなくて、10年経ってこのままならKubernetesの次を探すときもこの泥臭いままなのかな、やることが残っていそうな匂いがしています。

それから、どこの会社の社内システムでもググれば大体のことはわかる、という世界を作ることにも興味があります。どこの会社でも何らかの自動化や効率化をしてきていると思うんですけど、それは会社によってだったり、やった人によってだったり、やり方に違いがあるんですよね。これまで何度か転職をしてくるたびに、「あ、これはあの会社とはこう違うんだな」というのを実感することを繰り返してきています。

でも、たとえばAWSを使っていて、EC2だとかRDSだとかElastiCacheの使い方のズレってそんなにないですよね。やっぱりAPIが切られているとそのAPIとして用意されている中でしかズレないのでキャッチアップしやすいですよね。

どこの会社のシステムもそういう風に同じAPIを軸に組まれていたら、もっとキャッチアップしやすい人材流動性の高い社会になると思うし、いろんな会社に首を突っ込みやすくなると思っています。そういう社会にしたいなと思っています。

いまSREチームとして他のチームの人から相談を受けるときも、社内独自でやってしまっている工夫についてはまだまだ眠っている暗黙知がある気がしていて、答えなければいけないプレッシャーにウッとなることがあります。Kubernetesのことは何を聞かれてもだいたいググって出てくるので、簡単だし怖くないんですけど。

freeeにはそういうところも期待しています。いつになるかはわからないけど、最終的には一社に一人freee担当がいて、そういう人が一人いるだけでいろんなシステムが自動化・効率化されていって会社が回る、みたいな世界を作れるといいですよね。

とはいえそういうfreee担当そのうちLinux担当とかKubernetes担当みたいになってそうですけど。やっぱりまずは職人芸の世界があって、それがだんだん職人が要らなくなっていくみたいな世界観をもって生きています。

インタビュー風景


長きにわたったインタビューでしたが、お付き合いいただきありがとうございました。

freeeではmumoshuさんのような職人気質のエンジニアを積極採用中です!!

jobs.freee.co.jp

jobs.jobvite.com

www.wantedly.com

Kubernetesでアプリエンジニアが勝手にやれるインフラを作りたい — 九岡 佑介 (mumoshu) インタビュー(前編)

こんにちは!freeeでエンジニアをやっている id:ymrl です。

ふだんマイペースに更新しているこのfreee Developers Blogですが、たまにはfreeeで働く個性豊かなエンジニアを紹介したいなと思い、第一弾として最近AWS Container Heroに就任したSREエンジニアで、kube-awsをはじめとするOSSのメンテナーとしても知られる九岡佑介(@mumoshu)さんにインタビューしてみました。Kubernetesの話やリモートワークの話を聞いていたら内容が盛り盛りになってしまったので前後編でお送りしようと思います。

mumoshuさんの写真

転職するごとにレイヤーが下がっていった

— mumoshuさんはこれまでKube-AWSの開発をされてきて、それもあって先日AWS Container Heroにも就任されたわけですけど、もともとKubernetesまわりのことをしはじめたのはいつ頃、どういうキッカケだったんでしょうか?

やりはじめたきっかけは、Chatworkのメッセージ基盤をScalaに移植するプロジェクトでした。このプロジェクトはアプリケーション側がずいぶんチャレンジングだったんですが、実はインフラもチャレンジングで、そこで採用したのがKubernetesでした。

そのころのインフラは社内で内製していたソフトウェアがあって、当時のChatworkをメンテナンスしていくのには最適化されていたんですが、Akka HTTPとScalaで作った新しいアプリケーションを動かすには不向きでした。また、当時のチームの構成としてアプリケーションエンジニアが多くそのモチベーションも高かったので、もっとプログラマブルで、アプリケーションエンジニアが使いたくなるようなインフラにして、その力を最大化できるものを求めていました。ちょうどそのときに使いやすそうだったのがKubernetesでした。

自分がかつてアプリケーションエンジニアあがりのインフラエンジニアなこともあって、そのころの自分が「これならインフラも見ようかな」と思えるインフラを構築したいと考えていました。自動化のしやすさや、必要だと思っている機能がひととおり揃っていて、自分たちで作りこまなくても使える状態というものが理想でした。

—アプリケーションエンジニアとしての経験が、いまのmumoshuさんのインフラエンジニアとしてのありかたに繋がっているんですね。なぜアプリケーションエンジニアからインフラエンジニアになったんでしょうか?

新卒のときは大手メーカー系の会社で、エクセルと電話を使って開発のディレクションをするような仕事をしていました。自分では全くコードを書かない仕事だったんですが「これなら自分が書いたほうが早いな」と思うこともしばしばありました。

そんなある日、社内で他の人から「あなたは優秀なのに、こんなことをしていていいのか?」と叱責されたのが最初のきっかけでした。自分でも「この仕事は全然面白くないな」と感じていたときだったので、考えた結果「自分で書こう」と思いました。

それから1年くらいその会社でプロダクションコードを書きました。当時HTML5とかCSS3とか、prototype.jsとかjQueryみたいな技術が出始めた頃で、いろんな会社のAPIをマッシュアップしてWebサービスを作っていました。

その頃はフロントエンドのことばかりをやっていた感じで、インフラのことなんて何も知りませんでした。エクセルを埋めて社内システムに登録して、あとは不明点などを電話で相談しているといつの間にかインフラが構築されている、という感じでした。そのときの「インフラわかんない感」を繰り返したくないなとか、その頃インフラもやっていたらこんな感じであってほしかったな、というのを未だに追いかけているのかもしれないです。

そのあと転職をするに従って、だんだん扱うもののレイヤーが下がっていきました。

2社目にいたときにScalaのPlay Framework 2に傾倒していて、自分の気にいった技術を社内で使ってもらうための外堀を埋める活動として、ドキュメントの翻訳をやったり、登壇をしたり、いろいろなことをしてきました。その一環でちょっとだけインフラを触ったのが自分にとって初めてのインフラでした。といっても他の人がAWSを設定したのをチョロっと触っただけだったので、今思えば「そんなところからよく初めたな……」という感じですけど。

インフラエンジニアとして仕事をするようになったのは3社目で、当時その会社ではじめてScalaを採用するというタイミングでした。そこで2社目でScalaを使っていたということでインフラに起用され、デプロイの自動化やモニタリングの仕組みなどをわからないなりに構築する機会を得ました。ここでそれまで触ってこなかったインフラの世界に一気に触れることができました。

その次の会社は、会社のエンジニアとしては5人目、自分がはじめての専任のインフラエンジニアという感じで、このときにはほぼアプリケーションコードを書かなくなっていました。このときの仕事はいろいろと大変でしたが、この経験がいまに一番生きていると思います。

インタビュー風景の写真

freeeに来たのは大きなチャレンジがあるから

— そのあと、現在も技術顧問をしているChatworkに行かれて、そしてfreeeに来たわけですけど、なぜfreeeを選んだんでしょうか?

Chatworkでは1年以上かけてKubernetesを導入するという大きなチャレンジがあって、あれは自分と、当時のチームでしかできないとても大きなチャレンジだったと思います。このチャレンジをやりきった上で、もっと大きなチャレンジをしたいと思うようになりました。

そこでChatworkには技術顧問として関わりつつ、本業としてそういう大きなチャレンジを探しているときに出会ったのがfreeeでした。

freeeには「規模」と「セキュリティ」という大きなチャレンジがあると思っています。freeeで扱う会計などのデータは、法律でどう守られるべきなのかが定められていたり、それ専用の監査のやり方が用意されているような情報です。そういうものが流れるシステムの監査に耐えられるインフラをKubernetesで作るのはとても大変なことだと思っています。

KubernetesをはじめとしたContainer Orchestrationの世界では、こういった厳しい監査のあるセキュリティ施策は未知の領域で、後付け後付けで改善されていっているんですが、それでもまだまだ進化の余地が残されているなと感じています。

規模の話でいうと、10人くらいで開発・運用を回しているような小規模なシステムでは、求められる要件が何であれKubernetesはオーバーキルなんですよね。しかし100人とかになってくるとカオスになってきて、「間違えることができない」が重要になってくるはずです。そういうときにKubernetesの、必要な機能が一通り揃っていて、それを組み合わせて使えばOKという特徴が生きてくると思っています。

自分は「ただ引き継ぐ」ことができない性格で、ついつい作りこみをして技術的負債を残してしまうので、そういう意味でも一通り揃っている機能から必要なものを選んで使えるKubernetesは合っているなと思っています。Kubernetesはやりすぎる余地があまりないし、もしやりすぎてしまってもその成果をOSSにしちゃえれば技術的負債にならないので(笑)。

そういったものを使いこなして、別次元の監査が要求されるような世界でも、開発者の生産性を落とさず監査に耐えられるような状態を作れたらいいなと思っていて、そんなチャレンジはfreeeでしかできないと思いました。

インフラは職人芸の世界

—— 自分にできないような大きなチャレンジの舞台として、今のmumoshuさんはインフラエンジニアをされているわけですが、自分はインフラのほうが向いていると思うようなところはあったりするんでしょうか?

インフラのほうが、職人芸が残っている分野な感じがしているんですよね。新しい技術が出てきたときに、最初は職人が絶対に必要になると思うんです。

Kubernetesもそうなんですけど、新しい技術を使うためにはどうしても必要とされるスキルセットが違うし、たくさんのことを憶えなければいけないですよね。そこまでして使いたい人というのはなかなか現われないと思うんです。でも、そんな中で物好きな人が勉強して使えるようになると、その人がその会社で最初の職人になるんですよね。

インフラの世界は、そういう職人芸が必要なものがまだまだたくさんあるのが面白いところかなと思っています。

インフラエンジニアとしては、アプリケーションエンジニアだった頃の自分が欲しいインフラを作っていきたいということを常に考えています。Kubernetes自体の運用はまだ職人芸というか特殊技能なんですが、その上でアプリケーションエンジニアが勝手にサービスを動かすということができるといいですよね。サーバーの台数を調節するなんていうのもアプリケーションエンジニアが勝手にやれるようにできるし、勝手にやったほうが絶対良いものになると思っています。それができるのがKubernetesだと思っています。

自分がアプリケーションエンジニアだったら、やっぱり人に押しつけられたものを使わされるのは嫌ですしね。これまで使ってきた仮想マシンベースのインフラと、Kubernetesベースのインフラを用意して、各自が使いたい方を自由に選べて、それをSREがサポートできる。そんな座組にできたらいいなと思っています。

mumoshuさんの写真


前編、いかがでしたでしょうか。リモートワークや未来の話で盛りあがったインタビューは後編に続きます。後編は明後日に公開予定です。お楽しみに!

2018/09/14追記: 後編を公開しました!

developers.freee.co.jp


jobs.freee.co.jp

www.wantedly.com

freeeの新しく公開されたAPIを使って、非エンジニアが音声で勤怠打刻をしてみました!

こんにちは、freee株式会社のgokiです。

私は2017年の新卒としてビジネス職で入社し、現在はProduct Value Boosterという、営業チームや導入支援チームに自社プロダクトの価値を咀嚼してお伝えするお仕事をしています。

非エンジニアではあるのですが、いろんな業務改善ツールを作ることが好きで、趣味でいろいろ作ったりしています。

IFTTTを使って音声で勤怠打刻をしたかった理由

皆さんは、勤められている会社で勤怠って付けていますか?

ほとんどの人が”YES”だと思うのですが、あれってなかなか面倒だったりしますよね。

freeeでは、会計や人事労務管理はすべて自社のサービスを使用しているのですが、クラウドとはいえ、勤怠のためにPCをつけて、ログインして打刻、という作業時間がもったいないなぁ、と感じていました。

人事労務freeeがタイムレコーダー(打刻)のAPIを公開!

そんな勤怠打刻の悩みを悶々と抱えていた矢先、なんと人事労務freeeがタイムレコーダー(打刻)のAPIを公開しました)!

人事労務freeeのタイムレコーダー(打刻)APIのリファレンスの画像

嬉しーーーーー!!!

タイムレコーダー(打刻)APIについて

指定した従業員のタイムレコーダー(打刻)情報を 登録 / 取得する ことができます。 登録の場合は、webの画面やアプリと同じく出勤 / 退勤 / 休憩開始 / 休憩終了 の登録ができます。 このAPIを用いて、自社のツール・ICカードや生体認証に対応した打刻機からAPIを呼び出すことで出退勤の管理を自動化することができます。

※タイムレコーダー(打刻)機能は、ビジネスプランのみ有効です。 https://developer.freee.co.jp/docs/hr 人事労務API 概要 | freee Developers Community

これで色んな方法で打刻ができます!

やっぱりやるなら音声入力

実は前回、Google HomeとIFTTTを使って、音声で経費の仕訳を作成するという記事を書かせていただきました。

developers.freee.co.jp

大変ご好評もいただいたこともあり、今回の打刻APIの活用アイデアを考えたときに、私は真っ先に音声入力が思い浮かびました。

前回のノウハウもありますし、何より音声入力ってやっぱり楽ですしね。

というわけで、前振りが長くなってしまいましたが、

「OK Google!出勤したよ!」と言ったら、自動的に人事労務freeeで出勤を記録する仕組みを作りたいと思います。

基本的な仕組み

仕組みとしては、前回の音声仕訳と同じく「①Google Assistant →②Google スプレッドシート→③freee」という順番でデータを飛ばそうと思います。

①と②の間をIFTTTで、②と③の間はGoogleのスクリプト“Google Apps Script(略称GAS)”を使用して、freeeが公開したAPIを叩くという方法です。

下準備で必要なもの

  • Googleアカウント
  • Google Assistantアプリのスマホへのインストール
  • IFTTTアカウント
  • 人事労務freeeのビジネスプランのアカウント

IFTTTの設定

準備が終わったら、あとはIFTTTの設定です。IFTTTにログインしたら「New Applet」よりAppletの新規作成を行います。

IFTTTのNew Applet画面のスクリーンショット

Appletのトリガーであるthisの部分は次のように設定します。

service
Google Assistant
trigger
Say a simple phrase

最後のtrigger fieldsについてですが、今回は、「出勤したよ」と喋りかけたら自動で打刻の処理をしたいので、次のように設定しました

What do you want to say?
出勤したよ
What's another way to say it? (optional)
出勤しました
And another way? (optional)
出勤するよ
What do you want the Assistant to say in response?
今日も一日頑張ってください

IFTTTの設定クリーンショット

これで、「出勤したよ」と話しかけたことをトリガーにアクションを実施できるようになりました。

ちなみに、このトリガー後のGoogle Assistantからのレスポンスは「今日も一日頑張ってください」とし、朝からテンションが上がるように設定しました。

続いて、thatにあたるアクション部分を作成します。

service
Google Sheet
action
Update cell in spreadsheet

を選択します。

action fieldsは、「音声打刻」というスプレッドシートを指定し、そのシートのA1セルを出力先に指定しました。

Spreadsheet name
音声打刻
Which cell?
A1
Value
clock_in

IFTTTの設定のスクリーンショット

また、出力先への値としては「clock_in」を指定しています。

これは、freeeの打刻APIでリクエストを送るときのtype(出勤・休憩開始・休憩終了・退勤)を指定する必要があるので、今回は出勤を指定する「clock_in」を入れています。

APIにて操作可能な打刻種別は以下のとおりです

clock_in
出勤
break_begin
休憩開始
break_end
休憩開始
clock_out
退勤

あとは同じ要領で休憩や退勤も作成

ここまでで、Google Assistantに話しかければ、Googleスプレッドシートに出勤情報を飛ばすことができました。

同じ要領で休憩開始、休憩終了、退勤なども作成すれば、IFTTT側の準備は終了です。

「①Google Home →②Google スプレッドシート→③freee」のうち、①→②が完成しましたので、

次からは②スプレッドシートから③freeeへの入力について説明します。

Google スプレッドシートとfreeeの連携の仕方

前回の記事でも書きましたが、Google スプレッドシートとfreeeの連携は意外と簡単です。

実はfreeeのヘルプページにはスプレッドシートからAPIを送信する用のサンプルシートがあります。

support.freee.co.jp

ただし、上記のサンプルシートについては、人事労務freeeではなく、会計freeeの取引登録APIなので、そのまま使うことはできません。

しかし、これを使えば、OAuth2認証で必要なアクセストークンなどを簡単に取得することができるうえ、POSTリクエスト(APIの叩く操作)もコードを数行書き換えるだけですぐ終わるので、めちゃくちゃ楽です。

Googleスプレッドシートの変更点

まず、サンプルシートをIFTTTの値出力先にするため、名前を「音声打刻」に変更します。

IFTTTからを値を受け取るシートを作成し、連携認証をマニュアルに従って行えば準備完了です。

Google Assistantから休憩開始を喋りかけてみて、A1セルにbreak_beginが入力されれば成功です。

Googleスプレッドシートのスクリーンショット

あとは、スプレッドシートの「ツール」→「スクリプトエディタ」から少しコードを書き換えるだけで完成です。

コードを変更した箇所

今回は、会計freeeの明細POSTのコードをコピーして、下記の部分だけ変更を加えました。

変数のrequestUrl を "https://api.freee.co.jp/hr/api/v1/employees/従業員ID/time_clocks"に変更

POSTする内容の記述を下記のように変更

  var d = new Date();
  var postdate = Utilities.formatDate( d , "JST" , "yyyy-MM-dd" ); 
  var gSheet = ss.getSheetByName( "IFTTT" );
  var posttype = gSheet.getRange( 1 , 1 ).getValue();

  var requestBody = 
        {
          "company_id" : 事業所ID,
          "type" : posttype,
          "base_date" : postdate,         
        };

打刻の場合はリクエストに必要な情報が少ないので、とってもシンプルかと思います。 説明するまでもないかもしれませんが、リクエストのtypeの値をIFTTTから出力されるA1セルの値にしています。

事業所IDと従業員IDの取得について

事業所IDと従業員IDについては、もともとサンプルファイルには事業所IDの取得リクエストができるようになっています。

さらに従業員IDについても、「ログインユーザーの取得」という人事労務freeeのAPIを叩けば分かるのですが、

そのコードを書くのがめんどくさいので、人事労務freeeにログインして「従業員情報」のリンクのURLが

https://p.secure.freee.co.jp/employees#従業員ID/年/月となっているので、そこで調べてコードに直打ちしています。

準備完了!!

これで準備が整いました、最後にスクリプトエディタのトリガー設定にて、シートが更新されると打刻のスクリプトが動くように設定しておけば完了です!

トリガー設定のスクリーンショット

音声打刻の使用感

作成してからは、これで打刻を行うようにしていますが、とても快適です!

「OK Google!出勤したよ!」で終わるので、とっても時間短縮。

あとは、Google Assistantが「いってらっしゃい、今日も頑張って」と返してくれるのも心がほっこりします。

Googleアシスタント(アプリ)のスクリーンショット
自分が設定したのだけど、応援してくれるのがうれしい...

もっとイメージがわくように、動画もいつか撮影して載せたいと思いますが、今回は写真ですみません。

人事労務freeeのビジネスプランを使っている方は、ぜひぜひ試してみてくださいね!

打刻APIを使えばいろんな連携ができそう。

私は技術にめちゃくちゃ詳しいわけではないのですが、今回のAPI公開で

GitHubやSlackから勤怠打刻したり、生体認証で勤怠を打刻したりといったことができるようになりそうですね!

個人的に音声については目が不自由だったりする方には最高の勤怠ソリューションかな?とか思いました。

もし、このようなテクノロジーを使って、いろんなビジネスの課題を解決することに興味がある方は、ぜひぜひfreeeという会社のこともチェックしてみてください~

jobs.freee.co.jp

iOSDC2018にスポンサーとして参加してきました!

こんにちは。freeeでモバイルエンジニアとして働いている kohirose です。 私の所属しているモバイルチームのiOSメンバーで iOSDC2018 に参加してきました。私自身は主にAndroid界隈で生きているエンジニアですが、iOSにも興味があるため今回のiOSDCに潜入してきました。

また、弊社は try!SwiftDroidKaigi といった技術カンファレンスでもスポンサーとして参加をしてきており、今回のiOSDCでもスポンサーブースを会場で出展しておりました。

developers.freee.co.jp

developers.freee.co.jp

iOSDCとは

受付の写真

2018年8月30日(木)〜9月2日(日)に3日+前夜祭の計3.5日間で開催されたiOS関連技術をコアのテーマとした技術者のためのカンファレンスです。 昨年の開催では計2.5日だったため、1日増えたことになります。

私は国内国外問わずモバイル関連のカンファレンスには頻繁に参加するのですが、iOSDCはその中でもセッション&LT数もとても多かったと思います。

8/30(木) 8/31(金) 9/1(土) 9/2(日)
12 35 49 38

また、毎年お酒が振舞われ、LTでは参加者が飲みながらワイワイと参加する形となっているのがiOSDCの特徴かと思います。

開場で振舞われる缶ビール

ブース出展

freeeブースの様子;

先述の通り、今回は弊社ではブーススポンサーとして参加したため、4日間会場でブースを出展しておりました。

昨今、働き方改革という流れもあって「副業やってみたいのですが・・・」「個人事業主として働こうと思ってます。」といった声が多くあった印象でした。また、今回弊社のブースでは確定申告についてお話しさせて頂きながら、私たちが開発しているiOSアプリを体験して頂きました。なお、こちらのアプリは開発中のものとなります。

youtu.be

上の動画と同じ、領収書の撮影から取引の登録までを体験して頂いていたのですが、その中でも私たちのiOSアプリでは、撮影時に OpenCV を利用して領収書矩形を切り抜いたり、取引登録時に OCR を実現していたりと、確定申告準備をより楽にしようとして開発をしております。

www.freee.co.jp

「どうやって実現しているのか?」「OCRはクライアントでやっているのか?サーバー側でやっているのか?」といった技術的なお話も多くすることができ私たちのiOSアプリに興味を持って頂いてとても嬉しく思いました。また、実際に体験して頂くことにより、UI/UX面での気づきもあり、今後より使いやすくなるようにより改善を続けていく必要があるなと改めて感じました。

freeeロゴのキーキャップと装着されたキーボード

また、今回もキートップノベルティは健在で人気を集めていました。弊社のブースで展示していた自作キーボードはブーススタッフの作成物であったため、自作キーボードの作り方や、種類、部品の発注方法まで多くのことを語られていました。私自身は作成したことなかったため、こんなに多くのキーボード自作ファンがいるのかと驚かされました。またノベルティを配布することがあればキートップも配布するかと思いますのでご興味ある方は是非スタッフに話しかけてみてください。弊社にはキーボード部があるくらいなのできっと喜ぶかと思います。

セッションについて

セッション開場の様子

iOSDC2018のセッションは先述の通りとても多く、内容もコアな部分から現場でのテクニックまでとても幅広く扱っていました。今年のWWDCで注目を浴びた ARKit の話であったり、差分更新アルゴリズムの話であったり、圏論 の話であったり、本当に多種多様なセッションが揃っていました。参加させて頂いたものの中からいくつか紹介させて頂きます。

ARKitと3D数学

speakerdeck.com

前夜祭である初日の1発目のセッションはARKitでした。ARKitを利用するにあたって必要となった3D数学を説明してくれるという、数学好きな私としては楽しみなものでした。

定義されたあらゆる体系の座標系があり、その座標系の中での座標を最終的にスクリーンに落とし込むことにより、スクリーンの任意の場所へ3Dオブジェクトを配置できるとのことです。この座標系の知識があれば、あとはARKitが用意しているAPIでiOS上でのARが実現できます。物体を30cm奥に表示するという簡単なところから説明してくださっていたのでARって難しそうで敷居が高いと思っている方におすすめです。今回のスライドでは行列の話がなかったので残念でしたが、Qiitaに追加として書かれていたのでそれも見るとより理解が深まるかと思います。

qiita.com

MicroViewControllerで無限にスケールするiOS開発

www.icloud.com

複数人開発を行っていると避けては通れないコンフリクトやオーバーヘッドを無くして多くの人数でプロダクトを効率的に開発していこうという目的に向けて、1画面のViewControllerの中の各々の部品をViewControllerとして実装していこうというお話でした。各々の開発者が触る領域が決まりやすいため、確かに人数が多ければ多いほどこの開発手法は生きてくるなと感じました。ただし、大量のViewControllerを作成していくことになるので負担をより軽減させるためにテンプレートが多くあると良いとのことです。一つ一つのViewControllerの責務が分かりやすく分割されるのでテストも書きやすくて良いなという印象を受けました。

iOSと(深層)強化学習

speakerdeck.com

本セッションでは、そもそも強化学習とはどういったものなのかから始まり、ニューラルネットワークをSwiftで実装しCartPole問題を題材にiOS上でデモを行うというものでした。

ニューラルネットワークを自作するには行列演算が必要で、そこにはBLAS(Basic Linear Algebra Subprograms)を利用するとのことでした。私自身このBLASを存じていなかったのでこのセッションが終わった後一番試してみたかったものでした。その場のデモでロボットが学習していき最終的にロボットが解決していく姿を見ていて会場も盛り上がっていました。

Depth in Depth

speakerdeck.com

iOSでは深度は AVDepthData というクラスで表さられ iOS11から利用できます。このAVDepthDataの取得には

  • 撮影済みの写真から取得
  • カメラからリアルタイムに取得
  • ARKitから取得

のパターンがあり、各々は用途によって使い分けると良いとのことです。

実際に本セッションではカメラからリアルタイムに取得して切り取られた自分自身の顔と任意の画像を合成するデモがあり、徐々に改善していくという実践的な発表となっていて惹きつけられました。また、今月リリースされるであろうiOS12からは Portrait Matte という、静止画かつ人物に限定されるがより従来の深度マップより人物と背景の深度差が的確に表現できるフォーマットが利用できるとのことで、ますます実用的なものになっていくなという印象を受けました。今回は被写体が静止画なのかリアルタイムなのかや、フロントカメラなのかリアカメラなのか、はたまたOSのVersionは幾つなのかなどといった多くのパターンがあるため、対象のアプリにおいて何が実現できるのかを整理することで自分自身の開発するアプリにも何かしらの機能として盛り込めるかなと思います。

まとめ

私自身iOSDCへは2回目の参加でしたがブーススタッフとしては初めての参加となりました。個人事業主の方で「freee使ってます!」といったとても嬉しい声や、同じくブーススポンサーとして参加された企業との情報共有などあり、セッションだけでなく他のところにも楽しみがあった良い機会だったと思います。今回実際にお話しさせて頂いた多くのエンジニアの方々や運営スタッフの方々に大変感謝しております。また、アプリを体験して頂いたことで得られたフィードバックについては改善として今後の開発とさせて頂きます!

iOSDCの開場で、freeeメンバーの集合写真

最後に

freee ではモバイルエンジニアを募集中です。 今回に限らず、弊社ではエンジニア向けカンファレンスに精力的にスポンサーとして参加しており、内容にもよりますが、大抵のエンジニア向けイベントには業務の一環として、業務時間にチケット会社負担で参加することができます。 今回は土日開催であったため代休を2日もらいました。私はその代休(と有給休暇)で沖縄にダイビングをしに今月行ってきます!ご興味がある方は是非一度弊社に遊びにいらしてください!

jobs.freee.co.jp