こんにちは。Garoon 開発チームの杉山です。

皆さんはスクリーンリーダー（画面読み上げソフト）を使われたことがありますでしょうか。主に視覚障がい者向けのツールだと思われるかもしれませんが、実はアクセシビリティのチェックツールとしても、とても有効に使うことができます。一方で独特の操作が多いため、慣れていないと操作が難しい一面もあります。 本エントリでは、開発者やデザイン担当者がアクセシビリティチェックツールとしてスクリーンリーダーを使う際の注意点をまとめてみました。

サイボウズのアクセシビリティ対応

サイボウズではアクセシビリティを「チームにアクセスできる能力」と定義し、取り組みを進めています。*1

しかし、

• アクセシビリティ基準*2を満たしていない箇所が多い
• アクセシビリティ対応に使える時間が少ない

といった理由から全サイボウズ製品ですぐにアクセシビリティ対応を完遂するのは非常に困難です。そのため、一部のユーザーにとってまったくアクセスできない(使うことができない）もしくは非常に使いにくい箇所を特定し、そこから優先的に対応していきたいと考えました。

アクセシビリティ対応の優先順位付けの方法はいろいろあるとおもうのですが、今回はスクリーンリーダーを用いた優先順位付けを行いました。この方法ではどこがアクセスできないのか、どこが使いにくいのかを開発者やデザイン担当者でも把握することができ、実感を持って優先順位を付けられます。実際の検証では NVDA と呼ばれる無料のスクリーンリーダーを利用しました。

NVDA とは

NonVisual Desktop Access (NVDA)は無料で使える Windows 用のスクリーンリーダーです。日本語対応が行われているため、インストールするだけで使い始めることができます。

はじめて NVDA を使う上で注意すべき点をまとめてみました。

読み上げの止めかた

インストールして起動すると、即座に読み上げが始まります。読み上げはいつでも [Ctrl] キーで止めることができます。

Firefox を使う

NVDA は Mozilla Firefox との併用を推奨しています。IE や Chrome も読み上げることができるのですが、WAI-ARIA *3の対応は Firefox と NVDA の組み合わせが最も進んでいるそうです。また、後述する NVDA のアドオンも Firefox での動作が安定しているようです。

NVDA キー

NVDA を起動すると、初めに NVDA キーの設定を求められます。

NVDA は 基本的に NVDA キーという制御キーと他のキーを組み合わせて操作します。NVDA キーにはキーボード上の任意のキーに割り当てることになります。NVDA キーはデフォルトで [無変換] と [Insert] に割り当てられています。この後の説明でも [NVDA] と書かれている箇所は [無変換] か [Insert] に読み替えてください。

キー操作が奪われる

NVDA には ブラウザモードと フォーカスモードと呼ばれる二つのモードが存在します。ブラウズモードでは通常のキー操作が NVDA に送られるため、通常の文字入力や、文字のコピーショートカットである [Ctrl] + [C] などが利用できません。また JavaScript のキー入力イベントも基本的に発火しなくなります。一方で、フォーカスモードではキーボードの入力がブラウザに直接わたるようになります。そのため文字入力やキーボードショートカットを使いたい場合は、[NVDA] + [スペース] を入力してフォーカスモードに切り替える必要があります。

NVDA コマンド

Web 閲覧時の NVDA 操作方法については、NVDA日本語版　操作ガイドがわかりやすいのでこちらを見ていただくのが良いかと思います。

重要な点は

• [H] で見出しが、[F] でフォームが、[K] でリンクが、といったように主要な項目はキーボードひとつで順々に読み上げられる
• [Shift] を同時に使うと逆方向の項目を探す

の2点です。

またこの操作ガイドにはないのですが、[NVDA] + [Tab] で現在のフォーカスの報告ができることも覚えておくと、より使いやすくなるかと思います。

開発者のための NVDA 設定

NVDA は上記の操作ガイドを覚るだけでも十分にアクセシビリティチェックツールとして使うことができます。しかしデフォルトの設定は視覚障がい者向けの設定になっているため、一部の設定を変更することでさらに便利に使うことができます。

スピーチビューアー

普段スクリーンリーダーを使わないユーザーにとっては、スクリーンリーダーの読み上げだけでどのように読み上げられたかを判断するのは容易ではありません。NVDA には開発者向けに読み上げられた音声を文字に出力する機能が標準で備わっています。

[NVDA] + [N] を入力すると、NVDA のメニューが立ち上がるので、そこから「ツール(T)」→「スピーチビューアー(S)」と選択することで起動できます。[NVDA] + [N], [T], [S] と順に押すことで、即座に起動させることができます。

マウス追従機能をオフに

NVDA のデフォルト設定では、マウスカーソルが移動すると移動先の内容を自動で読み上げてくれます。しかし、スクリーンリーダーになれるまではマウスカーソルによって意図しない箇所が読み上げられることが多く、アクセシビリティチェックツールとして使いにくい原因になります。[NVDA] + [M] と入力して、マウスカーソル移動を報告しないようにすることをお勧めします。

FocusHighlight アドオン

FocusHighlightは NVDA が読み上げている箇所（ナビゲーターオブジェクト）やフォーカスのあるオブジェクトを、色付き長方形で表示する NVDA のアドオンです。
上の画像では、緑色のギザギザ線で囲まれている部分がいま NVDA が読み上げているところを示しています。一方で赤い四角で囲まれた箇所はフォーカスが当たっていることを表しています。これにより、スクリーンリーダーに慣れていない開発者でもスクリーンリーダーの挙動を把握しやすくなります。

音声を切る

スクリーンリーダーを長時間利用していると、休みなく情報が耳に流れてくるためとても疲れます。長時間の検証を行う場合は、音声を切りスピーチビューアーを利用することをお勧めします。

[NVDA] + [S] で 「声で読み上げ」「読み上げなし」「ビープ」の3種類を切り替えることができます。音声を止めていても、スピーチビューアーは引き続き利用することができます。

ページ読み込み時に読み始めないように

音声を止めている場合、新しくWebページを開くとページ内の情報が一度にすべてスピーチビューアー上に表示されてしまいます。さらにナビゲーターオブジェクトもページの下のほうに移動してしまいます。

[NVDA] + [N] で NVDA メニューを起動し、「設定(P)」→「ブラウズモード(B)」から「ページ読み込み時に自動的に読み上げる」のチェックを外すと、ページ遷移だけでは読み上げが行われないようになります。

ブラウズモードとフォーカスモードの切り替えを文字で知らせる

[NVDA] + [スペース] でブラウズモードとフォーカスモードの切り替えを行うと、ビープ音によりブラウズモードかフォーカスモードかを教えてくれます。この音はデフォルト設定ではスピーチビューアーに表示されません。

[NVDA] + [N] で NVDA メニューを起動し、「設定(P)」→「ブラウズモード(B)」から「フォーカスモードとブラウズモードの切り替えを音で報告」のチェックを外すと、スピーチビューアーにもラウズモードとフォーカスモードの切り替えが表示されるようになります。

アクセシビリティを調べるときは

実際にスクリーンリーダーでアクセシビリティチェックを行うときにいくつか注意したほうがよいと感じたポイントがあります。

FocusHighlight アドオンに頼りすぎない

FocusHighlight アドオンは開発者にはとても便利なのですが、その分スクリーンリーダーユーザーの不便を感じにくくなる恐れがあります。フォーカスが見えてしまうと、どうしても視覚的に Web ページをとらえてしまいます。しかし、スクリーンリーダーは Web ページの HTML を順番に読み上げる性質であるため、実際には各パーツの位置関係やスペースの空き具合といった視覚的情報を把握することは困難であると考えられます。そのためブラウザを小さくしたり実際に目を閉じたりして、スクリーンリーダーユーザーに近い操作条件を課すと良いと思います。

スクリーンリーダーだけに対応しようとしない

アクセシビリティ対応はスクリーンリーダ―ユーザーのためだけのものではありません。多様なユーザー・多様なデバイス・多様な状況下で使いやすくする必要があります。

スクリーンリーダーを使ってアクセシビリティチェックを行う場合でも、スクリーンリーダーで操作できないデザインを探すのではなく、高齢者や弱視の方・健常者にも操作しにくくないかを意識したほうがより効果的になります。

おわりに

アクセシビリティ基準だけを見ていると、この画像に alt がない！とかここのマークアップがおかしい！ということはわかっても、それがどれくらいクリティカルな問題なのかはわかりません。もちろんすべての問題に対処していきたいところですが、限られた時間の中で対応をすすめなければいけない場合、やはり利用するユーザーが困る場所から優先的に改善をしていきたくなります。

スクリーンリーダーを使うと全盲の方が困るであろう UI のピックアップが簡単に行うことができます。しかし実際に抽出された UI を分析してみると、高齢者や弱視の方・健常者にとっても使いにくい UI であることが多いこともわかってきました。アクセシビリティ対応でどこから手を付けたらいいかわからない場合には、こういった手法がとても有効に使えると思います。

また、キーボードのみで操作する、拡大鏡の画面から操作する、カラーフィルタを利用するといった方法でも同様にアクセスできないもしくは非常に使いにくい UI を探すことができます。

ぜひ皆さんもアクセシビリティの改善にこうした方法を使ってみてください。

こんにちは、アプリケーション基盤チームの池添（@zoetro）です。 2016年9月に中途入社し、Necoプロジェクト（アーキテクチャ刷新プロジェクト）において新しいログ基盤の構築を進めています。 その一環でRedashの導入もおこなっています。

新しいツールやサービスを導入するときに気になるのが認証の仕組みです。 社内ではいろいろなツールやサービスを活用していますが、それぞれにアカウントをつくるのは大変なので、やはりシングルサインオン(SSO)したいですよね。

Redash v0.11のドキュメントを見るとSAML認証について記載されていました。 さっそくSAML認証の設定をし始めたわけですが、どうにもうまくいきません。

そこで、SAML認証ができるまで - Cybozu Inside Out | サイボウズエンジニアのブログを読み、RedashやOpenAMのソースを調査し、SAMLの仕様書とにらめっこしながら、なんとか認証できるようになったので、その過程を紹介したいと思います。

なお、IdP(Identity Provider)としてはOpenAMとAD FSで動作確認しています。

ちなみにRe:dashはv1.0からRedashという名前に変わるみたいですね。

TL;DR

• RedashでSAML認証をやってみた
• v0.11では問題があってうまく認証できなかった
• 問題を修正してPRを投げたらv0.12で取り込まれた

Redash v0.11でSAML認証が使えるようになるまで

SAML認証の有効化

まず、Redash v0.11においてSAML認証を有効にするためには.envファイル(Redashの設定ファイル)にREDASH_SAML_METADATA_URLの設定を追加します。

REDASH_SAML_METADATA_URLにはIdPのメタデータを返すURLを指定します。 たとえば、OpenAMならhttp://Your_Domain_Name/openam/saml2/jsp/exportmetadata.jsp、AD FSならhttps://Your_Domain_Name/FederationMetadata/2007-06/FederationMetadata.xmlのようになります。

この設定をしてRedashを起動すると、下図のように通常のログインフォームの上に SAML Loginというリンクが表示されるようになります。

認証要求が通らない

さっそくSAML Loginのリンクをクリックしてみましょう。 しかし、認証に失敗します。

OpenAMのログを確認してみると"The name identifier is missing or an empty string"というエラーメッセージが出力されていました。

OpenAMでは、認証要求メッセージ(AuthnRequest)のIssuerが空になっていてはいけないのですが、Redashではここに何も指定していませんでした。

この件に関してはPRを投げて、Redash v0.12で取り込まれました。 .envファイルにREDASH_SAML_ENTITY_IDという項目を追加し、SP(Service Provider: ここではRedashのこと)を一意に表す文字列を指定すればOKです。一般的にはSPの実際のURLを指定することが推奨されているようです。

アカウントの表示名がつくれない

再度SAML Loginのリンクをクリックしてみますが、今度はRedash内でエラーが発生しました。

Redashでは、認証応答メッセージ(Response)のSAMLアサーションの属性ステートメント(AttributeStatement)に、"FirstName"と"LastName"が含まれていることを期待しているようです。 Redashのドキュメントにも書いてありますね。

RedashのアカウントにはNameとEmailという項目がありますが、"FirstName"と"LastName"を結合した名前がNameとして使われます。 また、認証応答メッセージのNameIdがEmailとして使われます。

この属性ステートメントはIdPで設定することができるので追加してあげましょう。設定方法はそれぞれのIdPのドキュメントなどを確認してください。

なおこの件に関して、属性ステートメントに"FirstName"と"LastName"が含まれなかった場合は、認証応答メッセージのNameIdを使うというPRを投げてみたのですが、残念ながら採用されませんでした。 おとなしくIdPでの設定をおこなうこととしましょう。

アカウント無限増殖

さて、ここまでの設定でめでたく認証は通るようになりましたが、認証が成功するたびにRedash上のアカウントが増えるという問題が発生していました。

Redashではpysaml2というライブラリを使っているのですが、このライブラリはデフォルトのNameIDFormatとしてurn:oasis:names:tc:SAML:2.0:nameid-format:transientを使うようになっています。 このフォーマットを指定した場合、認証応答メッセージのNameIdとして毎回異なるIDが発行されます。 Redashではこの発行されたIDをアカウントを一意に識別するために使っており、アカウントが存在しなければ新規にアカウントを作成するという動きになっています。

この状態は困るので、PRを投げてNameIDFormatに任意の値を指定できるようにしました。これもv0.12で取り込まれています。

.envファイルのREDASH_SAML_NAMEID_FORMATにurn:oasis:names:tc:SAML:1.1:nameid-format:unspecifiedなどを指定しておきましょう。

イントラ内のIdPが使えない

最初にSAML認証を有効にするためにREDASH_SAML_METADATA_URLを設定するという説明をしました。 RedashはこのREDASH_SAML_METADATA_URLにHTTPリクエストを投げてIdPメタデータを取得するようになっています。

つまりRedash(SP)からIdPに直接アクセスできなければならないということになります。 しかし、IdPがイントラ内に設置されているためSPから直接アクセスできないというケースもよくあるのではないでしょうか。

そこで、メタデータをIdPから直接取得するのではなく、ファイルから読み込む機能を実装しPRを投げました。これもv0.12から使えるようになっています。

IdPからメタデータファイルをエクスポートしてRedashをデプロイしているホストに配置し、そのファイルのパスを.envファイルのREDASH_SAML_LOCAL_METADATA_PATHで指定します。 なお、この項目はREDASH_SAML_METADATA_URLと併用することはできないので、どちらか一方だけを設定するようにしてください。

Redash v0.12のSAML関連設定まとめ

Redash v0.12におけるSAML関連の設定項目を以下の表にまとめました。 REDASH_SAML_METADATA_URLまたはREDASH_SAML_LOCAL_METADATA_PATHのどちらかを設定することでSAML認証が有効になります。それ以外の項目はオプショナルになっています。

また、認証応答メッセージのSAMLアサーションの属性ステートメントに設定する項目を以下の表にまとめました。

まとめ

RedashでSAML認証を使えるようになるまでの顛末を紹介しました。

Redash v0.12ではOpenAMやAD FSでSAML認証ができるようになっているかと思います。 しかし、限定的な条件でしか動作確認していないので、もし問題などが見つかったらご指摘いただけるとうれしいです。

サイボウズではログ基盤構築に興味のあるエンジニアを募集しています！

キャリア採用 募集要項/イベント | サイボウズ株式会社

こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。

先日、エンタープライズジン様の記事で、弊社の名前が挙がっていました。

井上　まあ、ミドルウェアに詳しい人間もいないと。ミドルウェアだけじゃないですけど、やっぱりアプリケーションベンダーも、我々もそうですし、サイボウズさんとかだって、ある程度ミドルウェアに詳しい人は一定数必要じゃないですか。そういう意味でいうとポジションはあるかなって。

神林　それはあるかなあ。研究所ですよね。サイボウズだったらサイボウズラボですよね、結局。

http://enterprisezine.jp/dbonline/detail/8770?p=6

この意見について、サイボウズではミドルウェアエンジニアも活躍しているという紹介をさせていただきます！

まず初めに、サイボウズとサイボウズ・ラボの関係について紹介します。サイボウズは cybozu.comを始めとするグループウェアを開発している会社です。サイボウズ・ラボはサイボウズ内のひとつの部門であり、中長期視点で次世代のグループウェアやそれらの基盤となる技術の研究開発を行っています。サイボウズ・ラボからも目覚ましい成果はあるのですが、今回はラボではなくサイボウズからのミドルウェア事情について記したいと思います。

サイボウズの提供するクラウドで使えるグループウェア、cybozu.com は AWS や Google Cloud Platform を用いず、自前でデータセンターからアプリケーションまで構築・実装・運用しています。cybozu.com はもうすぐ 6 年目に突入しようとしており、内部では数えきれないほどの自作ミドルウェアが動いています。

まず、ミドルウェアの定義について。何をもってミドルウェアとして扱うのか、その定義は難しいところがありますが、Wikipedia の Middleware の項目を引用します。

Middleware is computer software that provides services to software applications beyond those available from the operating system. https://en.wikipedia.org/wiki/Middleware

意訳すると「ミドルウェアは、OS が提供する機能を超える機能をアプリケーションに提供するソフトウェアのことである」といったところでしょうか。サイボウズでも、直接ユーザーのリクエストを受け付けるアプリケーションではなく、そのアプリケーションを支えるソフトウェア、というイメージでミドルウェアを扱っています。

サイボウズには、アプリケーション基盤チームというチームがあります。僕も所属しているチームなのですが、ここは主に各製品の共通部分の実装を担当しており、その中でミドルウェアの開発も行っています。

我々のチームが提供するプロダクトのひとつに、ワーカーと呼ばれる非同期処理専用のプログラムがあります。ユーザーのリクエスト内ではなくバックグラウンドで非同期に処理を行うことで、ユーザーへのレスポンスを高速に返す、ということを目的として開発されたものです。このワーカーは日々数千万ジョブを捌いており、ユーザーからは見えませんが、cybozu.com を支えるひとつの柱となっています。また、ファイル管理も自作のファイルサーバーで行っており、今では億を超える膨大な数(そして膨大な容量)のファイルを自作ミドルウェアで管理しています。

僕のチーム以外からもミドルウェアはいくつも開発されています。例えば yrmcds という OSS で公開しているプロダクトがあります。yrmcds については下記記事で解説されていますが、簡単に言うと、memcached プロトコル互換, memcached よりも高速, レプリケーション等の機能も備えている KVS です。cybozu.com では主にセッション回りのデータストアとして利用しており、極めて安定して稼働しています。単一のマシンで 1 千万を超えるオブジェクトを管理し、毎日 1 億アクセスをゆうに超える cybozu.com を支えています。 blog.cybozu.io

月読という名の自動障害回復システムも自作しています。これはピア同士が死活監視しあう自立分散システムです。最近では Go 言語に力を入れており、GitHub の cybozu-go のページでは、Go 言語ライフを快適にするためのツールが複数公開されています。Square という冗長化ネットワークストレージの統合管理システムも自作しました。現在開発中ですが、Fluentd ライクでより我々のニーズに合致したプロダクトの開発も目論んでいます。

blog.cybozu.iogithub.com

紹介しているとキリが無いのでこの辺で抑えておきますが、サイボウズではミドルウェアを多数開発しており、運用しています。ミドルウェアエンジニアのポジションももちろんあります！

OSS ももちろん多数活用しています。特に MySQL は 10 年以上前からヘビーに使用しています。MySQL 以外にも、 Apache, nginx, Elasticsearch, Hadoop, etc, こちらも挙げたらキリがありません。OSS 無しには cybozu.com は成り立ちませんし、OSS にコントリビュートすることもしばしばあります。一方で何故ミドルウェアを自作するのかというと、その方がコスト安であったり、ユーザーのニーズにあった価値を提供できたりするからです。必要なものが無ければ自作する精神がサイボウズにはあります。機能面ももちろんそうですし、より安全であったりより高速であることを自分たちの手で叶えられるのなら、我々はそれを実現します。

こちらの記事でも紹介している通り、今のサイボウズは新アーキテクチャに向かって様々な箇所を刷新しようとしている最中です。今後はさらにミドルウェアに注力していくことになるでしょう。

サイボウズはミドルウェアエンジニアも随時募集しています。「我こそは！」という方は是非サイボウズで腕を振るってください！

We Are Hiring!

こんにちは。生産性向上チームの宮田(@miyajan)です。

12/13(火)に、サイボウズの技術発表イベント「Cybozu Tech Conference 2016」を開催いたしました。

東京・大阪・松山の3拠点をテレビ会議で同時開催したところ、社外から多くの参加者にご来場いただきました。ありがとうございました！

東京

大阪

松山

内容

「Cybozu Tech Conference 2016」は、サイボウズの開発のこれまでと未来の話、開発プロセスやプロジェクト管理の話、認証やセキュリティ、バグの調べ方といった技術寄りの話、SREチームや生産性向上チームといった特色あるチームの話、そしてリモートでチーム開発を行う文化の話と、サイボウズらしい多様性のあるテーマで8セッションの発表が行われました。

発表資料のスライドはすべて公開しておりますので、ぜひご覧ください。

• サイボウズの現在と未来
• kintoneの開発プロセスとプロジェクト管理ツール
• cybozu.comの認証
• バグの調べ方
• とある脆弱性の永い議論
• SREチーム発足！
• 開発者を支える生産性向上チームの取り組み - CI, Browser Test, Tools and Infrastructure
• サイボウズのリモートワーク・リモートチーム

「とある脆弱性の永い議論」と「SREチーム発足！」を除いた6つのセッションにつきましては、発表動画をYouTube上のCybozu Inside Outチャンネルで公開しております。こちらも合わせてご覧ください。

• https://www.youtube.com/channel/UCNtfeunXH-ZuYefyTh9jPsQ

また、当日のtwitter上でのつぶやきを、参加者の@PET_HALさんが詳細にtogetterでまとめてくださいました。ありがとうございます！

• 【自分用まとめ】Cybozu Tech Conference 2016

懇親会

懇親会も、3拠点をテレビ会議でつないだ状態で開催されました。お寿司やケータリング、ピザなどをいただきつつ、サイボウズ社員と参加者で親睦を深めました。

寿司！

乾杯！

懇親会はサイボウズ名物『リモート飲み会』です。

おわりに

「Cybozu Tech Conference」は、今年が初の試みでした。参加者にどれだけサイボウズの技術に興味を持ってもらえるか不安もありましたが、多数の方に来場いただき、懇親会でもさまざまな議論が盛り上がっていたのでよかったです。

リモート接続で3拠点同時開催というチャレンジングな取り組みでしたが、特に大きなトラブルもなくスムーズに進行することができました。

来年以降も続けていく予定ですので、より多くの人にサイボウズの技術情報を発信していきたいと思います。また、来年は「Cybozu Tech Conference」以外にも、よりテーマを絞った勉強会を開催する予定ですので、ぜひそちらにも参加していただければ嬉しいです。

最後になりますが、ご来場いただいた皆さま、本当にありがとうございました！来年もよろしくお願いします！

どうも！アプリケーション基盤チームの横田(@yokotaso)です！

kintoneなどで利用していたJavaフレームワークのSeasarのEOLに伴い、S2Daoからの脱却を試みたのですが、パフォーマンス問題や障害を発生させてしまうなど問題を多々発生させてしまいました。

同じ過ちを繰り返さないという強い決意のもと、今回の失敗をブログで公開いたします。 失敗をあえて公開する点で斬新かつ濃いブログ記事となっております！

失敗体験の公開は恥だが役に立つ！

移行先の選定の失敗

移行先として選定したプロダクトは Hibernate*1です。

Hibernateを選んだ理由としては

1. Spring Frameworkを選定した

2. Spring Frameworkで Interface + アノテーションでプログラミングするならSpring Data JPAが有力

3. JPAに準拠したのORMの中でも、Hibernateがメジャーである。

この3つを主な理由として、S2Daoから、Spring Data JPAへ移行を試みました。

どう失敗だったのか？

以下の3つの点で失敗だったと考えています。

• JPAに準拠することを目指しながらもEntityのプロパティ変更を自動的にDatabaseに反映する機能は我々は必要としていなかった

• パフォーマンスの劣化、運用障害の原因になってしまった

• Hibernateに問題があるケースの調査が難しく、コストが辛い

技術選定になぜ失敗したのか

設計思想の違いを意識できていなかった

失敗の原因の一つ目はS2DaoとHibernateの設計思想の違いです。

Hibernateはキャッシュ機構が充実したORMです。一方S2Daoはキャッシュ機能はあまり持たない、軽量なORMになります。

S2DaoとHibernateで同じように動作することに注力したため、S2Daoと比較した時に Hibernateが「できてしまう」ことの調査に注力ができませんでした。

結果的にこのキャッシュ機構に苦しめられることになります。

HibernateとS2Daoのキャッシュの仕組みの比較

単純な比較表ですが、キャッシュの機構としてはHibernateのほうが充実しています。

クエリ キャッシュ

• Hibernate
  アノテーションで宣言されたクエリをキャッシュする仕組み。それとは別にQueryPlanCacheオブジェクトでキャッシュする

• S2Dao
  SQLコメント機能を利用するためにパースしたクエリをキャッシュする仕組みを持つ

エンティティ キャッシュ

• Hibernate
  SELECTなどで生成したEntityは、EntityManagerにキャッシュされる。EntityManagerはEntityの変更を検知する。Databaseと自動的にシンクされる。

• S2Dao
  エンティティ キャッシュの仕組みはない

メタデータ キャッシュ

• Hibernate,S2Daoの両方でクラスのメタデータをキャッシュする仕組みがある

• Hibernateのほうがメタデータに関しても多機能である

得られた教訓

フレームワーク移行は、互換性を確保すると同時に、新しく「できるようになること」の影響も調べよう。 できるようになることも、できなくなることも、移行元のフレームワークから差が大きくないのが望ましい。

長いものに巻かれることにこだわりすぎた

もうひとつの失敗の原因がズバリ長いものに巻かれることにこだわりすぎたことです。

SeasarがEOLになったこともあり、EOLに対する恐怖心がありました。

そのため、移行先のプロダクトは「コミュニティが活発である」、「JPAに準拠している」ことを重視しました。上のような理由のため他ORMの選択肢が少なくなりました。

途中からHibernate一択という状態になってしまい、他のORMとの比較もおろそかになってしまった点も反省しています。JPAに準拠することも諦めるべきでした。JPAにできるだけ準拠することも他のプロダクトの選択肢を減らす原因にもつながりました。

JPAを諦めていればspring-jdbcの中に入っているJdbcTemplateを利用することも検討できました。S2Daoに比べると機能落ちになる面もあるのですが、キャッシュ機構がないので、提供される機能はS2Dao時代と近いです。

後で障害の例を紹介しますが、JdbcTemplateを利用すれば運用障害になるケースは避けられた可能性があります。

得られた教訓

長いものに巻かれるのは大事だが、選択を誤る(謝る)バイアスになる可能性があることに注意すべきである。

移行後に発生してしまった障害

Hibernateがらみの移行で、パフォーマンス問題や障害につながってしまうケースが発生してしまったのですが、味わい深い2つの障害を紹介します。

バッチ処理でOutOfMemoryError

Hibernateはトランザクションの内部で実行されたDELETE/UPDATE文はすべて保持するようになっています。

これはHibernateがSQLとは別にEntityをキャッシュする仕組みを持っているためです。トランザクションの最後にDELETE/UPDATEをSQLとして実行します。

100回程度のDELETE/UPDATEを実行する分には問題になりませんが、10万回レベルのDELETE/UPDATEを実行するようなケースは、OutOfMemoryErrorを発生させる原因になります。

移行後、長時間にわたるバッチ処理が、処理途中からFullGCが大量発生し、OutOfMemoryErrorに至る現象が発生するようになり、原因調査とHibernate内部の調査に大きな時間を割くことになりました。

参考: DELETE/UPDATEでOutOfMemoryError

クエリ・キャッシュが原因でOutOfMemoryError

Hibernateはクエリを内部にキャッシュする仕組みがあります。

Hibernateは次のようなクエリは、すべて別のクエリとしてキャッシュされてしまいます。IN句の数が違うだけです。S2Daoではこの機能はありませんでした。

SELECT * FROM book WHERE id IN (p1, p2, p3);
SELECT * FROM book WHERE id IN (p1, p2, p3, p4);
SELECT * FROM book WHERE id IN (p1, p2, p3, p4, p5);

Hibernateのクエリキャッシュは、LIRSキャッシュアルゴリズムが利用されており、キャッシュが増殖しつづけるのを抑制する仕組みは存在しています。しかし、次の2つの現象が同時に発生したときに障害になる可能性があります。

• IN句の中身が大量

• IN句の個数が1つでも違うとすべてキャッシュされる

これが原因で、FullGCに伴うJVMのハングとOutOfMemoryErrorを発生し、障害が発生しました。

参考: QueryPlanCacheでOutOfMemoryError

まとめ

• フレームワークの移行は後方互換性とともに移行後に「できるようになってしまう」ことも調査しよう

• 長いものに巻かれるのも大事な要素だが、それにこだわりすぎる余り、技術選択の視野が狭くならないように注意しよう

• 移行先のフレームワークが一択の状態は危険なサイン。移行先フレームワークは複数用意するようにしよう

最後に

楽しんでいただけたでしょうか？皆様のお役に立てれば幸いです。

今回の移行に際して運用環境のパフォーマンス低下や運用障害を発生させたことは我々の不徳のいたすところであり、猛省を重ねております。

サイボウズは、今後も同じような失敗を繰り返さぬように技術の研鑽を続けていきます。

こんにちは、エンジニア採用担当の岡田(@y_okady)です。サイボウズではこの度、サイボウズでの仕事を複(副)業とする方を募集する「複業採用」を開始しました。おかげさまで早速たくさんのご応募・ご意見をいただいているのですが、その中の一つに「副業で具体的にどんな仕事ができるのかわからない」といった声がありました。

具体的なことは何も書いてないしそりゃそうだよなーと思ったので、開発/運用のエンジニア職について現時点で考えている業務内容を共有させていただきます。

業務内容

Webアプリケーションエンジニア

• 既存機能の改善、不具合改修、パフォーマンスチューニング、受け入れ試験自動化
• 新機能のプロトタイピング
• アーキテクチャ刷新に向けた研究開発、技術調査
• モニタリングシステムの改善

担当していただく製品/プロジェクトは、kintoneやNecoなどをイメージしています。

モバイルエンジニア (iOS/Android)

• モバイルアプリケーションの開発
• モバイル関連の技術調査
• 新製品のプロトタイピング

生産性向上エンジニア

• 社内業務改善ツールの開発
• 開発支援ツールの開発
• 継続的インテグレーションにおける性能検証の導入

※現時点でモバイルエンジニア、生産性向上エンジニアの募集要項はキャリア採用のページに掲載されていませんが、後日掲載を予定しています。

業務内容を書いてみたものの

実際に副業として働いているエンジニアはまだ一人もおらず、どんな業務をお願いできそうかはまだまだ手探り状態です。ここに挙げた業務以外にも、スクラムマスターやスクラムトレーナー、Jenkinsおじさんといった役割をお願いすることも可能なんじゃないかと考えています。この業務は大丈夫でこの業務はダメ、といったものはまだ一つもありませんので、まずはご相談いただいて、一緒に実現可能性を考えていきましょう。

勤務地について

勤務地は本業でも副業でも変わらず、東京、大阪、松山に加えてリモート（在宅など）も応相談となっております。今のところ完全リモートワークのエンジニアはまだ出てきていませんが、週2〜3回在宅勤務したり、1ヶ月まるまる在宅勤務するエンジニアも出てきています。完全リモートワークにもこれからチャレンジしていきますので、地方で働きたい方、在宅勤務したい方、お気軽にご相談ください。

おわりに

サイボウズは、多様な人々が多様なスタイルでつながるチームを目指しています。ワークスタイルや契約形態に関係なく、理想でつながり、一緒にチームワークあふれる社会を目指す仲間を増やすため、本業を持ちながらもサイボウズでの仕事に興味を持っていただける方を募集しています。

サイボウズの理念や考え方に共感いただける方の応募をお待ちしております。

複業採用 | サイボウズ 採用情報（新卒・キャリア）

みなさんこんにちは。SRE チームの内田（@uchan_nos）です。

サイボウズでは去年の 11/30 から 12/02 にかけて、4 回目となる毎年恒例の社内ハッカソンが行われました。 業務時間で好きなものを作ってよいので、図書委員でもある私は Raspberry Pi 3 と NFC リーダー、バーコードリーダーを使った図書管理システムを作ることにしました。 （ちなみに、この図書管理システムはハッカソンの審査で大賞に輝きました。うれしい！）

年明け 1 月下旬、ついに図書管理システムが本格的に稼働しはじめましたのでご紹介します。 使用機材やソースコードも公開しますので、興味があれば試してみてください。

作ったもの

kintone上の図書管理アプリの貸出・返却ステータスを、遠隔で変更する IoT システムです。 このシステムには社員証リーダーとバーコードリーダーが接続されていて、 誰がどの本を借りようとしているか（または返そうとしているか）を識別し、図書管理アプリのステータスを更新します。

kintone とはウェブ上にデータベースのようなものを構築できる弊社サービスで、 弊社内の開発系書籍はその kintone 上に構築したアプリ（データベース）で管理しています。 このアプリには、書籍名、ISBN、貸出ステータス（本棚にある・貸出中・紛失中）、棚番号などが記録されています。

今回作ったシステムでは、今までウェブブラウザ経由で貸出ステータスを変更していたものを、 社員証のタッチとバーコードの読み取りでできるようにします。 いちいちアプリを呼び出してきたり書籍名を入力する手間がなく、また、システムを本棚に常設することで、 「借りたい」「返したい」と思ったときに 直感的に使うことができるようになりました。 認知心理学の言葉を借りれば「アフォーダンスが劇的に向上した」といえます。

ハードウェア構成

簡単に買えるものだけで構成しています。

• Raspberry Pi 3 Model B
• バーコードリーダー BUSICOM BC-BR900L-W
• NFC リーダー PaSoRi RC-S380
• WiFi アダプタ WN-G300UA (本運用時のみ)
• Raspberry Pi 7" Touch Screen LCD (本運用時のみ)
• スピーカー

Raspberry Pi 3 本体は裏にあるので見えませんが、ちゃんと動いています。 Raspberry Pi 3 には USB 端子が 4 つ付いており、バーコードリーダーと NFC リーダーに加え、 開発時にキーボードとマウスも接続できます。すごいですね。

WiFi アダプタは本運用時に追加で買ったものです。 本棚にシステムを設置してみたところ Raspberry Pi 3 本体に内蔵されている WiFi アンテナでは電波の飛びが悪く、ネットワークが不安定になりました。 WN-G300UA のおかげで 電波強度が向上し、安定して運用できるようになりました。

実はこの WiFi アダプタ、USB コネクタ部が太く、上下の USB 端子で干渉してしまうことが分かりました。 アダプタを片方の USB 端子に挿すと、もう片方には何も挿せなくなるのです。 本運用のために調達しておいた Raspberry Pi 7" Touch Screen LCD は当初、タッチ機能を使わないつもりでしたが、 アダプタ干渉のためマウスを接続するポートが足りなくなり、この機能が図らずも役に立ちました。 危なかったです(^^;)

ソフトウェア構成

メインの制御プログラムは Python 2.7 で作りました。 この制御プログラムが無限ループにより動作し続け、社員証の読み取り、バーコードの読み取り、kintone アプリのレコードの更新を行います。

本を借りたい・返したい人はこんな感じで操作します。

1. 社員証をタッチ
2. 書籍の ISBN バーコードをスキャン

このシステムは音声案内が流れるようになっています。 社員証をタッチすると「97 で始まるバーコードをスキャンしてください」と言われます。 スキャンすると、その書籍をまだ借りてないなら借り、すでに借りている場合は返します。

弊社の社員証は NFC 規格にしたがっていて、nfcpyと PaSoRi リーダーで簡単に読み取ることができました。 社員証の中に社員番号が記録されているので、誰がシステムを操作したかを特定するのに使っています。

バーコードリーダーは USB キーボードとして認識され、スキャンに成功するたびに文字列として読み取った値を送ってきます（例えば 9781530445387\n）。 標準入力から読み込んで処理します。

制御プログラムと kintone とのやり取りには pykintoneを使いました。 kintone を操作するライブラリはいくつかあるようですが、今回はレコードのステータスを API からいじる必要があるため、それに対応したものである必要があります。 ステータスをいじる API が搭載されたのは kintone の 2016 年 5 月版からですので、メンテされてないライブラリだと対応していない可能性があります。

音声案内は AquesTalk Piを利用しています。 このソフトウェアは、コマンドライン引数で文字列（日本語対応）を与えると、標準出力に wav 形式の音声データを吐き出すという、非常に簡単に使える仕組みになっています。 当初は音声案内が無かったのですが、AquesTalk Pi を利用するようにしてから、システムの UX がとても高まりました。

図書管理アプリ

Raspberry Pi から操作する対象の図書管理アプリは kintone にて構成しました。 下図のように蔵書を管理しています。

このアプリ自体は以前から使われており、既に 1500 冊を超える本が登録されています。

それぞれの書籍情報は下図ようなレコードになっています。 （同じ本が複数冊ある場合、複数のレコードが登録されています）

図書管理システムの第一目標は、このフォームにある「ステータス：レンタル中」を、自席の PC に戻ることなく バーコードをピッとするだけで操作することです。 kintone ではフィールド以外にも「ステータス」を API から操作できるので、このシステムを実装することができました。

社員番号 - ユーザ名変換アプリ

会社によってポリシーは違うと思いますが、弊社の図書管理では 誰がどの本を借りたかを管理しています。 図書管理では様々なトラブルが発生するので（例えば、借りたい人がいるのに本棚に無いとか、「本棚にある」というステータスなのに見つからないとか） 最後に誰が借りたかが分かるとトラブルが解決しやすくなります。

弊社の社員証には 6 桁の社員番号が記録されています。 社員番号さえあれば個人の識別ができるはずですから、これでシステムが作れます。やったー！

というのはちょっと早とちり。 kintone 上でユーザを指定するには社員番号ではなく、kintone のユーザ名を得る必要があるのです。 そこで今回は、社員番号と kintone 上のユーザ名を記録した kintone アプリを作って対処しました。

このアプリは本質的なところではないので、詳しくは紹介しませんが、 社員番号とユーザ名の 2 つのフィールドがあるレコードが、社員の数だけ並んだ単純なアプリです。

リソース

今回作成したソースコードは https://github.com/uchan-nos/hondanaで公開しています。 オープンソースライセンス（MIT ライセンス）で公開しておりますので、ご自由にお使いください。

さいごに

今後は運用しながら出たバグを修正したり、使い方を分かりやすく掲示するなど、図書管理システムを便利にする活動をしていきます。

今回のシステムでは社員証と ISBN という、2 つの情報を組み合わせて「誰が何を」借りたかを管理しました。 もうちょっと頑張って、同じ ISBN を持つ複数の書籍を区別できるよう、1 冊 1 冊固有の管理番号を振り、バーコードを印刷して貼り付けておけば、社員証のタッチをなくすことができます。 これは実際の図書館が使っている方法ですね。

また、このアイデア自体は書籍に限らず「物を管理する」こと全般に適用できます。 既に総務部からひきあいが来ていて、電源タップなどの備品の貸し出し管理に使えたら便利だよね、という話をしています。 仕出し弁当の管理に使うこともでき、社内に存在するいくつかの問題を解決できそうな気がしています。

社員証を読み取る技術を応用すれば、社内でイベントを開催したときの参加者の記録を取れます。 そのほかにも無限に可能性が広がる技術なので、応用先を見つけていきたいと思っています。

こんにちは。情報システム部の松平です！ 今回は社内ネットワーク内から安全にインターネット上の Web サービスを活用するためのプロキシ構築方法を紹介します。

1. Web プロキシの NAT に対する利点

企業では、ルータやファイアウォールなどの NAT 機能を利用して、社内ネットワーク内のコンピュータからインターネットにアクセスすることが多いのではないかと思います。
NAT の構成では、悪質なサイトなど、特定のサイトへのアクセスを IP アドレスでしかブロックできない場合があります。

IP アドレスでブロックした場合、AWSや Akamaiといった CDNまで対象に含めてしまうと、まったく関係のないサイトで利用されている CSS、JavaScript ファイルまでブロックしてしまうケースが出てきます。

そこで注目したいのが Web プロキシである Squid の活用です。 Web プロキシは、IP アドレスではなく FQDNでブロックが可能となっており、昨今の CDN を多用する Web サービスを安全に利用できます。 また、FQDN で接続ログが残るのも良い点になります。

2. Squid とは

Squidはコンピュータとサーバー間の通信を中継するプロキシサーバーソフトです。 様々なプロトコルに対応しており、 Web サービスへのアクセスに用いられる HTTP、HTTPS の通信を中継することができる Web プロキシサーバーになります。

3. 具体的な設定例

Squid は CentOSなどの環境に簡単にインストールできます。インストール後、コンピュータ側のブラウザでプロキシの経由設定を行えば完了です。 ここでは CentOS 7.2 にインストールする手順を参考として記載します。

Squid を構築する

1) Squid をインストールする

yum -y install squid

2) Squid の設定ファイルを理解する

Squid では squid.confファイルを編集することでブラックリスト方式とホワイトリスト方式によるアクセス制御ができます。

squid.conf

# ローカルネットワークの定義
acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10# RFC 4291 link-local (directly plugged) machines

# SSL接続時に 443 ポート以外の CONNECT を拒否
acl SSL_ports port 443
acl CONNECT method CONNECT
http_access deny CONNECT !SSL_ports

# 接続先として指定されているポート以外を拒否
acl Safe_ports port 80    # http
acl Safe_ports port 21    # ftp
acl Safe_ports port 443   # https
acl Safe_ports port 70    # gopher
acl Safe_ports port 210   # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280   # http-mgmt
acl Safe_ports port 488   # gss-http
acl Safe_ports port 591   # filemaker
acl Safe_ports port 777   # multiling http
http_access deny !Safe_ports

# キャッシュの設定( manager を定義してないので無効な値)
http_access allow localhost manager
http_access deny manager

# ローカルネットワークからのアクセスを許可
http_access allow localnet
   
# 自身からのアクセスを許可
http_access allow localhost

# ここまで一致しなかった場合は拒否
http_access deny all

# Squid が使用するポート
http_port 3128

# core 出力場所の設定
coredump_dir /var/spool/squid

# キャッシュの設定
refresh_pattern ^ftp:     1440    20%     10080
refresh_pattern ^gopher:  1440    0%1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%0
refresh_pattern .   0 20%     4320   

初期設定では、localnet が acl として定義されており、定義したネットワークから定義したポート以外への接続が禁止されている構成になっています。
上記設定ファイル内の http_access から始まる行でアクセスルールを定めています。
これらの定義は、上から順番に評価されますので記述する順番をよく考える必要があります。

初期設定時のアクセスルール

↓ http_access deny CONNECT !SSL_ports # SSL接続時に 443 ポート以外の CONNECT を拒否  
↓ http_access deny !Safe_ports        # 接続先として指定されているポート以外を拒否  
↓ http_access allow localhost manager # manager が localhost から接続することを許可  
↓ http_access deny manager            # manager が接続することを拒否  
↓ http_access allow localnet          # localnet が接続することを許可  
↓ http_access allow localhost         # localhost が接続することを許可  
↓ http_access deny all                # ここまで一致しなかったものは拒否  

3) コンピュータ側のブラウザでプロキシの経由設定を行う

インターネットオプション – [接続]タブの、「LAN の設定」をクリックし Squid を経由する設定を行います。

ブラックリスト方式

※ ここでは localnet の acl を利用した設定例を記載します。
ブラックリストは特定のサイトのみをブロックする方式です。原則としてアクセスを許可する場合は向いていますが、安全性でいえば後述するホワイトリストのほうが高いです。

1) ブラックリスト用にファイルを新規作成する

ブラックリスト用にファイルを新規作成し、アクセスをブロックしたいサイトを 1 行づつ記述します。 先頭に. (ドット)を入れることで、サブドメインを含めた指定が可能です。
2017/1/30 時点で cybozu.com において、URL のタイプミスを利用した攻撃サイトが確認されています。 タイプミスを利用した攻撃サイトのブロックを想定してみます。

blacklist

.cybouz.com
.cyboz.com
.cybosu.com

2) squid.conf を編集する

ブラックリスト用の acl 、http_access の定義を追加し、ブラックリスト記載のサイトをブロックします。

squid.conf

acl blacklist dstdomain "/etc/squid/blacklist"
http_access deny blacklist
http_access allow localnet
http_access allow localhost
http_access deny all

3) Squid の設定を反映させる

Squid をリロードして設定を読み込みます。

systemctl reload squid

ホワイトリスト方式

ホワイトリストは特定のサイトのみアクセスを許可する方式です。例えば、cybozu.com のみ許可するといった設定が可能です。

1) ホワイトリスト用にファイルを新規作成する

ブラックリスト形式と同様に、ホワイトリスト用のファイルを新規作成します。

2) squid.conf を編集する

ホワイトリスト用の acl、http_access の定義を追加し、ホワイトリスト記載のサイト以外はブロックするようにコメントアウトします。

squid.conf

acl whitelist dstdomain "/etc/squid/whitelist"
http_access allow whitelist
#http_access allow localnet
#http_access allow localhost
http_access deny all

3) Squid の設定を反映させる

Squid をリロードして設定を読み込みます。

cybozu.com を使うためのホワイトリスト設定

自社の cybozu.com 環境のみアクセスを許可したい場合は、上記のホワイトリスト方式を利用し、ホワイトリスト用のファイルに cybozu.com のアクセスに必要なドメインを追記します。

サブドメイン名.cybozu.com
static.cybozu.com
store.cybozu.com
www.cybozu.com
help.cybozu.com

4. プロキシ設定の配布

Squid を経由するためには、前述したとおり、コンピュータ側での設定が必要となります。コンピュータが大量にあると大変手間な作業ですよね。
また、ノート PC など、社内ネットワーク外にコンピュータを持ちだした場合、プロキシの設定を解除する必要が出てきます。

上記の課題について解決する選択肢の 1 つとして、 WPAD を利用したプロキシの自動検出があります。
WPAD の利用については、賛否あると思いますが、今回は効率的にプロキシを展開する方法として紹介します。

WPAD 方式

WPADは、プロキシの設定を自動配布するための方法として開発された技術です。 WPAD は、Windows や Mac で利用可能な仕組みです。
プロキシの情報を自動配布するには、DHCP サーバーや DNS サーバーに対してプロキシサーバーを検出させる仕組みの設定が必要となります。
ここでは、DNS サーバーに対する設定を簡単にご説明します。

1) Web サーバーを構築する

まず、社内に Apache などの Web サーバーを構築し、社内のコンピュータからアクセスできるようにします。

2) 自動構成スクリプトファイルを配置する

Web サーバーのルートディレクトリに wpad.dat というファイル名の自動構成スクリプトファイルを格納します。
自動構成スクリプトファイルには、社内のプロキシの接続環境を記述しておきます。

wpad.dat

function FindProxyForURL(url, host)
{
        return "PROXY 192.168.0.10:3128;
        # PROXY サーバーIPアドレス：192.168.0.10 ポート番号：3128 の場合
}

3) DNS サーバーを設定する

DNS サーバーで wpad という名前の DNS レコード( A レコードまたは CNAME レコード)を登録し、社内ネットワーク上で、wpad の名前を解決できるようにします。

4) コンピュータ側の設定を確認する

Windows のブラウザの設定

初期値で [設定を自動的に検出する]のチェックがオンになっているため、特に設定することなくプロキシを自動検出できます。

Macのブラウザ設定

初期値で[自動プロキシ検出]のチェックがオフになっているため、チェックをオンにする必要があります。

Mac を社内ネットワーク外に持ち出した場合の挙動は利用するブラウザやアプリケーションの挙動に依存するようです。
Safari など社外で接続できない場合は、[自動プロキシ検出]のチェックをオフにする、またはネットワーク環境を切り替える必要があります。
詳しくは Apple 社のネットワーク環境を使うを参照ください。

Active Directory 方式

社内ネットワークのコンピュータが Active Directory により管理されている場合は、Active Directory のグループポリシーの基本設定を利用して、
コンピュータの[設定を自動的に検出する]のチェックを強制することや、自動構成スクリプトファイルの使用を強制することも可能です。
詳細を記載すると長くなるので今回は割愛させていただきます。
詳しくは Microsoft 社のグループポリシー管理コンソール-基本設定項目の構成をご参照ください。
なお、Active Directory 方式は、Mac は対象とできない点が欠点になります。

5. プロキシのログ監査

Squid では、どの IP アドレスからどのサイトへアクセスしたか /var/log/squid/access.log に記録するようになっています。
ログを保管しておくことで、ウイルス感染などの不正通信チェックなど、通信状況を把握する調査に役立ちます。 ログフォーマットの指定によりカスタマイズもできます。

6. まとめ

いかがでしたでしょうか。細かい設定まで説明しきれてなくて大変申し訳ないのですが、Squid を利用することで FQDN でサイトを許可、または拒否できることがイメージいただけたのではないかと思っております。 弊社 cybozu.com をご利用いただく上での安全な Web プロキシの構築方法として参考になれば幸いです。

7. 参考サイト

Japan IE Support Team Blog LAN のプロキシ サーバーの設定について
Japan IE Support Team Blog “WPAD” について

はじめまして、モバイルチームの刈川です。みなさんの会社や組織における「モバイル」ってどんな感じでしょうか。昨年からサイボウズにもモバイル専用のチームができたので今回はその紹介をしたいと思います。

モバイルチームとは

モバイルチームの説明をする前にサイボウズが置かれていたモバイル事情についてお話します。

サイボウズでは上図のように、製品ごとに各PGがモバイル開発を行っている状況でした。 ここで問題になっていたのが、

• モバイル開発スキルがチーム間で分散する
• テストやCI環境の整備などの作業が後手に回りがち
• そもそもモバイル開発自体の優先度が低い（※Webアプリの会社なので）

このような問題がありました。 そこでモバイル開発に特化したチームを設けることでこれらの問題を解決しようとしました。

モバイルチームがやったこと

各製品のモバイル開発にジョイン

前述の通り、モバイル製品を触れるプログラマは各製品チームにいるのですが、リソースや優先度の都合で対応が後手に回りがちなのが現状でした。そこでモバイルチームが各製品チームのモバイルプロジェクトにジョインすることでモバイル対応を支援してきました。

モバイルに関する情報を収集・共有

社内外からモバイルに関する情報を収集し、社内勉強会などを通じて共有を行いました。 情報の収集元は様々ですが、例えばDroidKaigiやiOSDC、Google for Mobileなどのカンファレンスに参加したり、Twitterやconnpass等で告知される社外勉強会への参加、また、Android WeeklyやiOS Dev Weeklyの定期購読などを通じて情報を収集していきました。その中で製品コードに使えそうなツールやライブラリは積極的に製品チームに提案し、実際に導入されたものもいくつかあります。

iOS/AndroidのCI環境の準備・運用

モバイルプロジェクトの中にはテストをしっかり書いているものもあれば、テストが存在しないものもあったり、また製品チーム内だけでCI環境を回していたりと、情報や環境が分散しているのが現状でした。そこでモバイルチームでこれらの作業を受け持つことにより、社内で共通で使えるCI環境の整備を目指しています。CIにはAndroidはJenkins, iOSはCircleCIを利用しています。

ワークショップの開催

これまでサイボウズのプロダクトはWebアプリケーションが中心でした。そのため、モバイルアプリの開発経験があるエンジニアは多くありません。そこで、まずは導入部分の障壁を取り払うためにAndroidアプリの基礎を学ぶためのワークショップをハンズオン形式行いました。教材に利用したのはUdacityでGoogleが公式に提供しているDeveloping Android Appsコースです。

プロトタイプの作成

モバイルの強みのひとつに、機能を切り出して単機能アプリとして提供できることが挙げられます。例えばFacebookのMessengerのようなアプリです。そういった単機能アプリで実現できそうなプロトタイプをモバイルチームで作成し、各製品のPMに提案を行いました。作ったものの例としては、kintoneで使えるカメラアプリやビデオチャットアプリ、通知消化アプリなどの単機能アプリです。これらのプロトタイプアプリを社内で使ってもらってフィードバックを得ることで既存製品に組み込んだり、別プロジェクトとして立ち上げることも視野に入るようになりました。

モバイルチームのこれから

今年も引き続き活動をしてきますが、今年は特にプロトタイプの作成に力を入れていく予定です。既存製品の新機能や全く新しいモバイル製品の提案などをプロトタイプ作成を通じて行い、モバイルの可能性を社内外にアピールし、サイボウズから新しいモバイル体験を世の中に提供できるよう取り組んでいきます。そのためにはまずはモバイルのニーズをヒアリングし、アイデアを募り、多くのチームを巻き込んでサイボウズらしいチーム開発をしていきます。

こんにちは！大阪開発部kintoneチームの鈴木亜耶(すずきあや)です。
今年1月にエンジニアとしてサイボウズへ中途入社しました。

今月から2018年卒の採用情報の公開が解禁となりましたね。
みなさん不安と希望を抱えつつ活動されているかと思います。

実家が関西・大学も関西という私。
新卒採用の頃、働くのも当然関西だろうと就職活動をしていました。
しかし、初めて入社した会社で上京することとなります。

そんな私が7年ごしで関西にUターン、サイボウズへ入社して感じた「働く場所」の文化の違い・驚きについてお話しします！

拠点間の近さ

私がまず驚いたのは、内定後に参加したCybozu Tech Conference 2016です。
このイベント、東京・大阪・松山の3拠点をテレビ会議でつないで同時開催されたのですよ！詳しくはリンク先をご参照ください。

遠く離れているはずの場所から資料が画面共有され、発表者が話しますが、ストレスなく聞くことができました。
無職になってまで脱出してきた東京が、こんなに近いなんて……と思ったものです(笑)

普段の業務でもテレビ会議は珍しくありません。
オフィスや自宅など、各々好きな場所から会議に参加します。
たまに自宅のお子さんやペットが映り込むというハプニングもあります！微笑ましい！

リモートワーク

リモートワークって何か特別な理由がないとできないと思っていませんか？そんなことないですよ！
サイボウズでは例えば、

• 子どもの側にいたいから
• 大雪だから
• 荷物が届くから

といった様々な理由でリモートワークする人がいます。
私も、健康診断の採血後で貧血が心配だから、なんて理由でしたことがあります(笑)

場所に依存しないチームワーク

個々人で働く場所が違うと、「対面コミュニケーションがしにくいぶん仕事が進まないのでは？」と疑問に思うかもしれません。
サイボウズではコミュニケーションツールとしてkintoneやCisco Jabberを使用しています。

入社から浅く、まだまだ分からないことが沢山ある私ですが、
kintoneで「×××をする方法が知りたい」「△△△で困っている」などとつぶやくと、必ず誰かが助けてくれます。
それは同じオフィスの人であれ、離れたオフィスの人であれ、在宅勤務の人であれ、他部署の人であれ、関係ありません。

この記事を書く時も助けてもらった

もちろん、内容によっては音声通話や対面で話すのが適切な場面もあります。
しかし、対面コミュニケーションが減ったから必ずしもチームワークが損なわれるとは言えないと感じました。
「困っている人を助けたい」「良い製品を届けたい」という気持ちは何処にいても一緒なのです。

さいごに

今回は好きな場所で働くことについて、サイボウズの環境と私個人が感じたことをお話ししました。

サイボウズでも仕事内容や職種によっては場所の制限があります。
しかしながら、「チームワークあふれる社会を創る」ために場所はそこまで関係ないんだなと入社して感じました。

今ある環境を整えるには長い年月を要したとお聞きしています。
これについては、Developers Summit 2017で岡田(@y_okady)が発表した「エンジニアが働きたい場所で働けるために、チームに必要なこと」で触れられているのでご覧ください。

kintoneの開発を通して、世の中に少しでも「自分の好きな場所で働ける人」が増えるよう、私も尽力していきます！

サイボウズでは、随時新卒採用・キャリア採用を行っております。
こういう働き方に興味がある・今まさに働く場所で悩んでいるという方はぜひ合わせてご確認ください。

募集要項/エントリー | サイボウズ 採用情報（新卒・キャリア）

サイボウズ・ラボの光成です。

今回はMicrosoft Excelに存在する特別なパスワードの仕様を紹介します。 後半はそれがマクロウイルスと関わるとどうなるか、ちょっとした実験をしたのでその紹介をします。

そもそものきっかけ

それは海外の人からのメールでした。 私はCODE BLUE 2015で「MS Officeファイル暗号化のマスター鍵を利用したバックドアとその対策」を発表した際、 Windows/LinuxでMicrosoft Officeファイルの暗号化・復号をコマンドラインでできるツールmsofficeを公開しました。

そのメールはツールについての質問で、「知人からもらったファイルをこのツールで確認すると暗号化されているのにファイルを開くときにパスワードを聞かれない。なぜ?」というものでした。

最初質問の意味がわからなかったのですが、確認すると確かにファイルを開くときにパスワードが不要なのに中身は暗号化されています。 拙作のツールを使うと暗号に使われている詳細パラメータを取得できます。

bin\msoffice-crypt.exe test.xlsm -info
flags =00000024
sizeExtra =0
algId = 0000660e
algIdHash =00008004
keySize =128
providerType =00000018
cspName = Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)
dataSize =72
saltSize =16
salt = 0C:A5:...
encryptedVerifier = FF:14:...
...
bad password

暗号化フォーマットとしては不自然なところはありません。とすると「何か特別なパスワードで暗号化しているのだろう」と想像しましたが、どんなパスワードか見当もつきません。 ふとLibreOfficeでも開けるのだろうかと試したら、問題なく開けたのです。

ということはLibreOfficeが何か特別な処理をしていると推測できます。 それでLibreOfficeのソースコードを調べてみたらまさにそういう処理が入っていました（filterdetect.cxx）。

if( aDecryptor.readEncryptionInfo() )
{
    /*  "VelvetSweatshop" is the built-in default encryption        password used by MS Excel for the "workbook protection"        feature with password. Try this first before prompting the        user for a password. */
   std::vector<OUString> aDefaultPasswords;
   aDefaultPasswords.push_back("VelvetSweatshop");

特別なパスワードVelvetSweatshop

ソースコードを読むと、どうやらVelvetSweatshopという特別なパスワードがあるようです。暗号化されたファイルを処理する場合、まずこのパスワードで復号してみて駄目だったら通常のパスワードを求める処理に移っていました。 そこで私のツールでこのパスワードをつけて先程のファイルに対して復号処理をしたらちゃんと復号できたのです。

ちなみにWordやPowerPointでこのパスワードをつけて保存すると、次回開いたときにパスワード入力画面が表示されました。 このパスワードはExcelのみに有効なようです。なんとも奇妙な仕様です。

マクロウイルスとアンチウイルスソフト

さて、ExcelなどのVBScriptを利用したマクロウイルスというものがあります。 1996年頃Larouxと呼ばれるマクロウイルスが初めて登場しました。 それからウイルスの種類が徐々に増えていき1999年ごろ大流行します。その後Office 2007からマクロ機能はデフォルトでオフになり、また会社によってはマクロを禁止しているところもあって近年では下火になっていました。 ただ去年の記事によると2015年ぐらいから再び増加傾向にあるそうです（マクロウイルスを知らない世代の社員が狙われる？「Office文書を開いて感染」攻撃が再び増加（INTERNET Watch））。

アンチウイルスソフトはマクロウイルスファイルを概ねパターンマッチで検出します。 しかしパスワードをつけて暗号化していたらもちろん復号できず、中身をチェックできません。

ただVelvetSweatshopという特別なパスワードをつけた場合、中身は暗号化されていても見かけはユーザにとって普通のファイルと同じです。 パスワードが分かっているので技術的には復号可能ですが、アンチウイルスソフトはこの中身をチェックしているのでしょうか。

そこで実際にLarouxと判定されるExcelマクロファイルを作り、VelvetSweatshopで暗号化して試してみました。 7種類のアンチウイルスソフトでチェックしたところ検出したのは一つだけでした（2017年3月6日時点）。 意外にも素通ししてしまうのが多かったです。

検出したソフトは、「暗号化Excelファイルを見つけたらとりあえずVelvetSweatshopで復号し、成功したら中身をチェックする」という処理をしているのだろうと思います。

実はこの話は海外では割と有名なようで、たとえばWhen is a password not a password?という2013年の記事があります。 今回、メジャーなアンチウイルスソフトが検知しないのを自分で確認して、個人的にはそれはチェックすべきではと思いました。しかしソフトベンダーにとっては、このリスクに対してスキャンするコストの増加が見合わないという判断なのかもしれません。 この件についてMSRC（Microsoft Security Response Center）に問い合わせしてみたのですが、たいして影響がないので（minimal impact）特に対応する予定はないとのことでした。

いずれにせよ最近は個人を狙った標的型ウイルスが多いそうです。ファイルを開くときやマクロを有効にするときにいつでも注意しなければならないのは実践するのが難しく、悩ましい問題ですね。

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

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

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

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

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

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

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

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

1年を通しての活動

2016年 前半

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

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

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

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

2016年 中盤

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

2016年 後半

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

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

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

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

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

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

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

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

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

メンバーの増員

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

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

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

今後に向けて

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

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

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

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

We are hiring!

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

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

Cybozu Meetup って？

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

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

• 東京オフィス：https://cybozu.connpass.com/event/49521/
• 大阪オフィス：https://cybozu.connpass.com/event/50513/

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をよろしくお願いします！

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

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

では、どうぞ！

障害にすてるところなし

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

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

運用障害の話

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

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

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

クラウドの規模と稼働率

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

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

さて本題

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

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

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

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

基礎知識を身につける

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

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

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

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

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

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

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

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

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

知識を深掘りする

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

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

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

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

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

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

チームで強くなる

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

失敗の名は

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

失敗を受け入れる文化

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

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

失敗を共有する文化

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

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

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

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

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

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

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

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

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

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

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

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

解決の糸口

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

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

ブログに公開

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

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

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

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

ずぶとく生きるように

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

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

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

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

おわりに

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

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

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

引用

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

• 大規模サービスを支える技術
• ハイパフォーマンス MySQL
• Java パフォーマンス

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

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

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

現状のシステム

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

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

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

Neco でやりたいこと

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

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

Kubernetes とは

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

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

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

• Kubernetes
• Mesos / DCOS
• Docker Swarm
• Nomad

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

勉強会の内容

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

• Interactive tutorial
• Redis と PHP を利用したゲストブックの作成

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

• helm

  K8s 用パッケージマネージャ。Redis 等のサービスを k8s に簡単にデプロイできる。

• stern

  kubernetes使いは全員 stern を導入すべき by @lestrrat だそうです。

記念写真

今後の予定

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

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

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

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

サイボウズ・ラボユース

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

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

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

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

修了生の発表

緑川志穂さん

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

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

城倉弘樹さん

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

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自作入門の著者の川合さんです。

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

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

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

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

for{i = 0}{1}{i++}{print i}

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

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

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

小津泰生さん

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

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

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

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

make_now_justさん

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

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

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

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

高品佑也さん

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

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

開発を初めて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の方どうもありがとうございました。

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

• 緑川さん ラボユースを卒業した
• 城倉さん サイボウズ・ラボユース 第6期

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

こんにちは、風穴（かざあな、@windhole）です。私事ですが、この4月から開発本部の所属になりました。ということで「初」エンジニアブログとして、先日開催した「Cybozu Meetup #2 SRE」についてレポートします。

「サイボウズの中の人」と交流する機会

「Cybozu Meetup」は、外部のエンジニアの皆さんが、サイボウズのエンジニアとカジュアルに交流する場として企画、開催しているイベントシリーズです。いま流行の企業ミートアップのサイボウズ版、ということですね。会場はサイボウズのオフィスなので、社内の雰囲気を実際に肌で感じて頂ける機会でもあります。

開催頻度は東京オフィスで月1回、大阪オフィスで数カ月に1回程度と考えています。毎回テーマを決めていて、先日開催した「Cybozu Meetup #2」（2017年4月3日、東京オフィス）は「SRE」（Site Reliability Engineering）ということで開催しました。

サイボウズのSRE

Cybozu Meetupでは、最初にトークセッションとして、テーマにちなんだプレゼンを行っています。今回は、サイボウズの「SREチーム」設立（記事「SRE チームを設立します」を参照）を主導した山本泰宇（@ymmt2005）が、SRE設立の背景や活動内容について話しました。

質問＆交流タイム

トークセッションの後は、ざっくばらんな質問、交流タイム。テーマが「SRE」ということで、サイボウズのSREチームのエンジニアが多数参加していて、会場のあちこちで質問攻めにあっていました。

また、SRE以外のエンジニアや、人事担当の社員も参加していたので、社内の雰囲気や、働き方や制度などの話でも盛り上がりました。ざっくばらんで率直な話を、直接「中の人」から聞くことができるのがMeetupの醍醐味でしょう。

Togetterのまとめはこちら：Cybozu Meetup #2 まとめ

次回は「生産性向上」

次回のCybozu Meetupは「生産性向上」をテーマに開催します。残念ながら、すでに募集は締め切らせていただきました。開催の様子は、こちらのブログでレポートしますので、お楽しみに。

5月以降も、東京オフィスでは毎月のペース開催していく予定です。また、6月には、大阪オフィスでの開催も予定しています。ご興味ある方は、connpassグループ「Cybozu Inside Out」をフォローして頂ければ。

ではまた。

こんにちは！デザイナーの篠原です。 先日サンフランシスコに出張に行ってきました。わたしにとって初めての海外出張！その一部始終をレポートします。

出張の目的

• USメンバーとワークショップ
• Adobe, HITACHI Americaへの企業訪問

サイボウズは現在「GO US!」を合言葉にUS市場の開拓にフォーカスしています。デザイングループはUS市場でローカライズされたサービスを作るためにUSメンバーと一緒にワークショップを行ったり、現地企業を訪問してネットワーク作りに力を入れています。

USメンバーとワークショップ

デザイナーの武器を使ってコミュニケーション

現地のメンバーと新しいモバイルサービス＆デザインを考えるワークショップを行いました。私は英語超初級者なのでジェスチャーやイラストを交えてディスカッション。言葉だとなかなか伝わらないのですがイラストなら伝わるようで、描くと場の空気が和み、新たな発言やアイデアを呼び込むきっかけとなりました。英語が苦手というデザイナーはイラスト積極的に使ってコミュニケーションしていくのが良さそうです。

TV会議で日本メンバーと密に情報共有

ワークショップの結果を日本の開発チームと毎日ビデオ会議で共有しました。サマータイム中で時差が16時間あるので会議時間の設定には注意が必要です。（気をつけないと真夜中に会議をするハメに…！）最初はうまく会議できるかな…？と不安でしたが、通信環境が良いので日本とサンフランシスコとの距離を感じさせないスムーズな会議をすることができました。

Adobe, HITACHI Americaへの企業訪問

Adobe

AdobeのユーザーリサーチマネージャーSherylさんを訪ねました。Sherylさんはデザイングループのマネージャー柴田の元上司です。

オフィスの様子はこちら（英語）
Adobe Headquarters - San Jose - Office Snapshots

サイトの画像からもわかるようにクリエイティブな刺激に満ちており、その空間にいるだけでワクワクして新しいアイデアが閃きそうなオフィスでした。至る所にソファやテーブルがあるのでちょっとしたブレストやミーティングがすぐできます。 さらにビックリなのが、オフィスの中にジムやバスケットコートがあること！ジムには本格的なフィットネスマシンが完備されていてトレーニングのクラスまで開講されていました。これなら仕事に行き詰まってもリフレッシュして仕事に戻ることができますね！

オフィス見学後はSherylさんとリサーチやワークショップについてのお話をしました。開発に関わるすべてのことをチーム一丸となって行うことが大事だとおっしゃっていたのが印象的でした。

HITACHI America

HITACHI AmericaのUser Experience Design Labにもおじゃましてきました。こちらのオフィスは社会学を参考に社内でデザインリサーチを幾度も行い作られたそうです。Meetupやパーティーができる広々としたオープンスペースは交流の場として親しまれており、月末の金曜日にはBeer Bashが開催されるそうです。

USオフィス

最後にサイボウズのUSオフィスをご紹介したいと思います。私たちのオフィスは、サンフランシスコ市内のミッション地区というところにあります。モンゴメリー駅から歩いて3分程度の場所です。ミッション地区は最近オシャレなカフェやレストラン、ブティックが増えてきている人気の町です。少し歩くとユニオンスクエアや観光客に人気の路面電車があります。

オフィス内はこんな感じで、みんなで机を並べてワイワイ仕事をしています。kintoneでおなじみのキリンもいますよ。

オフィス付近にはDAISOが！付箋やペンなどワークショップで使う道具が一式揃うので、急にブレストしたい！ワークショップしたい！となっても大丈夫です。

海外で仕事がしたいデザイナー募集中！

現在デザイングループは「海外で仕事がしたい！」というデザイナー、リサーチャーを大募集中です。興味のある方ご応募お待ちしております！
デザイングループ 採用 | サイボウズ株式会社

こんにちは、コネクト支援チームの風穴（かざあな）です。先日開催した「Cybozu Meetup #3 生産性向上」についてレポートします。

サイボウズのミートアップ

「Cybozu Meetup」は、サイボウズのエンジニアとカジュアルに交流する場として企画、開催しているイベントシリーズです。いま流行の企業ミートアップのサイボウズ版ですね。会場はサイボウズのオフィスなので、社内の雰囲気を実際に肌で感じて頂ける機会でもあります。

開催頻度は東京オフィスで月1回、大阪オフィスで数カ月に1回程度の予定です。毎回テーマを決めていて、これまでに「フロントエンド」、「SRE」（Site Reliability Engineering）というネタで開催しました。

サイボウズの生産性向上

通算3回目となるCybozu Meetupのテーマは「生産性向上」。

2015年8月に生産性向上チームを立ち上げた宮田（@miyajan）が「すべてを自動化せよ！　〜生産性向上チームの挑戦〜」と題してトークセッションを行いました。

質問＆交流タイム

トークセッションの後の交流タイムでは、別チームのエンジニアや一般社員も参加し、生産性向上に関する技術の話や、エンジニアの働き方の話などでも盛り上がりました。

サイボウズの生産性向上チームでは、一緒に生産性向上に取り組んでくれるエンジニアを絶賛、募集中です。詳しくは、以下のサイトをご覧ください。

生産性向上エンジニア──CIや自動化などの開発基盤を整備する大事なお仕事 - サイボウズ株式会社のWeb エンジニア中途の求人 - Wantedly

次回は「スクラム／アジャイル」

次回のCybozu Meetupは「スクラム／アジャイル」をテーマに開催します。開催の様子は、こちらのブログでレポートしますので、お楽しみに。

また6月には、大阪オフィスでの開催も予定しています。ご興味ある方は、connpassグループ「Cybozu Inside Out」をフォローしてくださいませ。

ではまた。

こんにちは、kintone開発チームの長谷川です。

今年もサイボウズではサマーインターンシップを開催します！去年好評だった3コース（Webサービス開発、UX/UIデザイナー、品質保証/セキュリティ）に加えて、今年はモバイルアプリやインフラの開発に興味のある学生向けのコースも新たに用意しました。

この夏はサイボウズでワンランク上のスキルを身に付けてもらえたらと思います。 皆さんのエントリーをお待ちしています！

募集要項

日時

• 第1回 8月21日(月)～25日(金)
  • Site Reliability Engineeringコースは第1回目のみの開催となります
• 第2回 9月04日(月)～08日(金)
• 第3回 9月25日(月)～29日(金)

場所

• 東京オフィス
• 大阪オフィス
• 松山オフィス

※ Webサービス開発コースは3拠点で開催します。その他コースの東京オフィス以外での開催は応相談となります

就業時間

9：00～18：00

※ 初日は10時集合、最終日は懇親会を実施するため20時～21時頃解散となります

コース

• Webサービス開発コース
• モバイルアプリ開発コース
• UX/UIデザイナーコース
• 品質保証/セキュリティコース
• Site Reliability Engineeringコース

対象

2019年4月の入社が可能な学生

募集人数

各コース1回につき5名程度

選考

書類選考、面接（Webも可）1回

待遇

日給8,000円

※ 遠方からご参加いただく方には、交通費・宿泊費を支給します

エントリー方法

こちらよりエントリーしてください

お問い合わせ

• 人事部: 中江 麻未
• メールアドレス: recruit@cybozu.co.jp
• 電話番号: 03-4306-0870

Webサービス開発コース

概要

サイボウズが提供するWebサービスの実際のユーザーや社内での要望を元に

• ユーザーが本当に困っているのは何なのか
• どういった機能を提供するのが良いのか
• その機能は他のユーザーにも広く使われるものか

といった企画段階から、その機能のプロトタイプを作成するところまでを体験していただきます。

実際にサービスを開発しているメンバーがメンターとなり、課題の設定の仕方や実装の進め方、コードやテストの書き方までを指導しながら開発を進めていきます。東京と大阪では kintone、松山では メールワイズか サイボウズOfficeに関連した題材を扱います。

必要な経験/スキル

• プログラミングの経験
• HTML、CSS、JavaScriptの知識

あると望ましい経験/スキル

• Webサービス開発の経験
• Git/GitHubの使用経験

モバイルアプリ開発コース

概要

サイボウズのモバイル製品に簡単な機能を実装していただきます。製品のソースコードに触れたり、テスト・コードレビューを通じて実際の開発現場を体験することができます。

必要な経験/スキル

• iOS(Swift) または Android(Java)の開発経験

あると望ましい経験/スキル

• Git/GitHubの使用経験

UX/UIデザイナーコース

概要

サイボウズのデザイングループメンバーとともに、製品・サービスのデザイン業務に取り組んでいただきます。自由な発想を活かして新しいデザインを提案してください。

必要な経験/スキル

• PCやスマホ向けのデザイン経験
• ポートフォリオ

あると望ましい経験/スキル

• ユーザーリサーチの興味、経験
• プロトタイピングスキル
• チャレンジ精神

品質保証/セキュリティコース

概要

製品の品質保証業務を通してソフトウエアの品質がどのようなプロセスで確保されているのか、そもそも品質とは何かを学んでいただきます。 品質を確保するだけではなく、製品がリリースされた後、製品の品質に関する情報をどのように顧客に伝達していくのか、顧客の要望をどのように製品にフィードバックしていくのかを実体験を通して学んでいただきます。

必要な経験/スキル

• Excelを操作できる（マクロやVBAは不要）
• Webサービスが動いている仕組みを説明できる
• 下記の内容を理解しており、それぞれの仕組みや用語を説明できる
  • インターネットの仕組み
  • ホームページの仕組み

あると望ましい経験/スキル

• Webサービスのテスト経験
• Webサービスのセキュリティテスト経験
• Webサービスの脆弱性の攻撃方法を知っている（SQLインジェクション、XSS）

Site Reliability Engineeringコース

概要

SRE(Site Reliability Engineering)チームにて、インフラにかかわるソフトウェアを開発・提案していただきます。

例：

• https://github.com/cybozu-go/cmdへのコミット
• 現在開発中のログ転送ミドルウェアの追加開発
• 開発環境の管理ツール
• 障害対応内容の自動記録ツール

実際の開発内容は応募された方とメンターにて相談の上で決めることができ、メンターのサポートの元取り組むことができます。その際、SREチームの持つ環境をご活用いただけます。(開発環境・本番環境のメトリクスデータ・OSSへの知見など)AWSなどのサービスを組み合わせたシステム構築ではない形になり、実質の開発期間は3日程度になるため、開発対象は小規模のものになります。

必要な経験/スキル

• Go言語, Python, C, C++のいずれかの言語にて、Gitを利用したツールの開発が行えること

過去に開発したソフトウェアを添えてご応募ください。(GitHubのURLなどでも可)

2016年の開催記事

• サイボウズサマーインターン2016 報告その1〜Webアプリケーション開発コース
• サイボウズサマーインターン2016 報告その2〜品質保証・セキュリティコース
• サイボウズサマーインターン2016 報告その3〜デザイナーコース