ハッピーバースデー&ドワンゴ退職
はじめに
ハッピーバースデートゥーミー
ハッピーバースデーディア僕
今日2月20日は僕の誕生日です。
10年ぶりに新しい職場で迎えた誕生日なのでblogを書こうと思います。
そう、ドワンゴの退職エントリです。
と言ってもやめたのは去年、2019年6月で本当はその時に退職エントリを書いてたんですが
今公開するとまずいかなと思って出すタイミングを見計っててました。
www.itmedia.co.jp
ですがちょうど黒字化したようですしいいかなと思って公開します。
何やってた人なの？
というわけでちょっと自己紹介します。
2009年4月に新卒で入社したエンジニアです。
関わってきたシステム/プロジェクトはというと、ガラケー向けサイトの dwango.jp のシステムに新卒配属後
2009年の9月からニコニコ生放送に異動を皮切りに
ニコニコアンケート立ち上げプロジェクト、
そのあとは nicocas(2014年のあの5日程度で閉じたやつ)立ち上げ、
ニコニコのiPhoneアプリチーム、
そしてまた nicocas(2018年にリリースして最近ニコ生専用アプリになった奴)のiOSアプリ立ち上げ
そのあとまたニコニコのiPhoneアプリチーム。
とまぁいろんなチームに異動し様々なシステムに関わらせてもらいました(たらい回しともいう)。
で、今年の2019年4月でちょうど10年ということになります。なかなか長いですね。
なぜ今まで辞めなかったのか
退職エントリはだいたい辞める理由を書くものですが、
今までやめなかった理由というのもかいてみようかなと思います。
というのも流石に10年いるといろんなことがあってやはりまぁまぁひどい状況というのはそれなりに味わってきましたし、
実際後輩に「なんでこんな目にあってんのにやめないんですか僕だったらやめます！」って言われたことさえあります。
ぶっちゃけ2012年ごろには転職活動をしています。
そんな中辞めなかったの理由を思い返すと
一緒のチームで働いたエンジニアに優秀でかつ面白い人間が多かった、というのがあるなと思ってます。
ドワンゴに入ってくる新卒は優秀な人が多いんですが
特に2013年以降、mesoさんが人事になってから入ってくる新卒のレベルが一気に底上げされた印象があります。
ついこないだ入ってきた新卒の子に「もっと今はいい方法あるのにしらないんですか」とか
「今時こんなデプロイ方法します？」とか煽られるのは刺激的で本当に楽しかったです。
もちろん、若い子だけでなく自分より年上のエンジニアにも面白くて優秀な人が多かったです。
(特にk1さんやngtmさんには本当にお世話になりました)
なのでまとめていうと辛いことも多かったけど支えてくれる人たちに恵まれた、幸運だったということだと思います。
(もちろんここにかけない理由もあるんですがそれは飲んだ時にでも)
じゃあなんでやめたのか
じゃあなぜそういう人に恵まれながらやめたのかというと
シンプルな理由で「知り合いに面白そうな仕事に誘われた」からです。
自分に期待されていること、やらなければいけないであろうことを
それを放り投げて自分だけ面白そうな仕事をするってどうなのよという後ろめたさはあったんですが、
ニコニコアンケート時代の偉い人に面白そうな仕事に誘われたので転職しようと思ってます、と伝えたところ
「人間あっと言う間に歳を取る。面白そうな仕事があったらすぐにやるべきだ」
と言われたのは本当にありがたかったです。
就職活動中のITエンジニアへ
さて、もしあなたがコードを書くことにこだわりがあり、かつ悪ふざけが好きで
深夜の大学の研究室みたいな雰囲気が苦手ではないITエンジニアなのであれば
是非ドワンゴをおすすめしたいです。
ドワンゴ は前述したように技術が好きで面白い人が多く
配属ガチャがあるので100%の保証はできませんが、楽しく仕事できるんじゃないかなと思います。
僕自身そんな中で20代と30代前半を過ごせたのは幸運だったと思ってます。
もちろんいいことばかりではなく問題点もいくつかあります
(というか、あげようと思えばいくらでも挙げられるのですが)
その中で辞める際に一番気になったのが
主観ではありますがシニアエンジニアのキャリアパスが定まっていない、ということです。
僕が退職した際、エンジニアのキャリアパスはマネージャーかスペシャリストの2択でした(現状はわからない)
マネージャー以外の道があるのは素晴らしいことだとは思うのですが
マネージャでもスペシャリストでもないが
チームの中で重要な役割をはたしてるシニアエンジニアの評価がうまくできてないのではないか、という感があります。
ただ、これはドワンゴのみならず、IT業界全体の問題でもある気がしてますし、
そこは業界全体でよくなって行くんじゃないかな、行って欲しいなという楽観的な希望を持っています。
現職のエンジニアの人たちへ
最後に、ニコニコ/ドワンゴはもう終わりだ、組織として問題がある、みたいなのをよくネットで見ます。
僕は万年平社員だったし経営周りに携わってたわけではないのでそれはわかりません。
ただ、その中で一つ言えることがあって
それは現在のニコニコの開発系の部長陣(TD)は皆、
手段はどうであれ何かが起きたら真っ先に泥水をすする覚悟のある人たちである、ということです。
あの状況から黒字化させたということは
多分現場からみてキツイこと納得行かないこともあったと思います。
(もちろんなければそれに越したことはないのですが)
それは決して現場を軽視した結果ではなく
なんとかして会社を持ち直そう、物事をよりよくしようとしてなるべくしてなった結果だと思います。
そして10年でいろんな部署を回った感想として、
どんなところでも完全に理想的な場所(会社/組織)というのはあり得ず、
どこかで腹を決めて大きな泥の塊と戦わなければいけない時がくる、ということです。
(泥は負債コードだけでなく運用やらコミュニケーション、体制の問題だったりします)
その際、その泥と戦う時間が無駄だと思うのであればやめるのもいいでしょう。
そして僕と同じようにもっと面白いことが見つかればそっちにいくのもありです。
一方で泥と戦ってみるという選択肢もあると思ってます。
人生の時間の使い方をどのように決めるかは人の自由です。
辞めた僕から言える義理ではないんですが、なんとか頑張って欲しいと思っています。
P.S
なんかよくわからないのですが、エンジニアの退職エントリに最後ってみんな Amazon のウィッシュリスト貼りますよね。
なんででしょうね？
退職したからプレゼントくれ、というのはちょっとおかしい気がします。
僕は今日が誕生日です。退職したからではないです。
というわけで誕生日プレゼントとしてウィッシュリスト貼ります。
誕生日からすぎたとしても全然OKです
よろしくお願いします。
https://www.amazon.co.jp/hz/wishlist/ls/30PJ2W3I7TZEH
どうもアドバイスおじさんです
lady_joker さんのこのblogを読んでぐささぁーって来たので懺悔。
後輩のエンジニアの子と相互フォローしてたりするんだけども
その子が趣味のコード/プロダクトとかを作ったりしたのをtweetするんだよね。
で、やっぱ悪手と思える手法をとってたりすると思わず言っちゃう。
リプライ飛ばしちゃう。
「その手法よりこの手法の方がいいんじゃない」とか。
もちろん10年ぐらいプロとして仕事してきてるわけなのでそれほど外したことは言ってはいないと思うんだけども
たとえそうだったとしても
その過程でもし助言が必要ならば、それを誰に求めるかを決める主導権は100%クリエイターの側にある。
アドバイスおじさんに花束を - lady_jokerのはてなブログ
この部分は本当にそのとおりで、
もちろん仕事上ではプロダクトクオリティに直結するので問題があればアドバイスするのは当たり前なのだけれども
趣味のプロダクトへのアドバイスは気をつけるべきだったなぁと反省。
特に知り合いなわけだから、本当に困ってて僕を信用してるのであれば彼の方から聞いてくるわけだしね。
ところで、lady_jokerさんはアドバイスおじさんの行動原理を
アドバイスおじさんの動機は善意ですらなく、ただの支配欲か承認欲求である。
アドバイスおじさんに花束を - lady_jokerのはてなブログ
と想定してるんだけどもそうとも限らないんじゃないかなと思う。(もちろんそう言う人もいるだろうけど)
というか僕の場合はちょっと違うんです。
「正しさ/正解」の虜なんです。いや、細かくいえば「自分が正解だと思う物」の虜なんですよ。
「なんか違うな、間違ってるな」って見えるモノを指摘してしまう。
相手がどうでもいい人間だった場合は何も言わないんだけども大切な人間であると言ってしまう。
結構この正しさの虜というのは厄介で、間違ったこと言ってないんだから、あなたのためなんだからにつながってしまう。
短期的に見れば確かに失敗によって時間の無駄遣いを防げるのでよいことではあるんだけど
長期的にみると失敗を踏んでそこからリカバリをするという重要な経験を奪ってるんだよね。
仕事で扱うシステムが大きくなって金を産むようになってそこで失敗が許されなくなってきてるからこそ
趣味で色々試してる子から失敗という経験を奪うのは想像以上に残酷なんですよね。
lady_joker さんの記事を読んでｳｯて反省すると同時に
これが刺さるということは「正しさ」への執着を捨てて若い子の失敗を見守るフェーズにはいったんだなぁと
おじさんになったんだなぁと思わず blog を数年ぶりに書いてしまった。
はぁ。
僕も非エンジニアになんで糞コードがだめか説明してみる
yamashiroさんの
で
他にいいメタファーあったら、ブクマやらコメントやら、ブログ別書くなどして、
世界を幸せにしてもらいたい。
ってあったので考えてみた。
プロダクト黎明期
とある会社になにも入っていない新しい倉庫があります
あるとき、倉庫番は経営者から本棚を倉庫にしまってほしいと言われます
倉庫には何もありません、すぐに倉庫にしまえるでしょう
そして、もし、その倉庫番が仕事のスピードを重視する人であれば
本棚は出入り口の近くにおかれるでしょう。
ある日、今度は本棚をとってき飾り付けしてほしい、といわれます。
本棚は出入り口の近くです。すぐに取って来れるでしょう。
また、数日がたち、今度は冷蔵庫をしまってほしいと言われます
冷蔵庫も取り出しやすいように出入り口の近くにおかれるでしょう
そんな感じでどんどんものを入れたり出したりしていきます
プロダクト発展期
月日がながれ
倉庫の中は今やいろんなものでいっぱいです。
そしてその初代の倉庫番もやめてしまっています。
どこに何があるかの資料も残ってません。
あなたはn代目ぐらいの倉庫番です
経営者は言います、
"本棚とって来て"と
しかし、まず、本棚がどこにあるかわかりません。
そして見つけて引っ張りだそうにもまず出入り口に積まれたものが邪魔で出せません
結局、後片付けも含めるととってくるのに何日かかってしまいました
そーなると経営者からこーいわれるわけです
『ちょっと、初代の倉庫番と比べてかなり仕事おそいんだけど！初代なら1時間で終わってたよ、その作業！』
確かに経営者から見れば
"倉庫から本棚を取ってきて"
という命令は同じです。
なので、この倉庫番は使えない、という評価になってしまうのです。
あなたからすると、おいおい、状況が違うだろ、ですよね。
でも経営者からみたらそんなのわからないので無能呼ばわりされるわけです。
どこに何があるか、どこにどうおくべきか、先代より頭使っているにも関わらず。。。。
やってられませんよね。
プロダクト衰退期
あるときあなたは、定期的にに倉庫の整理を行っている会社を見学してみます。
その会社は定期的に整理し、記録をつけているからどこに何があるかはだいたいわかってます。
もちろん入り口を塞ぐものはなく、そこから重機を入れることができます。
なので、重いものを運ぶのは重機任せです。
そして仕事が早く終わる、倉庫番たちは評価されていて給料も良いです。
そして、重機の操作といった様々なノウハウがたまっていきます。
それを見て思うはずです、うちも重機入れよう、と。
しかし、入れようとして気づくのです、入り口が詰まっていて重機を入れたくても入れられない。
結局、重いものを一人で運ぶから時々壊したりしてこれまた叱られたり減給されたりします。
そーいうのに堪え兼ねてどんどん仲間はやめていきます
解説
いうまでもなく、倉庫っていうのはプロダクトの事。
冷蔵庫とか本棚とかは"機能"の事で重機はjenkinsとかのCIツールの事。
で、そのぐちゃぐちゃの倉庫の会社にいると、なんもノウハウが身に付かないのか、というとそー言う訳じゃないです。
〜〜を置く時は普通におけないから斜めにして置く、とかそーいうノウハウは身に付きますよ。
ただ、会社をやめた時に気づくのです。
それがその会社でしか通用しないという事に。
一方、重機を扱うノウハウはいろんなところで使えるでしょう。
だから優秀な人ほど、リスクヘッジも考える訳ですから、そんな倉庫がぐっちゃぐっちゃな会社に居続けようとは思わないですよね。
で、優秀な人はそーいう会社には来なくなるので、ますます酷くなっていく、というわけです。おしまい
Flash 3大Domainのお話 - ApplicationDomain編 -
Flashの3大Domain
- ApplicationDomain
- SecurityDomain
- crossdomain.xml
(crossdomainの下りは無理矢理)
ここらへんの単語はFlash開発していて良く聞くけど、あんまりきちんと解りやすい説明がない。
いや、ない訳じゃないんだけど、なんか解りづらい。
というわけで記事を書いてみる。
で、今回はApplicationDomainのお話。
解りにくい概要はここに書いてある。
(http://help.adobe.com/ja_JP/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e07.html)
Loaderでswfファイルを読み込んださい、読み込み元swf、読み込まれたswf、相互に内部のMovieClipやクラスにアクセスできるのだが
ApplicationDomainを使うとそのアクセス関係を制御できるというお話。
つまり、A.swfがB.swfを読み込んだ際、A.swfからB.swf内部のクラスを使う事を許可、不許可の設定ができるのだ。(もちろん、その逆方向も可能)
そしてそのApplicationDomainの設定の仕方は全部で3通り
- 新しいApplicationDomainを割り当てる (使用形態A)
- 読み込み元と同じApplicationDomainを割り当てる(使用形態B)
- 読み込み元の子としてApplicationDomainを割り当てる(使用形態C)
使用形態Aの場合
基本的にこの設定がデフォルト(だと思ってる)。
同じパッケージ名、同じ名称のクラスが読み込み元、読み込まれたswfに有った場合、同じApplicationDomainだと読み込まれた側のswf内部のクラスが上書きされてしまい、予想外の挙動をしてしまう。
例えば、読み込み元のA.swfにも、読み込まれたB.swfにもHogeという名称のクラスが有ったばあい、
B.swf内部にあるHogeクラスはA.swfのHogeクラスと同じものと見なされる。
一方新しいApplicationDomainを割り当てると
A.swf::Hoge
B.swf::Hoge
というクラスに内部的にはなる。なので、内部実装がよくわからないswfを読み込む場合とかに設定する。
使用形態Bの場合
前述したけど、読み込む際にApplicationDomain.currentDomainを指定すると
B.swf内部にあるHogeクラスはA.swfのHogeクラスと同じものと見なされる。
これは、特定のケース時のみHogeというクラスが必要になるけど、普段はいらない、というときに便利だ。
Loaderで必要なクラスを読み込んで使える様にする訳だから、普段はそのHogeのクラス分だけのswfバイナリサイズを小さくできる。
バイナリサイズが小さくできる、という事はユーザーがswfを表示させるまでの時間を短縮できるし、起動も速くなるという事でもある。
ただ、この方法使う際、swfを読み込む前にHogeクラスを参照してしまうとVerifyErrorが飛ぶので注意が必要。また、細かく分けすぎると、読み込む際のオーバーヘッドがでかくなりそのクラスを使用する際の処理が重くなってしまうのも注意(やり過ぎると、だけど)
使用形態Cの場合
2の場合も結構特殊だが、この場合はかなり特殊。
さっき書いたadobe様のリンク先によると
現在のドメインの新しい子ドメインを作成することにより、親のクラス定義を使用します。図では、"module3.swf" に対するアプリケーションドメインとして現在のドメインの子ドメインを設定しており、子ドメインでは、親ドメインに含まれるすべてのクラス定義を使用します。
この形態の用途としては、複数画面の RIA (高度なインターネットアプリケーション) を構成するモジュールをメインアプリケーションの子としてロードし、メインアプリケーションで定義されている型をモジュール内でも使用できるようにすることが考えられます。
クラスを更新される際に必ず後方互換性を維持するようにし、また、ロードされるモジュールよりもメインアプリケーションを常に新しくしておけば、メインアプリケーションに含まれるクラス定義はモジュール内でも使用されます。 また、このようにして新しいアプリケーションドメイン内にロードしたモジュールは、アンロードすれば、すべてのクラス定義をガベージコレクションの対象とすることができます (ただし、子 SWF への参照を確実に破棄する必要があります)。
このテクニックでは、ロードする側にあるシングルトンオブジェクトや静的クラスメンバーを、ロードされる側のモジュールでも共有できます。
とある。たぶん、この文章で一発で意味解る人は少ないと思う(僕は最初意味が分からなかった)。
簡単に言ってしまうとFlashでゲーム等のプラットフォームみたいなのを作る際に必要になる。
一般的に、プラットフォームを作る場合、プラットフォーム側がAPIクラスを用意してやり、アプリケーション側がそのAPIを使う。
このFlashの場合でいうと、読み込み元がプラットフォーム、読み込まれた側がアプリケーションとなる。
で、読み込み元と読み込まれた側のswfが違うApplicationDomainだとA、Bから読み込み元のAPIクラスが利用できない。かといって読み込み元と読み込まれたswfを単純に同じApplicationDomainにしてしまうと今度はAとBで同じ名称のクラスが有った場合コンフリクトを起こす。
上図の様に、読み込み元とはApplicationDomainは同じだけど、読み込まれたswf同士ではApplicationDomainを変えたい時にこの設定を利用する。
この設定ならば、子のApplicationDomainは親が用意したAPIクラスにアクセスできるが、子同士はアクセスできないので安心。
こんな感じで書いてみたけど、わかりやすかっただろうか。
マー気にせず、次はSecurityDomain周りのお話をします
続きは『鯖』で
僕は仕事でとあるwebサービスのFlashのクライアントアプリを作っている。
その仕事ではまったところとか、得た知識を業務規約に触れない程度で書いていこうと思う。
もちろん、それ以外にも日常的な事も。
で、タイトルなんだけど、僕は仕事の際によく「ここまではクライアントサイドで、続きはサーバサイドで処理します」みたいな事を言う。
だから、タイトルが「続きは『鯖』で」
わからない事があったら『鯖』側で。
