はてなブックマーク

はじめに アドベントカレンダーの時期、ブログなどで、セッションの通し方、みたいなノウハウが語られることが多いようです。カンファレンスの実行委員としてオープンプロポーザル形式で公募するようになって長いので、私なりにこうあってほしいなーということを書いてみることにしました。 「よいセッションの作り方」「よいプロポーザルの書き方」「そのための日々の過ごし方」という流れでブログが書かれるといいなーと思うのですが、実際は「ウケるプレゼン作成術」「通るプロポーザルの書き方」こそが利用者にウケる、というコンテンツが増えたりはしそうです。 これはOutput, Outcome, Impact の話につながるのですが、登壇することを通じて得たい成果(Outcome)は話を聞いてもらって、参加者の皆さんに活かしてもらうこと、それが話者の評価にもつながるというところかなと思います。そうして参加者の皆様が成功すれ

もう10年以上前の話になります。 仙台で開催されたレッツゴーデベロッパーというカンファレンスに参加したときのことです。 kyon_mmさんの登壇を聴講していたのですが、「スペシャリストではなくゼネラリストを目指そう」という趣旨のお話でした。曰く、一つの分野を8割くらいまで学んだら、そこからさらに突き詰めるよりも、別の分野を学んでいった方がいいのではないか、と。 会場の若いエンジニアたちは深く頷いていました。確かに、一見すると理にかなった話です。100%を目指すより、80%を複数持っている方が応用が利く。よくある話ですよね。 ただ、会場の一番後ろで立って聞いていた私とbikisukeさんだけは、クスクス笑っていました。なんというか、皆さん騙されている気がするなぁ、と。 懇親会の席で、本人に直接聞いてみました。 「ちなみにKyonさんの言う8割って、具体的にはどの辺なんですか？」 返ってきた答

多くの人が「スクラム＝ソフトウェア開発手法」と認識している現状を見て、少しもったいないなと感じることがあります。実は、スクラムの源流は経営学の巨人・野中郁次郎先生（1935-2025）の研究にあり、その本質はもっと深く、もっと広範囲にわたるものなのです。 私は初めてスクラムを知ったとき、その背景に野中先生の影響があることに驚きました。そこから多くを学んでいく中で、日本のプロダクト開発黄金期にあったはずのものを、どうやったら取り出して、現代の私たちとして活用することができるだろうか、と考えてきました。野中先生、ジェフ・サザーランド博士、本間さん、竹内さん、南野さんのご協力を得て、できる限りの情報を集めて、スクラムの枠組みだけではくみ取れない、成功のためのディテールを集めてきました。 （2025年1月25日、野中先生がご逝去されました。先生のご冥福をお祈りするとともに、その偉大な知的遺産を受け

品川アジャイルでは呼ばれたら各スクラムフェスにお邪魔して配信のお手伝いをしているのですが、お手伝いさせていただけることはうれしいものの、どちらかというと、あらゆるカンファレンスの運営の方に「配信することをあきらめてほしくない」と思ってやっています。 カンファレンスの配信において注意しているのは、だいたいこんな感じです。 機材に詳しくない人でも運用できる 一日中放っておいても動く安定性 発表者が慣れているZoomと画面共有を使う 発表者PCからHDMI接続する際のトラブルを避ける そのままクラウドに録画録音して録画漏れを避ける (公開するかどうかは選択) 専任のカメラ担当を置かない (活人) 専用の機材を置く机を作らない (活スペース) 会場に映っていない、音が出ないことでオンラインの異常を検知する (ポカヨケ) 通常の配信では、「詳しい人しか使えない機材は使わない」ようにしています。普通に

プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。 序盤戦、中盤戦、終盤戦の戦略 一番美味しいアイデアがでる可能性に備えるために 引き継ぎにはコストがかかるので人を追加すると遅くなる システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。 1. 序盤戦、中盤戦、終盤戦の戦略 「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユ

ポッドキャスト(PodCast)の音声編集、なんか時間を無限に溶かしそうで、手を出していなかったんですが、以前出演した furoshiki_fm  で、岩瀬さん (@iwashi86) がすごい頑張ってfukabori.fmを編集してる、という話に感化されたいっしーさん(@oturu333)が、最近、編集頑張り始めたそうで。ただ、Mac付属の無料の GarageBand だと編集の手間がたくさんかかるという話になり、ちょっと周辺をググって「Podcastのおすすめソフト」の記事をリサーチしたところ、サブスクの一部とか(Adobe Audition)、無料とか、デスクトップ音楽用の定番ソフト(Cubase)、メーカー自身がレビューしているもの(Cyberlink)といったものがのっているレビュー記事のなかで、共通して参照されているソフトに「Hindenburg Journalist PRO」

この記事は、スクラムギャザリング＆スクラムフェス Advent Calendar 2022 - Adventarの二日目の記事です。サッカーワールドカップでスペインに逆転勝利して今日は休みにしようと皆さんが盛り上がっているときに誰が読んでくれるのか不安ではありますが、記念に公開いたします。サッカーにちなんでハッカー文化の話も出てきます。 adventar.org アドベントカレンダーなのに業務連絡っぽくなってしまって恐縮なのですが、最近ハラスメントポリシーへの対応についてみんなの思いを文章化する作業をやってましたので紹介させてくださーい。 ポリシー作ったのはいいんだけど、ポリシーの運用って実は地道に大変な作業だったりします ルールは作っただけでは何も効力を発揮しなくて、関係者全員が理解して、遵守に向けて動くという多数の行為があって効果を発揮する。プロセス全体を見ると相当なハイコストだと思う

スクラムフェス大阪を無事に終了しました。スクラムフェス大阪は４回目で、第一回は2019年にオンサイト開催(関大MeRise様をお借りしました)、2020年はコロナ初年度ということでオンライン開催(19トラック)の形を作り、2021年のオンライン開催を経て、2022年はハイブリッド開催となりました。品川アジャイル(#shinagile)では、現地からのラジオ的なライブ放送を通じて、スクラムフェス大阪をはじめ、各地のスクラムフェスのオーガナイザーの皆さんの取り組みや思いを聞きました。 スクラムフェス大阪(6月)　https://youtu.be/5BZI9A3jhsY?t=851 スクラムフェス大阪2022の開催は、オンラインを中心としたハイブリッド開催。現地イケマンカンファレンス会場の役割は、セッション会場ではなく「廊下」。13トラックの地域トラックと、3トラックのスポンサートラックがオンラ

株式会社ホロラボに入社しました。アギレルゴコンサルティング株式会社は退社するわけではなく、引き続き研修中心に仕事を行っていきます。 ホロラボとのご縁 ホロラボは、Kinect とか HoloLens をやっているコミュニティのエンジニアを中心に2018年のHoloLens 日本向け正式販売開始を契機に設立されました。私は当時楽天株式会社で Rakuten Technology Conference というのを実行委員の一員として運営していて、そこで、ARとVRに関する展示をしてもらおう、という回があり、その際に、ホロラボ設立直前のCo-Founder、中村薫さんと伊藤武仙さんに出展をしていただいたのがご縁の発端になります。中村さんについては、さらにさかのぼること10年くらい、Shibuya Trac とか すくすくスクラムといった勉強会からのご縁になります。遠巻きにKinectやHoloL

This is a translated article. You can access the original here: Mob Programming – A Whole Team Approach by Woody Zuill モブプログラミング-チーム全体のアプローチ by Woody Zuill Translated by Yasunobu Kawaguchi, Ikuo Suyama and Ken Matsumoto 1. はじめに モブプログラミングとは、チーム全体が同じものを、同じ時間に、同じ空間で、同じコンピュータで作業するソフトウェア開発のアプローチです。これはペアプログラミング[PAIR]に似ています。ペアプログラミングは、2人の人が同じコンピュータの前に座り、同時に同じコードを共同作業するというものです。モブプログラミングでは、1台のコンピュータを使ってコード

コロナ前からですが、リモートでモブ作業をすることがすっかり当たり前になりました。会議を含むリモート作業がうまくいくための条件はいくつか思い当たるのですが、こちらのサイトでシンプルにまとまっていたので、紹介したいと思います。 Remote Mob Programming | How we do Remote Mob Programming. 紹介されている原則は以下の15個です。 Remote Everybody (全員リモート) Camera Always On (カメラは常時オン) Regular On-Site Meetings (定期的に対面で会う) Small Team (小さなチーム) Same Time (同じ時間) Typist and the Rest of the Mob (一人は入力者、残りはモブ) Screen Sharing (画面共有) 10 Minute Int

リサとジャネットの Agile Testing Condensed という短い書籍があるんですけど、これの翻訳をお手伝いしました。権利周りの調整のお手伝いと、翻訳レビューです。 leanpub.com アジャイルテスティングという、日本ではそんなに盛り上がっていない分野がありまして。アジャイル時代にどのように品質を担保するのか、QAやテスターはどのように関わっていくのか、非常に大事なんですけど、なぜか日本ではTDD(テスト駆動開発)やテスト自動化についての注目に比べても、今ひとつ盛り上がっていない感じがします。惜しいことです。 Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all me

先週末はオープンセミナー広島さんにお邪魔してお話させていただきました。資料は下のものです。資料冒頭で「西島カーブ」の話をしました。 osh-web.github.io speakerdeck.com 前日に観光に行った呉市の大和ミュージアムで、呉の海軍工廠の成り立ちから戦闘艦を国内生産する話を勉強しまして。そこで科学的管理法が連呼されてて、なんだろうと思って調べたわけです。 yamato-museum.com そうしたら、西島技術大佐の「西島カーブ」というのにたどり着きまして。 http://hesaka.sakura.ne.jp/nishizima.html もう10数年前に前間孝則の「戦艦大和誕生」を読んでいた時、主人公であるところの西島亮二が呉工廠で工程管理を行うために生み出された「西島カーブ」なるものが出てきた。しかしこの工程管理手法についての説明は概略のみであり、また造船所勤めと

RSGT2020今年もつつがなく開催できました。お陰さまですごく楽しかったという声を多くお聞きしてほっとしてます。スタッフのみなさんおつかれさまでした。スピーカーの皆さんも高いプレッシャーの中、出来る限りのものをぶつけていただいて、本当に感謝していますし、すごいなーと思います。尊敬します。 すごく雰囲気が良かったというご評価をいただくことが多くて、大変ありがたく感じております。雰囲気作りについて、ちょっと思ったことをFacebookに書いたら長くなったのでブログに転記しました。 カンファレンス会場の雰囲気なんて参加者の人たちが作ってるものなので実行委員はなにもしてません。なるべく会話を邪魔しないで済むように空間を考えたり、大きく声を出して指示しなくても自然と必要な場所に流れるのがベスト。そのために例えば受付では変な人が入ってこないようにリスクを摘み取ってたり、場を壊してしまいそうなリスクを

プロダクトオーナーが忙しい、プロダクトバックログ書いてくれないって話をよく聞くんですけど、そのあと話を聞いていくと実はプロダクトオーナーは同じ会社じゃないんです、お客さんなんですっていうパターンがちょくちょくあります。 プロダクトオーナーがやる仕事は結構あります。 ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む なるべくROIを高められるようにプロダクトバックログを優先順位付けする。 直近の数スプリント分は準備完了(チームが着手可能)にする チームと定期的に話し合ってバックログを見直す(リファインメント) すべてのステークホルダーと話す 予算を取る バックログの内容についてチームからの質問を受けつけ、明確化する チームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする 受け入れた成果物をリリースすべきときにリリース

RSGT2020の基調講演をやっていただく Jim Coplien さんによる、大規模組織のお話がありました。 この話を聞くのは実は三回目(飲み屋、ウィーンでのScrum Gathering、今回)ですし、ありがたいことに、色んな人に日本語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。 いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。 人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違う

実践アジャイルテストの続編である、More Agile Testing の第一章が、アジャイルテストの歴史を端的に書いてていいな、と思ったのでその部分だけ訳してみました。 More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley Signature Series (Cohn)) (English Edition) 作者: Janet Gregory,Lisa Crispin 出版社/メーカー: Addison-Wesley Professional 発売日: 2014/09/30 メディア: Kindle版 この商品を含むブログを見る 第一章 アジャイルテスティングはどのように進化してきたのか 私たちは、それぞれ、エクストリームプログラミング（XP）チームの中のソロのテスターとして「アジャイル」なキャリ

大きめの企業でスクラムで回し始めて、ビジネスもうまくいくようになってきたところで、急に訪れがちなのが「体制変更」です。これまで陰に日向に支援してくれた上司や役員の方がいなくなって、新しい方がいらっしゃるという。ここで苦労したり、諦めてしまう例が多いと感じます。 答えはないのですが、雑多な考えをここに記録しておこうと思います。まとまってもいないので、無駄に長くてごめんなさい。 うまくいく確率は論理的に50%を下回る 「新しい人とうまくいく可能性もあるので、50:50じゃないの」という意見もあるかもしれません。しかし、なにかを始めるときはだいたいうまくいきそうな上司や役員を選んで相談するわけです。しかし、人事異動で次に来る人は選べません。ですから、うまくいっていたことがうまく行かなくなったり、説明を求められたり、基本、いままでよりは手間が増えることは確実ですし、その結果、フラストレーションが溜

スクラムギャザリングというカンファレンスの実行委員会がありました。実行委員会といっても、会議をやってるというより、淡々と決めて作業を進める会です。このカンファレンスは2011年からやっていて、来年でちょうど10年になります。紆余曲折ありながらも、ここ数年は実行委員業も枯れてきて、ああうまくいくアジャイルチームってこういう特性あるのかもな、と気づくところもありまして。今日はそのあたりを記してみます。 今日は趣意書の公開まで 今日は 4-5時間ほどで、趣意書(スポンサー向け資料含む)と、スポンサー受付のサイト作成までが終わりました。ちなみにWebサイトまでは終わらなかったので基盤まで整えたところで、次回の作業になりました。 趣意書はこちらです。 日本語: Dropbox - prospectus-ja.pdf - Simplify your life 英語: Dropbox - prospec

日本は長かったゴールデンウィークが開けるということで、戻って働けるのかしらという話が飛び交ってますが、いかがお過ごしでしょうか。引き続き Hunter Industriees にいまして、学んだことをメモしておこう、というエントリです。前回のエントリは単体のモブプロについて気がついたことが中心でしたが、今日は複数モブについてです。 Hunterで学んだことその8: 仕事領域 = モブ != 人 3つのモブを持つプロダクトに参加していているのですが、それぞれのモブは同じコードベースで、別の仕事をしています。モブごとに紙ベースのタスクボードをホワイトボードに作っていて、WIPは1に制限されてます。 これは私がソフトウェアを作る人生の中でも初めて体験したのですが、モブは作業場所なだけでなく、どの部分をいじっているか、も示します。フィーチャーブランチを切らず、トランクベースで開発しているので、同じ

日本方面は、平成最後とか、令和こんにちわ、連休ながーい、という噂を聞いておりますが、私はなぜか米国に来ていて、フィーバーに参加できておりません。アベンジャーズは一応、公開日に観に行きました。字幕ないし、アメリカンジョーク(推測)とかは聞き取れなかったんだけど、そんなのどうでもいい感じの映像美でしたね。 Hunter Industries にお邪魔してます モブプログラミング・ムーブメントを生み出した、Hunter Industries に来てます。２年前に半日だけお邪魔したんですけど、モブ自体には参加してなくて、もうちょっといろいろわかりたいな、と思いまして。1月にRegional Scrum Gathering で来日してくれた、Director のクリスさんにお願いしてみたら、いいよーってことだったので、お邪魔しに来ました。 ビザの関係で生産活動には従事できないのだけど、横で立ってるの

沖縄でみんなでつくった Fun! Done! Learn! が広がりをみせていて、作った人の一人としてとても嬉しいです。ちなみに私の貢献は寝坊して起きてきた朝に「いいねそれ！」って言ったことと、「Deliverは長いし、汎用性考えるとDoneのほうが使いやすそうだし、なにより英語でも日本語でも語呂がいい」って主張したくらいです。つまりだいたい私のおかげだと思っております(壮大な勘違い)。 yattom.hatenablog.com 大事なポイントは、私たち、全然教えてないのに、これだけ広まって、成果の声が届いていることです。これは、なんかすごいものを、見つけてしまったのではないかと感じています。みなさんの共通の、心のなかにあったものを、見える化できたんじゃないかと。 このエントリは、私の心の中にあったものを、書き出してみたものです。Fun! Done! Learn! とは一体なんなのだろう