2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
提供:LINE株式会社
リンクをコピー
記事をブックマーク
清水:いくつか質問は来ているのですが、次の質問とも関係しそうなところなので、まず次のテーマに移っていきたいと思います。続いてですが、みなさんそれぞれ現在、それぞれのキャリアの中で力を入れているところはどういったところでしょうか? ではまた順番で松永さんからお願いします。
松永:エンジニアとして最新の技術をキャッチアップしていくのは、当然、気をつけているところです。
あとは大きいプロジェクトだとプロジェクトマネージャーみたいな人が専門で入ってくることがあるんですけれども、必ずしもそうではないので、スケジュールとか仕様とかで不明瞭なところがあるとエンジニアにとって、実装不可能なものだったりとか、実装不可能なスケジュールで進んでしまうようなことがあるので、そうならないように不明瞭な部分があったら極力排除するようにするですとか。
それからドキュメントですね。自分が作っているものを人に引き継いだりとか、説明するときにドキュメントをきちんと書くとか。あとはプロジェクトでプランナーの人とかがiOSをメインで使っていたりとかすると、Androidの動作チェックとかがけっこう疎かになっちゃったりすることもあるので、そういうときに動画を撮ったりとか、バイナリーをできるだけ早く共有したりとかっていうところですかね。
自分が作っているコンポーネントがライブラリ化できそうだなと思ったら切り出してライブラリにしていったり、そういうところは力を入れているというよりは気をつけて普段やっているところになります。
清水:ありがとうございます。ちょっと追加の質問で、松永さんにお聞きしたいんですけれども。今LINEで働いているうえで一番大事にしているところってどういうところでしょうか? それからその質問と一緒に来ている内容として、入社歴はどれくらいですか?
松永:私は2017年のゴールデンウィークくらいだったので、入社歴としては今ちょうど3年半くらいだと思います。その中はほとんどLINEのメッセンジャーの開発をしていました。
大事にしているところですが、前の会社とかでも、僕、実はそんなに働き方のスタイルが劇的に変わっているわけではないんですけれども、周りの人がびっくりしないようにしています。いきなり独自の俺が考える最強の設計をボーンって出したりとか、スケジュールの期限の1日前に実は間に合いませんとか、自分が関わっている周りの人たちがびっくりするようなことはないように。
なるべく早め、早め、小出し、小出しに情報を出していって、周りの人がびっくりしないようにしていくっていうのは大事にしているところですかね。自分がされたらそれが一番嫌なので、大事にやってはいます。
清水:なるほど。ありがとうございます。では続いてTech Leadとして力を入れているところ。尾上さんどうでしょうか?
尾上:各プロジェクト、わりと私、大きいプロジェクトをやることが多いんですけれども。だいたいそうするとプロジェクトマネージャーとかプロダクトマネージャーの方たちがいるんですけれども、ただ必ずしも技術に明るいわけではないので。
あくまでも私の役割としてはエンジニアではあるんですけれども、エンジニアとしての技術的な視点プラス、ビジネス的への技術の影響ですとか、純粋な実装技術だけじゃなくて開発プロセスに対して選定した技術の影響とか。そういった幅広い観点でなるべくものごとを見て、なにかを決めるようにしていますね。
さきほどの清水さんのお話でもあったんですけれども、わりとプレッシャーがかかることが多いので、それを楽しめないと仕事がつまらないので。難しい制約などが出てきたときでも、それをなるべく楽しんでいい雰囲気で働けるようにとは最近は心掛けています。
清水:なるほど。松永さんと同じように、来ている質問に対してなんですけれども。尾上さんの入社歴、LINEで働くうえで大事にしているところは、どういったところですか?
尾上:私は入社してだいたい8年くらいだと思います。LINEのメッセンジャーのグローバルでのユーザーが1億人超えるか超えないかくらいの入社だったと思います。
大事にしていることなんですけれども、入社当初からちょっとびっくりしたところは、エンジニアの仕事の範囲がここからここまでですよみたいな、エンジニア同士の間での仕事の範囲はここからここまでですよみたいな区切りもあんまりなくて。ほかのプランナーとかPMの人たちとの仕事の区切りもここまでですよみたいなのがわりと少ない会社だなって、最初びっくりしました。
なのでわりとみんなが自分がどこまでやるのかっていうのを積極的に見極めながら、周りの人が困っていたら普段はやらないところなんだけれども積極的にそっちもどんどん踏み込んでいこうみたいな感じで。あまり垣根を作らずにやる必要もあるし、やるといい成果が生まれると思っているので、そこらへんをなるべくできるように心がけていますね。
清水:なるほど。私もそうですね。今、尾上さんが話されたようなところは、僕も思っていて。役割がそれぞれあるのはもちろんですけれども、間に落ちているようなボール、これはTech Leadがやるべきなのか、これはIndividual Contributorがやるべきなのかみたいなところだったりとか。
あとは例えば私はフロントエンドですけれども、フロントエンドなのかサーバーサイドなのかみたいな間に落ちているような課題だったり問題っていうものをいかにチームで協力して、時には自分から積極的に拾ってそれを解決するために動いたりとか。そういったところはけっこうLINEの中で必要とされているし、わりとそういったところを大事にしている方は多いんじゃないかなと感じています。
では最後にEngineering Managerとして力を入れているところは、昌熙さん、どうでしょうか?
金:技術的な面では、フロントエンド領域は変化が激しいので、その場その場で適切な判断がすぐできるように、変化をずっとキャッチアップし続けているところに力を入れています。
マネージャーとしてはやっぱりメンバーのスキルを引き出さないといけないので、モチベーションアップとかにつなげられるような案件にアサインできるように常にメンバーとコミュニケーションしながらプラスになるような感じに持っていくところに力を入れています。
そして定期的に1on1を実施して業務以外のことでも気軽に話せるような関係づくりを……まあメンバーはどう思うかわからないですけど(笑)。私はそこに力を入れている感じですね。気軽にコミュニケーションできるように業務関連はSlackで話して、ほかの雑談とかはLINEでやるっていうのを分けて活用したりもしています。
清水:なるほど。ありがとうございます。質問がいくつか来ているんですけれども、このあとのQ&Aの時間もあるのでそちらでお答えさせていただくとして。最後に、それぞれのキャリアについて、こんな人にはおすすめというところを話していただければと思います。では松永さんお願いします。
松永:わりと制度がかっちりしていて、役割がかっちりしていて、自分がなにをやらなきゃいけないとかっていうのが明文化されている組織ではないので、ある意味では自発的に行動して、自分でプロダクトのためとかチームのためにはこれをやるべきだっていうのを自分で考えて積極的にやっていけるような人じゃないと逆にストレスが溜まるのかなと思います。
エンジニアだけどプロダクトのためになんでもやっちゃおうかなというような感じの人だとけっこう楽しめるかなとは思いますね。あとは関係者。メッセンジャーの場合、特に関係者がすごく多いのでたらい回しになることもあるんですけれども、そういうときでも知り合いが増える機会だなと思って楽しめるような感じの人だと楽しく仕事ができるかなと思います(笑)。以上です。
清水:ありがとうございます。では尾上さん、どうでしょうか?
尾上:先ほどまででも出てきたんですけれども、複雑さを楽しめる人とか、プレッシャーを楽しめる人は向いていると思います。プレッシャーについては楽しめるというか、ある程度働いていくとたぶん鈍感になってくると思うんですけれども(笑)。自分はわりとプレッシャーに関しては鈍感になっていますね。
Tech Leadに限らないと思うんですけれども、先ほど出てきたように提示された役割の垣根を超えてフットワークの軽い人っていうのは、LINEのエンジニアに向いているかなと思っています。
これはわりとTech Lead固有なことも多いと思うんですけれども、先ほども出てきたとおり、コードをあまり書けない日もあります。システム全体の絵、UML、コンポーネント図とかシーケンスをずっと書いている日が多いみたいなこともフェーズによってはあるので、コードを1日でも書けないと発狂しちゃうような人よりは、UMLとかを書くのも楽しいみたいな、そういうタイプの人が向いているかなと思います。
清水:ありがとうございます。では最後にEngineering Managerとして、昌熙さんはどうでしょうか?
金:マネージャーとしてジュニアメンバーの育成も役割として求められるので、そういう育成をしてみたい人。自分自身がそういう育成をされた経験がある人は、すごくやりがいを感じるのではないかと思います。私自身も私の開発者人生には師匠的な人がいて、その方からJavaScriptとかを学んで今に至っているので、そのような関係作りが好きな人はけっこう向いているんじゃないかなと思います。
そしてやっぱりマネージャーとして、最初にプロジェクトが立ち上がったときとかに初期からいろいろな案件に幅広く関わることができるので、1つのプロダクトだけをやりたいというよりはいろいろなプロダクトに少なからず関わってみたい人には非常に向いているんじゃないかなと思います。
清水:ありがとうございました。本日用意したテーマに関しては以上となるんですが、このあと今来ている質問に答えていきたいと思います。時間の許す限りにはなりますが。では、上からにしようかな。
3名の方が現在の役割で仕事をしたうえでそれぞれ感じたやりがいを教えていただけますか? また逆にエンジニアとしてLINEを改善していきたいところがあるでしょうか? という質問です。このあたり、尾上さん、どうでしょうか?
尾上:えーっと、やりがい。
清水:さきほどわりと話の中で出てきた気もするんですが。
尾上:ちょっと繰り返しになってしまうかもしれないですけれども。最初の自己紹介でお話したように、私はDeveloper Productを担当していて、外部のデベロッパーの方とか、社内の各個別のサービスが作るサービスのプラットフォームとなるようなサービスを開発しています。LINEログインとかLINE Front-end Frameworkといったものです。
それっていろいろな使われ方をするので、かなり複雑な制約条件がいろいろ嵩んでいったりします。そういう複雑なところをいかにシンプルな実装に落とし込んで、外部の開発者の方とかが簡単に使えるようにする。複雑なものをすごくシンプルにするプロセスがおもしろいので、それはすごくやりがいになっていますね。
LINEの改善したいところは、LINEのプロダクトとかサービスの話ですかね? だとすると、まだまだDeveloper Productのプロダクトってそんなにシンプルですぐに使えますという状態になっていないところが、どうしてもいろいろ過去の制約とか互換性を維持するところとかであると思うので、そういったところをどんどんもっと使いやすいものにしていきたいなという思いはあります。
清水:なるほど。ありがとうございます。では時間もないので次の質問に移りたいと思います。それぞれの役割では、どういう成果やポイントが特に評価されますか? 逆に求められないポイントはあったりしますか? ここはEngineering Managerとしてどうでしょうか?。
金:開発業務での成果ももちろん大事なんですけど、やっぱりマネージャーとして求められるところを中心にちょっと説明しますと。
自分自身が率いるチームが成果を出すのも大事なんですけれども、それをマネージャー1人ですべて抱えて1人で全部かんばりましたというより、その過程でメンバーを成長させる。それぞれのメンバーに権限委譲ですけれども、そうしたことが非常に大事に求められていて。そうやってメンバー全員が取り残されず、全員が成長して高い成果を出したときに一番評価されるんじゃないかなと思います。
逆に求められないポイントは、特にないかなと思うんですけれども(笑)。表面上に出ている数値とか、それももちろん大事なんですけれども、やっぱりメンバーがそのチームにいることをどう思うかと、メンバーや自分自身が成長を感じられるのかっていうのが。
そういう調査のツールとかがあって、定期的にアンケートをとるのでそこで点数として表れます。1つでも怠るとちょっと下がる傾向が見えたりするので、日々1on1とかがんばるしかないかなって思っていますね。これで回答になったでしょうか?
清水:ありがとうございます。次の質問にサクッと移っていきたいと思います。コロナ後にチームで仕事の仕方に変化はありましたか? 順番に、松永さんどうでしょうか?
松永:職場環境は当然変わって、だいたい今、エンジニアはみんなほぼほぼ自宅で仕事をしていると思います。オフィスにいるときは、ほかの部署の人と雑談とかもあったんですけれども、最近はそういうのがないなと思います。
ただ仕事、プロダクトを開発する部分に関しては、実はそんなに変化はありません。海外にデザイナーがいたりとかもするんですけれども、その人とチャットでやりとりするっていうのは、もともとオフィスにいるときから変わっていませんし。
あと企画職。プランナーの職業の人たちは同じビルにはいたんですけどフロアが違うと実はチャットでやりとりしたほうが早かったりするので、同じビルの中にいるのにずっとチャットでやりとりしているみたいなのはけっこうあって。だから変化はあったんですけど、実は仕事自体には困ったこととかはあんまりないですね。
清水:そうですね。海外も含めてけっこう開発拠点が多くあって、もともとリモートに慣れていたとところはあると思うので、そこまで大きな変化というのはないですね。オフィスに来てみんなと雑談できないとか、そういったものはありますけれども。わりと慣れているところはあったのかなとは自分も思っています。
清水:次の質問です。プロダクトマネージャー、プロジェクトマネージャーはエンジニアリングマネージャーの方が担当されているのでしょうか? もしくは別の職種の方がいらっしゃるのでしょうか?
これは自分から答えると、兼務されている方は実際いたりはするんですけれども、本当にあるべき姿としては、プロダクトマネージャーであればプロダクトマネージャーにフォーカスしたほうがよく、プロダクトのほうにフォーカスしてやっていくべきというのはあります。そういったところは別のエンジニアリングマネージャーを立ててやるとか、そういったことはやろうとはしているんですけれども。
とはいえ、できる人ってなかなかすぐに出てくるわけではないので、そういった期間は兼務したりすることはあります。今言ったように、ちょっと繰り返しになるんですけれども、私個人の意見なんですけれども、分けてやるべきものだとは思っています。
清水:もうそろそろ時間ですね。どのロール(役割)が給料が上がりやすいとかありますか?(笑)。これはないと思います(笑)。お時間になってしまったので、質問は残りいくつかあるんですけれども、このあたりにしたいと思います。
みなさん今日のセッションは、どうだったでしょうか? 3つのキャリアについてそれぞれの立場でいろいろ話をして、質問にお答えしました。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
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには