岡澤裕二のレビュー一覧

実践ソフトウェアエンジニアリング （第9版）

Roger S. Pressman / Bruce R. Maxim / 西康晴 / 水野昇幸 / 井芹久美子 / 井芹洋輝 / 池田暁 / 岡澤裕二 / 金子昌永 / 衣笠駿 / 鈴木一裕 / 根本紀之 / 松尾和昭 / 山﨑崇

ソフトウェアエンジニアリングに関する幅広い要素についてまとめてある教科書的な一冊。
要求エンジニアリング、モデリング、テスト、マネジメントなどソフトウェアを開発するための考え方が多数書かれています。初級者は自分が必要なところを選んで読む／中級者は全体を読んで全体観を把握するのに適している印象です。
この本でソフトウェアエンジニアリングのすべての要素を含んでいるわけではありませんが、多くの範囲をカバーしているのは間違いありません。手元に置いて、困ったときに手を伸ばすような使い方になると思います。

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムのあるゆることが網羅されている。かなりのボリュームだけど手引き書としてとても良いと思う。
これまでの経験や知人から聞いたような事柄をいろいろ思い出して、自分の経験知識のおさらいになった。よくまぁこれだけ的確な文章で書ききったなと。

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムの基本的なポイントがおさえられ、かつ現実的に制約になりえるところ(複数プロダクトを見るチーム、SMと開発者の兼任など)にも目配りされた網羅的な一冊。
「グルーミング」など最新のスクラムガイドでは用いられていない用語があったり、この一冊だけでスクラムと向き合うにはいささか時が流れすぎてはいるが、ある程度習熟しているなら自己点検の意味でも読む価値のある一冊。

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムを導入した会社のBiz側として必要な章だけかいつまんで、通読。
一気にスクラムの理解が深まった。

あとは業務上で必要な時に辞書として使うのが良さそう。

実践ソフトウェアエンジニアリング （第9版）

Roger S. Pressman / Bruce R. Maxim / 西康晴 / 水野昇幸 / 井芹久美子 / 井芹洋輝 / 池田暁 / 岡澤裕二 / 金子昌永 / 衣笠駿 / 鈴木一裕 / 根本紀之 / 松尾和昭 / 山﨑崇

ソフトウェアエンジニアリングについて書かれた本。正直、知らないことの方が多かったが、開発をより良くするため辞書的に活用していきたい逸品。

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

翻訳が読みやすくてサクサク頭に入るのがすばらしい。ところどころにLeffingwellさんの名前が出てくるからSAFe系の図解が多く、エンプラ系に響きそう

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムを始めたときから、何回も開いている。
ここに答えはないが、考えるための要素がある。

これまで一気通貫で読んだことがなかったので、通しで読んでみた。
結果、あらためてスクラムは難しいと思った。

予想として良しとするのか、コミットメントしてやり切るのか。
どっちが正解なのかわからない。

本気なのか適当なのか。
本気でやってても、他人からみたら適当レベルに見えるかもしれない。

ただ開発はチームで行っていて、人と一緒にチームを形成している。
一人ひとりが異なるのだから、どのチームでも正解なんてないのと同じように、
そういうことを受け取られる可能性の一つがスクラムなのだと思う。

スクラムを用いることで、チームに最低限のルールを示し、
一人ひとりが異なることを前提に、チームで前進していくしかないのだろう。

（以下抜粋。○：完全抜粋、●：簡略抜粋）
○私自身は、開発チームはすべからく、各スプリントで何を届けられるかを予想（見積もり）しなければならないということに賛同する。しかし、予想を基にコミットメントを導きだすことで、利益を得られる開発チームも多い。コミットメントによって、プロダクトオーナーと開発チームの間にも、開発チームの内部にも、相互の信頼関係が築かれる。（P.18）
○プロダクト開発の初日には、自分たちが何をしているかについての情報は最も少ない。開発が続くにつれて、少しずつ学習していく。それではなぜ、最も重要で、おそらくやり直しの利かない判断を初日、もしくは初期に行おうとするのだろうか？（P.38）
○ただ実際のところは、ほとんどの技術的ストーリーはプロダクトバックログに入れるべきではない。代わりに、これらのストーリーはビジネスストーリーの関連タスクとするべきだ。（P.88）
●プロダクトバックログアイテムの例：PBIの形式は、フィーチャー、変更、不具合対応、技術的な改善、知識の獲得
○みんなでグルーミングすることでさまざまな意見がを引き出せることを知っている。みんなの意見や、それぞれの立場から視点を活かせば、重要な情報をもれなく引き出せる。また、いろいろな立場のチームのメンバーをグルーミングに参加させると、プロダクトバックログについての明確な理解を共有できる。（P.102）
○見積もりはコミットメントではない（P.120）
○技術的負債があまりにも増えすぎてしまうと、そのプロダクトに関して何らかの予測をするのはほぼ不可能になる。（P.139）
○負債を返済する手段として一括払いを選ぶことが多い。それよりは、何回にも分けて、適切なタイミングでインクリメンタルに既知の技術的負債を返済していくほうがよい。（P.154）
○チームを小さく保つ理由を以下のように述べている。
・誰かがやってくれるから自分はやらあくてもよいという「社会的手抜き」が少ない。
・小さなチームは建設的なやり取りが頻繁に発生する。
・調整に必要な時間が少ない。
・誰も陰に埋もれることがない。
・小さなチームのほうがメンバーを満足させることができる。
・有害な過度の専門家が発生しにくい。（P.197）
●Appelo による7段階の権限レベル、通知、説得、相談、合意、助言、確認、委譲（P.218）
●伝統的なプロジェクトマネージャーの責務は一貫性の管理、スコープ、時間、コスト、品質、チーム、コミュニケーション、リスク、調達。PO、SM、開発チームはこれらの責務を分割、あるいは共有する。（P.226）
○事前にきちんと計画を作れると思うな（P.235）
●プランニングのレベル（P.244）
・ポートフォリオ：おそらく年単位
・プロダクト：数か月単位、あるいはもっと長期
・リリース：3か月から9か月
・スプリント：1週間から1か月
・デイリー：毎日
○MRFは最低限の「必須」フィーチャーを表すものだ。つまり、顧客が期待する価値や品質をもたらすために、今回のリリースに必ず含める必要があるフィーチャーである。リリースプランニングの中でも重要なのが、今回のリリースにおける真のMRFが何なのかを再評価して見直すことだ。（P.300）

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラムについて一通りに情報が記載された一冊。

スクラムになれた人がきになる部分をつまみながら読むとスクラムを更に加速させることができる1冊。

エッセンシャル スクラム

KennethS.Rubin / 岡澤裕二 / 角征典 / 高木正弘 / 和智右桂

スクラム開発を詳しく知るのには恰好なのだろうけれども、スクラム開発を支持するひとびとのスクラム開発それ自体へのものすごい熱量やこだわりはたまたま巻きこまれてしまった程度の人間にとっては次第に馬鹿馬鹿しく感じられてくる。

実践ソフトウェアエンジニアリング （第9版）

Roger S. Pressman / Bruce R. Maxim / 西康晴 / 水野昇幸 / 井芹久美子 / 井芹洋輝 / 池田暁 / 岡澤裕二 / 金子昌永 / 衣笠駿 / 鈴木一裕 / 根本紀之 / 松尾和昭 / 山﨑崇

【読み方：精読】
【周回数：0.7】
【収集メトリクス：未理解】
【理解度：理解・適用】
【時間：50時間ほど】
【媒体：実物】
【メモ
■内容自体は目が飛び出るくらいにとても良い箇所がある。そういった場所をつまみ読みするのがコスパが良いと思う。もしくは、困った箇所や直近実践したい箇所を参照にするのが良い。
■これ一冊で強制的にソフトウェア開発の全体像が見えて、PdM,デザイナ,エンジニアの視点がわかる点が良い。
■チームメンバーにこれを読んでいる人がいたら心強いのにな。と思う場面はある。
■自分だけだが、読む際はとても集中力を要する。朝イチの頭の冴えているときに、2時間くらいまでしか続かない。読んだその日はSEPAを開くことができない。
内容が認知領域に収まりきらない、右開きの違和感、見出しと内容の不一致が多いため都度主張を要約する、用語の定義や関係性が掴みきれないなど、独特の読みづらさがあり、何度も返し読みをしてしまっている。一章につき2～3周ほど回して理解を進めている。