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

市谷聡啓

• ビー・エヌ・エヌ新社 (2019年6月14日発売)

作品紹介・あらすじ

従来のソフトウェア開発とは、「既に正解があり、記述された正解をそのまま形にする」というものづくりであり、いかに効率よく作るかという観点が主眼でした。そのため、正解の見えないなかで手探りで進んでいくことが必要となる不確実性の高い現代においては、うまく噛み合わない状況になっている開発現場も少なくありません。

本書では、共創を実現する具体的な⼿段としてのアジャイル開発を下敷きに、これからのソフトウェア開発／デジタルプロダクトづくりに、作り⼿（エンジニア、開発者、デザイナーなど）と、それを必要とする⼈（クライアント）がどのように臨むべきなのか、その考え方と行い方を具体的に提⽰する一冊です。

「正しいものを正しく作る（著者の掲げる理念）」とは、すなわち「正しくないものを作らない」戦略をとることであり、そのためには粘り強く「正しく作れているか？」と問いに置き換えながら探索的に作っていく必要があります。問いを立て、仮説を立て、チームととともに越境しながら前進していく。本書はそのための力強い手引きとなるでしょう。

感想・レビュー・書評

[ikuodanakaさんの感想 · 2019年6月12日]

300ページを超える本書は、特に初めてプロダクトオーナーなど「プロダクトでの視座を求められる」エンジニアに勧めたい。

第一章 なぜプロダクトづくりがうまくいかないのか ではどこの現場でも失敗や混乱が起きていることを伝え
第二章 プロダクトをアジャイルにつくる ではアジャイル開発の基本について解説され
第三章 不確実性への適応 では「暗黙的な期待」「成り立たないトレードオフ」といったアジャイルを導入してもなお立ち上がってくる不確実性と向き合い、ひとまず「正しくつくる」方法を身につける。
第四章 アジャイル開発は2度失敗する では文字通り、2つの壁が提示され「正しくつくる」だけでは不十分であることが示され
第五章 仮説検証型アジャイル開発 では「正しいもの」を探索する方法を知り
第六章 ともにつくる で「目的に忠誠を誓う。しかし心中はしない、問いを持ち続け共創する」という価値観が掲げられ、またそのためには「正しいものを正しくつくれているか」という問いの重要性が説かれる。

上上下下左右左右過去未来、視座と視野を動かし
正しいものを探し
正しくつくる

300ページを超える重厚な本書を読めばたちどころにプロダクトがよくなるわけではないが、本書の内容を咀嚼し、実践し、失敗し、カイゼンし、血肉としていくことで「正しいものを正しくつくる」力がついていくのではないだろうか。
2019年、エンジニアにとって令和最初の必読書である。

[まっさんさんの感想 · 2022年2月12日]

開発者、PMどちらも読むべき。とても勉強になったし、さっそく一部取り入れはじめた。今のプロダクトの開発前に出会いたかった1冊。

[きしんさんの感想 · 2021年11月21日]

仮説を仮説のままに検証する仕組みを持つこと、
わかっていないことをわかっていないままに受け止めることの重要さを感じた

[masahiro884さんの感想 · 2020年5月4日]

‪なぜプロダクト作りやソフトウェア開発はいつまで経っても上手くいかないのか？この永遠の課題に立ち向かう武器となるアジャイル開発の解説本。体系的理論よりも実践と失敗をベースにした構成になっており、自分が何に陥っているのかカウンセリングされているかのごとく見えてくる（ただし本書でも繰り返し言及されている「習得は非常に困難」には留意すべし）個人的には不確実性との向き合い方が書かれた第3章、特に「学びから生まれる課題」の話は目から鱗。開発が進み次にやることの洗い出しの精度が上がるのに比例してスケジュールが混沌としてくる違和感の正体はこれだったのか。今後も末永くお世話になる一冊になりそう。‬

[kazumiksさんの感想 · 2019年7月2日]

昨日の「プロダクトをつくるとはどういうことなのか？ -正しいものを正しくつくる-」に参加して、言われてみたらまだ本を買って読んでいなかったこともあり帰りに購入。
著者の体験を書籍にまとめたとのことですが、特に衝撃だったのは「アジャイル開発は二度失敗する」という章。早く少しだけ形にすることで新たにわかってきたこと(特に不安的要素)を現実的にどう受け止められるかという第1の壁、そして、プロダクトオーナーと開発チーム間の境界線という第2の壁がアジャイル開発に存在するということを痛切に思い知りました。私自身はアジャイル開発の経験がほぼないに等しいのですが、実際に取り組むときはこの2つの壁を意識しつつ、仮説検証をして回せるようにしたいものです。特にアジャイル開発をして上手くいかないと感じる方には一読すると良いかも知れません。

[starmankingさんの感想 · 2024年3月1日]

アジャイルやスクラムについて、なぜ失敗するのか、どうやるべきなのかがわかる。

[RTさんの感想 · 2024年2月20日]

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

[かばおさんの感想 · 2023年10月30日]

アジャイルの実践が必要になり、メソッドとしての知識ではなく原則を知りたくて読みました。仮説検証型アジャイル開発というプロセスを提唱していますが、それが標準的なアジャイルと何が違うのかは(知識不足で)わかりませんでした。陥りそうなアンチパターンなどがわこりやすく、現在進行形で参考にしたい考え方ばかりでした。間違ったものを正しく作ることを避けること、そのために視座を意識的に行き来することが必要と感じました。

[keng310さんの感想 · 2023年4月10日]

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

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

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

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

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

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

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

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

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

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

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

---

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

[tk23ohtaniさんの感想 · 2023年3月19日]

近代的なプロダクト開発で使われないようなものを作らないためにはどう実践すべきかの指南書になる。より詳細なプラクティスはスクラムやアジャイルの知識を参照しつつ、マインドセットとして参考にすると良さそう。必要性も含めて文章でしっかり説明されており、プロダクト開発の全てのフェーズで活用できるはず。
発売から4年経つので、第2版にも期待。

[japapizzaさんの感想 · 2022年6月18日]

第1章　なぜプロダクトづくりがうまくいかないのか
■まとめ
・なぜ、プロダクトづくりに苦戦し続けるのか。それは、プロダクト自体と、それを作る側の多様性が不確実性をもたらすからだ。
・その不確実性に対するこれまでの戦い方はどうだったか。作戦1:要件定義によって確実性を上げる。作戦2:合意を重視する。作戦3:合意形成を遵守する。しかしうまくいかない。
・不確実性に向き合うための別のアプローチ=アジャイル開発(早く少しだけ形を作る)への期待が生まれた。
・しかしアジャイル開発でも混乱が生じる。作るべきものの決め方の混乱、合意形成についての認識違い、変更が不可能になることへの関係者の不満。
・ではアジャイル開発でも不確実性に対処できないのか?アジャイル開発とはどういうあり方なのかを次章で解説する。

第2章　プロダクトをアジャイルにつくる
■9つの意義
①フィードバックに基づく調整で、目的に適したプロダクトに仕立てられる。
②形にすることで、早めに関係者の認識を揃えられる。
③作るものやチームについての問題に早く気づける。
④チームの学習効果が高い。
⑤早く作り始められる。
⑥結合のリスクを早めに倒せる。
⑦Time to Marketが短い。
⑧サンクコストを小さくできる。
⑨開発チームのリズムを整えられる。

■まとめ
・アジャイル開発は同意された4つの価値があり、その背後には12の原則※がある。
・スクラムには経験主義を支える3つのコンセプト(透明性、検査、適応)、さらにコンセプトを推し進めるために5つの価値基準(確約、勇気、集中、公開、尊敬)がある。
・スクラムチームには、3つのロール(開発チーム、プロダクトオーナー、スクラムマスター)、4つのスクラムイベント(スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ)、3つの成果物(プロダクトバックログ、スプリントバックログ、インクリメント)で構成される。
・ゴールデンサークル(Why、How、What)を使って自分たちのプロダクトづくりとしてどうありたいのか向き合う。
・ゴールデンサークルのWhyを考える取り掛かりとして「アジャイルに作る9つの意義」がある。
・アジャイル開発が破綻する理由とその適応については?「正しく作る」を支える戦略と戦術、作戦について次章で示していく。

※12の原則
〈プロセス〉
・顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
・要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
・動くソフトウェアを、2～3週間から2～3ヶ月というできるだけ短い時間間隔でリリースします。
<働き方>
・ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
・意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
・情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
〈持続可能性〉
・動くソフトウェアこそが進捗の最も重要な尺度です。
・アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
<設計>
・技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
・シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
・最良のアーキテクチャ要求・設計は、自己組織的なチームから生み出されます。
<カイゼン〉
・チームがもっと効率を高めることができるかを定期的に振り返り、それにもとづいて自分たちのやり方を最適に調整します。

第3章　不確実性への対応
■インセプションデッキ
①われわれはなぜここにいるのか:プロジェクトのミッションは何かに答える。
②エレベータピッチ:プロダクトの特徴を短いステートメントにまとめる。
③パッケージデザイン: 利用者からみたプロダクトの価値を表現する。
④やらないことリスト:大まかなスコープの特定。特にスコープ外について。
⑤ご近所さんを探せ:プロジェクトコミュニティ(関係者)を明らかにする。
⑥技術的な解決策: 採用する技術の利点とリスクの説明。
⑦夜も眠れない問題 : チームや関係者が認識しているプロジェクトのリスク。
⑧期間を見極める必要なプロジェクト期間の算出。
⑨トレードオフスライダー:QCDSの優先順位。
⑩何がどれだけ必要か:ミッション達成に必要な期間、予算、チーム編成。

■まとめ
・アジャイルに作るだけでは適応できない問題として、「暗黙的な期待を放置したままでの合意形成」と「不確実性への対処から得られる学びが新たな不確実性を生む」がある。
・不確実性に適応するための「正しく作る」あり方は、共通の軸「ミッション」の共通理解、余白の戦略、スプリント強度を高める戦術、全体への共通理解を統べる作戦。
　ミッション：期待をマネジメントする⇒インセプションデッキ
　余白の戦略：余白でもって不確実性を受け止める
　・調整の余白⇒広さでコミットし深さで調整する
　・期間の余白⇒プロジェクトに期間バッファを設ける
　・受け入れの余白⇒アイスボックスを設ける
　全体への共通理解を統べる作戦：プロダクトづくりの状況をチームの共通理解とする活動
　・OODAループ⇒観察→状況への適応→意思決定→行動
　・個人レベルの適応⇒SARの実施＝共有、表明、振り返り
　・チームレベルの適応⇒線表の適用（＝期待の可視化と意思表明）
　・ファシリテーターレベルの適応⇒プロダクトづくりの演出
　・自分たちの活動に作戦名をつける
　スプリント強度を高める戦術：確実性をスプリント前で確保する行動
　・背骨駆動開発
　・状況をクリーンに保つ5つの条件
　　①受け入れ条件を定義している
　　②ベロシティを計測し、安定させている
　　③受け入れテストを実施している
　　④ふりかえりを実施し、カイゼンし続けている
　　⑤実運用担当のデータが揃っている
・ミッションの共通理解を得るためのインセプションデッキづくり。
・余白の戦略とは、調整の余白、期間の余白、受け入れの余白からなる。余白でもって、不確実性を受け止める。
・スプリント強度を高める戦術とは、開発の確実性をスプリントの前で確保する行動。すなわち、背骨で駆動する開発と、プロダクトづくりの状況をクリーンに保つ5つの条件を実践する。
・全体への共通理解を統べる作戦とは、個人レベル、チームレベル、ファシリテーターレベルでの適応があり、これらをまとめた自分たちの活動に名前付けを行うようにする。

第4章　アジャイル開発は2度失敗する
　PSfitしている/していないの判断について絶対的な基準を定義するのは難しい。検証の結果から割合を見て判断する。例えば、ユーザーインタビューを実施して、想定ユーザーに当てはまる10名の被験者のうち、7から8割がソリューションへの高評価を行ったとすればPSfitの期待を高めに持つ。一方、5割程度ではまだ判断はできないし、4割を切るようではまずPSfitの期待を持つことはできない。検証を続けるか探索を打ち切ることになるだろう。

■まとめ
・プロダクトづくりでチームが直面する2つの壁がある。「アジャイルに作る」という取り組みの困難、そしてプロダクトオーナーと開発チームの間にある暗黙的なミッションの境界線。
・プロダクトオーナーに期待される役割と知識として、「なぜこのプロダクトを作るのか」という方向性の番人、「プロダクトの世界観を実現するために何を備えるのか」という仮説の番人、そして「プロダクトを形にするために必要な運用スキルと知識」がある。
・「なぜこのプロダクトを作るのか」に応え、その実現を導く概念が、ビジョン、ミッション、コンセプトである。
・「プロダクトの世界観を実現するために何を備えるのか」に応える3つの観点「要求は何か？」、「インターフェースはどうあるべきか？」、「ビジネスモデルはどうあるべきか？」
・「プロダクトを形にするために必要な運用スキルと知識」としての8つの領域がある。ソフトウェア開発の基本的な知識、プロダクトバックログの管理方法、受け入れテストの実施とテスト結果の活用、ユーザーテストによるフィードバック取得と継続的な計測、プロジェクトマネジメント、コミュニケーション設計。
・プロダクトオーナーと開発チームの間の「ミッションの境界線」を形成してしまう2つの境界には、「作る」と「作らない」の境界、アウトプットとアウトカムの境界がある。
・境界を越えるためには、プロダクトについてのチームとして共通の「基準」が必要となる。基準づくり仮説検証について次章で示していく。

第5章　仮説検証型アジャイル開発
■まとめ
・「プロダクトとして何が正しいのか」という見立て(基準)をチームの共通理解とする活動が、仮説検証である。
・仮説検証では「正しくないものを作らない」戦略を取る。「正しくないもの」の理解から、プロダクトについての基準の輪郭を浮かび上がらせる。
・「正しくないものを作らない」戦略にある3つの選択は、何のために必要なのか(目的選択)の実現のために何が必要なのか(実体選択の段階)、③どうやって実現するか(手段選択の段階)
・MVP開発へと進む判断基準は、「ユーザーに体験してもらわないとこれ以上の検証はできない(検証してもわかることが増えない)」かつ「その検証のためにはソフトウェアを作る必要がある」。
・MVPの範囲を決めてプロダクト開発とつなげていく活動において、検証活動＝価値探索において、モデル化とその検証を繰り返す。具体的には、検証の地点、検証活動、検証の終点から探索活動を構成する。
・モデル化の手段：仮説キャンバス(静的モデル)、ユーザー行動フロー(動的モデル)
・検証の手段：ユーザーインタビュー、プロトタイプ、ランディングページ、アクティングアウト
他
・仮説の種類は、課題仮説、ソリューション仮説、インターフェース仮説。それぞれ、本質、実体、形態にあたる。
・仮説検証が必要となる状況では、採用の失敗や下の失敗が起きている。

第6章　ともにつくる
■まとめ
・「正しいものを探す」から「正しく作る」へ接続するために「プロダクトバックログ詳細化への段階設計」、仮説検証の「精度と頻度の戦略」、「わかったことを正しく作る」。
・「わからないことをわかるようにする」から「わからないことを増やす」へ。自分たちが捉えている現状へのから離れて、新たな理解の獲得へと進む。
・越境のために視座と視野の位置、範囲を動かす。視座と視野に動きをもたらすコマンド「上上下左右左過去未来」。
・わからないことを増やすと一人の力では手に負えなくなる。不確実性にはチームの多様性で立ち向かう。
・越境するチームは「一人の人間」のような状態へと近づく。
・「役割を中心とした調整によるプロダクトづくり」から「問いと向き合い続ける共創によるプロダクトづくり」へ。

[田中久太郎さんの感想 · 2022年6月8日]

自分の抱えているシステム開発の悩みについて、さまざまなヒントが詰まっていた。システム開発の経典になりそうだ。

[akio yoshihashiさんの感想 · 2021年11月14日]

ソフトウェア開発の話なので前提を共有できてなく、リアルに状況を想像できないところも多くて理解するのがたいへんだった。それでもこれまでのいわゆるウォーターフォール型のソフトウェア開発との違いは歴然。

最終章（6章 ともにつくるー正しいものを正しくつくる）では、「視座、視野を越境」し、「チームでつくる」ことの重要性が提示され、アジャイル開発をひとつ上のレベルに押し上げていく。圧巻。

引用：「これからも高まっていくだろう不確実性に適応するためには、役割を中心とした調整によるプロダクトづくりから、問いと向き合い続ける共創によるプロダクトづくりが、 より「ふつうのプロダクト開発」となっていくはずだ。そういうチームが次々と増えていくことを願っている。共に前進しよう。」（p318）

[neetonさんの感想 · 2021年11月3日]

読み物的な側面が強いので万人にはオススメできないけど、正しいものを正しくつくるとはどういうことなのか、つまり正しくないものを作らないことが結果的にそれにつながる、ということが新たな発見として感じられたのでよかった。
正しいもの、正しくないものを見つけるために必要な活動をしていこう、と思った。

[bob-taniさんの感想 · 2021年6月20日]

不確実性の高いプロダクトづくりの方法論の言語化。
アジャイルから組織理論にリーンまで。
開発におけるここ十数年の問題解決手法に対して著者の経験と引用から捉え方を展開。
コンセプトをwhy+howととらえたり、わからないことの定義に地図なしのコンパスから見る仮説検証の考え方など
人に説明する時に役立つ言語化が参考になる。
参考書籍の多さに加えて、著者の思考が読めるので実践に落とし込みやすい。

半年ぶりに読み直したが、やはりよい。
越境と混沌を仮説の番人である視座視野意識のプロダクトオーナーとまとめるとよさそ。

[tomさんの感想 · 2021年6月8日]

目次
・アジャイルとは
・なぜアジャイルが生まれた？
・アジャイルの２つの要素
・クイックに開発するための開発組織
・開発組織の２つの壁
・仮説検証で重要な3つのこと
・多様性と共創

・アジャイルとは？
正しいっぽいプロダクトを小さく素早く走りながら作っていくこと

・なぜ生まれた？
➀課題が複雑で正しいプロダクトがなにかわからなきなってきたから
➁チームの役割も多様になったから

・アジャイル開発の２つの要素
➀クイックに動く開発組織
➁仮説検証

・クイックに開発するための開発組織
クイックに開発するために、
-開発のルール
-開発フロー
-スプリント(なに作る)
-機能ゴール
-定期的な開発フロー/組織KPT
の設定、実行が必要

・開発組織の２つの壁
➀アジャイル形式を実践できない
これは実践知になるまでPDCA回すのみ

➁開発側とプロダクトオーナーの言語の壁
これはBiz側がんばろう、あと専門用語ダメ

・仮説検証で大切な3つのこと
➀基準/組織・事業・プロダクトの目的設定/共有
➁正しくないこと(やらないこと)の設定/共有
③目的→機能→手段の順番での検証
(コード書く前に声聞いてPDCA回せ)

・多様性と共創
多様なメンバーの力で、多様な視点(上下、左右)から、問いに向き合う。

ユーザーをも巻き込んで、共創していく。

[90997さんの感想 · 2021年5月5日]

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

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

[honjobeiさんの感想 · 2021年4月13日]

近年、ちまたにあふれているデザイン思考本より、よっぽど分かりやすい。アジャイル解説本であるが、より良いモノをつくりたい。という思い、考え方は、デザイン思考とベクトルは同じ。必要なマインドも同じ。というのが、よくわかる。

[quwajiさんの感想 · 2020年12月28日]

正しいものには行きつかずとも、わかったものを正しく作る。分かるに行きつくことに、もっと向き合わねばと思った。

[standarrowさんの感想 · 2020年4月25日]

0→1段階のプロダクト開発における企画、仮設検証、チームビルディングの方法論や考え方がじっくりと書かれている書籍だと感じました。

著者プロフィール

株式会社レッドジャーニー 代表。サービスや事業についてのアイデア段階の構想からコンセプトを練り上げていく仮説検証とアジャイルについて経験が厚い。株式会社リコー CDIO付DXエグゼクティブ、政府CIO補佐官も務めた。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、自らの会社を立ち上げる。株式会社リコー CDIO付きDXエグゼクティブ。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。著書に『カイゼン・ジャーニー』『チーム・ジャーニー』『デジタルトランスフォーメーション・ジャーニー』（翔泳社）、『正しいものを正しくつくる』『組織を芯からアジャイルにする』（BNN新社）、『いちばんやさしいアジャイル開発の教本』（インプレス、共著）、訳書に『リーン開発の現場』（オーム社）がある。

「2023年 『これまでの仕事 これからの仕事　～たった1人から現実を変えていくアジャイルという方法』 で使われていた紹介文から引用しています。」