マネージャーに向く人、向かない人
及川卓也氏（以下、及川）：今のお二人の話だと、どういう人が（マネージャーに）向くか、あるいはどういうスキルが必要かというところはなかなか紐解けないかもしれないんですけど、なにかヒントみたいなものをお話しいただければ。
井原正博氏（以下、井原）：マネージャーに向いているかどうかはわからないんですけど、いろいろなことをやってみたらいいんじゃないかなとは思うんですよね。
僕は、別に自分がどれぐらいの成果を出したかはわからないんですけど、それが成果だったとすると、別に自分でやりたいと言って始めたわけではなく、「やってみて」と言われてやってみたら意外とできた。でも、それはやってみなければ起きなかったことだなと思うんですよね。
だから、「意外と絵を描いてみたらうまかった」「歌を歌ってみたらうまかった」「釣りしてみたらめっちゃうまかった」とか、いくらでもあるんですけど。
そういうことって、必ずしも自分自身が選択したものが正しいわけではなく、それが与えられたものであってもチャレンジしてみると、本当は世界が広がるんじゃないかなということはあとから思いました。
及川：そうですよね。スティーブ・ジョブズで 「Connecting the dots」みたいなやつで、なにか1回経験したやつがそのあとに生かされてきたりするということと同じかなと思います。
ただ一方で、そのやり方をするには、マネジメントでいうと、一旦マネジメントやリードをやってみて合わなかったときにそれをやめられるか、という問題があるような気がするんですよね。人事制度的に。そこはもう少し柔軟になるといい感じですかね。
井原：まあ、制度なんかどうでもいいですからね。
及川：なるほど（笑）。
井原：はい。ぶっ壊そうぜ、と。
及川：わかりました。杉浦さん、なにかありますか？
杉浦正明氏（以下、杉浦）：そうですね、向く人向かない人はあまりないと思うんですよね。僕自身も向いていないと思っていたので。スキルも後天的に身につけるものだと思うんですよね。必要になったらやればいい。
僕の場合はスタートアップへの転職などがきっかけでした。3人ぐらいしかいないところに入ったので、そうすれば自ずと自分がプロダクトマネージャーや人事的なことをやらないといけない。そういうところで身につけていった。だから後天的に身につけられるものだと思いますね。
身につけ方は、一番手っ取り早いのは同じ立場の人と情報交換することですよね。同じようにスタートアップで戦っている人や、大企業でも、マネージャーとして戦っている人とコミュニケーションする。
業界の最先端の人と情報交換することで、そういう知見が入手できるので。今日のこういう場もそうだと思うんですけど、やっぱりそういう場に顔を出して情報を集めることが大事かなと思います。
マネージャーに向いているのはドM？
及川：なるほど。わかりました。そうですね。確かに後天的、あとから身につけるというところはそのとおりかなと。肩書きが人を育てるというところはあると思います。
「あなたはプロダクトマネージャーです」「あなたはリーダーです」となったときに、視座が高くなったり、むしろ自分で足りないところを人に聞きに行ってアドバイスを求めたり、もしくは自分でなんらかのかたちでそのスキルを伸ばすように努力したりすると思うので。それが与えられたものであったとしても、いろいろなものを捉えてみると、実は向いていることにあとから気づいたりすることもたくさんあるのかなと思います。
井原：なんか、ドMじゃないですかね。
（一同笑）
つらくなかったですか？ やっていて「つれーなぁ」「めんどくせー」みたいなことがいろいろあるんですけど、その苦しみを楽しいと思ってエンジョイできないとけっこうつらいんじゃないかなと思います。
及川：それが向いている人ということですね。なるほど。確かに井原さんはドMですからね（笑）。
井原：僕はドMなんですけどね（笑）。
及川：井原さんって……いつでしたっけ、あの記事が出たのは。2週間ぐらい前？
井原：2週間ぐらい前ですかね。
及川：自分でどういった内容か言っていただけたら。
井原：もしかしたら読まれた方がいるかもしれないですけど、「エンジニア 超長距離走」で調べると記事が出てきます。はてブが500ぐらいついた、僕がいかに160キロとか300キロの大会を走るようになったかという話があって。エンジニアが超長距離走でPDCAを学ぶという完全なネタ記事なんですけど。
それでたぶん出てきそうですね。
及川：（スクリーンに記事を表示して）これだ。
井原：それです。
及川：この間ヨーロッパで走られたのは何キロでしたっけ？
井原：330キロですか。
及川：それを何日で走られたんでしたっけ？
井原：150時間ですね。
及川：150時間。という方なので、ドMです（笑）。
井原：まあ、そんなにMじゃなくていいと思うんですけど（笑）。
杉浦：そんな人なかなかいないですよね。
井原：いないですね。いなくていいと思います。
杉浦：（笑）。
井原：まったくおすすめしていないです。
及川：長い記事ですよね。でも、むちゃくちゃ参考になるので。なんの参考かよくわからないけど、参考になりますから（笑）。
井原：なんの参考になるのかわからないですね。ランの参考にはなると思います。これは一応若手エンジニアに向けて書いてくれと言われて書いたんですけど、ぜんぜん勧めないですね。
及川：さっき控え室で話をしていて、私もちょっと走るんですね。井原さん、この間のあれはどこでしたっけ？ イタリア？
井原：イタリアですね。
及川：イタリアですね。「イタリアを走られたあと、次はいつ走るんですか？」と聞いたら、「いや、もう長いのは走らないで、次は12月に70キロです」と言われた時に、私週末にフルマラソンを走るんですけど、「フルマラソンは短いんだ」と思って、別の世界のことを知りました。
井原：いえいえ、とんでもないです。
エンジニアの評価はどうすべきか？
及川：脱線しましたけれども。質問がたくさん来てますね。ちょっと見てましょう。「エンジニアの評価について教えてほしい」。ちょうどこれは（スライドの）次ぐらいに入ってるんじゃないかな。
評価システムの話があるので、これを先にやっちゃいましょうか。エンジニアの評価。ずばりお二方にどうやられているかをお聞きしたいと思います。じゃあ、まず杉浦さん。
杉浦：3つ軸がありますね。エグゼキューションとエッジとバリューと呼んでいるんですけど、この3つの軸で評価をしています。
エグゼキューションは、いわゆるエンジニアであれば、コーディング力や、「きれいなコードが書けるよね」「設計できるよね」という基礎的な技術力のことです。
エッジは、専門能力でその人にしかできないこと。そのメンバーの代替不能性、得意なことはなんなのか、ということですね。
3つ目のバリューは価値観のところで、例えば僕らの企業ミッションは「経済情報で、世界をかえる」なんですけど、ミッションに共感してもらえるか。あとは「7つのルール」という企業の価値観であるバリューがあって、先ほどの「異能は才能」もその1つですし、あとは「渦中の友を助ける」というものもあったりして。
僕らはやっぱりチームプレーなんですよね。つまりチームプレイなので、「自分の仕事が終わったからもう早く帰ります」ということは、僕らの会社の価値観とはそぐわない。チームで困っている仲間がいれば助けるとか、そういう点も評価に組み込んでいます。
なので、このエグゼキューションとエッジとバリューで評価しています。
（及川氏がスクリーンに「7つのルール」が記載されたページを表示させたのを見て）あ、いいのが出てきますね。さすがのファシリテーション能力（笑）。
及川：（笑）。
杉浦：あとは、特徴的なのは360度フィードバック。上司から部下だけではなく、同僚同士とか、部下から上司とか、360度でこの3つの軸に当てはまっているかを評価していますね。これはメンバーのフィードバック作業が膨大になり、めちゃくちゃ大変なんですけど、上司から見えない景色も見えてくるので、フェアに全員が評価されるような仕組みを整えています。
及川：はい。わかりました。井原さんはどうされていますか？ 今の会社と、過去の経験も踏まえてでけっこうです。
井原：いろいろな会社でいろいろな仕組みがあるとは思うんですが、僕はクックパッドの頃から基本的にOKRで設定と評価をやっていました。
実際はOKRで目指したところ、例えば目標設定だと思うんですけど、目標設定と実際に給与を決める評価はあまり関係なくて、OKRはあくまでどこを目指すかの羅針盤みたいな、一緒に握ったことをちゃんと残しておく誓約書みたいな感じがするんですよね。
評価はまた別で。評価は本当に難しいですよね。OKRってとくに130とかを目標にして70パーセント達成とか80パーセント達成を目指すと、その数字が必ずしも直接的に反映できるわけでもなく、やろうとしていることの難易度もあれば、やはりなかなか数字どおりに出すのは難しいなぁ……と言って終わるんですけど。
及川：（笑）。
井原：いろいろな会社がいろいろなやり方をやるとは思うんですけど、僕が思うのは、もちろんエンジニアとして基本的な能力を持っていることは当然大事で。ただ、「それってなんのためにやってるんだっけ」というと、成果を出すためにやっているわけで。
どれだけきれいなコードが書けますと言っても、それが例えば1円も売上を生まないとか、1人のユーザーも生まないとか、誰も満足しないものであればなんの意味もないと個人的には思っています。なので、プロセスや潜在能力ではなく、出した結果でしか評価できないと思っているということがまずあります。
じゃあ出した結果はどうやって測るのかというと、与えた影響の大きさというか、その人が出した成果は1人レベルのものなのか、チームに対してなのか、事業部に対してなのか、社会に対してなのか、日本に対してなのか、世界に対してなのか。「この人の技術的な成果がどのぐらいインパクトを与えたんだっけ」というもので評価したいなと思っています。
なので、そのプロセスがどうであれ、あまり気にならないというか。それがたった1行のコードでも、世界を平和にしたなら、それはすごい1行のコードだし、すごいエンジニアリングだと思うんですよね。
「どれだけインパクトを与えたか」を評価軸に入れるべき
及川：そうですね。そのとおりだと思います。私も今いろいろな会社をお手伝いしていて、評価制度や評価システムづくりをやることが多いんですけれども、きれいにやろうとするとめちゃくちゃコストはかかるんですよね。
その評価を回すだけで下手すると1ヶ月エンジニアリングの組織が止まってしまうということにもなりかねないところがあるので、あまりそこを強制しないようにしつつ、「最終形はこんなふうにしたらいいですね」とお話しする。
今おっしゃったみたいに、エンジニアってまず能力というコンピテンシーがあるんですよね。ただ、それ自身でその人のパフォーマンスを評価するべきではない。コンピテンシーはどちらかというと職位というグレードをきちっと決めるものだと思っています。
例えばジョブグレードが1から10まであったら、一番ジュニアなレベルで何個の言語……それだけでやってはいけないんですけれども、「何個の言語を覚えられましたか」「SQLを叩いてデータベースを扱えますか」というある程度フルスタック的な基礎素養のところを全部押さえるところだけ見ていくのがあると思います。また、そこから上になると、どれだけ複雑な問題を解けるかというところの能力を見ていったりすると思うんですね。これ自身は能力にすぎないというところでグレードが決まるものです。
もう1つが、井原さんがおっしゃったみたいに、実際に残した結果で見ていくという業績評価の部分。それが「そのグレードのときにはこのぐらいの結果を残せるはずです」というところと比較するかたちでその人の評価をしていったほうがいい。その評価の仕方のときに、上司からの目だけでは捉えきれないところがあるので、できるだけ360度的なものは入れましょう、というかたちをとる。
今おっしゃったみたいに、どれだけ社会に貢献したかとか、インパクトを与えたかということは非常に大事なところで、やはりインパクトを与えたということをエンジニアの評価軸の1つには入れましょうということをお話ししているんですね。
そうでないと、エンジニアっていろいろなタイプの人がいて、ひたすらコードを書いているんだけれども、それでどんなユーザー価値を創出したかということを考えない人がたまにいるんですよ。
あとは、お二人もコードを書くのでわかると思うんですけれども、ひたすらバグを直してしまうことがあると思うんです。もちろん、バグを直すことには価値があるのですが、たとえば1万人に1人という割合で、しかもごくたまにしかそのバグに遭遇しないというときに、「我々は今100万人もユーザーがいるのに、1万人に1人がたまにしか遭遇しないバグを6ヶ月かかって直したとしても、それにどれだけの価値があるんですか？」というところは考えなければいけない。
本当はプロダクトオーナーやプロダクトマネージャーが優先度をつけるときにちゃんとトリアージをすべきなんですけれども、細かいところすべては見れないというときに、本当に価値のあることするということを価値基準に入れるべきだなと思っています。
なので、今、井原さん言われたところはまさにそのとおり。私もいろいろな会社におすすめしているところです。
「俺に任せろ」と言って納得感を作れるかどうか
及川：そういう評価システムって、いろいろ顧問されている会社、自社や過去の会社もそうですし、ニューズピックスもそうなんですけれども。エンジニアから不満が出てきたり、もしくはもう少し改善が必要だと思われるところがあったりしませんか？ あまりないですか？
井原：もう最終的には「決め」なんですよね。誰かが決めるしかなくて。決めるので決まるんですけど、これは前も及川さんとお話ししたかもしれないですけど、僕はどちらかというと、決めたときにその人にちゃんと納得感を持ってもらえるかというほうを大事にしたいと思っています。
なので、「お前に言われたかねえよ」「井原が評価するんじゃねえ」と思われるか、同じことを言っていても「井原が言うなら確かにな」と思ってもらえるかというのは、機械的に決められない以上、その人との1対1の信頼関係なんじゃないかなと思うんですよね。
なので、僕がなにかを言ったときに「確かにそうかもな。じゃあそこは次に改善してみよう」と思ってもらえるようなコミュニケーションを日々とることのほうが大事なんじゃないかと思っています。なので、評価日に「よーし、がんばるぞ」と評価してももう間に合わないというか、ちゃんと信頼貯金を作っていくということをやろうとしています。
及川：なるほど。杉浦さん。
杉浦：まさにおっしゃるとおりで、不満は出ます。とくに360度フィードバックはけっこう大変なので、「なんでこれを入力しないといけないんだ？」「入力量が多い」だったり、「なんで自分は昇格しないんだ？」ということはありますよね。
やはりそれを乗り越えるのは、オープンコミュニケーション。もう率直に話す。自分の理解やほかの人にどうやって見られているかをお互いに正しくフィードバックすることが自分の次のキャリアステップへの大切なものになるので、そういう話をします。
あとは率直にお互いの見えている景色を交換することで「本人のためになるんだよ」というところを伝えることが大事かなと思います。
及川：そうですね。これはたぶんその2つのところに重なるところで、やはりお互いがお互いの成長を助け合うようなフィードバックをし合うというところは、そこにつながっていく文化を作ることなのかなと思いますね。
杉浦：そうですね。はい。
及川：あとは井原さんが言われていた、「最後は決めだ」というところはそのとおりで。私はいろいろな企業さんに「最終形としてこんな評価システムを作るといいですね」という話をするんですけれども、エンジニアが2桁の体制のときに、例えばグーグルやマイクロソフトが使っている評価制度を入れても重すぎるんですよね。
正直に言うとグレードもなにもなくてよくて、もうCTOかCEOが「俺に任せろ」と言ってえいやで決めて、というところで納得感を作れなかったら、本当はその組織はおかしいんですよね。
だから、評価システムなんていうのは、30人ぐらいだと微妙かもしれないですけれども、おそらく50人以上ぐらいになってからはじめて考えればいい話であって。それまでは、日頃の信頼があって「この人に評価してもらったからそんなにブレはないはずだ」と思っていることが非常に大事だというところはあるかなと思いました。
井原：とくに人数が少ないときにそこでバタバタしていると、もうちょっときついですよね。
及川：そうなんですよね。
毎日が給与改定日でもぜんぜんいい
及川：あともう1つは、先ほどのオープンコミュニケーションというところで思ったんですけど、これもマネージャーだった時に私が非常に苦労しているし、今いろいろな企業のマネージャーの方にお伝えしているのが、フィードバック。とくに「ネガティブなフィードバックはすぐにする」ということなんですね。
例えば、評価が半年に1回とか1年に1回、3ヶ月ごとにやるところはないと思うので短くて半年だと思うんですよ。長いと1年だと思うんですね。1年目にして初めてネガティブな評価を受けたら、それはサプライズなわけですね。
なので、日頃から「あなたはこういうところの改善が必要です」と言って改善を求めていくということをしていきつつ、それでもダメだった場合は本人もそれを伝えた上司もわかっているわけなので、1年目の評価は「やっぱり難しかったね」「厳しい評価になりました」と言われたときにサプライズにならないじゃないですか。なので、とくにネガティブなフィードバックはすぐに行うことをおすすめしていました。
井原：評価日って、「評価日」というイベントなだけであって、実際は日々コミュニケーションをとってやりとりをするなかで「こいつイケてるな・イケてないな」「この仕事よかったな・よくなかったな」とやっているはずなんですよね。
それはもう評価日には実は決まっていて、評価日はただ「半年間こうでしたね」みたいに総括するイベントの日であって、「なにか悪いことあるんだったら今日言ってくれよ」「なにか良いことあったんだったら今日言ってくれよ」と。絶対にそうだと思うんですよ。「なんで半年待ってこの日に言うの？」みたいな。なので、日々こまめにやっているほうがいいんじゃないかなと思います。
及川：そうですね。確かGEが評価制度をやめたと言っていたのは、実はそういう話だったらしいんですよね。評価日というところで全部決めるやり方ではなくて、日々フィードバックを与えてそれで成長を促すという話だったみたいです。
井原：という意味では、本当に可能なのであれば毎日が給与改定日でもぜんぜんいいと思っていて。「今日500円上がりました」みたいな。
及川：いいですね。ビットコインみたいでおもしろいですね（笑）。
井原：「昨日2,000円上がった。でも、今日100円落ちた」みたいな。それはさすがにあれですけど。ただ、「なんで3月31日とか9月30日にやるの？」「それ会社の都合でしょ」みたいな。なので、能力が日々向上したり成果が出ているんだったら、そのときにやればいいじゃんと本当は思うんですけどね。
及川：おもしろいですね。一応、たぶん日本の給与体系上に沿ってやらなければいけないので、ベースラインはいくらと決めておいて、それより上は全部……。
井原：変動する、みたいな。
及川：投げ銭みたいなかたちで、いいことをしたら同僚から投げ銭をもらって、それが上積みされて。おもしろいかもしれないですね。
井原：できそうな気はするんですけどね。ただ、仕組み上、半年に1回ぐらいでやると楽なんだろうなというのもわかります。
及川：（杉浦氏に）なにか言いそうでしたけど。
杉浦：いや、おもしろそうだなと思って。完全に余談なんですけど、メタップスの佐藤さんが作られているタイムバンクのような世界観に近づいてきているかなと。
及川：そうですね。
杉浦：僕は個人の評価を金額換算して。
及川：自分の市場価値ですよね。
杉浦：市場価値が見える化されるというか。別に会社にこだわる必要もないと思うんですよね。副業してもいいと思いますし。自分がいったい社会でどういう役割を担えるのか、ということがお金で可視化されてくる世の中にどんどんなってくると思うので、会社の評価制度もやはりそれに合わせて変わっていかないといけないです。
及川：そうですね。とてもできそうにないと思うんですけれども、本当に社内版のタイムバンクみたいなものがあって、そのエンジニアの評価というのが……タイムバンクはたしか秒ですよね。1秒いくらでその人の価値が見えるんですけれど。社内でそれが見えていたらおもしろいですよね。
杉浦：おもしろいですよね。「ちょっとこいつ半年間買うか」みたいな（笑）。
及川：そうですよね。なるほど。わかりました。
マネージャーは本当に必要なのか？
質問者：すいません。
及川：はい。
質問者：今の段階でぜひおうかがいしたいことがありまして。私、マネジメントは必要だと思うんですけど、マネージャーが必要なのかというのがちょっと疑問で。もしお考えがあればおうかがいしたいなと。
及川：とてもいい質問ですね。私はすごくしゃべりたいですが、先にお二人どうぞ。
井原：いや、しゃべりたいならしゃべっていただいたほうがいいんじゃないですか（笑）。
及川：一応、私はモデレーターという役割がついていたから今までけっこう黙っていたんですけど。最後のほうは我慢できなくなってペラペラしゃべって。
井原：あとから出てきて全部ひっくり返されてもあれなので、もう先に（笑）。
（会場笑）
及川：わかりました（笑）。じゃあ、しゃべらせていただきます。
マネージャーというか、やはり組織にコミットする人は必要じゃないかと思うんですよ。先ほどのお二人の経歴の中でも出てきたように、エンジニアでありマネージャーであるという立場なんですけれども、どっちに軸足を置くかというところは大事だと思うんですね。私はけっこう軸足という考え方は好きなんですよ。
もしマネージャーという人がいなかったならば、組織に対してコミットする人がいないと思うんです。組織にコミットするということは、やはり責任。責任というものが大事だと思うので、私はそこは職種として持つべきだと思っています。採用・育成を含めたところで、今日のテーマになっている強い組織を作っていくというところに対してコミットする人が必要だと思うんですね。
これはやはり、お二方の経験がそうであるように、自分自身のコードを書くというエンジニアとして一個人が貢献するところを犠牲にすることになると思います。ですから、本人がそれに対してやはり覚悟を決めて携わるということと、もう1つ、今出てきている評価の問題なんですね。
だからそういったことにコミットする人は、個人が書いているコードなどの個人の技術での貢献ではなくて、組織を作ることによって技術的にどう貢献しているかという、一段階置いたところを評価軸にしなければいけないと思うんです。
それを誰かがちゃんとつけないかぎりは、やはりある程度の規模になってくると組織の成長は難しいんじゃないかなと私は思います。
質問者：ある程度の組織になったら、どんな形態の組織でもやはりそこは必要ですか？
及川：そうですね。どんな形態というのは、例えばどういうものを想定されていますか？
質問者：人数によって。
及川：ああ。そうですね。でも、人数が何人以上かというのは正直難しいところはあるかなとは思っていて、少人数であったとしても必要になってくることは多いと思います。
簡単な話で、採用に対して誰がミッションをコミットするかというところだけとったとしても、「全員がんばってください」と言っても、「いや、俺はコード書くのが好きだ」とみんなが思ってしまったら、採用戦略は誰も立てられないと思うんですね。
質問者：ありがとうございます。
「マネージャー」という言葉に抱くイメージの違い
杉浦：じゃあ僕も。マネージャーとマネジメントですよね。もし「マネジメント」という単語が「管理」を表すとすると、「管理」は必要ないと思っています。僕は管理されるのが大嫌いなので。マイクロマネジメントとかされると嫌じゃないですか。
ただ、マネージャーなのかわからないですけど、仕組みを作る人は必要だと思っていますね。いい製品を出すための仕組みを作る。みんなが気持ちよく働けるための仕組みを作る。採用や評価の話もそうですけど、評価というものは、いいエンジニアが働いて、エンジニアがちゃんとキャリアアップできる仕組みだと思うんですよね。そういう仕組みを作ってちゃんと回るようにするという。
それがもしマネージャーであるとすると、そういう立場の人は必要なんじゃないかなというのが僕の考え方ですね。
及川：はい。井原さん、ひっくり返さないですか？ しゃべってください。
井原：もう合わせた話しかできないですけど（笑）。
及川：いやいや、チャレンジしてくださいよ（笑）。ここで「マネージャーいらないと思います」という一言をぜひ。会場の人は期待していると思うので（笑）。
井原：そうですね。クックパッドの頃は「会社に必要ないものはM＆Mだ」「ManagerとMeetingだ」と言っていたんですね。
それはそんなに変わらないんですけど、いらないのは「いらないマネージャー」だと思うんですよ。必要なのは「必要なマネージャー」。だから結局、いらないマネージャーはいらないですよね。例えば、本当に無駄なミーティングを設定してくるとか、「○○君、調子はどう？」って無駄に仕事を妨げてくるとか。
及川：だから杉浦さんが言われたみたいに、管理という日本語をつけちゃうことが本当はよくなくて。英語のmanageって、もう少し管理のイメージがないんですよね。だから例えば「time management」といったときに、時間を管理するって、管理の意味がちょっと違うじゃないですか。むしろ「なにかやりくりする」というイメージなんですよね。
だから組織の中で人員配置を考えたりするところは、プロジェクトを回すために、もしくは本人のモチベーションを維持するためにやりくりをしているというかたちで、どちらかというと偉くないんです。
「マネージャー」というときに私がよく言っているのが、甲子園に出るのを目指している野球部のマネージャーだとか、吉本の芸人さんのマネージャーをイメージをするほうが正しいんですよ。エンジニアのほうが神様なんです。そのエンジニアが気持ちよく働くための環境づくりをしているのがマネージャーなんですよね。
井原：だからめんどくさいんですよね。「もうあいつらはわがままばかり言いやがって」というところを……やっぱりこれはドMでないとやれないんじゃないかと。
及川：そうなんですよ。私がよくネタで話すんですけど、3年ぐらい前に、甲子園に出た女子マネージャーがおにぎりを100個作ったのがニュースになったことがあったじゃないですか。その時、私の部下から「卓也さんもマネージャーだったら、俺たちのおにぎりでも作ってくれるのかな」と言われて、「こいつら怖えな」と思って（笑）。
井原：まあでも、そういうことですよね。本当に。それで成果が出るならそれをやる、という。
及川：本当にそのとおりなんですよ。なので、管理者というイメージは払拭したほうがよくて、そういう意味ではないところで、本当に組織を活性化させたり、成長させていくという役割は誰か必要かなと思います。
質問者：ありがとうございます。
