今年の個人的な流行語は「Git」と「プルリクエスト」※今更ではあるが…

2015年も今日が最終日。

今年は（も？）自分なりの目標を立てて挑んだ一年。

技術のみならず、チームとかマインドセットとかモヤモヤしたものに挑んだ一年でもありました。

モヤモヤの部分を語るには、ここは適切で無いかもしれないので、それはまた別の機会に譲るとして、今年そのモヤモヤの部分に大きく影響を与えたツール「Git」について少し書いてみようと思います。

SVN期

今年の始めは、バージョン管理はSVNで行っていいました。

既に社内にGitの環境はあったのですが、社外の現場と連携したソースコードの共有を行う必要があったことからクラウドベースで運用していたSVNを選択しました。並行してチームメンバーで作業を見える化するためにタスクボードは先ずは下記のようなスタンダードなカタチから始まりました。

チケットの粒度が大きくて、作業が完了しないまま次の作業が始まるケースが多発して、価値を産まない仕掛中のタスクが多発する傾向にあったのでWIPを設定しました。

さらに、個人作業がメインで完了の定義があいまいだったタスクを、他の人がチェックするようにしました。

これにより個人任せだった完了定義と品質が少しずつ改善されていきました。

Git（bucket）期

社外メンバーとの連携の制約が解かれて、晴れて（？）社内のGitbucketでのバージョン管理が始まりました。最初は、ひたすらmasterブランチへPUSHするSVNのような運用を行っていましたが、プルリクエストを前提とした運用を始めました。これにより、動作的な確認だけでなくコードベースのレビューが自然の流れで可能になりました。当初はSVNの時の運用と違って、いちいちブランチを切るのが面倒くさく感じたのですが、プルリクエストの恩恵に気付いてからは、その手間はあまり気にならなくなりました。加えて、フィーチャーブランチを切る時に悩まないよう、ブランチの命名規則をルール化（案件を示す英字一文字_ISSUE番号）したことで、さらに気にならなくなりました。

が、チームメンバーが増えるに従ってどれを誰がやっているのかが分かりにくくなるという新たな問題も発生しました。

そこで、現在（今年の最後）は、タスクボードは上記のようなカタチになりました。新たにレビュー待ち、レビュー中という状態のレーンも設けることで、以前と比較して【実装】→【レビュー】→【完了】までの流れと状態がかなり分かりやすくなりました。また、この流れはプルリクエストを出してからレビューしてマージするまでの流れと非常に非常に非常に…自然な流れでシンクロしています。

プルリクエストの文化を徹底するため、ふりかえりなどで運用のしかたを相談して、masterブランチ、developブランチには直接PUSHできないよう、フックスクリプトを設定して事故を未然に防ぐような運用にしました。

あとは、ブランチ戦略としては

nvie.com

 を参考に、先ずは下記のようなシンプルなルールで運用をし始めました。実際は、下記をベースにテスト用のブランチやドキュメント用のブランチをケース・バイ・ケースで切るなどの試行錯誤や工夫はしていますが、現在でも大枠は下記の戦略です。

 

これによって、何が変わったか？

ですが、下記のような目に見えた恩恵がありました。

• レビューをする文化の定着
• 責任の分担（ソースコードの共同所有）
• ソフトウェア品質の向上
• 開発スピードの大幅UP（※メンバーにもよるけど半端ないくらいUPした）
• 柔軟なリリース（プルリクブランチのマージを選択することで可能）
• 人のソースコードを見る習慣から自然と学びがある

ハッキリ言って本当にいいコトずくめで、考えてみてもデメリットは思いつかないくらいです。

良い文化というものは、ツールの力を借りはするものの、それはメインのパワーとはならないと思っていたのですが、Gitとプルリクエストは、上記のような恩恵をもたらす文化を醸造するのにものすごい力を発揮してくれました。

モチロン結局は運用するのは人なので、このような機能を良くも悪くも使えるとは思いますが、個人的にはこれを使わない手はないと思っています。（※だって只だし）また、メンバーが必要を感じて段階的にカイゼンしていけたことも（今思えば）結構大事なことだったんじゃないかなと思います。押し付けて一方的にやらせていたらまた違った結果になっていたんじゃないかなぁ…

使ってる人にとっては今更イマサラですが、巷ではなんかGitが流行っているなぁ…と思ってから随分と時間が経って（気付けば数年？）しまいましたが、その恩恵を感じた一年でした。

個人的に今年は燃えプロ（※炎上プロジェクト）もあって、イロイロと大変なこともありましたが、チームメンバーと同じかそれ以上にGitとプルリクエストに助けられた年でもありました。たぶんSVNとかTFSを今までどおりの感覚で使ってたらもっと炎上していたんじゃないかなぁ…（※これらのツールがダメという訳ではないです。ちゃんと使えばいいだけだとは思います）

今、いっぱい飲んで年末を堪能しながらいい気持ちでこの記事を書いています。

きっと誤字もたくさんあることでしょうが、ご容赦ください。

それでは、今年も残すことろあと２時間…

良いお年をお迎えください。

初めてのATTでCSMになれた話

この記事は TOCfE Advent Calendar 2015 の14日目の記事になります。

昨日はメイド長こと大和さんの「未来福音」のおハナシでした。

まずは自己紹介。Twitterアカウントと同じくorinbouというHNでBlog書いてます。派遣や受託でソフトウェア開発を行うの小さな所謂SI屋で働いています。プログラム書いたりマネージメントしたりしながらそこそこデベロッパな生活を送っています。時々、IT系のコミュニティに参加したりTOCfE Boot Campに姿をあらわします。

TOCfE歴は、TOCfE Boot Campで、考えるための3つの道具「ブランチ、クラウド、アンビシャス・ターゲット・ツリー」をひととおり学びました。そういえば、今回TOCfE Boot Campに参加するキッカケもメイド長だったような…ｗ その人からのバトンを引き継ぐことになるとは、何やら不思議な縁を感じますね。

今回は、一年前に参加した

で 「アンビシャス・ターゲット・ツリー」を初めて学んだ時のお話をしたいと思います。

アンビシャス・ターゲット・ツリー（長いので以降はATTと略しますね）は、「目標を実現したいけど、どーやったらいいんか分からない…」という時に、今ある情報を基に達成計画を立てるツールです。ATTについては「目的と目標について｜Eijiのブログ」でもEijiさんが解説してくれているのでそちらもご覧ください。

ATTをつくる流れはこんな（↓）感じです。

1. アンビシャスターゲット(AT)を決める
2. ATに対する障害やリスクを洗い出す
3. 障害を乗り越えたといえる中間目標を出す
4. 中間目標を前提条件順に並べる
5. 中間目標に実際の行動を加える

この日は折角の機会だったので、私が普段から抱えているリアルな目標（AT）を達成するためにワークショップを活用させてもらいました。私のATは「認定スクラムマスター研修（通称CSM研修）に参加して認定資格を得る」というものでした。資格を得る事自体が本質的な目標というわけではなく、IT系コミュニティなどで仕入れた様々な知見やツール、マインドセットなどを自分の現場や社内に展開するにあたり、分かり易い資格というカタチとして持っておくことが、それを加速するひとつの武器になると考えたからです。人事考課の面談や折をみては１年くくらい上長に訴え続けていたのですが、なかなか行かせてもらえず半ば諦めモードな感じでした。

そんな状態で先ずは個人作業で自分なりに障害やリスクとなることを洗い出してみてATTを作ってみましたが、手詰まりの連続でした。直列的なツリーとなり、とても目標を達成できそうもない木になってしまいました。ATTというツールを初めて使うということもあったと思いますが、自分なりにやることはやってきた…という変な先入観というか自尊心みたいなものが邪魔をしていたいように思います。

ワークショップが進行していき、各自が自分なりに作ったATTを３人一組のグループ内で共有する時間になりました。その時、同じグループのお二方から様々な指摘やツッコミ、問いかけをしていただき、自分なりに手は尽くした…と勝手に思い込んでいたカチカチ頭の自分に気付けました。ありがたいことです。

さらに、私があまりにも切実そうだったためか、お二方とも自分のATTを差し置いて、後半のグループワークの殆どの時間を、私のATTを完成させることに費やしてくれました。自分だけで考えることももちろん大事ですが、前提として思い込みがあるような場合は、他者から質問されたり、声に出して読んでみて自分自身の耳から情報を入力してみたりすることは、自分の置かれた状況を客観的に捉えるための手段として、とても有効なのだと改めて感じました。

その日、完成したATTがコチラ（↓）になります。

• 濃黄色：アンビシャス・ターゲット（１年以内にCSMの資格を取る）
• 薄黄色：中間目標
• オレンジ色：行動

玄人の方からすると、まだまだ十分な完成度とはいえないツリーかもしれませんが、自分なりにしっくりきていたので、翌日からこのツリーに沿って下から順番にやっていくことにしました。徹夜でCSMアピールスライド作ったり、社長室へ乗り込んで説明したりとか。ツリーに沿って進めていく中で新たに分かること、状況の変化などに応じて微妙に修正を加えはしましたが、基本的には、この日決めた方向へ殆ど迷うことなく進んでいくことができました。アンビシャス・ターゲットに期限をつけたのが良かったのかもしれませんし、また、一緒に考えてくれた人達の顔（プレッシャー？ｗ）が後押ししてくれたようにも思います。

そんな訳で、今年の3月めでたくCSM研修に参加して資格を習得することができました。

その時の様子は

の記事に書きました。単にATTだけの力ではないかもしれませんが、この日この会に参加していなかったら、間違いなくこのようなアプローチはしていないかったと思います。TOCfEのATTというツール、また、TOCfE Boot Campという場、また、そこで出会えた人達には、ただただ感謝の言葉しかありません。本当にありがとうございます。

TOCfEに興味がある人、また、学びたい人にとって、TOCfE Boot Campは費用もそれ程かかりませんし、初心者でも気兼ねなく参加できる場になっていますので、少しでもご興味ある方は、一度参加されてみては如何でしょうか？もしかしたら素敵な "アハ体験" ができるかもしれませんよ。

最後に告知です。TOCfE Boot Campの直近のイベントは

になります。年内最後のイベントになるのかな？

ご興味ある方は是非ともご参加ください。

明日は15日目、Kunikazu Fujita さんです。どんな話が聞けるのか楽しみです。CLRかな？クラウドかな？そんな訳で、まだまだ TOCFEアドベントカレンダー2015のバトンは続くのです。それでは、よろしくおねがいします。

認定スクラムマスター（CSM）を取得しました

先月の話になりますが念願の認定スクラムマスター研修を受けてきました。

講師：ジム・コプリエン - James O. Coplien(Jim Coplien)

日時：2015年03/02（月）〜03/03（火）

場所：渋谷 VOYAGE GROUP 会議室 パンゲア

この日も、日本人だけでなく、アメリカ、バングラデシュ、中国といった多国籍の参加者がいました。なんちゃってアジャイラーの自分にまず最初に刺さったのは、朝会の３つの質問に足りないもの（「チームのゴールに貢献するために…」を常に意識して話をすること！）という指摘と、朝会で毎日スクラムボードを見なおしなさい…という点でした。やってたつもりだったけど、改めて、そこまで意識的にはやってなかった…でも、そういう小さい意識が結果として大きな違いを生み出すんだろうな、と

ノッてきたのかいつもなのか、Copeも裸足になって熱く語ってくれました。

２日目後半は、楽天の川口さんも駆けつけてくれてスクラム流の挨拶を教えてくれました。

得るもの、気付き、出会いなどなどイロイロとあった訳ですが、実践の場（私の現場）で活かしたいと思います。なんせ赤いピルを飲んだ（飲まされた？）訳ですから。

セミナー終了後、1週間くらいで、ScrumALLIANCEから認定試験の案内が来ます。メールの案内に記載されているオンライン試験にパスすれば、すぐに認定スクラムマスター（Certified Scrum Master、略称CSM）の認定証が発行されます。ちなみにこういうの（↓）です。

いつ頃からかは不明ですが、今では日本語で受験できるので英語が苦手な人でも問題ありません。日本語、英語の他にも中国語などのかなりの言語で受験できるようになっていたので、スクラムの認知度が世界的に高いことを間接的に感じました。

そして、これはゴールでなく、始まりです。

終わりなき旅が始まります（もう始まってますが…）

いざ

RTMP接続を自前で死活監視する方法

新年あけましておめでとうございます。

年末年始の休暇で、執筆やプログラミングなど色々とやろうと思っていたのですが一家で病に伏していたためでコレしかできませんでした。ほぼ自分用の技メモです。

一般的なサーバの死活監視あれこれ

pingレベルのサーバ死活監視やWebサービスやURL死活監視については、無償／有償のサービスが世の中には沢山あります。例えば監視サービスだと「Site Alert(サイトアラート)」とか「Site Care FREE Ⅱ」とかありますし、最近だとやっぱりHatenaさんの「Mackerel」とかですかね。自前で監視サーバを建てるんなら「Hinemos」なんかもあります。

RTMP接続の死活監視サービスはないの？

現在ストリーミング配信サービスの開発に関わっているのですが、今回やりたかったのがストリーミングサーバの死活監視なので、監視対象のプロトコルはrtmpやrtmpeやrtmptなどです。これらはもともとAdobe社が開発したTCPベースの通信プロトコルで、現在では仕様が「Real-Time Messaging Protocol (RTMP) specification | Adobe Developer Connection」として公開されています。一般的な死活監視サービスでは、この特殊な接続の死活監視をすることができません。

と思ってRTMPの死活監視サービスを探したら、「おっ！」ありました！！

こんなビンゴなの（↓）を発見しました。

Webサイト監視サービスで初！ストリーミング配信の監視が可能に！ 『AEROALIVE（エアロアライブ）』に、RTMP監視機能を追加 | AEROALIVE | プレスリリースを無償で投稿・閲覧・配信：AEROPRES（エアロプレス）

が、情報が2年前から更新されておらず新規ユーザ登録もできなくなっていました…orz

う～ん、残念。。やはり自力でやるか…

自前でRTMP接続の死活監視するには？

仕方ないので「rtmpdump コマンド一覧と使い方 : ニコニコ動画研究所」を参考に自力で死活監視する方法を考えてみました。

まず下記のツールを入手します。

Linux版とWindows版があります。

今回はWindows版（EXE形式）をダウンロードしました。

RTMPDump 2.4 122213

次にダウンロードした実行ファイル一式を任意の場所に配置します。

パスを通す必要もなく、コピーのみでOKなのでとても簡単でした。

Jenkinsで監視するプロトコル毎に下記コマンドを定期実行させるJobを作成します。ありがたいことにRTMPDumpはコマンドラインで実行でき、かつ、実行結果をEXIT STATUS（成功：0、失敗：1 or 2）として返してくれるので、実行（死活監視）に失敗した場合のみJenkinsでビルド失敗メールを簡単に飛ばせます。

• RTMP

         rtmpdump.exe -r rtmp://localhost/vod/mp4:sample1_500kbps.f4v -o rtmp.f4v

• RTMPE

         rtmpdump.exe -r rtmpe://localhost/vod/mp4:sample1_500kbps.f4v -o rtmpe.f4v

• RTMPT（※必ず失敗してしまうので監視対象外としました。Win版だからかな？）

         rtmpdump.exe -r rtmpt://localhost/vod/mp4:sample1_500kbps.f4v -o rtmpt.f4v

念のためRTMPdumpの監視接続時に接続数が増えることも管理コンソールで確認しました。とりあえず、これでOKですね。

そんな訳で、マニアックな記事で始まった2015年となりましたが、本年もどうぞよろしくお願いします。

[2014/12/9(火)］アジャイルサムライ横浜道場 特別編 へ参加してきました

久しぶりにアジャイサムライ横浜道場へ参加してきました。

本日は次回の忘年会を抜かすと2014年内最後の道場勉強会となります。

少々難しい話でしたので、本日の気付きを簡単にメモっておこうと思います。

本日の概要まとめ

アジャイルサムライ横浜道場 特別編 「アジャイルコミュニケーションプログラム2：コミュニケーションの妖怪マップをつくろう！～コミュニケーションの構造分析ワークショップ～」 - アジャイルサムライ横浜道場 | Doorkeeper

講師（自称コンビ芸人「なんでんかんでん」）は、本橋さん（左）、林さん（右）で座学＆ワークショップ形式で行われました。そして、写真には移っていませんが、本日はパタランの大御所、羽生田さんも来られていました。

本日は、この「エゴグラム」というだんご３兄弟みたいなツールを学びました。

簡単な説明は上記のとおりです。それぞれのだんごは下記の項目を表しています。

• P：親（CP：批判的な自我状態、NP：養育的な自我状態）
• A：大人
• C：子供（NC：自然な自我状態、CC：従順な自我状態、RC：反抗的な自我状態）

それぞれの良い状態（左）と悪い状態（右）の例が下図になります。

 

全体を満遍なく行き来し、かつ、青いエリア同士が矢印で結ばれた状態が良い状態です。逆に、青から赤、または、赤いエリア同士が矢印で結ばれた状態が悪い状態です。この悪い状態を、本ワークショップでは「妖怪」と呼びコミュニケーション「問題」の象徴として向き合います。

 

そして、一度でも赤色のエリアに出てしまうと、赤いエリア同士を矢印で結ぶことになるコミュニケーション悪化の連鎖が始まりやすくなるそうです。この悪い状態の連鎖のサイクルを「妖怪のうつり」と表現していました。この話を聞いていて、虐待された人が成長してから自分の子供に対して虐待を繰り返してしまう負の連鎖を想像しました。

本日の気付き

以上の座学を踏まえた上で、ペアをつくってお互いの身の回りのコミュニケーションにおける問題点を取り上げ、エゴグラムを使って分析してみました。自己分析結果（左）と、それを発表した際に講師の方に解説しながら修正してもらったもの（右）です。

 

この図からは、分かりにくいですが、以下のことに気付きました。

• コミュニケーションを見える化すると客観的に考え分析できる
• その結果、誤認（もしくは、その可能性に）気付きやすくなる
• 最終的に、実は妖怪は相手でなく自分であることに気付く（こともある）

人間がなんとなく頭で考えることというのは、ロジカルに考えていると思っても、実はものすごく感情の影響を強く受けていて、そのままでは、なかなか正しい分析ができないみたいです。TOCfEの３大ツールもそうですが、今回のエゴグラムのようなツールを活用することで、コミュニケーションの問題を見える化し、分析することで、問題と向き合いやすくなるかもしれないな…と感じました。

Gembaの"小さな"越境とその前提条件

このエントリーは『DevLOVE Advent Calendar 2014 「越境」』の18日目の記事です。

昨日のエントリー zakky さんからのバトンを受けて書かせてもらいます。 

自己紹介

昨年の「DevLOVE現場甲子園2013」をキッカケに始めたBlogですが、なんとかまだ続いてますｗ

まずは自己紹介ということで、Twitterアカウントと同じくorinbouというHNでBlog書いてます。派遣や受託でソフトウェア開発を行うの小さな所謂SI屋で働いています。昨年のDevLOVE現場甲子園では団長の中村洋さん率いる「団」チームで、二回裏に「世界を変える前に現場を変えよう」というタイトルで発表させてもらいました。今年の現場甲子園では裏方専門スタッフ（雑用係）として活動しています。今年の登壇としては、XP祭り2014のLT（オオトリで撃沈…）くらいかな？気が向いたらBlogのプロフページでも見てやってください。

Gembaの"小さな"越境とその前提条件

９月末までの私の現場はお客様先でした。紆余曲折を経て１０月から自社に戻りかつて自身が立ち上げに関与していた自社サービスの開発に戻ることとなりました。戻ってまず感じたのは、開発の現場となっている所内がとても静かだったこと。おかげで自分の声だけがとてもデカく感じましたｗ２年以上もその現場を離れていたことと、前任者からの引き継ぎが全く足りていなかったこともあって、しばらくは、自分が居ない間に変化したことや忘れてしまっていることを思い出しながら苦戦していましたが、その中で、チームがあまりに流動的でモヤモヤしていたので、上司と掛け合って先ずはあえて垣根をつくりました。垣根といっても、悪い意味ではなく、とにかくイロイロなことを言われるがままにやらされていた人達が属するチームを明確にしました。まずは所属する確かな場所があってこそ開発者もアイデンティティが確立する訳で、兼務とかヘルプ要員みたいな人ばかりで編成されたチームって、当事者意識がなくてまともに機能しないことが多いですから。作業をお願いする側も、いつ居なくなるか分からない人に大事なことや時間のかかりそうなことを頼めないってなると、もはやな何なんだその組織は？って話になるし、チームとかいう以前の状態です。越境するには、まず確かなアイデンティティ（根っこ）があってこそだと思っています。でないとただの根無し草でフワフワしてしまうので、突っ込んだ話もできないし、それ故に、個人もチームも成長の機会を奪われてしまいますよね？ 

という訳で、ここ１ヶ月半くらい下記のことやりました（※というか、気付いたらやっていた） 

• 【Step1】チームの垣根づくり：所属を明確にしてアイデンティティ確立

　　　→所属するチームやプロジェクトを明確にして、腰を据えて作業できるようにする。

• 【Step2】かんばん：情報共有、見える化、見せる化（開発者、営業、経営者へ）

　　　→所属するチーム内で何が起きているか（ステークホルダーに）分かるようにする。

• 【Step3】ふりかえり：大層なことはやらない。ちょっとしたことからカイゼン

　　　→チーム内のことでもいいし、ソレ以外のことでもいいので、できることから改善する。

 弊社のプロジェクトは、中も外も、毎度毎度、個人でタテ割りになっていることが多い（なぜ？）のでイロイロと問題が発生することも多い訳なのですが、少しずつ良い方にサイクルが回り始めてきたように思います。

特に『ふりかえり』では、プロジェクトに全然関係ないことでいいから、少しでもやりにくいと思っている事や、なんだか分からないけど、モヤモヤしていること、などをお互い（最初は２人サシからスタート）とにかく何でもいいから出し合っていきました。で、先ずは自分から腹を割って、ホントに些細な事「事務所内のゴミ捨て当番の偏りが酷いよね」とか「事務所内の湿度が40%切っててヤヴァいよね」とか話してたら「え？そんなことでいいんですか？」ってなって出るわ出るわで…もちろん、Problem（問題）だけでなくKeep（良かったこと、続けること）も出るようになったし、そこからのTry（挑戦）も自発的出るようになってきました。

嬉しかったのは、最近、出張で終日不在となった日（金曜日）があったのですが、翌週の月曜日に出社したらタスクボード（の付箋）が動いていたんですよ。もちろん勝手に動いたっていうオカルト話ではなくて、着手している作業がとある事情でどうしても進められなくなったので、開発メンバーがかんばんボードを見て、自発的に優先度の高い別のタスクをTODO→DOINGにして作業を進めていてくれていたんです。当たり前といえば当たり前のことではありますが、言われたこと（だけ）キッチリやって後は知りません…みたいな感じが当たり前だった、ほんの１ヶ月前のことを考えるとものすごい変化だと思いました。

さて、ここまで全然『越境』の話をしていませんが、最後に少しだけしたいと思います。

ウチの社内アルアルとしては、個人のサイロ化が問題になることが多いのですが、今回は、個人のチームへの所属が曖昧であったことから、チームとして機能しておらず、力を集中させることができていないことが問題でした。そういう意味で、メンバーには、まず明確にチームへ所属してアイデンティティを感じてもらうことが、最低限のスタートラインだったように思います。その上で、個人がサイロ化しないように、普段から情報を共有し（見える化）、問題に対してチーム（※必ずしもチームでなく『！個人』という意味。チーム全体でなく、とあるメンバー同士でもいいと思う）で取り組んでいけば、まずは、チーム内メンバー間での"小さな"『越境』がしやすくなるのではないでしょうか？

最後に『越境』という言葉の意味を調べてみたら、「不法に…」とか、何となく悪い意味で使われることを前提としているようですが、そこは文脈次第だと思うので気にしない気にしない。とまれ、良いか悪いかはさておき、越境するには、それを乗り越えるためのエネルギーが必要だということにかわりはないと思います。

越境とは - コトバンク

えっきょう【越境】の意味 - 国語辞書 - goo辞書

それぞれの現場で、それぞれの人、それぞれのチームなりの越境があると思います。

私も次の越境へ向けて、また明日から進んでいきたいと思います。

次の人へ

次は今年の現場甲子園2014で初登壇を経験された kimKimmy さんへバトンをお渡しします。

日々現場で奮闘する様子に私も元気と勇気をもらっています(^^)

どんな物語が聞けるのか、とても楽しみにしています。

それでは、どうぞよろしくお願いします！

[2014/9/6(土)］“俺の” XP祭り2014体験メモ

先日は初のXP祭りLT体験で記事を書きましたが、忘れないうちにそれ以外に体験した内容もメモがてらここにまとめておこうと思います。

XP祭り2014は、昨年と同様に早稲田大学理工学部キャンパス(東京都新宿区大久保3丁目4-1)で行われました。そしてコチラも昨年と同様に手作り感満載の案内ポスターがお出迎えしてくれました。こういうのとても好きですｗ

【H-4 アジャイルコミュニケーションプログラム1】

XP祭り2014：H-4 アジャイルコミュニケーションプログラム1：コミュニケーションの妖怪を召喚であります！～コミュニケーションの問題を妖怪に見立てて解決を探るワークショップ～【ワークショップ】

本橋さん、林さんによるワークショップを体験しました。

我々の身近にある様々な問題を妖怪に見立てて、人ではなく問題そのものと向き合おうというものでした。様々な立場で参加している参加者のなかからペアをつくって、妖怪の問題の抽出→原因→命名→解決策といった感じで、最終的には向き合った問題を解決しようという試みです。私の現場でもよくあることなのですが、ミスや問題を起こすとその原因などを考えもせず人のせいにして終わる…ということがよくありますが、それで本当に根本的な解決ができてるのでしょうか？問題を人から切り離して、また、妖怪というイメージしやすいものに例えることで、楽しみながら（？）問題の本質を考えることができるかもしれないな…と。できれば、社内や現場でこういうワークショップやってみたいんだけど、そもそもそういうことを無駄と考えているような文化だと、まず始めること自体がハードルなのかも

当日スピーカーをやってくださった本橋さんのブログに当日の様子がまとめられていいますので、詳細はコチラ（↓）をご覧いたけるといいかと思います。

妖怪とうまくつきあう（妖怪のしくみ、もんげーずら） - ari's world

ちなみに、来月１０月２８日（火）にはアジャイルサムライ横浜道場の特別編として、再演（もしくは類似WS？）があるようなので、ご興味のある方は参加してみたは如何でしょうか？すでに募集が始まっているようです。下記のサイトから参加登録ができます。

アジャイルサムライ横浜道場 特別編 「アジャイルコミュニケーションプログラム1：コミュニケーションの妖怪を召喚であります！～コミュニケーションの問題を妖怪に見立てて解決を探るワークショップ～」 - アジャイルサムライ横浜道場 | Doorkeeper

【D-6 Motivating Agile Teams】

XP祭り2014：D-6 Motivating Agile Teams【ワークショップ】

次はEiichiro Ogura | Profile | Scrum Allianceさんによるチーム開発のモチベーションに関するワークショップでした。自分自身のモチベーションを駆り立てる要素とは何でしょうか？普段あまりそんなこと考えずに行動しているのですが、きっとその人毎にモチベーションをUPするツボ（やる気スイッチ的な？）っていうのは当然違うはずですよね。で、人のやる気SWはもとより、そもそも、自分自身のやる気SWって何なの？っていうのを、このワークショップでは見える化してくれます。詳細はSlideShareにUPしてくれている下記のスライドをご覧いただければと思うのですが、ヒトコトでいうと、色んな視点からの価値観（例：品質、納期、新しさ、学び…etc.）が書かれたカードでババ抜き（５〜６順）して最後に手元に残った（残した）カードに書かれている価値観が、自分が普段大切にしている価値観になるというババ抜きのようなポーカーのようなゲームです。

Motivating Scrum Team from Eiichiro Ogura

Motivating Scrum Team

ちなみに私の手元に最後に残ったカードは上記の５枚でした。

で、この５枚（チャレンジ、学び、成長、高め合える仲間、お客様からのありがとう）の中からさらに３枚を選択して上記のように並べます。

この３枚のカードが私のモチベーションをUPするために必要な（？）価値観ということでした。確かに言われてみれば、この３つがPDCAのサイクルのようにグルグルと回る（チャレンジ→学び→成長）ことを意識しながら行動している（というか、したいと思っている）と言うのは自分でも納得できました。また、一緒にワークショップをした人が大切にしている価値観というのも見せてもらうことで、単にモチベーションをUPする…ために必要な要素って、やはり人によって全然違うんだなぁ…と改めて気付けた気がします。例えば、普段一緒に働いている開発チームのメンバーが大切に思っている価値って何なんだろうか？チームビルディングするにあたり、こういう要素も重要だし、他の人が自分と同じ価値観だと決めつけてしまわないようにしたいな、と改めて感じさせられました。

さらに、選んだ価値観を日常（※今回はソフトウェア開発という視点から上記のようにScrum開発の日常になっていました）のどこに配置するのか、によって、どのくらいの頻度や大きさで、それを実践しようとしているかということが見えてきます。これも面白くって、デイリー内に置く人もいれば、リリースのタイミングに自分が選択した価値カードを置く人もいて、何を選択したか？と同じくらい面白いな、と感じました。価値の選択もそれをやろうとするタイミングも人それぞれなんですね。そして、それがそれぞれの人のモチベーションUPにつながるんだなぁ‥と

【B-7 なぜアジャイル開発はうまくいかないのか？ 】

XP祭り2014：B-7 なぜアジャイル開発はうまくいかないのか？ 〜ソフトウェア開発の本質とエンジニアの生き方【講演】

最後はSonicGardenの倉貫さんの講演を聞きに行きました。（※途中参加でしたが）

例えば今までのSIerのビジネスモデルの中でアジャイル開発をやろうとする限界や文化の違いに関して体験談を交えていろいろと面白い話をしてくださいました。 で、なんと当日LTやったので優先的に本をいただけるということで、まさに今話題沸騰の下記の本をいただきました。ありがとうございます。私はもう読んだのですが、せっかくなんで、今社内で回し読みしています（買えよ！というツッコミは無しでお願いします…^^;）

 そして、最後の最後はXP祭りの打上げの渾身会でした。

ここでは途中で終わってしまった例のLTの続きをやらせてもらいました。

皆さん、ものすごく協力的かつノリが良くって、気持よくLTさせてもらいました。

そんな中、XP祭りのゲストで、下記の講演をしてくれたJoeさんもLTしてくれました。

XP祭り2014：G-4 Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work【講演】

 そのときの様子がツイートされています。

RT @tkfuji: JoeがLTしたい！ってことで5分のLTなう。おまいら、世界に出て日本のことしゃべれよと。 #xpjug pic.twitter.com/mEBnNmXP2R

— xpjug (@xpjug) 2014, 9月 7

JoeさんのLTの中で「リーン（トヨタ式生産方式）もアジャイル（スクラム）も日本で生まれ、海外で育ってまた日本に戻ってきた。だから、君たちももっと世界に出て、日本のことをしゃべれよ！」という部分と「今年と同じことを来年もやってたら、それはアジャイルじゃないよ！」っていう部分がもの凄く印象的で心に残りました。そして、最後の〆は「Don't do agile, be agile!」 っていう（俺の大好きな）言葉で終わりました。イカスぜJoeさん…そして、さすが分かってるな〜なんて思ってしまった。当日パッとメモった走り書きと記憶を頼りに書いているので、もしかしたら、少し言い回しやニュアンスが違うかもしれないので、その辺はご容赦を。間違っていたら逆に指摘してもらえると非常にありがたいです。

今回のXP祭り2014のLTスピーカーやワークショップ体験、また講演を糧にして、来年も今年と同じことをやってないよう、新たな志で持って自分の現場に挑みたい…という気持ちにされられた一日となりました。来年もまた参加したいと思います。もちろん、例のLTのリベンジも画策しながらねｗ