長年システム開発の仕事に携わってきた(エンジニアと企画担当の両方)が、人々が最も心にダメージを食らうのは「認識違いが起きて急遽設計をやり直さないといけない時」である。

開発が佳境に差し掛かった時にこれが発生すると、「うう・・・」と声なき声を上げ、しばらく放心状態になったりする。

作り手であるエンジニアも、彼らに方針を指し示す企画側も同じように辛い気持ちになる。何度も経験していると面の皮が厚くなって「次に起こすべきアクションは」なんて考えられるが、来たばかりの人はショックも大きいはずだ。

悲しいことに目に見えない抽象的な存在であるプログラムというのは、認識違いが極めて起きやすい。どんなに小さなプロジェクトでも、細かなズレや認識違いは潜んでいるものなのだ。

そして、システム開発関連の裁判はほとんどがこの認識違いを起点に行なわれる。

で、昔ながらのウォーターフォール型開発は、「認識違いが起きた時にエンジニア側は最大限の努力でもって要望される要件を達成しなくてはならない」という不文律があった。

もちろん実際にはクライアント側に「ここは我慢してください」ということはある。しかし、まず出発点は「いかにして創意工夫をして要望を叶えるか」だった。

出発点がどこから始まるかは、交渉ごとにおいてゲームのルールを左右するほどの重大事である。

では、アジャイル開発はどうか。ここではプロジェクトの進行と共に使われてゆく工数がより明確に可視化される。

そのため、認識違いが起きた時には　「クライアント側でどこまで妥協できるか」も選択肢としてフラットに論じやすくなる。「知っての通り残りの工数はこれだけしかありません。そのため、修正しようにも何かを引き換えにしないとできません」という話がしやすくなるのだ。

前から要望していた機能を削ってでも認識ギャップのあった機能を修正するのか。あるいは思い切って修正しないままリリースするのか。「柔軟に修正できる」というのは、「修正せずに妥協する」という選択肢をもたらすのである。

「アジャイルは柔軟な修正ができる開発手法」というのは実のところ一側面しか見ていない。この手法はこれまで裏側で抱えてきたエンジニアの苦労を白日のもとに晒すのである。

クライアント側はこれまでエンジニアに丸投げしてきた「限られた資源の中でやりくりする苦労」を、一緒になって頭を悩ませなくてはいけないのだ。

個人的にはこれは歓迎すべき流れだと思う。コスト感覚が磨かれるし、技術的な制約を自分ごととして理解しようという動機にもなる。

ビジネスマンとしての深みは、「葛藤をどれだけ乗り越えてきたか」で決まると思っている私からすると、絶好の成長機会だ。

これからシステム開発に携わろうとしている方たちには、是非ともアジャイル開発の裏も表も味わい尽くして、深みのある人材になってほしい。