KNOWLEDGE WORK Dev Talk #05「品質と成長の両立を目指す。QAイネーブルメントの挑戦」tettan
ナレッジワークで働くエンジニアたちのパーソナリティに迫るインタビューシリーズ、「KNOWLEDGE WORK Dev Talk」。これまでのキャリアの歩みや価値観、現在取り組んでいるプロジェクトなどについて質問していくコーナーです。ナレッジワークのVPoE（VP of Engineering）である木村 秀夫（hidek）と一緒に、ナレッジワークのエンジニアのイネーブルメントの源泉に切り込んでいきます。
第4回目となる今回は、 ナレッジワークでQAイネーブルメントを推進する河野 哲也 (tettan)に話を聞きました。
※過去のインタビュー記事はマガジンからご覧ください。
河野 哲也 (tettan) / QA Enablement Group QAエンジニア
工業高校卒業後、日本無線でハードウェアのQAに従事。その後、電気通信大学夜間主コースに入学。ソフトウェアQA関連研究に触発され博士課程に進学。博士号取得後、2011年、株式会社日立製作所、2017年、株式会社ディー・エヌ・エー、2021年、株式会社メルカリに入社。すべてソフトウェアQAエンジニアとして従事。2023年、株式会社ナレッジワーク入社。
企業文化と価値観がフィットし、成長期にあるナレッジワークへ
ーーまずは自己紹介をお願いします。
tettan: 河野 哲也です。tettanと呼ばれています。現在QA Enablement Groupに所属し、ナレッジワークの品質保証活動をプロダクト横断で推進しています。また、ラーニング領域のプロダクトを開発している、Learning Dev GroupでQAエンジニアも兼務しています。
これまでのキャリアについてお話しすると、高校を卒業して、まず日本無線という会社に就職しました。そこでは検査部という品質管理や品質保証が重要視される部署で、ハードウェアのテストを担当していました。その後、電気通信大学に入学したのですが、研究室ではソフトウェアにおけるテストやQAを専門にしている先生のもとで学び、そこからソフトウェアのQAにキャリアチェンジをしました。卒業後、日立製作所に6年弱勤め、QAエンジニアとして働きましたが、後半にはリーダー的な仕事も担当しました。
tettan: 次に、DeNAに転職し、3年少し働きました。ちなみに、その時の採用面接官はhidekさんで、入社後も直接レポートしながら一緒に仕事をしていました。最初はQAマネージャーを担当していましたが、途中からQAエンジニアに転向し、新規プロダクトの開発などに携わりました。
その後、メルカリに入社し、IC（インディペンデント・コントリビューター）として2年間働きました。入社してすぐに新規プロダクトにアサインされて、グローバルメンバーの中で唯一のQAエンジニアとして立ち上げに携わりました。また、メルカリ本体のモバイルアプリのリプレースも担当しました。そして、ナレッジワークに2023年5月から入社して、現在に至ります。
ーー大きな企業でキャリアを積んできたtettanさんが、スタートアップに転職した理由を教えていただけますか？
tettan: 転職の理由は大きく3つあります。まず1つ目は、これまでのキャリアで経験していなかった「会社が大きくなるフェーズ」を体験したかったからです。これまで働いてきた企業は、ある程度完成された組織が多かったので、成長期のフェーズを経験できることがモチベーションとなりました。
2つ目は、QAの組織が大きくなるフェーズも未経験だったからです。僕はナレッジワークに4人目のQAエンジニアとして入社しました。それが5人、10人、20人と増えていく過程で、QAの組織に貢献していくことに挑戦したいと考えました。
3つ目は、僕のこれまでのQAエンジニアとしての経験を、新しい会社で試してみたかったからです。成長段階にある会社で、僕の持っている知識や経験をどのように活かして、インパクトを与えることができるのか、興味がありました。
ーーありがとうございます。他の成長途上にあるスタートアップではなく、なぜナレッジワークを選んだのでしょうか？
tettan: その理由は非常にシンプルです。「お金の匂いがしない会社」だったからです。
hidek: なんか分かる気がします（笑）。
tettan: お金儲けが第一であるという思想が経営者になく、事業を拡大すること自体が世の中のためになる、という価値観が根底に感じられました。個人的な印象として、過去に在籍してきた企業と比較すると、ナレッジワークはコトに向き合う意識が強く、mayahさん（CTOの川中）を始めとして経営者の考え方も落ち着いていて、魅力を感じたんです。
ーーなるほど。ストイックな企業文化と相性が良かったという感じでしょうか？
tettan: そうですね。正直なところ、これまでのキャリアで少し疲れを感じることがあり、もう少し落ち着いて働きたいと思っていました。そんな中でナレッジワークはまさにそのニーズにぴったりだったんです。なので、選考を受けたのはナレッジワーク一社だけでした。実際に入社してからも、事前に抱いていた印象と現実とのギャップは全くありませんでした。
いまだ黎明期にあるBtoBの品質保証。QAイネーブルメントの新たな挑戦
ーーQA Enablement Groupが立ち上がった経緯や、具体的な役割について教えてもらえますか？
tettan: 今のところ、QA Enablement Groupの活動は、大きく二つの軸に分けることができます。
一つ目は、QAエンジニアの育成です。元々、ナレッジワークにはQAグループという組織が存在し、各メンバーがプロダクト開発グループに分散して品質保証業務に携わっていました。しかし、形式上はQAグループに所属しているものの、実際にはほとんどの業務を開発チームで行っていることに違和感を覚えていました。この問題を解消するため、全メンバーを開発チームに正式に所属させることにしました。ただし、若手や中堅メンバーの育成を完全に開発チームに任せることに懸念がありました。そこで、QA Enablement Groupがその育成部分を担当することになりました。
二つ目は、品質指標の統一など、組織横断の活動です。各開発グループがそれぞれ独自のやり方で進めるよりも、一定の標準化された方法で進める方が効果的です。例えば、品質指標を取る際に、各グループが異なる基準を使用していると、比較が難しくなり、統一的な評価ができなくなってしまいます。そのため、共通の基準で品質指標を設定したりして、開発グループ間で優れた取り組みやノウハウを共有できる体制を整えています。
hidek: 実際に運営してみて、難しさや課題はありますか？
tettan: 難しさとしては、QA Enablement Groupが7月に立ち上がってからまだ3ヶ月しか経っておらず、組織としての方向性がまだ完全には固まっていない事です。従来から運営されているQAメンバーが集まるミーティングをQA Guildという形で維持しながら、役割の違いを明文化したり、存在意義を模索している状況です。しかし、その試行錯誤の中で、若手の育成や品質指標の統一といった、組織全体の品質向上に向けた取り組みは着実に進んでいます。
hidek: 僕たちが取り組んでいるBtoBのSaaS事業は、品質管理や品質保証の観点から見ると、まだアーリーステージにあると言っても過言ではないと思います。このような状況の中で、ナレッジワークでのQA活動について、tettanさんがこれまでの経験と比べて異なると感じる点はありますか？
tettan: 以前働いていたメルカリのようなBtoC向けプロダクトでは、非常に速いリリースサイクルが求められていて、QAエンジニアにはフットワークの軽さが重視されていました。しかし、ナレッジワークではリリースのスピードよりも、お客様にどれだけ価値を提供できるかが重視されます。そのため、よりしっかりとした品質管理が必要とされる傾向があります。事業ドメインの違いもありますが、そこは勉強しながら進めているところですね。
tettan: また、これはステージの違いというより文化の違いですが、ナレッジワークでは、僕が何か提案をすると、みんなが「やってみよう」と前向きに受け入れる雰囲気があり、非常に仕事がしやすいと感じています。QAエンジニアの仕事は単にテストを行うだけでなく、開発プロセス上の問題を発見し、その解決策を提示することも重要な役割です。ナレッジワークでは、提案に対してさらに別のアイデアが追加され、より良い解決策が生まれるという文化が根付いており、この点がこれまでの経験とは大きく異なると感じています。
ーー現在ナレッジワークでは、ジュニア層やポテンシャルのある人材の採用を進めていますが、その狙いについて教えてください。
tettan: まず、日本のQA・テストエンジニアにとって最大の課題は「成長できる組織が少ない」ことだと感じています。僕が目指しているのは、ジュニア層やポテンシャルのある人材が、僕を含めたナレッジワークのQAメンバーと関わりながら成長していくことです。QAエンジニアの成長を見守るのはとても楽しいですし、一緒に働けることがさらに充実感を与えてくれます。
そのため、採用活動においては「ナレッジワークには若手が成長できる環境が整っている」というメッセージを重視しています。本気でチャレンジしたいと考える人に対して、成長の機会があることをしっかり伝えることが大切だと思っています。
ただし、外部の方へのイネーブルメントだけでなく、僕たち自身のイネーブルメントも同様に重要です。そのため、スキルのアセスメントやQAのキャリアラダーの整備にも力を入れています。これにより、ジュニア層やポテンシャルのある方が入社しても、成長を支えるための準備がしっかりと整っているという実感があります。
hidek: そういった若手のQAエンジニアが成長するための秘訣や、何かアドバイスはありますか？
tettan: QAエンジニアに限った話ではないですが、僕がエンジニアとして成長するために大事だと思うのは、2つのマインドセットです。
1つ目は「謙虚さ」です。一定の謙虚さがないと、周りからのフィードバックを前向きに受け入れて、自分自身にフィードバックをかけることが難しくなります。成長するためには、他者の意見や指摘を素直に受け入れる姿勢が欠かせません。
2つ目は、少し矛盾するかもしれませんが「勘違いする力」です。謙虚すぎると自己評価が低くなりすぎて、成長のチャンスを逃してしまうことがあります。僕は「自分はできる」という多少の勘違いができる人が伸びると考えます。常に謙虚であるだけではなく、「今は未熟かもしれないけど、自分はやればできる」というポジティブな自己認識、強いメンタリティを持つことが重要だと思います。
特にQAエンジニアには「謙虚すぎる」タイプが多い印象があります。多くの人が、周りの意見に従順で、自分に厳しく反省する傾向が強いです。しかし、時には「自分ってすごいかも」と思えるくらいの自信を持っても良いのではないかと思います。
hidek: なるほど、それは面白い視点ですね。確かに言われてみると、QAエンジニアの方は尖った性格や、自己主張の強い方が比較的少ないかもしれません。
tettan: そうなんです。もちろんバランスが大事で、謙虚すぎてもいけないし、勘違いだけでもダメです。その間で自己成長をうまく促せる人が成功すると思います。
QAと開発が良好な関係でいるために必要なマインドとは
hidek: 実は、僕がDeNAでの面接で初めてtettanさんと出会い履歴書を見たとき、とても新鮮に感じました。それまで長い間QAエンジニアの採用に携わってきましたが、tettanさんのようにアカデミアで品質管理をしっかり学んできた方に出会うことはあまりなかったからです。大学で品質管理を専攻された背景には、どのような理由があったのでしょうか？
tettan: 冒頭でお話しした通り、キャリアの当初、僕は日本無線でハードウェアのテストを担当していました。その後、夜間の大学に通うことになった際、仕事に関連が深い信頼性や品質管理の分野を専攻するのが、最も違和感がない選択でした。そして、大学4年生の時にソフトウェアテストを専門とする先生の研究室に配属されて、そこからソフトウェアに軸足を移すことになりました。卒業時、多くの先生からは学士号を取得後に企業に戻ることを勧められましたが、ソフトウェアテストが専門の先生だけが大学院進学に理解を示してくださり、最終的に博士号を取得しました。
hidek: その分野を専門的に学んだ方々がどこで働いているのか興味があります。というのも、僕はこれまでそういった方々と出会う機会が少なかったので。
tettan: 僕がいた学科の卒業生たちは、有名な大企業でエンジニアとして働いている人が多いですね。日本では、品質管理を専門に教える先生自体が少ないということもあり、そういった知識をベースに持つ人材は貴重だと思います。僕が所属していた研究室の指導教官の先生たちには、ISO9000の推進に大きく貢献し、日本の品質管理をリードしてきた飯塚悦功先生がいらっしゃいました。さらにその上には、久米均先生や石川馨先生といった、日本の品質管理の礎を築いた方々がいました。そのような環境で学んでいく中で、日本的な品質管理の考え方が自然と自分の血肉となっていきました。
hidek: 品質管理や品質保証は、日本では特に製造業において長い歴史があり、ナレッジが積み上げられてきた分野ですよね。一方、ソフトウェア業界では、今ではかなり改善されてきましたが、軽視されがちだった時期もありました。例えば「QAさん」「テスターさん」といった呼ばれ方に、僕自身も違和感を覚えていました。一方で、QA側が開発者を「エンジニアさん」と呼ぶのを耳にすることがありますが、これも個人的には好ましいと思っていません。QAエンジニアもエンジニアでありお互いの意識を変えていくことが大切だと考えています。
tettan: それはソフトウェア業界全体にとっての課題ですね。開発とQAとの間に、若干の距離感や序列関係が存在します。
hidek: その背景には構造的な問題もありますね。テスト工程は、アジャイルであれウォーターフォールであれ、開発プロセスにおいて後工程に位置付けられることが多い。ものを作った後にテストするのが一般的なので、どうしてもテストフェーズにしわ寄せが集中してしまう。個人的にそこは気をつけるようにしています。
tettan: そうですね、とはいえ開発側だけでなく、QA側の問題もあります。QAが受け身で仕事を進める場面もありますし、その結果として序列が生まれてしまうこともあると思います。一方で、開発側の認識や見方も影響しているでしょう。だからこそ、両者が協力して上手くやることが必要です。
hidek: その点で、QA Enablement Groupのメンバーがよく話している「シフトレフト（Shift-left）」（注1）のマインドセットが非常に大切だと思います。同時に、プロダクトマネージャーや開発エンジニアは「シフトライト（Shift-right）」（注2）を意識すべきだと考えています。開発プロセス全体のオーナーシップをチーム全員が持つことが重要で、それぞれの専門性や役割がありつつも、開発の全体像に対する意識を高めていってほしいですね。その考えを、tettanさんは高いレベルで体現している一人だと感じています。
tettan: ありがとうございます。
【注1】シフトレフト（Shift-left）：品質保証活動を開発ライフサイクルの早い段階で実施するアプローチ
【注2】シフトライト（Shift-right）：品質保証活動をリリース後にも継続的に実施するアプローチ
品質管理やQAを取り巻く状況と、未来の方向性
hidek: 海外での事情についても教えてください。品質管理やQAに関してはどのような状況なのでしょうか？
tettan: 欧米では、ISO9000が品質管理のモデルとして広く採用されています。ISO9000では「品質保証＝テスト」という捉え方が強いため、QAエンジニアは「動作確認をする人」と見られがちです。QAエンジニアという職種自体が存在しない企業も多く見られ、日本でも同様の傾向が少しずつ増えてきているように感じます。しかし、企業によってはQAエンジニアの役割が非常に幅広く、テストにとどまらず、品質全般に関わる重要な役割として認識されている場合もあります。
hidek: なるほど、勉強になります。ソフトウェア開発の世界では、 最近ではSRE（Site Reliability Engineering）がトレンドとなっており、特定の職種ではなくチーム内で役割を分担するという意識が強まっていますが、QAの役割も変化していくのでしょうか？
tettan: それに関しては、2つの方向性があると考えています。1つ目は、QAエンジニアがチームの一員として、開発者寄りの仕事にシフトしていくことです。例えば、APIレイヤーのテストやユニットテストのカバレッジが不足している場合、QAエンジニアがその部分を補うといった形です。プロダクトコード自体には触れないものの、その周辺のコードには関わるという進化の方向性です。
2つ目の方向性は、もう少し引いた目線で、会社や組織全体の品質指標や品質管理をどうするか、という観点に立つことです。品質マネジメント全体を俯瞰し、ディープダイブする役割が求められていると感じています。ただし日本のソフトウェア業界では、その重要性がまだ十分に認識されていないのが現状です。
hidek: なるほど。製造業だと品質管理や品質保証の重要性はしっかり認識されている印象がありますが、ソフトウェア業界ではまだまだ不十分ですね。
tettan: その通りです。例えば、日立製作所には品質保証本部という、全社横断で品質保証をどう進めていくかを考える部門が存在していました。社長直下で事業部から独立しており、どの事業部からも干渉されない形で品質を守る役割を担っています。ナレッジワークでも、そのような体制の良い部分を上手に応用できると良いかもしれないですね。
hidek: AIの影響についてもお伺いします。実装の領域では、例えばGitHub Copilotを使用しても結局手直しが必要なことが多いです。一方で、テストの領域では、例えばユニットテストはある程度完成度高く書いてくれることが多く、工数がかなり削減されています。つまりQAの業務はAIの影響を受けやすく、将来的にAIに仕事を代替される可能性すらあるのではと感じているのですが、今後この関係性はどうなっていくと思われますか？
tettan: そうですね、テスト計画やテスト設計に関してはある程度AIがサポートできる部分はあると思います。ただ、AIが得意なのは決まったコンテキストの中で何かを生成することです。例えば、ソースコードを基にユニットテストを書く場合、ソースコードには明確な文法があり、その中でAIが答えを導き出します。
tettan: 一方で、テスト計画はコンテキストが多様すぎるため、AIが出す答えが的外れなこともあれば、上手くいくこともあります。テスト設計についても同じで、AIが自然言語で書いたものが良い設計になることもあれば、「ちょっとイマイチだな」と感じることもあるでしょう。大事なのは、その「イマイチだな」を判別できるスキルです。ある程度のスキルがないと、AIが出した答えが適切かどうか判断できないので、そうした判断力や、出力されたものを加工する技術は必ず残ると思います。
AIが出した複数の答えをミックスして一つの成果物を作る作業は、より高度な仕事になってくると思います。いろいろ出てきたものを組み合わせて1つの成果物を作るというのは難しい領域なので、そうした判断が必要な部分は今後も残る仕事だとイメージしています。
hidek: テストケースを仕様書や要件定義書から作成することは、ある程度AIに任せられるかもしれませんが、最終的にテストケースが正しいかどうかを判断するのは人間の仕事として残る、ということですよね？
tettan: そうです。実際にAIがテストケースを作成しても、「ちょっとイマイチだな」というケースはまだまだ多いと思います。だからこそ、最終的な判断基準を持って「これなら問題ない」という判断をできるかどうかが重要です。
hidek: その考えを踏まえると、品質保証の分野では、シフトレフトの動きがさらに重要になるんじゃないでしょうか？AIが進化しても、コンテキストの理解を深め、早い段階から品質を考慮することが必要だと思いますが、どう思います？
tettan: そうですね。企画の段階からQAが関与し、テスト計画に必要なデータを整備して、AIに食わせるための情報をしっかり準備することで、より良いテスト計画を立てることが可能になります。究極のシフトレフトを実現するには、仕様書にテストの視点を加えて、AIが精度の高いテストケースを生成する流れも考えられますね。
hidek: なるほど。そのアプローチが進めば、AIが生成するテストケースの精度も向上しますよね。
tettan: その通りです。その段階で仕様の矛盾や抜け漏れをQAエンジニアが見つけられるようになれば、結果的に仕様自体の精度も上がっていくと思います。こうした役割がQAエンジニアにはますます求められるでしょう。
hidek: QAの仕事って、要件定義に対して開発が出したものをテストしてリリースするだけだと思われがちですが、実は「魅力的品質」を高める役割もありますよね。これは、顧客からのフィードバックを開発に反映させるチャレンジでもあり、コミュニケーション力などのソフトスキルが必要です。こういう部分では、まだまだ人間の役割が大きそうですね。
tettan: そうですね。CS（カスタマーサクセス）と連携してユーザーの声を聞き、その洞察を企画やエンジニア側にフィードバックすることで、より感度の高い開発ができるようになるはずです。
hidek:そう考えると、QAエンジニアのキャリアにはまだまだ広がりを感じますね。それをナレッジワークで実現してほしいです。
tettan: 同感です。世の中ではQAエンジニアの領域が狭く見られがちで、「開発者にテストも任せればいい」という意見もあります。QAエンジニアの専門性が、まだまだ十分に認知されていない。僕はそれに違和感があります。職種にはそれぞれの専門性があり、その専門性を持った人がその役割を担うべきだと思います。
例えば、「開発者にCSの仕事も任せればいい」という声を聞くことがあるでしょうか。プロダクトをリリースした後、問い合わせ対応をし、そのフィードバックを開発に生かすのは開発者にとっても有益ですが、実際には開発者がCSをやることはほとんどありませんよね。
hidek: なるほど。その認知を広げたり、ロールモデルを作っていくことが、ナレッジワークとしての大きな役割になるかもしれませんね。
ナレッジワークのQAの価値を社内外で広げ、インパクトを与えていく
ーー今後、ナレッジワークのQA組織や活動をどのように向上させていきたいと考えていますか？
tettan: 僕がナレッジワークで実現したいのは、QAエンジニアだけが品質に責務を負うのではなく、プロダクトに関わる全員が品質にコミットする組織文化です。そのためには、QAエンジニアが「やりすぎない」ことが大切です。関係者を巻き込みながら、全員でテストや品質管理を進めていくことが理想です。例えば、プロダクトマネージャーやデザイナーにもテストに参加してもらい、全員で品質に向き合う仕組みが必要です。QAエンジニアがすべてを抱え込まず、他のメンバーも品質に関心を持って一緒に高めていく。このような文化がナレッジワークでは可能だと思っています。
tettan: また、「ナレッジワークのQAで働くと確実に成長できる」と対外的に認知される組織にしていきたいです。これが実現できれば、カンファレンスでの発表や外部での発信活動が当たり前になり、「ナレッジワークのQAエンジニアから良い話が聞ける」と評価されるような人材を輩出できる組織になっていると思います。社内での成果はもちろん、外部にも積極的に情報を発信し、そのフィードバックを受けて社内改善に繋げる。そうした外と中の行き来が活発な組織を目指したい。QAエンジニアは内向きになりがちですが、外での発信も重要だと思います。
hidek:僕も、品質管理や品質保証の分野は、事業やプロダクトの性質に関わらず、ある程度パターン化できるんじゃないかという仮説を持っているんです。もしその仮説が正しいなら、ナレッジワーク発の品質保証の仕組みを外部に発信できたら、社会全体のイネーブルメントにも繋がるし、すごくかっこいい。それができたら、本当に魅力的ですよね。
tettan: そうですね、パターン化に関してはフェーズによる文脈が重要です。立ち上げフェーズでは難しいかもしれないですが、プロダクトがある程度進んだフェーズでは、「このチームならこういうやり方が合っている」といった形で、一定のパターン化は可能だと思います。
hidek:うん、確かにこのフェーズではこういう品質担保のパターンがある、みたいに整理できますよね。プロダクトが成長して、組織やユーザーの規模が大きくなるにつれて品質基準も変わってくるし、事業フェーズに応じたパターン化は十分できそうな気がします。
tettan: そうですね。例えば「QA組織を立ち上げたいなら、ナレッジワークの資料を見るといいよね」という認識が広がれば、業界内での地位も確立できるし、外部からの評価にも繋がると思います。
hidek:もう一点お聞きしたいのは、テスト領域は人海戦術で解決するケースも少なくないですよね。でも、僕がナレッジワークのQAに求めるのは、やはりエンジニアとしてテクノロジーを活用してほしいということです。自動化やプロセスの整備など、いろいろな手法が考えられますが、労働集約的になりがちなテスト領域を、科学的なアプローチで進化させてほしいと強く思っています。どう思われますか？
tettan: そうですね、その点については僕も同感です。例えば、QAのスキルアセスメントシートにはテストオートメーションの項目を入れていて、いくつかのスキルは難易度を低めに設定しています。これは、最低限ジュニアのQAエンジニアでもテストスクリプトの実装ができるようにするためです。
僕の考えとして、ナレッジワークで育ったQAエンジニアが市場で正当に評価されない状況は避けたいんです。だからこそ、ソフトウェアエンジニア寄りのスキルに触れる機会を提供することが重要だと思っています。これは業務上の必要性だけでなく、本人にとっても成長を促すためで、後から振り返ったときに「やっておいて良かった」と思える経験になるようにしてあげたい。そのため、QAのスキル評価やキャリアラダーにもエンジニアリングの要素をしっかり取り入れています。僕自身もその思いを持って実装しています。
hidek:ありがとうございます。おっしゃる通り、スピードと品質の両立は短期的にはトレードオフになりがちですが、中長期的には自動化などを活用することで、両立は十分に可能だと思います。そういったことを実現できるエンジニアは市場価値が非常に高いと思いますし、僕もその点には強く同意します。
ーー最後に。ナレッジワークではQAエンジニアとしてどういった人材と一緒に働きたいですか？
tettan: やはり、謙虚でありながら勘違いできる人です。ナレッジワークのメンバーはみんな謙虚で、協力的な人が多いです。そういった文化にフィットし、なおかつ自分の能力を信じて前に進める人が向いていると思います。
また、今はQAエンジニアが8人で、これから10人、20人と増えていく予定です。それに伴ってエンジニアリングの組織も100人を超えるような規模になっていくと思います。そういった、小さいチームから大きな組織へ成長していくフェーズに興味がある人にとっては、非常に面白い環境になるんじゃないかと思います。
hidek:ありがとうございます。沢山の専門的な話を聞くことができて、非常に興味深いインタビューでした！
（取材・編集：三木鉄平 / 撮影場所： WeWork 神谷町 共用部）
【採用情報】 ナレッジワークでは、一緒に働くエンジニアを募集しています
採用ページ（求人一覧・エンジニア向け採用情報）
技術ブログ（Zenn / Note）
技術勉強会・採用イベント（Connpass）