今の仕事はシステムエンジニア。
今のプロジェクトでは長く働いているので、プログラムの修正などは、
他の会社の人にお願いするケースがある。
遠方の人なので電話でのやり取りがメインになる。
そこでのやりとりで、うまくコーチングの手法を使えればと思う場面がある。
この間、プログラムの修正をお願いした結果、
想定していたより大掛かりな修正になったので、
その修正はいらないという場面があった。
プログラムを修正した側の意見を聞くともっともな話がでるものの、
あまり必要以上に修正するとその影響範囲が広がって、
テスト工数がかさむし、予期せぬ不具合といった、あまりよろしくない結果になる。
なので、依頼する側としては何とかして、
修正範囲を減らしたかったのだが、
結局は、必要のない根拠を自分で調べて、だから必要ないのでやめてくれと依頼するより
他思いつかなかった。
そして、プログラムを修正したらテストがつきものなのだが、
これもまた必要以上に多くのテストをしようとしている。
テストは向こうでテストした結果を送ってくるので、
内容はこちらで確認しなければいけない。
やるにこしたことはないけど、やりすぎても確認する方が大変だし、
だいたいの経験から言って、スケジュールも遅れ気味になるので、
これも減らそうとして、何とか説得をした。
説得はするものの伝えたいことの意図は伝わっていなかったようで、
言われた分だけテストの数が減っているようで、
本当はもっと減らしてよかったのにと、
また、減らしてくれというと、また、そういうのに時間がかかるし、
じゃ、やりたいならやってもらってもという、あきらめというか妥協というか、
そんな心境でOKをだしたりした。
実はここまでのやりとりでも、相当時間を使っていて、お互い消耗した感があった。
どうも私の意図しているところは、充分に伝わっていないようで、
向こうは確かにやる気まんまんで、がんばりますという意気込みがあって、
それは充分にいいことなのだが、必要最低限の労力と影響範囲で
プログラム改修をしていくというのもひとつの考え方でもあって、
その辺りお互いにかみ合わなかったのかもしれない。
向こうにしてみれば、どうして向こうが考えた案が変更させられるのか、
やや心外なところもあるのかもしれない。
どうも話している感じから受け取る印象は、プログラム改修に自信があって、
やりたいようにやらしてくれといった印象がある。
それを、やめてくれといわれたもので、認められなかった感というか、
自尊心を傷つけられた感というか、そういうものがあったのかもしれない。
実際、最初のうちはほいほいと私の依頼を聞いてくれたけど、
後半は、やや渋るというか、私の依頼を断る理由をさがしては質問してくるような
場面もいくつかあった。
その度に私はもっともらしい理由で私の依頼どおりにしてもらったわけでもあったのだが…
まぁ確かにほっておいても、問題にはならなかったかもしれないし、
やりたいようにやってもらってもよかったようにも思えるけど、
その場合、では、必要最低限の影響範囲にとどめたいという私の想いはどこにいくのだろう。
何故、必要最低限の影響範囲かというと話が長くなるので割愛するが、
プログラム修正側と依頼側で、ややかみ合わなかった印象がある。
ここでコーチングの手法が使えたのだろうかと、ふと考えてみたりもした。
この場合、コーチングのやり方だと、たぶん相手のやりたいようにやるが結論なんだろう。
結局私の想いはどこへやらというものかもしれない。
コーチは、誘導してはいけないとも言う。
本当にそうなんだろうか。
その修正でいいと思いますか？
って聞けば、向こうは
いいと思います
っていって終わりかな。
いや、あまり修正しすぎると、思わぬトラブルが起こるかもしれませんが、
その辺りいかがでしょう？
と聞くことはできたかもしれない。
でも、自分の考えた修正案が気に入っている向こうとしては、
その辺りはテストでカバーします。
って答えるだろう。
テスト工数がかかりすぎているように思えますが、もう少し減らせませんか？
と聞けば、
テストは必要だと思いますので、これくらいやらせてください
って答えるだろう。
やらわらかい質問口調でいけば、やる気満々だから、向こうのやりたいやり方以外の
方法はでてこないのだろうと思う。
この場合、相手のメリットになる質問があったのかもしれない。
もう少し修正範囲を減らせれば、楽になると思いませんか？
テストも減らす方法があるように思えるのですが、早く帰りたくないですか？
テスト数が多いと大変でしょう。
そういうのはありかもしれない。
こちらのポリシーを伝えて考えてもらうのもありだったのかもしれない。
こちら側のポリシーは最低限の影響範囲でトラブルを減らすというところにあります。
この考え方って、どう思います？
もう少し付け加えてもいいかもしれない。
といいますのは、いままでの経験上、トラブルが起こると夜中呼び出されて大変だったんです。
次の日も、復旧作業に追われてえらいことになったことがあって…
などというと納得してもらえたかもしれない。
あとになって考えれば、いろいろ思いつくものだ。
パターン的には、
・相手のメリットになる質問をする
・こちらのポリシーを伝えて理解してもらう
かもしれない。
他もでてきそうだから、あとひとつだけ考えよう。
かみ合わなかったことを振り返って考えるに、
私が少し話すぎた
というところが思い当たる。
あれこれ、先読みして話してしまったので、ちょっとよくなかったかもしれない。
これは、こういう意図で質問していると思いますので、こういう懸念点があるということですよね？
という相手の意図をこちらで決めて話を進めていたことを思い出した。
・口数をもう少し減らしてみる
そういった工夫をしてみてもいいかもしれない。
あと、コーチは誘導していいのかという点については、議論の余地がありそうだ。
それは、ケースバイケースかもしれない。
また今度考えてみよう。
今のプロジェクトでは長く働いているので、プログラムの修正などは、
他の会社の人にお願いするケースがある。
遠方の人なので電話でのやり取りがメインになる。
そこでのやりとりで、うまくコーチングの手法を使えればと思う場面がある。
この間、プログラムの修正をお願いした結果、
想定していたより大掛かりな修正になったので、
その修正はいらないという場面があった。
プログラムを修正した側の意見を聞くともっともな話がでるものの、
あまり必要以上に修正するとその影響範囲が広がって、
テスト工数がかさむし、予期せぬ不具合といった、あまりよろしくない結果になる。
なので、依頼する側としては何とかして、
修正範囲を減らしたかったのだが、
結局は、必要のない根拠を自分で調べて、だから必要ないのでやめてくれと依頼するより
他思いつかなかった。
そして、プログラムを修正したらテストがつきものなのだが、
これもまた必要以上に多くのテストをしようとしている。
テストは向こうでテストした結果を送ってくるので、
内容はこちらで確認しなければいけない。
やるにこしたことはないけど、やりすぎても確認する方が大変だし、
だいたいの経験から言って、スケジュールも遅れ気味になるので、
これも減らそうとして、何とか説得をした。
説得はするものの伝えたいことの意図は伝わっていなかったようで、
言われた分だけテストの数が減っているようで、
本当はもっと減らしてよかったのにと、
また、減らしてくれというと、また、そういうのに時間がかかるし、
じゃ、やりたいならやってもらってもという、あきらめというか妥協というか、
そんな心境でOKをだしたりした。
実はここまでのやりとりでも、相当時間を使っていて、お互い消耗した感があった。
どうも私の意図しているところは、充分に伝わっていないようで、
向こうは確かにやる気まんまんで、がんばりますという意気込みがあって、
それは充分にいいことなのだが、必要最低限の労力と影響範囲で
プログラム改修をしていくというのもひとつの考え方でもあって、
その辺りお互いにかみ合わなかったのかもしれない。
向こうにしてみれば、どうして向こうが考えた案が変更させられるのか、
やや心外なところもあるのかもしれない。
どうも話している感じから受け取る印象は、プログラム改修に自信があって、
やりたいようにやらしてくれといった印象がある。
それを、やめてくれといわれたもので、認められなかった感というか、
自尊心を傷つけられた感というか、そういうものがあったのかもしれない。
実際、最初のうちはほいほいと私の依頼を聞いてくれたけど、
後半は、やや渋るというか、私の依頼を断る理由をさがしては質問してくるような
場面もいくつかあった。
その度に私はもっともらしい理由で私の依頼どおりにしてもらったわけでもあったのだが…
まぁ確かにほっておいても、問題にはならなかったかもしれないし、
やりたいようにやってもらってもよかったようにも思えるけど、
その場合、では、必要最低限の影響範囲にとどめたいという私の想いはどこにいくのだろう。
何故、必要最低限の影響範囲かというと話が長くなるので割愛するが、
プログラム修正側と依頼側で、ややかみ合わなかった印象がある。
ここでコーチングの手法が使えたのだろうかと、ふと考えてみたりもした。
この場合、コーチングのやり方だと、たぶん相手のやりたいようにやるが結論なんだろう。
結局私の想いはどこへやらというものかもしれない。
コーチは、誘導してはいけないとも言う。
本当にそうなんだろうか。
その修正でいいと思いますか？
って聞けば、向こうは
いいと思います
っていって終わりかな。
いや、あまり修正しすぎると、思わぬトラブルが起こるかもしれませんが、
その辺りいかがでしょう？
と聞くことはできたかもしれない。
でも、自分の考えた修正案が気に入っている向こうとしては、
その辺りはテストでカバーします。
って答えるだろう。
テスト工数がかかりすぎているように思えますが、もう少し減らせませんか？
と聞けば、
テストは必要だと思いますので、これくらいやらせてください
って答えるだろう。
やらわらかい質問口調でいけば、やる気満々だから、向こうのやりたいやり方以外の
方法はでてこないのだろうと思う。
この場合、相手のメリットになる質問があったのかもしれない。
もう少し修正範囲を減らせれば、楽になると思いませんか？
テストも減らす方法があるように思えるのですが、早く帰りたくないですか？
テスト数が多いと大変でしょう。
そういうのはありかもしれない。
こちらのポリシーを伝えて考えてもらうのもありだったのかもしれない。
こちら側のポリシーは最低限の影響範囲でトラブルを減らすというところにあります。
この考え方って、どう思います？
もう少し付け加えてもいいかもしれない。
といいますのは、いままでの経験上、トラブルが起こると夜中呼び出されて大変だったんです。
次の日も、復旧作業に追われてえらいことになったことがあって…
などというと納得してもらえたかもしれない。
あとになって考えれば、いろいろ思いつくものだ。
パターン的には、
・相手のメリットになる質問をする
・こちらのポリシーを伝えて理解してもらう
かもしれない。
他もでてきそうだから、あとひとつだけ考えよう。
かみ合わなかったことを振り返って考えるに、
私が少し話すぎた
というところが思い当たる。
あれこれ、先読みして話してしまったので、ちょっとよくなかったかもしれない。
これは、こういう意図で質問していると思いますので、こういう懸念点があるということですよね？
という相手の意図をこちらで決めて話を進めていたことを思い出した。
・口数をもう少し減らしてみる
そういった工夫をしてみてもいいかもしれない。
あと、コーチは誘導していいのかという点については、議論の余地がありそうだ。
それは、ケースバイケースかもしれない。
また今度考えてみよう。