アリエル・ネットワークを退職しました

misc

今月末をもって2年4ヶ月働いたアリエル・ネットワークを退職することにしました。

あるとき同僚とお昼ご飯を食べていて、私より後に入社した2人の同僚が私のブログを読んで入社を決意したという話を聞きました。

なんか書いた責任みたいなのも感じたため、辞めましたというのを書いておこうと思った次第です。

アリエルは良い会社だと思います。社員数が100人に満たない会社なので個人の裁量は大きいですし、周りの人や身近な部署が何をやっているのかが見通せて、組織間の横串も通しやすいです。開発者の視点からみたとき、一緒に働いている同僚に嫌な人がいなくて、同僚の技術スキルが高いというのが魅力的です。

Be the Worst

cLabs

という言葉があります。私にとってのアリエルの開発部はそんな場所でした。

いずれマネージャーをやってほしいという展望で採用されていましたが、結局は開発ばかりやっていました。お仕事なので良いことも悪いこともありますが、ある種の閉塞感があって、モチベーションの低い状態で働くよりは潔く辞めることにしました。

なんとなくいま思うのは、良いマネジメントというのはその世界を広げることなんじゃないかという気がします。

やったこと

開発したもの

プロダクトのコンポーネントのうち、5つほどコンポーネントオーナーとして開発に携わりました。

以下の3つのコンポーネントは、私がプロダクトである開発プラットフォーム上にスクラッチから開発したコンポーネントです (外部からみえるもののみ紹介) 。ようやくお客さんに使われ始めてこれからユーザーフィードバックがくるのにとか、あの機能も作りたかったなと心残りはあってすごく残念な思いがあります。またそれを引き継ぐ同僚へは迷惑をかけることになるので申し訳ない限りです。

1. 動画ストリーミング機能

Red5 のリポジトリが google code から github へ移行された後、Windows インストーラーの生成スクリプトと RPM パッケージの生成スクリプトを コントリビュートしていました 。それが認められて、数日前に Red5-Installer リポジトリへのコミット権が付与されました。

せっかくの申し出なので快諾しました。今後もできる範囲で何かしら貢献していこうと思います。

2. 外部システムとのデータレプリケーション機能

  • アプリレベルの、完全内製で作ったもののため、外部に出せるものがなかった ... (/ _ ; )

3. システム監視ツール

インターンシップ生のメンター

毎年1ヶ月半ほど、wikipedia:インド工科大学 という大学から3回生のインターンシップ生がやってくるのでその面倒をみました。親会社が面接やらライブコーディングやらで選抜した学生のみを招待しているのもあり、とても優秀な学生たちでした。もっとうまく指導してあげられたら、という反省が多い経験でした。

私はほとんど英語を話せませんが、1年目のときは自分の英語力が低いからうまくいかないと自己嫌悪になりつつ考え込んでしまっていました。2年目はその失敗を反省して、周りにも協力を仰いだり、日々彼らの進捗にあわせてカリキュラムを作ったりしていました。そのうちに英語とか関係なく、そもそも就業経験のない21歳の学生に対して、会社での業務開発にいきなり入っていくという高いハードルをいかに手引きするかということの方がずっと大事だと気付きました。

英語力が低いことでより高次の会話ができないのは事実だけれど、だからと言ってコミュニケーションが取れないというのはちょっと違うんじゃないか。日本語でやり取りしていても、開発プロジェクトで認識違いが普通にあります。インターンシップ生とやり取りも本質的にはそれと同じだと気付いて、それからはずいぶん自分の心持ちが楽になったことがありました。

Trac のインフラ管理

もともとは社内に Pythonista が少ないというのもあり、私が管理した方が良いだろうと自主的に始めました。普段の業務での開発は Java と JavaScript がほとんどで、たまに Python や Ruby といったスクリプト言語でツールを作るといった感じでした。業務でそこそこの規模のサーバーサイド開発をしていると、たまに息抜きしたくなるんです。

そこで Python ですよ！

Trac という、Python が書ける対象があったのでストレス解消的な位置付けでプラグインを作ったりしていました。Trac の良さの1つにプラグラインが簡単に開発できるという利点があります。気分転換にちょっと作って、社内で運用しているからユーザーフィードバックもすぐに来て、自分も便利になって、なんかすごい楽しい！みたいなっ ... 業務のイテレーション開発の隙間に気分転換でやっていたのがうまくまわっていたように思います。

良かったこと

働いていて一番何をしたかと思い返すと、とにかくソースコードを読んだことだろうと思います。

コードを読んで読んでも分からないことがあったり、見当違いのところを無駄にデバッグして遠回りしたり、すごい人たちはどうやってソース読むんだろうと先輩の背中から見てたり、とにかくコードを読むという体験が私にとって一番良かったなぁと振り返って思うことです。

忘れる体験

どこかの雑誌の記事で"米国の平均的なプログラマーが把握できるソースコードの量は1万行だ"というのを読んだことがあります。

ひらメソッド - LinuxKernelHackJapan

プロダクトのコードベースの規模が大きくなると本当に忘れるんです。ひどい場合は、例えば1年前に自分が修正していたという事実すら忘れていることもありました。そうすると、当たり前の話ですが、忘れていてもコードを読み直してその意図を理解できるかという可読性の重要さに気付けたわけです。

頭で理解しているのと実際の体験から得られるものの差異みたいなのがちょっと分かって良い経験でした。

直せない体験

他の人の書いたコードを自分のコードと同じくらいよく理解することはできない。どんなに熱心に読んだとしても、それは単に読んだというに過ぎず、書いたわけではないのだ。だからコードのある部分が複数の人によって書かれていたとすると、それは誰によっても一人の人に書かれたコードほど深く理解されることはない。


そして他の人もいじっているコードは、安全に再デザインすることができない。

頭の中にプログラムを入れる

他人が開発したコンポーネントを引き継いで1年半ぐらい保守開発やサポートもしました。

そうしていると、そのコンポーネントの全体像や振る舞いは把握できるようになって、この仕組みは潜在的に不具合になりやすいとか、ここは汎用的な仕組みに置き換えるべきとか、いくつか抜本的にリファクタリングした方が良いというところは分かってきます。

けれど、これがまた再デザインというレベルでは結局手をつけられませんでした。

自分が作ったものでないと、(前任者がいない状態で) コードからいまに至る変遷 (歴史的経緯) とその意図を完全に把握するのは困難です。チケットやコミットログをちゃんと書いてないのも論外です。

いわゆる「動いているコードは触るな」ですね。

具体的には以下のようなものを初期実装者がやっておかないと、他人が正しく再デザインしようというモチベーションになりにくいと実感できました。

  • テストを書く
  • 仕様を書く (ドキュメント)
  • 依存関係を小さくする
  • 意図を明確にする (可読性)
  • がんばって作り込み過ぎない

読めない体験

code is read much more often than it is written.

PEP 8 - Style Guide for Python Code | Python.org

Python 2 では文字列を str と unicode という2つのデータ型で扱いますが、文字コードを扱う処理のベストプラクティスとして、外部との境界で文字コードのエンコード／デコードを行うというものがあります。コード内では全て unicode 文字列を扱い、(ファイルやネットワークなど) 入出力のときに適切な文字コードに変換します。このプラクティスを無視して、コード内のあちこちで文字コードのエンコード／デコードをやっているツールがありました。

そういうツールで文字コード周りの問い合わせがくると、コード上のある時点で str と unicode のどちらのデータ型なのかの判別が難しく、あちこちに型チェックのコードが散らばり、結果的にデータ型や文字コードに依存した処理も所々に実装され、上述したベストプラクティスに従うにはツール全体をリファクタリングしないといけないという、どうしてこうなった状態が出来上がってしまっていたわけです。

Python みたいな言語だと、そんなコードを読むより実行してデバッグした方が確実だと読まなくなりました。毎回コードを読み始める度に「またこれか、、、」みたいな気持ちになって辛いわけですね。

これは顕著な例ですが、たぶん可読性の悪さと設計の良し悪しはそれなりに因果関係があるのでしょう (そういう理論があれば教えてください) 。もちろん最初から良いものを作れというわけではなく、可読性が悪かったらなにかが間違っているんだと直感的に信じて、どんどん直していく姿勢をもつ方が結果的に良いものができるような、何となくそう思うようになりました。

まとめ

そんな感じでお仕事ばっかりやってたのでしばらくは息抜きしようと思います。