組織（チーム）を成長させるための参考書籍

概要

マネジメントやプロセスの方法論自体をどのように適用、変化させるのか。 というのは、方法論自体を知る必要があるのはもちろんのこと、どんな組織にしたくて、どうすれば成立できるのかということを考える必要があります。 それらを引っ張るものが、理想や価値観であり、それらを明確につくる能力も大切です。

というのをあるTweetの具体例から入って話しているうちに、参考書籍を紹介しておこうという流れになりました。 ので、ある程度抽象的なやり方っていうんですかね。組織に変化をもたらす方法っていう感じですかね。

Twitterの流れ

togetter.com

参考書籍

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(下)

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

「タレント」の時代 世界で勝ち続ける企業の人材戦略論 (講談社現代新書)

トヨタの強さの秘密 日本人の知らない日本最大のグローバル企業 (講談社現代新書)

エクストリームプログラミング

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

IMPACT MAPPING インパクトのあるソフトウェアを作る

アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

HARD THINGS

ワーク・ルールズ！―君の生き方とリーダーシップを変える

蛇足 : 方法の反対は目的ではない

最近勉強していて当たり前？のことを知ったのですが、方法の反対を意味する語は目的ではないという。 目的のために方法があるだけであって、反対という意味ではないというか。 ロランバルトという思想家？の著書をいくつか読んでいるのですが、彼の考え方は非常に刺激的ですので、興味がある方は読んでみてはどうでしょうか。 （ちなみにこのような解釈における方法の反対は教養になります。方法は目的を価値とするけど、教養は縛られるものがないという意味）

というのをこういった方法論とか組織論とか価値とかビジョンを勉強して、自分で考えているときにそういったことを考えていないとまさしく無縄自縛っていう感じになってしまってよくないなぁと。 っていうのを考えるためには哲学とか言語の勉強が役に立っています！

Hacker Tackleでアジャイルテストにおけるアンチパターンについて講演しました。 #hackt

3行まとめ

• Hacker Tackleっていう激熱なITデベロッパー向けのイベントで「アジャイルテスト」について講演しました。
• みなさんがつらいのはわかるけど、解決したいなら本気で取り組む必要があるので、参考になれば幸いです。
• あと、アジャイルにテストしている人達といろいろ議論したいです。

Hacker Tackleとはなにか

hackertackle.github.io

HackerTackleは、プログラマのための総合技術イベントです。 「ハッカー・タックル/博多・来る」の意味を持つイベント名には、多くのハッカーが博多に来て、さまざまな議論をぶつけあう場になればという思いがこめられています。 イマのプログラマにとって必要な知識を切り取った、さまざまな技術に関するセッションを用意しています。 ぜひ博多に来て、新しい技術を吸収し、議論をぶつけあってみませんか？

なんかMMA感がありますが、まさしく登壇者の多様性と豪華さはすごかったです。 主催者と登壇者のみなさまほんとうにありがとうございました。 僕はホクホクして帰りました。

名前の由来はハッカータックル、ハカタクル、博多来る というかんじです。 今年で2回目ということでして、昨年に引き続き参加させてもらいました。

どんな講演をしたのか

speakerdeck.com

50分間の講演だったので、30分はスライドの内容をかいつまんではなし、20分は会場と意見交換をしました。

スライドでは次の3つのアンチパターンを紹介しました。

1. 過剰自動化
2. モック酔い
3. TDD不要論

で、時間の都合上2番目のモック酔いは軽くだけふれて、1と3を中心的に話しました。 これら3つはまぁ私のまわりではよくあったので、その状況における原因とか自分なりの対策をまとめました。

ちなみに1の話ではかの「自動化ハイ」についても口頭で言及しました。 @関西のテスト自動化コミュニティ

また、アンチパターンだけはなしても「こいつうさんくさい」とおもわれるかなぁとおもったので、 一部ではありますが、自分達のチームがどのようにテストにとりくんでいるかも紹介しました。

いまは少しずつですが、手動テストもテスティングフレームワークで書くような下地をつくりはじめているところ。ってかんじですかね。

会場との意見交換では、いろんな質問がでておもしろかったです。 きょんくんの現場ではこういったことは困っていないのか？といったものから、参加者さまの現場で困っていることについての方針相談などなど。

まとめ

アジャイルって「素早く順応する」ってことが大切だとおもうので、みなさんも自身含めてどんどん変化していくとよいのでは！！！とおもっています。

改めてになりますが、Hacker Tackleの運営のみなさまによって素晴しい会になったとおもいます。本当にありがとうございました。 また、来年も参加させてもらえると非常にうれしいです。

Specification by Example: How Successful Teams Deliver the Right Software

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

「アジャイルコーチの道具箱 - #見える化実例集 -」を読みました。 by mari

kyon_mmさんの友人のmariです。今回はkyon_mmさんのブログを借りて、「アジャイルコーチの道具箱 -見える化実例集-」の書評を書かせていただきました。

本書はすごく楽しんで読めた一冊でした。著者、翻訳者のみなさまありがとうございます！

leanpub.com

付箋愛

まず感じたのは、「溢れんばかりの付箋愛！」です。 私も会社でガンガン使っています。 すぐかけて、貼りたいところに貼れて、 誰かに渡すことも簡単で、すぐ共有できる！

付箋がもたらす情報共有力、見える化力ってすごいですよね。 私も好きです、付箋。

肝心の本書の内容について。

基本的に説明が書いていないので、好き嫌いは分かれる本なのかもしれないなぁと思います。 どういう理由でそれをやるのか、を誰かに教えてほしい人には読みづらく感じそうです。 説明がないと物足りない！って人は、別の本を読んだ方がいいと思います。 私はどちらかというと感覚でものをとらえるタイプなので、 非常に好きなタイプの本でした。

Exampleが基本1頁に1つの構成になっていて非常に読みやすいです。 読むというより、観るって感じが近いかもしれません。 長い文章が一切なく、半分以上が図となっており、感覚的に脳に入ってきます。 本書で取り扱うExampleの中にも、図や表を利用するExampleが多く出てきますが、 それらの効果を本書をもって証明しているように思います。 すぐにできそうなシンプルなExampleばかりで、すぐにでもTryできそうです。

見えるようになるとそもそも何が嬉しいのか。

1. 気づかなかったことに気づくようになり、今まで考えなかったことを考えるようになる。
2. コミュニケーションが増える。
3. 知らなかったことを知ることができる。
4. 成長できる。
5. 楽しいと思える機会が増える(ここは人によりそうですね。)

楽しんでチームと仕事をする、という部分に特化しすぎているように思える部分もありますが、 「楽しむ→やる気がでる→効率よく仕事ができる」 とつながっていくので、仕事をするうえで楽しむって必要なことなんじゃないかな、と自分は思います。 「仕事に楽しさは求めていない」という人もいますが、 私は楽しむことで、自分の人生が金銭的にもメンタル的にも豊かになると信じています。 本書には、楽しんで仕事をする、チームうまくやる、ための工夫がたくさん詰まっています。

下記に、特に自分の心に響いた部分をいくつか引用し、レビューの締めとします。

シンプルに。

更新されなくなると信用されなくなり、どんどん使われなくなっていく。

どんな情報もツールも同じだし、よくあることだと思います。 メンテナンスされない膨大な利用ガイドや、設計書を含め、 身に覚えがある人も多いのではないでしょうか。 始めは凝ったつくりにするものの、結果として自己満足になっていて、 他の人からすると、情報や装飾が多すぎて使いつらいとか、読みづらいとか、 そういう使えないものになり、更新されなくなっていく。 作った人は、せっかく作ったのに、とイライラし、結果としてチームの雰囲気が悪くなる。

私は身に覚えがありすぎて、「本当それ！」と叫びそうになりました。 言うのは簡単ですが、実行するのは難しい。 「シンプルに」考える、「シンプルな」ものをつくる、 このあたりの考え方は、人生をより楽しく生きるためにも必要な要素だと思います。

自信のニコニコマーク！

これならひとりひとりの感覚が可視化できるし、 毎日、進捗や達成可能か？と考えることができます。 そして達成できるためにできることはないだろうか、と考えるきっかけとなると思います。 なんとなくバーンダウンを見て、「はい、見た！終わり。」ってなっているチームや、 そもそもバーンダウンなんて見てません！ってチームに取り入れると意識が変わりそうですね。

情けない話、自分のチームではそういうことがありました。 こういう工夫をしていたら、もっとよいチームになれたような気がします。

評価しよう。改善、調整をしよう。必要ないなら、使うのをやめよう。

やめ際がわからなくて、ずるずると必要のないことをやってしまったり、 引き際がわからなくて、余計なことを言ってしまったり… たくさん思い当たるふしがあります。 ずっとやってるからといって、必要かどうかを考えずにやり続けている レガシー的な何かとか。 常に物事は変わっていくのだから、常に評価して 必要がないのであればやめるというのはよく考えたら当然のことですね。 全然できていないけど、それは頭を使っていないってことなんだなぁと思いました。

テスト(コード)レビューの方針 書きなぐり版

牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。

元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs

僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日

牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」

僕のコメント「書いていません！」

僕のコメント「書きました！」

パターンに関する質問と、パターンとはアートなのかデザインなのか考えてみた

最近、 TwitterとかFacebook で @ryuzee さんとか @katzchang さんが「スクラムにおけるImpediments Listはどう扱うのか」みたいなやりとりがありました。 そのやりとりの途中で @jcoplien さんが日本で開催した組織パターンに関する講演の話がでてきました。それは @m_seki さんのブログにレポートがあって先ほど読みました。http://d.hatena.ne.jp/m_seki/20131110#1384094601

で、これらを読んで思ったことを書きながら、TODOってなっていることを @ryuzee さん、 @katzchang さん、 @m_seki さん、 @kawaguti さん、 @jcoplien さん、 @haradakiro さん @digitalsoul0124 さんあたりに質問してみたいなぁと思っています。

ちなみに話題にあがっていた Impediments Listは僕は扱いやすいように管理しておけばListでもバックログでもKPTでもなんでもOKで、いつ解決しないとやばい問題であるかが最初に考えることですかね。出てきた問題によって置き場が変わります。

パターン

パターンが何であるかのより具体的な説明として @jcoplien さんが説明した様子を @m_seki さんは次のように書いてくれていて、「パターンは複数の問題に対して使える」という理解は僕もなんとなくしています。

研修のテキストに「1つのパターンが、いちどに解決する問題は一つだけ」という誤訳があり「一度に一つずつ適用する」が正しかったのですが、これを起点に「一つのパターンが複数の問題を解決するよ、それは…」といった具合にコプリエンが暴走してくれました。

彼の話を全部受け止められた自信はないのですが、がんばって説明します。

まずたくさんのいろいろな向きのフォースが存在する空間があるモデルを考えます。

# ホワイトボード全体にいろんな向きの矢印（フォース）を描いてくれました。だれかホワイトボードの写真残ってない？

つぎにいくつかの矢印を「対象の問題」として選び囲み「それらを解決する、調和させるのがパターンだ！一度に複数の問題が解決されるんだよ！」っぽいことを話してました。

うぉー。なにを問題と思うかも自分たちに任されてる！パターンはきれいに並んでるわけじゃなく重なり合ってる！この説明はいいなあ … あ、あれ？

今思うと変だな。あのときは腑に落ちたんだけど…。これってパターンじゃなくてコンテキストとフォース、解決策ですよね。それのカタログがパターンなんだろうか…。

問題すら自分たちで選べるっていうのは自分たちのチームの雰囲気と合ってていいなあと思いました。でもカタログの方はあんまりぐっとこないんですよね…

@m_seki さんの気持ちと一緒かどうかはわからないけれど、パターンのカタログがわくわくしないみたいなのは僕も組織パターンというか、PLoPのなにかを読んでいても同じ気持ちになります。（ちなみに僕はパターン言語好きです） 僕がよく説明するのは「パターンとパターン言語の関係は、業界と業界用語の会話のような関係で、業界用語リストを見てもわくわくしないけど、どの用語を組み合わせるのか、新しい用語を発見するときはちょっと楽しい」みたいな感じです。パターンとイディオムは区別すべきなのですけど、ここでは関係を表現する比喩として使いました。 TODO この認識であっているか聞いてみる

文中にある1度に1つのパターンを適用しなさいは組織パターンというパターン言語（6.2 漸進的成長を主眼にして話した内容）だったからだと思う。どっちにしても1つのパターンが複数の問題の解決に役立つというか、どの問題に使うかは自由で、それは自分がどんな文章組み立てるかは自由なのと似ていると思う。 カタログとしてのパターンやパターン言語は僕の中では、辞書とか文例集とかが近いです。でも、組織パターンやいくつかのパターンに関する名著からも伺えるようにそれはなんらかのストーリーであるべきだし、うまく書かれているものは読んでいて感情移入できるくらいに読めるものもありました。例えば、僕は Fearless Change というパターンの書籍ではいくつかのパターンは読んでいて興奮しました。

でも、どんなに瑞々しい文章でも、自分たちが体験してことばにならないものを触り続けている瞬間の感覚とはかけ離れてしまうなぁと思います。恋愛小説を読んでいる時と自分の恋愛の違いみたいに感じます。恋愛しなくなったり、まともな恋愛をできていないと、恋愛小説を読んで羨ましくなることはあると思います。パターンと毎日楽しく触れ合っている人には、カタログになったパターンはきっとつまらなくうつってしまうときがあるし、そうではないときもある。くらいの印象です。

日本語でも「つまらない」と表現することはいろんな事象に当てはめられるし、「旅行で休む」という行為においてもいろんな問題（仕事で忙しい、家事が大変、日本のキッチリさが鬱陶しい）を解決することもできます。 でも、その1フレーズだけでその人の状況が表現できないので、パターンというのは言語の1部であり、全体性が重要であり、パターンを見出すというのはある種の言い回しと状況を具体的にするという行為なのかなぁと思いました。 TODO もう少し具体的にしたいけどよくわからないので、聞いてみる

パターンはデザインかアートか

最近「芸術とは何か」みたいなのを勉強しているので、パターンはデザインなのかアートなのか考えてみました。（芸術という言葉が面倒（歴史的経緯が面倒）なので、とりあえずアートという言葉で言います。

パターンをみつけたり組み合わせたり、明確にしていくという過程は「デザイン」なのか「アート」なのか。 現代的？に捉えると、アートであるならば問い、未来、可能性の性質が強くなりますし、デザインならば答え、過去の性質が強くなると思います。（僕はデザインとアートの違いをそう捉えている） そうではなく、本来的な意味を考えると、アートは問いと答えを連続させていく行為であり、その蓄積物のスナップショットが文化であるがゆえに、文化とは迷いの象徴であるというようにも捉えることができます。

パターン、パターン言語に触れているその瞬間は「問いと答えを連続させていく行為」としてのアートに近い存在、もしくは「アートとデザインの両方を持っている」と思います。 また、先にあげた業界用語のように比喩に上げたものでさえも同じように言えると思います。日本人が時折バラエティなどで「あぁ、この漢字、熟語の成り立ちはこうだったのか」と感心するのはまさにそういった例なのではないかと思うのです。

デザインの性質が近いパターンとはおそらく本来的な意味のパターンを表現していないのだと僕は思います。 問いや意思や可能性を広く深くしようとするという思いが感じられるから、複数の問題を解決するために使えるパターンになるのではないでしょうか。 TODO 全体的におかしいところがないか聞いてみる

次回

「UXを重視したいという風潮が、建築、都市計画、ITの業界で起きているのは、アートとデザインが再び統合されようとしているのではないか。もしくは似非アーティスト、似非デザイナーをあぶりだす時代の到来か」みたいな話を書きたいと思っています。（予定は未定

組織パターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

2015年に読んだうさみみエンジニアがよかったと思う書籍

2015年は会社の業務外でまるでアウトプットができませんでした。特に下半期はやばかったです。 自分なりにいろいろ大変な時期だったので、学んだことはたくさんありました。学んだことの量で言えば多分仕事し始めてから一番学んだ1年だった気がします。

で、振り返りを書くのは大変だし、むしろそういうのは、 Scrum Gathering Tokyo 2016 で話すので、自分の記録として恒例の「2015年に読んだうさみみエンジニアがよかったと思う書籍」をまとめておきます。

組織

HARD THINGS

ワーク・ルールズ！―君の生き方とリーダーシップを変える

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術 (早川書房)

エクストリームプログラミング

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

組織パターン (Object Oriented SELECTION)

エッセンシャル スクラム

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

リーン開発の本質

テスト

絵で見てわかるシステムパフォーマンスの仕組み

Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design

Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing

プログラミング

Groovy in Action

コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方

C#実践開発手法 (マイクロソフト公式解説書)

．ＮＥＴのエンタープライズアプリケーションアーキテクチャ　第２版 (マイクロソフト公式解説書)

Lean Architecture: for Agile Software Development

C#プログラマのための.NETアプリケーション最適化技法 (Programmer's SELECTION)

要求

ソフトウェア要求 第3版

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

誰のためのデザイン？　増補・改訂版　―認知科学者のデザイン原論

ユーザーストーリーマッピング

ゴール&ストラテジ入門: 残念なシステムの無くし方

IMPACT MAPPING インパクトのあるソフトウェアを作る

価値論

哲学概論 第1部 (岩波文庫 青 654-2)

哲学概論 第2部 (岩波文庫 青 654-3)

新カント学派の価値哲学―体系と生のはざま

行動経済学

予想どおりに不合理: 行動経済学が明かす「あなたがそれを選ぶわけ」 (ハヤカワ・ノンフィクション文庫)

お金と感情と意思決定の白熱教室: 楽しい行動経済学

ファスト&スロー(上) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

ファスト&スロー(下) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

文章

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 推敲編 (ちくま学芸文庫)

数学

初等整数論 ―数論幾何への誘い― (共立講座 数学探検 6)

超高速グラフ列挙アルゴリズム?〈フカシギの数え方〉が拓く，組合せ問題への新アプローチ?

経済学

コーポレート・ファイナンス 第10版 上

コーポレート・ファイナンス 第10版 下

看護学

看護覚え書―看護であること看護でないこと

看護の基本となるもの

今年はあんまりテストの書籍を読んでいないなーと思ったのですが、テストはもっぱら論文ばっかりだったのと、チェッキングよりもテスティングに力をいれていたという事情があってあんまり書籍には結びつかなかった感じですかね。。。

いつもよりはいろんな分野の書籍を読むことになったので、来年もこの調子でもっといろんな分野の知識を統合できるといいなぁと思っています。

来年の個人的な目標は「価値基礎勉強会」をやることですね。

要求を明確にしたり、整理したり、共有するときに参考にしている書籍リスト

背景

次のようなリプライが飛んできたので、後輩も絡んでいることだし kyon_mmが普段仕事で要求を明確にしたり、整理したり、共有するときに参考にしている書籍リスト を公開してみる。

これらの書籍の情報から得られるPOとしての振る舞いを僕は常日頃、自他共に求めている。読んだことがなくても体験で得られるものもあるとは思っている。僕はその体験を待つだけの忍耐がないのと、自分に恥を感じるのと、知的好奇心からこれらを読んだ。ちなみに全部合わせて2年くらいで読んだと思う。

@kyon_mm 教えてきょんせんせー！ RT @zakky_dev @c0hama どの書籍がいいか、さらに知りたいのであればきょんさんに聞いてもらうのが良いかと思います！

— こはま (@c0hama) November 19, 2015

ビジネスモデル系

ビジネスモデル・ジェネレーション ビジネスモデル設計書

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

ビジネスモデルYOU

キャズム

ＨＡＲＤ　ＴＨＩＮＧＳ

ゴール指向

IMPACT MAPPING インパクトのあるソフトウェアを作る

ゴール&ストラテジ入門: 残念なシステムの無くし方

ソフトウェア開発全体系

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

アジャイルソフトウェア要求 (Object Oriented SELECTION)

ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド

ソフトウェアシステムアーキテクチャ構築の原理 第2版 ITアーキテクトの決断を支えるアーキテクチャ思考法

システムアーキテクチャ構築の実践手法 (IT Architects’ Archive)

Lean系

リーン開発の本質

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

リーン・スタートアップ

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES)

ユーザーストーリーマッピング

アントレプレナーの教科書

要求仕様系

ソフトウェア要求 第3版

要求工学知識体系 第1版

ユースケース駆動開発実践ガイド (OOP Foundations)

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

ユーザエクスペリエンスのためのストーリーテリング -よりよいデザインを生み出すストーリーの作り方と伝え方 -

モデル系

UMLモデリングの本質 第2版

形式手法入門―ロジックによるソフトウェア設計―

抽象によるソフトウェア設計−Alloyではじめる形式手法−

VDM++によるオブジェクト指向システムの高品質設計と検証 (IT architects’ archive)

見積もり系

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ソフトウェア見積り

ソフトウェア見積りのすべて 第2版 ―現実に即した規模・品質・工数・工期の予測―

IA/UX系

誰のためのデザイン？　増補・改訂版　―認知科学者のデザイン原論

インタフェースデザインの実践教室 ―優れたユーザビリティを実現するアイデアとテクニック

IAシンキング Web制作者・担当者のためのIA思考術

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

IA100　ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計

一人から始めるユーザーエクスペリエンス

ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン (情報デザインシリーズ)

モバイルデザインパターン 第2版 ―ユーザーインタフェースのためのパターン集

リスク系

熊とワルツを - リスクを愉しむプロジェクト管理

ピープルウエア　第3版

ソフトウェアテスト293の鉄則

人月の神話【新装版】

チームの文化系

Clean Coder プロフェッショナルプログラマへの道

Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

組織パターン (Object Oriented SELECTION)

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン