ソフトウェア開発に限らないと思うけど、結局「人間」も「チーム」も「プロダクト」も性質は十人十色なので「これさえパクれば開発速度10倍！利益10倍！顧客満足度1000%！」というものはありません、という前提がある気がする。
大学でCSの学位を取ったとしても、本を沢山読んだとしても、資格をとったとしても、この次働くチームで全てが最高に上手く回るとは限らない。以前いたチームでのプラクティスが全てそのまま当てはまるわけではない。じゃあなんで世の中で流行っているフレームワークやプラクティスがあるかというとそれはあくまで70点、80点を取りたいときに適しているというだけであって、100点を取るには正解は自分たちで見つけないといけないということ。
「人間」は様々な性格があるし、モチベーションの有無とか、スキルの有無とか、経験の有無とか、いろいろある。なので仮に自分に後輩ができたときに「こうすれば100%後輩はすくすく育つ」と言い切れるようなことはないはず。同じことがチームでのプロダクトの開発でも言える。5人とか10人いるチームで効果的にソフトウェアを開発しユーザが喜ぶ機能を高速に提供するにはどうするべきか。スクラムってフレームワークを使うと"高速"になるのか？そうとは限らないけどイテレーションを回して短いスパンでフィードバックがもらえるなら早い段階で方針を変えることができていいかもしれない。そもそもこのプロダクトの"価値"ってなんだろう？ユーザは何を求めているのだろう？我々は何がしたいんだろう？正解はわからないけどインセプションデッキってフォーマットを使ってみてはどう？みたいな。
前提がないままにトップダウンで「◯◯が巷で流行ってるらしいからこれやってよろしく」という風に言われて"ただやるだけ"になるとイマイチそう。これが「銀の弾丸などない」ってやつですかね。現状が10点であれば俯瞰してどこが改善できそうかを分析して世の中に存在する近い事例を取り入れて改善してみるのはやると良さそう。だが90点、100点を目指したい場合は最終的にはチームメンバー同士やユーザとの対話が必須になる。だってソフトウェアを開発しているのも利用しているのも人間だから。
