サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
会話術
tmaegawa.hatenablog.com
書籍"Fearless Change: Patterns for Introducing New Ideas"の日本語訳が出版され、ありがたいことに献本をいただきました。翻訳者にはアジャイル界隈で日頃お付き合いをいただいている方々の名前が並んでいます。 原著は Mary Lynn Manns, Ph.D. と Linda Rising, Ph.D.による名著で、2004年に出版されています。それが10年の月日を経て、待望の日本語版が出版されたということです。私自身もこの本は既に原書で読んでいましたが、日本語版についても改めて目を通しています。 そういえば、今の会社に入る時のインタビューで「何をやりたいのか?」と聞かれて、「組織のtransformationをやりたい」と答えたことを思い起こすとともに、今まさにこの本を読み返す必要が出てきたタイミングで日本語版が出版されたのも何かの縁と思って
動画 Spotify Engineering Culture - Part 1 という動画がとてもよかったので、貼り付けておきます。 Spotify Engineering Culture - part 1 from Spotify Training & Development on Vimeo. 関連する参考記事 藤原さんのこの翻訳もあわせて読みたい。同じテーマのHenrikのブログ記事の翻訳です。 Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む | 『リーン開発の現場』越境せよ! 書籍"Fearless Change: Patterns for Introducing New Ideas"の日本語訳が出版され、ありがたいことに献本をいただきました。翻訳者にはアジャイル界隈で日頃お付き合いをいただいている方々の名前が並んでいます。 原著は Mary Lyn
3年前に旧ブログで「ウォーターフォールの興亡」というエントリを書きました。 Always All Ways: [IT] ウォーターフォールの興亡 昨日、そこにコメントいただき興味深い論文を紹介いただいたので、こちらでもご紹介しておきます。 The Rise and Fall of Waterfall まずはその前に、旧ブログのエントリの方で貼り付けていたYouTubeの動画がブロックされて日本では観れなくなっているようですので、改めてvimeoにある動画を貼り付けておきます。 ウォーターフォールモデルの誤解を解く そして、そこに昨日コメントいただいた小椋さんのブログエントリが ウォーターフォールモデルの誤解を解く « 儲けの秘訣を伝授します です。 Royceのモデルがどこかでウォーターフォールという名前のもとで誤解とともに広まってしまった悲劇は有名ですが、「では、いったい誰が最初にウォー
私自身は、研修やセミナーなどで行われるワークショップが苦手です。もちろん、よく考えられて運営されたワークショップで多くの気づきを得る場合もあるにはあります。しかし、なんとなく「ワークショップ的な」ことで適当に時間を埋められたり、なんとなく「座学だけではなく体験型の研修を演出してみました」的なものに付き合わされている感があったり…そんなワークショップも少なくなく、そんな時は疲労感しか残りません。 というわけで、「ワークショップ」と聞くと「面倒くさいなー」「普通に座学させてくれないかなー」とか思ってしまうわけです。(それとは少し違いますが、「パネルディスカッション」という言葉にも似たような感覚を持ってしまうことも多いです。) そんな私ですが、別にだからと言ってワークショップそのものが悪いとは思っておらず、それがちゃんと「デザイン」されていないというところが問題なのだろう…と思うくらいには大人に
今年に入ってからしばしばtwitter上で#NoEstimatesというハッシュタグを目にします。その議論は未だに続いているようですが、ここらでちょっと(後で自分で考えるためにも)簡単に整理しておきたいと思います。(全ての議論を追っているわけではないので、事実誤認などもあるかもしれません。お気づきの点などあればコメントいただけるとありがたいです。) はじまりは、この辺? おそらく、最初のきっかけとなっているのは、Woody Zuillが、No Estimatingのカテゴリーで書いているの一連のブログ記事ではないかと思います。 Life, Liberty, and the Pursuit of Agility » No Estimating で、本人曰く、 #NoEstimates というハッシュタグを最初の使い始めたのがおそらく彼だろうということです。 もう一人、積極的にこのテーマについ
今日は、今(今更ながら)読んでいる本について紹介したいと思います。 その本とは、 Amazon.co.jp: デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns series): アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章: 本 です。 本書は、原書が2001年(その後、Second Editionが2004年)に出版されており、訳書も2005年発売ですので、それほど新しい本ではありません。また、私自身は設計をしたりプログラムを書いたりということから離れて久しいので普段であれば手に取ることはないような部類の書籍ですが、とある場で羽生田さんにおすすめされて手に取った次第です。 著者はAlan ShallowayとJames R. Trott この名前を聞いてピンと来る人はピンと来るでしょうが、"Lean-Agile Software
先日、Scrum Alliance Regional Gathering Tokyo 2013にJurgen Appelo氏が来日するということで紹介記事を書きました。 Jurgenがやってくる ヤア!ヤア!ヤア! - Always All Ways 本日は、そのJurgenが世界各地で開催し好評を得ているManagement 3.0コースが日本でも開催されるという話のご案内です。(特に私自身が当研修の運営に直接関わっているわけではありませんけど。) 開催概要 日付: 2013年1月17日(木)〜18日(金) : 2日間 時間: 10:00 〜 18:00 開催場所: 株式会社 VOYAGE GROUP 会議室パンゲア ( 〒150-0045 東京都渋谷区神泉町8-16 渋谷ファーストプレイス8F ) 価格: 20万円 主催: アギレルゴコンサルティング株式会社 詳細については、以下のサイ
昨日、Agile Japan 2012が開催されました。私自身は今年は参加していなかったのですが、twitterなどで情報を追う限りでは今年も熱く有意義なイベントだったようです。それらを見ながら感じたことと今まで考えてきたことを合わせて、全体の文脈や空気を読まないまま、思いをまとめてみたいだらだらと書いてみたいと思います。 プラクティスのCherry Picking "Cherry Picking"とは、Wikipediaからその説明を引用すると以下の通りです。 チェリー・ピッキング(英語:cherry picking)とは、数多くの事例の中から自らの論証に有利な事例のみをならべたてることで、普遍的な真理や政治的な妥当性を導こうとする論理上の誤謬、あるいは詭弁術。cherry-pickingの語義はサクランボの熟した果実を熟していないものから選別することであり、転じて「いい所取り」「(特売
私自身が、アジャイルなシステム開発やアジャイルな組織についての考えを深める上で、最も影響を受けた人物を5人挙げるとしたら、Tobias Mayer氏は間違いなくそのうちの一人です。 そんな彼が今月から新しいブログを始めました。 Business Craftsmanship 単にアジャイル開発がやりたいとかじゃなく、組織やビジネス環境を変えたいと思ってアジャイルに取り組んでいる人たちにはオススメです。 できればブログを読む前に、その背景などを綴った Welcome to Business Craftsmanship にも目を通しておくとよいでしょう。 そして、昨日公開された最新記事が、 Delete [ScrumMasters] です。 世の中で"ScrumMaster"を名乗っている人たち(「認定」であろうがなかろうが)には、是非読んでほしい記事です。 ScrumMasterは組織の変化に
3月末頃からユルユルと翻訳作業を進めてきた"How to Change the World"(Jurgen Appelo著)の日本語版を、昨日(7/13)無事に出版することができました。 本書は電子書籍版(PDF/EPUB)のみで、達人出版会さんのサイトから購入できます。 How to Change the World 〜チェンジ・マネジメント3.0〜 - 達人出版会 この本との出会い 過去の関連記事は、こちら Always All Ways: [IT] Change Management 3.0 Lulu.comで「世界を変える方法」を買ってみた - Always All Ways 著者のJurgenは、このブログでも再三取り上げている書籍「Management 3.0」を書いた人で、私が最も影響を受けた人物500人のうちの一人です。ご興味があれば是非、ダウンロードして目を通してみてくだ
昔のブログで、アジャイルなプロジェクトやチームにおけるBA(Business Analyst)の役割についてのいくつかの参考資料のまとめエントリを書いていました。 Always All Ways: [IT] AgileにおけるBusiness Analyst そこでピックアップした資料群は、どちらかというとトラディショナルなBAがアジャイルの文脈にどう対応していくかという観点のものが多かったと思います。しかしながら、現実にはもう少しハイブリッドな環境(←実際には過渡期を含めてこのような環境の中でどうしていくかというのは非常に大きな課題だと思っています)に直面することも多く、そこでどう考えるべきかということを、以下の記事を参考にして整理してみたいと思います。 The 3 types of hybrid projects, and how they affect the business an
なんか、id:kent4989さんの記事にかぶせて書くというのが続いて恐縮ですが、 アジャイル開発に求められる人材像に関する雑感 - 勘と経験と読経 を読んでまたいろいろと刺激を受けたので、いくつか考えたことをまとめておきたいと思います。 プラスアルファかマイナスアルファか? id:kent4989さんいわく、 これまでの就職や就社では「賢い」ということが重視されてきたのだと考えているのだけど、これからは「賢いプラスアルファ」が必要ということなのだろうか。じゃあ、アルファの部分に入るのは何なのだろうか。 とのことですが、ここで引っかかった点がふたつあります。 「いやいや、もともと賢いだけじゃないさまざまな要素は求められてきていたでしょ?」っていうのがまず1点。そして、氏がプラスアルファの要素として挙げているのって、程度の差こそあれ、氏が冒頭で「PMの97本」や平鍋さんのブログをわざわざ引用
今朝、巷でちょっと盛り上がっていたやつに私も乗っかっておきます(笑)。 # 最初は乗っかるつもりはなかったのですが、読めば読むほど味わい深いので、私なりの解釈や思うところを書き記しておきたいと思った次第です。 # 元記事の著者お二人の意図に反した解釈を勝手にしている部分もあるかもしれませんが、あくまで私なりの解釈とそれらについての個人的見解とご理解くださいね。 元記事ふたつ ウォーターフォールのほうが楽だという話 - 勘と経験と読経 ウォーターフォールの方が楽ですか? | Ryuzee.com 著者のお二人は個人的にもお付き合いがありどちらも尊敬している人です。ユーモアまじりの記事の中でそれぞれの視点や考え方が出ていて興味深く読みました。 まず、両記事を読んで私が感じたのは、(おそらくお二方も承知の上で敢えて書かれているのだと思いますが) 「どちらが楽か」というのは、PMやコーチとしてメン
「エンタープライズ・アジリティについて考える」シリーズの第3回です。 過去の記事はこちら。 Always All Ways: [IT] エンタープライズ・アジリティについて考える (1) エンタープライズ・アジリティについて考える (2) - Always All Ways 過去2回では、エンタープライズあるいはエンタープライズ・アジャイルといったものをどういう範囲で捉えるか、どう定義して考えるかというような話をしました。今回からそろそろ本題に入りたいと思います。とは言え、このシリーズは明確な全体構想やストーリーがあって書いているわけではありません。相変わらず、思いついたところや書きたいところから順不同に書いていますが、ご容赦ください。 組織レベルでの3つの大きなTransformation 情報システム開発や製品開発におけるアジャイルな組織への転換においても、メンタルモデルというかマイン
DSDMって聞いたことありますよね?そうそう、アジャイル開発手法の一覧みたいな表には必ず含まれているけど、XPやScrumと違って実はあまりその実態を知らないやつです(笑)。もちろん私も聞いたことはある程度で、ちゃんとした知識は持ち合わせていません。(そういう意味だとCrystal、FDD、ASDとかみんなそんな感じですけど。) DSDM: Dynamic Systems Development Method 少し前の記事ですが、DSDMについて面白い記事を見つけたので紹介しておきます。 » DSDM is Agile’s Best Kept Secret? » Agile Scout タイトルを見た時には、昨日のブログ・エントリで紹介したSteve Denningの"The Best-Kept Management Secret On The Planet: Agile"にインスパイアさ
このブログでも今まで、アジャイル開発におけるマネジメントやマネージャーの役割について何回か取り上げてきました。が、今までのはそれでもまだ、どちらかというと「現場より」のマネジメントの話でした。(会社の役職で言えば課長から部長くらいのイメージですかね。) で、もう少し上のいわゆる役員以上くらいをイメージした時に、どうやってアジャイル開発を説明していくかとか売り込んでいくか、あるいはその層をどうやって味方にしていくかという課題に関して、最近のSteve Denningが書いているものが結構ツボにはまる内容なので、注目記事をいくつかセレクトして簡単にご紹介しておきたいと思います。 地球上で最も守られている経営の秘法:アジャイル まず、割と新しいところで最もインパクトのあった記事がこちらです。 The Best-Kept Management Secret On The Planet: Agile
先週は、リーンソフトウェア開発のポッペンディーク夫妻(メアリーとトム)が来日していました。幸運なことに私も、 月曜日はリーダーシップ・ワークショップの一日目に出て〜とんかつ食べに行って〜 火曜日はリーダーシップ・ワークショップの二日目に出て〜しゃぶしゃぶ食べに行って〜 水曜日はSECセミナーでの午前中の講演を聴いて〜 金曜日は夫妻を囲む会でミニレクチャー聴いて懇親会で飲んで〜 という形でいろいろと直接お話をする機会を得ることができました。 本当は、「メアリーから学んだ5つのこと」みたいなタイトルでまとめてみたかったのですが、なかなかうまくまとまりそうにないので、以前のエントリとも絡めて一つだけ書いておきたいと思います。 Don't answer questions これは、以前のエントリ(Scrumを教えるのに最適なフレームワークはScrum - Always All Ways)で紹介した
組織へのアジャイル開発導入とか、アジャイルな組織への変革について考えたり調べたりしていると、温故知新というかなんというか、結構古くからある先人の知恵とでもいうべきものにたどり着きます。その中の一つとして、デミング(W.Edwards Deming 1900-1993)の理論があります。 昨夜も、Bob Marshall氏のTweetから、こんな小冊子にたどり着きました。 Transformation Forum - Managing Transformation actually means Transforming Management ここからダウンロードできるたった12ページのpdfですが、何がいいってこのタイトルですね。というわけで、今回は中身には細かく触れずにこのタイトルだけでちょっと書いてみたいと思います。 "Managing Transformation actually m
id:kent4989さんのエントリに反応しつつ、また少し要求開発界(?)を盛り上げてみましょうか。 元エントリは、こちら↓ 要求開発のホームグラウンドについての考察 - 勘と経験と読経 この中で彼は、要求開発の適用範囲は限られており以下のような領域がその「ホームグラウンド」である、としています。 複雑度が高いエンタープライズ系のシステム (人系を含む)ビジネスシステムのリプレース 対象企業の規模は大きめ 今回はことさらそれに異を唱えるというよりも、世間で「要求開発」が語られるとき、あるいは自分自身が「要求開発」を語るときの、なんというか落ち着かない感じというか、ムズムズ感というか、えも言われぬ心地悪さについてちょっとだけ述べてみたいと思います。 なお、改めて言うまでもないことですが、ここで書いていることは筆者の個人的な見解であり、要求開発アライアンスをはじめいかなる団体その他の意見も代表
Tobias Mayer氏が、「スクラムのワークショップにおける5つの『やってはいけない』」みたいなブログ・エントリを書いています。せっかくなので、その5つを見出しのみ抜粋してみると、 Don't plan the whole workshop. Don't ask questions you already know the answer to. Don't play games with predefined outcomes. Don't answer questions. Don't talk about yourself. Top 5 Scrum Workshop Dont's それぞれの内容については原文を見てくださいね。 Scrumを教えるためのフレームワーク これらの5つのポイントはそれぞれ重要な示唆を含んでいるのですが、私自身は、この記事の中で最も重要なのは、"Scrum
アジャイル開発への取り組みに関して、現場メンバーとユーザ/顧客は前向きだけれども、情報システム部門も含めた社内マネージャ層が支持してくれないという話を良く聞きます。過去、自分の組織の中でのアジャイル開発(Scrum)の導入・展開を推進してきた経験をふりかえってみても、一番説得・突破が難しいのは、情報システム関連の他リーダや品質・リスク管理関連部門などのいわゆる「中間管理職層」であったような気がします。 なぜ彼らは反対するのか? 答えは簡単です。それが彼らの仕事だ(と思っている)からです。 現場メンバーは、変化への反応は人それぞれですが、自分たちがよりよいやり方にトライできるならば比較的柔軟に対応していく傾向があります。また、トップマネジメントやユーザ部門は、よりよい商品やサービスが生み出せたり、Time-to-Marketが短縮できたりすることの方にフォーカスする傾向があるため、その点での
昨日のエントリー(QA versus Testing! Antagonism or Symbiosis? - Always All Ways)でQA/テストからの視点でチーム編成に少し関連することを書きましたが、一般的に、Scrumにおけるチーム編成を行う上でポイントとなることが2点あります。それは、 チーム分けの切り口(フィーチャーチームvs.コンポーネントチーム) メンバーの多能工化の進め方 私自身も過去に複数チームで一つのシステムを開発するような組織へのScrum導入・展開を推進したときにメンバーからよく聞かれました。その時に自分自身で繰り返し参照したり、メンバーに読むことを進めたりした文献がありますので、少し前の文献になりますが改めてここで紹介しておきたいと思います。(「こんなのあるから、一度読んでみて!それから、うちの会社でどうすればいいか一緒に考えよう!」みたいな感じでディスカ
Peter Callies氏がLeadingAgileに書いていた記事が良かったので、簡単にご紹介しつついろいろ思うところをメモ書き。 Agile at the Speed of Trust – An Overview | LeadingAgile この記事は、Stephen M.R. Coveyの"The Speed of Trust"(邦題:『スピード・オブ・トラスト―「信頼」がスピードを上げ、コストを下げ、組織の影響力を最大化する』)をベースに、アジャイルの文脈における「信頼」について論述したものです。今回はOverviewということで今後、続編が出てきそうな気配ですので楽しみです。 アジャイルと信頼/信用の話 アジャイル界隈の人は、「信頼」と聞くと、まずは「信頼貯金」とか「信用貯金」を思い浮かべるのではないでしょうか? たとえば、角谷さんのこの記事(↓)にあるように。 アジャイル開
アジャイル開発というと、まず頭に浮かぶのがXP、Scrum、Lean、Kanbanあたりでしょうか。その中でも私は、リーン(Lean)がイマイチよくわかっていないのです。いやほんとに。確かにいろいろ書籍も出ていますし、インターネット上でも調べればその説明をしたサイトがたくさん出てきますので、その辞書的な説明を字面を追いかけてなんとなくそんなもんかというのはあるのですが、ほかの3つ(XP、Scrum、Kanban)と比べるとなんとなくレイヤーが違うというかスコープが違うというかちょっと靄がかかった向こう側にあるような感覚です。 リーン3部作も2冊目まではピンと来なかった リーンソフトウェア開発と言えば、MaryとTomのPoppendieck夫妻の3部作が有名です。読んだ時期にもよるのかもしれませんが、「リーンソフトウェア開発」は読んだかどうかすら覚えていないし、「リーン開発の本質」も図書館
アジャイル開発の文脈において、自己組織化されたチームという概念がよく出てきます。これはアジャイルなマネジメントを考える上でポイントとなる一つの大きな概念である半面、誤解(時によっては過大評価)されていたり、またそれが故にマネージャの役割が過小評価されているようなことも起きているのではないかと思います。 "But...Self-Organization Is Not Enough"というのはこのブログでも再三取り上げているJurgen Appeloの"Management 3.0"の第8章のある一節の見出しになっているフレーズです。この書籍では、第6章(The Basics of Self-Organization)でも1章を割いてSelf-Organizationの理論的背景や類似概念との比較などがされており、とても参考になります。このエントリでは、そこから私がポイントと思うところを適宜抜
"MANAGEMENT 3.0"は、2010年に出版されたJurgen Appelo氏の著作です。彼のブログ(Agile Management | NOOP.NL)が好きでよく目を通しているのと、slideshareで公開されている彼のスライド群の中でもこの本の内容に触れているものが多いため、すっかり原著を読んだ気になってしまっていましたが、改めて書籍を入手し、読みといています。 人によっては、「アジャイル・マネジメントって何それ?自己組織化されたチームで、マネージャが要らないのがアジャイルなんじゃないの?」という人もいるでしょう。確かに、Scrumのロールにプロダクトオーナーやスクラムマスター、開発チームはあっても、プロジェクトマネージャやマネージャといったロールは定義されていません。しかしながら、組織というものを考えるといずれにしても何らかの形でマネージャという存在が必要であるし、その
今朝、下のようなtweetがあったので、早速、見てみました。 Have you seen the new subway map from @agilealliance? It is awesome. guide.agilealliance.org/subway.html #scrum #agile— Scrum.orgさん (@Scrumdotorg) 2月 29, 2012 ビジュアルのイメージは、下に貼り付けたような感じで、地下鉄の路線図みたいな図の駅に相当するところにいろんなプラクティスが配置されています。もちろん、「駅名」をクリックすると各プラクティスの説明を見ることができます。 http://guide.agilealliance.org/subway.html このガイドについての説明は、こちら↓にあります。 Guide to Agile Practices サイドメニューのア
このたび、アスキー・メディアワークスより書籍「課題管理システム JIRA入門」が発刊され、アトラシアンの大澤さんおよびリックソフト株式会社様のご厚意により、献本をいただきました。ありがとうございます。 ツールを使いこなし、その効果を十分に引き出すには、そのツールの設計思想や「癖」のようなものを理解しておくことが必要であるということはよく言われることです。その意味で、JIRAの基本を理解しないまま、業務では欠かせないツールとして使ってきた私にとっては、まさに待望の書と言えます。原著のタイトルに"JIRA 4 Essentials"とあるように、まさにEssentialsが過不足なく網羅された書です。なお、技術関連の翻訳書ではよく「訳書の出版までのタイムラグにより出版時点では既に情報が古くなっている」ということがありますが、本書は、JIRA4.1と4.2をベースにした原書の翻訳に対して4.4へ
昨日、ふとしたことからダイヤモンド・オンラインで神戸大学の松尾睦先生の記事を見かけました。これって、今まで全くフォローできていなかったのですが、昨年秋からの連載だったのですね。というわけで、今さらながら第1回から読み直しています。 シリーズ「経験から学ぶ力」 ビジネスパーソンが成長するには なぜ経験から学ぶ力が必要になるのか? 神戸大学大学院経営学研究科教授 松尾 睦 ――シリーズ「経験から学ぶ力」①|日本を元気にする新・経営学教室|ダイヤモンド・オンライン 「挑戦し、振り返り、楽しみながら」仕事をし そして「思い」と「つながり」を大切にする 経験から学ぶための5つの要因とは 神戸大学大学院経営学研究科教授 松尾 睦 ――シリーズ「経験から学ぶ力」②|日本を元気にする新・経営学教室|ダイヤモンド・オンライン 経験から学ぶ力を高めるにはどうするか 「挑戦し、振り返り、楽しむ」ための実践的方法
このページを最初にブックマークしてみませんか?
『Always All Ways』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く