サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
digitalsoul.hatenadiary.org
2024/3/5にオライリー・ジャパン様より出版される『組織を変える5つの対話 ―対話を通じてアジャイルな組織文化を創る』のご紹介。 組織を変える5つの対話 ―対話を通じてアジャイルな組織文化を創る 作者:Douglas Squirrel,Jeffrey FredrickオライリージャパンAmazon はじめに こちらの本は Douglas Squirrel氏とJeffrey Fredrick氏の著作『Agile Conversations: Transform Your Conversations, Transform Your Culture』(IT Revolution Press、2020年)の全訳となります。翻訳をするのは『リーダーの作法』(オライリージャパン、2022年)以来約2年ぶり、8冊目になります。まずはこの本を翻訳することになったきっかけから。 フルストリームソリューシ
9月に翔泳社より上梓した『スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー』のポイント整理と、「協調型」リーダーの理解を深めるためにあわせて読みたい本の紹介 『スモール・リーダーシップ』における「協調型」リーダー 『スモール・リーダーシップ』では、リーダーシップのあり方として、「協調型」という言葉を使っています。これについては平鍋さんの推薦の言葉を引用したいと思います。 自分で考え、自分で決め、自分が指示する、というやり方では、現代のプロジェクトは簡単に破綻します。それよりも、一緒に考え、一緒に決め、一緒にコミットするチームを作ること。そして、成功の喜びを分かち合う仲間を作ることのほうが、大きなビジネス成果を生み出すことができるのです。 つまり、リーダーに求められることを一言で言えば、「チームで考えながらゴールを目指す」ことになるのですが、それにあたって考えなけれ
9/11に翔泳社様より上梓した『スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー』について、簡単なまとめとふりかえり。 スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー 作者: 和智右桂出版社/メーカー: 翔泳社発売日: 2017/09/11メディア: 単行本(ソフトカバー)この商品を含むブログ (4件) を見る 出版に至る道のり ソフトハウスでプログラマを始めて以来、システム開発のベンダー側に10年ほど勤めていましたが、2015年10月からユーザー企業の情報システム部に勤務しています。早いもので、もうすぐ二年が経つことになります。「発注者の側に回っても、システム開発に変わりはなかろう」と思っていた部分はあったのですが、いざ移ってみるとその見込みの甘さに気づくことになります。SIer側にいた頃と比べると、文化や基礎知識、さらには責任範囲も
パラダイムを学ぶことと、実際にデリバリーすることとのバランスについて。あるいは転職報告。 導入 9月末を以て、グロースエクスパートナーズ株式会社を退職しました。4年と2ヶ月の間この会社にお世話になっていたことになりますが、その中できわめて多くの貴重な経験をさせていただいたと思っています。退職を決めてから、4年前に自分が書いたエントリ(SIを仕事にするということ)は何度か読み返しました。その中でGxPを表現した次の言葉は、今読んでも正しかったと思います。 ソフトウェアをデリバリーすることには、多くの「泥臭い作業」が伴います。そしてその「泥臭い作業」は本に書かれたり、語られたりすることがあまりない。それはたぶん、語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったりするせいでしょう。だからといって、「そういうこと」をしなくていいわけではない。こ
本に書かれた内容を実際に使うことの難しさについて 導入 ここ一年ぐらい将棋にハマっているのですが、最近は棋力が上がらなくて悩んでいます。序盤で失敗して一方的に敗けるのが嫌なので、序盤から中盤の入り口について解説してある戦型の本をよく読んでいるのですが、いまいち「強くなった」という気がしません。原因は明らかで、「知らない形に出会った時に安定して力が発揮できない」のです。初めて見る局面でも自信を持って指せるようになりたい。多分私が触れたいのは、定跡とか手筋を超えたところにある「棋理」みたいなものなんでしょう。そんな話をあるプロ棋士の先生にしたときに言われたのが「お勉強しても強くなれませんよ」という言葉で、それが妙に耳に残っています。 似たようなことはシステム開発にも言えるのではないか、ということを最近よく思います。そのことについて、「ドメイン駆動設計(DDD)」や「スクラム」を例に言葉にしてい
産業革命期以降における生活の根本的な変化を題材に、今のエンジニアの生活に警鐘をならすLinda Rising氏の発表の要約と若干のコメント。 要約 アジリティ:個人レベルの可能性 Agility: Possibilities at a Personal Level コーヒー、紅茶、コーラといったカフェインを含む飲み物は、世界中で飲まれている。 カフェインは石器時代から知られていたが、最近になるまでは重要な役割を果たすことは無かった。 産業革命は1800年頃のイギリスにおいて起こった。そこで重要な役割を果たした要素はたくさんあるが・・・ 時計の精度が向上したのは、カフェインが使われ始めた時期と一緒。 時計とカフェインが近代市民社会の発達に大きな影響を与えている。 "Command and Control" 昔は朝食にビールを飲んでいた。 昔のことわざ ワインには知識が住み、 ビールには自由が
アジャイルがダメだと思う7つの理由へのだいぶ遅い反応 導入 もうだいぶ前の話になってしまいましたが、アジャイルに関するブログエントリ「アジャイルがダメだと思う7つの理由」は予想以上に波紋を呼び、それに呼応していくつものエントリが公開されました。発端となったエントリに関していうと、通常であれば必要となる数々の留保事項や前提事項を書かずに切り込んでいるという点において、間違いなく「煽り」であると言えます。ただ、「アジャイル」という言葉をとりまく数々の事象をかなり的確に指摘することによって、「アジャイル」という言葉をパブリックな場所で語っている少なからぬ人たちに対して、(意識的か無意識的かは問わず)ある種のポジショニングを強いたという意味で、実にいい釣り針なのではないでしょうか。 個別の論点に関する「アジャイルでは全体スケジュールにコミットできない」「いや、アジャイルだって全体スケジュールにコミ
デブサミ関西2012での講演内容まとめ はじめに 今月、GOOS日本語版が発売されました。 実践テスト駆動開発 (Object Oriented SELECTION) 作者: Steve Freeman,Nat Pryce,和智右桂,高木正弘出版社/メーカー: 翔泳社発売日: 2012/09/14メディア: 大型本購入: 4人 クリック: 262回この商品を含むブログ (31件) を見る継続的デリバリーに続き、高木さんと一緒にお仕事をするのはこれで二冊目です。今回も多くの人に助けられて、目標としていたデブサミ関西での出版にこぎつけることができました。関係者の皆さま、どうもありがとうございました。 講演では触れませんでしたが、ここで「実践テスト駆動開発」というタイトルの由来について少し書いておきます。原書のタイトルはご存じの通り、"Growing Object-Oriented Softwa
DCIを参照しつつ「業務分析」について考える はじめに 最近「アジャイル」という言葉をなるべく使わないようにしています。なぜなら、この言葉に込められた「桃源郷へのあこがれ」が、色々なものを見えなくしてしまうような気がするから*1。例を挙げましょう。アジャイルの基本は、「タイムボクシングによるインクリメンタルかつイテレーティブな開発」であると言え、それを実現するために流派によって様々なテクニックが提示されます。Scrumを見てみましょう。Scrumを実現するために絶対的に必要なのは、プロダクトオーナーによって適切に優先順位付けされたプロダクトバックログなわけですが、網羅性と整合性を保証したかたちでバックログアイテムを優先度順に並べるって、実はものすごく難しいことを言っていませんか? 確かにタイムボクシングによる軌道修正がある程度できるとは言え、「優先順位の低いところは粒度が粗くてもいいよ」で
設計ツールとしてのモックの使い方について考える。 導入 先日、"Mock Roles, not Objects"の日本語版「ロールをモックせよ」を公開しました。この論文は2004年に書かれたもので、著者はSteve Freeman氏、Nat Pryce氏、Tim Mackinnon氏、Joe Walnes氏という豪華メンバーです。また、Steve Freeman氏とNat Pryce氏は『Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))』(いわゆるGOOS)の著者でもあり、"Mock Roles, not Object"で語られている思想はGOOSのベースになっているとも言えます。 今回は、この"Mock Roles, not Objects"(以下、MRnO
パラダイムを学ぶことと、実際にデリバリーすることとのバランスについて。あるいは転職報告。 導入 8月1日にグロースエクスパートナーズ株式会社に入社しました。人生で2回目の転職となります。入社してまもなく一ヶ月が経とうとしていますので、本日はその報告を。ブログ、翻訳、プレゼンに続く舞台裏記事の第4段ですね。私とは違う物事のとらえ方をする方々も多くいらっしゃることは重々承知しておりますし、それを批判するものではないこともあらかじめご了承ください。 転職をした理由 私が7月まで勤めていたのは、いわゆる「ITゼネコン」と呼ばれる元請けSIerでした。開発の実務は協力会社さんにお任せしつつ、自分はメールと打ち合わせに埋もれる日々を送っていたわけです。要件定義から保守まで一通り経験できたという意味で学ぶこともありましたし、アーキテクチャ策定やデータモデル設計のようなことも隙を見てやっていたことは事実で
オーム社様と監訳者の方々より献本いただきました。厚くお礼申し上げます。ありがとうございます! アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本(ソフトカバー)購入: 42人 クリック: 1,991回この商品を含むブログ (257件) を見る はじめに まずは「読者の声」から: 最初は、軽いノリの入門書だろうと高をくくっていた。「マスター・センセイ」だし、そもそも「サムライ」だし。でも、そんなに甘くない。軽い文体とは裏腹に、アジャイルな開発のありかたが、きわめてロジカルかつ網羅的に語られている。ありそうで、なかった本。手元に置いておけば、きっといいことがあるはずだ。 > 和智右桂 『エリック・エヴァンスのドメイン駆動設計』訳者 私はこの本に
著者の方々より献本頂きました。厚く御礼申し上げます。ありがとうございます! プログラミングGROOVY 作者: 関谷和愛,上原潤二,須江信洋,中野靖治出版社/メーカー: 技術評論社発売日: 2011/07/06メディア: 単行本(ソフトカバー)購入: 6人 クリック: 392回この商品を含むブログ (155件) を見る はじめに まずはじめに、これはGroovyを好きな方々、Groovyのことが気になっている方々にとっての必携書になると思います。素晴らしいお仕事をなさった著者のみなさまに感謝します。 さて、本の紹介をする前に、私のGroovyに対するポジションを明らかにしておきたいと思います。過去の記事を見て頂けばおわかり頂ける通り、私は時々Groovyを触っています。たとえばDSLを書いてみたいとき、DCIアーキテクチャで何か作ってみたいとき、モダンTDDを試したいとき・・・。意図が伝わ
プレゼンテーションの下準備を行う際に、普段心がけていることを整理する。 導入 ブログ、翻訳に続く舞台裏シリーズの第3弾として、プレゼン前の下準備の際に自分が心がけていることをまとめておきたいと思います(もう舞台裏ネタはないので、これで最後です)。2010年10月のDevLOVE "Beautiful Development"が、私が個人として行う初めてのパブリックスピーキングでした*1。その時から今まで何度か登壇の機会を頂いていますが、最初のとき以来、事前に必ずやるようにしていることが3つあります。一般的に基本と言われるものがすべからくそうであるように、たいしたことではないのですが、地道にやることでそれなりの効果は得られているような気がします。もちろん、「こうしなければいけない」という話ではありません。「私はこうしています」という話です。参考にして頂ければ幸いです。 内容に入る前に、すこし
2011年7月2日に開催されたTDDBC仙台のレポート。 導入 「TDD Boot Camp」通称TDDBCにはずっと参加したいと思っていたわけですが、今回仙台で機会を得ることができました。最初はJavaでと思っていたのですが、Scala組に入れて頂きまして、山中(@ymnk)さん、武田(@takedasoft)さんと3人でチームを組んでペアプロという貴重な体験をさせて頂きました(どうもありがとうございました!)。最終的には仕様変更2が何となくかたちができたところで時間切れとなりました*1。 プログラムが組み上がっていく過程や、興味深いリファクタリング、うっかりテストを書かずにコードを修正してしまったことによるバグの埋め込み、モックを使ったタイマー処理の分離など、非常に興味深い体験を数多くさせて頂きましたので、ここにご報告させて頂きます。なお、作業中のコードは記憶を頼りに書いていますので、
翻訳に必要と思われる技術について整理する。 導入 私のブログの書き方を紹介したエントリの中でもすこし触れたとおり、翻訳という作業は自分の中で大きな位置を占めるようになってきています。『エリック・エヴァンスのドメイン駆動設計』が出版されて以来、新しい翻訳をやったり、他の方の翻訳をレビューに参加させて頂いたりと、翻訳がらみの仕事が増えてきましたので、この機会に自分が考えていることを整理したいと思います。 なお、この場を借りて大先輩の翻訳論をご紹介しておきます。 翻訳の心がけ - 結城浩さん http://capsctrl.que.jp/kdmsnr/diary/20110326p01.html - kdmsnrさん 私の考える、翻訳に必要な3つの技術とは「英文解釈」「翻訳のテクニック」「日本語作成技術」です。結局のところ翻訳とは、「英文を正確に理解し」「日本語に置き換え」「日本語として自然に読
レッツゴーデベロッパー2011での発表原稿とスライド 導入 2011年05月28日「レッツゴーデベロッパー2011@仙台」が開催されました。このイベントのテーマは「共有と交流」。"「共有」には、最新技術、知識、復興への想い、それぞれの決意を共有することを、「交流」には、東北と東北圏外のデベロッパーやコミュニティ同士の交流を深めることを込めて。" このイベントにてDDDセッションに登壇させて頂きましたので、そのときの発表原稿とスライドを公開致します。なお、当日はワークとして参加者の方にペアモデリングを行って頂きましたが、このドラフトではその部分を割愛しています。 スライドはこちら また映像はこちらで公開して頂いています。 さて今年4/9にDDD日本語版が出版されました。それから2ヶ月弱、翔泳社様から、はやくも増刷のお知らせを頂きました。多くの方々とおかげと深く感謝しています。さて、この増刷が
この記事はMario Gleichmann氏による、「Functional Scala」シリーズの第7回「Functional Scala: Lambdas and other shortcuts | brain driven development」を、氏の許可を得て翻訳したものです。(原文公開日:2010年12月5日) 前回は、関数型プログラミングの世界における最も強力な概念のうちの1つ、すなわち高階関数を見てきました。本質的に、ある関数が高階と呼ばれるのは、他の関数を引数として受け取る場合か、結果として関数を出力する場合でした。この考え方により、抽象化の新しいやり方がもたらされるだけでなく、ある種の状態やいわゆるコンビネータ(関数ビルダと呼んでも構いません)を捕捉したり受け渡したりするといった、かなり便利なこともできるようになるのです。なお、コンビネータとは入力された関数もしくはその
この記事はMario Gleichmann氏による、「Functional Scala」シリーズの第6回「Functional Scala: High, Higher, Higher Order Functions | brain driven development」を、氏の許可を得て翻訳したものです。(原文公開日:2010年11月28日) 関数型Scalaの第6話にようこそ! 今回は、このシリーズでほぼ毎回、何度も言及してきた強力な概念について詳しく見ていきましょう。それが、高階関数です。かっこよくありません?そうでもないですよね。名前がかっこいいだけでは、あなたを興奮させることはできませんから。そこでこれから、どうかっこいいのかを実演し、「高階関数は、関数型プログラミングにおいて、エレガントに、コンパクトに、そして効率的に書くための基本原則の1つである」という、少なからぬ声の原因とな
この記事はMario Gleichmann氏による、「Functional Scala」シリーズの第5回「Functional Scala: Comprehending Comprehensions | brain driven development」を、氏の許可を得て翻訳したものです。(原文公開日:2010年11月21日) 関数型Scalaの第5話にようこそ! これまでに集合の内包について聞いたことはありますか?そうですね、数学の授業を受けたことがあるなら、きっと聞いたことがあるでしょう。しかし、聞いたことがなくても、怖がることはありません!これは単に、ある集合のメンバが満たさなければならない性質を述べることで、要素の集合を定義する数学的な記法にすぎないのです。この説明があまりに抽象的に思えるなら、単純な例を見てみましょう: { x | x ∈ N : x == x² } ここにあるの
勉強と結びつけながらブログを続けていくためのプラクティスについて整理する。 はじめに 先日、『DDD(Domain-Driven Design)』の日本語版が出版されました。謝辞でも触れましたが、この本を翻訳するということは私にとっては目標かつ夢であり、それが実現できたことは自分にとっての1つのマイルストーンとなります。私がそこにたどり着けたのは、間違いなく多くの方々の助けによるものです。ただ、「自分では何をしたのか?」と考えてみると、継続的に勉強を続けつつ自分の立ち位置を考えていく上で、ブログを書き続けることの意味はとても大きかったように思います。 ブログを書く際には、「その記事を書く意味」をそれなりに意識してきたつもりです。そこで今回は、自分がこれまで意図的に採用してきたスタイルを整理してみます。これまで、このブログには技術ネタだけを極力客観的に粛々と書くようにしてきました。しかし、ブ
"Beautiful Development"(2011.04.09 DevLOVE)の講演資料と原稿 はじめに 本日(4/9)、DevLove様と共同で、第2回"Beautiful Development"を開催致しました。これは、日本語版DDDの発売を記念し、DDDに造詣の深い方々に集まって頂き、2枠構成で講演して頂くという豪華なものでした。このカンファレンスでトリを務めさせて頂きましたので、講演資料と原稿を公開致します*1。なお、今回の発表は「ドメイン駆動設計入門」では駆け足でまとめてしまった部分を、改めてクローズアップした続編と考えて頂くこともできるでしょう。 アジェンダはこちら 戦略的設計とは? サンプル業務 モデル駆動設計をすると? 戦略的設計 スライドはこちら 戦略的設計とは? 「戦略的設計(Strategic Design)」とは、DDD第4部のタイトルです。DDDは全体で
この記事はMario Gleichmann氏による、「Functional Scala」シリーズの第4回「Functional Scala: Closures | brain driven development」を、氏の許可を得て翻訳したものです。(原文公開日:2010年11月15日) 関数型Scalaの第4話にようこそ! 今回はあちこちで議論されているクロージャを詳細に調べ、クロージャに関する誤解を解きたいと思います。単純な関数とクロージャを混同している議論が非常に多いからです。第一に、クロージャはある特別な特徴(これについて話していきます)を備えた関数です。その特徴によって、関数はクロージャになるのです。 一般的な関数の定義と、その特徴については、これまでの3話を通じてすでに深い知識を得ていますので、もう時間を無駄にせずに、関数の他の例を見てみましょう。この関数は、与えられた整数値の
この記事はMario Gleichmann氏による、「Functional Scala」シリーズの第3回「Functional Scala: Functions as Objects as Functions | brain driven development」を、氏の許可を得て翻訳したものです。(原文公開日:2010年11月8日) 関数型Scalaの第3話へようこそ! 今回は、Scalaの内部を軽く見ていき、前回お話しした不可解な関数の型の謎を明らかにしていきたいと思います。つまり、今回は一般的な関数型プログラミングよりは、むしろScalaの専門的な話になります。 関数は、単純に関数リテラルを指定することで定義できるのだということを、思い出して下さい。この関数リテラルは、関数パラメタのリストと関数の本体で構成されています(両者は関数矢印 => によって分けられます)。さらに、特定の関数
技術書の読み方を考えつつ、『ドメイン駆動設計』を位置づける。 はじめに 〜1冊目の本〜 あなたは技術書をどのくらい読んでいるでしょうか?多い人は月何冊も読んでいるでしょうし、もう何年も読んでいないという人もいるでしょう*1。あるいは、「買っているけど読んでいない」ということもあるかもしれませんね。私にも積んでしまっている本があります。 技術書はすでにかなりの数が出版されており、その数は増え続けています。経験を積んだ方であれば、「自分にとって必要な本を見抜く眼」を持っているものですが、これから学ぼうとする方にとっては、読んだ方がよさそうな本の数も値段も絶望的かもしれません。このエントリの目的の1つに、『ドメイン駆動設計』の紹介があることは否定しませんが、それ以上に、「技術書の読み方」について考えてみたいと思います。 仕事としてプログラミングに携わる人であれば、「退職するまでに1冊も読まない人
この記事はMario Gleichmann氏による、「Functional Scala」シリーズの第2回「Functional Scala: Functions | brain driven development」を、氏の許可を得て翻訳したものです。(原文公開日:2010年10月31日) 関数型Scalaの第2話へようこそ!前回は、コアとなる考え方を調査し、式に基づく関数の適用を、関数型プログラミングの基本的な処理方式として抽出しました。今回は、Erik Meijer博士(※1)であれば、関数型プログラミングの必需品(the bread and butter)と呼ぶであろうものから始めましょう。それは・・・なんと・・・関数です(BGMとしてトランペットが鳴り響いていると想像して下さい) 関数を呼び出すためには(これは、関数を引数に適用すると表現されます)、まず、関数を定義しなければなりま
この記事はMario Gleichmann氏のブログエントリ「Functional Scala: Introduction | brain driven development」を、氏の許可を得て翻訳したものです。(原文公開日:2010年10月28日) また、当記事の翻訳許可を求めてメールした際、その返信として氏から暖かいメッセージを頂きました。ここに紹介させて頂きます。Danke schön, Mario!! first of all let me say that all our prayers and thoughts are with you and all japanese people! For all of us here, the tragedy's so unbelievable - we just feel for all of your sorrow and pain
訳者の方々とオライリー・ジャパン様より献本頂きました。厚く御礼申し上げます。ありがとうございます! プログラミングScala 作者: Dean Wampler,Alex Payne,株式会社オージス総研オブジェクトの広場編集部出版社/メーカー: オライリージャパン発売日: 2011/01/20メディア: 大型本購入: 3人 クリック: 320回この商品を含むブログ (38件) を見る はじめに Dean Wampler and Alex Payne著『Programming Scala』の、「株式会社オージス総研 オブジェクトの広場編集部」様による翻訳です。訳質に関してはさすがと言いましょうか、まったくストレスを感じません。内容も初頭文法の説明からアクター、DSLなどの応用編まで多岐にわたっていて、じゅんいち☆かとうさん*1や、ゆろよろさん*2もおっしゃっている通り、間違いなく良書でしょう
「共通基盤チーム」と呼ばれるチームの役割に関する私見と、その共通基盤チームの方のための文献紹介。 共通基盤チーム 共通基盤、他には「インフラ」や「フレームワーク」「アーキ」など文化によって色々な呼び方をされていると思いますが、要するにアプリケーションのアーキテクチャ策定から業務横断的な共通機能の提供を行うことで、各アプリケーション開発者の方々を支援するチームのことを指しています。すっかり一般化した「ITアーキテクト」という言葉で指される人たちが集ったチームと考えていただければ良いでしょう。開発者が10人位までのプロジェクトであれば、特にチームとして作られることはないと思われますが、40から50人規模のプロジェクトでは大概明確に設定されていると思います。 共通基盤チームの役割を要約するならば、「業務開発者の責任範囲を限定すること」になるのではないかと考えています。つまり、各業務開発者は担当す
次のページ
このページを最初にブックマークしてみませんか?
『Digital Romanticism』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く