radioc@?

レディオキャットハテナ

【読書メモ】スタンフォード式 最高のリーダーシップ

スタンフォード式 最高のリーダーシップ

スタンフォード式 最高のリーダーシップ

少し前に会社のマネジメント層で話題になっていて、これは読んで勉強しておかねばと思い読みました。基本的にはリーダーシップ理論にモチベーション理論やコーチング理論、行動心理学、EQなどの要素を取り入れて整理した内容になっています。アサーティブというキーワードと4つのスキルにまとめて、心理学の視点で丁寧に解説されているので、わかりやすく読みやすい書籍です。
著者はリーダーシップとは誰もが内面に持っているスキルであるとしており(詳細は後述)、マネジャーやリーダーだけでなく自己成長と組織の成果を求める多くの人におすすめできる書籍です。

リーダーシップは生き方であり、働き方

本書のタイトルである「スタンフォード式 最高のリーダーシップ」について、次のように述べています。

リーダーシップを身につけることで自分を成長させる。実際のリーダーとして、チームや組織で成果を出せるようになる。

リーダーシップの重要な成果の1つ目は組織を強くするということです。

リーダーは人を動かさねばならず、人はシステムやロジックではなく、心で動く
(中略)リーダーシップを備えた人がお互いに影響を与え合う職場は、組織として強くなる。

そしてもう1つは、個人の成長です。

決められた「一つのルール」に従えばよかった時代は、過去のものだ。これからは、自分の能力を最大限に活用し、最高のパフォーマンスを引き出す方法を、一人ひとりが模索する時代がやってくる。そう考えると、リーダーシップとは生き方であり、働き方だ。

個人が成長し、組織の成果を導き出すのがリーダーシップであり、誰もがその能力を持っているので、「生き方であり、働き方」であるとし、「 We are the Leaders 」と述べています。

アサーティブ・リーダー

冒頭で述べているとおり人は心で動くため、人の心を理解しなければ人を動かすことができず、リーダーシップは発揮できません。そのため、誰もが内面に持つとしているリーダーシップを理想的な方向に引き出していくことが重要です。その目指すべき理想のリーダー像が「アサーティブ・リーダー」です。アサーティブとは直訳すれば「主張型」「積極的」となります。筆者によるとアグレッシブとパッシブの中間的な考え方・行動力を持つのがアサーティブ・リーダーです。

自分自身を尊重し、人を否定することなく、自分とチームの利益のために行動できるリーダー

アサーティブ・リーダーの強みや特徴を次のように述べています。

  • 自信・自尊感情があり、「息の長いリーダーシップ」が発揮できる
  • 聞く耳を持ち、「信頼」される
  • 自分の意見やアイデアを、しっかりと「主張」できる
  • 「誠実」である
  • 人を「責めない」
  • 「責任感」がある
  • 「チームに必要とされている」と感じられる
  • 「難しいメンバー」ともうまくやっていける
  • 「何を期待されているか」を理解し、実行できる

そして、アサーティブ・リーダーに必要な4つのリーダーシップ・スキルが次の4つです。

  1. Authentic Leadership(本質的なリーダーシップ)
  2. Servant Leadership(支援するリーダーシップ)
  3. Transformative Leadership(変容をもたらすリーダーシップ)
  4. Cross-Border Leadership(壁を超えるリーダーシップ)

本書ではアサーティブについての解説のあと、この4つのスキルについて順番に説明されています。

オーセンティック・リーダーシップ

自分自身をよく知り、信念にもとづいて人のためにつくすことができる思考と行動がオーセンティック・リーダーシップです 著者によると、心理学の知見に基づいたオーセンティック・リーダーシップを磨く「5つの方法」があります。

  1. 弱さ(vulnerability、ヴァルナビリティ)を認める
  2. 「役割性格」を超える
  3. 「人」と比べない
  4. 自分の「生涯の大きな目的」を見つける
  5. 「超・集中状態」になる

自分を過信せず弱みを理解し、リーダーでありながらビギナーの心を忘れないこと。他者に共感し、自分の信念に従い取るべき行動をとります。「超・集中状態」ではマインドフルネスを取り上げています。マインドフルネスに関しては前著も広く読まれている書籍です。

スタンフォード大学 マインドフルネス教室

スタンフォード大学 マインドフルネス教室

サーヴァント・リーダーシップ

部下の能力を引き出して支援するのがサーヴァント・リーダーシップです。そのために必要なのが次の4つの行動です。

  • 人間関係づくりから
  • Ask, don't tell(語るのではなく、質問せよ)
  • 任せる(失敗していもいい仕事に速いうちにチャレンジさせる)
  • Fail early, fail often(速く失敗して失敗から学ぶ)

トランスフォーメイティブ・リーダーシップ

心理学でいうtransformとは、本質から変わる「変容」であると同時に、自分が本来持っている可能性を引き出し、活用して開花させる

単に変容させるのではなく、その人の長所や特性を理解し可能性引き出すのがトランスフォームです。そのためには上司ではなく「メンター」として次の行動が重要だと著者は述べています。

  1. individualized(「個人」に働きかける)
  2. intellectual(「知的」に刺激する)
  3. Inspirational(「心」を引きつける)
  4. idealized(「理想のモデル」となる)

コーチングなどのスキルが求められるのがこのリーダーシップだと思います。

クロスボーダー・リーダーシップ

著者は、IQ,EQの次にこれから注目される能力が「CQ(Cultural Intelligence Quotient)」= 文化の知能指数 であるとしています。まずは自分を縛る「壁」を理解することが重要です。

  1. 文化・習慣
  2. 行動様式
  3. 前例

そして、チームを断絶する「壁」にも目を向けます。

  1. パワー
  2. 男女
  3. 世代・年齢
  4. ステレオタイプ

壁の存在を理解し、マネジメントするのがクロスボーダー・リーダーシップです。

参考

以下のサイトに著者が書いた3つの記事があります。これらを読むことで4つのスキルを持つアサーティブなリーダーのイメージがより具体的になると思うので合わせて読むと良いでしょう。

toyokeizai.net

【読書メモ】ソフトウェア・ファースト

巷で話題ということで、またしても読書キューを順番抜かしして読みました。 タイトルがキャッチーで、ソフトウェア開発に関わる人からすると技術面に関する期待の高まるテーマのように感じられますが、タイトルや著者の経歴のイメージで、明日から使えるエンジニアリングの手法やマインドに関する本だと期待して読むと少し戸惑うかもしれません。メイン・ターゲットとしているのはIT以外の企業でITに関わったり取り入れようとしている経営者やマネジメント層だと思います。もちろんそれ以外の、会社や組織をソフトウェア・ファーストにしたいと強く思っている人は読むべき本です。

ソフトウェア・ファースト

タイトルに込められたテーマについて著者は次のように説明しています。

(前略)これまでに説明したプロダクト開発の手法は、ソフトウェアの価値を理解した上でプロダクト/事業開発を前に進めていくための一部にしか過ぎません。また、これらも日々変化しています。必要なのは、手法の理解ではなく、思想や姿勢です。これが本書のタイトルにもなっているソフトウェア・ファーストです。

具体的なソフトウェア開発の手法よりも、背後に押さえておくべき思想や姿勢を理解し、その価値観をベースにキャリアパスの構築、組織運営、企業経営をしていく。その取り組み方がこの本のテーマです。

ソフトウェア・ファーストで最も大事なことは、変化しないものを理解することです。ソフトウェア技術は日々進化します。ソフトウェアを活用したビジネスモデルも変化し続けます。変わらないものーーそれはビジョンやミッションであり、それに関連する社会課題や価値観です。目指す世界観に対して、ソフトウェアという変化し続ける手段を用いる人間に必要なのは、成し遂げようとする執念であり、成し遂げるために考えること、考え続けることです。

これを理解して読めば経営者やマネジメント層だけでなく、現場のリーダー、エンジニアにとっても明日から引退するまで使えるソフトウェア・ファーストの価値観を理解し、実践することができると思います。

ソフトウェア・ファーストなキャリアを築くには

エンジニア的には5章に書かれているこのテーマが最も参考になります。これは、著者自身が別の場でも語られている内容です。

www.slideshare.net

計画的偶発性理論

ソフトウェア・ファーストのキャリアを構築するための個人の重要な特性として、スタンフォード大学のジョン・D・クランボルツ教授による理論が紹介されています。

慎重に立てた計画以上に予想外の出来事や偶然の出来事がキャリアに影響を与える

とし、次のような行動特性が重視されます。

  • 好奇心
  • 持続性
  • 柔軟性
  • 楽観性
  • 冒険心

ja.wikipedia.org

クイズ

冒頭に10の質問が出てきます。これらの質問に対してソフトウェア・ファーストの価値観から答えるとどうなるか、本書を一通り読むことで答え合わせできます。

Q. あなたの会社を変えるため、取り組むべきことは次のうちどれでしょう?

1. とりあえずソフトウェアエンジニアを採用する
2. ソフトエンジニア採用のために破格の条件を提示する
3. ソフトウェアエンジニアのやりたいように開発させる
4. 新規事業のアイデアが出たらすぐにエンジニアが開発をスタートする
5. デザイン思考やリーン・スタートアップという方法論を取り入れる
6. アジャイル開発を実践する
7. 未知の技術を使って障害を起こしたくないので、枯れた技術をあえて用いる
8. 将来の拡張性や保守性を考え、マイクロサービスアーキテクチャを採用する
9. リファクタリングが必要とエンジニアに言われたので、3ヶ月間リファクタリングのための期間を設ける
10. できるだけ人間のオペレーションを排除する

参考

note.mu

公式のブログページがnoteにあります。

fukabori.fm

著者自身が fukabori.fm にゲスト出演して本書の概要を一通り語られています。

【読書メモ】40歳からの本を書く技術

ビジネスマンのための40歳からの本を書く技術

ビジネスマンのための40歳からの本を書く技術

アウトプットの精度を高めたいという動機で本を書くレベルの技術とは何か興味を持って読みました。特に本を書こうと思っているわけではなく書籍の出版に関する部分は軽く読んだ程度なのでここでは触れません。

インプットの重要性

本を書くというアウトプットがテーマですが、テーマの選び方や着眼点、情報収集のしかたなど、半分ほどはインプット系のことが書いてあります。アウトプットするためには、まずはしっかりインプットしましょうということです。他のアウトプット系の書籍でもまずインプットについて書いてあることが多いので、当然のことと言えるかもしれません。

読んで情報収集するための4つの留意点

  1. 問題意識を明確にする
  2. 情報の「メタ化」を行う
  3. 定量のインプットによって蓄積する
  4. 速読は必要ない

興味を持ったことを何でもかんでもインプットしてもアウトプットの精度は上がらないので、どういう問題意識でインプットするかを明確にし、読者に付加価値を与えられるようにインプットに磨きをかけていきます(メタ化)。

定量のインプットについては「プラトー」が紹介されています。学習を続けていくと一定の段階で成長が止まり成果が出なくなる期間があります。そこで頭打ちというわけではなく、さらに学習を続けることで再び成果が現れるようになります。これを「プラトー=学習高原」と呼ぶそうです。プラトーを超えた段階の知識こそが価値が高く、読者に付加価値を与えられるインプットになりうるということだと思います。

diamond.jp

速読については否定しているわけではなく、無理にやる必要はないということです。

そこで受けた刺激について自分自身で考えるということが最も大切です

速く読むにしろ、ゆっくり読むにしろ自分の中で理解を深めることができれば良いということです。

ショーペンハウアーの「読書について」の中でも次のように述べています。

本を読んでも、自分の血となり肉となることができるのは、反芻し、じっくり考えたことだけだ

分かりやすい文章を書く

アウトプットの質にとって一番はやはり文章のわかりやすさであると思いました。本を書くということで、まずメールなどの特定の相手に向けて書く文章との違いを意識することが重要だと述べられています。

あなたとあなたが文章を書こうとする相手との間に、その文章の話題やテーマについての情報共有の程度に差がある

そもそも不特定多数を相手に文章を書くので、読み手によっては知識のレベルに大きな差があります。そのため、注意すべきことは「わかりやすい文章」を書くことに尽きると述べられています。

分かりやすい文章を書く4つの秘訣

  1. 文の長さをできるだけ短くする
  2. 曖昧さをなくす
  3. 接続詞を大切にする
  4. 数量化する

著者の目安では文の長さは40〜100字の範囲内だと述べられています。

一文が長くなればなるほど、その文の中に入ってくる主要な内容と、それを修飾する文が増えてくるため、加速度的に文意が不明確になっていきます。

長くなればその文が主とする内容が曖昧になってしまうということです。ただ、短文ばかりではなくある程度の長さの文章も織り交ぜてリズム感を出すほうが読みやすく、読者を楽しませる手法として勧められています。

40〜100字の範囲内で、短い文章と長い文章を「ほどよく混ぜる」

曖昧さについては形容詞と副詞、読点の使い方にスポットが当てられています。「ここではきものを脱いでください」のような様々なところで引用される古典的な例もあるので説明不要だと思います。

blogs.itmedia.co.jp

本書では次のように2段階で文章を整えていくことが勧められています。

  1. 修飾語と被修飾語を近づけるという作業を先に行って文章を作った上で、
  2. 適切な場所に読点を入れる

接続詞については「文章における方向指示器であり、接着剤の役割を果たしています」としつつも、使いすぎると稚拙な表現になりリズム感を損なう懸念から、最初は文章の論理性を重視して接続詞を除外せずに入れていき、書籍化されるまでの校正の中で削っていくのが著者のやり方のようです。

数量化については前出の形容詞と副詞の使い方の発展型と言えるかもしれません。修飾語を使うのではなく具体的な数字で表現することで曖昧さを省きます。

「非常に」とか「高い」などというった副詞や形容詞ではなく、その代わりに、客観的な具体的数字を使うことによって、文章の曖昧さを除くことができます

つまり、読み手によってイメージが変わるような曖昧な表現を徹底的に排除していくことが、著者の考える書籍化レベルの分かりやすい文章を書くためのアプローチであると言えます。

文章力を養う4つの心がけ

上記のようなアプローチによって分かりやすい文章を書けるようなスキルを得るために心がけることとして次の4つをあげています。

  1. 多読する
  2. ひいき筋の著者をもっておく
  3. よいと思う文章をまねて書く
  4. とにかく書く

結局のところ、インプットとアウトプットを繰り返し地道に回数をこなしていくということであると言えます。

【勉強会メモ】6社の開発現場ツール大公開Night

sansan.connpass.com

関西に拠点を置く6社による合同勉強会です。諸事情あって最近はなかなか勉強会に参加する時間が作れていませんでしたが、今週はこれのために週明けから調整してなんとか参加してきました。少し遅刻しましたが…

ツールというテーマのもと、開発現場の苦労や工夫が垣間見えて参考になる内容でした。弊社も7社目以降に加われるように頑張らねばと思いました。

ウェブアクセラレータ(さくらのCDNサービス)のアクセスデータ収集の裏側

@nozomi_1773 さん / さくらインターネット株式会社

speakerdeck.com

ウェブアクセラレータ(CDNサービス)

  • CDNが活躍:突発的なアクセス像が予想されるとき

コントロールパネル

  • リアルタイム更新

アクセスデータをどのように集めているか

  • キャッシュサーバのログをログサーバに収集
  • APIサーバからログサーバを参照

OSS

独自デーモン

  • logcollectd

ログ収集側

プロキシ(nginx) ↓多段キャッシュ 独自デーモン(logcollectd) graphite形式への連携形式にパース TCPで送信 ↓ go-carbonで処理

参照側

APIサーバ carbonapiにリクエスト carbonzipperへリクエスト(proxy) whisperファイルの読み出し

今後変更を検討中

タスク管理ツールをGitHub ProjectからAsanaに移行した話

hokkai7go さん / 株式会社はてな

SREチーム

  • 大きなチーム
  • インフラ構築、SREいないチームの運用など

SREチームの使っているツール

Asana移行の動機

  • 依存関係が多分にある一連の大きなタスクをうまいこと可視化して計画の確実性を高めたい
  • いくつか運用上の問題がでてきた

運用上の問題

  • taskの依存関係が見えにくい
  • 細分化したtaskの進捗状況が見えにくい
  • 看板が横に伸びて一覧性が悪い
  • taskとissue(後述)が混ざっていた

taskとissue

  • task:project管理上のアイテム。目的を達成するために大きなタスクから細分化されたもんお
  • issue:問題、課題...

project⇒taskという含合関係

  • SREチームにいくつかproject
  • スクラムチームの中にいくつかプロジェクト(スクラムinスクラム)

Asanaに移行

  • 依存関係を確認しやすい
  • いつごろ終わりそうかが確認しやすい
  • 各自が抱えているタスクを確認しやすい

心理的安全性を養うツール

経堂隆大さん / Sansan株式会社

異動・転勤に伴い潜在意識の変化

  • 心機一転
  • モチベーションUP
  • 言語チェンジ

潜在意識下

  • 緊張の連続
  • 人間関係の再構築
  • 慣れない環境
  • プレッシャー

心理的安全性

  • 質問しやすい、気兼ねなく発現できる、というような場の環境

ホワイトボードと付箋

プランニング

  • 手法
    • 新規ストーリー開始時に簡易な設計図をホワイトボードに書く
  • ポイント
    • 5〜10分で書く
    • 曖昧な部分に気づく
  • アナログのメリット
    • アウトプット・フィードバックのスピード
    • オフラインでの対話になれる

雑な絵でもいい

ラーニングセッション

  • 内容
    • 積極的に自分の学びを共有
    • 積極的に他人の学びを共有
  • テーマ
    • 1週間の学びを共有
    • 教えてほしいところ
  • 進め方
    • 自分の学び、教えてほしいことを書く
    • ホワイトボードに張り出す
    • 知りたいものに投票
    • 点数が集まったものに重きを置いて、順に発表

効果

  • 技術面
    • 属人性の排除
    • 同じ轍を踏まない
    • 更に詳しくなる
  • 心理的
    • 知らないの表明
    • 無知の受容、わからないへの共感

ふりかえり

  • KPT方式
    • 取り組みの最適化
    • 個人で抱えている問題・懸念をチームのものにする
    • 問題の解決に向けてTryにチームで取り組む
  • ポイント
    • 1人の感じた抱える問題は全体の問題として捉える
  • ホワイトボードと付箋で振り返るメリット
    • 振り返りに集中できる
    • 他人の意見に左右されずに振り返る

kintoneを丸裸にするモニタリング&ロギングツール

鈴木 亜耶 ( @szkayeah ) さん / サイボウズ株式会社

speakerdeck.com

モニタリング

2つの監視サービス

  • Datadog
  • New Relic

Datadog

  • 自社クラウド基盤
  • 割とヘビーに活用
  • 機材故障の検知にも有効
  • カスタムメトリクスで業務的な監視

New Relic

もっと自由に可視化したい

  • Elasticsearch+Kibana
    • 自社ツールでデータ加工してElasticsearchへ投入

kintoneのロギング

blog.cybozu.io

同じ方法で閲覧

  • ログ種類、日時、hostで絞り込み

2つのアクセス手段

  • CLI(HBase client)
    • 長期間のログが閲覧可能
  • GUI(Elasticsearch+Graylog)
    • 短期間だが複数hostを高速に閲覧可能
    • エラーコードが分かるときなど特定の検索
    • データの可視化

アクセスログの活用(非エンジニア)

  • Presto+Redash
    • SQLライクにログを検索
    • CLIでログを読めるエンジニアでも嬉しい
    • Prestoの便利関数が利用できる
  • 加工したデータの列を追加してより検索しやすく
    • 製品
      • kintone,garoonなど
    • ブラウザ
      • UAだと見にくい

A lot of Bots in Moneyforward

村上 勝俊 さん / 株式会社マネーフォワード

Toolの話

Editor

  1. Jetbrains系(RubyMineとか)
  2. VSCode
  3. Vim

Botの話

github-pr-message

  • いい感じにDescriptionを埋めてくれるBot

r2m2tag

  • r2mというタイトルのPRがマージ

mentions

  • メンションをSlackにリレー
  • esagithub上でメンションされたときに各サイトのSlackにDMが届く

tanomu

  • 明示的なレビュアーアサインをしない場合にランダムにレビュアーを決められるようにする

unfurller

  • privateなesaのページのumfurring(OGPっぽいやつ)を挿入してくれる

Unipos Suggest

  • 週に1回Slackのリアクションやメンションを可視化

ファンタスティックエボリューション

  • 個室トイレが空いているかどうかチェック
  • Throneが導入されてお蔵入り

ダイレクトプラス開発裏話

原田 康生 さん / クックビズ株式会社

プロダクト開発ツールとしてのフレームワークCakePHP

高速開発のための解決策

  • 仕様策定からリリースまで3ヶ月
  • 既存のコードをフル活用
  • Cookbiz Packagist
  • CRUDアプリケーションツール

基本の動作はプラグインを活用

ビジネスロジックを振る舞いとして作り込む

設定とロジックの分離

  • 仕様変更には設定変更で対応する

【読書メモ】レガシーコードからの脱却

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

色々と噂を聞いて興味を持ったので、積ん読待ち行列を追い越して読みました。タイトルからご察しの通り、例えば次のような、「いまだにウォーターフォールで開発していて、10年前に流行った某フレームワークを使っていて、当然テストコードも無いです。このままでは良くないので変えたいんですが、何から変えていけば良いでしょうか?」的な課題に立ち向かう勇気をもらえる本だと思います。

レガシーコードから脱却する

一言で言ってしまうと「レガシーコードから脱却する」ということは、「テスト駆動開発できる状態を目指す」ことであると私は読み取りました。

レガシーコードから脱却するためのテスト駆動開発

テストファーストに徹することで、テストコードを仕様書として扱えるようになり、変更に柔軟なコードへリファクタリングできるようにしていくと、設計が最後に完成します。これらは常にCLEANなコードを意識し、これを維持することで実現できると筆者は述べています。9つのプラクティスのうち後半の半分がCLEANコードによるテスト駆動開発の話です。

CLEANコードとは

  • Cohesive(凝集性)
  • Loosely Coupled 疎結合
  • Encapsulated(カプセル化
  • Assertive(断定的)
  • Nonredundant(非冗長)

オープン・クローズドの原則

CLEANなコードを維持して前述のような開発が実現できれば、いよいよレガシーコードをリファクタリングし脱却に向けて動き出すことができるようになります。レガシーコードのリファクタリングはオープン・クローズドに行うべきだと述べています。オープン・クローズドの原則とは以下の意味です。

拡張に対して開かれているが変更に対して閉じられている

※参考

レガシーコードから脱却するためのアジャイル開発

レガシーコードに囲まれた状態で、いきなりCLEANコードを意識してテスト駆動開発しましょうと言っても実現は難しいと思われます。そのベースを作るのがアジャイル開発です。9つのプラクティスの前半の半分がアジャイル開発の話です。

アジャイルの実践

本書は2部構成になっており、9つのプラクティスの解説に入る前の第1部ではソフトウェア開発の業界が抱える課題や、そこからアジャイル開発が生まれた経緯、筆者が重要と考えることをアジャイル開発から出発して9つのプラクティスとしてまとめた経緯について、丁寧に述べられています。

  • 小さな単位でビルドすることの目的は可能な限り早くタスクを完成させることであり仕掛り中の作業を制限することである。
  • アジャイルはいかにスコープを箱に収めるかだ。作業対象の範囲をいかに限定するかだ。
  • ここで重要なのは、スコープや仕事の単位の観点で小さくしようと努めることであり、時間の単位ではない。

継続的インテグレーション

開発プロセスアジャイルに変えることは、体制を変えてイベントを導入するだけではないということは今さら説明不要だと思います。

いつ統合するかは、アジャイルスクラムの実施有無や、イテレーションスタンドアップミーティングなどとはほとんど関係ない。もし、2週間のイテレーションで開発していて、各チームがコードを自分たちのブランチに統合し、年末にすべてのブランチを統合しているんら、悪いニュースがある。あなたはウォーターフォール開発をしてしまっている!

人もコードもプロダクトも、小さな単位のイテレーティブな開発を手に入れることが、テスト駆動で開発をするための土台であるということだと思います。

9つのプラクティス

レガシーコードからの脱却のためにテスト駆動開発を取り入れる。テスト駆動開発を取り入れるために、まずアジャイル開発を取り入れる。その流れに沿って必要なことを分解し整理したのが9つのプラクティスです(あくまで私の理解ですが)。

  1. やり方より先に目的、理由、誰のためかを伝える
  2. 小さなバッチで作る
  3. 継続的に統合する
  4. 協力しあう
  5. 「CLEAN」コードを作る
  6. まずテストを書く
  7. テストでふるまいを明示する
  8. 設計は最後に行う
  9. レガシーコードをリファクタリングする

書籍の冒頭の「はじめに」で筆者は次のように述べている。

成功するチームと失敗するチームの差は、プラクティスがなぜ重要なのかを理解していたかどうかだ

テスト駆動開発でのテストコードの作り方やアジャイル開発でのユーザーストーリの作り方などの具体的なやり方なども解説されていますが、大事なのは具体的な手法をなぞることではなく、プラクティスの本質を理解することにあります。一度読んで満足するものではなく何かあった時に読み直し、書かれている概念的な要素を反芻して腹落ちさせることで理解を深めていく書籍であると思いました。手元に置いて繰り返し読むことにします。

参考

翻訳した吉羽さんのスライドです。読後に改めて読むとまた理解が深まります。

slide.meguro.ryuzee.com