“やってみた系”技術ブログの技術のはなし〜クラスメソッドの働き方・社内アンケート【技術編】〜

960x400_gijutu

こんにちは。 take3000です。

採用面接でエントリー理由を質問すると「AWSがやりたかったから」「Swiftをやりたかったから」というふうに具体的にやりたい技術を教えてくれる人や、「マネージャーになるより現場でプログラミングを続けたかったから」と答える人がかなり多いです。そこで、みんな入社してからやりたいことはできているんだろうか?ということが気になったのでアンケートをとってみました。

クラスメソッドに入社してからやってみた技術について感想を教えてください

AWS

AWSが繰り出す大量のサービス追加とアップデートに対し負けじとやってみたブログを書きまくるという、そんな千日戦争を生きがいにしたAWS野郎の集まり、それがクラスメソッド。AWS事業部以外のメンバーもなんだかんだ仕事で使うので、クラスメソッドに入ってAWSに触らないということはありえないわけですが、そんなAWSへの取り組み方について回答をもらいました。

  • 2014年の夏。お客様が要望されていた機能(memcachedのノードをMulti-AZに分散配置する)がAWSから発表されたので、提供開始から1週間で検証、本番導入したこと。当時オンプレの世界から移ってきたばかりだったので、このスピード感に衝撃を受けました。

  • 前職まではオンプレのサーバーを利用した開発が多かったのですが、クラスメソッドではインフラはもちろんミドルウェアとしてもAWSを活用することが多く、物理的な制約に直面することはほとんどなくなりました。結果として、業務上はもちろんのこと、プライベートの開発・検証でもインフラ準備の煩わしさがなくなりました。AWSの特長として、単なるIaaSだけでなくそれをとりまくミドルウェアやツールと組み合わせ「業務上の課題を解決するエコシステム」を発達させる方向に進化している点があると思います。クラスメソッドではその恩恵にあずかるのはもちろんのこと、AWSのコントリビューターとしてエンジニアリングを満喫できる点が楽しいです。

  • AWSのCodeDeployを中心にデプロイフローを組み立てるのが、どのような案件にも導入しやすく応用の幅が広いので、便利だと思っています。

  • もはや手作業でのデプロイはめんどくさくてできない体になってしまいました。AWSと組み合わせると、もはやデプロイ用のサーバやファイル置き場を自前で用意する必要なしに完全にサーバーレスで実現できます。CIひとつとっても、CodeDeployを使う方法から、ゴールデンAMIを作ってまるっとサーバーごと作る方法まで多種多様なのであらゆるシーンに対応できます。デプロイ・CIにかかるコストが格段に下がり、エンジニアにパターン選択の余地が生まれている点で良い環境だと思います。

  • 今では当たり前に使っているAWSに触れているのが良かったです

    たまたまプロジェクトでAWSをつかってみたら楽しかったから続けたかったんだけど、その後の仕事がオンプレしかなくてクラスメソッドに転職しました、っていう人はけっこう多いです。

  • AWSのサービスが(常識の範囲内で)使い放題。

あくまで常識の範囲内です。

Swift

Swift の本を書く社員がいれば、Swift のコミュニティを運営する社員もいる。何気に Swift 熱が高いのですが、新しい言語ゆえにどこでもAWSの圧倒的サービスリリース、アップデートに対抗するには、圧倒的なスピードでブログを書いて仕事をこなしていくしかありません。しかし、ひたすら使いこなすことで「量は質に転化する」し、技術者としてスキルも上がっていくと思います。

  • Swiftによるアプリ開発をガンガンやっていけること!地方だとSwiftで書けるiOSの仕事がそもそもなかったり、東京に来てもまだSwiftで書ける案件は多くは無いと思うが、クラスメソッドでできた。

  • Swiftが発表されて半年という期間でありながら、業務への導入に際して、社内での調整がほとんど必要なかったこと。落とし穴がいろいろあったが、無事にのりきれた。

  • Swiftのバージョンが1の頃から作られているプロジェクトがあり、バージョンの変移を味わいながらSwiftに関わることができた。躓きも少なからずあるが、比較的初期のものでも積極的に取り入れようとする姿勢は「やってみた」系の醍醐味です。

”やってみた系”技術ブログは”やってみないと気がすまない系”技術ブログでもあったりします。

Scala

Scala は実際にやっている企業や現場が少なく、クラスメソッドの社員が書いた Scala 本を読んで入社を希望する人がけっこういます。クラスメソッド社内でも Scala を使うプロジェクトがたくさんとは言えませんが、それでもちょいちょいやっている、そんな Scala についてもコメントがありました。

  • いろいろなプログラミング言語に触れることができる点が入社して良いと感じました。もちろん使いたいからという理由だけでなく、適材適所で選んでいます。言語によって変わるもの、言語が変わっても通じるもの等、「プログラミングスキル」を再確認し磨く場としてうってつけです。その中でもScalaは、オブジェクト指向の考えかたはそのままに関数型の世界を私に体験させてくれ、考え方を拡張させてくれました。

  • Scalaでのサーバサイド開発。言語仕様が巨大なため、慣れるために時間はかかったが、後々開発が進むにつれて表現力が豊かな部分が効いてきた。モデルを書くのにボイラープレートコードを書かなくても済むのがいい。

プログラミング全般

特定の言語に限らず、プログラミングの仕方とかそもそもの話も回答がありました。

  • コードの設計やテストドリブンな開発を体験できたこと。テストドリブンな開発は始めこそ時間はかかるが、後々自分の書いたコードの品質が担保されている領域が把握できるため、長い目で見ればエンジニアにとってプラスになると思う。

  • 自分のアプリの設計に対する意見が通ったのが良かった。経験にかかわらず、アイデアが妥当であればチーム内で議論して開発を進められるのはとても楽しい。

チーム開発(コラボレーション・ツール)

どんなツールを使っているのかっていうのは、その会社や組織の開発スタイルの特徴がでてくるものだと思います。そして、ツールは導入すればいいってものではなくて、それをどんなふうに使っているのかも大事です。チーム開発や、チーム開発に必須なメンバー同士のコミュニケーションにも技術がいるのです。多分。

  • GitHub, CI, ChatOps, スクラムを用いて少人数でもワイワイやれたことが良かったです。 「一人で開発しているんじゃないんだ。」という気持ちが、大きなモチベーションになりました。

  • Atlassian製品やサテライトオフィスなど、リモートでも業務を円滑に進めるツールが整備されていて良いです。 会社として成果を出すための投資をする姿勢が良いと思います。

  • クラスメソッドでは、開発チームのメンバー同士のコミュニケーションにSlackを使っています。他のサービスとのインテグレーションが充実していて、開発をより円滑にすることができ、非常に便利です。

  • クラスメソッドの開発では、お客様に成果物をいち早く、そして継続的に届けることを重視しています。その中でCI(Continuous Integration)やCD(Continuous Delivery)は非常に重要な役割を担っています。CircleCIなどのようなサービスを使うことで、人的なコストをかけずにCIやCDを実現できているので、非常に役立っています。

  • チケットシステムによるタスク管理。影舞をいれてまわりに広めたけどイマイチ定着しなかった。技術に対するキャッチアップと習得が早いので良いツールをどんどん取り入れて試していける企業文化は好きです。

Git

意外なことに、Git が使えてよかったーっていう意見が多かったのも印象に残りました。

  • クラスメソッド入社時(編者注:2009年ごろ)、世の中ではSubversion全盛期でした。その中でのGitの導入はかなり挑戦的でしたが、プロジェクトに積極的に取り入れることができました。新しいことに投資してくれる会社だからこそできたことだと思っています。結果として現在はほとんどGitを使って開発が行われています。

  • 前職ではちゃんとgit使った版管理をしてなかった(まわりも使ってなかった)ので、使ってる人に教えてもらいながら使えるようになれたのは良かった。

 アジャイル

モバイルアプリサービス部では、3年前に外部のスクラムコーチの方に来ていただき、半年かけてスクラムの導入に取り組みました。現場のメンバーにとっては大変なことも多かったと思いますが、この時、チームが身につけた習慣や作法は仕事をする上での礎になっていると思います。

  • アジャイルコーチをお願いして半年ほどチームをコーチングしてもらったこと。特に継続的に開発/運用し続ける時に必要になる要素が身についた。

  • 技術ではないかもしれませんが、スクラムコーチを招いて実際のプロジェクトでスクラムを実践しながら学んで、改善を始めるまでができました。教科書を見るだけの導入に対して、効果が高かったと思います。そこで実際に招くことができる環境であるのが良いと思いました。また、一緒に導入したZenHubも良いツールです。

いろいろな技術トピック

技術が好きな技術者が100人も集まっていれば、社内だけでもいろんな化学反応がおきます。社内で読書会や勉強会も頻繁に開催されてます。また、おもしろそうだと思えば海外のカンファレンスにも行ってきてもらいます(もちろんブログも書いてもらいますが)。

  • Elastic 社の各プロダクト。検索エンジンならではの柔軟な検索機能だけでなく、Logstash / Kibana と組み合わせたログの可視化により、実案件で障害時の解析を効率よく行うことができた。あとブログ書いてたら海外のカンファレンスに連れて行ってもらえた。Elastic 社との共催で勉強会ができた

  • 社内のメンバーだけで統計や数学、機械学習やSICPの読書会を企画できたこと。

  • 自社イベントでの登壇に向けてApache Tezの調査をしたこと。クラスパスにJarファイルを追加するだけでYARNのMRエンジンをTezエンジンに切り替えられるようにServiceLoaderを使ったりしていて、その辺のソースを読み込んだりしてEMRの制約下(当時はEMR AMI 3系でTezは組み込まれていなかった)でどのように動作させるか検証したのがおもしろかった。

  • さまざまな商用UNIXの管理がメインだったのでクセにならないよう B-Shell のみで作業してた。入社して bash → zsh  にしてから作業効率(補完とか)が格段にあがってうれしい。

  • AWS以外にSaaSも沢山使っていますが、DatadogとPagerDutyの組み合わせがとても良いです。

文化

どんな技術やツールも、それを使う人たちが何を目的にどうやって使うのかが大切なんだと思います。言い換えれば文化です。例えば、部署・職位・入社歴・年齢とかはコミュニケーションの障壁を上げてしまう要素ですが、そういったものをいかに取り払ってコミュニケーションそのものを軽く(そして早く)していくのも大切です。何か新しいことをやろうとする人を、周りの人や組織が応援するっていうのもそうです。

  • 会社で同じフロアにいる人も、海外で働いている人も、みんなコミュニケーションするときはチャットツールを活用しているので、働いている場所を意識せずに仕事ができるのはクラスメソッドのいいところだと思います。

  • 有名企業のお客様と直接取り引きがあるので、自分が構築に携わったシステムが世の中にどのような影響を及ぼしているのかを実感しながら仕事に取り組むことができた。自分が関わったシステムが提供するサービスがメディアで取り上げられたり、逆に、メディアで取り上げられたことによってシステムに影響することもしばしばで、自分が1ユーザとしてそのサービスを利用することもあった。

  • 自由に検証し、自由に提案/導入できることが嬉しかったです。 組織の制約に縛られることなく、新しい技術やツールを取り入れられます。 いい技術を見つけた時はブログで社内に向けてもアピール出来るのも良いです。いいブログを書けば、いい反応を貰えます。

  • 以前は本番環境は実績のある枯れた仕組みを使うことが良しとされていた環境に置かれていたこともあり、エンジニアとしては物足りなく感じることも多かったが、クラスメソッドに入社してからはお客様も新しいサービスに挑戦することに意欲的なので、新サービスが発表された翌日にはお客様と一緒に「とりあえず試してみましょうか」というような話ができるので、とても幸せ。

  • 自分がブログから発信した情報に社内外問わず、様々な形でフィードバックやリアクションがあることが非常にありがたい。良い記事を書けば反応が大きいことが多いので、その為の勉強や情報収集も自然と意欲的になる。

  • モバイルアプリ開発者もサーバーサイドに転向できるのがいい。能動的に動く人間にチャンスを与えてくれる環境は素晴らしい。

おまけ

  •  今では無かったことになっている Android 3.x のアプリ開発にチャレンジできたこと。

いろいろ手を出すから、いろいろなんかこう……(すいません。言葉がみつからないです)

まとめ

技術についてはいろんなことに挑戦がしやすく、その挑戦の結果がブログとしてアウトプットしやすいことが周囲の理解につながり、さらに挑戦しやすい環境をつくっていっているのだと思います。

もうちょっと詳しい話を聴いてみたいとお思いの方は、MEET UPイベント(会社説明会)を開催していますので、以下のリンクからご都合に合う回にお申し込みください。

https://classmethod.jp/recruit/event/