勉強会」カテゴリーアーカイブ

Regional Scrum Gathering Tokyo2021 に参加してきました #RSGT2021

もう4週間前になりますが、Regional Scrum Gathering Tokyo2021(#RSGT2021)に参加してきました
今回はハイブリッド開催でしたが、これまでとは違う楽しみ方を見つけることができました
この状況で、開催してくれた実行委員会のみなさん、スタッフのみなさんありがとうございました

こういう話をしてきました

組織がアジャイルになっていく道を歩んだ時、「少しだけうまくやれたこと」と「うまくやれなかったこと」“というお話させてもらいました
とてもとてもありがたいことに5年連続でRSGTでお話する機会をもらっています(投票してくれているみなさん、ありがとうございます)
今回は”組織”にフォーカスした自分の経験をお話しました

1つのチームにとどまらず、組織をよりいい感じにしようと活動する、している人にとって何か役立てば良いなと思っています

ハイブリッド開催だったRSGT2021での過ごし方

私は1,2日目は東京に行き現地で参加、3日目は朝一に大阪に帰り、自宅からオンラインという参加のスタイルにしました

現地では(それほど多くなかったものの)久しぶりな方々と話をすることができました
それにいろいろな人がアイデアを出して、実験をしていく中で、オンラインとオフラインが溶け合っていくような感じ(Discordに「廊下」というチャンネルができたり、会場の廊下の様子をオンラインに流したり)がしていました
また夜遅くまでDiscordのいろいろなチャンネルで会話が発生していて、これまでRSGTが終わった後にあった”中華”と似たような雰囲気を感じることもできました

RSGTが終わった後の過ごし方

ハイブリッドだったこともありセッションの録画を観ることができます
しかも、RSGTのチケットを持っている人と一緒であれば、他の人たちも見ることができます

関わっているある現場では、一緒にセッションを見て「自分たちの現場でどう活かせるか?」といった話をしています
また別の現場では「ウォッチパーティー」と呼び、ほぼ毎日のように視聴会が開かれています
このウォッチパーティーでは感想などを共同ドキュメントに書き込んでいくスタイルを取っているのですが、これがまた見終わった後の感想戦をとても豊かにすることに効果的なようです

クライアントの経営者が参加してくれたこと

前回のRSGTに参加したクライアントのチームから、今回さらに多くの人が参加しました
それと同時にその組織の経営者が現地で参加してくれたことがとても嬉しかったです

「よく紹介してくれる本や自分の会社で見るチームの様子とはまた違った角度のいろいろな現場の話や熱気、大切にしている価値観のようなものを感じることが出来てよかった」という感想をもらいました

次回のRSGT2022がどのような場になるかわからないですが、同じでも違っていてもここに集う人達とならいろいろ実験をして、学び、楽しむことができそうと思えるRSGT2021でした

Regional Scrum Gathering Tokyo2020 に参加してきました #RSGT2020

Regional Scrum Gathering Tokyo 2020(以下 RSGT2020)に参加してきました。
※スライドなどはRegional Scrum Gathering Tokyo 2020のスライドまとめ #RSGT2020 - スクラムマスダーの日記にまとまっています。

4年連続で参加していますが、毎回ものすごい熱量があり、新たな発見や学びを得られる場です。
そして次回のこの場に「自分のやったことや変わったことを持ってこれるようにする」ことが自分のモチベーションの源泉の1つでもあります。

実行委員会やボランティアスタッフのみなさん、ありがとうございました(もちろん話し手や参加者一人ひとりの貢献もあってこそですが)。

トピック

  • 発表した
  • Coach’s Clinic をやった
  • クライアントを呼んだ
  • その他いろいろ
  • RSGTのようなエキサイティングで熱い場が各地である

発表した

「みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?」という内容で発表しました。

いくつかトピックは削ったのですが、それでも持ち時間20分に対し52枚(前夜は64枚ほど)ありました。
早口だったり、多少説明不足だったりした点もあったと思いますが、Twitterや会場でもらったフィードバックは概ね好評だったようです。
※いただいたフィードバックや質問は前述した削ったトピックだったりしたので、またどこかでお話したり、ブログに書いてみようと思います。

印象的だったのは「Outcomeは大事とわかっていたけどやり方がわからなかった。でもダイヤの事例が具体的で参考になったので、自分達の現場でも早速試してみようという話になった」という声でした。
※ダイヤがどう生み出されたのかはギルドワークスの事例(企画と現場の距離が近づき、OutputよりもOutcomeを優先する意識が根づいた)に詳しく書いています。

余談ですが、このチーム、現場はまだまだこれから変わっていくと思うので興味がある方は訪問したりコンタクトを取ってみると良いと思います。

Coach’s Clinicに参加した

Coach’s Clinic にコーチとして参加しました。
フィードバックを見ると何かのヒントになった方が多かったようでホッとしています。

相手の状況を聴いて対話していくという点では日々やっていることの一面と似ています。
が、相手のコンテキストの理解から深堀り、(必要があれば)何か伝えるという一連を15分〜30分の時間で行うのは集中力が必要でした(例年思うことですが)。

その他いろいろ

クライアントに参加してもらった

ギルドワークスのスポンサーチケットを興味を持っていたクライアントに渡したところ若手が参加していました。
これからいろいろ新しいことに取り組んでいこうとしている中で、これまでのやり方や価値観を持っている人達や流れの中でいろいろ試行錯誤している様子でしたが、ネットワーキングパーティなどで似たような場でも先に進んでいる仲間と出会えたようでした。

3日目のスポンサートークをやった

1,2日目のゴールドスポンサートークを聞いた方はわかると思いますが「あれはずるいなぁ」と思いながらやりました。
「関西人が全員おもろいわけじゃない」という話をしつつ、真面目な話として「こういう熱量が高い場に参加した翌日の現場との温度感の違い」の話をしました。
※この話も別のブログに書いてみようと思います。

(小さなことだけど)英語を少しだけ使った

前夜祭で Cope さんに少しだけ英語で挨拶とちょっとした会話ができたのは、小さい一歩だけど自分にとって嬉しい出来事でした。

RSGTのようなエキサイティングで熱い場が各地である

同じような場が札幌(Scrum Fest Sapporo)では4月に、大阪(Scrum Fest Osaka)では6月に開催される予定です。

そこに集まった人達によってRSGT2020に勝るとも劣らない場(勝ち負けじゃないですが)になるんじゃないかと思っています。
※宣伝:Scrum Fest Sapporo には「これまでと違うやり方に取り組む時にうまくいくかもしれない方法とその落とし穴」というプロポーザルを出したので、面白そうだなと思った方はLikeしてください。

Regional Scrum Gathering Tokyo2019の感想(1日目) #RSGT2019

Regional Scrum Gathering Tokyo

Regional Scrum Gathering Tokyo(以下 RSGT2019)に参加しています(このブログは3日間あるギャザリングの2日目の朝に書いています)。

参加はRSGT2017RSGT2018に続き、3回目です。

1日目の感想

セッション

Gabrielle Benefieldさんの基調講演「Outcome Delivery: delivering what matters」でのメビウスループの話は「やっぱりそうだよね」と強く思いました。
自分達ギルドワークスの「正しいものを正しくつくる」の実現するための1つの手段である仮説検証型アジャイル開発とも通じるものを感じました。

他にも支援しているエウレカさんのカンバンの話やDevLOVE関西などでもよく話してくれる椎葉さんの話など現場で実践した話をいろいろ聴けました。

Coaches’ Clinic やっていました。

セッションの合間にコーチに1on1で相談できるというコーナーがあり、そこに少しお手伝いしていました。
それぞれの現場の課題やいろいろ考えていることにふれる機会も貴重でした。

2日目は「ファシリテーションの難しさと楽しさ」というタイトルで話します。

先に公開しているスライドです。

2日目の最後のあたりの時間帯でアジャイルやスクラムの話はみんなお腹いっぱいになっていると思い、そのあたりの話はほぼなく”ファシリテーション”にフォーカスしています。

Scrum Festa Osakaやります

2019年2月22日(金)・23(土)にScrum Festa Osakaというイベントを開催します。
(あまり貢献はできていませんが、実行委員会に名を連ねさせてもらっています)

Scrum Fest Osakaはスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。この2日間を通じ、参加社同士でスクラムやアジャイルプラクティスについての知識やパッションをシェアするだけでなく、ここで出会ったエキスパートに困りごとを相談することもできます。

Scrum Festa Osaka が立ち上がるまで

思い返せばRegional Scrum Gathering Tokyo(RSGT)2018の前夜祭で「関西でもやろうよ」と声があがり、その場でSlackが作られたのがきっかけでした。
それからほぼ1年以上経ち、次のRSGT2019の開催より遅くなりましたが、開催することができそうです。

ここに至るまで本当に多くの方々の協力なしにはできなかったと思います(まだ終わっていませんが)。
実行委員会設立においてはスクラム道関西運営メンバー、またスクラムギャザリング東京実行委員会、中でも川口さんには何度もMTGにも参加いただいたり、これまでRSGTを運営してきた知見などを含め、貴重なアドバイスをいただきました(ありがとうございます)。

また素敵なロゴもJUNBOwさんに作っていただきました。

Scrum Festa Osakaの特徴

タイムテーブルにあるように2日間、2トラックの構成です。

これらのセッションは応募のあった78個ものプロポーザルからそしてみなさんの投票などで決まりました。
第1回目にもかかわらず、こんなにも多くのプロポーザル、ありがとうございました。
残念ならが採用できなかったプロポーザルも魅力的なものが多いので、ぜひ、社内外での勉強会などの場で発表できるといいなと思っています。

セッションは、平鍋さんなどアジャイルの黎明期から活動されてきた方から、今まさに現場でScrumを導入しようとしている方まで、まさに初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が話します。
おそらくどのセッションもその人が経験し、血肉となっていることを話してくれると思います。

1日目の終わりにはネットワーキングパーティーの場があります。
1日目のインプットを踏まえて、その夜に参加者同士で意見を交わし、2日目に新たなインプットをすることで、より深い理解や考えができるのでは?と考えています。

参加するにはどうしたらいいのか?

2月1日から発売予定のStandardチケットをこちらでお買い求めいただければと思います。
(なんとタイミングの悪い日に公開したエントリでしょう)

Regional Scrum Gathering Tokyo2018に参加してきた #RSGT2018

2回目のRegional Scrum Gathering Tokyo

前回に引き続き、Regional Scrum Gathering Tokyoに参加して、【「ふりかえり」の始め方と続け方】というお話をしました。

前のセッションと休憩なしで連続、かつ、20分という短い時間だったのでHowのテクニック的な面の話が多くなりましたが、”ふりかえり”など、自分達のやり方をよくする余地はいろいろあります。

そういうことを考えるきっかけに少しでもなれば幸いです。

印象に残ったことなど

  • 1、2日目の基調講演、両方とも心に沁み込んできた。Richard Sheridanからは「(本にも書いているけど)実験することの大切さ」を、2日目の河野さんからは「自分で作ったものが世界を変えていく楽しさ」をそれぞれ受け取った
  • デブサミやらで色々お世話になっている岩切さんから「久しぶりに会ったけどすごく表情がよくなっているね」と言われたこと(3日目の岩切さんの話は残念ながら聞けなかったので、そのうちご飯でも食べながら聞かせて欲しい)
  • ネットワーキングで、現場支援先のスクラムマスター数人にちょっとネジが跳んでいる(※褒め言葉)人達を引き合わせることができた
  • 前回に続いて「Coach’s clinic」(コーチに相談する場)に相談される側で参加したこと。自分のやっていることが少しでも役に立ったのであれば幸い
  • 相変わらず運営がスムーズ、かつ、ホスピタリティ溢れるものだったこと。実行委員会、スタッフのみなさん、ありがとうございました

最後に

Regional Scrum Gathering Tokyo 2019もスピーカーで参加したいなと強く思いました。

どんなニーズがあるかわからないけど、東京だけでなく関西とかでもこういう場を作っていきたいなと思いました(DevLOVE関西はそういう場の1つだと思うけど少し違う感じで)。

Regional SCRUM GATHERING Tokyoに参加してきた #RSGT2017

初めてのRegional SCRUM GATHERING Tokyo

Regional SCRUM GATHERING Tokyoに初めて参加して、発表してきた。

余談。このスライドを作るために直近の3連休をほとんど使ったけど、そうさせてくれた家族に感謝。

印象に残ったことなど

  • 2日間(前日の準備なども入れると3日間)とも運営がスムーズ、かつ、ホスピタリティ溢れるものだったこと。実行委員会、スタッフのみなさん、ありがとうございました。

  • ロッシェル・カップと「明日、同じ時間に話すので、似たようなテーマで興味があるのにお話聞けないのは残念ですね」→「じゃ、先にお互いスライドを見せて意見交換しましょうよ」の流れで、1日目の夜に、お互いのスライドや話す内容の意見交換をして、フィードバックをもらったこと。だいぶ刺激になったし、、もっと話したいと思った。

  • このようなカンファレンスにほぼ初めての参加という、クライアントの若手(1人で来ていた)にスピーカーやスタッフなどを紹介したこと。

  • 「Coach’s clinic」(コーチに相談する場)に相談される側で参加したこと。自分のやっていることが少しでも役に立ったのであれば幸い。

  • 聴いたセッションはどれも面白かったけど、色々な人との議論が楽しかったし、考えの整理や新しいやり方、考えを得られた。

  • そしてこれ。

Regional SCRUM GATHERING Tokyo 2018もスピーカーで参加したい。

【資料公開】アジャイルカルチャーが組織に根付くまでの挑戦

Regional SCRUM GATHERING Tokyoでお話した「アジャイルカルチャーが組織に根付くまでの挑戦」の資料です。

現場コーチとして、組織にアジャイルなカルチャーを広めていく時の壁に関する事例・経験・道具箱(プラクティス)をザッとお話しました。
かなり詰め込んでしまった(45分で122ページ)ので、深く話しきれないこともありました。
関西/関東、勉強会/企業問わずお声がけいただければお伺いしますのでTwitterFacebookなどでお気軽にお声がけください。

まとめは以下です。

メトリクスによる「見える化」のススメ: エッセンシャル・リーン #DevKan

2015年3月7日(月)に「メトリクスによる「見える化」のススメ: エッセンシャル・リーン」を開催しました。
#会場を提供していただいたシナジーマーケティング様、ありがとうございました。

きっかけ

2014年秋頃に発表されたスライドを見た時に「自分の現場でもこのエッセンスは役に立つので、ぜひ話を聴いてみたい」と思ったのがきっかけで、伊藤さん(@hageyahhoo)にお声がけをしました。

私は「現場コーチ」という肩書きで色々なクライアント様の開発チームと一緒に、プロセスや開発の改善をしていくことを多くしています。

その際に闇雲にやるのではなく、狙いを絞る必要があります。そのためにも「今どのような状態で、それをどのようにしたいのか?」という現在地点と目標地点を見極め、その途中経過を計測して、把握することが大事です。
その見極めや把握は定性的なものではなく、定量的であることも大事です。

その定量的に計測するポイントなどを学ぶことができればと期待していました。

内容

セッション、ワークショップの内容やその裏での狙いなどは伊藤さんのブログに詳しく書かれていますので、そちらをどうぞ。

改めてメトリクスをどう設定して、見える化するのか大事さを感じました。
この手のメトリクスは1つ(例えばディベロッパー)の視点になりがちなのですが、このワークではマネージャ・デベロッパー双方の視点をぶつけ合うことで一方的なメトリクスにならないようにしていました。
これは実際の現場でも同じで、開発チーム以外にもマネージャーをはじめ、様々な視点を持った違うロールの人がいます。その人達にも納得感のある内容、見せ方が大切になってきます。

実体験と重ね合わせて感じたこととしては、メトリクスを実際の取るのに手間がかかるやり方では定着しないということです。
一手間で誰もが見れるようにする、自動化していつでも見れるようにするというのもこの手のプロセスでは大事です。
ただ様々な理由でそこまでできていないこともあるので、まずはうまくリソースを使いながらメトリクスの重要性を見せていって、より効率良くするためのリソースを獲得する…といった戦略も大事になってきます。
#その最初の段階をクリアするために伊藤さんのような内部のコーチや外部のコーチの力を借りるという方法もあります。

後は、なかなか他の人のワークショップの進め方を見る機会はないので、伊藤さんのワークショップの進め方などを垣間見れたのは面白かったです。

今後のDevLOVE関西

FacebookページDoorKeeperでお知らせしますので、興味ある方はお越しください。

「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver) #DevKan

2015年2月7日(月)に「「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver)」を開催しました。
#会場を提供していただいたはてな様、ありがとうございました。

きっかけ

東京のDevLOVEページでこれを知り、「四半世紀前からのソフトウェアの話ってきっと学びが色々あるんだろうなぁ」と思っていました。
そんな時、たまたま話し手の一人である新井さんに「今度DevLOVE関西でもやって欲しいです」と相談したら、「じゃ前回の話し手全員で行きますよ!」という嬉しいお返事をいただきました。

#ちなみに新井さんはDevLOVE Advent Calendar 2014 「越境」で1人10エントリを書いた猛者です。

内容

募集ページにスライドやブログのリンクをまとめています。

駅すぱあとの産みの親である宮本さんのセッションからスタートしました。

プロダクトに四半世紀も携わってきただけあって、どのエピソードもとても面白かったです。
最後の方の「自分の経験がこれからの人に少しでも役に立てばと思って今日は話しました」という言葉がすごく印象的でした。
主催者の1人としてはこの宮本さんのお話を聴けただけで本当に満足していました。

次のセッションは一転してDSLの話。
しかし「運賃計算ってなんでこんな複雑なんだ?」というのが印象でした。その中で技術と業務(ドメイン)の会話をスムーズにするためにチャレンジされているお話でした。

さらにDevOpsBizのお話。これもあるある話だったのですが、「あるよねぇ、仕方ないよなぁ」で終わらずに関係者を巻き込んで進めているというお話でした。

新井さんのお話。組織改善、変革をすごいスピードと情熱でやっているその実例のお話でした。これだけやるのもすごいですし、何よりそれを自分のところだけで終わらずに他の部署や社外にも向けてアウトプットしているのがすごいです。特に人材交換はホンマにやってみたいなぁと強く思いました(ギルドワークスとヴァル研究所さんでできないかな)。

最後は新規サービスのProduct/Market Fitのお話。ギルドワークスでも新規サービスに色々関わっているので、この辺の難しさを共感しました。いいなぁと思ったのは、本やサイトに載っていることを鵜呑みにせず、ぶつかった壁に対して「じゃ自分達の現場ではどうやったらうまく行きそうか」を色々試している点でした。

セッションが終わった後は、そのままピザとビールを投入しての懇親会をしました。ここでも話し手ごとのテーブルごとに色々な話が盛り上がっていました。
20150207_164414

今後のDevLOVE関西

FacebookページDoorKeeperでお知らせしますので、興味ある方はお越しください。

ウェブデザイン・ウェブ開発に必要なこと(DevLOVE仙台共同企画) #DevKan

2015年2月2日(月)に「ウェブデザイン・ウェブ開発に必要なこと(DevLOVE仙台共同企画)」を開催しました。
#会場を提供していただいた楽天様、ありがとうございました。

きっかけ

DevLOVE仙台のスタッフの佐々木(@chachaki)さんが、今回の話し手である細川さんが書かれているブログ「バニレートデザイン」のファンで、特に「ウェブデザインに関する知識や技術の相互関係チャート」が面白そうなので、これを元にしたお話をしてもらいたいというのが、そのきっかけでした。

そして久々にDevLOVE関西、DevLOVE仙台での共同企画がスタートしました

内容

まずバニレートデザインのブログの書き手、細川富代さんのセッションからスタートしました。

ウェブデザインの歴史から始まり、ウェブデザインに関係する要素という流れでした。
スライドにはそれほど説明はありませんが、細川さんの話は整理されていてとても分かりやすかったです。

続いてDevLOVE仙台の角銅さんのセッションです。
こちらは角銅さんが自分達がされている開発の流れをその必要性などの面にフォーカスしてお話してもらいました。
このお話はギルドワークスでやっているプロセスにも似ていたので、参考になりました。

セッションの後は以下のテーマでダイアログとしました。
ダイアログ

ダイアログの時間は少し短めでしたが、DevLOVE関西、DevLOVE仙台それぞれでどんな話をしたかを(一部ですが)共有したりしました。

今後のDevLOVE関西

FacebookページDoorKeeperでお知らせしますので、興味ある方はお越しください。

DevLOVE関西「JavaScript フレームワークは Angular JS だけじゃない!」 #DevKan

JavaScript フレームワークは Angular JS だけじゃない!」を開催しました。
#会場を提供していただいたシナジーマーケティング様、ありがとうございました。

きっかけ

きっかけ

話し手の一人でもある中村 久司さんのこんな言葉がきっかけでした。
当時、私はいくつかのJavaScriptのフレームワークを調べていて「いっぱいあるなぁ…」と思っていたこともあって、これをDevLOVE関西のテーマにしてみようかと企画を蹴り出しました。

結果的に(DevLOVE関西の企画にしては珍しく)半年以上後になりましたが開催できました。

セッション

話し手3人それぞれのスライドです。

セッションの後は、セッション毎=紹介したJavaScriptのフレームワーク毎にグループに別れてQ&Aを行いました。
KnockoutJSやVue.jsのグループには割と自分でガリガリと使っている人が集まり「このブラウザでこの場合にうまく動かないんだけど、みんなどうしている?」と言った話が盛り上がり、一方、Senchaではセッションのタイトル通りエンタープライズでお仕事をされている方が多く集まっていて、「現場への導入トレーニングをどうスムーズにするか」などの話がメインで特色が出ていました。

今後のDevLOVE関西

FacebookページDoorKeeperでお知らせしますので、興味ある方はお越しください。

DevLOVE関西「事業会社の現場を知ろう~クックビズ編~」 #DevKan

2015年最初のDevLOVE関西として「事業会社の現場を知ろう~クックビズ編~」を開催しました。
#会場を提供していただいたファーストサーバ様、ありがとうございました。

クックビズさんとはギルドワークスとして…厳密にはギルドワークスを立ち上げる前から仕事を一緒にさせてもらっていました。
CEOの藪ノさんや杉田さんとやり取りが楽しく、またその考え方も自分にとっても考える内容が多かったので、一度DevLOVE関西でお話してもらおうと思い、お願いしました。

また事業会社のエンジニアが普段どのようなことを考え、行動しているか?という話はあまり関西では聞かないのでは?と思ったこともありました。

藪ノさんの採用の話はギルドワークスも常に仲間を見つけているので、自分達の採用や「どんな人と働きたいだろうか?」と色々と考えることがありました(この辺はまたまとまったら書きます)。

杉田さんのスライドは以下で、特に事業会社と受託会社のマインドセットの話は共感しました。

2人のセッションの後は数人のグループに別れ、以下の4つのテーマでダイアログ(対話)をしました。
ダイアログテーマ_20150119

参加していただいた皆さん、話し手の藪ノさん、杉田さん、ありがとうございました。

2014年の発表スライドまとめ

2014年に色々なコミュニティで発表したスライドのまとめです。
ギルドワークスとしては他にも色々ありますので、興味がある方はお気軽に声をかけてください。

「開発現場に伝えたい10のこと」それぞれの後日談

DevLOVE関西「開発現場に伝えたい10のこと」それぞれの後日談にて。

DevLOVE関西の電子書籍が出来上がるまでのお話でした。

成功と失敗の 狭間に横たわる2つのマネジメント

DevelopersSummit2014(デブサミ2014)にて。

このツイートから実現したことでした。会場の雰囲気も素晴らしく、憧れであったデブサミでお話できたのはとても嬉しい出来事でした。

Trelloを使ってサクサク開発してみませんか?

DevLOVE関西TrelloやBacklogを活用して仕事に追われないようにする方法にて。

Trelloは個人的にけっこう使っていたので、それらの良さをまとめてお話しました。

プロジェクトを成功させるための期待マネジメント

DevelopersSummit2014inKansai(デブサミ関西2014)にて。

2月のデブサミに続いての発表でした。
発表で伝えたかったことなどはGuildWorksBlogをご覧ください。

(LT)DevLOVE関西の現場

DevLOVE現場甲子園2014 日本シリーズ編 〜東西開発現場の集結〜のランチLTにて

改めて自分がなんのためにDevLOVE関西をやっているのをふりかえる良い機会になりました。

その他

・アジャイルジャパン神戸サテライト「コミュニティをやってきて気づいたこと」
・ミライカフェ「越境する難しさと楽しさ」

最後に

なんといっても2014年はデブサミ、デブサミ関西と2つのデブサミでお話させていただき、また両方のセッションとも多くの方に聴いていただいたのが、印象的で嬉しい出来事でした。

「開発現場に伝えたい10のこと」を出版しました

2013年の出来事の1つとしてDevLOVE関西【開発現場に伝えたい10のこと】という電子書籍を出版し、私もその1章を書かせてもらいました。

どんな内容?

所属する組織や立場が異なる10人それぞれの経験を書き記した10本の話が詰まった内容になっています。

目次はこんな感じです(サイトより抜粋)。

出撃の前に
第1章 チームをビルドする (栗栖 義臣(id:chris4403))
第2章 アジャイルな乙女ゲーム開発のおはなし (粕谷 大輔(@daiksy))
第3章 道具に関するよしなしごと (いろふ(@irof))
第4章 大きな会社の小さなマネジメント (川畑 雄補(@ku_suke))
第5章 インセプションデッキによる期待マネジメント (市谷 聡啓(@papanda))
第6章 「どうすれば価値を生み出すか」を知るためにヌーラボで行っていること (染田 貴志(@tksmd))
第7章 ゲーム業界と私 (田口 昌宏(@masahirotaguchi))
第8章 最初に行う3つのプラクティスと継続していくコツ (中村 洋(@yohhatu))
第9章 エクストリーム開発者満足&エクストリーム顧客満足のアジャイル開発~アジャイル開発から考える、究極の「生産力」~ (株式会社アジャイルウェア 代表取締役CEO 川端光義 (@agilekawabata))
第10章 ふつうの受託開発 (川島 義隆)

「DevLOVE関西~Decision~」でもお話してくれた染田(@tksmd)さん、川畑(@ku_suke)さん、他にもirofさんなどDevLOVE関西にゆかりのある10人の皆さんです。

達人出版会さんから1コインでお買い求めできますので、お年玉の使い道にしてもらえれば幸いです。

2014年最初のDevLOVE関西

そして2014年最初のDevLOVE関西では、これをテーマにした【「開発現場に伝えたい10のこと」それぞれの後日談】を行います。
書き手の皆さんがあの話の後日談や書ききれなかった裏話など少しずつですが話す予定です。
#場所の関係もあり全員集まるというわけでには行きませんでしたが。

以下にこの本にある「はじめに」を抜粋しておきますので、よろしければお越しください。

人ひとりが経験できることには限界があります。かつてのパイロットたちも、自分ひとりでは不足してしまう経験をハンガーフライトで補ったはずです。他のパイロットの語りを聴くことで、自分の経験を拡張したわけです。

これは、私たちの生業であるソフトウェア開発でもあてはめることができるのではないでしょうか。デベロッパーひとりが経験できる開発には限界があります。現場第一線での開発を仮に30年近く続けたとしても、ひとりが投入できる時間はせいぜい300ヶ月です。人月でいえば、300人月のプロジェクトです。これは、規模としてはかなりのサイズですね。

しかし、300人月のプロジェクト1つだけを仕上げて、自身のデベロッパー人生を終えている場合ではないのです。実際には、来月から50人月、100人月程度のプロジェクトに挑む方もいらっしゃるでしょう。そう、私たちの開発現場は、それまで自分が経験したこともないような規模や知識領域、技術に挑まなければならない状況を迎えているのです。空とビットで世界は違えど、先人のパイロットたちの知恵を借りない手はありません。私たちも、現場や職場、コミュニティでハンガーフライトしましょう。

いま、皆さんの目の前にあるものは、文字になったハンガーフライトです。ここには、10人のデベロッパーたちの、さまざまな経験が詰まっています。それぞれの語り口調で、経験したことを語ってくれます。

さあ、現場に行く前に、彼らの語りに耳を傾けてみてください。あなたが、あすの現場で飛び回るためのヒントがここに、きっとあります。

(「はじめに」より)

2013年をふりかえって

2013年もいろいろあったので、どんなことがあったか記録しておきます。
DevLOVE関西関連のことは35回開催した2013年のDevLOVE関西に書いたのでそれ以外で。

1月

大阪リーンスタートアップ読書会 #5
傍楽いきいきプロジェクト~職場の景色を変えるワークショップ~
リーンカンファレンス2013 ~ヒット商品をつくる仮説検証型開発プロセスとスキル~

仕事面では普段のスクラムマスター業以外に、リーンキャンバスやインセプションデッキなどを使って企画やアイデアをもう少し違う形で考えてみるには?といったことに取り組んでいた時期でもありました。

2月

Scrum Boot Camp in 島根
その時のエントリ【「Scrum Boot Camp 島根」に行ってきました】です。
カラダで学ぶチームビルディング
デブサミ2013
11回目にして初めてのデブサミでしたが(デブサミ関西2013の実行委員長として)LTをやってきました。
その時のエントリ【デブサミ2013(やその他色々)に参加してきました
【勉強会】第1回リクリ勉強会「失敗しないアプリ開発を行うには〜 Getting Realを学ぼう 」
京都アジャイル勉強会 #京アジャ 春の特別編
2月25日 第16回 #TFSUG: 大阪vol.2(大阪府)

イベント以外ではマナスリンクさんで「DevLOVE関西」のことを書き始めたり、仕事面では社内でアジャイル開発の勉強会をやっていました。

3月

スクラム道関西「POStudy(第0回)」
京都アジャイル勉強会 #京アジャ 第18回
TOC/TOCfE関西分科会~成功事例から学ぶCCPM講座~

この頃には社内で毎週1回のランチ勉強会というのが始まりました。
そしてもう社外のイベントでは「デブサミ関西2013のキックオフ」というのがカレンダーに記録されていましうた。ここから半年以上に及ぶ準備が始まったわけです。

仕事面では、複数チームのスクラムマスターとして、スプリント計画やふりかえりなどに出たりして色々試行錯誤していました。

4月

第5回大阪Jenkins勉強会
第18回 #TFSUG TFS の今(大阪サテライト)
DevLOVE四国
XP祭り関西2013

仕事面では組織変更なんかがあって守備範囲が広がったりして提案活動に少しだけ足をつっこんだ時期でもありました。

5月

AgileJapan大阪サテライト
実は2013年で、あまり良い意味ではない方の印象に残っている発表でした。
参加者層や届けない内容などが本当にフワッとして、結果として「参加者の皆さん、どういうのをお聞きしたいですか?」的な形にしたのですが見事に盛り上がりませんでした(質問してくれた人は、なんとなく知っている方が多かった気がします)。

この頃からの2、3ヶ月での出来事(人との出会いや場)が、残り半年に大きな影響を与えているように思います。

6月

・Drupal Cafe 2013 vol.5 in OSAKA

7月

色々な人と会って、話して、当時考えていたことの仮説を検証をしたり、インタビューをしたりして、どういうニーズがあるか?など本当にお金を払うのか?など色々試していました。

それに呼応する形で、これまで以上に社外の人と一緒にプロジェクトを進めることが増えてきて、それぞれのやり方や振る舞い、多岐に渡った関心事などにも目が行って面白かったです。

9月

共感で駆動するプロダクト開発の始め方と進め方
XP祭り2013 ~XP~(東京都)
デブサミ関西2013
Scrum Boot Camp (スクラム道関西 presents)
2014年からやっていくことになるChangeHackersとして明確な最初のイベントをやったり、そこからXP祭り→デブサミ関西→Scrum Boot Campというコンボはなかなかにタフでした。

10月

Innovation EGG 第一回 IT系コミュニティ合同•未経験者向け勉強会

仕事面ではこの時期に「あぁ2014年からはまた次のステップに行くんだなぁ」と決めました。

11月

DevLOVE甲子園
1日で最大60人が話したDevLOVEらしいイベントでした。
「団」チームとして話したのは以下のスライドです。

12月

第28回 関西IT勉強宴会
アプリのペーパープロトタイピング勉強会

2013年のまとめ

DevLOVE関西以外でもスクラム道関西、デブサミ関西2013など色々なイベントに関係することができました。
何より2014年はまた違うステージに挑戦してみようと思ったのも2013年の大きな出来事でした。

※アイキャッチ画像:http://www.flickr.com/photos/4ever30something/451088722/

社内勉強会の初めの一歩

先日のDevLOVE関西「勉強会勉強会」のビアバッシュでの話です。

社内勉強会を始めようと思った時の2つの不安

20人位の組織にいる人で「どうやって社内勉強会を始めて良いか分からない」という課題を持っていました。さらに聞いてみると以下の2つのことを強く気にしているようでした。
1:人が集まらなかったらどうしよう?
2:講師出来るほど教えることもないので、どうしよう?

「1:人が集まらなかったらどうしよう?」の自分なりの答え

「(自分以外に)もう1人いたらやってみる」
「勉強会勉強会」でもお話しましたが、自分以外にもう1人いれば、それは「勉強会」だと思っています。
2人以上いれば勉強会と呼べば良くて、呼び名や定義は些末なことかと。

2人でそのテーマについてお互いの知見や考えを話し合い、共有することで、それぞれが持っていた暗黙知が、2人にとっての形式知となりお互い勉強になります。
仮に新しい知識そのものに出会わなくても、自分とは異なる考え方を知るというのはそれだけで十分な価値があります。

特に小さな組織の場合、2,3人でも何かやっていたりすると「なにやっているんだろう?」と目に止まったりします。そういう興味を持っていそうな人も、勉強会をやっている人から見つけやすくなり、「一緒にどうですか?」と巻き込みやすくなります。

その相談してきた人は、アイデアとしてお茶の時間に休憩スペースにお菓子を用意して、そこでまずは始めということで軽くに30分程度でやってみようと話をしていました。

「2:講師出来るほど教えることもないので、どうしよう?」の自分なりの答え

「みんなで考えて、教え合えば良い」
 
誰か1人が参加者の中で一番そのテーマについて知っている講師である必要はどこにもないと思います。
もちろんテーマによっては、有識者がいる方が進めやすいというのもありますが、それこそみんなが持っている知識を持ち寄ることで解決できることもあります。
またそういう解決できない問題が実際に出てから、それを解決できる有識者を見つけに行っても良いと思います。

その相談してきた人は「【勉強】会」という名前からか、ロールとして「講師」「生徒」なイメージを持っている感じでした。
「自分はこう思うけど、みんなの考えはどう?」「ここのコードがわからなかったから、一緒に読み解いてみない?」と一緒に考えれば良いと思いました。
エンジニアの現場で出会う課題は、ほとんどが唯一の正解があるわけではなく、むしろそのコンテキストに応じた「より正しいと思われる選択を見つけに行く」必要があります。

なので、自分ともう1人が興味あることを見つけて、軽くやってみるのがまずは第一歩だと思ったわけです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Lindsay Henwood via VisualHunt.com

社内勉強会

社内勉強会の難しさ

これまで(セミナーや読書会などの)社内勉強会をやったり、他社さんで社内勉強会のお手伝いをした中で、難しいところや思うところがあったので書いてみます。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

社内勉強会の定義

クローズドで開催され、参加者は(原則)社員のみ。スピーカーや講師は外部の場合もある。

モチベーション

参加者のモチベーションは(社外勉強会とは)大きく異なっています。
社外勉強会ではほぼ「自分で選択して参加」しています。
中には上司や会社から命令されて参加するというパターンもありますが観測範囲では少数だと感じています。

一方、社内勉強会では「面倒だけど評価に響くかも」とか「仕事的だから」とモチベーションが高くなく、良い感情を持っていない状態で参加する人もいます。

不思議なことに「自主参加で評価などには一切関係ありません」とアナウンスしても一定数の割合で本当に嫌々参加している人がいます。
残念ながら、そういう人の一部は(無関心でなく)抵抗勢力になってしまうこともあります。

そのような抵抗勢力との対応にリソースを使うと、数少ない興味ある人へのリーチやリマインドが弱くなり、参加者が集まらなかったり、無断キャンセルやドタキャンばっかりだったということも起こります。
#講師と参加者の割合が2対1というマンツーマンどころか講師の側がダブルチームという悲しいセミナーも経験しました

いつ行うか?

いつ行うか?も社内勉強会では悩ましい問題です。

1:定時内

「(日常の)業務タスクとの兼ね合いをどうするのか?」という声が上がってきます。
「○○という社内勉強会に参加していたため、進捗が遅れました」なんて報告されたりすると、そのプロジェクトからクレームが飛んでくることもあるかもしれません。

2:定時後

「それは業務命令ですか?残業時間として付けますが良いですか?」という声が上がってきます。
この場合、「業務命令でないから自主参加」or「業務命令」という2パターンがあります。

「業務命令」の場合、残業代や業務監督責任なども発生してくるので、それなりに上司や組織に根回しをしてバックアップを得ておく必要があります。
そこまでゴタゴタ言う人はモチベーションが低いことも多いので「そこまで言うなら来なくて良いよ」と思うこともありますが、組織に社内勉強会から得られる何かが根付いて欲しいと思うと割と対応することが多かったりします。

3:休日にする

定時後の場合と同じ問題がより高いレベルで発生します(休日出勤手当や振り替え休日など)。
「業務命令」という形にしても、なかなか組織としては認めてくれないと思います。

どうしたらうまく行くのか?

「うまくいく方程式」があるわけではありませんが「参加者のメリットを提示する」「仲間を見つける」はまず最低限必要なことだと感じています。

1:参加者のメリットを提示する

「メリット」というと生々しいですが、「今、困っていること」を少しでも解決できそうなら、時間を作って参加してくれることもあります。
またすぐ役立ちそうなことなら、参加者もいつか役立つかもしれないことよりモチベーションが高くなることが多いです。

このパターンで1、2回社内勉強会に参加すると、後でテーマが「いつか役立つかもしれないこと」になっても継続的に来てもらえたりします。

2:仲間を見つける

継続しようとすると、準備などを全部自分1人でするのは、時間的にも気持ち的にもしんどい時期が来ることもあります。
その時に頼れる仲間やバックアップしてくれる上司がいれば、継続することもできます。
※参考:[雑多]「XP祭り関西2012」でLTしてきました。

社内勉強会はモチベーションの問題など悩ましいことがあります。
#もちろん全然問題なく社内勉強会をやれる組織もあります。

一方で、自分の多くの時間をその組織とそこにいる同僚(仲間)のために使っています。
なので、そのレベルアップのため、そして伝える側のレベルアップのためにも社内勉強会をやってみてはどうでしょうか?

※アイキャッチ画像:http://www.flickr.com/photos/mattimattila/6878384654/

社内でのランチ勉強会

以前、「社内読書会をやってみて」というエントリを書きましたが、今度は社内でやってる「ランチ勉強会」のお話です。

どんなの?

週に1回、(社内の会議室などで)お昼を食べながら、プレゼン+ディスカッションをしています。
テーマはプレゼンする人が決めるか、参加者からリクエストがあったらそれについて話すという感じです。

きっかけ

6,7年目頃の同期数人で情報交換のために集まったのが最初だったようです。
私も途中から参加するようになりました。

同期ばかりだと発展性のない雑談だったり、(年次が近いこともあり)同じ視点になりがちなので、「色々な人にも声をかけよう」と動いていきました。

今では、部門もバラバラ…現場/本部系、開発部門/パッケージ導入などなど…ですし、年次も2年目~10数年まで広がっています。人数も多い時には10人を越えるようになって、最初の頃にやっていた会議室では手狭になり、場所を変えたりもしました。

どんなテーマでやっているか?

これまで20回以上やっていますが、テーマも様々です。

・Meteorの紹介とデモ
・CCPMってなに?
・RxTstudyの再演
・社内で作ったリッチクライアントフレームワークの話
・バーンダウンチャートの説明
・世代交代するためには
・お客さんとの付き合い方
・英語勉強会の進め方の相談
・インセプションデッキをつくろう
・社外勉強会ってどんなの?

後、新しい参加者がいれば、その人の自己紹介もあります。
同じ部門、同期でも「何をやってきたか?これから何をやっていきたいか?」は知らないことも多く、自己紹介をきっかけに話が盛り上がることも多くあります。
 
出欠や資料、終わってからのやり取りはyouRoomを使っています。
ランチ勉強会本編以外の話題…主に最近ネットで話題になったエントリとか…を起点に「youRoomでディスカッション」→「ランチ勉強会本編へ」という流れもあります。

「社内読書会」との違い

冒頭に書いた社内読書会との違いは「組織有りきで考えるかどうか」というところです。

「社内読書会」のメンバーは社外勉強会にも多く出ていたり、若い方が多いこともあってか「自分はどうなりたいか?そのために~」「(自分のやり方、キャリアの)こんなことで悩んでいる。〇〇はどう思う?」という感じがします(組織云々よりも)。

一方、「ランチ勉強会」は、中心メンバーがそれぞれお客様と向きあって、また、プロジェクトリーダーなりでやっているからか「自分達のお客様とのビジネスをどうしたら良いか?」「この組織のどこをどういう風にしていけば良いのか?」というような「組織があって、その中でどうすれば良いか?」という話が多くあるように思います。

良い/悪いではなく、それぞれの立場や考え方があるのですが、両方参加している自分としてはその対比がなかなか興味深いです。

「ランチの時間ぐらい好きにさせてよ」と言う意見もあります(また、毎日やっていると疲れると思います)が、普段あまり話さない別チーム、別部門の人と話すことで新しい意見や情報を手に入れる良い機会だと思っています。
これをきっかけにして新しい何か…「〇〇さん、ランチ勉強会で△△に興味あるって言っていたから、このプロジェクトに引きこんでみよう」とか…が始まるかもしれませんし。

「いつもの」同僚と「同じような」話をするランチも良いですが、たまにはこういう風に「違う」人と「違う」話をするのも良いと思います。
ランチ勉強会を継続して続けている当初メンバーの皆さんに感謝です。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visualhunt

社内読書会をやってみて

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

この社内読書会をやり始めたきっかけ

やりはじめた経緯は(当時、同じ会社だった)@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で聴くことができそうなので、楽しみにしています。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visualhunt.com

初めて勉強会で発表する人に伝えたいこと

同僚がチームが直面した課題、その課題へ工夫したことを事例紹介として、勉強会で発表することになりました。
この同僚は社外の勉強会では初めて発表するというこもあってか「ほとんどの聴き手が『そんなん知ってるわ!』と思ったらどうしよう…」と不安がっていました。

この話を聞いた自分なりの考えを書いています。
#この同僚には伝えたことでもあります。

伝えてみたこと

100人の参加者がいたとして、全員が満足するような話は難しいです。ただその100人のうちひとりが「新しい知識、考えを知ることができた。今日は来て良かった」と思ってもらえれば、それで話し手としては十分です

発表に慣れないうちは、聴き手のことをあまり深く考え過ぎず、まずは「発表してみよう」という姿勢、そして実際に発表するアクションが大切なことだと考えています。

貴重な時間やお金を使って勉強会にやって来ている「聴き手のことを考える必要がない」というわけではありません。ただ、それを考えすぎる余り「発表する」ことそのものを躊躇するのはもったいないことです。

発表したことが、理解を少し誤解していた、もっとベストな方法があった場合、聴き手にいる有識者からアドバイスをもらうこともできます。また同じような境遇の人と話しあうこともできます。こんな風にフィードバックをもらうこともできます

技術的な検証、自分の考えや話に矛盾がないかはある程度事前に確認は必要ですが「話す内容が完璧な正解でないといけない」「ベストな方法でないといけない」わけでもありません。
そして、発表することで得られたフィードバックを、その勉強会で参加者にも共有したり、後日にブログなどで発信できれば十分です。

この同僚の発表は、勉強会、その後の懇親会でも多くの聴き手の興味をとてもひいたようで、いろいろな良いフィードバックを受けていた様子でした。

※この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: tobiastoft via VisualHunt / CC BY