未経験エンジニアの私がインターンからNewsPicksへの入社を決めた理由

はじめに

NewsPicksの法人向けサービス開発チームの前表です。今回は、プログラミング未経験者だった私が、NewsPicksにエンジニアとして入社して半年間でやったことやキャッチアップするために工夫したことを振り返りつつ、未経験者ならではの視点からNewsPicks / Uzabaseの開発組織の魅力について紹介してみようと思います。

未経験からエンジニアを目指そうとしている方にも、現役エンジニアの方にも是非読んでいってもらえたらと思います。

それではどうぞ!

キャリアチェンジのきっかけは、「仕事に夢中になりたい」

NewsPicksは私にとって3社目で、これまではメーカーの管理会計部門、戦略コンサルティングファームと渡り歩いてきました。プログラミングとは縁のない、経営戦略畑の人間です。そこからどうして突然エンジニアが出てくるんだって思いますよね?

個人的な話になってしまうのですが、本題にも繋がってくるので少しだけ紹介させてください。

私がエンジニアを目指そうと思ったのは、「仕事に夢中になりたい」という思いからです。

これまでの仕事は、「成長できそうだ」という思いで選んできましたが、その結果全てを修行と捉えて日々業務をこなしている感覚でした。(特に20代のうちは)それが当たり前だと思っていたんです。

でも世の中には仕事それ自体を楽しみ、夢中で仕事に向かっている人がいるんですよね。修行期間と考えていた20代の終わりが見えてきた頃、私もそんな人達の存在に気づいたんです。自分も「夢中になれるかどうか」を仕事選びの基準にしてみてもいいんじゃないか、人生は1度きりだぞ。

そこから色々と検討し、辿り着いたのがエンジニアでした。今までで楽しかった仕事は何だっただろうかと改めて振り返ったところ、excelでモデルを組むのが一番楽しかったんです。考えてみれば、子供の頃から何かを作ってそれが思った通りに動く感覚が大好きでした。プログラミングも同じ感覚でできるんじゃないかと、仮説を立てました。

そこからは仮説検証作業。知人の知人まで当たってなるべく多くの現役エンジニアの話を聞いて回り、職業に対する解像度を上げつつ、プログラミングスクールで実際に手も動かしてみて「エンジニアなら夢中になれそう」という自信を持ちました。

私がエンジニアへのキャリアチェンジを決めたのはこんな経緯からです。そしてキャリアに対するこの考え方は、結果的にNewsPicks / Uzabaseにぴったりとはまりました。詳しくは後述しますね。

未経験でも出せる価値はたくさんあった

3ヶ月ほどの準備期間を経て、私は運良くNewsPicksでインターンできることになりました。配属先は、現在の所属チーム、NewsPicksの法人向けプロダクト開発チーム (Enterprise Product Unit) です。このチームでは、NewsPicksの中でも比較的新しいサービスである、NewsPicks Enterpriseを開発しています。ここからは、入社後から現在までの半年弱を振り返っていきます。

NewsPicks Enterpriseとは

NewsPicks Enterpriseは、法人向けにカスタマイズされたNewsPicksです。 通常のNewsPicksアプリに追加される社員限定のクローズドな空間において、下記のような機能を提供しています。
  • NewsPicksや外部サイトの記事を共有
  • オリジナルコンテンツ(社内報)を投稿
  • 記事に対してコメントを投稿
  • 利用状況をデータで可視化し、各種施策に活用
部門や役職にとらわれない自由な議論が生まれ、互いに刺激を与え合い、イノベーションのきっかけが創出される。NewsPicks Enterpriseは、そんな場を提供しています。
NewsPicks Enterpriseの提供価値


結果より理解を優先できた最初の2ヶ月

最初の2ヶ月間は、スタイル修正やバグ取りをメインで担当していました。私にとっては全てが未知の言語やフレームワークでしたし、コードの土地勘もないため、膨大なコードの中から修正すべき箇所を見つけるだけで1日かかることもざらでした。そんな状況だったので焦る気持ちもありましたが、「今は結果を出すことより理解することを優先すればいいよ」と当時のリーダーに言われ、ちょっと開き直れたのを覚えています。勤務は週4日に留めて技術の一般的な勉強にもしっかり時間を確保できたこともあり、2ヶ月目には毎日のように改良箇所をリリースできるようになっていました。

徐々に機能追加に取り組み、価値提供の喜びを経験

3ヶ月目頃から、サービスの管理画面から更新できるメニューを追加する等の、小規模な機能改善に取り組み始めます。調査から設計・実装(サーバー / フロント双方)・テスト・リリースまで、必要に応じてチームメンバーのサポートも得ながら進めていきました。この頃の改善は技術的な難易度こそ高くはありませんでしたが、ユーザーの方々にとても喜んでもらえました。ユーザーが求めているものを開発すれば、技術レベルに関わらず価値を提供できる。これを体感できてモチベーションが一層向上しました。

現在はより大きな機能追加を担当し、他チームとも連携

現在は、サーバー / フロントだけでなく、DBやインフラも絡んでくる、より大きな機能追加に取り組んでいます。主担当として技術仕様を設計し、UIデザイナーやスマホアプリの開発者など、チーム外のメンバーも一緒になって機能を作り込んでいます。

振り返ってみると、とても濃い経験ができた半年だったと思います。繰り返しになりますが、技術レベルが高くなくても出せる価値はたくさんあるんです。未経験だからといって卑屈になる必要は全くありません。

キャッチアップの秘訣は、「構造化」と「仮説思考」

この半年間、なんとか早くキャッチアップしようと工夫した点は色々とあるのですが、振り返ってみると「構造化」と「仮説思考」が大事だったかなと思います。この2つを実践することで、既存コードを読み解く時間を大幅に省略できました。特にコードを読み解くのに時間がかかるビギナーにとってはとても重要な要素なんじゃないかなと思います。以下、経験者の方には当たり前のことだと思いますが、大規模なコードに触れる機会の少ない方の参考になればと思い、これらについて説明します。

問題を構造的に分解し、深堀りすべき箇所を絞り込む

例を使って説明します。ユーザーの行動ログを表示する機能Aと機能B、同じユーザー行動を参照しているはずなのに双方の出力結果にズレが生じており、この原因を調査しているとします。

まずは「構造化」について。問題を大きなブロックに切り分けた上で、飛び込むべきブロックを特定します。今回の例だと、まずは「行動ログの入力→DB(データベース)の状態→行動ログの出力」とプロセスをざっくり抽象化・構造化した上で、これらのどのプロセスで差異が発生しているのかを特定するための調査をします。もしAとBで同じDBを参照しているようなら、出力過程の違いだけ調べれば良いはずですよね。そしたら次に出力過程をさらに「DBへの問い合わせ→DBからの返却→集計」と抽象化・構造化し、どこで差異が発生しているのかを特定...といった具合です。このように、具体的なコードの構成を見に行く前にプロセスを抽象化し、構造的に捉えておくことで、デバッグも効率的になるはずです。

コードを読む際は、必ず仮説を携えて

仮説思考では、仮説を立て、検証するというサイクルを繰り返します。例えば今回の例では、差異の出方によって原因仮説が立てられるかもしれません。毎回AがBより大きい結果を出力するのであれば、filter処理の有無に相違が出ているのかもしれない。AとBどちらが大きいパターンも存在するのであれば、どちらかで処理速度を優先した概算処理が入っているのかもしれない。このように立てた仮説をコードを読んで検証し、違っていればまた別の仮説を検証する、というサイクルを繰り返します。最初は仮説の精度は高くないと思いますが、何も意識せず当てずっぽうで調査したり、膨大なコードを網羅的に調べようとするよりは効率的なはず。

このように、問題を構造化して切り分け、常に仮説を持った上でコードを読む、ということができれば、コードを読む時間を大幅に削減できますし、手詰まりになってチームのメンバーに助けを求める際もクリアな質問ができます。どこまで分かってどこから分からないのか、これまでに潰した仮説は何か、仮説を検証する方法についての質問なのか、もしくは仮説を立てるための質問なのか、といったことが明確であれば、質問された側も答えやすいんじゃないでしょうか。

正社員転換をリクエストした理由

4ヶ月のインターン期間を経て、最近正社員に転換しました。最初からNewsPicksへの入社だけを考えてインターンしていたわけではなく、他の企業への就職も比較検討した上で正社員転換をお願いしました。ここでは、正社員転換をリクエストした理由、つまり私から見たNewsPicks / Uzabaseの魅力を紹介します。

サービスの提供価値への共感

1つ目は、サービスの提供価値に対する共感です。私達のチームで開発しているNewsPicks Enterpriseは、ユーザーに「学び」に加えて「繋がり」を提供します。普段は関わることのない部署に所属するユーザー同士でも、NewsPicks EnterpriseでのPickやコメントを通して繋がることができます。

NewsPicks Enterporiseを一つのきっかけとして組織のサイロ化を打ち破ることで、それぞれの知見を活かして活躍できる機会が増えるはず。そしてみんながいきいきと働くことができれば、企業としてのアウトプットも変わってくるでしょう。この伸びしろを活かす取り組みに、NewsPicks Enterpriseの開発を通して自分も参加したいと思いました。

幅広く、かつモダンな経験が積める

2つ目は技術的な観点です。NewsPicksの開発組織は、基本的にはサービス軸で別れており、機能軸ではありません。なので、例えば私の所属するチームでは、法人向けサービスに関することならサーバーもフロントもインフラもDBも、幅広く扱います。駆け出しでまだ経験が少なく、それぞれの分野がどんな性格のものかもよく理解できていない私にとって、幅広い経験が積めるのはとても魅力的でした。

また、モダンな経験が積めるというのも大きな魅力です。あまりレガシーな技術ばかりでは開発していてワクワクしないですよね。NewsPicksの開発組織では、「開発者体験」を大切にしており、(もちろん機能性向上も目的に)モダンな技術が積極的に取り入れられています。例えば、これまでサーバーで使われている言語はJavaが中心でしたが、先日Kotlin化が決まり、現在進行系でKotlinで書かれたコードがどんどん増えていっています。「開発していてワクワクしたい」という思いからボトムアップで技術基盤の更新の話が出てくるし、その思いを尊重する雰囲気が組織として定着しているからどんどん公式にプロジェクト化されて動いていく、そんな環境です。 tech.uzabase.com tech.uzabase.com

夢中になれる

そして私にとって一番の魅力が、日々の仕事に夢中になれることです。仕事に夢中になりたいという思いでキャリアチェンジした、というのは前述しましたが、これがまさに実現できているんです。

NewsPicksにおける「夢中」を実現している要素は、プログラミングが好き、ということだけではありません。全ての開発者が楽しく仕事できるような仕組みがいくつも存在するんです。最後にこの要素を紹介して終わりたいと思います。

「仕事に夢中」を実現する要素

NewsPicksの開発者が仕事に夢中になれる理由を、3つ紹介します。どれも社内では当たり前のことなのですが、私の視点からはとても新鮮で特徴的な要素でした。

「最高の開発者体験」を実現する開発環境の整備

NewsPicksでは、開発者が開発に集中できる環境が整備されています。社内に「最高の開発者体験」という言葉がありますが、まさにこれが体現されているんです。開発環境構築やデプロイ作業、運用作業など、開発の本質ではないプロセスは仕組み化され、ここにかかるコストは最小限になっています。もちろん仕組み化できていない部分も一部では存在しますが、「最高の開発者体験」の構築に組織として旗を掲げて取り組んでいますので、「非開発業務を減らすための開発」にもオフィシャルに時間が確保され、日々改善が進んでいます。

tech.uzabase.com
本人の「やりたい」を尊重したタスク設計

私にとって一番魅力に感じたのが、本人の「やりたい」を尊重したタスク設計です。NewsPicksの開発は、チームごとの「スプリント」形式で進みます。各スプリントで各人が受け持つタスクは、NewsPicksとしてリリースしたい機能からトップダウン的に決まるものだけでは埋まりません。開発効率を上げるためにやっておきたいことや、開発からみてあったほうがいいと考えられる機能の開発等、ボトムアップでやりたいタスクも織り込めるんです。やらされ仕事ではなく、本人がやりたい、やったほうがいいと思う仕事だから、みんな前のめりに仕事に取り組めるし、結果としてアウトプットの質も上がっていく。

なんでみんながやりたいことをやって組織が回るのか、不思議に思いませんか?私も最初不思議でしたが、段々分かってきました。この仕組みを支えているのは、一人ひとりの高いプロ意識なんです。やりたいことと言っても、それは本人の興味関心だけから出てきたものではない。開発組織やサービスの将来を考えた上でしっかり練られたものなんです。こんな人が集まっている環境って、あんまり無いんじゃないでしょうか。

スプリントとは

アジャイル開発の手法で、「イテレーション」とも概ね同義です。1-2週間程度の期間を一つの単位として、各期間中に下記サイクルを回し、一定の成果を出します。
  1. スプリント計画:そのスプリントで各人が受け持つタスクを設定
  2. デイリースタンドアップ:日々発生する重要事項・相談事項を手短に共有
  3. 完了報告・共有会:スプリント期間中にで実装したタスクを共有し、相互にフィードバックを提供
  4. 振り返り:各スプリントでよかったことや、もっとうまくやるためにどうすればいいかを議論
スプリント計画で設定したタスクを終わらせることを重視しすぎてはいけません。タスクが終わらなかった場合、終わらなかった原因を振り返り、必要に応じて次のスプリントのタスク量を調整します。これを繰り返すことによって、チームとして消化可能なタスク量が精度高く見積もれるようになる、という仕組みです。

ウォーターフォール式の仕事の進め方しか知らなかった私にとって、スプリントを含むアジャイル開発の本質を理解するのには少し時間がかかりました。同じような境遇の方は、『アジャイルサムライ』のような解説本を読んでおくことをおすすめします。


企業文化としての相互リスペクト

最も特徴的で、入社して一番驚いたのがこれです。メンバー同士が本当にお互いをリスペクトしてるんです。お互い素直に褒め合い、感謝し合う。ミスしても人を責めず仕組みを疑う。これがあるとみんなチャレンジしたくなるし、組織に還元したいと思えるんですよね。めちゃめちゃ褒められてめちゃめちゃ感謝されれば、またみんなのために頑張ろうって自然と思えますし、そんな思いで頑張っている時間はとてもワクワクします。

しかもこれは開発組織の中だけの話じゃないんです。ビジネスサイドのメンバーとも相互リスペクトの関係が構築されています。ビジネスサイドは開発効率を下げないようになるべく同じ問い合わせを減らすように工夫してくれているし、エンジニアもビジネスサイドの困りごと・依頼に対して我先にと反応する。相互リスペクトは全社で徹底されており、これは企業文化と言っていいと思います。Uzabaseのバリューの一つに「異能は才能」という言葉がありますが、これが本当に体現されています。

最後に

どうでしたか?NewsPicks / Uzabaseの魅力が伝わったでしょうか?少しでも魅力に感じた点がありましたら、是非ご連絡を!

tech.uzabase.com

© Uzabase, Inc. All rights reserved.