強い言葉、有野さんがどのくらい力強くあるいは jerk-ish に発言したのか第三者の我々にはわからないけれど、若干 jerk ぽかったという設定でなんか書いてみたい。
この話はいくつか切り口があると思う。
- 気の弱いキャラのプログラマでも強い語調の相手に頑張って押し返すべきなのか
- 自分は時には強い語調で問題をはっきりと伝えるべきなのか
めんどくささとトレードオフ
2 は和良さんが書いてくれているのでまず 1 から考えてみる
自分は（おっさん力や seniority によって薄まったとは言え）気の弱い方なのもあり、強く主張されると「めんどくせえなーハイハイ」といって微妙であれなんであれ相手の主張を受け入れる傾向はある。
「めんどくさい」というのは問題の根幹にある気がする。当たり障りのない言い方をすると、議論にはコストがかかる。
わかりやすいコストは時間。コードレビューとかだと、議論のラウンドを重ねるよりは相手の言うことを飲んでささっと LGTM してもらう方が速く仕事が片付く。コード品質は犠牲になる・・・というか自分の好みからはちょっとズレるかもしれない。でも move fast の方がしばしば大事。相手がエラかったり忙しかったりで返事の遅い人だと議論に時間がかかるため、妥協して仕事を進めたい引力は更に強くなる。
コストその 2 は精神的なもので、まあ疲れるよね議論。自分の考えに説得力を与えるよう整理するのって大変だし、強い言葉すなわち感情的なダメージのある言葉に晒されるのも堪える。そうですねハイハイといえばダメージは最初の一回分だけで済み、自分のメッセージを考える苦労もない。
といった理由から人々「めんどくせえなーハイハイ」をしているのだろうけれど、ほんとはめんどくさがらず押し返すべきなのだろうか？というと、場合による。コストがある以上、トレードオフもある。
ただめんどくさい側に振りすぎた我が身を反省すると、めんどくさがってばっかりいると議論が苦手なままで、コストがちっとも下がらないんだよね。自分の主張を整理するのは、練習すればできるようになる。角を立てない対話技法にもスキルはある。時間がかかるのも、忙しい相手のアテンションが他に行く前に返事をサッとするだとか、返事がないときにチャットでつつくだとか、やりようはある。
自分は殺伐とした環境で仕事をしていた影響もあり返事の催促が壊滅的に苦手で、過去にすごく多くの時間を無駄にした。最近はマシになったけれど、気負わずチャットで催促できる程度には図太さが必要だった。
なので議論や主張 (argument) は面倒でも普段からちょっとずつ練習しておくと、強い言葉を使う相手と渡り合う時のトレードオフも変わるんじゃないかな。チーム全体がクソ忙しかったり殺伐してたりすると練習する気も起きないかもしれないけど、そういう時は・・・どうするんだろうね。友達と共同プロジェクトをやってみたり、平和そうなオープンソースプロジェクトに PR を書いてみたりすると練習になるのかもしれない。そこまで頑張る価値があるのかはわからない。議論のスキルを育てられないのは不幸だけれど、不幸な職場というのはある。
変化する関係性
これを逆側から見ると、議論が得意で強い言葉に躊躇のない人が議論の苦手な人と対話をしたいなら、相手のトレードオフを変えてあげないといけない。それが和良さんの主張の原点だと思う。強い言葉がデフォルトな jark-ish/candid people にとって言葉を sugarcoat するのはコストなのかもしれないけれど、自分の勤務先とかだとそういう courtesy は前提になってるし、昨今はそれが段々とメインストリームになってきてるんじゃないかな。
別の見方をすると、議論が得意な人は議論が苦手な人を啓蒙する必要がある。ある種のシニア仕草(©和良)かもしれない。
ただまともな人は成長するし健全な人間関係は成熟するので、必要とされる politeness や courtesy も時の流れとともに変わると思う。お互いに付き合いが長くなれば素の自分も出しやすくなるし、会話もよりカジュアルになりうる。いつまでも過剰に他所他所しく丁寧である必要はない。逆に歯に衣着せぬ会話をしたいなら、まず相手との相互理解を深めないといけない。
有野さんは冒頭で、我々は割と押し返すのが得意なのではと書いたけれど、それは付き合いの長さもあると思う。我々、もう 10 年前後の付き合いがあるよく知った仲なわけです。そこに親しき仲の礼儀以上のものはないじゃん。かわりに時々口を滑らせて反省することもないではないけれど。
テック企業、割と人の流れが速い。景気のいいチームはどんどん人が増えるし、景気の悪いチームからは人が逃げていく。そうでもなくても飽きたりなんだりで人が入れ替わる。これは風通しの良さにも繋がるので悪いことばかりではない。ただチームとしての成熟には限度がある。先に書いたような courtesy はこの流動性が前提にあると思う。オープンソースプロジェクトなんかは雇用の摩擦がないから、この流動性や他者の偏在がより強くなる。
ただソフトウェア開発チームが常にこうである必要もない。
書籍 “Pragmatic Programmer” の二版には “Pragmatic Teams” という節があって、良いチームとはこんなものだと説明している:
A pragmatic team is small, under 10-12 or so members. Members come and go rarely. Everyone knows everyone well, trusts each other, and depends on each other.
これはいつも言葉遣いに気をつけながら仕事をするのが嫌な人にとっては一つの答えかもしれない。いま自分のいるチームでも在籍歴が長く付き合いが長いメンバー同士ほどコミュニケーションが直截で話が早いように見える。ただ転職や異動でよくチームを変える人や、有野さんのようにフリーランスの働き方とは互換性が無い気もする。そしてずけずけとものを言う pragmatic team は気の弱い新入りに優しいだろうか？この二つは別に矛盾する必要はないだろうけれど、現実には敷居は高くなりがちだろうね。それはトレードオフだと思う。
Pragmatic Pair
Pragmatic Team 的な関係性の究極は Pragmatic Pair だと個人的には思っている。
Google の有名なプログラマに Jeff Dean という人がいる。もう少しだけ有名でない話として、Jeff Dean は Sanjay Ghemawat 相棒といつもペアプロをしていた（と言い伝えられている）。この二人, Google 以前は DEC というコンピュータ会社の研究所で一緒に働いていたと言うから、かなり付き合いが長い。そんな二人のペアプロで飛び交う言葉はどんなものだろう。
この一件だけだと説得力がないけれど、自分が昔やっていたブラウザの仕事でもレンダリングエンジンチームの筆頭 Adam Barth と Eric Seidel の二人はいつもペアプロでばんばんコードを書いていた。彼らはその後エラくなってペアプロなんて全然しなくなったと思いきや、最近 YouTube でペアプロの live coding を公開していると少し前に向井さんに教わった。彼らに Youtuber として成り上がる野心があるとは思えないから、たぶん気心の知れた相手と一緒にコードを書くのが楽しくてはじめたんだと思う。Pragmatic Pair の特別さを伝えるエピソードと解釈している。
本当に有意義な議論をするには時間をかけて相手との関係性を築くのが一番良い・・・なんてのは、ファンタジーかもしれない。流動性のあるドライな関係のチームで議論を活発にしたいという我々の現実的な願いから程遠い、なんの役にも立たない話かもしれない。一方で普段「あるべき議論の形」だと思っているものが、真の理想というより職業上の処世術や他の理想を実現するためのトレードオフかもしれない点のは心の片隅に置いておきたい。別に courtesy を大切にする inclusive な対話それ自体を理想とするのがダメといいたいわけじゃない。そういう考え方にも理はある。ただ議論に期待するものって人によって色々だよね。