2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
司会者:それでは時間も押してきてしまっているので、「技術選定の方法」というところで、実際にプロダクトを作る時に、どういった点を考慮して技術の選定をしているのか、それに対するベストプラクティス的なものはあるのか。
あとは、技術選定をした際に、「これでいきます」みたいなことを説明する機会もあると思うんですが、そこで心がけていることがあったらお聞きしたいと思います。LIGさんはどうですか?
土屋大輔氏(以下、大輔):弊社では、技術選定は基本的にエンジニア個人に任されています。もちろん聞いてくれたら、他のエンジニアがレビューするみたいなこともしますが、基本的には(個人に)任せてます。
「どういう基準で選んでいるか」を一言で言うと、「ちょうどいいものを選ぶように」です。なので、オーバースペックすぎるものを選んで、難しくなって詰まってしまうことになってもいけないし、プリミティブすぎて実装が逆に大変になるということもないようにしています。ちょうどいいものを選んで、(既存のものと)組み合わせて使う感じです。
具体的に言うと、さっき(の登壇で)も挙がっていましたが、私はNuxt.jsを最近使っていたりします。Web製作なのでSPAを作ることはあまりないんですが、(Nuxt.jsは)静的にサイトを書き出すみたいな機能も持っているので、使ってみたりしています。
WordPressになるとNuxtは別の話になってくるので、あまり採用したりはしていなくて、WordPressはシンプルにWordPressです。たまにPjaxみたいなものを入れたりしてる感じです。
千葉弘太郎氏(以下、千葉):これは弊社の課題だと思っているんですが、けっこう今までは攻めていて、とりあえず案件に関わらず最新技術を入れているケースが多かったんです。最近スクラム体制になって、いろんな人間が同じものを触るようになったので、そこらへん(技術選定)は慎重になっています。
例えば、ReactなのかVueなのかという時に、デザイナーまで入って、「どっちが実装しやすいか」とかは必ず検証しています。
あとは、JSをあまり触ったことがないエンジニアに、いきなりNode.jsやReactを書かせるのは、フロントエンジニアからしても、なかなか酷だと思うので、Reactを選ばなくても継続的にプロダクトをリリースできるようなかたちをとったりしています。
なので、無理はしない、ある意味突っ走らなくなってはいますが、弊社はいろんな事業や案件を持っていますので、フロントだけに限っては、そこらへんを選定できる人間をもう少し増やしていきたいなと思っています。
松本雄太氏(以下、松本):そこらへんは難しいですよね。
千葉:そうですね。技術選定は難しい。
司会者:エアークロゼットさんはどんな感じですか?
松本:ものすごく簡単に言うと、ある程度GitHubのスター数とかは見ます。リリース頻度も見ます。
あと、先見性はけっこう大切だと思っています。最近だと、Reactのカンファレンスが先月末にあって、そこで注目を浴びていたのが「Hooks」という機能だったんです。
今までStateless Functional Componentsと呼ばれていた関数、要はクラスを使わないでコンポーネントを定義する方法は、「ステート使えないよ」「ライフサイクルメソッドを使えないよ」という制約があったりして、結果としてクラスを書かなきゃいけなということがあったんです。
それでも「SFC使いたいね」という中で、recomposeに派生してきたという流れがあったり、データフローで「基本的にContextがイケていないからRedux入れるんだ」ということもありました。
Hooksの機能の中にuseState、useReducer、useContext、useEffectという機能が入りました。16.7.0-alpha.とかから使えるやつなので、まだまだ本番で使うのはあまり推奨してないんですが、もしかするとReduxとかrecomposeとかがなくても、Stateless functional components、Hooksを使った場合は、もはやステートを持っています。functional componentsと言うんですが、今後それが主流になってくるという動向を見ながら、「Redux使おうかな」みたいに悩むことで、ちゃんと正しい選択ができるかが技術選定の方法になると思う時もあります。
司会者:ありがとうございます。Reactの話が出てきたので、自分的にもすごく気になる質問をします。「ReactとVueについて、1〜2年後の盛り上がりは?」というのと、「また、それ以外の技術(の盛り上がり)は?」ということで、ここはかなり見解が分かれるかもしれません。
LIGさんはNuxtを使っていたり、千葉さんとかはNextを使っていたりしますが、この2つは比較対象によく挙げられますよね。「ぶっちゃけ、1〜2年後どうなってる?」というところで、本音を聞きたいなと思っています。ここは思いついた人から挙手制でいきましょう。
千葉:弊社は(ReactとVueの)両方を使っているので、数年後にどうやっているかわからないんですが、個人的に興味があるのは、例えばWeb Componentsなど、もう少しWeb標準に沿ったコンポーネントを設計できて、もっと知見を貯められるようなアプリケーションづくりができるといいなと思っています。
やっぱりReactもVueも、人が作っているものというか、Web標準ではないので、「シンプルに使い回せるコンポーネントが作れたらいいな」というところで、弊社もWeb Componentsをどこかで入れたいなと考えているんですが、まだPolyfillを使っていたり、Polymerを使わないとそもそも動かない機能がいっぱいあったりするので、そこらへんはまだわかりません。
ReactとVueは、「まぁ残ってるんじゃないかな?」ぐらいしか言いようがないです。弊社もReactとかは3年前に運用しているので、1〜2年でなくなるような技術ではないんじゃないかという気はしています。
司会者:なるほど。
千葉:どうですか、みなさん?
司会者:みんなめっちゃ頷いてる(笑)。
土屋:同感ですね。
千葉:えー、同感?(笑)。
土屋:先を見るセンスが問われているような気がして、答えるのもちょっと怖いんですけど(笑)。本当に同感で、シンプルに答えると「残っているんじゃないか」「まだ使われているんじゃないかな」という印象です。
やっぱりWeb標準の仕様を、もう少し取り込んでくるんじゃないかと思います。もうすでに「実はWeb Componentsで書ける」みたいなこともあるんですかね。わからないですけど。
千葉:そのサービスの推奨環境とかによりますけど、たぶんスマホだとWeb Componentsは、ある程度使えると思うので、今日(来ている人の中で)やられている方も実はいらっしゃるんじゃないかなと思っています。
そこは難しいところですよね。ユーザーさんに届ける側なので、「下手なことはできない」というところと、「試してみたい」というところのせめぎ合いになります。
司会者:ちなみに、今日会場に来ている方で「Web Componentsを実案件で使っています」という方はどれぐらいいらっしゃいますか? ……いない。
千葉: 心理戦?(笑)
土屋:ブラウザの対応状況とかも関係しますよね。
千葉:それもあります。ReactやVueみたいに、たくさんコンポーネントをネストした、巨大なコンポーネントで、そもそもWeb Components自体が耐えられるのかとか、いろんなところでまだ心配なことはあります。
土屋:でも、Web Componentsの仕様だけでは実現できないところを、ReactやVueの周辺機能が持っていたりするじゃないですか。そういう意味ではまだ使われているかな、という予想です。
千葉:そうですね。ぜんぜん実践かどうかはわからないんですが、最近サーバサイドの言語もフロントでできるように、WebAssemblyという技術があるので、2〜3年後には、JSを書かなくてもDOMの整形ができたりする技術が、ひょっとしたら生まれてるかもしれないですよね。
まだそこらへんはわからないのと、実践に耐えてるサービスをあまり聞いたことがないので、なんとも言えない感じです。
松本:僕もおっしゃられたとおりだと思います。いかに標準化するかがキーになってくると思います。結局ブラウザがプラットフォームの中で動く以上、ブラウザの仕様には抗えないというところがあるので、そこがどこまで盛り上がってきて、僕らがどこまで保守するかという感じもします。
React・Vueに関して、僕が思っていることとしては、今の人気から見ると1〜2年後はぜんぜん大丈夫だと思います。もともとReactの伸びがすごかったんですけど、最近はVueの伸びもかなり上がってきていて、僕自身はReact信者なんですが、Vueのほうが盛り上がるかなと思ったりしています。
とはいえ、たぶん好き層というか、信者層というのは違ってくるかなと思っていて、ReactはVueと比べるとけっこう固いんですよね。Vueは柔軟な書き方ができたりするので、わりとRubyライクな感じなのに対して、ReactはけっこうJavaライクな感じで、もう固く書くしかないというところで、たぶん棲み分けができてくるのかなと思います。
長期的に保守やメンテを考えていくと、たぶんReactに軍配が上がるものの、Vueのほうが開発速度とかは速いよねという感じで、棲み分けられるのかなと。
司会者:Vueはデザイナーからフロントエンドに転身した方とかも入りやすくて、適度なハードルの低さだと個人的には思います。Reactのほうがハードルが高いイメージがあるんですけが、そこらへんはどうですか?
松本:それはおっしゃるとおりだと思います。絶対Vueのほうがとっつきやすいし、書きやすいと思います。ただ、Reactは決まった書き方をしないといけないので、保守性では優れていると思います。
司会者:プロダクトの性質やチーム体制、開発するものの規模だったりで、いい具合に棲み分けしていく感じですかね。
松本:そんな感じはあります。ただ、個人的な意見としては、好きなものを使ったらいいんじゃないかなと(笑)。
司会者:確かにそれにかぎりますね。ありがとうございます。せっかくReact Nativeの話がでていたので、Webアプリやネイティブアプリ、あとPWAとかの話も聞きたかったんですが、ここらへんは交流会でお話できたらと思います。
司会者:最後に、「今後のフロントエンドの変化」についてお聞きしたいと思います。技術的なところもですが、「エンジニアの担当領域がどうなっていくのか」「拡大するならどういった領域がスキルとして求められるか」というところをお聞きしたいです。挙手制でお願いします。
岡澤伸也氏(以下、岡澤):じゃあ、僕から話します。そんな大それたことは言わないですが、「社内は社会の縮図」と、僕は……。
(一同笑)
僕なんかもそうですが、「フロントエンド」という名でやっているんですけど、ちょっとPHPを触ったりしていて、フロントエンドとバックエンドの領域がどんどんフラットになってきているというか、そこの領域を踏み越えて、やっている人が増えてきているなというのは実際に感じています。
それはジェネラリストという道で、1つの道としてあるんじゃないかなと思うんですが、Web製作の現場で言うと、先ほどの実績でも紹介しましたが、WebGLであったり、描画系の技術を使う場面があります。なので、実際に「WebGL Developer」という呼び方が、海外では出てきています。
スペシャリストはいろんな道がこれからできていくんじゃないかなと、僕は勝手に思っています。
司会者:ほかの方はどうですか?
松本:フロントエンドの変化についてだと、「画面を作らなくてよくなるんじゃない?」ということは思っています。
今はぜんぜんイケてないんですけど、Sketchなどを使って画面を作った時に、そのコードを落とせたり、React Native版が落とせるのもあるんですけど、そこで落とされるコードは、「そのまま貼りつけたら全部absoluteになる」みたいな、ちょっとやばいやつなので使えないんですが、今後そういうのもGUIでできるようになるんじゃないかと思います。
あと、今のWebってJavaScriptが王位につくじゃないけど、基本的にJavaScriptからは逃げられない世界じゃないですか。
そういったところで、たぶんAssemblyの話とかがあったりして、新しい技術がどんどん標準的に取り入れられるようになってくると、後発でJavaScriptじゃない、なにか新しいものに置き換わっていくと、うれしく思います。
僕は新しいものを触るのは好きなので、そういうのはぜんぜんウェルカムで、そうなるとまた一層盛り上がるし、おもしろいし、できることも増えてくるかなと。
千葉:そうですね。最近だと正直、ReactとかVueとかES6は書けて当たり前みたいな雰囲気なので、それらの技術をどうプロダクトに落とし込めるかとか、そういうことが求められる。
例えば、モーション系だったらWebGLがいいのか、Canvasなのかとか、そういう判断がちゃんとできる人のほうが重宝される気がします。
僕はデザイナーから(エンジニアに)なって、去年はインフラとかを触っていたんですが、けっこうWebの低レイヤーのことを知っているだけで、だいぶ職種の幅が広がる。広げたくない人もいらっしゃるかもしれないんですが、いろんな人としゃべれるようになります。
「マークアップだけに突出してました」という人が、ネットワークやWebアプリケーションがどうできていくかという低い部分を知っていると、自分のアイデアとかをいろんな人と話せたり、「別にここはフロントでやらなくてもよくない?」「もっと楽してえな」みたいなことも思えるようになります。
伸ばしたい部分と、Webに従事していく上での絶対普遍的な技術というのが、いまだにあると思うので、その両方をちゃんと押さえると、自分のやりたいようにできると勝手に思っています。
司会者:ありがとうございます。
土屋:僕も先ほどの話と同じで、マークアップはだんだん人がやらなくていいようになるんじゃないかと思っています。なので、今までコーダーと呼ばれていたような職業の人は、それだけでは生きていけなくなるんじゃないかぐらいに想像しています。
なので、バックエンドと言えるようなところまで踏み込んでいったり、デザインに関わっていくみたいな関わり方をしていかないと、もうHTML/CSSを書くというようなところは、どんどん人の仕事じゃなくなっていくんだろうなと感じています。
でも、正直まだまだ書くんだろうなとは思います。全てを機械に任せると「全部absolute」みたいな、すごいものが出てきたりするので(笑)。完全に人の仕事でなくなるまでにはまだ時間がありそうですが、きっとその流れは止まらないと思うので、ちょっとマイナスな言い方かもしれませんが、「生き残り方」みたいなことを考え始めたりしています。
司会者:ありがとうございました。時間が来てしまったので、パネルディスカッションを終わりにしようと思います。聞けなかったことや質問がある方は、ぜひこのあとの交流会でお話してください。
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには