サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
agile-monster.com
Regional Scrum Gathering Tokyo2023 の中の moyiyuya さんの「私考える人、あなた作業する人」というセッションが大きな反響を呼んでいました。 スクラムを導入してチームとして一体感をもってプロダクト開発をよりうまくやっていきたかったはずなのに、いつの間にか「私考える人、あなた作業する人」という関係性ができてしまっていた、という相談を受けることがあります。 なぜこのような「私考える人、あなた作業する人」という関係性が生まれてしまうかについて、コミュニケーションの観点で考えてみます。 プロダクトオーナーと開発者の堺目 「私考える人、あなた作業する人」のような関係性が生まれてしまっているチームでは、開発者からプロダクトオーナーに対するコミュニケーションが以下のようになっていることが多いです。 プロダクトバックログを出してくれたらつくります 仕様を決めてくれた
この記事は、「子育てエンジニアAdvent Calendar 2021」1日目の記事です。 子育てエンジニア Advent Calendar 2021 - Adventar adventar.org 子供が生まれると自由な時間が減って学習できなくなる！ なんて不安を感じたことはありませんか？ 確かに子供が生まれると子供中心の生活に変わり、それまで自分が自由に使えていた時間が減ってしまうことが多いです。ナレッジワーカーの側面が強いエンジニアにとって、これは死活問題に見えます。特に学習意欲が強いエンジニアほど、学習に使えていた時間が減る＝成長が鈍化してしまうのではないか？と不安に駆られやすいでしょう。 ところが、子どもが生まれてから3年経った今、このような不安を感じていた自分はおこがましかったなと感じるようになりました。 わたしの家族 2021年12月現在、こんな家族構成でおもしろ楽しく生活し
ソフトウェア開発の現場においても、地獄への道は善意で舗装されている�のかもしれないと思った話。 地獄への道は善意で舗装されている 「善意でなされた行為であったとしても、その実行により意図せざる結果が招かれるの」意 エンジニアの手を煩わせたくない！開発組織のマネージャーやプロジェクトマネージャーなどの方が�、「エンジニアの手を煩わせたくない」というセリフを口にすることがあります。 その動機は、 エンジニアには開発に集中してもらいたいそのためにも開発以外の仕事はなるべく自分たちで裁こうといったものであり、エンジニアのためを思っての言動です。善意に満ち溢れていて、とても素晴らしいことだと思います。 ところが、その善意から来る行動が、 自らがビジネスとエンジニアの間に入って仕事をまわす気が散らないようにエンジニアの見えないところでコミュニケーションをする決まったことだけをエンジニアに伝えるというコ
簡単なお題で18分弱におさめていて、ところどころ字幕を入れています。モブプログラミングの進め方や雰囲気をつかんでもらうのにお手頃なサイズ感です。 モブプログラミングに興味がある人やチームに見ていただいたり、ワークショップや勉強会での紹介に使いやすいように編集しています。 以下の資料と合わせてご自由にお使い下さい。
新型コロナウイルスの影響でWorking From Homeをする人が多くなった。そして、オンライン会議などをする際に顔を出すべきか否かという話をよく耳にするようになった。 緊急事態宣言が全国的に解除されて、リモートワークを続けるのか元通りの会社生活に戻るのか、というこのタイミングでこの問題について考えてみる。 オンラインコミュニケーションでは顔を出すべき？オンラインコミュニケーションの場では顔を出すべきだ、といわれる主な理由はこんなところだ。 何しているのかわからないコミュニケーションが円滑でなくなってしまうオフラインでは顔を出している仕事なんだから個人的にオンラインで自分が話しているときに参加者の反応が見えずに不安になった経験があるので、顔を出してほしい気持ちは少しはわかる。一方で、これらは少し極端な意見に聞こえてしまう。 「オンラインはオフラインの代替」なのか？こうした意見の根底には
「スクラムガイド」モブリーディングとは文字通りチームで「スクラムガイド」を読むだけです。 個々に読むのもいいですが、ふだん働いているチームで雑談しながら読み合わせをしたかったので、モビングスタイルで読みました。全員で同じ画面を見ながら輪読し、気になったところや分かりづらいところは「ああでもない」「こうでもない」と議論をしながら読み進めていきます。 スクラムガイドはとても短くまとまっているところが素晴らしいです。どれだけじっくり読むかによりますが、そこそこ議論をしながらすべて読み合わせをするのに、2回に分けて合計2時間程度で終わりました。見積もりのご参考までに。 モビングについて学びだければ、こんな素晴らしい本が出たそうですよ！ 「スクラムガイド」で面白かったところ今回モブリーディングをして、改めて面白かったところをご紹介します。 スクラムの定義スクラムとは、以下のようなものである。 • 軽
この記事は、インセプションデッキAdvent Calendar 9日目の記事です。 XP祭り2019 に参加した際に、角谷さんとこんなやりとりをしました（遅くなってすみません） 言い忘れたけど、@TAKAKING22 のビブリオバトルでのインセプションデッキ案外使いづらい、はそれはそう(なんかやるつもり) — Kakutani Shintaro (@kakutani) September 21, 2019 手前味噌かつちょっと古いのですが…https://t.co/QyDGfsAHNN 確かにカスタマイズ具合についてはあんまり公開されていないです。ということで今度最近つくったインセプションデッキのカスタマイズについてブログでも書いてみます。 — TAKAKING22 (@TAKAKING22) September 26, 2019 体感としてインセプションデッキをやっている現場はそこそこ多
モブプログラミングに関するAdevent Calendarを、昨年に引き続き今年も立ててみました。まだ空いている日があるのでぜひ飛び込んでみてください。アウトプットの年末調整です。 なぜモブプログラミングの導入についてなのか今年もモブプログラミングについての講演、ワークショップ、現場相談会などをさせていただく機会がたくさんありました。そうした際に、 「どうやってモブプログラミングを導入すればよいですか？」「モブプログラミングのファシリテートについて教えてほしい。」など導入する側としてのアドバイスを求められることがありました。 モブプログラミング自体はかなり広まってきているものの、いざ自分の現場でやってみようと考えると、自分以外はモブプログラミングを知らない／やったことがないメンバーばかりなのでどうやって導入すればよいのかわからない、という状況が多いようです。 自分のチームでは導入してから（
まとめ職人がいそうになかったのでつくりました。随時アップデートしていきますが、あくまで個人によるまとめなのでご容赦ください。 当日のスライド、当日のスライドの一部と思わしきもの、補足として紹介されていたものなどをまとめておきます。
現代サッカーは、戦術化とデータ化が進んでいてとても面白いです。 サッカーは世界で最も人気のあるスポーツチームに関する知見、研究、理論の宝庫プロダクト開発との共通点が多いという点から学べることがとても多いです。 ゲームモデルをはじめて知った時に、きっとこれはプロダクト開発に活かせるに違いないと思い、いろいろな本や文献を漁って、実際にチームでつくってみて、今回の講演に至りました。 中でもこの本はとても参考になりました。著者である脇さんは、高校のサッカー部の監督であり、未経験からサッカーを学び、ゲームモデルをつくり、それを広める活動をされています。ゲームモデルの作り方の説明だけでなく、どこにポイントがあるのか、どうやって伝えていくのかまで丁寧に書かれています。
10個のタフクエスチョンが用意されていて、チーム全員で話し合いながらそれに答えていく形式で埋めていきます。最終的にチーム全員で合意したものがインセプションデッキとしてアウトプットされます。 キックオフMTGやPMBOKでいうプロジェクト憲章のように、仕事を進める上で既に似たようなことをやっているかと思います。ですが、やっている目的を達成できているかを再確認してみるとよいでしょう。 一部の人間だけで決めてない？ 一方通行に説明して終わっていない？ 都合がいいことだけしか話してなくない？ メンバーの不安に思う点は感じることができた？ テンションがズレてない？ ただの根性論になってない？ つくった後に見直したことある？ これらに「YES」と言えるならいまのままでよいでしょう。 インセプションデッキの良いところは、チーム全員でタフクエスチョンに答えるという共通体験を通して真の合意にたどりつくプロセ
2019年1月末にチームでFA宣言をしました。この度、無事にチーム転職することができたのでここにご報告いたします。 7月1日付けで、株式会社デンソーにチームごと移籍しました。MaaS開発部でクルマの未来を創る予定です。 アジャイル開発チーム発足からわずか1年でMaaSリリース！ デンソーのチームビルディング【デブサミ2019】 (1/2)|CodeZine（コードジン）
2019年6月30日をもって楽天株式会社を退団することになりました。楽天には2009年に新卒で入社したので、丸10年間在籍したことになります。ディケイドです。 人事との退職者面談でネガティブな辞める理由をしつこく聞かれてイラッとするくらいには、楽天という会社が大好きです。 辞める人にはネガティブな理由があるって決めつけてはいけないな、カブロン！様々な機会で注目されることが多く、すべての人に好かれる会社だとは思わないけれど、自分にとっては最＆高の1社目でした。まさか入社した時には、会社が英語化して、楽天イーグルスが優勝して、バルセロナのスポンサーになって、ヴィッセル神戸にイニエスタとビジャが来て、第4の携帯会社になるなんて想像すらしていませんでした。こんなに刺激的で突拍子もない会社は他にないです。制御不能な自分が好き放題できたのも、会社の懐の深さと、まわりの人達に支えられたからに他なりません
「BPStudy#140〜IT企画／エンジニアリング組織・マネジメントを語る会」というイベントで1on1についてのLTをしてきました。
以前、スクラムマスターを雇う時に聞いてみるとよい38個の質問 を読んで面白そうだなと思っていたら、実際にこれに回答をする記事をちら見したので、読みたい衝動を抑えてまず自分で答えてみることにしました。回答したら @Ryuzee さんが点数を付けてくれると聞いて（言ってない）。 回答するにあたって、 「コンテキストに依る」は全てにおいてそうなので禁止問題に対するつっこみはなしを前提に真摯な態度で回答しました。 また、自分はここしばらくキレイなスクラム／スクラムマスターをやっていないので、基本的には「自分だったらどうする？」をベースに回答しているのと、スクラム／スクラムマスター前提の質問に対しては「転生したらスクラムマスターだった件」という気持ちで答えております。 答えてみてスクラムの復習にちょうどいいかもー！！ 復習じゃなくても「自分（たち）だったらどうする？」を考えながら回答していくことで、
FYI : 所謂「斜に構える」は誤用この記事をきっかけに「斜に構える」の語源について調べてみました。 １. 剣道で、刀を斜めに構える。 ２. 身構える。改まった態度をする。 ３. 物事に正対しないで、皮肉やからかいなどの態度で臨む。 斜に構える - コトバンク 普段使っている「斜に構える」は 3 のイメージが強いが、実はこれは誤用が定着してしまったもので、本来は 2 の意味らしいです。
Fun Done LearnとはFun Done Learnはふりかえり手法の1つです。詳しくは以下を御覧ください。 やり方に正解はないので各々でやりやすい方法を見出していけばよいですが、 アウトプットの時間：Fun Done Learnを意識せずにとにかくやったことを付箋に書き出すマッピングの時間：付箋をどこに貼るか話し合いながらマッピングするのように、アウトプットの時間とマッピングの時間を区切ることがコツだな、としばらくやってみて思いました。「マッピングのことを考えながらアウトプットする」など2つのことを同時に進めるのは人間には難しいので、1つのことに集中できるように進めることをおすすめします。 モブチームのFun Done Learnタイミング自分のチームでは、だいたい以下のようなリズムで働いています。 ※「Art」や「Science」が気になると思いますが、それについては後述します
2/23（土）に「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」が発売します。すごく良い本なので良かったらお買い求め下さい。既に予約開始しているようなのでぜひご予約下さい。 解説しましたなんとありがたいことに、この本の解説文を書かせていただきました。 お話をいただいた時、正直なところ、 「原著者の方の名前は聞いたことないし本当に面白いのかなー」 「心の底からおすすめしたい本じゃないと解説は書けなそうだ」 などと思い、出版社の担当者の方にもその旨を伝えていました。 ところが読んでみて本当に面白かったので、心置きなく解説させていただきました。 今でもモブプログラミングをずっと現場でやっていて、いろんな場所で講演・研修・ワークショップをやってきて、「この本はモブプログラミングの必読本だ」と自信を持っておすすめできます。 内容について章立ては以下です。 第1章
一方で、 すごい個人・一緒に働いてみたい個人の名前は挙がっても、すごいチーム・一緒に働いてみたいチームの名前はなかなか挙がりません。なぜでしょうか。 せっかくいいチームができても会社や組織など様々な事情によって壊れてしまい、チームの寿命がそんなに長くないことが大きな要因のような気がしています。もちろんチームが長生きすればいいわけではないですし、チーム至上主義を謳いたいわけではありません。 私達はチームで今後について話し合ったときに、純粋に「もう少しこのチームでやりたいことあるよね」という想いが一致したため、チームFA宣言をすることに決めました。 全員に当てはまることではないことは知っていますが、「チームで転職する」という選択肢がもっとふつうになれば、もっと楽しい世界になるような気がしています。 私たちのチームFA宣言御社のベネフィットビルドされたチームごと採用することができますチーム採用を
エンジニアリングマネージャー界隈でよく聞く話マネージャーは役割であって上下関係ではないマネージャー＝エラいという不文律が存在している組織がまだまだ多い。そうではないと言ったところで給与体系が違ったり、組織上ツリー構造の上位に位置していたりする。マネージャーになることを「昇格」と呼んでたりするのは、こういう風習の表れだったりする。 それにしても「部活のマネージャー」と聞いて上下関係を思い浮かぶ人はいないのになんで「組織のマネージャー」になると話が変わるのだろうか。部活のマネージャーは仲間だけど、組織のマネージャーは仲間だと思えないのかもしれない。 ところが少し前からWorks Rulesの影響などもあって、徐々にマネージャーというものが見直され始めてきているように感じる。役職としてのマネージャーから役割としてのマネージャーへと目線が移ってきた。 自分もそういう考え方のほうが好きで、メンバーと
楽天株式会社で新規事業のエンジニアリングマネージャーをやっている @TAKAKING22 です。 最近「エンジニアリングマネージャー」が流行っていますね。弊社にはそんなかっこいい役職名はないんですが、いわゆる開発部のマネージャーをやっているのでエンジニアリングマネージャーがわかりやすいと思って最近使っています。 意識低いエンジニアリングマネージャーを目指して意識低いエンジニアリングマネージャーを目指してやったことについて書いてみます。 なぜ「意識低い」なのかというと、そもそもマネージャーにはなりたくなかったのでできる限り要領よくマネジメント業務を効率化してその分プレイヤーとして仕事をしようと考えたからです。なんと意識が低いのでしょう。 でも「俺がマネージャーだ！（ドンッ）」みたいにマネージャーになっただけで偉そうに振る舞ううざいマネージャーになるよりは意識が低いマネージャーの方がマシだと思
Calendar page for Qiita Advent Calendar 2018 regarding モブプログ ... また空いてるので「書いてみようかな」って少しでも思った人はぜひ書いてください！ Advent Calendarはやったことあるかないかや、エキスパートであるかどうかに関係なく、この流れに乗ってアウトプットするぜっていう勢いがすべてだと個人的には思っております。せっかくなのでモブで記事を書いてみてはいかがでしょうか（ネタ提供）？ モブプログラミングのよくある誤解この1年半近く、モブプログラミングについていろんな方とお話する機会があったんですが、その中でよく出てくるモブプログラミングのよくある誤解について書いてみようと思います。 前提として、「モブプログラミングはすべてにおいて最＆高だからやるべきだ！」とは全く思っていません。 ですが、SNSなどを見てもネガティブな
【増枠】Tech-on MeetUp#03「Agile for Developers ～やってみよう！お作法だけじゃないアジャイルレシピ～」｜IT勉強会・イベントならTECH PLAY［テックプレイ］ Tech-on MeetUp#03「Agile for Developers ～やってみよう！お作法だけじゃないアジャイルレシピ～」で、「超アジャイルのすゝめ」というお話をしてきました。 資料久しぶりに、モブプログラミングではなくアジャイルの話をしました。話したいことを話せたので楽しかったです。 資料だけ見ると煽り気味に見えてしまうかもしれませんが、LTのノリで作ってしまったのでいつもどおり現場での臨場感重視です。メッセージ・内容はいたって真面目です。 イベントではいろいろな人とお話できて嬉しかったです。 「デブサミや過去の資料を見てモブプログラミングや現場改善に取り組み始めた」や「明日から
エンジニアが勉強会で話を聞きながらタイムラインで騒いでいる理由①インプットしながらアウトプットするため講演を聞くという行為は、どうしてもインプット一辺倒になってしまいがちです。そして集中して聞こうと思っていても、人間の集中力は脆いので興味がない話が続くと集中力が途切れて眠くなってしまいます。また集中して聞くことに夢中になり、なんかためになったけどよく覚えていないという経験がある人も多いのではないでしょうか。 人の話を聞きながら（インプット）自分の言葉に変換して出力する（アウトプット）という行為は簡単なようで難しいです。機械的な全文書き起こしでもしない限りは、相手の話していることを咀嚼して自分の理解に落とさないと自分の言葉には変換できません。「重要なことだけ書く」ということは、何が重要で何が重要でないかという自分の理解／判断のステップを挟んでいるのです。 インプットとアウトプットは表裏一体で
更新した内容全体のデザイン・言葉遣いの調整最近のスライド内容から学びの部分のスライドを追加「モブプログラミングについて知る」の情報を最新化資料
CEDECという場まさかゲーム業界にいない自分がCEDECという場でお話できるなんて思っていませんでした。なので今回参加＆講演できることになってとても嬉しかったです。 参加してなにより驚いたのはCEDECという場の熱量です。業界は違えど、負けていられないなーと思いました。来年はちゃんと公募出して参加しよう！ 資料モブプログラミングのお話はたくさんさせてもらってきましたが、今回はいつもと違う場でお話するということで、かなり準備に苦労しました。 具体的な事例よりもそこから抽出した学びを中心にするプロダクトづくりを生業にしている人であれば業界が違っても伝わる言葉で話す「生産性」について本気で考えるチームで仕事をするということについて本気で考えるということを意識して構成してみました。うまく話せたかどうかはわかりませんが、良いフィードバックをいただけたのでよかったです。 * CEDEC用に自己紹介ス
セッション概要 5人で1台のコンピュータを使ってプログラミングをする？そんなことをして生産性は高まる？そんな疑問はもっともだと思います。その疑問に回答するのは簡単ではありません。我々が”フロー”の力を理解し始めるまでは - モブプログラミングはどうすれば一つのチームが一緒に効率よく働くことができるかということを探求する過程で発展してきました。一旦始めてみると、我々はモブプログラミングが次のような様々な面でより良い効果を生み出すことにすぐに気づきました。 ・今までよりも多くの作業を終えることができた ・より多くの重要な作業を終えることができた ・作業の品質が劇的に向上した ・チームのナレッジ、スキル、遂行能力が急速に進歩した ・そしてチーム全員がとても楽しんで仕事をしていた 1日を通してみんなで一緒に働くことがこれらの良い効果をもたらす主な要因であることは明らかでしたが、それでもこの働き方が
「OST実践ガイド」がすごくよかった。 個人的にOSTを運営した経験があったことのでジャケ買いをしたが、「OST実践ガイド」はOSTのHOW TO本に留まらず、OSTを通して人と人の関係性や組織のマネジメントなどにも触れられていて、組織づくりや場づくりに興味ある方にもおすすめの内容だった。 Open Space Technologyちょっとだけ前提知識の補足をしておくと、OSTはOpen Space Technologyの略である。 1985年にハリソン・オーウェンによって提唱された。 5人から2000人といった小人数から大人数にまで一堂に会して行えるのが特徴である。参加者が課題を提案してミーティングを行う仲間を募り、課題を解決するプロジェクトを創出することができる。参加者の当事者意識や自発性を喚起するとともに、参加者の主体的な発案、対話を促す。 via オープン・スペース・テクノロジー
Google検索でできる基本的なことググり方のコツ・・・の前にそもそもGoogle検索でできること＝機能について知っておく必要があります。 ここで紹介する以外にも実はGoogle検索には細かなTipsや隠しコマンドのようなものも存在しますが、ここでは代表的なものを紹介します。 AND検索AND検索とは、 ワード1 ワード2 ワード3 のように、スペース区切りでワードを足していくことで実行できます。 入力したすべてのワードに当てはまるページが検索対象となります。 上記の例のようにワードを足していくことで、検索結果の件数が絞られていくことがわかります。検索ワード次第では検索結果が大量に出てきてしまうので、欲しい情報を効率的に集めるためにはAND検索をうまく活用して情報を絞っていく必要があります。 OR検索OR検索とは、 ワード1 OR ワード2 のように、ワードとワードを「（スペース）OR（ス
次のページ
このページを最初にブックマークしてみませんか？
『AGILE-MONSTER.COM』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
