病みつきエンジニアブログ

機械学習、iPhoneアプリ、Javascript,Ruby on Railsなどなど。

チーム開発における「ニワトリ」が適切に鳴くために

アジャイルスクラムとかの文脈で「ニワトリ」と「ブタ」という概念がある。

f:id:yamitzky:20170713001738j:plain

その言葉自体は結構ググれば出てくると思うんだけど、一つ寓話を引用してみる。要は、「ニワトリとブタ」のプロジェクトメンバーが「ハムエッグ」を作る上で、「ブタ」は自分の身を削っているのに対し、「ニワトリ」は身を削っていないですね、ということ。

ニワトリとブタがいた。
ニワトリは「さあ、レストランでもやろうよ」と言った。
ブタはよく考えてから「レストランの名前は何にしようか」と言った。
ニワトリは答えた。「ハム・エッグさ」。
ブタは言った。「僕は止めておくよ。君は産むだけだけど、僕は切り刻まれるんだよ」

recompile.net

※ 原典は シュエイバー・ビードル共著の「アジャイルソフトウェア開発スクラム」?

原義からずれるかもしれないが、自分は「ブタとニワトリ」をこう解釈している。

ブタ・・・開発チームのメンバーであり、開発工数を使ってプロジェクトにコミットしている
ニワトリ・・・マネージャーやステークホルダーや部外者であり、プロジェクトに関わってはいるが開発はしない

あまり好きではない言い方だけど、一言で表現するなら「現場」と「マネージャー」だ。ちなみに自分は、ブタになることもあれば、ニワトリになることもある。

ニワトリはなるべく鳴いたほうが良い

まず大前提として、開発チームも、マネージャーもステークホルダーも部外者も、自由に意見が言えた方が良い

逆に、開発チーム以外が意見が意見を言えない状態というのは最悪で、

  • 問題に気づいた人が報告できない状態になってしまう
  • 新鮮な観点の意見を取り入れられなくなってしまう

なので意見は、多ければ多いほど良い。それが、チームでモノづくりする一つのメリットでもある。ただし、意見を適切に取り入れることのできる限りにおいて、という前提が必要だ。

ニワトリが鳴くデメリット

ニワトリが自由に鳴ける環境の方が健全だけど、ニワトリの鳴き声は開発チームへの悪影響がつきものだ。

  • 「偉い人」の報告の重要度がわからず、目の前の開発が止まる
  • 既に話した仕様を再度聞かれていたりして、ストレスが溜まる
  • 報告義務が発生する上に、専門家ではないから理解に時間がかかる
  • エンジニアとの共通言語がずれていて、コミュニケーションに時間がかかる
  • 「偉い人たち」の言ってることが違っていたりすると、もう大変

注意してほしいのは、これが善意かどうかにかかわらず起こる可能性がある、ということだ。

偉い人が要望をあれよこれよと善意で提案して、現場が右往左往している、といえば、失敗経験が思い浮かぶかもしれない。

ニワトリが自由に鳴けるチームが健全だけども、鳴き方に問題があると、悪い問題が発生するのだ。

適切なニワトリの鳴き方

では、どういう風に意見・要望を伝えたり、悪い報告をすれば良いのだろうか?

僕が気をつけていることは、4つある(できている、とは言えなくて、後悔することも多いのだけど、、、orz)。

1つめは、重要度/緊急度を適切に定義し、選択権を委ねることだ。これから提案しようとしていることは、目の前の開発を止めてまでやってもらうべきことだろうか? 開発スプリントに差し込むべきものだろうか? もしそうでないなら、「急ぎではないので、一段落したら対応検討してください」とか「とりあえずバックログの一番上に積んでおきました」とか「優先度を明日の朝会で調整させてください」とか、そういうコミュニケーションを取るようにしている。目の前の開発を止めなくていいですよ ということを表現するようにしている。コードレビューにおいても「今じゃなくて良いんですが、今後こうしたいですねー」とか言ったりする。

2つめは、なるべく正確に表現することだ。特にバグレポートに顕著で、「再現方法」「生じた事象」「推測される要因」などを、誰が読んでも誤解なく読み取れるように書くようにしている(参考)。「誰が読んでも誤解なく」というのは、例えば、「アプリが動かない」ではなく「フリーズして操作できなくなる」というふうに、曖昧でない日本語を使ってあげることだ。

3つめは、ポジティブに取れる表現をして、決定権を委ねる(特にこれができてない、反省)。「◯◯かもしれないですね(これを前職で「かもトーク」と呼んでいた)」とか「◯◯も良いと思います」とか「◯◯と思ったんですが、どうでしょうか?」とか。自分の発言が正しく、相手に説明すれば理解してくれるという性善説に立てば、決定権は相手に委ねることができるはず。(意見が割れるときは、投票というテクニックを使います)

4つめは、聞く前に検索する。最近のチーム開発だったら、Slackとか使って、Qiita:team的なナレッジベースがあって、Github Issueベースで仕様が固まっていったりするので、検索すれば出てくることも多い。「検索してみたんですけど見つからなくて」とか言えば「ああ調べてくれたんだな」とポジティブに構えてくれる。むしろ、検索して出てこないのであれば、仕様がちゃんとドキュメントとして残っていないということなので、「ドキュメントをより良くしましょう」という改善のためのコミュニケーションができる。

ニワトリが鳴いてもいいとき

また別の観点として、「偉い人」や部外者が自由に発言しても良いとき、というのがある。

1つは、「良いこと」を言うときだ。これは、無条件に、良い。「ここの動きが良いですね」「速いですね」「きれいですね」「新しい機能気に入りました」「あざーす」など。そういう「褒め」はエンジニアのテンションが上がるので、言えるなら言えるだけ言ったほうが良い。特に、エンジニアが気を利かせて何かをやってくれたときというのは、本当に感謝すべきだなと感じている(言ったことを3倍にしてやってくれる人って、重宝ですよね)。

もう1つは、「長期的なビジョン」を言うときだ。(言い方に気をつける必要があるが)「一年後にはこうなってたいねー」とか「このプロダクトはこういう目的があってね」とか。「長期的なビジョン」を知りたいという開発メンバーは、マネージャーが思ってる以上に多い。単純にわくわくするので。そして、ビジョンを適切に伝えていれば、開発メンバーが「そんなこともあろうかと」と気を利かせた作りにしてくれることもある。

鳴く以外の、ニワトリの表現方法

偉い人と開発メンバーのコミュニケーションは、何も発言するだけではない。

ずばり、MTGに(勝手に)参加することだ。朝会にいれば、空気感もわかるし、「偉い人への報告」みたいなもの省ける。

ただし、MTGに参加しても基本的には発言しないのが重要だと思う。MTGというのは参加者が増えれば増えるほど、質が落ちるからだ。MTGは、ブタのための時間である。

もし気になることがあれば、後でチャットとかで「朝会で気になったのですが、◯◯って☓☓ですか?」みたいな非同期コミュニケーションで解決できる。

まとめ

最近考えていたことを、つらつらと書いてみた。

  • 「偉い人」や部外者が意見できる環境が健全だが、悪影響がある可能性がある。より良く伝えるためのテクニックがある。
  • 「良いこと」と「長期的なビジョン」であれば積極的に伝えたほうが良い
  • 「偉い人」や部外者もMTGに参加できる方が健全。ただし、その場では発言しない方が良い。

たとえシステムが落ちても“社内には”謝罪するべきではない理由。あるいは”反省”と”対策”にフォーカスしようという話

こんなことを書くと怒られそうなんですが、自分の一つのポリシーとして、システムが落ちたり障害が起きたりバグが発生したことについて、基本的に“社内には”謝罪しないことにしています(もちろん例外は度々あります)。

という概念は広まるべきだなと思っていて、紹介したいと思います。

こんなこと言うと、ビジネスサイドの人からは怒られると思うんですけど。。。

前提

  • 自分の勤めるJX通信社は、自社開発している企業であり、ベンチャー企業です。外注はしていません。
  • 自分の立場は、エンジニアですが、固い言葉で言うと中間管理職とも言える立場でもあります(チームリーダーとかっこよく言えるほど職責を果たせているとは思えないので、そういう言い方をします)

理由1:システムは落ちるときは落ちる。バグるときはバグる

最初から諦めていて申し訳ないのですが、まず第一に、システムは落ちるときには落ちます。バグるときはバグります。システムを落ちづらくしたり、バグりづらい開発体制を敷いたりすることはできますが、100%24時間365日落ちないシステムというのは基本的にはできません。(こういうことを言ってしまうと、仕事に対するスタンスとして当然不適切なのですが)

具体的な事例を出すと、僕みたいなポンポコリンより数百倍すごいエンジニアを集めたGithubでも、落ちますGithubは有償プランを持っていますが、それでも落ちます。AWSですら障害は起きます。

理由2:ほぼ落ちないシステムはあるかもしれない。けど、コストとスピードが見合わない

落ちないシステムを作るとしたら、たとえば次のような「品質担保」の段階が考えられるでしょう。次の例は、AWSを使っている企業が落ちないシステムを作るための話です。

  1. ソフトウェアが落ちても自動復旧する設計にする → 負荷が高まって、無理かもしれない
  2. オートスケールする設計にする → リージョン全体で障害が起きるかもしれない
  3. マルチリージョン構成にする → AWS自体で障害が起きるかもしれない
  4. ハイブリッドクラウドや、GCPなどその他のクラウドサービスを併用する

加えて、パフォーマンステストみたいなものを時間を取って行なうといった作業も必要になるでしょう。ソフトウェアまで踏み込むと、厳重なコードレビューをしたり、カバレッジ100%なテストなども必要かもしれません。

システムを他社に卸す企業ならまだしも、自社新規サービスやエンジニア数が限られていたら一層、これらはコスト的に見合うものではありません。要は、リスクマネジメント=いわゆる「程度の問題」です。

ただ、一つ考えておかないといけないのは、「もしこの障害が起きたとき、どう対応するか?」というのは検討しておくべきなように思います。

理由3:謝罪しても何も解決しない

謝罪をすれば責任者の溜飲は下がるかもしれませんが、それ以上に何も生産しません。責任者が怒ってなければ(“怒る”責任者じゃないことを期待しますが)、なお一層無意味な振る舞いです。

代案:反省しよう!

とはいえ、十分にシステムに対してやるべきことをできているとは思いません。やるべきことがないとも思いません。日々精進、日々改善です。

そこで代案として提案したいのは、謝罪しない代わりに、障害対応報告は必ず書いて反省しましょう、です(※そこに「申し訳ございませんでした」を書く必要はない)。

弊社の場合、次のような障害対応報告テンプレートがあり、それに則って書くようにしています。これは、システム障害にかぎらず、ソフトウェアバグに関しても使うことがあります。

# 障害概要 

# 発生原因 

# 対応内容 

# 再発防止策

自分の場合は「どういう調査をしたか」というのも書くようにしています。これは、また同じような障害が起きたとき、自分以外の人がその調査フローをなぞって切り分けできるようになるためです。

また、再発防止策は、具体的で、過剰な時間をかけずに一定の品質を担保し、直近取ることのできる策であることが特に大事なので、それを意識しています。

まとめ

  • 謝罪をするのはやめよう
  • 代わりに、反省をして、具体的な対策を考えよう
  • 日々精進

なぜ“まとも”なソフトウェアを作らなければいけないのか

私達まともなソフトウェアエンジニアは、まともなソフトウェアを作ろうとする。ソフトウェアエンジニアには、アプリのエンジニアだったり、サーバーサイドエンジニア、リサーチエンジニアなども含む。

まともなソフトウェアエンジニアは、テストコードを書く。ドキュメントを書く。CIも整備する。まともなクラス設計を考える。スケールするDB設計をする。ここでは、「まともなソフトウェアエンジニア」を「優秀なエンジニア」と定義し、「テストコードがあり、ドキュメントがあり、CIも整備され・・・」なソフトウェアのことを「まともなソフトウェア」と定義しよう。

つまり、優秀なソフトウェアエンジニアは、まともなソフトウェアを作る(※必要条件)。

まともなソフトウェアを作るのは、時間がかかる。テストコードを書けば、それだけ時間がかかる。クラス設計を議論しても時間がかかる。

なぜ私たちはまともなソフトウェアを作らないといけないのか

もちろん「まともなソフトウェアを作ってない会社に勤めたくないから」とか「単純に作るべきだと思うから」というのも理由としてあるし、実際それは正しい。「まともなソフトウェアじゃないと品質低くて提供できないでしょ」も正しい。けど、もう少し深掘りしながら、なぜまともなソフトウェアを作るべきかを考えてみたい。

私たちはまともなソフトウェアを作るべきで「ない」のか

まずは逆説的に、まともでないソフトウェアを作る場合のことを考えてみる。

まともでないソフトウェアはテストを書かなくていい。CIも整備しない。ドキュメントは書かない。クラス設計は適当。DBも逐次てきとーに作っていこうか。議論も不要。コードレビューもやめよう。

まともでないソフトウェアを作るのは、余分な時間をかけずに済みそうだ。まともなソフトウェアを作る金が100万円だとしたら、まともでないソフトウェアは30万円くらいで作れるかもしれない。

やったね! どうやら、まともでないソフトウェアを作るべきみたいだ。

まともでないソフトウェアの問題点

まともでないソフトウェアの問題点は明確だ。

まず、テストコードが書かれていない。テストコードのないソフトウェアの品質は良くないだろう。将来の改修でデグレ(過去、動いていたものが動かなくなること)を起こすかもしれない。試していなかったパターンでエラーが起きるかもしれない。

CI環境も整備されていない。つまりデプロイは毎回手動でやらないといけない。ミスが起きるかもしれないし、デプロイするたび時間がかかる。

レビューも設計もないので、コードの品質もひどい。それでは後から入った人が困るだろう。どんどんクラスが肥大化していって、改修もしづらくなるかもしれない。

まともでないソフトウェアの問題点の問題点

ここまではあたりまえ体操だが、もう一歩うがった見方をしてみる。果たして、まともでないソフトウェアの問題点は、本当に問題なのか?

テストコードが書かれてないと、どれくらい困るだろうか。人によって意見が異なるだろうが、自分の経験上、完全に一人で作っている場合や、運用を考えなくていい場合、テストコードがなくて困ることはあまりない(※完全に一人かつ運用を考えないというのは、かなり限定的な条件だ。つまり一般的には必要だと考えている)。要は、自分個人の記憶以上にスケールする必要がないとき、テストコードはなくても困ることは少ないと思う。

CI環境がないと、困るだろうか? これもサーバー規模があまり大きくなければ、正直あまり困らない。例えば、ssh して、git pull して、restart かければ良い。もしくは、自分の手元からそれらを自動化する簡単なシェルスクリプトがあれば、時間もかからない。

コード品質は、一人で作っているときであれば、気にしなくても短期的には困らないものの最たる例だろう。オレオレ設計は、オレの中で最大級にスケールする。

要は、短期的に一人でやる場合であれば、まともでないソフトウェアを作ってもあまり困らない、というのが正直なところなんじゃないかと思う(だから私含めてみんなサボるんだ……)。

なぜ、まともなソフトウェアを作るべきなのか

ここで「なぜ私たちはまともなソフトウェアを作るべきなのか」という疑問に対する私個人の答えを言うと、チーム開発を円滑にするためであったり、長期的に運用するため、ということだ。

「チーム開発を円滑に」というのは、今現在一人で作っている場合にも当てはまる。「長期的に運用」というのは、作り始めでも当てはまる。本当に今作っているソフトウェアを成長させたくて、人を増やしてチームを大きくしたくて、一年後もコードを書いていたいなら、やっぱりまともなソフトウェアを作るべきなんだと思う。そして、「チームのため」という目的のためにこそ、あるいは「チームのため」という目的を意識しながら、まともなソフトウェアを作るべきであり、まともなソフトウェア開発は、チーム開発に還元されるべきであると思う。

逆に言えば、まともでないソフトウェアを作ろうとしているのであれば、それはチームを大きくしたくないということであり、今後運用したくないということだと思う。

何故こんな疑問を書いたか

冒頭に言ったとおり、まともなソフトウェアを作るのは時間がかかる。まともでないソフトウェアは時間がかからない。(本当に優秀なエンジニアは、まともなソフトウェアを短時間で作るだろう、というツッコミは置いておく)

まともなソフトウェアを作りたいが、実際のビジネス要件は「早く、早く」であることも多い。そのためには単純に、テストやCI、ドキュメント、設計に掛ける時間を削ることもできるだろう。けれどもそれを安直に受け入れていいとは、どうしても思えなかった。

裏返して、ビジネス的視点で考えたとき、「僕がまともなソフトウェアを作ろうとするのは、どう正当化できるだろうか?」という疑問があった。だって自分が経営者だったら、速く成果物を作る人を評価するでしょ?

そういったバランスの中で、「なぜまともなソフトウェアを作らなければいけないのか」を考えることで、適切に“まともさ”にこだわることができるんじゃないかと思った。

まとめ

  • まともなソフトウェアを作るのは時間がかかる
  • チーム開発や運用を考えるならば、まともなソフトウェアを作るべきである
  • というか、「チーム開発や長期的な運用のため」を意識して、まともなソフトウェアを作りたい

補遺

こんなことを書くと、「経営者はまともなソフトウェアを書かせろ!」とか「おいあいつまともなソフトウェア書いてないじゃないか」とか「まともなソフトウェアはわしが育てた」とか言っているかのごとしですが、そういうのは全くないし、一切の皮肉を含んでいません(汗 あくまで、自分が開発する上で何考えないといけないんだっけ、っていう思考の出発点のつもりです。

ちなみに自分がいるプロジェクトは、テストコードがあって、後からジョインしたら大変助けられたパターンです。

2016 / 2017 総括と今年の目標と今後の方向性と

2016年の振り返りと、2017年の抱負とか。

2016年の総括

2016年は、本当に大変な年だった。おわり。

目次

  • 体重キープした件
  • 家出れるようになった件
  • 君の名はまだ見てない件
  • おうちハックしたい件
  • 今年やった技術とか
  • 今後の方向性とかに悩んでいる件

体重キープした件

大変素晴らしいことに、1年間体重を76kg前後にキープした。毎日体重を計測して、 Twitter のプロフィールに自動反映しているのが効を奏していると思う。オムロンのNFC体重計スマホをぴっとやると、TwitterAPIを叩いて変更する仕組み

家出れるようになった件

大変驚くべきことに、何もなくても家出れるようになった。これだけ書くと人間としてやばいっぽいが、休日家でごろごろマンは多いと思う。

引っ越したのが要因として大きい。徒歩圏内に、Wi-fiと電源のある、まあまあ入れるチェーン店のカフェが複数あるのが大事(スタバと上島珈琲店がある)。今後引っ越すとしても、繁華街の近くに引っ越すのが戦略として正しいっぽい。

君の名はまだ見てない件

シン・ゴジラは見たんだけど、まだ君の名はを見ていない。新宿の映画館とかでまだやっているそうなので、1月中に見に行きたいなと思う。

映画というところで言うと、2016年はギンレイホールに初めて行ってみた。ギンレイホールというのは、いわゆる「名画座」というジャンルの映画館。入れ替え制じゃないので、一回のチケットで2本映画を見られる。雰囲気のわりにはチョイスが古すぎるわけではなく、昨年アカデミー賞とかもやってる。

おうちハックしたい件

おうちハックというのは、家にIoT系の製品とか、Arduinoとかラズパイ取り入れたりする振る舞いのこと。おうちハックできなかったのは、2016年の目標の中で、ちょっと後悔しているものだったりする。

おうちハックに使えそうなものは結構揃ってて、

  • Raspberry Pi 3 Model B
  • IRKit
  • milight とかいう Hue のパクリ製品
  • ルンバ(リモコン付き)
  • mornin という電動カーテン

家に帰ったら、「おかえりなさい」って言いながら、やってないタスクとかを読み上げながら詰ってくるホームアシスタント作りたいなって思っている(もしかして:ジャーヴィス)。AWS に読み上げお姉さん API あるしね。

今年やった技術とか

  • Docker
  • BigQuery
  • AWS Lambda
  • Akka (Scala)
  • Vue.js まわり
  • keras
  • Go

だいたいこんな感じかも。Vue.js とkerasとGoは触りに近いかなorz

結果的には、Docker、Akka、Vue.js はかなり自分の役に立った。特に、プロトタイプ環境やデータ可視化環境を作るのに、Docker と Vue.js が大活躍していて、そのうちブログに書きたい。JSのReactiveなビューライブラリ界隈は、行き着くところはReactでもVue.jsでも(触ったこと無ないがRiot.jsでも)良いと思っていて、けど「手軽にさくっと」みたいな用途だと Vue.js が個人的に良かった。

Go は、本当に手に馴染まなくて辛かった。機会作ってまたやりたい。

機械学習周りは、今年あんまりできなかったなぁ・・・が、クリスマスに会社にGPUサーバーをお願いしたら予算がおりたので、頑張るぞい。GPU使う部でも作ろうかな。会社のデータ資産に機械学習をアプライするっていうところは、自分主導でいろいろと進めたいところ。

今後の方向性に悩む件

僕個人は、メインには技術をやりたいと思っている。特に機械学習周り(もっというとNLP)をビジネスに適用する、という分野に興味がある。これは、全くぶれていない。

唯一ぶれたのは、機械学習というものに対して、「キラキラ技術したいなあ」ではなく「ビジネスを真剣に考えて、課題解決をしたいなあ、あわよくばキラキラ state-of-the-art 良いなあ」という気持ちになったところ。つまりプライオリティが変わった。あと、「NLPって結局ルールベースが一番早いしメンテナブルやんけ!」みたいな諦めも若干あったりする(これを覆せないのは、完全に自分の経験不足に起因する)。

けど、PM的な立場についになってしまった。「なってしまった」というのは完全に言葉の綾で、どちらかといえば真面目にちゃんとマネジメントに取り組みたいし、そういう旨のことを経営陣に言って、そういう立場に置いてもらった、というのが説明として正しい。「自動化できる人間」たるエンジニア、そして「エンジニアの気持ちがわかる人間」たるエンジニアがマネジメントをするというのはとても大事なことで(私が人間の気持ちがわかるとは言っていない)、それは非エンジニアのマネジメントスペシャリストにはない視点。そういうところに問題意識を感じたりするので、「責任と裁量を持って、意見を述べたい」という旨のことを言ったのだった。

さて、ここにコンフリクトが発生する。「マネジメントに真剣に取り組みたい」も真だし、「機械学習のビジネス適用を真剣に取り組みたい」も真だけど、自分の体が一つしかない。

まあ、コンフリクトを解消する手法は単純で、残業とかもっと減らして(弊社、本来はホワイト企業なんだが、仕事脳なので一人ブラック企業している節がある)、周りを巻き込みながら勉強と実践する時間をもっと増やす、というのが正解っぽいし、これを今年一番の目標としたい。せっかくマネジメント側の機能を持つわけだしね、自分もチームも、残業なしに働けるように、頑張らないといけないね。

真人間になるための今年の目標

  • 残業時間を減らす(週に5時間くらいにしたい)
  • 週に5日は1〜2時までに寝る生活習慣を作る
  • 会社のGPUを活用する部を作る
  • ホームアシスタントを作る
  • 今年二回は旅行に行く。一回は一人旅をする。
  • 月に一回は映画館で映画を見る
  • 休日コンスタントに12時ぐらいに家出れるようになる
  • 体重をキープする
  • 週一程度で弁当を作る

振り返ってみたけど、1年というのは振り返るには長すぎるかもしれない。半年ぐらいで振り返りたい。

Dockerfileを生産性高く書く方法についてLTしてきた

10月21日(金)に、JX通信社内での勉強会でDockerfileを生産性高く書く方法のLTをした。

この3ヶ月で、公開しているものだけでも8個ぐらいDockerイメージを作ったらしいw

↑のスライドの要旨を言うと、 Dockerfileを書くときはTmuxとSlimeを活用しましょう!ということ。

Dockerfileを書くとき、「全部書く」→「docker build」→「修正」→「docker build」→「修正」→「docker build」みたいなことをやってると、かなり生産性が悪い。処理の途中でエラーが起きたりするし、apt-getしないといけないものが後から出てきたりする。その度に docker build していると、時間がかかってしまう。

そこで、tmuxとslimeを活用して、Dockerfileを一行ごとに検証していくと良いですよという話。 Tmuxは、Screenとかと一緒で、ターミナルを画面分割して表示するためのもの。 Slime(やその類似プラグイン)は、Tmuxの他のペイン(つまり画面分割した先)に、エディタ上のコードを送って実行するためのもの。

勉強会の様子↓ モニターの裏には泡盛が・・・

f:id:yamitzky:20161021202656p:plain

さて、そんなJX通信社では、エンジニアを募集しています! 興味のある方はぜひお声がけください! Docker力とサーバーレス力がめちゃくちゃ高まる

ちなみに社内勉強会の名前の案を募集したら、社長が大喜利を始める弊社w

f:id:yamitzky:20161021203115p:plain

25歳になった / 労働についてのあれこれ

もう誕生日から2ヶ月経つが、8月末に25歳になった。
お祝いを頂いた方、本当にありがとうございましたm(_ _)m

ちょうど今年は転職した“転機”で、転職して一段落経ったし、最近思ったこととか、気持ちの変化とか書いてみようかなと思う。

アプリのサーバーサイドを作って思ったこと

この半年間、NewsDigestというアプリのサーバーサイドを作ってきた。
そこで得た結論を言うと「アプリを作る上で、フロントエンドエンジニアが一番偉い」だ。

アプリの品質・面白さをコントロールする上で、最も直接的に影響があるのは、UI/UXだと思う。
いろいろ施策を毎日考えるが、「サーバーサイド不要でできる施策」はたくさんあるが「フロントエンド不要でできる施策」はあまり多くない。
どんな施策を考えても、結局フロントエンドエンジニアが作ってくれなきゃ何もならないのだ。。。

そもそも、この2016年において、フロントエンドエンジニアがウェブのバックエンドを“書かずに作る”方法はたくさんある。
ParseとかFirebaseとかのmBaaSを使えば良い。
実際NewsDigestでもParseを使っているので、僕のようなサーバーサイドエンジニアがやっているのは「配信アルゴリズムエンジニア」だ。
フロントエンドエンジニアが「Webの仕組みがわからないのでできない」という壁はあまり高くない。

だからそのうちフロントエンドをまたやりたいな、というのは正直思ったりする。何年後でも。
でもKotlinのプロジェクトが良いな。笑

5年後価値のあるエンジニア

「5年後、価値のあるエンジニアは誰か」という問題は難しい。

5年前を思い出してみると、AWSは今ほど使われてないし(公開されたの2006年だって!)、Dockerも存在しない。Sparkもないらしい。
GoやNodeは一応あるが、Scalaや関数型も今ほど流行ってないし、ECMAScriptの状況も全然違っただろう。
サーバーレスなんて言葉もなく、RX系もそんなに流行ってないだろうな。知らんけど。

5年後、「Webアプリケーションを作る」という言葉が示すものは、少なからず変わっているだろう。

自分の場合は、答えを出すのをやめたけれども、考え続けてはいる。

ベンチャー機械学習分野を活用すること

機械学習が“最近”コモディティ化して、個人がやりやすくなった、というのはやっぱり誤っていると思う。
今も5年前も、適切な問題設定をすれば、sklearnやらを使って問題を解くことは可能だったはずだ。
ちなみにTheanoも5年前からある。

「適切な問題設定があれば、一定の問題を、一定の品質で、既存のモデルで解く」
そのラインを超えた先、というのは何なんだろう? と、ずーっと考えていた。

一つは、大規模な学習、具体的に言い換えるとディープラーニング系のトピックを追うことだろう。
ただし「大企業が」「大規模なデータで」「大規模なインフラで」というのが大抵の枕詞だ。
(※少年ジャンプと同じように、3つのキーワードが揃わなくても良い)
他に、最新の手法を作っていく、というのもあるだろう。

そしてもう一つ、「ビジネス要件を理解し、新しい問題設定を作る」 というのがあると思う。
例えば出会い系サービスで「人工知能」を活用するとしたら、学術分野では決して出てこないような案や仮説・手法が出てくるだろう。
そのような洞察は、機械学習分野への知見だけでなく、ビジネスへの深い理解から来る。
ただし、ビジネス理解を突き詰めても、必ずしも学問的・技術的に新しいものは生まれるわけではない。

自分が、自社が、前者と後者どちらで行くのか、というのは考えた方が良いと思う。

労働において重視するものの心境変化

自分はもともとエンジニアとして「機械学習」とか「データ」のドメインに張りたかったというところで会社を選んできた。
ベンチャーを主戦場にしてね。

今、転職して、それなりに好き勝手やってるんだけど(分類サーバーとかログ基盤とか作ってる)、どっぷり浸かるほどやれてるわけではない。
転職直前の方が時間比重的には多いと思う。
かと言ってそこに大きく不満があるかというと、そうでもない。

そのことに気づいて、改めて、なぜ機械学習/データ分野をやるべきだと思ったのか、というのを考え直して見ると、 「難しい問題を自分の武器で解き、市場で希少価値のあるエンジニアになりたい」ということだったんじゃないかと思う。
(もちろん、単純に面白いからっていうのが一番大きいけどね。減ったけど、今でも公私で論文読むし)

「難しい問題を自分の武器で解く」を高めるために、もっと高度な手法、もっと大規模な手法、という風に手を伸ばしていくことも必要だと思うんだけど、 自分個人は、ビジネス理解を深めたり、あの手この手を考えて、それが必ずしも「高度」じゃなくても解決していくことに、面白みを感じてしまった。
それはもはや「エンジニアとして『機械学習』とか『データ』のドメインに張る」ということによる高みではない。

勉強からのドロップアウトとも怠惰とも言い換えられて、それで良いのかという悶々としたものはある。
週末・業務後に勉強したりいろいろ試したりするけど、あんまり身が入らない感じもあって焦っている。

まあ、かなり悩んでいたり焦っているけど、別の楽しみを見つけたのが今の状態、というところ。
一言で言えばたるんでるけど、楽しいので、なんとも言えない。
「技術的・学術的高み」と「ビジネス理解から来る課題解決」をうまく結び直すのが、今後の自分の宿題なんだろう。

Webエンジニアの職種を変えるとしたら

僕は結構映画が好きだったり、テクノロジー系イベント(VRとかDMM.planetsみたいな)行ったりするんだけど、 テクノロジーで人を感動させるのってすごいなーと思う。
Computer Vision系の研究とか見ると、本当にすごい(ディズニーとか)
Perfumeのライブ行ったことないんだけどすごそうだし。

だからもし職種を変えるとしたら、テクノロジーで人を感動させる仕事をやりたいなと本気で思ったりする。
もしくは同人でやるとか。
数年後にはVRコンテンツをインディーズが作れるようになって、いろいろ変わっているだろう。 (Unityの無料化とかUnreal Engineとか、ここ数年だしね)

大学院に行きたいなと思ったことがある話

自分は学部卒なんだけど、特定の学問を“修了”できなかったこととか、ちゃんと勉強しなかったこととか、学部時代の研究への心残りとかがいろいろある。

会社員になってみて気づいたのは、自分は学生時代に「プロセス」を全く知らなかった。課題解決的な思考方法というのが全くなかった。
あと9時に起きるという習慣も、勉強する習慣もなかった。とにかく怠惰だったな。苦笑

逆に、会社員経験を経てから学生に戻れば、学問とは別の“武器”を持った上で戦えるのかな、とは思う。

決して今ではないんだけど、ある程度人生に余裕ができたら進学したいな、というのは一つの選択肢として思っている。

次の転機

次の転機は、漠然と「5年後」だろうなと思っている。

会社は今のx倍になっているだろうし、事業は変わっているかもしれないし、自分の立ち位置は随分と変わっているだろう。
そのとき残るのか、転職するのか、起業するのか、入学するのか。
何か1つまたは2つを、明確に“選択”することになるだろうなと思うけど、選択はきっとポジティブな理由だろう。

最近見たもの

最近のオススメで言うと、

の3点、ご査収ください。

ライトノベル原作しばらく見てなかったけど、面白かったな。

今期は亜人が楽しみなのと、テラハ新シリーズが楽しみです。

最近買ったもの

最近買ってよかったなと思うのは、

  • ケルヒャーの高圧洗浄機・・・水回りの掃除が楽になります
  • ルンバ

あたりかなぁ。今は乾燥機付き洗濯機を買いたいけど、家の蛇口が低くてダメ。

終わりに

随分と長く、面白くもないポエムを書いてしまった。

また半年後か1年後ぐらいに、いろいろ心境変化があるだろうし、言語化できたらまた書こうかな。

おわり。

俺がTerraformファイルをいじるときに使ってるツールを雑に紹介する

Terraformは、インフラ管理をコードで管理するためのツールです。具体的にJXでは、AWSのインフラを管理するのに使っています。「インフラを管理する」というのは、今までだったらAWSのWeb管理画面(コンソール)やらAWS CLIでやっていたような作業を、ソースコード(以下、Terraform設定ファイル)で管理できるようになります。

さて、そんなTerraform設定ファイルの編集ですが、正直に言ってかなり時間がかかります。具体的には、AWSとかのリソース名とか覚えていられないし、変数とかも覚えていられないし、リソースに必須なプロパティとか覚えていられないわけです。それをいちいち調べるのがとても時間かかります。

自分なりにいろいろ試してみて、生産性があがったツールを2つ紹介します。

1. IntelliJ(無料)

ひとつ目は、IDEIntelliJ IDEAです。ScalaとかJavaとかを扱うあれです。PyCharmでも構いません。コミュニティエディション(無料)でも使えます。

IDEで編集すると聞くと大仰に感じるかもしれませんが、HCL Language Supportのプラグインが死ぬほど使いやすいです。

とにかく補完が効きます。事前定義済みのAWSのリソース名はもちろんのこと、自分で定義したリソース名や変数名なども補完が効きます。さらに、必須のプロパティが設定されてないと、黄色くなって教えてくれます(Option+Enterで、必須プロパティを全部入力してくれます)。

例)必須プロパティの補完

f:id:yamitzky:20160801164236p:plain

Option + Enterを押すと、、、

f:id:yamitzky:20160801164307p:plain

例)リソース名の補完

f:id:yamitzky:20160801164443p:plain

2. Dash (有料; $24.99)

ふたつ目は、ドキュメント検索ツールのDashです。有料ですが、使い勝手の悪さをガマンすれば無料で使えるはずです。

Dashは、各種言語などの(公式)ドキュメントを検索することができます。なので、リソースのプロパティの細かい仕様を知らなくても、すぐに調べられるわけですね。

しかも、ローカルにキャッシュしてくれるので、とても速いです。わからなくて、ググッて、ネットワークの接続待って、公式ページに辿り着いて、ネットワークの接続待って、、、ってしなくて良いので、かなり効率が上がります。

例)検索

f:id:yamitzky:20160801164910p:plain

公式ドキュメントが表示されます

f:id:yamitzky:20160801164930p:plain

まとめ

以上、2ツールを紹介しました。他に便利なものがあったら教えて下さい。