【読書メモ】PROJECT TO PRODUCT フローフレームワークでデジタルディスラプション時代に成功する方法
期間を定めたプロジェクトではなく、プロダクト開発を勧める一冊。BMWを事例として取り上げながら、ソフトウェア開発に必要なアイデアを紹介している。
概要と感想
気になった部分をいくつかピックアップしながら、感想をまとめたいと思う。
第２章
教訓1 局所最適の落とし穴を避けるには、エンドツーエンドのバリューストリームに注目すること
教訓3 エンジニアリング、ITとビジネスは繋がっていなければならない
ITツールや業務改善を進めようとすると、短期的にある作業・業務を効率化することで効果を確認したくなってしまう。これ自体が悪いわけではないが、全体最適の視点を忘れてしまい、全体としてはあまり改善できていないことがよくあるが、その点はあまり考慮されることは少ない。「ザ・ゴール」で有名な制約理論にも通づるところもあり、ボトルネックを解消しない限り個別を最適化しても効果が少ないことを改めて、実感できた。
これらを改善して行くための測定項目は3章以降に記載されている。具体的には、「フローベロシティ」「フロー効率」「フロータイム」「フロー負荷」の４つが重要な指標としていた。生産性や品質などの測定指標は数多挙げられるが「フロー」に着目した指標はそこまで多くはないと思う。教訓1に挙げられていたエンドツーエンドを意識して、全体の流れ(フロー)を止めずに、効率的に流して行くことを意識していると感じた。多くの人や組織が連続して作業を進めて行く場合、自分達の責任所掌を限りなく改善することは意識されるが、チーム間・組織間の間には作業が停滞する待ち時間が発生しがちである。詳しくは4章のリードタイムとサイクルタイムに記載されているが、この点を意識するだけで、顧客から見えるリードタイムは大きく改善されることは体感とも一致する。
技術的な視点では、ツールネットワークを繋げて行くことは意識しておきたい。JIRAやServicenowなど運用管理ツールは無数にあるが、それぞれのツールが生まれた背景から、JIRAはアジャイル開発、ServicenowはITSM領域といった強みがあり、そこを中心に発展してきている。利用部門はそれらの強みに惹かれて使い始めているので、これらを連動するような視点は重要であると感じた。これを実現するためには、相互のデータが連動できるようなマスタ管理やID管理の仕組みを具備した環境が必要だと感じた。
いずれも短期的にできるものばかりではないが、プロダクト開発のロードマップやアーキテクチャビジョンの中に組み入れ、徐々に実現して行くことが企業変革の一歩になると感じた一冊でした。
次にやること
コスト削減だけでなく、バリューフロー全体に着目した視点で見直す
プロセス間の「待ち時間」がないか着目する
こんな人におすすめ
プロダクト開発に取り組みたい/取り組んでいる方
大規模アジャイル（SAFe）に取り組みたい/取り組んでいる方
関連メモ
Mik Kerstenさんの動画を探したところ、OKRの動画がわかりやすかったです。Value Streamから適切なOKRになるように工夫したいものです。フルバージョンは、Youtubeで見れないようなので、時間がある時にアカウント登録して見てみようと思います。
この記事が気に入ったらサポートをしてみませんか？