「エンジニア」といっても、企業によってその業務範囲や働き方は様々です。今回は、ナイルのエンジニアがどのように働いているのかを、マネージャーの3人に聞いてみました。

プロフィール

エンジニア発案で企画が進む

―― ナイルのエンジニアはどのような働き方をしていますか？

三瓶： 職能で業務範囲を分けている企業では、マーケターやディレクターから企画をもらって、エンジニアがプログラミングをするというケースが多いですよね。僕も前職では開発だけが担当でしたが、「この企画、もっとこうした方がグロースできそうなのにな」というモヤモヤを感じることもありました。
ですがナイルのスマートフォンメディア事業部では「全員企画、全員自走」という方針があるので、エンジニアだから開発だけをやる、ということはないです。

塚本： ナイルで求められるのはいわゆる「T型人材」ですよね。技術を目的にするのではなく、「このゴールを達成するためにどの技術を使えるか」を考えられる人が活躍していると思います。

―― 実際にエンジニア発案で企画が進んだケースはあるのでしょうか？

小宮： 僕が所属するコーポレートエンジニア部門（CE） では、気づいたことはすぐにお互い共有して、「じゃあやるわ」という感じでパッと進めちゃいますね。「企画を発案」というほど大きなことではないかもしれないですが、エンジニア自身が考えて実装するというのが日常茶飯事。当たり前になっています。

三瓶： たしかに、僕はチームは違いますがCEのSlackチャンネルを見ていても「ここ問題あるよね」「OK、すぐやっちゃう」という感じでスピード感がありますよね。

小宮： そうですね。僕のチームメンバーは3人とも技術の得意分野が違いますし様々な経験をしてきています。それぞれの担当分野においては作業の妥当性やタイミングも適切に判断できるので、完了までお任せしています。僕もマネージャーとしてゴーサインを出すのは速いと思いますが、「リリースの時だけは慎重にお願いね」と話しています。インフラはミスがあるとシステムを全滅させちゃう、なんてこともありますからね…（苦笑）。

―― スマートフォンメディア事業部の方でも何か実例はありますか？

三瓶： Applivのシステムリニューアルを自分が提案して進めています。実はApplivに参画した当初思ったのは、規模の割にエンジニアが多いなということでした。その原因のひとつが、リリースから6年分、地層のように蓄積された何万行ものソースコードだったのです。6年もサービスを運営していると、機能のアップデートを繰り返す度に使われなくなったソースコードや、新機能開発のタイミングで中途半端に移行されてきた実装などがあったりしていました。
何かを直そうとしたときに、その地層のようなソースコードを毎回すべてチェックしなければいけないから時間がかかるのです。生産性が悪いこの状況をなんとかしたかったんですよね。これが改善できればコストは下げられますし、エンジニアの余剰工数を別のところに割くこともできます。ついでに最近のモダンな技術を使って楽しく作ろうよ！という感じで始めました。

塚本： 最初に提案するときに、リファクタリングの効果を非エンジニアのメンバーに客観的に示すのは結構大変そうでしたよね。

三瓶： そうでしたね。リファクタリングってサイトの見た目は何も変わらない上に、瞬間的にエンジニアのリソースが必要になるので、理解を得るのが難しいケースが多いです…。Applivや事業部にとってのメリットを定量的に示したから納得してもらえたのだと思います。

小宮： そしてリファクタリングが終わると、今度はインフラの出番がやってきますね。サーバーの数が減るので毎月かなりのコスト削減になります。下がったコストで焼き肉とか行きたいですよね（笑）。

塚本： 月単位で数十万の費用が減るかもしれないですもんね。

小宮： 「プロジェクトカルビ」とかにプロジェクト名を変えてもいいかもですね（笑）。

三瓶： それ、いいですね（笑）！…話はそれましたが、売上を伸ばすことももちろん大事ですがコストを下げることでも業績に貢献できると思っています。僕のアプローチは後者なんですよね。

非エンジニアのメンバーと働くということ

―― 幅広く経験をしたい人にとってはチャレンジングで恵まれた環境のように思えますが、エンジニア視点で今感じている課題感を教えてください。

小宮： CEでは技術や成果、がんばりの可視化が難しいと感じています。部門外のメンバーも「技術系はよく分からないけどとにかくいつもありがとう！」という感じなので（笑）。とはいえ、感謝の言葉をいただけるのは有難いです。

三瓶： エンジニアの評価制度は難しいですよね。そもそも経営陣や事業部長がエンジニアではないので、技術力は理解してもらいにくいだろうなと思っています。ただ、僕たちが重視しているのは「技術を使ってどのようなビジネス価値、インパクトを創出するか」という点なので、技術に対してではなくビジネス成果をメインに評価されるのは基準が明確でお互い健全だと考えています。

塚本： 一方で、ナイルには代名詞になるような技術の強みが無いのが現状です。これまでこの会社がデジタルマーケティングを強みにビジネスを展開してきたのと同様に、なにか新しいサービスを作る際に「うちの強みであるこういう技術が使えそうだよね」という形で技術が戦術の1つになれば、今以上の事業拡大に繋がるのではないでしょうか。経営陣も含めてそのように考えられるようになったら、技術×ビジネスのいいシナジーが生まれそうですよね。

「チャレンジしたい人、ウェルカム！」ナイルのエンジニアとしてのキャリアパス

―― ナイルでエンジニアとして入社すると、どんなキャリアパスが考えられますか？

塚本： スマートフォンメディア事業部であれば、エンジニアで入ったとしても事業責任者などの道もありえますね。最近は職種に関係なく新規事業のテーマと責任者候補を募集していますし、本人の意向で職種チェンジをした事例もあったりします。Applivのオペレーターからデザイナーへの転向だったり、エンジニアが技術的な挑戦をするために別のプロダクトに異動したり、などです。

小宮： インフラは保守的な業務イメージを持たれることも多いですが、ナイルでは受け身にならずアクティブな姿勢を意識しています。トライアンドエラーができるような環境を用意しているので、SREなど、新しい手法のインフラ設計への取り組みも推奨しています。

三瓶： たしかに、「やりたい！」と手を挙げたものはやらせてもらえる環境ですよね。業務改善のためのツールの稟議も通りやすい印象です。その分成果は求められますし手厚いサポートも期待できないのが正直なところですが事業部のコンピテンシーの１つに
「挑戦を奨励し実験的失敗を容認することで仕事環境を改善しプロジェクトと個人の発展的成長を促す」という一文があります。なので、色々挑戦したい人にとっては恵まれた環境です。チャレンジしたい人、ウェルカム！という感じですね。

―― 成果に対してはシビアな面もありそうですが、メンバーのアイデアは比較的受け入れられる土壌があるようですね。最後に「この職種では珍しく、ナイルには頑固なエンジニアはいない（笑）」と口を揃えて言う3人が、今後も一緒に働きたい人の要素として挙げたのが「ポジティブさ」「性善説に基づいた思考」「バランス感覚」でした。

塚本： 一緒に働きたいのは「前向きに考えられる人」。これに尽きますね。スキルはあるに越したことはないですが、たとえ足りなくても、課題を見つけたら何らかの手段を使って自ら解決策を見いだせる人と仕事をするのは楽しいですよね。

三瓶： 僕は、昔は性悪説をベースに仕事をしていて、何事もあらゆるリスクを想定していました。でも細かいところまで対応しているとどうしてもスピードが犠牲になるんです。ナイルのようなベンチャー企業は限られた人員の中でスピート感をもって業務推進をする必要があるので、それだと成果が出しづらいのです。何よりユーザーへの価値提供スピードが落ちてしまいますしね。なので細かいところは割り切ってPDCAをまわしながら継続的に改善していこうという思考が大切だと思います。
ただし、重大事故やインシデントになり得そうなことは事前に察知して排除なり対応策を立てることも当然必要です。要は、性善説思考をベースとしつつも必要に応じて性悪説思考も使い分けられるような方と今後も働いていきたいですね。

小宮： インフラは限られた予算の中で最大限の成果を出すことが求められます。ときには妥協を強いられることもありますが、その中でも最善より最適を選択できるバランス感覚が必要です。それからナイルは新しいツールやフレームワークをどんどん取り入れるので、キャッチアップ力も大事ですよね。僕もScalaや各社のクラウドサービスなど、仕事で必要になりそうな勉強を休日の時間があるときにやっていますよ…！

―― 色々とお話いただき、ありがとうございました！エンジニアとして求められるレベルの高さが垣間見れました…。が、前向きな挑戦と失敗が奨励される環境で、エンジニアとしてはもちろん、ビジネスパーソンとしても貴重な経験ができそうですね。

ナイルでは事業を一緒に作ってくれるエンジニアを募集しています！

・エンジニアの求人はこちら

・ナイルつくばオフィスの採用ポジション一覧はこちら