VOICE
さまざまな技術領域をカバーするジークスには、ベテランの「スペシャリスト」たちが在籍しています。今回は、エンジニアやデザイナーなど、それぞれの専門領域で活躍するスペシャリストのなかから、アプリ開発でテックリードや若手育成に関わるメンバーにインタビュー。ジークスに所属する技術のスペシャリストがどのように活躍しているのか、技術一筋のその働き方を語ってもらいました。
アプリ開発の「スペシャリスト」が担う役割とは？
こんにちは、アプリエンジニアの後藤です。2025年2月で入社16年目に入ります。現在私はジークス内で「スペシャリスト」としてアプリ開発に関わっています。今回は、そんな私がどのような役割で、どんなことを考えながら仕事をしているのかをお伝えします。
2010年2月、初代iPadが発売された年にジークスに中途入社しました。もともとはIT業界と無縁の公務員でしたが、Windows 95が流行し、インターネットが普及しはじめたころから、かつて抱いていたコンピューターへの興味が再燃して、独学を経てIT業界に飛び込みました。
ジークスに入社してからは、Webやアプリの開発に従事しています。入社して間もないころ、現在のCEO・渡辺が、当時日本では販売されていなかった初代iPadを海外で購入したんです。「これで何かやりたいんだけど」と相談を受けて、私は基礎研究に近いことを楽しんでやっていました。今思えば、これがテックリードとしての出発点だったかもしれません。
現在はアプリエンジニアのスペシャリストとして、複数のプロジェクトにわたってアプリの品質管理を行いながら、開発現場で難しい領域の問題が起きたときの対処や助言をする役割を担っています。新規プロジェクトが立ち上がる時には、開発のベースを実装することもありますが、最近は直接開発に携わることは少なくなってきています。
常時2～3件のプロジェクトの品質管理に関わりながら、他の開発者の成果物に対してコードレビューを行っています。コードレビューでは、単に仕様を満たしているかだけではなく、”より良い書き方は何か？保守しやすくするためにはどのように書くべきか？”を重視して、それをメンバーに伝えています。どちらかというと、教育的な観点で指摘をしているかもしれません。
テックリードの魅力は、新しい開発技術を発見して伝えること
テックリードとしては、主に最新技術の調査をしています。最初のステップはX（旧Twitter）を使うことが多いです。広く浅く手を広げて、気になるキーワードを見つけたらそれを深掘りしています。私は、Xを普段から技術的な興味を持って見ているので、タイムラインにも自然と有能な技術者の発言が集まります。技術系のブログが流行っていたころに見つけた技術者の方とは、面識はないものの今もXでつながっていて、有益な情報をいただいています。
最近はAIについて調べることが多いですね。日常的に試しているのは GitHub Copilot や ChatGPT です。他にも新しいプロダクトが出てきたときには、都度チェックするようにしています。これらのAIを使ってソースコードの生成もしますが、生成されたコードをそのまま使えることは稀ですから、自分で確認・調整して使います。AIはまだまだ、完璧な答えを出すことには向いていません。私はAIに、曖昧な要求やわかりにくい文章から、コンピューターで扱いやすいデータを生成できる機能が生まれることを期待しています。
社内への情報共有は、Slackのチャンネルを使っています。基本的にはオンラインミーティングよりも、チャットベースの情報共有です。なんでもテキストに残すようにしていて、サンプルを作って、実際に動くコードを相手に見せるようにしています。また、他の人にもどんどん発信してもらいたいと思い、技術情報のほかに、何でもない雑談を流したりもします。Slackのチャンネルを、少しでも発信しやすい環境にしたいと思いながらも、いつも「どうしたらいいんだろう？」と悩んでいるのですが…。結局、お互いの共通認識を少しでも増やすために、対話やチャットなどのやり取り、つまりコミュニケーションが必要だと考えています。
ヒューマンエラーを減らすため、技術力だけではないスキルが問われる
業務にあたっていつも考えているのが、「いかにヒューマンエラーを減らすか」です。ヒューマンエラーの入り込む余地を少しでも減らすことは、アプリ全体の品質向上につながっていきます。
私は強い型付け言語が好きです。型の表現力が高くてミスしにくい工夫が施されているSwiftには、特に好感を持っています。KotlinやDartも良いですね。もし他の言語で型の違いを意識せずにプログラムを書いてしまうと、意図せずバグが作り込まれて、後々保守しにくいものが生まれてしまうからです。そのため、コンパイルの時点でエラーが発生する、これらの言語の方が良いと考えています。
人間は間違うものですし、ヒューマンエラーは完全に防ぐことはできません。それでも、少しでも減らすにはどうすればいいかというと、ヒューマンエラーが起きる状況そのものを減らせばいいんですよね。コンピューターが担当する部分を増やして、人間が担当する部分を減らす。この大きな目標を、自分が関わる領域でいかに実現していくかを日々模索しています。
具体的にヒューマンエラーを減らせた事例は、プロジェクトのベースを作ったときの工夫が奏功したケース。ベース実装を用意する時に、型による制約を使ってルールを仕組み化したことで、開発者ごとの実装のばらつきを抑えられ、品質の向上につながりました。この取り組みはある程度成果が出たと思っていて、PLやPMからも評価をいただいています。ただ、この方式だと開発者にとっては作業の手間がかかってしまうため、タイトなスケジュールのプロジェクトだと実施が難しいというジレンマもあります。1つの方法に縛られず、プロジェクトの事情にあわせて試行錯誤し続けていくことも大切です。
スペシャリストが向いているのはどんな人？
エンジニアからリーダー職、マネージャー職へ進むキャリアパスは一般的ではありますが、自分がマネージャーに適性があるのかピンとこない人もいると思います。現に私もそうです。しかし、技術をとことん追究したい人に適した職も世の中にはあります。
スペシャリストに向いている人は、好きな分野を突き詰めて、考えることを努力だと捉えない人。探求が楽しくて苦と感じない人だと思います。
私のように技術に特化したポジションの人は、その人自身が好きでやってきた結果、気づけばこのような立ち位置にいる人がほとんどなんですよね。好きな領域をもっと突き詰めたいという思いを抱く人がいれば、自然とスペシャリストとして育ってくれるはずです。技術の追究はやればやるほど、ちゃんと前に進んでいる実感が湧くものです。だからこそ、スペシャリストを続けられると考えています。
あとは、後継者が育ってほしいとずっと考えていますが、こういった資質を持つ人をむやみに指導せずにうまく伸ばすことや、その人が次のキャリアとして目標にできるポジションをしっかり整備しておくことが大事だと感じています。
私はこれまで、プログラミング言語やAIなどの技術調査をして、使える形に整えて開発者に役立ててもらうことを地道に続けてきました。開発するうえで大切なことを伝えて、少しでも開発が前に進んでいることが、自分自身のやりがいとモチベーションになっています。同じように技術が大好きな人と一緒に仕事ができたら嬉しい、そんな仲間ができることも1つの夢です。