こんにちは、エンジニアのづやです。
LIGでは、Ruby開発者であり、当社の技術顧問を務める、まつもとゆきひろさんによる社内勉強会を開催してエンジニアのスキルアップに取り組んでいます。
第5回のテーマは「エンジニアの技術トレンドとの向き合い方と注目の技術」です。
流れの速いIT業界において、目の前の仕事に向き合いながらあらゆる技術トレンドを追い続けるのは至難の業です。そこで今回はまつもとゆきひろ流の、エンジニアが技術トレンドを追うときのポイントを伺いました。また最近話題の「ノーコード・ローコード」「ChatGPT」、まつもとさんが注目している「Hotwire」「Jamstack」についてもお話しいただきました。
 |
Rubyアソシエーション理事長 まつもと ゆきひろ プログラミング言語Rubyの生みの親であり、一般財団法人Rubyアソシエーション理事長。株式会社ZOZOやLinkers株式会社など複数社で技術顧問などを務めている。オープンソース、エンジニアのコミュニティ形成などを通じて、国内外のエンジニアの能力向上やモチベーションアップなどに貢献している。 |
|---|
目次
情報収集はジャンルを絞ろう！
プログラマーという仕事は、よく「一生勉強」と言われます。ですが仕事をしなければ食べていけず、勉強だけに時間を使うわけにはいきません。では仕事をしながら、どのように勉強時間を捻出すればいいのでしょうか。
40年くらい前、私がプログラミングを始めたころは、手に入る情報は限られていて、それらをすべて読むのはそれほど難しいことではありませんでした。ですが今のIT業界は変化が激しく、情報の流れが速い。全部の最新情報を追いかけるのはまず無理です。
そのためジャンルを取捨選択して、自分にとって必要な情報をしっかり学んでいくことが大事です。
ポイントは「専門分野」と「課題」
ジャンル選択の方法として、私は次の二つをおすすめします。
一つ目は「自分の専門分野」です。
自分が得意・詳しいジャンルであれば、すでにある程度の専門性があるため、新しい技術でも理解しやすいでしょう。また専門分野を持つエンジニアに対して、周囲も「あの人は最新情報を持っているはずだ」と期待していると思います。そのため自分の専門分野の情報収集や学習は、時間をかけましょう。
二つ目は「直面している課題」です。
自分や周囲が何かしら課題を抱えているときに、それを解決できるテクノロジーが出てきたら、優先して学んでいきましょう。課題がわかっているため学ぶべきポイントもわかり、効率的に勉強ができると思います。それが課題解決にも直結するでしょう。
課題に敏感でいよう
エンジニアは、課題に対して常に敏感であってほしいと思っています。ソフトウェア開発において「ここはもう少し改善の余地があるんじゃないか」と課題を瞬時に発見できれば、学ぶべきことも見えてくるはずです。
また日々コードを書いたり、仕様を決めたりするなかで、できるだけ技術トレンドには常にアンテナを立てておくようにしましょう。
そのためにも、仕事が忙しすぎてはいけないと思います。たとえば8時間会社にいるとすると、その間ずっと会議をしていたり、ひたすらコードを書いていたりしていては、情報は入ってきません。課題意識を持っていても、そもそも解決するための情報を得る暇がないのです。このような状況が続けば、いずれ情報に取り残されてしまうかもしれません。
ぜひ仕事の生産性を上げるなどして、情報収集の時間が取れるようにしてください。
最近話題の技術の解説と注意点
エンジニア界隈で話題となっている技術について、簡単な解説と注意点をご紹介しておきます。
ノーコード・ローコード
ノーコード・ローコードは便利と言われますが、自分でプログラムを書けるプログラマにとっては逆に面倒かもしれません。ですが、自分でコードを書けない方たちに対して、簡単にデータを加工して見せることができるという点で、プログラマのアピール手段として使えます。
1950年代にプログラミング言語「Fortran」が登場する前は、どんなに巨大なプログラムでもすべてマシン語で書かなければいけませんでした。Fortranはその状況を変えたため画期的だと言われましたが、その後プログラミング言語はどんどん進化し、今や書く量はFortranの何十分の一程度です。つまり、ローコードはプログラミングの進化過程なのです。
ただしノーコード・ローコードが広がることには、懸念点もあります。
一般的にノーコード・ローコードでは、データの入手先やデータ出力フォーマットは指定されたものからしか選べません。そのため、表現できるプログラミングモデルが限定されます。
当初はそれを理解し納得していたとしても、人間の欲望というのは限りがないものです。だんだんと「こういったことはできないか」「もう少し改善できないか」と考えるようになるでしょう。
それがノーコード・ローコードでできることの限界を超えると、作り上げたものは捨てて普通にプログラミングをすることになる。結局「プロトタイプツールにしかならなかった」となる可能性があるのです。
また、ノーコード・ローコードを使えば初心者でもアプリケーションを作ることができるため、たとえば社員が勝手に社内データを使って自分用のツールを作り、それをほかの人も使うようになって社内に浸透するケースがあります。これは一時的には便利かもしれませんが、元のデータベースの仕様が変わったといったときには、ツールのアップデートが大変だったり、開発者がすでに会社を辞めてしまっていて誰もメンテナンスできなかったりするといった事態に陥りかねません。つまり、社内システムに悪影響を及ぼす可能性があるのです。
ノーコード・ローコードは入口としては価値があると思いますが、長期的・大々的に使う場合には課題も多いと理解しておいてください。
ChatGPT
今大変話題になっている技術といえば「ChatGPT」です。
「コンピュータ科学の父」とよばれる研究者アラン・チューリングは1950年に書いた論文で、コンピュータが本当に知性を持ったかどうかを判定する方法として「チューリングテスト」を提案しています。これはチャットで十分な対話を行ったあとに、対話の相手が人間かコンピュータか判定できなかった場合、そのコンピュータには知性があると判断していいとするものです。
私はChatGPTは、すでにこのチューリングテストを余裕でクリアしていると思います。つまりチューリングテストの観点からは、すでにコンピュータは知性を持っていると断言できます。これは素晴らしいことです。
ただし気をつけなければいけない点もあります。
ChatGPTは大規模言語モデルの「トランスフォーマー」を使っています。そのため今のAIとのやりとりは、言語情報を大量に集めて、プロンプトの流れに応じて相応しい文章を返しているだけです。膨大なデータを抱えているために、それらしい答えが出せているのです。
またChatGPTの返答のベースとなるデータには、最新のものは含まれていません。そのため例えば2023年のWBCの優勝国を聞いても、正確な答えは返ってこないはずです。
加えて、生成した文章に含まれる情報が本当に正しいのかどうかを保証する仕組みもありません。たとえば私がChatGPTに「まつもとゆきひろはどこに住んでいますか」と聞くと、「長野県松本市に住んでいます」と答えました。私は長野には住んでいません（笑）。
SF映画ではロボットやコンピュータは嘘をつけず、無理矢理嘘をつかされると壊れてしまうというシーンがよくあります。ですが現実には、知性を持ったコンピュータは息を吐くように嘘をついています。
ただ私は、そもそも最新の情報を持っていないChatGPTを「知識を得るためのツール」として使っていることが間違っていると思います。
ChatGPTのおすすめ活用法
ChatGPTは「言語を扱うツール」として活用するのがいいと思います。
たとえば要約です。文章内の重要な部分を切り出す要約という作業に最新データは必要なく、言語に対する知識さえあれば実行できます。実際に自分について書かれたWikipediaのページを要約させましたが、内容は半分程度になって、意味も大体合っていましたね。
原稿の校正もおすすめです。校正を指示すると誤字脱字を指摘してくれたり、別の表現を提案してくれたりします。また、英語の文章を「もう少し流ちょうな表現にしてほしい」と頼むと、内容をアップデートしてくれます。英語が苦手な日本人には非常に便利だと思いますね。
プログラミングの領域においても、かなり活用できると思います。プラグラミングはプログラミング“言語”という人工の言語で表現されるため、ChatGPTにとっては扱いやすいジャンルです。たとえばPythonで書かれたプログラムをRubyに翻訳するといった指示ができ、その返答も内容は大体合っています。私は試していませんが、プログラムにコメントを書く作業もできるそうです。
なお、個人的にはペアプログラミングAIの登場を期待しています。2人でコードを見て、コメントをつけながらブラッシュアップしていく「ペアプログラミング」はプログラミングにおいて非常に有効な手法です。ただし、誰かと一緒に作業するため気を遣って疲れてしまったり、相性が悪くてうまくいかなかったりなど、思うように作業が進まないこともあります。
ですが、その相手がAIであれば遠慮は不要です。またAIに関数やテストコードを生成してもらい、それをベースに作業を進められれば、雑務をAIに任せられるため仕事の効率もアップするはず。ペアプログラミング用AIが登場すれば、生産性は格段に上がると思いますので、開発を期待したいですね。
まつもとゆきひろの注目の技術
ここまで世間で話題となっている技術を紹介しました。ここからは私が注目している技術トレンドを二つご紹介します。
フロントエンドとバックエンドの境界線問題
Webアプリケーション開発においては「フロントエンドとバックエンドの境界線をどこに置けばいいのか」という悩みをよく聞きます。
昔のアプリケーション開発は、RailsのビューにHTMLを書けば終わりでした。簡単な機能を追加するくらいであれば、1時間程度、長くても1日あれば作業は終わりました。
ですが今の開発現場では、見栄えとデータベースなど扱うものに応じてフロントエンドとバックエンドでチーム分けをしているケースが多い。その状態で開発をしていくと、必ずどこかで両チームの会議が必要になります。そして、この「会議」が、仕事を遅らせる原因になるのです。
フロントエンドとバックエンドそれぞれのチーム内で会議をする、そのうえで両チームで会議をして内容をすりあわせる。構造的に利害対立が起きやすく、やり取りが増えれば、それだけ仕事の進みは遅くなります。
一般的にRailsは、素早く作業ができて生産性が高いという理由で開発に採用されています。ところがフロントエンドとバックエンドにチームが分かれると、その良さが失われてしまうのです。私はずっと、このようなフロントエンドとバックエンドの線引きには課題があると思っていました。
その解決策になるものとして注目しているのが「Hotwire」と「Jamstack」です。
Hotwire（HTML OVER THE WIRE）
Hotwireは「HTML OVER THE WIRE」の略で、Railsアプリケーションのためのオープンソースのフロントエンドフレームワークです。
ビューの部分にタグのようなものを付けておくと、そのタグの部分を操作するだけで簡単にリアルタイムでHTMLをアップデートできます。バックエンドはHTMLだけで作業ができるため、昔、Railsだけでアプリを作っていたときと同じスピードで作業ができます。このスピード感がHotwireの最大の魅力といえます。
一方、フロントエンドにはStimulusという名前の小さいJavaScriptが送られています。これがRailsアプリケーションと通信することで、HTMLのエントリーをDOM操作ですり替えたときと同じことができるのです。
Hotwireはすべてのアプリに対応しているわけではありませんが、HTMLとCSSだけでつくれるアプリであれば、JavaScriptを一行も書かずにシングルページアプリケーションを書くことも可能です。
すでに実装も進んでいて、メールアプリケーション「Hey」はHotwireを活用して作られています。Heyはシンプルなアプリということもあり、それなりに高速で動きます。
Jamstack
JamstackはJavaScriptとAPI、Markupを組み合わせた開発手法です。
バックエンドにはAPIしかなく、アプリケーションなどすべてをJavaScriptで書いて、フレームワークごとフロントエンドに送るという仕組みです。表示速度の改善、セキュリティの向上などが期待できます。
Hotwireがすべてをバックエンド側に持っていったのに対し、Jamstackはすべてをフロントエンド側に持っていっています。両者のアプローチの仕方はまったく逆ですが、フロントエンドとバックエンドの境界線をどちらか一方に動かすことで、調整コストを減らして生産性を高めることができると思います。
まとめ：自分に必要な情報を効率的に追いかけよう
開発が忙しく「情報が追えていない」「仲間の話についていけない」と焦っている方もいるかもしれません。ですがインプット・アウトプットが仕事のまつもとさんでも、すべては追い切れていないとのこと。悲観的にならず、ChatGPTなども上手に活用して、業務効率化・情報収集を進めていきましょう。
次回のまつもとゆきひろ勉強会もお楽しみに！
