チーム内でJIRAを使ったペアプロ大会の企画をやった話

はじめに

これは DeNA Advent Calendar 2018 その2 の 19 日目の記事です。

はじめまして、FINAL FANTASY Record Keeper(FFRK)チームの今江です。現在は、FFRKチーム内の新機能開発チームでリードエンジニアを務めています。 FFRKは、2018年時点で4周年を迎えた長寿タイトルで、チームの規模も大きいプロジェクトとなっています。当然エンジニアの人数も多く、多数のエンジニアが日々開発を行なっています。

今回は、FFRKチーム内で行なったJIRAを使ったペアプロ大会の企画に関して紹介できればと思います。 この企画はペアプログラミングによるエンジニアの交流・成長の機会の提供や、着手されずに放置されているタスクを解決しつつ、チームの文化を醸成する目的がありました。同様の問題を抱えている方の参考になると幸いです。

JIRAとは?

JIRAとは、チケット管理型のプロジェクト管理ツールです。あらゆるタスクが「チケット」として管理され、進捗/タスク/アサイン管理など、プロジェクトの見える化に一役買っています。 FFRKチームでは、JIRAを使ったチケット駆動開発でプロジェクト開発を行なっています。

jiracon.000.png

企画の背景

FFRKチームでは、チーム内のエンジニアが集まる定例「エンジニア定例」という場があります。 エンジニア定例は普段は各チームの情報共有で終わっているのですが、せっかく定期的にやっているので、普段やらないような新しい取り組みをやったり、日頃感じているがなかなか解消できていない課題を解決したいという話題が上がっていました。

で、何かしらの取り組みをする上で、あがった要望が以下です。

  • みんな、ペアプロとかしたいって言ってる
  • JIRAが溜まっている
  • 業務とかに活きることやりたいよね
  • ゲームの改善にできるだけ工数を使いたい/繋げたい
  • チームビルディングは大事だよね。

「お、モリモリの要件やん。」ということで、しばらくネタを考えて思いついたのが、 今回紹介するチーム内のJIRAを使ったペアプロ大会 「JIRACON 2018」です。

JIRACON 2018

「JIRACON 2018」は、FFRK内の「業務効率化や既存の不具合などに関するJIRA」を題材にしたペアプロ大会です。

  • 概要
    • 1チーム3人で、JIRAをたくさんやったチームが優勝
    • どの程度「やった」かで点数がもらえて、一番点数が多かったチームが優勝
    • 出題するJIRAは、FFRK内のJIRAから適当に選出されたJIRA群
  • ルール
    • 時間: 1時間
    • チームのPC: 1台(コードを触れるPC)
    • チーム内容: リーダー1人 + メンバー2人

ざっと、こんなルールだったのですが、「やった」という基準は以下のように設定しました。

  • やったの定義
    • JIRAに調査結果を記入 1点
    • JIRAに解決策を書く 3点
    • JIRAの修正PRを作る 10点

ルールとして、何かしらJIRAに対して解決に繋がる取り組みを行うと、点数がもらえる方式を取っています。

取り組みの意図

企画の詳細を詰める中で、最終的にJIRACONの目的は以下のように整理しました。

  • 主目的
    • 互いの作業 (調査、コーディング、etc.) を見ることで、相互に良いところを吸収しあい、今後の業務に生かす
    • 今回で「JIRAをサクッと解決する」という感覚をつかみ、今後もすぐに解決できるものは溜めずに解決していく習慣づけの端緒にする
    • 限られた時間の中で調査や解決策の検討を行うことで、調査力や問題解決力の向上を図る
  • 副目的
    • 日頃触れない領域のコードに触れる
    • 溜まっているJIRAの数を少しでも減らす
    • エンジニア間の交流

この目的に沿って、JIRACONを進めるように詳細を詰めて行きました。

当日の流れ

JIRACONの当日の流れについて、説明します。

スケジュール

当日の進行スケジュールです。

  • 15:00 : ルール説明
  • 15:05 : 出題JIRAの公開
  • 15:05-15:55 コンテスト時間「50分」
  • 16:00 : 終了

※ 結果は、次回のエンジニア定例で発表

最初にルール説明を行い、またこのタイミングで再度JIRACONの目的を説明し、目的を踏まえて取り組んでもらうような流れを取っています。

jiracon.png

コンテスト中の流れ

JIRACONは、以下のような流れに沿って取り組みます。

jiracon.001.png

時間になると、JIRACONのWebページから問題一覧のページにアクセスできるようになるので、 各チームごとにJIRAを精査しJIRAに取り組みます。

SECCONなどのイメージが近かったので、専用のページをGoogle Sitesで作成しています。

jiracon.002.png

それっぽいWebページがサクッと作れたので、ちょっとしたWebページ作成におすすめです(サーバも用意する必要がない)。

全体のシステム構成としては以下のような感じです。

jiracon.003.png

(ほぼGoogleですね) あとは、採点を自動化できなかったので、ここはやむなしという感じです。

JIRAの一覧ページはこんな感じです。

jiracon.004.png

やってみてどうだったか?

最後にJIRACONを開催してみての振り返りを含めて、アンケートの結果を紹介できればと思います。 それぞれ、「取り組みの意図」で説明した3つの目的に関してのアンケートを取っています。

1. 互いの作業を見たことで、今後の業務に活かせそうか?

jiracon.005.png

一つ目の目的だった

互いの作業 (調査、コーディング、etc.) を見ることで、相互に良いところを吸収しあい、今後の業務に生かす

に関しては、綺麗に3分割されました。基本3人チームなので、役割ごとに意見が別れたようでした。 定性的なアンケートを結果を見た所、

  • 時間的な制約で、他の人の効率のいい面を見る余裕がなかった
  • 点数など競技性があったことで、個々が得点を取るための動きをしてしまっていた
  • どういうところで困っているのか/分からないのかを見れてよかった
  • 単純にスキルを吸収してもらう方へ力を入れたので、自身の得るものはなかった
  • いつも触らない領域を触って知見が広がった、業務に活きそう

傾向としては、時間的な猶予が厳しかった人、他人に吸収してもらう役回りだった人が低評価で、 競技性が合っていた人や、教えてもらう/見る側の人は目的を果たせたという結果でした。

2. JIRA解決の敷居が下がったか?

jiracon.006.png

二つ目の目的は、

今回で「JIRAをサクッと解決する」という感覚をつかみ、今後もすぐに解決できるものは溜めずに解決していく習慣づけの端緒にする

に関しては、全体的にJIRA解決の敷居は下がったという結果になりました。 代わりに、自分から能動的に動く習慣が付いたかという意識改革までには至らない結果になりました。

また、最終的に、総計 「21件」のJIRAが解決されていましたので、JIRA解決という副目的もそれなりに満たされた結果になりました。 入賞ラインのチームは、「17点、13点、12点」といずれも、修正PR 10点を1つ以上は出していました。

3. 限られた時間の中で、調査力や問題解決力の向上が感じられたか?

jiracon.007.png

最後の目的に関しては、1つ目のアンケートでも出ていましたが、時間的な制約がネックになっているという結果でした。 調査力・問題解決力が微増、全体的にポジネガが半々という状態でした。

ただ、時間に関しては「1時間では短いが、2時間だとダレそう」という意見があったので、単純に伸ばせばよかったとは言えない感じでした。

まとめ

最後に、JIRACONという取り組みをやってみた、まとめになります。

JIRAというプロジェクト管理ツールを使って、ペアプロ大会をやってみました。 互いの作業を見ながら、相互に刺激をもらえる機会を作ることができました。 また、チーム内に溜まったJIRA解決の敷居を下げつつ、ゲームの改善に繋がるような取り組みを行いました。

  • 主目的
    1. 互いの作業 (調査、コーディング、etc.) を見ることで、相互に良いところを吸収しあい、今後の業務に生かす
      • → 人の作業風景が見れてよかった or 余裕がなかった
    2. 今回で「JIRAをサクッと解決する」という感覚をつかみ、今後もすぐに解決できるものは溜めずに解決していく習慣づけの端緒にする
      • → JIRA解決の敷居は下がったが、マインド改革までには至らない
    3. 限られた時間の中で調査や解決策の検討を行うことで、調査力や問題解決力の向上を図る
      • → 一部の人には効果があったが、限られた時間だとその余裕が作りづらい
  • 副目的
    • 日頃触れない領域のコードに触れる → 人によってはあった
    • 溜まっているJIRAの数を少しでも減らす → 21件のJIRA解決
    • エンジニア間の交流 → まぁなったかなと

今後の展望

上記踏まえて、今後似た企画を行う場合のアイデアとしては、以下のようなことを考えています。

  • 時間的な制約がネックになったので、競技性のない取り組み
  • 普段関わりのある人で固めてチームを組んだので、チームを跨いだ交流の場
  • スタートから実装に取りかかれるような企画
  • 簡単なゲームを1から作る企画

JIRACONは競技性が高かったので、ゆとりを持って他人の作業を見ることに注力しやすい企画だったり、調査が必要なくやることが明確な手を動かせる企画が良いのではと考えています。

以上、FFRKチーム内で行なったJIRAを使ったペアプロ大会「JIRACON」に関して紹介してきました。 チケット駆動開発を行なっているチームがいれば参考にしていただければと思います。

jiracon.008.png

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA Engineers' Blogをリニューアルしている話

@mazgiです。
これはDeNA Advent Calendar 2018の3日目の記事です。

せっかく社のBlogを書くことになったので社のBlogリニューアルについてご紹介します。 今日2018/12/03現在みえているこのBlogのリニューアルを「Engineers' Blog編集委員会(仮)」という有志の横断的な組織で進めていてだいぶ形になってきました。
(Advent Calendarには間に合いませんでした)

きっとこんな見た目になります!
we-just-building-new-dena-engineers-blog.screenshot.png

技術Blogやオウンドメディアの長期運用あるあるな話としてどなたかのご参考になればという気持ちで書かせていただきます。

なぜリニューアルするのか?

リニューアルする理由をざっと書き出すと次の3点です。

  • もっと活性化してほしい
  • 機能追加やシステム更新がつらくなってきた
  • オンプレミスでのセルフホスティングをやめたい

順にご説明します。

もっと活性化してほしい

今のこのBlogはMovable Type製なのですが、全社員にアカウントが払い出されているわけではなく、初めて記事を書くときにBlog専用アカウントを申請する運用になっています。
また書いてから公開されるまでのフローは整備されてはいるのですが当事者以外からはなかなか知ることができず、その結果新たに「Blogを書いてみようかな」と思ったときに「どうやって書くんだろう?」「どういう内容ならOKなんだろう?」「誰にレビューお願いすればいいんだろう?」といった疑問が心理的障壁になっていることがわかりました。

これを解消するため前述の「Engineers' Blog編集委員会」で「もっと気負わず思いついた時に誰でも記事を書けるようにしたい!」と話し合いました。

機能追加やシステム更新がつらくなってきた

DeNAは元々腕利きのPerl Mongerな方々が集まっていた会社でもありこのBlogのシステムは2010年頃にMovable Typeで構築されたようです。
ところでDeNAは来年2019年で20周年だそうです。IT企業として20年、すごいですね!老舗ですね!
この機会に技術Blogもシステム刷新してもいいのではないでしょうか?

前述の活性化を行うにしてもイマドキな方が色んな方に書いていただけそうですし、長く運用できそうです。
Blog編集委員会では「新し目で運用負荷低い仕組みを目指しましょう」と話し合いました。

オンプレミスでのセルフホスティングをやめたい

20世紀からWebサービスを作っておられる多くの会社がそうだと思いますが、DeNAもオンプレミスとパブリッククラウドを併用している会社です。
しかしこの度パブリッククラウドに完全移行することが決まりました :tada:
ところで2010年頃に構築されたBlogのサーバーは? ...オンプレミスです。移行しましょう!

編集委員会でも「パブリッククラウド上でサービスするのは当然としてインスタンス立てたくないね」と話し合いました。

ちなみに全社インフラのクラウド移行については弊社オウンドメディア@ITでも記事にしていただいていますのでご参照ください。
また、2019年2月のTechConでも紹介される予定ですのでこちらもぜひご参加ください。

どうやってリニューアルを進めているか?

先ほど上がった理由をブレイクダウンし、それぞれの課題を解決する方法を考えていきます。

どうやってもっと活性化しやすくするか?

まず、Blogシステムの概観をどうすれば活性化しやすいくなりそうか話し合いました。

世の中には色々な素晴らしいBlogサービスやCMSが存在することも改めて確認し、同時にエンジニアリングやデザインのリソースが少し取れそうだったので自前実装という道も生まれました。
これらの状況を加味した上で自由度とセキュリティ担保や今後の運用とを秤にかけ「薄く自前実装しよう」という方針が決まりました。

それが今の私たちにとって、システム面でも文化や雰囲気の面でも、もっともバランスの良い形に思えたのです。

まず"書きやすいシステム"にする

技術Blogの主なWriterとなるエンジニアが"書きやすいシステム"について考えた結果以下を決めました。

  • 普段使っているGitHub(Enterprise)に集約しよう
    • 記事内容はもちろん、記事執筆のフローもGitHub的にしよう
    • Pull Request -> Review && Merge -> CI/CD で記事が公開されるようにしよう
  • Markdownで書けるようにしよう
    • フォーマットの好みは色々あれどMarkdownは大抵の人が書いたことあるはず
  • 社内向けBlogを併設してもっと気軽に記事を書けるようにしよう

GitHubへの集約ですが、この画像のようなリポジトリのmasterにMarkdownで書かれた原稿がMergeされると公開されるようにしました。
(Private Repositoryですが全社員がメンバーとして設定されています)
we-just-building-new-dena-engineers-blog.0090.png

レビューは何かを開発するときと同じようにPull Request上で行えますが、Push毎にこのように記事をプレビューできる専用のURLが発行されます。
we-just-building-new-dena-engineers-blog.0050.png

このプレビュー用URLは社内から誰でも閲覧できるので例えば法務や広報といった、GitHubアカウントを持っていない方にもレビューに参加していただけます。

最後の「社内向けBlog」については、「『社名とともに世界に公開される』と考えると気後れしてしまうかもしれないけど、社内限定公開なら何書いても恥ずかしくないよね!」という気持ちで作ることにしました。

  • 「内容軽すぎない?」=>「1 tip(s)だけでも大丈夫です、社内限定公開なんで」
  • 「これ社外秘かも...」=>「社内の人が知ってて大丈夫なら書いて大丈夫です、社内限定公開なんで」
  • 「社内のあれこれ知らないと伝わらない」=>「読む人みんな知ってるので書いてください、社内限定公開なんで」

という感じで記事を書くハードル下げられるといいな!と思ってます。
社内向けBlogも公開Blogもリポジトリが異なるだけで仕組みや原稿フォーマットは一緒なので、社内限定記事を公開記事に変換する時はリポジトリ間でファイルをコピーするだけです。
社外秘な社内限定記事は後日社外秘じゃなくなるように編集して公開すればいいですし、社内知識が前提となっている社内限定記事は先に社内知識を説明する記事を公開すればいいですよね!

"書きやすい雰囲気"にする

DeNAで掲げている「DeNA Quality」の1つに「透明性」があります。
言葉通り「正直でオープンなコミュニケーション」を是とするいたって真っ当な姿勢なのですが、今回の一連のBlogリニューアルの動きとしてもこの「透明性」を強く意識しています。

リソースのほとんどはGitHubに集約され、全社員がアクセスできます。
we-just-building-new-dena-engineers-blog.0030.png

タスク一覧や進捗はGitHub Projects(カンバン)上で公開されており、自由にカードやIssueを作ることができます。
we-just-building-new-dena-engineers-blog.0040.png

SlackでのやりとりもPublic Channel上で行われ、
we-just-building-new-dena-engineers-blog.0080.png そのままでは流れ去ってしまうSlackコメントは必要に応じてGitHubのIssueコメントとして蓄積されます。
we-just-building-new-dena-engineers-blog.0081.png そしてGitHubでのコメントや色々なアクティビティはSlackのPublic Channelに通知されます。
we-just-building-new-dena-engineers-blog.0082.png

DeNAでは開発業務に従事していない方などGitHubアカウントを持っていない方もいるのですが、Slackアカウントは全員が持っているので、誰でもこれらの情報にアクセスしコメントすることができます。

こうやって記事やレビュー内容だけに留まらず経緯までオープンかつ正直に残しておくことで、今だけではなく将来にわたって「あ、こんなカジュアルでいいんだ」と感じてもらえたらいいな!と思っています。

どうやって機能追加やシステム更新を行いやすくするか?

まずどんなシステムにしてどんなサービスを使ったところで、そのままではいずれ機能追加が行えなくなり更新がつらくなると考えています。
それはきっと避けられないのでしょう。

なのでせめて2018年に考えられる継続的にアップデート可能な"オープンな普通の仕組み"を作ろうと努めました。
具体的には以下のツールやサービスを組み合わせてBlogを構成しました。

HugoとTerraformはOSSですし、その他のXaaSはどれも有名で調べればすぐに情報が得られます。
また2030年くらいまでにはBlogのリニューアルが避けられなくなるかもしれませんが、むしろもっと短いイテレーションで頻繁にシステム構成自体を再考し更新し続けられたらうれしいですね!

パブリッククラウド上でどのような構成にするか?

今からオンプレミスのサーバーを新規構築しないのは当たり前として、Blog編集委員全員に「インスタンス立てたくない!」という強い気持ちがあり、サーバーを立てない前提で話が進みました。
これだけ色々なマネージドサービスが提供されている2018年にBlogのためにサーバーを運用するリソースはもったいないですね。
そのリソースはDeNAのサービスを使ってくださっている皆さまのためにもっと違う形で使いたいものです。

構成は前述の通りなのですが、それぞれ以下のような点を考慮しました。

Markdown

平易なテキストフォーマットなので他のシステムへの載せ替えも容易。

Hugo

Apache 2ライセンスのOSSでライセンス上の検討事項が少ない。
Golang製でバイナリファイル1つで動く。バイナリさえ保持しておけば先々「本体は入手できてもライブラリが入手できない」といった事態を避けられる。

GitHub Enterprise / CircleCI Enterprise

DeNA内で標準的に利用されており世間的にもデファクトスタンダードと言える。

Terraform

MPL 2ライセンスのOSS。
Hugo同様Golang製でバイナリファイルといくつかのモジュールだけあれば動く。
IaCのとても著名なツールと言え情報も多い。

AWSの各リソース

AWS自体はいうまでもなく世界有数のクラウドサービスプロバイダで情報が大変多い。
もちろんDeNA内でも広く使われている。

Blog閲覧時のアクセス経路は、公開/社内向けそれぞれ以下の通り。

公開Blog: Browser -> CloudFront -> S3
社内向けBlog: Browser -> CloudFront -> WAF -> S3

更新時はCircleCI上でHugoにより生成されたHTML, CSS, JavaScriptなどをS3にアップロードしている。

さいごに

いちばん最初に載せさせていただいたかっこいいBlogテーマはデザイン担当の方が作ってくださいました!
(かっこいいので再掲)
we-just-building-new-dena-engineers-blog.screenshot.png

Blogリニューアルの初期は仮テーマということにして私が作ったテーマで実装してたんですけど、見比べていただけるとどれくらいかっこよくしていただいたかわかると思います(

そして残タスクはデータ移行。。
どんなシステム刷新も最後に残るのはデータ移行ですね。
完全な自動マイグレーションは難しそうなので今色々とディスカッションしてます。
we-just-building-new-dena-engineers-blog.0010.png

DeNA「Engineers' Blog編集委員会(仮)」ではこのように技術Blogのリニューアルを検討中です :muscle:
Slackでコミュニケーション取ったり、
we-just-building-new-dena-engineers-blog.0020.png 意見はフィードバックいただいたり、
we-just-building-new-dena-engineers-blog.0070.png we-just-building-new-dena-engineers-blog.0060.png オフラインで集まったり、 we-just-building-new-dena-engineers-blog.0100.jpeg

進めていますので次は「リニューアルしました!」とご報告できることを楽しみにしています。

続きを読む
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る