オルタナティブ・ブログ > 椎野磨美の観察日記 ~感性と審美眼を磨こう~ >

組織開発・人財開発・IT・ビジネスについて、日々、感じたことをつづります。

その議論、前提条件が同じですか?【ウォーターフォール vs アジャイルという二項対立で考える落とし穴】

»

ITメディアでブログを書き始めて、2年が経過し、今月から3年目に入ります。
3年目のスタートは、先日、SNSに投稿したところ、「Cannot agree moreです!」「全く同感です」と言うコメントをいただいたことについて、別の観点からの考察も加えて書きたいと思います。

■二項対立で考える習慣の罠

ウォーターフォールが上手くできる人は、アジャイルも上手くできる。

ウォーターフォールが上手くできない人は、アジャイルも上手くできない。

上手くいかない理由は、単純に手法の問題ではないのですが、手法だけ変えれば全てが解決する、まるで銀の玉のように思われている場面に遭遇することがあります。

盲信的にウォーターフォールがNGで、アジャイルがGoodと言っている方々の話を見聞きしていると、前提条件が異なるにも関わらず、ある側面だけを捉え、二項対立であつかうことで、アジャイルの方がGoodと言っているように感じることがあります。

そして、これは、ウォーターフォール vs アジャイル議論に限ったことではありません。手法やモノが比較される際、前提条件と判断基準として何を優先するかが明確にされないまま、お互いの主義主張だけで、二項対立の議論がおきている場面に遭遇することがあります。

前提条件が異なる二項対立の議論は、ムダな議論の時間、誤解やミスによる後戻りなど、多くのムダをつくりだします。また、多くのムダだけでなく、その議論に関わる人達の関係性を悪化させる原因にもなっています。

前提条件を確認せず、二項対立で考えてしまう習慣によって、無意識のうちにある一側面で判断し、うまくいかなければ、もう片方の「手法」や「モノ」だけ変えれば、うまくいくという誤解が生じてしまっているように思います。

■前提条件と判断基準を確認・整理する習慣

議論が平行線のまま、解決しない場に、モノゴトを整理する人として投入される時、私が、最初におこなうことは「前提条件」と「判断基準の優先順位」の確認と整理です。前提条件とは、ある物事が成り立つために、あらかじめ満たされていなければならない条件のことですから、お互いの前提条件の認識が異なっていると、いつまで経っても議論は平行線のままです。

自動車の購入を例に説明します。購入する車種を決める時、メーカー、機能、金額、デザイン、色など、購入時に検討する、さまざまな判断基準があります。もし、顧客の前提条件に「現在の駐車場に入る」という条件があったにも関わらず、前提条件を確認せずに検討すると、購入したい車種が大きくて、前提条件を満たさないということが発生します。

その場合、前提条件を優先し、別の車種を選択するのか、それとも、元々は前提条件であった「現在の駐車場に入る」を前提条件から外し、新しい駐車場を探すことによって、希望の車種を購入するのかによって、結果は異なります。

意外なことかもしれませんが、前提条件は、「言わなくても分かっているだろう」と、暗黙の了解として議論されていることが多く、前提条件を確認すると、まず、前提条件の認識が異なっていたということが少なくありません。そして、議論を継続しているうちに、元々は前提条件であったことが、頭の中だけで、前提条件から外されていたり、変更されていたりすることもあります。

自動車の購入のように、具体的な判断基準や前提条件の確認項目が分かり易ければ、それほど難しいことではありませんが、前提条件に納車期限やその他の条件が増えた場合、前提条件と判断基準を明確にしておかなければ、なかなかモノゴトが決まりません。

話を戻すと、ウォーターフォール vs アジャイル議論も、どちらか一方がNGで、どちらか一方がGoodということではありません。前提条件として、何を優先するかによって、どちらの手法を使うとBetterかという話です。

ところが、ある側面だけを捉えた二項対立の議論がおこなわれることで、盲信的に、どちらか一方がGoodという風潮が広がってしまい、別の側面が議論されず、見落とされるケースが増えているように感じています。

急激な社会変化に伴い、さまざまなルールやアプリが発表されるたびに「〇〇の観点や⭐︎⭐︎の観点で、後から問題が出そうだな」と感じることがあります。そして、残念ながら、予測どおり、問題の多くは、確実に発生しています。

システムやアプリケーションを設計する際、さまざまな例外系を想定できるかどうかは、ウォーターフォールであろうとアジャイルであろうと必要なことであり、手法には依存しません。ところが、変化の激しいビジネスニーズに迅速に対応するには「アジャイル開発」という一側面ばかりが重要視されるあまり、多くの観点が議論されず、例外系が見落とされたままリリースされるケースが増えていると感じています。

同じ施策に対応するWebサイトやアプリケーションであっても、問題が起きないように作られている(例外的なユースケースが最初から想定して対応できている)ところと、問題が起きるであろうところがあります。当然のことながら、後者は、例外発生により、例外対応や改修によって多くの追加工数を費やすことになります。

■モノゴトの変化には理由がある。歴史を体系的に学ぶことの意味

VUCA時代に必要とされる能力の1つに「予測不可能な事態を想定して変化を受け入れる能力」があります。この能力を磨くためには、私は、歴史を体系的に学ぶことが重要だと考えています。

歴史を体系的に学ぶことで、モノゴトの変化を学ぶことができます。OSの進化だったり、製品の進化だったり、ITの進化だったり、細かい機能の差ではなく、どのような経緯でそのような変化がおきたのかという、変化の背景を知ることが大事です。
それは、過去に起きたことを学ぶことで、予測できる問題を避け、問題対応にかかる時間だったり、人が感じる不快感だったり、いろいろなムダを減らすことができるからです。

2020年11月1日 箱根仙石原にて

Comment(0)