2014年。開発組織を作るためにやってみた事

杉谷と申します。最近、株式会社セプテーニの執行役員・技術担当に任命されました。頑張ります。

前回のエントリから早1年ちょい、だいぶ組織が良い感じになってきたので会社ぐるみで試みてみたことを紹介します。

昨年に入社した直後に開発インフラとして導入した4ツール

がすっかり普及しました。

開発には安心して使えるコード管理（というかプルリクエスト機能）・タスク管理・ドキュメント管理・コミュニケーションツールは欠かせないよねーと、入社条件の一つにこれらの整備を条件にいれさせていただいたので導入はスムーズでした。

前職でも発生した現象なのですが、Atlassian製品は非常に優秀で、サービスとして社内提供をすると、ほおっておいても自然とドキュメントやコードが集まってくるようです。（かなりの勢いでデータ量と負荷が上がるので、これから導入する方はご注意を！）

※ GitHub:EnterpriseでなくStashな理由は値段の桁が違うためですが、Stashは本当に申し分ない出来です。

※ HipchatやSlackでなくChatworkな理由は、入社前からすでに一部で使われていたからですが、非エンジニアにも使いこなせるのでこれはこれでよいです。APIも整備が進み、やりたいことはできるようになってきました。

弊社もご多分にもれずレガシーコードに悩まされていました。
それを反省し再発させないため、「質を重視する」というポリシーを「会社として」定めました。

制定した内容はおおざっぱにまとめると以下の通りです。

トップダウンはあまりよろしくない印象がありますが、会社行動を起こす際の起点になるのでなかなか便利です。

やれ！と言う方は出来るように整える義務があります。
（さもなければ、よく分からないので表面だけ整うが中身はカオス、というよく見られる現象が発生します）

この場合はちゃんとテストやスクラムを教えられるようになるのが義務、となりますのでTDDの普及活動で有名な@yattomさんや@t_wadaさん、アジャイルサムライ監訳者の西村さん等が講師をされているアジャイルアカデミーを主要メンバーで受講し、普及活動の参考にしました。

またLEGO®ではじめるスクラム入門を弊社で開催していただいたり、
@yattomさんが公開されているテストのありがたみを噛みしめられる演習問題をエンジニア全員でやってみたり、などを行いました。

エンジニア同士の情報共有などを目的として1プロダクト一人、代表者エンジニアを出して状況を共有するシステムリーダー会議を開くようにしました。

この場で、チームの開発状況や衛生環境の共有や相談、上記のポリシーなどの話し合っています。

プロダクトをまたがって情報共有をする場は元々、プロダクト毎にディレクターが進捗共有を行う会議（進捗会議）があり、ビジネスとしてどういう状況なのか、というお話をしていました。

進捗会議では"全ての土台"であるシステムがどうなのか、という情報が見えづらくビジネスを優先させてしまう効果があるので、SL定例はそれを打ち消すものとしても狙いもあります。

今年1月に我々開発部署は株式会社セプテーニから子会社として分離し、「株式会社セプテーニ・オリジナル」になりました。これにより親会社とは違う制度が敷けるようになったので、「裁量労働制」を導入しました。

裁量労働制というと運用によっては大変黒くなるのですが、前述のポリシーに従い、正しく運用しようとしています。

現状としてはこれまで通りの9時半出社 & 定時18時半だよね感が根強く残っていますが、用事があるときは遅くでる・早く帰るが気軽にできるようになった感じでしょうか？時間が経てばもっとフリーダムになっていくとおもわれます。

おあと、株式会社セプテーニは関東広告業健保でしたが、我々は関東ITソフトウェア健保(ITS)を目指し中です（設立直後は入れないので、今は全国健康保険協会）。いまITSの方は速やかに鮨一新に行くと良いでしょう。

会社分離前はエンジニア・非エンジニア区別なく「360度評価制度」を採用していました。
360度評価制度とは関係者（上長・同僚）から半期毎にレビューをしてもらい評価の参考にする、という制度です。

この制度の難点は「人気取り」が強くなってしまうところで、システム開発の場合「とにかく早く、言っていることを実装する」がプラスで、「手入れできるように組む。リクエスト優先の空中回廊は組まない」など、大事でも時間のかかることはマイナスになってしまいます。

これはこれで正しい面はあるのですが、全てがこれでは興ざめなので、
評価の半分は、エンジニア同士で評価をしあう制度に変更しました。

GANMA!等ではScalaを採用しているのですが、Scalaは表現の強力さとコンパイル速度の遅さに定評があります。

これへの有効な対策が札束で殴ること、というのは広く知られているのでMacbook Pro 15インチ / Core i7 2.5GHz / 512GB SSD / メモリ16G という現行MBPの最上位機種（BTO除く）を会社標準PCとしました。

会社でゲームぐらいできたっていいじゃないか！ということでゲーム部が立ち上がりました。

9.5割くらいスマブラをやりたかっただけではあるのですが、
実際、会社で一緒にゲームできる仲間がいる、というのは良いことですし
会社でゲームもできないくらい固い、というのはエンジニアにとっては何とも魅力に欠けるお話です。

ということで、結構マジメにプラスな効果を狙っています。

GANMA!と開発中の新規プロダクト2点ではドメイン駆動開発（DDD）を採用しつつscala + playframework で開発。インフラ周りはchefやvagrantを活用、テストも整備、CIも回る、となかなか盛りだくさんなことに。
ほぼ全てのチームがスクラムを回すように（以前はexcel ガントチャートなど…）
エンジニア同士の勉強会が開かれるように。
ディレクター陣もプロダクトオーナーとしてどうプロダクトを回していくのか、の勉強会を開くようになったり。
レガシーなプロダクトもレガシーコード改善ガイドなどを参考に、諦めずに戦ったり。