英語×IT×仕事

何でも依頼どおり対応することがベストな対応というわけではない、と気づいた日のこと

こんにちは、にわです。

最近、ビジネス系YouTuberと呼ばれている方々数名をTwitterでフォローするようになり、数年前の気づきをふと思い出しました。



ビジネス系YouTuber

「ビジネス系YouTuber」というカテゴリすら知らなかったのですが、何かのきっかけで1名フォローしてみたら、その人がリツイートしている、つぶやき元の方のツイートも興味深くて、芋づる式に3,4名ほどフォロー対象が増えてしまいました。

この方たちのツイートを拝見していると、どうもみなさん「ビジネス系YouTuber」と呼ばれる方々のようです。

YouTubeはバックグラウンド再生ができないので、スマートフォンでは視聴しづらく、家にいるときは、今は基本的に息子に時間を捧げているので、PCやタブレットでじっくり視聴、ということができないでいます。

そのため、私が見るのはもっぱら、隙間時間や移動時間が活用できるツイートかブログかの活字情報(そして音声メディアを少々)ですが、最近はすっかりTwitterから情報収集するのがおもしろくなってきています。

つぶやいている方々にとっては、何気ないであろうつぶやきが、自分にはなかなかためになり、ふと過去の自分の失敗と学びを思い出したので、本日のブログに書いてみたいと思います。

当時の私と同じように、初めてプロジェクトを担当する、というような、普段プロジェクトとはかかわりがない方々に、私の失敗談が参考になるとうれしいです。



依頼は絶対に対応しなければならないのか?

自社のIT部門で働いている私にとって、「顧客」は社内ユーザや同じ部門の他チームのエンジニアたち、ということになるのですが、入社したころは、チームの文化的に、依頼にはすべからく対応すべき、というような空気がありました。

もちろん、ルールなどにより対応できないことはルールに基づきお断りするのですが、技術的にできるのにその時点で対応していないだけのことや、とくによいとも悪いともルールがなく対応していないだけのことだった場合、断ると、なぜ断ったのか?と断ることのほうが問題視される環境だったように思います。

今の職場に転職してくる前は、もっと若かったからか、契約で働いていた時期が長かったからか、「顧客」から自分に直接依頼が来ることはそうそうなく、上司や先輩社員を経由して、「指示」として依頼の対応をしていたため、対応の要否について考える、ということはなかったように思います。



私の失敗体験

数年前に、とあるグローバルプロジェクトに、日本チームの代表として関わらせてもらう機会がありました。本社ですでに導入しているシステムを、ヨーロッパや日本にも導入するというプロジェクトでした。

単なるシステムの新規導入というわけではなく、このシステムが本来的にもっている概念みたいなものを認識している日本のメンバは、当時の職場にはほとんどいなかったため、概念を理解してもらうことからスタートしなくてはなりませんでした。

そしてこの概念は、当時の職場のやり方とは真逆というか、理解を得ることは非常に難しかったです。現行のシステムやプロセス、運用も大きく変更になることもあり、みなさんの不安や不満をヒシヒシと感じるプロジェクトでした…。

そんなこともあり、「こういうことはできないのか?」とか「ここはこうしてほしい。」とか言った質問や要望が来るたびに、グローバルの担当者に確認や依頼を行い、如何に要望に応えるか?ばかり当初は考えてしまっていました。

システム的に対応できないわけがなかろうという照会に関しては、「できると思うので依頼してみます。」と依頼者の機嫌を損ねないような回答をしてしまっていました。

しかし、グローバルチームの担当者からはあまりよい返事が来ることはなく、システム的にできないわけがないのに、何で対応してくれないのか?と少々苛立ちを覚えていました。

が、しばらくして、苛立っている自分のほうが誤りだったことに気がつくことになります。



どのくらいの人数の人たちがその対応を望んでいるのか?

自分の誤りに気がついたのは、とある人の依頼で、とある機能を追加してもらったものの、実際にはあまりその機能が使用されている形跡がなかったことからでした。正確には、自分で気がついたわけではなく、グローバルチームの担当者からの指摘で、はっとさせられました。

その機能追加について、最初の依頼は、グローバルチームの担当者はすんなり対応してくれたのですが、さらに、細かい機能追加の依頼がきたために、再度グローバルチームの担当者に依頼したところ、「その機能は本当に必要なのか?」と質問されました。

私は依頼元から聞かされていた理由を返答したのですが、グローバルの担当者はさらに聞いてきます。

「その機能は本当にグローバルチーム全員にとって必要な機能なのか?」
「一部の限られたユーザしか必要としないような機能は追加できない。」
「最初の依頼はほかの利用者にとっても有用だと考えたから対応したが、追加の依頼は利用者全員にとって必要とは思えない。」
「利用者全員にとって必要な機能か否かを考えて依頼をしてくれ。」

そう言われて考えてみると、それほど必要な機能には私には思えなかったので「技術的には可能だが対応しない」という返答を初めて依頼元にしました。もちろん、なぜ対応できないのかについても説明をしました。

しかし依頼元は私の返答を聞いて不機嫌になってしまい、依頼元の反応によって私も少々気持ちが落ち込んでしまいましたが、その後、その機能はほとんど使用されていないことがわかり、落ち込んでいた気持ちはすっかり回復しました。

依頼元のユーザすら、ほとんど使っていなかったのです。追加機能の対応をしなかったために使われなかった、というわけでもなく、この機能の存在自体を早々に忘れてしまったようでした。

システム化すべきか運用回避すべきか

私はシステム開発の上流工程で働いたことがないため、こういう考えをしたことがなかったのですが、どうやらユーザというものは、システム化できることであれば何でもシステム化してほしいと依頼してくるようである、とうことに、プロジェクト半ばで気がつきました。

当初は、システムの変更でみなさんに不便な思いをさせてはなるまい、とがんばって要望に応えようという一心だったのですが、グローバルの担当者に、「そこをシステム化してしまうと、こういう変更が発生した時に、ここも変更しなくてはならないし、ここも変更しなくてはならない。」とか「そこをシステム化してしまうと、こういう対応ができなくなる。」とか「ここまでは日本もほかの国も同じだから、システム化するのはここまでにして、ここから先は運用で回避したほうがいいのでは。」というような指摘を多々受けました。

「これは対応してくれてもいいだろう!」ということも対応してくれない、ということも多々あったものの、上述のような指摘はもっともであり、私には新しい学びでした。

システム開発の上流工程で働く人たちは、日々こういうことを考えているのだなあと感心しました。

学んだこと

このプロジェクトからはいろいろと学ばされたのですが、依頼への対応という点において学んだことをまとめます。今、私は依頼を受けるとき、以下の点に気をつけています。

  • その依頼は多くの利用者にとって意味があるのか?
  • その依頼に工数やコストをかけることをステークホルダーは了承しているのか?
  • 組織やステークホルダーとの調整なく、いちユーザが自分がほしいだけの要望をしていないか?
  • その依頼は、運用やプロセスで解決すべきものではなく、システム化することが最適なのか?
  • システム化したことが稼働後に運用やプロセスの足を引っ張ることにならないか?
  • ユーザに過度の期待をもたせない。断るべきことはきっぱり断る。

以上です。



2020年8月吉日





-英語×IT×仕事
-

© 2024 雨の朝の庭