宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
JavaScript界隈はソフトウェアのトレンドの移り変わり・流行り廃りが激しい、とはよく聞く。 「だから辛い」とはどういうことなのか、について考えたことのあれこれをXに垂れ流したのを、再編集してまとめた。
きっとすでに誰か偉い人も言ってそうだけど、今のWeb技術、特にJavaScriptのつらみは、「プロダクトやサービスの寿命」より「フレームワークやツールチェインの寿命」の方が短くなりがちにも関わらず、その事がプロダクト開発時の前提になってない、ということから来てるんじゃないか?と思ってる。
神社には一定期間ごとに建物を作り直す「式年遷宮」というイベントがあるけど、あれは「神社」が部材や作り手の人の寿命より長い期間存在する事が明白だから行われてると思ってて(宮大工の技術継承のために必要だとはよく言われる)。
言い換えると、フレームワークやツールチェインの寿命よりプロダクトの寿命が長いことが前提にあるからそういうやり方を選べてるんだろう、というのが僕の解釈で。
翻ってWeb開発の世界を見たとき、「今のフレームワークやツールチェインが寿命を迎えても別の物に載せ替えられるように、今のフレームワークやツールチェインの思想に密結合にならないよう注意しながらソフトウェアを設計する」なんてことを、できてる人がどれだけいるんだろう?
フレームワークやツールチェインは「そこで規定されてるやり方のとおりにやれば天国、外れれば地獄」という性質が強く、自由度が低い分迷うことが減って開発効率が良くなる物だから、プロダクトの設計がフレームワークやツールチェインの思想と密結合になってしまうのは必然と言える。
そこを疎結合に作るのってものすごく大変、というかもしかしたら原理上不可能で、無理にやれば「既存フレームワークの上に独自フレームワークを築き上げる」ような本末転倒なことにすらなりかねない。
予算や期間もそもそも潤沢でないから、結局、特定フレームワークやツールチェインと一蓮托生になるしかなくて、フレームワークやツールチェインの方が先にEOLを迎えてしまって、システム全体を塩漬けにせざるを得なくなりがちなのではないか。
そうこうするうちに人も入れ替わりにっちもさっちもいかなくなってからやっと、「コードを掘り返し、考古学的調査で仕様を解析して、新しいフレームワークに載せ替える」ということになり……みたいなことが度々起こっている印象を、自分の狭い観測範囲からは受けている。
そこに絡む「新しい何かを作る」のとは違う後ろ向きさを嫌がる人が少なくない、ように見受けられる。
実際には、前述のようなことになるのはレアケースなのかもしれない。
多くのサービスが生まれた端から消えていく状況では、「フレームワークやツールチェインの寿命」より「プロダクトやサービスの寿命」の方が短くて、結果的に問題にならないことが多いのかもしれない。
あるいは、継続するサービスであっても、流行りのフレームワークが短命を前提としている(作り捨てる物以外に使うのに適していない)のなら、短いスパンでスクラップ&ビルドするのが「フレームワークの正しい使い方・フレームワークとの正しい付き合い方」なのかもしれない。
「フロントは捨てる前提の物なので、塩漬けが視野に入るのが間違っている」とか、もっと身も蓋もない言い方では「適切な(=短い)サイクルで作り直す金をケチってるだけだ」という指摘もあった。
ということは、「流行りのJSフレームワークは貧乏人が使うものではない」が真理なのだろうか?
フレームワークの寿命に負けないペースでスクラップ&ビルドする費用をまかなえるだけの収益が無いならフレームワークを使う資格は無い、というのは、傷みやすくて洗濯もろくにできない高級ブランド服を(あれは金持ちが使い捨てる前提の物だから)貧乏人が大事に着るもんじゃない、という話と類似しているようにも感じる。
「ケチってる」という指摘をくれた方は同時に、「フレームワークの寿命が明記されてないのも問題だ」というようなことを書かれていた。
そうなんすよね。仮に「このフレームワークは2025年に開発放棄します」と最初から明記されてれば、2023年から開発を始めて10年もたせる前提のシステムでは使わないでおこうって判断できる。
でも、「このLTSのバージョンのサポート期限はいつまでです」と明記されてるパターンは見かけるけど、プロジェクト自体の寿命まで明記されてるパターンは、自分は見たことがない。だから「そのフレームワークの寿命より長く使われる事が明らかなプロダクトで、短命なフレームワークを採用してしまう」という悲劇が起こる。
開発コミュニティの最前線でやり取りしてればなんとなく寿命を嗅ぎ分けれるものなのかもしれないけど、「フレームワークというプロダクトの、消費者に過ぎない立場の開発者」達にまでそれを求めるのは酷だと僕は感じる。
ということを、「セキュリティアップデートの提供は来年の何月に終わる」という事が明記されてるFirefox ESRを「1年後にリプレースする前提で」導入するために多くの人が動くお手伝いをする、という企業案件を何件も手がけてきた僕は思ってしまう。
大企業の社内システムの類のように、短期間ではそう変わらない(変えられない)物との接続が強いプロダクトだと、外部要因によって「短期間では捨てられない」がしばしば発生する。それが問題を引き起こす原因なのだとしたら、お堅い・速度の遅いビジネスほどJSは相性が悪く、フレームワークを採用するのが間違い、ということになってしまうのだろうか?
しかし、そういうお堅い・遅いビジネスほど日本では金になる印象もある。
「新しい物を作り捨て、薄給」と「レガシーを長くメンテし、安定収入」が現実なのだとしたら、夢が無いにも程がある……
「その会社独自のフレームワーク」は「ダメ現場あるある」として揶揄されがちだけど、会社のプロダクトの寿命が流行りのフレームワークの寿命より長くなる想定のもとでは、必ずしも駄目な選択とは言えない気もしてくる。
独自フレームワークは「学んでも潰しがきかない」ということで忌避されがちだだけど、2~3年単位での流行フレームワークの学び直しも、それはそれで辛いように僕は思う。
あるいは、もし「(短命な物を)作って捨てて(それが寿命を迎える前に)転職して」が前提だから問題にならない、ということなんだったら、個人としてはそれでいいけれど、残された開発者・運用者やユーザーは梯子を外された形になってしまうわけで、これも別の意味で辛い。
現代のソフトウェア・サービス開発では「先を見据えた抽象化等にコストをかける」よりも「成長スピードを優先する」判断が行われる結果としてこうなっている、という感じの指摘もあった。
「成長」というフレーズからは、僕は「ビジネス規模の拡大・増収増益」のことを指している印象を受けるのだけど、ソフトウェアやサービスの存在意義って「金を稼ぐための物」だけではないんじゃないのか、というか、それよりも「社会に存在している問題を解決する物」の方が本質的な存在意義なんじゃないのか、という思いが僕にはある。
「お金を稼ぐこと」と「社会の問題を解決すること」のどちらに重きをおくかで、考えが変わるものなのかもしれない。
自分は後者の方への関心が強いからか、ユーザー数の増加や社会状況・問題そのものの変化に追従するために発生する作り直しは「仕方ない」と感じて納得しやすい。
その一方で、フレームワークやツールチェインの寿命が先に訪れるために作り直しが何度も起こるのは、「なんか不毛だ」と感じて納得し辛い。
ビジネス優先のために短命であることが宿命付けられた物を使う上では、短いサイクルでの作り直しが避けられないという、ビジネス都合に一方的に振り回されるのがイヤなのかもしれない。
そう感じること自体が、自分がビジネス下手であること、致命的にビジネスセンスに欠けていることの証左なのかもしれない。
資本主義社会の中での持続可能性のためには、お金稼ぎと問題解決は不可分の両輪だとは思ってるんだけど、問題解決の側面の方に皺寄せが行きすぎてるように僕には感じられて、歯がゆさを感じてる。
自分のステータスを明らかにすると、
という、JavaScript界隈では明らかな外れ値なので、ここに書いた諸々の事は、前提の事実認識に相当な偏りがある自覚がある。
特に、現状の認識については、「ツールチェインに振り回される状況は変わってきている」 という趣旨らしい発表が行われていたJSConf JPという技術イベントに参加していないどころか開催を後から知ったほどの浮世離れっぷりで。
にもかかわらず自分の狭い観測範囲のことだけでこうしてテキトーにクダ巻いてる、という状況であるからして、ここに書かれている内容は相当に割り引いて読んだ方が宜しかろうと思われます。
の末尾に2020年11月30日時点の日本の首相のファミリーネーム(ローマ字で回答)を繋げて下さい。例えば「noda」なら、「2023-11-20_javascript-framework-lifetime.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。
writeback message: Ready to post a comment.