わからなければ、話をしよう

2024年10月31日 21:25

コンサルティングを行っていると、お客様から質問を受けます。それに対して回答を当然行うのですが、これがかなり難しいのです。私自身、こういうことを語ることが非常に不得手なもので、まとまりがないかもしれませんが、自戒の念も含めて書いていきます。

伝わるということ

伝わるということは、自分が話したことを正しく相手が理解したということです。ちゃんと話したつもりでも、相手が同じようなことを聞いてくる、話が噛み合わないなと思う瞬間、ありませんか？単に「話した」だけで、相手が正しく理解していないとそれは「伝わった」とはならないのです。伝わったかどうかは、話し手に責任があると思っています。

私が心がけていることは、

略語を使わない
相手が発した言葉を使う
なるべく易しい言葉で説明する
図式化して説明する

等です。しかし、それでも誤解が生じたりするものです。
誤解や齟齬、つまり意見や物事がうまく噛み合わないことは、下記のような条件で発生すると思います。

相手の言語化されていない前提や「常識」がわかっていない
お互いを理解しようとしていない
前提となる基礎力が欠けている
違和感が働いていない

暗黙の了解という魔物

色々なケースが考えられる中、前提や常識が共有されていないのは結構多いのではないかと思います。事の背景や歴史、組織や人的関係などを把握できていないまま、課題に対して解決策を提示しお話をしたとしても、腹落ちしないミーティングになりがちです。
「この会社のシステムであれば当たり前のこと」や、いわゆる「暗黙の了解」であったりという部分は、どうやっても新しく参入した人にはわからないものです。

社内の人間で新入りであれば、ここは誰かに聞くしか方法はありません。萎縮することなく聞きましょう。あとで「今頃何を言っているんだ？」となる方がよっぽどまずいです。
しかし外部から雇われたのシステムインテグレータやコンサルタントなどは、会話や議事の進行を遮って、根掘り葉掘り聞くのは現実的ではありません。お客様との限られた時間を価値のあるものにするには、ある程度は経験に基づく想像でカバーするしかないですし、やんわりと「XXはYYと同じ意味とすると...」みたいな会話で認識を共通化していくのが現実ではないでしょうか。

あらかじめ「質問票」を用意しておき、それを埋めてもらうという方法もよくありますが、残念ながら私は苦手です。質問を受けるのも質問を作るのも...
なぜかというと、やはり「前提や常識」を踏まえて書こうとすると長文になりがちなので、本来伝えないといけない前提や常識がが抜けやすいですし、前提や常識が抜けている場合は想像して書くわけですが、往々にして要領を得ないボタンの掛け違い的な回答になりがちだからです。効率的なやり方ではない事が多いです。

あまり解決策にはならないかもしれませんが、お酒の場とかお菓子タイムみたいなフランクに聞ける環境を作り、ちょっと聞いてもいいですか？みたいな感じで聞き出すのが良いのではないかと思います。（朝9時始業で9時5分にこれをやられたら流石に相手から怒られますので、雰囲気や状況を観察しながら、適切なタイミングで...）

社内での会話の難しさ

IT部門と業務部門の間での会話はもっとひどく、不明点を聞こうにも「あなた、何年この会社で働いているわけ？いまさらそれ？」というような会話で萎縮してしまい、二度と聞けない状態になっている状況もよく目にします。難しいですよね。精神的にも参ってしまいます。

IT部門が業務部門に聞けないとなると、あまり参考にならない過去の資料をあさり、やっぱりわからないとソースコードの解析から想像で設計・実装をしがちです。これは全くの悪手で、苦労して出来上がったとしても業務部門から「コレジャナイ」という辛辣なコメントを受けることになります。
誰も幸せになれない、最悪のシナリオです。

業務部門に聞くことが出来ないような時は、今までお付き合いのしていなかったコンサルタントを利用しましょう。彼らは御社の業務は知らないかもですが、他社での経験があります。その経験をうまくマッピングして聞き出して整理ができるはずです。

そもそも、巷で大流行？なDXことディジタルトランスフォーメーションを考えているのであれば、それは業務部門とIT部門が協業をしないと始まりません。お互いの距離を縮めての会話は常に必要なのです。単にデジタル化をする、ツールを入れるだけではDXは全く成立しません。

多くの企業では、10年前、20年前から使っているシステムがあったりするわけですが、業務のためのシステムであったのがいつの間にか「システムに合わせた業務」になっていませんか？システムが業務をロックしている状態です。この状況では、業務部門に「何をしたい？」とオープン・クエスチョンを出しても、せいぜいUIのデザインの変更程度しか要望は出てこず、業務の効率化を目指した本質的な部分まで到達することは稀です。

先にも書きましたが、仲良くなった上で聞き出すとか、何かをたたき台にして議論をする等のアプローチはいかがでしょうか。業務部門とIT部門がお互いに提案し合うような関係性になることが望ましいと思います。

まとめ

今回は締まらない話になってしまいましたが、いずれにせよ、解決策はお話をするしかない気がしていて、人に聞けば解決する課題はまだまだたくさんあります。
私がお勧めしているルール駆動開発も、ソースコードの解析からはじめるのではなく、業務部門とIT部門との会話から始まる開発手法です。