最近のAI開発のしんどさ

今AI機能を使ったサービスの開発しているがその中で困ったりすることがあったので残しておく。

常に結果が安定しない

これから書く内容の全てでこの問題が根本に影響を受けている。AIモデルはほぼ期待した結果が出ているが、稀に期待していないレスポンスが返却されることがある。この今までのシステムの前提と大きく違うことが大きく影響している。

普通のシステムと同じ結果が出ると思われる

最初はAIを使った補助的な機能として開発されていたのだが、いつの間にかメイン機能想定で組まれるようになった。確かにビジネス視点で言えばAIを補助的に使うサービスよりも全面に打ち出した方がいいのは理解できる。

ただ全面に打ち出したからといって技術的に問題が急に解決するわけではない。期待値だけが上がりいつの間にか結果が常に安定している訳ではないことが置いてけぼりになっている。

通常のアプリケーション開発との兼任

AI機能とは別に通常のアプリケーション開発も行っている。そのためAI機能の改善に常に時間を割いているわけではない。そのため改善したいことはあるが他の作業も並行しているのでAI機能に対しての要望が出たとしても、そもそものAI機能を開発するための土台が出来ていないので大変である。

関係者でAIについて知識・開発レベルでの差を感じる

AI使ってこういうことをやりたいという要望を受ける。ただ紐解いてみるとそれってかなり難しいと感じることがある(例えばAIを使って全自動のような)。そこを丁寧にコミュニケーションするのが大変である。というよりも、前提の知識の隔たりがあるので説明するのが大変である。

また期待しないレスポンスが起きた場合にすぐにプロンプトの修正を直接指示されるのも大変である。今のプロンプトを改善して問題が果たして解決されるのか、改善した結果逆に悪くならないのかなどの評価が難しいからだ。もちろんプロンプトを評価する手法もあるが、その評価する仕組みをちゃんと整備していない。 そのためHuman loopではないけど、手動でフォールバックの方法もあるが直接プロンプトの修正を指示されるのがキツい。

期待値が高い

SNSでも海外のベンダーやサービスで新しく出来ることが増えた、また新しい手法が増えたことによってどんどん期待値が上がっている。でも前提として個人単位で使った場合が多い。例えば上記のプロンプト改善だって個人レベルであれば評価云々よりもどんどん改善した方がいいとは自分も思っている。でも複数人が使う前提のサービスでかつメイン機能であればそれは難しい。

さらに海外ベンダーが宣伝する内容だってベストパフォーマンスのことが多いし、こんなすごいサービス出来ているんだから、自分たちも出来ると言われても人員も資金も全然違う前提を無視していることが多い。

まだ自分は携わっていないが本格的なAIエージェントの実装はかなり難易度が高い。ちょっと技術書を読んだ感想レベルであるがこれを作るのも運用していくのも大変そうだなと感想になった。

要件定義が雑になった

AIエージェントで開発が高速になった反面要件定義や指示が雑になっていくことを感じる(自分だけ？)

もちろんAIエージェントの活用によって開発スピードは上がるが、この要件定義が雑になることによってそんなにスピードが出ていない。また雑な要件定義は雑なコードとPull Requestが増えるので人で書いていた時よりも技術負債が増えている。別にAIエージェントだから技術負債が増えてもそこまで問題無いという考えの人も増えているが自分は反対である。コンテキストが無駄に増えるのでAIエージェントの精確さもどんどん低下するからだ。

というよりもAIエージェント関係なく間違った方向に進んでいるなら高速に開発が出来るかどうか関係なくゴミしか出来ない。しかも別にやってみなければ分からなかったという問題でもなく、1時間ぐらい調査や考えれば回避出来た問題が多いのでより徒労を感じる。

これは現場の問題ではあるけど要件定義が雑になった組織が増えたのではと思う。

---

雑に最近思っていることを書いてみた。
過渡期ならではの問題でもある。個人的にはAIに対して期待値が高すぎるのと、仮に可能だったとしてもそれに対応できる人も資金も不足しているため

2025年の振り返り

2025年を振り返る。

仕事について

引き続き週2でiOSの開発を行うのと、別のプロジェクトを週3する感じの1年間だった。iOSについてはほぼ変わらない。そのため若干マンネリ化しているので、来年はLiquid Glass対応をしていけたらと考えている。

別のプロジェクトは主にSaaSの開発だった。技術はRuby on Railsプロジェクト、PHPプロジェクト、Next.js + React Nativeプロジェクトの3つをした。今はNext.jsとReact Nativeを引き続き書いている。 方針としてはiOSのネイティブ開発一本だと不安のため、分散のためWeb系の仕事も並行している。

個人開発について

何年か前に本格的にやるのはやめると書いたが今年もなんだかんだ書いている。理由としてはAIの影響が大きいと思う。昔よりも短時間で開発ができるのと、AIでの開発の実験場として個人開発をしている。

4月にはほぼ更新をやめていたアプリの開発を行ったところユーザー数が倍になったのは嬉しかった。ただ妻のために開発したアプリであるため5月以降やマーケティングするやる気は起きずそのままにしている。

6月からは自分のために作ったシステムを拡張してSaaS化した。

チャット日報

内容は簡単に言うと日報の管理をSlackの上で出来る。作成した理由としては緊急ではない重要なことを後回しにしてしまうことが多かったので毎朝日報に目標内容を書くというのをしていた。効果は高いが手帳やNotionに書いても急ぎの内容があると見返すのを忘れてしまうことが多く、そのため普段一番使うツールであるSlackで管理できたらと考えたのがきっかけである。

また過去に一時期仕事のメンバーの管理をしていたが、自分が忙しかったのもありメンバーが現在の状況を把握するのが大変だった。だから日報みたいな形式で提出してくれるとすごく助かるが、日報を提出側の立場になると何か必ずしもフィードバックがあるわけではないので難しさも感じた。そのような経験でもっと上手くやる方法はないかと考え日報の管理ツールを作った。このへんはもっと書きたいこともあるが長くなりそうなので一旦やめておく。

技術的なことを書くとSlackのSDKをTypeScriptを使用しさらにExpress.jsのフレームワークを含んでいるので、自然と構成が決まってしまった。TypeScript自体は好きでも嫌いでもない言語だが生成AIが発展した今だからこそ思い切って別の言語にしたかったな。例えばRustとか仕事では全然使う見込みはないが一つのきっかけとしてやりたかった。

期間としては子どもの寝かしつけ後や始業前の時間をコツコツやっていたので6ヶ月間ぐらいかかってしまった。来年は開発だけではなくてプロモーションのために動画投稿など違う分野のことを挑戦したい。

AIについて

今年の初めは高精度なタブ補完レベルだったのがこの一年でエージェント経由でコーディングが圧倒的に増えた。とくにOpus 4.5になってから精度はよく主力としてはClaud Codeを使っている。金額は高かったが明らかに金額以上の時間の節約は出来た。その他にもCursorは常用しCodexは仕事関係で無料で使えるようになっている。使い方としてはClaudeで大まかな実装方針をドキュメント化して実行し、適宜Cursorで整えていく感じが多い。Codexはドキュメント化した内容のレビューをしてフィードバック用に使っている。

色々と新しい機能は多いが全てを試していると時間が無くなるのとベストプラクティスも変わるのでり、具体的に改善したいタイミングで都度調べるようにしている。

気をつけるいる点は月並みだがいわゆるコンテキストエンジニアリングと作成対象を絞り込みする点。 コンテキストを必要最低限の量を与えることにこだわっている。そのため必要以上の仕様のドキュメント化はあまりさせなくて関連コードを指示する時にちゃんと含ませることを意識している。そのため指示しやすい設計を作るのは重要だと考えている。あとは作成対象の絞り込みでは雑に「会員登録機能を作って」というのではなく、ある程度は設計後に細かく指示するやり方にしている。

他に変化としてAIエージェントは便利だがコードを書きながら仕様を考えるみたいなのは昔は少しアリだった感じだったが、AIエージェントが主体になると明らかに手戻りがキツくなるのを感じた。理由としてはコード生成スピードが速いためふわっとした要件でもがっつり書いてしまい、後から変更になった場合にその分のコードを消すのがツラい。そのためわりと以前より最初から要件を決めておきたい。

ただこのブログだったり個性を反映したものに関してはあまりAIは頼らないようにしたいと考えている。

まとめ

子供が3歳になって色々と会話が出来るようになって楽しいし、積極的に旅行に行ったりした。子どもの記憶には将来残らないかもしれないが自分達の思い出にはなるのでそれは良しとする。

投資から見たITフリーランス vs サラリーマン論

基本的にはどっちでもいいしケースバイケースだよねとは思っていたがスタンスをどちらかに取った方が面白いトピックである。そのためポジショントーク込みでフリーランスの方がいいと自分は立場を取る。

まずはそう思った結論として”投資・資産”を築くのにどちらが有利かを考えた時にフリーランスになった。

前提としてあくまで資産のみをフォーカスした話にする。それ以外の要素を書き出すときりが無いので対象を絞りたい。そして自分が将来の理想像として資産をある程度積み上げ40代以降は平日を週3~4日が生活のための労働で、それ以外のは平日は別のことをしたいという目標にしている。

以上前提が終わりで大きな会社でマネージメントしたいとか、企業に属さないと達成できない目標が無い人向けである。

そして以下が本題

投資歴としては20代の時に個別株で低い金額だが失敗してからあまり才能が無さそうだなと思いたまに暗号通貨ぐらいしかしてこなかった。難しいなと思ったのは伸びそうな会社であっても世界経済・日本経済の動向に株価は連動しているので、企業自体に魅力があっても自分の力ではどうにもならない点と個別株などは株価の上下が激しいので感情コストが高いと思った。エンジニアっぽく言うとめちゃくちゃでかいプロセスが常時動いているのでリソースを大量に消費しているということか。

ただ3年前から節税目当てでiDeCoを本格的にしてから以降はNISAも含めてインデックスの投資中心にした。 資産のポートフォリオの比率を重視していて、投資信託・iDeCoと現金の比率を気をつけている。 また暗号通貨や個別株は資産として重視していないが暴落時に購入して最初に決めた金額で売却をしているので資産というよりも臨時収入目当てとしてている。スタンスとしてはフリーランスの部分でリスクを取っているので手堅い感じにやっているが、単純に個別株の勉強時間が無いので中途半端に個別株やる方がマイナスになるという判断からだ。

余談だが投資の成績が今のところいいのでこれ個人開発をしないでその分を受託して全力でインデックス株に投資していた方が圧倒的に資産も時間も節約になっていたなあと思ったが、、

ここからが本論だが大部分のエンジニアは会社員よりもフリーランスの方が税金、経費、単価を含めて可処分所得(会社員で言うと手取り)が多く残りやすいのでそれを全力で投資した方が資産が残りやすいと自分は考える。例えばS&P 500の過去10年間の平均年間上昇率は、概ね12%から14%程度ある。さすがに30年ぐらいの幅を取ったら10%は切るかもしれないが会社員で年収が毎年10%ずつ上昇するのはかなり難しい。つまり労働収入より投資の方が資産を増やすには効率がいい(ピケティの法則（R > G）)

ということは長期投資で重要なのは投資額と投資期間が重要なのでフリーランスでがっつり最初からまとまった額を投資しやすいフリーランス(マイクロ法人含む)のが有利であるからだ。

もちろん種銭としての労働収入はフリーランスでも会社員でも重要なのは変わりない。ただ会社員の方が賃金の上昇がゆっくりではあるので若い時にがっつり入金することが難しく無理をするとQOLが下がる。ほかにも退職金を投資に回しても投資期間が短く大して増えないし、増えないことを考えてリスクが高い投資商品に手を出すのはもっとやめた方がいい。

まあ以上がほとんどの内容だが投資の話は身近な人同士でもしにくし、というよりお金についての話題は嫉妬の対象にもなりやすいのであんまり情報共有されない。

余談：本当は2025年の振り返りで書いていたがこの箇所だけ長くなったので別に切り出した。

フリーランスエンジニアのアンチパターン

もう長くフリーランスエンジニアをしていても業績などの外部要因以外で契約を切られているエンジニアというのはあまり見たことがない。ただし過去に切られた人の中で共通項を書いていきたい。

コードのキレイさににこだわりが強い

コードの品質にこだわりが強くとにかくキレイにしないとストレスが貯まる人。ただこの品質というのも実際には個人視点のキレイさであって他の人が必ずしもそのキレイさに同調しているわけでもなかったりする。

また個人的にキレイなコードじゃないとストレスが貯まるし、やりたくないというの一種のワガママに見える。フリーランスのエンジニアに求めらているのは汚かった・読みづらいコードも理解してプロジェクトを進められる能力が必要である。

自分は昔いた会社のコードがまあ酷かったからある意味耐性が付いたのは不幸中の幸いだったかも。

プロジェクト・プロダクトの成功ではなく自分のやりたいことを優先する

コードのキレイさに似ているが自分がやりたいタスクや実装方法に固執する。そのためちょっとしたタスクでも勝手に大規模なリファクタリングも追加したり、費用対効果が良くわからないリファクタリングを勝手に始める。リファクタリング自体は悪いことではないが誰からの同意を得ていないこと勝手に始めると他の人のリソースを奪うのでやめたほうがいい。

プロジェクトに参加していきなりアーキテクチャの変更や既存のコードを貶す

プロジェクト参加して実力を披露したく空回りしているか、もしくは自分が好きなアーキテクチャに変更して快適にしたいパターンである。ただ新参者がよくプロジェクトの理解が浅いままやると結局のところ費用対効果が悪く、なんならマイナスのことしかない。だから企業ブログで異動・新規に参加していきなりこんな改革をしましたみたな内容を見ると本当に大丈夫かな？という印象を持つ。

アーキテクチャだったり大きな変更というのは変えた直後ではなくて、実際には半年から1年くらい時間が経過しないと効果は出ないものだから。

また既存のコードに文句を言うのはやめよう。まだ1円も売上に貢献していないタイミングでそのような発言するとデメリットしかない。(デメリットしかないという発言する時点でとくにフリーランスには向いてないが)

進捗の共有が苦手

分かりやすく自分が何をしていてどこまで進んでいるか共有するのが苦手だったり、重視してない人がいる。そのためマネージャーの人は進捗共有について時間を取ることになってしまう。結果的にマネージャーの人が負担になってしまい悪い評価になる。

これの防止はチケット管理を入れているなら進捗状況をこまめに記入するだけで良い。そうすればマイクロマネジメントもされないので快適に仕事が進められる。

2024年の振り返り

今年はの冬休みは出かけたり作業に集中したりして恒例の振り返りが書けなかったのでこの時期になってしまった。 ただ2024年は色々と挑戦した年だったが上手くいったこともあるし、良くなかったこともある年だった。

勉強会や交流会に参加

経営者同士の交流会に誘われて参加した。結果から言うとちょっと自分には今のタイミングではないなと感じたので退会した。悪い場所ではないと思うし合う人には合うと思うが、子どもが小さいタイミングで優先して継続的に参加するのは難しかった、、

ただそれ以外の勉強会やiOSエンジニアの交流会にも参加してああエンジニアの勉強会はこういう感じだったなあと思いだした。

年初の個人開発やめることについて

結局色々と考えた上で完全にやめるというのはしないことになった。ただ、個人開発と書くと趣味みたいな感じになるので普通にサービス作りというように変える。

継続する理由としていくつかある。

まずコロナ直前からあったDXブームは少し一段落した年だった。その結果システム開発自体の件数は落ち着いた傾向にあると思う。
そのためちょっと営業すれば良いようなことは難しく、何かしらの戦略を持たないといけないなあとはやっていくうちに感じた。また単純に受託して何でもやりますだと印象に残りづらい。そのためこういうことに興味があるということを発信するためにもサービス作りはした方が良いし、またサービス経由で仲良くなれたらいいなと考えている。

追い風としてコーディング面も含めてAIの発達が進んだので昔よりも敷居は下がったと思うし、AIを活用する素振りとしてもサービス作りの経験は重要そうである。 とはいえ毎回一からスクラッチするのでは大変なので共通化しやすいようにしていっている。

受託について

今年はいくつかの案件に参加した。ただ、やはり普段の自社サービス企業の開発とは違う。自分の参加したシステム規模は大きくないので比較的にリスクは小さいがこれが何千万や何億みたいな金額のシステムになると全然違うスキルが求められる。ということで自分はシステム開発はできるけど、受託開発のプロではないと感じることが多かった。

が、今の受託開発のやり方が今後AIが導入され始めるとめちゃくちゃ大きく変わるなあと同時に思った。とくに大規模なシステム開発というよりも自分が得意とするスモールチームでの開発のやり方は大きく変わる気がする。今までは重い要件定義や見積もりをしてから本格的な開発着手だったが、今後はPoCのようにAIである程度までのシステムを一気に生成しお客さんに触ってもらいながら詳細をつめるみたいなことが起きそうである。この方が認識の齟齬もおきづらいし、とりあえず触ってみないとよく分からないと今までだったらわがままな要求も満たせそうである。ただ要件定義までの時間は短縮はされると思うが全体の工数が下がるのかというと劇的に下がることは無さそうと思う。結局デモとしてシステム開発とユーザーに提供するシステムは作り込みが違うので期間は下がるかもしれないが、システム開発に費用はそんなに落ちないと予想している。

ともかく昔のiPhoneやクラウドと同じように、AIによる受託システム開発はゲームチェンジャーである。

技術について

iOSの開発は継続して行っている。今年は本格的にSwiftUI導入の年だったので、UIKitよりSwiftUIで構築する時間の方が多かった。

自分のサービスではNext.jsを使った。とくに最新のAppRouterを使用して作業した。よくSNSで言われているような難しすぎるという指摘は一部当たっているし、誇張に表現されている面も多いという印象を受けた。 ただ、Next.jsは自社開発という枠組みでは上手くいくかもしれないが、受託開発になるとやはりまだ先進的すぎて使うのは時期尚早ではあるなあと。

あと受託の方はRailsを使用した開発を行っていた。久しぶりなので結構忘れていたが、こちらも改めてメリット・デメリットあるなあと感じた。とはいえRailsでMVC全て完結するフルスタックの面とActiveRecordの優秀さなどはやはり唯一無二と感じる。

ここしばらくTypeScriptでバックエンドを構築していたが、オブジェクト指向ではないし、かといって関数型言語ような強力なパターンマッチやIO向けの機能が備わっていないので記述量が多く疲れた(個人的に感じるあらゆることがTypeScriptはBetterではあるがBestではない)

仕事の強度

会社員・フリーランス・経営者関係ないんだけど、仕事の強度を減らしていくのはやめた方がいいなと思った。30代後半って絶妙で目の前の仕事は今まで資産でなんとかこなせるし、育児も含めてプライベートでも忙しくなる期間だと思う。ただそうすると手癖で処理するようになり、新しいことの挑戦や目の前の仕事にスーパーコミットするみたいことをしなくなり40代ぐらいの微妙なおじさんが出来上がる下地になりそうだなと思った。

だから今の期間に1日2~3時間しか仕事しなかったり、旅行しながら仕事するみたいなことはしないように自分を律しないといけない。

家庭の時間を減らすというのは別にしないが受けている仕事や自分の仕事については営業時間内は精一杯コミットする習慣をもっと継続していきたい。

---

2025年について

今年からは年間単位の目標を立てることはやめることにした、というよりも立ててもあまり行動に結びつかないので意味がなかった。
そこで今年からはOKRを使うようにする。OKRというツールはここ何年か仕事先でも使っていたし、四半期単位で設定するのも良い区切りだと思うので。別に目標設定をしないという判断をしてもいいのだが、そうすると目の前のタスクばかりに手を取られて緊急ではないけど重要なタスクに手がつけられないので長期的にやばいなという自覚が出てきたので。

やばいなという実感の一つとして生成AIの台頭である。エンジニアの仕事がこの先どんどん需要が逼迫するという予想だったのだが、生成AIの登場で前提が大きく変わった。つまり今の開発のやり方が10年以上先までも同じやり方で残るとは到底思えない。生成AIによって低品質な翻訳やイラスト作業が消滅したようにどこかのレイヤーがまるっきり無くなるということはありえるだろうし、そこまで頭数が要らなくなり賃金が低下することはありえそうである。

ただ悲観的な面だけではなく解決できる課題も広がるし、今まで良くも悪くも日本語が障壁だったのが同時通訳によって海外の仕事を請け負うハードルが低くなることもあるだろう。

まとまりの無い感じになってしまったが、今年も頑張りたい。

工数見積もりのサービスを作った

最近、システム開発向けの工数見積もりを簡単にするサービスを作った。

https://www.bakumitsu.com/

トップページのデザインは全然だめだし、まだ作りたい機能は山程あるが一旦リリースしないとずるずるしてしまうなあと思って公開した。

バクミツのコンセプト

一言で言うと「システム開発における工数見積もり作業に対して、正確さと作業時間の短縮」を目指し、より抽象的には「工数見積もりのベストプラクティスを集めたフレームワーク」を提供したい。 システムに開発において要件からどのぐらいの工数を見積もることはクライアント作業であれば利益に直結するし、自社開発でも事業計画に影響があるので正確に見積もることはすごく重要である。

例えば最近でもスタートアップが金融向けのシステムを大手企業と協業して作ろうとしたら、莫大な開発が必要と発覚して最終的には解散になった。これは極端な例だけどエンジニアをやっていれば当初予定していたリリース日から2~3ヶ月遅れてしまったということは結構な人が経験していると思うし、その結果の機会損失や軌道修正に多くの作業・時間が失われることになる。

他には受託開発であれば見積もりを出して欲しいと依頼があると思う。ただこの見積もり作業というのは作業としては非常に重いのに、失注した場合はタダ働きになる。このような損失を少しでも減らすために見積もりの効率化は重要であるし、さらに早い段階で不明点を洗い出せておけば赤字というのも防げる。

自分が持っていた課題点

見積もりにおいて誰にどのようなシステムを作るのかという要件定義はかなり重要だ。ただ要件定義の部分は個々のケースが違うので共通化して解決することは難しかったりする。ただ見積もりが外れる点として自分は以下の課題があった。

• Excel・スプレッドシートで見積もりすることも多いがとくにテンプレートを持っていいない
• Excel・スプレッドシートについて苦手意識がある
• 誰かが公開しているテンプレートもあるが、自分には不要な項目があったりしてしっくりこない
• システムの設計・実装の部分に見積もりにを重視しすぎて、その他のドキュメント作成やミーティング時間に対してのぬけもれが多い

つまり見積もりにおいて要件定義は以前として重要であるが、そもそも他の部分も改善できるしこれが10%改善するだけでも大きな差になっていく。

その他のモチベーション

以前宣言したがあまり個人での開発についてやる気は実はなかった。ただ、今年は入って外部の人と交流するようになって感じたのは自分のサービスやプロダクトを持っている方が話題のきっかけになりやすいなあと感じた。

また今までは自分が好きだったり、将来性がある(勝手に？)と感じたサービスを作ってきたが、自分が継続的に使用するという部分については出来てなかった。そういう意味では開発する上で見積もり継続するので最終的に自分ひとりだけでも使用する。

直近の目標

まずは工数見積もりの一点について10倍の効率化を目指すツールを目標にする。

【2024年】受託案件でRuby on Railsを使用した感想

5月から7月末の3ヶ月間に受託の案件をしており、その際にRuby on Railsで使用した。
選定の理由としては元々の依頼主がRailsに詳しかったり、別の先行しているプロジェクトで参考になるコードが多かった、つまり資産を流用できるのでリスクが低いと判断して採用した。

個人のRailsの経験で言うと合計で2年ぐらい過去に使用していたが、結構忘れてしまったところも多かった。ただ1ヶ月を過ぎたぐらいでだいぶ書き方を思い出したのでそこまで足を引っ張ったわけではなかった。

この記事の狙いとしては久しぶりにRailsを使った感触について書いていく。

実装の作業量はフロントの方が圧倒的に高い

最近のプロダクトの業務量としては圧倒的にフロント側の方が高くなってしまった。これは単純にユーザーが普段使用するtoCサービスにおいてUI/UXがかなり向上し慣れてしまったからだ。
その他にも純粋にサービスの機能で差を付けるのが難しく、また競合に真似もされるのでプロダクトにおいての違いの部分が使いやすさが重要になった。

そのためSPAのように画面遷移をなるべく挟まない、昔ながらMVCで十分という古いエンジニア多い意見に対して賛同できない。今はよっぽどPoCとかそういうプロジェクトでない限り純粋な機能差で圧倒できるビジネスモデルは難しい。(めちゃくちゃ使いにくいけど圧倒的な営業力で売上を上げているプロダクトはあるが、それはこんかいとは関係のない話)

以上の背景が前提にある。

Hotwireの感想

今回の案件では画面の動きをHotwireメインでサービスのコアとなる複雑なUI部分だけReactで実装した。Hotwireについては以下のブログ記事がとても参考になるし主張している箇所も納得できる。

Hotwireの良かった点、辛かった点、向いているケース、向いていないケース - 猫Rails

ただ上の記事でも書いてあるようにReactとHotwireの両方を利用するバットプラクティスを実践した。理由はコアの部分の仕様が複雑すぎてHotwireのみでは実現が難しかった。

Turbo Frames, Turbo Streams, Stimulusの使い分け

Turbo Frames, Turbo Streams, Stimulusの左から右への順番で複雑なUIに対応ができて、StimulusというのはJavaScriptも書きたい場合に使用する。要するに段階的に使えることがメリットらしいが自分は逆にデメリットに感じた。

そもそもそのUIが以上の3つうちどれからスタートすればいいか経験がないと判断が難しい。Turbo Framesからスタートしていけばという意見もあるが、どう考えてもその試行錯誤している時間は無駄だし、またUI変更とは頻繁あるのでその度に切り替えるのはコストがかかる。

Railsは選択のレールがしっかりしていて、迷いが少ないというのが売りだがここには迷いが生じているので個人的には微妙な点だった。

手続き型のJavaScript

Reactは関数型の傾向が強いが、Hotwire(Stimulus)は手続き型の記述なのでなんというか、昔のjQueryでの実装に近い。確かにJQuery使うのであればHotwireで良いと思う。 たぶんRails自体が関数型の書き方ではないから、それに合わせたと思う。

ただ手続き型で複雑なUIを実装していくには困難ということは歴史が証明しているので、今回コアの部分をReactする結果になった。

そのため機能によっては一部Reactなりで書かないといけないみたいなことが発生すると開発者がHotwireとReactの両方に精通する必要があるのでそこは問題がある。 しかし、上の記事にもあるようにView側は完全にReactでRailsはAPIサーバーに徹する場合にコミュニケーションコストが確かに発生するので、小規模案件ではペイしないと主張も正しい。

TypeScriptを使わない

Stimulusは基本的にJavaScriptで記述していく(DHHがそのように方針を変更した)。そのためビルドが複雑になるのを回避するために、ReactもJavaScriptで記述するようにした。結果的にReactの部分が複雑になったのでケアレスミスが発生しまた補完が効かないので効率が悪かった。

確かにRubyは動的言語だから統一したかった狙いはあるかもしれないが、個人的には開発者体験が悪かった。まあRuby書いている人がその延長でStimulusを書く流れだから分かるが、、フロントエンドエンジニアからは不評である。

以上のことを書いてて結局Reactが必要がないような仕様であれば100%意見は変わっていたと思う。ただし、ユーザー視点ではなくHotwireだとキツイので仕様変更しましょうというのも違う気がするし今回のように自社開発ではない場合に断るのは難しい。

Hotwire以外でRailsの良さを感じたこと

Hotwireに関しては厳しいことを書いたが改めて良さを感じたことも多かった。やはりActiveRecordは強い。ORMとしてのメリットも大きいがバリデーションが直感的かつ短い記述で書けるし、テストの周りもFactoryBotやFackerなど定番のライブラリを使って簡単に記述出来たこと。 以前Nest.jsで以上のバリデーションやテストコードを書いたがRailsほどに洗練も情報も十分ではないのでやはり大きく差がある。

またRails consoleの使いやすさやdebuggerも使いやすいので、ViewではなくAPIサーバーに徹したコードをかけばストレスはほぼ感じない。

ただ最大に良いところはRailsはフレームワークの機能ではなく、アーキテクチャも提供している点だ。いわゆるRails wayというものである。Rails以外のフレームワークは最低限の置き場所は決まっているケースもあるが基本的にはプロジェクトごとにアーキテクチャが異なる。もちろんちゃんと分析し設計すれば良いのであるが、プロジェクト初期にそこまで分析できることは稀である。また初期にその設計が良かったとしても初期メンバーが入れ替わったり、サービスのピボットでベストが変わる可能性がある。つまり、Railsの設計方針はBestではないけどBetterであるし、世の中のほとんどのプロジェクトはそれで十分だったりする。

Hotwire以外でRailsとRubyの残念なところ

RailsというよりもRubyが動的言語であるためnilの判定を事前にビルドしてチェックできない。 これは上記で書いた利点が動的言語であるからのトレードオフになっている。RBSというLintでチェックもあるらしいがまだそこまで広がっていない。それにRBSを後から頑張って書くのであればGo言語で書き換えしてパーフォーマンスの向上も選択肢に入る。結局昔感じた大きなプロジェクトの場合に事前に型のチェックが出来ないことによる問題は当たり前に残っている。

大規模プロジェクトにRailsが使えない？GitHubやShopifyのような大きなサービスでも使われているじゃないかという反論もあるがそもそも比較することがナンセンスだと感じる。所属しているエンジニアの能力も給料も全然違うしRailsを保守していく費用も日本の一般サービスと全然違う。

ただ難しい問題で事前に型のチェックような入ると今のRubyとRailsの良さの部分も大きく影響あるだろうし、たしかに静的言語の要素を積極的に取り入れてしまうと単純にRubyの魅力も同時になくなる。

まとめ

以前以下のような記事を書いた。
受託企業のプログラミング言語とフレームワークの選定 - cassette

色々と批判的なことを書いたが受託開発する上で実はかなり相性の良いフレームワークと感じた。受託開発だとスタート開始時点で十分な仕様が固まっていることも稀だし、またドメインエキスパートとなる人間と距離がある中でBestではないけどBetterであるアーキテクチャを提供するのは開発を進める上で心強い。