主張と受容、非対称性
Akerun Advent Calendar 2019 - Qiita の25日目の投稿です。 書いたのはeijisakatoです。インフラがメインの技術スタックですが、デザイン、マークアップ、JS以外のところは大体がんばれます。
これを書いた経緯
12月が近くなってから「アドベントカレンダーやるから何か書いて」と怖い先輩からのお達しがあって、当初は入社してしばらく取り組んでいたKubernetesの技術的な話を書こうかなと思っていた。Kubernetesは死ぬほど大変だからやっぱりやめたほうが良さそうという趣旨の下書きを少し作ってみてはみたものの、書いててもどうもピンとこないので別のテーマにすることにした。
僕がPhotosynthにインフラエンジニアとして入社したのは今年の7月のことで、前職での経緯も含めればここ3,4年ほど、技術的なイシューよりは「良いチームや組織」ってどんなものだろうか? ということを、ものすごく重要なテーマとして考えることが増えた。まず当然の前提というか一般論として、「完璧な組織」や誰にとっても都合のよい組織は存在しない。僕は現職の前にも転職は何度かしてきたし、フリーランス時代の経験も含めれば渡り歩いてきた現場は多いほうではないかと思っている。これまでの経験から振り返ってみると、組織で発生する課題というのはいろんな本に書いてあったとおり、いろんな組織で似たような問題が似たような感じで起こっていたと思う。典型的なものではビジネスサイドと開発サイドのコンフリクト、組織の拡大と反比例する開発スピードなど。とはいえ、同じような問題といってもそのディテールは様々であり、全く同じ問題というものもやはり存在しない。
組織において前述のような課題が現場で顕在化してくると、だいたい出てくるのが「もっとコミュケーションをよくしよう」という話だ。そしてそれを改善するためにひねりだされるのは、例えば会議のファシリテートルールだったり人と接するときの標語コレクションみたいなものが多い。でも「コミュニケーションにおいて大事なことをリストアップすべし」などと言われたらそれこそ無限に挙げることができる。相手の話を聴く力やら忍耐力など、「何とか力」のリストを見ると白々しい気分になってくる。ダセェ! 僕はそんな非クールなリストが壁に張り出されるより、もっと単純な指針や心構えで本質的な要点を表現できないかと考えていた。何しろ単純であれば毎日復唱して覚えなくてもいいし、そのことだけを気をつけていればよい。僕のような横着な人間にはピッタリなのだ。
社会的な背景
完全になくなったわけではないにせよ、従来の典型的な組織のヒエラルキーが意味をなさなくなってる状況が増えていて、これはそこら中で言われてることだけど、本当にそうである。
とりあえず我々エンジニア職の仕事を見渡してみるだけでも、技術領域は細分化されそれぞれが果てしない深さを持っており、 自分はある場面ではリードを取れるが、他の場面では完全にフォロワーにならざるを得ないという状況は頻繁に発生している (恐らく他の職種でも多かれ少なかれ、同じようなことは起こっているはずだ)。
エンジニア1人で経営者と要件定義してデザインからマークアップからサーバサイドからインフラを作って保守し続ける人なんてのは、もはや人間ではなさそうにさえ思える。するとチームでの協業は必然となり、長いこと働いていくにはカッティングエッジなアーキテクチャより「いろいろやりやすいチームであること」のほうが個人にとって差し迫った命題になってくる。ヘタに上下関係を作るより、それぞれが対等な立場であるほうが余計な人間関係の問題にかかずらわなくてもよくなる。僕が15年ぐらい前に月400時間超えの稼働を達成した案件でやっていた、Windows98端末にActiveXのDDLを人力でインストールし続ける経験など、現代のシステム開発においては「へえ、それは大変でしたね!」ぐらいの話題にしかならない。当時の僕は発狂寸前でやっていたが、今はすごくも何ともない。そうすると自動的に「僕ちゃんはエラい人だから威張ってもよい」だの「結構イケてんじゃないか」なんて言ってるヒマは全然なくなる。そんなことを本当に思ってふんぞり返ってたら、またたく間にボコボコにされてしまうだろう。アイデンティティもへったくれもない。
何が言いたいかというと、自分のプレゼンスが良くも悪くも不確かな現代では、誰に対してもフラットな関係を意識的に構築していくことが極めて重要なのである。経営陣やベテランの人に対してもそうだし、入社したばかりの若い人に対してもそうだ。 皆がそれぞれの専門性を持っており、自分のできないことを誰かがやって、誰かができないことを自分がやっている。 そういったフラットな関係性においては、自分はアレができないからなぁとか思う必要は別になくて、みんなそれぞれにリスペクトを持てるように自分のマインドを維持することは健全な精神を保つための死活問題とさえ言える。 でも、先述したように、そういう関係性を作れるための、単純で本質的なコミニュケーションの要点って何なんだろうか?
信頼を作る対話とは何か? 2つのA
人間の意識は大変に矛盾に満ちたもので、昨日にこう思ったとしても今日には全然反対のことを考えているということがよくあるし、 思っていること全てを言語化することはできない。他人の矛盾は指摘したくなるが、自分の矛盾など気づいてもいないか、気づいたとしても理由をこじつけて自分はオールオッケーだと認知的不協和を解消する。また、使った単語や言い回しによっては異なった意味に受け取られたり、思っていることをうまく言えずに議論の場が進んでしまい、それ以降は何もいえなくなってしまうなんてこともよくある。要件を決めていっしょうけんめいに作った機能をレビューすると「あっ、そう意味で言ったんじゃなかったんです」などと言われた日には、全てを投げ出したくなるのはまず間違いない。我々の思考には恐らく限界はないが、使う言葉にはどうがんばっても限界があるのだ。
こういった議論はこれまで、言葉を変えてさんざっぱらなされてきた。そうして大体は「対話を増やそう、フラットに話していこう」といった結論になり、なんとなく結束が強まったような気になって仕切り直しの会議は解散する。その後の経過は言わずもがなだ。でも、対話を増やすとかフラットに話すってのはどういうことなんだろうか。それは、職業はなんですか? とか年収はいくらですか? といった婚活パーティのような質問を延々繰り返したり、「あなたはムカつきます」などといきなり金属バットでぶん殴るような声掛けをすることだろうか。もちろんそんなはずはない。
誰かと話をしていてあまり楽しくなくなってくる場面にはいろいろあるが、自説の主張しかされない、こちらの言い分を聞いてもらえないというのはよくあるケースではないだろうか。そういうケースが続き、自分の話が聞いてもらえないとか言っても無駄だという考え方に行き着くと、自分の身を守ることが他のことより優位になる。すると機能追加の話がきても「知らんけどリソースがありません」と無慈悲に突っぱねることになる。
自分の思っていることを言うには結構な勇気がいる。相手を怒らせやしないかとか、そんなことも知らないの?とバカにされたりする不安もあるし、表現するための適切な語彙を持たず、アワアワ言ってる間に相手に何だこいつと見限られてしまうこともある。
ところが、自分の考えを率直に言ってみる話し手の勇気と、発言を受けいれる聞き手の寛容さがうまく場に揃うと、スッと心が通じたと感じられることがある。そうするとなかなかしめたもので、この野郎と思っていた相手が急にいいヤツに見えてくることだってある。打開策として出てきた案が結局は同じであったとしても、互いに主張をして落としどころをつけたという経過はその後のモチベーションを上げることに大きく影響する。
これをいかにもそれっぽいキーワードに展開してみたとき、僕は Acceptance(受容、受け入れること) と Assertiveness(「自他を尊重した自己表現もしくは自己主張」などと訳される) という単語を思いついた。しかし僕は、もうひとつの何か賢しげに見える、Aから始まる単語を探したいと思ったのだ。もちろんそれは「ポイントは3つあるんです。それは3つのAで始まる・・・」と、まるで本物のMBAホルダーのように言いたいがためである。
3つ目のA
(このエピソードは僕の現職での話ではなく、システム開発の現場でよく見られる典型的な場面という前提で読んでほしい)
経営者とセールス部門やカスタマーサポート部門、システム部門の人たちは抽象的には同じ目標に向かっているはずがが、現実はそれぞれが日々まったく異なる人々や情報に接している。例えば先月に入社したカスタマサポートさんが顧客からの素朴な質問を開発部門に問い合わせると、エンジニアさんは長年の経験から、脳内を一瞬でめぐって出てきた正論をぶっかましたとする。すると大体がカスタマーサポートさんの反発を招くだけに終わる。なぜかといえば、エンジニアさんがその正論を反射的に言えるまでに培った何年もの経験(という言葉に集約されるいろんなこと)を、カスタマーサポートさんは全く知らないからだ。で、その答えが「仕様です」といった極めて短い、愛想もない言葉だったりすると、カスタマーサポートさんはエンジニアさんに殴りかかりたくなるに違いない。
また、経営者が「なんでこんなに人が増えてるのに開発スピードが遅いの?」と首をかしげることが多いのは、成長したシステムはいわばゲームが進んだジェンガのようなもので、上に新しいブロックを置くことも難しくなるし、下にあるブロックを抜いたり入れ替えたりするなんてことはそれこそ一巻の終わりになりかねないという、システム開発の宿命を肉体的な実感として理解することが難しいからだ。DELETE文をターミナルに貼り付けてEnterキーを叩くまでの葛藤を、僕はゼヒ色んな人に体験してほしい。話が逸れたが、時間がかかるのは恐ろしく慎重にならざるをえないからで、そのスピードを上げるために必要なのは何のことはない、単に経験が長いといった身も蓋もないことだったり、何年も経ったシステムを入社3ヶ月のメンバが攻略するのは実に果てしない戦いなのだ。ジェンガの話はどこかで聞いた話の受け売りである。
つまりAさんとBさんの脳内には情報の非対称性(Asymmetry)があって、我々はその非対称性を埋めるように言葉を選ぶべきなのだ。この考えに至ったとき、僕はこれだ!と膝を叩いた。そういったわけで僕は Assertiveness,Acceptance,Asymmetry という3つのキーワードの頭文字を繋げて「3A原則」と名付け、ひとりで喜んでいた。今回の転職活動では面接に行くたびにここぞとばかりに使っていたのは言うまでもないが、評価してもらえたのかどうかはよく知らない。変な人と思われていたかもしれない。
3A原則とは単なる言葉遊びである
でも実際のところ、3A原則というのは単なる言葉遊びやMBAごっこに過ぎない。
「真にフラットな組織(とかいうものがあると仮定して)」は恐らく、参加する全員が成熟した精神を持っていることを前提としている。なぜなら、何を言われても怒ったりムカついたらダメなのだ。そんなのははっきりいって単なるファンタジーである。僕はふざけたことを言われると、何より真っ先に怒りを感じるタイプだ。ただし顔には出さないようにしている。
信頼を築くために我々がやるべきことは結局のところ、対話を積み重ねるといったような新しくも何ともないキーワードに行き着く。これは見方を変えれば、普遍的な課題であると同時に永遠に解決されない課題だとも言える。経験や挫折を重ねて神髄にようやく行き着いたと思ったら棺桶に入っていたということも、昔から綿々と続いてきたことだろう。他者との間で信頼を作れたと実感できるまでには、例外もあるが概してとても時間がかかるものだ。しかし時間をかけて組織における信頼を構築するのは結構だが、何がトレードオフになるか・・・スピードだ! 致命的な犠牲だという他ない。
その人がどういう人かというのは、その人が昨日言ったこと、今日に言ったこと、明日に言ったことの連続においてようやく分かってくる。お仕着せの1on1をしたその1時間の中だけで判断されるべきではない。こんなのは当たり前のことだが、現実的には会社組織において当然のように行われている。なぜなら時間がもったいないのでコミュニケーションは手っ取り早く効率的に行わないといけないからだ。クロージングを意識せずに長々としゃべってると社長に怒られるぞ! でも、しょうもない話をするのもまた楽しいですね。
つまるところ、経営スピードと組織の信頼構築のうち、我々はどちらを優先すべきだろうか? もちろん、何かを選ぶということは他の何かを選ばないことである。しかし僕はこの問いに対して明確な答えを持っていない。僕は結局のところ経営者ではなく、会社員(というか、資本家の対極の存在として)の論理しか持ちえない。どちらかといえば後者なんだけど、そうは問屋が卸さないこともまた真実だ。そういうアンビバレンスには答えがないというのが正解なのだが、しかし一方で、論理が対極にあるとしても互いに信頼が構築されていれば、あまり難しく考えてアレコレ対策をしなくとも幸福な組織が少しずつできていくんじゃないかとも思う。
どこに住んでるの? とかあそこの唐揚げ定食おいしいよね? という話はそれはそれで楽しいものだが、ときにはその人が重要にしている価値観について直接切り込んで聞いてみるのも、とても楽しいと思う。信頼というのは、自分のことを受け入れてもらえたとか、この人は信頼できる条件を満たしたと思ったときにだけ作られるのではなく、自分が相手を受け入れたときにも作られる。つまり、不完全な存在に過ぎない相手を信頼するということを、同様に不完全な存在である自分が選択するのだ。