たぶんサーバサイドエンジニアの@pnskです。
約１年前に設立した、「Ameba Dev. Center」という
「Amebaの開発環境周りに関わる事であれば、何でもやる」というスタンスで
いつか世の中に出しても恥ずかしくない開発環境とその文化をAmebaに根付けられたらなぁと野望を持った組織に所属しています。
さてはて。
今回は、エンジニアブログ執筆の機会をいただいたので、Ameba開発環境についてこしゃべりをしようと思います。
誰得情報ですが・・
Amebaの開発環境ですが、この1年でちょっぴり変わりました。
（誰も気づいていないかもしれないですけど・・・
）topicでいうと、GitHubEnterprise、JIRA、HipChatが導入されました。
現在は
・ドキュメント管理はConfluence
・課題管理はJIRA、アジャイル開発補助ツールとしてJIRA Agile
・チャットツールはHipChat
・ソースコード管理はsubversionまたはGitHub Enterprise
がAmeba公式ツールとして利用されています。
まだまだ途中で、課題は山ほどあり、
進めば進むほど課題が新しく出てきて、それに立ち止まり、それに追われ、また進む日々です。
この１年間を振り返って、
・それまでどんな環境だったかと
・それに対してどう対応していって
・これからどこを目指しているか
について書いていこうと思います。
今もまた新しく検証や導入を検討している物がありますが、基本的には
どれも同じような壁にぶち当たり、また同じように解決？していっているので、
特定のツールについて今回は述べす、まとめてみました。
Amebaの開発環境の課題と解決？方法について
課題：同じようなものが沢山ある
Amebaには沢山の同じような物がありました。
ソースコード管理では、複数のgitlab,複数のsubversion、複数のgithubプライベートリポジトリ・・・それから公式ではCVSとsubversion
課題管理では、Redmineが主流で多くあり、Track, Backlog,Brabioなどなど。
チャットツールでは、skypeが主流で、IRC、chatworkとか。
どれが最適か？どのツールが一番効率が良いか？を検討する以前の問題で、
次から次へと新しいものが増えていき、また昔に作られた物は残り続け、
気づいたら沢山の類似ツールがありました。
関わるプロジェクト毎に、様々なツールが利用されていました。
少人数や、サポートできるメンバーがプロジェクト内にいるうちは良いですが、柔軟な組織構成になっているので、メンバーの移り変わりも激しく
管理が難しくなり、新しくアサインされたメンバーの学習コストが課題になりました。
また、統合に向けて、類似物を消している最中に、また増えていくという現象がよくありました。
なぜ・・・
対応1：どれを使うか決めて「統合」
当たり前でシンプルな対応ですが、ある程度の調査の上、
「これにする」と決めて、「統合」！！
可能な限りmore betterを決定して、もうやっちゃえ！
仕切り直しは足並みそろえてからでいい。
と企んでいたのは今だから言えるお話。。
新規のプロジェクトは良いですが、既存のプロジェクトについて
「移行」がどうしても課題になるので、
なるべく事前に吸い上げて、移行は可能な限りサポートするようにしました。
※ソースコード管理の統合は700リポジトリ以上、移行しました
個人的には、CVSを撲滅した事が何より大きい
対応2：組織設立
「開発環境」を管理している組織の知名度の低さにありました。
こういうツール欲しいなって思ったときにすでにあるのかも分からない。
分からないときに、どこに相談したらいいのか分からない。
だから、必要になったら自分たちで立てていく。
これが大きな原因だったんじゃないかと考えました。
GHE導入時は、「経営本部部門 QMグループ」というチームにいて、
経営とかやってないのに、経営やってる人みたいなイメージがついていたんじゃないか？
勝手にそう考えて「Ameba Dev. Center」という比較的分かり易いイメージの組織を設立しました。
※これは他社のGHE管理者の方とお会いしたときにアドバイスいただいたのを参考にしました
あとは知名度があがるまでは、
増えたことをいち早くキャッチアップして抹消しました。
未だに増える事がありますが、以前よりずっと減ってきたのではないかと考えています。
対応3：社内広報活動
以前は重視していなかったのですが、
最近、重要なのかなって心を改めています。
毎週のtopicメール
うちの公式ツールはこれだよ・・・感。。時には勉強会も。。
GHEの大々的な勉強会したり
（登壇者は他の人にむちゃぶりしたのはナイショ）、
エンジニア＆プランナーさん向けに、別日程で開発ツール全般の勉強会をしました。トータルで約500名の方が参加してくれました。
（これはちゃんと自分で登壇シマシタヨ。。しぶしぶ・・・。終わったその日に熱が出たのはナイショ。。慣れない事をした。。
新卒向けに、勉強会したり。。。
ポスターとかも作ったり。。
そして、こうしてエンジニアブログ書いたり。。
課題：現場との乖離
実際何に困っているのか？をしっかりキャッチアップするにはどうしたらいいのかはとても課題になりました。
Amebaにはたくさんの部門があり、それぞれに、それぞれの特性があるので
共通化すべきこと
共通化すべきでないこと
を知る必要がありました
対応1：各部門のコアメンバーとの定例
基本的には毎週やっています。
どんな些細な事でも、仮に私たちが直接対応できない事でもキャッチアップするようにしました。
検証や導入していくツールが増えるにつれて定例に出席するのが苦しくなり、今はチームの他の方に出席してもらってて私はJIRAのチケットしかみてないですが。。
対応2：Ameba技術代表メンバーと月一定例
「Ameba全体の開発環境を考える会」を月一で開催するようにしました。
「こんなことやろうとしてるよ」がオープンになるように、
Confluenceに議事録を公開状態で残しておくようにしてます。
他社では当たり前のことなのかも知れないですけど、
こういった全体のことを決めようとする議事録がMTG参加者やエライヒトにのみにしか共有されないことが多々あります。
内容によりけりなので、どちらが正解などはないですが、
Amebaの開発環境においては、みんなが関わるので、
どんなことをしようとしているのかが見ようと思えば見れる場所にあればいいのかなぁ・・と。
誰かが議事録を見て「これやろうとしてるみたいですけど、こっちの方がいいかも」などのコメントwelcomeです。
対応3：ひっそり聞く
ひそひそ・・・
そんなところでしょうか。。
他は、特に大きなことは何もしていません。
導入を検討するときに共通して確認するのは
・クライアントの対応 (winとかmacとか、、iphoneとか)
・移行サポート手段
・アカウント管理
・api (連携や管理に便利)
・UI
・運用のし易さ（verが上がったときに簡単に対応できるとかも含めて）
・コスト（オカネ、ヒト）
スタンスとして気をつけているのは
・私たち自身がその手段にこだわりを持たないこと
・実現するためには手段を選ばない事
・more betterを意識する事
・大きなメリット、大きなデメリットを意識する事
くらいです。
できているかは別・・・。こういった横軸組織に、どういったスタンスがmore betterなのか、いつも試行錯誤しています。正直ワカラナイ
結局のところ
この1年を振り返って、ちょっぴりでも開発環境が改善できたんじゃないか？
くらいまで持っていけたのは、
職種問わず、現場の開発者のみんなの手助けが一番大きかったかなぁ。。
勉強会の実施を手伝ってくれたり、検証を手伝ってくれたり、
「何か手伝える事はないか？」と聞いてくれる現場のみんなに一番感謝してます。
その言葉だけで私たちは100人力です
これからどこを目指しているか
Ameba Dev. Centerという組織の確立
課題は色々とありますが
Ameba Dev. Centerという組織の弱さを多々感じています。
いまは、Ameba Dev. Centerという組織をしっかり確立していくことが課題かなぁと考えてます。
いつも存続の危機と戦っている日々です・・・
どんなに組織体制が変わっても、
「Amebaサービスを支える人たちの環境を支える組織が必ずある」
ことが大事なんじゃないかと考えています・・よ。
ともあれ、
Amebaに関わる開発者が困ったときに、
スピード感もってしっかり後押しできるように、
もっと頑張らなきゃ
デザイナーさんの環境改善
この1年はエンジニア周りの環境ばかりやっていたので今期は絶対にやります
（やるやる詐欺になってはいけないのでここで宣言）
私たちが足かせになりませんように・・。
今は現場の人たちに助けてもらう事の方が多いですが
少しずつ、Amebaのユーザサービスを支えてくれている皆さんの足かせを外して、素敵なサービスがユーザの皆さんにいち早く届く手助けができれば嬉しい限りです
