問いに答える時間、問いをつくる時間

making

本当のところ、どのくらい目的に叶ったプロダクトをその適したやり方でつくれているのか?目的に叶っていない、間違ったものを間違ったやり方でつくり続けていないか。あるいは、やり方は正しくとも、つくっているものが間違ったものでしかないならば、目的にそえることは無い。正しいものとは何か、正しくつくるとはどういうことか、私たちは問い続けなければならない。そう、ソフトウェア開発には正解がない。あるのは問いだけだ。


自分の日常を振り返ってみて、問いに答える時間(これはこれこれこういうやり方でつくるべきだ)と、問いをつくり設定する時間(何をつくるべきか、この場合どうつくるべきなのか)とを比べてみて欲しい。問いに答える時間しかない、問いを生んでいる時間の方が極端に少ない場合、もしかしたら何かの枠組みに囚われているかもしれない。枠組みの中にいる間は、問いは既に存在している。例えば「アジャイル開発を現場で始めるには」という。

守破離で書いたとおり、守を身につけていないと話にならない。守を身につけようとするだけで、スタートラインによっては実に力になる。その次の段階では、様々な問いを設定し、自分で答えていくようにしなければならない。その問いの中身は、How(どうやるのか、始めるのか)から、Why(なぜ、どうしてやるのか)へと移る。なぜ、アジャイル開発なのか。枠組みの一歩外に出ようとした途端に、問いの広がりは広大となる。

自分の役割の向こう側には、別の役割があり、自分とは異なる問いに答えようとする人がいたりする。例えば、開発チームにとってのプロダクトオーナーだったり。ソフトウェア開発の良いところは、問いを共有できるところだ。一人ではなく、チームで答えることができる。お互いの抱えている問いを知るためには、枠組みだったり、役割を超えていくことが必要になる。

越境することは骨が折れるが難しいことではない。自分たちの目的が本当に果たせるのかと問い直すことで一歩外側に目を向けられる。歩を進めるのは、問いなのだ。

eye catch photo via Visual Hunt