最近は計画に時間をかけて立てても、外部環境の変化が速すぎて、計画を行うことに対する価値は以前よりも下がっている気はします。計画に時間をかけすぎるくらいなら始めてみるというスタンスについては、個人的には概ね同意します。
ただ、あまり考えずにとりあえずやってみるというのは、あまり良い行動とは言えないケースもあるでしょう。下手な鉄砲も数撃ちゃ当たるというのは、その通りなんですが、鉄砲ばかり打って運任せというのは、さすがになぁとは感じます。
まず、鉄砲を打つにしても、そのコストを考えるべきです。コストというのは主に金銭的な観点と、時間的な観点が挙げられます。金銭的にも時間的にもコストが低ければ、どんどん試すでよいのですが、コストが高くなりそうなら一度立ち止まるべきでしょう。まずは、ここら辺の見極めをすることは心がけるべきと考えています。
じゃあ、コストが高くてもやってみるという場合、どうプランニングすればよいか。取り組むことが、課題自体の検証なのか、方法の検証なのかというのを切り分けるのが、極めて重要な気はします。例えばPoCとかやっても方法の検証に寄りがちな面はあるのですが、実は課題自体があまり深掘りされてなく、なんかうやむやになるケースはある気はします。取り組むべき課題については、以下の記事で書かれてるように、
「価値」の質は、それによって解決するターゲットの「課題」の質が前提にあるものともいえると思いますが、「課題」の質とはターゲットにとってお金を払うに値する、解決し甲斐のある課題になっているかという点が重要
コストをかけるに値するものかという視点が、大事になってくると思います。
開発の要件定義においても、この視点は大事かなと考えています。仕様を決めるにあたって、とりあえずこれでいくかというケースはあるとは思います。しかし、それが繰り返されると、何を狙いに作ってるかやはり分からなっていく気はします。
もちろん、何が仕様として正解か分からないという時はあるでしょう。そういう時は、どういう課題を解決しにいくのか、より慎重に検討すべきとは思います。
例えばアジャイル開発においては、要件がざっくりな傾向があるように感じられますが、以下の記事にあるような、
現場や市場の状況に応じて、何かを探求していく姿勢
が欠けていると、いかにプラクティスを実践しようが、アジャイル開発に取り組む効果がほぼ得られない気はします。だから、アジャイル開発を導入する際は、こういったマインドをいかにメンバー間で共有するかは、個別の手法論よりもはるかに重要と私は考えています。
