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

Septeni Engineer's Blog

セプテーニエンジニアが綴る技術ブログ

2015〜2016年で開発組織を作るためにやってみたこと

Scala スクラム DDD 勉強会

こんにちは、杉谷と申します。 GANMA!を開発しつつ、社内環境を整えたりとかしています。 この会社に入社してから3年(+1ヶ月)経ちました。あっという間!

いろいろやってきた結果、組織がますます良い感じになってきたので、会社ぐるみで試みてきたことをご紹介します。

2013〜2014でやってみたこと

入社1〜2年目は以下のことを行いました

  • Chatwork / Stash(現BitBucket) / Confluence / JIRAの導入
  • 開発ポリシーの制定
  • TDD研修・スクラム研修
  • システムリーダー定例
  • 裁量労働制の導入
  • 評価制度の改善
  • 会社標準PCをMacBookPro 15インチ(松)に
  • ゲーム部を立ち上げてみた

詳しくは前回のエントリ 2014年。開発組織を作るためにやってみた事 をご参照ください。

Slackの導入

2013〜2014の段階ではChatworkを利用していましたが、Slackに移行しました。

Chatworkを利用していたのは、"既に利用していたから + 特に大きな不満はなかった"というのが理由なのですが、 システム連携の楽さ・豊富さ、開発のしやすさ、エンジニアうけの良さ、を求めてえいやっと切り換えてしまいました。

移行してみた感想としては

  • プラグインが豊富で楽。システム連携では殆ど自分で開発しなくてもよくなった。
  • 物理より文字で会話したい、なエンジニアにはよく馴染む感
    • 文字の書き味・表現力がだいぶ良い
    • でも発言は気安い、チャット感がある。
    • 絵文字でのReactionが最高。 Cult of the Party Parrotが大繁殖f:id:ysugitani:20160808113531g:plain:w16
  • エンジニア以外の方々にはChatworkのほうが良さそう感は強い
    • チャンネル名・人名に日本語が使える
    • レスも発言単位に行え、1発言がメールとチャットの中間の重みを感じる。

といった印象で、移行に満足しています。

社内全レビューと社外レビュアー

良い開発を行うためにコードレビューは欠かせないのですが、 経験の浅いチームや人数が少ないチームではレビューの質や、視点の豊富さに不安が残ります。 誰かの思い込みによる主張で良くない方向にコードが曲がってしまう、とか最悪ですね。

これを防ぐため、チーム外からもレビューが行える仕組みを整えました。

我々はコード管理にAtlassian社BitBucketを利用しているのですが、そのプラグインに グループ単位でレビュアーを自動で追加できるプラグインWorkzoneというものがあります。

これを利用して、社内の全てのレビューに参加するグループを作成、 視点が偏らないように社外レビュアーとしてScalaドメイン駆動設計(DDD)伝道師のかとじゅん氏にも参加していただき、 現時点では2名で社内の全てのレビューに参加をしています。社外レビュアーはもう1名増える予定です。

なお、全レビューはあくまでアドバイスなので、指摘があってもマージなどはしても良いルールなので チームの自治権は維持されています。

"技術指針"の制定

上記全レビューを行う際、どういった基準で指摘を行うかを定めておかないと無用な混乱が発生するので、 前回エントリーで制定した"開発ポリシー"を進化させ、会社としての品質に対する考え方、採用する技術やその理由と例外、などをまとめた技術指針を作成しました。

内容は以下のような物です

  • 我々は”高速高品質”を目指す
  • 我々は保守性のあるコードを高速に生産する
  • Scalaを使う理由は気軽に品質を維持するため / Scalaを利用しない場合
  • スクラムを採用する理由はプロダクトオーナーがハンドルを握るため / スクラム以外を利用する場合
  • DDDを採用するのはチーム全員で要件の芯を捉え続けるため / DDDを採用しない場合
  • ユニットテストを書く理由はリファクタリングをし続けるため
  • テストを書く=遅いという思い込みを止めよう / テストを書かない場合
  • レビューを行うのは意識を保ち続けるため / レビューを行い続けるため属人性を高めない / レビューを行わない場合

全アクティブプロダクトでのScala・DDD採用率 100%

積極的に開発を続けているプロダクト全てが Scala・DDD採用となりました。(2016/8月次点で6プロダクト)

普及の経緯は以下の通りです

  1. GANMA!でScala・DDDの初採用
  2. GANMA!チームに他プロダクトから留学
  3. 留学を終え、Scala・DDDで新規プロダクト開発に着手。外部アドバイザーとしてかとじゅん氏も加わる。
  4. その後どんどん株分けが進み全てのプロダクトがScala・DDD化

ScalaMatsuri将軍スポンサー + 勉強会の多数実施

環境としてはずいぶんと胸を張れる状態になってきたので、知名度を上げようといろいろ活動するようになりました。

ありがたいことに、これらのイベント経由で弊社を知った、というご応募を頂くことも多くなってきていますし、実際に入社に至った方ももう数名になります。

今後もイベントを続けていく予定です。connpassの Septeni×Scalaグループに入っていただくと新しいイベントの通知が届くので便利です。

今後と求人

今後もプロとして誇れる仕事ができる職場でありつづけられるよう邁進してゆきます。

もし弊社にご興味をもっていただけたかたがいらっしゃいましたら 弊社コーポレートサイト経由のセプテーニ・グループ中途採用窓口までご応募ください。 オフィスツアーも毎月実施しています。こちらもオススメです!

以上です。 読んで戴きありがとうございました。

【保存版】Scala/Scrum/DDD 困ったこと50連発ガトリングトークでの質問に対する回答

Scala DDD スクラム 勉強会

こんにちは。 @kimutyam (木村)です。

先日は『Scala/Scrum/DDD 困ったこと50連発ガトリングトーク』という勉強会にて登壇させていただきました。

scala-scrum-ddd-gatlingtalk.connpass.com

登壇後はガトリングすぎたのであっという間に終わったという意見がありましたので、

勉強会で質問していただいた内容の回答をまとめるエントリとします。 

勉強会内容について

www.slideshare.net

 

50連発でもスライド数173枚到達しました。

元々は100連発にしようと目論んでいたけど辞めてよかった...

以下のカテゴリで困ったことを50連発して各社でどのように解決してきたかというのが、このイベントの趣旨です。 詳細はスライドを参照ください。 

Q&A (Scala)

Question 1

Scala関連のドキュメントが英語ばかりで辛いです!良い読み方はありませんか? 英語覚えろks!以外でコツがあれば

Answer 1

セプテーニ・オリジナル 杉谷

英語を読むしか無いように思います。あるいは「100万円払うからplay2.5のドキュメント日本語化して!」と叫ぶとか。

オプト 平岩さん

自動翻訳して間違っててもいいから大意を掴み(掴んだ気になり)、その後目的の箇所を中心に読み進めるとかですかね? あと、英語は「覚える」ものなのかについては諸説ありそう。

CyberZ 門田さん

技術英語は読むんじゃなくて感じるんです

Question 2

非エンジニアにScalaをどうやって認めさせましたか? 「Scalaにしてる暇あったら機能増やして」に勝つ方法が知りたいです。

Answer 2

セプテーニ・オリジナル 杉谷

Scalaは型があり/表現力が豊か/IDE支援が強力、などの特徴から、慣れた後であれば他の言語に比べて圧倒的に楽にしっかりとした実装ができるし、慣れるのは大変ではない。PHPで同じ水準を保とうとすると大変だし、なによりPHPでそこまでちゃんとやりたがる人は多くない。つらい言語で衛生状態の悪いプロダクトをつくって人が寄りつかず衰退するよりは、より目的に合う言語で衛生状態の良い環境をつくり、組織を育てていくのであればScalaを積極的に利用しよう。という理屈でセプテーニ・オリジナルはScalaを利用しています。

オプト 平岩さん

一言で言うと、既成事実化しました(ニッコリ) ソフトウェアの減価償却の耐用年数を過ぎたら経営判断としてリプレースを検討した方が良いと思うので、それまで待つとか。

オプト 貴田さん

新機能の種類にもよりますが、マイクロサービス化できそうなのを立ち上げ時点からScalaで開発する方向はいかがでしょうか?

CyberZ 門田さん

誰か一人の意見ではなく、組織内のエンジニアの複数人の意見として上げました。メリットデメリットとか提示しつつ。 そもそも言語にこだわりは無いはずなので、越えるべきはラーニングコストかとおもいます。管理画面とか、ちっちゃいシステムとかでひっそり使って少しづつ慣れるのが一番かなと懐います。 それでも無理ならCyberZへお越しください

Q&A (DDD)

Question 1

DDDでドメインをコードに落とし込むところに工夫していることはありますか?

Answer 1

セプテーニ・オリジナル 杉谷

レイヤードなりヘキサゴナルなり、DDDに関係する全てのアーキテクチャドメイン層に余計なことをかかないようにするために産まれた物なので、ドメイン層にドメイン外のことをできるだけ書かずに済むよう気をつけます。またドメインに書くべき事がドメイン外に漏れ出さないようにも気をつけます。

オプト 平岩さん

DDDやってませんが、名前重要という空気と無駄な依存は作らないという空気はあります。

CyberZ 門田さん

名前付けですかね。ドメインに密接に関係すると何気ない名前でもすごく意味を持つので、後世のメンバーに誤解されないかをレビューなどでいろんな観点から考えます。ドキュメントも書きますけど、読まなくていいほうがカッコイイので。

Question 2

DDDって何が嬉しいのでしょうか?

Answer 2

セプテーニ・オリジナル 杉谷

セプテーニ・オリジナルでは採用するのはチーム全員で要件の芯を捉え続けるためにDDDを採用しています。「エンジニア以外にも翻訳不要で伝えることができる」「設計と実装に対する価値観が共有できる」という特徴があり、チーム全員で要件の芯を捉える助けになることを期待しています。

オプト 杉泊さん

DDDやってませんが、とりあえず弊社内にて質問してみたところ、誰も答えをくれませんでした……。 DDDやってない人が傍から見て簡単にわかるような嬉しみは無いのかもしれませんね。

オプト 平岩さん

概念だけでも参考になる部分はあり、学ぶべき価値のあるものだと思いますが、実践するまでのコストをどう捉えるか、という要素はあるかなと思います。最終的にはやりたいかどうかなので、やりたい人がいれば是非チャレンジした方が良いと思います。

CyberZ 門田さん

ベタな話は置いといて、 ビジネスロジック部分に対してアプローチするフレームワーク的なものってあまりないので、一番フワッとする部分の「標準化」を図れるのはすごく大きいかなと思います 

Q&A (開発ツール)

Question 1

使えるツールやライブラリを探すときは、 どうやって探してますか?(有益なサイトとか)

Answer 1

セプテーニ・オリジナル 杉谷

ググったりして見つけた物で、githubで人気のありそうなものを選びます。あとはTwitterでスゴそうな人がオススメしているものを選ぶとか

オプト 平岩さん

うちのメンバーの場合はtwitterが多そう。あとはgithubのtrendをウォッチしておくとか。 【宣伝】技術系キュレーションメディアです、私も公式Clipperというのを務めさせていただいてます。ツールを探すときにもオススメ!

CyberZ 門田さん

サイバーエージェントグループ内の知り合いにざっくり聞いたりとか。 いくつかグループ内のGithubを覗いて使ってるもの見たりもします

Question 2

仕様をドキュメントで可視化するために、 何か便利なツールやライブラリがあれば教えてください

Answer 2

セプテーニ・オリジナル 木村

我々はAtlassian(JIRA,Confluence,Bitbucket, Bamboo)を使っており、 ドキュメントは基本的にJIRAとの相性がいいConfluenceを使っています。 グラフィカルなドキュメントが必要な場合は別のツールを使うこともあります。 コンテキストマップはCacoo。シーケンス図、フローチャートmermaidを利用しています。

また以前まではスプレッドシートで統合テスト仕様書を記載してましたが、 統合テストを自動(コード)化する動きをとり、Bitbucketで管理するようにしました。 自動化出来てない部分はMarkdownで記載後、Bitbucketリポジトリ上で管理してます。 これによりバージョニングも可能になります。

オプト 平岩さん

いろいろ試した結果、仕様については、マークダウンに向いてること or マークダウンでも頑張ればできることは極力マークダウンでgithub管理した方が良いよね、って流れになりつつあります。 あとはだいたいgoogle driveでやってますが、仕様書を補足するようなもの(管理資料や、仕様書になる前段階のもの)に限定しつつある感じです。議論しながら多人数でドキュメントを更新できるのは便利ですね。

CyberZ 門田さん

今全社あげて丁度探してるところです(笑)

Q&A (チーム運営・スクラム)

Question 1

振り返りで課題が出ないということはつまるところチームの運用が 上手いこといっているというポジティブな勘違いに至ることはないでしょうか?

Answer 1

セプテーニ・オリジナル 木村

勘違いしている可能性はあると思います。 ただ、本当に課題が出ない状況なのかは個人的には意識しております。 たとえ1~2週間の期間のスプリントでも課題が発生しないことの方が少ないからです。

例えば進捗が悪く見えるのに何も課題がないとなると、課題を言いづらい状況なのか 危機管理能力が欠落しているのかのどちらかだと思います。 課題を出さずにスプリント未達成になることは最悪なので、 そのような事案が発生しないように予防線をはっておくべきではあると思います。

オプト 平岩さん

課題が出ないのは、

- チームが取り組んでいるミッションの難度が低すぎる

- きちんと振り返れてない のどちらかなのではないかなと思います。

振り返りでしゃべってくれる人があまりいないこともあるかもしれませんが、チームの皆で互いにファシリテートしあえることが理想ですが、最初のうちはリーダークラスの人(スクラムマスターとは限らない)が責務としてファシリテートをやっていった方が動き出しやすいと思います。

ファシリテートについては、議論が進むように各人に発言を促したり、課題を示唆したり、といった司会っぽいファシリテートもありますが、発言しやすい空気、心理的安全をどうやって作るかということも重要になります。例えば、お茶やお菓子をいただきながらやっちゃう、という手段もあると思います。

CyberZ 門田さん

慣れたチームだとたまにあります(笑) 基本的にはマンネリになっている可能性が高いかなと思います。 無意識のうちに過去出したものを避けていたりなど。 ただ、今までやったKPTを見返してみたら、「そういえばあれTryで続いてたけど、最近やってないね」とかありますし、やり方や場所などをガッツリ変えてみたら大体うまく行きます。

Question 2

コードレビューをする側の時に気を付けていることはなんですか? レビュアーは何に気をつけるべきでしょうか?

Answer 2

セプテーニ・オリジナル 木村

【コード内容について】

- 要件を満たしているか  

大前提となります

- 何をレビューして欲しいのかが明確になっていること

明確になってないとレビューできません。

- コード内容を全て説明できること

例えばコピペが検知できたら理解せずに書いてる可能性が高い

- レビュアーへの配慮ができているか

レビュアーが理解できる粒度まで落とし込まれているかを確認します。 大抵はレビュイーよりレビュアーの人数が多いので、 レビューのコストを下げるためにレビュイーが コストを支払う方が全体コストが抑えられる可能性が高くなります。

【コミュニケーションについて】

- 指摘する際はサンプルコードを付与する

- 人格否定をしないこと

 

弊社社員がまとめている記事も合わせて参考にどうぞ

【暫定版】新人エンジニアのプルリクエスト入門

オプト 渋谷さん

重視すること

- 複雑でないこと

- 名前大事

- 異常値・エラーを正しく処理しているか

- 適切にテストコードでカバーされていること

- トレードオフについて検討がなされていること

 

重視しないこと

- ソースコードの書式や整形

CyberZ 鈴木さん

・人格を否定するコメントは一切書かないこと

・キツい指摘になる場合は、「かも」などをつけてやわらげること 以上、2点に気をつけています。

 

レビュー関係でモチベーションを下げることは気をつけたいですね。

Question 3

プルリクエストレビューについて、例えばRubyJavaがあって、 担当者の得意不得意があって Rubyのレビュアー、Javaのレビュアーが 固定されたりするのについて対策ありますか?

Answer 3

セプテーニ・オリジナル 杉谷

そのようにレビュー不能になる段階で組織の負けなので、できるだけ属人性が高まらないようにチームを組んでいきます。 GANMAの場合、iOSしかみれないサーバ側しか見れない、というのは少数で、Scala/Swiftどちらもみれるとか、iOS/Android/Play全部いじれるというのは普通です。

オプト 平岩さん 

フルスタック指向のある人はどんどん色んなことをやってもらうとか? スキルの問題なのか(知識不足・経験不足)人の問題なのか(意識、仲の良し悪し)は切り分けても良さそう。両方のケースが多いと思いますが。

CyberZ 門田さん

ビジネスロジックのレビューについては、よほど苦手意識が無ければみんなレビューは可能かなと思います。 言語的なレビューになるとある程度得意(好き)な人がやるので良いとは思います。 

Question 4

>プルリクエストの指摘

レビューの確認項目は大分類すると

1.業務要件が満たされているか

2.コードの美しさ

の2つあるかと思いますが、 この2つが混在するとコメントが増えていったり 本来レビューするべきことを見失ったり、 今の現場で起きています。

 

レビューの確認項目で何かルール決めなどされていたら教えてください

Answer 4

セプテーニ・オリジナル 木村

我々は『pull requestを利用した開発ワークフロー』を参考にして レビューコメントにタグをつけています。

 

業務要件が満たされていることは必須条件です。[must]のタグをつけてます。

 

コードの美しさは保守や拡張におけるコストを削減したいので求めたいです。 ただ、コードの美しさについては思想の違いによって 美しさの定義もばらばらですし、 ビジネスサイドとの兼ね合いも関係しますので、必要条件ではないです。 [IMO]のタグをつけます。

 

[IMO]をつけることで議論対象にし、 ROIがもっとも見込める選択をレビュイーとレビュアー間で合意した上で決定します。 コードの美しさにおける対応遅延が発生している状況はデイリースクラムで検知し、 プロダクトオーナーと相談して対応スコープを考え直すこともあります。

オプト 平岩さん

[MUST] とか [IMO] とか [nits] とかやってなくはないですけど、厳密にルールは決めてないです。 レビューの場だけでなくて、普段からオーラルコミュケーションも含めて取るようにしておくと、レビューも円滑に進むのではないかと思います。

オプト 貴田さん

まだ始めたばかりですが、レビュアーを複数アサインするのを試しています。「コードの美しさ」の方はどのレビュアーも気づいたら言ってくれると思いますので、業務要件の方をしっかり見てくださいという人を1人(以上)指名しておくのもいいかと思います。 

CyberZ 門田さん

スライドにも書いたのですが、リアルファイトにならないよう、 主張か事実かをはっきりするとかですね。

Question 5

タイムゾーンが合わない状況でどうやってビデオ会議するんでしょうか? 結構きつくないんでしょうか?

Answer 5

オプト 平岩さん

普段はそういう機会はあまりないですけど、一回、自社のイベントでlightbendの横田さん(マサチューセッツ州在住)にオンライン登壇していただいたときは、発表順を一番最後にすることで何とかしました。それでも向こう早朝だけど。 アメリカと打合せするときは、どちらかが早朝でどちらかが夜みたいな合わせ方が多い気がする。

CyberZ 門田さん

CyberZ USA(サンフランシスコ)にエンジニアが居て、日本のチームと一緒に開発していますが、日本の午前中が向こうの夕方ぐらいなので、リアルタイムに話す時間帯を絞ればそんなにめちゃくちゃキツくはないです。ただ、向こうの治安が悪いのであまり遅くまではやらないです。 

Question 6

Scurmってどんな問題をどのように解決してくれる手法何でしょうか?

Answer 6

セプテーニ・オリジナル 杉谷

 セプテーニオリジナルではプロダクトオーナーがハンドルを握るためにスクラムを採用しています。開発においてリソースが潤沢であることは希で、殆どの場合、限られたリソースの振り分け判断が重要となります。スクラムバックログを通してプロダクトオーナーの意図を表せますし、スプリントとストーリーポイントにより、コストも根拠を持って可視化することができ判断が的確になります。

オプト 平岩さん

ベロシティ計測が意味を持ち始めるには1年以上とか続けないと意味ないのではないかなとも思います。 私は諦めました><

CyberZ 鈴木さん

請負的な雰囲気なチームを主体的に持っていくマインドを変えるための手法です。

Scrumは、

・全てチームの承認を元に実行

・スプリントというマイルストーンごとでの計画

・少人数でのチーム編成 という各メンバーの責任感と一体感を醸成できる手法なので変化に強いと考えています。

Question 7

今までスクラムをやったことのないチームに 導入するのに苦労したことはありますか?

Answer 7

セプテーニ・オリジナル 杉谷

スクラムとはなにか、どういったルールになるのか、という基礎部分を全員理解するところがスタート地点である、というところが最も難しいところです。セプテーニ・オリジナルでは会社に講師をお招きし、社長も含め全社員が研修を受けました。

オプト 平岩さん

個人的には立ち上げたばかりの会社でやったので導入は苦労しなかったですが、以前流行ってたころに比べて、世の中的にスクラムというものに対して幻滅期に入ってる部分もあると思うので、「スクラムをやる意図」を関係者で合意する必要があると思います。 

CyberZ 鈴木さん

いきなりガチガチのスクラムを行うのではなく、最小限から入っていくという感じです。 結局ガチガチのスクラムは、回すのも大変なので、最終的にゆるいスクラムになっていますが。

Question 8

スクラムにおけるポイント見積もりのコツってありますか?

Answer 8

セプテーニ・オリジナル 木村

- 複雑度で相対評価

- ポイントが大きくなるにつれて不確実性が増すことのでポイントの幅を増やす

フィボナッチ数列を採用するケースが多い印象

- ポイントが大きいチケットに関しては分割を検討

 

基本的に『エッセンシャルスクラム』を参考にしています

CyberZ 門田さん

スクラムでポイントは付けていないです。タスクを理解(イメージ)できているかどうかは、スプリント計画時に確認するのであまり問題はないです 

 

Question 9

レビューの大きさってどんなもんでしょうか? 小さな単位(メソッドの単位とか)でやるとやりやすいとは思うんですが、 全体を俯瞰してレビューできないかな、とも思います。

Answer 9

セプテーニ・オリジナル 木村

レビューのそれぞれ解決したい内容が異なるはずなので、 一概に粒度のレギュレーションは決めかねますが、 レビューしてもらうモジュールを限定的にする努力はしてもらう感じです。 チケットスコープ=プルリクエストスコープである必要はないと考えます。

 

また、単一責務の原則(SRP)、開放/閉鎖原則(OCP)が守られていないとレビュー粒度が肥大化すると思います。 責務=変更の理由であり、変更の理由が複数になっている場合は修正範囲が増える傾向があります。 拡張に対して開いていればコードの再利用ができ、修正に対して閉じていれば修正箇所を限定でき、 結果レビュー粒度が小さくなります。

 

土台コードが腐っているとレビューの度にボディブローを浴びるので、 そのような状況の時は技術的負債を返済する動きをとって事前に予防するのも大切かと思います。

オプト 平岩さん

コードレビューをするということと、ハイレベルアーキテクチャを把握するということは、別のタスクではないかなと思います。

 

ハイレベルアーキテクチャを理解できていないことが、コードレビューにとってマイナスになるなら、レビューに入る前にアーキテクチャを理解する工数を確保すべきかなと。方法はいろいろ(ひたすらドキュメント読む、詳しい人と打合せする)あると思いますが。

CyberZ 鈴木さん

全体のレビューは、GitHubではなく別で設計レビューという形でやっていますね。

 

なので、GitHubで見るコードレビューは基本的には、 小さい単位に分割してWIPでもらってレビューを実施しています。

Question 10

スクラムからDevOpsへ移行する検討はあるのでしょうか?

Answer 10

セプテーニ・オリジナル 杉谷

DevOpsとされるものの効果の「頻繁なリリースを可能にする」と相反するのでは?というご質問だとすると、スクラムだからといってスプリント区切りでしかリリースしないわけではないので、移行する物では無く共存する言葉だとおもいます。

オプト 平岩さん

スクラムとDevOpsは対立する概念ではないと思います。スクラムは方法論に近く、DevOpsは概念に近いかなと。

CyberZ 鈴木さん

スクラムとDevOpsは対立する概念ではないですね。 

Q&A (その他)

Question 1

PHPの開発で破綻したことはどんなことだったのでしょうか?

Answer 1

セプテーニ・オリジナル 杉谷

テストも無く設計のポリシーや知識もないまま機能追加を塗り重ねた結果、不具合が頻発し、業務として使い続けるには信頼できる品質ではなくなってしまった、という内容です。なお言語が悪いわけではなくPHPでも技量と衛生維持の意識さえ有ればちゃんとやることは可能です。

勉強会風景

勉強会は弊社の牧場スペース(!?)で行いました。

オープニングトーク(杉谷)

f:id:kimutyam:20160727194139j:plain

発表(木村)

f:id:kimutyam:20160727195649j:plain

LT&懇談会

f:id:kimutyam:20160727215015j:plain 

感想

この勉強会はScala将軍達の後の祭り#7 市ヶ谷Geek★Night「Scala大名の平成維新〜殿中でScala!〜」の懇談会で技術話をしていたCyberZさんとオプトさんと類似した開発手法および技術を扱っていることに気付き、3社で何か共同勉強会をやってみれば面白いんじゃないかとなったのが話の発端です。

Scala/Scrum/DDDで各社話そうと言ってましたが、会社の色がそれぞれ出ていて面白かったです。

CyberZさんとオプトさん改めてありがとうございました。 

 

各社のTipsのまとめとしてイベントに参加いただいた方含め、このエントリをみていただいている方の何か役に立てると大変嬉しく思います。

 

Firebaseの設定をビルド環境ごとに切り替える[iOS][Android]

こんにちは!寺坂です。

GANMA!では、iOS/Androidのアプリに Firebaseを導入しています。

いったん必要な部分だけ利用しているので、
Analytics, Notification, Crash, Dynamic Linksなど、まだ一部の導入だけですが、

徐々に利用ノウハウを貯めていっています。

今回は、導入に際して行った環境切り替えのアプローチを紹介したいと思います。

続きを読む

エンジニア業務に役立つ英語学習のコツ

はじめまして、4月から新卒入社した大北です。 実は私、入社するまでプログラミング経験が0でした。現在はHttpやデータベースなど、プログラミングの基本を1から、マンツーマンで叩き込んでいただいています。

そんな私がこれまでやってきたことのうち、唯一役に立っていると感じるのが英語学習です。開発用語は英単語が多いですし、クラス名などを考えたり、ドキュメントを読んだり、意外と英語を使う機会が多いですよね。

今回は入社してからの3ヶ月間で使った英語学習方法をお伝えします。

続きを読む

Automation of Load Testing by Gatling

Gatlingによる負荷試験の自動化

In this tutorial we will create an load testing by using Gatling Tool. First, I am going to tell you about what is load testing and what is the gatling tool. Then, I will show you the simple scenario and results. Tips for reading this tutorial, I would suggest you read this tutorial step by step and I hope you will enjoy it too.

続きを読む

editorconfigでエディタの設定を共通化

editor

新卒1年目の東です。

僕はもともとvimをメインで使っており、rubyを書いていました。javascriptを書いていた時期はsublime textを、scalaを書くようになってからは intellijを使うようになりました。複数のエディタを使うようになると、インデントの整え方など共通して使える方法があれば便利ですよね。

そんな問題を解決してくれるのが、editorconfigです。

editorconfig.org

続きを読む

Management Reading Club

こんにちは、セプオリ隠れ広報の関です。

今回も前回の記事同様、オフィス内の取り組みについて書こうと思います。

セプテーニ・オリジナルでは、有志で結成されたManagement Reading Club(通称MRC)という会があります。 どういう会かというと名前の通り、マネジメントに関する本のいわば読書会です。

続きを読む