高木正弘のレビュー一覧

実践ドメイン駆動設計

ヴォーン・ヴァーノン / 高木正弘

> ソフトウェアは、業務側が「こうしたい」と考えていたことを、ソフトウェア開発者が翻訳したようなものになってしまうことが多い。できあがったソフトウェアがドメインエキスパートのメンタルモデルをきちんと反映できているわけではなく、仮にできていたとしても部分的なものに過ぎない。時がたつにつれて、この断絶のコストは高くつくようになる。開発にかかわったメンバーが他のプロジェクトに移ったり転職したりした時点で、ドメインに関する知識のソフトウェアへの翻訳は消え去ってしまう。（事業価値をもたらすのは難しい）

> ここで言う「チーム」とは、ドメインエキスパートとソフトウェア開発者がどちらも参加しているものだ。「私たちとあの人たち」ではない。常に「私たち」だけになる。（DDD がどのように役立つか）

良書。
決して読みやすい本ではないが、それは説明の悪さにあるのではなくて、DDD を現実のサービスに適用する際の難しさ（自由度の高さ）にあるのではないかと感じる。

概念的すぎず、ドメイン、バリューオブジェクト、エンティティなど DDD の基本的な概念が定義から記述されている。慣例はそれとして、「本来それらの概念はどのようなものであるべきか」を DDD の立場から考えるための視点を与えてくれる。

> ソフトウェア開発の世界では、...豊かな振る舞いを備えたドメインの概念を設計するのではなく、まずはデータの属性（カラム）と関連（外部キー）を考えてしまう。（エンティティ）

> Java の世界では、インターフェイス名の後ろに Impl を続けたものを、実装クラスの名前とするのが一般的だ。...実装クラスをこんな名前にできるということは、そもそもセパレートインターフェイスなど必要なかったという証ではないだろうか。（セパレートインターフェイスは必須なのか）

継続的デリバリー 信頼できるソフトウエアリリースのためのビルド・テスト・デプロイメントの自動化

JezHumble / DavidFarley / 和智右桂 / 高木正弘

継続的デリバリーの化身みたいな人が書いた本
ソフトウェア開発をするのであれば、確実に読んでおきたい一冊

エッセンシャル スクラム

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

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

エッセンシャル スクラム

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

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

エッセンシャル スクラム

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

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

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

実践ドメイン駆動設計

ヴォーン・ヴァーノン / 高木正弘

DDD本では掴めなかった点がサンプルなどから段々クリアになってよかった。
サンプルは徐々に時を経て古くなってきているけどGitHubで全て公開されているので参考にしやすくてとても良い。

エッセンシャル スクラム

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冊。

実践ドメイン駆動設計

ヴォーン・ヴァーノン / 高木正弘

Evan本より実装寄りのため書いてあることのイメージがしやすかった。
ただ文章、流れ、構成が悪くとても読みづらく理解しづらかった。翻訳も一部わからない部分があった。
また図も少ないのもわかりづらかった。
全体がJavaのサンプルコードなのに、最後の付録AがC#のコードであったのは残念だった。

書いてあることは★４～５だが、読みづらさは★１～２なのでトータルで評価は★３とした。

エッセンシャル スクラム

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

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