アリエル・ネットワークでアルバイトをしてきました

3ヶ月半という短い期間でしたが、アリエル・ネットワーク (以下アリエル) でプログラマーとしてアルバイトしてきました。

よく見かける、どこそこでインターンシップをしてきました風な記事を書いてみます。普通はそういった記事を学生さんが書いているものですが、この記事は普通の無職の人が書いています。

最終日に「開発方法論提案改めアリエル開発の所感」というタイトルで発表しました。

私が過去にいくつかの会社で働いてきた中で、アリエル開発で改善したら良いと思うことがあったら提案してほしいと言われていました。とはいえ、私の経験よりもアリエル開発の方がずっとレベルが高かったため、釈迦に説法な気がして、そんなタイトルに落ち着きました。この記事では、その内容からいくつか抜き出して紹介します。

私がやったこと

アリエル・エンタープライズという Web アプリなグループウェアの開発に携わりました。

Trac でアサインされたチケット (バグや機能拡張) に対して修正するといった感じです。4-5年ぐらい開発を継続しているらしく、製品としての中核や部品、UI はかなり作り込まれていました。そのため、自分でコードをガリガリ書くというよりは、製品の動作や仕組みを理解するためにコードを読んで原因を特定したり、既存のコードを再利用して機能拡張するといった開発作業がほとんどでした。

製品の規模もコード量が数十万行というオーダーの、私にとってはこれまでで最も大規模なアプリケーションでした。開発を通して、大規模アプリの設計、ソースコードの読み方、Java のイディオムも少しずつ分かってきておもしろかったです。

アリエルの開発は、プロダクト系の開発だと Java、UI 系の開発だと Javascript がメインのようです。ただプロダクトと連携するツール類は Ruby や Python で書かれたものもいくつかありました。なので、業務で Java か Javascript しか書けないというわけでもありません。試験的な取り組み、プロトタイプ的なツールなどは、開発者の好みの言語で実装できそうに思えました。実際、私自身も Python でプロダクトと連携するツールを実装しました。

アリエル開発の良かったこと

開発体制／インフラ

雑誌や書籍で見かける類いの開発手法を当たり前のように業務の中に取り入れてました。開発インフラが整っていると、開発者はこんなに楽なんだということを実感しました。

また、開発者にとっての業務の中心は Trac です。チケット管理、wiki、ドキュメント、レポーティング (グラフ)、技術メモなど、かなり活用されてました。会社として開発情報を統合的に一元管理しようという意図をもって Trac に集約していて良い考えだなと思いました。

そんな中、チケットが分裂・派生していき、手動で関連チケットのリンクを張るのが煩わしくなって TracTicketReferencePlugin も作ってみました。これはアリエルの 10% ルールという枠組みの中で開発したものです。アリエルの Trac で耐えたら、世の中では大丈夫だろうと個人的に思っています。

仕様の決め方

アリエルの開発における仕様の決め方に、最初は戸惑ったのですが、これはこれで良いこともありそうだと後になって考え直した次第です。緩い感じに仕様を策定していきます。

バグ修正的なチケットは、バグを直せばいいだけです。大きな機能追加は全く違った開発プロセスを歩むので、ここでは書きません。適切な粒度の機能追加的なチケットは、大まかな方向性は決まっていますが、詳細は決まっていません。基本は担当開発者がまず、外部仕様策定から始めます。仕様は、チケットをあげたヒトやプロジェクトマネージャ、プロダクトマネージャと相談しながら決まっていきます。プロダクトマネージャがこうしたいと思っても、表向きは担当開発者が決める形になっています。ただ、あまりにも紛糾していて物事が進まないときは、偉いヒトの強権が発動されます。
http://blog.pasonatech.co.jp/ootani/105/17869.html

然るべき人が、ちゃんとした仕様を決めて、一方的に押し付けるというよりは、そのチケットの関係者が議論しながらより良い仕様に作り上げていくといった感じです。この過程を厳密にシステム化、もしくはプロセス化しないことで関係者間のコミュニケーションを促進している面もあると私は思いました。困ったら関係者のところへ行って「これってどういうことですか？」と聞くしかありません。そこで要件の齟齬や考え方の違いを認識して、やり取りから開発者も学ぶ、視野が広がるといったことに繋がるように思いました。

組織的な牽制機構

その緩い仕様の決め方にはもう1つのメリットもあります。

組織的な牽制機構が働かないと、ほとんどの組織は堕落します。

組織が1つだけだと、なぁなぁになってしまいます。組織が2つだと、けんかして対立関係になりがちです。組織が3つで、相互に牽制する関係が私の開発経験の中では、結果的にうまくいっていたように思います。アリエルもそういった3つ巴的な体制になっていて良さそうに私は思いました。但し、組織が分かれると、情報共有されなかったり、生産性が落ちたりするので、横の連携の工夫が必要になります。

会議がなかった

私がアルバイトだったこともあるかもしれませんが、会議がほとんどありません。こんなに会議がない会社も初めてでした。週報も書かないので、週例ミーティングがなく、グループミーティングのようなものもありませんでした。意図的に会議を減らしているように思いますが、開発に集中してたら1日中全く話さなくて終わるような日もあったかもしれません。

しかし、月に1回の開発部の全体会議がいまいちでした。私からの唯一の提案は、どうせやるならちゃんと全体会議をやった方が良いですという当たり前の意見を述べてみました。

また、Trac の活用度が高いため、開発の進捗状況やいろんな数字が出せるので、そういった数字からビジョンを語ると良いのではないかと偉そうなことを言ってみました。実際に Trac 上ではロードマップを管理して、バーンダウン・チャートも出力されていました。

パッケージ開発は長期的な展望をもって開発するので、普通の開発者は何を目指して開発しているのか、いまどういう状況なのかがよく分からなくなることがあります。何かしら開発者の意思統一を図るというか、共有するためにビジョンが必要です。ビジョンを語るのはとても難しいことですが、かっこいいビジョンばかり語っても本当の意味ではよく分からないので、実際の数字から現状分析や今後の方向性を語ると分かりやすくて良いのではないかと私は思います。