このタイトルは、先日読んだ「プログラマが知るべき97のこと 」の74番目に登場します。
そこには、下記のようなことが書かれています。
私はテクニカルリーダーという立場になったばかりの頃、自分の役目は、プロダクトマネージャやビジネスアナリストから来るバカげた要求をはねつけ、自分たちのチームの素晴らしソフトウェアを守ることだけと思っていました。何か要求が来た時には、それを「受け入れるべきもの」ではなく、常に「却下するもの」と捉え、その前提でほとんどの会話を始めていたのです。 （略） 「イエス」から始めるようにする、という簡単な変化だけで、私の仕事への取り組み方は劇的に変わりました。わかったのは「イエス」という返事の仕方にも多くの種類があるということです。
こういったことを思い当たる人、または周りにいるって人は多いのではないでしょうか。
IT部門に勤めていると、絶えず顧客からの要求にさらされます。
その中には、聞くに堪えないものも数多くあり、一通りの話を終える前にその話を握りつぶすかのように反論を始めたりもします。
しかし、そんな話の中にでもユーザーは目的を持って話しており、論点がずれていたりはするものの確かに解決すべき課題というのが見えてくることも多々あります。
「ノー」と答えて行き場を失ったユーザー要求
立場の違いから、言われたことは受け入れざるを得ないというエンジニアも数多くいると思います。
そういった人から見れば、要求に「イエス」ということへのリスクというもの強く認識しているでしょう。
要求を受け入れることで面倒な仕事は増えるは、何らかの変化をもたらすことで実行リスクが大きくなるは、スケジュールがタイトな中でリソースは不足するは、丸投げされるは、とネガティブな要素しか考えられなくなってしまったりもします。
過去に一度痛い経験をしてしまうと、もう二度と簡単に「イエス」なんて言うもんかという態度も取りがちです。
そんな経験があるかないかはわかりませんが、まずは「ノー」と突き放す人は自分たちの領域を守ろうとえらく保守的になってしまっていたりもします。
「ノー」という答えの中には、「それは自分たちの仕事ではない」という意味が含まれていることがあります。
しかし、自分たちがノーと突き放したその要求は誰が解決するのでしょうか。
確かに、しかるべきところがまずは要件を固めるべきという問題もあります。
システム化の施策の中で解決を図ろうにも、IT部門で考える前にその業務であったりルールであったりを整備する担当部門というものの存在があり、そっちで検討してきてから話しましょうね、というような意味合いでノーと答える人もいるのでしょう。
「ノー」という人の中には、ノーといった理由を示さないでただ拒否する人や、たいしたリスクではないのだけど、さも致命的であるかのように拡大解釈して理由を付けるという人もいます。
「客先で資料を参照したいのですが」と聞かれれば「セキュリティの関係でそれは無理です」と答え、「じゃあオンラインストレージでファイル転送とか出来ませんか？」と聞かれれば「予算がありません。おたくの部門で費用を持ってもらえるんですか？」ってな具合で、押し問答を繰り返したり。
頭ごなしに「ノー」と言ってしまうとそのユーザーの要求は行き場を失い、ただただその人の心のうちで消滅するしかなくなってしまいます。
それが本当に会社にとって解決すべき重要な要求や課題であったとしても。
情報システム部門の役割は、自社の業務ドメインを認識し、そこでの問題や変化に対してITを投入して管理していくというものがあるでしょうが、自分たちの領域を守ろうとするあまり、そこに踏み入る勇気を失っていたりもします。
ITのプロ集団であるはずなのに、ITによる解決案さえも出さないのは悲しいことではありますが。
「ノー」では始まらず「イエス」では始まること
ノーと答えることで「情報システム部門がノーと言ったのでダメになった」という変な軋轢も生まれます。
まぁ、イエスと答えると、「じゃあ、後は情報システム部門でよろしく」と丸投げされたりもするので、それはそれでユーザー部門への疑心が募る結果となり、そのバランスの取り方も難しい場合がありますが。
一昔前では、システムは魔法のように思われていたのかもしれません。
そして、餅は餅屋にのように魔法は魔法使いにと情報システム部門に頼っておけばどうにかなるという考えの人も多かったのでしょう。
現在では、ITサービスはコモディティ化しており、魔法使いとしての威厳や持ち味も失われつつあります。
その過去にいいように扱われた苦い経験からか、ユーザー部門と情報システム部門との信頼関係も失われつつあるように思えます。
「イエス」と答えてきた過去があるがその報いが無いからこそ、現在は「ノー」と答えたくなるのかもしれません。
または、「イエス」と答えるだけの力を持ち合わせなくなってしまったということも考えられます。
ただ、それは「イエス」の答え方にもよるもので、きちんと解決すべき課題に対して要求する部門とシステム部門とでどのような体制で取り組んでいくべきかという検討が必要でしょう。
その中には、業務担当部門でしか考えることが出来ないプロセスであったり、解決手法というものが存在します。
お互いがその問題を解決するためにどのように取り組んでいくべきかというのを、双方の役割を明確にしながら進めていけばいいわけで、その一部を担うことに対して「イエス」と答えればいいわけです。
まさに「イエス」にも様々な種類があるということです。
ユーザーの要求というのはいきなりゴールかのように見えて、実際は方向違いでスタートを切っていることも多々あります。
その要求の向こうにある本質的な課題を聞き、別の手段からのアプローチを提供すれば解決する問題かもしれません。
「イエス」から始めれば道は開けますが、「ノー」から始めれば始まりもしません。
「Yes or No」の二極化した答えしかないわけではありません。
その答えはそんなに単純なものではなく、ずっと複雑であり紐解かなくてはならないものでしょう。
それはお互い認識しつつも、双方が自分たちの利益を守るためのカードとしてしか使ってないようであれば本末転倒ではあります。
そのきっかけである「イエス」という回答が望まれるのだと感じます。