CRUD実装、artisanコマンド、TDD…。実践で使えるLaravelのエッセンスがぎゅっと詰まった濃密セッションを、アーカイブで公開中。

このライブコーディングのポイントは5つ！

• ローカル環境で“すぐ試せる”開発を。
• Artisanコマンドで開発を加速。
• TDDで“動く状態”を保ちながら実装。
• モデル設計とリレーションが要。
• 認可とセキュリティを意識したAPI設計。

▼詳しくはアーカイブ動画でチェック！

▼ライブコーディングの解説ブログもチェック！

武田さんへに向けた感想や質問

当日の質疑や感想だけではなく、アンケートに寄せられた質問へもご回答いただきました。

感想：Laravelって英文がわかりやすい！って気づきがありました。

“Laravelが好きなところは「英文がそのままですごいわかりやすいところ」とおっしゃっていましたが、今まで気づかずにいて、確かにって気がついてすごくいいなと思いました”

武田さんから

ありがとうございます！せっかく感想いただいたので、それに関してちょっとコメントさせていただきます。ユーザー、つまり開発者側の使い勝手としてそういう風にしているっていうのもあるんですけど、Laravelの内部の設計とかでも、徹底まではいかなくともかなり気遣いがあったりする部分なんです。

Laravel FrameworkのPullRequestとかをずっと見ているとですね...様々な議論を経て、ようやくこの完成した新機能のPullRequestにメンテナの人たちがみんなApproveしていたとします。残すはTaylor Otwellさんがマージボタンを押すだけの状態だとしても、「なんか名前がいけてない気がする〜」ってTaylorさんが名前だけ変更してマージするみたいなことが結構あります。...結構は嘘だな。たまにあったりします。

見てるとわかるんですけど、技術的な正しさみたいなところよりかは、気持ちいいかどうかみたいな感覚的なものをすごく重視してるフレームワークなんだなって感じたりしております。

質問：ライブコーディングではCopilotを使用されていましたが、普段は他にどんなAIツールを使っていますか？

武田さんからの回答

私も含め皆さん試行錯誤中してる分野ですね！今のところCloud Code 、GitHub Copilot Agentを使い分けつつ、やはり使い込んでいるのは、Copilotのコード補完です。

使いこなせば他も便利なのは知ってるのですが、ある程度綺麗なコードベースだと必要性をまだあまり感じないんです。今回お見せした書き方はあくまで一例ですが、フレームワークを使った開発は、ある程度「型」が決まってることが多い。そして「型」に従ったコードはGitHubにAIの学習データがいくらでも公開されているので補完の精度がかなり高いんです。今回1時間で間に合ったのは「型」とタブキーのおかげです！

ただ、いざ仕事になるとそうはいかないことも多いですね。特に古いコードは補完の精度も落ちるので今回のようなリズム感で書くのは絶対に無理。そういう時に、Cloud Codeに読ませたりCopilot Agentにプルリク作らせたりしています。

ところで、AIエージェントを使う時は個人的なこだわりがあります。例えばAIにプルリク作らせた場合、それを自分の手で「写経」したりします。一見LGTMなプルリクでも、自分が素で書く時と微妙に書き方が違ったりして、写経するとそれが見えてくる。ここに発見があったりして面白いです。まあ、この写経も結局はタブキー多用するんですけどね(笑)

（おまけ）終了後におちゃめな武田さんのXのポスト

ライブコーディング、コードとは直接関係ないが割と「見せ場」と考えてた箇所を実演し忘れた！！！

* ここで一旦コミット、理由は後程 ←ここまで自動生成
* ｶﾀｶﾀｶﾀｶﾀ.... ←ここは自分で書いてる
* 終わったのでdiffを確認！変更、少なっ！ ←忘れた

しまったwwwwww

— 武田 憲太郎 (@KentarouTakeda) October 30, 2025

ポストを見た上で、これがどこに入る予定だったのかを楽しみにアーカイブを視聴する楽しみ方もできるかもしれませんね（笑）

ぜひ、このアーカイブで、Laravelシャワーをぜひ浴びてみてください！

TechTrainメディアでは、これからも様々なメンターさんやプロダクトのインタビューなどプロダクトの「価値につながる」情報をお届けしていきます！！

https://no-hack-no.life/post/2020-05-09-my-first-programing/

読み終えた頃には、きっと「武田さんと話してみたい」と感じるはず。その人柄と経験に裏打ちされた考えを、TechTrainメディアでお届けします！

ものづくりに本気で向き合ってきた時間

プログラミングとの出会いは小学2年生。誰しもが知る某有名RPGの1作目が発売された年でした。休み時間の教室ではみんながこぞって「俺の最強のRPG」を自由帳に描くのがブーム。しかし、父がプログラマーだった私は「動いてこそゲーム！」と、ゲームの写経を始めました。

その後は、数学にのめり込みMathematicaにハマったり、音楽活動のためにMIDIの自作ツールを作ったり、ものづくりが身近にありました。そこには常に”明確な目的”が存在していました。「美しいグラフを描きたい」「より効率的に曲作りをしたい」。他にもたくさんの経験を重ねましたが、どれも納得がいくまでやり切ってきました。この本気で向き合った経験ひとつひとつが、今の自分に繋がっています。

“作品”をつくるという姿勢から生まれるプロの品質の納品物

そんな風に自分が本気で向き合ったアウトプットを“作品”と呼んでます。ミュージシャンを志していたこともあり、時間をかけてでも自分が納得いく“最高の形”に仕上げることが当たり前だという感覚もこのスタンスに影響していると思います。ただ、仕事となるとそこまでこだわり切ることは、なかなかできません。仕事で守るべきは、個人のこだわりではなくプロジェクトの成功、それに応えるのがプロの役割です。実は、私の何十年のエンジニア人生の中で、満足のいく”納品”はできても“作品”まで作りきれたことは、一度もありません。ただ、“作品”を目指した結果、たとえ自分の求める最高の形まで行けなくとも、良いものを作り技術を磨くことができてきたのも事実です。

伝わってこそ価値になる

プロダクトに限らず、登壇資料や技術記事も“作品”です。そして、“作品”をつくる時に一番大事にしているのは「相手に伝わってなんぼ」という視点です。

テーマに合わせた起承転結や、その題材を読む人に合わせた文体など、伝えたい相手に対して伝わる表現を意識しています。この視点は、プロダクトづくりでも変わりません。たとえば、スマホに慣れていないおばあちゃんおじいちゃん向けのアプリと、常にスマホ3台持ってるヘビーユーザー向けのアプリ。この2つを想像したら、UI/UXは同じになるはずがありませんよね？

私は常にこんな風に「どうすれば相手に伝わるか？」を頭のどこかで考えています。なにかアウトプットをする前に「相手に伝わるかな？」と一度立ち止まってみてください。その意識が、“作品”の仕上がりに近づく第一歩になるはずです。

一流は難しいことをシンプルにする

数学の世界では、幅広いことに適応できる普遍的な法則ほど、定理や公理はシンプルです。学生時代、数学のことばかり考えている時間を過ごすほど数学好きの私にとって、シンプルであればあるほど応用が効くという考え方は自然なもの。だからこそ、説明するときや実装するときも“いかにシンプルにするか”を意識するようになりました。

難しいことを難しいままやることは簡単です。その物事を理解して、シンプルで普遍的な法則にできるだけ近い状態に仕上げること。それが一流の仕事だと思っています。

実際に、1億PVをPHP , Laravelだけで捌いたときも、考え方の出発点は「言語不問の王道をきっちりやる」ことでした。詳しいポイントはXにもまとめていますが、ここで大事なのは“まずシンプルに考える”という姿勢です。

1億PVをPHP, Laravelだけで捌いてるPHPerが通りますw https://t.co/Gs3LkOQ1r3

— 武田 憲太郎 (@KentarouTakeda) August 24, 2025

具体と抽象を行き来すること

ものごとを“シンプルにする”には、「具体と抽象を行き来する」ことが必要です。まずは、そのものごとに対してしっかり理解することから始めてみてください。

例えば、チケット販売サービスを開発しているとき。チケット販売の仕様が抽象だとしたら、ブースに並ぶ人々のリアルは具体です。そこには必ずヒントがあります。

1. サービスの仕様が理解できず躓く（抽象）
2. 普段は足を運ばないが、美術館に行って、チケットブースの観察をする（具体）
3. 「これか！」と仕様の理解が進む（抽象）

具体的な動きを知ることで、抽象的な仕様の理解が深まるのです。

コードを勉強するときも同じです。

1. コードの動作を理解する（具体）
2. そこから汎用的な解法を学ぶ（抽象）
3. さらに応用して新しいコードを書く（具体）

──このサイクルを繰り返すことで、ものごとをシンプルに考えられるようになっていきます。

時には、そこで煮詰まってしまうこともあるかもしれませんが、そんな時は回り道も大歓迎。その悩んだ時間も含めて、あなたにとって最高の形を実現するための大事な時間になります。

▼参考資料：そーだい(X:@soudai1025)さんのPHPカンファレンス名古屋登壇資料「抽象化をするということ - 具体と抽象の往復を身につける」

Hello world！ で味わった感動が未来の力に

ここまで読んで、少し難しい話に感じた方もいるかもしれません。でも、コードを書くときも、登壇資料を作るときも、大事なのは「よりシンプルに考え、相手に伝えること」です。

その上で、私が強く伝えたいのは、どんな立場の人であっても「Hello world！」を表示させたときのあの感動を忘れないでほしいということ。小学2年生の頃、ゲームの写経でエラーに出会うたびに「いつか開発チームに加われるかも！」と胸を躍らせていました。その喜びは、学びの段階の最大の醍醐味です。そして、今の自分をつくった原点にもなっています。

そして、本気で最高の“作品”を目指してみてください。その積み重ねが、未来の自分の力へと必ずつながります。

いかがでしたか？どんなにすごいエンジニアも、はじめの一歩は「Hello world！」です。学びの途中で挫けそうな人も、仕事で行き詰まっている人も、武田憲太郎さんとの面談を通して、シンプルに考えて伝える力を、一緒に磨いてみませんか？

TechTrainでは今回インタビューに答えてくださった武田憲太郎さんをはじめ、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」から、ぜひ気軽にメンタリングを予約してみてください！

普段、フリーランスとして働く中で自作した「Flutterのアニメーション」のパッケージを引っ提げ登壇するちゅーやんさん。セッションで描画の仕組みとあわせて「楽しい体験」を届けたいという想いを、出発前にお届けします！

本記事では、インタビュー内容を4つの切り口でお伝えしていきます。

• 海外カンファレンスに挑戦した理由
• 今回のセッション内容とオリジナリティ
• 技術的な見どころ
• 海外登壇に込める思い

海外カンファレンスに挑むきっかけと1年半の闘い

もともと、FlutterKaigiなど日本で行われているカンファレンスで何度か登壇していました。発表を繰り返していくと次第に「海外のカンファレンスでも発表できたらいいな」と思うようになりました。そんな中で、海外の案件にも関わってみたいという気持ちもあり、海外でも今まで国内でやってきたように発信をして「こういう活動をしている人なんだ」と知ってもらえる機会を増やしてみようと思ったことが、世界規模のカンファレンスへの登壇を目指すきっかけでした。

そんな風に海外登壇をしてみたいと思い立ってから、1年半ほどずっと海外の色々なカンファレンスにプロポーザルを出し続けました。結果は、全落ち。そして、1年半越しに念願叶って、Fluttercon EUに採択され、ようやく初の海外登壇が実現しました。しかも、このFluttercon EUは特に参加してみたかったイベントだったので、登壇がとても楽しみです。

セッションのテーマはオリジナリティが重要

発表するのは Flutterのアニメーション についてです。自分が作ったアニメーション用のパッケージ「animated_to」の紹介と、それに絡めたFlutterの描画の仕組みを解説する予定です。

このテーマを選んだ理由は、自分にしかできないオリジナリティのある話ができるからです。海外のカンファレンスでは、GoogleのFlutter自体の開発者や有名なパッケージ開発者といった“中の人”が直接登壇します。そういう場で、国内で自分が話しているようなFlutter フレームワークやパッケージの仕組みの話をしても「それは本人が話すよね」となってしまいます。なので、自分にしか話せないテーマを選ぶことにしたんです。自作パッケージを題材にすることでオリジナリティを出しつつ、そこからFlutterの理解を深めてもらえる。そんなセッションを目指しています。

今回のセッションで伝えたい「Flutterでの楽しい体験」

Flutterのアニメーションは、動画やデモを見せるととても盛り上がるんです。Xに投稿しても反応が段違いで。だからこそセッションでも「難しい理屈より楽しい体験」を大事にしたい。「Flutterでこんなに滑らかなアニメーションが作れるんだ！」と驚いてもらえたら嬉しいですね。

そして、それをぜひ「animated_to」で体感してみてね、と思っています。ありがたいことに「animated_to」は、DartPadに採用されているので、発表では「このURLを開けばすぐ試せます」と、その場で動かせる体験を届けられると思います。

そしてセッションの後半は、より深いFlutterのアニメーションの仕組みの話をするので、それも活用して今後の開発にもつながるワクワクを感じてもらえたらいいなと思っています。

海外登壇にチャレンジして、視野を広げてみてほしい

海外に出ることで得られる刺激はとても大きいと思っています。現地ではセッション以外にも交流の場があるので、開発者同士で直接話すのが今から楽しみです。

そしてもうひとつ、今回の挑戦を通じて、個人的に感じたのは「日本語だけで発信を閉じてしまうのはもったいない」ということです。日本にはQiitaやZennのような、日本語だけで知識をシェアできる環境があります。それは大きな強みだけど、海外に挑戦するきっかけを持ちにくい面もあると思います。

実際にプロポーザルを出すだけでも学びがありますし、通ればさらに新しい経験が広がります。だからぜひ、日本のFlutterエンジニアにもチャレンジしてもらって、「日本でもFlutterがこんなに盛り上がってるよ！」ということを世界へ発信していきたいと思っています。GoogleがDashくん人形を日本の Flutter イベントにもっとたくさん送ってきてくれるように（笑）一緒にFlutter界隈を盛り上げましょう！

Dashくんとは？

もちろん、国内で海外向けの発信ができるイベントもありますので、そちらから挑戦してみるのも良いかもしれません。

FlutterNinjas2025のちゅーやんさん登壇アーカイブ

動画の発表で利用した登壇資料

画像をクリックすると資料へ遷移します

念願の海外カンファレンス登壇に挑むチャンスを掴んだChujoさんの言葉からは、
「自分にしかできない発表を届けたい」という強い意志と、
「日本の技術力を海外にも発信していきたい」というメッセージが伝わってきました。

TechTrainメディアでは、ちゅーやんさんにFlutter EU参加後の後日レポートもインタビュー予定です。その公開も楽しみにお待ちくださいね！

Flutter Kaigiのセッションで月1,000ドル以上稼げるアプリの割合の少なさを知った、いせりゅーさん。この時からアプリを“価値化”する挑戦が始まりました。リリースしたアプリ『FoodGram』のこれまでの開発についてをこの記事に凝縮してお届け。この記事を読み終えたとき、あなたも「個人開発で価値を出す一歩を踏み出したい」と思うはずです。

個人開発をしてリリースした先で“価値”を届けられる人はまだまだ少ない...

FlutterKaigiに参加して衝撃を受けた言葉があります。

「月1,000ドル以上稼げるアプリは、Revenucat利用アプリのうち17％しかない」

Flutterでよく使われる課金管理サービスRevenucatのエンジニアJeffrey Bunnさんの英語のセッションだったので全部を理解できたわけではないんですが、それでもこの数字は強烈でした。アプリをリリースしている人はたくさんいるのに、マネタイズできている人は本当に少ないんだなと。終わったあと、Jeffrey氏に 「このアプリでマネタイズするならどう思う？」と質問ができました。この時、直接話をしたことで、「本気でマネタイズしてみよう」と決めたんです。

実際、開発した『FoodGram』では少しずつですが収益化を達成できています。
Appleから初めて振り込みがあったときは、部屋で一人ガッツポーズしたり、SNSにも思わずシェアしてしまうくらい嬉しかったです。自分のアプリの価値を初めて客観的に見られた、大事な瞬間でした。

はじまりは、技術をアウトプットする手段としての個人開発

『FoodGram』を作る前も、学生時代からたくさんアプリをリリースしていました。とにかく作って出してみるというスタンスで技術を学んできました。その時に工夫していたのは、学んだ技術を使って手順の通りにやってみて、その後自分なりに工夫を加えてさらに技術を定着させるというプロセスを踏むことです。例えば電卓アプリを作ったときのこと。まずはインプットした通りに電卓アプリを作ってみました。そしてさらにフリック入力で演算できるようにアップデートをしたんです。こんなふうに少し上のレベルの開発に挑戦する癖をつけていたおかげで技術の定着はとても早かったと思います。

この「まずはやってみる」という姿勢は、今でも変わりません。一度リリースしてうまくいかない挙動があったら直すということも怖くなくなりました。今までたくさんアウトプットしてきた経験が活きているところかなと思います。実は、『FoodGram』はもともとは違ったレビューアプリをリリースする予定で進めていたんです。でも、諸事情でリリースを諦めることになってしまって、せっかく作り込んでいた機能をこのままにするのはもったいないなと思いました。そんな時、普通のSNSで食べ物だけを共有するアカウントで発信していたこともあって、「これをフードの情報共有に特化したアプリとしてリリースしたら面白そうだな」と思い立ち、スタートしました。前進のアプリも『FoodGram』もまさに「まずはやってみる」から始まっています。

このお話の詳細はnote記事もぜひ併せてご覧ください！

「やりたいことをやりたいだけ」挑戦し続ける開発スタイル

 『FoodGram』は、とにかく「やりたいことをやりたいだけやる」のモットーに基づいて、今まで自分が触れてきて面白いと思った技術的アプローチや興味のある最新の技術・機能を扱った新規実装にチャレンジしていることが技術的にこだわっているポイントです。基本的にはFlutterで全て開発しているので、Flutterでできることをできるだけやっているつもりです。アプリの内容としては一般的なフードシェアアプリではあるものの、技術の中身は新しいものも入れつつ、「ここにこんな技術を取り入れるんだ」って思ってもらえるような技術選定や開発を進めています。そして、それは全てpublicで運用をしています。

▼『FoodGram』のリポジトリ

もちろん、publicで運用にするにあたり必要な部分は難読化したりしていますが、基本的には開発者の方が新しい技術を使うにあたり参考になるようなコードや設計を意識しているのでぜひソースコードなどもみてもらえたらと思います。

ここから少し、実装の際にこだわった点について紹介していきます。

まず、ひとつめは、ソーシャルログイン機能です。この機能はアプリの根幹を支える重要な機能です。もちろん『FoodGram』にも実装することにしました。今回のログイン機能の実装には、Supabaseを採用しています。

まず初めに、ドキュメントを参考にGoogleログインとAppleログインから実装をしたのですが、その2つのログイン方法だけの場合に問題点があることに気がつきました。それは、Androidユーザーが何らかの理由でGoogleログインできなかった場合、アプリそのものが利用できなくなるというリスクです。そこで、第三のログイン方法としてTwitter(X)ログインを追加することにしました。
ところが、この実装は簡単ではありませんでした。Supabase側・Twitter Developer側・Flutter側のすべてが正しく連携していないと動作せず、何度試しても失敗の連続。それでも諦めず、一つひとつ確認しながら修正を重ねた結果、ようやく動作させることができました。今後も、さらに多様なソーシャルログインを導入し、より多くのユーザーにとって使いやすいアプリを目指していこうと思っています。

ふたつめは、シェア機能です。単にフードの画像を共有するのではなく、より目を惹くようなビジュアルを届けたいと考えました。
具体的には、画像やレストラン名などを組み合わせた独自のWidgetを作成し、screenshot というパッケージを用いてそのWidget全体を画像としてキャプチャ。さらに、シェア可能な画像形式に変換し、文言とともにシェアできるように実装しました。

単なる画像のシェアではなく、アプリ独自の世界観を反映したデザインでシェアされる体験を目指し、Widgetの構成やレイアウト、画像変換処理の流れなどに試行錯誤しながら開発を行いました。

▼具体的な実装code部分の抜粋

import 'dart:io';

import 'package:path_provider/path_provider.dart';
import 'package:screenshot/screenshot.dart';
import 'package:share_plus/share_plus.dart';
class WidgetShareService {
    Future<void> captureAndShare({
    required Widget widget,
  }) async {
    try {

      // 実装を簡潔にするため、毎回新しいインスタンスを作成
      // 本格的な実装では、Widgetのライフサイクルに合わせて管理することを推奨

      final controller = ScreenshotController();

      // ウィジェットをキャプチャ
      final bytes = await controller.captureFromWidget(widget);

      // 一時ディレクトリを取得
      final tempDir = await getTemporaryDirectory();

      // 画像ファイルとして保存
      final path = '${tempDir.path}/shared_image.png';
      final file = File(path);
      await file.writeAsBytes(bytes);

      // 画像をシェア
      await Share.shareXFiles([XFile(file.path)], text: 'シェアする文言');
    } catch (e) {
      print('シェア処理でエラーが発生: $e');
    }
  }
}

これからも色々な実装に挑戦し、ユーザーへ届けるための手段やユーザーに使ってもらえる仕組みを考えていきたいと思っています。

月額2ドルだからこそアプリの「価値」を意識する毎日

今は自分がやりたいことはもちろんですが、月2ドルのサブスクで利用をしてもらっているので、いただいているお金に見合った価値を返さないとという意識で開発にあたっています。その中で最初にぶつかった壁は、やっぱり広告について。そこで、自分の体験も含めてユーザーがなるべく不快感を感じないようにということを意識し、より快適に使ってもらうために、磨きをかけています。

まず、サブスク登録をしているユーザーに対しては、広告表示をなくし、より快適に使ってもらえるように。

そして、無料で利用するユーザーには、できるだけ不便だと感じさせないよう、広告の表示頻度やタイミング、広告の場所などを工夫しています。

表示頻度については広告の多さでアプリ利用離脱のリスクと広告収益安定のバランスを踏まえて、乱数を生成し、１０回ぐらいに１回の表示など、ちょうどいい具合の調整を頑張りました。

そしてここで、まだあまり知られていない、現段階のサブスク特典についてお話しさせてください！

• 全ての広告が非表示になる
• アカウントの画像を自分で自由に設定できるようになる
• 投稿すればするほどトロフィーとして称号がもらえる
• 自分の好きなジャンルを選択して、表示することができる

正直なところまだまだ特典は弱いと思っているので、これからももっと使ってもらえるような特典や仕組みを考えている最中です。（もちろん、将来的に、サブスク利用をしてくれたユーザーさんが損をしないようなことも着実に考えていますよ！）

リリースを機に、自分が考えた実装を進めるフェーズは落ち着きました。ありがたいことに知り合いから広がりユーザーが増えてきていることもあり、現在は、開発の4割ほどを口コミやフィードバックからの修正改善、アップデートに充てています。

要望を受けて実装中💻
あと少しでできますが、続きは明日👀#foodgram pic.twitter.com/Px1hnOOFlZ

— いせりゅー 🥳 (@isekiryu) July 19, 2025

ここまでで、実際に開発にあたった口コミをひとつ紹介します。

「自宅近くのレストランを投稿すると、住所が特定されそうで不安」というフィードバックです。この意見にはとても納得感があり、すぐに改善に取り掛かることにしました。『FoodGram』の開発にあたっては、できるだけシンプルかつ、自分の手の届く範囲で確実に作り切ることを大切にしています。そこで、複雑になりすぎない実装方法を模索しました。
最終的に思いついたのは、投稿に「匿名かどうか」のフラグをデータベースに追加し、それに応じてアプリ側の表示や共有処理を切り替える、というシンプルな方法です。複雑なロジックを避けつつ、ユーザーの安心感にしっかり応える対応ができたと思います。

▼この機能のコードをチェックする

「やりたいことをやりたいだけやる」とアプリの「価値」のバランスは難しいところですが、たくさんの人にアプリを広めるためにも大事な観点なので、毎日向き合う日々です。

▼X(旧Twitter)での実際にアプリを利用しているユーザーの声

使ってまーす！楽しいし、ランチの記録ができて凄く便利です🍛

— Natsuki (@NatsukiNo8) July 23, 2025

ただ、その共存を目指してまずはなるべく高くなりすぎない金額設定を意識しました。また、現在低コストで運用しているからこそ実現できている背景もあります。特にリリースしてからコストについて意識した選定をしたのはMap表示。ランニングコストが高い地図サービスではなく、オープンソースのMapLibreを採用して運用コストを抑えることで、ユーザーに負担をかけない形を選んでいます。この採用に関しては、同じ業界で活躍する家族やTechTrainのメンターなどからのアドバイスも活用しました。（このお話は、またどこかでできたらと思います。）

▼実際にこだわりがユーザーにも届いていることがわかるポスト

いせりゅーさんのアプリは随所にこだわりを感じられてとても好き #flutter_tokyo

— aq (@aqhayami) June 7, 2025

「まずはやってみる」から「価値」を提供する経験を

アプリをリリースしてお金をいただくとアプリに対しての「価値」を考える必要があります。ただ、「まずはやってみる」とリリースするだけではその経験はなかなか味わえません。ハッカソンで作ったアプリ、個人で作ったアプリ、たくさんの人がその経験をしている中で、まずは1円でも「価値」を提供する経験を本気でしてみませんか？

「やりたいことをやりたいように作る」って、個人開発の特権だと思う。
でも、ふと「ちゃんと誰かに届けたいな」って思う瞬間がある。そのたびに「価値ってなんだろう」って立ち止まってしまう。
今日もその間を行ったり来たりしながら、ちょっとずつ手を動かしてる🔥

— いせりゅー 🥳 (@isekiryu) August 8, 2025

「やりたいことをやりたいだけやる」から始まった開発も、ユーザーがお金を払う価値を感じてくれるのは大きな喜びです。少しずつでも「ちゃんと誰かに届けたいな」と思える瞬間があるからこそ、自分の作ったアプリで提供できる価値を考えながら、これからも挑戦を続けたいと思います。

『FoodGram』とは？

“FoodGramは、世界中のユーザーと食の楽しさを共有できる「フードシェアリングアプリ」です。美味しかった料理や、お気に入りのレストランを投稿して、みんなでグローバルな「フードマップ」を作ることができます。”

iOSのアプリストア

Androidのアプリストア

ダウンロード用QRコード

公式アカウントやLPサイトなどがまとまったものは以下よりチェック可能です。

TechTrainは、これからも「プロダクトをリリースして価値を提供するまで」の過程を発信し、日々プロダクトと向き合う開発者の方を応援していきます！

リリースまでの背景や実装の楽しさや大変だったこと、そしてリリースした先に見えた景色やその先の未来についてを語ってくださる開発者の方がいらっしゃいましたら、ぜひTechTrain DevRel Rai（X：https://x.com/hiraisoko_rai）宛にお気軽に声がけください。

「Yes」と言える準備をした人が、チャンスを掴める

もともと、海外で働くなんて選択肢は持ち合わせていませんでした。でも日経新聞社時代にRebuild FMというポッドキャストのイベントに参加して、​​グローバルに活躍する宮川達彦さんと話す機会がありました。その時初めて「海外で働く」という選択肢に気が付きました。そこから、いつか来るかもしれない機会に「Yes」と言えるように、英語の勉強を少しずつ始めていったのです。

そして社会人3年目を迎えようとしたときに、転機が訪れます。大学時代の友人から「大手総合商社のタイ現地法人でエンジニアを探してる」と声をかけてもらったんです。このチャンスのために準備していたこともあり「今しかない」と思って即決しました。もちろん不安がなかったわけではありません。ただ、それまでの数年、しっかり現場で経験を積んできたからこそ「失敗した時に日本に戻る選択肢もある」と思えたこともあり、潔く決断をすることができたように思います。結果的に、日本での経験を経たことで、納得感を持って海外を選べたのかもしれません。

アジア圏ということもありますが、英語の準備に関しては、以下のnoteをご覧いただけるとわかりやすいと思います。

「価値を届ける視点」が、“貢献力”を引き上げる

現地ではリードの経験をしたのですが、日本では経験がなく、初めてのチャレンジでした。リードとして、社内の経営層や営業の方はもちろん、パートナー企業の方とも会話する機会が多く、「事業にどう貢献するか」という視点を問われるようになりました。今まで経験のないことで、最初はよく分かっていませんでした。慣れない環境の中、分からないなりに質問し、何度も対話を重ねる中で、事業の全体像が少しずつ見えるようになっていきました。

次第に、「このプロダクトは何のために作るのか？」「どうやって会社の成長につながるのか？」と自分自身に投げかけることが当たり前に。そうして、自分のアウトプットにも変化が生まれました。単に「仕様通りに作る」だけでなく、「どうすればユーザーに届くか」「どうすれば価値が最大化されるか」を考えるようになっていったんです。 “正しく作る”から“価値を届ける”ことを大切にする意識の変化が、エンジニアとしての貢献力を大きく引き上げてくれました。「視座」が変わると、同じコードでも意図が変わってくる。それは単なるコードの話だけでなく、チームの中でどう信頼を築き、どう価値を共創するかという視点にもつながっていきました。

チームの信頼関係が、より大きな成果が生まれる

より大きな成果を出すには、チームの力が必要です。価値あるプロダクトをチームで届けるために、信頼を築くことを意識するようになりました。当時のチームでは出社して会話しながら進めるマネジメントが中心だったこともあり、「小さなことでも、一つひとつ丁寧に確認」し、とにかく対話を重ね、意図をしっかりと伝えることを大切にしたんです。初めこそ大変でしたが、コミュニケーションを重ねるにつれて、メンバーとの信頼関係が築けている実感がありました。この時から、チームとして組織に貢献する動きができるようになっていったように思います。

信頼関係を築くことは、海外組織に限った話ではないですが、この経験を通じて、「事業に貢献するには、そこで働く人同士の信頼が必要不可欠だ」ということを強く実感しました。個人としてどんなに技術や語学力があっても、チームメンバーとの関係性がなければ大きな成果は出せません。この時に経験した異文化の中で信頼を築く力は、後のグローバルな環境でも確実に活きる、自分の“貢献力”の土台になりました。

「目指す未来」を描ける人が、どこでも活躍できる

グローバルに活躍するために大切なのは、やっぱり「いち会社員としてどうやったら事業成長に貢献できるかを考えられる視座」。一言で言えば、“貢献力”です。これは、AIが発展した時代において、なくてはならないソフトスキルだと思います。ぜひ、自分が作った機能でエンドカスタマーに影響を与える経験や自分の仕事で会社全体を動かすような、組織で働かないとできない経験を積んでみてください。

もちろん私もそんな経験を積んできて、“貢献力”の大切さを身をもって感じています。それは、ここまで話してきたタイでチームや事業に貢献するために考え抜いてきた経験と、Adobe入社後の動画編集ソフト『Premiere Pro』の字幕翻訳機能の開発プロジェクトでの経験です。この経験は、私の人生で初めて世界中にユーザーがいるプロダクトの開発となりました。 実際にリリースされたあとの「自分が関わった機能が、世界のどこかで使われている」というエンドユーザーに大きなインパクトを与えることができた貴重な機会でした。

ここまで「グローバルに活躍するには」と話してきましたが、“貢献力”は、どんな環境で働くとしても、必要なスキルだと感じます。

事業にインパクトを与える“貢献力”は、今から磨ける

グローバルで活躍するには、英語力や特別なスキルが必要だと思われがちです。もちろん、最低限の英語力や技術力は必要なことには変わりありません。でも、それ以上に、「事業の目指す先に向けて、自分はどう貢献できるのか」を常に考え、行動し続けることが一番の力になると思っています。

“貢献力”は海外に行く前から、育てることができます。

たとえば、

• 機能開発をするとき「この機能は誰の何を良くするのか？」を自分に問いかけてみる
• 「こんな機能を作りたい」と提案されたとき「これをするとユーザーにどんなインパクトがあるのか？」を自分の中で考えてみる

そんな小さな習慣が、信頼を築き、視座を上げ、次のチャンスに繋がっていくと思います。また、もし海外にすぐに繋がらないとしても、必ず現場で役立つスキルであることは間違いありません。ぜひ、“貢献力”を磨いて、どんな場所でも活躍できるエンジニアを目指してみてください。

また、本気で「海外に挑戦したい」と思っている方は、この“貢献力”を磨くこと、英語の勉強と並行して、グローバルキャリアのイベントに出向いたり、現地の求人に日本から応募してみたり具体的なアクションを起こすことも必要です。

チャンスに出会う数を増やし、準備をしておけば、いつでも「Yes」と言えるはず。ぜひ、どれかひとつでも今日から始めてみてくださいね。

Taketoさん、貴重なお話をありがとうございました！「貢献力」は、誰もが今日から鍛えられる力。そしてそれは、どこで働くかに関わらず、キャリアを拓く土台になります。世界とつながるキャリアに一歩踏み出したい方は、まずはSlackやミーティングで「誰に、どんな価値を届けているか？」を一度立ち止まって考えてみることから始めてみてください。その小さな問いが、あなたの貢献力を育て、未来の選択肢を広げてくれるはずです。

TechTrainでは今回インタビューに答えてくださったTaketoさんをはじめ、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」から、ぜひ気軽にメンタリングを予約してみてください！

もしかしたら、少しだけ受け取り方を変えるだけで、人との関わり方や仕事への向き合い方が、大きく変わるかもしれません。マネージャーとして、そして今再びエンジニアとして歩むOsamuさんの実体験から、そのヒントを探ります。

フィードバックを「成長の種」に変える受け止め方

「フィードバックをもらったけど、なんだかモヤモヤする」。そんな経験はありませんか？もちろん人と人同士なので、言葉尻や伝え方によって感情が動くのは当たり前のことです。ただ、そのフィードバックをしてくれた人は「自分のために時間をかけて伝えてくれた」という事実があります。まずは、そのエネルギーを自分のために使ってくれたこと自体に感謝をしてみると、少しだけ素直に言葉を受け取れるようになれるはずです。

とはいえ、私自身も最初からそう思えたわけではありません。若手の頃は「なんでそんなこと言われるの？」「こんなに頑張ってるのに…」と、落ち込んだことも何度もありました。そんな私が、今のように考えられるようになった背景には、同僚間で行う360°評価で、丁寧に言語化してくれたフィードバックを受け取った経験があります。それは、仮説を立てて「こうした方がいいのでは」と見える形で示してくれ、自分よりも自分のことをわかっていると感じるような丁寧なフィードバックでした。そこまでしてくれた時間と労力に、正直グッときましたね。それ以来、どんな内容でも一度真摯に受け止めるようにしています。それが、どんなフィードバックも「成長の種」に変える第一歩です。

次のアクションに繋げることが成長のチャンスに

受け止めることができたら次の一歩を踏み出します。それは、フィードバックを受けただけで終わらず、自分から積極的に動くことです。

たとえば「ここはこう理解したけど合ってる？」と確認したり、「こういう課題を見つけたので、一緒に考えたい」と巻き込みを図ったりする。大切なのは、次の具体的なアクションに繋げることです。フィードバックを自分ごと化した先にこそ成長のチャンスが待っています。

私自身も、わからない点や納得できないことがあれば、すぐにフィードバックをくれた人に質問しに行きます。ほとんどの場合、丁寧に説明してくれるし、むしろ「もっとフィードバックをほしい」と積極的に関わろうとする人を、邪険に扱う人はまずいません。こうしたやりとりを通じて、課題を深掘りし、次の行動につなげることができます。フィードバックを受け止められたら、今度は「ここはこう理解したけど合ってますか？」や「一緒に考えてほしいです」と伝えて、アクションを決めるための情報を、できるだけ多く集めていくことで次のチャンスが広がっていきます。フィードバックは、あくまで成長のきっかけ。次のアクションを決めるのは自分自身です。

一方通行で終わらせない、“対話”から得られる新しい視点

壁打ち相談やレビュー依頼、メンターとの面談などは、一方的に教えを請う場ではなく、「対話」を通じて学びを深めるチャンスです。

まず、意外と大事なのは事前に「どこまで調べて、どこが分からない」かを明確にすることです。その境界を整理して話すだけで、対話の質がぐっと上がります。そして、そこから一緒に調べていく過程にこそ、大きな学びがあります。

• 相手はどのように情報を探し、整理するのか？
• どの点に着目して、問題の核心に迫っていくのか？

相談した相手の調べ方や思考の流れを間近で見られること自体が、貴重な機会です。ここで意識して欲しいのが、答えをもらって終わらせないこと。面談中に「こう理解しましたが、合ってますか？」と確認することで、理解が深まります。こうした質問を挟むことでどれくらい理解しているかが相手にも伝わるので、より学びに繋がる時間になっていくはずです。

特にTechTrainの面談のような、限られた時間で的確なフィードバックをもらいたいときには、その前の「準備」が大きな差になります。ぜひ「こう考えたけど、ここで詰まっている」と整理してから臨んでみてください。また、面談中も「今の理解で合ってますか？」と対話することで情報の質を高め、学びの幅を広げてくれますよ。

学びを最大化する、フィードバックを受けるスキル「コーチャビリティ」

今までたくさんのフィードバックを受けてきた中で、「なんでこの言葉は素直に受け入れられないんだろう？」と内省する時期がありました。その時に初めて、受け取るスキルに「コーチャビリティ (Coachability)」という名前があることを知りました。「コーチャビリティ」とは「フィードバックを受け入れ、成長に繋げる能力」で、意識と訓練によって誰でも習得できる後天的なスキルです。

まさに、今まで話してきた、

1. まず一度、真摯に受け止める
2. 主体的に動き、次のアクションに繋げる
3. 対話を通じて学びを深める

この一連のプロセスを実践するための土台となる考え方です。

もちろん、フィードバックをする側の伝え方やリスペクトの姿勢は大切な技術です。ただ、それをどう受け止め、学びに変えていくかは、受け取る側の意識や姿勢に成長の幅は大きく左右されることも事実です。コーチャビリティはまさに、その「受け取る力」を磨くための視点です。たとえば、どんなフィードバックも大きく成長する種と捉えて「今の言葉、どう活かせる？」と問いかける視点を持つだけで、より良い未来へ少しずつ変わっていくかもしれませんよ。

Osamuさん、インタビューありがとうございました！

「耳が痛いけれど、ありがたい。」そんなフィードバックに、少しだけ勇気を出して向き合ってみませんか？それは、あなたの成長の伸びしろを示してくれているサインです。
まずは一度、言葉に向き合ってみましょう。受け止め方と動き方を少し変えるだけで、見える景色がきっと変わっていきます。

TechTrainでは今回インタビューに答えていただいたOsamuさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

エンジニア人生13年のうち、SESとして10年過ごしてきたKodaniさん。多様な現場で経験を積む一方で、「自分の強みとは何か？」を模索してました。今回のインタビューでは、悩みながらもキャリアを歩み、現在は複数のプロジェクトのリーダーとして活躍しているKodaniさんの経験から「自分らしい武器を見つけていくヒント」を探っていきます！

迷いながらも、目の前の役割に向き合い続けた10年間が作ったキャリア

エンジニア歴13年のうちおよそ10年をSESとして過ごしてきました。SESの最大の魅力は、さまざまな技術や業界に触れ、幅広い知識と対応力を培えること。そんな環境で業界・業種・技術を超えて様々な現場に飛び込み、与えられた仕事を全力でこなしてきました。でも正直、「このままでいいのかな」と迷う瞬間は何度もあったんです。その理由は、特定の尖った得意分野がない、ということ。あのときはただ目の前のことに必死でした。でも、振り返るとそれが今の自分を支えている実感があります。

キャリアは、思い通りにいくことばかりじゃありません。そんな時こそ「なんでも前向きに取り組む」姿勢がいつしか自分の武器になるかもしれません。まずは、目の前のことに前向きに取り組むこと。偶然の出会いや想定外の経験が、新しい好奇心や興味が生まれるなんてことも。むしろ、そうやって広がってきたのが、僕のこれまでのキャリアでした。

「広く浅く」だからこそ感じた後悔と、経験を活かすキャリアの選択肢

SESとして最初の5年間、ずっと金融機関向けの案件を担当していました。扱う技術はメインフレームに関するもので、所謂オープン系のシステム開発で触れるインターネット上でも広く認知されている技術要素と比較して特殊なものでしたが、金融機関向けということもあり、品質に対する考え方、例えば、テストやレビューなどはここでしっかり身につきました。その他にもドキュメント作成やプロジェクトの進め方など、エンジニアとしての基礎を徹底的に鍛えられました。この経験は、今にも繋がっていますが、もう少し早くオープンな技術を使用した開発環境での開発へチャレンジしても良かったなという後悔もちょっとだけあります。

次の転職をするタイミングで、かねてから興味のあったweb系でオープンな技術をメインに扱うSESへ転職しました。この時は、まだ経験のなかった技術を扱う案件も多く、とにかく目の前の仕事を全力でこなすことに一生懸命でした。広く様々な現場で技術を磨くことができた一方で、プロジェクトの切替時の面談で「これが得意」と胸を張って言えるものがなかなか見つからず、自分よりも特定の技術に詳しい人がアサインされることも次第に増えていきました。特定の技術を尖らせることも考えましたが、「今すでに尖ってる人と比べてさらに尖らせるのは難しい」と感じたこともあり、まだ経験したことのないマネジメントに挑戦することを決めました。

幅広く経験することで見えてくる「好き」や「強み」はありますが、それを育てる意識を持てていたら、もっと早く選択肢を広げられたかもしれません。もし、あなたが得意分野が欲しいと思うなら、早めに「軸」を意識してみてください。

尖ってなくても大丈夫。自分にとってベストな戦い方をみつける方法

2回目の転職を考え始めたとき、選択肢は2つありました。先に話していたマネジメントとITコンサルです。どちらも今までの幅広い経験が活かせる可能性があると考えていたのですが、縁があってマネジメントの道を進むことになりました。

今はレンサという会社で、自社サービスの開発や社外の開発プロジェクトをラボ型開発として対応していて、今までのように幅広い業務をさせてもらっています。チームをリードすることやPMとしての役割がインの業務です。なので、開発において自分自身がメインで手を動かすことは少なく、最初は慣れないことも多々ありました。最近は、慣れてきたこともあり、複数のプロジェクトに並行して関わることも増えて、大変ですがやりがいを感じています。

1つのチームでのマネジメントではなく、複数の案件でプロジェクトを管理するポジションなので、今まで様々なプロジェクト・開発で開発してきた経験で培ってきた、柔軟性・適応力・全体把握力が活きています。これは、そんな自分だからこそ選ぶことができた、新しい“戦い方”だと実感していますし、自分の経験が強みとして活きる道を選ぶことができたと思っています。

尖っていなくても、広く経験してきたことを活かせる場面は必ずあります。大事なのは、「自分の経験が活きる場面ってどんな環境だろう？」と問い直してみることかもしれません。

どんな道を歩んでも手に入る。武器は使い方を考えることが大事

キャリアを考えるとき、まず意識したいのは「自分がどんなエンジニアになりたいか」ということです。技術を極めたいのか、幅広く活躍したいのか。目指す姿が少しでも見えると、選択肢や行動も定まりやすくなります。

極めたい技術があるなら、周囲にアピールしてみてください。「この技術を伸ばしたい」「これを極めたい」と言葉にすることで、チャンスが回ってきやすくなります。たとえばQiitaやZennで発信したり、技術イベントに参加してみたり。実際マネジメントをしていると、声に出しているメンバーの方を、自然と応援したくなるんですよね。

まだ極めたいものがない人も安心してください。いろんな技術や開発環境に向き合いながら、「自分はどんなときにやりがいを感じるか」を探っていくと良いです。好きや得意は、あとから見つけて育てていくこともできます。幅広い経験そのものを“武器”にしてチャレンジしていくことも、立派な選択肢です。

キャリアには正解はありません。自分の変化を見つめながら今あるスキルをどんな武器にできるか？という視点で経験を積んでいきましょう。

「このままでいいのかな」「強みはなんだろう？」と感じることは、きっと誰にでもあると思います。Kodaniさんも、そんな迷いの中で少しずつ自分の道を見つけてきました。

すぐに答えが出なくても、自分なりに積み重ねていくことが、あとから意味を持つこともあります。無理せず、自分のペースで進んでいけたらいいですね。もし迷ったら、誰かに相談するのもいい選択です。

TechTrainでは今回インタビューに答えて頂いたKodaiさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

「ものづくりが好き」が、すべてのはじまり

いまは一人目デザイナーとして働いていますが、実は、最初からデザインを専業にするつもりはありませんでした。新卒で入社したゆめみでは、内定者アルバイトの頃からフロントエンドエンジニアとして開発に携わっていて、当時の自分の肩書きは“エンジニア”だったんです。そんな自分がデザインに興味を持つようになったのは、UIを実装するなかで、「その前段にあるデザインも自分でできた方が、もっといいものが作れるのでは？」と思ったことがきっかけでした。

僕にとっての原点は、ずっと「プロダクトをつくりたい」っていう気持ちなんですよね。コードを書くのが好きというより、“ものづくり”という行為そのものに惹かれるという感覚の方が強いです。

将来的にはエンジニアリングもデザインもどちらも担える存在になりたいと考えていたので、UIを中心に未経験だったデザインのスキルを伸ばそうと、デザインチームへの異動を決めました。そこからはUIデザインの経験を積みつつ、デザインエンジニアリングのチーム立ち上げにも関わり、両軸のキャリアの土台を築いていきました。

すべては「ゼロ」から。チームを育てるデザインを担う責任

そんな中、現在所属するニーリーから、副業を経てデザイナーとしてジョインしないかという声がかかりました。  最初は、「自分のアウトプットが、そのまま会社のデザイン品質の上限になる」ということへの不安の方が大きかったのを覚えています。

当時は、デザインエンジニアリングを突き詰めたいという思いもありましたが、ニーリーが求めていたのは“デザイナーから事業のトップラインを伸ばすことができる人”というフェーズであることも理解していました。でも、その環境だからこそ、“プロダクト/文化づくり”に一から関われる。そう感じたことが、決断の後押しになりました。

ゼロからの入社ではなかったため大きなギャップはありませんでしたが、デザインに関する土壌が何もない状態からのスタートは、やはり大変でした。 

アウトプットも、チームも、一からつくる必要がある中で、最初特に大事にしているのは“属人化を防ぐ仕組みやルール”を整えることでした。デザインシステムと呼ばれるような、色や角丸などを“トークン”として一元管理し、FigmaのたComponent機能やVariablesを活用し再利用できるよう整える──といった具合に、使いやすく・間違えにくいデザインのルールや仕組みを目指しました。

UIを超えて、事業そのものをデザインする

また、もうひとつ大変なことは、一人で会社に関する全てのデザインを担う必要があるということ。デザインする対象としては、今まで経験してきたプロダクトのデザインに留まらず、SNSやブログ関連の画像、チラシなどの広報素材や、外部向けの資料など、グラフィックデザインや広義のコミュニケーションデザインなども含まれます。経験がない分野でのデザインは大変ですが、同時に、事業全体を見据えた高い視座でデザインを考える貴重な機会にやりがいも感じています。よりプロダクトの魅力が伝わるデザインがあれば、事業全体の成長にもつながっていくことを日々実感しています。

「なぜ？」を考え抜く。それが、すべての仕事に通じる力に

経験のない分野にも手を伸ばしていますが、その中でひとつ大事にしている言葉があります。それは、デザインを学び始めた頃に尊敬している先輩からもらった「なんでそれがそうなっているのか説明できなきゃ、それはデザインじゃない」という言葉です。

例えば、UIであれば、ボタンひとつとっても「なぜ角丸なのか？」「なぜ4pxなのか？」「なぜその色なのか？」など、全て理由を説明できる状態にするということです。自分がする仕事全てそうだと思っていて、常に「使う人にとって本当にいいものは何か？」を考えています。もし、迷ったときは、説明するための根拠を得るために、UI（画面の見た目や操作性）なら類似サービスを調べますし、UX（ユーザー体験）ならユーザーにヒアリングを行う。チームづくりなら関係者に話を聞く。とにかく納得できる理由を探して説明をできるようにしておくんです。

一人目という選択肢を選ぶときに考え抜いてほしい「なぜ？」

一人目デザイナーになるという経験は、必ずしも「目指してなる」ものではないかもしれません。自分自身も、“タイミングとやりたい事のマッチがあったので選んだ”という側面が大きかったです。

ただ、もし、少しでも一人目デザイナーという選択肢を考えている人がいるのなら「なぜ、一人目デザイナーになりたいのか？」をよく考えてみてほしいなと思います。

とても広い経験を積むことができる反面、誰にでもおすすめできるというものでもないというのが本音です。ただ、もし、この世界に飛び込むか迷っている方がいるのであれば、「なぜ、一人目デザイナーなのか？」という問いにとことん向き合ってみてください。

一人目には、一人目のやりがいがあります。でも、もしかしたら、「なぜ」の理由は、他のポジションでも得られる可能性もあるかもしれません。だからこそ、「何をつくりたいのか？どう働きたいのか？」を立ち止まって考えてみてください。そのうえで、一人目デザイナーとして歩む理由が自分の中にあるなら、ぜひこの選択肢に一歩踏み出してみてください。

「なぜ一人目デザイナーになりたいのか？」今回はデザイナーでしたが、エンジニア、その他の職種でも、初期のフェーズには必ず一人目〇〇というポジションはありますよね。

あなたがもし、“最初の一人”としての挑戦に迷っているなら、まずは一歩踏み出して、現場で向き合っている人の声を聞いてみてください。

TechTrainでは今回インタビューに答えて頂いたunotoviveさんをはじめとして、150名以上の現役エンジニア／デザイナーが、あなたのキャリアの相談に乗っています。気になる方は、サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

続けることは誰にとっても難しい。でも、もし続けるためのシンプルな方法があったとしたら？

今回は、読書やプログラミングを習慣にし、着実に成長を重ねてきたYukiさんにインタビュー。習慣化が苦手なあなたにも、きっと刺さるヒントが見つかるはずです！

才能じゃない。プログラミングを続けられた理由

「継続できる人＝才能がある人」と思われがちですが、僕はそうは思いません。というのも、僕は最初、「HTMLって何？」というレベルからのスタートでしたが、サイトを作ってみたいという好奇心で少しづつ学び進め、自然とコードを書く習慣がつきました。その積み重ねで、明らかに自分の力になっていたからです。

社会人になると、「習慣がある＝積み上がっていることの強さ」をより実感するようになりました。短期集中で詰め込んだ勉強は忘れてしまっていたのに、地道に続けてきたことはしっかりと身についていたんです。

とはいえ、毎日ストイックにやっていたわけではなく、気が乗らない日もありました。そんな時は思い切って休む。そんな“ゆるさ”があったから、長く続けられたのかもしれません。

今では、その習慣が仕事にも活きていて、プログラミングがいつの間にか“武器”になっています。やっぱり「続けること」こそが、いちばんの成長法だと実感しています。

筋トレをやめて気づいた、続けるための意味

プログラミングは自然と続けられた一方で、筋トレはうまくいきませんでした。1〜2年続けたものの、いつの間にかやらなくなっていて。「また続かなかったな…」「自分って、意志が弱いのかな」と感じたこともありましたし、頑張ってた自分を思い出して、いやになることもありました。

でも、ふと「そもそも、なんで筋トレしたかったんだっけ？」と考えてみたんです。すると出てきたのは、「健康のため」「やったほうがいいから」という、どこか一般論的な理由ばかりでした。

プログラミングは、「楽しい」「できるようになりたい」という自分の感情が出発点にあったのに、筋トレは違っていたのです。

この経験をきっかけに、「やったほうがいい」じゃなくて「本当にやりたいこと」を選ぶこと。そのうえで、自分なりに“意味づけ”できるかどうかが、習慣を続けられる鍵なんだと気づくことができました。

たった1ページから。無理なく続けられた読書習慣

いろんな習慣化に挑戦してきた中で、今、自然と続けられているのが読書です。始めたのは2023年の夏。「もっとインプットを増やしたい」「SNSに時間を使いすぎているかも」と感じたのがきっかけでした。

まずは、1日1ページは必ず読むというルールで、ハードルをぐっと下げました。さらに、読んだことをブログでアウトプットすると決めたことで、毎日の達成感にもつながり、技術知識もビジネス思考力も身について行った感覚も得られました。今では月に2冊ほど読むようになり、読書が日常の一部になっています。

とはいえ、疲れていてどうしても気が乗らない日もあります。そんなときは「せめて1ページだけでも」と、自分を奮い立たせページをめくりました。1ページでも読むと、不思議と「もう1ページいこうかな」と思えてくる。それが小さな自信になったんです。

この経験をきっかけに、意味だけでなく継続するためのやり方にも意識するようになりました。

“1ページ・1行”から未来が変わる。意味と最小単位が、習慣をつくる

続けられた読書、自然と途切れてしまった筋トレ。振り返って見えてきたのは、「気合ではなく、仕組みで続ける」ということでした。

僕が最も大切にしているのは、“最小単位”で始めること。大きな目標を掲げると、どうしても負担が大きくなってしまいます。だから、「これだけじゃ達成できそうにない」と思えるくらい小さく始めるのがコツです。読書なら1日1ページ。たった数分でもページを開けば、「今日もできた」と思える。こうした小さな達成感の積み重ねが、習慣化への近道です。

もうひとつ大切なのは、“本当にやりたいこと”であること。筋トレは「やったほうがいいから」と義務感で始めたけれど、つらくなったときに続けられなくなってしまいます。「これを続けてどう変わりたいか」「どんな未来が欲しいのか」が見えていると、納得して行動し続けられるんです。 今日の1ページが、未来の自分をつくる。それくらいの気軽さで、でも確かな手応えを感じながら、僕はこれからも小さく、楽しく、続けていきます。

続かなくても、大丈夫！「また始める力」が習慣をつくる

プログラミングの学習は、ときにうまくいかず、気持ちが折れそうになることもあると思います。僕は、また始める力も習慣の一部だと思っています。100日続いたあとに止まってしまっても、それで終わりじゃない。101日目からまた始めればいいんです。

僕自身も、休んだ時期がありました。でも気づけば、またコードを書く日々に戻っていました。続けたい時は、一度も止まらないことじゃなくて、何度でも戻ってこられることも大事にしてもらいたいなと思います。

もし「これは自分の力にしたい」と思えることがあるなら、完璧じゃなくていい。1日1ページ、1行でも。小さくていいから、今日から始めてみてください。

Yukiさん、素敵なお話をありがとうございました。「続けるのが苦手」と感じていた方こそ、小さな一歩を踏み出すヒントになったのではないでしょうか。もし、“自分のペースで成長したい”と思ったなら、意識して習慣化スキルを手に入れたYukiさんと話してみるのもおすすめです。

TechTrainでは今回インタビューに答えて頂いたYukiさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

与えられるのを待たず、自らの手で成長のきっかけを掴み取ってきた軌跡と、独自の仕事観に迫ります。

今の自分と、求められるスキルのギャップがエンジニアとしての成長のバネに

大学のときは、エンジニアとはまったく無縁の学生生活を送っていました。そんな自分がITの世界に飛び込んだのは、「これからは、どんな業種にもITが必要だ」という直感からでした。入社後、最初に任されたのは、なぜか営業。正直戸惑いました。でも、現場での社長やお客様とのやりとりを通じて、エンジニアには想像以上のスキルや責任が求められることを実感し、厳しい現実を肌で感じることができました。

その後、希望通りエンジニア職に転向はできたものの、スキル不足で任される仕事も少なく、なかなか経験が積めない日々が続きました。振り返れば、「スキルがなければ仕事は回ってこない」という現実を突きつけられたあの悔しさが、自分を変えるきっかけになった気がします。そこで、さらに自分を磨くため、転職を決意しました。

指示を待っていた自分から、考えて動く自分への変化

転職してから僕を待っていたのは「誰もやることを決めてくれない」環境でした。最初は何をすればいいのか分からず戸惑いましたが、その分、自分で考えて動く力が自然と鍛えられていったように思います。仕様書通り進めるのではなく、「なんでこれをやるんだっけ？」と問いながら取り組むようになってから、実装がただの作業ではなく、誰かの役に立つ仕事へと変わっていきました。

きっかけは、何気ない会話から提案した社内ツールの改善でした。実装後、あるメンバーから「毎日この作業に30分かかってたけど、今日は2秒で終わった！マジでありがと！！！」という言葉をもらって、「自分の仕事ってこんなに誰かの役に立てるんだ」と実感したんです。想定以上の反応が本当に嬉しくて、「次は何ができるかな？」と自然に考えるようになり、「みんなが喜ぶ、開発で解決できる課題はないかな？」と自分から探すようになっていました。こうした小さな成功体験がいくつも積み重なって、指示を待つのではなく、自分から動くことが当たり前になっていきました。この受け身から自律への変化が、自分の働き方を根本から変えてくれました。

活躍する人が当たり前にやっている「価値」を考えるということ

ベンチャーでは、エンジニアも意思決定に関わる場面が多く、「こうしたら良くなるかも」「この方法もある」と自ら考え、提案し、早いサイクルで実行できる人が重宝されます。つまり、「価値を出す」という意識をもって動ける人が、信頼され活躍できるのだと思います。そんな環境下で複数のチームメンバーと仕事をしていて気がついた、活躍しているエンジニアの共通点が2つあります。1つは「自分で考えて動けること」。もう1つは、「コミュニケーションがスムーズで、レスが早いこと」です。

それに加えて、ただ作業をこなすだけじゃなくて、「本当に価値があるのか？」「それが誰のためにどう役立つのか？」を考える癖をつけることが大事。それだけで、やるべきことの質がグッと上がります。

最小の労力で最大の成果を出すため、最近はAIを活用して自動化や効率化も進めています。もともと、「どうしたらもっとラクにできるか？」を考えることが好きなこともあり、もっと価値を高める業務に時間を捻出するための動きをどんどん組織に取り入れていくことも、今の僕の大事な役割になっています。

あえて“階段”を選ぶ習慣をつけることが、成長に直結する

駅で階段とエスカレーターが並んでいると、つい楽なエスカレーターを選んでしまいますよね。僕もそうでした。でも最近は、あえて階段を選ぶようにしています。小さな選択の積み重ねが、仕事での成長にもつながると気づいたからです。たとえば、コードレビューで「OK」と思っても、もう一度見直してみる。会議でも「まあいいか」と流す前に「ここだけ確認させて」と声を上げる。エスカレーターのように流れに乗る方が楽ですが、そうした“ひと手間”こそが違いを生むんです。

AIツールの選定でも同じです。「今のやり方で十分」と流すこともできましたが、新しいツールを少しずつ試してはチームに共有してきました。こうした地道な積み重ねが、結果的にチーム全体のAI活用を大きく前進させました。僕の好きな言葉に『Do something you are not ready to do（今の自分にはできないと思うことをやれ）』があります。でも実は、日々の「ちょっと大変だけど、やったほうがいいこと」を選び続けることも、同じくらい大切だと思っています。

成長のチャンスは、あえて選ぶ“階段”の中にある。AI時代だからこそ、この習慣が「昨日の自分を更新する」原動力になると信じています。

ちょっとでもいい。常に「自分史上、最高」を更新し続けよう

これから技術を学ぶ人に伝えたいのは、すごい誰かと比べるより、自分の技術や興味としっかり向き合ってほしいということ。昨日より少しでも前に進めたら、それだけで立派な“更新”です。

僕もまだ道半ばですが、毎日少しずつ「昨日の自分」を更新する努力は続けています。最近は仕事でAIエージェントやMCPといった新しい技術を使い始めて、その可能性にワクワクしています。いつかこういった経験を、自分の言葉でしっかり発信できるようになりたい。それが今の僕の"階段"です。

メンターとして登録はしていますが、実はまだメンタリング経験はありません。だからこそ、一緒に悩み、一緒に成長していける存在でありたいと思っています。完璧な答えはなくても、自分が通ってきた道や、今まさに挑戦していることは共有できる。

あなたが次に目指す「史上最高の自分」は、どんな姿ですか？

「自分史上、最高の自分」を、焦らずゆっくり"更新"していく。その道のりを、一緒に歩んでいけたら嬉しいです。

Jumpeiさん、インタビューありがとうございました。「成長したい。でも、どう動けばいいかわからない」そんな迷いに、そっと背中を押してくれるようなお話でした。まずは、小さな”更新”を積み重ねていく。昨日よりほんの少し前に進むことが、成長する習慣になっていくのかもしれませんね。

もし迷ったときは、Jumpeiさんに相談してみてください。自分の歩幅で一歩を踏み出すヒントを、きっとそっと差し出してくれるはずです。

TechTrainでは今回インタビューに答えて頂いたJumpeiさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

コードを書く前に必要な初期設定をあらかじめ整えておくことで、アイデア発案時の熱量を落とすことなく、開発することができます。

今回は、その初速をサポートしてくれる「GitHub の Template Repository」についてご紹介します。

Template Repository とは

GitHub の Template Repository とは、リポジトリをテンプレート化し、同じ構成の新しいプロジェクトを簡単に作成できる仕組みです。

テンプレートとして登録されたリポジトリには「Use this template」ボタンが表示され、そこから新しいリポジトリをワンクリックで作成できます。通常の fork と異なり、コミット履歴が引き継がれないため、まっさらな状態から開発を始められるのが特徴です。

Template Repository の作り方

既存のリポジトリをテンプレート化する手順についてご紹介します。

1. GitHub 上で対象リポジトリを開く

まずはテンプレートにしたいリポジトリを開きます。

2. [Settings] → [General] → Template Repository にチェック

上部メニューの「Settings」をクリックし、画面左の「General」セクションをスクロールします。

すると、[Template repository] というチェックボックスが現れます。

ここにチェックを入れるだけで、このリポジトリはテンプレート化されます。

3. 作成したテンプレートを使う場合は「Use this template」から作成

テンプレート化されたリポジトリには、[Code] ボタンの横に 「Use this template」 というボタンが表示されます。

このボタンをクリックすると、新しいリポジトリ作成画面が表示されます。

開発対象ごとにテンプレートを用意する

私は開発対象に応じて、以下のようなテンプレートを日常的に活用しています。

活用しているテンプレート例：

• Nuxt プロジェクトテンプレート

• ESLint (Stylistic) / VSCode settings / Cursor Rules 等を設定済み。

• Nuxt UI Dashboard テンプレート
  • 上記に加え、管理画面開発に適した Nuxt UI のセットアップ済み。
• Nuxt + Capacitor を使用した Native iOS アプリテンプレート
  • Capacitorを用いて、Native iOS 開発のセットアップ済み。
• TypeScript ライブラリテンプレート
  • unjs/template をベースにした設定。automd や changelogen の設定が特に便利で重宝しています。

Template Repositoryを使うメリット

手間を減らし、開発に集中できる

設定や構築にかかる時間をカットできるため、本来注力したい実装にすぐ入れます。

アイデアをもとに突発的にアプリを実装する際には、この「すぐ書き始められる」感覚が非常に重要です。

コードの一貫性が保たれる

Cursor等を用いてソースコードを生成することで、エディターに表示されるエラーを検知し、自動で修正してくれます。

これにより、ソースコードの品質を保ちながら、開発者が手作業で修正する手間を大幅に削減できます。

初学者の学びにもつながる

あらかじめ構築されたテンプレートを元にカスタマイズすることで、各種設定の必要性や、プロジェクトの構成を実践的に理解できます。

プロジェクトの裏側にある構造やビルドの仕組みを学ぶ題材としても有用です。

まとめ

Cursor や Claude Code などのAIを活用した「Vibe Coding」では、あらかじめ整備されたテンプレートの存在が大きな役割を果たします。

例えば、

• 好みのLinterや型チェックを最初から適用することで、AIが生成したコードの品質を担保できる
• サーバーやアプリケーションを即座に起動できる環境を整備することで、開発にすぐ着手できる

このように、GitHubのテンプレートリポジトリを活用することで、開発初期の立ち上がりをスムーズにしつつ、高いコード品質を維持することが可能になります。

皆さんもぜひ、好みの設定を適用した GitHub Template Repository を作成してみてください！

久しぶりのメンター執筆シリーズはいかがでしたか？

現役エンジニアが執筆するからこそのトピックや本よりライトだけどみなさんにとって新しい発見がある情報をお伝えできるコンテンツとなってきました。この執筆シリーズは、リライトはほとんどしておらず、メンターの思考をそのままみなさんへお届けしています。

更新タイミングは不定期ではありますが、ぜひ、次の記事も楽しみにお待ちください！

コードも書けず、何もできなかった時代から、どうやって理想の働き方にたどり着いたのか。実装とリサーチ、両輪でキャリアを切り拓いてきた道のりに迫ります。

「コードが書けない」から始まった、キャリアの一歩

大学1年でプログラミングに出会い、ベンチャーでアルバイトを始めましたが、コードは意味不明、エラー続きで無力さを痛感する毎日。それでも少しずつ書けるようになり、楽しさも感じられるようになっていきました。そして、就活が始まる頃には、「もっと多くのユーザーに価値を届けたい」と思うように。そんな中で参加したクックパッドのインターンでは、ただ動くものを作るだけでなく、ユーザーの声を意識して開発する面白さに初めて触れました。

その後もクックパッドでバイトを続けましたが、技術力の壁に何度もぶつかり、タスクをこなせず悔しさや無力感に押しつぶされそうになることも。それでも、「もっと良いものを届けたい」という気持ちは消えませんでした。次第に、届けるにはコーディング力だけでは不十分なのではと感じるようになりました。

「届けたい」が導いた、研究という道

就職か大学院か。将来を考え始めた大学4年の頃、ちょうど機械学習やディープラーニングの研究が注目を集めていました。Webエンジニアとして働くなかで、「ユーザーに価値を届けるには、どう課題に応えるべきか？」という問いが、次第に大きくなっていきました。大学でも研究に触れる機会が増え、アルバイト先のクックパッドでもリサーチに関わるように。本を読んでコードを書くうちに、研究そのものの面白さにも惹かれていきました。

当時は本当に迷っていたんですが、「もっと良い技術を、ちゃんと届けたい」と考えたときに、「やっぱり研究だな」って、すごく腑に落ちたんです。学ぶことは多く、リサーチ自体とても面白かったのですが、それと同時に、ある不安も芽生えていきました。

届ける実感が導いた、研究×実装というキャリアの軸

コーディング力もなく、ユーザーとの距離感にもやもやしていた頃、機械学習を使ったiOSアプリ刷新プロジェクトでAPIチームに異動し、本格的にソフトウェアエンジニアとして挑戦を始めました。しかし現実は厳しく、わからないことだらけ。プライドもあって助けを求めにくく、心が折れそうになりました。

でも「前より1行でも良いコードを書く」みたいな小さな目標を積み重ねていくことで、前に進める実感が持てたんです。リリースされ、自分のコードが役に立つ。その実感こそがやりがいだと気づきました。そして、どんなに素晴らしい研究も、実装されなければ価値がないという考えは、ここから生まれました。

今は自動運転のスタートアップであるTuring株式会社で、最先端の論文を読み、プロダクトに落とし込む日々を送っています。研究と実装の両輪でユーザーに価値を届けることが、自分のエンジニアとしての軸になっています。

「難しいを楽しむ」謎解きとしての技術探求

研究成果を社会に届けることは、一筋縄ではいかない挑戦です。どれほど理論的に優れた技術でも、実環境で動かし、ユーザーに価値を届けるには多くの壁があります。だからこそ「これ、いけるかも？」という仮説が「できた！」に変わる瞬間に、私は強いやりがいを感じます。

私にとって難題に向き合うことは、まるで謎解きのような感覚なんです。最近では、『大規模AI学習用データ生成基盤を支える技術』の記事でも紹介したように、クラウド上での非同期処理やスケーラブルな設計といったゼロからの構築に取り組みました。膨大な計算と精緻なフィルタ設計が必要で非常に困難でしたが、その分没頭でき、楽しくもありました。研究と実装、その両輪で技術をかたちにしていくことが、いま私が理想とする働き方です。

“できた”の積み重ねが、理想へとつながる

挫けそうなとき支えになったのは、クックパッドCTOの「楽しんでやってるやつが無限に伸びていく」という言葉でした。すぐに楽しめたわけじゃないけれど、毎日没頭していくうちに、自然と楽しくなっていった気がします。そんな積み重ねが、気づけば力になっていたんです。

努力は、生活のあちこちに分散していていいと思っています。プログラミングが進まなくても、ちょっと早起きできた、机を片づけたみたいな、”小さなできた”が、「ちゃんと進んでる」という実感につながるんです。

今、挑戦の途中だったり迷っている人へ伝えたいのは、いきなり「理想の働き方」を実現しようとしなくていい。私も、書籍を読み直す、1つの論文を読み切る、机を片づけるといった積み重ねが、理想に近づく原動力になりました。小さな努力を続けること。それが、理想の働き方への一歩になるのかもしれません。

迷いながらも、小さな“できた”を積み重ねていくこと。
Shintaroさんの歩みは、そんな毎日がやがて理想につながっていくことを教えてくれました。まずは今日、自分なりの“できた”をひとつ。 その一歩が、未来を少しずつ作ってくれるはずです。改めて、Shintaroさん、貴重なお話をありがとうございました。

TechTrainでは今回インタビューに答えて頂いたShintaroさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

本記事では、登壇者の技術的エッセンスをギュッと凝縮してお届けします。

登壇トピックまとめ

「そのNext.js(Server Actions)のセキュリティを意識できていますか？」by Ken Watanabeさん

Server Actionsは「便利だけど危うい」──気を抜くと大きな脆弱性につながることを実際の事例も交えてわかりやすく解説。実際のコードやそれを実行するとどうなるのかが話の流れで入ってきやすく学びになるセッションでした。

登壇内容サマリ：

Next.js 14以降で導入された「Server Actions」は、use serverを付けるだけでクライアントからサーバ関数が呼び出せる便利な機能。しかしその気軽さゆえに、セキュリティ面での見落としも起こりやすくなってしまいます。その対策もセットで解説。

• 実態はfetchによるPOST通信。curlでも実行可能
• パストラバーサル、環境変数の露出など、ナイトメアな実装例も紹介
• 対策として、バリデーションの徹底・ヘッダー設定・リクエストサイズ制限が必須

登壇資料に掲載されているカミナシ社のProduction Readiness Checkについては、以下のテックブログからチェックできます！

「FigmaのMCPを活用したNext.js withTypeScriptの爆速実装ガイド」by スーさん

「理想の状態を定義し、そこに近づけるループを回す」──AIを活用するうえでの実装ガードレール設計について。AI活用は、まだまだTechTrainの中でも模索中！現段階でお伝えできる内容を凝縮して公開。

登壇内容サマリ：

Figmaの構造データをAIが理解可能な形式に変換する「MCP（Model Context Protocol）」を活用し、FigmaとCursor、Next.jsの連携による実装自動化ワークフローを紹介。

• Figma → Style Dictionary → 実装に反映
• 型定義・バリアント・デザインパターンなどを前提に設計することで、AI実装の精度向上
• 実装後はlinter・型チェックで品質を担保、自動化と品質の両立

「TSで型安全なエラーハンドリング〜まずはBranded Typeから始めてみては？〜」by かわりくさん

小さく導入できてチームにも広げやすい設計。型安全なエラーハンドリングについて話を聞いてすぐに実践できそうなくらい具体的な話が10分に落とし込まれていました。

登壇内容サマリ：

TypeScriptでよくある「try-catchのerrorがunknownで困る」問題に対し、Branded Typeを活用するアプローチ。実際のコードを見せながら、エラーハンドリングとBranded Typeそれぞれについてコンパクトにかつわかりやすくまとめており、話を聞いてからすぐに試してみたくなるような解説。

• string & { __brand: 'ErrorName' } のように型にタグを付けて識別
• エラーはthrowではなくreturnで返す → 扱いやすく型安全
• AIコーディング補完との相性も◎、現場にフィットしやすい導入方法

「「Figma見れば全部わかる」を目指したデザインシステム」by だいちさん

時間が限られている中でブランディングと同時に複数プロダクトを立ち上げるために導入したデザインシステム。参照先をFigmaのみにしたり、用意するコンポーネントをあえて絞ることでフロントとのやり取りの効率化に対する取り組みが主なテーマ。スーさんの登壇内容とも関連が深く、まだまだこれから進化の余地のあるTechTrainのデザインシステムの現在地について発表してくれました。

登壇内容サマリ：

• リブランディングとデザインシステムの構築を同時に行う方針・効率化の意思決定
• プロダクト制作高速化のための取捨選択・仕組み作り

Figma運用において自動化の前提には“設計の整理”がある。どこまで定義するかも含めて作って終わりにならずプロダクトや環境とともに育てていく必要があるし今後もプロダクトの進化に合わせてやりたいことはまだまだたくさんあります。

FigmaCommunityに公開したTechTrain Terminal. [ UI Design System ]は以下のURLからチェックできます！

https://www.figma.com/community/file/1472050808130527580/techtrain-terminal-ui-design-system

「リアルタイムAIの実装とWasm奮闘記」by Tomohiro Inoueさん

食品ラベル検査AIを実装する中で、Python → TypeScript（OpenCV.js）→ C++（Wasm）と3回プログラムを書いた過程をリアルに紹介。本当は1回の書き直しで完了の予定だったはずが、2回になった背景も含め、実務で試したからこその知見たっぷりのセッションでした。

登壇内容サマリ：

実装変遷そのものが教訓。カミナシ社ならではの現場で実際に活用されるシーンにおける必要事項も加味した上で「最適な技術選定は一発では決まらない」ことを痛感するリアルな開発記録。緊張感がある現場実装の話から最後はチームメンバーみんなで「ロブスター食べた」のオチでほっこりタイムもあった素敵な内容。

• OpenCV.jsは手動deleteが必要でメモリリーク多発
• C++でWasmに落とし込むことで処理速度・精度・安定性がUP
• wasm領域ではマルチスレッドの課題も残るが、エッジAIの可能性は大きい

「Cloudflare Durable Objectsについて」by Ugoさん

今回、TechTrainメンターとして登壇したUgoさんは、Cloudflare Workers + Durable Objectsでリアルタイムチャットを実装した個人開発での事例を紹介。サーバレス × 状態管理 × WebSocketという組み合わせでシンプルかつスケーラブルな構成に。メリットデメリットやその回避方法なども具体的に提示してくださり、今後の技術選定や検証のヒントとして参考になる、実感のこもったセッションでした。

登壇内容サマリ：

Cloudflare Workersだけでは難しい「状態を持つ処理」を、Durable Objectsを活用して丁寧に組み上げていく姿勢が印象的。ユースケースに即した選定と構成により、リアルタイム性や一貫性を担保する上での実装アプローチが参考になる内容。

• Durable Objectで各ルームの状態を保持
• WebSocketをつなげてリアルタイム通信を管理
• ステートフルに見える構成を、ステートレス基盤上でどう作るかが鍵

おわりに

技術の進化と実装の現場感が混じり合った6本のLTは、どれも単なる「知識の共有」にとどまらず、課題への向き合い方や実務上の工夫までを含んだリアルな学びにあふれていました。

「Server Actionsをセキュアに使うには？」「AIとデザインの協業はどこまで自動化できる？」「型安全な設計って、実際どう始めるの？」

そんな問いへの“現場からの答え”が詰まった、刺激的な3時間となりました。また、後半の交流会ではセッションの内容のより細かい部分や、日々の業務で困っている実装についてなどの議論も飛び交っていましたよ！

また、今回はカミナシさんのカルチャーである「現場主義」ということで、TechTrainのアンバサダーを務めてくれている東京海洋大学プログラミングサークルNeppの学生3名をご招待し実際に現場で働くエンジニアからの知見を持ち帰ってもらう機会にもさせていただきました。

▼Nepp公式Xのポスト

株式会社カミナシ様×株式会社Techbowl様(TechTrain)の勉強会に参加させていただきました！
実際に働かれてる社員さんから貴重なお話も聞けてとても勉強になりました！！#TechTrain #勉強会#東京海洋大学#プログラミング pic.twitter.com/DWv0t8NHqe

— NePP@海洋大プログラミングサークル (@NePP63975908) June 4, 2025

TechTrainでは、エンジニア、デザイナー、PMなどものづくりを支えるみなさんの知見を広げるイベントの開催を積極的に企画しています。

今後のイベントの様子も引き続きお伝えしていきますので、お楽しみに！これからも、たくさんのエンジニアの皆さまとお会いできることを楽しみにしています。

「面白い」だけでは届かない。プロの現場で知ったリアル

学生時代は、作りたいものを自由に作れる環境でした。課題も自分の好きなジャンルで挑戦できたし、チーム開発も気の合う友達と進め、面白いかどうかだけに集中できたんです。就職先も迷わずゲーム業界。

でも、いざプロの現場に入ってみると、「おもしろい＝売れる」わけじゃないことを痛感しました。いくらおもしろくても、ビジネスとして成立しなければ企画は通らないし、チームには様々な立場の人がいて、自分一人の意見で物事が動くわけではない。憧れの仕事に就けたはずなのに、実際に現場に入ってみると、想像以上に厳しい現実が待っていました。「これがプロになるってことか」と、いろいろ考えさせられました。

やりたいことを全部やる。エネルギーが有り余っていた新卒時代

そんな現実に直面しながらも、「もっと何かやりたい」という気持ちが強かった。特に新卒の頃は、本当にがむしゃらでしたね。空き時間はひたすらインプットにあてて、オンボーディングも全力。社内でゲームジャムを企画したり、別部署の人と部活動をしたり、ビジネスコンテストに出してみたり…。

そんな頃、社内でUnityを使うプロジェクトが増えてきて、「デザイナーがUnityも使えた方がいいよね」という話が上がり、独学は大変だから勉強会を開いてみようと。気づけば社内のデザイナー50人以上にUnityを教えていました。Unity勉強会が評価されたときは、組織の成長を支えている実感が湧いてうれしかった。

振り返ってみると、こういう様々な活動を通して、「ありがとう」と言ってもらえることが自分の原動力だと気づいたんです。

“楽しい”の原点は、「人に喜ばれた」という実感

ゲームをつくるのも好き。だけどそれ以上に、人に喜ばれることが嬉しかったんです。評価されるのはもちろんだけど、「Keiさんのおかげで助かりました」と言ってもらえる瞬間に、自分の価値を感じられる。

いろんなことをやって、自分の強みも見えてきて。自分の行動が誰かに影響を与え、ポジティブな反応として返ってくることにやりがいを感じるし、楽しくて仕方がない。いい意味で、ゲーム業界へのこだわりが薄くなっていき、自分の価値観を大切に、力を発揮できる場所を探してみようと思いました。

業界を越えて活きる場所へ。CG業界で見つけた“自分の意義”

そうして一歩踏み出し、今はCG業界に身を置いています。実はこの業界、エンジニアがすごく少ないんですよね。技術とCG、両方に詳しい人はかなりレアで、社内でもクライアントからも重宝されます。

そんな環境の中で、自分に求められていることと、「楽しい」と感じることがぴったり重なっている。それが今、この業界に感じている“自分の存在意義”なんです。

初めは業界にこだわらず「面白そう」「自分が貢献できそう」と思った場所に飛び込んでみたけれど、結果的にそこが一番しっくりきた。だからこそ、業界や職種よりも「自分がどこで活きるか」を軸に考えてみるのがいいと思います。やるべきことが見えていれば、あとはやるだけ。今はそんなふうに、シンプルに考えています。

10年後なんて見えない。でも“動いたからこそ”わかったこと

学生のころはゲーム開発しか見えてなくて、正直、10年後の自分なんてまったく想像できませんでした。だからこそ、若いうちは深く悩みすぎず、まずは動いてみるのが大切だと思います。

実際に働きながら、少しずつ「モチベーションを軸にキャリアを選ぶ」ことの大切さに気づいていきました。たとえば僕の場合、最初は「ゲームが好き」という理由でプログラミングに興味を持ちました。でも、仕事を通して「チームや業界にポジティブな影響を与えること」が自分にとって大きなやりがいなんだとわかってきて。

キャリアの軸って、経験とともに少しずつ変わっていくものなんですよね。だから、いきなり完璧を目指さず、そのときのベストを選び続けること。迷ったときには、信頼できる人に相談できる環境を持っておくこと。それが、自分らしいキャリアにつながるんじゃないかなと思います。

遠慮なんていらない、TechTrainメンターは頼ってなんぼ

TechTrainのメンターは、技術的に優れているだけでなく、人として魅力的な人が多いんです。だから、遠慮せず頼っていいと思います。「ちょっと、わからなくて…」と聞くと、「しょうがないな〜」と親身になってくれると思います。頼られるのが嫌なメンターはいませんから。

ここで大切なのは誠実さ。たとえばエラーが出たとき、メンターは時間をかけて具体的にアドバイスしてくれます。それを理解せず、我流で進めて同じミスを繰り返すのは、メンターの誠意を無駄にすることになります。逆に、真剣に学びたい姿勢が伝われば、メンターもより「この人のためにもっと応えてあげたい」と思ってくれるはず。

悩んだとき、自分ひとりで抱え込まず、気軽に声をかけてください。僕たちメンターは、技術だけじゃなく、気持ちの面でも支えになりたいと思っています。

インタビューありがとうございました！

学生時代の情熱と、プロの現場で感じたリアル。その中で見えてきた働き続けられる環境の選び方は、これからキャリアを築いていく人にとって、大きなヒントになったのではないでしょうか。

Keiさんが現在取り組んでいる、CG映像業界での挑戦や課題へのアプローチについては、CGWORLDの連載でも詳しく紹介されています。より専門的な視点から、テクニカル系スタッフとしてのやりがいや工夫、未来への展望が語られていますので、ぜひこちらもご覧ください！

CG映像業界のテクニカル系の仕事を探る 第8回・前編：CafeGroupのテクニカル系スタッフの仕事
CG映像業界のテクニカル系の仕事を探る 第8回・後編：CafeGroup テクノロジー・イノベーション部門の取り組みと、今後の展望

Keiさんのように、“自分らしいキャリア”は動く中で見えてくるのかもしれません。まずは一歩をTechTrainで踏み出してみませんか？

TechTrainでは、今回インタビューに答えていただいたKeiさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。

サイドメニューの「面談予約」から、ぜひメンタリングの予約をしてみてください！

2025年5月に『DeepSeek革命』を出版したNaganoRikuさんに、執筆の舞台裏と、AIとどう付き合っていくのが良いかを伺います。

AIは待ってくれない。1ヶ月で書き上げた『DeepSeek革命』

これまでWeb開発やプロダクト設計など幅広く関わってきましたが、最近は生成AIを活用する機会が増えています。ChatGPTは広く知られていますが、「少し触っただけ」という人も多く、DeepSeekの存在を知らない人も少なくありません。実はそれ、意外なチャンスを逃しているかもしれません。だからこそ、最新のAI事情や活用法をわかりやすく伝える必要性を感じました。

そんな中、出版社から声をかけられ、『DeepSeek革命―オープンソースAIが世界を変える』の執筆に挑戦。以前からやりたかったので、迷わず引き受けることに。「今伝えなければ意味がない」という思いから、勢いで一気に書き上げました。1日遅れるとAIの進化に置いていかれる気がして。通常半年の出版スケジュールを大幅短縮し、原稿を1ヶ月で完成。校閲も急ピッチで進め、全体で約1ヶ月半。スピード勝負が一番の苦労でしたね。

壁打ち相手はAI。質も効率も引き上げてくれる相棒に

初めての書籍で「どう構成するか」「どんな表現なら伝わるか」に悩みました。技術的テーマゆえ専門用語や複雑な内容が多く、注釈の配置や章のつながりにも気を使い、技術者視点と一般読者の読みやすさのバランスが難しかったです。そんな時、頼りになったのがAIでした。ChatGPTやDeepSeekに「伝わっているかな？」と不安な時に質問すると、本当に心強い“相棒”になってくれたんです。また、何十ページも検索するより必要な情報をまとめて教えてくれるので、「調べる時間がかかる」という悩みも減りました。

疑問が出たらまずAIに聞く。これだけでも効率はかなり変わりますし、プロンプトを試行錯誤することもすごく大事だと実感しました。 「こう聞けばもっといい答えが返ってくるかも」と探る中で、自分の考えも整理されていく感覚がありました。

本を書いたら世界が変わった。技術発信が生んだ“次の一歩”

書籍を出してから、今まで接点のなかった方と話す機会がぐっと増えました。「DeepSeekってニュースで見かけたけど、何ができるのかわからない」「どう組み込めばいい？」といった相談も増えて、思いがけない広がりを感じています。

もともとモノづくりが好きでしたが、書籍という形で発信することで、これまで届かなかった人たちにも声が届くように。活動の幅が広がると、こんな形で反響があるんだなと実感しています。セミナーや勉強会の参加者も少しずつ増えて、実は今、2冊目の出版も進行中です。発信してみないと何が返ってくるかはわからない。でも、技術記事やブログといったアウトプットが誰かの役に立つこともあるし、「参考になりました」と声をもらえることもあります。社内のSlackでも立派なアウトプットです。

「出して大丈夫かな」と迷う気持ちもありますよね。でも、つまずいたことや工夫したことを残しておくと、それが誰かの参考になるかもしれません。小さな一歩でも、発信することで理解も深まり、技術者としての視野もきっと広がっていきます。

ChatGPTとDeepSeek、どう違う？生成AIの使い分け術

書籍では、ChatGPTとDeepSeekの違いを詳しく解説しています。たとえば、ChatGPTは英語に強く、自然な言い回しや幅広い知識を活かして、バランスの良い回答を返してくれます。一方、DeepSeekは「えっ、そんなことまでわかるの？」と驚くような、日本や中国などのアジア圏の情報に強い場面もあります。

ただしこれはあくまで「いま現在」の印象。AIは日々進化しているので、どちらか一方に決めるのではなく、使いたい目的や場面に応じてうまく使い分けるのがポイントです。

『DeepSeek革命』は全8章を通して、AIをうまく活用するための考え方をわかりやすく紹介しています。第3・4章では特に、ChatGPTとDeepSeekの違いや、AIが直面する「文化や背景の壁」についても触れているので、「生成AIを使いこなしたい」と思っている方にはぴったりの内容です。気になるところから読んでみてください。

ChatGPTとDeepSeek、どう選ぶ？技術的な視点から考える生成AI

AIを料理に例えると、ChatGPTは「おいしい料理だけを出すシェフ」、DeepSeekは「料理とレシピも教えてくれるシェフ」です。DeepSeekは中身（AIモデル）が公開されていて、自分で試したりカスタマイズしたりできるのが特徴。実際、僕も社内チャットボットにセキュリティ要件の兼ね合いで、一部DeepSeekを使ったことがあります。

とはいえ、「結局どっちを選べばいいの？」と思う方も多いはず。そこで、主な違いをパッと見で整理してみました！この違いを知っておくだけでも、ぐっと使い分けやすくなります。

大事なのは、「どっちがすごいか」ではなく、「どんな場面でどちらが合うか」という視点。目的や状況に応じて使い分けることで、AIとの付き合い方もずっと柔軟になります。

まずは触って試す。NaganoRiku流AIの使い倒し方

AIも他の技術と同じで、まずは試してみることが大事です。やってみて悩み、調べる。この繰り返しが使いこなす力になります。

最近は、複数のAIモデルを組み合わせて精度を高める方法にも注目されています。すでにChatGPTを使っているなら、同じプロンプトでDeepSeekなど他のモデルも試してみると、アウトプットの違いが見えて面白いですよ。こうして情報を集めて実際に試しながら、自分なりの判断軸を育てていくことが、これからますます重要になっていくと感じています。

今後は、日本語特有のひらがな・カタカナ・漢字の構造を活かしたAI活用も広がるはずで、「サカナAI」のような日本語に強い生成AIも期待しています。新しいものが出てきたら、まず試す。その経験から、自分なりの判断軸や付き合い方が少しずつ見えてくるかもしれません。

インタビュー、ありがとうございました！AIとの付き合い方に“正解”はありません。でも、「まず試してみる」「誰かと共有してみる」そんな小さな一歩から、見える世界は大きく変わってくるのかもしれません。

この記事が、AIとの関わり方を考えるヒントになれば嬉しいです。詳しく知りたい方は、ぜひ『DeepSeek革命』も手に取ってみてくださいね！

 ▼書籍を読みたくなった方は、以下よりチェック！

TechTrainでは今回インタビューに答えて頂いたNaganoRikuさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

“良いコード”に少しずつ近づくための一歩として、ぜひこの後編も読み進めてみてください。

“良いコード”への気づきを増やす入り口に

『良いコードの道しるべ - 変化に強いソフトウェアを作る原則と実践』は、読んですぐに全部理解しようとする必要はありません。究極、本のイラスト部分だけ読んで「なんとなく雰囲気をつかむ」ぐらいの読み方でも、すごく意味があると思っています。
本の中に登場するイラストは、株式会社MIXIの久野（X：@Kunodayo_oboete）さんにすごく可愛く描いていただいています。

本を読み始める前に簡単なまとめをしているnoteを読んでいただくと、全体像を掴みやすいです。

そして、なによりも大切なのは、本でキーワードや考え方を知っておいて、実際の現場やプロジェクトで「あ、これってあの本に書いてあったやつかも」と気づくこと。本を読み、実際に現場で試す。その上でたまに本を読み返す、というサイクルの繰り返しで、だんだんと“良いコード”が身についていくはずです。

とにかく小さな一歩を踏み出す

実は、この本で“良いコード”を伝えるにあたって、構成にこだわった部分があります。それは、2章から5章までの一連の流れです。なるべく読んでくれる方が自然に理解を深めていけるように意識しています。まずは小さな単位から改善をはじめ、そこから徐々にグルーピングしたり、それぞれの関係性を見て整理していくような流れになるように整理しました。
基本、「なんとなく雰囲気をつかむ」という気軽な気持ちで自由に読んでいただけたらと思いますが、2章「動くコードから意図の伝わるコードへ」から5章「絡まった依存関係を解きほぐせ」までは、ぜひ順番に読んでもらえると嬉しいです。

ただ、各章、前半の1,2は比較的わかりやすく、後半の3,4などに進むにつれて内容が専門的になっていく構成にしています。読み進めて理解がなかなか進まない部分があれば、無理して読み切らずにあとからもう一度戻ってくるぐらいの気持ちで読んでみてください。全体を一周したあと、もう一度戻ることで「あ、これはこういうことだったんだ」と理解が深まることもあると思います。まずは前の方から順に読んでみて、「ちょっと難しいな」と感じるところがあれば、思い切って飛ばしてもOKです。

変更するときこそ“良いコード”への意識が必要

そしてもうひとつこだわったのが、8章「コードは書くより変更が難しい」というパートです。内容自体は他の章と重なる部分もあるんですが、“変更にこそ注意が必要”という視点をしっかり伝えたかったので、あえて独立した章にしたこだわりのポイントです。
ここでは、プロダクト開発の中で実際に起こりがちな、“変更による崩れ”のような問題について掘り下げています。最初にコードを書くときは丁寧に設計するのに、後から機能を追加するときは、ついその場しのぎに。あとで気づいた時には、全体の整合性が崩れてしまっていた...。そんな経験がある人も多いのではないでしょうか？
この章では、そんな一見そのコードの変更自体はうまくできているように見えて、全体で見ると重複や破綻が起きてしまっている、というケースを紹介しています。既存のコードに新しい処理を追加するとき、どこで保守性が損なわれやすいのか？などを、よくあるその場しのぎについて、解決方法をステップバイステップで具体的に解説しています。
現場で「その場しのぎ」に出会った時、この本を思い出してもらえたら嬉しいなと思います。

初心者だけじゃない、レビューをする立場の方へ伝えたいこと

“本書は主に初学者の方に向けて書かれておりますが、ぜひとも中堅以上のエンジニアの方にも手に取ってもらいたいと考えています。
基本的な原則や考え方は常に重要であり、この本を基本を振り返るきっかけにしてもらえると嬉しいです。また、チーム内での情報共有や若手の育成にも役立つと考えています。”
「書籍『良いコードの道しるべ - 変化に強いソフトウェアを作る原則と実践』を出版します」より引用

僕自身も日々感じていますが、コードレビューのときの言語化ってすごく難しいと感じる方もいるんじゃないかなと思っています。
特に、確かに正しく動いてるけど、将来問題になりそうだな…という、先を見据えたレビューなどは、指摘するかどうか悩んだり、上手に伝えようとしてもレビューする手が止まってしまったり、なんてことはありませんか？そういった場面で、本を読んで、言語化の一助として活用してもらうと、現場でのコミュニケーションもしやすくなるのかなと思っています。「この原則に従ってください」というレビューだけではなく、「なぜその原則が有効なのか」を伝えるためのボキャブラリーを持っておくと、先ほどのような場面でもレビューがしやすくなると思います。僕自身、この本を書く中でそういう発見がたくさんありました。そういった背景から、まだ、レビューをする立場の方にも何かのヒントになる一冊になればいいなと思っています。

“良いコード”を書くために必要な観点はまだまだある

今回は、重要な内容に絞って、これから“良いコード”を始めようとする方にも無理なく読んでもらえる構成になるように意識しました。

ただ、コードのメンテナンス性を高め、そのプロダクトの開発を続けるために他の人や将来の自分が読んで正しく理解できるコードにするためには、本では触れていない、コードを書いたあとそれをどうリリースして運用していくかに関わる開発フローや運用面など、DevOps.の観点は欠かせません。たとえば、テストの仕組みを整えたり、CI/CDのような自動化を活用して、コードを書いてからユーザーに届くまでのサイクルをどう短くしていくか。こうした考え方も、実はコードの保守性や変更容易性にとってはすごく大事な要素のひとつです。

僕自身、まだ運用やインフラについては専門分野というほど詳しくはないのですが、この領域も“良いコード”を支える大事な視点だと感じているので、もしかしたら、次の一冊として扱う可能性があるかもしれません。

様々なAIツールの登場によってコードを書くこと自体のハードルは下がっている今。「コードを書く」だけではなくより良いプロダクト、そして今後どんどん大きくなるプロダクトを作るために必要な“良いコード”の視点を意識するようなきっかけになったらなと思います。

TechTrainメディアではこれからも、「テクノロジーを支える、すべての人のターミナルに。」を目指して、実践に根ざしたコンテンツをお届けしていきます。

書籍が気になった方は以下の森さんのnoteからぜひチェックです！

• 「そもそもなぜ良いコード（保守性が高いコード）を書く必要があるのか」保守性に対する目的を理解すること
• 原則や手法を覚えるだけでなく、それぞれの目的や利益を理解して、適切に取捨選択すること

きっとあなたは、この記事を読み終わったとき、“良いコード”についてもっと知りたくなっているはずです。

“良いコード”を始める前に。まずは目的から考える

では、そもそもなぜ良いコード（＝保守性が高いコード）を書く必要があるのでしょうか？まずは、保守性に対する目的を理解するところから始めてみましょう。

コードの読みやすさや、保守のしやすさなど様々なルールや方法がありますが、それ以前に、「なぜ、それを目指すべきなのか？」がはっきりしていないと、どんなに理屈を覚えても実際の現場で活用することはできません。
本の元となっている新卒研修「良いコードとは何か」を話したときにも、「どのようなコードのほうが好ましいのか」とか「設計はこうした方がいい」という技術的な内容より、「どうして高い保守性が必要なのか」に焦点を当てました。それは、「そういう視点があるんだ」と知ってもらうことの方が大事だと思ったからです。
実は、そんな僕にも“良いコード”を意識せず、とにかく動くものを作ることに集中していた時期がありました。

*ここでは本でも明記されているように、簡単に変更できる保守性が高いコードを「良いコード」と定義します。

「動く」けど、なぜかその先がうまくいかない...

高専時代の僕は、とにかく「まず動くものを作る」ことを重視していました。ハッカソンのように短期間でプロダクトを作ってプレゼンする経験を重ねていた僕にとって、まずは形にすることが最優先事項だったんです。面白いものができた手応えはあるのに、いざ、サービスとして育てようとすると急に手が止まってしまう。思うように進まず、楽しかった開発が急につまらなくなって、やめてしまう...そんなことが何度もありました。

そのときは理由がわかりませんでしたが、あとから振り返ってみると、それはコードの構造や書き方に原因があったんだと思います。“良いコード”じゃなかったから、続けられなかったんですよね。そんなふうに、もどかしさを感じながらも原因がわからないまま過ごしていた僕が、“気づく”きっかけを得たのは大学への編入後のことでした。

「なんだか読みづらいコード」から“良いコード”へ

大学へ編入すると、他の高専や大学内部生などバックグラウンドの異なる仲間たちと一緒に開発をする機会に恵まれました。そこで初めて、「森のコードはなんだか読みづらいな...」という言葉をかけられたんです。コードは「動かすためのプログラム」だと思っていた自分にとって、それは全く新しい視点で、衝撃でした。でもその一言が、“良いコード”への入り口になったのです。

そこからは、周りの人に教えてもらったり、読みやすさについて自分でも調べたりしながら、“良いコード”って何だろうという問いが徐々に深まっていきました。可読性、保守性、アーキテクチャやテスト...知れば知るほど、「あのときのあの失敗って、こういうことだったのか」と思うように。

そしてついに、“良いコード”とは、そのプロダクトの開発を続けるために他の人や将来の自分が読んで正しく理解できるコードなのだと気づいたのです。自分があとから触ってもつらくないし、他の誰かに引き継いでも「なるほど」って思ってもらえる。プロダクトの価値を育て続けていくための土台になるような”良いコード”に夢中になっていきました。

開発スピードや品質が上がる？原則やルールは目的・効果を理解すべし

ここからは、原則や手法、それぞれの目的や利益を理解して、適切に取捨選択する準備を進めていきましょう

大事なのは、難しい原則名やルールをただ覚えることではありません。できるだけ、その考え方を噛み砕いて、理解してみてください。もともと、学生時代の僕も原則の名前など難しい単語を覚えることは苦手でした。ただ、「なぜこの設計なのか」「なぜこの命名なのか」を噛み砕き理解することで、活用することができるようになっていったと思います。

もちろん、考え方は複数ありますし、携わるプロダクトや開発環境、事業フェーズなどそのシチュエーションによって「絶対にこれが良い！」と断言できないような部分もあります。だからこそ、本の中では、実際の開発現場で迷ったときに頼りになるような考え方や、順序立てて理解しやすい構成にこだわって、本を書き進めていきました。

僕自身も“良いコード”の考え方や適用する指標を知って、プロダクトの品質も開発スピードも変わったと実感してきました。僕が書いた本が、これから“良いコード”を始める方がその体験をする一助になったらと思います。

感覚を言語化すると“良いコード”はまだまだ極められる

そんな整理を進める中で、僕自身今まで曖昧で感覚で判断していた「依存性逆転の原則」を適用すべき指標が明確になりました。

SOLID原則のひとつDependency Inversion Principle（＝依存性逆転の原則）とは、「具体的な中身に直接依存するのではなく、抽象的なインターフェースに依存するようにする」という設計の方針のことです。このように、あとから中身を取り替えるのがすごくラクになる。これって、ソフトウェアの柔軟性が上がるから、コードが長く使えるようになるよね、という考え方です。

人によってどの場面で適用するかの意見が分かれがちな考え方です。本の中で言語化するにあたって複数人でかなりの議論を重ねました。その結果、「この場合はインターフェースを使った方がいい」「この規模や変更頻度ならむしろ使わなくていい」と細かく指針を整理することになりました。この議論は、僕自身の感覚を言語化する良いきっかけにもなりました。もともと感覚で捉えていた考え方を、言葉にして伝えることで、改めて自分自身が一番学ばせてもらった気がしています。この本は、僕にとっても“良いコード”を言葉で見つけていく旅のひとつでした。

いかがでしたか？

「今までわからなかったことが、ある日ふっとつながる瞬間がある」

森さんがそう語ってくれたように、『良いコードの道しるべ〜』は、きっとみなさんの気づきを引き出してくれるはずです。この記事が、そんな“気づき”のきっかけになれば嬉しいです。

後半の記事では、『良いコードの道しるべ - 変化に強いソフトウェアを作る原則と実践』の読み方や本に込めたメッセージを中心にお伝えしていきます。

書籍が気になった方は以下の森さんのnoteからぜひチェックです！

「作ってから相談」では遅い。プロジェクト成功の鍵は“作る前に話す”

日本の職場で働きはじめて、まず戸惑ったのが“報告・相談のタイミング”でした。

中国にいた頃、少なくとも自分が経験したスタートアップでは、技術系の出身者が多く、自分のタスクは自分で完結させるのが基本でした。そんな環境に慣れていたので、日本で頻繁に進捗を聞かれることには、正直「自分で完結できたのに、なんで？」と、少し効率が悪いと感じてしまって。もしかして、自分のこと信用されてないのかな……と、つい考えてしまうこともありました。そんな戸惑いの中で起きた、ひとつの失敗体験があります。

以前、録音アプリの開発に関わったときのこと。担当のメンバーはとても丁寧で、録音の音質（サンプルレート）やファイル形式など、細かな設定を選べるように作り込んでくれていました。でも、開発が進む中で「そこまで機能が必要なんだっけ？」とふと立ち止まる場面がありました。改めてチームでプロジェクトのゴールを話し合ってみると、このアプリのターゲットはITに詳しくない高齢のユーザー。求められていたのは、「AI分析に使える程度の音質で録音できれば十分」という、シンプルな要件だったんです。つまり本来は、録音ボタンひとつで完結するくらい、誰にでも使いやすい設計にするべきだった。

この経験を通して感じたのは、「何を大事にするか」という共通認識を最初に持つことの大切さです。それが共有できていれば、細かい相談がなくても、メンバーが自然と正しい方向に進めていたはず。報告や相談の頻度を増やすことも大切ですが、それ以上に、判断の基準となる共通認識を整えておくことが、自走できるチームをつくる鍵になると実感しました。そして、チームで開発を進めるには、単にすり合わせるだけでなく、“どう伝えるか”も大きな鍵になります。 

技術とチームをつなぐ“伝える力”が強い武器に

技術的なやりとりの中で感じるのは、「伝えること」と「伝わること」はまったく別だということです。以前、クライアントに挙動の説明をしたら沈黙の時間が長く続いてしまったこともあったんですよね。自分の中では当たり前になっている言葉も、相手がそれを知らなければただの専門用語。だからこそ、話す前にまず「この人はどんな立場で、どれくらいの知識を持っている人だろう？」と想像するようになりました。

たとえば、iOSチームとして働いているときに、バックエンドのエンジニアと話すとき。同じエンジニアでもベースの知識やいつも触れている技術が異なるためいきなりコードの話をするのではなく、iOSの基本的な仕様や動きから説明して、どうしてこの実装にしたのかを順序立てて伝えるようにします。ビジネスサイドの人と話すときは、仕様の背景やユーザー体験をベースに話を組み立てていきます。「なぜこの技術を選んだのか」「そのメリットとデメリットは何か」を、なるべく噛み砕いて伝えることを心がけています。相手に合わせて伝え方を変える。それだけで、チーム全体の理解や判断スピードはぐっと上がると実感しています。

そうして個々の対話を丁寧に重ねるうちに、チーム全体としてどんな方向を目指すべきかという視点のもと、“チーム全体の認識を揃える”役割を担うようになっていきました。

意見が分かれたとき、決断の軸は“対話”にある

チームでの共通認識を持つことは決して簡単ではありません。特に、リーダーになってからは、「どこまで話し合い、どこで決めるか」という見極めに悩むことも増えました。
たとえば、私が3人のチームのリーダーをしていたときのことです。パフォーマンスを重視するAさんはある技術を推し、スピード重視のBさんは別の技術を勧め、そして私も第三の案を考えていました。誰かの提案を採用すれば、他の誰かを否定するようで、最終的にどの意見を選ぶべきかを判断するのに非常に悩みました。

この時、まず最初に話し合ったのは、プロジェクトのゴールを明確にすること。何を最優先するのかを共通認識として持つことで、チームに共通の土台ができあがります。そして、各メンバーがなぜその技術を選んだのか、その背後にある価値観（重視しているポイント）を丁寧に共有しました。

最終的には、「限られた期間内で、どの選択肢が最も現実的にゴールに近づけるか」という観点から、チーム全員で意思決定を行いました。重要だったのは、メンバー全員の共通認識を定義するための対話。こうした“対話のプロセス”を積み重ねることで、チームの判断力も育ちます。リーダーとしては、答えを出すことだけが役割ではなく、皆が納得して進める状況をどう整えるかも大切な責任だと実感した経験でした。

信頼され、“任せたくなる”人を目指す

ここまでにコミュニケーションや対話の話をしてきましたが、一貫して大切にしているのは「また一緒に仕事がしたい」と思ってもらえる存在でいることです。

アプリやプロダクトの開発は、私にとって「ものづくり」そのもの。うまくいかないことも、悩んでしまうこともありますが、それでも手を動かして、少しでもよいものを目指し続ける。それこそが私が夢中になれる瞬間です。だからこそ、“つくること”に情熱を持つ人と、共に成長していけたらと思っています。その理由は、自然と前向きな議論が生まれるし、ただ形にするだけじゃなく、使いやすさや美しさ、そして長く愛されるプロダクトを一緒に作り上げることができるから。

もちろん、チームに貢献するためには、技術力や実装力を磨くことも欠かせません。レビュー対応などで技術的な信頼を積み重ね、みんなで同じゴールを目指して進んでいけるように、日々の学びや努力を大切にしています。

“対等に話せる力”は、技術の裏打ちから生まれる

技術力がすべてではないものの、まずはチームメンバーと対等に意見を交わせるレベルの技術力を身につけることも大切です。技術を理解することは、対話に説得力を生み、プロジェクトの推進力にもつながります。

TechTrainでメンターをやっていて感じるのは、課題のコードが書けても、その理由が説明できない人が多いということ。でもそれこそが、成長のチャンス！常に探求心を持ち、実際に技術がどう動いているのか、背後にある仕組みにも目を向けてみてください。たとえば初心者の方には、「私はSwiftを勉強したい」と言語ありきで学ぼうとする人が多いのですが、それは少しもったいないと感じます。大事なのは、言語の文法そのものではなく、その言語を通してソースコードの裏で何が起きているのかを観察すること。たとえば、値を代入するとき、裏ではどういう処理が走っているのか？メモリはどう管理されているのか？設計思想はどこに現れているのか？そうした“書き方以外の部分”にも意識を向けてほしいんです。そうすれば、新しい言語を学ぶ必要が出てきても、過去に学んだ知識と照らし合わせながら「なんとなく分かる」「なんとか書ける」と感じられるようになります。

そして、課題を解決したあとは、その背景や解決策を他の人が見ても理解できるようにドキュメントとして残すことをおすすめします。解決までの流れや、コードの根底にある仕組みを言語化することで、技術の理解がぐっと深まります。これは、プロダクト開発で求められる対応力を養うための効果的な勉強法です。

そして、この「技術を理解する力」は、自分の成長だけでなく、チームにとって大きな武器になります。技術に裏打ちされた対話は説得力が増し、プロジェクトを前進させる起爆剤になります。だから私はこれからも、技術への探究を続けていきます。

ひとりじゃない。学びも楽しさも、“つながり”から深まる

プログラミングやプロダクト開発って、「ひとりで黙々と進めるもの」というイメージを持たれがちかもしれません。でも実際は、チームで開発を進めていくことがほとんど。なので、TechTrainのような場を活用して、メンターや仲間の力を借りて成長していくのが一番だと思います。「これをつくりたい」という思いがあれば、学ぶことも苦じゃなくなりますし、完成までのプロセスもきっと楽しめるはずです。
私は誰かの成長をサポートすることにやりがいを感じています。もし学習で行き詰まったり、チーム開発で悩んだりしたときは、ぜひ気軽に相談にきてください。一緒にものづくりの楽しさや技術の奥深さを、思いっきり楽しみながら学びましょう！

Ouさん、インタビューありがとうございました。

「チームの一員としてどう振る舞うか」を、時間をかけて丁寧に言語化してきた姿勢が印象的でした。文化の違いに戸惑いながらも、報連相のタイミングや伝え方に悩み、実践を重ねてきたからこそ、「また一緒に仕事がしたいと思ってもらえるように」という言葉には重みがありますね。

TechTrainでは今回インタビューに答えて頂いたOuさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

「エンジニアって面白いかも」―カナダの大学でものづくりに出会う

海外の大学へ進学したいと考えて調べる中で、カナダはコンピュータサイエンスの教育に力を入れていることを知りました。「せっかくならレベルの高い環境で成長したい」と思い、本格的にパソコンを使ったことはなかったのですが、ブリティッシュコロンビア大学のコンピュータサイエンス学部へ進学しました。

大学ではコンピュータの基礎を学びつつ、Webアプリのチーム開発など実践的な課題にも多く取り組みました。それまでは”使う側”だった自分が、”作る側”としてプロダクトを形にしてくのがすごく楽しくて。フィードバックをもらったり、ちゃんと形になったときの達成感が大きく、「エンジニアっておもしろいかも」と思うように。ものづくりの原体験が、今の原動力になっています。

卒業後の進路では、カナダと日本どちらで働くか悩みました。両国でバックエンド開発のインターンを経験し、最終的には日本での就職を決意。大学を6月に卒業し、2月頃から本格的に選考を受け始め、3月にサイボウズ株式会社から内定をもらいました。

入社は10月。配属先が未定だったので、どの部署に行っても活きる力をつけておこうと思い、入社前の準備に取りかかりました。

入社前にやってよかった！土台になる力を鍛える

「入社後すぐに力を発揮したい」と思っていた私が、入社前にやってよかったと思うことが2つあります。

まずひとつ目は、コンピュータサイエンスの基礎を押さえておくこと。OSやネットワーク、メモリといった仕組みを理解していると、コードを読んだときの理解度がまったく違ってきます。表面的な動きだけじゃなく内部構造から理解できるようになり、実装の引き出しも増えました。大学で学んでいた内容を、入社前に整理し直しておいたことが、業務の立ち上がりを早くした実感があります。

もうひとつは、物事を要素に分解して考えるクセをつけること。この思考は、エラー対応や業務改善の場面で本当に役立ちます。「どこまでがうまくいっていて、どこからうまくいってないのか」を切り分けられると、解決までの道筋が見えてくるんです。一見すると複雑に見える問題も、小さな要素に分解していくと、次にやるべきことが明確になってきます。私の場合は、学生時代のインターンや部活でうまくいかなかったことを「なぜダメだった？どうすればよかった？」と振り返る思考習慣が、今も大きな支えになっています。難しいことではなくて、たとえば日常生活で「この作業、なんで時間かかるんだろう？」と考えるだけでも効果的です。そうした“分解力”は、どんなチームでも重宝されるスキルだと思います。

この2つがあれば万全というわけではないですが、なかったらもっと苦労していただろうと思います。「本当にやっていけるのかな？」という不安は常にありましたし、どんなに準備をしても入社後に覚えることもたくさんあるだろうと思っていたので、自分にできる準備はやっておきたいという思いでした。

技術も知識も追いつかない中で直面した、入社1年目のリアル

配属されたのは、10年以上運用されている製品を手がける開発チームでした。そこで任されたのは、まさかのフロントエンドのリアーキテクチャ。学生時代はバックエンド中心に学んでいたので、フロントエンド技術には軽く触れたことがあるくらいでしたが、むしろ未経験だからこそ、前向きに挑戦してみたいという思いもありました。ただ、対象となるのは、古い技術と新しい技術が絡み合ったコードベース。複数のフレームワークに関する知識が求められ、最初はめちゃくちゃ焦ったのを覚えています。
さらに大きな壁になったのが、製品固有のドメイン知識です。入社して最初のころは、ドメイン知識が足りなくてエラーの原因特定に時間がかかったりすることがよくありました。「これで大丈夫かな」と漠然とした不安を抱えながら取り組んでいたように思います。とはいえ、自分にできるのは地道に向き合うことだけ。まずは理解するところからと決めて、ひとつずつ取り組みました。

未経験技術にどう立ち向かう？技術キャッチアップの型とは

最初に取り組んだのは、技術の全体像をつかむことでした。まずは公式ドキュメントを読み込みながら、「ちゃんと理解できているかな？」と自分に問いかけつつ、小さなアプリを作ってみることも。ただ使い方を学ぶだけでなく、「なぜこう設計されているのか」「どんな場面で使うのか」といった背景まで理解することを意識していました。コードの裏にある思想や文脈まで含めて理解しようとすると、時間はかかるけれど、応用が効く力になると感じています。
他にも、社内の技術資料に目を通して、内部設計やコードがどうなっているのかを確認したり、必要な情報源にアクセスして、ひとつひとつ丁寧に理解していくことも心がけていました。そうやって時間をかけてでもちゃんと向き合う姿勢が、私なりのキャッチアップの仕方だったと思います。

「プロダクトを使い倒す」「質問する力」で成長が加速

ドメイン知識不足を解決するために意識していたのが、プロダクトを隅々まで触ってみることでした。ユーザーとして実際に製品を使ってみると、「あ、こういうことだったのか」とそれまで断片的だった知識が、少しずつ繋がって見えるようになる感覚がありました。
加えて、社内の詳しい人にどんどん相談するようにしていました。というのも、質問するハードルが低い人ほど、早く成果を出している印象があったんです。わからないことをすぐに解消できるから、次の課題や挑戦に早く進めるんですよね。私も最初は「自分で全部調べなきゃ」と思いがちだったんですが、思い切って他部署の方に質問してみたら、一瞬で解決したことがあって（笑）。それ以来、質問できるネットワークを築くことの大切さを実感しています。

入社1年目で一番大事だと感じたのは、とにかく「プロダクト」「情報」「人」との接点を増やすこと。プロダクトに触れて、ドキュメントを読んで、人と話してみる。その行動だけで、成長がぐっと加速する気がしました。成果を早く出したいのであれば、まずはプロダクトを使い、そしてどんどん質問をしていくことから始めてみるのが一番の近道だと思います。

「問い」から始まる、自分らしい仕事のつくり方

仕事を進めるうえでずっと意識しているのは、「与えられた仕事をただこなすのではなく、自分なりの問いを持つこと」です。まさに、前述の分解力が活かされてきます。たとえば、ある機能を実装するときも、「なぜこの方法が選ばれているのか」「もっと良いやり方はないかな？」と考えるようにしていました。その問いがあるだけで、学びの深さが全然違ってくるんですよね。「小さなことかも…？」と思ってもまずは行動に移す。仮にその場で採用されなくても、その思考や試行錯誤が、後から必ず活きてくると感じています。そして行動のあとには、自分で振り返ったり、周囲に意見をもらったりして、そのフィードバックを次に活かす。このサイクルを大切にしています。それから、チームとのコミュニケーションでも同じです。自分だけで抱え込まずに、気づいたことを共有する。その小さな行動で、周りが「じゃあこうしてみようか」と反応してくれて、チームがちょっとずつ前に進む感覚があります。

とはいえ、すべてを完璧にやろうとすると、どれも中途半端になってしまう。だからこそ、いま本当に優先すべきことは何かを見極める意識も大切にしています。特に、新しいチームに入ったばかりの時は迷いも多いですが、そういう時こそ相談するのが一番の近道。 遠回りに見えても、結果的に一番スムーズに進めることが多いと感じています。

これからプログラミングを学ぶ人へ。まずは“分からない”を楽しもう

プログラミングを学び始めたばかりの頃って、「何が分からないのかすら、分からない」という状態になりがちですよね。私も大学で初めてコードに触れたときは、エラーの原因も分からず何時間も悩んだことも。その時に感じた大変さを今も覚えているので、これから学ぶ人ができるだけスムーズに進めるよう、難しいことこそシンプルに伝える姿勢を大切にしています。

プログラミングの学習は、つい効率を求めすぎて慎重になってしまうこともあるかもしれません。でも、学びの中で大事なのは、失敗を恐れず、まずはやってみること。たとえ上手くいかなくても、「やってみた」という経験が、必ず次につながります。最初は誰でも初心者です。焦らず、自分のペースで、一歩ずつ。一緒に挑戦して、一緒に成長していきましょう。

Kenさん、インタビューありがとうございました！

海外の大学に進学し、未経験の領域にも挑みながら、試行錯誤を重ねてきたKenさんの姿から、「まず一歩踏み出すこと」の大切さを感じた方も多いのではないでしょうか。目の前の“小さな違和感”に目を向けることが、次の成長へのヒントになるかもしれません。

TechTrainでは今回インタビューに答えて頂いたKenさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

“夢中になれること”を見極めて、デザインの道へ

大学では情報系を専攻しつつ、趣味でゲーム制作に熱中していました。「将来はエンジニアかな」となんとなく思っていたんですが、いざコードを書いてみたら、なぜか眠くなって、集中できない。最初は慣れてないからかなと思って続けてみたものの、どうにも改善せず、「これは仕事にするのはまずいかもしれない」と不安になりました。
一方で、ゲームのUIや画面づくりをしている時間は、気づけば何時間でも没頭できたし、自然と学習も続けられたんです。「これはもう、向き・不向きの問題なんだ」と感じ、“ものづくり”のなかでも自分が夢中になれる道を選びました。

「UIだけみていてはダメ」失敗から始まった視点の転換

新卒でサイバーエージェントに入社し、ゲームUIの改善を目的とした新機能開発のプロジェクトに配属されました。リードデザイナーを任され、「自分にできるだろうか」と不安を抱えながらも必死に取り組んでいました。しかし、結果的に思わぬトラブルが発生してしまいます。そのプロジェクトはゲームユーザーを増やすためのキャンペーン施策だったのですが、仕様検討が不十分なままリリースした結果、ポイントの不正取得を許す形となり、ユーザーからは「意味がわからない」や「運営は何をしているんだ」といった厳しい声が寄せられました。この不備は社内にも波紋を広げ、「UIだけを見ていてはダメだ」と痛感する出来事となりました。当時の自分は、UI部分のデザインだけに意識が向いていて、プロジェクトの背景や施策の意図を深く理解せずに進めてしまっていたのです。この失敗を通じて、プロジェクト全体の文脈や意図を理解し、ユーザー目線で提案や改善を行う重要性を学びました。今でも、自戒を込めて当時のユーザーレビューを読み返しています。初心を思い出す大切な原点です。

“なんか違う...”違和感の正体は、ユーザーの解像度

UIだけでなく、もっとユーザー全体を深く理解する必要がある。そう痛感してから数年後、その視点を意識して取り組む機会が訪れました。
それは、ABEMAのサッカージャンルのUI設計の業務でした。自分では「うまく整理できた」と思い、社内のサッカーファンに画面イメージを見せたら、「なんか違う」という反応が返ってきたのです。試合の種類やカテゴリ別に分けて表示すれば、わかりやすいだろうと考えていたのですが、実際に寄せられた声は「三笘が観たい」「選手ではなくチームで追ってる」といった予想外に多様な反応でした。自分自身がサッカーを視聴するユーザーの属性の理解ができていなかったこともあり、全ての声に耳を傾けすぎて、方向性が何度も変わることも。
「サッカーが好きな人」という大きなくくりではなく、実際には、サッカーというコンテンツを楽しみたい人、国内サッカー派、海外サッカー派、特定の選手を応援する人、チーム単位で追う人など、それぞれに異なる関心軸があったのです。このように属性の解像度をどこまで上げられるかが、デザインの成否を左右するのだと強く実感しました。
こうした経験を通じて私がたどり着いたのは、「ユーザーがどう受け取り、どう感じ、どう動くか」までを含めて、デザインの責任だということ。作って終わりではなく、それがどのように使われ、どんな感情や行動につながるかまで見届ける。それこそが、デザイナーとしての“届ける力”の本質なのだと思うようになりました。。それ以来、デザインの意図を言語化できるほどまでユーザー理解を深めてからでないと、プロダクトの方向性は決めちゃいけないと思うようになったのです。

勘に頼らない。仮説が導く確かなUI設計

ユーザーがどう受け取るかまでを見届ける。そこに責任を持とうとするほどに、事前にしっかり仮説を立てて設計に臨む必要性を感じるようになりました。
現在関わっている不動産SaaSのプロダクトでは、現場の業務を丁寧に観察するところから始めています。たとえば、スケジュール調整や移動の無駄など、アナログで複雑な業務を観察すると、“現場で本当に困っている問題”が浮かび上がってきます。直接ヒアリングしてみると、「この作業が面倒で困る」「チームの誰かが気づかないと滞る」といった声があったり、マネージャー層からは「もっと効率よく働けるはずなんだけど…」といった構造化されていない悩みも浮かんできました。そのひとつひとつ丁寧に耳を傾け、業務フローをプロダクト設計に反映していきます。
ユーザーやマーケットを調べ切ると、細かな仮説が積み上がり「これしかない」と思える状態のプロトタイプを作れるようになります。そうすれば、ユーザーからのフィードバックも仮説を確かめる材料として扱え、的確な判断につなげることができるのです。結果として、無駄なやり直しも減り、自信を持ってデザインを進められるようになりました。今後はデザインマネージャーとして、このユーザー理解をさらに広げ、チーム全体でデザイナーがプロダクトや会社に大きな影響を与える体制を作り上げることが次の目標です。

事業を動かすデザインへ。マネージャーとして組織づくりから挑む

組織体制を整えることは、デザイナーが事業に深く関わるための土台づくりでもあります。UIを作るだけでなく、プロダクトの上流工程から携わり、その価値を最大化できる環境づくりこそが、いまデザインマネージャーとして実現したいことです。例えば、もともとアナログ管理が中心だった業界に対し、プロダクトを通じてデジタル化やツール導入の必要性を日々伝えています。ただし、初めから高機能すぎるものを提案すれば、現場に抵抗感が生まれる場合もあるため、受け入れやすいバランスを見極める必要があります。プロダクトに対して経営視点を持ち、組織に影響を与えられる状態が理想です。だからこそ、チーム内外の合意形成にも注力し、デザイナーの枠を超えた貢献を目指しています。デザイナーがもっと大きな影響を与えられるように。そんな環境を整えていくことが、挑戦中のテーマです。

つくる楽しさに出会えるきっかけを、メンターとして届けたい

社内でのデザイナー育成にも力を入れていますが、それだけにとどまらず、会社の枠を超えて「ものづくりをする人」を増やしたいという思いが根本にあります。ものづくりが好きという気持ちに加えて、自分の存在が誰かの人生にポジティブな影響を与えられるなら、それはとても嬉しいこと。自分自身も、これまで多くの人に支えられ、さまざまな経験を積んできたおかげで、視点が広がり、成長してきました。ゲームやメディアに携わってきたのも、突き詰めると「誰かの人生をより豊かにしたい」という想いがあったからです。

TechTrainのメンターになったのも、最高のUIデザインをアウトプットするための考え方や準備のプロセスを伝え、若いデザイナーが自信を持ってデザインに向き合えるよう支援したいという想いが原点です。ときには、自分のやり方を実際に見てもらいながら、学びのきっかけを届けられたらと思っています。

UIデザインにセンスはいらない。必要なのは学び続ける姿勢

「UIデザインにはセンスが必要」だと思っていませんか？実は、UIデザインは学習することでスキルアップできる、再現性の高い分野です。

レイアウトや配色、UIの使いやすさなどには、すでに多くの知見や原則が整理されています。たとえば、Appleが公開している「Human Interface Guidelines」は、プロの現場でも活用されているベストプラクティスの宝庫です。実際、業務の中で迷ったときは、何度もこのガイドラインに立ち返ってきました。
もちろん、インプットだけでは不十分です。自分で手を動かして何かを作り、誰かに見てもらうというアウトプットのプロセスも欠かせません。そして、フィードバックを受け「どうすればもっと使いやすくなるか？」を考える。その繰り返しが、改善の一歩を踏み出す鍵になります。失敗を恐れず、挑戦し学び続けましょう。みなさんが、どんな壁にも立ち向かえるUIデザイナーになれるよう、私なりの経験を元に全力でサポートしたいと思っています！

Yuseiさん、インタビューありがとうございました！
「誰の、どんな視点を知るべきか？」という問いから、デザインの可能性は大きく広がっていきます。迷ったときは、まず手を動かしてみること。そして、ひとりで抱え込まず、信頼できる誰かと話してみること。きっと、その最初の一歩に、Yuseiさんの言葉がヒントをくれるはずです。

TechTrainでは今回インタビューに答えて頂いたYuseiさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

ご経歴を教えてください

もともと文系だった私がVRに出会ったのは、大学で映像学部に入学したことがきっかけでした。と言っても、最初からVRに興味があったわけではなく、法学部や文学部などの一般的な文系学部に興味が持てず、大好きな映画を撮ることで学士がもらえるという点がとても魅力的だったということで選んだのですが...。入学後はしばらく映画を撮っていたのですが、3年生の時に受講したVRの授業がとても面白く、VRの研究室に入ることを決めました。その研究内容が、フランスの「Laval Virtual」というVR/AR/XRをテーマとした国際的フェスティバルに採択され、そこでVR産業の大きさを肌で感じ、全世界で爆発する可能性のある産業だ！と確信したことで、卒業後VRの道に進むことになります。新卒で入社した会社は、リアルタイム3Dソフトを開発する会社。ここでVRエンジニアのスタートを切りました。在籍した7年間で多くのVRプロジェクトを経験することができた一方で、同時に不安も募っていきました。VR業界は、自社の技術を外に出さない文化が根強く閉鎖的な部分があり、この会社でしか活躍できない人材になっていないか？と感じるようになっていったのです。次第に、もっとオープンな業界で働きたいと思うようになり、勉強会やカンファレンスなど知見を広く共有し合う文化を持つWeb業界へ転向することを決めました。余談ですが、当時宮崎に配属され、初めて入った居酒屋で仲良くなる人がいるなど人の良さに完全に魅了され、このまま九州で生活していきたいなという強い思いもあり、九州に拠点のあるWeb企業を軸に転職活動を進めました。最終的に、その中でもレベルの高いエンジニアが多く在籍している株式会社Fusicに入社。主力事業であるAWS構築、コンサルティング案件に携わり、3年ほど前から地域通貨アプリ（地域限定クーポン）のプロジェクトマネージャーとして全体を見る仕事をしながら手も動かして開発もしています。

VRエンジニアからWebエンジニアへの転換は、苦労しましたか

プログラミングをするということ自体は同じですが、扱う技術や考え方が全く異なっていたので、ゼロから学び直すことが大変でした。入社して2〜3年は1日6時間ほど勉強をしていました。資格の勉強は明確なゴール（＝終わり）がありますし、Web未経験の自分が人一倍やらないと置いていかれてしまう危機感も相まってモチベーションが下がることはありませんでした。AWSの資格を全て取得して改めて感じたのは、知識を体系的に学ぶことで頭の中にマッピングされるので、実務で構築する時の調べ時間が大幅に短縮されるメリットがあるなと。その一方で、資格の勉強だけでは実務ができるようにはならないので、どんな勉強でも同じだと思いますがインプットとアウトプットは並行していくのが大事だなと感じます。

Web業界に入ってみて、文化の違いを感じられましたか

憧れていたWeb業界のオープンな文化は、期待通りでした。所属企業を問わず業界全体に開かれたイベントの開催が多くあり、参加すればするほど刺激を受けることができました。特にFusicの特徴でもあるのですが、勉強熱心なエンジニアが集まっていて、一緒にいると自然と勉強会やイベントへ参加する機会に恵まれ、理想の環境に身を置いていることを実感します。参加だけではなく、登壇もしており、今までにAWS関連やPHPのカンファレンス、勉強会などを含めて10回ほど登壇してきました。もともと人前で話すのはかなり苦手でしたが、登壇者としての学びもあり、四半期に一度は登壇しようと考えて頑張っています。

登壇に苦手意識があるのですね！どのように向き合っていますか

準備をしっかりすれば、不安が軽減されることに気づいてきました。目安としては約15時間くらい準備に時間を充てています。最近意識している事は、「この日までにスライドを作ろう」と決めるのではなく、「この日からスライドを作り始めよう」という着手開始の日をスケジュールすること。完成目安日のだいたい2週間前に設定しています。スタート日さえ決めていれば、それから1日1〜2時間ペースで作っていけば確実に作り切ることができるんです。

また、自分の言葉ではなくなってしまう気がするので、当日は原稿を読まないことを意識しています。一度、原稿を一行飛ばしてパニックになってしまった経験があり、今は原稿ではなく伝えたい要所をメモ書きにしておき、その場の言葉で伝えるようにしています。

また、登壇してみて感じた一番のメリットは、主役としてイベントに参加できるということです。聞く側として参加することもメリットがあると思いますが、登壇することで一参加者ではなくそのイベントでちょっと認知度のある人になり、懇親会の場で話しかけてもらえる機会が増えます。また、自分が話しかけたときにも、「あの登壇してた人ですね」とすぐに距離が縮まり、その後も繋がりを継続することができ、参加者として参加している時よりもコミュニケーションを取る機会が増えたと感じます。苦手だった”人前で話す”ことを乗り越え、多くの人との繋がりを通してより深い学びができますし、カンファレンスに参加することが今まで以上に楽しいと感じるようになりました。

今後のビジョンを教えてください

短期的な目標として、現在携わっている地域通貨アプリプロジェクトに注力して、プロジェクトのリーダーとしてエンジニアはもちろん、プロジェクトに関わるメンバーの力を最大限発揮できる環境作りをすることで事業成長に貢献していきたいです。

また、長期的には「自分で仕事を生み出すことができるエンジニア」になりたいと思っています。改めて自分のやりたいことを考えた時に、利益を追求するのではなく、社会問題を解決するようなソーシャルビジネスに興味を持つようになりました。これからの大きな目標を実現するためには、マネタイズする方法や、資金調達の術なども含めビジネス全般の知識も必要になってきます。ありがたいことに、いろんな業界の方と接点を持つ機会が多い環境にいるため、現在の案件はもちろん、Fusicでの仕事をすることでビジネス力をつけるための学びが多いなと感じています。まだ具体的に決めているわけではないですが、長期的にはお金の流れが鈍化している一次産業、特に林業や環境に関する事業で自ら仕事を作り出せる人になれたらと考えています。

ここまで読んでくれた方へ一言

私が転職したときは、TechTrainのような技術を体系的に学べる環境はありませんでしたが、今や教材として学習環境が整備され、しかも年々良くなってきていると感じています。なので、この環境を活かして諦めずに学習を進めてもらいたいなと思います。また、学ぶ上で、質を上げるためには、やっぱり量をこなすことが大前提。多くのコードと接し、たくさんコードを書いていってください。そうすれば、きっと今活躍しているエンジニアを超えていくことができると思います。実際、エンジニアとして働く中で、若い人の方が優秀だなと思うことが多々あります。

また、ぜひ登壇することにもチャレンジして、登壇の楽しさを味わってください。「みんな知っている内容だから、発表する意義がないかも」と思う必要はありません。たとえ知っている内容だとしても、聞き手にとっていい復習する機会になりますし、エンジニアあるあるなどは共感することができるので、わたしは聞いていてとても楽しいです。自分の発表内容にハードルを設ける必要はなく、むしろ発表することに価値があると思います。AWSやバックエンド技術の相談に加え、登壇についての相談も大歓迎です。気軽にお話ししましょう！

インタビューありがとうございました。VRエンジニアからWebエンジニアへの転換に苦労されたMasakiさん。ゼロからの学び直しが大変だったということですが、これから新しい技術を学ぼうとする方にとってどのように向き合っていくべきかヒントがあったのではないでしょうか。

TechTrainでは今回インタビューに答えて頂いたMasakiさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

デザインとエンジニアリングを両立することになった背景は

デザインでキャリアをスタートし、エンジニアリングも両立する一番のきっかけは、「広くものづくりがしたいし、ゆくゆくはプロダクトを自分で作りたい」という想いです。小さい頃からものづくりが大好きで、絵を描いたり、音楽を作ったり、プログラミングをしたり。ものづくりに関する興味のあるものをちょっとずつ齧って育ってきました。大学受験を迎えたとき、ものづくりができる進路を志望し、理工学部電子情報学科を選択したのですが、想像とは違う環境に、悶々とする日々を過ごしていました。そんな中コロナが訪れ、環境を変えたいと奮起した矢先、友人からアメリカの美大ならチャンスがあると聞き、デザインを本格的に学ぶ環境に飛び込むことになりました。やむを得ない事情があり、卒業まで通うことは叶いませんでしたが、授業の中でデザインに向き合い「なぜこのデザインにしたのか」「なんでこの配色？配置？」などデザインの意図を突き詰めた経験が、デザインを軸にものづくりを仕事にしようと思える自信につながりました。

また、独学でエンジニアリングにも触れていて、デザインもエンジニアリングもどちらも経験したいと伝えて入社したこともあり、入社してから2年半でゆめみ内でデザイン1本から、デザイン兼webフロントエンド、デザイン兼Androidエンジニアというキャリアを歩んできました。

お仕事内容について教えてください

現在は、UI/UXデザインを主軸としながら、Android開発にも携わっています。もともとAndroid自体は未経験だったのですが、ずっとモバイルアプリには挑戦したいと思っており、業務と並行して勉強を始めようと思っていた時、社内のAndroidエンジニアが、Google公式の「Android Developers Courses」を使って基礎を教えてくれると声をかけてくれました。そのおかげもあり、基礎を2ヶ月で吸収し、そのあとも業務と並行しながら独学でブラッシュアップをしてきました。そのことがきっかけで、もともと担当していたフロントエンド開発のプロジェクトからAndroid開発のプロジェクトへ移行し、現在はtoC向けのAndroidアプリのプロジェクトでデザインと開発を両方やっています。今はまだまだ主軸はデザインですが、これからも開発に関する知識も広げながら、事業、エンジニア、デザイナー、プロダクトを使うユーザーそれぞれにとって素敵なプロダクトを導けるようなPdMを目指したいなと思って日々奮闘している最中です。

両立のメリットと苦労を教えてください

メリットは2つで、デザインがベースにあるため、仕様を細かく理解してサービスに一貫性を持たせて開発ができることと、デザイナーとエンジニアのコミュニケーションギャップを埋める役割ができること。例えば、ユーザーが触れた時の画面サイズの動き方をエンジニアは具体的にイメージして作りますが、デザイナーは静止画で把握するために考慮できていないことがあります。双方の認識を確認した上でインタラクションの提案をしたり、UIデザイン知識のないエンジニアがデザインの専門用語の解釈に齟齬があることに気づき修正したこともありました。デザイナーとエンジニアの両方を経験して橋渡しのような役割を果たせて、チームや会社に貢献することができたときは、特にやりがいを感じますね。

ただ、もともとデザイナーからスタートしたので、初めてエンジニアの実務に入った時は周りが当たり前にできることができずに苦労しました。例えば、もともとエンジニアの人であれば、Gitの使い方やプログラムの良し悪し、チーム開発のお作法を知っている状態でしたが、私だけ何も知らない状態だったことは心理的な負担が大きかったなと思います。もし未経験でエンジニアを目指す方は、TechTrainのような学習支援サービスを活用して、エンジニアの基礎を習得してから実務に入ることをおすすめします。私の場合は、幸いなことに、周囲の人が「最初からできる人はいないし」と丁寧に接してくれたことで今までなんとか業務を進められています。

従来の枠組みにとらわれない選択をされていますが、キャリアパスはどのように考えていますか

キャリアの話をすると、良くも悪くも、わたしが何やっていて何がしたいのか疑問を抱かれることがよくあります。デザインとエンジニアリングの2軸を持つ人は社内にもまだあまり多くないので、キャリアについて壁打ちをする時もどっち？となりがちです。会社が用意してくれているキャリアパスに乗れていないと感じる一方で、そんな自分を受け入れてサポートしてくれる環境に感謝しています。自分自身は、今後キャリアを築いていくにあたり、ものづくりに関するできることを広げていきたいというモチベーションがあるので、どちらかに絞る必要がないのではと考えています。今はデザインスキルをベースにしていますが、その場その場で目指す先が変わっていくと思います。より良いものづくりをするために、幅を広げていきたいという自分の気持ちを大切にしながら、エンジニアのスキルを高めていったり、マネジメントの経験を積むことで、ユーザーの気持ちに寄り添ってプロダクトの成長を支えられる人を目指していけたらと思います。

ここまで読んでくれた方に一言

私は、音楽、イラスト、アニメーションなどいろんなことに興味を持ち、広い意味でのものつくりを経験してきましたが、中途半端に終わることが多く、もどかしさや専門性を持つ人を羨ましく思っていました。ただ、その時にうまくいかなくても結果的に後から知識として役立つこともありました。また、たとえ「デザインは向いてないかも」と思ったとしても、インフラやバックエンドなど、別の領域でしっくりくることもあるかもしれません。なので、皆さんも、視界に入った興味をやってみるといいのではと思います！

私も、最終形はまだまだ模索中ですが、今まで経験したことを融合した何かを作れたら最高だな！と、考えて日々色々な経験を積んでいます。困ったり悩んだ時は、いつでも気軽に相談しに来てくださいね！

インタビューありがとうございました。専門性を深めることと、領域を広げることの両方の大切さが伝わってきました。また、Kanonさんの「興味を持ったことは、無駄にならない」というメッセージでは、自分の気持ちに素直に従うことで、遠回りに見える選択だとしても将来のプラスになるのだと励まされますね。技術の質問はもちろん、職種転換や複数技術の習得を目指したいなどキャリアに迷ったときは、Kanonさんに相談してみてください。

TechTrainでは今回インタビューに答えて頂いたKanonさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

世の中には、たとえばモバイルアプリ開発者であれば Android や iOS 向けのアプリを個人的に開発してストアに公開したり、Web開発者であれば Web サービスを開発して公開したり、他にもさまざまな技術でアプリケーションを「個人開発」している人たちが存在します。

技術力向上のため、事業収入を得るため、趣味として、その目的は人によってさまざまですが、「自分のアイデアを人が触れる形で実現したい」というモチベーションは共通しているのではないかと思います。

しかしその一方で、「触れる状態になるまでが長い」「開発時間が確保できない」という悩みを抱えている個人開発者も少なからずいらっしゃるのも事実です。その悩みが個人開発のハードルを上げている側面もあるでしょう。

単純な電卓やリマインダーのようなちょっとしたアプリケーションならまだしも、他にないサービスを考え、機能や仕様を検討し、システム全体を設計し、開発し、デザインも整え、さらにはプラットフォームの規定に従って公開作業を行う、という一連の作業は個人開発としてやるには規模が大きく、よほどの熱量がなければ達成できません。加えて、公開した後も機能追加やユーザーのサポートで継続的なモチベーションが求められます。

ここで視点を変えてみると、もしかしたら「ライブラリ開発」という発想がそのような悩みの解決策のひとつになるかもしれません。それがなぜなのか？を詳しく説明していきたいと思います。

ライブラリ開発とは？

読んで字のごとく「ライブラリを開発する」というものです。

言語やフレームワークに関わらず、みなさんも利用する側として日頃からライブラリのお世話になっていると思います。あれです。

私も Flutter 向けのライブラリ（Dart/Flutter では「パッケージ」と呼びます）をいくつか開発・公開していますが、まわりをみると同じようにパッケージを開発・公開している人は個人アプリを作っているという人にくらべて極端に少ないように思えます。

ハードルが高い印象があるのか、アイデアが沸きづらいのか、あまり選択肢として思いつかないのか、正確な理由はわかりませんが、実際にやっている身として改めて考えてみるとライブラリ開発にはアプリ開発に比べて継続しやすい理由がいくつかあることに気がつきます。ここからはその理由についてまとめてみます。

1. やりたいことに集中できる

なにより大きいのは自分の「やりたいこと」に集中できるという点です。

先述の通り、アプリ開発はモバイル・Web を問わずアイデアが実現するまでにとても長い工程と相当な規模の開発が必要になります。

もしそのすべての工程に興味があるということであればアプリ開発は最適です。しかし、必ずしも全員がそうではないとも思います。できることならアイデア出しとコーディング以外は AI にでも任せてしまいたい場合もあるでしょう。規模が大きくなればそのコーディングだってどこかで妥協しなければ終わりません。

一方、ライブラリ開発の場合はそれがありません。

ライブラリは「最低限のことをうまくやる」ことを求められることが多く、フレームワークのようになんでもやってくれる多機能なライブラリは逆に「重い」とネガティブに受け止められることすらあります。

つまり、機能をうまく実現する最小限のコードに集中できるため、めいっぱいコーディングにこだわれます。デザインを整えたりアイコンを作ったり、技術的には「以下同文」な大量のコードを書いたりする必要もありません。

2. 同じ立場の開発者に使ってもらえる

通常、アプリ開発というと利用者は一般の消費者であり開発者であることは稀です。つまり、コミュニケーションの背景となる知識や考え方、習慣の異なる人に向けてサービスを考える必要性が出てきます。

この点も「それがしたい」という場合はアプリ開発が最適なのですが、やはり技術やコーディングに集中したい場合はこの顧客理解に必要以上のリソースが割かれてしまいます。

一方で、ライブラリ開発の場合は利用者も開発者です。つまり、共通する前提や知識をもとに、スムーズにコミュニケーションをとることができます。GitHub 上で同じコードを読みながらやりとりができますし、場合によっては仕事や勉強会で知り合った人が自分のライブラリの利用者ということもあるでしょう。

そうなると、ライブラリは開発者の間で「名刺代わり」になることもありますし、話題のタネにもなります。勉強会での登壇ネタとしても最適です。

さらに視点を広げると、Readme などのドキュメントを英語で書いておけば世界中の開発者に自分を知ってもらうきっかけにもなります。もしかしたらその言語やフレームワークの「中の人」の目に届くこともあり得ない話ではありません。

3. アピールしやすい

面接をする側の経験から考えると、「個人アプリ開発」というのはポートフォリオとしてわかりやすいようでわかりづらい悩みがあります。

たとえばサービスを触ってみて表面から評価をしようとすると、それは見てくれが良いだけで技術的には大したことがないのか、本当に考え込まれよく実装されたサービスなのかがなかなか判断しづらいです。とはいえコードを読もうにも規模が多くて全体をしっかり読んで判断するには時間がいくらあっても足りません。そもそもコードが非公開である場合も少なくないでしょう。

一方でライブラリ開発の場合は必然的に issue などから「他の開発者からの評価」がつきやすく、それはソフトウェア開発技術の評価として大きな参考になります。またコードが少なければ全体を読み込んでより正確な判断ができますし、開発する側も妥協のない自分の技術を詰め込めます。

ライブラリ開発の難しさ

範囲を狭めてやりたいことに集中でき、集中できるからこそこだわりを入れやすく、さらに開発者同士のコミュニケーションや評価にもつながりやすい、そんなライブラリ開発ですが、もちろん難しい点もあることを書いておかなければフェアではありません。そちらについても考えてみましょう。

1. アイデアがわきづらい

アプリ開発は、内容的にも視覚的にも「自分がユーザー」となって使っているイメージが沸きやすく、アイデアも出やすい側面があるかと思います。

一方でライブラリ開発となると、もうすでにライブラリとしてほしいものはだいたいあったり、そもそもどんなコードを世の開発者が必要としているのかを想像しづらいという難しさが挙げられるでしょう。

しかし、一見同じことをするライブラリでも、いくつかピックアップして比較するとそのアプローチはさまざまであることに気がつきます。

ライブラリとしての対応範囲や利用側のコードの見た目（つまり API デザイン）、バージョンアップの頻度や内容、さらには開発者個人の属性まで、ライブラリに対する需要はさまざまです。もしかしたら「日本人が開発している」こと自体に需要があるとすら考えることがあります。

「このライブラリ、もう少しこう使えればいいのにな」「このコード、なんかよく書いてるな」という経験があればそれがライブラリ開発の入り口になります。「同じ目的のライブラリがすでにある」は新しいライブラリの開発を諦める原因には意外となりません。

2. ハードルが高いイメージがある

多くの開発者にとって、ライブラリは通常「探して使う」ものであって、それをどんな人がどのように作っているかをイメージする機会が少ないかもしれません。もしかしたらとんでもなくスーパーなエンジニアが想像もできない技術力で作っているイメージすらあるかもしれません。

確かに一部の人気で有名なライブラリは私たちとは世界が違う人たちによって開発されている場合もあるかもしれませんが、その他の大半の「ちょっと使えてちょっと嬉しい」ライブラリの GitHub を覗くと、意外と私たちとそう違わない立場やスキルセットの人たちが試行錯誤しながら改善している様子が伺えます。

アプリ開発する際も、いきなり有名企業の巨大なアプリと比べたりはしないと思います。それと同じです。

「ちょっと使えてちょっと嬉しい」ライブラリを使う機会があれば、ついでにそのライブラリの GitHub リポジトリを見てみると、「ライブラリ開発者」の解像度をより高めることができるでしょう。

まとめ

個人開発といってもその形はさまざまです。

モバイルや Web のフロントエンドひとつをとっても、ひとつのアプリケーションを作り上げて公開するだけでなく小さなライブラリを開発するという選択肢が同じ程度に存在し、そこにはまた違った楽しさやチャンスが広がっています。

今までライブラリ開発という選択肢がなかった人、「難しそう」と考えて手を出せずにいた人にとって、この記事が新しい選択肢を与えるきっかけになれば幸いです。

いかがでしたか？

「個人開発」といえば何か動くもの！と思いがちですよね。新しい選択肢に興味が湧いた方もいらっしゃるのではないでしょうか。ぜひ、気になった方は挑戦してみてください。何か困ったことがあれば、メンターに相談してみましょう。きっと新しい挑戦を応援してくれるはず。

みなさんの「記事、読みました！」の声がメンターにとっても運営にとっても励みになります。読んだ方は感想などを伝えてもらえたらとても嬉しいです。

メンター執筆シリーズについて

メンター執筆シリーズはこれからも定期的に配信中。

現役エンジニアが執筆するからこそのトピックや本よりライトだけどみなさんにとって新しい発見がある情報をお伝えできるコンテンツとなってきました。この執筆シリーズは、リライトはほとんどしておらず、メンターの思考をそのままみなさんへお届けしています。

更新タイミングは不定期ではありますが、ぜひ、次の記事も楽しみにお待ちください！

SIer営業からエンジニアへ。想定外から始まったキャリア

エンジニアになるまでの道のりには、いくつもの転機がありました。

大学では統計をメインに学んでいましたが、就職活動では、もともと興味のあったデザイン・アパレル系のほか、金融やITなども幅広く検討。最終的には成長できる環境や福利厚生なども含めて総合的に判断し、SIerに入社しました。新人研修では、JavaやCOBOLなどを中心にプログラミングをみっちり学びましたが、配属されたのは希望していた営業職。ところが、実際の業務はイメージしていた内容と異なり、2年足らずで退職することになります。

退職後、しばらく職に就いていなかった頃、ITに詳しい人を探していた方から声をかけられ、ホームページ制作を頼まれたのが、エンジニアとしての第一歩でした。SIer時代に基本的なプログラミングは学んでいたものの、Web制作の実務経験はゼロ。それでも「なんとしても完成させたい」という思いから、自分で調べながら試行錯誤し、無事に納品することができました。その実績が信頼につながったのか、次第にメディアサイトやLP、Webデザインなどの依頼が舞い込むように。とはいえ、当初はまだ生活が安定せず、1〜2年ほどは複数のアルバイトを掛け持ちしながらの日々が続きました。

やがて、システム開発の案件を任されるようになったことで収入が安定し、ようやく本業としてエンジニア一本でやっていけるように。この経験から、「求められるエンジニア」であり続けるために、戦略的なスキルアップとセルフブランディングに力を入れています。

“誰もやらない”をやる。sho_yamaneさん流セルフブランディング術

ビジネス感覚を持つようになった原点は、高校時代にあります。当時、テレビ番組で出演者が着ていた人気ブランドの服を買って転売したことで利益が出た経験から、「需要に対して供給が少ないところにはビジネスチャンスがある」と実感しました。この経験をきっかけに、利益を生み出す視点を意識するようになったのです。

フリーランスとして独立してからも、その感覚は常に意識していて、世の中の“需給バランス”にアンテナを張りながら活動してきました。例えば、エンジニアとしてどう差別化して生き残るかを考えたとき、当時は「プログラミングとデザインの両方ができる人材」が少ないと感じたため、自分の強みをそこに絞ってセルフブランディングを展開。それが功を奏し、システム開発系の仕事を安定的に受けられるようになっていきました。

また、技術面でも“将来のニーズに応える”ことを意識しています。たとえば、個人開発したマークダウン式ドキュメント管理ツール『Tree』では、リリース当時まだ新しかったNuxt.jsのVersion0をあえて採用。今後フリーランスに求められる可能性が高い技術を、個人開発でいち早く経験しておくことで、自分の武器になると考えました。

技術トレンドのキャッチアップには、日々X（旧Twitter）、はてなブックマークのテクノロジータブ、Zennのトップページなどをチェックしており、こうした継続的な情報収集も、ブランディングと差別化の大きな柱になっています。

『あったら便利』が原点。個人開発で得た成長とスキル

「いつか自分でサービスを作って、収益を上げてみたい」。そんな思いを持ち続けていた私は、受託開発の傍らでモダンな技術を学びながら、個人でのサービス開発にも取り組むようになりました。最初に開発したのが、『FITOUT』というサプリメント比較サイトです。当時は筋トレに夢中で、週に5〜6日ジムに通う日々。プロテインの摂取量も多く、少しでもコストを抑えたいと考えていました。しかし、輸入品が多いプロテインは為替相場の影響で価格が大きく変動し、都度いろんなECサイトを見比べるのは手間がかかります。
「それなら、自分で比較できるサイトを作ればいい」と思い立ち、1gあたりの価格を比較できるツールを自作することにしました。このように、私の個人開発はいつも自分自身の「これがあったら便利だな」から始まります。自分のニーズを出発点としたプロダクトばかりなので、開発にも自然と熱が入ります。

個人開発の一番のメリットは、たとえユーザーが少なくても、X（旧Twitter）上で発信することでフォロワーが増え、エンジニアとしての知名度を上げられたことです。また、誰かに使ってもらう前提があるからこそ、妥協せずサービス設計や仕様にこだわるようになりました。技術的に難しいことにも挑戦する機会が多く、自分の成長を実感できたのも大きな収穫です。たとえば『FITOUT』では、複数のECサイトから価格を取得するためにスクレイピングを用いましたが、HTML構造が頻繁に変わるため、その都度コードを修正する必要があり、保守性の重要さを学びました。

その次に開発した個人開発『bitChecker』では、ビットコインの価格変動をリアルタイムで表示するサイトを作り、さらにそのデータをもとに自動で画像を生成・投稿する仕組みも実装しました。これにより、プログラミングでの画像生成という新たなスキルも身につけることができました。知らないことを知ることが好きなタイプなので、分からないことに出会っても「頑張ればできるはず」というマインドで楽しく取り組めています。

プロダクトを売却してわかった、もう一つの“得られるもの”

個人開発を通じて収益を得たいと考える方は、きっと少なくないはずです。私自身もそのひとりで、過去に開発したプロダクトを売却した経験があります。そのときのお話をさせてください。

きっかけは、あるビジネス系YouTube動画で耳にした「先にものを作るな、買ってくれる人を先に見つけろ」という言葉でした。その教訓に従い、まずはニーズがありそうな相手に話を聞き、相手のニーズから課題解決を提案。あらかじめ売却の可能性を見込んだ状態から実際の開発に着手し、無事にプロダクトを売却することができました。もし「これから新しいプロダクトを作ろう」と考えている人がいたら、先に買いたい人を見つける選択肢もあるということを知っておいてほしいです。

この経験を通じて強く感じたのは、得られた報酬以上に、「プロダクトを売却した」という経験そのものが、自分のブランディングにつながる強力な“実績”になるということです。たとえば、その後に高単価の案件を紹介してもらえたり、イベント登壇のお声がけをいただいたりと、思ってもみなかった形で次のチャンスにつながっていきました。

すぐに売上や利益に直結しなくても、「プロダクトを一つ作って世に出した」という事実そのものが、自分の名刺代わりになります。すぐに利益を得ようと焦らずに、新しいことに挑戦することが、やがて将来の自分の信頼や価値をつくっていきます。一つひとつ経験を積んでいくことが大切です。

途中で諦めてきたからこそ見えた、作り切るためのヒント

プロダクトを作り始めることは比較的簡単でも、最後まで作りきれる人はごくわずかだと思います。私自身も、途中で開発を諦めてしまったことは何度もありますし、2つ作り始めて1つ完成できれば良い方でした。

そんな中でわかったのは、「どうしてもこれを作りたい」と思えるものほど、最後までやりきれるということです。たとえば、自分にとって“それがないと困るもの”や“絶対に欲しいと思えるもの”であれば、自然と手が動きます。逆に、思いつきで始めたものや、完成した後の評価がイメージできなかったものは、途中で手が止まってしまうことが多い傾向にありました。また、もう一つ大切だと感じているのが、「やらなければならない環境に自分を置くこと」です。たとえば、X（旧Twitter）などで「このサービス作ります」と宣言してしまうことで、自分自身にプレッシャーをかける。そういった仕組みをうまく使って、逃げ道をなくしていくのも、ひとつの方法だと思います。

せっかく何かを作るなら、しっかり形にして世の中に出したい。そう思えるものに出会い、最後まで向き合える環境を整えることが、プロダクトをやりきるための大きなポイントになると感じています。

ものづくりの一歩を踏み出そうとしているあなたへ

ゼロイチでプロダクト開発に挑戦したいと考えている方に、ぜひ伝えたいことがあります。
それは、良いプロダクトをつくるためにはエンジニアリングだけでなく、デザインなど多角的な視点を持つことがとても大切だということです。そうした視点を意識することで、プロダクトの質がぐっと上がり、他の人から評価される機会も増えます。そして、それが次の開発へのモチベーションにつながる。そんな好循環が生まれるはずです。

私自身、これまで複数のプロダクトをひとりで開発してきました。アイデアが形になる瞬間は本当に嬉しいですし、それが評価されると人生そのものが豊かになる感覚があります。いま何かを作ろうとしている方、アイデアはあるけれど形にできていない方、ぜひ気軽に声をかけてください。TechTrainのメンターとして、私のこれまでの経験が少しでも役に立てば嬉しいです。
自分の手で作ったプロダクトを世の中に出し、誰かに喜んでもらう。そんな未来を一緒に目指していきましょう。

sho_yamaneさん、インタビューありがとうございました！

求められ続けるエンジニアであるための戦略や、プロダクトを売却するために先に買い手を見つけるなど、目から鱗の内容ばかりでした。開発をこれから始めようと思う方にとって、sho_yamaneさんがおっしゃっていた最後までやりきるためのポイントは参考になったのではないでしょうか。

TechTrainでは今回インタビューに答えて頂いたsho_yamaneさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

武田さんご自身がコントリビューターとして追加した機能や、翻訳プロジェクトのメインメンテナとしてPHP8.4を隈なく知り尽くす武田さんの悩んだ末に選んでもらったイチ押しの機能についての解説をご紹介します。

武田さんが8.4で追加した機能「PostgreSQLのPDO」

PHPのPDOからPostgreSQLのデータベースにアクセス時に、PostgreSQLでメモリをどれぐらい使っているのかを観測することができる新機能です。PDOとは、PHPからデータベースを扱うための拡張機能のことです。

▼実際のpull request

*補足：mergeされたとしても、closed表示になっちゃうことがある特殊な運用をしています。

▼日本語翻訳のpull request

PHPへの新機能追加は私にとっては長年の夢で、それが叶った思い入れのあるcontributionsとなりました。GitHubアカウント名の右側の表示からも分かる通り、この頃はまだメンテナではありませんでした。そして、この数週間後にはメンテナとしてIssue Trackerを立てたりしています。今思うと本当に急展開です。

今までlibpq含め全てのマニュアルに目を通していましたが、あまり機能追加が活発ではなかったため、この機能追加なら貢献できると思ったことが追加のきっかけとなりました。これまで、PHPは多くのサービスで採用されているMySQLをメインにDatabaseのサポートを拡充してきました。ところが、海外での開発で採用される機会が増えていく中でPostgreSQLのサポートをより拡充することの声が上がってきていました。

そして、個人的にPostgreSQLが大好きだということもあり、より皆さんに便利に使ってもらえたら、という想いもあり機能実装をすることになりました。

余談ですが、OSS活動をしている方なら少しでもあるはずの「この新機能について、自慢したい！」という思いから（OSS活動してる方、この気持ちありますよね？笑）、過去にPHP Conference Japan 2024では「PostgreSQLのPDO」をテーマに登壇もしています。

武田さん推し機能「BCMATH 任意精度数学関数」

翻訳に携わっていると隅々までの機能を知り尽くしているので、本当なら2時間くらい語り尽くしたいくらい選びづらいですが...1つ挙げるなら、PHPコア開発者の高町咲衣さんが追加したBCMATHの追加機能です。

この変更は、今までPHPが活用されづらかった端数を含む正確な計算が必要な金融の分野や、高精度が求められるヘルスケア分野にも広がるきっかけになる可能性を秘めていると感じます。そうなれば、後世になって語られるぐらいのインパクトがある機能追加なんじゃないかなと個人的に思っています。

▼翻訳元の英語ドキュメントのpull request

▼日本語翻訳のpull request

「任意精度数学関数」というのは、誤差が出ないよう正確な計算をするための機能です。この機能自体はもともと昔からありましたが、今までと比較して高速化し、より使いやすくなっているのがポイントです。なんと、状況によっては、約1000倍の高速化が施されています。また、before/afterで同じ計算をするコードを実際に見ると使いやすくなったことが顕著にわかると思います。

Before

// (150  2 + 100)  1.1

var_dump(bcmul(bcadd(bcmul('150', '2', 0), '100', 0), '1.1', 2));
// string(6) "440.00"

After

use BcMath\Number;

$number = new Number(0);
$result = $number
    ->add(150)
    ->mul(2)
    ->add(100)
    ->mul('1.1', 2);

var_dump($result);
// object(BcMath\Number)#3 (2) {
//   ["value"]=>
//   string(6) "440.00"
//   ["scale"]=>
//   int(2)
// }

Afterではオブジェクト対応により、可読性も高く、そしてシンプルで書きやすくなっていることが見てわかりますよね。

さらに、これだけではなく、演算子オーバーロードにより、演算子（+、-、×、÷など）を使った計算が実現し、よりシンプルで使いやすくなりました。

use BcMath\Number;
$answer = new Number(42);
$enigma = new Number(23);

get_class($answer); // BcMath\Number
get_class($enigma); // BcMath\Number
get_class($answer + $enigma); // BcMath\Number

error_log($answer + $enigma); // 65
error_log($answer - $enigma); // 19
error_log($answer  $enigma); // 966
error_log($answer / $enigma); // 1.8260869565
error_log($answer % $enigma); // 19
error_log($answer * $enigma); // 21613926941579800829422581272845221888

出展元：以前武田さんがPHP勉強会で登壇した時の資料をブログ

関連ツール「Composer」の公式マニュアルでの紹介

Composerは、PHPでアプリを開発する際にライブラリを管理するツールで、どのフレームワークを採用していてもPHPを使う人なら利用しない人は誰一人としていないくらい有名なツールです。ただ、このComposerはPHPで書かれていますが、PHPが公式に出しているものではありません。PHP8.4の翻訳中、公式マニュアルに突然掲載されたのを見つけた時には本当に驚きました。

実際に翻訳が掲載されている[PHPマニュアル「Composer 入門」

▼日本語翻訳のpull request

この翻訳元のcommentを見ると、公式の出されたツールではないもののマニュアルを載せることについては慎重に議論がされていることがわかるので、ぜひ興味がある方は見てみてくださいね。

▼翻訳元の英語ドキュメントのpull request

Composerの部分は早く翻訳したいなと思っていた箇所なのですが、なかなか手をつけられずにいました。そしたらなんと、コントリビューターの方から翻訳のプルリクエストを頂き、おかげでやっと日本語訳を提供できました。本当に良かったなと思っています！

"マニュアルの「今」があるのはプルリクエストを下さった皆さん全員のお力です。PHPへの貢献に感謝！"
by武田さん

取材頂きました！マニュアルの話なのにいつの間にPHP 8.4を熱く語っていた取材風景。聞き上手な @hiraisoko_rai に感謝。

記事は私への取材ですが、 マニュアルの「今」があるのはプルリクエストを下さった皆さん全員のお力です。PHPへの貢献に感謝！https://t.co/YuAMfNZV0m

— 武田 憲太郎 (@KentarouTakeda) April 1, 2025

前回の記事では、翻訳プロジェクトについてをメインでお話ししてきましたが、インタビューの中でいくつか具体的な機能についても解説していただきました。

本記事をきっかけに、一部の機能に触れていただくことで、少しでもPHPマニュアルや、翻訳のOSS活動に興味を持ってもらえるきっかけになれば嬉しいです！

また、マニュアルの整備は、これからPHPに触れたい！という方や、PHPに触れ始めたばかりという方々の成長の後押しになります。あなたも、翻訳に参加してみませんか？

▼Issue「PHP 8.4 マニュアル翻訳状況」

武田さんが取り組むPHP8.4のマニュアル日本語翻訳プロジェクトについてをお題に、PHP8.4を軸にPHPの歴史とこれからについて、そしてプロジェクトに取り組む中での想いについてなど余すことなくお伝えしていきます。

PHP8.4日本語マニュアル翻訳プロジェクト着手のきっかけ

「すごいバージョンがリリースされるのに、このままでは、日本のPHPコミュニティの人たちにこの凄さが伝わらないかもしれない...」

きっかけはこの危機感からでした。

実は、今まで他のメンテナの方がほぼ一人で翻訳を進めてくれていましたが、PHP8.4リリース前の3〜4ヶ月間、そのメンテナの方が多忙となっていたこともあり、翻訳自体の更新がない状態が続いてしまっていました。

今回のバージョンでは、私自身がPHP本体に機能を追加した機能もあります。初めて機能追加した思い入れの深いバージョンということもあり、リリースがされたら、自分の追加した機能の部分だけでも翻訳マニュアルを書かないとな、でも面倒だし、どうしようかな〜と悩んでいました。

そんな矢先に翻訳全体が止まっていることを知ってしまい、「ならば、この素敵な機能たちを広めるため、8.4全ての翻訳を私が進めてリリースに間に合わせなければ！」という使命感に駆られ、本プロジェクトをスタートしました。

▼Issue「PHP 8.4 マニュアル翻訳状況」

▼8.4リリース間近の武田さんのXのポスト

PHP 8.4のリリースまであと5日。

そして、恒例行事(?)ですが、ドキュメントのスケジュールがタイトですwhttps://t.co/6OBCInH9Ar

新機能を先取りしたい方、コントリビューションに興味ある方、各機能のエキスパートの方、是非ともIssueをご覧の上、気になる機能はプルリクご検討ください！

— 武田 憲太郎 (@KentarouTakeda) November 16, 2024

PHP 8.4は“歴史的転換点”になるようなバージョン

先ほどのきっかけでもお話ししたように、「PHP 8.4は歴史的な転換点になるようなすごいバージョンなんじゃないかな」と私含め、色々な方が話しているバージョンです。それがなぜなのかを、PHPのここまでの変遷とともにお話しします。

PHPコミュニティでは長年、JetBrainsに所属していたNikita Popov氏という天才的なプログラマーが中心となり、PHPの進化を牽引してくれていました。Nikita氏が天才的と言われている所以は、当時JetBrains内でのPHPの言語自体へのContributionsが第2位とさらにContributionsをするプログラマーがいる中で、言語の考え方自体を変えてしまうような破壊的な変更を加えていった点です。例を挙げると、7.0で構文解析（PHPスクリプトをコンピュータが実行可能な形式に変換するための解析処理）を書き直し、それを皮切りに続々と、オブジェクト指向原則や型に関する改善を取り入れていきました。また、7.4の継承エラー(リスコフの置換原則違反)の機能などもその代表例といえます。しかし、そんなPopov氏が転職を機にPHPコミュニティから離れてしまい、その後のPHP8.2や8.3のバージョンでは、新機能追加のペースはやや停滞気味となっていきました。私だけではなくPHPを扱うエンジニアの方々は、体感としてこのような印象を抱いているのではないかと思います。

ところが、8.4では、それまでのコミュニティ体制の再構築が実を結び、かつてPopov氏がいた頃の勢いを超えるような大量の機能追加が一気に実装されました。

そうはいっても、すでにここまで大きな変更がなされているため、Popov氏の追加した機能のような今までできなかったことができるようになる機能追加はそう多くありません。ただ、このバージョンリリースを「歴史的な転換点」と言わしめる最大の特徴は、別にあります。それは、すでにある機能がより洗練され、その洗練度合いが凄まじいという点です。かつての転換は「考え方」でしたが、今回は「書き方」です。その中には、言語自体を拡張するような手法で書き方を洗練させるような機能も含まれます。とにかくかなりすごいバージョンになっています。

これからPHPのバージョンはどうなっていく？

ここからは、新機能の議論の方針も踏まえて、私の想像の話になります。

まず、前述した通りPHPはすでに何度も追加機能の実装を経ていて、標準でできることの幅が広い高機能な言語です。そのため、これ以上今ある機能を便利にするネタはそうそうない気がしています。なので、今後の機能追加の方向性で言えば、Popov氏が機能追加を牽引していた時のような、「PHPでできないことをできるようにする」という言語の概念を覆すような大きな機能追加の方向にシフトしていかざるを得ないんじゃないかなと思います。

わかりやすい例を挙げるなら、非同期処理でしょうか。非同期処理は歴史的にPHPが苦手とする処理と言われており、プログラミングの考え方が異なる以上導入しようがないような機能をできるようにする。そんなPHPの概念を大きく変えるような機能追加以外には、変更をするタイミングはもうあまりないのではないかなと想像しています。

余談ですが、もしかしたら、この非同期処理の変更が実現すれば、PHPがISUCONで勝てる日も遠くないかもしれません........

翻訳プロジェクトを通してPHPのコミュニティを支える人を増やしたい

「8.4のマニュアル翻訳をリリースに間に合わせなければ」という思いがきっかけで着手したプロジェクトですが、動き出してからは、PHPコミュニティでのプルリクエスト1個でも経験したことがある人を1人でも多く増やしていくことを大事にしたいと強く感じるようになりました。

OSSの世界ではほとんどがボランティアだからこそ、関わる人を増やすことで、そのコミュニティが盛り上がっていくと思っています。翻訳プロジェクトは、OSSの中でも、はじめの一歩に最適です。今後、この翻訳ドキュメントでのmergeの経験が自信となり、ライブラリ本体にpull requestを送る経験をするというステップアップのきっかけになったら嬉しいなと思っています。

そのため、多くの人に参加してもらえるように、基本的には肯定的なコミュニケーションをとるようにしていますし、さまざまな工夫を凝らしています。

この難易度の絵文字は、リストが増え出した頃からつけるようになりました。どこから取り組んだらいいかが一目でわかり効率的に翻訳が進められるようになりましたし、初心者の方もゲーム感覚でとっつきやすくなったのではないかなと思います。また、視覚的に賑やかになったことでXでも盛り上がってもらえました。

武田さんから、この記事を読んでくださったみなさんへひとこと

ひとことと言わず、15ことくらいになってもいいですか？（笑）
実は、私もTechBowlの掲げるミッション「エンジニアリングで日本の国力を上げる」と似たようなことを考えています。国力まで言うと大袈裟ではありますが、PHPコミュニティに所属する人たちのスキルをボトムアップできたらという想いを持っています。

それを実現するアクションのひとつとして今回お話ししたマニュアル翻訳も関わっています。ある程度エンジニアリングの経験を積めば、たいていのことは一次情報（マニュアル）を読めば解決できるとわかっているため「マニュアルを読めば載ってるよ」とアドバイスしてきました。その一方で、マニュアル自体のハードルが高ければ、その一言を口にすることが憚られるなとも思っています。例えば、マニュアルの情報が古い、間違っているとか、英語しかない、などです。

そのハードルは、翻訳を通して、マニュアルの内容が正確、最新の情報が反映されている、日本語で敷居が低く、初心者の人にも分かりやすい表現になっているなど、ドキュメントを整備していくほど下がり、PHPを使っている人のスキルが底上げに繋がるのではないかなと思っています。

ドキュメントの整備って思っているより気軽に参加できます。例えば、「hogehogeのマニュアルのここがわかりにくいと思っている」そんな声を上げるだけでも構いません。pull requestのハードルが高ければXに呟いてもらえたら届きます。OSSしてる人は大体エゴサしてるので。笑

そういったつぶやきも大事な情報です。ぜひ気軽な気持ちでドキュメント整備に参加してみませんか？その声が誰かを助ける情報になるかもしれません。

インタビューの中では、「PHPのコミュニティに属しながらPHPを落とす発言ばかりしちゃってます」と話していた武田さん。私の印象では、愛あるdisという印象で、「それでもそんなところが愛おしい！」と溢れんばかりの気持ちでたくさんのことをお話ししていただきました。

皆さんもPHP8.4の翻訳にpull requestを送ってみませんか？武田さんをはじめとした、PHPコミュニティの先輩エンジニアの皆さんが優しく歓迎してくれます。その経験がこれからの自信につながっていくと思いますよ。

武田さん、改めて、インタビューにご協力いただきありがとうございました！

テーマは、"現場の生々しい実装のお困りごと"。幅広く現場の生々しいことを大公開の勉強会。会場では「ここだけの話..」と実際の画面を投影するなんてサービスタイムもあったとか。当日限定で入手できる情報があるのもオフライン勉強会ならではですね！

当日のLT

• 『年間3000万件以上のEC出荷を支えるシステムをRDRA2.0のUC複合図にリバースエンジニアリングした話』冨田 陽介 / 株式会社ロジレス
• 『紙を印刷するだけじゃない？意外と奥深い帳票印刷アプリ開発』山下 智己 / 株式会社ロジレス
• 『TechBowl流ドメインモデルでの情報設計』ロキ / 株式会社TechBowl
• 『認知負荷を考慮したエンジニアオンボーディング』スー / 株式会社TechBowl

本記事では、TechTrainのエンジニアの登壇内容をメインにご紹介します。

ロジレスのテックリード冨田さん、エンジニア山下さんの登壇については以下テックブログよりご覧いただけます。記事を執筆したエンジニア山本さんの補足コメントもあり、登壇内容がまとまっており、勉強会の雰囲気が感じられるブログとなっています！

『TechBowl流ドメインモデルでの情報設計』ロキ

入社してからずっとDDDを推進してくれているロキさん。今回のLTでももちろんテーマはDDD！

TechBowlが提供するサービスTechTrainの中にはサービスが複数あり、またそのサービス内にもたくさんの機能が備わっています。そのため、TechTrain特有の名称や呼び方があります。今回のLTテーマであるドメインモデルでの情報設計は、関係者が認識を合わせて開発を進めるために非常に重要な役割を担っています。

TechTrainの開発チームでは、毎週「モブ会」というミーティングがあります。情報整理で意識することにある3つはこの会でかなり議論をしている点です。

• どんなワードを設定するか？
• 依存関係の確認やどれくらいまで許容するか？
• ワードを生成・変更をするときのルールをどうするか？

かなり密にそして熱い議論をしながら設計を進めています。

DDDの効果の実感

”チームで認識を合わせながらモデルを作ることで各人の連携力が高まっていると感じます！今後も方法論に捉われず、チームで試行錯誤しながらいいものを作る土壌を育てたいと思います ”
by ロキ

▼このLTに関連するTechTrainテックグログも公開中！

『認知負荷を考慮したエンジニアオンボーディング』スー

TechTrainに1人目エンジニアとして入社し、開発の重鎮となっているスーさん。多くのメンバーを受け入れ、常にブラッシュアップし続けているエンジニアオンボーディングについてをテーマにLT。

TechTrainの開発チームは、PM・デザイナーを含め現在社員9名、業務委託7名、インターン生3名となっています。稼働時間のばらつきがある上に、サービスや機能が多数ある中でそれぞれが担う役割も異なります。「覚えることが多すぎる！」とならないために、負担を軽減することがスムーズに開発に入ってもらうためのカギとなります。

そのためにしていることは以下のようなことです。

• 情報を一気に渡さず小分けにし、伝える順番を意識する
• 相手が想像しやすい例えや比喩など相手に合わせた伝え方をする。これをTechTrainでは”for you感”と呼んでいます
• ドキュメントを統一し、情報を集約し、不要なものは伝えないと決める

言葉にしてみれば当たり前に感じますが、複数人集まる組織ではなかなか難しいのが現実です。何度もチューニングしながら日々アップデートしている最中ではありますが、あえて発信することで改めて意識しなければと気が引き締まりました。

オンボーディングを充実させた理由

”時間がないからこそテストを書いた方が良いという言葉をよく聞きますが、それはオンボーディングにも当てはまると考えています。時間がないからこそオンボーディング資料を充実させておくことで、イネーブルメントの観点としても、開発者体験としても良くなると考えて2人目のエンジニア社員が入る時点でのオンボーディング資料を充実させる方が良いと判断しました！結果的にすごく新しく入ったメンバーの方の立ち上がりが良くなっています！”

by スー

▼このLTに関連するTechTrainテックグログも公開中！

オンボーディングどころではないTechTrain初期の開発環境を大公開している対談記事

オンボーディングを意識し出した時の記事

設計も組織もこれからますますパワーアップしていきますが、今の等身大の”お困りごと”を発信できる良い機会となりました。現場では、どのLTもレイヤー問わずに「わかる〜」という声が上がるくらいの現場あるあるが満載です。

みなさんも、機会があれば、ぜひLTで現場のお困りごとを聞いてみてはいかがでしょうか？

現在、TechTrainでは企業さんとのコラボ勉強会を積極的に企画しています。一緒に勉強会を共同開催してくれる企業さんをお待ちしています。ぜひ、たくさんのエンジニアの皆さまと知見を共有し会えたら嬉しいです！

SIer営業からエンジニアを目指そうと思ったきっかけを聞かせてください

私は、もともとエンジニアを目指していたわけではなく、小学校の頃からずっと官僚を目指して勉強に励んできました。「みんなが簡単に目指さなさそうな公務員」という逆張り的な思考がきっかけです。最終的には国家公務員試験を受けるところまではやり切りましたが、官僚の道には進まず、新卒でNTTデータに総合職として入社することになりました。学生時代の企業でのアルバイト、インターンシップ、他学部での授業などを通じて経営や技術のコンサルティング業務に興味を持ったxめです。

営業職として働く中で、プロダクトについてエンドユーザーからリクエストがあった時、自分の目の前にクライアントがいて、その中に開発チームがあり、その先にプロダクト、そしてエンドユーザーがいるというように、多くの人やチームを挟んだ状態でした。その距離の遠さから、プロダクトを改善する手応えを感じるのが難しかく歯痒い思いを経験することも少なくありませんでした。

そんな時、仕事を続けながら週末プログラミングスクールに通うようになり、そこでの原体験が、エンジニアを目指すきっかけです。プロダクトを一から作り、フィードバックをもらって、さらにその機能を自分の力でプロダクトに還元していくという経験が想像以上に楽しく感じられたのです。

実務未経験でエンジニアキャリアをスタートした時のことを教えてください

実務未経験で、ポートフォリオも少なかったため、書類選考に通過できないこともありました。そんな中、当時未経験から参画したエンジニアが活躍した過去事例があったfreee株式会社に転職することが決まりました。振り返ってみれば、採用のリスクがある中で何人もの方との面接をセッティングしてもらい、熱意や伸びしろを評価してもらえたのではないかなと感じています。

freeeにはエンジニアが中心になってプロダクトをどんどん作っていくような雰囲気に強く惹かれて入社したものの、実務でWeb全般の開発と並行して土日もずっと勉強しないと追いつけないくらい大変な状況でした。特に最初の半年間は、実務の中でエンジニアの先輩方から、技術はもちろんエンジニアとして働くための基本的な部分についてたくさんのアドバイスをもらいながらなんとかしがみついていました。初めは、バックエンド開発を中心に業務を進めつつ、その後、WindowsやMacのデスクトップアプリ開発を広く任せてもらえるようになっていきました。業務の中でパフォーマンスチューニングをきっかけにインフラ周りも見るようになり、他にもグロース施策など様々な機会をいただけるように。この頃から、社外の技術コミュニティの勉強会やLTに参加したり、技術書典で書籍を出すなど、アウトプット駆動で少しずつ技術を身につけてきたように思います。

▼toshitoshi0607さんが技術書展に初めて出した共著の書籍『Extensive Xamarin』のブログ記事

その後、現在専門とするプラットフォームエンジニアリングのキャリアに辿り着くまではどのようなキャリアを歩んできましたか？

振り返って考えてみると、一貫して事業内容に関心が持てること・技術的におもしろそうと思えることを軸としてキャリアを広げてきた中で、プラットフォームエンジニアリングに辿り着いたように思います。

freeeで開発をする中で「お金の流れを作る」ということに興味を持ち、よりその流れに直接関わることができる事業内容が面白そうという思いを持っていた中、Gopher道場に参加して「Goでもっと開発してみたい」と感じたことで、株式会社メルペイへの転職を決めました。メルペイは、マイクロサービスアーキテクチャを採用しており、ひとつのプロダクトが複数のサービスによって構成され、そのサービスごとにバックエンドからインフラまでを幅広く担当する体制を取っていました。その中のひとつを一人目エンジニアとして担当したため、開発はもちろん、チームを作ったり設計に携わるなどの開発だけではない経験の機会にも恵まれました。業務を進める中で、普段バックエンドをメインで開発している人でも、少ない設定でマイクロサービス用のインフラを一通り構築できるという洗練された仕組みに感動したことを覚えています。

その後、その仕組みを作っていきたいと思ったことをきっかけに、メルカリの方とコミュニケーションをとることとなり、最終的に転籍することになります。メルカリでは、希望が叶い、マイクロサービスの基盤を作ったり、開発者の方々が使いやすいようにワークショップをしたり、ドキュメントを整備したりという、まさにプラットフォームエンジニアリングの業務を担当。今のプラットフォームエンジニアリングのキャリアの最初の一歩を踏み出しました。

プラットフォームエンジニアリングとはどのような業務ですか

プラットフォームエンジニアリングは、開発者体験と生産性の向上により開発者が創造的な問題解決に集中できるように、セルフサービスで利用できるツールチェーンやワークフローを設計・構築する分野です。簡単に言えば、エンジニアが開発する上で邪魔になるものを取り除く仕事です。

直近2社では、プラットフォームエンジニアリングを推進したり、ゼロから作ったりする業務に携わっています。ある程度出来上がった土台に機能を足していくのに加え、社内の開発者に新しい体験を提供するという、まさにサービスの土台や環境を整えていくことになります。

そのため、これからプロダクトや開発者が増えるなどのサービスが大きくなるタイミングや、グローバル展開するときなど組織に大きな変化があるタイミングに導入されることが一般的です。例えば、UbieにSREとして入社することになった時は、サービスがこれから大きくなって、開発者がどんどん増えいく真っ只中でしたし、現在在籍中のLegalOn Technologiesももともと複数の異なる基盤上に作っていたサービスを統合するため導入するというタイミングに入社しています。現在もプロジェクトは進行中で、テックリードとして、十数名のSREメンバーとともに日々プラットフォームの拡張や改善に取り組んでいます。

改めてなぜこの業務に魅力を感じているのかと考えてみると、過去に理想の生活を実現するための土台を作ることを目指す官僚を夢見ていた時と通じる部分があると感じます。

大きな変化の渦中で土台を整える。その土台をもとに課題にぶつかった方々それぞれが自律的に解決できる仕組みを支える。環境は違えど、昔から変わらず根底には誰かの課題を解決する仕組みを作りたいという価値観があるのかもしれません。

未経験からスタートし凄まじいスピードでキャリアを歩んでいますが、何か意識していることはありますか？

そういっていただいてありがとうございます。笑

ただ、先ほどもお話しした通り、freeeでエンジニアキャリアをスタートした当初は苦労の連続でした。

ひとつ意識していることを挙げるとすれば、freee社内で取り組んだことをきっかけにOKRに取り組む習慣ができ、目標を可視化して振り返るようにしていることです。もちろん、今でも個人で設定しています。

OKRとは...

定性目標（Objective）を掲げ、それを達成するための測定可能な結果（KeyResults）を設定するという目標設定フレームワークです。

このOKRのおかげでいろんなところに興味を持って目移りする機会に惑わされず、決めたことをやり切るという経験を得ることで、日々スキルアップができている実感を得られています。

▼toshitoshi0607さんのOKRはブログから全てご覧いただけます！

OKRをうまく回すコツを教えてください

OKRを上手く回すためには、目標の立て方が大切です。そのポイントは自分でコントロールできる範囲で設定することです。例えば、「カンファレンスに登壇する」だと叶わないこともありますが、それを「カンファレンスのプロポーザルを3つ出す」という目標にすることで自分にできることに集中でき、行動するきっかけになりますね。さらに、今あげた例のように定量化して計測でき、できたのかできなかったのかが振り返りやすい目標になるようにすることも意識しています。

当たり前ですが、初めから上手くいったわけではありません。最初の頃は、3ヶ月でできるわけがない量の目標を盛り込みすぎてしまったり、目の前の業務に関係ないけど興味あるからやってみようという気持ちで目標に盛り込んだものの、自分の中での切り替えが上手くいかず結局時間が割けずに終わることもありました。そんな時は、振り返ったときに次はもっと絞ろうと反省して、次の3ヶ月に活かします。OKRは、3ヶ月でやることを決めると同時に、やらないことを決めることでもあります。プログラミングの初学者の場合、勉強しないといけないことがたくさんある中で、この3ヶ月はこれをやりきる！と整理してそれに集中し、モチベーションを保っていくことがとても大事だと思います。私もそうやってスキル習得をしてきました。いろんなところに目移りする機会があると思いますが、やり切ることを決めて注力することが成長に直結します。

▼「これから個人OKRに取り組む方の参考になりそう」と、toshiさんが共有してくれた個人OKRをテーマにマイクロソフトのイベントで登壇したときの記事

実際にバックエンドエンジニアからプラットフォームエンジニアにキャリアチェンジするタイミングで立てたOKRを例に出します。

2019年10〜12月　プラットフォームエンジニアへの闘争

• O1: プラットフォームエンジニアへの闘争
  • KR1: DIY Serverlessプラットフォームを構築する
    • ServerlessDays Tokyo
    • ServerlessDays Fukuoka
    • CLI
    • server -> functionのミドルウェア
  • KR2: Kubernetesの知識を網羅的・原理的に理解する
    • CKA取得
    • 何かコントローラー作る
    • what-happens-when-k8sを図を書きながら説明できるようになる
  • KR3: プラットフォームを支えるOSSにコントリビューションする
    • 機能 > テスト > リントツールでわかるもの > 設定ファイル > ドキュメント・コメント
• O2: ゆとりある心で秋〜冬を感じる
  • KR1: 心があたたまる食べ物を食べる
    • 鍋パする
  • KR2: 季節のイベントに参加する
    • ディズニーハロウィン
    • 温泉
    • もみじ、山
  • KR3: やりたこと、いきたいことリストをつくりワクワクする

今見てみると、重い目標を目一杯詰め込んでるな〜という印象ですが...笑。でも、当時の自分のスキルレベルや求められる環境を考えると絶対必要だったと思うので、今の自分からアドバイスができるとしてもかける言葉は「これをやりきれ！」の一言に尽きますね。

過去には、カンファレンスやイベントに紐づけた目標を立てることも多くありました。在学中のジョージア工科大学の修士課程に社会人学生として進学するというのもOKRを使って達成した目標のひとつです。やると決めたら自分を奮い立たせて最後までやり切ることを習慣にしています。

忙しそうですが、しんどいと思うことはありませんか？その時はどう乗り越えていますか

土日は基本的にコミュニティ活動をしたり、本を書いて過ごしていたので、大学院に通い始めても時間の使い方は大きく変わっていません。ただ、毎週課題の締め切りがあるので、追い込まれるプレッシャーは大きいかもしれません。

それでも、大学院の授業でOSやネットワーク、分散コンピューティングなどコンピュータの基礎的な部分を理解することで実務での応用が効くようになりますし、OSの仕組みが抽象化された設計をクラウドやOSSなど至るところで見出して類推するといった気づきに繋がるようになったので、進学して良かったと思っています。ある程度業務を経験してから学び直すことで業務の実感を持った上で課題に当たれるので、より深い学びを得られたのではと思っています。2025年12月で卒業予定なので、あと少し頑張ります！

しんどいときは、猫吸いとサウナでストレス解消しています。余談になりますが、サウナに入った後に中庭で外気浴しながら猫ちゃんと戯れるのがずっと夢でして、今の家を建てる時に自宅サウナ、そして外気浴ができて猫ちゃんが脱走しない構造の中庭を作っちゃいました！

ここまで読んでくれた方へ一言

私は、自分が作ったものを使ってもらって、人に喜んでもらえるとめちゃくちゃ嬉しいと思うタイプです。そのために多くのスキルを身につけ、日々できることを増やしています。プログラミングは大変な時もあると思いますが、そんな時はユーザーが使うシーンを思い浮かべ、喜ぶ人の笑顔を想像するとモチベーションが上がると思います。SREやプラットフォームエンジニアリング、個人の目標管理について困った時は、気軽にご相談くださいね。そしてサウナや猫のネタには飛びつくので、ぜひ話しましょう。

インタビューありがとうございました！猫吸い、サウナは共感する方が多いのではないでしょうか♪

周りの人やコミュニティの力を頼ることや、3ヶ月後に何ができる状態になるのかを決めることが、toshi0607さんの圧倒的な成長スピードを支えていたんですね。皆さんの3ヶ月後の目標は何ですか？これを機に改めて考えてみたいものです。

TechTrainでは今回インタビューに答えて頂いたtoshi0607さんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

2024年度は、3箇所（東京・名古屋・大阪）。そして、2025年度はなんと新たに2箇所が加わり、5箇所（東京・会津・名古屋・大阪・福岡）にパワーアップして開催しました。

今回、2年連続各地で大反響だった先輩LTの資料2025年版をアーカイブにて公開します！（2024年版は記事の後半で案内あり！）

リアルな就活体験談は、これから就活を受ける学生はもちろん、採用をする立場からも同意の嵐間違いなし...

先輩エンジニアの皆さんも、今のエンジニア就活のリアルをぜひ体感してみてください。

『ニックトレイン』って何...？

ニックトレインのコンセプトは、"エンジニア就活を知る・肉を食べて元気をチャージ・同じ場所を目指す仲間と出会う"です。connpassにあるイベント説明は以下の通り。

エンジニアを目指す学生よ、この1年をどう過ごすかが 超重要 なのだ・・・

テストが終わってこれから春休み....でも、ちょっと待ったぁ！！！！
なんと、新卒の採用が本格的に始まるのは 卒業から2年前の10月 なんです。

つまり・・・？

この2月 から 9月 をどう過ごすかが、めちゃくちゃ重要なのです。

そう、2 から 9 ！！ニク！！肉！！

毎年、コンセプトの中にある「エンジニア就活を知る」という文脈では、セミナーではなく生の声として、1つ上の代の先輩のLTを用意しています。

それではここから先輩の資料を公開。
なお、福岡会場では、諸事情ありメンターでもありTechTrain COO/CPOのsugitの特別LTを実施しました。

東京

よっしー
X：@yosssy424

会津

Shogo
GitHub：scarlet_7

名古屋

たく坊
X：@tak__it

大阪

ちゃんくろ
X：@ryota1582

福岡（特別編）

sugit
X：@sugitlab

毎年リアルな先輩の声が聞けて、参加した学生からも「やるぞ〜」と声が上がり盛り上がるニックトレイン。

実は、2025年に登壇してくれた先輩は、2024年のニックトレイン参加者がほとんど！

▼大阪会場登壇のちゃんくろさんの1年前のニックトレイン参加後の目標ポスト

「「「（来年ニックトレインで登壇）」」」

今日のイベントでモチベーションが上がったので今年の目標立ててみた
・行きたい企業さんへの内定（来年ニックトレインで登壇）
・Tech.Uniの後輩に万全の状態でバトンパス
・大学生活、馬鹿みたいに楽しむ（大学生らしい青春取り戻そうの会）
・自作app2つリリース

— ちゃんくろ iOS developer (@ryota1582) March 5, 2024

来年のニックトレインでは2025の参加者が登壇するかもしれませんね。今から楽しみです！

2026年度も実施できるようTechTrain頑張りますので、この記事を読んだ感想や気になったことのつぶやき共有など、ぜひたくさんの形でニックトレインの応援をよろしくお願いいたします！

▼2024年の先輩LTのアーカイブをみる

ご経歴を教えてください

東京工業大学在学中にXR開発に魅了され「これを仕事にしたい」と考えるようになる。卒業後、株式会社サイバーエージェントにUnityエンジニアとして入社。
入社式を終え、いざ配属というタイミングでグループ会社でVTuber事業が立ち上がるという話を聞き、「やりたい」と手を挙げ参画。その後、バーチャルプロダクションやメタバース事業部を経験し、XR周辺の分野に携わってきました。現在は、XR研究所所長としてApple Vision Proを活用した新しい体験の開発等、XR領域での事業創出にチャレンジしています。

また並行して、「好きな技術で社会インパクトを与える」ことを目指すIwaken Lab.でXR事例と人材を育てるための人生活動をしています。

Iwaken Lab.（イワケンラボ）について詳しく教えてください

Vision：バイネームで活躍する技術好きのサードプレイス

Mission：好きな技術で社会インパクト

Value：「志」とトガらせて言語化 / 面白い技術＆人間と「ワイワイ」/「勝手に」学び、発信 /「自分の土俵」で勝負 /「ときめき」ドリブンで「軽率」に行動 / 主人公のような「自分らしい」決断

このようなMVVを持つ、技術好きが集まるコミュニティで、現在のメンバーは、学生から社会人3年目までの57名が在籍しています。僕がXR領域を好きでやっているせいかXR好きなメンバーが集まりやすいですが、特に限定はしていません。自分の好きな技術を社会人になってからも追求し、人生の中に取り込めるようになって欲しいなと思っています。

どんな想いでコミュニティ運営をしていますか

Iwaken Lab.は、技術好き学生が抱える「もったいない」状況をどうにかしたいという想いでスタートしました。学生時代、XRを学んでいたものの、同じ領域にいる同世代の少なさに、孤独を感じていました。技術が好きでも、それを活かせる環境と思想が整っていなければ、その可能性が埋もれてしまう。そうした状況を何とかしたいと思ったのが、Iwaken Lab.を始めた原点です。さらに、XR市場はまだ成長過程にあり、例えばWeb技術と比べて仕事の選択肢が限られています。自ら仕事やマーケットを作っていかなければ、技術を極めた人材が活躍できる場が生まれないと考えています。Iwaken Lab.では、こうした課題を解決するために、高い熱量を持った人たちが集まり、語り合い、切磋琢磨しながら、自分の好きな技術 (XRなど) を活かして自分らしいキャリアを築くためのロールモデルを一緒に作り出しています。具体的には、志の言語化を一緒に行ったり、技術を活用できる活躍の場を創ったり、発信の支援を行っています。Iwaken Lab.のメンバー（通称ラボメン）には自走力のある人になって欲しいと考えています。自分自身が自走力を持ってキャリアを開拓してきたというのがありますが、その背景には、私が感銘を受けた『野村ノート』という書籍があります。この書籍は、野村克也監督が、当時低迷していたヤクルト球団を優勝へ導くまでの哲学や指導論を記した本です。小学4年生のときにこの本を読み、将来自分も「誰かの成長を加速させたい」と思うようになりました。

その影響で、中学でも野球部に入部しましたが、最も惹かれたのはランナーコーチ（走塁指示をするポジション）でした。高校時代は野球部のプレイヤーではなくマネージャーを志願して3年間やり抜きました。、大学時代は家庭教師、プログラミングメンターとして教育に携わりました。、きっかけは野球でしたが、振り返ると一貫していつも誰かの成長に向き合う立場にいました。

試行錯誤する中で、自走力の重要性に気づきました。そして、その力を伸ばすために、どのような言葉をかけるべきか、どのようなコミュニティ文化を設計すべきかというのを研究していました。ラボメンには、自走力を磨くことで成長スピードを加速させて欲しいと考えています。そのためにもIwaken Lab.は技術を愛し「自分を持つ人」を支援し、共に成長できるコミュニティであり続けたいと思います。

コミュニティでどのような成長を目指していますか

ラボメンには、自走力を身につけるために、入会時に私との1on1で自分の強み、やりたいことを明確にする機会を設けています。自分の強みを把握し、やりたいことが明確になれば、自走の土台が整うからです。

その時に大切にしているのは、単にXRをやりたいという思いだけではなく、なぜやりたいのか、どうやりたいのかをとことん話して志を尖らして言語化することを大事にしています。

例えば、福岡県在住のもふるねさんというラボメンがいるのですが、最初面談をした時は「XR開発が好き」というふわっとした思いの持ち主でした。ここから「なぜXR開発が好きなのか」「なぜ創作が好きなのか」という”なぜ”を繰り返し問いかけます。その結果、中学校時代まで遡り、中学2年生の時にジョジョの奇妙な冒険 (以降ジョジョ) の漫画にハマり、中学3年生の卒業研究でジョジョの発表をしてめっちゃウケたことが創作を好きになった原体験だと認識します。

そこから、彼がジョジョをテーマにした作品をBlenderやUnityで創作していることに気づきました。本人も一緒に面談して初めて認識します。

この「好き」に基づく継続的なアウトプットをもとに、他人に負けない「得意」を再認識し、「志」の言語化へとつなげていきます。最終的に「XR技術を活かした作品でジョジョの荒木先生とコラボする」という明確な志を言語化しました。

この志の言語化をしたことによって、彼の自走力は飛躍的に向上し、さまざまなハッカソンやイベントに積極的に参加。受賞や登壇などの実績を積み重ねる中で、次第にその名が知られるようになっています。

これはIwaken Lab.の私の活動の一部ですが、吉田松陰が作った松下村塾のように、ラボメンが5年後10年後のキーパーソンとなり、世の中を変えていく人を増やす「令和の松下村塾」を目指しています。

イワケンさん流キャリアの考え方を聞かせてください

まず、「得意」なことを認識することを大切にしています。「得意」とは、みんなにとってストレスだが、私にとってはストレスでない領域と定義しています。私の場合は、エンジニアでありつつも、他人の自走を応援すること、考えや感情を言語化すること、Unityのプロトタイプを素早く作れることが他人より「得意」なことだと認識しています。「なぜ他人を応援する事が好きなの？」と聞かれても、「なぜみんなはしないのだろう？」と思うほど、当たり前のことだと感じています。この当たり前の差分が「得意」だと考えています。

次に「得意」が求められるポジションや環境がどこか考えます。

例えば、プロトタイプが素早く作ることが得意であれば、新規事業系の仕事やスタートアップ環境が向いているかもしれません。考えや感情を言語化する能力が得意であれば、様々な職種とコミュニケーションをとる役割がフィットするかもしれません。

このように、「得意」を起点に環境を選ぶことで、無理なく力を発揮でき、自然とキャリアが広がっていくのではないかと考えています。

最後に、どうすれば「好き」を仕事にできるのかを考えます。私が大切にしているのは、「運」を磨く (確率を上げていく) という考え方です。そのために、常に準備をし、発信を続けることが重要だと思っています。例えば、私は「XR」が好きでしたが、最初から仕事として任されたわけではありませんでした。

仕事ではまず「得意」を活かし、さまざまな経験を積む一方で、「XR」については趣味の延長として開発を続け、社外のXRコミュニティで積極的に活動しました。その結果、社外での活躍が会社にも知られるようになり、ある日、「XR研究所の立ち上げを任せたいのだけど、どう？」とオファーをいただきました。さらに、個人としてもXRに関する仕事の依頼を受けるようになりました。

このように、「好き」を仕事にするには、無理に直結させるのではなく、まずは自分の「得意」でポジションを築きながら、「好き」を磨き続けることが大切です。そして、チャンスが訪れたときにそれを掴めるかどうかは、自分がどれだけ準備し、発信をしていたかにかかっていると思っています。

TechTrainメンターへの想いを教えてください

メンターになったきっかけは、XR領域以外の学生も応援したいという想いからでした。そして、TechTrainなら、自分の経験を活かして貢献できるのではと考え、メンターへの就任を決めました。「好き」な技術で生きていくという考え方は、一見楽しそうですが、その道は決して平坦ではありません。しかし、どのように登ればよいのかが分かれば、実践できるはず。私は、その可能性を探りながら実験しているのが Iwaken Lab. だと考えています。

実際、Iwaken Lab.の学生たちは、自分の人生に向き合いながら、納得できるキャリア選択をしてきました。そのプロセスの中で培われたノウハウや考え方を、より多くの学生にシェアしたい。そんな想いでTechTrainのメンターを続けています。

ここまで読んでくれた方へ一言

すでにあるレールを歩くより、新たにレールを作りたいと思う人とお話したいです。私は、人が「得意」をどうキャリアに織り交ぜていくのかを一緒に考えたり、言語化することが好きです。将来の業界や仕事を開拓していきたいけれど、どうすればいいのか迷っている人のサポートをしていきたいと思っています。

技術面では、Unityの非ゲーム領域が専門なので、興味がある方には具体的なアドバイスもできると思います。「イワケンといえばXR」という印象を持っているかもしれませんが、XRに限らず、キャリア相談や新しい分野を開拓するための作戦会議も大歓迎です！

一緒に、好きな技術で生きていく人生を作り出していきましょう！

インタビューありがとうございました！

イワケンさんのインタビューでは、「自分をどう表現するか」「何を大切にして生きるか」という深いメッセージを感じる事ができました。その姿勢がラボメンの方々に大きな影響を与え、成長する原動力になっているのでしょう。

自分の強みを見つけ、仕事を作り出す力を身につけてキャリアを切り開いていきたい方は、ぜひ”XR界の吉田松陰”イワケンさんと面談してみてください。

TechTrainでは今回インタビューに答えて頂いたイワケンさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

2024年度は、3箇所（東京・名古屋・大阪）。そして、2025年度はなんと新たに2箇所が加わり、5箇所（東京・会津・名古屋・大阪・福岡）にパワーアップして開催しました。

今回、2年連続各地で大反響だった先輩LTの資料をアーカイブにて公開します！まずは、2024年3箇所のアーカイブから。リアルな就活体験談は、これから就活を受ける学生はもちろん、採用をする立場からも同意の嵐間違いなし！

先輩エンジニアの皆さんも、今のエンジニア就活のリアルをぜひ体感してみてください。

『ニックトレイン』って何...？

ニックトレインのコンセプトは、"エンジニア就活を知る・肉を食べて元気をチャージ・同じ場所を目指す仲間と出会う"です。connpassにあるイベント説明は以下の通り。

エンジニアを目指す学生よ、この1年をどう過ごすかが 超重要 なのだ・・・

テストが終わってこれから春休み....でも、ちょっと待ったぁ！！！！
なんと、新卒の採用が本格的に始まるのは 卒業から2年前の10月 なんです。

つまり・・・？

この2月 から 9月 をどう過ごすかが、めちゃくちゃ重要なのです。

そう、2 から 9 ！！ニク！！肉！！

毎年、コンセプトの中にある「エンジニア就活を知る」という文脈では、セミナーではなく生の声として、1つ上の代の先輩のLTを用意しています。

それではここから先輩の資料を公開。

東京

ゆせ
X：@yuseidayo53

名古屋

Hiroki Yoshioka
X：@YoshiYoshiPro

大阪

ukwhatn
X：@ukwhatn

それぞれの会場で個性が異なるLTですが、リアルな準備や振り返りが聞ける貴重な時間。今までたくさんの就活生を見てきた私たちも首がもげるほど頷くくらいとてもリアルな内容でした。

そして、2025年の5箇所の先輩LT資料もアーカイブで公開します！お楽しみに🌟

2026年度も実施できるよう、この記事を読んだ感想や気になったことのつぶやき共有など、ぜひたくさんの形でニックトレインの応援をよろしくお願いします！

ご経歴を教えてください

現在は株式会社JMDCでモバイル領域を専門とするエンジニアマネージャー・スクラムマスターとしてヘルスデータプラットフォームの開発・事業推進をしています。

それまでは地元の高専に7年在学して卒業。新卒でエンジニアとしてとあるオーディオブックコンテンツの会社に入社しました。その会社は、ずっと好きだった本の音声コンテンツを扱う会社。事業内容に興味があったこと、そして同郷だったCTOとたまたま高専在学中に接点をもったことで、よりその志望度が高まり、入社を決めました。その会社では、PHPでのバックエンド開発とモバイルの開発に携わりました。2年経って退職し、少し期間を空けてからオンラインでフォトブックや年賀状を作るサービスを展開する会社へ転職しました。そこでは、フォトブックのAndroidアプリを開発するエンジニアとして機能追加の開発を担当。その後、現在在籍している株式会社JMDCに転職しました。

今までの会社を決めるタイミングで、私が大事にしていたポイントが3つあります。「給与面が満足できるか」「スキルアップができそうか」「事業内容を面白いと思えるか」です。この大事にしたいポイントは人によって選ぶポイントは異なると思いますし、全てを満たすか？というより、この3つのバランスをどう満たすかだと思います。また、入社時はマッチしていると思っても、キャリアを積む中でマッチ度は変化していくものです。この後お話しをしていきますが、どの会社も入社時点では3つにマッチしていましたが、キャリアを積む中で環境が変わり、この軸に対して違和感を感じた時に転職を決意しています。私の経験談を元に、皆さんのこれからのキャリアを歩むヒントを見つけてもらえたら嬉しいです。

初めての転職活動について聞かせてください

まずは転職活動のきっかけからお話しします。元々提供しているコンテンツが好きで入社をしたので、「事業内容を面白いと思えるか」については満たしていました。また、「スキルアップができそうか」については、新卒でまだ実務経験がそこまでなかったため、どこに入社しても身につくと考えておりあまりこの時には重要視していませんでした。「給与面が満足できるか」についても新卒だったこともあり将来的な期待値も鑑み納得しており、総合的にみて3つの軸とマッチしていると感じていました。ただ、モバイルアプリ開発に携わる中で、この分野を自分の専門領域として伸ばしていきたいと感じるようになりました。より高度な知識を得るためには、経験豊富なエンジニアのもとで学ぶことが重要だと考え、次の成長のステップとして転職を決意。

転職活動の第一歩として、まずは会社を辞めました。（これは本当におすすめしません。笑）転職先を決めずに辞めてしまったため、とにかく時間との勝負。動き出しとして、X（当時のTwitter）にブログの退職エントリーを投稿することにしました。加えて、当時あまり数の多くなかったAndroidとReact Nativeの経験を打ち出したところ、複数のDMをもらうことができました。エンジニアとして転職するためには自分の経験やスキルをしっかり言語化することが大事です。その中で市況感や自分のアピールポイントの中でどれを大きく前に出すかを考えることで、より多くの企業に出会うことができると感じます。最終的に、13社と面談し、5社の選考を経て2社目の会社に入社を決めました。

この転職活動の一番の失敗を挙げるとすると、転職先を決めずに退社してしまったこと。毎日貯金がなくなっていく恐怖を感じながら家計をやりくりすることに苦労したし、預金残高が気になり精神衛生上よくありませんでした。

2社目のマッチ度合い、そして2回目の転職活動はどうでしたか？

まず、2社目の会社で最も期待していたことは、3つのうちの「スキルアップができそうか」でした。その理由は、ここから先のキャリアをモバイルアプリエンジニアとして頑張りたいと思っていたことが関係しています。これまで、Androidエンジニアが1人の環境で、本当にこれで合っているのかという不安な気持ちを抱いて業務に当たっていました。そのため、2社目を選ぶにあたり、自分より知識も経験も豊富なロールモデルとなるAndroidエンジニアが在籍していて、今までにない学びの機会があるという点が一番マッチ度に影響していたと思います。給与に関しては、転職のタイミングということもあり希望を満たしていました。事業内容は、いいサービスだなと共感していたので、全体的にマッチしている感覚があり入社を決めました。

入社後は、期待通り、新しいことにも挑戦できて成長を実感することができましたが、ある日、師匠が退社することに。業務を引き継ぎ、必死にもがいたおかげである程度の知識がついた感覚と新しいチャレンジがあまりない事業のフェーズからやり切った感覚に、満足している自分がいることに気が付きました。

転職活動らしい活動はしていなかったのですが、このタイミングで、自分の希望年収を提示した上で企業からスカウトを受けられる転職サービスを利用し、希望する年収が実現可能ラインかどうかを確認をしていました。また、昔から興味のあったヘルスケアの事業に関わりたいな〜という気持ちが強くなり発信したところ、たまにチャットにリアクションをくれていた2社目の会社のOBからAndroidエンジニアとしてJMDCへのお誘いを受けリファラルで選考をすることになりました。

3社目のマッチ度は、いかがでしたか？

今までの「事業内容を面白いと思えるか」については、今まで、toCで自分が触って楽しそうなサービスかどうか？の観点で選んでいましたが、私自身、健康オタク（笑）なので、現在携わっているヘルスケア事業というのは自分の興味関心のど真ん中なんです。そして、ずっと興味があったマネジメントに未経験でも手を上げることを積極的に受け入れてくれる環境だという点で「スキルアップができそうか」も実現できそうだと思い、入社をすることに決めました。

現在、健康に関心が高い分、日々新しい発見がたくさんあり熱量高くプロダクトに向き合うことができています。また、元々、入社時はアプリを作るチームの所属は自分1人でしたが、今はメンバーが徐々に増えてきていて、実際にマネジメントに携わっています。

複数のポジションの異なるメンバーのいるチームでのマネジメントの大変なところは、調整などのコミュニケーション。ただ、会社という複数の人が集まってものをつくるためには、その調整が必要不可欠です。私は、ものづくりも人と人のコミュニケーションについても興味があるので、将来的にはものづくりを組織で円滑に進めるための「いい感じに調整できる」スキルを身につけたいですし、そういった調整力を身につけるのにとてもいい環境に身を置いていると日々感じています。

転職活動を失敗しないために準備しておいた方がいいことはありますか？

やっぱり、人に自分のことをちゃんと説明するための準備が重要だと思います。方法は色々ありますが、私がやってきた例でいえば退職エントリーブログやXの発信です。登壇経験なども良いと思います。さらに、このアウトプットを選考の際に書類に添えることで、自分がどういう考えをしていて、どういう経験をしてきたのかなど履歴書では伝えきれないことを知ってもらえ、面接の中で深い質問をしてもらえる確率が上がります。それだけではなく、自分がいいと思っている会社でも、実はマッチしていないのではということに相手側が気づいてくれる可能性もあります。2社目と3社目は会社側から声をかけてもらえ、自分から探すことなく採用担当者がわざわざ探しにきてくれたのは本当にありがたいことだと感じたので、「自分はこういう人ですよ」という発信は転職をする上で強い武器になりうると思います。

もちろん、ただアウトプットをすれば良いということではありません。先ほど話した通り、相手に伝えるためのものなので、私がアウトプットする上で意識しているポイントは、中学生に伝えても理解できる表現にすることです。決して難しい横文字は使わず、前提知識がない人が読める文章にしています。専門用語や横文字は、分かったつもりで分かっていないことがよくあり、そのような語彙を使ってしまうと自分の意図を正確に伝えることができなくなってしまいます。読み手が何も知らない状態を想定して情報発信をすることで、自身の細かい認識確認ができますし、丁寧に伝えることができる人だと思ってもらうこともできるのではと思います。

ここまで読んでくれた人へ、ひとこと

私はアウトプット作業を通して自分とはどういう人なのかを知ることが比較的得意ではありますが、多くの人は自分一人で自分のことを知ることは難しいと思います。私を含めTechTrainのメンターはいろんな経験をしてきた人が多いので、壁打ち相手にもってこいだと思います。一人で悩まず、ぜひ相談しにきてください。

また、無職の転職活動は絶対やめた方がいい！と声を大にして伝えたいです。本当にきつかったので。無理をし過ぎる前に環境を変えることは大事ですが、今思えば、もっと早めから転職の準備をしておけばよかったと思います。決して転職をおすすめしているわけではありませんが、いざという時に転職できる準備をしておきたいならば、少しもやもやするなと思った時が始め時かもしれません。転職活動をしていると伝えてもマイナスに受け取られることはほぼありませんし、カジュアルに話を聞きにいくのはおすすめです。社外を見ると意外と社内の良さに気がつくこともありますしね。

転職活動の相談、そしてAndroidやReact Nativeについてのご相談はお気軽にどうぞ〜！

ありがとうございました！

転職が当たり前になっている今の時代、いつ転職の転機が訪れるのか、その時にちゃんと転職できるのか不安な方も多いのではないでしょうか。mrtryさんの経験談は転職成功のヒントがたくさん詰まっていますのでぜひ参考にしていただき、悩んだ時は相談してみてくださいね。

TechTrainでは今回インタビューに答えて頂いたmrtryさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

メンター紹介

Ruby on Railsとは？

Ruby on Rails（Rails）は、Rubyというプログラミング言語で書かれたWeb開発フレームワークです。”Rails”という名前のとおり、決まったルールや手順に沿って開発を進めやすいのが特徴。 MVCモデルというWebアプリを「データ管理（Model）」「画面表示（View）」「処理の制御（Controller）」の3つに分けて整理する仕組みとなっていることで、開発が分かりやすくなり、変更や修正がしやすいことも特徴です。
「Hello world!からIPO(上場)まで」と言われるように、1人で手軽に作れる小規模なアプリから、大企業向けの大規模システムまで対応可能なスケーラビリティがあります。直感的で手を動かしながら身に付く初心者にも学びやすいフレームワークなので、ロードマップを参考にぜひチャレンジしてみてくださいね！

さっそくここから、「Railsは小さなアプリから、複雑な大規模アプリケーションまで作れる万能な感じが好き」と語るAmaneさん直伝の学習ロードマップを紹介します。

オススメは以下の5つ！

Amaneさんおすすめの学習コンテンツとして以下の5つをご紹介いただきました！

1. Ruby on Rails チュートリアル
2. プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)
3. texta.fm
4. オブジェクト指向設計実践ガイド～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
5. Rubyの仕組み

学習の進め方

RailsはWeb開発フレームワークです。そのため、”Web”自体の仕組みを理解してから取り組むことで、よりスムーズに学習を進めることができます。例えば、フロントエンドやバックエンドがそれぞれどういうものなのかや、データがWebによってユーザーにどう届いているのかというデータベースの仕組みなど。もちろん、完全に理解していなくても良いので、Webの仕組みの大枠をつかんでからロードマップに入ると良いでしょう。

また、ここで案内する学習の進め方は、Ruby単体ではなくRailsへ繋げてより実践的な活用を身につけることを目的としたロードマップとなっています。
Rubyという言語は、直感的で理解しやすいと思うので、初心者にも扱いやすいと思います。そのためまずはRuby on Railsを学習しながら実際にRubyを触ってみて、を学習しながら、躓いたところを調べていく方法がおすすめです。
このロードマップもインプットをすることだけをメインとしておらず、手を動かしながら身につけていけるコンテンツを前半に置いています。直感的に書くことができ、楽しくWEBアプリケーションを作れるRailsの世界を、みなさんも体感してみましょう！

①Ruby on Rails チュートリアル 

Railsを学ぶなら必須のコンテンツ！ここを通らずしてRailsを習得する人はほとんどいないというくらいみんな初めに取り組んでいる教科書の基礎問題のような存在です。初めて学ぶ人にも難易度が適切で、最低限必要なものが揃っています。Web上で、実際のアプリケーションを作って手を動かすことができるところが最大のメリット。

Railsチュートリアルのよいところは手を動かしながら進められるところなので、少しずつ理解を深めることができます。
とはいえ最初は学ぶ内容が多いと思うので、1回ですべて理解するというよりも、何回も繰り返し繰り返し、5周くらいする気持ちを持って、少しずつ理解を深めて行くのが良いかと思います。
それくらいの長い目で見ると、まずは写経するくらいの気持ちでまずは完走しきってRailsの雰囲気を掴むことからスタートして、2回目以降を繰り返しながら復習や、理解を深めながらやることが大事。

まずは知る → 覚える → 自分でやってみるという段階を踏みましょう。

やはり、プログラミングは見て覚えることはできないので、そのためには自分で手を動かすことが必要です。この手を動かすというステップまでWebで完結できるので、Railsチュートリアルを最初に持ってきています。

このタイミングで、詰まったりわからなかったところは公式ドキュメントを読むのがおすすめです。

• Ruby on Rails Guides
• Rails API
• Ruby API

以下は公式でないので注意してくださいね。

• Rails ドキュメント

また、理解するフェーズとしておすすめした2周目以降は、アレンジを加えながら進めていくと力がつくと思います。例えば、3周目はTODOアプリの実装部分をブログの実装にしてみよう、などです。ぜひRailsチュートリアルの中で色々試してみてください。

“「理解できているかどうか」は、実際にやってみてバグやエラーなど教科書にないところで初めてわかります。間違えないと理解が進まないので、積極的に間違えていきましょう！
by Amaneさん”

②プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ) 

タイトルに「プロを目指す人のための」とあるように、実際に現場で使われる書き方でRubyを学べる書籍です。
この本の1番のおすすめポイントは、Rubyとは？という入門でありながら、Railsで使われる書き方を元にしてRubyを学べる内容となっているところ。
実例を元にした書き方の事例から、それがどういったRubyの構造なのかを解説してくれています。こう書けばいいんだな〜のイメージができるようになったタイミングで読むと良いでしょう。Railsチュートリアルで足りないRubyについての部分をいい感じに補完してくれるので、Railsチュートリアルが教科書だとすると、この本は試験で応用問題を解く練習をするための参考書のようなイメージです。

TechTrainでRailsに取り組んでいる方は、以下のタイミングに読むとより理解が深まるはずです。

1. Railway Ruby入門編[URL埋め込み]でRubyやWebの仕組みを知る
2. Railsチュートリアルで手を動かす。（何周かしてね）
3. Railway Ruby on Rails初級編で手を動かす。（何周かするのがおすすめ）
4. 『プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)』を読む
5. Railway Ruby on Rails基礎編で手を動かす。

“自分の場合は、Railsチュートリアルを何周かしていける！と思っている時に読み、「こんな書き方があるんだ」とかなり勉強になった書籍です。皆さんも、ぜひ、「Railsを理解した！」と思ったときに目を通して、さらに理解を深めてもらえたらと思います。
by Amaneさん”

③ texta.fm

Yasaichiさんがピクスタ株式会社CTO時代に収録されたt-wadaさんこと和田卓人さんの会話が聴けるポッドキャスト。Amaneさん的激推しコンテンツです！Railsの実装イメージがまったくないと理解できないかもしれないので、実務を経験して少し経ち、中級者になるくらいで聴くとよいかもしれません。Railsの現場でより良い開発をするためにが詰まったコンテンツとのことなので、ぜひ聴いてみてください。

ソフトウェアにまつわるいろいろな概念や『パーフェクトRuby on Rails』の内容についての解説がメインの内容です。
「コードを書いて開発する」から「設計する」という抽象度の高いタスクをこなすためのステップアップにつながること間違いなしのコンテンツです。よい設計ができるようになるためには、言われたとおりにコードをただ書けるだけではなく、よりシンプルな設計にしなおせないか？という視点を持って、ときには要件から調整する必要もあります。そのためには今使っている技術やアーキテクチャの深い理解が必要ですが、ことが必要になります。このコンテンツを聴くことで、Railsを抽象度の高い目線で捉え直すきっかけになると思います。

“実務経験1年くらいの人にはぜひ聴いてほしい！Railsの現場でより良い開発をするためには必聴コンテンツと言ってもいいかなと思います。自分としては、聴いてて「そうだよね〜」や「楽しい！」となるので、その感覚を皆さんにも味わって欲しいと思います。
by Amaneさん”

④オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

こちらの本も中級者向け。③はRailsをもとにした設計を話していますが、この書籍はRubyを使ったソフトウェアを書く上での考え方を知るのに向いている本です。実務でアプリケーションのアーキテクチャ設計に触れるまたは、理解していた方が良い場合には読んでおいた方が良いでしょう。

アプリケーションとは？の部分やRubyを使ったソフトウェアの例を書いてくれていて、例えば、どういうクラス作っていくかや設計をしていくかというヒントがあります。アプリケーションの「ふーん」くらいの感じでしたが、実務に入って1年経ったくだいで読むと「なるほど」と理解できるようになってきたので、ある程度実務経験を積んでから読むのがおすすめ。設計プロセスの過程を自転車作りに例えて説明しています。流れがあるため、辞書的に読むのではなく、前から順番に読むことで理解が深まります。

“経験を積めば積むほど業務の抽象度はどんどん上がっていきます。視座を上げるためには読んだ方が良い本です。この本の内容は、知っていた方がより良い設計ができます。コードを書くことからより上流に携わる時には、読んでみてくださいね。
by Amaneさん”

⑤Rubyの仕組み

Rubyの概念そのもの自体が実務に活きるわけではありませんが、実務の中でパフォーマンスやスピードを考える際には、Rubyがそもそもどういう言語か？を知ることが必要になってきます。

プログラミング言語の仕組みを学ぼうと思うと大学の学位レベルでのコンピュータサイエンスの知識が求められるので、上級者向け。最近、身の回りでは実務を経験した中級者以上のエンジニアがこの本を読み始めている印象です。

Railsが大体わかってきたあとにRailsを構成するプログラミング言語であるRubyに興味が出てくるのは自然な流れかなと思います。自分もRubyを使って働き始めて3年目ごろから興味が出てきて勉強を始めました。

ただ、RubyKaigiやKaigi on Railsといったカンファレンスや地域.rb(Shibuya.rbなど)といったコミュニティに参加すると、自然と好奇心やモチベーションが出てくるのではないかなと思います。特に、年に1回行われるRubyKaigiは海外の方もたくさんきますが、日本の人も多く登壇するカンファレンスなので、分からないことを日本語でも英語でも、直接Rubyのコミッター（制作者）たちに質問できるので、Rubyそのものに興味が出るきっかけになりやすいはず。

“直接業務に効いてくるとは言えませんが、よりRubyでテッキーな部分を極めていきたいと思ったら、勉強すると良いと思います。”

まとめ

Ruby on Railsの魅力は、とにかく早い、標準で搭載されてる機能が多く一人でぱっと作れるところ、それだけでなくひと工夫すれば大規模なサービスにも対応できたり、スケーラビリティがあるところも魅力的で、挙げ出したらキリがありません。

“直感的に書いていけるし、本当に書いてて楽しいフレームワークです！日本語でのカンファレンスで身近なところもハードルが高くないと思うので、ぜひRubyKaigiやKaigi On Railsにも参加してみてくださいね。

by Amaneさん”

2024年の12月にGoogleから「Android XR」と呼ばれるXRデバイス用のプラットフォームが発表されました。GoogleからのXRプラットフォームの登場により、さらにXRデバイスへの期待が高まっています。

そこで本記事では、前編と後編に分けてエンジニアとして知っておきたい「Android XRの基礎知識」と「Android XR向けサンプルアプリの作成」について解説します。

前編(基礎知識編)では発表されている情報をもとにAndroid XRの基礎知識や現在地について、後編(アプリ作成編)ではJetpack XR SDKを使用してAndroid XR向けのサンプルアプリ作成について解説する予定です。

Android XRの基礎知識とアプリ開発方法について知りたい方はぜひ一読していただければと思います。

Android XRとは？

Android XRとはヘッドセットやグラスなどのXRデバイス用のOSです。スマートフォンにおけるAndroid OSのようなイメージで、今後様々なメーカーがAndroid XRを搭載したデバイスを発売していくことが予想されます。

2025年にはSamusungからAndroid XRを搭載した「Project Moohan」と呼ばれるヘッドセット型のデバイスが発売予定となっています。また、ARグラスを手がけるXREALもAndroid XRのパートナーとなっており、グラス型のデバイスの発売も予想されています。

Android XRの特徴

他のXRデバイスやOSと比較して、Android XRならではの特徴があります。

1. Google Play Storeのアプリが使用可能

Vision OSがiPadやiPhone向けのアプリに対応しているのと同様に、Android XRでもGoogle Play Storeで公開されているAndroidアプリを利用することが可能です。*1

*1: NFCなどハードウェアに関連した一部の機能を必要とするアプリはAndroid XR用のストアでは非表示となります。
詳細: App manifest compatibility considerations for mobile and large screen apps

既存のAndroidアプリ資産を活用することで、コンテンツ不足に悩まされることなく充実したXR体験ができることが予想されます。ただし、よりXRフレンドリーなアプリを作るには、後述の大画面表示への対応やXR独自の機能を提供する必要があります。

2. AIの活用

Android XRの公式ページに以下のように紹介があるように、AIとの連携が重視されています。

Android XR is an AI-powered operating system coming soon to headsets and glasses. 

AIを活用した機能として、例えば以下のような機能があります。

Gemini(AIアシスタント)との連携

会話を通じて、デバイスのコンテンツを操作したり、表示されている内容やデバイス越しに見える現実世界について、さまざまな情報を得たりすることができます。

リアルタイム翻訳

デバイス越しに見える現実世界の文字を翻訳して表示したり、会話している相手の音声をリアルタイムで翻訳することができます。

かこって検索

スマートフォンでも利用可能な、かこって検索の機能がAndroid XRでも使用できます。視界に入っているものを囲むジェスチャーをすることで、それについての情報を検索することができます。

Project Astraとの連携

Prject Astraと呼ばれるAIアシスタントとの連携も視野に入っており、今後グラス型のデバイスへの展開が期待されています。*2

*2:Project AstraはGoogle DeepMindのプロジェクトであり、マルチモーダルな入力(音声、視覚情報など)や過去のやり取りの記憶を処理して、タスクを実行をする次世代のAIアシスタントの開発を目指すプロジェクトです。

GoogleのYouTube動画を見るとどういう未来を想像しているのかわかると思います。めちゃくちゃ未来を感じられるので一度見ておくことをおすすめします。

Android XRのスペースについて

ここからは少し開発寄りの解説をしていきます。

開発に関する前提知識として「スペース」について解説します。

Android XRではスペースと呼ばれる場所でアプリが実行されます。 スペースには「ホームスペース」と「フルスペース」の2種類があります。*3

*3:解説に利用するイメージは、公式ドキュメントの以下より引用。
https://developer.android.com/design/ui/xr/guides/foundations

ホームスペース

ホームスペースは、図のように複数のアプリを並べて操作できるモードです。 既存のAndoridアプリはこのホームモードで動作し、ユーザは制限の範囲内でアプリの画面サイズを自由に変えることができます。

フルスペースモード

フルスペースモードは、図のように1つのアプリが全体を占有するようなモードです。 3Dモデル等を使用して360度の没入感のある体験を提供することができます。 このモードで既存のAndroidアプリを実行するには、後述のJetpack XR SDKを用いた、Spatialize(空間化)対応の実装が必要になります。

Android XR向けアプリの開発手法

Jetpack XR SDKを使用することでAndroid XR向けのアプリを開発することができます。

Jetpack XR SDKは、AndroidアプリをSpatializeするためのライブラリが含まれているSDKになります。 AndroidアプリをフルスペースモードでXRデバイスの特徴を活かしたアプリを提供したい場合は、このSDKを用いて開発をする必要があります。

Jetpack Compose for XRと呼ばれるXR向けのUIをComposeで書くためのライブラリや、Material Design for XRと呼ばれるXR向けのガイドラインに沿ったUIコンポーネントライブラリなどが含まれます。

詳細は割愛しますが、その他にも、Unity、 OpenXR、 WebXRを使用して開発することができます。

既存アプリのXR対応について

既存のAndroidアプリはAndroid XR上でも動作しますが、XRへの対応状況によって以下の3段階に分類されます。*4

*4:動作イメージは、公式ドキュメントの以下より引用。
https://developer.android.com/develop/xr

XR compatible mobile app(XR対応モバイルアプリ)

XR compatible mobile appは、大画面対応されていないAndroidアプリになります。基本的にはモバイル端末での使用を想定したアプリなので、XRの広い空間を有効活用しづらくなります。

XR compatible large screen app(XR対応大画面アプリ)

XR compatible large screen appは、モバイルに加えてさまざまな画面サイズに対応したアプリになります。例えば、タブレットやFoldable対応がなされているアプリはこちらに分類されます。

パネルのサイズを自由に調整することができ、レイアウトも崩れないため、XRの広い空間を有効活用してより良いユーザー体験を提供することができます。

XR differentiated app(XRに差別化されたアプリ)

XR differentiated appは、XRならではの機能を提供するアプリです。3Dモデルなどを使用し、XRデバイスの特徴を最大限に活かした、没入感の高いユーザ体験を提供することができます。

XR体験をより良くするためにも、最低限、最後に紹介したXR compatible large screen app(XR対応大画面アプリ)に対応できると良いかなと思います。

まとめ

本記事では、エンジニアとして知っておきたい「Android XR入門」の基礎知識編として、Android XRの基礎知識について解説しました。

次の記事では、Jetpack XR SDKを使用して簡単なサンプルアプリを作成する方法について解説する予定です。お楽しみに！

いかがでしたか？

最新技術の情報を分かりやすいようにまとめてくれていますよね。記事の内容や公式ドキュメントに書かれているさらに詳しい内容について気になることがあれば、TechTrainの面談からYusukeさんに質問も可能です！

みなさんの「記事、読みました！」の声がメンターにとっても運営にとっても励みになります。読んだ方は感想などを伝えてもらえたらとても嬉しいです。

メンター執筆シリーズについて

メンター執筆シリーズはこれからも定期的に配信中。

次回はいよいよYusukeさんからXR Androidのサンプルアプリをつくる実践編。基礎知識編を繰り返し読んで準備しながら、次の記事の公開を楽しみにお待ちください！

最初にプログラミングに触れたのは、高校時代にブログサイトを作りたいと思ったときでした。当時はnoteのようなブログサービスがなかったので、ブログを作る！となれば、ゼロから作る必要がありました。

最初に、独学でHTMLを、さらにできることの幅を広げるためにCSSを学び、学んだ技術をもとにサイト内に設置したら面白そう！と思っていた様々な機能、例えば、ユーザーが投稿できる掲示板やアクセスカウンターなどのプログラムを書き始めたのが原体験です。当時は”プログラミングをしている”という意識はなく、ましてや将来エンジニアとしてばりばりコードを書くようになるとは想像もしていませんでした。

その後どのような経緯でエンジニアになりましたか

実は、学生時代はまだエンジニアになろうと思っていませんでした。

そんな私の社会人のスタートは、ソフトウェア開発会社の営業職。業界はIT業界ではありましたが、テレアポなどの営業がメインの仕事。ただ、仕事に取り組む中で、営業の業務よりも顧客管理データをエクセルでマクロ組んで自動化させているときの方が楽しいと感じていました。営業職は合ってないかも...と思い、インフラエンジニアとして初めての転職。基本情報技術者資格は持っていましたが、プログラミングの経験は趣味程度で、データセンターなどの物理サーバの経験は皆無の未経験状態で業務をスタートしました。ただ、この時もまだエンジニアとしてずっとやっていこうという気持ちではなく、営業よりはまだ自分に合っているし、大変でも将来のためになればいいなという想いで、ただただ必死に業務をこなしていました。

そんな中、たまたま目にした株式会社ALBERTのインフラエンジニアの求人が自分のそれまでのインフラエンジニアの経験とマッチしていたので応募し、再び転職することに。ALBERTでは、データシステムの開発業務に携わったので、インフラのみならず、データエンジニアリングやデータベース周り、データ基盤設計構築など技術の幅を広げることができました。それまで経験した企業とは異なり、ALBERTは上下関係がないフラットな関係性であることに衝撃を受け、ベンチャーらしい自由な雰囲気が自分にフィットしました。ちょうどその頃からコミュニティ活動を始め、カンファレンスに登壇したり技術書籍の執筆や Python x データ分析のコミュニティ「PyData.Tokyo」の立ち上げをするなど精力的に取り組みました。仕事半分、趣味半分のような感覚で人とつながりコミュニケーションがとれるのがとても楽しく、公私ともに充実した日々を送れるようになり、エンジニアとして今後もやっていこうと思えるようになりました。

起業しようと思ったきっかけは何でしたか

ALBERTの創業者にはアントレプレナーシップ（起業家精神）があり「チャレンジするといい」と日常的に聞く環境だったので、いつか自分も起業チャレンジをしてみたいと思っていました。執行役員としてIPOを経験してひと段落したタイミングで、起業する決断をしました。

2015年頃の日本国内では今ほどSaaSがメジャーでなく、僕は海外のSaaSやツールを比較して使ってみることもありましたが、費用感があわなかったり使い勝手が良くなかったという経験があったので、日本版Atlassianのようなグローバルに通用する開発者フレンドリーなWebツールを生み出したいという意識でSaaS開発に着手しました。

起業して良かったことはありますか

起業初期はひとりしかいなかったため、プロダクトを一人で作りきるということをしていました。その経験がエンジニア人生の中で最も技術力を伸ばしてくれたと思います。必要に駆られてフロントエンド・バックエンド・インフラなど何から何までを自分でこなし、当時Reactの黎明期だったと思いますが、モダンフロントエンドについて何が分からないのか分からないような状態から学習していました。振り返ってみれば、この時最も技術力が伸びたと実感しています。

こう感じた背景には、前職で途中からマネジメントに転換していたことが関係しています。マネジメントに転換したタイミングで、業務中に自分がコードを書く機会が格段に減りましたが、当時の開発チームはAngularJS（現在の Angularの初代バージョン）といったフロントエンドのフレームワークを習得し実装している状態でした。実際に現場でコードを書かない僕はそのフレームワークを使えないという点に、ある種のコンプレックスを持ちながらマネジメントをしていたと思います。プロダクトを一人で作り、技術力がアップした結果、フロントエンド技術に対する苦手意識はなくなり、現在のCTO業務における技術の下支えになっていると思います。

最終的に約4年で会社を畳むことを決め、そのタイミングでメンタルヘルスに関する事業を立ち上げようと誘われ、2019年株式会社AwarefyにCTOとして入社しています。

現在、CTOとしてどのような役割を担っていますか

今の僕の役割として最も重要なのが技術起点で社会課題と経営課題を結び付けて事業推進することだと考えています。CTOはTechnologyに最も長けているべきなので、技術起点で事業に取り入れたら良いのではという価値を発見したり組み合わせること、その結果ユーザー起点で事業の価値をどのように感じてもらえるのか、最終的に企業の経営にどうプラスの効果を導くのかを総合的に考えていくことが重要だと思います。

代表からも、「Technologyで何か面白いことをやってくれ」と期待されているので、技術起点・ユーザー起点の両視点で考え、より良いヘルスケアの実現を目指しています。

過去の経験の中で、今のCTO業務に活きている点はありますか

ALBERT時代のマネジメント経験は、今でも非常に活きていると思います。執行役員という立場でしたが、経営者がどのような視座で仕事をしているか、といったことを学ぶことができた機会でした。

また、1回目の起業ではゼロイチ含め会社経営全般を一人で進め、2回目はCTOとして創業期からジョインしてゼロイチを経験しましたが、1回目の起業でのゼロイチフェーズで培ったプロダクトにもくもくと向き合った経験も活かせています。

プロダクトの立ち上げ段階では人との調整業務はほぼなく、プロダクトとユーザーしかないので、”どんなプロダクトだとユーザーは価値を感じてもらいお金を払うのか”をひたすらに考えます。1回目のサービス立ち上げの時はがむしゃらに考え行動したので、知っていたら避けられていた失敗がありました。

Awarefyの立ち上げでは、その時の反省を活かしCTOとしてちゃんと無駄は省きつつ創業期のゼロイチフェーズで必要なことにフォーカスして進めていきました。ファイナンスやプロダクト含め、ゼロイチ立ち上げの守破離の「守」を知った上で、必要な時に考え決断することで無駄な失敗を避けることが出来たのではないかと思います。

起業経験が、CTOとしての足かせになっていることはありますか

強いて言えば、起業したとき会社経営に必要な労務周りなどバックオフィスも自分でやっていたため、現職でもCTO業務範囲外のことでも気になってしまう点です。基本的にはチームに任せているので僕が関与する必要はありませんが、業務を分かってしまうがために覗いてみて、効率化の提案をしてしまったりします。CTOとして、プロダクトを大きくしていくことを最優先事項として取り組むべきだと分かっていますが、いろいろ経験した分関心事が広くなり、分散してしまうのが欠点かもしれません。

今後、どんなCTOが求められ、どんな準備が必要になりますか

2025年はAIエージェント元年と言われていますが、CTOの役割のひとつであるチームの組成において、AIの導入を前提にチームビルディングを考えていく力が必要だと考えています。業務効率を上げることはできないか、AIの導入により少数のチームで遂行できないかを考えられるようになると良いでしょう。そういったAI視点、思考の材料となるAI知識、業務に取り入れる実務経験の重要性が増していると感じています。

また、CTOに限らず、もっというとエンジニアに限らずですが、AIを使いこなす力がこれからますます求められます。AIとよりよいコラボレーションを行うには？という思考を巡らせることができるCTOやエンジニアはエンパワーメントされ、活躍の場が広がると思います。

AIの発展が凄まじい昨今、僕はXで流れてくる情報や海外のビックテックの経営者の発言や取り組みなどから最新情報を得ることが多く、そこから考えをアップデートしています。情報を見聞きするだけではなく自分で触ることが大事だと思うので、AIを導入することで本質的な業務効率につながるのかを判断し、事業の中にうまく取り入れることを目指しています。

TechTrainユーザーに一言メッセージをお願いします

エンジニアとして、インフラ、バックエンド、フロントエンド、モバイルと環境に応じて何でも挑戦し身につけてきました。起業した経験では、プロダクトはつくれるけど収益があがらない、といった手痛い失敗も経験しました。プロダクトに関わる人や物をひとつのシステムとして捉える目線に加え、「本当にユーザーに求められるサービスになるのか」「利益が出るか？」という厳しい目線も養ってきたと思います。

ユーザーに価値を感じてもらうためにどのようにすれば良いか、悩む時はぜひご相談ください。そういった悩みは抽象的であることが多いので、漠然とした状態でも大歓迎！プロダクト開発の壁打ち相手になりますので、一緒に悩みましょう！

TechTrainでは今回インタビューに答えてもらったいけぴさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

どのようなきっかけでエンジニアを目指しましたか

私のキャリアは最初からエンジニアとして始まったわけではありません。京都の大学に入学後は外国語学部英米学科で英語やアメリカ・イギリスの文化を学んでいました。当時は、「英語を学べば、世界中の人とコミュニケーションを取ることが出来る！言語の壁がないのは素晴らしい」という思いから、通訳や翻訳の仕事を目指していました。

念願叶って新卒で通訳として就職を果たし、社内のインド人エンジニアと他のメンバーとのコミュニケーションの橋渡しを担うことに。実は、その入社先はゲームのモデリングを開発する会社で、英語ができるだけでは全く通訳ができない事態に。やはり、エンジニア同士の会話を翻訳するには、英語の知識に加えて、Webやアプリケーションの知識が必要不可欠でした。もちろん、勉強の一環としてサイトを作ったりしましたが、少しかじった程度の知識で通訳をするのは無責任だと思ったことがきっかけで、「いっそのこと、しっかり学ぼう」と通訳の仕事を辞め、プログラミングスクールに通うことにしました。これが私のエンジニアキャリアのスタート地点です。

通訳からエンジニアへの職種転換は大変でしたか

まず、スクールを卒業してからエンジニアとして就職するまでに苦労しました。カリキュラムでRuby on Railsを学びましたが、ただ学んだだけでは就職することができず、次のステップとして職業訓練校でJavaを学び、Androidアプリ開発に取り組むことを選択しました。アプリ開発の経験を積むことでようやく名古屋のWeb制作会社に就職を果たすものの、ここでも再び壁にぶつかってしまいました。就職した会社は、目指していたアプリ開発ではなく、HTML、CSS、JavaScriptなどを使ったLP制作やWordPressでのサイト制作がメインだったのです。求められる仕事と自分のやりたい仕事にギャップがある環境を変えようと意を決し、上京してSESに転職。その転職先での初めての案件は客先常駐。プロジェクトの内容は結合テストや管理業務で、開発ではなくエクセルと8時間にらめっこする日もありました。またしても目指す環境とのギャップに苦しみましたが、次の現場で、ようやくLaravelでのバックエンド実装を経験することができ、次第にもっと広くエンジニアリングに挑戦していきたいと思うようになりました。

通訳を目指していた学生時代から「グローバルで働く」というビジョンを持ち続けています。「通訳」と「エンジニア」は、職種は違えどビジョンを達成するための手段として共通している点が多くありました。もちろんゼロベースで経験を積み上げていく大変さはありましたが、目標ドリブンの私にとって、もっと挑戦していきたいと思えたこの開発経験は前向きになれる転換でした。

具体的にどのように挑戦の幅を広げましたか

「グローバルで働く」ためにエンジニアとしてどう経験を積み上げていくと良いか考えた時、さらにスキルアップが出来る環境に身を置きたいと思うようになりました。

その想いから、開発の経験をより積むことができる受託開発の会社に転職し、LaravelをメインにしつつTypeScriptやVue.jsなどを使うプロジェクトに3〜4件携わりました。その時印象に残ったプロジェクトが1つあります。それは、JavaScriptを使ったとあるプロジェクト。メンバーの中でJavaScriptを書けるのは自分しかいない状況だったのです。この時は、期待とプレッシャーを一身に受け、苦労した記憶があります。バックエンドとして入ったにも関わらず、JavaScriptをゴリゴリ書き、しかもその実装はネイティブアプリ、クラウド、バックエンドが全て絡み合う箇所で技術的な難易度が高い部分。加えて納期も日に日に迫ってくる環境もあり、私はオーバーヒート状態でした。大変ではありましたが、振り返ってみれば、切羽詰まった経験を潜り抜けたことで、一歩一歩成長できていると思います。

どうやって壁を乗り越えてきましたか

苦しい時期に、周りの人に恵まれ、相談をできる環境だったのは大きかったと思います。体力的にも精神的にも辛いことは2度や3度ではなく、エンジニアをやめようと思ったこともありました。そんな時に周りに相談できたお陰で、励まされ、支えられ、「将来笑い話にできればいいや」という気持ちで乗り越えることができたと思います。自分の中に「ここで辞めてしまったら自分には何も残らない」みたいな気持ちもあり、ちょっと無理してきた部分もあると思いますが、何度も乗り越えるうちに乗り越えられる壁のレベルが上がっていきました。その結果として、現在はSRE・クラウドサポートを行う会社にフロントエンドエンジニアとして転職し、また一歩目指すビジョンに近づいている実感があります。

エンジニアは、就職してからも途中で挫折する方もいるくらい大変な仕事だと実感する部分も多くあります。でも、一人で乗り越えられないときに相談できる人がいるだけで、余裕が生まれてちょっと楽になれると思うので、私を含むTechTrainのメンターに頼って欲しいと思います。

苦労した経験から、学んだことや成長したと感じることはありますか

実感する成長は、やはり技術力です。受託会社に転職するまでは、開発すると言っても管理画面を作るなど一部分だけであったり、作り切ったプロダクトの改修など幅広い技術知識がなくても対応出来る業務ばかりでした。ゼロから作っていく経験を通して、自分の知識が”技術を使える”レベルで止まっていたことに気づきました。要件の棲み分け、クラウドの知識など異なるレイヤーの関与がある業務を通して、総合的な技術力アップにつながったと思います。

また、壁の乗り越え方が上手くなったと思います。忙しくなり目の前の業務に追われると、つい自分を見失ってしまいますし、どんな成長ができているのか認識できず、ただただ苦しいだけになってしまいます。そんな時、私は思考や経験を整理しアウトプットしてすることを大事にしています。例えば、知識や経験をまとめたブログを書いたり、今までの経験・スキルを一覧で見ることができるポートフォリオを2〜3ヶ月の頻度で更新します。こうすることで、大変な仕事があったとしてもアウトプットにして自分の糧にしようという前向きな気持ちになることができますし、今まで何をやってきて、ビジョンに向けて何が足りていないのかを客観的に見直す機会にもなります。もちろん、一人で考えることも大事ですが、いろんな人と話した上で内省すると、より客観性が増すので、アウトプットとセットで人との交流の幅を広げていくことも大切にしていることのひとつです。

これからの挑戦を教えてください

現在は事業会社で、チーム開発やプロジェクト理解・スキルレベルの異なるメンバーがいる環境を前提とした開発・レビュー文化などの今まで経験したことのない開発フローに挑戦しています。今まで経験してきた環境とは考え方や業務フローが異なり、今もなお成長するために挑戦し続けています。そして、将来はいろんな側面を持つ人としてグローバルに働くことを目指しています。そのために、英語、エンジニア、スクラムマスター、TechTrainメンターなど多方面に活動の幅を広げ、しっかりアウトプットして自分というカタチをブランディングしていきたいと考えています。今はまだ0、1、2と積み上げている状態ですが、いつの日かそれが10にも100にもなって活躍できるように、これからもひとつひとつ積み上げていくことを継続していきたいと思います。

ここまで読んでくれた方に一言

私は、エンジニアになるまでもなってからも結構苦労をしてきたと思うので、皆さんの苦労や辛さに共感できます。一方で、苦労することでより成長できる事実も人一倍知っていると思います。なので、エンジニアとして成長したいという気持ちを持ち続け、試行錯誤を繰り返していけばきっと成長出来ると思いますが、一人一人考え方も異なればやりたいことも違うので、その人にあったやり方を一緒に考えていきたいですね。私もまだ道半ばの人間なので、皆さんと一緒に成長していきたいと思っています！「こんなこと相談してもいいのかな？」「ちょっと人生に悩んでいて...」という相談も大歓迎です。私の経験がみなさんの成長の後押しになれたらうれしいです。

エンジニアを目指している人、エンジニアとしてのキャリアに迷いがある人、まさに現場で壁にぶつかっている人にもきっと役立つヒントが詰まっている内容でしたね。Ugoさんは、人の気持ちを人一倍理解し、労わり、そっと手を差し伸べてくれるメンター！頑張りたいけど、頑張ることに疲れたときはUgoさんに相談してみてください。きっと一歩を踏み出すきっかけになるでしょう。

TechTrainでは今回インタビューに答えて頂いたUgoさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

HRに足を踏み入れたきっかけを教えてください

私のキャリアは、決して順風満帆ではありませんでした。高校卒業後、アメリカの大学に進学しましたが、「大学で勉強してるよりも早く社会に出て実力を試したい！」という強い思いから中退を決意。日本に帰国後、就職活動をするものの、大学中退という経歴に対する社会の目は厳しく、50社以上に書類を送っても、書類選考通過0件という厳しい現実を突きつけられました。さらに、24歳の誕生日直前に東日本大震災が発生し、内定取消になるといったことも重なり、かなりツラい時期を過ごしました。しかし今振り返ると、自身この苦しい時期と重なった震災だったからこそ、頭の中に当時の印象が強く残っており、それが後述する福島県の被災地に再建された高校でのキャリア教育や、昨年の仙台移住に繋がっているのかもしれません。

初めて正社員として働いたのは、映画祭イベントの企画運営会社でした。イベント事業の他に人材派遣事業も手掛けており、バックオフィス管理や人事の仕事を幅広く任されました。この経験を通して、フロントに立つよりも縁の下で力を尽くす仕事に魅力を感じるようになり、次第にHRの仕事を次のキャリアとして本格的に考えるようになりました。

どのようにHRの経験を積んできましたか

様々なフェーズ、事業の企業でHRを経験する中で、スキルや経験を磨き上げていきました。

2社目のDMM.comでは労務をメインに担当。比較的システム周りが得意だったこともあり、SmartHRの導入をリードするなど、HRにおけるプロダクト選定の経験を積むことができました。また、チーム再編の流れで採用やマネジメントなどチーム作りも経験し、メンバーに権限移譲することの大切さや、一人ひとりにあった目標設定による働きがいの醸成の大切さを学びました。この経験は、後にスタートアップで1人目○○を脱却し、チームを組成するうえで非常に役立ちました。

そして大きな組織での経験を経て、次は縦割りではなく幅広い業務を経験できる、少人数スタートアップでのHR業務に挑戦したいと考えるようになりました。また、過去に自身が就活で苦しんだ経験から、大学で学んだスキルなどが就活では見向きもされず、大学の総合偏差値等で評価される社会に疑問を持っており、それを打破したいという想いから、理系学生向けダイレクトリクルーティングサービスを提供する株式会社LabBase（旧社名 株式会社POL）に転職。面接のタイミングでは社員数約10名、2ヶ月後の入社のタイミングでは約20名に、そして退社する1年3ヶ月後には50名超にまで増え、組織がどのように成長するのかを当事者という立場から見ることができました。余談ですが、LabBase時代に副業で手伝ってくれた、現TechTrainエンジニアのスーさんとのご縁で、今回メンターにジョインする運びとなりました。

LabBase退職後、キャリア×教育をより追求したいという思いから、友人が以前インターンしていた認定NPO法人カタリバを紹介してもらい、1年間キャリア教育を担当。福島県の中高一貫校に赴き、キャリアの選択肢を生徒と一緒に考えたり、学外の人とのつながりを生み出す活動をしました。2022年から高校で「探究」という授業が義務化されるのに先駆け、先進実験校として学校の先生たちと一緒にカリキュラムを考える機会にも恵まれました。「探究」は、課題を自分で設定し、解決していく必要があり、まさに仕事と同じ頭の使い方をするので、今までの社会人経験を活かすことができました。

カタリバでの任期を終え、LabBase時代から副業としてジョインしていた地域創生系のスタートアップである株式会社おてつたびにて正社員として参画。コーポレート周りの立ち上げや広報チームの立ち上げ、SNSマーケ、カスタマーサポートなど幅広い業務を担当しました。

そして現職であるUbieとの出会いは、たまたまスカウトをもらったことから始りました。Ubieは当時から人事として面白い施策を実践していることで人事界隈でも有名で、社員全員が組織作りに力を入れている企業でのHRポジションの挑戦は非常に魅力的でした。そして過去に教育系NPOで一緒に活動していたメンバーがUbieに在籍していたことも後押しとなり、一度は内定を辞退したものの、最終的には転職を決意。Ubieでは、アクセラレーター本部という組織で人事や労務、組織文化作り、採用、海外子会社の管理など多岐にわたる業務を担当しています。

Ubie株式会社での組織作りについて詳しく聞かせてください

Ubieは組織作りにかなり力をいれていますが、中でも特徴的な2点をお話しします。

1点目は、会社のカルチャーを徹底的に言語化していることです。ホームページやnoteなどのサイト上でUbieのカルチャーに関する資料を多く見つけることができると思いますが、創業初期からコンサル出身のメンバーが多く、考えを言語化・可視化することに長けていることもあり、以前より言語化にはこだわりを持っています。また組織や事業のフェーズの変化に合わせてカルチャーを常にアップデートしています。トップダウン・ボトムアップを上手く組み合わせながら、全社員でカルチャーを議論し徹底的に言語化する過程で、カルチャーが社員一人ひとりに徐々に浸透していき、最終的にはメンバー同士の共通言語となり、意思決定における優先順位や基準となります。こうしたカルチャーへのこだわりが、Mission・Visionの達成に役立っていると考えています。

2点目は、カルチャーにマッチする人を採用することにこだわっていることです。いくら組織作りに注力しても、たった一人カルチャーに反する人が入ることで一気に崩れてしまう組織を過去にいくつも見てきました。採用は単にスキルや経験だけでなく、その人が会社のカルチャーに合うかどうかを見極めることが重要だと考えています。一方でUbieでは採用面接官は人事だけが行なうのではなく、原則、全社員が面接に参加しています。むしろ人事が面接フローに入らないことの方が大多数です。そのため、面接におけるカルチャーの見極めには工夫をしています。

カルチャーが候補者に”合うか合わないか”をどのように見極めていますか

候補者と会社のカルチャーマッチを測る上で、UbieではValueを更に分解したUbieness/Umapと呼ばれるスタンス・コアスキル項目を面接で利用しています。こちらは各項目ごとに行動指針のようなものが明記されており、Ubieの社員自身も自己成長の物差しとして普段社内で利用しているものです。これらの各項目に紐付いた質問例を用意することで、人事以外のメンバーが面接を行なっても、カルチャーマッチの見極めができるようになっています。

また面接では会社が一方的にカルチャーマッチを見極めるのではなく、候補者の方もUbieのカルチャーを見極めてほしいと考えています。Ubie社内では「パクチー採用」と呼んでいるのですが、Ubieのカルチャーが好きな人もいれば、合わないと感じる人がいても正解だと思っています。そのなかで、Ubieのカルチャーが好きと感じる人と一緒に働きたいと考えているので、過去には行動指針をより具体・言語化した【Do's and Don'ts】をカルチャーガイドとして公開するなど、カルチャーの言語化と公開/透明性がカルチャーのミスマッチを防ぐ上で重要と考えています。

TechTrainユーザーに一言メッセージをお願いします

ここまで読んでくださった皆さんに向けたエールとして、自分の考えを大切にし、自分が活躍できる環境を見極めることが大事だと伝えたいです。入社する側も、会社側にとっても、お互いのカルチャーがあっているかを見極めることが大切だと思っています。決して、ネームバリューだけで判断せず、自分の価値観やライフスタイルに合った企業を選んで欲しいと思います。特にこれからの時代、生成AIの発展などでスキルや環境、経験の差は小さくなっていくからこそ、自分が会社で何を成し遂げたいのかが、自身の成長に繋がると考えています。

今まで組織作りや採用・教育など人事領域で多くの人を見てきた経験、カルチャーマッチ見極めの慧眼はあると自負しているので、今の会社が自分と合っているのか悩んでいる方や、選考を受ける企業とのカルチャーマッチに不安がある方は、ぜひ面談しましょう！

インタビューありがとうございました！

社会人生活は波乱のスタートから始まり、様々な企業でHRとして経験を積んできたGisshiさん。キャリアを選ぶ上で、カルチャーが合うか合わないかの見極めの重要性を語っていただきました。価値観の言語化、カルチャーマッチの見極め、今後の進路に悩む方は、ぜひキャリア教育のご経験もあり、言語化の最強メンターのGisshiさんに相談してみてください。

TechTrainでは今回インタビューに答えて頂いたGisshiさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

YUMEMI.growとのコラボ開催について

YUMEMI.growとは、株式会社ゆめみが開催する勉強会の総称です。 最新の技術や業務で得た知見・ベストプラクティスなどの情報共有、 エンジニア同士の交流を目的としています。この目的に沿って、今回は若手エンジニアが主動となって企画した勉強会をTechTrainと一緒に開催する運びとなりました。勉強会の開催に慣れているYUMEMI.grow うーたん(@uutan1108)さんの手解きを受けつつ、今回メインで運営をしてくれたのはゆめみ24卒エンジニアいまいまい(@imaimai17468)さん。

若手開催のオフライン勉強会を盛り上げようと、ゆめみの先輩エンジニアのみなさんが多数参加してくれていました！（素敵...！）

今回のテーマは”リファクタリング”。このテーマに決まった背景をちらっと公開。

まず、「新卒3年目ぐらいまでのミドルクラス」、「若手が意識したいweb開発のあれこれ」というターゲットを設定。それならと、若手がこれからぶつかるであろうリファクタリングをテーマとして採用しました！

当日は、それぞれ実際のプロジェクトで経験したリファクタリング、このテーマを話すためのプロジェクトを立てたリファクタリング、それぞれの自分の経験をもとにその振り返りと、意識することを発表する場となりました。

当日のLT資料アーカイブ

• 『remedaのpipeを使ってデータフローをリファクタリングした話』infixer/@ryo__kts
• 『デザインシステムを始めるために取り組んだこと』梶川 琢馬/@kajitack
• 『昔の自分に教えたいレイヤー・責務・検証のハナシ』Hajime Nakagawa/@yumemi_hajimism
• 『テーブルの型付けを改善した話』Yugo Yagita/@ygkn35034

『remedaのpipeを使ってデータフローをリファクタリングした話』

infixer
マークアップおじさん
アクセシビリティとかやってます

なんと...当日朝10:30ごろに登壇決定からの準備での登壇でした。すごい...

『デザインシステムを始めるために取り組んだこと』

梶川 琢馬
2023年TechBowl入社。
プロダクト開発をメインに、リアーキテクトやデザインシステムの立ち上げにも取り組んでいます。
趣味はトライアスロン。今年はアウトプット頑張るぞ！

取材として潜入している私自身はエンジニアではないのですが、自社プロダクトの裏側を聴けるのも勉強会参加の嬉しいところ！

『昔の自分に教えたいレイヤー・責務・検証のハナシ』

Hajime Nakagawa
2023年新卒で株式会社ゆめみ入社。
フロントもデザインもやってます！

とってもわかりやすい比喩で、みんなが「あ〜つらい」という声が漏れるレイヤー・責務・検証のハナシ...

『テーブルの型付けを改善した話』

Yugo Yagita
2023年新卒で株式会社ゆめみ入社。 開発者体験の向上やアクセシビリティなどに興味があります。

「「「実務で役立つ型プログラミング、あります！」」」のひとことがとっても印象的でXでも呟いている方を見かけました。

勉強会の懇親会ってどんな話をするの？

LTが話題の議論や気になった部分の質問はもちろんですが、年齢やポジションの異なるエンジニアが集まれば雑談や相談も飛び交います。勉強会に馴染みがなかったり、参加してみたいけど未知の世界！という方へ、懇親会で出てた話題をこっそり公開しちゃいます。

• 社内の採用やスタック、開発のリアルな現場の話

• 「エンジニアって、サービスデザインに興味ある人ってどれくらいいるのかな？」
• 「デザインエンジニアに必要な要素って、どんなこと？」
• 「最近React Nativeキテるよね！」
• 「実際問題定年っていつになるの？？？？」

美味しいケータリングとお酒も入って、生の現場の話を聞くことができるのもオフライン勉強会ならでは！

TechTrainでは、今後も勉強会を開催していくので、気になる方は予定をぜひチェックしてみてください。

告知

次回のTechTrain勉強会は、株式会社ロジレスさんとの勉強会となります。

ロジレス×TechTrain『現場の生々しい実装のお困りごと見せます！』

今回も、会場はSHIBUYA STARTUP OASISさんです！（いつもありがとうございます）

参加のお申し込みは以下から。（参加無料）

皆様とお会いできること、楽しみにしております〜

💪つよナレとは？？

つよナレは、株式会社TechBowlが提供する勉強会コミュニティです！

• つよつよエンジニアのナレッジ の略語「”つよ”+" ナレ"」
• つよつよを目指すエンジニアへ向けての想い「”つよ”く+"なれ"」

の2つの意味が込められています！

"弊社のメンターを含む様々なつよつよエンジニア（通称：つよつよ）" と "つよつよを目指す若手エンジニア（通称：つよなれ）" が決められたテーマに対してLTを行い、「あーだー」「こーだー」と様々な観点から意見をいい、知見を交換し合う場を提供しています！

🔍テーマ：「2024年振り返り。やってみて良かったTips」

第2回めのテーマは、「2024年振り返り。やってみて良かったTips」

• 初めてイベント/カンファレンスに登壇した感想
• 今年はこんなツール/技術を使って良かったので聞いてほしい
• 初めてOSSコントリビュートしてみました など

つよつよやつよナレの皆さんの昨年を振り返りからTipsを聞けるLTとなりました。

録画アーカイブ

📚登壇資料

つよつよ💪

Amane Inoue / 株式会社マイベスト

@isaka1022
株式会社マイベスト Databaseミッション DevLead。2021年に新卒1期目として株式会社マイベストに入社し、データベースやランキング周り等バックエンドの開発から新規事業まで幅広く担当。直近ではデータベース領域におけるAIの活用に注力。2025年サハラマラソン挑戦予定！

『チームリードになって変わったこと』

keigo / 合同会社Steg

@Kspace_trk
2020年の大学3年次に、合同会社Stegを創業。 Vue, Nuxtを用いたWebアプリケーション開発を得意とし、受託開発や新規サービス開発に取り組んでいます。 Vuejs-jp のコアメンバーも務め、最近は Vue Fes Japan 2024 の広報チームリーダーとして貢献しました。

『もう二度と迷走しない！極端なタスク分割 実践編』

つよなれ👨‍💻

na2kera / TechTrain ユーザー

@na2kera_0510
大学生。開発団体PeachTechに所属し、現在はフロントエンドを中心に勉強中。TypeScriptを使用した個人開発やチーム開発がメイン。Cursorの魅力に取り憑かれ、彼が書きやすいようにコードを整えるのに尽力しています！最近は25卒の知り合いと共に振り返りプラットフォーム「リフティ」の開発に闘志を燃やしたり、技術イベントにも積極的に顔を出しています。

『Xの募集に乗っかったら今年のターニングポイントだった話』

第1回の資料アーカイブはこちらから！（こちらは動画アーカイブはありません）

💪つよナレとは？？

つよナレは、株式会社TechBowlが提供する勉強会コミュニティです！

• つよつよエンジニアのナレッジ の略語「”つよ”+" ナレ"」
• つよつよを目指すエンジニアへ向けての想い「”つよ”く+"なれ"」

の2つの意味が込められています！

"弊社のメンターを含む様々なつよつよエンジニア（通称：つよつよ）" と "つよつよを目指す若手エンジニア（通称：つよなれ）" が決められたテーマに対してLTを行い、「あーだー」「こーだー」と様々な観点から意見をいい、知見を交換し合う場を提供しています！

🔍テーマ：「PHPにまつわる話」

初回となる今回のテーマは、「PHPにまつわる話」

• PHPを良く触っていた「あの頃のPHP」
• 業務ではそこまで触らないが私生活で「ふと触るPHP」
• マイナーバージョンアップ8.4を控えた「最新のPHP」など

皆さんにとってPHPはどのようなものでしょうか？？
つよつよエンジニアのナレッジやつよなれの若手エンジニアの視点からPHPに関わる幅広LTを聞ける良い機会ですので、ぜひご参加ください！

📚登壇資料

つよつよ💪

ytake / 千株式会社 CTO

@ex_takezawa
千株式会社 CTO。Go、Scalaを利用したデータ基盤開発、インフラストラクチャ分野の改善・再構築、マネジメントやプロダクト開発のサポートやデータ戦略などを担当。スケーラブルなアプリケーション開発、ストリーム処理、リアクティブシステムやマイクロサービスアーキテクチャの支援、ドメイン駆動設計導入サポートなどにも携わる。）

『ステートレス VS ステートフル 状態管理と並行性』

sadnessOjisan / TechTrain Mentor

@sadnessOjisana
TechTrainを立ち上げた2019年からメンターをしています。Webのクライアント開発がエンジニアキャリアの出自ですが、段々とCDNからバックエンドまで守備範囲を広げていき、最近はクラウドの仕事もしています。Webに関する開発は何でもします。最近はTechBowlの開発アドバイザリーもしており、ETLの構築やモノレポ化・マイクロサービス化を手伝っています。

『PHPだからこそOpenTelemetryが嬉しい』

つよなれ👨‍💻

ukwhatn / TechTrain Jr.Mentor

@ukwhatn
近畿大学4年、25新卒エンジニア。現在はJr.MentorとしてTechTrain Railwayのチャットサポートを行っています。大学入学前からコミュニティ向けのWebアプリ等を開発しており、現在はWebバックエンドエンジニアをしながら、趣味でコミュニティ運営や学生エンジニア向けのイベント運営をやっています。普段はPythonやTS、Ruby on Railsを使うことが多く、インフラ管理からフロントエンド実装までなんでもやります。

『初心者こそバニラなPHPでWebアプリを作るべき』

shy / TechBowl副業エンジニア

@iam_soheyyyy
23年卒の新卒2年目。TechBowlには2021年よりエンジニアインターンとしてjoinしていました。2023年3月に就職のため退職しましたが同年8月より副業として再join。現在、本業では認証認可基盤周辺サービスの設計・開発をしています。

『TechBowlのPRレビューで指摘されたこと』

今回は録画アーカイブはなしとなっております。（ごめんなさい！）

登壇資料を読んで、メンターに質問したいことがある、実際に取り組んでみた！などぜひ皆さんの糧にしてもらえたら嬉しいです。

次回公開のつよナレ#2のアーカイブは録画あり！

以下からチェック！

経歴を教えてください

学生時代は、まだWebが一般的ではない時代でグラフィックデザイナーを目指し、美大に通っていました。卒業当時にFlashなどのマルチメディアコンテンツが台頭し、Web技術に興味を持ったことがきっかけで、新卒ではDVDパッケージやFlashコンテンツの制作を行う会社に入社。その後よりWebに近い領域に携わりたい想いから、Webサイトやアプリのデザイン・実装を行う制作会社へ転職しました。グラフィックデザインやWebデザイン、HTML/CSSコーディング、フロントエンドの実装など幅広く経験し、Web技術の基礎を確立できたと思います。

しかし、クライアントワーク中心だとプロダクトを継続的に改善する機会が少なかったため、自社プロダクトを成長させる仕事に魅力を感じ、事業会社であるさくらインターネット株式会社へ転職。サーバーのコントロールパネルのUI設計やフロントエンド開発などを担当しました。そこから副業も始めるようになり、複数の企業でデザインの仕事を並行して行うようになりました。

その後、株式会社SmartHRでプロダクトデザイナーとして4年間、インターフェース設計やデザインシステムの構築、フロントエンド開発を担当。前職である株式会社Algomaticでは、横断組織CoSとして会社全体を支援する業務やコミュニティ形成支援などに取り組みました。

今ではエンジニア・デザイナー・アドバイザーとして、多角的にキャリアを展開しています。

どのような背景で、副業をスタートしましたか

一社にのみ所属していると「自分が今どのような価値を発揮しているのか」が客観的に見えにくいと感じたことが大きな理由です。たとえば、外部から指摘されるまで給与が相場より低いと気づかなかったように、自分がいるコミュニティの中だけだと“当たり前”が固定化されがちです。

ちょうど転職先のさくらインターネットが「やりたいこと」を「できる」に変える、というビジョンを持っており、副業にも柔軟だったことから、自分の市場価値を客観的に捉えたいと考え始めました。

実際に副業を通じて、さまざまな企業や人と関わる機会が増え、新しい視点を得られたり、異なる価値観に触れて刺激を受ける場面が多くなりました。そこから「イベントを一緒にやろう！」といった声が生まれ、コミュニティ活動も本格化していったのです。

コミュニティ運営を詳しく聞かせてください

2022年から、まずはプライベートでPodcast配信やコミュニティイベントをいくつかスタートしました。こうした活動は、営利目的だけではなく、同じような悩みや興味を持つ人たちと“面白い”と思えることを一緒にできる場を作りたいという想いが大きいです。

中でも主催を務めるテックコミュニティ「CrossRel」で開催した「R35 Meetup」というイベントは、35歳前後の人々がキャリアへの迷いや将来の生き方について率直に語り合う場として企画しました。テック業界を中心に、さまざまな価値観を持つ人が参加し、新しいつながりが生まれる良い機会になりました。私自身、人との出会いによって大いに助けられた経験があるので、今後もコミュニティを通して、人と人が交流し、知見やアイデアを交換できる場を提供していきたいと思っています。

AIの進化によってエンジニアやデザイナーの働き方は大きく変化すると考えられますが、そんな時代だからこそ、人と人とのリアルなコミュニケーションを大切にし、知識を共有し合うコミュニティの存在意義はさらに増すと感じています。

R35 Meetupについて、最後に告知あり！

AI時代となった今、デザイン業界の展望を聞かせてください

ここ数年の一大トピックであり、私自身も非常に強く関心のある「生成AI」ですが、昨今の急速な普及と高度化により、作業効率は格段に向上しました。たとえば、デザイン制作にかかる時間をAIが大きく削減してくれるケースも増えています。私自身、作業をAIに助けられたことで、ブランクを感じることなく業務に取り組めた経験もあります。

一方で、AIに任せきりにすると、人間が実際に手を動かし試行錯誤する機会が減り、人の“経験学習”が蓄積されにくいとも感じます。AIが高度な回答を返してくれる一方で、そのプロセスを学べないままでは、本質的な問題解決力が育ちにくいからです。

だからこそ、エラーや問題の根底を探り、論理的に捉える思考力がますます重要になります。TechTrainのように課題解決力を磨く場や、思考のプロセスを共有し合うコミュニティが、今後さらに必要とされるはずです。

ズバリ、デザイナーに求められるスキルとは

ハードスキル

• アーキテクチャの原理原則や思想
• デザインの基礎知識や色彩論などの原理
• プログラミング言語や設計手法などの成り立ち

AIによってある程度のアウトプットが得られる時代だからこそ、基礎となる理論や背景を深く理解しているかどうかが差別化につながります。AIの答えを鵜呑みにするのではなく、なぜそうなるのかを自分で考察できる知識と経験が大事です。

ソフトスキル

• コミュニケーション力
• チームワーク
• 事業ドメインの深い理解

これからはプロフェッショナルの個人プレイだけではなく、複数の専門家が連携してよりよいサービスを形作る時代です。ユーザーやクライアント、そしてチーム内外とのコミュニケーションを円滑に行い、信頼関係を築いていける人ほど活躍の場が広がると思います。

また、信頼できるメンターや仲間からフィードバックを得ることが、成長の近道です。AIを使う際にも、人から正しい情報や経験に基づいたアドバイスを受けながら活用することで、より実践的なスキルへとつなげられます。

ここまで記事を読んでくれた方へ一言

サービスをゼロから立ち上げる際には、ドメインとプロダクトデザインの知識があることで、圧倒的にスピード感を持って開発が進められます。そして、その上でシステムの基盤やブラウザの仕様などを理解していると、より本質的な部分を把握しやすくなり、質の高いアウトプットを生み出せるでしょう。

デザイナーとエンジニアの業務領域は密接に関わっており、デザイナーがプログラミングを学んだり、エンジニアがデザインの考え方を身につけることは、これからの時代を生き抜くうえで大きな武器になるはずです。

TechTrainには、テクノロジー業界を支えるエンジニアやデザイナーが多数在籍しているので、信頼できるメンターを見つけて一緒に成長を目指してみてください。応援しています！

こぎそさん、インタビューありがとうございました。

デザインとプログラミングの関係性や、これからのデザイナー・エンジニアに求められるスキルについて、たくさんの学びがありました。AI時代にキャリアを築いていきたい方は、ぜひこぎそさんとの面談を検討してみてください！

TechTrainでは、こぎそさんをはじめ150名以上のメンターが登録しており、無料で1on1メンタリングを受けられます。サイドメニューの「面談予約」から、ぜひメンタリングを予約してみてください。きっと新しい視点や知見を得られますよ。

イベント告知

インタビュー内に登場したテックコミュニティ「CrossRel」主催の「R35 Meetup」。

次は3月に沖縄で開催されます。なんと...TechTrainからCPO sugitが登壇！LTタイトルは『品質第一の業界とスピード第一の業界の経験から見えてきた、PMのキャリア（仮）』
JTCからスタートアップと環境の変化から見えてきたプロダクトマネジメントのお話をする予定です！

＼ 沖縄でsugitと握手！！！！ ／

では、その言語やフレームワークは「いつまでも使える」技術と言えるでしょうか。

おそらくほとんどの場合、その答えは「No」だと思います。

ソフトウェア開発の歴史を振り返っても、何十年と同じ知識と同じコードで成り立っている技術は私の知る限りありません。時間が経てば新しい言語が登場し、従来の課題を解決する新しいフレームワークが作り出され、さらにはその技術自体の開発やメンテナンスが止まってしまう可能性すらあります。

たとえば私が使っているFlutterも、開発を主導しているGoogleが「これ以上Flutterの開発にリソースをかけない」と決めたらどうなるか、予測はできません。そのリスクを理由にFlutterは使わないと判断している開発者も少なくないでしょう。

ではそれが現実になったとき、次に使う別の技術の学び直しは「ゼロからやり直し」になってしまうのでしょうか。今まで学習に費やした時間と労力はすべて無駄になってしまうのでしょうか。

これは「学び方による」と考えています。

そこでこの記事では、別の技術を学ぶ際に「強くてニューゲーム」できる学び方について考えてみたいと思います。

※「強くてニューゲーム」とは
ゲームを一度クリアした時点（もしくは進行途中）のアイテムやレベルデータを引き継いで新たに最初から始めること。一度目よりも効率的にゲームを進められ、一味違った楽しみ方ができるシステムです。

学び方を学ぶ

「強くてニューゲーム」するためにはいくつか学び方のコツがあります。そのひとつ目は「学び方を学ぶ」ことです。

たとえばモバイルアプリ開発を例にとった場合、GPSデータを扱いたい、アプリケーション全体の設計を考えたい、環境構築をしたい、などのいろいろな課題に対し、みなさんはどのように調べてどのようにそれを解決するでしょうか。

もしもパッと検索して出てきた適当な技術記事を真似して済ませているようであれば赤信号です。

たしかに「とりあえず動かす」ことを目的とするのであればそれで良いかもしれません。しかし、「この場合は、こうする」のような場当たり的な調べ方や学び方は、扱う技術が変わって前提が変わった時に役に立たなくなり、「ゼロから学び直し」が発生してしまいます。

一方で、課題を分解して整理し、適切な調べ方を考え実践し、より適切な解決策を模索する、そんなひとつひとつのステップを意識することで、「学び方」や「考え方」という基礎的なスキルが身につき次の技術を学ぶ際に活かせます。つまり「強くてニューゲーム」できるというわけです。

ちょうど良さそうなコードを拾って適用する、というやり方ではなく、GPS自体の仕組みについて調べるところから始めたり、アプリケーション設計について議論している本を読み、公式ドキュメントで正確な情報を得る、という学び方や調べ方を実践してみてください。他にもGitHubやDiscordなどのコミュニティで質問する、記事を書いてフィードバックをもらう、ライブラリを作って公開する、などの経験は扱う技術に関わらず活かせるスキルになるはずです。

比較する

2つ目のコツは「比較する」ことです。

人の脳の作りとして、同じ情報をインプットするにしても、ただ頭に入れようとするよりも何か既存の知識に紐づける方が理解が早く深くなるそうです。

たとえばFlutterには「宣言的にUIを構築する」という考え方があるのですが、このことをただ覚えようとするよりも従来の「命令的なUI構築」と比較する形で学ぶことでより学習が効果的になると実感しています。

言語同士の考え方や機能の違い、プラットフォームごとの特性や制約の違い、システム全体における各レイヤーの優先順位の違いなど、ソフトウェア開発する上で「比較」できる観点はいくらでも存在します。

しかし、「比較する」ためには既存の技術に対する確かな知識が不可欠です。あやふやで不正確な知識を基に比較をしても意味がありません。たとえば「命令的なコーディング」を知らない状態で「宣言的なコーディング」と比べようとしても学ぶべきものが2倍に増えるだけです。

比較をすることで学習は効率的になりますが、そのためには比較対象としての今扱っている技術への理解が不可欠です。その意味でも、よくわからないまま実装して動いたからOKとするのではなく、先述した通りに課題や調べ方を考え、その仕組みを深く理解することを今から実践してみてください。

まとめ

目の前の技術を学ぶ目的は、決してその技術を使うためだけではありません。適切な学び方で身についた確かな理解は、別の技術を学ぶ上で大きな助けになるはずです。

そう考えると、「今何の技術を学ぶのに時間を費やすべきか」という点はあまり大した問題ではなくなります。今やりたい技術が将来的にどれだけの期間使い続けられるかと悩んでいるくらいであれば、少しでもその技術を深く学ぶことに時間を費やし、少しでも早く実際のソフトウェアを開発する経験を積むべきだと考えます。

何かひとつ技術を習得すれば別の技術を学ぶことは難しくない、とはよく言われますが、それはこの記事に書いたようなことが理由にあるのではないかなと思います。

技術の将来性というのはとても不確かな要素です。それを気にするよりも、今使っている技術や気になっている技術をより深ぼって詳しくなることに集中してみてください。将来的に別の技術を学ぶことになったとしても、今の技術に対する理解と経験は必ず活かせるはずです。

いかがでしたか？

読んでからすぐに意識できるTips満載でしたよね。記事の内容について気になることがあれば、TechTrainの面談からちゅーやんさんに質問も可能です！

みなさんの「記事、読みました！」の声がメンターにとっても運営にとっても励みになります。ぜひ読んだ方は感想などを伝えてもらえたらとても嬉しいです。

メンター執筆シリーズについて

メンター執筆シリーズはこれからも定期的に配信中。

次回の記事も続々準備中です！公開を楽しみにしていてくださいね〜。

ちゅーやんさん直伝「強くてニューゲーム」なFlutterの学習ロードマップも公開中！

ご経歴を教えてください

中学生の頃から人間の認知や学習などに興味があり、慶応義塾大学の環境情報学部（SFC）に入学。学部の頃はことばの発達や確率的な意思決定などの認知科学をメインに学び、修士ではそろばんのエキスパートの神経ネットワークを解明する脳科学の研究をしました。在学中、研究室の先輩が立ち上げた教育系ベンチャー企業で約5年間インターンシップに参加。インターン生にいろいろ学ばせてくれる環境であったため、仕事の取り組み方、デザインの考え方などをイチから叩き込んでもらいました。入社当初はこっぴどく叱られる日々でしたが、1年くらい経つと先輩から指摘されることが減り、デザイナーとして一人前に近づけたと思います。

新卒では、日系大手の金融系SIerに入社。インターンシップでベンチャー環境を十分体験できたので、次は社会的影響力を持ち、世の中に貢献している日系企業に入社しようと思ったのが理由です。入社後は、デザインの発想や考え方を評価され、社内で最大級の予算規模のWeb系システムの再構築プロジェクトにアサインされ、システム開発の最上流を経験しました。大学院やインターンシップでやってきたことに囚われず、ゼロから叩き上げてもらおうという気持ちで入社したので、とてもいい機会に恵まれました。

その後、同級生が立ち上げたスタートアップにプロダクトを立ち上げるタイミングで1人目の社員として転職しました。

なぜ転職をしようと思いましたか

大きなプロジェクトに関われたことは良かったのですが、プロジェクトが大きい分、自分の関わっている要素が小さくなってしまいました。自分で考えたプロジェクトにこそ情熱を持てるタイプであることに気が付き、裁量多くプロジェクトに関わりたいと思うようになったのが、転職を考え始めたきっかけです。

転職準備として、まずは自分で作りたいものを作れるようになろうと考え、働きながら独学でプログラミングを学びました。ちょうどRuby on Railsがスタートアップ界でよく使われるようになった頃でしたので、Ruby on Railsから学び始めました。その後、目的に合わせてTypeScriptやPythonに得意分野を広げていきました。

転職をする上で、どのようなことを大事にしましたか

いつか0→1のプロダクト開発をやってみたいと思っていたので、スタートアップへの転職を第一に考えていました。30,40代になってからスタートアップに携わるのはちょっと怖いと感じていたので、20代である今飛び込んでみようと思ったことがきっかけです。

また、スタートアップで働くことは決して楽ではないと覚悟していたので、共に苦境を乗り越えられる人がいることを重視していました。事業をスケールさせるための思考力や行動力、物事に向き合う熱量や真面目さを持つメンバー、信頼できる経営者の下で働きたいと思っていました。

そんな会社を探していたところ、起業した同級生に声を掛けてもらい、事業フェーズが私の理想と合致していること、信用できる人であったことから転職を決断しました。

同級生の会社で働いてみていかがですか

特にデメリットは感じず、むしろ働きやすいと思います。学部の頃から存在を知っていて、すごく仲がいいというわけではなくお互いに顔を知っている程度でしたので、いい距離感で仕事ができていると思います。

最も大きなメリットは、お互いの性格やコミュニケーションスタイルを知っていることです。価値観の観点でも、ビジネスにおける決断軸、プロダクトへの熱量や課題に向き合うスタンスが私と似ていると感じます。大学や研究室が一緒だったから、という理由だけではないと思いますが、少なからず興味関心が近いという意味で影響しているかもしれません。

働く上で、会社組織をどう作っていくか、チームをどうまとめるかなど「ヒト」に重きを置く人と、ビジョンを実現するためにどうサービスをどうデザインするのかの「モノ」を追求する人がいると思います。代表の同級生は「ヒト」を、私は「モノ」を重視するタイプで、それぞれに異なっていることも補完し合えるいい関係だと思います。

「コト」へのこだわりを詳しく聞かせてください

私の「コト」へのこだわりは、プロダクトを通して高いクオリティで新しい体験を実現することです。今までBtoBプロダクトをメインに携わってきたのでその領域で言えば、仕事において今まで存在しなかった便利さの体験を提供したいと考えています。しかもそれが、とりあえずできますというレベルではなく、「おもてなし」を感じられるような良い体験として提供したいのです。

新しい体験を質高く実現するために、自分の中にデザイナーとエンジニアの両チームがいる感覚で、上流工程から実装までフルスタックに協働することで実現しています。どんなに体験設計が素晴らしいものでも、見た目がダサいとがっかりさせてしまうと思うので、UIの細かなところにもできる限り気をつかっています。分業も効率という意味では正しいと思いますが、プロダクト内で統合された体験を提供するためには、自分一人で完結できる方が安定したクオリティを出せることが多いと自分の経験では感じています。というのも、たとえお互いがクオリティを高めたいと思っていても、何をもって高いクオリティなのかのギャップは少なからず発生してしまうからです。その点、自分一人で完結できるのは大きな強みになっていて、n1でユーザーの感想を聞き、自分でも触れてみて、繰り返し試行錯誤することで新たな体験を創造するよう心掛けています。

どうしたらデザイナーとエンジニアのフルスタックになれますか

私は、デザイナーを約5年、エンジニアを約5年それぞれ経験し、約10年かけてようやく一人前のフルスタックになれました。誰でもこれから時間をかけて各職種の経験値を伸ばしていけばフルスタックになれると思いますが、人生における優先順位は人それぞれだと思うので、誰にでもおすすめできるものではありません。

ただ、デザイナーだとしても、エンジニアだとしても、相手の立場になって考えることが大事です。単にFigmaが使えるとか、コードが読み書きできるといったスキルではなく、その職種のプロが何をもって良いプロダクトだと思って仕事をしているのかを理解することが重要だと感じています。

例えば、私がデザイナーとしてこだわっている点は、エンドユーザーの体験や提供する価値で、エンジニアとしてはプロダクトの中長期的な運用を想定した機能整理などの保守性や開発者体験にこだわっています。

TechTrainユーザーへ一言メッセージをお願いします

私は、プログラミングやフレームワークをほぼ独学で学んだのでかなり時間がかかりました。気軽に質問ができる環境があるならば、絶対に活用すべきです。TechTrainにはすごいメンターが揃っているので、例えば表面的なところに躓いていると思っていても、本当は違う視点で躓いていることもあるので、プロ目線のフィードバックをもらうことで、楽に学習効率を上げることができます。私は幅広い立場や開発現場に携わってきたので、デザイナー目線でのアドバイス、エンジニア視点でのアドバイスの両側面を踏まえた助言が得意です。そういった新しい視点を増やすためにも、面談を活用するといいと思います。

そして、学習する時は課題をこなすのではなく、自分が作りたいもの、実現したい体験のために技術を考えることを大切にしてください。「これが作りたい」や「このような体験を実現したい」といったゴールを明確にしてメンター面談や教材を活用することで、ちゃんと使えるスキルが定着します。かくいう私も、初学者の頃は作りたいものはありませんでした。そんな時は教材のゴールを意識し、なぜ今これをやっているのかという目的を忘れずに取り組みましょう。

どれだけ技術を深く学べるかは自分の興味関心の強さによると思いますが、どれだけ早く学べるかは環境に左右されると思います。30分考えて分からなかったら質問するようにすると、きっと2倍3倍のスピードで成長できるでしょう。早く成長した分、幅広い経験を積むことができます。一緒に頑張りましょう！

masaさん、インタビューありがとうございました。良いプロダクトを作る上で、エンジニアとデザイナーとがどのように関わっていくべきか、さらに深く知りたくなるインタビューでした！ユーザーに喜ばれるプロダクト開発を目指している方は、ぜひmasaさんと面談してみてください。

TechTrainでは今回インタビューに答えて頂いたmasaさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

エンジニアになったきっかけを教えてください

「理系出身で情報を学んでいました」という方とは真逆で、もともと地元北海道で音楽活動をしていました。上京したとき、音楽活動だけで生活していくことに不安があったのでアルバイトを探していたところ、縁があり同郷の友人が上京して立ち上げた会社で、右も左も分からないままエンジニアとして働き始めました。当時は、ZennやQiitaなどのテックブログやGitHubがなかったこともあり、今ほど情報が多くありませんでした。しかし、コードを書く人は社内に私一人しかいなかったので、近くの本屋に行って技術書を立ち読みし(笑)、その場で覚えて会社に戻って試してみるといった日々を送りました。2〜3年経った頃、急にそれまでの知識の点と点が繋がっていくような感覚を覚えました。この感覚を機に、エンジニアという仕事に面白みを感じ、本腰入れていこうと思うきっかけになりました。

その後、どのようなキャリアを歩んできましたか

当時はどれだけ働いても許された時代でしたので、終電を超えて働く日も少なくありませんでした。4年ほど経つと、Webアプリのフレームワークをイチからひとりで作れるまでに成長していました。そこで、次のステップとして、少し規模の大きい事業の開発に携わりたいと思うようになり、エキサイト株式会社へ転職。エキサイトでは、まず、ISPの部署でインターネット回線の開通や外部連携の業務を経験しました。その後、新しいことに挑戦したいと思い新規事業開発へ異動。PHPでの開発業務を担当しました。その頃から社外のカンファレンスに顔を出すようになりました。

さらに規模の大きなサービスに携わりたいという思いからLINEヤフー（旧ヤフー）へ転職。しかし、今までベンチャーというスピード感のある環境で仕事を進めてきたこともあり、社風や技術的な志向性が自分の考えとは異なる部分が多く9か月ほどで転職することに。そのタイミングで、PHPカンファレンスで出会った人から紹介してもらった、技術改善のためのエンジニアとして株式会社アイスタイルへ入社。入社間もなくマネージャーとなり、3年目にCTOとして事業を推進しました。

その後、友人の紹介で株式会社スターフェスティバルへ転職。リードエンジニアとして、インフラ領域の設計構築、データ活用のための基盤を整えたり、データドリブンな文化の醸成を進めました。いろんな経験をしていましたが、本当にやりたいこととのギャップを感じるようになり、3年ほど在籍した後に退社。約1年前に現職の千株式会社に転職。千は、今までの経験を活かすことができ、テクノロジーを使って事業そのものを作っていける環境です。CTOとして事業の方向性をマーケットリサーチから戦略立てていくことや、企業文化を作っていくことに取り組んでいます。

環境を選ぶ上で、大事にしている価値観はありますか

振り返ってみると、自分の行動範囲を広げることを大事にして環境を選んできたと思います。20代の頃は給与を上げたいと思うこともありましたが、一定ラインを超えてからは意識することはなくなり、もっと自分のできることを増やし、裁量の広い仕事に挑戦していきたいと思うようになりました。エンジニアとしてコードを書くことに加え、事業を伸ばしていくための中長期的なロードマップを考えたり、プロダクトの営業戦略やマーケティング戦略をチームを超えて議論し、その上でユーザーへの価値を分析したり、ドメインを理解してプロダクト開発に活かすドメイン駆動設計を活用することにやりがいを感じます。私は世の中に何かしらのイノベーションを与えたいと思っていて、それを実現するためには、人に言われたことをやるだけでなく、自ら変化を起こす側として事業をつくるところから関わっていくことが重要なのです。

OSSやカンファレンス登壇、書籍執筆など幅広い活動をしていますが、どんな想いを持って活動していますか

技術の楽しさを多くの人に伝えたいと思って活動しています。登壇する際は、日本の人がやっていないけれど海外では注目されているテーマを選び、オーディエンスに「こういうやり方があったんだ！」といった驚きや楽しいという気持ちになってもらいたいと考えています。

少し話が逸れますが、北海道にいるとき障害者施設で仲間と一緒に楽器演奏のボランティアをしたことがあります。障害を持つ子どもたちが、演奏を聞いて感動した気持ちを全身を使って表現してくれ、一緒に楽器を全力で楽しんでくれた姿に感動したのを覚えています。その経験を通して、人に想いを伝える時は、自分が思うよりも大胆に行動しないと伝わらないのだと気付き、そのために自分で環境を作ることが大事なのだと思いました。自分で立ち上げた技術コミュニティをサポートする一般社団法人もその一つです。

コミュニティで話すときは、技術の話を聞いてもらうだけではなく、必ず面白いパートを設けるようにし、私のトークを楽しんでもらいたいと思っています。そして、私の話をきっかけに技術っておもしろいな、楽しいなと感じてもらえたら嬉しいです。

ytakeさんのように高いスキルを身に付けるには、どうしたらいいですか

よく聞かれるのですが、正直分かりません。ぜひ音楽活動をやってみてください。というのは冗談ですが(笑)

まず前提として、スキル習得に効率を求めてはいけないと思います。よく「1000時間の法則」「10000時間の法則」などと言われますが、量をこなさず質を追い求めるのは逆効果です。ギターのコードを押さえる動きは絶対一発でできなくて、体の動かし方を覚えることと指の筋肉を鍛える必要があるのと同じ感覚です。今やChatGPTで答えを簡単に知ることができる時代ですが、プログラミングの基礎トレーニングが出来ていない状態ではそれを使いこなすことも自ら導き出すこともできません。自分は、若いころは「人の3倍やらないとダメだ」と思ってプログラミングに向き合っていました。人の2倍、3倍やることで同年歴の人よりも成長することができ、いろんなチャンスをいただくことができたと思います。

どうしたら人の3倍の量をこなせるようになりますか

それは、コードを書くことを好きになり、たくさんコードを書くことです。私は、今でもOSSライブラリ開発等でコードを書いています。もはや趣味と仕事の垣根がなくなっているほどに(笑)。自分が思い描いた通りに処理されたときは言葉にできないほどの快感ですし、バグが出たときにその理由を突き詰めたときもすごく楽しいです。

では、どうしたら楽しめるのか。それは、「目の前の課題を乗り越えたら、きっと楽しいだろう」とバグを理解した先の快楽をイメージすることです。私は行動範囲が狭くなると飽きちゃうタイプなので、普段から幅広くキャッチアップしていて、習慣的に機械学習を通じて自分でモデルを作ってみたり、ビッグデータの高速処理にチャレンジしてみたり、ブロックチェーンのシステムを自分で設計開発してみたりしていました。分からないからやりたくないではなく、乗り越えたら絶対楽しいという仮説の元進めていけるようになると強くなると思います。

TechTrainユーザーに一言メッセージをお願いします

私は、プログラミングにおいて複雑なことをいかにシンプルに考えられるかを意識しています。難しい課題に直面した時に、どう解決していくか悩んだ時はぜひ相談してください。例えば、課題をシステムを使って解決したい場合、課題をどう認識し、どう整理し紐解いていくとプログラムに落とせるのかは専門領域なので、十分アドバイスできると思います。そして、フレームワークをただ使えるようになるエンジニアではなく、世の中の課題を解決するためのプロダクトをどう表現していくのかを考えていくと面白いと思うので、ぜひこれから一緒にエンジニア業界を盛り上げていきましょう！

ytakeさん、インタビューありがとうございました！コードを書くことを心の底から楽しんでいることがひしひしと伝わってくる時間でた。また、人の3倍やりこむことで成長されてきたとは驚きましたが、その結果が今の素晴らしいご活躍に繋がっているのだと腑に落ちました。コードを書く楽しさを分かち合いたいときや、課題をどうプログラムで解決するのか悩む時は、ytakeさんにぜひご相談くださいね！

TechTrainでは今回インタビューに答えて頂いたytakeさんをはじめとして、140名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください。

ご経歴を教えてください

プログラミングはほぼ未経験で、新卒で自社アプリ開発会社へ入社。新人研修で、CPUやメモリの動きから、C言語で”Hello, World!”を出すところからプログラミングの基礎を学びました。研修後はOJT形式でJavaを学び、その後バックエンド開発とAndroid開発を7年ほど経験しました。

7年間会社に在籍する中で、会社の給与テーブルの枠組みの中でしか給与を上げていくことができないもどかしさや、会社というひとつの組織内の常識のみに囚われることなく、世の中にどんなエンジニアがいて、どんなことをしているのかを知りたいという気持ちを抱いていました。30歳になるまでに一度フリーランスを経験しておきたいと思い、29歳の時に退社しフリーランスへ転向。今ではFlutterを専門として開発、講師、TechTrainメンターなど様々な業務に携わっています。

どういう経緯でFlutterエンジニアになりましたか

当時はバックエンド開発とモバイル開発の経験が同じくらいあり、同じくらい好きでした。フリーランスとしてモバイルアプリの開発案件を任せられることの方が多かったので、自ずとAndroidアプリやiOSアプリ開発をする人になっていきました。

わたしはAndroidの経験しかありませんでしたが、「こういうモバイルアプリを作って欲しいんだけど、できる？」というお話を受け、「Androidしか分からないですが、iOSも頑張ってやりますよ～」と挑戦したことが何度かあり、そのおかげでiOS開発の経験を積むことができました。Flutterに関しても、クライアントから「ちゅーやんさんならできるだろうから、Flutter開発よろしく」と依頼されたことがきっかけで使うことになりました。

一般的に、フリーランスは今ある技術で勝負することが多いです。これは仕事の取り方に左右され、とりわけエージェント経由だと実績ベースで判断されることが多いと感じています。しかし、私が未経験のiOS開発やFlutterを触るようになったのはクライアントからの直接の相談がきっかけでした。運が良かったのだと思いますが、このようにクライアントから相談されるポジションを築いていくことで新しい技術に挑戦したり得意領域を広げていくことは可能だと思います。

ただ、未経験からスタートしたFlutterは、業務で使い始めてから2年くらいの間は、目の前のエラーを解決するために技術記事を読んでは解決、読んでは解決、の繰り返しでした。そんな中、コロナ禍で業務が減り、時間に余裕が出てきました。

余裕が出てきて、何か変わったことはありましたか

なんだか暇になってしまったので「記事でも書こうかな」と思い、それならば公式ドキュメントを読んでみよう！とひらめきました。

Flutterの公式ドキュメントは、他技術よりも読みやすいと言われていますが、それでも結構なボリュームがあります。私は、Inside Flutter というFlutterの内部構造を解説したドキュメントを1～2日ほどかけて読みました。英語表記で、内容も難しく1回読むだけでは理解できない部分も少なくなかったので、私自身はしっかり理解できるまで5回読みました。

公式ドキュメントを効率的に読むコツはありますか

公式ドキュメントはボリュームがあるため、途中で断念してしまう懸念があります。ドキュメント内には様々なトピックがあるので、まずは自分が気になっていることや問題を抱えている内容が記載されているページから読み始めましょう。

Flutterの場合はバージョンアップが盛んなので、一般公開されている技術記事だと情報が古いことがあります。技術記事の情報は古くても放置されてしまうので、実務でばりばり使っている人はもちろん、これから学ぶ人も公式ドキュメントを読むことを大事にするのがおすすめです。意外と平易な英語で書かれているので、DL翻訳でも意味が大きく崩れることは少ないです。

ちなみに、私がドキュメントを読んだ2020年頃は公式ドキュメントに則った内容の技術記事は非常に少なかった印象ですが、近年は見るようになってきました。技術記事を参考にした場合は、リファレンスとして公式ドキュメントを参照する癖をつけていけると良いです。

公式ドキュメントを読む前と後での変化を教えてください

公式ドキュメントを読んでからは、業務においてのエラー処理のスピードが格段に速くなりました。以前は、クラスやメソッドが無機質に列挙されているだけの印象を持っていて、このエラーはこう解決するといった場当たり的な対応をしていました。ドキュメントを読んで仕組みから理解してからは、エラーの意味をすぐ理解することができましたし、そもそもエラーに遭遇する頻度が激減したので業務効率がぐっと上がりました。

また、技術記事の執筆やカンファレンス登壇など情報発信のためのアウトプットの質が格段に良くなりました。

記事を執筆する際に高い頻度で抱く不安が、「自分が書かなくても他の人が書いているのでは？」ということでしょう。先にも書いたように、2020年当時は公式ドキュメントに関連する内容の記事を目にすることはなかったので、執筆のネタとしてもってこいだなと思い、不安を抱くどころかむしろ執筆意欲が上がりました。日本語の執筆に加え、海外向けの英語記事も執筆。Flutterの内部構造と該当するソースコードをメインに記事をまとめたところ、思っていたより良い反応をもらうことがでました。コロナ禍では仕事が少なかったので1ヶ月で1〜2万字の記事を3〜4つ執筆。その後仕事が増えてきても、1年に2〜3記事ペースで執筆を継続しています。

それ以外にも、内部実装の発信をしたことでの変化がありました。2021年からスタートしたカンファレンス FlutterKaigiのプロポーザルに応募し採択され、その後も第3回、第4回開催でも内部実装にフォーカスした内容を発表することができました。その他、FlutterGakkaiや海外の方も訪れる英語で開催されるカンファレンスFlatterNinjasでも登壇することになり、海外でも内部を知りたい人が多いのだと気付きました。

アウトプットの質が上がったことで、何かいいことはありましたか

キャリアの見せ方やお仕事の受け方において大いに生かされていると思います。

フリーランスは、個々人の露出の内容や頻度によって外部からの評価を受ける傾向にあります。技術記事の執筆の質が上がることでFlutterに詳しい人だと認識してもらえて仕事の依頼DMをいただいたり、カンファレンス等イベント後の懇親会での出会いから仕事につながることが増えました。

スキルアップできたことは言わずもがなです。分からないことが出てきた時、公式ドキュメントと内部実装を読めばすべてが分かるという状態になったので、第三者による技術記事を読むことがほとんどなくなりました。今でも公式ドキュメントの各所ページを読んで知見を広げています。内部実装は奥が深く、時間をかけて調べれば調べるほど内部ソースコードを読める状態になり、執筆や登壇に活かしています。

TechTrainユーザー方へ、メッセージをお願いします

何か分からないことがある時、QiitaやZenなどの技術記事を読むことがあると思いますが、その後に必ず該当する公式ドキュメントを読む癖付けをしましょう。技術記事公式ドキュメントを読むことで正確な情報を確実に得ることができます。とはいえ技術記事に意味がないわけではありません。詳しくは以下の記事にまとめています。

そして、もし技術記事等でご自身の知識や経験をアウトプットしていきたいと思うなら、一次情報である公式ドキュメントの参照リンクを載せておくと、ユーザーがわざわざ自分で探す必要がないので親切かなと思います。

参照リンクの載せ方例：

技術について調べる時は、必ず公式ドキュメント！これを徹底して、スキルアップを目指していきましょう。

公式ドキュメントを活用したちゅーやんさん直伝のFlutter学習ロードマップもMediaにて公開中です！

ご経歴を教えてください

慶応義塾大学湘南藤沢キャンパス（通称SFC）の4期生として入学。コーディングスキルを活かして3,4年生の頃からWeb制作の案件を受注をしていて、98年に卒業した後もなし崩し的にフリーランスになりました。同時に、劇団の演出助手の仕事をやっていたご縁で、テレビ局や芸能事務所のホームページ作成を多く手がけていました。演出助手というと驚かれる方も多いのですが、私の中では舞台の上の表現も、ブラウザ上の表現も、テレビや雑誌の表現もデザインすることには変わりないと思っていたので、自然な流れで仕事をしていました。

CSSが世に広まってきてからは、コーディングから企画の仕事をする機会へ移行し、さらにクライアントも増えてきたため、2003年2月に仲間と一緒に事業を法人化しました。法人化すると、信頼度が上がったせいか提案の幅を広げることができ、メールマーケティングをはじめとしたサイト導入設計、フューチャーフォン向けサービス、iモードサービス、Facebook（現Meta）アプリなどに携わるようになりました。

その後、スマートフォンという新しいデバイスをメインにやっていきたいと思い転職を決意。2011年からはサービスデザイナーとなり、デザイン思考やワークショップの知見を深めていく方向へ。その中で、よりワークショップデザインについて構造的に学びたいと思い、青山学院大学の育成プログラムを受講しました。結果として、認定ワークショップデザイナー、人間中心設計専門家、デザイン思考ファシリテーターなどの資格を得て行きました。

現在は、株式ゆめみのCGO（Chief Generative Officer）として、今までの経験を活かしてクライアントを巻き込む創発型（ワークショップ形式）の会議における設計や運営（ワークショップデザイン・ファシリテーション）を強みに、スマートフォンアプリの企画やサービスデザインを提供しています。

デザイナーになったきっかけを教えてください

初めから「デザイナーになろう」とは思っていませんでした。入学したSFCはインターネットの理論と実践を重要視していて、93年当時では珍しく、入学するとすぐに全員にメールアドレスが付与され、全員がHTMLを学び、当たり前のように論文をオンラインから提出する環境でした。否応なしにITやWebにどっぷり浸かる環境に身を置いたからこそ、インターネットや学問に慣れ親しむことができ、さらに当時はWebが分かる人やコーディングができる人がどこにもいなかったので、たまたま人づてに話が舞い込んできてWebエンジニア・Web制作をやっていたという感じです。優秀な友人は、大学での学びを言語化し、他の業界への就職に役立てたと思いますが、自分はWebスキルをそのまま使うしかできず、今に至ったのだと思います。あえてデザイナーを選んだのではなく、環境によって身に付いたことを活かして仕事をしていたら最終的に「デザイナー」に辿り着いたということです。

実は、小学6年の卒業文集で、将来の夢を”プログラマー”と書いていました。書いた記憶もありませんし、なぜ書いたのかも分かりませんが(笑)、結果的に夢が叶っていたのが面白いですよね。

そして、今はサービスデザイナーとしていろんな人と協力してサービスの価値を設計しているので、経験してきたコーディング、起業、クライアント対応などの経験を広く活かすことが出来ています。

サービスデザイナーとしてキャリアを歩むことになった起点を教えてください

スマホアプリ開発の企業に転職し、サービスデザイナーとしてサービスの価値を考えるようになったことをきっかけに、デザイン思考に意識が向き始めました。転職した当時、スマホアプリ開発は前例がないばかりか、事業の責任者でもあり1人でさくさく作れるものではなく、多くの社員でどうグロースさせるか話し合う必要があったのです。デザイナー、エンジニア、CS、広報など職種がばらばらなメンバー20〜30人ほどで議論を円滑に進める上で、「デザイン思考」の考え方をひとつの共通言語として活用しました。実務だけでデザイン思考をトレーニングするのに限界があり、経歴でお話ししたようにプライベートの時間を使ってさらに学びを深めました。

サービスデザインを身に付けるにあたり、様々なアプローチがあります。私は、先にも述べた通り、デザイン思考、ワークショップデザイン、ファシリテーション、人間中心設計（HCD）を体系的に学び、サービスデザインに活かしてきました。そして、これらの考え方は手を動かしてプロダクトを作るエンジニアが持っていると強みになりうる知識だと考えています。

エンジニアにもデザイン思考は必要ですか？

デザイン思考は、非デザイナーがデザイナーの考え方やアプローチを借りてくる手法だと考えています。なので、エンジニアの方も知っておくと業務に活かす場面があるのではないでしょうか？ユーザー中心の考え方を持つマインドセットは、特に重要です。

さらにおすすめしたいのは、デザイン思考でマインドセットを学んだ後に、人間中心設計（HCD）を習得することです。

HCDは、ユーザーの体験をより良くするのに優れている考え方なので、実際にエンジニアやPMを担っている方でも学んでいる方が多いと思います。加えて、HCDを理解していると、デザイナーとの共通言語が生まれ、コミュニケーションが取りやすくなります。また、何から始めればいいのか分からない方にはHCD基礎検定がお勧めです。HCD基礎検定は初学者向きで学びやすいのでおすすめです。

うめがねさんのこれからの目標を教えてください

最高のサービスデザイナーであるために、最高のジェネレーターになりたいと思っています。ジェネレーターとは、慶應義塾大学 井庭 崇教授や一般社団法人みつかる＋わかる代表理事 市川 力氏が提唱する考え方で、創造・探究を進めながら周囲も巻き込んで成し遂げる人を指します。

参考書籍：『ジェネレーター 学びと活動の生成』

サービスデザインをする上で、ワークショップをしたりディスカッションの場を設ける機会が多くあります。ファシリテーションの役割は、場づくりです。つまり自分の意見は言わず、参加者の意見を促します。一方で、ジェネレーターは、自らも考えを伝え、積極的に関与していくことで創造的コラボレーションを目指します。どんなテーマでも参加者に面白がってもらえる「面白がり力」を高めていきたいと考えています。

また、エンジニアも、ビジネスサイドの方も、ジェネレーターになることができます。「ジェネレーター」という考え方を世の中に浸透させていくことも、私の目標のひとつです。

TechTrainユーザーへ一言メッセージをお願いします

面談では、何でも聞いてください！特に、今明確に目指す像がない人は、かつての私と境遇が似ているので相談相手になれると思います。

私は、インターネットが生まれた30年前にそれが仕事になると全く思わずに関わった界隈の人間です。SFCへの入学も、最先端のIT環境があるから選んだのではなく、入試科目が小論文と数学だけで良かったからという理由でした。前向きでない理由ばかりを並べてしまいましたが、選択がいつも前向きである必要はないのかもしれません。私は、明確な夢を持って歩んできたタイプではありません。ですが、いつも選択する上でのアプローチは決めています。それは、「迷ったら面白い方を選ぶ」ということです。

どっちを選んだうめちゃんの方が、人は笑うかな？と常に考えているので、例えばステーキ店であえてハンバーグを頼み、先輩から本気で怒られるような人間ではありますが(笑)、想定外の選択をすることで「意外とハンバーグもおいしいんだな」など思ってもみなかった内容で会話が弾み、1回の食事で味わう面白みが格段に上がったのです。

私の特徴をタグ付けするならば、#全てを面白がる #想定外の切り口 #納得の着地 あたりでしょうか。誰かと面談したいけど誰を選べばいいのか迷う場合は私を選んでくれれば間違いありません。

応援しています！

うめがねさん、インタビューありがとうございました。”迷ったら面白い方を選ぶ”というアプローチでキャリアを進んでこられたところに驚きました。エンジニアのマインドアップ・スキルアップとして何を学ぼうか迷う方は、ウメムラさんにサービスデザインやHCDについて質問してみてください。

TechTrainでは今回インタビューに答えて頂いたうめがねさんをはじめとして、140名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

ご経歴を教えてください

2020年新卒で、事業インパクトの大きさや在籍社員の熱量の高さ、エンジニアとしての成長環境に魅力を感じ、株式会社ZOZO（旧株式会社ZOZOテクノロジーズ）へ入社。入社後はAndroidアプリの新規機能開発や機能改善をメインとし、開発以外にも新卒採用面接や逆求人イベントに参加したり、技術記事の執筆を積極的に行いました。

約3年ほど働いた後、フリーランスへ転身。業務委託契約を結び、クライアント企業の開発を行う傍ら、HACK.BARというエンジニアが集まるバーでバーテンダーとして働いたり、個人でサービスをリリースしました。このように、フリーランスになって以降は活動の幅を広げていき、TechTrainのメンター業務もそのひとつでした。

フリーランスとして約1年半ほど活動し、2025年3月にタクシー・ライドシェア事業を手掛けるスタートアップ企業へ入社予定。フリーランスを経て再度正社員として働くことを決断しました。

なぜフリーランスになろうと思ったのですか？

フリーランスとして可処分な時間を増やして、サービス開発に携わるエンジニアとしてのスキルアップだけではなく、さまざまな挑戦をしたいと考えるようになったためです。

組織に属するエンジニアとしてサービス開発のスキルを磨きたい気持ちはある一方で、他のスキルアップにも時間を使いたいと思うようになりました。今後のライフイベントや年齢、経験を踏まえ、長い人生を見据えたときに今が挑戦するのに良いタイミングだと判断しました。

フリーランスとして可処分な時間を増やせたおかげで、HACK.BARのバーテンダーとして技術的な交流を深めたり、個人でサービスをリリースして安定して月数万円程度の収益を上げられるようになったり、TechTrainでエンジニア志望の方々の成長を支援したりなど、貴重な経験を積むことができました。その他にも旅行、英会話の勉強、筋トレ、格闘技へのチャレンジなど余裕を持って趣味を楽しむこともできました。

フリーランスの理想と現実にギャップはありましたか？

良くない意味でも、良い意味でも、ギャップはありました。

良くないギャップとして、まず、思い描くキャリアを築きづらいということです。正社員であれば、willを踏まえた業務を任せてもらえたり必要に応じて上長がマネジメントしてくれますが、フリーランスはそのようなことはほとんどありません。 思い描くキャリアを実現するには、キャリアの実現につながる課題を見つけ出し、それを解決した実績を積むことが必要です。業務委託という立場では開発での貢献が最優先で求められるため「なぜ今この課題に取り組むのか？」をきちんと説明する必要があります。組織にもよりますが、この説明は正社員の頃よりもシビアに見られていると感じました。また、実務経験を伴う技術の幅を広げづらいと感じます。基本的には今持っているスキルを武器に勝負しなければなりません。雇う側の立場で考えると、業務委託として異なる技術の人材が必要になった場合、既存の業務委託メンバーに新しい技術を習得させるよりも、その技術領域に詳しいエンジニアを業務委託で採用した方が、開発効率が高いと判断される可能性があるためです。正社員であればキャリアや成長を考慮してもらえますが、業務委託の場合はそうした配慮は基本的に期待できません。

良いギャップとしては、正社員時代より技術力と実績を意識して磨いていくようになったことです。フリーランスとしてクライアント企業と契約する際は、自身の経験、実績、技術力などをアピールする必要があるため、日頃からそれらを磨くことを意識するようになりました。例えば、組織内の大規模プロジェクトでAndroidの責任者としてリードしたり、リファクタリングを提案してチーム内で認識を合わせるなど、組織で求められる能力を証明できる実績を積める環境を意識しました。また、金銭的な待遇はかなり良かったと思います。自分は時給5000円から7500円で仕事をしていたため、経費や健康保険料を差し引いても良い報酬をいただいていたと思います。さらに、お金について詳しくなることができました。確定申告の義務があるため、所得、経費、控除、税金などについて知識がないと正しく申告できず、場合によってはペナルティや税負担が増えてしまいます。それに関連して節税や資産運用にも興味を持つことができました。

以上の内容は自身の経験に基づくものなので、他の会社、契約内容、環境で異なる可能性もあるので、参考程度にしてもらえればと思います。

フリーランスエンジニアとして、どのようにスキルアップしましたか？

技術記事や書籍を通じたインプットに加え、学んだことを積極的にアウトプットすることを意識しました。

例えば、DroidKaigi.collectで登壇したり、技術記事を執筆したり、学んだ技術をサンプルコードとして実装して他のエンジニアと意見交換を行ったりしてきました。アウトプットすることで知識が整理され、人に伝える過程で理解が深まり、単なる知識ではなく自分の血肉となるような実感がありました。

また、案件に関わるエンジニアメンバーと設計や技術について意見交換する機会を意識的に作り、人から学ぶことも大切にしてきました。

このような取り組みは、基本的には会社員時代と大きく変わりませんが、フリーランスになったことでインプットやアウトプットに使える時間や余裕が生まれ、より学びを深められるようになったと感じています。

フリーランスから正社員へ回帰した背景を教えてください

正社員に戻ることを決めた理由は、大きく二つあります。

一つ目は、共感できる事業や会社に貢献したいという想いが強くなったことです。

フリーランスでは、事業の方向性に共感していても経営的な理由で契約が終了することがあったり、逆に事業に共感していなくても好条件のため仕事を受けることがありました。こうした状況で、高いモチベーションを維持しながら働くのが難しく感じる場面がありました。それであれば、自分が心から共感できる事業や会社に正社員として所属し、熱量高くコミットしたいと思うようになりました。

二つ目は、将来を見据えたキャリアへの不安です。前述の通り、フリーランスという立場で理想のキャリアを実現するのは難しい場合があります。理想のキャリアを描きやすく、それに向かって挑戦しやすい環境で働きたいと考えるようになりました。

正社員とフリーランスを経験して、思うことはありますか？

フリーランスになった当初は、可処分な時間を使って、開発以外にもさまざまなことに挑戦したいという気持ちが強くありました。しかし今は、エンジニアとしてさらに成長し、事業に貢献したいという想いが強くなりました。

活動の幅を広げてさまざまなことにチャレンジした結果、心から共感できる事業のもと、メンバーと協力しながら、エンジニアとして貢献することが自分にとって何よりもやりがいを感じることなのだと、改めて実感しました。

正社員とフリーランス、それぞれに良い点があります。どちらも経験したからこそ、自分が理想とするキャリア、ひいては人生を歩むための選択肢が広がったと感じています。

これからの目標を教えてください

スピードと品質を意識して社会課題の解決に貢献できるエンジニアになりたいと思います。そのためにAndroidアプリエンジニアとしての得意領域に磨きをかけつつ、他の技術やポジションもそつなくこなせるスキルや実績を積んでいければと思います。

TechTrainユーザーへ一言メッセージをお願いします

自分がエンジニアリングの勉強をしていた時、壁にぶつかることが非常に多く、しかも結局解決できないことが多かった記憶があります。課題に向き合い、一人で解決に向けて方法を考える経験はとても大切です。ただそれでも解決ができない時があれば気軽に頼ってもらえたらうれしいです。いち早くアドバイスをもらい、前に進み続けた方が方が圧倒的に成長スピードが上がります！これはまるで、過去の自分に伝えているようです(笑)

TechTrainメンターは、ユーザーの成長に全力でサポートできる人ばかりなので、安心してください。あなたの相談を待っています！

Yusukeさん、インタビューありがとうございました。正社員で働くこととフリーランスで働くことの違いがとてもよく分かるインタビューでした。フリーランスになろうか迷った時やAndroidアプリ開発で悩んだときはYusukeさんの存在がとても頼りになりますね。

TechTrainでは今回インタビューに答えていただいたYusukeさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

今までのご経歴を教えてください。

新卒では、自動車が好きだったこともあり、TOYO TIRE株式会社へ入社し、技術部門で製品開発をしていました。タイヤの開発には多くの時間を要し、もっとスピード感持った開発がしたいと思ったことがソフトウェア開発に興味を持ったきっかけです。

2018年頃からプログラミングを学び始め、2年弱のフリーランス期間を経て、2021年に80&Companyに入社。当時は社員3~4名ほどの規模で、これから会社も事業も大きくなるフェーズでした。エンジニアとしてフロントからインフラまで広く経験が積めそうだなという点と、代表の堀池さんの”人の意見を大切にする姿勢”に尊敬の念を抱き、入社を決意しました。3年3ヶ月在籍し、0→1の経験を積む中で、今後のキャリアの方向性として、広く一般に使われているサービスに携わることで、既存サービスをさらに良くしていくための技術・マインドを持てるようになりたいと思い、2025年1月にさくらインターネット株式会社に転職しました。

技術者になるまでの経緯を教えてください

小さいころからものづくりが好きで、特にレゴブロックに多くの時間を費やしていました。ひとつひとつは単なるブロックに過ぎないのに、頭の中でイメージして組み立てていくとちゃんとした物体になるのがおもしろく、中学生になる頃には「将来は技術者になりたい」と思っていました。

私が技術者への道へ踏み出したきっかけは、高専に進学したことでした。親の影響で高専の存在を知り、高専祭に足を運んでみたことがありました。そこには、伸び伸びと取り組む学生の姿があり、自分の責任を全うし、その上でやりたいことを自由にできる学校文化が自分の肌に合っていると感じ、高等専門学校へ進学しました。

高専時代は、自作PCを組む機会があったものの、当時Windows OSが高価だったため、無料で使えるUbuntu（Linuxディストリビューションの一つ）をインストールして遊んでいました。ものづくりが好きな自分にとってパソコンを作ることも、高専で専攻した都市工学の勉強も楽しかったです。

都市工学も楽しかったですが、もっと幅を広げて勉強したいと思い、大学の編入試験を受けて農学部に進学しました。農学部で学ぶ農業工学は、機械、電気、土木、水文学、気象学など、様々な工学の領域が関連しているので、当初の希望通り様々な知識を身に付けることができました。

幅広い分野の勉強を経て、新卒でTOYO TIREに入社し、見事技術者になる夢を達成しました。もともと自動車が大好きだったことや、タイヤという工業製品の難しさに魅了されたことが理由です。ITエンジニアへキャリアチェンジについて聞かせてください

タイヤの開発はとても楽しくやりがいを感じていましたが、トライアンドエラーのサイクルをもっと早く回したいと思ったのが理由です。タイヤは、一つの製品を世に出すまでに最短でも1年から1年半以上かかります。タイヤは自動車と地面の唯一の接点であるため、法規対応やテストを繰り返し、すり合わせを何度も行う必要がありますが、ソフトウェアだと、やる気さえあれば1日に何度もデプロイを行うことができますし、リリース後も高い頻度でトライアンドエラーに取り組め、スピード感や変化の多さに魅力を感じました。

当時の自分は、ソフトウエア開発に関してはあまり触れたことがありませんでしたが、2018年頃は既にソフトウェア開発に関する情報がオープンに公開されている状況だったため、手を出しやすく、興味を満たす目的と技術習得の両方を目指し学習を始め、エンジニアとして働き始めることとなりました。。

フリーランスエンジニアとしてどのような経験を積みましたか？

基本的に何でもやるスタンスでフリーランス期間を過ごしていました。友人から案件を紹介してもらったり、企業専属の業務委託としてWebサイトの開発に従事しました。また、エンジニアが敬遠することが多いWordPress構築をすることもありました。当時はとにかく必死で、経験を積むための経験だと自分を鼓舞してやり抜きました。

フリーランスとして働くと、もちろん教えてくれる先生はいません。分からない時に自力で壁を乗り越えなければならない苦労も味わってきました。ですが、フリーランスとしての経験があったからこそ、「開発する」という観点だけではなく、顧客のニーズを理解し、提供できる価値を具現化すると同時に、コスト管理や生産性の向上を目指していくといった一連の売上の立て方を理解できるまでに成長できました。そして、苦労している人の気持ちはよく分かるので、TechTrainメンターや専門学校の非常勤講師の仕事で寄り添うスタンスを大事にできているのだと思います。

専門学校で非常勤講師をする上で、どのようなことを大切にしていますか？

生徒と対峙するときは、単に開発スキルを教えるだけではなく、学生自身が問題解決能力を身に付けることを目指しています。それは、分からない問題に対してどのようにアプローチするか、そしてそれをどのように解決していくかを自分で考える力が重要だと考えているからです。

現在、専門学校の非常勤講師として、Next.js、React.js、TypeScript、HTML、CSS、JavaScriptの授業を担当しています。生成AIが発展している現代では、プログラミングスキルだけを持っていてもあまり大きな意味を持ちません。そのため、私の授業では実習型の授業スタイルをとっています。生徒が自主的に課題を解いていき、そこで当たったエラーを解決する力を鍛えています。

具体的には以下のようなスタイルで進めていきます。

1. 生徒が質問してきた時、「エラー文は何て書いてある？」と逆質問します。
2. エラー文は大抵の場合、英語で書かれているためほとんどの学生が意味を理解することができないので、ChatGPTなどの生成AIに入力して翻訳を促します。
3. 翻訳によって、エラー文の内容や解決するためのヒントが書かれていることがわかる状態に持っていきます。
4. ここから初めて具体的なアドバイスをします。

TechTrainメンター面談でも、問題解決能力を高めることを大切にしているのですね

TechTrainのメンター面談でも同じように、ユーザー自身で解決できるようにサポートしています。

今までのプログラミング学習は、プログラミング自体を教えるものが多かったと思いますが、これからの時代は生成AIが作ったコードを人間が判断してアプリケーションを作っていくようになると思います。だからこそ、自分の力で分からないことを解決していく能力が不可欠だと考えています。

余談ですが、みなさんにはエンジニアがかっこいい仕事だと思ってほしいと思っています。自分は没頭して何かを作ることが大好きで、それが世の中に出たときの達成感は言葉では言い表せません。また、変化が大きく流れが早いので、刺激的な仕事だと感じているので、これからエンジニアになる人にも、その面白みをプロダクト開発を通して味わってもらえるといいなと思っています。

TechTrainメンターへの想いを教えてください

メンターという役割を通して、IT業界への貢献も目指しています。Web業界はエンジニアに問題解決能力がもともとある前提で、「基本的に、自分で頑張って解決してくださいね」と育成がなされる文化があると感じています。問題解決能力がある人にとっては成長できる環境だと思いますが、誰しもそうではないと思います。日本社会を支えるエンジニアが今以上に活躍するようになるためには、丁寧で実践的な教育の普及が大切だと考えています。問題をどう解決すればいいのかで迷う人は多いと思いますし、TechTrainユーザーの中にはスキルアップするために何をしたらいいのか分からず悩んでいる人もいると思います。TechTrainは、現役で活躍しているエンジニアから直接話を聞くことができるのが一番のメリットだと思います。技術やキャリアについて思う存分質問して、上手く生かしていってもらいたいです。

-最後に、Wangchangdogさんの今後の目標を教えてください

今ある状況は、5年前に私が望んでいたものではなかったかもしれません。非常勤講師は高専時代の友人からたまたま声を掛けてもらったことがきっかけで始めました。当初は、知識経験をシェアすることで自分の理解が深まるのではという想いでしたが、やってみたら生徒の変化や成長を身近で感じられることに面白みを感じています。80&Company.で新規事業開発にがむしゃらに取り組んだことも、さくらインターネットでクラウド開発に挑戦できたことも想定していたわけではなく、様々な事象がたまたま重なった運の良さだと思います。

メンターや講師業は引退するまで続けていきたいです。様々な刺激を自分に取り入れ、それを社会の役にたてるエネルギーに変換していきたいです。そして、理系エリートがITエンジニアを目指すような日本になって欲しいという夢もあります。エンジニアはいい仕事だということをエンジニアを目指す若者に伝え続けていきたいです。

Wangchangdogさん、インタビューありがとうございました。学生のレベルに応じたアドバイスを意識されているとのことで、TechTrainユーザーの方も安心して相談できるのではと思います。エンジニアという職種の面白みを聞くことで、さらに学習モチベーションがアップしそうですね。

TechTrainでは今回インタビューに答えて頂いたWangchangdogさんをはじめとして、150名以上のメンターから無料で1on1メンタリングが受けられます。サイドメニューの「面談予約」からぜひメンタリングの予約をしてみてください！

アプリケーションの開発において「デザイン」と言っても、様々あります。今回ロードマップとしてお伺いしたのは、中でもtakanoripさんが得意とする「UIデザイン」をメインとした内容です！
また、”デザインロジカルに考える”というtakanoripさんならではのデザインの学習ロードマップとなっておりますので、より良いUIデザインを作りたいという方は、最後までご覧いただき開発の中で実践してみてくださいね。

UIデザインとは？

UIとは、ユーザーインターフェースの略で、「ユーザーとの接点、つなぎ目」を意味します。

ユーザーとサービスをつなぐ役割を持つUIデザインは、大きくわけると、4つの観点で捉えることができます。それは、情報デザイン、画面デザイン、ユーザビリティ、インタラクションデザインです。

「UIデザイン」というと、”情報をどう伝えるか？”の画面デザインをイメージするかと思いますが、サービスとユーザーをつなぐという観点では、”誰に”、”どんな風に”、”どういう状況で”情報を届けるのか？を考えたデザインの全てを「UIデザイン」といいます。

早速、takanoripさんのおすすめの学習ロードマップをみていきましょう。

TechTrain流 学習ロードマップ

おすすめのコンテンツを9つご紹介！

• 今日からはじめる情報設計
• IA100
• ウェブ・インクルーシブデザイン
• Webアプリケーションアクセシビリティ
• はじめてのUIデザイン 改訂版
• 縁の下のUIデザイン ──小さな工夫で大きな効果をもたらす実践TIPS＆テクニック
• インタフェースデザインの心理学 第2版
• 新版 アフォーダンス
• ABOUT FACE: インタラクションデザインの本質
• 参考書籍：ソフトウェアエンジニアのためのUIデザイン概論

学習の進め方

”デザインをロジカルに考える”takanoripさんらしい、エンジニアがデザインについて学ぶためのステップが整理されたロードマップになっています。

ここでは、体系的に学ぶことができるように以下の流れでロードマップを引いています。

• 情報デザインを学ぶ
• 画面デザインを学ぶ〜Webアクセシビリティ〜
• 画面デザインを学ぶ〜UIデザイン〜
• ユーザビリティを学ぶ〜認知科学・認知心理学〜
• インタラクションデザインを学ぶ

「なんとなくこういうデザインにしよう」というところから、意図を持ってデザインすることができるようになるには、その意図を表現するための知識が必要不可欠です。

自分でデザインができるようになる前に、まずは、なにかしらデザインされたものを見た時に、 デザインした人の意図のようなものをなんとなく推測できるようになるところからがスタートラインです。具体的なイメージでいうと、スマホでアプリを触っているとき、「このボタンがここにあるのは、こういう事情や意図があってここに置いてあるのかな？」など推察ができるようになるといったようなイメージです。

ただ、このように意図の汲み取りをできるようになるには、知識のインプットだけではなく、たくさんのデザインに触れる機会も必要です。ぜひ、ロードマップを進めながら、生活の中で何気ないもののデザインに込められた意図を意識してみてくださいね。

情報デザインを学ぶ

まずは、「何を伝えるか？」の情報デザインをするにあたり必要な情報設計から。情報設計に特化した書籍というのは、実はそう多くありません。

情報をユーザーに伝えるために、どう組み立てるかというところにフォーカスされていて装飾の話は出てきません。ただ、この機能はここに置いた方が良いな、機能の説明はここにおいた方が良いななどUIデザインをする時に、まずは情報設計が必須知識となります。UIデザインの前準備として、最初に知識をつけておきましょう。

①今日からはじめる情報設計

情報を整理整頓するための考え方と心構えを7つのステップに分けて解説する情報アーキテクチャ(IA)の入門書。まずは、ここからUIデザインの学習をスタートしましょう。

②IA100

表紙にある“Webサイトと人をつなぐ”が、まさにtakanoripさんのいうUIデザインそのもの。伝えるための情報アーキテクチャ(IA)の全体像を理解するための100の要素が載っています。

“エンジニアは、常に情報設計に向き合っていると思います。読みやすいコードを書くとき、 機能の全体像をみて、コードの順番や分割はこうしよう、関数はこういう風に分割しようというような意識をしていますよね。情報設計は、その考え方と似ています。それをUIやプロダクト開発に応用していけるので、最初のステップとして最適だと思います。

by takanoripさん”

画面デザインを学ぶ〜Webアクセシビリティ〜

Webアクセシビリティは、情報デザインと同様に、UIデザインをする上では避けて通れない必須知識。アクセシビリティは、「情報を伝えるための基本知識」といえます。デザインを作るための避けるべきBADパターンである、見づらいコントラスト比や、読みづらい文章のレイアウトなどのことです。例えば、文章内で誘導リンクをおく時に「◯◯はこちら」の”こちら”部分だけをリンクにするとわかりづらいよね、といったこと。
最初に、避けるべきBADパターンを基礎として学ぶことで、より効果的にUIデザインの勉強ができます。

③ウェブ・インクルーシブデザイン

よりたくさんの人にわかりやすく、使いやすいデザインをするために必要な考え方がまとまった一冊。

④Webアプリケーションアクセシビリティ

Webアクセシビリティの基礎「HTMLとWAI-ARIA」を解説から、「フォーム」、色やテキストなどの「UIデザインの基本」、モーダルダイアログや通知などの「少し複雑なUIパターン」の3つに分けてWebアクセシビリティを解説しています。よくある事例を元にしていて、この1冊でより実践的にアクセシビリティを学ぶことができます。

“ここまでお話ししてきた情報設計・Webアクセシビリティは、プロダクト開発の中でデザイナーとエンジニアが協業することが多い分野です。知識をつけてデザイナーとコミュニケーションができるようになると、ガッツリデザインができる！という人でなくてもデザイン寄りの仕事に活かすことができるので、より仕事の幅が広がるのではないかなと思います。
by takanoripさん”

画面デザインを学ぶ〜UIデザイン〜

「何を伝えるか？」、「情報を伝えるための基本知識」を身につけたところで、「UIデザイン」に取り掛かります。ここまでくるとUIデザインで手を動かすことができるようになっているはず。UIデザインに関する本はいくつか出版されていますが、書いてあることは大きく変わらないので、自分が読みやすい本を選ぶと良いと思います。選ぶ時に気をつけることは、最初はあまり文字が多くなくビジュアルの説明が多いものを選ぶこと。迷ったら手にとって欲しいおすすめの本は次の2冊です。

⑤はじめてのUIデザイン 改訂版

価格がお手頃な点も魅力的な上、中身も網羅されていて、UIデザインを始める入門本としてイチオシの1冊。数年前に出版されていますが、時代に左右されず良い情報が載っている良書。

⑥縁の下のUIデザイン ──小さな工夫で大きな効果をもたらす実践TIPS＆テクニック

UIデザインに関する引き出しを増やすために活用する中級者向けの書籍。タイトル通りTIPS形式でより良いデザインの方法が載っています。HOWがたくさん載っていますが、UIデザインを学び始めに読むと、そのTIPSをどこで活かすかわからないなと感じてしまうので、⑥に持ってきています。⑤『はじめてのUIデザイン 改訂版』までで紹介してきた「デザインとは何か」を知ってから、さらにいいUIデザインにするにはどうしたらいいかという悩みが出てきた時に読みましょう。

“⑤『はじめてのUIデザイン 改訂版』までくると、「なんとなく一人でUIデザインができる」ようになります。そして、⑥『縁の下のUIデザイン ──小さな工夫で大きな効果をもたらす実践TIPS＆テクニック』まで学ぶと「なんかイケてないかも…をアプデできる」ようになってきます。

ここから先は、本を読むだけでなく自分で何か作ってみることが重要です。インターネットで題材を見つけたりして、たくさんアウトプットをしましょう！

by takanoripさん”

ユーザビリティを学ぶ〜認知科学・認知心理学〜

ユーザビリティは、単なる「使いやすさ」を表す指標ではありません。ただ、現時点で確立された定義はまだありません。ただ、「プロダクトを届けたいと思っているユーザーが、また使いたいと思える」UIデザインを考えるために、非常に大事なことです。UIデザインのブラッシュアップをするためには、自分でアウトプットができるようになったこのタイミングで学ぶのがおすすめです。より具体的なHOWの書籍と概念を学ぶ本をそれぞれ紹介します。

⑦インタフェースデザインの心理学 第2版

科学的な観点に基づいた人間の思考や行動に合ったデザインをするための必読書。例とともにTIPS形式で書かれており、これを読むと、⑥『縁の下のUIデザイン ──小さな工夫で大きな効果をもたらす実践TIPS＆テクニック』のHOWがなぜ良いデザインなのかの根拠や背景を理解できます。

⑧新版 アフォーダンス

今まで紹介してきた本に比べると、抽象的な内容がメイン。UIデザインを学ぶ文脈でご紹介をしていますが、デジタルを前提に書いている書籍ではありません。

どんなことが書いてあるかというと、例えば、「ドアノブって、なんで回したり押したり、つい触りたくなっちゃうのか」のような話。

日常にあるものに対して「何気なく触ってるけど、それがなんでそういう行動を起こさせるのか」を知ることで、 この行動を促すためのUIデザインをするとしたら、こういうデザインはどうか？とイメージを膨らませるための知識としてピッタリな本といえます。

実務に直接役立つかというと難しいところですが、今世の中にない新しいプロダクトのUIデザインや、斬新なUIデザインを考えるシチュエーションがきたら、この書籍の知識があると良いデザインができると思います。

“⑦『インタフェースデザインの心理学 第2版』までは、割と実践的な内容ですが、⑧『新版 アフォーダンス』は、ここまで学習してきたUIデザインから、もう少しはみ出して、「なんでこれがこう触ってみたくなるんだっけ。」みたいなデザインのもっと根本の話に興味が出てきたら、読んでみると面白いと思います。人によっては、知的好奇心を満たすだけになる可能性もあるので、 面白そうだなと思ったら読むぐらいでいいんじゃないかなとは思いますね。笑

by takanoripさん”

インタラクションデザインを学ぶ

インタラクションデザインとは、ユーザーの操作・動作によって生じるシステムの変化・反応という、具体的な「やりとり」をデザインすることを指します。例えば、ユーザーがこのアクションをしたら、こんなフィードバックを返しましょうというようなユーザーとプロダクト上でのやりとりというとイメージが沸きやすいでしょうか。では、ロードマップの最後の書籍を紹介していきます。

⑨ABOUT FACE: インタラクションデザインの本質

インタラクティブデザインを考える上で効果的で実践的な方法（デザイン原則・デザインパターン・デザインプロセス）を解説している1冊。
実はこの本、「インタラクションデザインの本質」と言いながら、デザインに関する様々な分野に関して書かれている本で、とってもおすすめ。実務で活かせる実践的な学習をするなら⑧『新版 アフォーダンス』よりも、こちらを読む方が良いのですが...なにせ鈍器くらい分厚い。先に手にするとそのビジュアルから心が折れてしまう方もいるのかなと思い最後に紹介しています。
とにかく読むのに時間がかかる本なので、まずは、興味がありそうなところからちょっとずつ読んでいくような辞書的のような使い方をすると良いでしょう。

“本当に分厚くて、1番最初に手を出すと心折れると思うので、ある程度知識が身についてきてから読んでください。おすすめの購入タイミングは、⑤『はじめてのUIデザイン 改訂版』を読み終わった後ですね。そのタイミングでとりあえず買っておいて、中身は読まなくても本棚に置いておく。ある程度知識がついてから興味のあるところから読み始めて欲しいです。
デザイン系の本は、内容が古くなることはあまりないので、絶版する前に買っておいてほしい。この書籍もかなり昔の本ですが、何度も翻訳されて、時代に合わせてコンテンツを追加して今でも読まれている本なので、手元に置いておいて損はないと思います。
by takanoripさん”

参考書籍

ソフトウェアエンジニアのためのUIデザイン概論

本ロードマップは、takanoripさん執筆『ソフトウェアエンジニアのためのUIデザイン概論』を参考に編集した箇所があります。

この本はWebエンジニアのために「UIデザインとは何か」「なぜUIデザインを学ぶのか」について、UIの歴史や心理学の観点から解説しています。バックグラウンドを知ることでUIデザインをより深く考えるきっかけになるような書籍です。

まとめ

ここまで、9つのコンテンツを紹介してきましたが、いかがでしたか？

最後に、takanoripさんからこのロードマップを通して、デザインの勉強をする上で大事なことをひとつお伝えします。

それは、「フィードバックをもらうこと」。

デザインは「できた」だけではダメで、他の人から見て「いい感じ」かどうかが大事。アウトプットをゴールにせず、フィードバックをもらうためのアウトプットという意識をして実際に自分で手を動かしてみてください。

“デザインにおいては、アウトプットを公開してからがスタートライン。そこからフィードバックをもらうことによって、それをより使いやすかったり、より見やすいように改善することで、だんだんレベルアップしていきます。まずは、自分で作ったデザインにフィードバックをもらうところからやってみてください。
by takanoripさん”

TechTrainでは、プロのUI/UXデザイナーのメンタリングを提供中です。UIデザインのレベルアップをしたいエンジニアは、活用してみてくださいね。今回ロードマップを紹介してくれたtakanoripさんへの相談も可能です！

今回は「不確実性から逃れられないITエンジニア」というエッセイを書かせていただきました。ITエンジニアが生まれたのはここ数十年の話であり、なぜこの職業が社会的に求められているのかに対しての自分なりの考えを伝えさせてください。

資本主義が求める価値と生産性

資本主義下において各プレイヤーは成長するために常に新たな価値を追求し生産性を向上し続ける必要があります。そのために人類の経済活動の大部分は農業から工業、サービス業へと移行してきました。これらの移行がなぜ起こったのかについて、ITエンジニアの観点から詳しく見ていきましょう。

自然という不確実性

農業とは人類が携わった最初の職業ですが、予測不能の自然の恵みに依存しています。干ばつ、洪水、病害虫の大量発生などが起きれば、農家の努力は一瞬にして無に帰す可能性を秘めています。

ITエンジニアからすると、こういった不確実な振る舞いをする外部環境への依存を一番嫌います。バグやエラーがあったとしてもそれには必ず原因があり、論理的に解決できなければならないのです。

農業技術の進歩もあって、人類の経済活動はより安定した生産が可能な工業へと移っていきます。

物質という不確実性

工業化によって自然の影響を受けず大量生産の夢を実現しましたが、同時にその限界も明らかにしました。生産者は、原材料の枯渇、環境破壊、エネルギー消費などの問題に悩まされる一方で、消費者は物質的に十分に満たされつつあります。

ITエンジニアにとって、クリエイティビティを発揮する上で物理的制約は考慮したくありません。思いついたアイディアは、そのままコードに落とし込み、すぐに仮想環境で試したいのです。機械系エンジニアや建築士は物理的制約を考慮する必要があり、確実にアイディアを形にするにはやはり物理空間を去る必要があります。

工業製品が大量生産されるようになると市場での競争が激化し、工業からサービス業に移行していきます。

人間という不確実性

サービス業としては、教育、医療、金融、娯楽などが挙げられますが、サービスの提供対象として必ず人間が関わってきます。この人間が不確実性の元凶なのです。人間とは適切に実装された関数とは違い、インプットに対していつも期待するアウトプットを返してこないのです。

不確実性を嫌うITエンジニアの身になって、サービス業の職種について考えてみましょう。ショップやレストランでサービス業務を行う販売職や営業職は直接人間に関わるので避けたいところです。教師、医師、弁護士、コンサルなどの専門職もアウトプット時にかなり人間との接点がありそうです。人事や総務などのコーポレート職は顧客との接点はないかもしれませんが、企業内部の社員と接点があるでしょう。アーティストとして大成するのであれば、人間に届く作品をアウトプットする必要があります。

不確実性がない情報空間

そこでITエンジニアは不確実性がない情報空間に逃げ込みます。そこは0と1で構成された明確な世界であり、不確実性から逃れたいと願うITエンジニアにとって究極の避難所です。プログラムが正しく設計されていれば、ほぼ100%の確率で期待した通りに動作します。この確実性は、自然、物質、人間による不確定性がつきまとう物理空間にはない魅力です。

もちろんITエンジニアは物理空間を全く無視できるというわけではありません。物理空間に影響を及ぼすためにITが必要なのであって、アルゴリズムやインタフェースを設計する際は必ず物理空間を考慮に入れます。しかし、物理空間の問題を情報空間で解決可能な形に落とし込まれていさえすれば、不確実性がない世界で万能感に包まれつつ解決策を形にする幸せな作業だけが残っているのです。

情報空間に現れた不確実なモノ

しかし、皮肉なことに、かつて不確実性から逃れた聖域であるはずの情報空間に、新たな不確実性が忍び込みました。生成AIの登場は、ITエンジニアたちに衝撃を与えています。論理的で確実であるはずのデジタル世界に、人間のような予測不能な振る舞いをする存在が現れたのです。

おわりに

自分も含めてITエンジニアの人たちはこんな志向性があるかもしれないなと思って書いてみました。TechTrainでエンジニアを目指されている方が、改めて「なぜエンジニアリングがしたいのか」について考えるきっかけになれば幸いです。

いかがでしたか？

今回は、今までとは違ったtakaakiさんならではの執筆記事となっています。本記事を読んで改めてエンジニアリングについて考えるきっかけになれば、運営としても嬉しいなと思います。

みなさんの「記事、読みました！」の声がメンターにとっても運営にとっても励みになります。ぜひ読んだ方は感想などを伝えてもらえたらとても嬉しいです。

メンター執筆シリーズについて

メンター執筆シリーズはこれからも定期的に配信中。

次回は、なんと初めてキャリアメンターが執筆する記事を準備中...エンジニアの採用やキャリア相談をたくさんしてきたメンターならではの視点での記事になる予定です。

公開を楽しみにしていてくださいね。