16/10/22 14:23:18.29 0czkjYs30.net
ドワンゴは大量退職に関する印象操作をやめろ
URLﾘﾝｸ(hiroki-uemura.hateblo.jp)
2. 顧みられない開発体制
ドワンゴは数年前まで「ニコニコ動画を3日で作った」とよく自画自賛していました。
最近はその話をしなくなって、ようやく良識ができたのかなと思っています。
というのも、サービスを急遽作り直して3日でリリースというのは決して褒められることではないからです。
僕はこれを批判して「ニコニコ動画は3日で作られたことによって、その後の3年を失った」と言っています。
当時のドワンゴでは担当の開発者達には明確な納期は伝えられず、
ある日唐突に発表されるXX日に新機能がリリースされるというプレスリリースによって初めて知ることが多くありました。
プレスリリースを打った以上その日にその機能がリリースされることは絶対で、間に合わないということは「起きない」という空気です。
サービスごとにコードベースは共有されず、突貫で作られた新サービスで同じようなバグが何度も発生しました。
ひとたびサービスが動き始めれば、リファクタリングは二度と行えません。
動いているものに手を入れて、動かなくなるかもしれないリスクをとる必要性を、スケジュールの決定権を持つ人間が理解できないのです。
それに加えて過剰な機能追加が繰り返し行われ、
目論見が外れほとんどの人間が使わなくなった機能でも停止することができず、
無限に複雑さが増していくばかりでした。
日に日に開発難易度が上がっていくばかりのコードを前に、僕は心がポッキリと折れました。
これが2つ目の理由です。
3. 成長余地のない開発環境
ドワンゴでは開発言語とミドルウェアは全て指定されていました。
建前上技術部長を説得できれば指定外のものを使用しても良いということになっておりましたが、
彼は全く仕事をしないお飾りなので、完全にただの建前でした。
さらに開発者はサーバのスペックも、何台で構成されているのかも、
どのような場所に置かれているかも知ることができません。
sshもできなければログも見れず、メトリクスのグラフを見ることすらできません。
ちょっとしたバグの調査であるテーブルのレコード数を調べるのにも、
発行するSQL文を添えた作業依頼書を承認リレーする必要がありました。
これらがなぜ必要なのか、いつからこうなのか、誰も知りません。
聞いても誰も答えてくれません。しかしながらこのように決まっているのです。
自分がどんなに実力を伸ばしたいと思っても、どんなにより良いサービスを作りたいと思っても、
この環境では望むべくもありませんでした。
それゆえに、グリーに転職するときにはサーバの中を直接触ることができるのか、
ミドルウェアから下の層に触れる機会が多くとれるかをしっかりと確かめました。