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

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

移行先は【仕事と勉強会の源泉の関係 – サウスポーなエンジニアの独り言】です。

[雑多]RxTstudy第4回に向けて

　AgileJapan2012でも少しだけお話したのでこちらでも宣伝です。

　「RxTstudy」(第4回)が2012年4月21日(土)にあります。
　参加受付はATNDで行なっています。

＃懇親会の出足が毎回いまいちなので、こちらもよろしくお願いします(笑)

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

◆今回の特徴1：「タスク管理」に焦点を当てたセッションが多い
　過去3回では(「R：Redmine」に関する話が多く)なかなか「T：Taskmanagement」である「タスク管理」になかなか焦点を当てることができませんでした。
＃これまでの過去3回の内容はRxTstudyの公式サイトにまとまっています。

　そこで今回は関西ライフハック研究会女子部の新妻あっちさんなど(あまりRedmine色が強くない方・笑)にお話していただきます。
　「IT業界じゃないから…」という方も参考になる話だと思います。

＃私も「個人のタスク管理」に焦点を当ててお話するつもりで、Redmineは出てきません。

　今更の余談ですが「RxTstudy」の「R」は「Redmine」で「T」は「Taskmanagement」を表しています。

◆今回の特徴2：グループディスカッション
　これまで「スピーカーが話す→それを聴く」という一方通行感がありました。
　また参加者のフィードバックにも「他の参加者と意見交換したい」という声もありました。
＃質疑応答や懇親会でディスカッションできた方もたくさんいるとは思いますが。

　というわけで、グループディスカッションを設けました。

※ATNDの文章より　

自分の自慢のタスク管理ツールをみんなに見せるもよし。
話すのが苦手な方は、今タスク管理について困っている事を相談するもよし。
タスク管理について、自由に話ができる場にしたいと思います。

　多くの方の話を聴いてインプットするのも良い事ですが、それにとどまらず(意見交換などを通じて)アウトプットをすることで、より良いものをRxTstudyで(自分も含めた参加者の方々が)得ることができれば…と(スタッフの1人として)思っています。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　まだ人数に余裕がありますので、興味がある方は軽い気持ちで覗いてみてはいかがでしょうか？

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

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

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

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

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

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

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

AgileJapan2012発表資料_Redmineと守破離

View more presentations from Yoh Nakamura

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

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

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

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

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

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

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

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

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

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

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

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

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

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　ちなみに(各セッションも良かったのですが)自分にとって一番勉強になったのは講師控え室での色々な方とのディスカッションでした。
　正解が無い話題が多い中で「自分はこう思う」を話して、それに対してフィードバックを(ダイレクトに)もらえる時間というのは、スピーカーをするメリットでもあると思います。