2013年05月13日

DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン 」を開催しました!

 DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン 」を開催しました。
#参加してくれた皆さん、会場提供してくれた楽天さん、大阪まで来ていただきお話してくれた和田卓人(@t_wada)さん、和田省二さん、ありがとうございました!

◆どんな内容だったか?
 詳しく書いている参加エントリを参加登録ページにまとめていますのでそちらをご覧ください。

◆きっかけ
 きっかけはDevLOVEとDevLOVE関西でコラボした「SQLアンチパターン・レトロスペクティブ関西」でした。
 その参加エントリにも書いていますが「1回で終わるのはもったいない。今度は和田さんをお呼びして関西でしたい」という声からスタートしました。

◆諸々の感想
 前回より(スタッフの負担は軽く)和田さんの講演をゆっくり聴いて、理解を深めることができました。

 「1部:データベース論理設計のアンチパターン」の内容は、ほとんど見たことがある、もしくは、やったことがあるというものばかりでした。
 現場のレビューでこの部分だけでもカバーすることができれば、ずいぶんひどい状況は少しでも減るのでは?と思いました。

 ダイアログでは(特に3人1組にしてから)様々なコンテキストから色々な意見が出て、しかもそれが言い放しにならず、そこからまた別の話に飛び火して・・・と盛り上がっていました。

 中でも印象的だったのは「RDBありきの考え方をするRDBネイティブと、必要になったらRDBを用意するNoSQLネイティブの世代間ギャップが出てきているのではないか?」という話でした。
 また和田省二さんがお話されていた「技術の継承問題」もDevLOVE関西のようなコミュニティの1つの目的とも考えているので、興味深く感じました。

 (急遽やることになった)懇親会でも半分以上の方が参加してくれ、これまた本編以上に色々な話が出て盛り上がりました。

#DevLOVE関西のアイデアや検討している勉強会はFacebookのグループDoorkeeperのコミュニティで公開していますので、興味がある方はご参加ください。

posted by yohhatu at 07:31 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2013年02月03日

「Scrum Boot Camp 島根」に行ってきました

ScrumBootCampShimane_1.jpg

 ご縁があって2013年2月に「Scrum Boot Camp 島根」に西村直人(@nawoto)さん、永瀬美穂(@miholovesq)さんと共に行ってきました。

 ScrumBootCampは1回目は神戸で参加者、2回目は大阪で主催者、そして今回が3回目です。

◆感想
 「島根の人は熱かった!」の一言です!
 それぞれ背景や目的は違いますが、「もっと上手く開発をしたい」という想いをヒシヒシ感じました。
#その熱さをより大きくしたメイン講師の@nawotoさんもすごかったです。

 私もちょっとしたワークショップをやったり、フリートークで一緒に質問に答えたりしていました。
 
 毎回思うのが(参加者の中で)「この中で1番、自分が学んだことが多かった」ということです(きっと全員想っているでしょうが)。
 @nawotoさんが話している時、「自分ならこういう風に話すなぁ」とか「こういう伝え方もあるんだ」とたくさんあり、また@miholovesqさんとはワークショップのコツや自分の状況を話して意見交換すをしたり。もちろん参加者の方からの質問からも色々学ぶことが多くありました。

 懇親会での本編の熱気以上に熱く、至る所で車座が出来て話し込んでいました。

 もう1つ嬉しかったことはAgileJapan2012の「アジャイルサムライ読書会」のセッションで知り合ったUbata(@jaVuBax)さんと再会できて色々刺激を受けたことです。

 このScrumBootCampの経験、体験が少しでも変わることの一歩になれば・・・と思っています。

◆補足
 弊社が島根に支社を開設するという話にも何人かの方に興味を持ってもらったりしたのも嬉しかったです。

◆最後に
 参加者のみなさん、そしてこんな場を用意していただいた事務局の方々、本当にありがとうございました!
 またお会いできるのを楽しみにしています。

ScrumBootCampShimane_2.jpg
posted by yohhatu at 13:25 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2013年01月24日

プロジェクト完了報告書の問題

※この記事は新しいブログに移行しました。

移行先は【プロジェクト完了報告書の問題 – サウスポーなエンジニアの独り言】です。
タグ:改善
posted by yohhatu at 08:18 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年12月10日

[仕事]Professionalと思う3つの振る舞い

 DevLOVE Advent Calendar 2012 “Professional”に投稿しました。

***********************

◆「自分にとってのProfessional」とは?

 私が考えているProfessionalの定義は以下の3つをやっている、もしくは、やろうとしている人です。
 それは「Whyを考え続ける」「厳しいことを言える」「ベストを尽くす」です。

 続きはDevLOVE Advent Calendar 2012 “Professional”のエントリでお読みください。

***********************

 私以外にも多くの方が「自分にとってのProfessional」というテーマで書いています(し、これからも書いてくれるでしょう)。
 何が正解・・・というのはありませんが、それぞれの考え方にふれることで何か新しい発見があるかもしれません。
タグ:考え方 Devlove
posted by yohhatu at 08:09 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年11月20日

[仕事]Winodws7の「スタートアップ」と「送る」フォルダの場所

 Winodws7を使い始めてだいぶ経ちますが、未だにちょくちょく調べているので備忘録です。

***********************

◆「スタートアップ」フォルダの場所
 起動時に一緒に起動しておきたいアプリケーションがちょくちょくあります。
 で、それを設定する場所です。
OSのインストールドライブ
 └ユーザー(Users)
  └(ユーザー名)
   └AppData ※初期状態では非表示
    └Roaming
     └Microsoft
      └Windows
       └スタートメニュー(Start Menu)
        └プログラム(Programs)
         └スタートアップ(Startup)

※AppDataの表示手順
1:エクスプローラーの「整理」→「フォルダーと検索のオプション」を選択
2:「表示」タブの「隠しファイル、隠しフォルダー、及び隠しドライブを表示する」を選択

◆「送る」フォルダの場所
 ついでに「送る」(SendoTo)もよく調べるので。
OSのインストールドライブ
 └ユーザー(Users)
  └(ユーザー名)
   └AppData ※初期状態では非表示
    └Roaming
     └Microsoft
      └Windows
       └SendTo

***********************

 UIが大幅に変わるWinodws8でもまた色々調べることになるんだろうなぁ
posted by yohhatu at 07:13 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年10月10日

社内勉強会の難しさ

※この記事は新しいブログに移行しました。

移行先は【社内勉強会の難しさ – サウスポーなエンジニアの独り言】です。
タグ:勉強会
posted by yohhatu at 08:29 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年10月09日

えらくなっていきたいか?

 ずいぶん前に書いたまま放置していたのを(ちょっと書き足して)アップします。

 組織において「えらくなっていきたいか?」という話です。

***********************

◆えらくなりたいか?の問いに対して
 一時期「昇格/昇級したいか?」という問いにNoと答えていました。
#前職の話です。
 
 なぜなら「上の人が楽しそうに、やりがいを持って仕事をしているように思えなかった」からです。

 自分がやりたい仕事でないのか、責任やプレッシャーの割に(評価された結果の)給料が低いのか分かりません。
 が、目を輝かせて「今の自分の仕事が楽しい/やりがいがある!」と伝える(伝えなくても態度で示す)人が少なかったように思います。
#恵まれたことに(一番お世話になった)直属のボスは上記に当てはまらない人でした。

 (現場や若手から見て)管理職や上司が魅力的に見えない組織は、新しい力も出てこなく、新陳代謝も起きず、 新しい変化にも対応できず、結果として若く有望な方は出て行ってしまうし・・・で、良いことは何もありません。

◆最近の考え
 最近(※2011年の冬頃)は少し変わってきていて・・・
「その組織で自分がしたいことをやりやすく、横槍を入れられずにやる(=自分でハンドルを握る)には、えらくなって上に行くのが一番の近道」
 ・・・と思うようになっていました。
#この話の前提には「その組織で頑張るなら」がありますが。

 えらくなることを目的としてとらえると(魅力が無いように映っているので)イマイチ前向きになれませんが、「自分がやりたいことするため」の手段として見ると、そう悪い話では無いと感じたからです。

***********************

 それからしばらくして、ハンドルを握るまでの時間の長さに待ちきれずに移る※ことになったのですが。
[仕事]会社を移ることになりました
posted by yohhatu at 07:38 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年10月02日

自分の転職活動

 2012年7月に今の会社に入社しました。
 その活動や考え方などを軽く書いておきます。

#宣伝
 この話は機会があれば2012年11月10日(土)のDevLOVE関西〜Drive〜でも少しお話する予定です。
 他にも多くのスピーカーが登壇予定なので、ぜひお越しください!
#宣伝終わり


***********************

◆転職や市場価値に対する考え方
 「自分の市場価値」を知っておきたいという願望がありました。
 その方法の1つとしてキャリアの公開をLinkedInやリクナビなどの転職サイトで行っていました。

 2012年2月頃にプロジェクトの区切りがついたので、職務経歴書やスキルの棚卸しを行い、上記のサイトなどに公開しました。

 ここでの「市場価値」ですが、たいそうなことではなく「(文章や一部のアウトプットを見た上で)どのような人/組織から自分は声がかかるのか?」また「どのような見せ方にすれば自分が望む人/組織にささるのか?」というイメージで使っています。

◆企業のオファー
 しばらくして、それらのサイトを通じていくつかオファーが来ました。

 前職と同様のSIerや派遣会社からのオファー、「へぇこんなところからも来るんだぁ」という企業からもありました。
 (東京に拠点を置いていたWeb系やゲーム会社が)BCPなどの背景で大阪に拠点を作ろうとしていた時期と重なっていたようです(たぶん今も)。
 
◆転職エージェント
 転職エージェントについては、肯定、否定双方の意見がありますが、私は積極的に活用しました。
 理由は2つです。

1:これまでの成功体験(良かった経験)
 これまで接した転職エージェントの方々は良い人/結果が多く、「最初から毛嫌いすることはない」とこれまでの経験上、分かっていました。

 (時々言われているように)「何でもかんでも薦めてくる」エージェントの方もいましたが、そのような場合でも「自分の意見、軸を持った上で、優先順位を明確」にしていれば流されることはなく「No!」と言えます。
#実際、とあるエージェントさんとはそう言っているうちに音信不通になってしまいましたが。

2:情報が豊富だった。
 ソーシャル転職という話もありますが、エージェントしか(知り合えない)情報もまだまだあると思います。また多くの転職希望者やそういうシーンを見ており目が肥えていることも多いです。
#地域差や業界のなども関係あると思いますが。

 それと自分の年齢、キャリア、したいことが「ニッチ」と思っていたので、情報のチャネルは少ないよりは多い方が良いだろうと判断しました。

 繰り返しになりますが、エージェントは、それなりに多くの応募者、企業の採用担当者と接しており、真摯に良いアドバイスをもらえる良い方と巡り会うことができれば、力強い味方になります。

 力強い味方になるかどうかの1つに「○○というのはどうですかね?」と尋ねた時、そのエージェントが担当している企業だとしても・・・
「あなたには○○という点で合わないと思うので、お勧めはしません」
 ・・・と面と向かって言ってくれるというのがありました。

◆TwitterやFacebookなどのソーシャル転職について
 Twitterなどをきっかけに知り合った方から「うちを受けてみない?」と声をかけていただき「あぁ実際にこういう転職がポピュラーになってきたんだなぁ」とも実感しました。
#昔からあったと思いますが、もっと(リアルな人脈のみなどの)もう少し狭い範囲の出来事だったと思います。

 ソーシャルな関係の中で「この人と(組織で)働きたい」というのもありましたが、地理的な関係などで実現には至りませんでしたが、声をかけてもらったのは(お世辞だとしても)嬉しかったですし、勇気づけられました。
#ありがとうございました!

◆実際に動いてみて
 改めて「自分の強みや弱み」(と思っていること)が、それぞれのフィルターから見るとどのように見える/評価されるのかが分かって、面白く良い経験でした。

 在職中で時間が限られていたこと、自分なりに「こうしたい」という譲れない部分が明確でしたので、会う前に質問をしておき、返答が「もっと話を聴いてみたい」と思う人/企業と会うようにしました。

 ちなみに「一緒に働く人(チームとなる人)と話をしたい」と伝えて会わせてもらうこともしました。
#自分の中で下手したら上司よりも大事なことなのですが、なかなかそういうことをリクエストする人はいないようで驚かれることが多かったです

***********************

 転職をするかは別として「自分のキャリアをどうしたいのか?」という棚卸し、「したいことに対する自分の市場価値はどのようなものなのか?」などを定期的に観測してみると面白いですよ。
タグ:考察
posted by yohhatu at 08:20 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年09月18日

2012年08月11日

2012年06月26日

会社を移ることになりました

 2012年6月末で会社を移ることになりました。
 (何度か転職をしているのですが)今のところ、社会人経験の中で一番長く所属していた会社になっていました。

***********************

◆思い出1:Rubyとの出会い
 入社後しばらくして、(弊社では)お客様向けとして開発実績の無かったRuby(とRuby on Rails)を使いシステムを構築し、(お客様に)良い評価をもらったことです。
※1システムだけでなく、確か計4つほど作ったと思います。

 チームはRuby未経験者ばかりだったので、当時(Rubyで)社内SNSを作っていた@kuranukiさんや@nsgcさんが助っ人で来てくれ、合宿形式でペアプロをしたのも良い思い出です。

◆思い出2:スクラムとの出会い
 直近で長く携わった社内向けのプロジェクトも印象に残っています。

 この時のチームは(ボスを筆頭に)本当に仕事に対する姿勢が素晴らしいもので(もちろん技術力もですが)、私も本当に多くのものを得ることができました。
#チームを抜ける時には「卒業証書」をもらったりもしました(笑)。

 このチームでは「ここぞとばかりに」色々チャレンジしました。
 Redmine、Jenkins、テストコード、そしてファシリテーションやスクラムなどなど…。
  
 RxTstudyに携われたりスクラム道な方々と出会えたりする機会にもつながりました。
 またそれらをきっかけにして社内外で人前で発表するという貴重な経験もできました。

 アジャイル(スクラム)については「教科書的にはこうだけど、自分達のコンテキストでは…」という点が多く、大きい壁となり、その度チームで話し合って、自分達なりの開発のやり方とユーザへ価値を届けるベストな方法を模索し続けました。
 これも良い経験でした。

◆思い出3:社内コミュニティ
 アジャイルサムライの道場(社内読書会)ランチ勉強会を通じて、(サラリーマンSE色の薄い)前向きなエンジニアと出会えたことです。

 「勉強会」が全てではありませんが、こういうのが積極的に開催されていて、参加者も多い組織はエンジニアにとって魅力的だと思います。
 (夢物語な感じですが)「毎日どこかのセミナールームで(社内外を問わず)勉強会をやっていて、色々な人がやってきて交流ができる環境にしたい」と思っていたりもしました。

 この考えに影響を与えた方として、入社した当時に(社内SNSを通じて)出会った@papandaさんがいます。
 今ではDevLOVE関西でつながっていたりします。 

◆これから
 相変わらず大阪でエンジニアをしています。
 新しい職場のことはまた折を見て書こうと思います。

 これまでの勉強会にも参加したいですし、新しい技術要素に出会うと思うので、その界隈の勉強会などにも参加すると思います。
 よろしくお願いします。

***********************

 余談ですが、コミュニティの知人には「どこに行くの?」よりも「(弊社を使っている)勉強会やセミナーの会場確保は(これからも)大丈夫?」と聞かれることが多かったです。
 幸いなことにそれぞれのコミュニティに弊社社員が(スタッフ的に)いるので会場を使うことは(社内規則が変わらない限り)大丈夫なのでご安心ください。
posted by yohhatu at 08:20 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年06月19日

[仕事]「会社を移る」ことと「部署・プロジェクトを移る」こと

 主に月末/月初に「退職します(した)」エントリ、「入社します(した)」エントリやつぶやきがちょくちょく見受けられます。

**********************

 弊社からも新天地へ行った方もたくさんいて、中には「おぉ、あの人もいなくなるのか…寂しいなぁ」という方もいます。
 ただ、たいがいそういう人とはTwitterやFacebookなどでつながっていたり、ブログを読んでいるので「元気にやっているなぁ」と分かります。
#そしてそれを励みに「自分も…」と思ったりします。

 ふと…
「同じ会社に所属していても、部署が変われば、日常的に言葉を交わすことは少なくなることがある。それって会社を移るのとそれほど変わらないのでは?」
 …と思ったりしました。
#もちろん事務手続きなどは別で。

 部署の異動以外でも、「自社での開発」から「お客様常駐(そのまま数ヶ月帰ってこない)」のパターンだと(同じ部署でも)言葉を交わすことは少なくなります。

 ただ、食堂で見かけたり、エレベータで乗り合わせたりしたら「久しぶり。最近どうよ?」てな感じで言葉を交わします。
 で、それは冒頭に書いたように(会社を移った人が)TwitterやFacebookで興味深い事をつぶやいていたり、書いているのを見かけたら「久しぶり。最近どうよ?」と声をかけるのと感覚的には一緒だったりします。

 部署異動したり、プロジェクトを移ると、(会社的に共通な)お作法以外に、ローカルルールや独自のやり方があり、けっこう覚えることもそれなりにあります。
#時にはそれまでのお作法が「間違い」と言われることもあったり(苦笑)

 また「知った顔」という意味でも、(プロジェクトによっては)ほとんど初対面ということもあり、結局(あまり価値の高くない)「まずはお互い知る」というチームビルディングにパワーが必要な状況も多くあります。
#組織としての成熟が足りないとも言えますが、そこそこ普通な光景だと思ったりします。

 「会社を移るとそれまでの人脈が…」という方もいますが、お互いが必要と思っていれば会社を移っても情報交換やディスカッションは続けます。
 むしろ、違うフィールドで新しい情報や視点を持ってディスカッションできるようになるので、刺激になります。
#「会社」という共通項以外でやり取りできないのであれば、あまり太い関係でもないと思いますし。
**********************

 こういう感覚は、どの程度「会社」「部署」などの組織を拠り所としているか…によりますが、自分の場合はこんな感じだなぁと思ったわけです。
タグ:考察
posted by yohhatu at 07:42 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年05月11日

[雑多]「マシュマロ・チャレンジ」を体験しました。

 GWの谷間に「マシュマロ・チャレンジ」を体験しました。

 ちょうど先日、NHKのスーパープレゼンテーションで放送されたのでご存知の方もいるのではないでしょうか?

***********************

◆「マシュマロ・チャレンジ」とは?
 「タイムボックス」や「チームビルディング」などについて色々な学びを得る事が出来るワークショップです。

 使うのは1チーム毎に以下のものです。
1:パスタ20本(もちろん茹でていない)
2:マシュマロ
3:マスキングテープと紐を90cmずつ

 ルールは制限時間内にこれらの道具を使いながら、パスタでタワーを立てその上にマシュマロを乗せ、高さを競うというものです。

 詳しくは以下のブログに色々書いています。
 ただし、ネタバレ(このワークショップの色々な狙いや気づき)も書かれているので「いずれ(自分で)それを体験してみたい」という人は見ない方が良いと思います。
「チームとタワーを創造せよ!マシュマロチャレンジでチームビルディング #sgt2011 #CSPO」
TED


◆やってみた
 進行は原田(@haradakiro)さんにお願いしました。
 そしてメンバーは「スクラム道場関西版」(仮)の11人。
#「スクラム道場関西版」についてはまた今度書きます。

 比較的こういうのに慣れている、そして、やっていくメンバーだったので、ゴールとして「体験することで、自分達が進行できるようにする」というのもありました。

 3チームに分かれて開始しました。
 私のチームは全員が仮にも(ペーパーでも・笑)「認定スクラムマスター」でした。

 そして1回戦は3チームともタワーを建てることができました。
 ↓こんな感じです。
DSC_0229.jpg


 しかし、2回戦は(少なくとも自分は)完全にこのワークショップの狙いにハマって、見事に失敗しました(記録ナシ)。

◆気づいたこと
・ちょっとした状況でこんな簡単に視野が狭くなるのかってこと。
・視野が狭くなったら、チームがこんな簡単に機能しなくのかってこと。
・「なぜうまく行ったのか?そしてそれは再現可能なのか?」を共有するのが難しいってこと。
・小さくても良いから、ゴールに近い部品から作ることが大事ってこと。
・時間はあるだけ使ってしまう(その使い方が有効かどうかに関係なく)ってこと。

 
 ある程度、どんな狙いがあるのか理解していたにも関わらず、他にも色々気づいたことがあり、興味深かったです。
 そして自分達のシステム開発でも同じような状況に良くなっているということも改めて感じました。
***********************

 「ちょっとやってみたい」「体験してみたい」という方がいれば、声をかけてくれると嬉しいです。
posted by yohhatu at 08:32 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年04月05日

[仕事]バーンダウンチャートの疑問を聞いてみた

※この記事は新しいブログに移行しました。

移行先は【バーンダウンチャートの疑問を聞いてみた – サウスポーなエンジニアの独り言】です。
タグ:SCRUM agile
posted by yohhatu at 06:49 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年03月23日

[仕事]仕事と勉強会の源泉の関係

 ここ1年ほどいくつかの勉強会に参加して、時にはスタッフだったり、スピーカーをさせてもらったりした中で「仕事と勉強会の源泉の関係」について感じたことです。

***********************

「今日の勉強会でエネルギーをもらったので、明日からまた現場で頑張れます!」
 …という声を時々聞きます。
 
 (スタッフだったりすると)そういう声は嬉しいのですが、一方で…
【うまく行っていないのに変化しようとしない現場やデスマの現場でエネルギーが切れる(心が折れる)】→【勉強会でエネルギーを補給】→【また日々のしんどい現場で…】→【エネルギー切れたら勉強会へ】
 …という(改善ではない)ループにハマっている感じがする時もあります。

 「(しんどい)仕事をやり切るために勉強会へ参加する」みたいな。
#もちろんこういう方は少ないよ!ってのであれば嬉しいことですが…

 一方、自分はどうだろうか?と考えてみました。
 「勉強会で話したいために仕事で(改善も含めて)楽しんでガンバル」
 ↑が自分のスタイルかなぁと。
#ベースは「オレの話を聞け!」なのかもしれませんが(笑)。

 自分にとって(会社での)仕事で改善を意識し続けてやっている源泉の1つに「(自分が経験して学んだ)アウトプットを話したい」というのがあります。

 もっと言うと、それを伝えた人からの(良い悪い関係なく)フィードバックを得て、もっと良いモノにしていきたいです(そして、それを共有したい)。

 さらにさらに言うと、自分と同じようなことに(不必要に)悩まず、はまらず、本来やりたいことにリソースを集中して、より良い仕事ができるようになれば…と思っています。

 そのためには、(当たり前ですが)上っ面をなぞるようなことでなく、自分が腹落ちしていることを言いたいわけです。
#腹落ちしていなくて、自分が悩んでいてもっと意見を聞きたい場合は、正直に伝えるようにしています。

 (自分で腹落ちするために)漠然とするのでなく、工夫や改善を意識して、「何か伝えるエッセンスがないか?」ということも意識しながらやっているわけです(いつもってわけではないですが)。
***********************

 勉強会やセミナーなどでよく話されるスピーカーの皆さんの(話す)源泉ってどんなんだろうって気になります。
タグ:勉強会 考察
posted by yohhatu at 08:06 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年03月17日

[雑多]「AgileJapan2012」に参加してきました

 「AgileJapan2012」に参加してきました。
#色々準備をされていた(もちろん当日も)スタッフのみなさん、スピーカーのみなさん、ありがとうございました。

 去年は大阪はサテライトだったのですが、今年はメイン会場でした。
 各地からスピーカーが集まり、参加者の数もかなり多くとても熱い内容になりました。

#それでも平日ということもありスーツな方の割合が多かったですが

 私はご縁があって2つのセッションでお話してきました。
 Agile セッション「チケット駆動開発の課題と展望」とChange セッション「現場に続くAgileの道を語ろう〜アジャイルサムライ読書会が変えてきたこと〜」です。

 今回は「チケット駆動開発の課題と展望」での話です。

***********************


 今回は(あえて)「Redmine話」や「チケット駆動開発」を意識しませんでした。
 「チケット駆動開発をどうやったらうまく行くんだろ?」と期待されていたものとは違ったものだったかもしれません。

 ただ「Redmineを入れてチケット駆動開発をしたいんですけど・・・」という相談をちょくちょく受けるのですが…
「どんな風なチームにしたいのですか?Redmineを入れてそれをどう実現したいのですか?」
 …と聞くと「本当にやりたいこと」が実はRedmineで無くてもできることがあったりして「Redmineやチケット駆動開発をやることが目的になっている」事例もけっこうあるなぁと感じていました。
 ですので、今回のスライドのお話にしました。

 いくつかスライドの補足です(当日話したこととかぶるかもしれませんが)。

◆「守」の話
 他のメンバーのチケットの書き方、分割・更新のやり方が自然に目に入る機会が多くなり、チームに広まって行くことがあります。
 フリカエリなどで「分かりやすいと思ったチケットはどれだったか?」などとテーマでディスカッションするとより効果的です。

 理想はツールを介せずに、ノウハウや技術の伝承ができるチーム(組織)です。
 しかしロケーションの違い、その風土が無いなどでも(諦めずに)このような方法でもレベルの底上げのチャレンジができるという話です。 

◆「破」の話
 「改善タスクを行うリソースをどう確保するか?」ですが、チーム全員が改善を好き(得意)ではないですし、そればかりだと本業(お客様へ価値をもたらすシステム)もおろそかになります。

 しかし、改善しないとちょっとしためんどうや不便さがチームのスピード、モチベーションを低下させ、パフォーマンスを奪っていきます。

 スクラムマスターはこういう改善がそれこそメインになりますし、改善が得意なメンバーがいれば(本業のタスクとのバランスで)改善タスクを取ってもらうのも1つの方法です。

 ポイントは(スクラムマスターやプロダクトオーナーを含めた)チームが「改善は必要なタスク」と意識することです。

◆「離」の話
 「これまでがこうだったから・・・」「○○を今まで使っているから…」という理由でチームのパフォーマンスを上げるチャンスを逃さないように・・・というのが言いたかったことです。
 確かにこれまではその方法がベストだったかもしれません。

 でも今ではチームのパフォーマンスも変わって、周囲の状況も変わっているはずです。

 その中で、これまでの方法も含めて「今のチームが一番パフォーマンスを発揮できるやり方」を考えて行く方が(短期的には多少遠回りでも)結果として良い価値を届けることができやすくなると思います。

 コンテキストもそれぞれですし「そんな簡単には・・・具体的にどうしたら・・・」という方もいると思います。
 そんな場合、愚痴を聞くだけかもしれませんが、(もしかすると)何かお力になれるかもしれませんので、お気軽に声をかけてください。

***********************

 ちなみに(各セッションも良かったのですが)自分にとって一番勉強になったのは講師控え室での色々な方とのディスカッションでした。
 正解が無い話題が多い中で「自分はこう思う」を話して、それに対してフィードバックを(ダイレクトに)もらえる時間というのは、スピーカーをするメリットでもあると思います。
タグ:agile
posted by yohhatu at 15:52 | Comment(2) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年02月28日

[仕事]フリカエリ

[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。

***********************

 今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカエリを行い、そこではKPT(Keep/Problem/Try)のフレームワークを使っています。

 やり方はほぼプロジェクトファシリテーション実践編 ふりかえりガイド(※リンク先はPDF)の通りです。

 以下は、今のチームでやっている工夫や気づいたことです。

◆W(分かったこと)を書き出す
 KPTに似たようなフレームワークで「YWT」というものがあります。
#Y(やったこと)・W(わかったこと)・T(次にやること)というもので、弊社ではひょっとするとKPTよりこっちに慣れている方が多いような気も・・・。

 Keep・Problemといった事象やアクションから「感じた」何かがあると思います。
 それを「W(分かったこと)」として書き出します。

 分かっこと自体がTryなどの直接のアクションになることは少なくても、それをさらに深く考えることで別のTryに結びつくこともあります。

◆日常的に書き出す仕組み
 youRoomをコミュニケーションツールとして使っています。
 そこにイテレーション開始時に"あらかじめ"フリカエリ用のスレッドを立てておきます。
 そして、日常の開発などで…
「あっ!これはPかも」
「次はこんなこと(T)したいなぁ」

 …と思えば、すぐに書き込むようにしています。

 イテレーション終了時のフリカエリより先にPの内容によってはすぐに対応できます。
 早く対応した分だけ、チームのパフォーマンスが上がります。
#なかなかチーム全員が開発に集中しているとPへの対応は後回しになりがちですが、そこはスクラムマスターがうまく動くことである程度はカバーできると思います。

◆Problemの深掘り
 これは最近やり始めたことです。

 Pに対してTを書き出しますが、中には・・・
「本当にそれでPは解決する?もう少し深く話した方がいいのでは?」
 ・・・というものもあります。
 例えばPの原因が実は根深かったり、TがPの対処療法にしかなっていない等です。

 このような場合、(KPTが一通り終わった後)新しいホワイトボードにPを中心としたマインドマップを使って深掘りします。

 こうすることで「隠れていた本当のP」や「(Pに対する)より効果的なT」が見えてくることもあります。

(時間の関係で)全てのPを深堀りすることはできないことも多いので、チームが「これでできるのかな?」と半信半疑な雰囲気になっているPを取捨選択する必要があります。

◆ProblemのTry以外にも、チャレンジしたいTryを書く
 (Pとは関係なくても)「こんなことにチャレンジしたい!」という意味のTも書き出すようにしています。

 そしてそれがPJの方向性と合うのであれば、実際にその手を上げたメンバーを中心にして、次のイテレーションなどでやるようにします。

 (サインアップのように)「自分がやりたい!」と手を挙げることで、その質やコミット感が強くなるのが良い点です。

 Pに対するTは(改善ではあるものの)、(内容によっては)「できていないこと」にフォーカスが当たりがちです。
 ですので、前向きにやる…とのが難しいこともあります。

 それとバランスを取るように「チャレンジしたいT」を使ってみると良いと思います。

◆同じProblemが上がっていないかを見る
 同じチームで何度かフリカエリをやっていると…
「あれ、これって前も同じようなPが上がっていなかったっけ?」
 …というシーンが出てくることもあります。

 同じPが出ていると、ひどい場合には、チームの中に「どうせ変わらないし…」という負の感情やマンネリ感が出てしまい、あまり良い状態ではなくなります。

 そこで毎回フリカエリのKPTを(写真などで)残しておき、次のフリカエリでそれを眺めて、同じようなPが上がってないか?を見るようにしています。
 そのようなPがあるなら、その根本原因やTを工夫しないと、また同じ結果になってしまうのでチームで対応を考える…例えば、上に書いた「深堀り」の対象にするなど…必要があります。

◆気づき:暗黙知となったKは減っていく
 同じチームでフリカエリを行なっていると(PやTはそれなりに出ているのですが)Kは少なくなっていきました。
 チームの状態が悪くなったわけではなく、そのKがチームにとって当たり前になり「暗黙知」になったのです。
 そして「あえて書き出すまでもない当たり前のこと」になり、Kとして出ることがなくなったわけです。

 新しいメンバーが入って、そういう暗黙知を「K」として書き出すことで改めて、チームがその良さに気づくということがありました。

***********************

 このように、いくつか工夫はしていますが、最初に上げた「プロジェクトファシリテーション実践編 ふりかえりガイド」に書かれているほぼその通りです。

 大事なのは(リーダーなどを含めた)チーム全員が、そこに書かれている心持ちや姿勢を取ることができるか?ということです。
 その点では、(日常の)朝会に比べると少し難しいかもしれませんが、フリカエリをきっかけにチームが大きく変わることもあるのでチャンレジする価値はあります。
posted by yohhatu at 22:47 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年02月24日

[仕事]朝会と夕会

※この記事は新しいブログに移行しました。

移行先は【朝会と夕会 – サウスポーなエンジニアの独り言】です。
posted by yohhatu at 08:23 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年02月22日

[仕事]「可視化」と「見える化」

※この記事は新しいブログに移行しました。

移行先は【「可視化」と「見える化」 – サウスポーなエンジニアの独り言】です。
posted by yohhatu at 07:56 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年02月20日

[仕事]Jenkinsさんと気軽に友達になってみませんか?

 今のチームではこちらのエントリにも書いたように「Jenkinsさん」はチームの一員・・・と言うほど、色々なことをしてもらっています。

***********************

◆使い始めるのは簡単だけど…
 一方、社内でJenkinsのセミナーなどの出た声を聞いてみると…
「現場で入れてその後、継続して使うのが難しい」
…という声がチラホラ聞こえてきます。

 どうやら「導入すること」は(上司などが「そんな訳の分からないもの入れるな!」と言わない限り難しくないのですが)…
「mavenなどの設定、Jobのメンテナンスが大変そう」
 …と思っているようです。

 そういうチームではリソース(できる人がいないし、仮にいてもそういう余裕がない)も無く…
「継続して使うのは難しい」
 …という判断が多いようです。

◆まずは軽く使い始める
 そんな時に思うのが…
「フルスペックでなくても【段階的に】使い始めてもでも良いのでは?」
 …ということです。

 100点(フルスペック)であればBestですが、何もやっていない0点よりも少しでもやっている方が良いという精神です。

 「構成管理からチェックアウトしてコンパイルエラーが出ないか?」だけでもチェックします。
 これで(別の誰かが)チェックアウトしたら壊れている…ということを早めに見つけることができます。

 次にcheckStyle、PMDなどの静的チェックをやってみます。
 ルールのファイルさえあればすぐに導入できます。
 デフォルトでも良い感じにチェックできます。

 これらが安定して実行されるJobがあるだけで「よろしくない」コードが混入するのを防ぐことができます。
#少なくともコードレビューで「インデントが・・・」なんて指摘はしなくて済みます。

◆静的チェックの次は…
 JUnitやSeleniumのテストはテストコードをいるので、ちょっと置いておくとして、次はデプロイに取り組みます。
#本当はこの時点でテストコードを書き始めてくれると嬉しいのですが…。

 これで常にチーム全員(チーム外の人も)が、動くアプリケーションを常に見ることが自動化できます。
#時々ある「オレの所では見えるんだけど・・・」という状況も少なくなります。

 そして、並行して「見える化」を進めるため(checkStyleなどの)レポートを表示します。

 コードの出来高などもレポートするようにすると「やる気」も出てきます。
 またcheckStyleの結果などがブルーだったりすると「うまく行っている」感が出て、チームのモチベーションアップにもなります。

◆そして自動テストへ…
 ここまで来ると…
「テストの結果も見えると良いよね?」
 …となって、テストコードやSeleniumのシナリオを書きやすくなります。

 この時も「カバレッジ100%じゃないと意味がない」わけでなく、まずは重要なクラスや変更が入りやすいクラスからコードを用意すれば良いと思います。

 今のチームでも、Jenkinsさんに色々やってもらっていますが、最初からいくつものJobやレポートがあったわけではありません。

 使いながら…
「こんなことが自動化できると嬉しいね」
「この情報がレポートで見えると嬉しい」

 …という話が出る度に運用を追加していきました。

***********************

 簡単なJobでも最初は思いの外、なかなかブルーにならないと思います。
 でもそれまで「成功/失敗が分からなかった」ことが「分かる」ようになったことが変化の一歩(改善)です。

 ですので、「大変そうだから」と尻込みせずに、気軽にJenkinsさんと友だちになってみてはいかがでしょうか?
タグ:Jenkins
posted by yohhatu at 23:30 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。