プログラマー (ITエンジニア) ならでは!?
かもしれない特徴的なものを四つご紹介。
「姿勢」二つ、「落とし穴」二つに分けています。
o 姿勢1: 提案のない不満と愚痴
o 姿勢2: 論理性のない納得がいかない
o 落とし穴1: 分析のないパズルゲーム
o 落とし穴2: ロジックとデザインの話がごっちゃ
姿勢1: 提案のない不満と愚痴
dragon「なんかそれダメなんですよねぇ」
slime「ふむ、どんなところが？」
dragon「こういうところが」
slime「そんなダメじゃない気も...これこれこうで」
dragon「まあ、そうっちゃそうなんですけど...」
slime「ふむ、したらどうすればいいでしょう？」
dragon「いやまあ、なんかダメだなぁと思って」
...
dragon「なんかそれダメなんですよねぇ」
slime「それこないだも聞きましたが...」
dragon「どうにかなんないんですかねぇー」
slime「どうなったらいいと思います？」
dragon「いや詳しく前提とか状況わかんないんで」
slime「じゃあ詳しく説明するので一緒に考えましょう！」
dragon「いや、いいです、時間ないですし」
まだslimeさんが提案的なのでマシかもしれません。愚痴なので途中で話が切れてしまいこともありますし。愚痴なのでこうしましょうと提案しても返事がないことも。
まだdragonさんが口に出してるだけマシかもしれません。普段から「協力的ではない」という姿勢で表現するだけで、堂々とは言ってこないということも往々にあります。
slimeさんもダメならダメで議論して直したいわけですが、仮に正しい意見だったとしても、精神的にだんだんつらくなって受け止めづらくなります。
人の気分を害するパワーはトップレベル。このような姿勢の人がいると、チームビルディングとしてはマイナスです。
本来、愚痴を出すのは悪いことではなく、吐き出したほうが精神的に良いというのはあるのですが、それは業務の議論でやることじゃないです。
姿勢2: 論理性のない納得がいかない
dragon「それはなんとも微妙ですねぇ」
slime「ん？どういうところがですか？」
dragon「こういうところが」
slime「でも、これはこうじゃないですか？」
dragon「うーん、まあそうなんですけど...」
slime「他の点で何かあります？」
dragon「まあ、いまは特にないですが...」
slime「したら、これでいきましょうか？」
dragon「うーん...」
slime「まだ納得されてないですかね？」
dragon「納得はしてないですね」
slime「したらどんな点が？」
dragon「こういうところが」
slime「それさっき話しましたが...それはこうですと」
dragon「うーん、まあそうなんですけど...」
まだslimeさんが前向きにやり取りしようとしているのでマシかもしれません。普通だったら「何が言いたいの？」って、途中でいやになって聞くのやめてしまいますよね。
本当に大事な抜けポイントがあるなら、slimeさんは当然前向きに議論したいわけですが、特に論理的なポイントは出てこないので話にならない。
議論の進まない姿勢より協調
二つの姿勢は、恐らく「どこかの価値観の違い」によるもの。好き嫌いという感情が根底にある可能性もあります。
プログラマーは手法にこだわりを持ちがちです。それは追求のために良いことでもありますが、どちらかというと言葉にすることも苦手な人が多いので、時に「議論の進まない姿勢」として現れやすいんだろうと。
またこれは、人にデフォルトで組み込まれた行動であって、油断すれば誰でも自分もそうなってしまうと思っています。理性でしっかりコントロールしないといけないんだろうと。
仮に、slimeさんの考えが確かに一番良い方法ってわけじゃない！だったとしても...業務判断を「なんか違う」だけで決定するわけにはいかないですし、代替案がなければ立ち止まってしまうだけ。もしくは、代替案を責任持って遂行してくれる人がいなければ同じこと。
そもそも、一番良い方法じゃないといけないわけでもないかも。二番目の方法をみんなで協調して成果を高めて成功できれば、それで別にいいことも。立ち止まるくらいならその方がいい。
そもそも、一番良い方法かどうかって、社会実験でもしない限り厳密には証明できないもの。
議論が進まないくらいなら「できる理由」を探すほうが良い。
でも、slimeさんがそれを見越して、うまくハンドリングできたらスーパーエンジニアですね。
...
jflute は、こういう姿勢たちを相手にしない (人を相手にしないわけじゃなく姿勢を相手にしない) のですが、若者たちがこういう場面に遭遇すると悲しいので、ブログで共有することで事前に回避してもらえたらな、という提案です。
あと、ブログで共有することで、自分がこうならないように気をつけようと。
落とし穴1: 分析のないパズルゲーム
さて、今度は落とし穴。
resort「mystic, oneman, bigband どれにしよう？」
sea「mysticは、セキュリティに強いはずです」
land「開発効率は普通かな」
sea「onamanは、パフォーマンスが特徴って聞いたことある」
land「セキュリティは普通かな、開発効率はbigbandかと」
sea「bigbandの、パフォーマンスは確か普通かな」
resort「じゃあ、まとめると...」
o mysticは、セキュリティに強く、開発効率普通
o onamanは、パフォーマンスが良く、セキュリティ普通
o bigbandは、開発効率が良く、パフォーマンス普通
resort「bigbandはセキュリティ不安だね」(★えっ!?)
sea「うちのシステムはパフォーマンスは良くないとダメですね」
land「でも、onemanは開発効率が悪そうですよね」(★えっ!?)
resort「そうなんだよねぇ。でも他で良いものないしね」
sea「確かに」
land「確かに」
resort「じゃあ、onemanだな。決定」
★えっ、決定しちゃうの!? ずいぶんとアバウトじゃない？
でも実は...よく調べると...
o bigbandはセキュリティも強かった。
o onemanのパフォーマンスの優位性は微差であった。
なんてことも。
情報がないところが「不安」として置き換えられています。優位性の「程度の問題」が無視されてしまっています。あとは限られた情報で要件と合わせてパズルをするだけ。
プログラマーは、論理的な人が多いとよく言われますが、"論理好き" と "分析好き" はまた別だと考えています。実際に分析が好きという人は少ないように思っていて、「論理(パズル)は好きだけど分析は好きでない」となると、こういうことが起きやすいだろうと。
もちろん、時間には限りがあるわけなので、ある程度は記号化して判断していく必要はあるので、あくまで「程度の問題」というところではありますが、浅すぎる議論で結論付けられるのをよく見かけます。
(議論対象がコードが読めるものであれば)
例えば、少しでもみんながソースコード読んでれば、そういう判断には絶対にならない...なんて思うことも。
...
あれ!? 議論は進んでるじゃん！って思いました？確かに、このパターンだと確かに議論は進んでますね。あっという間に結論まで出ましたし。ただ、良い判断をしてるように思えないので、しっかりと分析している人を議論に入れてみましょう。
す・る・と、進まないのです。
分析している人が孤軍奮闘して伝えようとしますが、優位性の「程度の問題」を伝えるというのは、非常に時間のかかること。議論の時間は限られてます。みんな早く決めたがりますし。
そもそも分析好きではない人たちが大勢であれば、のみこみも悪くさらに時間がかかるでしょうし、それを重視しようとはしないかもしれません。「程度の問題」って体感しないと本当の理解にならないから。(ちゃんと、自分で検証したとかコード読んだとか)
また、分析している人が大勢であっても、一人二人の分析していない人が発言力のある人だと、同じようなことが起こりがちです。
ちゃんと分析している人から見て、議論が進まないのです。
ツールの選定っぽい話を例にしていますが、もっと細かな様々な判断を要する場面に応用できます。
...
ちなみに、もう一つあるが...
resortさんは、そもそもonemanが好きだった...とか。決める立場であるんであれば一概に悪いことじゃないです。
「もうどれ選んでも大差ないから自分の好きなもので」
と堂々と言葉になるのであれば。隠れてると議論のロジックが歪むから。
落とし穴2: ロジックとデザインの話がごっちゃ
プログラマーは、
o 動くか動かない？
o 正しいか正しくないか？
を議論するのは得意です。
そういうことばかりやっていますし、もともとそこを追求するのが得意な人が集まっているでしょうから。
でも、昨今のプログラマーに求められることが多様化してきました。
// プログラマーに求められるデザイン脳
http://d.hatena.ne.jp/jflute/20170623/desigraming
議論の中で、
「ロジカルで答えが明確に出やすいもの」と、「デザイン的で究極は優劣の証明ができないもの」を、混同してしまう
のをよく見かけます。
また、後者のようなものを判断する場面が、以前よりも増えているというのも要因でしょう。
そのような前提が頭にない状態で、それを一生懸命みんなで「どれが一番か？」というのを議論しようとしていても噛み合わなくて議論が進みません。
議論自体はしないといけないことですが、ロジックの話なのかデザインの話なのか、ちゃんと頭のモードを切り替えて話をする必要があります。
議論スキルへの意識
プログラマーは、計算能力が必要、という印象は誰もが持っているでしょうが、チームで開発する限りは、「議論」という仕事もたくさんします。
プログラミングスキルは、優劣の概念があって、個人個人でどんどん成長させていこうという意識もあるし、会社としては教育もしていこうと考えます。業務でも、未熟な人には重要なものは任せず、フォローワーが入って徐々に難しいものをやらせたり、得意な人が重要なものを任せられたり判断したり、って自然と区分けされているように思います。
一方で、「議論スキルをどんどん成長させていこう」ってのはあまり聞かないし、「議論が未熟な人には重要な議論はさせない」とか、そういうこともあまりありません。(あったら不公平だとかで問題になるかもしれないし)
でも、人間的なスキルだって別にフラットではありません。大いに優劣が出るのは当然のはずで、議論が苦手な人が議論に入ると議論が進まなくなり、チーム全体道連れになって、間違った判断に突き進んでしまうかもしれません。
それが声高に言われないのは、やはり「不公平になるから」というのがあるからでしょう。
でも、「議論スキルをどんどん成長させていこう」という意識と前向きな姿勢があるのであれば、議論自体をフォローしていくことはいくらでもできます。
こちらの記事は、とても印象的でした。
「ちがう意見＝敵」と思ってしまう日本人には、議論をする技術が必要だ。 | HUFFPOST
もう少し、わたしたちは、「議論スキル」に着目した方が良いだろう
と思いました。
