サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
今年の「#文学」
kawaguti.hateblo.jp
品川アジャイルでは呼ばれたら各スクラムフェスにお邪魔して配信のお手伝いをしているのですが、お手伝いさせていただけることはうれしいものの、どちらかというと、あらゆるカンファレンスの運営の方に「配信することをあきらめてほしくない」と思ってやっています。 カンファレンスの配信において注意しているのは、だいたいこんな感じです。 機材に詳しくない人でも運用できる 一日中放っておいても動く安定性 発表者が慣れているZoomと画面共有を使う 発表者PCからHDMI接続する際のトラブルを避ける そのままクラウドに録画録音して録画漏れを避ける (公開するかどうかは選択) 専任のカメラ担当を置かない (活人) 専用の機材を置く机を作らない (活スペース) 会場に映っていない、音が出ないことでオンラインの異常を検知する (ポカヨケ) 通常の配信では、「詳しい人しか使えない機材は使わない」ようにしています。普通に
コロナ後リブート開催のAsianPLoPのエクスカージョンで、埼玉県入間市にある東野高校に行ってきた。米国の建築家であり、パターンランゲージという取り組みで、アジャイルの源流に大きな影響を与えたクリストファー・アレグザンダーが設計したことで、界隈では知らない人がいない場所だ。(ただし界隈はそんなに広くない気もする) 盈進学園東野高等学校は、ただ偶然に外国人の建築家を呼んで校舎を作ってもらったわけではなく、まず先生方が移転にあたって理想的な学舎を考えるという試みが2年あった上で、実現できる建築家を探して『オレゴン大学の実験』に辿り着き、偶然の伝手で、中埜先生が軽い気持ちで誘ってみるところから実現してしまったらしい。中埜先生がアメリカ留学で身につけた楽天的にトライする文化も、先生方の熱意も常務理事さんのビジョンも地域の協力もゼネコンさんの妥協も、全てが組み合わさってそこに結実してた。完璧はない
プロダクトオーナー(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 アドベントカレンダーなのに業務連絡っぽくなってしまって恐縮なのですが、最近ハラスメントポリシーへの対応についてみんなの思いを文章化する作業をやってましたので紹介させてくださーい。 ポリシー作ったのはいいんだけど、ポリシーの運用って実は地道に大変な作業だったりします ルールは作っただけでは何も効力を発揮しなくて、関係者全員が理解して、遵守に向けて動くという多数の行為があって効果を発揮する。プロセス全体を見ると相当なハイコストだと思う
脱予算経営 Beyond Budgeting の 12原則というのが BBRT のサイトにあったので日本語訳をつけました。 Beyond Budgeting - enabling business agility 脱予算経営 - ビジネスアジリティを実現する Leadership Principles リーダーシップ原則 Purpose - Engage and inspire people around bold and noble causes; not around short-term financial targets 目的 - 大胆で崇高な目的のために人々を巻き込み、奮起させる。短期的な財務目標ではなく。 Values - Govern through shared values and sound judgement; not through detailed rules a
スクラムフェス大阪を無事に終了しました。スクラムフェス大阪は4回目で、第一回は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
DevOpsDays Tokyo 2020 は実施・オンライン配信・延期・中止を検討の結果、中止ということになりました。関係する皆様、ご支援いただいている企業様には大変ご迷惑をおかけしまして恐縮ですが、何卒ご理解をいただきまして、今後も引き続きご支援いただければ幸いです。 www.devopsdaystokyo.org 実行委員会での議論はどのように進んだか? 実行委員会での議論の経緯は以下のような感じでした。 まず中止の場合のコストを検討しました。会場費、キャンセルできない渡航費、通訳、あたりはかかってしまうけど、返金はしたいので前年からの繰越金を手当てしても、資金不足になることはほぼ確定しました。しかし、今後関係者に支援をお願いする可能性がありますが、なんとかなりそうという感触を得ました(ここ大事)。 海外スピーカーのほとんどは来日してくれる姿勢でしたので、そのまま開催する案を検討しま
先週末はオープンセミナー広島さんにお邪魔してお話させていただきました。資料は下のものです。資料冒頭で「西島カーブ」の話をしました。 osh-web.github.io speakerdeck.com 前日に観光に行った呉市の大和ミュージアムで、呉の海軍工廠の成り立ちから戦闘艦を国内生産する話を勉強しまして。そこで科学的管理法が連呼されてて、なんだろうと思って調べたわけです。 yamato-museum.com そうしたら、西島技術大佐の「西島カーブ」というのにたどり着きまして。 http://hesaka.sakura.ne.jp/nishizima.html もう10数年前に前間孝則の「戦艦大和誕生」を読んでいた時、主人公であるところの西島亮二が呉工廠で工程管理を行うために生み出された「西島カーブ」なるものが出てきた。しかしこの工程管理手法についての説明は概略のみであり、また造船所勤めと
RSGT2020今年もつつがなく開催できました。お陰さまですごく楽しかったという声を多くお聞きしてほっとしてます。スタッフのみなさんおつかれさまでした。スピーカーの皆さんも高いプレッシャーの中、出来る限りのものをぶつけていただいて、本当に感謝していますし、すごいなーと思います。尊敬します。 すごく雰囲気が良かったというご評価をいただくことが多くて、大変ありがたく感じております。雰囲気作りについて、ちょっと思ったことをFacebookに書いたら長くなったのでブログに転記しました。 カンファレンス会場の雰囲気なんて参加者の人たちが作ってるものなので実行委員はなにもしてません。なるべく会話を邪魔しないで済むように空間を考えたり、大きく声を出して指示しなくても自然と必要な場所に流れるのがベスト。そのために例えば受付では変な人が入ってこないようにリスクを摘み取ってたり、場を壊してしまいそうなリスクを
昨年初参加した、Agile Testing Days のぼっち対策のポスターが秀逸だと思いました。 パックマンルールを常に心がけよう。 Keep the Pac-Man rule, always in mind! 初参加の人や初対面の人が話の輪に入りやすくなるよう、必ず入り口を開けておきましょう、パックマンの口があいているように。 究極の対策でもなんでもないんですけど、このちょっとした心がけを普及させれば、「入れてあげるようにしよう」「入っていいのかも」という気持ちが少しだけ高まる気がします。 パクりたい。
プロダクトオーナーが忙しい、プロダクトバックログ書いてくれないって話をよく聞くんですけど、そのあと話を聞いていくと実はプロダクトオーナーは同じ会社じゃないんです、お客さんなんですっていうパターンがちょくちょくあります。 プロダクトオーナーがやる仕事は結構あります。 ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む なるべく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)チームの中のソロのテスターとして「アジャイル」なキャリ
リーマンショックの少し後に出た本なのですが、当時書店で立ち読みしたままで、なんとなくちょうどいまくらいの時期に読むとよさそうかなということで、読みました。 ビジョナリー・カンパニー3 衰退の五段階 作者: ジム・コリンズ,山岡 洋一 出版社/メーカー: 日経BP 発売日: 2010/07/22 メディア: 単行本 購入: 8人 クリック: 140回 この商品を含むブログ (43件) を見る うまくいった企業がなぜ衰退するのか 2009年に原著が出ているのですが、ちょうどリーマンショック後の信用収縮が進行しているあたりのようで、序章からその話が出てきます。この研究は5年ほどやっていたそうなので、2009年になったのは偶然で、サブプライムローン問題で破綻したファニーメイについては付録に記載した、とのこと。 本書では素晴らしい業績をあげた企業が、衰退していく例を詳細に追ったものです。前著のBui
大きめの企業でスクラムで回し始めて、ビジネスもうまくいくようになってきたところで、急に訪れがちなのが「体制変更」です。これまで陰に日向に支援してくれた上司や役員の方がいなくなって、新しい方がいらっしゃるという。ここで苦労したり、諦めてしまう例が多いと感じます。 答えはないのですが、雑多な考えをここに記録しておこうと思います。まとまってもいないので、無駄に長くてごめんなさい。 うまくいく確率は論理的に50%を下回る 「新しい人とうまくいく可能性もあるので、50:50じゃないの」という意見もあるかもしれません。しかし、なにかを始めるときはだいたいうまくいきそうな上司や役員を選んで相談するわけです。しかし、人事異動で次に来る人は選べません。ですから、うまくいっていたことがうまく行かなくなったり、説明を求められたり、基本、いままでよりは手間が増えることは確実ですし、その結果、フラストレーションが溜
スクラムギャザリングというカンファレンスの実行委員会がありました。実行委員会といっても、会議をやってるというより、淡々と決めて作業を進める会です。このカンファレンスは2011年からやっていて、来年でちょうど10年になります。紆余曲折ありながらも、ここ数年は実行委員業も枯れてきて、ああうまくいくアジャイルチームってこういう特性あるのかもな、と気づくところもありまして。今日はそのあたりを記してみます。 今日は趣意書の公開まで 今日は 4-5時間ほどで、趣意書(スポンサー向け資料含む)と、スポンサー受付のサイト作成までが終わりました。ちなみにWebサイトまでは終わらなかったので基盤まで整えたところで、次回の作業になりました。 趣意書はこちらです。 日本語: Dropbox - prospectus-ja.pdf - Simplify your life 英語: Dropbox - prospec
ITプレナーズさんで主催しているDevOpsの体験型研修がありまして、見学させていただきました。 この研修はオランダに本拠をおく GamingWorks 社が開発したワークショップをITプレナーズさんが日本語化(のお手伝い)をしたものです。GamingWorks 社はAgileやプロマネ向けのゲーム形式研修を手がけているようなので、今後の拡充が期待されます。 https://www.gamingworks.nl/business-simulations/the-phoenix-project/ 継続的デリバリーの先の世界 ここでいう DevOpsについては、Phoenix Project を参考にしていただくとよいかと思います。当初の DevOps の定義はインフラやデプロイの自動化を中心に考えられたものですが、サイロ化が進行した会社が本当に変化のスピードを上げるためには、組織間の連携や会
日本は長かったゴールデンウィークが開けるということで、戻って働けるのかしらという話が飛び交ってますが、いかがお過ごしでしょうか。引き続き Hunter Industriees にいまして、学んだことをメモしておこう、というエントリです。前回のエントリは単体のモブプロについて気がついたことが中心でしたが、今日は複数モブについてです。 Hunterで学んだことその8: 仕事領域 = モブ != 人 3つのモブを持つプロダクトに参加していているのですが、それぞれのモブは同じコードベースで、別の仕事をしています。モブごとに紙ベースのタスクボードをホワイトボードに作っていて、WIPは1に制限されてます。 これは私がソフトウェアを作る人生の中でも初めて体験したのですが、モブは作業場所なだけでなく、どの部分をいじっているか、も示します。フィーチャーブランチを切らず、トランクベースで開発しているので、同じ
日本方面は、平成最後とか、令和こんにちわ、連休ながーい、という噂を聞いておりますが、私はなぜか米国に来ていて、フィーバーに参加できておりません。アベンジャーズは一応、公開日に観に行きました。字幕ないし、アメリカンジョーク(推測)とかは聞き取れなかったんだけど、そんなのどうでもいい感じの映像美でしたね。 Hunter Industries にお邪魔してます モブプログラミング・ムーブメントを生み出した、Hunter Industries に来てます。2年前に半日だけお邪魔したんですけど、モブ自体には参加してなくて、もうちょっといろいろわかりたいな、と思いまして。1月にRegional Scrum Gathering で来日してくれた、Director のクリスさんにお願いしてみたら、いいよーってことだったので、お邪魔しに来ました。 ビザの関係で生産活動には従事できないのだけど、横で立ってるの
沖縄でみんなでつくった Fun! Done! Learn! が広がりをみせていて、作った人の一人としてとても嬉しいです。ちなみに私の貢献は寝坊して起きてきた朝に「いいねそれ!」って言ったことと、「Deliverは長いし、汎用性考えるとDoneのほうが使いやすそうだし、なにより英語でも日本語でも語呂がいい」って主張したくらいです。つまりだいたい私のおかげだと思っております(壮大な勘違い)。 yattom.hatenablog.com 大事なポイントは、私たち、全然教えてないのに、これだけ広まって、成果の声が届いていることです。これは、なんかすごいものを、見つけてしまったのではないかと感じています。みなさんの共通の、心のなかにあったものを、見える化できたんじゃないかと。 このエントリは、私の心の中にあったものを、書き出してみたものです。Fun! Done! Learn! とは一体なんなのだろう
Regional Scrum Gathering Tokyo 2018で基調講演をしていただいたRechard Sheridanさんの講演の書き起こしが、ログミーTechさんで公開されました。3回にわけて毎日更新だそうです。 logmi.jp ネガティブイベント、官僚化、そしてシャドーIT ネガティブイベント、つまり悪い物事が起こると、組織が反応を起こしますよね。ソフトウェア業界であれば、それは分厚い本のようなものです。文書による承認、委員会の招集、ミーティング、誰かが承認しないといけない申請書で埋め尽くされた分厚い本です。ソフトウェア開発のライフサイクルといった書類です。私たちは、カオスから脱却しないといけません。そしてその分厚い本を司るプロジェクトマネジメントオフィス(PMO)を設立します。 そして官僚主義に至ります。全く仕事が終わらない状態(カオス)から脱却しようとしたのに、今度は仕
アジャイルコーチとして社内でスクラムを始める人のサポートをちょくちょくやってきたのですが、一番多い質問の一つが「緊急の割り込み仕事が多くて予定が立たない」です。作業をどうやって安定させるかはスクラムの本線なのでチームで考えるとして、結構ストレスなのが、割り込みたい人への対処だったりします。 むしろ緊急にして持ってくる人がいる 割り込みを持ってくる人は断られないようにむしろ緊急にしてから持ってくる傾向があります。列に割り込んで一歩でも前に出られたなら承認欲求が満たされるケースとか。私が責任者だから私の意見が通らないといけないと思っているとか。 透明性を担保して相手も理解できるようにする 透明性と心理的安全性を確保して、早めに相談する方が得な環境を作れるといいんじゃないかなぁって思います。スクラムだと、プロダクトバックログを透明に保って、誰でも見られるようにして、その上で何番目にその案件を位置
RSGTの来年の会場である御茶ノ水ソラシティさんの見学をしました。そのあとスタッフ打ち上げ。 RSGTのスタッフの合言葉は「頑張らない」です。カンファレンスの運営って、お祭りなので頑張っちゃう、おもてなしなので張り切っちゃう、非日常なので情熱をぶつける...いつも以上にパワーが出てしまうものだったりします。 スタッフが燃え尽きないカンファレンス ですが、終わった後で「疲れたなー。もういいや」って思った人は、翌年の開催の時にはスタッフをやってくれない可能性が高くなると思うんです。毎回ボランティア集めに奔走したり、業務命令みたいな形でお願いするのは、実行委員の負荷も上がってしまって...。 なので私はどのカンファレンスの運営でも「スタッフが燃え尽きない」ことを第一に目指しています。誰も燃え尽きなかったとは言えませんけど、スタッフの負荷が上がるようなタスクや要件を増やさないこと、あるいはやめてし
こんなご相談をいただきまして。 スクラムマスターは支援者だとは思っているんですが言葉が難しく…提案や促し?ではなく「指示」なってしまう場面があり上手く出来なくて うーん、まあそんなに焦らず、刺激を与えたらその反応を、じっくり観察していきましょう。ってなアドバイスをしまして。 スクラムマスターっていうのは、人を変えるというか、理解を促したり、姿勢を矯正していくような仕事なので、「30m走りなさい」って言えるPOとはちょっと違ってですね。人間という複雑なものを複数束ねたチームというのを扱うので、とにかく刺激->反応を見るを繰り返すしかなかったりすると思います。 なので、「こうしてほしい」に「はいやります!」っていう変化は単純、もしくはうわべだけなので、もうちょっと本質的な深い変化を観察する必要があるかなと思います。 問題 (ミーティングが長い) -> 対処 (短くしたほうがいい) ... では
次のページ
このページを最初にブックマークしてみませんか?
『kawaguti’s diary』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く