Raccoon Tech Blog [株式会社ラクーン 技術戦略部ブログ]

株式会社ラクーン 技術戦略部より、tipsやノウハウなど技術的な話題を発信いたします。

第3回技術部LT大会 開催

こんにちは、たむらです。

先日第3回技術部LT大会を開催しました。
昨年から部内研修として開催しているLT大会ですが、今回も個性溢れるテーマが取り上げられました。普段あまり接点のない部内メンバーの業務内容も伺えるものになっていて、メンバー間の相互理解にも一役買いそうな内容になっています。今回のLT大会では今年の新人が早速発表したり、来年度の内定者を招いたりと賑やかなイベントとなりました。

~発表されたLTタイトル~
「はじめてのSOAPへGo」
「NetBeansのプロファイラを使ってみた」
「PowerShellを使ってみた」
「ピュアSQLで数独を解いてみた」
「fumiのマスコットを作ってみた」
「「クエストフェーズ解決ミニアプリ」ではなぜRIot.jsを採用したか?」
「オラクルマスター12Cのブロンズを受験する為の基礎の参考書を読んでみた」
「あのAmazonも使っているApache FOPで請求書を作る」
「SDのSVNをGit&GitHubに移行したい件」
「ぼくと
の100日戦争」
「backlog APIとWebhookを使った家庭内タスク管理」
「ラクーンに入社して」
「俺のオンラインストレージ ~ ownCloud on AWS ~」

LT大会の様子
DSC_0796
DSC_0806
DSC_0814
DSC_0803

今回の結果は、
1位:「ぼくと○○○の100日戦争」
2位:「ピュアSQLで数独を解いてみた」
3位:「NetBeansのプロファイラを使ってみた」
となりました。

1位のネタは、スピーカーのエンジニアが、とあるスマホゲーム攻略アプリを作った際に実際に起きたエピソードで、会社オフィシャルの当Blogにはちょっと詳細を書けない様な内容でした(笑)。ただ、誰もが知っているスマホゲームで内容も技術的な知見を含むリアリティのあるトークだったことから、ダントツの1位となりました。
2位は「数独問題をバインド変数でインプットデータとして与えると、答えを返してくれるSQL」を作成するという、ちょっと宇宙人的な発想と超人的なSQLスキルを持ったスピーカーならではと言える内容でした。

次の開催は来年の1月頃を考えていますが、段々レベルが上がってきているので次回も楽しみです。

『レジスタンス:アヴァロン』を遊びやすくするDIY

開発の松尾です。
テックブログのネタを要求されたので、色々と考えてみまして、弊社が運営しているサービスとは全く関係のない、最近社内でランチタイムに遊んでいる人狼型カードゲーム『レジスタンス:アヴァロン』を遊びやすくするための、ちょっとしたDIYについて書いてみることにしました。

『レジスタンス:アヴァロン』とは

20150824_1
『レジスタンス:アヴァロン』は2013年にホビージャパンより日本語版が発売された、人狼系正体秘匿型推理ゲームです。ゲームマスターのような中立な立場のプレイヤーが必要ない、手軽な人狼系カードゲームといったところでしょうか。「アーサー王伝説」を下敷きにしたファンタジーな雰囲気がお気に入りです。

ゲームのルールがわからないと、後段で紹介するちっちゃなアプリたちが意味不明過ぎるシロモノに見えてしまうので、ゲーム内容とルールについて解説してみましょう。

『レジスタンス:アヴァロン』は5人~10人のプレイヤーで遊ぶことができるカードゲームです。経験上7,8人で遊ぶのが一番バランスがとれていて楽しいと思います。また、面白い特徴として参加人数の多寡によらず1ゲームがおよそ30分程度で決着します。昼休みにお弁当をつつきつつ気軽にプレイできるところが嬉しいですね。

20150824_2
最もオーソドックスに5人でプレイする場合は、画像に見える5枚のキャラクターカードを使用します。青いマークがアーサー王側のキャラクターであることを、赤いマークはモードレッド側のキャラクターであることを示しています。これらのキャラクターカードをシャッフルしてプレイヤーに一枚づつ配ります。各々のプレイヤーは原則として誰がどのキャラクターであるかは分からない状態でゲームを開始します。プレイヤーは自分に割り当てられたキャラクターが示す陣営に属し、その陣営の勝利条件を目指します。アーサー王側のキャラクターであれば各クエストを成功させることを目指し、モードレッド側のキャラクターであればアーサー王側に属するフリをしながら各クエストを失敗させるために頑張ります。

20150824_3
クエストと言っても内容は単純です。この画像はプレイヤーが5人の場合のクエストシートですが、「2、3、2、3、3」と並んでいるところが各クエストに参加するプレイヤーの人数を表しています。第1クエストの数字は「2」になっているので、5人で討議しつつ2人のプレイヤーを選出しなければなりません。クエストに参加するプレイヤーを選出するのはリーダー権を持つプレイヤーです。ゲーム開始時のリーダー権はジャンケンかなにかで任意のプレイヤーに付与し、そのプレイヤーの位置から時計回りに移動していきます。

20150824_4
リーダー権を持つプレイヤーがクエストに参加するメンバーを提案したら、プレイヤー全員による投票を行います。各々のプレイヤーが投票トークンを伏せて提出し、過半数強の承認が得られればクエストフェイズに移ります。5人プレイでは3人以上の承認が、6人プレイでは4人以上の承認が必要になります。また、提案が却下されるとリーダー権が次のプレイヤーに移動します。提案の却下が5回続くと自動的にアーサー王側陣営の敗北が決定します。クエストシートの投票トラックは提案が却下される度に数字を進めて、今が何度目の投票であるかを示しています。

※ちなみにラクーンのメンバーで遊んでいるときは、面倒くさいという理由もあって投票トークンは使わずに、承認の場合は一斉に挙手という手法を採用しています。「いっせぇーのっ、せっ」って感じで。

20150824_5
クエストに参加するプレイヤーが決定したらクエストフェーズに入ります。クエストに参加するプレイヤーは、任務を成功させるか、はたまた失敗させるかをカードで提出します。任務カードに各々の陣営のアイコンがあるように、アーサー王側のプレイヤーであれば絶対に「任務成功」のカードしか提出できません。しかし、モードレッド側のプレイヤーであれば、自身がモードレッド側であることを隠すために、あえて「任務成功」のカードを選択する自由があります。内容を隠して提出されたカードをシャッフルし一斉にオープンします。全ての任務カードが「任務成功」であれば、そのクエストではアーサー王側の勝利です。しかし、ひとつでも「任務失敗」が混じっていればそのクエストはモードレッド側の勝利となります。
※プレイヤーが7人以上になると「任務失敗」が2枚提出されないとアーサー王側の勝利となる特殊なクエストも存在します。
このように第1クエスト、第2クエストとゲームを進めていく中で、先に3回目的を達成した陣営が勝利します。誰が味方で誰が敵なのか、疑心暗鬼にかられつつ自分の陣営の勝利のために考え抜き議論していくのが、このゲームのもっとも面白いところです。
とは言え、全てのプレイヤーが他のプレイヤーについて情報をまったく知らないままだと単に運否天賦なゲームになってしまいます。人狼ゲームに特殊な能力を備えた役職があるように、『レジスタンス:アヴァロン』では特定のキャラクターに付与された能力が存在し、その能力によってゲーム開始時点の情報量に差をつけます。
それぞれの主要なキャラクターの能力は以下のように分かれます。

マーリン(アーサー王側)

  • 能力:ゲーム開始時点にモードレッドの手下をすべて知ることができる。
  • 戦略:アーサー王側が勝利を飾っても、モードレッド側の「暗殺者」にマーリンであることを見ぬかれると逆転負けになるルールがあるため、身分がバレないように行動しつつ、うまくアーサー王陣営を勝利に導く。

アーサーの忠実なる家来(アーサー王側)

  • 能力:なし
  • 戦略:敵も味方もさっぱり分からない状態で開始。疑心暗鬼に負けず知力を尽くす。

モードレッドの手下(モードレッド側)

  • 能力:ゲーム開始時点で味方がどのプレイヤーなのかを知っている。
  • 戦略:モードレッド陣営であることがバレないようにしつつ、クエストに自分か仲間が含まれるように誘導する。

暗殺者(モードレッド側)

  • 能力:ゲーム開始時点で味方がどのプレイヤーなのかを知っている。また、アーサー王側が勝利した場合に、マーリンだと思われるプレイヤーを指名して正解すると暗殺によるモードレッド側の逆転勝ちになる。
  • 戦略:基本はモードレッドの手下と同様。しかし、負けた場合にマーリンを指名する責任があるため、誰がマーリンであるのかに常に気を配る必要がある。

何人でプレイした場合でも絶対に「マーリン」と「暗殺者」は含まれます。キャラクターがマーリンであれば、自分がマーリンとバレないように、時にはわざと任務を失敗させるなどのテクニックを駆使して、頑張って味方を勝利へ誘導しなければなりません。モードレッド側のキャラクターであれば、陣営は少数派ながら、味方が誰かはわかっていることを活かしつつ、アーサー王陣営に属しているフリをしながら、うまく任務を失敗させる必要があります。このようなキャラクターによる情報量の差がゲームに深みと戦略性を与えています。もっとも情報量の少ない「アーサーの忠実な家来」で疑心暗鬼にかられる中で知力を絞るも良し、何食わぬ顔でモードレッド陣営であることを隠しつつ任務の失敗に邁進するなど、ゲームのたびに自分の立ち位置や戦略ががらりと変わっていくのが『レジスタンス:アヴァロン』の醍醐味だといえるでしょう。

『レジスタンス:アヴァロン』を10倍遊びやすくするDIY

さて、こんな楽しい『レジスタンス:アヴァロン』ですが、ゲームマスターのいない人狼型ゲームであるという特性から、ゲームの開始時に少々やっかいな儀式が必要になります。具体的には、各々のキャラクターの情報量をコントロールするために、全員で目をつぶり、モードレッド陣営の味方の確認フェーズやマーリンによるモードレッドの手下確認フェーズを設けなければなりません。

以下は、ゲームのマニュアルより引用した、全員が目を閉じた状態で行うこの儀式を進行するためのセリフの例です。

「皆の者は目を閉じ、自分の手を握り拳にして前に差し出せ」

「モードレッドの手下は目を開き、周囲を確認してだれが邪悪のしもべであるか確認せよ」

「モードレッドの手下は目を閉じよ」

「すべてのプレイヤーは目を閉じ、自分の手を握り拳にせよ」

「モードレッドの手下は親指を立て、マーリンがお前らを知られるようにせよ」

(以下略)

キャラクターの能力による情報量の差を実現するためには、この儀式を正確に執り行う必要があります。

『レジスタンス:アヴァロン』で遊ぶようになった当初は、自分で買って持ってきた責任から、わたし自身が目をつぶりつつ、上記のようなセリフを唱えていたのですが、やはりセリフや順序を間違ってしまうことが多々ありました。せっかくプレイヤーにキャラクターを割り当てても、この儀式に不備があるとキャラクターのシャッフルからやり直さなければなりません。ゲームを何度か遊ぶうちに段々とこの手順が面倒くさくなってくるのはいかんともしがたいところでした。

そんな時に天啓のごとくひらめきました。

OSXってたぶん喋れたよな!?

『レジスタンス:アヴァロン』オープニングスクリプト on OSX

$ say "松尾です"

さっそくググってコマンド名を調べ、サブノートMacのコンソールからsayコマンドを叩いてみます。多少不自然なイントネーションながらも女性の声で「まつおです」とはっきり喋るではないですか!この仕組さえあればあとは一気呵成に書くのみ。

#!/bin/sh
STORM="storm.mp3"
THUNDER="thunder.mp3"

function effect() {
  if [ -f "$1" ]; then
    afplay "$1" -t $2
  else
    sleep $2
  fi
}

say "「レジスタンス:アヴァロン」を開始します"
sleep 2
say "みな、目を閉じ、拳を前に出せ"
effect $STORM 4
say "モードレットの手下は、目を開け"
sleep 1
say "モードレットの手下は、仲間を確認せよ"
effect $THUNDER 5
say "モードレットの手下は、目を閉じよ"
sleep 2
say "マーリンは、目を開け"
sleep 1
(以下略)

概略このようなシェルスクリプトを書いてざっくりとデバッグ。afplayコマンドを使えばmp3ファイルの再生も可能だとわかったので、無料素材サイトより拾ってきた効果音を鳴らして雰囲気を盛り上げる仕掛けも施しました。上記のスクリプトの先頭部にある、変数STORMやTHUNDERに入っているファイルが存在すればそれを効果音として指定した秒数で再生します。ファイルがなければないで単に無音でsleepするという単純な仕組みです。

『レジスタンス:アヴァロン』では「マーリン」や「暗殺者」以外にも、マーリンが誰なのかを知ることができる「パーシヴァル」、マーリンからモードレッド陣営だと見抜けない「モードレッド」など、任意で追加できる特殊なキャラクターがいます。そういったパターンに全部対応できるように仕上げたスクリプトの完成版はgistに置いています。環境変数で特殊キャラクターの有り無しをコントロールすることも考えましたが、面倒臭いのでやめました。このちょっと頭の悪そうなシェルスクリプトで完成版です。不要だったらコメントアウトすれば良いという方針です。セリフを変えたければスクリプト内の日本語をいじりましょう。必ずしもsayコマンドが日本語を正しく区切って読んでくれるわけではないので、変な読み方をされたら「、(句読点)」で区切るのがオススメです。

※ちなみに上記のスクリプトには、『レジスタンス:アヴァロン』の拡張版『湖の騎士』での追加キャラクター「ランスロット」を使った場合の選択ルールにも対応していますが、大抵の場合は不要なため「ランスロット」と書いてある行はコメントアウトしちゃいましょう。

『レジスタンス:アヴァロン』クエストフェーズ解決ミニアプリ

さてこのように、『レジスタンス:アヴァロン』の難儀なポイントがひとつ解決しました。昼休みのたびに持ちだされて、オープンニングスクリプトだけを喋らされるMacbook Airに多少の憐憫の情が湧きますが、標準状態のWindowsでは逆立ちしても真似ができない仕事をあっさりと実現できたわけですので、きっと故スティーブ・ジョブスも草葉の陰で喜んでいるのではないかと妄想しつつ、もうひとつ煩雑な手順があることに気づきました。

それは、クエストフェーズの投票と開票が非常にセンシティブな手順である、という問題です。

具体的には、仮に3人がクエストを実行する場合、3人にそれぞれ「成功」「失敗」の2枚組のカードを割り当てて、選択したカードを回収してシャッフルの後オープンします。結果として1枚「失敗」のカードが含まれていても、誰が出したのか分からないようにする必要があるからです。また、選択されなかったカードについても回収してシャッフルしなければなりません。誰がどのカードを残していたかは、どのカードを選択したかの裏の結果に過ぎないため、これら情報についても慎重に取り扱う必要があります。

この手順の実行には少々緊張感が漂います。仮に、誰かの選択したカードが見えてしまったら最後、その瞬間からゲームバランスが崩壊し、せっかく進行したゲームが途中で台無しになってしまいます。

と、このような悩みを解決するためにエンジニアの下田が作ったのが、HTML5+JSのみで作られた、えーっと名前は無いので適当につけると「クエストフェーズ解決ミニアプリ」です。
20150825_1
スマホからここにアクセスするだけで簡単に起動します。ソースコードはgistに置いてあります

とりあえずクエストフェーズに入ったらこの画面より「START」をタップします。

20150825_2
クエストの「成功(SUCCESS)」か「失敗(FAILURE)」のどちらかを選んでタップします。タップする指の位置で投票内容がバレないように、ボタンの上下はランダムに入れ替わるようになっています。(わたしが「指の位置でバレそう」と呟いていたら翌日実装されていました。きっと小人さんの仕業でしょう。)

20150825_3
投票が完了するとこのような画面が表示されます。クエストの投票を完了していないプレイヤーが残っていたら、このままの状態で次のプレイヤーにスマホを手渡します。「CONTINUE」をタップすると次のクエスト投票が続行され、すべてのプレイヤーが完了したら「OPEN」をタップしてクエストの結果を確認します。

20150825_4
「成功」が2人、「失敗」が1人という結果が出ました。残念なことにクエストは失敗です。3人のプレイヤーにモードレッド陣営の邪悪なキャラクターが混じっていた模様です。

と、このような感じのミニアプリを使うことで、慎重にカードを取り扱う必要のあったクエストフェーズの煩雑さが一気に解決してしまいました。文明の利器の最たるものである現代のスマホ上で、インターネット技術の重要な基盤であるHTML5を用いて、単なる計数機を作ってしまったような罪悪感をちょっぴり感じてしまうのですが、これもまた一種のIoTではなかろうかと強弁して逃げ切ることにします。

テーブルゲームのDIY万歳

このように『レジスタンス:アヴァロン』にハマったがゆえに、エンジニアの余技でDIYしてしまったという、誰得な記事を書いてしまいました。実際に他部署の人間と『レジスタンス:アヴァロン』を遊んだ時に、急にMacが喋り出したり、スマホでクエスト投票ができたりする様を見て、ちょっぴり引かれた空気を感じてしまい、落ち込んだりもするけど、私は元気です。

この内容が役に立ちそうな局面がほとんど思いつかないのですが、快適に『レジスタンス:アヴァロン』を遊んでみたいという奇特な方であれば喜んでいただけるのではないかと思っています。

それではみなさん、素敵なテーブルゲームライフを!


CORECを支える技術 ~チケット駆動編~

こんにちは。なべです。
CORECの開発を担当しています。
これから何回かに分けて、『CORECを支える技術』と題してCORECの開発について書いてみようかと思います。
今回はチケット管理と構成管理との連携についてCORECでの取り組みをご紹介したいと思います。
 
 
corec

毎週リリースのサイクルを維持するためのポイントは自動化

CORECは2014年3月17日に初回リリースをしてから、80回を超えるリリースを行っています。(2015年5月時点)
その内容は、機能追加からデザイン変更やバグフィックス、文言変更まで大小さまざまですが、ほぼ週1回のペースを守っています。それは、より早くフィードバックサイクルを回し、お客様に喜んでいただける機能の追加や改修をより早く届けたいと考えているからです。

このペースを維持するために、いくつかのツールを利用したりそれらを連携する仕組みを構築しています。
できるだけ自動化することによって生産性の向上ヒューマンエラーの極小化を目指します。
 

その一端を担うのがチケット管理と構成管理との連携です。
この仕組みがCORECの開発を飛躍的に安心・安全にしてくれます。

なぜ、チケット駆動開発と構成管理?

なぜ、チケット管理と構成管理が連携すると安心・安全になるのでしょうか?

「やった(ような気がする)」のヒューマンエラー

チケット駆動開発は、チケットが正しく完了しそれがリリースされる必要があります。
開発者にチケットを渡し、そのチケットの完了を各担当者に任せると、やはり人間ですからミスが発生することがあります。 たとえば、実装したつもりが実装していなかった、実装したがコミットせずにチケットを完了してしまった、といったことがあげられます。

チケットの対応確認は手間

ですので、管理する側はチケットの内容がリリースされるかどうかを確認する必要があります。
CORECでは構成管理からリリース対象を抽出してリリースするフローになっているので、 管理する側から見てリリースされるかどうかを確認する一番確実な方法は構成管理を確認することです。 しかし、手作業でチケットの一覧と構成管理のログを突き合わせて確認するのは、根気と注意力のいる作業です。 少なくとも私には無理です(^^;

だから、自動化!

そこで、構成管理から自動的に連携します。
構成管理にコミットされたことをチケットに反映することによって、チケット管理システムで対応状況を正確に把握できるようになります。 副次的な効果として、開発者側も対応してコミットしたものが自動的に”対応済み”に変わっていくとちょっとした達成感が得られるという心理的効果もあり、 、それが、コミットコメントにチケット番号を含める動機にもなるので、ログで対応内容が把握しやすくなりました。


使用しているツール

まずはどのようなツールを使用しているかを説明します。

  • Backlog(チケット管理)
  • git
  • jenkins

Backlog

CORECではすべてのタスクをチケット化します。
そのチケットの管理にはBacklogというWebサービスを利用しています。

このチケットに割り振られたチケット番号がすべてのキーになります。

git

構成管理はgitを利用しています。
社内で管理しているサーバー上にあります。
CORECでは単純にgitを使うのではなく、git-flow()というブランチモデルを利用しています。

git-flowブランチモデル

このgit-flowはCORECのスピードを保つ一つの大きな役割を果たしています。
本番(master)・開発(develop)のブランチをキレイに保ちつつ、本番で発生した問題に対応するブランチ(hotfix)、 日々の機能開発をするブランチ(feature)が適正に管理できる素晴らしい仕組みです。
この仕組とgitの的確なマージのおかげで開発者は同時に走っている他の開発のことをほとんど意識することなく自分のペースで開発を進めていくことができます。

※参考:『いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識』(http://www.atmarkit.co.jp/ait/articles/1311/18/news017.html)

gitのルール

git-flowを利用することでgitの使い方はおのずと決まってきますので、gitを使う上で決めているルールは以下の5点ほどです。

  • 開発作業はfeature/hotfixブランチで行うこと
  • feature/hotfixのブランチ名にはチケット番号を使用すること
  • コミットコメントにはチケット番号を含めること
  • finishは第三者が行うこと
  • developにマージするコードはテストが通るものであること

jenkins

皆さんご存知のCIツールです。 gitとBacklogの連携部分を担います。


連携の設定

corec-2015-06-006

featureがfinishされ、gitサーバーのdevelopにpushされると、git-hookからjenkinsのjobをキックしてビルドが開始します。
ビルドでは自動テストやメトリクスの取得など実施し、結果をIRCに通知します。
ビルドが成功した場合には、開発評価環境に自動的にデプロイします。
逆に失敗した場合にはBacklogに課題チケットが作成されるので他の開発者に冷ややかな目で見られることになります。

それでは実際の連携の方法を解説していきたいと思います。
すべて同じツールを利用していなくても、部分的にも利用できるところはあるかと思いますので、参考にしていただければと思います。

構成管理(git/git-hook)とジョブ管理(jenkins)

まずは構成管理が更新されたことをジョブ管理に通知します。

git(git-hook)側の設定

gitにはgit-hookというイベントトリガの仕組みが用意されています。
いろいろありますが、詳細はこちらを参照してください。
今回はpush後に呼ばれるpost-updateというトリガを利用します。
トリガを利用するには、gitリポジトリのルートパス以下のgithookフォルダにトリガの名称のファイルを置きます。
同じフォルダに.sampleファイルがあるのでリネームしてファイルを作成します。

[gitリポジトリのルートパス]/githook/post-update

例えば以下のようになります。この例ではブランチ名を取得してdevelopだったらjenkinsの”corec”jobをキックしています。

#!/bin/bash
BRANCH=$(git rev-parse --symbolic --abbrev-ref $1)
if [ "${BRANCH}" = "develop" ]; then
  curl http://[jenkins-host]/job/corec/build
fi

jenkinsのjobの実行にアクセス制限をしていない環境では、こんな簡単なcurlコマンド1行でjobを実行できます。

jenkins側の設定と認証付きの連携の設定

jenkinsのjobの実行にアクセス制限を設定する場合は以下の2つの方法があります。

  1. jenkinsそのものにユーザー認証をつける
  2. jobの実行にパスワードをかける

jenkinsそのものにユーザー認証をつけるには、jenkinsの Jenkinsの管理>グローバルセキュリティの設定から「セキュリティを有効化」して認証方法を選択・設定する必要があります。 その方法については、ここでは省略します。

以下、上記2つのアクセス制限を設定した場合のgit-hookとjenkinsの連携について説明します。

ユーザー認証情報(APIトークン)の取得方法

jenkinsそのものにユーザー認証をつけた場合、APIトークンが必要になります。
具体的には、APIトークンをパスワードとしてベーシック認証を行います。

  1. 実際にgitサーバーからアクセスするユーザでjenkinsにログインします。
  2. ヘッダーの右側にあるユーザ名のリンクをクリックすると、開発者というメニューが表示されます。
  3. 設定メニューをクリックします。
     
    corec-2015-06-002
     
  4. 右のペインに「APIトークン」のカテゴリが表示されます。
  5. APIトークンの表示をクリックすると、APIトークンが表示されるのでそれを控えておきます。
     
    corec-2015-06-003  
     
job実行の認証情報(認証トークン)の設定方法

jobの実行にパスワードをかける場合、認証トークンが必要になります。 実行パラメータに認証トークンを渡します。

  1. jobの設定画面を開きます。
  2. ビルド・トリガのリモートからビルドのチェックボックスをチェックし、表示された認証トークンのボックスに任意の文字列を設定します。
    ここに入力したものがそのままパスワードになります。
    ※ 認証トークンをjobに設定した時点で先ほどサンプルに書いたcurlコマンドではアクセスできなくなりますので、稼働中の仕組みを触る場合はご注意ください。
     
    corec-2015-06-001

認証付きでjenkinsのjobをリモートから実行する方法

最後に取得した情報を元に[repos]/githook/post-updateを編集します。
curlでベーシック認証&POSTするように以下のように書き換えます。

#!/bin/bash
BRANCH=$(git rev-parse --symbolic --abbrev-ref $1)
if [ "${BRANCH}" = "develop" ]; then
  # 認証トークンをパラメータとして送るのでPOSTにして、できればhttpsにしておいたほうが良い  
  curl -u corec_jenkins:[APIトークン] -X POST \
  http://[jenkins-host]/job/corec/build?delay=0sec&token=[認証トークン]
fi

ジョブ管理(jenkins)-チケット管理(Backlog)

次にジョブ管理から、構成管理の更新をBacklogに通知します。
仕組みとしては、ジョブ管理の中でシェル(プログラム)を起動し、Backlogの提供しているAPIを叩きます。
以下の2つのステップで実現しています。

  1. 更新する対象のチケットの取得
  2. Backlogへ通知

それではそれぞれ説明します

1.更新する対象のチケットの取得

更新する対象のチケット番号はjenkinsの変更履歴を解析して取得します。
gitのlogから取得しても良かったのですが、jenkinsは場合によっては複数のリビジョンをまとめて対象にする場合があるで、jenkinsのjobで管理されている変更履歴から取得する方法を採りました。
jenkinsの変更履歴の取得にはjenkinsのリモートAPIを利用します。
 
http://[jenkins-host]/job/corec/[build-no]/api/json
 
このURLのレスポンスでビルドの情報がJSONで取得できます。
取得したjsonのchangeSet以下が変更履歴のリストになるのでその中からチケット番号を拾い出しています。
 

2.Backlogへ通知

Backlogへの通知はコメント登録をすることによって実現しています。
Backlogへの接続にはスペースIDAPIキーが必要になりますが、取得方法は以下のとおりです。

  • スペースID
    Backlogのサブドメインの部分です。
    https://[スペースID].backlog.jp
     
  • APIキー
    Backlogの個人設定のAPIタブを選択して登録ボタンをクリックすると生成されます。
     
    corec-2015-06-004

BacklogのAPI

BacklogのAPIライブラリはこちらに各種言語のものが紹介されています。
CORECではBacklog4Jを利用しています。
Javaを選んだ理由は当時私が扱いやすいものを選びました(^^;

Backlog4Jでの接続とコメント登録は非常に簡単で数行で実装可能です。
その他、いろいろな操作ができますので、詳細はgithub - backlog4jを参照してください。

// Backlogへ接続
BacklogConfigure configure = new BacklogJpConfigure("[スペースID]").apiKey("[APIキー]");
BacklogClient backlogClient = new BacklogClientFactory(configure).newClient();

// ステータスを変更し、コメントを登録
UpdateIssueParams params = new UpdateIssueParams(issueKey);
params.status(Issue.StatusType.Resolved);  //ステータスを処理済みにする
params.assigneeId([担当者のID]); //担当者を変更する
params.comment(comment); //コメントを付加する
backlogClient.updateIssue(params);

ちなみにコメントは以下のように登録しています。
Backlogに登録するコメントにビルドURLを含めておくことで同時になにがコミットされたのか参照しやすくなるのでお勧めです。

変更がdevelopにコミットされました.

commiter:corec taro
commitId:xxxxxxxxxx9c6bc1adf5d3319f8cb49598
comment :COREC-999 jenkins自動登録機能

refer :http://[jenkins-host]/job/corec/[build-no]/changes

jenkins Backlogプラグイン(おまけ)

jenkinsにはBacklogプラグインがあります。

いくつか便利だと思った機能をご紹介します。お試しください!

  • jenkinsへのログインをBacklogユーザーで認証する。
  • 変更履歴にチケット番号があると自動的にBacklogへのリンクにしてくれる。
    先ほどのコメントのサンプルにあるようにBacklogに登録するコメントにビルドURLを含めておくと、Backlogとjenkinsの変更履歴が相互リンクできるようになります。
  • 失敗ビルドの場合Backlogにチケットを登録してくれる。
  • jobのメニューにBacklogへのリンクが表示される。
    クリックするとBacklogのスペースに飛んでくれます。  
    corec-2015-06-005

まとめ

CORECを支える仕組みとして、今回はチケット管理(Backlog)と構成管理(git)をjenkinsでつなぐ仕組みと その設定方法をご紹介しました。
それぞれの設定やコードは簡単なものだということがわかっていただけたかと思います。
しかし、これにより得られる生産性や安心感は絶大です。
もし、まだこのような連携をしていなければ、ぜひ試していただいて、得られる生産性や安心感を実感していただきたいと思います。
少しの手間を惜しんで多くの時間を無駄にしないように、自分の仕事の環境にこそITを導入しましょう!

次回の『CORECを支える技術』もお楽しみに!

ここ数年で技術部で定着した制度2つ

こんにちは、たむらです。
今回は私が部門長になった頃に施行されて、今ではだいぶ定着した技術部の制度を2つご紹介しようと思います。

1.技術サポート制度

開発環境の増強及びスキルアップの資金として会社が補助金を支給する制度です。1名につき年度毎に10万円迄が利用できます。開発環境の最適化を支援したり、最新デバイスや技術トレンドをいち早くキャッチアップできることを目的として用意されました。

技術に関連するものであればメンバーが自由に利用目的を選択することができて、多くのメンバーが毎年利用しています。

使われ方としては、大体みんな最初にノートPCを買っています。開発メンバーのメインPCはデュアルモニター+(スペックを考えて)デスクトップという構成なので、ミーティングで利用できるノートPCのニーズが高いためです。その後は開発環境のディスク増設やキーボード、技術書の購入などに利用されていることが多いようです。また、資格試験の受験費用やセミナーの参加費用などにも使われています。

matome3















購入したものの一部。ノートPCやキーボードではかなりメンバーの好みや個性がでます。

予想外の効果も

エンジニアの好奇心を満たす為の福利厚生として生まれたこの制度ですが、思わぬところで予想外の効果もありました。

それはハンズオン系の勉強会が増えたことです。今迄デスクトップPCしか無かったので会議室などで集まって行う勉強会では講義形式が主流でした。それがノートPC保有者が増えたことにより、ハンズオン形式の勉強会が行い易くなり頻繁に開催されるようになっています。勉強会の一例は社内勉強会をご参照下さい。



2.ユニットチーム制度

技術部の開発チームは現在17名の大所帯となっていますが、実際にはユニットというチームで開発業務にあたっています。

ユニットチームの概要
  • 2名~4名の小チーム制
  • プロジェクトや開発業務はこのユニットの単位で行う
  • ユニットセンターという代表者が1ユニットに1名存在。報連相の仲介役
  • ユニットは緩やかに担当するサービスが決まっている
  • ユニットの再編やユニット間の人の移動は年に1回程度人事異動的に行う
  • ユニットには名前を付ける(←大事!名前があると思い入れが違います

このユニットチーム制になったことで、以下の様な効果がありました。

スモールチームによるチーム力の向上!

言うまでもなく、チームは大きくなれば大きくなる程コミュニケーションコストが加速度的に増加する傾向にあります。小さなチームであればそのコストを小さくすることができます。また少人数のチームメンバーで継続して業務にあたることでそれぞれのスキルや性格の理解も深まり、「jsなら彼に任せるのが良い」など、経験に則した信頼関係が築けてチームとして相乗効果が生まれます。スクラムでいうベロシティが測りやすいメリットもあります。

多角化したサービスに柔軟に対応できる

ラクーンでは「スーパーデリバリー」、「Paid」、「T&G売掛保証」、「COREC」と4つのサービスを展開しています。それぞれのシステムには当然開発言語や環境、仕様といったシステム面でのナレッジの他、各サービスについての業界知識も必要となり、とても一人で全てを把握することはできないボリューム感となっています。そこで、各ユニットにはそれぞれメイン担当となるサービスが"緩やかに"割り当てられています。この"緩やかに"というのがミソで、基本はメイン担当となっているサービスの開発をするのですが、大規模なプロジェクトが企画され複数のユニットで担当する時や他のサービスでヘルプが必要な際には別のサービスの開発にも参画できるような運用としています。これによりメンバーが技術的にも業務的にも深く掘り下げて軸になる部分を作るニーズと、会社的にダイナミックな開発計画をとれる柔軟性のニーズの両方を満たせられるようにしています。

業務仕様を現場で判断しスピードUP+やる気UP

ラクーンにもリーダや部長といった役職はあるのですが、一般的な会社の役職者は人事的なマネジメントだけでなく、業務仕様的なイニシアチブもとることが多いと思います。ですが、マネジメント業務もかけ持ちしている状態の役職者が業務仕様まで見ようとするとボトルネックになる上、現場との認識の乖離が起きやすくなる傾向にありました。そこでユニットチーム制を開始するに際して、役職者はあくまで人事マネジメントに注力し、業務仕様面での権限は担当するユニットチームにできるだけ移管し現場チームで仕様決定できるようにしました。ユニットは細かな仕様の決断は勿論、開発案件リストの中で何を実施するかという点も含めて判断を任されています。結果的に開発パフォーマンスが上がり、且つメンバーがやりがいを持てる体制になっていると思います。

教育や研修が実施しやすい

ユニットチームは教育や研修でも効果を発揮しています。少人数のチームなので教育する側とされる側が密にやりとりができる為、目が届いた研修が行えます。また、「個」に合わせた対応が取りやすいことや、教育のサイクルを多くのメンバーが担当することで教える側のスキル向上にも繋がりやすいこともメリットだと言えます。

スケールの調整がしやすい

サービスの誕生やメンバーの増減に対してスケールしやすい構成です。2014年にサービスを開始したCORECも新規事業として一気に立ち上げがありましたが、各チームから人を集めて担当チームを作る形で対応でき、フレキシブルにチームの構成を変化させやすい人数になっています。そんな意味で、例え部門の人数が2倍になってもボトルネックを産みにくく生産性を落としにくい仕組みになっているかと思います。



ラクーンでは、エンジニアが楽しくやりがいを持てて、仲間と共に成長できる環境こそがより良いサービスを生むと本気で考えています。今回はそんな考えの中から生まれてきた2つの制度を紹介させていただきました。

こんな技術部やラクーンに興味を持ち、是非働いてみたい!という方、私達は一緒に働く仲間を随時募集しています。ご応募お待ちしております。

技術戦略部有志イベント『エンジニアの宴』を開催しました

kanpai


こんにちはなべです。
技術戦略部有志のイベント『エンジニアの宴』をレポートします。

『エンジニアの宴』というのは、全社的なイベントではできない企画で、エンジニアらしく楽しんでしまおうという、エンジニアのための、エンジニアによる、『エンジニアの宴』です。
 
コンテンツはLT大会とFightCode大会です。

それでは早速ご紹介します。 



第1部 LT大会

   
25 27-IMG_3701 22-IMG_3698

ネタは、最近業務で作ったJSライブラリ、ソフトウェア業界の偉人(変人?)、WindowsAPI Hookから、
エンジニアとはあまり関係ない、最近流行の陣取りゲーム、
最後は、エンジニアとは全く関係ないお掃除に使う洗剤の話まで多種多様。
日頃のLT大会とはまた違ってゆるいネタで盛り上がりました!
 


第2部 FightCode大会

56 32 54

FightCodeは、JavaScriptでロボットの動きを実装して戦うゲームです。 
今回の参加者は10名。総当りで戦いました。 
普段JavaScriptを使っている人もそうでない人も、それぞれの叡智を結集して戦いに臨みました。
強いロボットが順当に勝つときもあれば、それだけではなく運の要素も絡んで金星などもあり盛り上がりました!


51


最後は、エンジニアらしく、それぞれのコード解説。
”勝つ!”という同じ目的で作ったコードですが、それぞれ考えた作戦もさまざまなので、コードもさまざまです。 
作戦に性格が出ていたり、強いコードは必ずしも行数が多いわけではなかったりして、ツッコミを入れたり感心したりしながら、それを肴に最後の〆。

日頃の研修や勉強会とはまた違ったゆるく楽しい宴でした。
 

記事検索