この記事でわかること
-
即戦力として活躍し続けるための学習方法や普遍的な技術との向き合い方
-
原因不明のバグ解決に効く「1つ上と1つ下のレイヤー」を学ぶ重要性
-
海外発プロダクトに対する誤解と、AI時代に必要な「データベース中心設計」
技術の移り変わりが早いIT業界において、「次は何を学ぶべきか」とキャリアに迷うエンジニアは少なくありません。次々と登場する新しいフレームワークや生成AIツールに追われ、技術の陳腐化に焦りを感じることも多いはずです。
本田技術研究所、DeNAといった多様な環境を渡り歩き、現在はフューチャーアーキテクト株式会社でシニアアーキテクトを務める渋川よしき氏は、「流行に飛びつくのではなく、目の前の技術を丁寧に学ぶことが重要」と語ります。
本記事では、数々の技術書の執筆や翻訳を手がけ、確固たる技術的基盤を持つ渋川氏に、流行に振り回されない汎用的なスキル構築法や、AI時代に本当に求められる「高度な設計力」の磨き方についてお話を伺いました。
渋川 よしき
フューチャーアーキテクト株式会社 シニアアーキテクト
本田技術研究所、DeNAを経て現職。技術書の執筆や翻訳も手がけ、「実用Go言語」「Real World HTTP」「Goならわかるシステムプログラミング」の執筆、エキスパートPythonプログラミングの翻訳などを行う。2023年5月に翻訳書「ソフトウェア設計のトレードオフと誤り」を、7月に「エキスパートPythonプログラミング改定4版」を上梓。
【X（旧Twitter）】：https://x.com/shibu_jp
フューチャーアーキテクト株式会社
ITを武器に戦略から実装までを担うコンサルティングサービスを提供。お客様の抱える経営上の課題を経営者の視点で共有し、お客様のビジネスの本質を理解した上で、実践的なノウハウをもとにテクノロジーを駆使した情報システムを構築しお客様のビジネスの発展をサポート。特に大規模な基幹システムの構築における「データベース中心設計」など、堅牢なアーキテクチャに定評がある。
【HP】：https://www.future.co.jp/architect/
【X（旧Twitter）】：https://x.com/future_recruit_
目次
異業種を渡り歩いても「即戦力」であり続けるための汎用的技術力
渋川さんはこれまで本田技術研究所からDeNA、そして現在のフューチャーアーキテクトと、全く異なる業種・ドメインを渡り歩いてこられました。どの現場でも即戦力であり続けるために、ご自身のキャリアの中で意識されてきた汎用的な技術力とはどのようなものでしょうか。
あまり「汎用的」ということは意識しておらず、目の前の技術を一つひとつ丁寧に学ぶということが一番大事だと思っています。例えば今流行っているReactやVueなどのアーキテクチャも、過去からのきちんとした積み重ねで設計されているものなんですよね。
生成AIのようにパラダイムを大きく変える例外的なものはありますが、基本的には業界で色々な技術が出てきても、全く新しいものというのは実はあまり出てきていないと感じています。
なるほど、ゼロから全く新しいものが次々と生まれているわけではないということですね。
新しい技術も「大体8割は既存と同じもので、2割が新しい」という感覚です。新しいからといって全くの学び直しになるわけではなく、その差分だけ学べばすぐに使える状態になると思います。むやみに流行に飛びついて新しいものを次々と触るよりは、腰を据えて1つのものをじっくり学ぶ積み重ねの方が良いのではないでしょうか。
その「差分学習」という考え方は非常に勇気づけられますね。焦って流行を追いかけるよりも、今ある技術の土台を固める方が結果的に近道になりそうです。ちなみに、仕事を選ぶ上でこだわっているポイントなどはありますか。
自分の担当領域や業務内容を最初から決めつけず、「これをやってください」と任されたことはきちんとやる、それの積み重ねですね。自分から見えている世界や好みが全てではないので。
会社から指示されたことも、自分にとって見えていなかったニーズが降ってきたと捉えれば良いと思っています。業界が変わっても、ユーザーのためにシステムを作るという意味でのベースは変わりませんから。
食わず嫌いをせずに取り組むことで、自分の枠を広げていくのですね。新しい技術や未経験のドメインに飛び込んだ際、渋川さんなりの「まずここを押さえる」というアプローチ法はありますか。
新しいドメインでも、人間がコードを書くという意味では変わりません。独自の書き方にこだわって奇をてらうのではなく、誰が読んでも読みやすいコードを書くこと。そして、それぞれのフレームワークやツールのコーディングスタンダードに素直に従う、つまり「その技術の文化や、チームの標準に合わせる」ということが一番大事だと考えています。
郷に入っては郷に従うということですね。具体的な学習の手順としては何から始めるのでしょうか。
まずはチュートリアルで自分の手を動かしてみます。そうすると自分が分かっているところと、分かっていないところがはっきりします。あとは、フューチャーのお客様とオープンソースのドキュメントの読書会を継続していて、例えばReactのドキュメントを頭から最後まで全部読むようなこともしています。
ドキュメントには設計者が知ってほしいことが書かれているので、一通り隅から隅まで知ることで、困った時の引き出しが増えていきます。最近は生成AIを壁打ち相手にして質問攻めにするのも有効な勉強法ですね。
低レイヤーやプロトコルを学ぶことが、結果として「最速の開発」に繋がる理由
渋川さんは『Real World HTTP』などの著書を通じて、プロトコルやシステムプログラミングの知見を発信されています。モダンなアプリケーション開発において、こうした基礎を学ぶメリットは何でしょうか。
プロトコルやシステムプログラミングを知っていればいるほど、何か困った時やデバッグの時の手数が圧倒的に増えるというのが一つのメリットです。基本的にはフレームワークに乗っていれば細かいところは気にしなくて済むようになっています。ただ、例えばキャッシュの仕組みがよく分からない時などに調べものを繋げていくと、「実はHTTPってこうだったんだ」と気付く。そういう細切れの知識がつながって身についていく流れが大切だと思います。
最初から焦って全てを学ぶ必要はなく、業務で壁にぶつかった時に深掘りしていくうちに身についていくものなのですね。とはいえ、どこまで深く学ぶべきか迷うエンジニアも多いと思います。
私はよく「自分が書いているレイヤーの1層上と1層下のスキル」を意識して知っておくと役に立つと説明しています。例えば、Webフロントエンドを開発しているなら下のHTTPを少し勉強しておく。C++を書くならOSの話を知っておく。逆にフロントエンドから1つ目線を上げて、デザインパターンやアーキテクチャの設計論を知っておく、といった具合ですね。
非常に明確で分かりやすい指標です。これなら多忙な現場のエンジニアでも、学習のスコープを絞りやすそうですね。システムの内部構造を知っていることで、日々の開発スピードやトラブル解決力にはどう影響するのでしょうか。
開発スピード自体は、フレームワークの使い方を知っているかどうかのほうが大事だと思います。ただ、パフォーマンスチューニングや原因不明の問題解決には、内部構造の理解が不可欠です。例えば、ループの途中で外部通信をしていて全体の処理が遅くなっているような場合ですね。
なるほど、平常時の開発速度というよりは、イレギュラーな問題が起きた時の解決力に直結するのですね。特にネットワーク周りのトラブルは現場でも多そうです。
一番多いのはネットワーク周りだと思います。通信ができないという問題は、クラウドの時代になっても基本的な考え方は変わりません。ネットワークが届かないなら、どこのレイヤーで止まっているのかを1つずつ調べて原因を突き止めていく。その意味で、基礎知識を持っていると非常に強いです。
「技術書の執筆」は究極の学習法。アウトプットを前提に知識を構造化する
渋川さんは技術書の執筆や翻訳など、極めて密度の高いアウトプットを継続されています。このプロセスがご自身の知識の構造化にどう繋がっているのでしょうか。
大げさなものではなく、仕事の中で調べて分からなかったことを日々ブログの形でメモしているだけなんです。ブログにしておけば、後でGoogle検索した時に自分の記事が出てきて調べやすいですから。
ただ、ブログの記事にするためには、断片的な情報だけでは成立しません。前提となる技術や状況を説明し、汎用化して多くの人が読んで理解できるものに整理する必要があります。
自分用のメモでありながら、他人が読んでも分かるレベルまで情報を整理・抽象化するプロセスそのものが、知識の定着を促しているのですね。発信する情報はどのように選別しているのですか。
業務で得た知識は、大きく「ドメイン知識」と「プログラミング知識」に分けられます。特定のお客様のドメイン知識は、機密性が高いので外に出せませんし、そもそも必要な人が限られていて多くの人には役に立ちません。
そのため、特定の文脈や固有の情報を削ぎ落とし、汎用的な「プログラミング知識」に昇華させて書くようにしています。そうやって情報を整理することが、結果的に後から自分が見ても一番役に立つナレッジになるんです。
固有の情報を削ぎ落として汎用的な知識へと昇華させるからこそ、社外へのオープンな発信が可能になり、それが巡り巡って社内からの新たな相談にも繋がるのですね。ちなみに、インプットした情報を「記憶しておくべきこと」と「忘れてもいいこと」で分けたりはするのでしょうか。
基本的には「全部忘れていい知識」だと思っています。アウトプットしておけば後で思い出せるので、書いて忘れて、次の新しいものに取り組むという感じです。本当に必要な知識は何度も繰り返し触れることになるので、暗記はしていなくても、何かあったらすぐ引き出せる状態にしておく感覚ですね。
「翻訳」から学ぶ、世界標準のエンジニアリング志向
渋川さんは海外の優れた技術書の翻訳も多数手がけられていますが、読者の中には「海外の方が設計思想が進んでいて、日本はもっとそれを取り入れるべきだ」と感じているエンジニアも多いと思います。実際のところ、どうお考えですか？
実は、本質的に海外が優れているということはあまりないと思っています。クラウドの様々なサービスや生成AIなど、海外発のプロダクトが多いので、それに伴って開発の設計思想なども進んでいると勘違いされがちですが、日本の現場の設計スキルやプログラミングのスキルも全然負けていません。アメリカにいたこともありますが、日本にいる技術者も全然負けていないなと実感しました。
プロダクトの発信源が海外だからといって、エンジニアの設計思想そのものに圧倒的な差があるわけではないのですね。少し安心しました。
そうですね。ただ、海外ではそうした現場の知見や設計思想を体系的な本にまとめて出版する動きが活発なので、内容がしっかりとまとまっていて面白いものを日本のエンジニアにも届けたい、という基準で翻訳する本を選ぶことが多いですね。 もちろん、新しい技術の発信源が海外であることは多いです。
ただ、そういう最新分野は英語の書籍が出るスピードもそこまで速くありませんし、今はWebを通じて日本でもほぼタイムラグなしに情報が入ってきます。 そのため、海外の書籍を翻訳して出版する際は、出版までに2〜3年遅れても陳腐化しないような普遍的な内容でないと、そもそも企画が通りにくいという出版側の事情もありますね。
スペシャリストとして生き残るための「学びのポートフォリオ」
Python、Go、システムプログラミングなど、渋川さんのスキルセットは非常に幅広いです。中長期的なキャリアを考えた際、次に習得すべき技術をどう見極めればよいのでしょうか。
私自身は、最初からキャリアを綿密に計画して技術を選んできたわけではありません。自分が「面白い」「便利だ」と感じた技術に純粋に向き合ってきた結果、たまたま半分流行って、半分は流行らなかったというくらいの割合です。
例えば、私がPythonを触り始めた23年前は、日本では全く流行っておらず変わり者扱いされていました。それでも、純粋に気に入ったから使ってみて、オープンソースのメンテナンス（※1）にも参加するようになった、というのが出発点ですね。
※1 Python製ドキュメンテーションビルダー、Sphinxの日本ユーザ会
キャリアからの逆算ではなく、ご自身の興味や「好き」という感情がモチベーションの源泉だったのですね。とはいえ、様々な技術を効率よく習得し、武器にしていくためのコツはありそうです。
一通りいろんな分野の仕組みを知っておくのが良いと思います。例えば、軽量言語（Python/Ruby/PHPなど）を1つ、システム寄り言語（Go/Java/C#/C++など）を1つ、そしてSQL、Webフロントエンドのフレームワークを1つ。各ジャンルで何かしら1つ「作れる」技術を持っておくと、学びが非常に速くなります。
各ジャンルの代表格を1つずつ押さえておけば、新しいツールが登場してもすぐに適応できるということですね。
そうですね、例えばMithrilというフロントエンドのフレームワークは気に入ったけど残念ながら流行らなかったものの1つではありますが、このフロントエンドのフレームワークの仕組みや書き方が分かっていれば、ReactやVueを触っても大体のパラダイムは同じなので、すぐに書けるようになります。流行るかどうかとビクビクしながら技術選定するのではなく、目の前にある各ジャンルの代表を軽く押さえておく方が費用対効果が高いですね。
現場のPL/PM層の中には、マネジメント業務が忙しくて技術の深掘りができないと悩む方も多いです。リーダー層はどこまで手を動かすべきでしょうか。
チュートリアルをやって卒業してしまう人が多いですが、要件から設計、そして自分が作りたいものを一気通貫で作れる経験を一度持っておくことが大切です。設計的な思考の基盤は、言語やフレームワークが変わっても活きるものですから。
生成AI時代のエンジニアリングと「データベース中心設計」
AIによるコード生成が普及したことで、エンジニアの市場価値や評価軸はどう変わっていくと予想されますか。
「書く」という作業のレイヤーが変わり、フォーカスポイントが変わってきています。昔は手書きの手紙で「字が綺麗」なことが評価されていましたが、携帯電話で文字入力するようになると字の綺麗さはどうでもよくなりましたよね。それと同じ変化です。特定のフレームワークの知識があって手が早い（タイピングが早い）といったことの評価比重はどんどん低下していくでしょう。
手書きからタイピングへの変化という例えは、非常に腑に落ちます。では、AI時代において逆に重要度が増すスキルは何でしょうか。
AIへの1回の指示で作れるコードは、数千行程度のものです。巨大なシステムを一発で作ることはできません。そのため、大規模なシステムを成立させるための適切なモジュール分けやレイヤリングといった「設計力」の重要性が相対的に増大しています。AIが出力した結果の妥当性を判断し、運用上のオペレーションを設計するのは人間のスキル領域です。
完璧なコードを追求するのではなく、AIの特性を理解した上で全体を設計する力が必要なのですね。最後に、AIが代替しにくい「高度な設計力」を身につけるためのステップと、読者へのメッセージをお願いします。
フューチャーアーキテクトでも大切にしている「データベース中心設計」をきちんと行うことが、高度な設計力の核になります。基幹系ではデータベースの寿命が長いため、テーブル設計をし、トランザクションの境界を見極め、サービスを分割する。AIに仕事を任せる単位や、ボトムアップで組み立てる順序を設計する力は今後も不可欠です。
AIがあるからエンジニアがいらなくなるという話に踊らされる必要はありません。むしろ、今までPMやPL業務が忙しくて手が動かせなかった人にとって、AIは様々なアイデアを実現してくれるチャンスです。これまで培った知識でどんどんモノが作れる時代ですから、ぜひこの環境を楽しんでいってほしいなと思います。
ライター
