Mogicのかんがえをきく

山根

エンジニアやデザイナーとのコミュニケーションは今も昔もあまり変わらないですね。

山根

「こんなサービスやプロダクトを作りたい」と言ってから「いついつまでにこんなことを成し遂げたい」と伝えます。そこからエンジニアには「難易度はどの程度で、どのぐらいの期間でできそうなの？」って聞きます。デザイナーだと「PCとスマホ両方に対応しないといけないし、ページ数でいうと数十ページあるけど感触どう？」って話しかけます。
要は、彼らが受け取った印象を聞いていく感じです。メンバがこのプロダクト面白そうと思わないとプロジェクトの原動力が生まれないので、やる気が出そうなポイントを見つけながら話しています。

山根

そうですね。同じ仕事をするにしても未来がありそうな方がいいじゃないですか。未来がなさそうな敗戦処理って、やりたくないだろうし。だから「こんな未来があったらすごいかもね」とか「こういう未来が開けるよ」という所を結構しゃべります。

山根

専門職であるなしに関わらず、実はどんな職であっても他の職種の仕事って細かくは分からないんですね。例えば、今みたいにインタビュー記事を1本作るとします。ライターと写真家がいて、同じ場所で仕事をして最後に組み合わせて完成します。ですが、ライターは写真家が細かく何をしているか分からないし、写真家はライターが細かく何をしているかは分からないんです。
分からないけれどもライターは写真家にフィードバックできそうだし、写真家はライターにフィードバックできそうということです。それと同じでエンジニアが作るプログラムや設計は見えないけどフィードバックできそうですし、デザイナーが作るデザインも同じです。
じゃあ、違う職種にまたがってアドバイスをしなきゃいけない、指示を出さなきゃいけない時に何が大事なのかということです。最低限の知識は必要ですが、あとはゴールのイメージを共有できる信頼感でしょうか。信頼できる関係をどう作るかが根本にあると思っています。

山根

もう一つ例を挙げてみます。仮に自分が園芸家だとして、一緒に組む人がかつて園芸家だったとします。要はお互いに共通の細かい知識やノウハウまで持っている状態です。やりやすそうに思いますが、反対に「ちょっと植生のバランスがおかしいんじゃないか」「枝ぶりの仕上がりが甘いんじゃないか」と細々と指摘される可能性がありますよね。つまり、専門職同士の方が実はやりづらいことってあるんじゃないかなと。
そうじゃなくて、お金は出してくれるけど自由にやっていいよというパトロンがいたとします。「今まで見たことのない、感動する庭園を作ってよ」というざっくりした要望になりますから、そっちの方が案外やりやすいものじゃないでしょうか。

山根

専門家からしたら、言葉が通じなくてイライラすることもあるでしょうけど、意外とメリットがあります。専門じゃないから斬新な視点を提供できたり、盲点に気が付けたり、素直にリスペクトできます。分からないから自然と相手に自由度を与えることができますから。

山根

20代の頃、起業する前はありましたね。自分でチームメンバを選べない状況だと、相性の合わない人と組んでプロジェクトが停滞することがあります。人と人の相性は変えられない性質があるので、まあ、がんばるけど高いレベルでは無理かなと半ば諦めていました。もちろん相手が悪いということじゃなくて、合う合わないの問題です。

山根

今は自分で会社をやっていて、一緒にやるメンバをお互いじっくり決めることができますからさっぱりないのですが、大きな会社だとありがちです。そもそも置かれる環境がシビアになりやすいので信頼関係の問題は出やすいかな。
大規模なプロジェクトをすごい人数でタイトなスケジュールでこなさなきゃならないと、どうしてもエンジニアやデザイナーに無理が出ます。そうすると、徐々に技術的負債といわれるものが蓄積するんですね。なんというか、いつもコップの水が目一杯入っている状態というか。
僕らビジネス側から見ると、ちょっとした修正だよねというのが彼らにとってすごく手間がかかるものになる。そういう局面で妥協して作らざるをえなかった我慢がいつか限界に達して、ザザザッと信頼関係が低下します。
分かりやすく、家を建てるとしましょう。最初にきちんと設計して作った家に無理やり毎年一部屋ずつ増築していくと、どこかで足せなくなるような気がしませんか？そんな感じです。本当は土台から見直さなきゃいけない時なのに、達成すべき目標があるから次から次に毎年部屋を作れと言われたら「もうそんなの難しいですよ」となります。
ビジネスのゴールだけでプロジェクトを強制してしまうと、どうしてもエンジニアやデザイナーは疲れてしまいます。

山根

エンジニアは、インフラ設計、システム設計、プログラミングと専門的にいいますが、建築でいえばインフラ設計は地盤を調査して土地をならして基礎を入れて、しっかりした土台を作ってみたいなところなんですよ。

山根

デザイナーのところを建築で言い換えれば、この土地は冬に南から光が入りにくいから屋根の角度を変えておこうとか、断熱を入れとこうとか、アウトドア好きだから入口には収納多くしようとか発想します。
Webで言い換えれば、ユーザーがスマホで見ても気が付けるようにボタンの形や色に配慮しとこうとか、慣れてきたらショートカットできる導線を作らなきゃねとか、そういうものが同じなんです。

山根

性格からいって誰かに仕事を依頼するときは、自分で最初からやってみないと気がすまないのでやりましたね。プログラミングやデザイン、映像制作もとりあえずやりますが、数週間やってみたぐらいのレベルで満足です（笑）。

山根

多少はあるでしょうね。ざっくりデータベースがこんな感じとか、HTMLのコーディングはあんな感じ、コンセプトワークはそんな感じというのを体が覚えていますから。専門職が止まってしまうポイントが早めに分かります。細かい専門用語は分からないけど、ふわっと雰囲気で話しかけられるので、そこはやりやすいです。

山根

より精度を上げて話しますと、エンジニアはデザイナーよりブラックボックスが多いんです。機械のエンジニアと似ているともいえます。

山根

そうです、いくら聞いても本当は中身が分からないんですよ。システムが完成したとしますね。データベースがこう、接続先がこう、インフラがこうと聞いたり、ドキュメントを見たりします。でも、実際に実物が目に見えるわけじゃなくてコードで書かれています。
パソコンという機械が食べやすい文字列で書かれているわけで、人間が直感的に理解できるものじゃないんですね。だから予想外の不具合は起きてはじめて分かる。家なら、住む前に床がゆがんでいるのは直感的に分かりますから。

山根

僕らは細かくコードをチェックするわけにはいかないので仕方ないところが出てきます。で、必ずどこかがブラックボックスになっちゃうんです。「こういう風に作りました」と言われたら「そうなんだよね」って、信じるしかない地点があります。
だから、そこがエンジニアとのコミュニケーションで一番難しいところになるんですよ。つまり、どこまで行っても分からないんですよね。分かっているようで分からない。
そういう状況で、もしエンジニアが悪意を持つとどうなるかっていう話です。当然分からないわけですから、やろうと思えば悪さができます。ちょっと穴をあけてみた、データを持ち出してみた、うまくいかなかった部分を隠してみた、とか。
あと、ブラックボックスが多いがゆえに既得権益になります。エンジニアがプログラムを全部抱えているので、それを逆手に仕事をしないということもできます。ビジネス系の担当者がエンジニアから「それは難しいですね」って言われたとして、ちょっと違和感を感じていたとしても、どうやって作っているか分からないから「ああ、そうなんだ」って納得するしかないんです。エンジニアは悪意を持てば「できませんね」と言えたり、自分が面倒だからという理由で断われたりします。

山根

だから、そこら辺も考えてエンジニアは相性や人間性を極めてよく見ていますね。デザイナーも同じです。究極的にいうと、どの職種もそうですけど。どの仕事も全部見られるわけじゃないので細部は分からない。だから、信頼できる人なのかどうかが大事です。
知らないうちに誰かが1カ所サボっていたとします。そうすると、他のエンジニアが見て「ああ、真面目にやってるのが馬鹿らしい。自分もサボろう」ってなる可能性があります。サボろう、サボろうという連鎖がチームとしての生産性を下げ、ぬるま湯な風土につながる。がんばりすぎてもダメだけど、サボりすぎてもダメ。適度な塩梅でやれる人か、人が見てなくてもやれる人かを見極めていき、信頼関係を育てていくのが大切かと思います。

山根

個人的には信頼関係をベースに置いていますが、さすがに組織なので多重にレビューされていて心配はしてないです。CTOの藤井、執行役員の加藤が全ての設計やコードをチェックしているので、専門的なコメントは違うルートで入っていますね。

山根

分かりますね。どこがどれくらい伸びるかなっていうのも何となくつかめます。「この人はおそらく面接の時はちゃんとしているけど、1年後に慣れて緩んできて、2年目に何かあるだろうな」とか分かりますね。何となくの予想ですけどね。

山根

このケースの根本にあるのは、自分自身への節度だと思ってるんです。他人から見られていると自分を律することができるけれど、見られてない時はついラクをしてしまう。誰しもそんな部分はあるかと思いますが、そこを自覚しているのか、自覚していないのか、それが分岐点ですね。もしボヤッと無意識で自分をラクさせているなら、未来において表面化します。なぜなら無自覚だからラクをしたい自分がいつ出るかコントロールできないからです。
新しい会社に入れば、1年目は業務や人間関係に緊張感がありますから大丈夫です。2年目はくりかえしが増えますから、ふっとあちこちに出ちゃうんでしょうね。仕事はチームプレーですから、自分がラクをするということは誰かにシワ寄せがいきます。つまり、チームとしての歪みとなって見えてくる。やがて歪みは何かの問題として表面化しますから、2年目に何かがあるだろうと予想できるわけです。

山根

違いますね。僕と合う人は僕の強みをいいなと思ってくれて、僕がないものを持ってくれている人になります。どちらかといえば僕は広く浅く見るのは得意なんですけど、一つを深くできないタイプです。だけど、CTO藤井はすごい深く、深くいけますね。いい相性というのは互いに足りないところが埋まるように選ぶわけです。
そうすると、執行役員の二人でいえば僕と性格が違いますから、違う人を選ぶべきです。各部門のチーフも同じで、チーフがいいな、チーフをいいなと思う人が必要なわけです。僕が前面に立って採用したら、ズレちゃいますね。だから、あんまり面接に登場しないのはそんな理由があります。みんな自分たちに合う人を責任もって選んでほしいんです。かといって、似た人ばかりになっては困るので、一つだけ条件をかけています。今のチームにいない個性を選んでということです。結構、難しいこと言ってますね。

山根

なぜエンジニアを採用するのが難しいかですよね。一般的にはエンジニアの絶対数が足りない、スタートアップで取り合いになっている、大手に吸収されているという話になりますが、少し考えは違います。
たしかに報酬や安定は大事でしょうが、レベルが高い人ほど自分にとってベストな環境を求める気がしています。先端技術にトライしたい、一からすべて組み上げたい、クオリティの高い議論をしたい、そういう環境をうまく準備するのが難しいからかなと。
サービスで何か問題があったら、エンジニアが最後の砦です。一番負担がかかるし、責任を負いやすいのできちんと理解してくれるマネジメントがいないとつらいんじゃないかな。「すぐなおせるだろう、簡単なことじゃないか」と言われそうだったり、「DX、UXなど横文字が並んでるから、実はIT感覚が薄いんじゃない」と思われるのが厳しいでしょうね。

山根

エンジニア含め、大切なのは信頼関係に従って任せるということです。だから、言いたい時には言うんですけど基本的に仕事の時間をどう使い、どういう段取りでいくかといったところは口を挟まないですね。昼休みにチームでワアワアとモンハンというゲームをやったりしてますけど、何か目的があってやっているんだろうと思っています。本人たちは「ただ楽しいから」っていいますけどね。任せているっていうことです。突き詰めると、自分の裁量が適度にあったほうがいいんじゃないかなと。
別にやりたくないと思ったら「やりたくない」って正直に口にしてくれればいいんです。ただし、こちらは「それは何の意味でやりたくないの」と聞くわけです。説明を受けてなんかおかしいと思えば「でも、それは個人的なサボりじゃん」と言います。「ああ、まあ、それはそういうところありますね」なんて言ったら、「じゃあダメだよ、やんなきゃ」って返します。だけどそれじゃ足りないから「これをやる意味って他にもあってね」と説明を重ねます。
だけど、「これはやりたくない。なぜならこういうふうに将来、不具合が増える確率が上がります。この不具合のリスクはこう大きいんです」と言われたら「それはそうかもね。じゃあ、やめよう」という話になります。
任せるんだけれど、実際に出てくるリアクションに対して、それが本当にサボりなのか、意味があるのかはちゃんと見定めてフィードバックする。それが健全なのかなと思っています。きちんと議論するというフェアさですね。それがやりやすさの一つかな。

山根

エンジニア以外も同じなのですが、大企業は自分の視点だけで採用できないんですね。自分だけが見ることはできないし、他の部署から異動もしてくるから、ベースがバラつきます。会社の業績目標があり、個人の達成目標があり、マネジメントへの上昇志向があり、給料を上げたい人もいれば、転職ステップしたい人もいるし、早く帰りたい人もいる。
みんなベクトルがバラバラなんです。サービス自体が大きくて、1つのチームの仕事自体が局所化しているから、最も分かりやすい共通項、つまり数字でガチっとまとめるしかなくなります。数字は強制力があるけど、チームとしてそんなにまとまりが出ないし、やり遂げ感も薄くなりやすい。だからミッションや使命というワードでまぶして1つのまとまりを醸し出すけど、最終的には数字が強く働きます。
ですが、Mogicだと「自分たちが信じた人と一緒にやりたい」「こんなライフスタイルでやりたい」「石神井でやりたい」「新しいことに挑戦したい」っていうベースで集まっているので、まとまりやすいですし、フィードバックを悪く取られないです。土台が整っていているから、スムーズに進むんじゃないでしょうか。

山根

意識してトレーニングしたことはないですね。専門職というより、一人の人間として話をしているだけです。ちょっと特殊に思われるかもしれないですが、エンジニアだと人と話すよりコンピュータと話すほうが得意な人がいます。コンピュータの方が曖昧なニュアンスで接してくる人間より、安定した返答があるので分かりやすいという話です。もしそういうコンピューター的な会話が好きな人がいれば、端的に言うようにします。文章を短く、誤解の少ない単語を使い、ニュアンスを消して話します。
ですが、それだけだとサービス作りで限界が見えるんですよね。結局、サービスって使う人のためにありますから、人間への理解がないと良いサービスはできないと思ってて。これは論理的な帰結というより信念に近いものですが。
作った人だけが分かる独りよがりなシステムって、割とできちゃうんですよ。それはデータベース的な発想からすれば最適だろうけど、素人の一般ユーザーなら分かりにくいし、使いづらいんじゃないかって感覚になりますから。
Mogicとしては、人が使って心地よいサービスを目指しているわけですから、エンジニアにも人と触れ合う楽しさや曖昧な会話を楽しむ良さが伝わるといいなと思っています。イベントを一緒にやったり、即席のチームで小さなプロダクトを作ったり。あれこれやって、コンパクトな会話にしつつも、楽しいニュアンスも混ぜて、人らしさを入れていくというのはやりますね。

山根

とりあえず、「状況ってどうなの」って聞いてみるんですね。そうすると、何か返答があるじゃないですか。返答に対して論理的に筋を組み立てていきます。「ここがそういう原因で正しいとするなら、あっちはこうならないと整合性が取れないんじゃない」「不具合の種類からいって確率的に原因は3つに絞られそうだよね」とか。
そういうふうに論理的に絞りながら、エンジニアの顔を見ています。ハッとした顔になるのか、それは検討済みだという顔なのか、しゃべりながら整理がつきはじめた顔なのかといった感じです。気づきがあったという顔をしたら、そこは何だったかなと思って、掘り下げて聞いてみます。
システムの不具合に限らずアクシデントというのは、当事者同士の盲点が重なって発生しがちです。そして原因が分からないと全体がパニックになります。本当はここだけ押さえればすぐに終わるのに、押さえる場所が分からないから被害が拡大する。
じゃあ、なぜ分からなくなるか？それは頭の中に情報を詰め込みすぎだと思うので、一つずつきれいに削ぎ落とすお手伝いをするんです。スペースが空くと冷静になれるじゃないですか。だから、高度な専門領域でも心理的な問題だと思って、顔を見ていますね。

山根

エンジニア、デザイナーだけじゃなく、セールス、マーケティング、経理、そして建築士、宅配屋であれ、ある程度トラブルシューティングはお手伝いできるかなと慢心しています（笑）。なぜかといえば、彼らは現場のプロフェッショナルで本当は解決できる能力が十分に備わっているのに、ただ気が付けていないから問題が解けないと想定しているからです。
問題を解決できる一番手はプロフェッショナル、専門家。彼らが解決できないのは、彼らの思考だと見えない場所があるから。つまり盲点があるので、彼らがそこに気づければいいだけだと。だから、あんまり職種とか関係なく絡んでいきますね。

山根

問題を解決しうるのは当事者だから。もし自分がマネジメントのポジション、サポートのポジションにいるとすれば、現場の人を助けることしかできないじゃないですか。
じゃあ、どう助けるのかといえば、プロフェッショナルをパフォーマンスさせることだけ。つまり、一時的な彼らの混乱を取り除くだけです。どう混乱しているのかといったら、いろいろなケースを考えすぎている、可能性を広げすぎてるってことですから。だから引き算して、割り算して情報を圧縮できれば、彼らが解けるということでしょうか。

山根

Webデザイナーは、エンジニアと違う意味で非常に難しい職種です。コンセプトワークみたいな概念的なところを作らなきゃいけない。それを実際のモチーフ、色、ニュアンスで表現する技術がなければいけない。その技術を表現するためにデザインのソフトウェアをマスターしなきゃいけない。ソフトウェアはどんどん新しくなるのでスキルをアップデートしないといけない。
次はトップページなのか、最下層のページなのか、スマホなのか、アプリなのかによってレイアウトを使いわけないといけない。グラフィックと違って、ボタンを押すとアクションがあって次のページに移動するから、前のページと次のページの整合性を取らなきゃいけない。画像をうまく切り出して軽くしなきゃいけない。コーディングというプログラムにしてHTMLとCSSで組んで不具合がないか確かめて、場合によってJavaScriptとプログラミングを組んだり、エンジニアとコミュニケーションとって仕上げに入って、運用が始まったら改修を加えて整合性を取り続ける。大変そうじゃないですか。

山根

Webデザイナーは10年前、20年前はまだやりやすかったんです。グラフィックデザイナーじゃないけど美術やりたい、アートやりたいっていう人が入りやすい登竜門だったんです。でも今はデバイスが増えて、ウェブのグラフィック能力が上がり、インタラクションという動きが求められるので、一人前になるレベルがかなり上がってしまったなという印象です。
それをトータルで学べる場はごくごく少ないでしょうね。おそらくレベルの高いデザイナーを中途採用しようと思ってもぜんぜん見つからないでしょうが、仕方のないことです。

山根

大学で学んでも求められるプロフェッショナルの5％ぐらいのレベルにしかならないでしょう。仮にウェブ制作会社に入って修行を積んだとしても、サービスを端から端まで作れるデザイナーとはまた違います。コーポレイトサイト、ランディングページ、キャンペーンページ、ブログサイトはある程度テンプレ化していて、そこから先のデザイナー文法は広がりにくいものです。
もし一からサービスを作るなら、コンセプト、トンマナ、動きに実験的な思考が求められるし、ユーザビリティと呼ばれる想像力はサービスをいくつも作って、多方面からフィードバックがないと積み上がらないと思っています。

山根

それぞれの経験からノウハウを引き出し、チームに蓄積していくのはさらに難しい。蓄積するのも難しいし、新しく入ってきた人に教えるのにもすごい時間がかかるわけです。積み上げるのに5年は平気でかかる職業ですね。

山根

一般的にウェブデザインに入る前にWebディレクターや仕様設計者がいて、こんな画面にしたいというワイヤーフレーム、画面の設計書が出てきます。当然、デザイナーはそれに従って作ります。つまり、普通にWebデザインの作業をしていると実験的なレイアウトや自分のアイデアを入れにくくなります。
ウェブ制作会社だとクライアントや代理店から依頼があって、おおよその色合いやサイト構造が決まり、ディレクターがいるので進めやすくはあります。でも自分たちのサービスで同じくディレクターが主軸になって進めたら、デザイナーの自由度は上がりません。
たくさん仕事をこなしても意外と自己表現の幅が広がらない。だけど、もともと美術が好きでアートをやりたいという動機でスタートしている人が多いから物足りなくなっちゃうんですね。そこらをカバーするためにプロダクトによりますけど、Mogicだとデザイナーを中心にコンセプトデザインから、配色の決定、ロゴの作り方とか主導権を持ってすべてやってもらいます。範囲が広くなりますが、楽しいんじゃないかな。「つらい、つらい」って言いますけどやった感はありますよ。デザイナーにはそういう自由度を渡している感じです。

山根

基本は同じです。細かいコーディングの仕方は分からないんですが、直感的に使いづらい、よく分からない違和感は感じるわけです。その時に多くの言葉を連ねると混乱するので、一番修正してもらいたいポイントからとりあえず3つだけ絞って伝えます。
10個気がついたとしても3個くらいにしておかないと「ええー、この人ヤダ」みたいになります。特にデザインは自分の感性と一体化しているから。こちらが事務的に修正点だけ言ったつもりでも相手にとっては自己否定になっちゃったりします。だから、自己否定になりにくいレベルでかつ、頭に入りやすいサイズのフィードバックをまずかけてみるんですね。
そうするときちんと考えているデザイナーは「実はこういう背景があって、ああいう意図があって、そういう仕上がりなんです」って言います。で、「ああ、なるほど、でも今言ってくれた意図ってさ、パッと見で伝わるのかな。小学生が使ったとして説明なしに分かるのかな」って聞いてみるんです。「うーん、伝わらないかも」ってなって、「じゃあ、ダメじゃん」っていう会話です。「でもさ、コンセプトはいいんだから、伝わるように工夫するにはどうしたらいいと思う？　じゃあ、アイデア出ししてみよっか」と、そんな流れです。
本人がもともと持っている意見を大事にしつつ、問題なのは彼らの表現技術ですから、そこにフォーカスしてより良いものを作っていくということですね。伝えるポイントを絞りつつ、例え話や比喩を多用してニュアンスを膨らませます。
プログラムもデザインもそうなんですが、作り手が作り込めば作り込むほど自分の世界に没頭しちゃって、他人との橋渡しを削ります。リテラシーの高い人だけを前提にして敷居を高くしすぎる。気がつくと分かる人にしか分からないものを作っている。素人がスルスル登れるハシゴをかけてあげなきゃいけなくて。そこを伝えることが多いですね。

山根

デザイナーはデザイナー特有の盲点が存在しているので、そこをうまく開いてあげるという感じです。失敗するときは、やっぱり作品に対する愛が強すぎるんですよ。手抜きをして失敗することはほとんどないですね。大抵は作り込みすぎて失敗します。結局、サービスは作ったものだけじゃなく、相手があって成立するから7割作り込んで、3割抜いてあげるのでちょうどいいかな。使い手がさわった時に3割埋めてもらって完成するゆるさをつくってあげないとユーザーが入り込めなくなっちゃうわけです。本当は意図的に抜かなきゃいけないところをデザイナーが欲張って埋めがちなんです。それはあえて抜いたほうがいいよ、みたいな話をしますね。

山根

良かれと思っていろいろ載せちゃったりとかするので、その人が持っている感性は尊重しながら、それだと情報量が多すぎだよと言っている感じです。

山根

共通するのは、のめり込む人たちなんです。エリアを決めて、その中をめちゃくちゃ深く掘り下げられる人たち。絵でいえば、額縁があるからその中に限ってめちゃくちゃ書き込むじゃないですか。職人ですよね。そして自分たちがつくっているものへの愛情が半端ないっていう意味では一緒です。
違いは、デザイナーは美しいものに触れたり、心が動かされるものが大好きでその感性をベースに仕事をしています。エンジニアは数学的な美しさですか。簡潔に物理法則を表現できるみたいなエレガントさ。できるだけ簡単に素早く多くのことを成し遂げられる美しさみたいな、論理的な美しさを追求している気がします。共通しているのは深さ、違うのは琴線に触れるベクトルでしょうか。

山根

プロフェッショナルは独自の美学を持っていると思うのですが、専門職ごとにどこに美学を感じているかが異なっていますね。

山根

僕らは実物を作ることはできないけれど、彼らとアイデアや着想でコラボレーションできるわけです。よく着地点の分からないよもやま話をするんです。全然関係ない話で笑ってくれると、「あの会話楽しかったな」っていうのがプロダクトに出ますね。暗い会議なら暗いものができるし、真面目な会議なら真面目なもの、ゆるすぎるものはゆるいものが不思議とできるのが面白いですね。

山根

影響しますね。やっぱり人なので、暗く重く長いフィードバックをかけると重い感じのトーンのアウトプットが出てきて、生産性が落ちてきます。

山根

スピードや不具合に出ますね。「あれ、なんか終盤のここ早いはずなのに逆に遅くなってない？」「不具合でもこのタイプはまずそうじゃない」という出方をします。不具合が多さはさらなるスピードダウンにつながります。
さっきも言ったとおり、メンタルがこんがらがるわけですよ。ずっと突き詰める人たちなので、直線的に突き詰めていたりするとちょっとブレたり、詰まったり、解けない問題になると「ううぅ」となって頭がいっぱいになります。
そこをちょっと話しかけてシュッとメモリを開放してあげると「ああ、そうなんだ。これなら簡単にクリアできますね」となります。もし止まったままだと、プロジェクトの他メンバも足が止まってきて、全体がトーンダウンしますから。
詰まっている時は顔色も良くないんですね。つまり、暗い雰囲気だったり、オーラがに濁っていたりするようなイメージです。「ああダメだ、あの人は何かやらかしてる」って、詳しくは分からないけど止まっているのが伝わってきます。

山根

これはエンジニアやデザイナーだけじゃなくて、他の仕事でも一緒かなと思っています。
例えば、今から文章を書くとします。文章をザーッと書けていて、詰まりぎみだけどまだ書けそうっていう時は明るいわけです。でも、本当に書けなくて書けなくて、自分の心が折れそうなゾーンだとすると、もう家から出たくないとなります。その暗さって、最初のものとは違いますよね。
エンジニアだけで解決しなくてもいいので、早めに聞くようにしています。「どこか詰まっているんじゃない」って。聞いて僕が答えられない問題なら、「じゃあ、ちょっとCTOか、チーフに聞いてみたら」「周りのエンジニアに聞いたほうがいいんじゃない」「デザイナーに聞いたほうが早くない」といった話をするわけです。つまり、僕が広げられなくて他の人が広げられたりするので、まずは開いてあげられるといいかな。
会社経営も仕事も、人に関わっている問題は同じだと思っていますね。重く苦しい感じでみんなが違う方向を見て混乱しているとして生産性が高いイメージありますか？

山根

ないですね。みんなが笑っていて余裕があって、問題もサクサク解決していたら生産性は高そうです。つまり、一人一人が詰まらないように頭を整理してあげたり、バランスを取ってあげるという意味では、経営と同じです。みんながリズム良く、負荷なく、ずっと続けられるようにするっていうのはプロジェクトも経営も一緒だと思います。

山根

おいしいものをチラつかせるっていうことですか（笑）。やはり、おいしいものをみんなで食べるっていうのは分かりやすい。だから、プロジェクトが詰まってきたら「もうしょうがないな、ゴールしたらすごくおいしいものを食べに行こう」とか。
「この辛い状況が実は単純なことなのかもしれない」と思わせたいんでしょうね。つらいけど、おいしいもの食べられるかもしれないというストーリーはちょっと笑い話になるじゃないですか。そうじゃなくて、自分の人生がかかっていると思い込むとつらい。「おいしいものを食べて、切り替えていけばいい話なんだ」と思ってもらうところですかね。

山根

わかりやすく、おいしいものですよ。

山根

こちらこそ、ありがとうございました！