シナプスを設計する——問題が起きる前に、気づける関係をつくる

ある日、人事の担当者から突然メッセージが来たことがありました。こちらからは何も聞いていないのに。「エンジニアチームの中で、少し雰囲気が気になる動きがあって」と。

その瞬間、「あ、これが機能しているんだ」と思ったんですよね。自分がやってきたことが、ここで現れた、と。

VPoEという役割の、日々の仕込みの話です。

「CTOの補佐ですか？」と聞かれると、半分は合ってる気がするし、半分は違う気がする。「エンジニア採用の責任者ですか？」と聞かれても、それだけでもない。「組織づくりをされているんですよね？」——それも正しいけど、核心じゃない。

今は、こう答えることにしています。「CTOの頭の中を翻訳して、エンジニア組織ではない人も含めたステークホルダーともディスカッションをしながら、組織に届ける人です。同時に、それを自分で執行する人です」と。

これが、僕がやっている仕事の本質です。翻訳して、届けて、執行する——この役割を担う人のことを、VPoEと呼ぶことがあります。そして、それを機能させるために「日々の仕込み」がある。今日はその話をしたいと思っています。

具体的に何をやっているかは後半で書きますが、先に言っておくと、ランチに誘ったり1on1を申し込んだりする、拍子抜けするくらい地味なことだったりします。

少し補足すると、VPoE（Vice President of Engineering——副社長・副責任者などと訳せます）という名前の通り、これは「誰かのVice」です。その「誰か」は自明ではなくて、組織によって違うし、フェーズで変わる。

この記事に書くことは、「誰かの意思決定を翻訳して、ステークホルダーと調整しながら、組織に届け、執行する」という役割の本質の話なので、相手が誰であっても通ずる部分があると思っています。自分の場合はCTOですが、それは一例です。

CTOの頭の中を翻訳するということ

翻訳、という言葉を使うとき、日本語→英語みたいな単純な変換を想像されることがある。

これは役職の話に見えるかもしれないですが、たぶん本質はもっと普遍的です。誰かと誰かの間に立って、両方の言葉を訳しながら橋を架ける——親としてパートナーと子どもの間に立つときも、チームでリーダーとメンバーの間に立つときも、起きていることは近い気がしています。VPoEという肩書きは、僕にとってはその「間に立つ役割」がたまたま会社という形を取ったものなんだと思っています。

でも実際は、それより根深いことが起きています。ビジネスサイドとエンジニアサイドは、同じ日本語を使っていながら、全然違うことを話していることが多い。言葉は同じ、文法も同じ、でも優先度が根本的に違う。

たとえば「この件、スピードが大事です」というとき、経営側がイメージしているスピードと、エンジニアがイメージしているスピードは、単位が違います。経営側は「今週中」と思っていて、エンジニアは「この四半期中」と思っている。どちらも「スピードが大事」と言いながら、それぞれ正しく振る舞っていても、いつの間にかズレが積み上がっていく。

CTOはこのズレの最前線に立っているわけですが、CTOは意思決定も技術判断も担いながら、経営にも向き合っている。そこにさらに「組織の隅々まで意図を届ける」という役割まで乗せると、人間の処理能力を超えてしまうことがある——たぶん、そういうことなんじゃないかな、と。

VPoEは、そこをカバーする役割だと思っています。CTOが意思決定した内容の意図を、エンジニア組織に届けられる形に変換する。「なぜそうなったのか」「何が大事なのか」「現場はどう受け取ればいいのか」——この解像度が高くないと、届けたつもりが届いていない、という事態が起きるんですよね。

これまでの経験の中で、これを失敗した体験があります。経営からのあるミッションを、自分なりの優先順位の判断で対処したとき、自分なりの正論プロセスを踏んでいたはずなのに、従業員の不満が水面下で積み上がっていた。それが表出したとき、正論プロセスは白紙にせざるを得なかった。結果的に1ヶ月で解決策を作り、その後3ヶ月かけて丁寧に組み直しましたが、最初から「組織がどう受け取るか」の翻訳をきちんとやっていれば、という後悔は今でも残っています。

「じっくり考えずに形にしたとき、組織に仕様バグが埋め込まれる」——これが当時の僕の学びでした。翻訳者であるということは、自分が腹落ちしていないものを届けない、という強い意志と、そのために時間をかけるコストを受け入れる覚悟でもあると、今は思っています。ただ、これができているかどうかは、正直いつも自信があるわけではないんですよね。

「何も起きないように」が正解だと思っている

自分の動き方が、同僚には見えていないことがあります。

ある同僚が、別のメンバーと1on1をしたとき、僕のことを話題にしていたらしい。「なんで彼はあんなに忙しいのかわからない」と。

そのことを後から聞いたとき、正直なところ、腹が立ったり傷ついたりはしなかった。「ああ、だからこの人はこういう動き方をしているんだな」と、客観的に受け止められた。

その同僚は、有事のときにきちんとファシリができる人でした。でも、有事になる前の準備に時間を使っているタイプではなかった——たぶん、そういうことだったんじゃないかと思っています。「何かが起きてから対応する」と「何かが起きないように備える」は、単なるやり方の違いではなくて、思考の形が違う。reactiveとproactiveは、そのくらいの深さで異なっているんじゃないかな、というのがそのときの気づきでした。

ただ、自分のスタンスとしては——

自分のフレームワークはproactive、「何も起きないように備える」ことにあります。前もって関係を構築し、シグナルが来る環境を作り、有事が有事になる前に消化しておく。これが自分の設計思想の核にあります。

ただし、これには注意が必要で——proactiveであることを思考や姿勢として持つことと、それを行動として組織に「見せるかどうか」は、別の問題だと思っています。

proactiveなのは、日々の準備に表れます。日々の関係構築は目立たずやるものです。コーヒーを飲みながら話す、すれ違いに声をかける、そういうことが積み重なって、有事の手前でシグナルが来る環境ができる。

ただ、それだけで全部防げるとは思っていなくて。準備していなかった方向から何かが起きたとき、reactiveに動く瞬発力や対応力も、自分には必要だと思っています。

シナプスという発想

ここで、自分が実際にやっていることの話をしたいと思います。

キーワードは「シナプス」です。これは自分でインタビューで語ったとき、自然に出てきた言葉で、今も一番しっくりきている比喩です。

脳の神経ネットワークを想像してください。シナプスが豊富に張り巡らされている状態では、情報がスムーズに伝達される。逆にシナプスが細かったり断絶していたりすると、信号が届かない、あるいは遅延する。

組織も同じだと思っていて。エンジニアリング側のVPoEが、人事・労務・法務・経理・経営企画・広報の人たちと、業務上の接点だけで関わっていると、シナプスは細いままになる。何かが起きたとき、「あの人に聞いたらいいかも」という第一想起が自分になっていない。

だから、意図的に接点を作る必要がある。

まず「自分の人となりを知ってもらうこと」から始まって、それが積み上がると「何かあったときの相談先として第一想起されるポジション」になっていく。その先に、「相手から先にアラートが来る状態」がある。

こうなるまでに時間はかかりますが、この順番は変えられない気がしています。近道をしようとすると、たぶんどこかで崩れるんですよね。

相手から先にアラートが来る、というのはどういうことかというと——冒頭に書いたあの連絡が、そういうことでした。人事の担当者から「最近、エンジニアチームの中で少し雰囲気が気になる動きがあって」と。こちらからは何も聞いていない。相手が「この人に言っておいたほうがいい」と判断して、自発的に届けてくれた。

これはシナプスがあったから起きたことです。シナプスがなければ、相手は黙っているか、「あそこのチームの話なんだから関係ない」と判断するか。少なくとも自分への連絡は来なかった。

退職リスク・申請遅延・予算策定——さまざまな場面で、「やばいんじゃない？こういう準備しておいたほうがいいよ」という声が届いてくると、対処のタイミングが変わる。後追いではなく前倒しで動けるようになる。これがproactiveな設計の、現場での姿なんじゃないかな、と思っています。少なくとも、自分にとってはそうだったかもしれない。

具体的にどうやってこのシナプスを作っているのか、それは後でまとめて書きますが、一番わかりやすいのはランチに誘うことです。それだけのことでも、少しずつ関係の線は太くなっていきます。

「じゃんけん事件」から学んだこと

シナプスの話をするとき、必ずセットで出てくるエピソードがあります。

事業側からコーポレート側に異動したとき、コーポレートの人から言われた言葉がありました。「これまでの言動が、少し高圧的に映ることがあって」「リスペクトに欠けると感じる場面があった」と。

最初は何のことかわからなかった。自分の中では普通にやっていたつもりだったので、正直、戸惑ったんですよね。

具体的に掘り下げてもらって出てきたのが、「じゃんけんでリーダーを決めよう」という発言でした。

僕の感覚では、これは純粋にフラットな気持ちで言ったんです。誰がリーダーをやってもいい、みんなが同じくらい能力があるんだから、決め方もフラットでいいじゃないか——というロジック。でも受け取る側は違った。「上下関係をこんなに軽く決めるのか」「リスペクトがない」という受け取られ方をしていた。

これはシナプスがあったから指摘してもらえました。なければ、相手は黙ったまま距離を置く。評価が下がっても報告されない。自分が気づかないまま、静かに信頼が失われていく——それがシナプスなしの状態です。

「指摘してもらえた」ことの価値は、本当に大きかった。

この経験から気づいたのは、職種ごとに育った文化が違う、ということです。自分の中には昔から「役職はロール違いで、偉さではない」という感覚があって——そのロジックは自分の中では一貫していて、今も正しいと思っています。

でも、正しいロジックを持っていることと、相手の文化の中でそれが同じように受け取られるかは、全然別の話でした。エンジニア文化の「フラット＝良いこと」は、コーポレート文化に持ち込んでも同じように機能するとは限らない——気がするんですよね。

思想として正しくても、コミュニケーションとして正しいかどうかはイコールではない。それを伝える言語や行動の選択は、相手の文化によって変える必要がある——そのズレを自覚できていなかったというのが、この経験で一番大きかったかもしれないです。

「広い心というか、いらっとすることが減った」というのが、この経験のあとの自分の正直な感想です。違いを理解することで、驚きよりも理解が先に来るようになった。

このズレに気づけたのも、シナプスがあって、正直なフィードバックをもらえたからです。

普段からできることが、結局一番大事だと思っている

じゃあ、シナプスはどうやって作るのか。

「最初から仕込もうとしないことが、最終的に仕込みになる」——これが正直なところで、ちょっと逆説的に聞こえるかもしれないですが、自分の体感ではそういうことなんですよね。

一番効果があると実感しているのは、ランチです。業務上の接点がなくても「ランチ行きませんか」と声をかける。これが自分の強みでもあって、初対面の相手でも、なぜか自然にできるんですよね。正直なんで自分がそれをできるのかはよくわかってないですが、躊躇がない。

リアルで会うことの効果は大きくて、話し方が口語になる。会議室で業務の話をしているときとは違う言葉が出てくる。「実はちょっと困ってることがあって」という話が、ランチのときに出てくることがある。これは心理的安全性が生まれているということで、その状態を作るのに、ランチという場は機能する。

1on1を申し込む、というのも同じです。業務上の理由がなくても「一度話しましょう」と伝えられる関係が、後々の仕込みになる。廊下やキッチンですれ違ったときに少し話す積み重ねも、同じです。

「この人との関係を作っておかないと後で困る」という打算でやると、たぶんうまくいかない。純粋に「人となりを知りたい」「どんな仕事をしているのかに興味がある」という気持ちで行くと、相手もそれを感じ取ってくれる。何かビジネスの話が出てきたら、それは後からついてくる。

「できればリアルで」というのは付け加えておきたくて、オンラインでも話せますが、距離の縮まり方が違います。物理的な空間を共有することで、言葉以外の情報が動く。それが「この人は信頼していい」という感覚に繋がっていく気がしています。

これは現在の会社の中だけの話ではなくて、前職の人とも定期的にご飯に行ったり飲みに行ったりして、一定の関わりを持つようにしています。

この関係は、自分が相手に時間を使ってもらう価値を提供し続けられないと、自然に断絶してしまう。だからこそ、いい意味でのプレッシャーになるんですよね。「この人と話すと何か得られる」と思ってもらえる自分でいなければ、という感覚です。

幸い、これまでいくつかの会社に勤めてきましたが、それぞれの会社で今でもつながってくれている人たちがいる。これは本当にありがたいと思っています。

ところで、proactiveにシナプスを設計していると、自分が想定していなかった方向から声がかかることがある。

たとえば、VPoEとしての自分ではなく、個人としての自分のキャリアや経験を頼られる場面がある。「この局面でどう判断するか、意見を聞かせてほしい」という形で。役割の外から届く声です。

これも、日々のシナプスがあったから届いた声だと思っていて。こちらが設計していたルートとは別のところから信号が来る——それも、proactiveな設計の結果なんじゃないかなと、そういう経験を通じて感じることがあるんですよね。

「何も起きなかった」は成果として残らない

シナプスを作り、関係を構築し、有事の前にシグナルを受け取る——この設計が機能していたとき、成果は「何も起きなかった」として現れます。

退職リスクが顕在化しなかった。申請遅延が起きなかった。チーム間の関係不全が大事に至らなかった。これらは全部、「ゼロ」として記録されます。

ゼロは説明しにくい。「今期、XXの退職リスクを未然に防ぎました」という報告は、防いでいなければ問題が起きていたかどうかが証明できないので、正直なところ評価されにくいと思っています。reactive寄りの設計だと、このゼロはさらに評価されにくくなる——そういうことは実際に起きているんだと思います。それでも成果はゼロで記録されていく。

それでも、こういう設計思想は自分にとって譲れないと感じています。理由は単純で、「突然起きた」と感じた有事の多くに、後から振り返ると必ずシグナルがあったからです。そのシグナルを受け取れる関係性がなかったことで、結果として後追いになっていた場面を、いくつも見てきました。自分だけじゃなく、組織の中では結構起きていることなんだと思います。

ただ、これが「いつでも正しい」とは思っていないです。

組織のフェーズによっては、関係構築にリソースを使うより、問題が表出してから素早く対応するほうが合理的なときもある。シナプスを作るのにもコストがかかる。小さな組織では全員と話せますが、何百人規模になると物理的に不可能になってくる。

たとえ同じ役職・役割で組織に存在していたとしても、規模やフェーズ、組織のマインドやミッション・ビジョン・バリューの在り方によって、同じやり方をそのまま持ち込めるとは思っていなくて、今もその調整をしながらやっています。「これが本当に機能しているのか」「この投資は本当に必要か」という問いは、正直なところ答えが出ていないんですよね。

ただ、設計の方向性としては、「有事が有事になる前に消化する」という思想を持ち続けていきたいと思っています。それが翻訳者であり執行者としての、日々の仕込みだと思っています。

進行中に正解はわからない——だから、そのときにベストと思うものを選んで、やりきる。それだけのことなんじゃないかな、と思っています。

もし今日、何か一つやるとしたら、それはたぶん、業務上関係のない誰かに、理由もなくランチに誘うことだと思います。