サウスポーなSEの独り言

　年末年始の小休止中＆次の書籍を検討中ですが、社内で行っている「アジャイルサムライ読書会」のことです。

◆この社内読書会をやり始めたきっかけ
　やりはじめた経緯は(当時、同じ会社だった)@mah-labさんが何気なくつぶやいたのがキッカケです。
　そこから「やってみよう！」と数人が集まって始まりました。
　そのキッカケの詳細は@mah-labさんがこのイベントで話していました。
　その時のスライドはこちら。

◆どんな風にやっているか？
・場所は？
　東京と大阪をテレビ会議でつないでやっています。

・人数は？
　大阪2名(最初の頃は私1人)と東京6〜8人という感じで最大10人程度の小さな所帯(でもみんな同じ会社に所属)です。
　時々、話を聞きつけたり、(テーマによっては)声をかけたりしてゲスト的に参加する方もいます。

・時間は？
　7：30〜8：30と朝早い時間です。
　定時後などの場合、残業や打合せなどで来れなくなることが多いと思ったためです。

・やり方は？
　毎回、対象の章…1章とは限りません…と発表者を決めてネタ振り(軽いプレゼン)を10〜20分行います。
　残りの時間をみんなでディスカッションしていきます。

　次回のテーマや事前の議論、連絡などはyouRoomを使っていました。

◆やってみて
　(部門の違いはありますが)同じ会社だからこそ「社内やお客様の状況を共通のコンテキストとして話ができる」のは大きな特徴です。
　もちろん部門やPJが違う部分もありますが、少し説明すると「あぁ、あのことね」となります。
　そのため、「自分達の今の仕事とマッピングして、どう取り入れていくか？」という話が深くできるように思います。

　反面、コンテキストに縛られすぎて「うちの状況では、それはムリよね」とネガティブな話になる時もありました。

　また1時間という短めの時間、話が深くなってヒートアップして・・・という感じで、(終了時間を)オーバーしがちでした。
＃朝早いということも寒くなるにつれて「起きることができなくて」遅刻する方もいたりして。

　この社内読書会をきっかけに参加者(とその周辺の方々)と新たなつながりができました。
　もちろんディスカッションをすることで自分の中でも深く考えることにつながりました。

　自分でインセプションデッキを書くことからスタートして、社内でインセプションデッキのワーク
ショップをやったりもしました。
　そのワークショップの参加者がそれをキッカケにして、そのチームや部門にインセプションデッキが広まっています。

◆これから
　遅くとも2月頭には社内読書会を再開予定です。

　「アジャイルサムライ」はほぼ全ての章を行いましたが、そこからの疑問やディスカッションのネタはストックされています。
＃対象の本が変わったとしても、アジャイル関連の本だと思います。

　こんな本に出逢わせてもらった@nawotoさん、@kakutaniさん、そしてJonathan Rasmussonさんに感謝です。
＃Jonathan Rasmussonさんのお話は3月にあるAgileJapan2012で聴くことができそうなので、楽しみにしています。

　「Developer's Test勉強会 特別編 - 学べ、Git! - SCMBootCampコラボ企画」に参加してきました。

　「Developer's Test 勉強会」とはXPJUG関西 分科会であり、この勉強会はそれの特別回でした。
＃前日まで東京で認定スクラムマスター研修をガッツリ受けていたので予習はほとんどできていなかった状態でしたが…。こちらの内容はとても濃かったので、ぜひ自分の考えをまとめてエントリを書こうと思います。

◆開始〜午前中
　早めに行けたので座席配置やら手伝っているとボチボチ集まってきて全部で20人くらいでした。
　一応全員「プログラマ」ということでした。

　まずは演習準備ということで、gitの設定の確認、ポジションペーパーの作成とそれを演習用gitHubにPullRequestを投げます。
　後はチーム分けをして午前中は終了でした。

　(午後はチーム単位での演習メインなので)チームでランチに行ったのですが、チーム4人のうち2人いた学生さんが、(タイプは違うけれど)良い感じに前のめりな感じで頼もしく感じました。

◆午後
　名古屋から登場の@bleisさんのgitのオブジェクトについてのお話。
　この資料とお話の両方とも、とても分かりやすかったです。
＃発表資料はたぶんそのうち議事録のサイトにアップされると思いますので、興味のある方はウォッチしてみてはいかがでしょう？

　お話の後は2つの演習をチームで行いました。
　お題は「gitのチートシートを作る」で、自然に多人数でやるとコンフリクトや色々な課題が出るのでそれをチームで解決していくという形でした。
　それぞれの演習の最後に直面した課題(と解決できたのなら解決方法も)を全員で共有もしました。

　これまで個人の勉強でしか使っておらず(仕事はSVN)、ごく初歩的な使い方以外の「普通に仕事で多人数で使った際に発生する」コンフリクトやbranchなどは未経験だったので、この演習は良い勉強になりました。
　特に学生さんのうち1人が日常的に使っている方だったので直面した課題を理解した上で解決して進むことができて良かったです。

◆実際の仕事に活かせるか？
　今の所、SVNからgitへすぐに変えることはないと思います。
　SVNで困っているチーム状態ではなく、自分がまだまだ理解できていない点があり「SVNよりもgitに変えた方が良いよ！」て言えるほどではないからです。
　ですが、自分やチームがgitのメリットを理解して(またSVNに不満を持った時に)、すっと移行できるようにしたいと思いました。

◆今後の予定？
　今回は特別会ということでしたが、この後も色々な活動をやって行くようです(と発起人の@kami_teruさんが言っていた)ので、興味がある方はMLに参加してみてはいかがでしょうか？
＃最後になりましたが、講師、スタッフ、参加された方々、楽しい時間をありがとうございました。

　勉強会などで使う個人名刺(うさぎのアイコン)のやつは、前川企画印刷さんのブロガー名刺で作ってもらっています。

　初めてこれを作る時のやり取りもスムーズで「もうちょっとこんな感じで…」という「感覚的」な注文にもかなり早く答えてくれました。
　こういうサービスは(値段よりも)やりとりのスムーズさや融通性などが重視されると思います。

　で、2012年。
　干支も辰になり、アイコンも変えました。

　ちょうど個人名刺がもう少しでなくなりそうです。
　ですので、今年の干支のアイコンを入れた新しい個人名刺を作ろうと思っています。

　ちなみに勉強会などで会社名刺と一緒に渡すと、個人名刺の方が興味を惹くようで「良いですねぇ、どこで頼んだんですか？」て聞かれることもチラホラあります。
＃イラストの出来…嫁さんが描くんですが…が良ければ毎年変えていこうって思ってます。

　2011年の出来事を備忘録として書いておきます。


■2011年の出来事
◇1月
・自分達が作っているプロダクトの紹介を社内セミナーとして行ったが、とある会では出席者があまりに少なく「発表者」＞「出席者」という回があった。

◇2月
・ランチを(同じチーム以外の)他の部門の方と食べるようにする(ディスカッションやら)。
・ヨメさんと子供が(ヨメさんの実家から)帰ってきて生活リズムが色々変わり始める。
・自分達が作っているプロダクトが社内の賞を取った。

◇3月
・(ずっと会って話をしたいと思っていた)東京の@kawasimaさんや@anarchiStrawさんと期せずして会えて、また広がりができた。
・ブラウザをFirefoxからChromeに乗り換える。

◇4月
・自分、チーム、部門、会社のスピード感の違いにイライラする(スピード感の違いがあるのは当たり前だけど)。
・「AgileJapan2011大阪サテライト」に行く。Linda Risingさんの講演は特に感動した。

◇5月
・社内のアーキテクトの方々とディスカッションする場を開く。また色々と広がりができた。
・(この頃から)より意識してRedmine、Jenkinsなどの有効な使い方を人に伝えることができるように考え始める。

◇6月
・たぶん人生で一番値段が高い買い物を(即決で)する。
・ソフトバレー。2年連続(またも2位でだけど)で全国大会出場できることになった。
・生活リズムが変わったりして、やたら昼間が眠い、集中力がない時期だった。

◇7月
・引越をして色々なモノを捨てる。
・社内セミナーで初めて名古屋に行く。
・「RxTstudy」で話す。これをきっかけに勉強会などで話す機会を得ることができた。

◇8月
・「アジャイルサムライ in TIS道場」が本格始動。また色々な人と広がりができはじめる。
・30代後半に突入する。

◇9月
・ScrumBootCamp関西に参加。
・東京方面の勉強会で話す。
・「DevLOVE関西」に参加して(懇親会で)LTをする。会場は自分が所属する会社のセミナールームを(たぶん)初めてこういう勉強会で使った。
・「第1回大阪Jenkins勉強会」に参加してLTをする。この9月は勉強会がやたらと重なった月だった。
・(これまたずっとお話したかった)@kaorun5さんとお話する機会があった。

◇10月
・「AgileTourOsaka2011」に参加してLTをする。伝えようとすることで深く考えることができるリズムができる。
・結婚7周年。(子供も一緒に)3人での結婚記念日。
・「RxTstudy」(第2回)に参加して話をする。これは(イベント自体の)準備期間がほとんど無い中でよく開催することができたと思う。

◇11月
・「スライド制作向上会議」に参加した。これまで参加した勉強会とは参加層が違って色々な話ができて面白かった。
・社内でやっているランチ勉強会に参加し始める。

◇12月
・社内で「インセプチョンデッキ」のワークショップをやってみる。
・社内でRails勉強会を始める。(参加人数はこの時点で2人。このエントリ時点で3人だけど)
・息子の1歳の誕生日。なんとかここまで元気でいてくれて嬉しい。
・Redmine社内セミナーを(大阪で)開催する。予想より参加者がいてくれて良かった。


　2011年は(特に後半から)勉強会ラッシュでした。
　さらにありがたいことにそこで色々と話す機会を得ることができて、自分の考えや「これからやっていきたいこと」を深く考えることもできました。
＃絡んでいただいた皆様、ありがとうございました！

　社内でも読書会、ランチ勉強会、Rails勉強会などに参加することができて、少しでも変わっていけることができれば…と思ってます(まだまだ巻き込み力が足りないですが)。

　プライベートな面では引越をしたり、子供中心の生活に(一部は)なったりして、時間の使い方を効率的にしたり、取捨選択することが今まで以上に大事になってきました。

　2012年は(たぶん)今やっているプロダクトが一区切りを迎えることで、次のステージに行くことになると思います。
　そのステージが今の継続なのか、違う場所なのか･･･は分かりませんが。
　　
　その辺の変化もアクティブに楽しんで行きますので、皆さん、よろしくお願いします。

　Redmine Advent Calendar jp 2011の25日目になります。

　余談。
　本場のAdvent Calendarは「24日まで」を窓を開けていくことでクリスマスを祝うそうです。
　一方、【技術系】Advent Calendarは「25日」まで書くことが多いようです。

　というわけでトリなわけですが、相応しい壮大な話ではなく「チームへのRedmineの効果」について書いてみます。


◆普段よく言っている「Redmineの効果」
　先日、社内で「Redmineを活用したタスク管理改善セミナー」というのをしました。

　Redmineの簡単な紹介から始まり、事例紹介を交えてそこから得た自分なりのメリットやTips、考え方をお話しました。
　後半は参加者の方と「こんなことで困っていませんか？」などのディスカッションをしました。

　その中で「Redmineを使った効果はどういうものがありますか？」と質問がありました。

　私はたいがい…
「Redmineは【見える化】【トレーサビリティ】【開発リズム】を強化してくれるツールです」
　…と答えています。

＃普段から言っている「ツールを入れることが大事ではなく、そのプロセスやマインドを変えていくことが大事」も合わせて言います。

　最近はそこに「教育に伴うチーム力向上の効果もあるかも？」と思い始めました。
＃前置きが長かったですが･･･

◆教育効果があると思ったシーン
　今のチームには割と(この業界の)経験年数が少ない方もいるのですが以下のような変化が出てきました。
1：チケットの書き方が(良いレベルで)揃ってきた
2：(チケットに書く)設計やそれまでの経緯を共有することができて、設計の技術が上がってきた
3：コードレビューの結果を共有することができて、実装のレベルが上がってきた

【1：チケットの書き方が揃ってきた】
　親チケットに要求をプロダクトオーナーが中心となって書いています。
　その要求に対し、どう作るか？と言った子チケットは担当するメンバーがそれぞれ自分で考えるようになっています。

　最初の頃はそのチケットの粒度が大きすぎたり、内容が抽象的なこともありました。
　また(粒度が大きすぎることから)予定工数の精度が低いこともありました。

　最初はそんな状況でも、イテレーションを繰り返していくうちに、他のチケットの(良い)粒度を参考にし、(自分が書いた粒度が大きいチケットを)苦労しながら片付け、それをふりかえることで、分かりやすいチケットの書き方を習得していったように思います。
　ここで言う「分かりやすい」とは(自分以外にも)チームが見ても分かりやすい･･･ということです。

　チームが見ても分かりやすい･･･ということはチケットの引き渡しをやりやすいということにもなります。

【2：設計の技術が上がってきた】
　1はチケットの書き方の粒度のお話ですが、こちらはチケットに書く内容の話です。

　チケットに「この設計はどういう考えで、ここに至ったか･･･」を書くことがあります。
　特に複雑な場合、議論した場合には「A案、B案、C案と考えたけど○○な理由でB案で行く」という風に書くこともあります。

　ちなみに「設計書」と言われるドキュメントには「どういう設計になっているか？」は書かれていますが、「なぜこれになったか？」はあまり書かれていないと思います。
　それ故に次にその機能を修正する際に余計なリソースがかかっているように思います。

　そういうチケットを(担当すること)で、設計の仕方や思考の経緯を学ぶことで設計の技術を上がってきたように思います。

【3：実装のレベルが上がってきた】
　コードレビューはRedmine Code Review プラグインを使っています。

　それまでのやり方･･･コードをプリントアウトして、とか、(コードは画面上でも)レビュー指摘内容はExcelに書く･･･に比べると(効率が良くなっていますし)、指摘内容の共有をしやすくなっています。
　そしてレビュー指摘がチケット登録されるので、どう対応したか？まで共有しやすくなっています。
　そのため若手や新しく入った方が(レビュー指摘をされやすい)コードを書かないようになってきました。

　またそうなることで(コードの)レビューアの負担も軽くなった、より有効に時間を使うことができます。


　チーム構成やその入れ替わりの頻度などによっては、Redmine(ITS全般でも同じことが言えますが)のこういう側面に着目してみても、使うことによるメリットは大きいと思います。

勉強会やセミナーで作ったパワポをPDF化する時に「primoPDF」を使っています。
※参考：priomoPDFの公式ページ
　.NET Framework 2.0 以上が必要かつWindows専用ですが、無料ですので。
　で、その「primoPDF」のちょっとしたTipsを2つほど書きます。


◆1：変換時の余白の調整方法
パワポをデフォルトのままPrimoPDFでPDFに変換をすると画像1のように、周囲に余白が残ってしまいます。
※元のパワポはもちろん周囲に余白はありません。

　周囲に余分な余白があるとイマイチですよね。
　というわけで、これを画像2のようにする設定です。

【設定】
パワーポイントのスライドの縦/横を入れ替えた数値にします。
デフォルトなら以下のように設定すればOKです。

参考：PrimoPDFでPowerPointファイルをPDF化する際に余白を消す方法@msakaiさんのマイページ

◆2：文字の欠落の防止
　最近バージョンアップして4.1にしたところ、(いくつかのスライドで)文字が欠落するようになりました。
　何度やっても同じスライドの同じ文字で欠落します。





　Google先生に以下のサイトを教えてもらいました。
参考：PrimoPDFの新バージョンにおける文字化け対応について＠PDF無料活用クラブ

　それの対応方法は以下のサイトにあるように…

(1) 「スタート」→「コントロールパネル」→「プリンタとFAX」でPrimoPDFのドライバをクリック。
(2) メニューから「プリンタ」→「印刷設定」で、「レイアウト」タグ内、「詳細設定」をクリック。
(3) 「Primo PDF詳細オプション画面」がオープンするので、「ドキュメントのオプション」→「PostScript Options」→「True Type Font Download Option」をOutlineに。

　以上です。

　エントリ「WindowsでのRails3環境構築」の続き･･･というか、エラーが発生したので、それの備忘録です。

◆現象
　irb、rails console を実行した際に以下のようなエラーが発生する

･･･Ruby193/lib/ruby/site_ruby/1.9.1/rbreadline.rb:2111:in `expand_path': non-absolute home (ArgumentError)

◆対処法
　ほぼそのまま「◆参考」のブログの通りでした。
　私の場合は環境変数HOMEを削除すれば無事動きました。

　Cygwinはちょっと試しに入れてみたのですが、使っていないでこの際キレイにしておいた方が良いと思っています。

◆参考
Ruby irb　Windowsのエラー対処法＠Maorin Blog

◆余談
　ちょうどペアプロしている最中にこの現象に出くわしました。
　ペア相手は普通に動いていたので「(Railsが悪いわけでなく)自分の環境が原因だろう」と早く切り分けができました。

　先日、社内で「インセプチョンデッキ」のワークショップをやってみました。

　※社内SNSでの募集期間が1週間も無かったのですが、10人強の方が参加してくれました。参加者の皆様、ありがとうございました。

◆インセプションデッキとは？
詳しくは「アジャイルサムライ」や色々なブログで紹介されていますので、そちらを。

◆ワークショップの内容
　定時後に約2時間で行いました。

　インセプションデッキの説明を行った後、提示する架空のシステムについてグループワークを行いました。
　グループは3つに別れ、「やならないことはなにか？」と「トレードオフスライダー」を話し合って、発表してもらいました。

　休憩を挟んで個人ワークです。
　それぞれの（今or過去の)プロジェクトのインセプションデッキを作ってもらうことにしました。
　主に「パッケージデザイン」と「エレベータピッチ」を作って発表してもらいました。

　これは社内ということもあり、包み隠さず良い感じの発表が続いたように思いました。
　この辺は(部門は違えど)コンテキストが共有できている部分もある点かな？と感じました。

◆自分なりに考えたインセプションデッキの気づき
何度か作ってみたり、今回のワークショップにあたって思ったことです。
※読み返してみるとこちらのエントリで書いたこととほぼ同じだったのですが…

ウォータフォール開発でも使える
　「インセプションデッキ」は「アジャイル開発」の文脈で語られる/使われることが多いと思います。
　しかし、アジャイルな開発以外でも、十分適用できるものだと思っています。
　例えば、弊社でも「プロジェクト計画書」「プロジェクト憲章」を作りますが、それとインセプションデッキは(表現の仕方は違いますが)同じようなことを伝えてようとしていると感じるためです。

意外と(自分もチームも)分かっていない
　実際に(自分の取り組んでいるPJについて)作ろうと、いくつかの質問に取りかかると「あれ？これってどうなんだろう？？」と思うことがあります。
　特に途中参加したり、大きなPJだったりすると余計に顕著かもしれません。

　チーム全員が同じような答えになるかと言うとそうでもなく、(エレベータピッチなどを書くと)少しずつ違った形になったりして、それぞれの想いが見えてきます。

10個もできないよ！！
　インセプションデッキは10個の質問で構成されています。
　「全て」をチーム「全員」でやろうとするとやはり時間がかかります。

　そのような場合、2、3つを選んでやっても良いと思っています。
※もちろん全てを関係者全員で出来るのが理想ですが。

　今のところのオススメだと思うのは…
・エレベータピッチを作る
・何を諦めるのかはっきりさせる(トレードオフスライダー)
　…辺りです。

　またプロジェクトの途中では…
・やらないことリストを作る
・夜も眠れなくなる問題はなんだろう？
　…あたりも良いと思います。

大事なのは･･･
　インセプションデッキは1回作って終わりでは無いと思います。

　継続的に、PJの状況が変化したら、インセプションデッキを確認して更新することで、より「PJの認識を合わせ、何を期待するか？」という点で効果があるように思います。
　そのためにも(壁に張り出すなど、手段は色々ですが)…
「あぁ自分達はこのために、こんな方法で、このPJを進めているんだ」
　…を意識するのが大事かと思います。
※ロッカーの奥深くのキングファイルに入れてまま、とか、ファイルサーバの奥深いフォルダで、最終更新日がPJの開始日･･･なんてことのないようにしたいです。

　Redmine Advent Calendar jp 2011の10日目になります。

　私は(プラグインをガリガリ作ったりしてないので)「自分達のチームでの使い方」をいくつか紹介します。


◆コンテキスト
・チーム：東京と大阪で別れて10人ちょっと
・作っているモノ：社内向けのFWや色々なツール群
・Redmine以外に使っている主なツール：Jenkins、SVN、youRoom

◆1:親子チケットの使い方
※これは「RxTstudy第2回でお話した内容」が元になっています。
　「親チケット」を「機能(feature)」、「子チケット」を(そのfeatureを実現する)「タスク」として使っています。
　親チケットには以下のようなテンプレートに沿って書いています。

【背景】
※その機能の背景など。
　要件定義的なもの。チケット起票の経緯など。
【ユーザーメリット】
【機能スペック】
【影響範囲】
【テスト時確認内容】

　ここまで書いていると、設計や実装の方針に迷った時などに「そもそもこれが誰にとってどんな風に嬉しいのか？」ということがぶれることなく開発に集中できます。

　またチームの進捗を見る場合にも(バーンダウンチャートと併用して)親チケットで見ています。
　具体的には「親チケットのみを表示する」カスタムクエリを作っています。

　親チケットの進捗率は、子チケットのステータス(と進捗率)に連動しているので(メンバーが親チケットを更新する手間なく)確認できます。

◆2：レビューアの話
　2つ目は(これも第2回のRxTstudyでお話した内容ですが)「レビュー」の話です。

　「ステータス」にデフォルトでは"レビュー中である"ことを知らせるステータスがありません。
　これをどう表現するのが良いか？と考えました。

　(今のところ)チームでは以下のように運用しています。
【準備】
1：カスタムフィールド「レビューア」を(リスト形式で)設定
　リスト内容はチームメンバー
2：ステータスに"レビュー待ち"を追加
3：カスタムクエリで「レビュー待ち一覧」(ステータスが"レビュー待ち")を用意

【運用】
　チケットの担当者が(コードレビューが可能になれば)ステータスを"レビュー待ち"にします。
　そして「レビューア」にレビューして欲しいメンバーを選択します。

　「担当者」を(レビューする際に)レビューアに変更して、レビューが終わったらまた元に戻す…という運用も考えました。
　ただ、それでは自分のチケットの行き先が分からなくなりますし、また「自分のチケット」に対するコミット感が失われてしまうのでは？と思い、先のような運用にしました。

　「担当者」を変えないことで、担当者が(自分のチケットを楽に追うことができ)レビューアに対して「滞留してるんだ、早くレビューしてくださいよ〜」を声をかけやすくなります。
※そんなことしなくてもレビューが消化できるのが良いのですが…

　レビューアにとっても「自分のチケット」と混ざることはないので、分かりやすくなります。

◆プライベートチケットの話
　3つ目は(今のメインのチームではありませんが)別で使っている所で持った感想です。

　「前略、private issue 使ってみました。あるいはITSの黒魔術とは何か」(＠ハードコイルド・ワンダーランド)を読んで、(黒魔術的な面では同意の上で)「こういう時、プライベートチケットは有効かも？」と思いました。

　それは(前述した)親チケットなどで機能仕様などを書いている途中、(何らかの理由で)作業を中断する場合に「プライベートチケットとして」使うのはどうだろう？ということです。
　(途中かどうかメンバーには一見して分からないので)公開されていると、それを見たメンバーから意見やツッコミが入ったりします。書いている側は「いや、まだそれ途中なので･･･」となるので、それを防ぐためにプライベートチケットを使ってみてはどうだろう？と思いました。

◆RxTstudy
　最後に宣伝です。「RxTstudy」というRedmineやタスク管理を考える勉強会が大阪にあります。
　スタッフの1人としてお手伝いしています。
※過去2回の内容などはこちらで。

　その第3回が(来年ですが)2012年2月4日(土)にあります(ATND)。

　充実した内容になるかと思いますので、この時期に関西に来る方は参加してみてはいかがでしょうか？


　次は@suerさんです。よろしくお願いします。

　今のチームのJenkins「さん」とは約2年位の付き合いです。
＃日本Jenkinsユーザー会はこちら。

　私はよく「Jenkinsさんが怒ってるで〜」と「さん」付けで呼んだりしています。
＃ITSではRedmineを使っているのですが、それは「さん」付けではありません。

◆なぜかな？
　あの執事の風貌も関係ありますが、シンプルにJenkinsさんをチームメンバーの一員として思っているからだと思います(少し痛いですが・苦笑)。
　
　ただマジメに、それくらいチームに無くてはならないのです。

　人力だと時間がかかる(そしてミスもしやすい)チェックやテストなどの作業を何回、何十回もしてくれます。
　また夜遅く/朝早くなどこれまた人では難しい時間でも平気です。

　そういうのをやってくれるだけでなく、結果も「この辺がおかしいですよ」と割と親切に教えてくれたりします。

◆感覚的なものですが･･･
　うまくCIが回っているチームほど、Jenkinsさんをチームの一員と思っているように感じます。
　うまく使いこなせていない所は「Jenkins設定めんどくせ」「Jenkinsがエラーを通知しているけど、修正は後で良いよね」というようなおざなりな感じだったりします。
＃Jenkinsではなく「CI」を活用しきれていないのですが…

◆そんなJenkinsさんの勉強会があります
　第2回大阪Jenkins勉強会が…来年…2012年2月10日に開催予定です。
　まだ先の話ですがご興味のある方は覗いてみてはいかがでしょうか？