Speeeが開発組織改革を行って、現場に起こった変化

Advent Calendar 組織
この記事はnisshiee.orgに移設しました。
自動でリダイレクトします。

この記事は、Speee Advent Calendar 2015の最終日です。
24日目は、takakazu_matsuyamaより、『【企画者向け】これだけ知っとけばすんなりとWebサービス・アプリの企画できるという知識リスト』です。

Speeeの開発組織改革

Speeeは2015年の5月、開発組織改革を行いました。

そのときの様子は、RubyWorld Conferenceで軽く雰囲気をお伝えしました。

また、経営、マネジメント視点でどのような意図を持ってこの改革が行われたのか、以下の記事で紹介されています。

2015年という年は言うまでもなくSpeeeの開発部にとって大きな変化を伴う年でした。そこで、この大きな転換点から半年、現場の視点で「変わったこと」を紹介していきたいと思います。

Ruby/Rails化

これは各所で既に語られていることですが、会社のメイン言語/フレームワークを、Ruby/Railsと定めました（サブにGo、Scalaを据えています）。

それまでは、PHP/Javaが主に使われていました。PHPではfuelPHPをラップした独自フレームワーク、JavaではSpringFrameworkが使われていました。

独自フレームワークの方は、一応Gitリポジトリに置かれてはいるものの、そもそもメンテされているのかわからない状態で、割りと酷い有様でした・・・一度独自フレームワーク再構築プロジェクトが走ったこともありましたが、プロジェクトに関わる開発者にプロジェクト用の時間は全く確保されておらず、結果は推して知るべしという感じでした。この再構築された独自フレームワークが社内に広まる前にRails化できて本当に良かった・・・

SpringFrameworkの方は僕とかは好んで使っていました。最新のJava(1.8リリースの翌日にはProduction導入し、StreamAPIやdefault methodを多用しています)や、最新Versionのライブラリを積極的に導入しており比較的上手く開発・運用していましたが、折角DIしているのにテストがあまり書かれていませんでした。Groovy Spockを使ったテストもありますが、一部だけでした。

テストを書く文化ができた

というわけで、Ruby/Railsになって一番大きく変わったところは、テストを書くのが当たり前になったことです。

PHPやJavaのときは、自動テストを回すために何かしら「がんばって」いました。それがRailsではテストまでエコシステムに組み込まれているから、がんばらなくても自然にテストを書き、自然にテストが実行されるようになりました。

僕は静的型付け関数型言語を好むタイプの人間なので、「Rubyはとにかくなんでもテストで品質を担保しなければいけない。もっとコンパイラが勝手にチェックして欲しい」という立場で、このあたりはブレていませんｗ
しかし逆に、Rubyコミュニティはそれを理解しているからこそ、よりテストの負担を減らすためのあらゆる仕組みが整っているなぁと感じていて、まさにコレこそが、テストを書く文化ができた根本原因だと思っています。

レビューする文化ができた

また、テストを書く文化ができた背景の1つに、レビューをする文化ができたというのもあります。

この文化は、井原さんの「人の目を通ってないソースコードはリリースするな」という強いメッセージを受けてできたという感じが強いですが、レビュー文化のおかげで、テストがないコードには「テスト書け」というレビューが返ることになり、テスト文化を促進しました。

ちなみにこう書くとレビュー文化はトップから押し付けられたように聞こえるかもしれませんが、現場もかなり積極的でした。「本当はレビューとかちゃんとやらなきゃいけないんだろうけどなぁ」と思ってはいたけどできなかったものが、井原さんの一言が良い刺激になり、「もうこの機会にちゃんとレビューするように変えていこうぜ！」という空気になりました。

チームの外の人が何を開発してるかわかるようになった

レビューの流れで、冒頭で紹介した資料にも書いたとおり、チームを超えてレビューをするようになりました。この施策は様々な効果を生みました。ノウハウ共有という狙い通りの効果もありましたが、もう1つ、チーム外の人のコードに触れることにより、チーム外も誰が何をやっているか分かるようになりました。

そもそも開発部という組織としてより健全になったという点でも良かったですが、「こんなことやりたいんだけど」「誰々が似たようなことやってたよ」みたいな会話が自然と発生するようになった点も良かったです。開発部全体という視点で、生産性を押し上げることになりました。

エンジニアの市場価値を重視

事業会社であるSpeeeにおいて、エンジニアのミッションが、ユーザへの価値提供と、事業に対する貢献であることは間違いありませんが、今回の組織改革で、「エンジニアとしての市場価値を高める」ことを大事にするというメッセージも合わせて発せられました。

ノウハウをアウトプットするようになった

「価値」について考えれば、価値の出し方は、自分の担当しているプロジェクトでコードを書くことだけではないのは明らかです。自分が時間をかけて調べたり、検証したり、考えたりしたことをチームに共有すれば、自分がかけた時間分、他のメンバーの時間を節約したことになります。その考え方は、井原さんやマネジメント層から強く伝えました。

その結果、Slackでノウハウをとりあえず発信したり、Qiita:Teamで知識を整理したうえで発信したりという動きが活発になりました。今では、エンジニアだけではなく、ディレクターもディレクターのノウハウをSlackやQiita:Teamで発信する文化ができつつあります。

社外に対してもオープンな発信をするようになった

さらに、アウトプットを社内に留めず、オープンにすることで、それを見て時間を節約できるかもしれない人の数が圧倒的に増えます。また、社外にアウトプットをすると、レベルの高い視点でフィードバックを受けることで、自分の更なるレベルアップに繋げられる可能性もあります。アウトプットをオープンにすることは、勇気は要りますが、とても価値の高い行いです。

Qiitaストック数やはてブ数といった数字を競うような、ゲーム感覚でアウトプットを行うような取り組みも見られました。会社のエンジニアブログ「TECHNICA」の投稿ペースも上がりました。

なにより、Speee Advent Calendarを、1日の隙間もなく、完走することができました！！

まとめ

言語が変わり、フレームワークが変わり、日々のアウトプットであるソースコードのレベルでの変化はもちろん当たり前のように起こりました。しかし何より、積極的なエンジニアが、より活き活きとエンジニアリングを楽しむ土壌が、少しずつ整ってきたかな、と思います。