レガシーな開発環境、開発体制に苦しんでいるエンジニアの人は多いと思います。
レガシーな開発環境になってしまう理由としては、
- 通常業務が忙しくて、なかなか改善の機会がない
- 今までこうだったから、で決められてしまい変えられない
- とりあえず今の状態でまわっているから、あんまり改善する気がない
等々、、、いろいろあるかと思います。
ベーシックの現在の開発環境は
- メイン言語はruby
- 開発者にmacを支給
- Vagrant + Itamaeで環境構築
- capistranoでデプロイ
- gitによるバージョン管理
- プルリクによるコードレビュー
- インフラ周りはAWS
- コミニュケーションはslack
とまあ、今風の開発体制ができてきていると思っています。
比較的新しい会社は「こんなの今じゃあたりまえでしょ」という感じだと思いますが、ある程度歴史があるところでは、なかなかできていないところもあるのではないでしょうか?ベーシックでも、これらは最初からそうでなく比較的導入が遅く、レガシーな開発環境での開発をしていることがありました。
この開発環境がどのように移り変わり、今に至るのかを書きたいと思います。
昔→ちょっと昔→ついこの前→nowの順番で紹介します。
おおよそ2年単位ぐらいの間隔です。
昔
このころ運営をしていたのは、おもに比較サイトと呼ばれるサービスです。
僕が入社当時はエンジニアの人数が6名ほど、
それに対してサービスの数は20ぐらいありました。
1人で3サービス以上 は担当している計算になります。
とはいえ、そんなにがしがし開発するようなサイトではなく1つのサイトをコピーして、中身の細かい要素をちょっと変えて、つくっていったのでそれほど開発には手間もかけず、運用レベルでの変更もさほどなかったので、
以前使った仕組みをコピー → 作って放置
という流れて開発が進んでいきました。
とりあえずものとして出来上がる、ということを重視して開発をしていたのもあり、あまりメンテナンス性がよくなかったり、Noticeエラーとかでもあまり気にせずすすめてました。。。
言語・ツールなど
LAMP環境で開発。
このころはphpのフレームワークは特に使っておらず、独自のマイクロフレームワーク?みたいなのを使ってました。
サーバはさくらとかGMOとかいろんなところのサーバ管理会社のものを使用してました。結構いろんなところと契約してたので、このサービスのアカウントどれだっけ??みたいな事象が発生して後々苦労をする・・・
運用・体制
あまり運用っぽいこともしてなかったので、 リリース後はテスト環境、バージョン管理なしで本番直変更で対応 をなんていう男気運用しているサービスもありました。いまこんな事をしたらグーパンです。
(もちろんこのころでも、一部プロジェクトではちゃんとテスト環境もありましたし、svnでのバージョン管理もしてました)
コミニュケーション
エンジニアは基本各サービスごとに配属されることになるので、エンジニア間のコミニュケーションという意味ではあまりなかったと思います。
別に仲が悪かったわけでもないのですが、業務であつかった技術の共有等は特にできてなかったかなーっていう感じです。
ちょっと昔
エンジニアの人数はちょっと増えました。
そしてサービスの規模も大きくなってきて、開発でやることも増えてきたころです。
従来の男気運用だともう無理でもあるし、様々な問題もでてきてました。
- ファイルが元に戻る
- ファイルが消える
- サーバが火事にあってデータ消失の危機(バックアップとってない)
このままだと死ぬので、とりあえず全サービスはバックアップ必須。
バージョン管理もgitに変更して、バージョン管理も必須。
gitは導入できたもののでもコードレビューの導入はできていませんでした。1サービスを1人でやっていたためレビュアーがいない状態だったのです。
もちろん担当以外のエンジニアにコードをみせて確認をすることはできるのですが、
- 仕様を把握するのに時間がかかる
- 結構自分のところだけで手一杯で、あんまに他にかまってられない
という感じでした。
なんだかあまり行けてない開発体制ではあったものの、このころにエンジニア的に大きかったと思うトピックがありました。
それが アプリ開発を始めた ことです。
パズドラとか規模の大きいアプリではなく、カジュアルゲームアプリというジャンルで、暇つぶし用のゲームアプリという位置付けのゲームアプリを開発してました。
結構このアプリ事業で大きい変化だと感じたのは、今までのベーシックですと、基本サイトのへの掲載費で売上を上げていたので、
営業→企画→エンジニア
という流れでまず営業始まりで事業が進むことが多かったです。
ところがアプリの場合、
企画→エンジニア
となり、営業を必要としなくなったので、エンジニアの事業に対して影響力が大きくなったなと感じました。
実はこのアプリ事業はかなり実績をのこしまして、実際app storeのランキングの総合1位をとった時期もあります。今は諸事情によりアプリ事業からは撤退をしてしまいましたが・・・残念
言語・ツールなど
Web開発は相変わらずphpがメイン。
ただ新規に立ち上げるサービスはcakephpを導入。
昔のを引き続き運用しているようなサービスは、どうしても旧来の仕組みのまま(いわゆる技術的負債)となってしまっているので、メンテナンスは困難なり、細かい変更がやりずらくなってしまいまいた。
この後運用に支障をきたしてしまうため、リニューアルをしたサービスもあります。
10年以上続くサイトを初めてリニューアルして感じた事
運用・体制
バージョン管理にgitを導入するようになりました。一部プロジェクトで使っていたsvnによるバージョン管理も合わせてgitへ移行。
エンジニアは多少増えたのですが、それ以上にやることが増えてきてしまいました。
1人1サービスを担う関係上、エンジニアとして必要な作業(監視設定とかバックアップとかリファクタとかパフォーマンス改善とかインフラ周りのもろもろの調整とか)などは事業部内でやりたいこととの折り合いの中で自分で調整してやっていく必要があるので、スケジュール管理がかなり大変。。。
無理矢理押し込んで対応する感じになってました。
コミニュケーション
今まで東京で働いていたエンジニアが、山形で働くようになり、遠隔地でエンジニアが一緒に働くようになったこともあり、 skype を導入しました。
エンジニアのグループも作り、これによって席はバラバラなのですが、ある程度のコミニュケーションがとれるようにはなってきたのですが、
今どんな開発をしていて、どんなことに困っているのか
みたいなのはよくわかりませんでした。
「おはようございます」→「お疲れ様でした」
ぐらい。(^^;)
ついこの前
エンジニアが足りないーって言う状況の中、世の中的にちょっとずつエンジニアが注目されるようになってきたり、アプリのヒットもあってベーシック内でエンジニアの採用に力をいれるようになってきました。
僕としては嬉しい限り。
だいぶ人が増えたおかげて、仕事がやりやすくなってきました。
1人1サービスからチーム体制をとれるようになって精神的に楽になりましたw
そして、エンジニアの新卒を始めて取ることになりました。
言語・ツール
ruby のスペシャリストが入社したこともあり、新規に立ち上げるサービスでrubyを使うようになりました。(ただ最初にベーシックでrubyのプロジェクト導入したの自分なんですよ……(-。-)ボソ)
インフラ周りでも AWS を使うようになり、ちょっと遅まきながらも世の中の流れについてきた感じがでて、新しいことに触れる機会がちょっとずつ増えて、個人的には技術力がついてきたかなーと実感ができきた時期でもあります。
またエンジニアはMacを支給するようになり、会社の中で、エンジニア=Mac使う人のイメージになりました。
運用・体制
人が増え、新卒も入ってきたこともあるのでプルリクによるコードレビューを取り入れ始めました。
vagrant を使って開発環境をローカルで持てるようになり、開発がだいぶやりやすくなりました。(それまではローカル環境はもってなくて、テスト環境を直でさわってた・・・)
エンジニアの人数が増えてきたこともあり、これまで全然手をつけてこなかったテストコード、デプロイツール導入などのCI周りも徐々に意識し始めるようになりました。
コミニュケーション
エンジニアを事業部付で配属させずに「開発部」としてあらたにエンジニアだけの部署を用意。
開発部というのを用意したことで意識的に共有しよう、みたいな雰囲気にだけはなったのですが、とはいえ実態は事業部配属に近い状態で、なかなか開発部として集まった意義は出せてなかった気がします。
席がみんなバラバラだったっていうのが、その要因であったかなと思います。
このころは chatwork を使って開発部専用の部屋も用意されていました。
が、やはりちょっとした実装レベルの相談になると、「なんかわざわざそこに投稿するのもな〜」っていう感じになってしまう感じがあります。
隣にエンジニアがいれば、「こういう機能なんだけど、メソッドの名前どうしようか?」みたいなことを気軽に相談できるなー、と今なら感じます。
よく「職種で固まらないほうがいい」、みたいな話も効くのですがそれは会社として作っているプロダクトがはっきりしている場合かなーって思います。
社名=プロダクト名 みたいなところですね
弊社みたいに事業が多岐に渡り、1事業部あたりのエンジニアの割合がそれほど高くない場合は、みんなでまとまったほうがいいなと思いました。
now
エンジニアの人数がかなり増えました。
また、入社当時に比べて運用しているサービスが集中されてきて、1つ1つのサービスの規模が大きくなってきています。
言語・ツール
変わらずrubyがメイン。
あまり大きな変化はないですが、技術ナレッジを Qiita へ投稿することが増えてきました。
運用・体制
コードレビューはgitlabで行っていたのですが、 Github へ移行。
一部のあんまり変更がない昔ながらのサイト以外は全てgithubにリポジトリを変更しました。
コードレビューを始めた当初はエンジニア以外にはあまり、意義とか浸透してない感じでしたが、全体的にやるのが当たり前みたいな雰囲気になってきました。
開発環境の構築はvagrant+chefから vagrant+itamae に変更するようになりました。
コミニュケーション
開発部としてのつながりを強化するために、いままでは各事業部ごとにエンジニアの席が分かれていたのが1つの場所に集まるようになりました。これによって普段仕事ではあまり関わらないようなエンジニアとも話がしやすくなり、コミニュケーションが活発になってきたと思います。
また、 TGIF などイベントを開催するようにして、普段は仕事で関わらない状態でも共有、コミニュケーションができる場を用意しています。
TGIFについては、
ベーシック開発チームのイベント「TGIF」を見学してわかったこと
新年1発目!! 第7回TGIF LTを開催しました!!
こちらを読んでみてくだい!
ツールとしてはchatworkから slack に移行しました。
といっても今のところslack使っているのはエンジニアだけなので、現在のところchatworkとslackの併用になってますが。
チャットツール併用しているっていうと大変そうな気もしますが、意外とそんなに大変でもないです。
最後に
ベーシック内での今までのエンジニアのイメージって多分
「エンジニアってなにやってるかよくわからんけどなんだか大変そう、俺には無理だ」
みたいな人が多かったと思うのですが、
最近は
「なんだか楽しそう」 とか 「エンジニアやってみたい」 って言う人の声がちらほら聞こえてきて、エンジニアやっていてよかったなーと感じるようになりました。
周りの環境がちょっとずつ変わっていって、ふと振り返るとずいぶん変わったなーって思います。
最後にイチローの名言の載せておきますね
夢を掴むことというのは一気には出来ません。小さなことを積み重ねることでいつの日か信じられないような力を出せるようになっていきます。
というわけでこれからも小さな積み重ねで、大きな成果を残していけるようにしたいと思います。