🔥

フロント開発を炎上させてしまった話

9 min read 12

はじめに

お久しぶりです、皆様のサンドバックが帰ってまいりました。
投稿ができていない期間、Nuxtにボコボコにされて裸足で逃げ出し、逃げた先のReactにも強烈な左カウンターをお見舞いされました。

本来であれば、このような場所に投稿することすらはばかられる内容ですが、敢えて書きましょう。
私はフロント開発を炎上させた愚か者です。

なぜ今懺悔するのか

Twitterでこんな投稿を見ました。

https://twitter.com/mittani_s/status/1459513414712127488?s=20
確かに、実務で得られる経験は、とても大きく得難いものです。
当然、ご迷惑をおかけしてしまうことは、だれであろうとあるでしょう。
ただし、その「ご迷惑」の大きさについて、我々は知っておかなくてはなりません。

見えている地雷を踏んでしまうようなモノ好きもいないでしょう。
特に、この手の地雷は強力ですからね。
塵となって吹き飛んだ私の命が、新たな浅瀬の民の糧となることを祈っています。

具体的に何が起こったのか

結論から申し上げますと、大幅な納期遅延を発生させてしまいました。その期間、2ヵ月。

ほんと、何やってんだって話ですよ。
あほか、と。

大変ありがたいことに、何とか開発をひと段落させることができ、賠償問題等にも発展することはありませんでした。
それどころか、開発の伴走をしてくださった上、報酬についてもいただくことができました。
お世話になっている企業の皆様、特に今回PMを担当してくださったKさんと、サーバー部分を担当してくださったUさんには、本当に頭があがりません。

ろくな技術も持たない状況で-あまつさえできると思い込んで-開発にあたることが、いかに愚かで、恥知らずか。
身をもって、体験することになりました。

ここからは、現場で起こったお話について、浅瀬の民なりのてきと~な感じで、ゆったりかいていきます。
まぁ、出来の悪いライトノベルを読むような感覚で楽しんでいただければ幸いです。
ちなみに、あれってフィクションだから楽しめると思うんですが、どうでしょうか。

本編

ことの発端

以前お世話になった方が、
「HPの制作とかできる人いませんか?いたら相談に乗ってほしい!」
という主旨のお話をされておりました。
一応、WordPressでのブログ構築(大嘘)やGatsby js でのブログ構築(完全に理解した)、Railsでのプロダクト開発(ちゃぷちゃぷ)などをぺたぺたとやっていた私は、
「一応技術としては持っているので、お話聞きますよ」
と、反応させていただいたんですね。

して、お話を聞いてみると、なんと新規Webシステムの開発のお話ではありませんか。
サーバーサイドの開発担当者は決まっているものの、プロント開発要員がいなかったそう。
「いや、まぁ、一応ReactとかRailsとかは触ってますが…。」
そんな話をしていると、あれよあれよと参画の方向へ。
今回PMを担当してくださったKさんは、私のリポジトリと作成したブログやサイトをご覧になると
「うん、これならいけると思います」
大変ありがたいご評価です。
これにて、フロント開発担当として参画が確定。
なんと技術選定からお任せいただけることになりました。
といっても、フロント担当は私一人。
他の方々との折り合いとかは、気にしないで大丈夫だそうです。

…すでになんだか焦げ臭いって?
焚火のにおいというのは、自分が焚火をしている時には気づかないものなんですね、これが。

初めての技術選定

今回の開発フレームワーク(?)の選択肢は以下の4つ。

  • React(素)
  • Vue(素)
  • Nuxt
  • Next

UさんやKさんは、軽いVueの利用経験がおありのご様子。
…筆者のReact利用経験よりも彼らの経験のほうが価値が高いのでは…?ボブは訝しんだ。
ま、まぁ一旦純粋な気持ちで選定しましょう。

まずはSSRとCSRのどちらを選択するかから考え始めました。

「は? ReactかVueかの選択の方が1000倍大事だろ!」
そう思われた良識人の皆様、私もそう思います
いやね、VueもReactも大した開発経験はありませんでしたし(今もないんですけど)、ちょっと触っていたReactに対してVueはEasyという意見が散見されていたので、あんま変わらんかなぁと。
当時の私はそう思っていた訳ですね。
まあこの認識が最大の誤算だったわけですが、一旦はいいや。

して、SSRかCSRか問題についてですが、水たまりよりも遥かに浅い筆者の下調べによると、どうやらCSRはSSRに比べてSEOで不利になる可能性が高いらしいとの情報が散見されました。
最近は以前ほどの差が出ることは減っているものの、流石に差がなくなるとまではいかないらしい。
ちょろちょろとGatsby.jsをつかていた私は、「ほ〜ん、そんならSSRで作ってみるか」などという軽い気持ちで、SSRを選択してしまいました。
…ぶっちゃけた話、今回のケースでは、SSR選択が裏目に出るようなことはほとんどありませんでした。
それ以前の問題だったんで。

さて、SSRとなるとNextかNuxtになりますが、私はNuxtを選択しました、まずは
NextとNuxtで、用意されていた開発予定のシステムのモックアップを見た目だけ作ってみました。
で、やってみると、以下みたいなことを感じたんですよ。

  • NuxtはReactに比べて見た目の部分とかよしなにやってくれる部分が多そう。
  • Next Auth よりも Nuxt Auth のほうが今回の開発要件にあってそう。

Nuxtをはじめてビルドした時、Headerとかレイアウトとか一気に生成してくれたんですよ。
ビルドの時に、デザインパッケージとか、その他必要そうなブツをポチポチ選択すれば、設定なしで立ち上がってくれたんですね。
一方で、Nextの場合はほとんど最低限のみ。基本的にはReactをそのままゴリゴリ書いていく感じでしょうか。

「…なんだ…このフワフワした情報は…?」
抜き身をつきつけんとしている画面の前のあなた、殺意をぐっとこらえてください。
何分、相当前に感じた感想です。
皆様がダイビングや遠泳に励む中、一人砂山を作っている者の意見に期待してはいけない(戒め)

そして、今回の技術選定の決定打となったのが、コレ。

「もしかして『nuxt』」

Nextの情報を検索するたび、延々と検索の最上部に出てくるんですよね。
google先生も余計なお世話です…。


……
………やってやろうじゃねぇかよ!

ほら、あれあるじゃないですか。野球のあれ。
「左で打てや!」
確かに、左打席に立たないといけない気持ちに…。

冗談はさておき、確かに情報量はNuxtのほうがNextより多そうなんですよね。
日本では。
というよりも、正直Nextに関する情報が非常に少なかったです。
「Nextだと、何が問題が発生した時の対応が大変そうだなぁ」とぼんやり考えていた私は、Nuxtを選択しました。
ま、結局コレが凶悪な罠だったんですけどね。

もちろん(というべきかわかりませんが)、言語はTypeScript。
vuetifyとかvuexとか、もろもろ入れる感じで決まり!

こうして技術選定のお話も済ませ、いざ開発へ。
正味、ここまでもだいぶきつかったんですが、本当の地獄はここからでした。
あゝ、不穏。

人生最悪の開発

さて、今回選定したNuxt。はっきり言って開発体験が最悪でした
私が今までやってきた、数少ない開発の中でも群を抜いています。
誤解のないようにお断りしておきますが、本稿はNuxtを非難するものではありません。
私たち浅瀬の民は、プロの皆様が作ってくれたものを、ありがたく利用させていただく立場にいますからね。
ただ、浅瀬の民ならではのハマリポイントが、私を恐怖のズンドコへと叩き落したのです。

結局、煉獄の中心にあったのは、やはりエラーの解決でした。
エラーの内容自体はここでは詳しく触れませんが、「TypeError: ~」とか「~~ is not defined」とか、そんなところです。
これも機会があれば別途記事にしようかと。

ともかく、内容はいったんいいんです。
問題はこのエラーがどこで出るかという点にあります。
実は、書いている間は特にエラーを吐きません。
存在しない参照を呼び出していたり、型指定がずれていたとしても、です。
…マジかよ。
結局、VSCodeではエラーが出ていないのに、画面ではエラーが頻発。
それでいて、どこが問題のコードなのかがまるで分らない、という状態に延々と悩まされることになりました。

「Nuxtは情報多いんだろwさっさとググレカスw」
知っていて高みの見物を決め込む、画面の前のプロの皆様、ご想像の通りです。
ネットで集められるNuxtに関する情報はJavaScriptがメイン。
Typescriptの記事は少ない(もしくはアクセスが割と難しい)んですね。
Vue、vuexとTypeScriptの相性の悪さは当初から指摘されていましたが、私の想像は完全に凌駕されていました。
また、その情報も「こうすれば動くよ」という情報ばかり。
エラーの解決策は少ない―少なくとも私は、その手の情報にまともにアクセスできなかったんです。

当初は2ヵ月、だいぶ余裕を持った計画が組まれていました。
が、開発は徐々に遅れはじめ、朝から晩までnuxtと戦う生活に。
最終的には文字通り、夜中泣きながら開発をするレベルになってしまいました。
さらにそれでも終わらないんだから、本当に救いようがありません。

そして私は、さらに愚かしい選択をすることになります。

世界一愚かなリプレイス

納期からおよそ2週間前の開発会議。

--申し訳ございません。Reactで書きなおさせてください。--

当然、開発会議前に決めていたこと。私も覚悟はしていました。
いざ口にしてみると、とてつもない情けなさと無力感で、胸がいっぱいになるものです。
胸を埋め尽くしたそれは、実は液体なんですね、はじめて知りましたが。
そこからあふれた分は、目から頬を伝ってデスクへと流れ落ちていくんです。
私はただ、お気に入りのリアルフォースと大洗土産のガルパンのラバーマットが水没しないように、顔を背けることしかできませんでした。

開発が遅れていたことはKさんもUさんもご存じでした。
当初はお二人とも不可解に思われていたようですが、作り直しに同意してくださいました。
Kさんは、私のコードレビューや、質問に対するサポートをしてくださいました。
その時間を完全に無駄にしてしまったわけですから、申し訳ない気持ちでいっぱいです。
Uさんは、もうすでに大半の開発を終え、フロントとの調整を行うのみというところでした。
Uさんにしてみても、「この状況で逆戻りか…」と思われたことでしょう。

それでも、私には、それ以上Nuxtで書き続けるだけの実力も、気力も、残ってはいませんでした。
Reactは、個人開発での採用経験もり、ここからでもまだ、対応が可能だ。
そう考えたんです。
私のような菲才の身に、ここまでのお仕事をくださったばかりか、手厚いサポートまでしてくださる。
そんな素晴らしい方々の信頼を、これ以上裏切るわけにはいきません。
多少経験のあるReactで、何とか遅れを取り戻す必要がありました。

…なんか、だいぶ文面が重いな。
ま、とにかくReactへの切り替えは認められたんだ、これで勝ったろ。
…なんてことはないんです。
私の受難は、まだ続いていました。

五里霧中のスケジュール

Reactで書き換えてから、開発体験は相当向上しました。
おかしい箇所は、VSCodeが教えてくれる。
それでエラーがつぶしきれれば、コードはちゃんと動く。
意☆味☆不☆明のエラーに悩まされていた私は、ここで初めて「開発体験」の意味を知りました。

が、そのReactでの開発でも、見事にテンプルを強打されることに。
まずは、useStateの仕様に関する誤解。
これも詳しくは言及しませんが、フレームワークそのもののデータ更新のタイミングを誤解していたんです。
これが原因となり、サーバー側に送るデータが格納されていない、なんて事態に陥ったりしました。
また、formDataの受け渡しにも問題がありました。
formDataは基本的にstringになるので、考慮に入れておかないと型が合わなくなるんですね。
普通のデータならまだいいのですが、画像データになると話が変わります。
この辺りについてきちんと触ったことが無かった私は、結構な苦戦を強いられました。

思い返してみれば、難易度が高いと思われるものや機能は、実装を妥協したり、友人の天才エンジニアに任せたり。
要は、まじめに実装していなかったんですよね。
今回はすべてを自分で実装する必要がありましたから、悪いところが出てしまった、と。
こんなにも興奮しないポロリが、未だかつてあったでしょうか。

さて、このようにトラブルには見舞われていたのですが、エラーやらトラブルやらは当然のことですよね。
問題はそれを踏まえて、どうスケジュールを組むかという点。
ですが、NuxtでK.O.された直後に、(少しですが)利用経験があったReactもまともに動かないという状況。
私はいよいよ、自分のイメージしていたエラーの原因と対応方法、開発速度やスケジュールを、全く信頼できなくなりました。

とにかく時間を割いて、片っ端からネットの実装方法を試す日々。
コードの条件分岐の見直しとか、テストを書くとか、そんな高尚なことには思い至らず、時間と体力と精神だけが無為にすり減っていく。
「愛と勇気だけが友達」という表現は、あながち空想のものではないのかもしれません。

気が付けば、Reactで遅れを取り戻すと誓った日から一か月が経過しようとしていました。

トンネルを抜けると

結局のところ、Kさんがスケジュールの調整と定期的なミーティングの機会を提供して下さ居ました。
「この辺りの機能をこのぐらいまでに実装しておいてください」
Kさんの見立てはおおよそ正しく、タスクの細分化も的確でした。

ある程度この指示に従い、定期ミーティングで問題の個所を解決する。
この体制になってから、開発の状況は好転しました。
慣れの問題もあるでしょうが、ここまで進めて、ここは相談しようという姿勢を取れつつあったことが、大きな要因だと思います。
その後、仕様変更等が入ったりもしましたが、何とか開発はひと段落となりました。
2カ月遅れで

本来であれば、この手の管理は当たり前のことだったのでしょう。
現にKさんも淡々と予定を組んでくださいました。
私は今まで、個人開発や友人のできるエンジニアの補助的な役回りが多く、この手の管理能力が欠けていました。
豆腐なんかは型箱に押し込んで固めなくては、形を保てませんよね。
「とにかく、やる」という開発の愚かしさを知った、数ヶ月でした。

結論

いやぁ、重かったっすね。
本当はこんなこと書く気はなかった(というか、もうzennにも投稿なんかできんなぁとか思ってた)んですが、件の投稿をみて、「私と同じような地獄を見る可能性がある方がいらっしゃるのでは」と思ったんです。
私の場合、周囲の環境に関しては天国といってよいでしょう。
その点では本当に、運がよかったです。
では、本稿の教訓を一通り。

何がマズかったのか(技術編)

まずは細かいお話から。
今回は技術選定が地獄の始まりでした。
具体的には 「VueはEasy」「もしかして 『nuxt』」 に、完全に踊らされましたね。

確かに、Vueはいろいろとよしなにやってくれます。それは間違いない。
ただ、実はReactも相当よしなにやってくれてたんです
Vueが実装をしやすく、よしなにやってくれるのに対して、Reactは開発体験の向上について、よしなにやってくれるといったところでしょうか。
少なくとも、私にはNuxtの開発体験をイイ感じにすることはできませんでした。
一方で、Reactに関しては、TypeScriptで立ち上げれば、そのままいい感じの開発体験をさせてくれます。

情報の内容に関しても精査が必要でした。
ちょうどVue3への過渡期だったこともあり、記事の書き方もバラバラ。
少なくともTypeScriptでの実装情報に十分にアクセスできるか、その情報で実装できるかは考えるべきだったといえますね。

「ReactができればVueもできる」という甘い言葉に踊らされてはいけません。
私たち浅瀬の民は、もともと泳げないんですから。
せめて良質な浮き輪を探せるようにしましょう。

何がアカンかったのか(姿勢編)

さて、結論としては、本来これがすべてでしょう。
はっきり申し上げます。

単純な勉強不足です。

そもそも、Nuxtのエラー周りは、Nuxtにおけるページ読み込みやpropsの受け渡しの流れについて、チュートリアルや小規模な開発で確認しておくべきでした。
そうすれば、エラー沼の回避はできずとも、解決の速度を上げられましたよね。
さらに言えば、その開発の中身をみて不安があるなら、最初からReactを選択してもよかったんです。
今回はざっと見た目とログインぐらいを作っただけで、フレームワークそのものの学習を怠ってしまいました。
これを怠慢といわずして、なんというのでしょう。

React周りに関してもそうです。
個人が浅瀬でちゃぷちゃぷやっている分には、妥協も諦めもいいでしょう。
人生は妥協と諦めの産物なんですから、個人の趣味がそれに倣っても何らおかしくはありません(暴論)。
ただし、今回の場合は人が使うサービス。それも業務としてやるんです。
こうしてやる以上は、やはり半端な状態で行くのはよろしくないでしょう。
最低限の仕様やよくある機能の実装方法、データ通信の方法とデータの形式なんかは一通り抑えておく必要があると思います。

ただ正直に言ってしまうと、おおよそ今持っている技術+αで行けると思っちゃったんですよね。
最初に申し上げました、「あまつさえ、できると思い込んで」。
なんやかんや、やってみないとわからないものってのはそうです。
しかし、今思えば、あれやこれや、いろいろ出来ましたねってお話。

いやぁ、言葉にしてみると本当に単純。
まぁ、ちゃぷちゃぷでいいんですよ。
プロの皆様も、ライフジャケットを着る時間、浮き輪を膨らます時間ぐらいはくださるでしょう。
要はその辺ちゃんとしないで飛び込んで、それで溺れて助けてもらう、なんてことはやめようねって話ですわ(自戒)

エンジニアはツライよ

さて、最後になりました。
マジ、エンジニアってツライんですね。

なんというか、最近は「エンジニアになると副業収入がぁ~」とか「エンジニアは自由に働けてぇ~」とか、そんなお話をちらちら見かけますが、実際どうなんでしょう。
私の場合、自分が作りたいものをちょろちょろ作るために、プログラム書けるようにした感じなんですが、実際仕事としてやるとなった時のストレスは相当でした。
こんな恵まれた環境でこれなんです。
個人で案件をとって、それをキチンと納品してお金を…なんて正気を保てるんでしょうか。

おおよそ目的が「副業収入」や「自由な働き方」にあるなら、その手段は何もプログラミングに限らないはずです。
そして、手段が目的化したとき、おおよそ幸せな結果を生んだ例はないと思うんですが…。

行動することは素晴らしいことですし、私もそうしたいと考えています。
ですが、一度止まって、考え、チョットだけ覚悟を決めましょう。
動いた先で、こんな状況に陥った仲間もいるんです。
私よりも厳しい状況にいる方もいらっしゃるかもしれません。
もちろん、気に留める必要はありません。
ただ、頭の片隅にはいれといてもらえると、チョットうれしいです。

末筆ながら、重ねて申し上げます。
塵となって吹き飛んだ私の命が、新たな浅瀬の民の糧となることを祈っています。

Discussion

趣旨からすると、些細な部分であることを承知の上で指摘させてください🙇‍♂️

ただ、当時の私はコロナにでもかかっていたんでしょう。
嗅覚とかダメになってましたね。

嗅覚云々でコロナを出すのは、実際に後遺症に苦しんでいる人への配慮が欠けていると思います。
「すぐ病気になっちゃいます、エイズを発症していたのでしょう」「目が見えません、糖尿病になっていたのでしょう」と同じ類です。
まずさが伝わっていれば幸いです。

ご指摘いただき、ありがとうございます。
こちら、表現を修正させていただきました。

お疲れさまです。昔Nuxtで苦しんだ民なのでお伝えしたいのですが、Google検索時に"nuxt" "nuxtjs"とクォーテーションをいれたり、かつ状況によっては-nextのようにハイフンを単語とつなげると排除できます(nextだとxxxx@nextのようなライブラリも排除されてしまいますが...)。もしまたNuxtをさわる機会があれば、試してみてください!
もしすでに知っていればスルーしてください。

ありがとうございます。
正直なところ、nuxtはだいぶ敬遠してしまっていたのですが、「Reactしかできませんってのもなんだかなぁ」と思っていました。
せっかくですので、もう一度トライしてみます。

2ヶ月の遅延程度ならまだいいんじゃないですかね。今回の記事から読み取れる範囲でそれならまだマシな方ですし、相手にも大きく責任がある話です。それよりは色々な学びを得られたことを喜んでいいのではないかと思います。

お疲れ様でした。

ちなみにフリーランスや副業は腕力のあるゴリラか、転んでも只では起きない鋼のメンタルを持ってるゴリラに向いた生き方です。

コメントありがとうございます。
つらつらと書かせていただきましたが、なかなかできない経験であったのは確かです。
実際のところ、「炎上案件」というものがどういうものなのかわかっていない状態。
自分が当事者になるとは、思ってもみませんでした。

今回の一件は、炎上の中でもボヤ程度のものだったのかもしれません(それはそれで恐怖です)が、皆様の懸命な消火活動に救われました。
これを学びに変え、今後の活動につなげたいですね。

追記:
フリーランスの件、その通りですね。
特に今回の一件、私の細腕には荷が重かったようです。
少なくとも、最低限の腕力は身に付けねば。
…こんなにもフリーランスが推されているということは、世の中の多くはゴリラなんでしょうか。

やっぱり会社員はいろいろなプロテクションがあるので、会社員がオススメなのは間違いなくて、でも必ずしもそのルートにいけるとも限らないため、人によっては生き方の一つにフリーランスがあるということかなと思います。また会社員 -> フリーランス -> 会社員みたいな生き方もあります。「もしかして Nuxt」と同じでフリーランスが推されてるからと言ってオススメの生き方とは限らないのも技術選定と同じで、どの生き方にも pros/cons があって、その人に会ったやり方を都度選ぶしかないところです。

もちろんフリーランスのメリットはいろいろあるので、経験値を積めたというのは今後の武器になるのは間違いないです。

世の中の多くはゴリラなところはあると思っていて、技術的困難を粉砕する腕力を持つゴリラもいれば、苦難な満ちたジャングルで傷を負いながら経験値を積みまくる歴戦のゴリラもいます。壊れず生きてさえいればなんとでもなるというのも、エンジニアにはゴリラの素養が必要なところなのかもしれません。会社に餌を与えられてるゴリラたちもひとたび目覚めれば圧倒的な野生を取り戻すのかもしれません。

メンタルをヤってしまったり、健康を害したり、極度のトラブル(訴訟沙汰とか会社が潰れるとか、人間関係が険悪になる)とかさえなければ大体なんとかなりますし、あってもなんとかなります(たぶん)

やっぱり会社員はいろいろなプロテクションがある

やはりコレは間違いなさそうです。
実際のところ、「業務委託としてやらせてもらっているのに、こんな質問をしてもいいんだろうか…?」「これ、作れなかったらどうなるんだろう」みたいに考えたことが多々ありました。
会社員として開発にあたる場合、上記のような状況のときに社内の人に頼れる、というのは大きいですか。

とにかく、経験値を積みながら、壊れないように戦って行けるように努力するべきですね。
気がついたらこんな状況に…といった具合だったので、自分に合う戦い方について、もう一度考えてみます。

ご助言ありがとうございます。

お疲れ様でした。
苦しみながらも逃げず、投げ出さず、そして切られもせずに最後までやり遂げられたのは素晴らしいことですね。

ありがとうございます。

周囲の皆様のお支えがあったからこそ、この程度で済んだのだと思います。
ありがたい限りです。

炎上を何度も繰り返すようでは、ただの放火魔といえるでしょう。
そうならないように尽くしたいものです。

普通に読んでて楽しかったです。
自分も実務はしたことなくVue.js,TypeScriptのチャプチャプ勢(この言葉好き)です

ちょうどVue3への過渡期だったこともあり、記事の書き方もバラバラ。

Vue2とJavaScriptを使った半年くらい前に「完全に理解した」ってなったのを覚えています。
調子乗ったままVue&TypeScriptに手を出した瞬間に「Vue2ClassStyle」「Vue2ObjectStyle」「Vue3ClassStyle」「Vue3ObjectStyle」という風にめちゃくちゃ記事出てきたうえに公式ドキュメントでは「Composition API」とかいうよくわからないのを勧められて困っていたので、めっちゃ共感できます。

ありがとうございます。
「出来の悪いライトノベルを読むような感覚で楽しんでいただけ」たのであれば重畳です。
そして、同じチャプチャプ勢とめぐり会えたことを嬉しく思います。

Nuxtで書いていた時は「Composition API」を使ってみていたんですが、やはりjsxレベルの相性とまではいかないようです(それ以上に情報が無いという…)。
やはりVueはEasyと言うのはウソなのでは?と訝しまずにはいられない今日この頃。
Vue3で検索結果が塗り替えられること、そしてNuxt3の正式リリースを待つしかありませんか。

プロの皆さまの活躍と健闘に期待しましょう。

ログインするとコメントできます