直近半年間で開発組織を変えるためにやってみたこと

どうも。F.O.Xの開発責任者をしています、門田です。
F.O.Xについては、話すと長くて脱線するので以下のリンク見て頂けますと幸いです。

直近半年間でやってみたこと

直近半年間(2016年4月ぐらいから最近まで)でF.O.Xの開発組織の中でやったことは以下です。

クラウド運用向けの組織最適化
共通技術部門の立ち上げ
勉強会死ぬほどやった

1. クラウド運用向けの組織最適化

F.O.Xではクラウド(AWS)をメインで使用しています。運用しているプロジェクトは30を超えて多数稼働していて、さらに日々増えているような状況です。そんな状況の中、クラウドを使えば使うほど、オンプレの頃から特に変えていなかったインフラ周りの運用体制が問題になってきていました。

状況を一気に打開するため「クラウド運用向けの組織最適化」策を2つ実施しました。

インフラ専任以外にクラウド環境作業が出来る権限を付けた
全エンジニアにクラウドのコストを見れる権限を付けた

それぞれ、もう少し詳しく説明します。

インフラ専任以外にクラウド環境作業が出来る権限を付けた

今まではインフラ専任の横断部署のみにAWSの操作権限を限定していましたが、この部署の稼働状況によってリードタイムが長くなったり、個々のエンジニアでクラウドの新サービスのキャッチアップ速度が低下するなどの問題が出ていました。

この状況を打破するために「インフラ技術向上プロジェクト」を立ち上げました。「インフラ技術向上プロジェクト」は、大まかに以下の流れです。

既に権限を持っているメンバーがメンターになり、ハンズオン形式で作業をレクチャーする
慣れてきたら、最終試験を実施し、パスしたメンバーに権限を付与する
これをサーバ(EC2)やDNS(Route53)、DB(RDS)など大まかな領域毎に分けて実施する

プロジェクトを開始して半数以上が複数領域の権限を持っている状態になっています。パブリッククラウドへのアンテナ感度があがったメンバーも増えています。

全エンジニアにクラウドのコストを見れる権限を付けた

これまでは、コストが参照可能な権限を事業責任者など一部の社員に絞っていました。それにより不要なインスタンスの放置や、過剰なスペックのインスタンス作成が散見されました。
そこで、前述の作業権限とは別で、クラウドのコストを全エンジニアが見れるように権限を解放しました。

明らかに現れた効果としては、メンバーが監視ツールをモニタリングするのと同様に、コストを意識するようになったことです。
最初は「コスト読み会」と言うかたちで集まり、コストの変化に対して明確なコメントをつけていくなどを行っていましたが、徐々にそれも個別のプロジェクト単位に収束していきつつあります。

なにより、「＊＊使ったら高いしオーバースペック。同じ事だったら＊＊の方が安い」という会話が生まれているのを良い傾向だと捉えています。

2. 共通技術部門の立ち上げ

前述したとおりF.O.Xのプロジェクト数はかなり多いため、各プロジェクトへの設計/運用レビューを目的とした共通技術部門を新設しました。「コアテクノロジー局(コアテク)」という名前で、インフラ専任エンジニアを中心とした組織です。

新設するにあたってのポイントは以下です。

インフラエンジニアの方向転換
ローコストなレビューと運用を目指して

インフラエンジニアの方向転換

この新設部門のメンバーの仕事を「エバンジェリスト」としました。組織内のみならず組織外含めた事例を各プロジェクトに展開することと定義しています。どのエンジニアよりも早く新しい情報をキャッチアップし、時にはプロジェクトにコミットして導入実績を作るイメージです。運用経験や新規の開発経験が多いメンバーが所属しているため、より現実的なサポートと品質の向上に寄与しています。

ローコストなレビューと運用を目指して

レビューでの指摘の際、ドキュメントの雛形やレビューポイントをチェックリストとしてまとめないのかという話を受けることがあります。私としては、お役所型のテンプレートやドキュメントを作るつもりはありません(キッパリ

Web業界は技術進化が非常に早く、少し前の知見が役に立たなくなることがよくあります。テンプレートや共通ドキュメントなども作った瞬間から既に老化が始まり、絶えずメンテナンスのコストを払い続けなければなりません。メンテナンスに追われ本来の仕事に向き合えなくなるのは本末転倒です。

ただし、指針は必要です。そのため、「＊＊をすべき」を示すドキュメントを作ることよりも、「＊＊はなぜ必要なのか」を個々人が意識できるようにガイドラインや教育を徹底する方向に舵をきりました。受け身にならず自身で必要なポイントを取捨選択し、個々人の能力を底上げすることが抜本的な解決だと考えています。また、教育やガイドラインは組織の事情に左右されないため、既に外部で公開されているものをうまく流用することでローコストで出来ると思っています。

3. 勉強会死ぬほどやった

ほぼ毎月勉強会をやりました。ここ半年で開催した勉強会や登壇は以下です。

※CAグループ内限定の勉強会入れるとあと３つ増えます

積極的に勉強会の開催/共催や登壇の後押しをしてきましたが、これは外部のエンジニアと交流する機会を作るという考えのもと行っています。

勉強会をやる意味

Web系エンジニアに求められるものは年々増えていて、自己学習で全てカバーするには限界があると考えています。それを補うために勉強会駆動で学ぶというのは効率が良いです。隔週で社内勉強会も行っているのですが、メンバーが似通ってくるため、技術体系として新しいものが入りにくいという問題が有ります。そのため組織的に外部との勉強会を開いて、メンバーが参加する機会を少しでも増やすことが狙いです。あわよくば社内勉強会を練習として外部で登壇するように目論んでいます。

少しづつ登壇するメンバーも増え、技術体系も広がっているのを感じています。勉強会死ぬほどやった成果は出ているかと思います。

共催や登壇などご協力頂いた皆様ありがとうございました！