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

 

大阪で「SRE」「生産性向上」「スクラム/アジャイル」を肴にミートアップ!

こんにちは。隙あらばコネクトしようと考えている風穴(かざあな、@windhole)です。

6月17日(土)に、サイボウズ大阪オフィスにて「Cybozu Meetup Osaka #2 SRE、生産性向上、スクラム/アジャイル」を開催しましたので、レポートします。

f:id:cybozuinsideout:20170713123730j:plain

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

2017年2月からスタートした「Cybozu Meetup」は、サイボウズのエンジニアとカジュアルに交流する場として企画、開催しているイベントシリーズです。会場はサイボウズのオフィスなので、社内の雰囲気や社員の様子を、実際に肌で感じて頂ける機会でもあります。

第1回は、東京と大阪をTV会議システムで接続して同時開催しましたが、運営上、やや難しい面があることが分かり、それ以降は別々に開催することになりました。その後も東京は月1回のペースで開催していますが、大阪は今回が2回目ということになります。

久しぶりの大阪開催ということで、東京の3回分のコンテンツ(SRE、生産性向上、スクラム/アジャイル)をまとめてお送りする「豪華版」(自称)として企画しました。

開催時間も、東京は毎回平日夜ですが、今回の大阪開催は、土曜日の午後として、3つのトークをゆっくり聞いていただく趣向に。

SRE

f:id:cybozuinsideout:20170713123939j:plain

運用本部長の山本 泰宇(@ymmt2005)は、サイボウズのSRE(Site Reliability Engineering)チームについて紹介。オフレコなトピックも交えつつ、話はアーキテクチャ刷新プロジェクト「Neco」にまで及びました。

生産性向上

f:id:cybozuinsideout:20170713124008j:plain

生産性向上チームの宮田 淳平(@miyajan)は、自身が2015年8月に立ち上げた同チームについて、具体的な例を交えて紹介。会場からは「生産性向上のための新しいツールを導入する際に、抵抗勢力が出てきたらどうしてますか?」といった、生々しい(?)質問が出ました。実はこれ、東京開催のときも同様の質問が出ていました。サイボウズの生産性向上チームは、各開発チームからの相談や要望を受けて活動しているので、今のところ、そういう課題は出ていないのでした。「人は、他の人から言われたことをやらされるのは楽しくないですよね。なので、当人たちがやりたいと思うところから改善していくのが良いのでは」(宮田談)。

スクラム/アジャイル

f:id:cybozuinsideout:20170713124026j:plain

自身が旗振り役となって、サイボウズの開発チームへのスクラム導入を進めてきた天野 祐介(@ama_ch)は、その経験を紹介しました。会場からは、改善スプリントについての悩みや、KPTのやり方、トレーニングへの取り組み方などについて質問が出ました。スクラムは、悩みが尽きないですね……。

交流タイム

トークセッションの後は、ドリンク片手におやつをつまみつつの交流タイム。今回は、3つの異なるテーマを詰め込んだため、テーマごとに参加者が分断されるかも……とも思ったのですが、蓋を開けてみると、複数のトピックに関心がある方がほとんどで、参加者同士でも大いに話が盛り上がっていました。

f:id:cybozuinsideout:20170713124050j:plain

次回は9月?

次の大阪開催は未定ですが、3カ月に1回は……ということで、9月に開催できたらと考えています。ご興味ある方は、connpassグループ「Cybozu Inside Out」をチェックして頂ければ。

また、「こんなテーマを聞いてみたい!」とか「今度は松山で開催してほしい!」といったご要望があれば検討いたしますので、遠慮なくお知らせください。

おまけ:
開催前夜は、チームワークを高めるべく「たこ焼き」に挑戦しました。 f:id:cybozuinsideout:20170710070117j:plain

ではまた。

 

スレッド名にデバッグ情報を埋め込むと激しく捗る件

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

今回、Java のちょっとしたデバッグテクニックを紹介したいと思います。Java で運用中何かトラブルが発生した場合、スレッドダンプを取得することはしばしばあると思いますが、スレッドダンプだけだとちょっと情報が足りないことがあります。今回はスレッドダンプから得られる情報を増やして、素早く障害対応したりデバッグに役立てる方法を紹介します。

まずはじめに: スレッドダンプの取り方

基本ですが、改めてスレッドダンプの取得の仕方を紹介しておきます。スレッドダンプを取得する対象のプロセス ID を仮に 12345 として、下記のように jstack コマンドを実行すればスレッドダンプが取得できます(※Linux上で操作する想定)。

$ jstack 12345

対象のプロセス ID は ps aux | grep java や、jps -l コマンドで調べましょう。

一つ注意点があります。jstack を実行するユーザーは Java プロセス実行ユーザーと同じユーザーでなければなりません。仮にログインユーザーが aoking で、対象プロセスの実行ユーザーが cybozu なら下記のようにしましょう。

$ sudo -u cybozu jstack 12345

さて jstack を発行するとこんなスレッドダンプが取得できます(一部抜粋)。

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f31fc09c000 nid=0x57d4 in Object.wait() [0x00007f31ccd17000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000005cab10ff8> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
    - locked <0x00000005cab10ff8> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"main" #1 prio=5 os_prio=0 tid=0x00007f31fc01a000 nid=0x57c4 runnable [0x00007f3204b90000]
   java.lang.Thread.State: RUNNABLE
    at java.util.regex.Pattern.<init>(Pattern.java:1351)
    at java.util.regex.Pattern.compile(Pattern.java:1028)
    at com.cybozu.common.Sample.main(Sample.java:8)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

これはスレッドごとにスレッド名や優先度、スレッド ID、スタックトレース等を出力したものです。例えば例では main スレッドと Finalizer スレッドがあり、main スレッドでは java.util.regex.Pattern クラスのインスタンス初期化をしている最中だということがわかります。

スレッド名に情報を埋め込もう

さて前述の例のスレッド名は mainFinalizer だったので一目瞭然でしたが、一般的なスレッド名は pool-472-thread-6392qtp278934944-22 などで、実質意味を成さないものがよくあります。ここに任意の名前を埋め込んで、デバッグ効率を高めましょう。

早速例を見てみます。

long customerId = ...
String requestId = ...

Thread current = Thread.currentThread();
String originalName = current.getName();

String name = String.format("blob-add-%d-%s", customerId, requestId);
current.setName(name); // スレッド名をセット
try {
    addFile(...);
} finally {
    current.setName(originalName); // スレッド名を元に戻す
}

こちらは cybozu.com 内で利用しているファイルサーバーの実装を元にした例です。このファイルサーバーに対してファイル追加を行うリクエストが来た時を想定しています。ここでは、ファイル追加処理であるという目印(blob-add の部分)と、顧客 ID、それからリクエスト ID というものをスレッド名に載せています。リクエスト ID とは cybozu.com へのアクセスごとに割り当てられる ID のことで、このリクエスト ID があればどのサーバーに何時にアクセスしたのかということがわかるようになっています。

この処理を入れておくと、スレッドダンプを出した際のスレッド名が blob-add-52153-1bd6bb9a88cc4ad のようになり、スレッドダンプを眺める時に「ファイル追加処理が怪しい。顧客 ID 52153 のユーザーに影響が出ていそうだ、リクエスト ID を元に他のログを見よう」ということができるようになります。

これはあくまで例であり、アプリケーションによって必要な情報は大きく異なります。過去の障害調査の経緯などを参考にしてスレッド名に埋め込む情報を決めると良いでしょう。

処理が終わったらスレッド名を元の名前に戻しておくと良いです。理由はふたつほどあります。ひとつ目は、スレッドは処理が終わったらスレッドプール内で寝ているので、その寝ている時のスレッドと処理中のスレッドを見分けるため、という理由が一つ。もうひとつは、スレッドが再利用された時、スレッド名を適切な名前に設定していなかったらリクエストとスレッドの情報に乖離が生じることになってしまう、という理由です。

スレッドプールの名前を任意の名前にしよう

前章では Web アプリケーションをイメージしており、リクエストごとにスレッド名を指定する作りでした。しかしアプリケーションの種類によっては、スレッド個々についてではなくスレッドプール単位で情報が分かれば良い、というケースもあります。

Java でスレッドプールといえば ExecutorService が便利なので良く使われますが、こちらはデフォルトだと pool-7-thread-5 のような味気ないスレッド名が使われます。ExecutorService を使う場合でもスレッド名を自由に設定することができるので、今回の例では新規にスレッドが生成される度にスレッドに番号を埋め込む方法を紹介します。

通常、ExecutorService の生成は Executors.newCachedThreadPool() あたりが良く使われます。このメソッドには java.util.concurrent.ThreadFactory を渡すことができ、ThreadFactory ではスレッド生成時の処理を書けるので、そこで任意の名前を設定することができます。

コード例です。

public class CybozuExecutors {
    public static ExecutorService newCachedThreadPool(String poolName) {
        // ここのスレッド名の %d にスレッド番号が自動的に割り当てられる
        ThreadFactory factory = new CybozuThreadFactory(poolName + "-thread-%d");
        return Executors.newCachedThreadPool(factory);
    }

    private static class CybozuThreadFactory implements ThreadFactory {
        private final AtomicInteger counter = new AtomicInteger();
        private final String threadNameFormat;

        private CybozuThreadFactory(String threadNameFormat) {
            this.threadNameFormat = threadNameFormat;
        }

        @Override
        public Thread newThread(Runnable r) {
            // ここでスレッド名をフォーマットする
            String name = String.format(threadNameFormat, counter.incrementAndGet());
            return new Thread(null, r, name);
        }
    }
}

使う側ではこのようにして呼び出して ExecutorService を生成します。

ExecutorService executor = CybozuExecutors.newCachedThreadPool("mail-processor-" + customerId);

するとこの executor を使ったタスクのスレッド名は mail-processor-52153-thread-3mail-processor-52153-thread-27 のようなスレッド名になり、顧客 ID 52153 のメール関連の処理を担当するスレッドということがスレッドダンプから一目瞭然になります。

注意点。CybozuThreadFactory はあくまでサンプル用に書いたコードです。実際に使う場合は Guava の ThreadFactoryBuilder 等を使うと安全でシンプルに ThreadFactory を生成できるのでおすすめです。

最後に

スレッド名にデバッグ情報を埋め込むのは大変便利ですが、当たり前すぎるのかあまり紹介されないテクニックなので今回紹介させていただきました。適切な情報をスレッド名に指定しておくと原因や影響範囲が特定しやすくなり、結果的にユーザーへのサービス品質が高めることができると思います。

特にマルチスレッドなプログラムはデバッグに大変時間がかかることが多いです。スレッド名の改善だけで解決できるようになるわけではありませんが、解決困難な現象に立ち向かう時のひとつの手がかりとしては有用なので、ぜひ参考にしてみてください。

それでは、良いデバッグライフを!

 

2016年 脆弱性報奨金制度を振り返って

こんにちは。Cy-PSIRT の山西です。

本エントリでは 2016 年に実施した脆弱性報奨金制度の結果、ご参加いただいた方向けのアンケートでいただいた質問への回答、2017年後半戦の取り組みについてまとめました。

ご報告くださった方、アンケートへ回答くださった方、ありがとうございました!

2016年の振り返り

定量情報

2016年のご報告数、報奨金のお支払金額は以下のようになりました。 f:id:cybozuinsideout:20170623135014p:plain

※ 数値の見方  外部からお寄せいただいた脆弱性情報は、受付 > 検証(再現確認)のプロセスを経て、脆弱性の認定手続きに進みます。  詳しくは過去の総括記事をご覧ください。

blog.cybozu.io

2016年報奨金額獲得ランキング

2016年にご報告いただいた脆弱性によって、獲得した報奨金額が最も多かったのは東内裕二(@yousukezan) 様でした。おめでとうございます。

f:id:cybozuinsideout:20170626092635p:plain

高額な脆弱性をご報告いただいた方ランキング

ご報告いただいた脆弱性が高額だった方ランキングも、全体のランキングに続き、東内裕二(@yousukezan) 様が 1 位でした。こちらもおめでとうございます。

f:id:cybozuinsideout:20170626092558p:plain

2016年のトレンド

前年以上に認定の可否を議論する機会が増えました。 2016年に社内で議論を重ねた報告については Cybozu Tech Conference 2016 で紹介した際の資料を公開しているので、よろしければこちらもご覧いただけると嬉しいです。

www.slideshare.net

それと同時に 2016年は、XSS の脆弱性がご報告数 1 位に返り咲きました。XSS単体では、前年より 10 件ほど多くご報告いただきました。

f:id:cybozuinsideout:20170623160617p:plain

新しい機能も追加されており、まだまだ「こんな脆弱性あるの?」と思ってしまうような脆弱性も眠っているかもしれません。 社内としてもそんな脆弱性達を撲滅するために新たな企画を考えておりますので、是非バグハンターの方々にもご協力賜りたいです。

アンケートでいただいた質問への回答

アンケートにご協力いただいた皆さま、貴重なフィードバックをありがとうございました。 いただいたご意見は今後の運営に生かすと共に、出来る限り要望にもお応えしていきたいと考えております。

報奨金のお支払い方法の検討

現在、報奨金のお支払いは口座振り込みでのみ行っております。口座振り込み以外で受け取りたいといった方もいらっしゃいましたので、その他のお渡し方法についても検討してまいります。

「脆弱性情報のご報告フォーム」で投稿したら自動返信をしてほしい

HPのご報告フォームに、自動返信の機能を早速設定いたしました。

認定までの期間を改善してほしい

現在は可能な限り 10 営業日以内に評価完了までご連絡できるように努めておりますが、報告が集中したり、報告いただいた内容が複雑だったりした場合には通常よりお時間をいただくケースもございます。ご了承ください。

修正の遅さを改善してほしい

申し訳ございません。セキュリティ品質の向上には日々努めておりますが、改修による影響範囲や脆弱性の与える深刻度によっては、改修が遅れる場合がございます。 また、クラウドサービスに比較してパッケージ製品はリリース間隔が長いため改修に時間がかかる傾向があります。 現在、そのような状況を解決するために開発プロセスの高速化に取り組んでおります。

修正までの期間が短い脆弱性の報奨金を上乗せしてほしい

CVSS の評価では、攻撃の容易度についても評価として考慮しておりますのでご要望にはお応え出来かねます。 また、前項で記載しておりますように、製品によってはリリースの間隔が異なり、改修期間で報奨金の上乗せをするのは難しい状況です。

2017年の取り組み

最大 5倍キャンペーン

最後のご案内になりましたが本日より報奨金の増額キャンペーンを実施いたします。

f:id:cybozuinsideout:20170623135407p:plain

詳細についてはキャンペーンページをご覧ください。

最大5倍キャンペーン

本制度の中では前例にない取り組みとなりますが、弊社の脆弱性に対する発見価値も高まってきており増額に踏み切りました。 対象製品は、Garoon、Office、メールワイズ がそれぞれ倍額。 kintone および、クラウド環境の共通管理画面(ログイン機能を含む)については、通常金額の 5 倍の額といたします。

報奨金獲得者のリアルタイムランキング

ご要望を多くいただいたため、リアルタイムランキングの実施を検討してまいります。 毎日の更新には対応できませんが、週 1 程度でランキングを公式 Twitter アカウント(@CybozuBugBounty)にてご案内いたします。 よろしければフォローをお願いします。最大 5倍キャンペーンで報奨金を獲得された方につきましても、こちらの公式アカウントにてつぶやいていく予定です。

バグハンター合宿

ご要望を多くいただいておりますので、今年の秋頃の開催を目指し検討を進めております。詳細は未定となっておりますが今しばらくお待ち下さい。

今後の活動について

今年の 1 月から Cy-PSIRT は、プロダクトセキュリティを担当するチームと社内のセキュリティ対策を行うチームを編成しました。よりセキュアに、そしてフットワーク軽く活動することを目標にしています。引き続きたくさんの脆弱性報告をお寄せいただけると幸いです。 報奨金制度に限らず「サイボウズにこんな企画してほしい」という要望がございましたら、 productsecurity@cybozu.co.jp までお気軽にご連絡ください。

よろしくお願いします。

脆弱性報奨金制度 | サイボウズ株式会社

 

プロジェクト引き継ぎのベストプラクティス、そしてアンチパターン

あじさいがきれいですね。そんなことを可愛い女の子に言ってみたい。

どうも!アプリ基盤チームの@yokotasoです。

唐突ですが、プロジェクトの引き継ぎはうまく行っていますか?

プロジェクトの引き継ぎを経験すると、「あのとき聞いておけばよかった…」経験あると思います。

社内でためた引き継ぎの知見を公開します!どうぞ!

開発のハードルを下げるための引き継ぎ

開発環境をコンテナ化する

人の移動が多くないプロジェクトでは、開発環境構築のドキュメントが長い間メンテナンスされないことがあります。 この手のプロジェクトを引き継ぐことになったら、最初に検討すべきは開発環境のコンテナ化です。

コンテナの内部でできるだけ作業が完結するように、依存するライブラリやパッケージはすべてコンテナの中に収めましょう。 動作確認もWebサービスであればコンテナ内にWebブラウザーをインストールし作業がコンテナ内で完結することを目指します。

コンテナ化すると嬉しいこと

  • 他の開発メンバーも参加しやすくなる
  • コンテナ化すれば、環境をコードで表すことができ、利用者がパッチを投げてくれる
  • 既存の開発環境を汚染しない

利用ライブラリのバックアップを忘れずに

開発時に必要なものはダウンロード可能な状態を維持するために、バックアップをしておきましょう。 本家のレポジトリが突然消えたりなど、なんらかのアクシデントでアーカイブがダウンロード不能になったりすることがあります。

CIシステムの引き継ぎ

CIシステムに関する引き継ぎもしましょう。スムーズにリリースできる仕組みを維持していく必要があります。

CIシステムが、突然動かなくなる可能性はあります。

  • CIシステムが不安定になるときの特徴、対処方法などを引き継ぎましょう。
  • 時間があるときに根本的な原因の究明を行うようにしましょう。

「いつか成功する」は圧倒的アンチパターンなので、撲滅していきましょう

問題の解決が難しい場合、監視など問題の発生に早く気付けるような仕組みを構築するのもよいでしょう。 CIシステム自体の問題に早く気付けるようになることで、問題の切り分けが容易になり調査のストレスを減らせます。

できるだけCI環境を停止するのはやめましょう。CIを復旧するのにそれ相応のストレスが伴います。

外部サービス連携の引き継ぎ

外部サービスの認証情報の切り替え

開発で利用している外部サービスの認証情報は、前任者がいるうちに利用しているアクセストークンの入れ替えなどを行っておきます。 前任者の退職に伴いアクセストークンの有効期限切れになり、連携している外部サービスがうまく動かなくなることがよくあります

引き継ぎ失敗あるある

  • 引き継ぎ完了後、JenkinsからGitHubのCommit StatusのAPIの実行に失敗する
  • テストは成功するが、Git Hubのステータス更新がされない
  • Git Hubのアクセストークンの更新を忘れていた

アクセストークンが有効なうちはPull Requestからアクセストークンの発行主を確認することができるので確認しておきましょう

f:id:cybozuinsideout:20170621115619p:plain

APNs の証明書の発行フローを確認する

Push通知を利用している場合、証明書の更新が1年に1回程度は必要になります(JWTを用いた認証方式を除く)。 証明書の更新が要求される外部サービスはかならず引き継ぐようにしましょう。

証明書管理のベストプラクティス

  • プロジェクトメンバーが複数人、証明書にアクセスできる状態を作る
  • 証明書の期限切れを3ヶ月ほど前にチームに対してリマインドする
  • 証明書の更新を優先度の高いタスクとして登録する

f:id:cybozuinsideout:20170621145909p:plain 弊社ではグループウェアのスケジュール上にリマインド予定を登録しています

開発者用アカウントの整備

Facebook,Twitterなど外部サービスと連携する場合は開発者用アカウントを整備しましょう。動作確認用に必要なアカウントを用意しましょう。 外部連携サービスの動作確認のハードルを下げることができます。

チームで共通アカウントを利用する場合は、どこかで一元管理すると良いでしょう。

共通アカウント管理のルールの例

  • 開発者用アカウントにアクセスできるのは、アクセス権をもつチームメンバーのみ
  • 情報システム部にパスワードを定期的に変更するリマインドをしてもらうルールを作る

外部連携APIのメンテナンス

「Facebookでログイン」など外部サービスのAPIと連携している場合、APIの期限切れに警戒しましょう。期限切れの半年前などにリマインドを設定しておくと安心です。 特にFacebookAPIは、APIの賞味期限が短いです。新しいversionが頻繁にリリースされていきます。

外部連携APIについてドキュメント化する

  • 利用APIを明記する
  • 動作確認方法を明記
  • 利用APIの期限切れをチームに対してリマインドする

バッチ処理などでFacebook APIを使うと、動作確認ミスが起きやすくなります。このあたりは注意が必要です

version無指定のAPI利用はアンチパターン

Facebook APIではversionを指定しない利用方法もあります。この場合、利用可能なAPIのうち一番古いversionのAPIが利用されることになります。 一見、便利な機能です。Facebookからも警告が届きます。ですが、version無指定が常態化するとFacebookの警告は、無視するようになるでしょう。 Facebook APIの仕様変更に気付けずログインができないなどの致命的なバグに繋がります。

version指定をしてAPIを利用しましょう

ライブラリへの独自パッチの適用を引き継ぎ

f:id:cybozuinsideout:20170621133108p:plain

レガシーなプログラムほど、既存のライブラリでは要求を満たすことができず、独自パッチが適用されていることが多いです。 ハックはビジネス的な価値を提供する一方で、メンテナンス性を悪化させます。

引き継ぎの担当者は独自改修の存在に気付けるようになっているでしょうか?レガシー・ブラウザ対応のための独自パッチは未だに必要でしょうか?

  • 独自パッチを適用するときは、適用した理由と箇所、ビジネス的な価値を必ずドキュメント化する
  • 止むを得ず独自パッチを適用しているときは、ライブラリのアップデート時にハックが外せないかを調査する
  • ビジネス的な価値を失った不要な独自パッチはは積極的にもとに戻す

サービス運用にまつわる引き継ぎ

メトリクスの共有

サービスに障害が発生している時にいつも見ているメトリクスは共有しておきましょう。 メトリクスがなければ、障害が発生しても何がおきているのか、わかりません。

メトリクスにあわせて、障害が発生するときの特徴的な負荷状況を共有しておきましょう。

いつも見るメトリクスに加えて、過去の障害のときの原因となったメトリクスも確認できるように、ダッシュボードをカスタマイズしていきましょう f:id:cybozuinsideout:20170621134840p:plain

無視しているアラートの共有

開発に注力するあまり運用やメンテナンスに力を避けていないプロダクトの場合、監視システムからのアラートを無視している可能性があります。 無視する正当な理由があることもあるので、無視しているアラートと理由、(わかっていれば)原因の共有を必ずしましょう。

新年度の切り替わり時などに発生する定期的な警告で無視しているアラートは必ず共有してください。 この引き継ぎをしないと新しい担当者が定期的な障害が発生した時に運用チームから問い合わせを受けても右往左往するしかありません。

稟議が要求されるタスクは作業手順書を作成する

運用チームが顧客情報を見せないなどのためににログ閲覧に制限を設けている場合があります。 ログを取得するために稟議を申請する必要があるときは、作業手順書を用意して後々の作業の負担を減らしましょう。

探求はつづく

プロジェクトの引き継ぎに関するベストプラクティスとアンチパターンを紹介しました。

未発掘のよいプラクティスがあると思うので、要探求です!「こんなのあるよ!」という方はコメントでぜひ教えてください!

プログラムが生み出してくれた価値に感謝することを常に忘れず、プログラムを愛でたいものですね。チャオ!

 

「サイボウズにスクラムを導入した話」を肴にミートアップ!

こんにちは、コネクト支援チームの風穴(かざあな)です。

早いもので、2017年の半分が過ぎようとしていますが、皆さん、進捗はいかがですか?(笑) それはさておき、今回は、5月30日に開催した「Cybozu Meetup #4 スクラム」についてレポートします。

f:id:cybozuinsideout:20170612173645j:plain

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

2017年2月からスタートしたこの企画も、今回で4回目となりました。

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

今のところ、東京オフィスで月1回、大阪オフィスで数カ月に1回のペースで、開催していこうと考えています。毎回テーマを設定していて、これまで「フロントエンド」、「SRE」(Site Reliability Engineering)、「生産性向上」というネタで開催してきました。

サイボウズのスクラム/アジャイル

第4回のテーマは「スクラム/アジャイル」。

サイボウズでは、1年ほど前から、開発チームへのスクラム導入を本格的に進めています。その旗振り役となっている、kintone開発チームリーダーの天野 祐介(@ama_ch)が、

  • スクラム導入前に抱えていた課題
  • スクラム導入の経緯
  • 導入期の試行錯誤
  • 現在のやり方

について発表しました。

f:id:cybozuinsideout:20170612173720j:plain

公開したスライドからは除いてますが、当日のトークセッションでは、公開できない 生々しい 情報(=撮影禁止)もお見せしながら、サイボウズのこれまでの取り組みについて、お話しさせていただきました。こういうところは「ライブならでは」ですので、ご興味がありましたら、ぜひ一度、Cybozu Meetupに足をお運び頂ければ。

質問&交流タイム

トークセッションの後の交流タイムでは、スクラムを導入している開発チームのエンジニアや一般社員も参加し、スクラム話に花が咲きました。

f:id:cybozuinsideout:20170612173757j:plain f:id:cybozuinsideout:20170612173836j:plain

サイボウズでは、今後も開発チームへのスクラム導入を積極的に進めていくことになっており、スクラムマスターとして活躍してくださる方を大募集しています。詳細は、以下のWantedlyのページをご覧ください。

求む、スクラムマスター! 開発をさらに加速させるチャレンジ

7月以降も、毎月開催を予定しています。ご興味ある方は、connpassグループ「Cybozu Inside Out」をフォローして、情報をチェック頂ければ。

ではまた。