バッチサイズを小さくすることが大事。まとめて全部やらない。製造業によくある「一個流し」をする。短いサイクルでフィードバックを得る。一度に作れる量は少ないので、大事な要求から順番に実装する。今何が大事で、何をやるべきなのか、ビジネス側が優先判断をし続ける。優先判断をまとめてやるのはビジネス側の責任をこなしてない。頻繁にサイクルを回す→アジャイル開発。頻繁にサイクルを回すリリースの方法→CI/CD。CI/CDの前にやらなくてはいけないこと。漏れがあるまま早いサイクルで回すと問題も早いサイクルで発生する。大事なのは漏れがあるまま急がない。ビジネスサイドが練られていない要求を開発に渡してもゴミになる。ダメな要求を開発側が常に確認し続けて時間が無駄になる。品質が悪いと後で修正するリソースが必要になる。ビジネス側は開発チームの能力を超えるプレッシャーをかけてはいけない。品質の確保が重要プロダクトやシステムによって求められる品質は異なる。大事なのは不良を次のプロセスに渡さない。自分にとって十分ではなく、相手にとって十分なものを引き渡す。プロセスの逆流が発生すればするほど遅くなる。一気に変更すると混乱する。逆流率が高ければ高いほど、いつ終わるのか予測がし辛くなる。ビジネスサイドでは予測ができないのが一番辛い。不良率の高い工程があると、全体の速度に影響を与える。不良率の高い箇所を修正する。それがどこなのかはプロジェクトによって違う、まずはそれを明らかにする。開発チームだけが問題だとは限らない。ビジネス側に問題がある場合もある。見えないものは改善できない。バリューストリームマッピング。色んな現場で試しているが、思っている以上に人によってプロセスに対する理解が違う。利益を得るための流れや他の部門が何をしているのかがわかる。データで共通理解を持つ。大事なのはいきなり全部データをとるのではなく、仮説を検証するためのメトリクスを取ること。不要な項目のデータをとるのは無駄。データは全員が見えるようにしないといけない。データがあると議論の空中戦を避けられる。事実としての問題を掴み、仮説を立てて、対策の仮説を立てて、ソリューションを適用し、また検証する。