yosuke_furukawa

yosuke_furukawa:しびれたやつなんだろうな。。。 派手なやつだと AMP Fest で話したやつですけど、それはシステムの高速化と言うよりはアプリケーションの高速化で、amp-htmlは使っているものの、 AMP のシステムそのものを使わずに自分たちでCDNで高速化したやつですね。実際自分たちでAMPを再構築してたみたいなもんなので、速かったんですけど、まぁこれ以上早くするのはもうAMP辞めるしかないなみたいなところまで行ってましたね。詳しくはこちらを聞いていただけたらと思います。 それ以外だと SSR が遅かったのを早くしたやつとかもありましたね。 https://web.dev/case-studies/five-ways-airshift-improved-their-react-app 自分だけがやってたわけじゃなくてメンバーと一緒になってやったやつなのでここで答えるのは微妙ですけど、そもそも10年以上前のPCでは快適に動かなかったのを動くようにするまでカリカリにJSを削ったり、virtual scrollとかを入れて早くしたんですよね。楽しかったですね。 こういう派手なやつじゃないものだと地道に色々やってましたね。普通にindex貼って高速化したり、全文検索入れて高速化したりとかよくやってましたね。最小限の手で最大の効果が得られるんで、このあたりも非常に楽しかったですね。 ISUCONとかに出てやってることも基本そんな感じですね。 僕はよくバックエンドもフロントエンドも両方の技術を知って性能チューニングしたほうが全体最適になり得ると思っており、それができたときが一番しびれるかもしれないですね。

yosuke_furukawa:本当に自慢できるわけじゃないやつですよね。カンファレンスでもらえるステッカー集めてますね。特に六角形のステッカー集めてます。 昔六角形のステッカー作るサービスとかやってたんですが、それ絡みで六角形のステッカーを集めてますね。 カンファレンスとか行くともらえるやつですね。昔は mac にペタペタ貼ってました。 六角形のステッカーって実は仕様がちゃんとあって、その仕様に従って作ると蜂の巣みたいに周期的な模様になるんですよね。それが好きでしたね。 http://hexb.in/ 今はもうmacに貼っちゃうと大変なので貼ってないですが、今でも取ってあります。 jsconf.jp という僕のイベントでもステッカーたまに出してるんですよね。 前回まではこういうシンプルなのでしたが、 去年は結構思い切ってリデザインしたんですよね。 この可愛いデザインは同僚でもある シェリーさんにやってもらいました。 https://twitter.com/shellyy_jelly

yosuke_furukawa:だいぶ前に来てたやつなんですが、なんか自分が答えるのは違うなーと思いつつ、途中まで書いちゃったんで回答しますね。 どれくらい難しいかというと、そもそも解雇は経営者側からの理屈ではできないように日本の法律ができているんですよね。つまり労働者を守ってる。レイオフや解雇するのではなく、残業をしないように規制したり、コストが高い部署ごと解散させたりして再編成をしますよね。希望退職者を募ったりもしますね。自主的な退職を促したり、コストを減らそうとするわけです。そうやって整理していくことをリストラと言ったりします。経営側からの理屈でレイオフができるものとは文化が違いますね。レイオフはできないが、そうやって人員整理・コストカットをする、時間のかかり方が全然違うので、レイオフよりもめちゃくちゃ難しいと思いますね。 これは日本の法律で失業者を増やさないようにデザインされてるからです。レイオフできる方が経営にとっては嬉しいのは確かで、人を雇って売上を上げたいときと、人を削ってコストを下げたいときが柔軟にできる方が企業としては強いですよね。一方、レイオフが急にされたりしないほうが労働者から見れば嬉しいですよね。 法律は経営者と労働者それぞれを考えたデザインになっていて、アメリカの法律は経営者側に有利で日本の法律は労働者側に有利にデザインされていると思ってます。もちろんここにはグラデーションがあるので、完全にどちらかに寄った設計ではないです。 もう少し抽象的に言うと、日本の法律は幸せになる人を増やすことよりも不幸な人を減らすようにデザインされているんだと思ってます。幸せな人を増やすことと不幸な人を減らすことは似てるようで違うことなんですよね。 次に「その難しさは誰のためにありますか？」という質問ですが、「不幸にも職を失った労働者が暮らしていけなくなるようなことは起きてはいけない」という思想が根本にあると思っています。そのうえでそれを国と民間企業の両方で守らなくてはならないという考え方だと思います。 つまり労働者、ひいては国民のためにあるんだと思ってます。

yosuke_furukawa:「絶対に守るべき」とかそういうのってあるんですかね。 wifi 提供する以上、大量トラフィックをさばくのは前提として、それを捌き切れるのかとかは努力目標になるでしょうし。 盗聴しないとかそういうことですかね。まぁでもそれは大規模カンファレンス開催に伴う必要はなく、あくまで wifi 提供者が倫理として守ることですよね。 まぁそれはそれとして僕は以前CONBUという大規模カンファレンスのwifi提供運営に関わっている人と話したことがあり、すごく参考になったのを覚えています。 https://gihyo.jp/admin/feature/01/conbu-lan/0001 https://gihyo.jp/admin/feature/01/conbu-lan/0002 これを読んでwifiが遅くなるのはどういう理屈なのかとかを参加者の人達が学べるといいなと思ってます。すごく混雑しているか、APから遠かったりでノイズが多いときにwifiは遅くなるので、wifiにとって理想の状況というのから程遠いのが大規模カンファレンスだったりするんですよね。その状況になったとしても利用状況を見てAPを新規設置したり、APの配置を変えたりして細かく理想の状態を作り出すのは非常に困難だったと思うし、CONBUはすごいなーと思ってたのを覚えてます。 ちなみに某カンファレンスで人気の話者が話すときにCONBUがAP追加する処理をしてたのを見てました。たしかそのときは休憩が5-10分程度しかない上に人が移動している中でケーブル持ってAP追加して、動作確認してーみたいなのを即座にやってました。あとあと上の記事を読んで勉強になったなと思いました。

yosuke_furukawa:そういう言語もあるんじゃないですかね。ただ自分はそういう言語は好みの問題でいうと嫌いですね。暗黙にオプショナルチェーンやnull合体してほしいときは少なくて、基本はそのアクセスが不正だった（≒実はnullになることがあった）のに、動いちゃう方が気持ちが悪いなーと思います。 エラーを隠しちゃう時がありそうで、その手前で実は問題が起きていたのに後になって発覚するみたいなことが起きそうな感じがありますね。 この感覚はもしかしたらサーバサイドから来てるからかもしれないですね。なんとなく、データ不整合だったり、本来あるはずのものが無かったときは動いてしまうよりも早くエラーになってほしいんですよね。結果動作不良で障害になるかもしれないですが、データ不整合な状態で動くよりマシだと思ってしまいますね。 だからオプショナルチェーンやnull合体は明示的に指定して、ここではそれがnullになることは気にしないのだという事がコード上で明確になっている方が好きなんですよね。 それはそれとして、冒頭に「そういう言語（普通のメンバーアクセスがoptional chainになったり、式文がnullishになるもの）もあるんじゃないですかね」と書いたので本当にあるのかなと思って調べてみたんですけど、無さそうですね。 optional chaining が出た当初は Groovy が2007年に実装しており、そこからC#やSwift、CoffeeScriptに導入され、JSにも導入されーみたいな流れでしたね。nullish coalescingは Perl が `//` で実装したのが起源とされており、そこからC#が `??` で実装し、そこからJSにも導入されーという流れでしたね。 optional chainが入った経緯は pyramid of doom (いわゆる、 if foo != null のなかで bar != null, baz != null をチェックしていきネストが深くなる問題)を解決するための方法として生まれたのですが、pyramid of doom の問題の解決策は「そもそもそこまで深くなるようなオブジェクトを作らない」という話になり得るので、用法用量を守って使うほうが良さげですね。

yosuke_furukawa:結構実は昔からカメがロケット背負ってる比喩がnode.jsで使われていたので、違和感はないですね。なんかでももう少しカワイイ感じにしてほしいですね。ミュータント・タートルズに出てきそうな亀だなーと。。。 海外のアニメ出ててきそうですよね。キャッチーさが足りないというか、GoとかDenoみたいなぬいぐるみにできそうな感じが足りない気がしてるんですよね。なんかもうちょい自分の表現力不足なんですけど、ポケモンのゼニガメみたいな感じにできなかったかなと。 ちなみになんでカメとロケットなのかというと、カメがJavaScriptのアナロジーで遅いイメージが合ったからだと思っており、それを v8 というエンジンを積んでおり、これがv型8気筒でモータースポーツ用の車や飛行機なんかにも使われるくらい速いエンジンのイメージが有り、それがロケットでブーストされてるので、このイメージなんだと思うんですよね。 もともとはこういうイラストを書いた人がいて、 https://github.com/nodejs/admin/issues/828 それが今の画像につながっているんだと思います。 （ちなみに、これ初めて書いたのsubstackだと思ってたんだけど、どこにも言及がないな。。。）

yosuke_furukawa:最近フレームワークやツールと言うよりももしかしてものすごく重要なのは「聴く」ということなんじゃないかなと思い始めてます。 最近 LISTEN という本を読んだことがきっかけで、実は人は思った以上に聞いてないのかもというのを考え始めたからです。 https://amzn.asia/d/5O9YyLY デリゲーション能力、つまり権限委譲する力ということですが、その逆が率先垂範というか自分で背中を見せて実行するいわゆるリーディング能力ですよね。僕は思い切りリーディングするタイプでした。ですが、それだと考える力が養われないという話を聞き、最近少しずつ「聴く」ことに注力しようとしています。（といってもまだ1週間ほどですが。。。） もうひとつきっかけがあって、川邊健太郎さんというLINE Yahoo社の会長が YouTube に出ていて、そこでも同じような話をしていたんですよね。特に面白かったのは Gyao! というサービスを黒字化せよというミッションをもらったときの話でした。 川邊さんは今までの率先垂範スタイルでは絶対に無理だと思ったそうです。そこで、今までのやり方を変えて、むしろ現場で耳を傾けるようにした結果、ただ聴くだけだったのに、現場でどうするべきかを考えるようになり、思った以上に大きな効果が生まれ、黒字化達成したという話を語られていました。 1on1 のやり方 ここで改めて語られているのはフレームワークやツールと言うよりもただ単に聴くという事だと思ってます。「ただ単に聴く」と言いましたが、何も言わずに聞いてるとか、適切なタイミングで相槌を返すとかそういう話じゃないんだろうなと思ってます。特に相手に対して好奇心を持って聴く、これが重要なんだろうなと思っています。

yosuke_furukawa:キャリアの最初のきっかけはバックエンドでパフォーマンスチューニングの仕事していたときが最初でしたね。DBのインデクスチューニングとか全文検索のチューニングとかそういうパフォーマンス計測やチューニングを仕事にしていました。 元々僕がやっていたアーキテクチャはフロントエンドにHTMLを構築するUI用のサーバがあり、バックエンドはロジックを担保するAPIサーバがあり、そのさらに裏にデータベースがある感じでした。今で言うBFFと似てるかもですね。 さて、自分はバックエンドを担当していたので、お客さんから検索が遅いとかAPIが遅いとか言われると自分の出番でした。インデクスをチューニングしたり、処理の非効率な部分を改善したりしてました。 しかし、フロントエンドでUIをアップデートした時のほうが喜ばれていたのをすごく覚えてます。お客さんはその方が早く感じられたんでしょうね。極めつけはGoogle Chromeに対応したときで、その時、目に見えてUIが速くなり、その上でお客さんから握手を求められんばかりに喜ばれていたのをよく覚えてます。 僕がこのときに思ったのは性能を改善すると言ってもバックエンドだけ改善してたんじゃ駄目で、UIやUXといったトータルで改善しないと意味がないんだなと思ったのを強く覚えてます。 ここからフロントエンドを学びたいと思うようになり、JavaScriptを最初に学ぼうという気持ちになったのがきっかけでした。しかしながら自分は素直に JavaScript や CSS を学ぼうとはせず、何故かそのときに流行ってた Node.js に手を出し、そこから今に至ります。 その辺の話は僕の昔のスライドのこの辺で出てきますね。 https://speakerdeck.com/yosuke_furukawa/enzinianinarujue-wu?slide=55 参考までに。

yosuke_furukawa:コテンラジオをめっちゃよく聞きます。 https://coten.co.jp/services/cotenradio/ 次にゆる言語学ラジオを聞きますね。 https://yurugengo.com/ 上の2つは哲学や言語学と言った自分に馴染みがあまりない知識を話してくれるのですごく助かるんですよね。勉強になるなと思ってその後他の書籍に手を出したりしてます。特にコテンラジオだとオススメなのは三蔵法師の回ですかね。ゆる言語学ラジオの場合は男子校のノリで刃牙を話している回が好きでした。 あとまぁ、エンジニア的な嗜みとしては rebuild.fm と mozaic.fm と fukabori.fm ですかね。他にも misreading chat とかも聞いてます。rebuild.fm は N さんが話してる回が好きで、なんか聞いちゃうんですよね。あとmozaicは専門分野が被ってるんで、聞いてると話したくなるという副作用がありますね。「俺の意見も言わせてくれ」となる。 fukabori.fm はプロダクトの話、技術の話、組織の話の3種類がまんべんなくまぶされてるので、楽しいです。misreading chat は論文がテーマなので面白いんですが、高度過ぎて振り落とされてることもしばしばです。でも面白いです。

yosuke_furukawa:個人の楽しみ方はありますが、みんな楽しんでやってるんですかね。 日々の家事や洗濯だったり、仕事とか、プログラミングそのものを楽しいと思うかどうかみたいな哲学的な話になりますね。なんとなく質問者には「負債解消が楽しくない」というのが前提にある気がしているんですが、楽しくないのってなんでですかね。新しい機能や価値を生み出していないからですかね。それとも誰かが書いた昔のコードを直すのが気が進まないとかですかね。 負債解消はコストが下がるという意味で価値を生み出していると思います。価値というのは売上と利益という考え方で言えば、売上を上げるための価値を生み出しているわけではないと思いますが、コストが下がれば利益を生み出します。生産性が上がれば売上も上がります。なので、そういった最終的な状況を考えれば楽しい状況を生み出せるのではないかと思います。 誰かが書いた昔のコードを直すのが気が進まないという話で言うと、古文書みたいになっているコードを読むのが大変なのはわかりますが、小さくスコープを切って「とりあえずここだけ直そう」「次にここを直そう」ってやっていけば「チリも積もれば〜」で徐々に勧めていくことができるんじゃないですかね。 私も数多くの技術負債を生み出し、解消をしてきました。生み出しているときは負債になるとは思っておらず、後から誰かが直してくれてるんだろうなと思うと申し訳ない気持ちになりますが、自分も技術的負債を解消しているので、おそらくそうやって輪廻が回ってるんだろうなと思います。 ソフトウェアは長く開発されれば開発されるほど減価償却のようにスタックが目減りしていきます。最初は良いと思っていた技術も後から見ると負債になる。なんかそういう輪廻のようなものを見るのが最近の楽しみ方ですかね。あー昔は jQuery にこういう機能あったなーとか、こういうコード書いちゃうのってDOMの理解が薄かったからだよなーとか。昔を懐かしみながら解消する、シニアだからこそできる楽しみ方かもしれないですね。

yosuke_furukawa:> エンジニアを目指して、これからプログラミング言語の勉強を始めるのはどう思いますか？ エンジニアを目指すならどうあれ必要なので、必要な勉強を始めることに対しては特に何も思いません。やったほうがいいと思います。AIの進化があったとしても勉強することが必要なことには変わりありません。 むしろ勉強すればするほどAIを使って仕事するときも伸びる気がします。AIの進化とはいえ、まだまだ全てを自律してAIが制御する時代じゃなく、人が制御するのを補助する役割としてのAIの使われ方がこれからはとにかく増えると思います。そういう時に主体者としてのプログラマーが言語の使い方ができていないと困ることも多いと思います。 たまに余裕で嘘みたいなコードを書いてくることがあり、それは見抜けないといけないですし、7割くらいはあってるけど3割は自分で書かないといけないことも多いです。ただそれでも無いときよりCopilotなどの補助があるときのほうがかなり楽です。 また、市場の要求からサービスの要件に落とすことを要件定義、要件から実装する前にどうやって作るのかを決めることを設計と言います。AIがいくら発展したとしても現在のシステムのレベルに到達するのはまだ遠いのかなと思ってる分野の一つがこの要件定義と要件から実装に落とす直前の設計部分ですね。ここは実はプログラミングの能力がある程度必要だと思っています。できないことをいくら要求したとしてもできないですし、経験がないと要件定義も設計も困難です。 まとめて言うと、プログラミング言語の勉強はしたほうが良いです。AIの進化があろうと実装経験不足の状態では良いものを作ることができないように思えます。

yosuke_furukawa:プログラミングの適性があるかないかでいうと、コードを書きたいとか読んで面白いとか思えていない時点で適性はないのかもしれません。 でもだからといって、プログラマーになれないわけではありません。仕事として言われたことをやっているうちにプログラミングはできるようになることもあります。ただおそらく、プログラマーになりたいわけでもないんだろうなと想像しています。 個人的にはアイデアを持ってるのであればそれをエンジニアを雇って実装してもらう方でもいいんじゃないかと思います。プログラミングの適性に悩まれているのであれば、キャリアもそれだけじゃないので。 ただ適性はなくても技術としてのプログラミングがどういうものなのかは荒く知っててもいいんじゃないでしょうか。数ある起業家が元々プログラミングをやってる事も知られている通りですし、適性はなくてもビジネスとして成功することはできると思いますが、技術としての方法は学んでおいて損はないと思います。プログラミングの入門の本とかどうやって動いてるのかとかを学ぶことはサービスとして成長させるうえでも重要かなと思います。 プログラミングの入門書といってもたくさんあるんですが、昔大学生の頃読んだので覚えているのは、この本ですかね。 https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%81%AF%E3%81%AA%E3%81%9C%E5%8B%95%E3%81%8F%E3%81%AE%E3%81%8B-%E7%AC%AC%EF%BC%93%E7%89%88-%E7%9F%A5%E3%81%A3%E3%81%A6%E3%81%8A%E3%81%8D%E3%81%9F%E3%81%84%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%81%AE%E5%9F%BA%E7%A4%8E%E7%9F%A5%E8%AD%98-%E7%9F%A2%E6%B2%A2-%E4%B9%85%E9%9B%84-ebook/dp/B094J3CK1C/ ただC言語でコードが書かれてて、コードが出てくるとわかりにくいと思うので、そう言うんじゃないのが良ければ最近読んだのはこの本ですかね。 https://www.amazon.co.jp/%E4%B8%96%E7%95%8C%E4%B8%80%E6%B5%81%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E6%80%9D%E8%80%83%E6%B3%95-%E7%89%9B%E5%B0%BE-%E5%89%9B/dp/4163917683 現代的で読みやすかったなと思いました。参考までに。

yosuke_furukawa:メリットはCPUやメモリのようなローレベルなものを意識して開発する必要があり、それが基礎として考えた時にプログラミングがなんの礎のもとに成り立ってるのかを肌で実感できることじゃないですかね。PythonやJavaのようなもっと簡単な言語でやった場合それらは隠蔽されてることが多いので、そこを理解するのは難しいですよね。 その代わりコードで何かを実現することに頭を振り切れるからプログラミングを楽しく学ぶとかはできると思いますね。自分はC言語でC言語の小さなプログラミング言語を書かされましたが、それはそれで貴重な経験でしたね。配列やハッシュテーブルがどう実装されてるのかを知らないとできなかったからですね。 デメリットはその逆でしょうね。ローレベルを意識しないといけない、目的がアプリケーションを作ることだとするとその目的に対して考慮するべき事が多いとかじゃないでしょうか。 基礎と応用はどちらを先に教えるべきかとかそういう話は数多くされてるように思えます。僕の持論としては両方必要だと思ってます。どっちかだけで考えるものじゃなく、両方教えるのがいいんじゃないでしょうか。 僕が学生の時もCだけで授業する教授はいませんでした。どっちかというとJavaとかJavaScriptも教えてたように思えます。ただ、教授がそれに詳しい第一人者というわけではありませんでした。そこはもう少し産学連携というか、産業側でアプリケーションを作ってる人も一緒に交えて教えるとかやってもいいかもしれませんね。 余談ですが、自分の母校でNode.jsを教えてると聞いた時に、「いや、俺に声かけてくれよ」と思ったのを覚えてます。この記事を見かけた母校の方、ぜひ僕に一言お願いします。

yosuke_furukawa:コンマは行末に置くことが推奨されているというより、行間を区切る、スラッシュ（/）が変化したものだそうです。 https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%9E#:~:text=%E8%8B%B1%E8%AA%9E%3A%20comma%E3%80%81%E3%83%89%E3%82%A4%E3%83%84%E8%AA%9E%3A,%E5%A4%89%E5%BD%A2%E3%81%97%E3%81%9F%E3%82%82%E3%81%AE%E3%81%A7%E3%81%82%E3%82%8B%E3%80%82 この内容を読めば、行間を結ぶ演算子だという事がわかるかと思います。 ちなみに、質問者の方が言う、コンマなどの区切り記号は二項演算子であり演算子は手続きだとします。で、一般的な手続きは先頭に置くべきであるという話があるのですが、手続きにも色々あり、中置するものもあるので、コンマに関しては行を結ぶために行と行の間で置くのが一般的な使われ方なのではないでしょうか。 例を挙げると、２つの数を足し合わせるという手続きをsum(1, 1) のように手続きを先頭に置くこともあれば、 1 + 1 のように中置で置くこともあるので、手続きにも様々あるように思えます。 一般的なのが先頭に置くことであるということであれば、コンマで区切るよりも箇条書きで書き連ねるという方法もあり、そちらは割りと一般的になっているように思えます。ちょっとその質問文をコンマ（読点）を使うのをやめて箇条書きで書いてみましょう。 > コンマなど区切り記号は二項演算子なのであり、演算子は一つの手続きなのですから、一般的な習慣に従い行の先頭に置くべきだと思うのですが、一般的な文書はおろか、プログラミングにおいても行末に置くことが推奨されがちなのは何故でしょうか？ * コンマなど区切り記号は二項演算子であり * 演算子は一つの手続きなのですから * 一般的な習慣に従い行の先頭に置くべきだと思うのですが * 一般的な文章はおろか * プログラミングにおいても行末に置くことが推奨されがちなのはなぜでしょうか 変に読みにくい文章になりましたね。行間を読まないといけないのと、箇条書きには順序と関係が描かれないのと、「ですから」「ですが」や「おろか」のような言葉を入れにくいですよね。まぁなので、質問に答えられているのか不明ですが、まとめると * コンマは文の区切りで使う記号である * だから行末でつかうというか、行間で中置の演算子として使われている（という意見） * 一般的な手続きだからといって必ず先頭に置くことが推奨されてるわけではない * 1 + 1 のように中置で使うものもある * あと箇条書きという表現もあり、それは先頭で使っている * ただ適材適所である、無理やり使うと変な文書になる（読みにくい） という感じですかね。

yosuke_furukawa:本を読む、習慣的に本を読んでいて、技術書を惜しむことなくつぎ込んで買ってるのを見ますね。購入するくらいは自分もある程度真似してます。あと一応読んではいます。ここからは真似できていないけど、精読っていうか隅から隅まで読んだ上で、ちゃんと全部課題とかも解く人がいて、そういう人は憧れますね。何冊かそうやって本を読んだけど、説明できるようになるレベルで本を読むのって時間もかかるし大変なんですよね。 あとはマニュアルやREADMEやAPIドキュメントを読み込むっていうのをやってる人もいますね。このくらいなら僕も真似してます。ただここからは真似できていないけど、遡ってどういう背景があってなぜこの説明が追加されてるのかとかを読み解くレベルで入り込んで読んでる人がいますね。古文書を読み解くかのように歴史まで遡ってるのはすごいなと思います。あとは議論のレベルの状態でまだアウトプットになっていないものまで追ってるとか。僕も Node.js ならそういうレベルで追えますが、関わる一通りのものを全て追うのは無理で、人に聞いちゃうんですよね。 あと真似できてないんだけど、新しいものが出た時にそれに入り込んで何かしらのアウトプットを出すまでが速い人がいて、ホント憧れますね。すぐにデモできるレベルのものを作るんですよね。ハマりすぎずにさっとアンラーニングしてんのかな。しかもそれで何かしらサービスとして売上を出そうとかしてるわけじゃなくて、本当に自分の興味本位でやってるんですよね。それがすごいなーといつも思いますね。 まとめると * 本を読む * API/README/マニュアルを読み込む、なんなら追う * デモできるレベルのアプリケーションを作ってすぐに見せる このあたりですかね。真似できてないものも多いけど。

yosuke_furukawa:ちょっと混乱しているので、分解します。 > 実際のソフトウェア開発におけるチームワークとコミュニケーションの重要性 ソフトウェア開発においてチームワークとコミュニケーションが重要になっていると言いたいんですね。ここからして少し疑問です。というのもソフトウェア開発に限らないからです。「ソフトウェア開発におけるチームワークって他の仕事におけるチームワークとなにか変わるものがあるんだろうか」、ここから考え始めてしまい、露頭に迷っています。 個人的にはあまり普遍的で変わらないものな気がします。ホウレンソウをしっかりしようとか、相手の立場に立って考えようとか、見積もりをしっかり出そうとか。個々の個別なツールややり方が少し違うとかそういうのは社会人になってから学べばいいですし。 > 現代のコンピュータサイエンス教育にどのように組み込まれるべきだと思いますか？ ここはもっと疑問で、質問者の方は「コンピュータサイエンス教育にチームワークやコミュニケーションを入れていくべきだ」と思っている前提だったので、私と考えが違いました。個人的にはあまりそう思わなかったんですよね。 というのも最初に述べた通りチームワークやコミュニケーションの重要性は普遍的なものだからです。それこそ小中高と教育機関で口酸っぱくチームワークの大事さやコミュニケーションの大事さを学びますよね。そういう社会の中で相手との関係性を構築するやり方はすでに教育の中で行われていて、さらにコンピュータサイエンス教育に限って何かを追加する要素があるのか、ここが一番むずかしいと思ってしまいました。 本当に強いてあげるんだとするとSNSとかチャットで相手の顔が見えない状態でのコミュニケーションの取り方やチームワークの作り方みたいなIT文化内で社会関係を構築する際に気をつけることを触れてあげる感じでしょうかね。その辺りであればまぁ少し納得します。

yosuke_furukawa:大した話じゃないけど、過去にウェブのアプリでテストデータ作ってる時に一人のメンバーは好きなアイドルの写真をテスト素材として使ってて、エイプリルフールの時にその画像を全てCEOの写真に書き換えたら、それが上司にもバレて怒られそうになったっていうエピソードならありますね。 昔はそういうスレスレの遊びをしてたんですが、怒られそうになってからはやってないっす。 あとは、昔海外でLTしてた時に海外エンジニアからの質問で「hogeって何？」って聞かれた時に「あーhogeって世界共通じゃないんだー」となりましたね。 その時に「hoge is Japanese foo」 っていう謎の返しをして微妙な笑いをもらった記憶があります。え、じゃあ「barは？」って聞かれて、「bar is fuga」って返したんですが、「bar is Izakaya」って返せばよかったなーと今でも後悔して思ってます。 どうでもいい話でしたね。メタ構文はたくさんあるんですけど、どれも面白いなーと思ってます。 https://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%BF%E6%A7%8B%E6%96%87%E5%A4%89%E6%95%B0 他の人も回答してますが、 hoge の歴史が面白かったです。 https://kmaebashi.com/programmer/hoge.html ちなみに僕は cat とか test とかの片手で打てるやつが好きです。

yosuke_furukawa:クライアントとサーバでの処理は毎回行ったり来たりを繰り返してて、PWAとかService Workerとかでクライアント全盛の状態からサーバでも色んなことができるようにして、少しずつサーバに回帰をしている状態ですね。その後どうなるかでいうと、今は Edge とかも相まってサーバの特にCDN周りで最適化できる機能が増えていき、それを組み込んだ戦略が増えていくんじゃないですかね。 今はクライアントとサーバのそれぞれで最適化すると言ってもプラクティスを貯めている状態で、一定のプラクティスが貯まればまた別なブレイクスルーが起きるんじゃないかなと思ってます。特にスタックが積まれすぎるとバベルの塔みたいに崩れて最小限セットの何かが出てくるので、そうなった時にどういう表現になるかは面白そうだなと思ってます。 ちなみに、 > モバイル端末でも、ネイティブアプリではなく、ブラウザアプリが主流になったりするでしょうか ここは難しいでしょうね。ネイティブ技術でネイティブアプリを作るときの利点をウェブ技術でネイティブアプリを作るときの利点が上回る気がしないなというのがここ数年見ていての率直な感想です。 僕はwebはweb、ネイティブアプリはネイティブアプリで別な作り方で作ったほうが良いと思ってるタイプの人です。もちろん組織内に開発者が少ないからと言う理由でブラウザアプリをネイティブアプリのように表現してそれをメインで使うというアプリが合ってもいいとは思いますが、それぞれ違う世界観だなと思ってます。 最適化手段が増えることとアプリケーションにとって最適な開発手法になるかどうかは全く違う話ですね。もちろんウェブアプリがネイティブアプリに近づけられるように表現が増えることは良いことだと思ってますし、ネイティブアプリと全く同じUXが提供できるなら検討の価値はあると思います。 もしかしたらそういう手段が増えると webview でとりあえず作っておいて後でネイティブにしていくみたいな戦略が取られるかもしれないですが、一時的な戦略はともかくメインストリームにはならないんじゃないでしょうか。

yosuke_furukawa:何はともあれ、継続できる人ですかね。OSSって一回入ってくるだけ入ってきて、その後すぐ抜けちゃう人が多いんですよね。 やり続けるのってオーナーシップが必要な気がしており、一回「興味あるかもー」程度で入ってきては抜けていく人を見ていると、結局オーナーシップを持たせるのが難しいっていう話になるんですよね。オーナーシップもずっとは維持できないですし。 言い換えると、 1. 興味あるかもーの人を沢山確保する 2. それらの人にオーナーシップを持たせる 3. オーナーシップを維持する この3点がOSSのコミュニティで必要になるポイントです。 まず、1についてはNode.jsだと good first issue みたいなカテゴリで最初のコントリビューションしやすいものをカテゴライズして表示しています。 https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 次に 2 についてはいくつかコントリビュートを続けていると Collaborator という役割が与えられ、オーナーシップを持たせる工夫をしています。 最後に3についてはワーキンググループがあり、その中で興味のあるものに関しては継続的にコアコミッターたちと議論できるようになってます。 ただやっぱり維持は難しいんですよねー。深夜にミーティングしたりとかが続いたり、言語の壁もあったりでずっとはできないなーってなる。このあたりがNodeの課題かもしれないですが。

yosuke_furukawa:統合って何を指してますかね。フロントエンド技術であるところの React / Vue.js を利用する際に Node.js は切っても切れない状態だと思うので、統合のパターンがいくつかある中で一番筆者がおすすめだと思う事を聞いてると思って話しますね。あと実際に遭遇した具体的な課題と解決策についてはサラッと書きます。 ちなみにマジでケースバイケースだと思ってます。 基本はこの２つですよね。 1. ツールとしてだけ使うよパターン これは Node.js をフロントエンドのツールを実行するためだけに使うパターンですね。TypeScript, webpack, vite などのツールを動かしてReactの成果物をJSとして生成して置くっていう。これはこれでパターンの一つだと思います。 2. サーバとしても使うよパターン Node.jsでSSRとかしながらBFFだったりでサーバとして使うパターンですね。 よくある Next.js とかはこういう完全にインテグレートされたものとして動いています。これはこれでパターンですね。 で、2の中にグラデーションで、SSRする・しないだったり、GraphQLなどのAPIの取りまとめを受け付ける口がある・ないだったりがあると思っています。 1. か 2. かはこの時点でアーキテクチャが違うのと、求められる要件によって選択が変わると思ってます。SSRが求められるなら 2 ですし、可用性を上げるために Node.js を置かずに Backend API と static file server だけで成立させたいというなら 1 になるのかなと思っています。 具体的には初期表示を早めてレイテンシーを上げて、Core Web Vitals の向上に寄与し、SEOを改善したいという課題があり、その場合は 2 を採用しました。他にはサーバの運用コストと異常停止の発生確率を少しでも下げたいという課題があり、その場合は1を採用しました。 さらに開発する人の習熟度とか採用がどうとか、将来の対応がどうとか色々考えることはあるので、ケースバイケースになっちゃいます。 何も考えたくない、とりあえず一番オススメは何だ、というのであれば、現時点では僕は Next.js を採用します。1でも2でもいける。レンダリングの手段が豊富、開発できる人も多い、大手の採用も多いのと、実績が多いので。 ただし、Next.jsも最近ちょっとずつ悩んでます。OSSとしての安定性という風に見るとバージョンアップのタイミングで毎回何かしらの問題が起きており、また issue / PR のトリアージも滞っているのを見かけます。流行しているが故に自重で身動きが取りにくくなっているのを感じてます。まぁそれでも現時点で Next.js ほど実績のあるものはないんですけどね。安定版みたいな考え方が出てくれるともっといいんだけどなーとは思ってます。

yosuke_furukawa:コンピュータサイエンスの教育内容が実際のソフトウェア開発の現場で使われることが少ないという話ですかね。 アカデミックな技術や研究と言った内容が使われないと言うよりもそれを使ってるけど認識しなくても良いようになってることが多いなと思います。例えばデータベースとかは集合理論の基礎学問から並行並列処理をどう実現するか、検索をどうやって効率的に実施ているか、という内容がありますが、それを利用してはいるものの、細かいアルゴリズムまで認識することは少ないです。 じゃあそれらの基礎知識（大学で学ぶ知識）は意味がないのかと言うとそうではないと思います。それらがそもそも全くないという状態よりは理解した上で使えたほうが強いです。なので、学ぶ内容にも意味はあります。 また実際のソフトウェアの開発では純粋な技術だけを使うというよりは総合的な能力が必要です。誰かと一緒に開発するのにコミュニケーションは必須ですし、大学で学ぶ利点としてはこういう周囲の人たちとコミュニケーションしたり、協調したりしながら課題を進めていくところにあるんじゃないかと思っています。

yosuke_furukawa:英語とかもそうだと思うんですが、ボトムアップに基礎や文法や単語とかから積み上げていくアプローチと、一気にトップダウンに英会話したり、字幕なしで映画見たりしながら細かいところを詰めていくみたいなアプローチがあると思っており、もしも前者のやり方で合わないということであれば、後者のトップダウンなアプローチが良いのかもしれませんね。 この場合 IT エンジニアになるのであれば、いきなりアプリケーションから作ってしまい、細かいところを後から理解するというアプローチになります。本当は両面からボトムアップとトップダウンで勉強をやるのが一番良いと思っていますが、ボトムアップなアプローチは重要なものの、基礎的すぎて何に活かせるのか不明という事も多いと思います。トップダウンにまずは動くものを作ってしまうのがおすすめです。 で、そうなると何を作るかで最初困ると思うんですが、生活してて困るものを少しだけ改善するツールを作るとモチベーションも上がるんじゃないかなと思います。 例えば料理何を作るかで困ってるとします。その場合、ChatGPTのAPIとかを叩いて、料理名を入れたらレシピを教えてくれるアプリとか料理の献立を自動で考えてくれるアプリとかを開発するのも面白いんじゃないかなと思っています。 もしくは朝を早起きしたいけど、起きれないというので困ってるとします。その場合、勝手にカーテンを開けてコーヒーを淹れてくれて、スケジュールから勝手にアラームをセットしてくれるものを作るのも良いと思います。（今だと SwitchBot とかあればカーテンの自動開閉はある程度できるはずで、起きたかどうかはfitbitで見れそうなので、連携すればできるのかな。） このように自分が困ってることを解消するためのアプリケーションづくりをしてみるのはどうでしょうか、という提案です。

yosuke_furukawa:どうでしょうね。「満足できる」っていうのは個人が満足するかどうかであって、全員が満足できるものは作れないですよね。 僕は自分のカンファレンスである JSConf.jp は満足しているけど、万人に受けるのかは微妙に思ってます。技術よりすぎてコミュニケーションが少なかったり、初学者向けじゃなかったり、国際色が強すぎて英語の発表が多かったりするので。 僕が満足する技術カンファレンスは以下のようなものですね。 * プレゼンが面白い * 技術だけではなく、ドラマを語っている（Howではなく、Why） * 新しい技術でこれまでとこれからが語られてる（Past, Present, Future） * 基礎的な話だけど大事なことが語られてる（ブラウザの中身とか） * 自分になかった新しい視点がある（技術だけではなく、ビジネスや社会学的な部分がある） * ワイワイガヤガヤと話せる場所がある * 交流ができるスペースが有る * 交流の時間が確保されている(JSConfでは反省点です) * 懇親会のご飯が美味しい まぁこんな感じですかねぇ。逆にビジネス色が強すぎるのは少し苦手です。もちろん重要なのは理解しています。

yosuke_furukawa:上記でおっしゃられてるような状況であれば、ほとんどのケースで1が推奨されると思います。 というのも多くの人に使ってもらいたいという場合、まずリリースしてそのニーズを確認する必要があるからです。ほとんどのサービスはリリースしたけど思ったよりも使われず、その生涯を閉じる事が多いです。 なので、作っては新しくトライしていくようになります。 この場合技術スタックは慣れてるものであればよいので、知っている技術で開発するほうがサービスリリースには役立ちます。 逆に知らない技術を使うことでキャッチアップをしたいということであれば、2が推奨されるように思えます。その場合はテストやインフラも凝ってみたりと、色々なポイントでキャッチアップすることが目的になると思います。 > 学習コストも少なくないので一旦はこのままLaravelで実装し、どこかしらのタイミングでそういったSPAだったりユーザー体験なところも修正していけたらと考えております。 その考えで良いと思います。 何かしらのサービスを作ってリリースすることは非常に勉強になるので、おすすめです。一方で、初学者がリリースすると完璧ではないので、色々な批判をされることもあります。僕は最初に作ったサービスはXSSを埋め込み、 alert 文言だらけになりました。こういうのも勉強ですし、建設的な批判を聞きながらも建設的ではない批判は無視してモチベーションを保つのも良いと思います。 何かを作ってる人のが批判だけしている人より圧倒的にすごいとおもっていますので、モチベーションを消さずに頑張ってみてください。

yosuke_furukawa:いくつかのステップに分かれると思うので、ステップを分けるところから理解を深めるといいんじゃないかなと思います。 * 参照先を見つける エントリーとなる最初のファイル（おそらく、bundlerのオプションで指定しているはず）から見ていき、参照先のファイルを見つけていきます。参照元から参照先のファイルを見つけて何が何に依存しているのか、というファイル間の結びつきを見つけます。木構造のようなグラフを作るようなイメージですね。 * 参照先を解決し、ファイルをまとめる 一個のファイルにするだけであれば、全ての参照先のファイルがわかっていれば、結合するファイルの全体が分かっているので、それをまとめるだけでいいです。まとめ方はものに寄りますが、webpackの場合は resolver と呼ばれる機能があり、それを介して参照先のオブジェクトを見つけて解決できるようにしています。 https://github.com/webpack/enhanced-resolve * ローダー/プラグインの仕組み ただし、これはあくまでJSのファイルを一つにまとめる場合の方法です。webpackにせよviteにせよ CSS や画像などのJSではないファイルをロードする仕組みがあります。それを loader と呼んだり plugin と呼んだりします。ひとつ上で書いた参照解決する際に JS じゃないファイルは「こういう拡張子だったらこのloader/pluginを呼んでね」みたいに定義することができます。これを使って CSS のファイルであっても中で参照解決したりします。このあたりの仕組みはややこしいです。プラグインそれぞれの中身を見たほうが早いと思います。 * 最適化する 「一個のファイルにするだけであれば〜」と書きましたが、一個のファイルにしてしまうとファイルサイズが大きくなりすぎます。JSのファイルが大きくなると全体のロード時間に影響してしまうので小さくするほうが望まれており、それを最適化する仕組みがまた別なプラグインやデフォルトの機能として提供されています。 これを Code Splittingと呼びます。 https://web.dev/articles/reduce-javascript-payloads-with-code-splitting この他にもキャッシュして読み込みスピード上げてたり、色んな施策をbundlerは行っています。オプションを眺めてると色々あるので見てみると良いと思います。

yosuke_furukawa:見方によってだいぶ変わりますね。 例えばネットワークIOはアプリケーションサーバでみると自分の経験上、大きく影響を与えてると思います。なぜならデータベースサーバの接続から値が返ってくるのを待ってる時間が長いからです。じゃあそのネットワークアクセス先にあるサーバは何でリソースを消費しているかと言うとDBを使ってる時のストレージIOで消費してたりします。 この辺りのボトルネックを潰していくと徐々にボトルネックが移っていき、CPU時間になったりメモリのIO待ちになったりしますが、経験上で言うとネットワークIO > ストレージIO > メモリ > CPU の順番でパフォーマンスに影響があるなと思っています。 ネットワークIOが問題になったときは大体が接続先のサーバが遅いからなので、その間に別なことをやらせるというのが一つの手段ですかね。Node.jsならそこは非同期処理になるので勝手に別なことをやってくれてます。もちろんそもそもIOの時間を減らして速度を上げるというのも手です。上の例で言えばDBのSQLが遅いのであれば、その遅いSQLを見直す、インデックスを貼る、データのキャッシュが使えないか検討するなどの手段を考えます。 メモリが問題になるときはなんかデータを持ちすぎてるケースが多く、この状態だとメモリIOよりもGCが頻発するほうが問題だったりします。経験上メモリリークみたいなのが起きてる時が多いかもしれないです。ヒープの内容を見てなんとかするかもですね。 CPUが問題になるときは非効率な処理が多い時ですね。無駄にループ回してるとかアルゴリズムがおかしいとかそういうときですが、あと実案件で経験上多いのはHTMLのレンダリングとかでSSRしてるとかそういうのですかねぇ。HTMLキャッシュできるならそうするんですけど、まぁできないことも多いので難しいですね。

yosuke_furukawa:トップがリードして全部指示を出すというので回るのはある一定の規模までで、大規模になると全ての意思決定を一人の人ができるわけじゃないので、階層が生まれ、合議制になり、スピードは落ちていくのかなと思います。 思うにそれをなんとかするには階層を減らすか、合議の時間を減らすかの工夫があるように思えます。権限を移譲して、なるべく意思決定に関わる階層を減らすようにしている所も多いです。他には組織の中の哲学やカルチャーやvisionのようなものを徹底して共有することで議論の方向性がブレないようにしている所も多いです。 本やどこかで読んだインタビューでの情報ですが、いくつか例を挙げます（URLは忘れました、すいません、正確な情報ではない可能性があります）。 Apple はプロジェクトを並列に増やさず、選択と集中をすることでリソースを集中させるとともに、徹底したシンプルさやユーザー中心の設計とリーダーのセンスを大事にしており、トップダウンに引っ張っていく哲学を浸透させていると過去にスティーブ・ジョブズのインタビュー記事で記載されていました。 階層を減らしつつ、合議の時間が減っているように思えます。 Google は意思決定そのものは合議的ですが、合議の際に意見よりもデータを重んじ、試しながらデータを取って先に進めようとする姿勢が見えます。これにより合議の時間を効率的に使っているのでしょう。 Netflixはプロジェクトリーダーが強い責任と権限を持っており、人事採用の権利すらもリーダーに移譲して実践していくと記述されていました。こちらも階層を減らしているように見えます。 こんな感じでしょうか。

yosuke_furukawa:質問ありがとうございます。僕の最近考えてることがあるので回答させていただきます。 まず、 SPACE という開発生産性のメトリクスを図る考え方があります。これは * Satisfaction * Performance * Activity * Communication * Efficiency の頭文字になっています。詳しくは論文を読んでもらうとして、今のご質問にある。 `サービスのためになる`は Performance で、顧客満足度や売上、自分の書いたコードが価値を発揮しているかを表現するための指標です。 `エンジニアのモチベーションが上がる`は Satisfactionで、開発満足度ですね。チームのNPS評価や自分たちの開発がイケてるかを元に測るイメージです。 この他に Activity はアウトプットの量での評価です。PRの数やコードライン数とかタスクのユーザーポイント数とかで評価します。 Communication はチーム内でオンボーディングにかかる時間が少ないとか、レビューの時間や質が良いとかで評価します。 Efficiency は効率性ですね。変更にかかる時間とかで評価します。 さて、例えば Satisfaction を上げるために新しい概念や新しいライブラリ、ツールを導入したとします。この場合、他の指標はどうなるかと言うと「影響がない、もしくは一時的に下がる」可能性があります。わかりやすく言うと Activity の量は習熟度に影響するので、新しいツールや概念を導入した時にその方法に慣れるまで Activity は下がります。 Performance は、というと開発のライブラリが変わったからと言って影響がない事が多いです。 （Nuxt.js を Next.js に変えたとしてもお客さんに与えるインパクトはないですよね。） このようにどれかを上げようとするとどれかが相対的に影響を受けてしまうような関係にあります。これが SPACE の面白いところで、そうすることで開発生産性のメトリクスをハックしにくくするという作用をもたらしています。 また、組織の規模や成熟度に応じて自分たちでメトリクスをカスタマイズしていくことが可能です。これにより、例えば Performance を満たしたから、次は Satisfaction の優先順位を上げて対応しようといったような事が可能になりますし、 Performance を最初顧客満足度にしていたけど、これからは売上にしようとかそういうメトリクス決定が柔軟にできます。 ご質問に戻りますが、 技術選定において「サービスのためになる」「エンジニアのモチベーションが上がる」の両面を満たすべきと考えているのですが、いつも悩んでしまいます。 これに関してはPerformance と Satisfaction を一度に両立できる技術選定があると本当は一番良いのですが、一度に両立しようとしてもそれぞれのメトリクスは無関係になっています。両立しないものを一度にやろうとしていることが問題なので、一度どちらを優先させるべきなのかを鑑みた上で、順序立てて両方達成するようにしていくことが良いのではないかと思っています。 スタートアップであれば、一旦開発者満足度の高い状態を作り、開発者採用のフックになるような技術選定を先に行い、後から Performance を狙うのも良いと思います。もしくは売上工場を狙いたい場合、一旦安定して機能追加を行い、堅調成長させる方向に技術選定を行い、後に開発者満足度を高くしようとするというのも有りだと思います。