.@behindwisteria 世の中には「困ってる人」と「困ったふりをしてる人(本人は困ってると思ってない)」がいて、皆にあまねく伝道師の役割をしていると後者から反感を買うんですよね。もちろん前者には協力は惜しみません。
「性格が歪んでしまった」わけではないので、最近の自分の考えを整理して残しておきます。
ソフトウェア開発に多少明るかったこともあり、日本にいた頃から「周囲への啓蒙」、「伝道師の役割」を期待される場面が少なからずありました。日頃ブログで情報を発信している人には組織で似たような役割を演じている人も多いのではないかと思います。バージョン管理、テストの整備、開発プロセスの改善、後進エンジニアの育成、便利なツールの紹介などなど… 新しい技術や新しいやり方を広めようとすると反対者が少なからず出てきます。それぞれ言い分があって
- メリットがわからない。
- 成功するのか(効果があるのか)怪しいものだ。
- 私は今のやり方で困ってない。
辺りがメジャーな反論ではないかと想像します。あと滅多に口には出てきませんが「私のやり方に口出ししないでくれ」や「手柄をたてようとしているあなたが気に入らない」というのもきっとあると思います。
アドバイスを何度か繰り返すと、あるとき提案が受け入れられるタイミングがでてきます。「トップダウンの命令で仕方なく」もありますが、私が考える一番成功しやすく、効果が出るタイミングは「聞き入れる側が”本当に困っている”」ときです。
例を挙げてみましょう。ある会社Aで作られたプログラムを、いろいろな理由から別の会社Bへ管理を移し後継モデルの開発に取り組んだところ、大量のバグがでてきたことがありました。会社Bでは同じ過ちを繰り返さないよう次期モデルの見積りを念入りに行い、そして計画案が出てきました。改善する箇所を絞って品質を改善するというもっともな計画ですが、一言「ところで改善する箇所はどうやって決めたの? どうやって改善していくの?」と聞いたところ「改善箇所はA社から引き継いでよく分からず、バグが多かった(気がする)ところを選んでいる。改善方法は”1行ずつソースを読んでから考える”」との解答でした。
私は「1.ユーザは改善の効果を体験できるの? 2.ソースが複雑なところにバグは入り込みやすいよ。 3.ソース読んでも時間かかるだけで、元の仕様なんて分からないよ。」というコメントを出してみました。これをきっかけにB社はいろいろな質問をだしてきて、「1.処理時間を測ってボトルネックを改善してね。 2.ソースの複雑度を測ってね。 3.テスト書いてね」といったこちらからの3つの改善提案が前向きに検討されています。逆の順番で、提案を先に行ったらどういう反応があったでしょう? 「前の開発でも勝手な要求ばかりでスケジュールがかなり押したのに!こっちの開発を邪魔してほしくないものだ!!」と思われたのではないかと思います。
私が思うに世の中には直面している問題を正しく認識できてない「困ったふりをしている人」がかなりいて、こんなことをよく言っています。
- 昔からやり方はこうだった。
- ルールがこう決まっている。
- どうしようもないんだよね。何かいい方法ない?
人から指摘されても、その人にとっては現状を言ってもらったに過ぎず、「改善すべき問題」ではありません。「問題ではないので、アドバイスも効果が無い」のかなと思います。
アドバイスなり啓蒙活動をするには、まず問題を認識させる必要があるというのが私の今の考えです。手を変え品を変え取り組まないといけません。これまでのやり方では問題が起きるようにわざとお願いしてみたり、いやでも認識出来るぐらい問題が大きくなるまで放置してみたり… これが冷たいと言われたら返す言葉がありませんが…
そういえば困ったふりをしている人は「問題を大きく捉えすぎて何から手をつけていいのか分からず、とりあえず普段は放置している」パターンもありますね。このタイプの人は定期的に同じような話題で相談してきて、アドバイスしても3日坊主で終わることが多い気がします。



