2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
東京・京都・福岡、3拠点のリードエンジニアによるパネルディスカッション(全1記事)
提供:LINE株式会社
リンクをコピー
記事をブックマーク
福島英児氏(以下、福島):ここからパネルディスカッションとして、東京、京都、福岡のエンジニアたちとより具体的な話をしたいと思います。それではパネルディスカッションに参加される3名の方に登場してもらいたいと思います。お願いします。
一同:こんばんは。よろしくお願いします。
福島:よろしくお願いします。本日のパネルディスカッションのアジェンダを一応用意してあります。事前にいただいている質問や、面接の中でよく聞かれる質問をちりばめています。最初に自己紹介をしてもらって、仕事の仕方や拠点の違い、キャリアパスなどをディスカッションしていきたいなと思います。
ここからは、画面の共有を切ってみなさんの顔を見ながら話していきたいなと思います。では早速ですが、自己紹介をお願いしたいと思います。東京からお願いできますか。
清水大輔氏(以下、清水):LINEの東京のオフィスで、UIT1室の室長をしている清水と言います。
業務としては、福島と同様にLINEの前身となるネイバージャパンの時に入社して、いろいろなフロントエンドのサービスの開発に携わってきました。ここ数年はエンジニアリングマネージャーとして組織の成長をメインに、業務をやっています。本日はよろしくお願いいたします。
福島:よろしくお願いします。次は京都にしましょうか。
岡本拓也氏(以下、岡本):LINEのフロントエンドエンジニアとして働いている岡本です。LIFF SDKと呼ばれる、一般デベロッパーと社内デベロッパー向けのJavaScriptのSDKや、LINEログインと呼ばれるLINEのソーシャルログインサービスなどの開発者向けプロダクトに、フロントエンドのチームのテックリードして従事しています。
あと数日で入社して2年になる、まだ若……まだ……若いですね? はい。今日のパネルディスカッションは周りのみなさんが役職者ということで、〇〇長、〇〇長って付いていますが、僕だけヒラです。よろしくお願いします。
福島:よろしくお願いします(笑)。では最後に福岡のほう、お願いします。
平山光太郎氏(以下、平山):はい、〇〇長をやっています(笑)。平山と言います。僕はLINEの福岡拠点の中のフロントエンド組織の室長をしています。清水さん同様、組織面を主に見ながら、ある程度プロダクトのほうもやっています。今日はよろしくお願いします。
福島:よろしくお願いします。今日はこのメンツで、パネルディスカッションを進めていきたいと思います。
福島:最初のお題、アジェンダには仕事の仕方と書いてありますね。拠点ごとのプロジェクトの進め方、仕事の進め方ってどう違うのかなというのをちょっと聞きたいなと思いますが。どうしようかな。じゃあこれは東京からにしますか?(笑)
清水:拠点ごとというか、一般的な事業、サービスの始まり方としては、事業側からある案件が来て、企画、デザイン、開発、QAも含めて、それぞれアサインされます。
そこでアサインが決まったら、キックオフをして、企画段階からエンジニア、デザインも一緒に入ってサービスに対して、どういうふうによくしていけるのかをいろいろな方面からディスカッションして進めるのが、まずプロジェクトの始まり方として典型的なところですね。
今日紹介する拠点の中では、東京の人数が一番多いんですけれども、東京はやはり組織が大きいということもあって、東京だけで完結するプロジェクトもあれば、大規模なものになると、先ほど紹介したような拠点、京都や福岡、海外の拠点も含めて、拠点をまたがって協業することもけっこう多くあります。
福島:なるほど。ちょうど東京の話にもありましたが、「組織図で出していたDev1からDev7はどのような軸での分割なのでしょうか?」という質問が来ています。ついでにここで回答してもらおうかと思うのですが。どうなんでしょうか? Dev1からDev7、7チームありますけどどういうふうな軸で分割されているか、清水さんから簡単に説明してもらっていいですか?
清水:これは、先ほど福島のスライドにあったのですが、toC、toB、toDというところで、そういう切り口で、例えばあるチームはデベロッパー向けのプロダクトにフォーカスして担当し、あるチームはコンシューマー向けに担当とか、そのコンシューマーの中でもより事業領域が近いものは同じチームで見たほうが、よいサービスを作るうえでいいと思っています。そういうかたちで振り分けている感じです。
福島:なるほど。ありがとうございます。場合によっては、複数チームで1つのこと、みたいなこともあり得るのかな?
清水:そうですね。現にLINE NEWSというサービスがあり、フロントエンドエンジニアも10名くらい関わっている大規模なプロダクトで、そういったものだと2チームにまたがってアサインされている状況ですね。
福島:では、東京以外の拠点のプロジェクトの進め方、仕事の進め方ってどうなんですか? 拠点ごとに進め方の違いはありそうですか? 福岡とかどうですか?
平山:福岡は、ここの3拠点だと2番目に大きく、ちょうど京都と東京の間くらいなんですが、全体の流れは、おおよそ東京と同じような流れを汲んでいます。ただ福岡の場合は、開発とQAで、あとはテスト自動化のチームというのが近いので、そことの連携は多い傾向にあると思いますね。
さっき、ちょうど出ていた企画というポジションの人たちは、福岡拠点にはいないです。基本的にどのプロダクトでも企画とのやりとりが発生するので、東京など他拠点と連携して働くのがベースになっています。京都はどうでしょう?
岡本:京都も、基本的には福岡と近くて、先ほど福岡はデザインチームもいるという話でしたが、京都は完全に開発チームのみなので、基本的には他拠点と協業するかたちになります。
例えば、僕自身が携わっているLIFFとか、LINE Webログインと言われるプロダクトに関してはUIT自体も東京と京都で分かれています。東京が2名、3名で、京都が3名という組織ですね。
僕は京都からリモートのチームのテックリードとしてやっています。デザインチーム自体はグループ会社のLINE Plusが担当していたりとか、プロジェクトマネージャーは東京にいたり、QAチーム、品質管理の部門は福岡のチームであったりします。
福島:ちょうどアジェンダの仕事の仕方の3つ目に、他業種との協業の仕方、サーバーサイドやデザインとどう協業しているの? と。質問にも「デザイナーとの協業をどのようにされているのでしょうか?」と来ています。
具体的にはどうなんでしょう。フロントエンドのエンジニアとしては、どのように他業種、他部署のメンバーと協業しているのかちょっと教えてほしいんですが。東京はどうですか?
清水:プロダクトによって、やり方は本当にバラバラなので、決まったやり方というのはありません。デザインとのやりとりに関しては、今Zeplinというツールを使ってデザインのカンプファイルをやりとりすることがほとんどです。
デザインと進める中で、やはりエンジニアリング観点で、いろいろアイデアや意見というのが必要な場面はけっこうあります。例えばアニメーションとか、UXとか、あとアクセシビリティとかですね。そういったところは、デザイナーと話し合いながら、プロトタイピングを進めて協業していくことが多いです。
サーバーサイドとのやりとりですが、最近だとgRPC使って開発しているサービスもありますし。あとはサーバーサイドのVueのテンプレートをいじる際に、完全にサーバーサイドのエンジニアがやっているものもあれば、フロントエンドエンジニアがそこも担当して開発しているものもあります。あと、Node.jsでSSRするようなプロダクトもあり、わりとこのようにやり方はマチマチです。
LINEはGitHub Enterpriseを使っているんですが、サーバーサイドのコードもiOS、Androidのクライアントのコードも基本的に全エンジニアが見れるような状況になっているので、そこでSlackを通じて直接コードを一緒にみながら「ここのコードをこうしたほうがいいんじゃない?」みたいな議論を進めながら開発していくこともあります。
福島:デザイナーは、LINEにおいてはほぼ東京がメインで、一部福岡にもデザイン組織があり、京都は開発組織だけというような組織構成だと思うのですが。具体的に京都はデザイナーと直接やりとりすることはありますか? またどこまではデザイナーで、どこからがフロントエンドなのか、そういう分け方ってどうなっていますか?
岡本:いろいろな会社の中には、デザイナーさんがマークアップするケースもあると思うのですが、LINEの場合はフロントエンドのチームがマークアップもします。
基本的には、おっしゃるとおりすべてリモートで、先ほど清水さんが言われたとおり、Zeplinが中心ですね。Zeplinで渡されたガイドをもとに実装していく。実装したあと、「これでいいですか?」というデザインQAと言われるプロセスを踏んで、品質を高めていくフローになります。
福島:なるほど。ありがとうございます。福岡もそこは同じような感じかな?
平山:そうですね。運がよければ福岡拠点内で全部完結します。
福島:福岡のデザイナーと一緒に協業してって感じですね。
福島:ちょうど今質問でも来ているので、リモートワークはたぶん参加されているみなさん興味があるところなのかなと思うのですが。先ほど、岡本さんからもリモートでという話をしていますが、現状リモートの働き方ってどうなっているんでしょうか?
岡本:京都からいくと、京都オフィス自体が先ほどお話したとおり開発部隊だけなので、常に基本全部リモートで拠点をまたいでやり取りをしているんですね。今のコロナになってからの働き方と、そんなに変わっていないなという感じです。みなさんたぶん、今話聞かれている方々も、リモートワークになられた方が多いと思うのですが、その働き方をイメージしてもらえればいいのかなと。
福島:厳密に言うと、拠点ごとでリモートという考え方と、そこの拠点の中でもエンジニア自身が、例えば在宅で作業しているリモートというところでいくと、その2つがあるのかなと思うのですが。
岡本:あ、そうですね。コロナ前まではそれぞれの拠点からのリモートというかたちを取っていて、今はそれぞれがWork From Homeをやっている状態ですね。僕は基本的にはリモートで問題ないと思っていますが、1点だけ問題あるとするなら、チームビルディングで必要性を感じるケースはあります。
またうちのチームの話になってしまいますが、LIFFチームにおいては、Beforeコロナ時代は僕が月に1度、東京に行くことでそこの差を埋めるというふうなことをやっていました。また半期ごとに全拠点が東京に集まって、全員でキックオフミーティングや振り返り会をするとか。
そうやって拠点が離れていることの差というか、コミュニケーション不足の部分は、そういったタイミングで埋めようとしていました。でも、Withコロナの現状に関しては、基本全部オンラインなので、拠点間の差はあまり見えないなというところになっています。
福島:なるほど。福岡もみんな今リモートで、出社している人はほとんどいなかったりするんですかね?
平山:みんなリモートなので、ほぼいないですね。
福島:開発はだいたいみんなリモートでやっている感じなのかな?
平山:そうですね。みんな環境にも投資し出しているみたいなので、いいことだなと思っています。
福島:それは東京も一緒かな。
福島:ちょうど仕事の進め方っていう話でいくと、「開発スタイルはアジャイルでしょうか?」という質問が来ているのですが。LINEの中での仕事の進め方って、開発スタイルというのはどういったものなのでしょうか? 誰が答えてくれるかな?
平山:じゃあ僕からいこうかな(笑)。さっき清水さんも言われていたように、プロダクトによって進め方がだいぶ違うというのはあります。アジャイルのスタイルをとっているチームもあれば、それが入り乱れたようなスタイルを取っているチームもあります。
規模が大きいものだと、それが入り乱れたスタイルの中に、アジャイルのチームを作ってやっているケースもあって、さまざまですね。なので、この質問の回答とすると50パーセントYes、50パーセントNoくらいの感じになると思います(笑)。
福島:なるほど。決まったやり方があるというよりは、そのプロジェクトチームごとに色がある感じなのかな。どうですか? 京都は?
岡本:そのとおりです。うちのチームもアジャイル風ウォーターフォールみたいなところもあるし。
(一同笑)
京都内の別のチームでも、スプリントをがりがり回しているチームもありますし、さまざまですね。そこはプロダクトマネージャー、プロジェクトマネージャー、あと部署ですね。関係する部署によって色が違うという印象を受けます。
福島:なるほど。ありがとうございます。質問に答えていったほうがいいですかね。この量だったら。
岡本:確かにそうですね。「バックエンドチームとどう連携していますか?」っていうのも、この話に近いですね。
福島:仕事の進め方で、先ほどはデザイナーとの進め方っていう話がありましたが、バックエンドの話も、ちょっと清水さんからありましたね。ほかの拠点に関してはどうですか? どういうふうな連携をして進めているんでしょうか?
岡本:たぶん福岡と東京京都で事情が違う部分もあるのかなと思ったりするのですが。まず京都UITは、組織としてそのプロダクトをもっているわけではなくて、横断的な組織で、その中にそれぞれの部署がプロダクトをもっている感じ……合っていますかね?
これがサーバーサイドになると、僕は東京側のサーバーサイドのチームと協業しているんですが、それぞれにプロダクトベースでいるサーバーチームなんですね。例えばデベロッパープロダクトはDev4といったかたちです。そこのチームの人たちは、基本的に同じプロダクトをずっとしており、プロフェッショナルな状態になっているので、そのサーバーサイドに関する実装の方法などは彼らに聞いています。
例えば僕が「フロントエンドでこんなことをしたいんだ」とか「こういうことを実現するためにサーバーサイドの協力が必要なんですけれど」といったやり取りを基本的には会話ベースでやって、必要であればWikiでも、例えばシーケンス図を書いてやりとりをしていくフローが多いですね。
平山:福岡の場合は、フロントエンドチームは1プロジェクト複数名で、1人は1プロジェクトに集中する感じでやっています。座席もプロジェクト単位で座っているので、となりの席にサーバーサイドのメンバーとかネイティブクライアントのメンバーがいたりする環境でやっていますね。なので、けっこうよくみんな立ち話とかしているのは見かけて……いました。
岡本:過去形(笑)。
平山:クイックコールみたいな形で連携を取りながらやっているのは、たまに見かけますね。そういう感じです。
福島:具体的にフロントエンドのチームがサーバー側のコードを触ったり、その逆とかはあるんですか?
清水:東京だけの例だと思うのですが、フロントエンドエンジニアが開発時に使うようなツール、そういったものはバックエンド含めてフロントエンドエンジニアが開発してたりするものもあったりします。
そうすると、やはりインフラやサーバーサイドの面もケアしなきゃいけないので、フロントエンドエンジニアなのにインフラの知識が求められたりとか、インフラ側のエンジニアと密に連携してやることもあったりします。
岡本:1つおもしろい例としては、AWSみたいな社内用のクラウドは自由に触れるので、テスト環境や、本当にプロダクション環境に出ないようなものであれば、僕らフロントエンドエンジニア側で作ってそれをQAチームに渡すとか、そういったことも積極的にしていたりしますね。
福島:ちょうど他部署のコミュニケーションみたいなところでいくと、よく聞かれるし、今回の質問にも入ってきていますが、業務における英語でのコミュニケーション、このあたりですよね。
例えばメンバーの日本人と外国人との割合はどれくらいなのか? 英語を使用する機会はどれくらいなのか? 英語はマストなのか? 英語話せないけど大丈夫なんですか? みたいなところはけっこうみなさん気にされるところだし、よく聞かれる質問だとは思うのですが。
このあたりの事情、東京だとどうですか? 業務で英語でコミュニケーションを取る機会って多いですか?
清水:東京に関しては、UIT1室のメンバーは基本的に全員日本語がしゃべれて、組織内のコミュニケーションは日本語がデフォルトです。ただ、先ほどいろいろな拠点と関わりがある話をしたと思うのですが、そういったときはやはり英語を使ったほうがコミュニケーションがスムーズに進みます。
あとはエンジニアなので、テクニカルドキュメントはやはり英語で書かれていることが多く、英語が読めなければ、仕事が進めにくいというか、スピーディーに進まない場面はあるので、必要と言えば必要かと思います。
福島:たぶん東京とは事情がまたちょっと違う京都と福岡だと思いますが、どうですか?
平山:たぶん僕らはほぼ英語かな。福岡の構成でいくと、開発者全体の中で半数以上が外国籍のメンバーで、UITという組織だと12人中9人が海外からのメンバーなので。やはり基本的な開発者同士のやりとりは英語が使われていますね。
それとは別に、さっき言った他拠点でのミーティングとかもあるので、そういうときには日本語でということはよくあります。たぶん京都も似たような感じですかね?
岡本:そうですね。京都もUITチームには僕ともう1人しか日本人がいない状況ではあるのですが、ただほかの外国籍のメンバーはどんどん日本語がうまくなってきているので(笑)。
福島:そうですね。みなさんね。
岡本:そうなんですよ。最近は日本語でのコミュニケーションが多くなってきました。とはいえ、ときどき認識齟齬を生まないために、厳密な話をするときは英語が必要な場面があるので、言語のフォールバック先としては英語が必要なシーンがまだあります。
基本的にはドキュメントを書く場合はすべて英語ですし、会話の中で認識齟齬を生みそうなときは英語でしゃべって説明します。なので、入社時は話せなくてもいいけど、話したいモチベーションがあるくらいでちょうどいいのかな、という環境ですね。
福島:じゃあ英語は絶対話したくない、勉強もしたくないみたいな人は、さすがに福岡京都だとちょっときついのかな?
岡本:どうでしょうねぇ。そういう新しい例になってくれるかも(笑)。
平山:補足しますと、選考では英語は見ませんが、やはり業務上現実に発生しちゃうので、そこは一緒にがんばりましょう、みたいなことは起こり得る気はします(笑)。
福島:みなさんのいいねが多くついている質問から答えていくのがいいですかね。
「現在採用に力を入れられているモチベーション、どんな課題があるか教えていただけますか?」。今日のような採用説明会みたいなのを、LINEの中ではフロントエンド開発センター以外でも、サーバーサイドのほうでも採用説明会とかを今やっています。とくにフロントエンド、UITとして、今採用に力を入れているモチベーションは何なのかちょっと教えていただいていいですか? 誰が答えてくれますか?
平山:わりと大きなテーマですけど(笑)。たぶんどこも一緒だと思いますが、いい人と働きたいっていうのはあると思うし、ビジネスとしても伸ばしていくのに、いい人がいっぱい必要だと思っているので、それが止まることって、基本的にないと思っているんですね。あ、なんか違ったら補足してください。
なので、むしろ止めるっていう理由がないので、そこのモチベーションはいかに維持するかというか。いかにリテンションを高めていくかが大事だと感じています。
福島:僕の最初のフロントエンド開発センターについての説明の中でもお話しましたが、やはり私たちが提供しているサービスで、まず新しい新規サービスを作るときはWebで提供するっていうのが圧倒的に多いですよね。
なかなかネイティブアプリケーションになると、それをユーザーのみなさんにインストールしてもらって使ってもらうところはなかなかハードルが高いけども、ありがたいことにみなさんLINEは使っている……ありがとうございます。
LINEは使ってもらっているので、その中からWebアプリケーションとして起動できるのは、やはり一番リーチするっていうところで、圧倒的にWebでサービスを提供しましょうっていうのは多いので。
そういった意味では、常日頃、フロントエンドエンジニアの人が足りない! というところは、みなさんエンジニアリングマネージャーとしてチクチク言われたりすることも多いかとは思うのですが、どうですか?(笑)。
清水:そうですね。新規サービスもいろいろ出てきますし、そういったものは「まずWebでやりましょう!」ということはやはり多いので、人は足りないですねぇ(笑)。
平山:間違いない(笑)。
福島:なかなかこういったところって、たぶん外から見るとわからないところなのかなぁと思うんですね。これで答えになっているのかな? 採用に力を入れなきゃいけない組織的な課題があるというよりは、サービスに対応していかなきゃいけないところが一番大きいのかなとは思いますね。
清水:そうですね。あとはLINEっていう、日本だと圧倒的なシェアをもっているコミュニケーションアプリだと思うのですが、そういったところで大量のトラフィックが来るサービスが多くあって。
その中で、やはりフロントエンドエンジニアとはいえ、多くのユーザーに影響を与えるというところで、ちゃんとパフォーマンス面やセキュリティとか、いろいろなところをちゃんと見れるエンジニアには、それなりのスキルが求められます。市場的にも人材的にもそういったハイスキルな方はなかなかいないので、そういった方を求めて日々採用活動をしているという感じですかね。
福島:あと1個くらい答えておきたいですね。「みなさん転職された方が多いと思うのですが、数ある会社からなぜLINEを選んだのでしょうか?」。どうでしょう?
平山:難しい。
清水:難しいのですが、私は冒頭言ったように、ネイバージャパンという会社にそもそも入っているんですね。そのときは前職で別の検索サービスを作っていたこともあり、それにつながるところで、Webの検索で、かつフロントエンドに特化してやってみたいなというところで、転職活動している中で、ネイバージャパンが当時Webのポータルのサービスを提供しようとしていたので、ジョインしました。それでもう11年くらいいて、その間に会社の合併などを経てLINEに変わり現在に至ります。
長く所属している理由って何だろうって考えたときに、今はこれだけ会社も大きくなってサービスも成長してっていう状況で、それでもあまり大企業らしくないというか。
先ほどのTake Ownershipとか、そういう話がありますが、現場のエンジニアが声を出せば、それがちゃんとサービスとしてみんな耳を傾けて聞いてくれるし、それがサービスに反映されるところがおもしろいと思います。逆に責任はあるのですが、そういったところができる会社だなというところは感じているので、長く続いているのかなという気はしています。
福島:なるほど。そのほかのお2人はなぜLINEを選んだんですか?
平山:僕の場合は3年ちょっと前くらいに入ったのですが、その前は東京で働いていて、福岡に移りたいというのも大きなモチベーションではありました。
あとは、入社前にしかいろいろ話できないことってあると思うのですが、そのときにここにいる福島、清水とお話しする機会もあり、なんか楽しめるんじゃないかなぁみたいなノリは大いにあり、軽い気持ちで移住もやりました(笑)。よかったなと思っています。
福島:よかった(笑)。ありがとうございます。
平山:ここでね、変なこと言ったら怖い(笑)。
岡本:平山さんJターンでしたっけ?
平山:そうですね。もともと九州の長崎出身で、そのあと福岡で大学、大学院に行って、東京に就職。その後、戻る感じで福岡ですね。なので、Jターンですかね。
福島:岡本さんは?
岡本:僕は関西でずっと仕事を探していたのですが、1つのモチベーションとしては、受託会社を転々としていたのもあったので、そろそろ自分のサービスといった、プロダクトを長い目線で見られる仕事をしたいなと思ったのがきっかけの1つ。
あと京都に開発部署ができたのが、きっかけの2つ。この2つがあったのでLINEを選びました。
福島:なるほど。実際LINEに入ってどうですか?
岡本:もっと大企業大企業するかなと思っていたんですね。例えば共通の言語はこれを使わなくちゃダメだよとか、共通の基盤はこれだよとかって、ほかの大企業さんとかだったら往々にしてあるのですが、意外と新しい先進的な技術とかを自分の裁量で選べるのは、プロダクトの品質を上げると同時に学んでいけるので満足しています。
福島:なるほど。ありがとうございます。なかなかすべての質問にはちょっとお答えできなくて本当に申し訳ありませんが、ぜひこのあとの拠点ごとのルームで、追加で聞いてもらえたらと思います。
それではパネルディスカッションは、これで終わりにしたいと思います。ありがとうございました。
一同:ありがとうございました。
LINE株式会社
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには