市谷聡啓のレビュー一覧

リーン開発の現場 カンバンによる大規模プロジェクトの運営

簡潔なのに、かなり包括的。中心は実例ベースだけど、最後にテスト自動化や因果関係図、プランニングポーカーまで載ってる。
継続的リリースを、警察機関の報告業務アプリで実現させたとのこと。こういう開発を日本でもやらなきゃいけない。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

カンバンを使うことによる組織のコラボレーションと進化の仕組みであると理解した。
カンバン上に表現することで、コミュニケーションが発生し、問題が可視化され、カイゼンする文化が築かれ、枠を超えた信頼とコラボレーションが発生するのだ。

現在のプロジェクトで利用しているタスクボード上にも、エモーションチケットやKPT、割り込みタスク、やりたいこと、バッファなどが発生している。これもいわゆるカイゼンプロジェクトボードという形でスケールしているんだなぁ。

-引用-
プロジェクトメンバーを集めて、自分たちのコンテキストでの「理想」を見つけよう。...理想の探求は、進むべき道を示すコンパスになるはずだ。理想を達成することが必要なのではない。理想とはたどりつくべき場所のことではなく、ありたい姿に向かい続ける事なんだ。

優れたプロセスは、設計によって生み出されるものではない。進化の結果として表れるだから、現在行っているプロセスが重要なのではない。現在のプロセスを改善するためのプロセスこそが重要なんだ。

本当の失敗はひとつしかない。それは、失敗から何も学ばないという失敗だ。

結果が重要なのではない。人と結果を出せるシステムを育てるのが重要なのだ。

学びとは、ただ知る事ではない。知識は頭の中のものだが、学びとは手の中にあって、熱意によって行動に移されるんだ

これまでの仕事 これからの仕事 ～たった1人から現実を変えていくアジャイルという方法

会社の人事評価の部分は頷ける部分があったけれど抽象度の高い内容が多かったので自分的には少し読みづらかった。プレイヤーからマネージャーになる段階で読み返すのも良いと思う。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

ストーリー仕立てで説明されており、とある事例の参照にできる
本書でも触れられている通り、この事例でうまくいったからといって、自分の現場でうまくいくとは限らないというのは、覚えておく
問題は起きるけど、最後はどうにかするのがもやもやした。

正しいものを正しくつくる－プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

いわゆるアジャイル開発の進め方をスクラムをモデルとして具体的に解説。チームビルディングからチームにおける役割、日々のスプリントの回し方、マインドなどが解説される。
私は本書が想定する読者ではなかったため、あまり刺さらなかったけれど、アジャイル・スクラムを具体的に導入したい方には実践的ガイドとなっているだろう。
とはいえ、守破離に言及する文脈で、あえて不確実性を残すことも必要という観点は面白かった。新規プロダクト開発はややもするとみんなが想像できる安定感のあるプロダクトに落としてしまいがちだけれど、それをあえて揺さぶるために不確実性を残す、取り込むという観点は忘れてはならないだろう。何のために新規事業開発をつくろうとしているかはスプリントを回している内に見失いかねないけれど、それを思い出させてもらえるからだ。

これまでの仕事 これからの仕事 ～たった1人から現実を変えていくアジャイルという方法

言わんとすることはわかるけれど
旧来の効率重視の方針のダークサイドを執拗にハイライトして「これからの仕事」の価値と説得力を高めようとしている印象は否めないな

古くからPDCAという概念はあったのだから

いずれも銀の弾丸ではないし協働や振り返り向き直り生むには隠れた前提が多くある

これまでの仕事 これからの仕事 ～たった1人から現実を変えていくアジャイルという方法

理想は理想。現実は現実。でも誰でもない自分が変えていかないといけない。それがアジャイルであるかどうかは方法論の問題である。現実を変えようとするにはまず自分が変わり、そのあとに周りを巻き込んでいく作戦を考えないといけない。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

# 「アジャイル開発」という言葉の説明

## 面白かったところ

* 開発者を含めたプロダクト開発に関わる人向けに書かれているため、IT業界を取り巻く状況などの背景知識もざっくり知れるとこ
* アジャイル開発のはじめ方にも種類があり、導入や初歩でつまづきそうなQ＆Aも揃っていて安心感があ

## 微妙だったところ

* 本に書かれていることは、おそらく「スクラム」というフレームワークに沿って進めていること前提に書かれている印象だが、スクラムとアジャイルは似て非なるものなのでごっちゃになりやす

## 感

仕事をすればするほど、本を読めば読むほど、ソフトウェア開発は難しいと思う

現場で開発者として働いていて思うのだから他の方々はもっと理解が困難なのだろうと思う

だからこそこの本を読んで、「アジャイル開発」という魔法のような言葉に親を殺される前に正しい知識をつけていただきたいと思った

もちろん、チームメンバーには推薦図書として紹介する

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

# チームの成長に寄り添った、ソフトウェア開発の物語

## 面白かったところ

* カイゼン・ジャーニーの続編という文脈を濃く受け継いでいる点
* チームの運営や雰囲気などに詰まった時、視座を高めてくれる一冊
* ひとえにチームと言っても、様々な段階や顔が存在することを知れる

## 微妙だったところ

* 組織マネジメントではなく、あくまでも「チーム」に特化した一冊であるため、分かりづらい点も少なくないこと

## 感想

エンジニア（開発者）として、チームの一員としてどう振る舞うべきか悩む時がある。

悩むのは悪いことはいいが、無数の答えが存在してメリットやデメリットを測ることも正直難しかった。

この本に出会ってかなりスッキリした点が多かった。リーダーとリードの違いや海星型チームと蜘蛛型チームの違いなど、チームによって様々な段階や形態があることを学んだ。

不明点も少なくなかったため、また読み返したい。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

かんばんの話が多かった印象。
短くて読みやすいけど、リーンについて本当に知りたかったらトヨタ生産方式を知る必要がある？

正しいものを正しくつくる－プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

具体的なHowについては、実践しながらインプットするとして、一旦概念的なもののメモを残しておく。

◾️第二章: スクラム開発
4つの価値
・対話を重んじる
・早く動くものを作る
・顧客との協調
・計画よりも変化への対応

原則
・早く、継続的に
・変化を味方につける
・振り返り改善する

チーム
・PO）プロダクトの価値の最大化
・開発チーム）製造・完成
・SM）スクラムプロセスの実施中

スクラムイベント
・プランニング
・デイリースクラム
・レビュー
・レトロスペクティブ

成果物
・プロダクトバックログ
・スプリントバックログ
・インクリメント

9つの意義 ≒ 目的
・早く認識を揃える
・早く問題に気づく
・繰り返して学習する
・早く市場に出す

■第五章: 価値探索
基本スタンス
・モデル化とその検証の繰り返し
　モデル化）分かっていることの言語化・図式化

仮説の種類
・課題仮説
・ソリューション仮説

検証結果のジャッジ観点
・Problem-Solution-Fit
・Product-Market-Fit

具体的な方法
・叩き作成（仮説キャンバス）
・課題設定の正しさの検証
　ユーザーインタビュー
・課題に対する解決策の正しさの検証
　プロトタイピング
・参考）その他の手法
　アンケート）課題仮説、ユーザーが見えないとき

---

感想
・環境変化が激しい時代なので、ウォーターフォール型の開発プロセスが時代にフィットしないっていうのはこれまで何度も言われてきていること
・そういう状況に対してアジャイル開発という手法で立ち向かおうとするってのもよく聞く
・その整理でいくと、本質は「変化への適応」のように思う。それを達成するために「小さく・早く作る」という手段が採用される
・で、特に面白いのは後半の「価値探索」の話
・仮説をに種類に分けて、仮説検証を繰り返すことで「小さく・早く作る」ことを実現しよう、みたいな話

組織を芯からアジャイルにする

やや内容はマニアックで、本当にアジャイルにフォーカスした内容だが、組織に浸透させる段階では再読すると思う。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

アジャイルについて、わかりやすく書かれていて、なんとなく把握するにはいい感じの本だった。
実際にやってみないとわからないけどもね。。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

勉強になりました。
経験者がチームに入って、展開するものだな
って、感じました。

この書籍には、これ読んだら、部分的にでも始めましょうとは、書いてありますが。

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

■チームになるための４つの条件
①チームの目的を揃える
②共通の目標を認識する
③お互いの持ち味を把握する
④協働で仕事するためのやり方を整える

■リーダーとリード
リーダー：組織上の職位として定義され、人に張り付く言葉のイメージ。
リード：ある状況において前進を主導する「役割」。役割なので、他の人に代わる、代えることもある、より動的なイメージ。

■雁行陣開発
　…プロダクトリード、チームリードという役割を置く。プロダクトリードは、プロダクトのつくり方、方針、そしてその実装について先導する役割である。一方、チームリードは、チームの運営を担うことになる。その他のメンバーは適宜プロダクトバックログを実装する。それぞれの役割で、それぞれのミッションをつとめる。
　このフォーメーションで、前衛にあたるのはプロダクトリード、後衛にあたるのがチームメンバーだ。プロダクトリードが先行してかつプロダクトの中核となるプロダクトバックログを開発する役回りになる。その他のチームメンバーは、その他の必要な機能の開発を受け持つ。
　雁行陣開発でのプロダクトバックログの管理については、まずその性質からプロダクトの「背骨」にあたるプロダクトバックログと「お肉」にあたるプロダクトバックログに分けることから始める。背骨バックログとはプロダクトを利用するユーザーの体験上必ず必要となる機能群になる。
　…お肉バックログは、背骨があることを前提としてそこにまさに肉付けするようにつくることができる機能群のことである。

■透明性を高め、チームの共通理解を深める３つの原則
１見える化：情報を得られるようにする
２場づくり：情報を伝え合うようにする
３一緒にやる：情報を一緒につくる

■INVEST：プロダクトバックログが開発レディになっているかどうかを判断するモノサシ
Independet　お互いが独立している
Negotiable　実現内容について交渉可能である
Valuable　中身に価値がある
Estimable　見積もり可能である
Sized Right　適切な大きさである
Testable　テスト可能である

■チームミッションと作戦の流通範囲
・すべての情報を全員で共同所有する
・Why寄りの情報は広めに、How寄りの情報は狭く

■リード・パターン
テクニカルリード
チームの技術方針を決める役割。複数チームの体制の場合、各チームの技術的な窓口にあたる。チーム間での技術的方針のすり合わせや合意を行う。

仮説検証リード
仮説検証の活動を計画したり、その実行を先導したりする役割。仮説検証に必要な様々な道具立てについて実践するための知見を有し、その引き出しに広さが求められる。

テストリード
プロダクトの状態、目的に応じたテストの計画やテスト設計を先導する役割。出荷前に実施するテストや、セキュリティやパフォーマンスなど非機能系のテストなど、必要に応じて企画する。

デベロッパーエクスペリエンスリード
開発環境を中心として、チームメンバーの開発体験を向上させる取り組みを先導する。他のチーム、現場での取り組みについて情報を収集し、自チームに適した形での取り入れ方を検討する。

XXXリード
上記によらず、 特に注力すべき課題に応じて設置するリード。たとえば決済機能の開発およびそれに必要な一連のタスクをぬけもれなく完するために「決済開発リード」を置くなど。

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

ソフトウェア開発のことはよくわからないが (自分はハード屋寄りなので)、カイゼンについて知りたかったため前作を読み、さらにチーム運営についても学びたいと思い読んだのがきっかけ。
私が本書から得たキーワードとしては、問うこと、多様性、ともにつくる、の3つ。うしろ2つはセットなので、2つと言ってもよい。
仕事でもなんでも、主体的にものごとを進めようと思うならば、問うことが欠かせない。なぜこの仕事をするのか、なぜ私がやるのか、どうしてこのやり方なのか、あるべき姿はなにか。いくらでも問いは生まれる。問うことを止めてしまえば、目の前の仕事に没頭してしまい、こなしていることで前に進んでいる感覚は得られるかもしれないが、責任感は失われ、大きな間違いに迷い込んでしまう可能性が大いにある。先の読めない時代と言われて久しいいま、よりいっそう問うことが必要。
そして人的多様性も必要だ。それは女性が、とか若手が、とかいう意味ではなく、純粋に別のことを考えている個人が集まる多様性のことを言っている。問答を自分一人で抱えてしまうと、答えを出すのに時間がかかるし、多面的な視点を欠いて見誤る可能性が高い。その際、多数決の民主主義ではなく、意見のぶつかり合いの中で、新たな着想を得ることが大事。つまり多様性+ともにつくることが大事。
言われてみると当たり前というか、いろいろなビジネス本に載っていそうなことではあるが、それを物語を読み進めながら、どういうときにこの考え方が必要になるのかを追体験していくことができるため、より浸透できたきがする。
しかしながら、話が長いのと、登場人物の名前が独特で読み難いのがマイナスポイント。まず、主人公の名前がすんなり読めないので (私の語彙力が弱いせいでもあるが)、最後まで頭の中で変換する必要があった (ふといじゃなくて、うずまきみたいな、そう、うずまさ)。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

ソフトウェア開発に携わったことがないので、描かれていることのひとつひとつが具体的にイメージできなかったり、共感しにくかったりすることが多かったが、チーム運営については参考になった。
それを一言でいうと、ひとはそれぞれ違うということ。それゆえひとが集まってできたチーム (自社の組織に留まらず、目的を共有する組織) というものは努力しないとベクトルが合わず、前進することができない。しかしその壁を乗り越えることで、違いを多様性として活かすことができる。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

アジャイルの概要、具体的な取り入れ方、注意点、など広く浅く書かれた本。

この手の本はいくつか読んだが、そのちょうど良い復習になった。

内容もわかりやすく、例えば上司やグループ全体、部への導入検討などの時に、素材として参考にするにはうってつけの本だと思う。

いきなりこれを読むよりは、何冊か読んで、実践もしてみて、こなれた頃に読むと丁度良いかも。

正しいものを正しくつくる－プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

不確実性に対処するためには、チームの多様性を最大限生かすような開発を行うことが重要、というのが本書の要旨と思います。システムに必要な要件="正しいもの"を探るにしろ、開発中の仕様変更や課題解決及び無駄の低減="正しく作る"にしろ、チームで共に考え創る体制を作ることが、正解のない問題に対してより良い結果を得る方法なのだと思います。また、アジャイル開発（主にスクラム）において陥りやすい問題や、その対処方法なども紹介されています。

ただ、アジャイル開発に関する説明は、本書だけで十分とは言えないと思います。尤も書中でも述べられている通り、アジャイル開発は理解は容易でも"習得は非常に困難"とされており、書籍で十分に説明するということ自体が難しいので仕方がないところではありますが。全体として書いてある内容は理想として理解できますが、実際の行動に起こすとなると困難は多そうです。とはいえ、アジャイル開発のアンチパターンや本書で初めて知った手法などもあり、読んでみて良かったとは思います。

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

実際に開発現場でアジャイル開発の手法が取られていたがイマイチどのようなものか理解していなかったので呼んでみた。ソフトウェア開発は本書に書かれている通り不確実性が大きく、開発中の仕様変更も往々にしてある。現代のソフトウェア開発において、変化に適応するスピード感という観点から、アジャイル開発の有用性がよくわかった。