この記事でわかること
-
Webディレクター出身者が「実装」を学ぶことで得られる、提案力と信頼
-
「AIにコードを書かせる新人」が育たないリアルな理由
-
PM/PLが市場価値を高めるために不可欠な「業界知識」と「マネジメント論」
Web業界において、ディレクションとエンジニアリングは時に別個のスキルとして扱われます。しかし、その境界を「越境」することで生まれる市場価値は、計り知れません。
株式会社ShareDanの代表取締役であり、デザイン会社・株式会社エスケイワードのCTOも務める山本真也氏は、過去に30歳という転換点でWebディレクターからエンジニアへの道を選びました。自社サービスの開発から、大手キャリアの解析、そして現在はSaaS系Webサービスの基盤構築まで、ビジネスと技術を高度に接続する「技術の翻訳者」として信頼を集めています。
生成AIの台頭など技術トレンドが激しく変化する中で、エンジニアは自身の価値をどう高めていくべきなのか。 技術力以上に求められる「ビジネスを動かす力」や、変化の激しい時代におけるPL/PMの生存戦略など、現場のリアルを知る立場から実践的なキャリア論を伺いました。
山本 真也
株式会社ShareDan 代表取締役
1984年千葉県生まれ。明治大学卒業後、Webディレクターとして100以上のサイト運営に従事。2015年に独立後、独学で技術を習得し、2017年に株式会社ShareDan代表取締役に就任。企画から実装まで担える強みを活かし、大手企業のWebアプリ構築や解析などで活躍。現在は「Webクリエイターズギルド」の主宰や、SaaS製品の開発責任者も兼任する。
【X（旧Twitter）】：https://x.com/yama_shin0525?s=20
目次
なぜ「ディレクター」が自らコードを書く道を選んだのか
まずは、山本さんの現在の活動について伺いたいのですが、株式会社ShareDanの代表を務めながら、名古屋にある株式会社エスケイワードでCTOも兼任されているそうですね。具体的にはどのような業務に携わっているのでしょうか？
2つの会社で、それぞれ異なる領域の開発を担当しています。まず、自身の会社であるShareDanでは、受託開発がメインです。金融系Webアプリケーションの構築や大手キャリアのサイト解析、直近では鉄鋼メーカーのWebサイト制作などを行っています。
また、エスケイワード社のCTOとしては、技術統括が主な役割です。同社はもともとデザインに強みを持つ会社ですが、最近は大規模な開発案件も増えており、私は出版系アプリの基盤構築や、制作案件全体の技術的なサポートを担っています。これまでの歩みと、現在の関わり方をまとめると以下のようになります。
山本さんのキャリアのルーツは「Webディレクター」だったと伺っています。ディレクターからエンジニアへ、というのは珍しい歩みに思えますが、なぜ自ら手を動かす道を選んだのでしょうか。
もともとは出版社のWebディレクターで、コンテンツベースのWebサイト制作などに関わっていました。ただ、当時からディレクターの枠を超えてHTMLやCSSに触れたいと考えるタイプではあったんです。
30歳の時、自社サービスを立ち上げようとしたのですが、「時間はあるけど、開発を依頼するお金がない」という状況になりまして。それなら自分で作ってしまおうと、会社を辞めて半年間、独学でフロントエンドとバックエンドの技術を習得したのが始まりです。
半年間、独学でやりきったのはすごいです。ディレクター時代の「人に任せる」仕事とは、全く感覚が違ったのではないですか？
Webサイト制作とアプリケーション開発は領域が全く別物なので、自分にとっては完全に新しい世界に飛び込む感覚でした 。
当時は30歳という節目でもありましたし、あえて半年間という期限を切り、「今は就職活動よりも、自社サービスを形にするための技術習得に全ての時間を投じる」と決めて、文字通り朝から晩まで開発に没頭したんです。その当時に習得した技術と、その後の広がりをまとめたのがこちらの図です。
エンジニアリングには「パズル」のような要素があって、ロジックを組み合わせて思い通りに動いた瞬間に、カチッとピースがハマるような快感があります。そのモノづくりへの純粋な探究心があったからこそ、短期間で実務レベルまで技術を深めることができたのだと思います。
「技術の翻訳者」になれ。ディレクション × 実装がもたらす信頼感
ディレクターとしての視点と、エンジニアとしての技術。この両方を手に入れたことで、実務において見える景色はどう変わりましたか？
一番の変化は、要件定義の「解像度」が劇的に上がったことですね。例えば、クライアントから要望を聞いた瞬間に、「ここから先は開発領域だからこれくらいコストがかかる」とか「この仕様だとDB設計にこういう負荷がかかる」といった見積もりが脳内で即座にできます。
打ち合わせの場で、即座に技術的な判断で回答できることが、大きな強みになるのですね。
クライアントに対して「わかりません、持ち帰ります」ではなく、その場で概算や実現可能性を答えられる。これがクライアントワークにおける圧倒的な信頼関係に繋がるんです。
近年、Webとアプリケーションの境界線が曖昧になっていて、Webサイトであっても高度な機能が求められることが増えています。そうした現場で立ち回り続けるには、単なる技術力だけでなく、多角的な視点が必要だと考えています。
これからのエンジニア、特に技術力だけに特化しないジェネラリスト志向のエンジニアの場合、技術やツールの理解に加え、「ビジネスの理解」が不可欠です。そしてその中核をなすのが「技術の翻訳能力」だと思っています。
技術に詳しくないクライアントに対して、専門用語を使わずに分かりやすく説明する。これができないと、どんなに優れた技術を持っていても対話が成立しません。「わからない人が悪い」というスタンスでは、真の信頼関係を築くのは難しいと思います。
技術を突き詰めるほど、相手の目線に立った言葉選びが難しくなってしまうことがありそうですね。
よくあるのが、「技術的には可能ですが、できません」といった回答です。これは、ビジネスの成功を第一に考えるクライアントからすると、 「ではどうすればいいのか」という次のステップが見えない回答になってしまいます。
クライアントが求めているのは技術の解説ではなく、「ビジネスをどう成功させるか」 です。「その方法は難しいですが、こういうやり方なら目的を達成できます」という代替案を提示できるか。ここにビジネス視点を持ったエンジニアの真価が現れます。
ジェネラリストの生存戦略。まずは「適切な判断ができる知識」を
多くのエンジニアが「一つの技術を深めるスペシャリスト」か、「幅広く知るジェネラリスト」かで悩みます。山本さんは、この二者の違いをどう定義されていますか？
そこは明確に区別した方がいいですね。まず、スペシャリストを目指すなら、コンピュータサイエンスの深い知識は必須です。DB一つとっても、内部構造まで深く理解していないと、いざという時のトラブルシューティングができません。
独学でキャリアを切り拓いてこられた山本さんですが、専門教育を受けてきたスペシャリストの方々と接する中で、「もっと深めたい」といった葛藤や、向き合い方の難しさを感じることはありましたか？
文系出身ということもあり、体系的に学問としてコンピュータサイエンスを学びたいという想いは今でも持っています 。ただ、それは引け目というよりも、自身の土台をより盤石にしたいという知的好奇心に近いですね。
実務において、私のようにジェネラリストとして生きるなら、必ずしもすべてを極める必要はないと考えています。大切なのは、「何を選び、誰に任せるか」という判断ができるための知識です。
ジェネラリストに求められる「知識」とは、具体的にどのようなものでしょう。
一言で言えば、「プロジェクト全体の最適解を導き出すための、広い知識」です。 具体的には、特定の技術を極めることよりも、各種データベースの特性やコスト感、あるいはネットワークやデバイスの構造といった全体像を把握していることが求められます。例えば、フロントエンド領域だけでもカバーすべき範囲はこれほど多岐にわたります。
こうした広範なツールの特性を理解した上で、「この要件ならどのDBが最適か」「セキュリティ上のリスクはどこにあるか」といったプロジェクトの成否に関わる大局的な判断さえできれば、細かな実装は信頼できるスペシャリストにお願いすればいいんです。
なるほど。でも、PLやPMとして現場を見ていると、全く手を動かさないのも不安だという声もありますよね。
気持ちは分かりますが、実際に手を動かすかどうかは規模によります。案件規模が億を超えてくるようなプロジェクトなら、PMはマネジメントに専念すべきです。逆に、数千万円規模の案件なら、PMも手を動かせないとリソース的に厳しい場面もあるでしょう。
ただ、どのレイヤーにいても、「技術トレンド」と「セキュリティ情報」だけは、業務として常にキャッチアップしておくべきです。
セキュリティはもちろんですが、技術トレンドも非常に変化が速い領域ですよね。マネジメント層がそこを追うことには、どのような意図があるのでしょうか。
技術トレンドの把握は、エンジニアの採用やチームビルディングにおいて極めて重要だからです。エンジニアには新しい技術を好む層が多く、今の市場でどの技術に人が集まっているか、何を採用すると優秀な人材を確保しやすいかといった感覚を持っておかないと、適切なチーム組成ができません。
一方のセキュリティも、リスク管理として不可欠な知識です。例えば「ゼロデイ攻撃」のような脆弱性が見つかった時、「知りませんでした」では責任を果たせません。セキュリティツールの公式HPでアップデートが推奨されたその瞬間から、攻撃者は未対応のサーバーを狙い始めます。最新のトレンド把握とセキュリティ対策、この両輪に敏感であることは、マネジメント層の必須条件ですね。
AI時代の残酷な真実。ベテランは進化し、新人は「AIに書かせる」から育たない
最近の大きな変化といえば、やはり「生成AI」の普及です。GitHub Copilotなどを使えば、誰でもそこそこのコードが書けてしまう。この状況を、山本さんはどう見ていますか？
便利になった反面、非常に危うい側面もあると感じています。 これまでの技術の進化を振り返ると、新しい技術は常に「より楽に」「より高品質に」という課題を解決してきました。
しかし、今回のAI活用に関しては少し性質が異なると考えています。実際に今の開発現場では、「新人エンジニアが成長しづらくなっている」という深刻な弊害がすでに起き始めているんです。
成長しづらい？ AIがあるから、むしろ学びやすくなっているのでは。
逆なんです。経験の浅い人がAIにコードを書かせると、バグだらけの、いわゆる「動いているように見えるだけ」のコードが平気で上がってきます。それをベテランがレビューするのですが、AIが生成したコードは量だけは多いので、ベテランはレビューに疲弊してしまう。
しかも、新人はAIに書かせているから、なぜそのコードが間違っているのかを理解できない、と。
はい、自分でロジックを考えて書いていないから、スキルが全く身につかないんです。一方で、ベテランはAIが生成したコードの誤りを見抜き、修正し、さらに効率的な指示の出し方を学んでいく。
結果として、ベテランのレベルだけがさらに上がり、新人は「AI依存」から抜け出せないという残酷な構図が出来上がっています。
それは恐ろしいですね。若手や初心者がこの罠から抜け出すための、ベストプラクティスはありますか？
遠回りに思えても、最初は「自分でコードを書く」ことです。 まずは自分で書いてみて、それをAIにレビューさせるという使い方が一番勉強になります。最初からAIに答えを書かせるのは、数学の問題を解答集を写しながら解いているのと同じです。
まずは自分の頭で考え、その後にAIを使って効率化やリファクタリングを学ぶ。このステップを踏まないと、いつまで経っても「AIが出すバグに気づけないエンジニア」のままです。
AIを「コードの代筆者」ではなく「家庭教師」として使うわけですね。
その通りです。また、これからのエンジニアが磨くべきは、AIには代替しづらい「ビジネスとの接続点」です。私はよく生成AIを「サービス開発の壁打ち相手」として使っています。
例えば、街中で高級車を頻繁に見かけるようになった時、「景気が良くなっているのか？」とAIに聞いてみる。そこから地域差や社会トレンドを掘り下げ、サービスの発想に繋げていく。こういう思考の拡張こそが、AI時代の賢い使い方だと思います。
優秀なPMの条件は「最後までやりきること」
山本さんはエンジニア視点から多くのPM（プロジェクトマネージャー）を見てこられたと思いますが、「現場のパフォーマンスを下げてしまう」PMには、どのようなアンチパターンがあるのでしょうか？
最も避けたいのは、PMがプロジェクトの途中で限界を迎えてしまい、継続困難になってしまうことですね。
現場では、そういったケースも少なくないのでしょうか？
これまでに何度か目にしてきました。責任感が強い方ほど、一人で課題を抱え込みすぎてしまい、ある日突然キャパシティを超えてしまうことがあるんです。だからこそ、PMとして最も重要な資質は、高いスキルや知識以上に、「最後までプロジェクトを完遂する」という継続力だと考えています。
PMはプレッシャーのかかる仕事です。長く走り続けるためのアドバイスはありますか。
「人に頼る」こと。そして「他責思考」を捨てることですね。抱え込んで突然いなくなるのが一番の他責です。うまくいかない時にメンバーのスキル不足を責めるのではなく、チームとしてどうリカバリーするかを考えることが大切です。
「できない人を責めるのではなく、チームでゴールする」という姿勢が、結果的に自分の負担も減らしてくれます。
マネ—ジャーとしての器が問われますね。市場価値を上げたいPL/PMが、技術以外で身につけるべき武器は何でしょうか。
「業界知識（ドメイン知識）」ですね。例えば、IT業界ではFAXなんて時代遅れだと思われがちですが、現場の商習慣では未だにFAXが主流という業界もあります。その文化を無視して「Webで完結させましょう」と提案しても、絶対に普及しません。
その業界特有の文化や慣習を理解した上で設計できるPMは、クライアントから絶大な信頼を寄せられます。例えば、会計システムを構築する際、プログラミング言語の知識以上に「決算」という業務そのものの理解が、設計の質を左右することもあります。
単に「数値を計算して保存する」だけでなく、上場企業の決算スケジュールや税務申告の期限といったビジネスのルールを理解していれば、どのタイミングでどのようなデータ処理が必要になるか、PL/PM側から最適な設計を提案できます。「何をつくっているか」というドメインへの深い理解があってこそ、技術を正しく実装に落とし込めるようになるんです。
相手のビジネスを深く理解することこそが、本質的な「提案」の土台になるのですね。エンジニアが「言われたものを作る」段階を脱却して、単価を上げるための秘訣はありますか？
「一度でいいから、自分でサービスを作ってみること」です。自分の身銭を切って、金額設定をして、集客やコストを考える。そうすると、クライアントが日々どんな不安を抱え、どんな成果を求めているのかが、自分事として理解できるようになります。その経験があれば、自然と「提案型」のエンジニアになれますよ。
キャリアに無駄な経験はない。過去の全てがエンジニアの武器になる
最後に、キャリアの踊り場にいたり、将来に迷っているエンジニアやPL/PM層に向けてメッセージをお願いします。
私がキャリア相談を受ける際によくお伝えするのが、「これまでのキャリアは、何一つ無駄ではない」ということです。時々、履歴書にエンジニアになってからの経歴しか書かない人がいるのですが、非常にもったいないと感じています。
とはいえ「エンジニア職への挑戦だから、異業種での経験は評価されないだろう」と思い込んでしまうケースは多そうです。
そんなことはありません。例えば前職がホテルマンだったなら、そのホスピタリティや接客の経験は、クライアントワークにおける強力な武器になります。ビジネスの現場では、技術力と同じくらい「人の気持ちを汲み取って調整する力」が求められるからです。
技術だけの履歴書よりも、その人のバックボーンが見える方が、「信頼に足る人物」かどうか判断しやすいということですね。
そうです。過去の全ての経験が、今のあなたという「エンジニア」を構成している。「何でも屋」を恐れる必要はありません。全ての経験を掛け合わせて、「自分はこういう人生を生きてきたから、今の自分がある」と語れるエンジニアにぜひなってください。
そんな「唯一無二」の存在になれば、どんなに時代が変わっても、市場から求められ続けるはずです。現場で起きているリアルな課題をいろいろお伝えしましたが、少しでも皆さんのキャリアのヒントになれば幸いです。
ライター
