KNOWLEDGE WORK Dev Talk #09 「プレイングマネージャーにとっては理想的な環境」tsuji
ナレッジワークで働くエンジニアたちのパーソナリティに迫るインタビューシリーズ、「KNOWLEDGE WORK Dev Talk」。これまでのキャリアの歩みや価値観、現在取り組んでいるプロジェクトなどについて質問していくコーナーです。ナレッジワークのVPoE（VP of Engineering）である木村 秀夫（hidek）と一緒に、ナレッジワークのエンジニアのイネーブルメントの源泉に切り込んでいきます。
第9回目となる今回は、 ラーニング領域のプロダクト開発組織のマネージャーを務める辻 純 (tsuji) に話を聞きました。
※過去のインタビュー記事はマガジンからご覧ください。
辻 純 (tsuji) / Learning Dev Group グループマネージャー
2004年、株式会社SCSK入社。ソフトウェアエンジニア職に従事。2006年、株式会社リクルート入社。ソフトウェアエンジニア職に従事。2014年、株式会社サイバーエージェント入社。ソフトウェアエンジニア職に従事。2024年、株式会社ナレッジワーク入社。
現在に至るプレイングマネジメントのキャリアの始まり
ーーまずは自己紹介をお願いします。
tsuji: 辻純と申します。2024年5月にナレッジワークに入社しました。現在ラーニング領域のプロダクト開発を担当しているLearning Dev Groupに所属し、グループマネージャーを務めています。いわゆるプレイングマネージャーとして、ピープルマネジメントやプロジェクトマネジメントなどの諸々のマネジメント業務を行いながら、バックエンドのコードも書いています。
現在、ラーニング領域のプロダクトでは、モバイルアプリケーション開発が進行中なんですが、僕自身は直接開発に深く関わらずに、他のメンバーがモバイルアプリ開発に集中できるよう、それ以外の開発業務を巻き取るようにしています。また、他グループのメンバーがプロジェクトマネジメントのサポートに入ってくれている関係で、現在の役割としては、マネージャーよりもプレイヤーとしての割合が大きいです。
ーーtsujiさんがエンジニアになることを決めたきっかけを教えてください。
tsuji: 私は大学は専攻が文系だったんですが、大学時代は正直かなり暇で、何をしていたかというと、主にインターネットを見ていたんです。当時はホームページや掲示板がインターネットの主流で、「どうやってこれを作っているんだろう？」と興味が湧きました。それから暇に任せて、いろいろと調べたり試してみたんです。そこでPerlやCGI、JavaScriptといった技術に触れたのが、私のエンジニアとしての原点ですね。
なので、そんな高尚な理由があるわけではなく、ただ暇だったんです（笑）。振り返ってみると、最初はそんな感じだったと思います。やってみたら面白いと感じて、「これを仕事にできたらいいな」と思ったのが始まりでした。
ーー辻さんがマネジメントに携わるようになったのは、どういう経緯なんですか？
tsuji: 2006年にリクルートに入社した際、会社の方針として「若手にマネジメントを任せてみよう」という動きがどうやらあったらしく、エンジニアリングマネージャーとして採用されました。なので自分で手を挙げたというより、指名いただいたという経緯です。
hidek: 今でこそエンジニアリングマネージャーについていろんな本が出版されていたりしますが、当時は業界でまだ明確に役割が定義されていた訳ではなかったですよね？具体的にどのようなマネジメントをされていたんですか？
tsuji: 現在のナレッジワークでの役割と同じく、当時からプレイングマネジメントなスタイルでしたね。チームの人数は今より少し多いくらいでしたが、マネジメント業務を行いながら、自分もプレイヤーとしてコードをバリバリ書いていました。
エンジニアリングと顧客の声が繋がる場。ナレッジワークとの出会い
ーーナレッジワークを知った経緯や、入社の決め手を教えてください。
tsuji: ナレッジワークを知ったきっかけは、tenntennさん（現newmoの上田拓也さん）がメルペイを退職してナレッジワークに入社した、という情報をメディアかSNSで見たのが最初です。もちろん存じ上げていたので「へえ、そうなんだ」って思ったのが最初ですね。そしていろんな露出情報をチェックしているうちに、mayahさん（CTOの川中真耶）とかよしこさん（フロントエンドエンジニアの吉田真麻）とか有名な方がいっぱい在籍しており、「エンジニアが強い会社なんだ」っていうのが最初の印象でした。
僕は当時サイバーエージェントで働いており、転職意欲がそれほど高くなかったんですけど、minoさん（グループマネージャーの味野大輔）とのカジュアル面談に誘っていただきました。で、受けてみたところ、minoさんってカジュアル面談がめちゃめちゃ上手いんですよ。面接が終わる頃には「選考に進みますか？」って言われて、気づいたら「はい」って答えていました。その時具体的に何が刺さったのかは覚えてないんですけど。
あとは、選考過程でプロダクトシェアデイ（注）に特別に参加させていただく機会があり、その体験が本当に響きましたね。顧客からの声やフィードバックを開発側が直接受け取る場があることに驚きました。
hidek: わかります。プロダクトシェアデイって、僕たちのプロダクト作りや会社そのものを象徴している場ですよね。一つのプロダクトに対して、エンジニア、プロダクトマネージャー、カスタマーサクセス、ビジネス、コーポレートの人たちが集まって話し合い、情報交換できる場ってなかなかない。開発側としては、顧客から直接お褒めの言葉をいただけたり、ニーズやリクエストを知ることができるのは貴重ですよね。
※注 プロダクトシェアデイ：ナレッジワークの全社員が参加する週一回のミーティング。各プロダクトに関する最新状況を顧客サイドと開発サイドの双方向でシェアする会
ーー面接で覚えているエピソードは何かありますか？
tsuji: まず、最初に受けるスキル面接は、minoさんが面接官でした。結果的にはパスできたんですが、面接中はとにかく緊張してしまいました。次にスタイル面接は、hidekさんが面接官でした。今はすごく笑顔でお話されているんですが、面接の時のhidekさんは笑顔が少なめだったので、少しビビったのを覚えています。
hidek: 僕、よくそう言われるんだよね...。
tsuji: でも、面接後半に「大人数のマネジメントって、メンバーのパーソナリティが分かりづらいですが、どうしたらいいでしょうか？」みたいな相談をしたんです。その時はアドバイスとして、「他の人や部署に聞いてみる」といった内容をおっしゃっていたと思いますが、その会話で少し笑顔が見えたので、安心したのを覚えています。
hidek: これ、面接の後で「絶対に落ちたと思いました。」とか言われることがたまにあるんですよ。自分の中では「この人めっちゃ欲しいな」と思っていても、応募者の方には「自分ではダメなんだ。どうしよう」って思わせちゃうみたいなんですよね。もっと柔らかい態度で臨むようにします（笑）。
tsuji: あと面接とは別の機会に、CTOのmayahさんとの面談をセットしていただき、面接で気になった部分について色々と話せる機会がありました。当時はナレッジワークがコンパウンド戦略を大体的に打ち出す前で、「プラットフォームを分割して、Monorepoで管理していく」という話をすでに面接で聞いていたので、その実情を詳しく伺うことができました。
tsuji: また、僕はグループマネージャー候補だと伺っていたので、mayahさんに「どういうことをマネージャーに求めていますか？」と質問した時に、第一声で「手をちゃんと動かせる人」という答えが返ってきたんです。一般的にはマネージャーって、マネジメントの素養が重要視されがちだと思うんですけど、プレイヤーでもあることが大事、とCTOの方が明確に宣言いただいたのが、すごく印象に残ってます。
そう考えると、ナレッジワークのエンジニアリングマネージャーは「プレイングマネジメント推奨」と、もっと強い対外的なメッセージングがあってもいいかもしれないですね。一応、求人要項には「プレイングマネジメント」ってワードをはっきり書いてはいるんですけど。
hidek: なるほど、確かに。プロダクトシェアデイが響いた、というエピソードに関連してもう少し聞かせてください。僕は前職までのキャリアにおいてずっとtoCのプロダクトに関わってきたのですが、実はtoBの方が顧客との距離が近いということに、ナレッジワークに入社して初めて気づきました。辻さんのこれまでのキャリアの中で、こういった顧客の声を聞けるような経験はありましたか？
tsuji: いえ、前々職のリクルートや前職のサイバーエージェントでは、事業としてtoBにもtoCにも関わる機会がありましたが、そういう場はあまり多くなかったです。いわゆるビジネスとエンジニアリングの情報の分断を感じることがありました。それが自分の中ですごく課題感としてありました。
プロダクトシェアデイに参加したのは、そういう悩みを抱えていたタイミングでもあったんです。「問題解決の糸口になるかな？」ぐらいの感覚で参加してみたんですけど、「こういう職場で働いた方が早いじゃん！」って思い、それが入社の動機になりました。
hidek: そうだったんですね。入社して実際にプロダクト開発に関わってから、顧客からの声は受け取れていますか？
tsuji: いえ、ラーニング領域のプロダクトはナレッジ領域のプロダクトに比較するとリリースして日が浅いので、まだまだ顧客のフィードバックを十分頂けているとは言えない状況です。プロダクトシェアデイで、ナレッジ領域のプロダクトに関するさまざまな顧客からのコメントが共有されているのを聞くと、すごく羨ましいですね。今後、いかにプロダクトを使っていただいて、多様なフィードバックをいただくことができるか、それをプロダクトの改善に活かせるかが当面の課題だと感じています。
ただ、エンジニア組織によっては、そういう顧客からの声が現場までなかなか届かないことも多いです。マネージャーは把握できていても、プレイヤーであるエンジニアには情報が届いていなかったり。ナレッジワークでは社員みんなに共有される仕組みがありますし、素晴らしい文化だなと感じています。
プレイングマネジメントの価値、求められるスキルとマインドとは
hidek: さて、今日は辻さんにプレイングマネジメントの働き方について色々と伺いたくて、たくさん質問を用意してきました（笑）。プレイングマネージャーって、聞こえはすごくいいし、理想的な役割として言われることも多いですが、本当のところはどうなのか聞いてみたいです。
まずは、エンジニアであればプレイヤーとしての価値はみんな理解していると思うんですが、プレイングマネージャーの価値ってどこにあると思いますか？
tsuji: いいですね。今日のインタビューは、まさにプレイングマネージャーの立場から、マネジメントのやりがいについてお話ししたいと思って準備してきました。僕は、マネジメントにおいてもプレイヤーであることには、大きな価値があると考えています。それによって戦術の幅が広がるからです。
例えば、納期が厳しいプロジェクトでタスクをこなさなければならない状況に陥ったとき、通常であれば他のチームから人を連れてきたり、今いるメンバーにさらに頑張ってもらうといった、他人に頼る選択肢を取ることが多いでしょう。しかし、もし自分がプレイヤーであれば、「じゃあ、自分が頑張ってやるか」と、自分でそのタスクに取り組むことができるんです。もちろん、これが常態化すると問題ですが、こういった自分で動く選択肢を持てることが、マネジメントにおけるプレイングマネージャーの価値だと考えています。
hidek: 確かに。僕もいろんな場面で、プレイングマネージャーにはどんなスキルが求められるのか聞かれることがあるんですが、僕が答えるのはまさに「いざという時に自分で何とかできるスキル」なんです。そういう意味で、今の話にすごく共感できるし、大事なことだと思います。
次の質問です。僕がいつも悩んでいるのは、チームの人数が増えてくると、評価や1on1など、メンバーとの日常的なコミュニケーションがどんどん大変になってくることなんです。プレイングマネージャーをやる上で、辻さんが考える適正な人数ってどれくらいですか？
tsuji: プレイングマネージャーとして現在と同じ振る舞いが可能なのは、おそらく「ピザ1枚で足りる人数」、つまり自分を含めて8人が限界だと感じます。リクルートに在籍していた頃は20人ほどマネジメントしていた時期もありましたが、今振り返ると正直無理がありました。
hidek: なるほど。自分も手を動かしつつ、ピープルマネジメントや戦略的なマネジメント、プロジェクトマネジメントも同時に行えるのは、8人くらいがちょうど良いバランスなんですね。
次の質問です。自分も過去にプレイングマネージャーを務めていた時期があるんですが、プレイングとマネジメントでは頭の使い方が全然違うんですよね。プログラミングは目の前のことに集中して、物を作り上げていく作業が中心ですが、マネジメントは目に見えないものと戦っているような感覚があって、ギャップを感じていました。辻さんも、プレイヤーとマネージャーを両立することの難しさって感じることはありますか？
tsuji: そうですね、マネジメントを始めた最初の頃は、確かにそういうのがあった気がしますね。コードを書きたいのに、ミーティングが多くて全く手を付けられないという状況がよくありました。特によくあったのは、日中の業務が全て終わってから、夜になってやっとコードを書き始めるという感じでした。昔はそんな風に仕事を進めていたんですが、最近はその切り替えが自分の中でかなり上手くできるようになってきたと思います。
hidek: 教えて欲しいんですけど、どうやってその切り替えをしているんですか？
tsuji: うーん、自分では具体的な方法はあまり思い浮かばないんです。一般的には、時間で区切るのが良いとか言われていますけど、僕はミーティングの合間の5分間にコードを少しだけ書いたりすることも普通にできるんですよね。それを話すと、よく「すごいですね」と言われるんですが、どうしてできるのかと言われると、正直自分でもよく分からない。多分コンテキストスイッチが早いタイプなんだろうなとは思います。
hidek: なるほど。僕は切り替えがうまくできないタイプなので、両立している人は本当にすごいなと感心します。僕は、一度プログラミングを始めると、つい没頭してしまうんですよ。かつてプレイングマネージャーだった頃、コードを書くことに集中し過ぎて、メンバーに重要なことを伝え忘れたり、会議をすっぽかしたり、チーム全体のことを考えられなくなることがありました。ある時、メンバーの一人から「もうコード書くの辞めてくれ」と言われたのがきっかけで、マネジメントに専念するようになりました。
tsuji: ありがとうございます。確かに、マネジメントとプレイングの切り替えは難しい部分もありますね。でも、プレイヤーとして複数のプロジェクトを掛け持ちしていると、自然と思考の切り替えが必要になることがよくありますよね。
たとえば、あるプロジェクトでコードを書いている最中に、別のプロジェクトに移って別のタスクに取り組むことは日常茶飯事じゃないですか。プレイヤーであればそういった状況には日常的に対応しているはずなので、自分としてはマネジメント業務にスイッチしても、実際にそれほどギャップを感じることはないんですよね。
hidek: なるほど。マネジメントっていろんな業務が同時並行に進みますよね。自分はマルチタスクは苦手で、時々パニックになってしまうので、ドキュメントやタスク管理ツールなどの仕組みに頼って対処しています。辻さんのように細やかに気を配って、すぐに切り替えられる人は個人的に羨ましいです。
tsuji: ありがとうございます。でも「ちゃんとできているか？」と聞かれると、正直ちょっと不安ですけどね。
マネジメントに正解はない。手探りで最適解に挑むアプローチ
hidek: では、現在のLearning Dev Groupでの組織マネジメントについて質問していきます。
ナレッジワークではマルチプロダクト戦略を掲げており、3年で10個のプロダクトをリリースしようとしています。より良い品質のプロダクトをより早く顧客に届けるためには、チームに自律性を持たせる必要があるため、スキル型ではなくドメイン型の組織を採用しています。Learning Dev Groupにも、バックエンド、フロントエンド、QAといった様々な領域のエンジニアがいますよね。辻さんは元々バックエンドエンジニアですが、自分のスキルとは異なる領域のエンジニアを対象にマネジメントすることについてどう感じていますか？
tsuji: その点については、マネジメントを始めた当初から課題を感じており、現時点でもまだ明確な答えは見つかっていません。例えば、QAやフロントエンドのように、チームに一人しかメンバーがいない領域については、詳細まで把握できないことが多いです。
対応策としては、自分からは主にメンバー全体に共通する課題を軸にコミュニケーションを取るようにしており、個別の技術的な詳細にはあまり踏み込まないようにしています。例えば、フロントエンドに関しては、フロントエンドギルド（フロントエンドエンジニアの横断的な情報共有・意思決定を目的とした組織体）からフィードバックをもらうことで、技術的なリファレンスを得て補っています。
hidek: なるほど、この辺りはスキル型組織とドメイン型組織の永遠の課題ですね。
tsuji: なお、前職のサイバーエージェントではチームにデータサイエンティストもいたので、彼らの評価も担当していました。技術面については、ナレッジワークと同様にギルドのような職能組織が存在していたので、その組織にリファレンスを取りながら進めました。評価においては、「プロダクトの課題に対して、その職能・職責としてどのように貢献したか」を重視していました。
hidek: ありがとうございます。ナレッジワークはプロダクトカンパニーを標榜しているので、僕も評価の方向性としてはプロダクトへの貢献度が正しいと思っています。同時に僕たちが重要視しているイネーブルメント、つまりスキル向上や支援に関しても取り入れながら評価を進めていきたいですね。
hidek: 次に、開発体制に関しても質問させてください。現在パイロット的に、ラーニング領域のプロジェクトマネジメントに、他の組織から1名サポートに入っています。目的としては、マネージャーは、ピープル・技術・プロジェクトのマネジメントを両立させる必要があるわけですが、人によって得意不得意があるので、外部から上手く補完するのが狙いです。ピープルマネジメントは、目標設定や評価など、マネージャー自身が責任を持って行わなければなりません。ただ、プロジェクトマネジメントは標準化しやすく、評価も外部に任せやすい。実際にこの体制で進めてみていかがでしたか？
tsuji: すごく良い取り組みだと感じています。前職までの経験から、ドメイン知識を持たない人がプロジェクトマネジメントを行うのは難しいと感じており、このサポート体制を試してみるまでは正直やや懐疑的だったんです。でも、補完関係がしっかりしていれば全然成り立つことが、この数ヶ月の運用で分かりました。
もちろん、詳細なタスクまで完全には把握することは難しいかもしれませんが、デイリースクラムやプランニングで補完すれば十分回ることが分かりました。取り組みとしては、とても良いと感じています。
hidek: なるほど、ありがとうございます。実は、僕らがこれからプロダクトを次々と作っていく中で、CTOのmayahさんを新しいプロジェクトにどんどんアサインして、プロジェクトマネジメントを外部からサポートする戦略を考えています。そのパイロット版としての取り組みはとても良かったですし、本当に助かっています。これがモデルとなって全社に展開できれば、さらに素晴らしい成果が期待できそうですね。
最後に、現在チャレンジしているモバイルアプリケーション開発に関する質問です。ナレッジワークはこれまでウェブアプリケーションを主戦場としてきたので、社内にモバイルアプリの開発ノウハウが全くなく、まさにゼロからのスタートでした。
実は、僕自身もモバイルアプリの立ち上げ経験はほとんどありません。DeNA時代にはモバイルゲームの開発に関わっていましたが、主にプラットフォーム側、つまりサーバーサイドを担当していました。また、その時はモバイルアプリ開発のノウハウがすでに確立されていた状態だったので、実質このナレッジワークが初めての経験となります。辻さん的には、このような状況でマネジメントを進める中で、難しさを感じていますか？
tsuji: それが実は、「なぜこんなにうまくいっているんだろう？」と少し不思議に感じるくらい、順調に進んでいます。2024年の7月から本格的にモバイルアプリの開発がスタートしたんですが、最初の1ヶ月は本当に何も分からなくて、僕自身もメンバーも手探りの状態でした。でも開発をスケジュール通りに進めることができ、顧客に自信を持って使っていただけるものを開発することができました。
理由としては、もちろんメンバーが非常に優秀だというのも大きいです。しかし、振り返ってみると、モバイルアプリ開発の豊富な経験を持つメンバーはいなかったものの、全員が「これをやらないとまずい」といった勘どころをしっかりと理解してプロジェクトを進めていたことに気づきました。
例えば、Flutterの経験がある外部の方に業務委託として協力いただき、設計方針の核心部分を最初にレビューしてもらったり、考えていただいたりしました。それがうまくハマったおかげで、今ではメンバーがどんどん吸収して、どんどん開発を進めることができています。この現在の状態を見ると、当初のリスク管理が非常にうまく機能したのが大きいと感じています。
hidek: なるほど。ナレッジワークにはキャリアとして2週目、3週目のシニアエンジニアが多いですよね。自分たちが直接モバイルアプリ開発の経験がなくても、周りにそういう経験を持った人たちやチームがいたからキャッチアップできたんでしょうか？
tsuji: おっしゃる通りです。開発がスタートしてから、チームとしてのイネーブルメントはかなりできてる印象があります。僕自身は、アプリ開発には直接タッチできていないので、ビハインドしているんですけど。
hidek: 素晴らしいですね。ナレッジワークでは、バックエンドエンジニアやフロントエンドエンジニアといった肩書きで役割を分けていますが、ある程度は一つの分野にスペシャリティを持ってもらいたいと考えています。ただし、それに固執するのではなく、スキルセットを広げ、裾野が広がる形で成長してほしいと思っています。そうすることで、自分の得意分野が外からも見えやすくなり、成長につながります。Learning Dev Groupではバックエンドエンジニアも含めて、モバイルアプリのコーディングに積極的に取り組んでいます。それこそ、まさにそういう広がりのあるスキルセットを発揮していると感じていて、とてもいいことだと思っています。
hidek: そういった中で、僕たちも開発組織をどんどんスケールさせていきたいと考えています。ナレッジワークでは、これからも新しいプロダクトを次々と生み出していきますが、そうやって新しい領域に挑戦しながら、プロダクト開発のサイクルを回していけると良いですね。その最初の一歩をLearning Dev Groupがやってくれたことが、本当に嬉しいです。
tsuji: ありがとうございます！
1→10のフェーズに挑む。ナレッジワークの成長と共に歩むキャリア
ーーLearning Dev Groupとして今後の展開や、挑戦したいことはありますか？
tsuji: まず、プロダクト開発としては、現在取り組んでいるラーニングイネーブルメントの開発をしっかりと進めながら、新しい領域であるピープル領域にチャレンジしようという動きが、今のグループ内ですでに出てきています。その展開がすごく楽しみです。
hidek: 僕たちナレッジワークが挑む対象が、ナレッジ、ワーク、ラーニング、ピープルという4象限の領域がある中で、ラーニング領域をさらにピープル領域へ広げていくという動きですね。これら二つは親和性が高いので、すごく良い方向性だと思います。そのあたりをLearning Dev Groupとして進めていき、もし規模が大きくなってきたらチームを分けてオーナーシップを持たせるという形も考えられますね。
ーー辻さんの今後のキャリアについてはどのように考えていますか？
tsuji: 実は自分自身のキャリアについては、あまり深く考えていないんです。今やっている仕事はとても楽しいですし、まだ今のポジションでも成長の余地があると感じています。今の自分のマネージャーとしての能力は、現在は8人くらいの規模かもしれませんが、まだ伸ばせる可能性があると思っています。
プロダクト視点でいうと、これまでのキャリアでは、既に土台ができあがったものをうまく運用したり、逆に何もないところから事業を立ち上げることをいくつか経験してきました。でも、会社やプロダクトをものすごく成長させることができた、1→10のフェーズの体験はまだありません。
ナレッジワークでは、1年後や3年後に向けた非常に大きな目標を掲げていますが、その達成に立ち会えることができたら、今やっている自分のロールとしての集大成になるのかなと思っています。まずはしっかりそこに取り組みたいですね。つまり、会社やプロダクトの成長と共に、自分自身も成長していきたいという気持ちです。
hidek: いいですね！ぜひ一緒に頑張っていきたいです。
ーー辻さんはどういったメンバーと働きたいですか？
tsuji: 今一緒に働いているチームのメンバーが、まさに理想的な人たちですね。ナレッジワークのスタイルにしっかりマッチして入社してくれている方が多いので、スタイルに共感してくれる方には、非常に良い環境だと感じてもらえると思います。
ーー最後に、ナレッジワークをこれからの転職先として検討いただいている方に、何かメッセージがあれば。
tsuji: 先ほども述べた通り、プロダクト作りにおいては、他の会社ではなかなか得られない、顧客との距離が近いプロダクト開発の体験ができるのが特徴です。それに加え、会社の文化として、スタートアップ特有のスピード感や熱量がありながらも、組織や制度はしっかり整っているという、その両面が非常に魅力的だと思います。
繰り返しになりますが、プレイングマネジメントができることも大きな魅力です。前提として、エンジニア一人ひとりの技術力が非常に高くて、こと技術的な会話においてはハイコンテクストで済むおかげで、細かい説明や確認が少なくて済み、スピード感を持って仕事に取り組みやすい環境だと感じています。プレイングマネージャーをやりたい人にとっては、ナレッジワークは本当に理想的な会社だと思います。
もしそういった方がいらっしゃれば、ぜひカジュアル面談で私をアサインしてほしいです。ナレッジワークの良さをたっぷり語りたいと思います（笑）。
ーーありがとうございました！
（取材・編集：三木鉄平 / 撮影場所： WeWork 神谷町 共用部）
【採用情報】 ナレッジワークでは、一緒に働くエンジニアを募集しています
採用ページ（求人一覧・エンジニア向け採用情報）
技術ブログ（Zenn / Note）
技術勉強会・採用イベント（Connpass）