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

Regional Scrum Gathering Tokyo2023 に参加してきました #RSGT2023

Regional Scrum Gathering Tokyo2023(#RSGT2023)に参加してきました。

今回もハイブリッド開催でしたが、この形になってから一番多くの人が現地に集まっていたように感じました。
スポンサーブース前、ホワイエ、廊下など多くの場所でいろいろな会話の輪が出来ていて「あぁ、RSGTってやっぱりこれやなぁ」と改めて感じました。

まず、実行委員、ボランティアスタッフのみなさん、(毎回のことですが)こんなステキな場、ありがとうございました!

【発表】Outcomeにフォーカスするチームへのジャーニー


前回と同じ1日目の午後最初のセッションで、緊張していていたところ、いくおさん( @martin_lover_se )や新さん(@aratafuji)など見知った人と言葉を交わせたので少し気が楽になりました。
が、いざ始まってみると「全然うまく話せていないなぁ。スライドのつなぎもだし、リズムが整っていない…」と焦りながらのあっという間の20分でした。
けっこう駆け足で、いろいろ足りない箇所、わかりづらかった箇所があったと思うので、そのあたりはDiscordやSNSで声をかけてもらえたら嬉しいです。

それでも、いくつか質問もらったり、会場で「あの先を聞きたかった」と感想をもらってその場で意見交換をしたりできたのは良かったかと思いました(「あの先」についてはそのうちブログにでも書こうと思います)。

セッションの壁打ちしてくれたAkiさん(@spring_aki)、レビューしてくれたトミーさん(@Tommy1969)さん、ありがとうございました!

スポンサーブース

今回もレッドジャーニーとしてスポンサーをさせてもらいました。
市谷さんや新井さんの書籍の表紙を印刷したチロルチョコをアメニティとして配ったり、ブースに来てくれた人とお話したりできました。

スポンサーセッションでは市谷さん(@papanda)が『右手に「正しいものを正しくつくる」、左手に「組織を芯からアジャイルにする」』を話していました。

Coaches Clinic(コーチーズクリニック)

1日目、2日目とも午後は主にコーチーズクリニックでいろいろな人の相談を聞いていました。今回は例年以上にとても盛況で、ほとんどのアジャイルコーチが時間いっぱい埋まっていたようでした。

私も2日間で13人の方とお話しましたが、だいたい最後には「この場には仲間がいっぱいいるのでひとりで抱え込まないでくださいね〜」みたいなことを言っていた気がします。

クライアントが登壇したりしていた

その支援しているチームメンバーが出したプロポーザルが選ばれて自分たちの経験を話していました。

以前に「yohhatuが話すのもいいけど、クライアントをこういう場で話すように後押しするのも1つやで」と言われていたことが実現できて良かったです。

他にもいくつかの支援先からそれぞれ複数人で参加していたようです。こういう場に一人で来ると現場に戻った時に「なにをしようか」となりがちですが、複数で参加していれば相談できたりする仲間となるので良い形だなと思います。

その他

Day0に英語話者と話した

Day0に少し機会があり、英語で話をしました。
「なんとなく言っていることはわかるけど、こちらから話せない」だったのが、ちょっとだけ会話を続けることができたのが嬉しかったです(毎日DMM英会話続けている結果)。

「DevLOVE関西やろうよ」って話をした

Day2の夜、関西から来ていた人たちと「やっぱりオンサイトいいですね〜。2022年に久しぶりに1回だけやったDevLOVE関西を2023年はやっていきましょうか」みたいな話をしました。

こういう、なにか背中を後押ししてもらえるのもRSGTの良さの1つです。

Scrum Fest Fukuoka 2023にプロポーザルを出した

3月のスクラムフェス福岡がプロポーザル募集中だったので、今回のRSGT2023で採択されなかったプロポーザル「アジャイルコーチは何をもたらすのか?何を考えて、どんなことをしているのか?」を出しました。
ちょっとアジャイルコーチ文脈なのでどれくらい聞きたい人がいるかわかりませんが、興味あるな〜という人はLikeしてくれると嬉しいです。

最後に

「次のRSGTでも何かを伝えられるように1年をやっていこう!」と気持ちを新たにした場でした。

Regional Scrum Gathering Tokyo2022 に参加してきました #RSGT2022

Regional Scrum Gathering Tokyo2022(#RSGT2022)に参加してきました。
前回と同じくハイブリッド開催でしたが、(特に1日目は)現地に多くの人が参加してて、ちゃんとマスクなどしつつ、ホワイエや廊下など様々な場所で面白そうな会話が繰り広げられたり、笑顔も見えたり、とても雰囲気がよくて「あぁ、RSGTってやっぱりこれやなぁ」と強く思いました。

まず、実行委員、ボランティアスタッフのみなさんありがとうございました。

発表:【「いい感じのチーム」へのジャーニー】

2017年から6年続けてお話させてもらっていますが、もしかしたら今回が一番緊張したかもしれません。投票してくれたみなさん、ありがとうございました。
1日目の午後に話したのですが、リアルの場であれほど多くの人の前で話すのは約2年ぶりということもあり、どういう身振り手振りをしたらいいのか、どこに目線を持っていけばいいのかとかとかかなりドキドキしました。

それでも終わった後のDiscordでの反応やいくつか質問や感想を直接もらったのを見ていると、なにか役に立ったようで嬉しかったです。

今回、事前に、@kawaguti@bash0C7@spring_akiの3人にレビューしてもらって、多くのフィードバックをもらいました。最初は正直、ザラザラでゴツゴツした感じでしたが、3人のフィードバックを取り込み、だいぶ良くなりました。3人ともありがとうございました。

Coaches Clinic

こちらもいろいろな人が来てくれました。中には「去年もお話聞いてもらったし、この1年間取り組んだことを話したいです!」という人もいたりしましたし、こういう場に初めて来たけど、少し勇気を出して申し込んでみた人もいたりしました(みなさま、ありがとうございました)。

2022年の印象としては、これから初めてScrumに取り組みますというよりも”自分のこれまでの領域から出る”ところで立ち止まっている、困っている感じの話が多かったように思いました。
それだけScrumなどアジャイルなやり方はチームレベルでは広まってきていることかなと思いました(少なくとも参加者の所属企業では)。

ホワイエやDiscordでの雑談

自分の中で、1日目は「久しぶりですね!」感がだいぶ先行していましたが、2日目にはだいぶ感覚も以前のようになり、ホワイエや廊下などでいろいろな対話や議論などができました。
「セッションは動画で後で見よう!」と決めて、この雑談に振り切っていた感もありますが、それくらいここでの雑談は自分にとって知的好奇心が刺激されて得難いものです。

また、RSGTとしてのハイブリッド開催は2年目ということもあり、夜遅くまでDiscord上の様々なチャンネルでいろいろやり取りがされていました。

スポンサーブース

所属しているレッドジャーニーでGold Sponsorとしてほぼフルメンバーでブースを出したり、市谷さん(@papanda)がセッションをしたりしました。
多くの人が興味を持って足を止めてくれたり、旧知の人が来てくれた様子です。

次回のRSGT2023でも、こんな風にステキな経験ができる場だと感じるために、自分もまた発表できるような学びや出来事を手に入れたいですし、自分の貢献できることをやっていこうと気持ちを新たにできたRSGT2022でした。

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