感情タグBEST3
Posted by ブクログ
紹介文にもある通り、ソフトウェアテストそのものというより、チームにどのように「テストの文化」を浸透させるか、に焦点を絞った内容。講演などでは最近よく話題にでる内容ではあるが、実践的な内容など改めて書籍で読むと新鮮。
Posted by ブクログ
組織の品質文化は品質ナラティブとして存在している。
プロダクトは組織内外の様々なメンバーが関わって作り上げられるもので、であればプロダクトの品質も組織の品質文化の影響を受けるよね。というと当たり前のように聞こえるが、「開発現場やテストチームだけでなく、組織一体となって品質を考えることが必要だ」というのは本書を読んで一番の学び。
「品質を通じて顧客に価値提供を行う」ことが必要となってきている現代で、品質をリードできるスキルが今一番求められているのかもしれない。
Posted by ブクログ
品質といわれてもピンときていない系の経営者向けの内容。スタートアップのアプリ開発なんかでひどい品質のものをリリースしてくる系の人には読んでほしい。特にここで説明に用いられているナラティブの話が秀逸で、特にこの分野に詳しくなくてもすっと入る内容。アジャイルとか開発プロセスに特化した話は少ない。自分のコンサルの道具として使いたいので、是非とも電子版をお願いします。
Posted by ブクログ
今や、低い品質が許される時代ではない。ユーザー目線では当然で、作り手としては首筋に冷たいものが通りぬけるこの事実をまえがきから突きつけられる。
品質がコストセンターだったパラダイムの組織で発生する問題から、文化のトランジションを起こす方法、品質とビジネス価値が軌を一にして前進するための勘所まで、100ページちょっとのボリュームの中にソフトウェア開発に必要なエッセンスが詰め込まれている。
そしてもうひとつ特徴的なのが、訳注の数の多さと丁寧さ。訳者の誠実な姿勢と、この本を日本の読者に正しく届けたいという使命感や情熱を感じた。
個人的にハッとさせられたのが、プロダクトのステージによって最適なテスト戦略は異なるという指摘。二言目には「自動化ァッ！！」と言いがちな人間なので気をつけようと思った。
Posted by ブクログ
ソフトウェア開発における品質文化の情勢のためのアプローチについて解いた書籍。単なる品質保証テクニックではなく、組織にどのようなアプローチをするかや、品質の世界観、ヒューマンスキルなどまで広く言及されているバランス感がとても良かった。
書籍のフォーマット的に、訳者の存在感がやや気になってしまう点だけ残念だった。特に、訳注が長い割に、本文の中で同じフォントスタイルで差し込まれているので、肝心の本文に集中しづらかったところが気になった。
Posted by ブクログ
思想には共感できる一方、方法論の記述が少ないので実効性に欠けるだろうという印象を持った。分量は少なく、手軽に読むことができる。
本書は3つのセクションと合計10の章から構成される。
セクションⅠ 品質リーダーになるには
第1章 品質と価値 / 第2章 3つの品質ナラティブ / 第3章 品質文化醸成
セクションⅡ 戦略的に品質の意思決定を下す
第4章 手動テストと自動テスト / 第5章 プロダクトの成熟度と品質 / 第6章 継続的テストとフィードバックループ / 第7章 テストインフラへの投資
セクションⅢ 成長を加速させるチームにする
第8章 チームと会社の成長指数 / 第9章 ローカルペルソナ / 第10章 品質戦略のリード
本書では品質に関する文化に注目することが多い。文化に関して提唱されている「3つの品質ナラティブ」はわかりやすい考え方ではある。
> 責任ナラティブ：誰が品質に責任を持つか考えられ、語られている
> テストナラティブ：品質向上につながる正しいテスト技法はどれか・どのツールを使うべきかが考えられ、語られている
> 価値ナラティブ：品質に投資した場合の見返りが考えられ、語られている
> 組織における品質リーダーとして重要なのは、どのナラティブが自分たちを目標から遠ざけているかを認識し、手を打てるようになることだ。（3つの品質ナラティブ p.20）
上記の3点は、気持ちや考え方を変えることで解決する問題ではなく、相当に技術的な解決能力が求められるように感じる。例えば、テストナラティブについて以下のような記述があり、これを解決できるのは技術や知識によってだろう。
> テストナラティブがよくない方向にいってしまうのは、テスト戦略が誰かの手による既存のものの猿まねにすぎないときだ。...10人のエンジニアに同じ機能を実装するように依頼したら、10通りのアプローチを目にすることになる。...テストをどうやるかを考えるにあたって、チームの成熟度・インフラ・予算といったものを考慮しなけえれば、おそらく良い結果にはならないだろう。（3つの品質ナラティブ p.22）
他部署との連携などの文脈でも以下のような記述がある。
> 味方につけたい人が話している言葉やコンテキストを捉え、その人が重要視していることを見つけて、注意をひくような言葉を使って問題をフレーム化しよう。機能や情報ではなく、あなたのアイデアがどんなメリットを提供できるかにフォーカスしよう。特に彼らが心配していることや望んでいることとどんな関わりがあるかを話すべきだ。（品質文化醸成 p.31）
これは相手の業務や組織的な課題を言語化して、それについての解決策を提示する必要があるということを言っていて、とても難しい。
本書を活用するためには、事業責任者やエグゼクティブが読むだけでは足りなく、本書で言及されている領域について手を動かしているエンジニアと共通認識を持ち、一体となって動く必要があるだろうと感じた。
その際に本書の方針に従うと技術的な理解が避けられないことが辛いところではあるが、お互いにとって客観的に理解できる指標（これはおそらく成長指標ではない）を導入して認識を合わせながら進めるのがいいのだろう。
