読者です 読者をやめる 読者になる 読者になる

CA MOBILE エンジニアブログ

株式会社シーエー・モバイルのエンジニアブログです

社内勉強会始めてみました

culture 勉強会 楽しく働く環境

f:id:jamieh-mongolian-chop:20160912114135j:plain

めっきり寒くなってきましたが、みなさんいかがお過ごしですか?

こんにちは、Jamiehです。

f:id:jamieh-mongolian-chop:20160912114556p:plain:w128 人物紹介:Jamieh(ぢゃみー)

サーバサイドエンジニアでPHPer。go langとかC++とかもやったりやらなかったり

お酒が大好き。残業は大嫌い。

前置き

いきなりですが、みなさんは勉強会とかって参加してますか? 僕は最低でも1ヶ月に2回くらいは外部の勉強会に参加するように心掛けてます。

勉強会に参加すると新しい知識が入ってきたり、いい刺激になるので社内のみんなにもどんどん参加して欲しいところです。

シーエー・モバイルでは勉強会カレンダーというものを作成して共有しており、全エンジニアがどんな勉強会に参加しているかすぐに確認することが出来ます。

f:id:jamieh-mongolian-chop:20160912120922p:plain

  • 「あの人が行ってるなら、僕も行ってみようかな」
  • 「あ、あの勉強会行った人がいるな。内容をちょっと聞いてみよう」
  • 「今日、勉強会行きたいのが2個あるんだけど、どっちか行ってる人いないかなぁ」

など、少しでも勉強会に参加することの敷居が下がればと取り組んでいます。

きっかけ

とはいえ、なかなか、勉強会に参加する人が増えない中、ある日


f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「どうしたら、みんなは勉強会とか参加したり興味をもったりするんだろう」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w48 「自分で勉強会開けばよくない」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w128 人物紹介:kkkw

サーバサイドエンジニアでPHPer。

趣味:プログラム

f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「は?」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w48 「いや、だから、社内で自分で勉強会すればいいよ」

f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「はぁ、、、」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w48 「こないだ、あのサービスのmysqlのバージョン5.1から5.6にあげたよね?あれ、話して」

f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「はぁ、、、」

f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「(なんで、命令口調??)」

勉強会を始めてみよう

あまり腑に落ちない感じでお願いされて、社内で勉強会をすることに。

ただ、どうせやるのであれば盛り上がって有意義なものにしたい!


f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「mysqlのバージョンアップの話するから、来週なんかテーマを決めて喋って」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w48 「え?」

f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「なんでもいいから、やってよ。この形式の勉強会、これから毎週やるから」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w48 「へ?」

f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「再来週はオレが喋る。勉強会のコンセプトとタイトルは決めたから。」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w48 「う、うん、、」

f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「タイトルは『伝える』

f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「コンセプトはスピーカーが伝えたいことをただ伝え、質問タイムは薄めの勉強会。これで行くから。」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w48 「う、うん、、」

f:id:jamieh-mongolian-chop:20160912114556p:plain:w48 「聞く人だけじゃなく、喋る人の敷居も下げたいから。」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w48 「そ、そうだね、」

f:id:jamieh-mongolian-chop:20160912121849j:plain:w48 「(なんで、命令口調??)」

『伝える』

こうして始めることになった勉強会『伝える』

『伝える』という勉強会を開くにあたり、会社とも連携して以下のルールで実施していくことにしました。

  • 技術的な話であればテーマはなんでもOK
  • おもしろく伝える
  • 傍聴者が10名を超えた場合はアルコールと軽食を用意する


Jamiehkkkwだけでspeakerを実施していこうと考えていたのですが、


f:id:jamieh-mongolian-chop:20161031143720j:plain:w48「おもしろそうなんで、師匠がやるなら僕もやりたい!」

f:id:jamieh-mongolian-chop:20161031143720j:plain:w128 人物紹介:ejiri

アプリエンジニアでサーバも書けちゃうイケメン・イクメンエンジニア

最近、子供が産まれたのに飲んでばっかりだからイクメンではないかも

弟子のejiriが参戦してくれることに。

こうしてspeakerも集まりなんとか始まった社内勉強会『伝える』


テーマをspeakerが好きに選ぶスタイルで実施しました。 一例ですが、何個かテーマを記載してみます。

  • 伝える 第4回 - 初めてのAnsible -
  • 伝える 第9回 - 大改造劇的ビフォーアフター 疲弊するシステム - *1
  • 伝える 第14回 -開発環境をdockerにすると何がかわるのか-
  • 伝える 第15回 - AWS Lambda 入門 -
  • 伝える 第25回 - 技術は家計を救うのか? aws lambdaで取得した為替データをamazon mlに食わしてみた -

こんな感じのライトなテーマで実施して、みんなの参加意欲が湧くように心がけました!

まとめ

最初は

本当に毎週やれるのか、

喋るネタが尽きてしまうのでは、

人が全然集まらないんではないか、

など、不安がいっぱいでしたが結果

大成功!!

speakerも最初は3人だけでしたが、何人かやってくれる人が現れ 参加者も徐々に増えて、なかなかの盛り上がりをみせました!!

f:id:jamieh-mongolian-chop:20161031153200j:plain

しかも、4月〜9月までの間、毎週実施することもできました!

今後もこのような、文化作りを積極的に実施していこうと思います!


もちろん『伝える』も続けていきます!


各社エンジニアの技術力向上のために様々な取り組みをされているかと思いますが、まずは勉強会に対する意識改革のために、社内での勉強会の盛り上げ方から 取り組まれてはいかがでしょうか

第1回 CAMビアバッシュ ~ テーマは “すてる” ~

楽しく働く環境 勉強会 culture

こんにちは。 シーエー・モバイルで、アドプロダクト事業を担当しているエンジニアの D.N です。 本日は、9月28日(水) に開催されました第1回 CAMビアバッシュについて、実施レポートをお届け致します。

はじめに

このたび、第1回 CAMビアバッシュと銘打ってエンジニア主導のイベントを開催しました。

過去にもシーエー・モバイルでは、社内での勉強会やエンジニア合宿など、エンジニアが中心となったイベントは数多く開催されてきました。

そんな中で、日頃業務に邁進しているエンジニアを労う意味もこめて、社内のエンジニア全員を対象とし、CAMビアバッシュという形でライトニングトーク大会を開催する運びとなりました。

テーマは "すてる"

今回のイベントのテーマは、"すてる" です。発表の紹介の前に、これについて少しだけ説明します。

エンジニアの方であれば、頷いていただけることと想像に難くないのですが、 サービス開発を進めていくと、多かれ少なかれどうしても発生してしまうのが技術的負債です。

技術的負債とは何でしょうか。

技術的負債とは、例えば、プログラミング言語フレームワークが古すぎたり、プロジェクトの設計書が最新版ではなかったり、 あるいは、特定のソースコードが著しく属人化している、などなど、理想的な継続開発を行う上で、阻害要因となるものを指します。

そういった数多くある技術的負債のうち、今回のイベントでは、開発環境サーバを圧迫するリソースなどにフォーカスを当て、 以前こちらのブログでも紹介させていただいた、CAM「技術戦略室」のメンバーが主体となって取り組んだ "すてる" 活動をライトニングトーク形式で発表しました。

tech.camobile.com

発表の内容

それでは、発表の内容を個別に紹介します。

1番目 : N・K チーム

f:id:cam-engineer:20161005150120j:plain:w300 f:id:cam-engineer:20161005150214j:plain:w300

  • 今回やること
    DBのクリーニング(共通開発DBサーバのおそうじ)
  • 解決すること
    • 容量問題を削減
    • 意味不明なものをなくす
    • peropero というナゾのDBが容量を圧迫している...!
  • 捨てる習慣を作る
    問題を解決したあとも継続的にキレイにできるように。

f:id:cam-engineer:20161005152104p:plain ※注釈:こちらの wiki は D.N が纏めさせていただきました!

  • 活動詳細
    • 削除方針
      • Phase1: まずは明らかに不要なDBから
      • Phase2: 次にクローズ or 移管したサービスのDBを
    • Slack にて告知して確認
    • 作業時は、ダブルチェック
  • 活動結果
    • Used 299GB -> 253GB
    • DB数 199 -> 131
      ※注釈:DB数であり、テーブル数ではないです。
  • まとめ
    • DBキレイになりました
      • 容量削減
      • 用途がわからないDBをなくした
    • 定期的にアラートを上げれる仕組みを作りたい

2番目 : M・N チーム

f:id:cam-engineer:20161005150923j:plain:w300 f:id:cam-engineer:20161005150937j:plain:w300

※注釈:こちらの発表は、某テレビ番組ビフォーアフターのナレーション風にお楽しみください。

過去の遺産を抱え続けるプロジェクトがありました。

  • 2015年のリニューアルから1年
  • 使わなれないのに消せないファイル
  • 肥大化するロード時間
  • 日々の運用の中で増え続けるバックアップ
  • 長年使い続ける機能

そんな状況を改善するべく、二人の匠が立ち上がりました。
まず最初に目をつけたのは、本番DB上に残った1年分のバックアップ。
これは、まとめて300テーブル以上を一気に削除。
すると、なんということでしょう。
こんなにスッキリしました。
WorkBench上で見ると、利用しているTableとBackupテーブルが散乱していた状況も
ごらんのとおり。格段に見やすくなりました。
ちゃんと3ヶ月以内に保存されたものはバックアップとして残しておくことも忘れません。

DB名 開発環境 ステージング環境 本番環境
A 86 65 94
B 44 39 68
C 33 36 66
D 41 43 66
E 44 12 17
63 28 21
合計 311 223 332
  • 今回、削除対象となったテーブルは866テーブルにもなりました

DB以外にも開発環境の不要ディレクトリ削除

監視ツールも綺麗に

  • MRTG の撤廃
    • UI がダサい
    • 更新が遅い
    • リロードしないと表示が更新されない
    • 情報の更新が止まる
  • Mackerel の導入
    • https://mackerel.io/ja/
    • 監視通知機能付き
    • とにかく見やすい! キレイ!
    • グラフはもちろん自動更新!
    • 拡大すれば1分間隔で参照可能!
    • その他の機能
      • Slack通知
      • サーバIP、ホスト名管理
      • ダッシュボード
      • グラフ共有
      • サービス、ロール機能
      • ホスト別アラート通知設定
      • 外形監視
      • Nagios, Munin, Sensu プラグイン
      • AWS 監視サポート
      • API での各種情報取得
      • 将来予測機能
  • 実際の利用シーン

f:id:cam-engineer:20161005153251p:plain

Memcache リプレース時、旧Memcache サーバへアクセスがこなくなったことを監視するのに役立ちました。

f:id:cam-engineer:20161005153304p:plain

  • 12時にトラフィックが一気に増加。
  • 何かしらイベントが行ったことが確認できる。

3番目 : E・T チーム

f:id:cam-engineer:20161005151123j:plain:w300 f:id:cam-engineer:20161005151148j:plain:w300

1. あるプロジェクトで運⽤しているリポジトリのブランチ整理

Mergeされたものや、検証でつかって不要になったもの、closeされたものが対象。
プロジェクトの特性上、コマンドで⼀括削除はできないのでGitHub Enterprise(以下、GHE)から内容を確認して1つずつdelete
作業結果
ブランチ数 593 -> 253
半分以下に!!!!!(それでも多い)

気づいたこと
* だれがブランチけしてないかがわかる
* 意外と作業フローが徹底できてなかった

2. 開発環境の不要なログ削除

$ find /x/*/logs/ -mtime +7 -type f
103641 ファイル。。。
$ cat /x/bin/delete_app_log_cron.sh [/x/bin 18:47]
#!/bin/bash
find /x/*/logs/ -mtime +7 -type f -name "*log" | xargs rm
# cat /var/spool/cron/root
# Remove logs in /x/PROJECT/logs
0 8 * * * /x/bin/delete_app_log_cron.sh > /dev/null

BEFORE

  /dev/sda2 557346600 462318700 66716348 88% /

AFTER

  /dev/sda2 532G 433G 72G 86% /

まとめ

  • 開発環境のログなんて⼀週間もあれば⼗分だよ!
  • 消そう!

3. 自社共通フレームワーク製媒体のエラー追跡⽅法の改善(途中経過 報告)

現状

前⽇のログファイルをERROR, WARNで grep して、MLに結果を送付

ある連休明けの朝

約2000行のログメール × 83通
OMG

問題点

  • (嬉しいことに)プロジェクトが増えメール件数が増えた
  • 無視して問題ないログも増えているがフィルタリングできない( egrep -v を媒体ごとに増やすのは現実的じゃない)
  • 無視していいならそもそもログを吐かないようにすれば良いが、可視化されていないためジャッジしづらい(個⼈の感覚に依存)
  • ⼈員不⾜による負担増
  • エラーの増減の傾向を、感覚でしか追うことができない

⾼速横転開発の恩恵の反⾯、もはやこのままでは耐えられない
改善開始
EFKスタック

今後の動き

  • Fluentd(td-agent)のインストール
  • ログ収集の開始
  • Kibanaでの⽇々の状態監視(fto-sysエンジニアにて)
  • MLへのメール廃⽌
  • ログフォーマットの⾒直し

Fluentdインストール状況

対象サーバ16台中10台導入済み

ログフォーマットの⾒直し

  • ⼀個のログが改⾏で分かれてしまっている
  • 将来的には jsonにするなどの、構造化が必要

4番目 : N・E チーム

N チームのやったこと

f:id:cam-engineer:20161005151331j:plain:w300

1. GHE ブランチの削除

  • 課題
    開発が進むにつれて,GHE に feature ブランチが散在している……。
    必要なものと不要なものが混在している状態は混乱のもとなので,放置されていたものを綺麗にしました。
  • 対応内容
    • GHE 上で merged となっているものや,いらないブランチを一個づつ削除した。
    • 各個人のローカル開発環境では,以下のように削除した。
git br -d $(git br --merged | egrep -v 'master|develop|*')
  • リモートで消されたブランチをローカル環境に反映を忘れずに。
git remote prune origin あるいは git fetch -p origin など
  • 結果
    ブランチ113個から9個へ!
    また、本番リリース手順書に以下の項目を盛り込みました。
  • GHE 上でタグを付ける。
  • GHE 上から不要なブランチを削除する。

2. パスワードなどの秘匿化

  • 課題
    本番環境の MySQL のパスワードなどが設定ファイルに直で書かれているプロジェクトがあるため,環境変数から読み込むようにしました。
  • 対応内容
    dotenv ( https://github.com/bkeepers/dotenv )とは
    • .env ファイルに記載されている環境変数を読み込んで使用できるようにするための gem
    • Rails の場合,dotenv-rails という gem を使うと autoload してくれる。
  • 補足

E チームのやったこと

f:id:cam-engineer:20161005151417j:plain:w300

  • エラー通知メールの抑制
    • 現状
    • 課題
    • 対策

現状

  • アプリやメールサーバのログをlogmonで監視
  • エラーログが出た場合、管理者にメールで通知

課題

  • 全てのエラーを一律メールで通知しているため、件数が多くなり、重要なエラーが埋もれてしまう
  • swatchを導入
    • ログファイル監視ツール
    • 所定のパターン出現時、所定のアクションを実行
    • アクションは「頻度」を設定可能

5番目 : O チーム

f:id:cam-engineer:20161005151634j:plain:w300

0 さん率いる開発メンバーそれぞれが "すてる" を行いました!

完全停止の媒体のクーロンを消す

結果 f:id:cam-engineer:20161005151741p:plain

  • ユーザに悪いイメージを与えないように、サイトのドメインを止める
  • 個人のローカル・リモートブランチの精査、削除

    • 396 -> 1
    • 1つ気になることとして、いなくなったメンバーのブランチがある!
  • apache, nginx の conf を綺麗にした話

  • ミドルウェアが動かないので OS を変えた話
  • デプロイを整理した話
  • ディレクトリ整理の話

6番目 : N with Infra チーム

f:id:cam-engineer:20161005151857j:plain:w300

すてるもの・すてたいもの がたくさん

  • 古い機器
    • サーバー(R300とかSolarisとか)
    • スイッチ(2960G)
    • disk
  • サービス終了後の不要なもの

だけど、消すのは難しい(´・ω・`)

  • サーバー内のプロセスが起動している
  • ヘルスチェックが成功している
  • サービスのあいのり
  • DNSの設定が残っている 終了サービス ・ ・ ほんとに消して大丈夫だろうか(つд⊂)
    ⇒ エンジニア全体の協力が必要!

  • 積もり積もったBIGIP古い証明書 130個

要因

  • BIGIPの仕様の問題(アクティブスタンバイで証明書削除の同期できない)
  • サービス終了後の削除フローなし

今後のすてる

  • DNSコメントアウトされているもの
  • GIP(サービス終了時に返却お願いします) と BIGIPの設定
    ⇒ 新ネットワーク環境

BIGIPの閲覧アカウントを共有しますので、いらなくなったIPは確認してくださいね。
宣伝:障害対応(よくある事象) を纏めましたので、みなさん、トラブルシューティングにご参照ください。

7番目 : K・H チ-ム

f:id:cam-engineer:20161005152650j:plain:w300

自称変態キーボーダーであるKさんは、今回の「第1回 CAMビアバッシュ」の発案者!!

  • 捨てたいものはないですか?
  • 捨てるって何?
    • 10万規模のコミット
    • 不要ファイルが大量にあるせいで肥大化
    • ブランチの命名規則がバラバラ
    • ログの削除やブランチの整理
    • git-svn使って移行
  • 捨てたのもの
    • httpd.conf@共通開発環境
    • 大量にあった conf のファイルをプロジェクトごとにコメント付与して見やすく!
  • 過去に捨てたもの
    • 『伝える第9回 大改造劇的ビフォーアフター 疲弊するシステム』
      注釈:過去に、社内勉強会にて、上記のタイトルで発表を行っていただきました。 「伝える」勉強会とは何かについては、また別の機会にこのエンジニアブログにてご案内があるかも?!

まとめ

今回、CAM 初の試みとしまして、ビアバッシュという形でライトニングトークのイベントを開催致しました。
当日は、70名以上のエンジニアが集まり、笑いあり、(当時を思い起こしつつ)涙ありの楽しいイベントにできたと思います。

"すてる"というテーマで、各チームが発表した今回の内容は、これで終わりにするのではなく、 エンジニア一人ひとりが業務の中で意識し、ワークフローに組み込むなど継続的に取り組んでいくことで効果が見えてくるものと思います。
これからも、日々新しく生まれる技術を追いかけながら、技術的負債を残さないように、シーエー・モバイルでは社内環境整備に取り組んでいきたいと思います。

インフラ視点で見た GitHub Enterprise の運用、更新など

Infra tool GitHub

こんにちは derax です
今回は弊社で導入している GitHub Enterprise について
インフラ視点で見た GitHub Enterprise とはどうなのか
構築からバージョンアップなどについて紹介したいと思います!

導入した経緯など

今回はインフラ視点なので割愛しますが
開発文化を変え、より効果的な開発プロセスとしていく土台として
2015年3月から導入運用を開始しました。

稼働、運用状況

  • オンプレミス(ESX)でマスタースレーブ構成の2台体制
  • 利用人数は80人程度
  • リポジトリ数はテストなどを含め 690前後

    構築当時の2015年ではクラスタ構成を構築出来ませんでした
    今年の頭くらいから GitHub Enterprise はクラスタが組めるようになり
    更に Github 謹製のバックアップツールも v2.7.0 よりクラスタの restore にも対応しました
    現構成は当時のままのマスタースレーブ構成で切り替え作業等発生してしまいます
    今のところ安定動作していますが、いざの時を考えると
    検証の上、切り替え出来ればなぁと思ってたりします

構築など

GitHub Enterprise はイメージファイルにて配布されているため
癖のようなものがありますが事前に検証を行っていれば問題ありません

配布されているイメージは以下の通りです

選択肢がオンプレミスとクラウドがあります
構築当時弊社はオンプレミス思考が強かったのでクラウド上ではなくオンプレミス環境で VMware のイメージを利用して構築し、 管理は vSphere Web client を利用しています
OVA イメージの「仮想マシンのバージョン」は 10 ですので注意が必要です

今から構築するのであれば
AWS と Direct Connect で接続を行った上でAWS上にクラスタ構成で構築してみるか
弊社はOpenStack環境もあるのでそちらのプライベートクラウド上に構築してもいいかなぁと思っています

バージョン更新

バージョン更新のスピードが早く、情報を追っていかないといけません
リリース情報はメールも受信しているのですが
折角 Slack も導入していますので使わない手はないです!

ということで公式ページの RSS を利用して Slack へも情報を流しています
Slack で情報を流していますので開発者への目にも止まり
社内エンジニアからアップデートリクエストが来る時もあります

アップデート作業自体は昼間行うと開発が1時間程度止まることになります
開発の手を止めないためにも夜間にて行っています

ですが夜間作業を行うことで当然課題も出てきます
アップデート作業には何かあっては行けないので念のため複数名で対応します
弊社のインフラチームは少数なので、次の日が手薄となってしまいます


アップデートの手順は以下な感じです

  • アップデート検証作業
  • 事前にパッケージのダウンロード
  • メンテナンスモードに切り替える
  • レプリケーション停止
  • スレーブでアップデートコマンド投入
  • 完了後、確認
  • マスタでアップデートコマンド投入
  • 完了後、確認
  • レプリケーション再開
  • ステータス確認
  • メンテナンスモード解除


アップデートのコマンドは
公式の手順にある ghe-upgrade を使いバージョンアップを行っています

導入初期段階では、1台辺り10分程度の作業で作業完了していたのですが
最近は1台辺り20分程度かかるようになりました
やはりデータ量が増えてくるとアップデートの時間も増えてきます

アップデート実行時間が伸びていると言っていますが
HDDの容量的には、約400GB中、5%利用している程度です

パッケージのダウンロードについては、5分程度でダウンロードは完了します

バージョン更新に伴うバックアップツールの入れ替え

バックアップ自体は GitHub 謹製のバックアップツールを利用しています

バックアップツールと GitHub Enterprise 本体のバージョンを合わせる必要があるため
本体のバージョンと共に、バックアップツールのバージョンアップも必要となります
GitHub Enterprise のバージョンアップとともに
git clone してバックアップツールの差し替えも実施します

ただ定期的にバックアップを行いたい場合は
cronなどでコントロールする必要があります

弊社では、jenkins にてコントロールしています


コントロールしていると格好良く言っていますが
単にジョブを定期的に実行しているだけです

GitHub Enterprise のバックアップツールのリポジトリは以下です
https://github.com/github/backup-utils/releases

障害対応

ど安定で障害対応の経験がありません・・・

他ツールとの連携

Slack、Redmine、JIRA などと連携しています
他にもインフラチームでは把握していない連携があるかもしれません

把握していないのは問題じゃないか!
と仰る方もいるかと思いますが
弊社では、エンジニアが各自の判断で比較的自由に連携ができるように
良い連携パターンを模索できるようにしています

困っていること

バージョンアップするとバックアップツールも入れ替えないと行けないのは、やや面倒ではあります
この辺はAnsibleを使用するなど、できる限り自動化していきたいと考えています

まとめ

  • GitHub Enterprise はイメージで配布されているので、収容先(ホストOSが動作しているところ)が必要
  • 慣れという意味でも構築、設定も念のため本格的運用の前に検証した方がよいです
  • バージョンの更新頻度が高いので、どう追随するのかを何となく決める必要があるし検証も必要
  • 安定しているとは言えバックアップ設定をした方がいいですが、バージョンアップと共にバックアップツールの入れ替えが必要になる
  • 他ツールとも連携出来る
    • 構築状況にもよりますが、Githubと連携できるサービスすべてがGitHub Enterpriseと連携できるわけではないので事前に調査が必要

エンジニアが働きやすい環境を創る(エンジニアのヘッドホン事情)

楽しく働く環境

こんにちは、シーエー・モバイルで、技術人事・技術戦略を担当しているA.Iです。

音楽を聞きながら仕事や勉強をしていると、集中力や効率が上がったという経験をされた方も多いかなーと思います。 弊社でも、ヘッドホンやイヤホンをつけて仕事をしている社員をよく見かけます。 コーディング・製作では、まとまった時間に集中して一気に終わりにしたいという思いからのようです。

f:id:cam-engineer:20160830170220j:plain

今回、エンジニアの楽しく働く環境作りの一貫として、エンジニアのヘッドホン事情に焦点を当ててみました。

そこで、弊社のエンジニアとデザイナーに協力してもらい、社内アンケートをとってみました。 その結果をご紹介します。

現在、開発や製作時に、ヘッドフォンやイヤホンを使っていますか(回答数48)

f:id:cam-engineer:20160808211459p:plain

使っているヘッドフォンやイヤホンの製品名を教えてください(回答数34)

一番多かったのは、意外なことにAppleの純正イヤホンでした。それ以外は個人の趣向で様々でした。

f:id:cam-engineer:20160830164345j:plainf:id:cam-engineer:20160830164353j:plainf:id:cam-engineer:20160830164354j:plainf:id:cam-engineer:20160830164500j:plainf:id:cam-engineer:20160830164459j:plainf:id:cam-engineer:20160830164501j:plain

どんな時に使いますか?(回答35)

やはり一番多かったのは、集中したい時でした。 コーディング作業時以外では、「パワーポイントの資料作成、ドキュメント整備する時」に聞いているようです。また、逆に「障害発生時にすぐ気づいたり、要望や悩みなどを聞き漏らさないように純粋に音楽を聞きたい以外は使わない」という回答もありました。

主にどんなジャンルの音楽を聴いていますか(回答36:複数回答可)

一番多かったのはJ-POP(19)、ついでアニソン(14)でした。ついでサントラ、ロックと続きますが、演歌や歌謡曲はゼロでした。

f:id:cam-engineer:20160808211512p:plain

開発や制作時に、音楽があると、開発や制作の効率やスピードに効果があると思いますか?

ほぼ効果を感じるとの回答でした。

f:id:cam-engineer:20160808211526p:plain

制作・開発作業が中断して、また音楽を聴くと集中力が戻りますか?

”中断時間が短ければ戻る”、”すぐには戻らないが、しばらくソースを書き続ければ戻る”などの意見もあり、概ね肯定的な意見でした

f:id:cam-engineer:20160808211310p:plain

ノイズキャンセルヘッドホンをつけてもらった

f:id:cam-engineer:20160830151019j:plain

"Team Geek"にエンジニアの集中状態を維持するために、ノイズキャンセルヘッドホンを配布したという記載もありました。トライアルで、普段は通常のイヤホンを使っている3名にその効果を試してもらったところ、このような感想がありました。

  • 話し声は聞こえるけど、他の雑音がないので気分的に落ち着いて開発できた
  • 開発に没頭しやすくなった
  • 集中したい時は手放せなくなった

f:id:cam-engineer:20160830165009j:plain

開発や制作の効率をあげていくために、ノイズキャンセリングヘッドホンは会社としても追加購入を検討をしていきたいと思います。

今回のノイズキャンセリングヘッドホンの導入検討や以前紹介させていただいたJetBrainsのIDEを使ってみるなど、シーエー・モバイルでは、エンジニアの楽しく働く環境作りに継続して取り組んでいきたいと思います。

技術力を促進させる横断組織の活動

楽しく働く環境 culture

こんにちは。

シーエー・モバイルで課金事業を担当しているエンジニアのkeny31です。

本日は、去年発足された技術戦略室という社内の技術力強化を推進する横断的な組織と、これまでに行ってきた活動内容を紹介させていただきます。

はじめに

「技術戦略室」とは

  • 社内のエンジニア技術レベル向上
  • 事業の成長に技術力で貢献する

を目的に昨年、2015年12月に発足されたエンジニア主体の横断的組織で、 社内の各事業部に所属している技術に熱いエンジニアで構成されています。

技術戦略室の構成

メンバーの中には、会社設立当初から様々な事業を支えてきたベテランから、 半期ごとに社内の技術力強化に最も貢献したエンジニアに送られる「ベストエンジニア賞」を 受賞したイケイケな若手まで年齢や経験、得意な技術分野も様々です。

現在は、スクラム大好きインテリな室長を中心に10名程で活動しています。

いざキックオフ!!

実際にどのような活動を行っていくか、どのようなエンジニア集団が集まる会社にしていきたいか、 活動内容とロードマップを作るために、今話題の「Chateau Ameba(シャトーアメーバ)」にて1日合宿を行ってきました。

当日の合宿内容に関しては、技術力強化に繋がる施策から環境改善、今後の未来像など、 部屋の壁(ホワイトボード)全てが文字で埋まるほど、白熱した議論で非常に盛り上がりました。

実際に合宿で出てきた内容

f:id:cam-engineer:20160722162219j:plain

ホワイトボードもこんな感じです

f:id:cam-engineer:20160722162217j:plain

私は、「キラキラIT女子エンジニアの積極的採用」による男性エンジニアのモチベーションアップと採用ブランディングを提案したんですが、 盛り上がったものの見事にスルーされました。

色々とやりたい事や改善していきたい事が山のように出てきたのですが、議論を重ねた結果、 下記の課題に対してアクションを考えていくことになりました。

重要課題キーワード

スピード & 品質 両方の実現のために何をするか

技術向上 何を強みとし、何をPRJに浸透定着させていくか

採用&技術ブランディング 優秀な人がきたいと思う組織と文化をどう創るか

技術者育成 技術者として成長するために必要なことなど

技術評価 技術者としてちゃんと評価されるために

働きやすい環境/制度 エンジニアにとって優れた環境、ジョブローテなど

実際に行った活動内容

重要課題キーワードを元に、施策レベルに落とし込んだ内容が下記となります。

  • 全社コード共通規約の作成
  • コードレビューを行う文化創り
  • 各プロダクトのエラー状況可視化と品質向上
  • エンジニアの働きやすい環境整備
  • エンジニアブログの再開
  • 各種勉強会の紹介と参加促進
  • 2016年度新人研修の企画と実施

実際に行動に移してみましたが、手探り感も手伝って、技術戦略室のメンバーだけが空回りしてしまって、周りを巻き込めずに上手くいかなかったものや、 1回きりで継続せずにそのままフェードアウトしてしまったものもありました。

ですが、その中でもエンジニアの反応が良かったものや、継続して行えているもの、来年も是非実施していこうと考えているもの。 そういった喜ばしい成果が上がった施策も出てきており、もっとこういった結果が出てくるように頑張っていきたいと思っています。

KPTで技術戦略室の半期を振り返る

f:id:cam-engineer:20160722162216j:plain

各施策の具体的な内容に関しては、次回以降に話していきたいと思います。

個人的な振り返り

f:id:cam-engineer:20160728182828j:plain

「技術戦略室」として様々な活動を行ってきましたが、個人的に十分に動けていない反省点があるものの、レビュー文化の醸成、プロダクト品質向上、勉強会への参加を増やしていったことなど、今後の改革に寄与できたところもあると思っています。

これからもシーエー・モバイルの技術力の向上、エンジニアの働きやすい環境を創り上げていくことを推進していきたいと思います。

あとは、合宿の時に私が提案した「キラキラITエンジニア女子の積極的採用」を何とか実現させられるよう頑張ります!!

エンジニアが働きやすい環境を創る(JetBrainsのIDEを使ってみる)

tool 楽しく働く環境

こんにちは、シーエー・モバイルで、技術人事・技術戦略を担当しているA.Iと申します。エンジニアが少しでも働きやすい環境、気持ち良く開発できる環境を創るために、日々画策しています。


開発効率を上げるエディタを探す

弊社ではGithub EnterpriseやSlackの有料プランなどを導入して、開発効率を上げる施策を行ってきました。今回は、エンジニアがコードを書く工程で効率を上げるために有料であっても開発効率のよいエディタを検討しました。

JetBrains製品を使ってみる

今回は、数名のエンジニアに協力を得て、”JetBrains製品を使ってみる”ことで、コード品質や開発効率にどういった効果があるのかを試してもらいました。弊社のサーバーサイド開発では、PHP(cake)とRuby On Railsを使用しています。そのため、PhpStorm、RubyMineを使用してもらいました。また、GOなど対応したIDEがなかった言語を書くエンジニアにはIntelliJ IDEAを使用してもらいました。また協力してもらったエンジニアには、アンケートを回答してもらいました。

f:id:cam-engineer:20160630151908j:plain

使ってみた感想(よかったと思えたところ)

アンケートの回答から概ね感想は好感触であり、コード品質向上、開発効率化などの期待感が得られたようです。

  • vim+ctagsで良いと思ってたが、そんなことはなかった。
  • ctagsなどと比べてコードジャンプの性能が非常に高いのが良い
  • リファクタ機能や補完機能が強力で使いやすい。ファイル検索がはやい
  • IDE内でMySQL, SSH, vagrant, gitが使えるため、ウインドウの切り替えが減り、作業しやすい
  • Android StudioとUI・操作方法・設定方法が類似しているので、Webアプリとネイティブアプリが両方あるサービスの開発時に、IDEの学習コストの観点で有利
  • 変数名のサジェスト、未使用変数の警告が出るなど、皆が一定のルールでの命名ができそうで、可読性が上がる期待感がある
  • 個人的に scala の開発がしたいので、複数の言語をサポートできる間口の広さは好ましい。
  • 他のIDEVimなどでも頑張れば同じ便利さを再現できるとは思うが、最初から使えるので楽。Vimキーバインドが良ければPluginもあるのが良い

f:id:cam-engineer:20160630151911j:plain

使ってみた感想(課題)

一方で、以下のような課題もありました。

  • キーバインドを覚えるために初期投資が必要
  • もっと軽いと思ってた
  • 海外製品なので日本語絡みのトラブルに遭いました(解決済)
  • リモート開発のための情報が出てこなくて、苦戦。。。

まとめ

協力してくれたエンジニアのほぼ全員が他の人にも薦めたい、とのことでした。もちろん、それぞれのエンジニアの好みも尊重しながらですが、現在のエディタからの移行を進めていきたいと思います。

シーエー・モバイル新卒エンジニア技術研修2016

研修

こんにちはメディアディヴィジョンの ono です。
シーエー・モバイルには、この4月に6名の新卒エンジニアが入社しました。
今回は、新人エンジニア向けの研修内容についてご紹介いたします。

研修のねらい

今回の研修の目的は「最高のスタートダッシュ」でした。
これまで当社の研修は LAMP 環境構築やシステム概論の講義形式で研修を行っていたのですが、
実際に研修のあとに業務で最高に走り出すためには、
「実務のフローの理解」 「自主的な問題解決」 「シーエー・モバイルの環境理解」
以上 3 点が不可欠と考え、 今回から研修スタイルを刷新しました。

研修テーマ

研修を実務に特化させるべく、新たな試みとして、
「実在の弊社サービスのバグ修正をテーマにした業務チケット消化バトル」
を行うことにしました(研修のために別の環境を用意しました)。

新人に実際に話しただいぶエモい研修説明

時は2016年 シーエー・モバイルに入社してきた6人の若者がやってきた。

若者達は突如試練にぶち当たる。

サービスの前任者が大量のバグを残したまま全員事故に遭ってしまった。

対応できるエンジニアは新人だけ・・・。

2チームに別れ、チーム内で協力しながら、

次の金曜日までにとあるサービスのバグチケットを解消し、リリースしなければならない。

先輩社員の協力を得つつも幾つもの困難を乗り越える

若者達は・・・、

果たして無事サービスをリリースすることができるのか・・・。

研修の事前準備

  • 研修用に用意した環境内で、実在の当社のサービスのコードに、あえてバグを仕込んだリポジトリを準備
  • git log を消すため .git 消して git init してそのあと各チームごとのリポジトリに登録
  • 開発サーバに実際、よく稀にあるようなバグ状態のプロジェクト設置
    • typo があってリンクが切れてる」
    • 「リクエストパラメータつければ他人の情報がみれる」
    • Apache エラーで立ち上がらない」 などなど
      調べる力、探す力、協力を仰ぐ力が試されるようなチケット25個
  • redmine でバグのチケットを起票

新人の実際にやった業務フロー

事前準備

  • ローカル環境セットアップ(Ansible)
  • リポジトリを fork

その上で
1. Redmine 起票されたチケットをアサイン
2. ローカル環境でブランチ作成
3. バグ修正を行う
4. プルリクエストを出す(GitHub Enterprise)
5. 先輩からレビュー(洗礼)を受ける
6. マージされたら開発環境で pull して確認

上記の当社の実際の開発フローを全員に体験してもらいました。

f:id:cam-engineer:20160603142348j:plain プルリクエスト説明中

研修中の様子

スムーズにいけたチームもあれば、環境を破壊してしまったチームもあり、
開発以外でもつまづいたりしていました。
毎日1時間、レビューおよび質疑回答時間として先輩エンジニアがフォローし、
また、Slack でも質問、回答を行い問題解決にあたりました。

悪戦苦闘する新人と先輩社員の図
f:id:cam-engineer:20160603142009j:plain

f:id:cam-engineer:20160603143137j:plain

研修振り返り&まとめ

内容を刷新しての初めての試みでしたが、運営の不備などはありつつも
研修を通して新人はプルリクでレビューを受ける文化に慣れ、
今現在実務に関わり、最高とは言わないまでも 「とびきりのスタートダッシュ」 を決めてくれています。

一方、研修後の振り返りで運営面での課題も多く見つかったので、来年の研修ではより良くなるよう調整をかけていきたいと思います。

この研修を通して、自分の修正内容がマージされることの難しさを感じてくれたと思っています。 配属後、新人が実際のプロジェクトで、初めてのプルリクマージができたら非常に喜んでいて、記念日として祝っているなど、 シーエー・モバイルに一つ面白い文化ができたと感じています。