Cybozu Inside Out | サイボウズエンジニアのブログ

 

「第6期サイボウズ・ラボユース成果発表会」開催

サイボウズ・ラボの光成です。3月30日に第6期サイボウズ・ラボユース成果発表会を開催したのでその報告をします。

サイボウズ・ラボユース

サイボウズ・ラボユースとは日本の若手エンジニアを発掘し、育成する場として2011年に設立されました。

ラボユース生が作りたいものをサイボウズ・ラボの社員がメンターとしてサポートします。 開発物の著作権は開発者本人に帰属します。基本的にオープンソースとして公開するのが条件です。

去年からは最大1年の通年募集となっています。

今年は3月で修了される3人の方と、現在開発継続中の4人、ラボユースOBから一人の発表がありました。

修了生の発表

緑川志穂さん

緑川さんは楕円曲線計算ライブラリecpyのC++による高速化というテーマで発表しました。 メンターはです。 f:id:cybozuinsideout:20170331150917j:plain

去年の中間発表ではペアリング暗号ライブラリのPython実装を紹介しましたが、今年はC++で開発したライブラリをPythonから呼べる形に改良しました(ecpy)。 PythonからC++ライブラリを呼び出すところでかなり苦労されたのですが、何度か実装・設計をやり直してきれいな形にもっていけました。 結果としてPython版に比べて約5倍の高速化を達成しています。 今後はPythonのパッケージ管理サイトPyPIへの登録を考えているそうです。

城倉弘樹さん

城倉さんはDPDKを用いたネットワークスタック, 高性能通信基盤というテーマで発表しました。 メンターは私です。 f:id:cybozuinsideout:20170331150822j:plain

DPDKとはカーネルをバイパスしてユーザランドから直接ネットワークカードを参照して高速通信をするライブラリです。 高速なのはありがたいのですが、ハードウェアに密着していてなかなか癖のあるライブラリです。 城倉さんはDPDKを使って高速通信をしつつも、なるべく簡単にアプリを作れるようなフレームワークSTCPの開発を目指しました。

Ether, ARP, IP, UDP, ICMPなどの実装は完了し、TCPも動いています。 10GbEのNICをつないだマシン間でpingをとばし、そのレイテンシを計測しました。Linuxよりも2倍速かったとのことです。

それでもまだまだ全然DPDKの性能を出し切れていないので、今後はどのぐらい高性能通信ができるか研究開発を続けるそうです。

篠崎慎之介さん

篠崎さんは「強化学習による文字認識」というテーマで発表しました。メンターは岩波データサイエンスの刊行委員を務める中谷さんです。

残念ながら諸般の事情で4カ月ほどしか参加できなかったのですが、一般的な画像の文字認識というチャレンジングな課題に対して非常に精力的に最新の論文を読んで実装していました。

まず再帰的ニューラルネットワーク(RNN)とHard attentionという技法を用いて一文字の画像を認識します。 次にmultiple object recognition with visual attentionという技法で複数物体を認識できるように拡張しました。

MNISTの数値データを適当にくっつけて3文字にしたデータセットに対して評価していました。 画像サイズが大きくなって、文字が離れると認識率は落ちるのですが28 x 84だと98%ほどの認識率になったそうです。

開発中の人の発表

西田耀さん

西田さんはヒトと機械に優しい言語nvというテーマで発表しました。 メンターは30日でできる! OS自作入門の著者の川合さんです。 f:id:cybozuinsideout:20170331150941j:plain

西田さんはこの本の熱狂的愛読者で2冊も購入したそうです。

今回開発中の言語nvは永続変数が使えて実行状態を復元可能なものを目指しています。 ここで永続変数とはプログラムを終了しても値が保持される変数で、nvでは一つの関数呼び出しで保存できるようにしました。

また、変数だけ保存してもプログラムを再開することはできないので、合わせて実行状態も復元できる機能を追加しました。

たとえば変数iを0から1ずつ増やしながらその値を表示するプログラムを

for{i = 0}http://blog.cybozu.io/entry/2017/04/04/080000{i++}{print i}

と書くと、実行中いつkillしても次回再開するとそこから動くようになるそうです。

今後はプログラムを表現可能なグラフ構造を扱う機能や複数のプログラム間で変数を共有できる機能を追加したいとのことです。

質疑応答ではメンターの川合さんが作成されたpersistent-Cとの比較で熱い議論をされていました。

小津泰生さん

小津さんは「自由度の高いグラフ描画言語の開発」というテーマで発表しました。 メンターは川合さんです。

小津さんは当初は別の言語の課題をしていたのですが、途中でテーマを今回のものに変更しました。

ExcelやGnuplotなどの既存のグラフ描画ソフトは細かいデザインを指定できないのが不満なのだそうです。 大学ではレポートのグラフに関していろいろ細かい指定があるのに、なかなか対応しづらいそうです。

開発バージョンでできるグラフの紹介をしました。複雑な数式を書けたり、グラフの値をLaTeXなどから参照できることにすることで論文を書きやすくすることも考えているそうです。

make_now_justさん

make_now_justさんは「先読みと後読みが可能なO(n)で動く正規表現エンジン」というテーマで発表されました。 メンターは西尾さんです。 f:id:cybozuinsideout:20170331150910j:plain

狭義の正規表現では「AまたはBまたはCを含む文字列にマッチする正規表現」はかなり複雑な形になります。 これを簡潔に表現するために導入されたのが先読みや後読みという機能です。

正規表現ライブラリはたくさんのものがあり、たとえばre2は決定性有限オートマトン(DFA)を用いて入力サイズNに対してO(N)の計算量で処理します。 re2は高速なのですが先読みや後読みをサポートしていません。 そこでO(N)の計算量でそれらの機能を実現する方法を設計、実装するのが目的です。

現在はまず先読みを事前に処理してから、それを除いた正規表現を処理するアルゴリズムを実装しました。 O(N)では動いたのですが、ネストできない点と、3回パースするのが難点で、それを改良するために現在はBFA(boolean finite automata)と状態を論理式や論理値で持つ方法やそれ以外の方法を検討しているとのことです。

高品佑也さん

高品さんは多変量の時系列データに対する異常検知アルゴリズムの実装というテーマで発表しました。 メンターは中谷さんです。 f:id:cybozuinsideout:20170331150926j:plain

異常検知とは、予期されるパターンにそぐわないデータを検出するというタスクです。たとえばサーバのアクセスログから不審な動きを検出して警告する、といった応用があります。

開発を初めて1カ月半なのですが、まずデータをクラスタリングし、小さなクラスタを異常とみなす方法をとりました。クラスタリングには、Hierarchical Temporal Memory(HTM)という階層的モデルの初期バージョンであるZeta 1アルゴリズムというものを用いました。

Water Treatment Plant Data Setという下水処理のセンサーログのデータセットで実験したのですが、残念ながらよい性能はでませんでした。

その理由として、HTM/Zeta 1が連続値の扱いに向いていない点や、そもそももっとシンプルなモデルで十分なデータだった可能性などをあげていました。

今後は既存の様々な手法を試したり、自分で考えた新しいアルゴリズムを試していきたいとのことです。

ラボユースOB

内田公太さん

内田さんは第2期OBでkprobesでカーネル空間ブレークポイントというテーマで発表しました。 内田さんは現在サイボウズ3年目でSREメンバーとして働いています(cf. kintone と連携する図書管理システムを作ってみた)。

KprobesとはLinuxカーネルのにbreak pointをおける機能で、任意のアドレスにbreak pointをおけるもの、関数の先頭のみのもの、関数から戻るときのものなどの機能や使い方の紹介をしました。 来月発売予定の『Linuxカーネルモジュール自作入門』という書籍の紹介もしていました。

終わりに

みなさん成長が著しく、また熱心なのに圧倒されます。 質疑応答に参加してくださった方、OBの方どうもありがとうございました。 f:id:cybozuinsideout:20170331151348j:plain

修了生の方が感想を書いてくださったのでリンクします。メンターも逆にいろいろ教えてもらうことも多く勉強になりました。

正式な第7期サイボウズ・ラボユースの募集は4月に出す予定です。 開発意欲の高い方の応募をお待ちしています。

 

@lestrrat 氏に Kubernetes を教えてもらいました

@ymmt2005 こと山本です。SRE とかやってます。

サイボウズでは「Neco」という、クラウド基盤のアーキテクチャを刷新するプロジェクトを進めているのですが、今回は @lestrrat こと牧大輔さんをお招きして Kubernetes の導入を検討しはじめた話です。

当日の牧さんの資料は以下で公開されています。

現状のシステム

サイボウズのクラウド基盤は 1,000 台規模の物理サーバーと数千台の仮想マシンの上で動作する数々のサービス群で構成されています。どのサービスをどのサーバー・VM で動作させるかは現状人手による暖かみのある管理方式で、規模の増大に伴い工数も増えています。

多数の物理サーバーを保有しているので遊休リソースも相当あります。画像変換処理などで遊休リソースを有効活用する Kodama という仕組みも自製しているのですが、Kodama に遊休リソースを割り当てるのは人手になっており、自動化しきれていません。

アプリケーションのデプロイに関しても、Docker 等のコンテナ技術を採用できておらずバージョンアップ作業などで一々人手による設計・実装作業が必要な状況です。

Neco でやりたいこと

次期アーキテクチャで目指す理想はこんなところです:

  • CPU やメモリといったリソースの空き状況を見て自動的に適切なサーバーを選択
  • サーバー故障時や退役時の自動的なサービス再配置
  • 配置されたサービスの発見方法(サービスディスカバリ)を提供
  • アプリケーションはコンテナとしてデプロイ

Kubernetes とは

Dockerrkt の登場で近年 Linux のアプリケーションのデプロイは急速にコンテナ化が進んでいます。

ただ、素のコンテナエンジンではデータセンターで運用するうえで必須となる冗長化やサービスディスカバリの機能がないため、開発環境はともかく、大規模な運用に必要なパーツに欠けている状況でした。と、いうのは一昔前の話です。

現在はコンテナを大規模な分散環境で自動的に管理するミドルウェアの開発が活発に行われています。代表的なものは以下です。

Kubernetes は元々は Google が開発していたものをオープンソース化したもので、その経緯から特に GCP では容易に利用できるようになっています。

勉強会の内容

社内で声をかけたところ、牧さん直々の勉強会ということで 10 名以上参加して実施しました。 勉強会の参加者は、一通り以下のチュートリアルをこなして参加しました。

牧さんの資料をもとに、builderscon のサイトを実際に k8s でどのように管理しているかや、以下のような便利ツールを教えてもらいました。

記念写真 f:id:cybozuinsideout:20170316134134j:plain

今後の予定

もくろみ通り、k8s 熱が社内で盛り上がっている状況です。当社のようなオンプレミス環境での構築はそこそこ大変そうですが、まず開発用データセンターに構築してノウハウを貯めていきます。

知見がたまりましたらまたブログで公開していきますので、応援よろしくお願いします。

お忙しい中勉強会を引き受けてくださった牧さん、ありがとうございました!

 

「障害に捨てるところなし」というお話をしました

どうも!アプリケーション基盤チームの@yokotasoです。 3月11日にBattle Conference U30 というイベントでお話をさせていただきました。 準備がてら作成したディスクリプションを公開します。

キーノートはSpeakerDeckからどうぞ!こちらも参考にしていただければ、嬉しい限りです。

では、どうぞ!

障害にすてるところなし

f:id:cybozuinsideout:20170310102053p:plain:w300

サイボウズ株式会社の横田です。

「障害に捨てるところなし」というタイトルで少しお話させていただきます。お手柔らかによろしくお願いします。

運用障害の話

f:id:cybozuinsideout:20170310102337p:plain:w300 f:id:cybozuinsideout:20170310102652p:plain:w300

まずはじめに、今回のお話をするにあたりまして

運用障害でご迷惑をおかけしたみなさま、大変申し訳ありません。 より快適に利用いただけるサービスを目指しまして、対策・改善をおこなっております。

これからも、弊社製品をよろしくお願いいたします。

クラウドの規模と稼働率

f:id:cybozuinsideout:20170310104031p:plain:w300

障害の話をする前に、サイボウズのクラウドの規模感についてお話させてください。

ご契約いただいている会社様は18000社、ビジネス規模では、年間の売上が40億程度の規模になってきています。 稼働率は99.9 % をだいたいクリアするくらいです。

さて本題

f:id:cybozuinsideout:20170310104725p:plain:w300 f:id:cybozuinsideout:20170310104728p:plain:w300

障害というとネガティブなイメージを持たれがちなんですが、

f:id:cybozuinsideout:20170310104731p:plain:w300

ちょっとまってそんなことないよと。

f:id:cybozuinsideout:20170310104734p:plain:w300

チョットイイね!くらいまで持っていこうよという話をしたいなと思います。イイねマーク、気持ち小さくなっております。

f:id:cybozuinsideout:20170310104737p:plain:w300

4つのネタで、失敗から徹底的に学ぶ障害学習の話をしていきたいと思います。

基礎知識を身につける

さて、1ネタ目。基礎知識を身につける。基礎的な素養を磨く話です。

f:id:cybozuinsideout:20170310105626p:plain:w300 f:id:cybozuinsideout:20170310105629p:plain:w300

障害からコンピュータの基礎を学ぶ

f:id:cybozuinsideout:20170310105835p:plain:w300

コンピュータの稼働状況を表す基本的な指標としてCPU、メモリ、ディスク、OSキャッシュなどがあります。

障害調査はボトルネック探しからはじます。

大規模サービス技術入門 という素晴らしい本があります。本を参考にしながら、何度も障害調査をしていくと、基礎的知識が身につきます。私もお世話になりました。

障害のたびにメトリクス監視ツールなどを眺めることになると思いますが、こういう経験をしていくと基礎的な素養と経験が身につきます。

障害がコンピュータの基礎を教えてくれた

f:id:cybozuinsideout:20170310105838p:plain:w300

こうして得た知識と経験は今の私にとっては素晴らしい財産です。障害調査、設計などにとても役に立っています。 問題の原因がわからないとき、落ち着いて基本的な指標に立ち返って解決に向かったこともあります。

f:id:cybozuinsideout:20170310111001p:plain:w300

「コンピューターの大切なことは、障害が教えてくれた」といってもいいと思います

知識を深掘りする

2つめのネタは、知識を深掘りする話です。

f:id:cybozuinsideout:20170310111712p:plain:w300

f:id:cybozuinsideout:20170310111715p:plain:w300

障害を通して、動作原理を深く理解しましょう。

f:id:cybozuinsideout:20170310111717p:plain:w300

MySQLIndexが使えないことが原因で障害になったことがあります。

f:id:cybozuinsideout:20170310111721p:plain:w300

原因としましては、重複を取り除くために安易につけたGROUP BYが原因でした。 MySQLJOINのときにIndexを利用するんですが、そのIndex とは違う列で GROUP BY を行うのでusing filesort になってしまう。 味わい深いですね。

f:id:cybozuinsideout:20170310111723p:plain:w300

この問題、MySQLIndex に関する動作原理からすると非常にあたり前な現象です。 この障害を通して、MySQLIndex を使った動作原理が実は理解できていなかったことがわかりました。 障害調査のたびに、ハイパフォーマンスMySQL を何度も読み返してやっと理解できたなと。

f:id:cybozuinsideout:20170310111726p:plain:w300

最初は理解できないことでも、直面した問題を読み解くことで、プログラムに関する深い理解が得られるのです。 障害は最高の良問だと私は思っています。

チームで強くなる

3つめは、チームの話です。失敗がすることは誰でもあります。であれば、失敗を受け入れるほうに注力するのも筋は悪くないはずです。

f:id:cybozuinsideout:20170310114542p:plain:w300 f:id:cybozuinsideout:20170310114544p:plain:w300

失敗の名は

f:id:cybozuinsideout:20170310115045p:plain:w300 f:id:cybozuinsideout:20170310115048p:plain:w300

弊社もご多分に漏れず、おおきな失敗をしております。 S2DaoからHibernateへの移行に失敗しました。パフォーマンス劣化、障害を起こしました。ご迷惑をおかけしました。 言い訳になりますが、S2Dao、いいフレームワークなんです。EOLなのが残念です。

失敗を受け入れる文化

f:id:cybozuinsideout:20170310115315p:plain:w300

じゃあ、どうやって失敗をうけいれるのかという話です。

f:id:cybozuinsideout:20170310115401p:plain:w300

私がおすすめするのはPostmortemを書くことです。Postmortemは振り返り文章のことで、失敗を整理、分析、共有するのに役立ちます。超有名企業の大規模障害のPostmortemをWebで読めるようになっていたりします。Webに公開する必要はないですが、チームでこういった文章を共有して話せる文化があるといいですよね。

失敗を共有する文化

f:id:cybozuinsideout:20170310120045p:plain:w300

失敗を共有することで、同じ失敗を繰り返さないように組織の問題として捉え直すことが出来ます。

ありがちな話ですが、失敗を共有するのは恥じらいや申し訳無さから難しいことが多いです。 話してくれた人には圧倒的感謝を。謙虚・尊敬・信頼(HRT) の精神で傾聴をぜひお願いします。

f:id:cybozuinsideout:20170310120444p:plain:w300

手前味噌になりますが、この移行失敗の顛末はブログに公開していますので、興味があればぜひ読んでみてください。 参考: 我々はいかにして技術選択を間違えたのか 2016

転んでもただでは起き上がらない

f:id:cybozuinsideout:20170310120635p:plain:w300

失敗を受け入れる話をしてきましたが、失敗は成功の道半ばでしかないという開き直りも大事です。

f:id:cybozuinsideout:20170310120815p:plain:w300

失敗したときの悔しいエネルギーがないと改善できないことってあると思うんです。 弊社も今回の失敗から立ち直るべく JdbcTemplate を使ってS2DAOに近いORMapperを再設計しました。 近いうちにOSSとして公開したいと思っているので、お楽しみに

f:id:cybozuinsideout:20170310121326p:plain:w300

失敗の共有は恥だが役に立つという話でした

よこしまな生き方について

4つめ。エモい話ですけど、よこしまな生き方についてです。

f:id:cybozuinsideout:20170310122807p:plain:w300

Javaの謎のパフォーマンス現象との戦い

f:id:cybozuinsideout:20170310122916p:plain:w300

Javaの謎のパフォーマンス劣化現象に苦しめられていた時期がありました。

f:id:cybozuinsideout:20170310122919p:plain:w300

無事解決しまして、原因はJIT Compilerでした。 JIT Compilerが停止したままになるのと、最適化されたコードを捨てる機能があり、これが悪さをしていました。

解決の糸口

f:id:cybozuinsideout:20170310122922p:plain:w300 f:id:cybozuinsideout:20170310123231p:plain:w300

どうやって解決したのか?という話なんですが、JVMはGCに使われるスレッドはCPUのコア数から決まります。 そして、GCスレッドは、CPUを100%専有する仕様になっています。このあたりの話はJavaパフォーマンスにあります。

これを前提にすると、GCが常に発生していたとしても、運用環境のCPUはまだ余裕がありました。そこで初めて、GCを原因から排除しました。 あとは、CPUを消費するケースをMLで読み漁りまして、発見したのが今回の現象でした。

ブログに公開

f:id:cybozuinsideout:20170310123244p:plain:w300

調査に苦労したので、少しでも元を取ろうということでブログ記事に公開しました。

f:id:cybozuinsideout:20170310123246p:plain:w300 f:id:cybozuinsideout:20170310123249p:plain:w300

公開時に読んでいただいた方もいるかもしれません。ご愛読ありがとうございます。 記事は大好評でした。OSSにお世話になっているので、情報公開で貢献したい気持ちもありました。

結果的には、3日間ぐらいドヤ顔してましたが。

参考: Javaの謎のパフォーマンス劣化との戦い

ずぶとく生きるように

f:id:cybozuinsideout:20170310123253p:plain:w300

このときの経験から、調査のモチベーションがガラリとかわりました。 現金なもので、面白いことがあるかもしれないと調査していると不思議と楽しいです。疲れますけど。

JIT Compilerの問題が長期間、原因不明だったので開き直れるようになりました。 いざとなったら逃げてもいいと実感できたことはとても大きな学びでした。

ずぶとくネタを使いまわして、今日も喋りに来ているわけです。

f:id:cybozuinsideout:20170310123256p:plain:w300

常にネタを探しているお笑い芸人みたいですけど、ちょっとよこしまな気持ちを持っていたほうが人は楽しく生きられるのかもしれません。

おわりに

最後になりますが、今日の話を聞いて障害調査に興味を持っていただける人が増えたらうれしいです。

f:id:cybozuinsideout:20170310123300p:plain:w300

障害学習、はかどりまっか?

f:id:cybozuinsideout:20170310123303p:plain:w300

障害にすてるところなしという話でした。ありがとうございました

引用

プレゼンテーションで引用させていただきました。日々、業務でお世話になっております

 

Cybozu Meetup #1 フロントエンド を開催しました!

こんにちは。Garoonのプログラマーをしている杉山です。2月27日にサイボウズで初めてとなるCybozu Meetupを東京・大阪の2会場で同時開催しました。今回はこの会の様子を紹介したいと思います。

Cybozu Meetup って?

Cybozu Meetup Logo サイボウズの技術・製品・文化など毎回異なるテーマをネタにお寿司とドリンクを楽しむイベントです。エンジニアのみなさんとサイボウズの社員がカジュアルに交流・情報交換できることを目的にしています。

初めての開催となった今回はフロントエンドをネタに、東京オフィス・大阪オフィスの2会場で同時開催しました。

2会場合わせて150名近くの応募があった中、最終的に約40名の方に参加いただきました。参加いただいた皆様、改めてありがとうございました!

トークセッション

交流会前のトークッセッションは開発本部長の佐藤鉄平(@teppeis)の『サイボウズのフロントエンド開発の現在とこれからの挑戦』でした。

Meetup の様子

当日の様子をトゥギャりました
交流会もフロントエンドの話題はもちろん、開発環境についての意見交換が行われたり、Golangを勧められるサイボウズ社員がいたりとたいへんに盛り上がりました。

お寿司。 お寿司の写真

トーク中の様子。 トーク中の写真

交流会後の集合写真。モニター越しに写っているのは大阪会場の参加者のみなさんです。 集合写真

次のスシネタは?

次回のCybozu MeetupはSRE (Site Reliability Engineering)をネタとして4月3日に開催予定です。@ymmt2005 より、『SRE なにしてますか? 忙しいですか? 救ってもらっていいですか?』と題してサイボウズのクラウドサービスcybozu.comの運用話を余すところなくお伝えしたいと思います。

  • Cybozu Meetup #2 SRE
  • 日時:4月3日(月) 18:30 会場 19:00 開始
  • 場所:サイボウズ東京オフィス (東京日本橋タワー 27階)
  • イベント詳細:https://cybozu.connpass.com/event/52668/

おかげさまですでに 約100名 以上の参加申し込みをいただいておりますが、抽選制となっておりますので皆様のお申し込みを心待ちにしております。

また、次回からは東京のみでの開催となります。大阪オフィスでは、後日形を変えて開催を予定しております。関西にお住いの方には申し訳ありませんが、しばらくお待ちください。 東京オフィスでは今後も月に1度のペースで開催を予定しています。

東京・大阪とも今後のイベント情報はサイボウズのconnpassグループにて告知していくので、よろしければフォローお願いいたします。今後ともCybozu Meetupをよろしくお願いします!

 

テストエンジニアリングチームができて一年が経った話

こんにちは、東京品質保証部の新関です。

2017年に入り、ちょうどテストエンジニアリングチームを設立して一年が経ちました。設立からのテストエンジニアリングチームの活動が、開発組織へどのような影響をもたらしたのか、紹介したいと思います。

テストエンジニアリングチームとは

まず、テストエンジニアリングチーム(以下TE)の説明から簡単にさせてください。サイボウズのTEは『枠組みを超えて品質/生産性の向上に貢献する』をミッションに設立した、プログラマーとQAのジョイントチームになります。

www.slideshare.net

@miyajanの紹介資料にもありますが、2016年1月に3名でキックオフし、テスト自動化の推進を主に行っています。

TE設立背景は紹介資料にある通り、内部環境の変化により、品質保証への要求も変化し組織自体も最適化していく必要があったというのは勿論なのですが、これまでの自動化アプローチで困っていた諸問題(コスト、自動化が定着しないなど)についても専門でなんとかしていきたい!というメンバーの強い思いも設立要因になっています。

2017年現在、TEのメンバー数は東京6名、ベトナム3名、上海2名の計11名で活動をしています。

以下、時系列順に昨年の活動を振り返っていきます。

1年を通しての活動

2016年 前半

@miyajan含め、3名でキックオフしました。いきなり自動化を進めました、というわけではなく、活動の指針を定めるため、これまでの自動化の整理、共通認識、理想のすり合わせについての議論をひたすら重ねました。

f:id:cybozuinsideout:20170307103646p:plain

チーム方針に対する議論が中心であったため、他部署に対して役立つようなアウトプットを出すことができず、もやもやする気持ちがありましたが、この時期に共通の理想/方針が定めることができたおかげで、

  • 徹底的に議論する文化の醸成ができた
  • 理想が共有できているため、事をスムーズに運ぶことができるようになった

と思っています。併せて、TEの活動プロセスを初期段階で決め、その内容に沿った形で活動を開始しました。

f:id:cybozuinsideout:20170307103813p:plain

2016年 中盤

上海、ベトナムと各拠点において立て続けにテストエンジニアチームを設立し、キックオフしました。日本ではプロダクトチームへ自動化に関するヒアリングを実施し、その中で依頼のあった自動化、CI改善などに取り組みました。ヒアリングをする傍ら、海外拠点で実施する自動化を選別して実施依頼するなど、かなりドタバタした時期でした。
このヒアリング活動や依頼への対応を進めると、各プロダクトで実施されている自動化は独自色が強く、知識も技術スタックもバラバラであることがわかってきました。少ないTEメンバーで、複数のプロダクトの独自システムをサポートをしていくことはなかなか難しく、効率もよくありません。これを統一していくことは多くの時間とコストを必要とすると思われますが、共通化することによるメリットも大きいのではないか、という意見が出てきたのがこの時期でした。
一方で社内イベントでTEの取組みを紹介するTE Cafeを開催するなど、社内に対して新設されたTEを認知していただく活動も開始しました。

2016年 後半

引き続き共通基盤についての議論。海外TEメンバーが来日し技術交流会を開催、STFやモバイルテスト自動化についての調査発表などがありました。

f:id:cybozuinsideout:20170307104500p:plain

技術交流会の後は、あれよあれよという間に一年が。。。\(^o^)/

開発組織にどんな影響があったか

1年の活動を通して下記の影響が出てきました。

プロダクトチームへのヒアリングによる効果

カジュアルなヒアリングを定期的に実施することで、プロダクトが抱えている問題を把握し、自動化に関する相談や依頼を掘り起こすことができました。その結果、以下のような効果がありました。

  • プロダクト独自の自動化の問題点の発見と改善
  • テスト自動化がうまく運用されているチームの手法の横展開
  • 自動化されていない、自動化が廃れてしまっていたチームへの自動化再導入
  • 環境を整えることによる自動テスト工数の削減

自動化を意識した開発計画

開発計画立案時点で、開発チームとTEの間で自動化の推進について議論が交わされるケースが増えていきました。

メンバーの増員

もともと自動化に興味を持っていた開発メンバーにjoinしてもらうことができました。

キャリアパスの一つとしての認識

QA内でキャリアパスの一つとして認識されてきました。

今後に向けて

よりアウトプットを増やしていく

この1年は、方針の策定やヒアリング、人員の増強といったいわば「準備の期間」でした。
今年は、前年よりもより多くの改善活動を、開発者やQAにわかる形で提供できればと思っています。

自動化は勿論、より品質/生産性を高めるためのアプローチの検討

テストエンジニアリングチームは、テスト自動化を推進して円滑にテストが完了することが使命です。
が、それだけにこだわらず、自動化以外にもより品質/生産性を高めるアプローチがないか検討していきます。

We are hiring!

一緒に働いてくれる仲間を募集しています!