私は、もともとがCOBOLで汎用機の事務処理システムを
開発するSE(システムエンジニア)でした。
システムを導入する会社を訪問して、
どんなシステムにするのか取材して
その内容をもとにシステムを開発します。
かなり几帳面でしたので、
「こんなシステムが欲しい」という取材内容を
毎回しっかり議事録にしました。
重要なポイントでは、確認印をもらったこともあります。
しっかり聞いた、ちゃんとまとめた、
それに沿ってシステムを設計した...
でも、システムが完成して導入のテストをすると
「違う!」と言われます。
私は、議事録を広げて
「ここで、こう確認しました」と言います。
顧客 「そこは、そういう意味じゃないんだよ」
池田 「でも、具体例ではこうです」
顧客 「これは、そうだけど..」
池田 「確認印もありますよね」
顧客 「でも、修正してもらわないと使えない」
池田 「...」
と言うような会話になります。
ここで、発見したことが今の図解につながってきました。
発見したこととは
「口で言っていることと、望んでいることが違う」
です。
この発見から、聞いているだけではダメだ!
そう思うようになりました。
良く言われる傾聴も大切ですが、
顧客の気がついていない「システムへの要求」を
尋ねて引出すことが必要です。
この尋ねるために使ったのが
・比べる
・並べる
・組立てる
この3つです。
試行錯誤で質問を考えながら
この3つに辿り着きました。
「比べる」は
・AさんとBさんで違いますが、どちらが正しいですか?
・Aと言われますが、Bの条件は考えられませんか?
「並べる」は
・A→B→Cとのことですが、途中に「E」が抜けていませんか?
・Cの次に「D」はきませんか?
「組立てる」は
・この要素が抜けていませんか?
・ここに、これが入るのは無理がありませんか?
と言うような、質問をしていきます。
「3つの型」を意識していると
・不足している部分が見えてきます
・間違いが発見できます
そこを、聞いて埋めたり修正すれば良いんです。
簡単な図解にして、お互いに確認すると
そこから内容を深めることもできました。
そして、一番良かったことが
自分の頭の中に開発のパターンが蓄積されたことです。
たとえば..
顧客が、「Aです」と言うことがあります。
でも私は、この展開では「B」になると確信しています。
そこで、「ホントにAで、良いですか?」と念を押し、
確認書を作成して確認印をもらいます。
設計では、AでもBでも対応できるようにします。
設定値を変えれば、プログラム変更なしで
動くようにします。
そして、システムの導入テストです。
もちろん、問題がおきます。
顧客 「Aじゃない、Bと言って無かっけ?」
池田 「何度もAですかと確認しましたよね!」
顧客 「確かに、印も押してる」
池田 「今の工程で、Bへの変更は重大です」
でも、ここで争うことが目的ではありません。
システムを変更しないと動かないので、
やりるしかありません。
でも、ここで変更の大変さを訴えます。
そして、ここでは泣きますが、
これ以上の変更があれば
追加見積もりをさせてもらいます。
と、念を押すことです。
システムって動かして分かることがあるので、
小さな変更などが必ずあります。
そこは、小さくても追加見積もりをします。
受容れ易い関係ができているので
話が早いです。
これができたのが、体験を構造化して
頭にいれておいたからです。
どんな現場にも、個人の頭の中には「知恵」があります。
それを社内で共有することで
仕事の効率も価値を上がります。
図解で、ノウハウとして社内に蓄積しましょう!