
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
リンクをコピー
記事をブックマーク
清野隼史氏(以下、清野):では、次のテーマに移ります。テーマ2までで、今のWebアプリケーション開発がどうなっているか整理できたと思います。それをまた踏まえた上で、次は「Railsってこういうところがいい」「こういうところがいまいち」という点を語り、最後にRailsに自分たちはどう向き合っていけばいいのか、どう使っていけばいいのかについて話します。
まずテーマ3「Railsあるある」では、Railsのいいところとつらいところをざっくばらんにうかがいます。まずはいいところから。Railsの「やはりここいいよね」というところはありますか?
櫻庭洋之氏(以下、櫻庭):賛否両論ありますが、ActiveRecordがメチャメチャ強力でシュッと書けるという強みのほか、ActiveSupportもすごく親切なメソッドがメチャクチャ用意されているので、データ操作が簡単に直感的に書けるのは、開発体験としてはメチャクチャいいと感じます。
清野:僕もまさにその部分(がいいところ)だと感じていて。Railsがここまで成長できたというか、これだけ使われるようになったのはActiveSupportの書きっぷりのよさによる。本当に書き心地がいい。オブジェクトを触っているだけのような感覚でDBアクセスできてしまうのが繁栄した理由だと考えているので、本当にそこはいいところだと僕も思います。赤沼さんはいかがですか?
赤沼寛明氏(以下、赤沼):今の点はすごく思います。久しぶりにRubyの素のスクリプトを書こうとすると「これRailsにしかないんだっけ?」と思うことがある。それ以外には、これも善し悪しだと思いますが、暗黙的な処理というか、記述をしなくても勝手に、よしなにやってくれるところが強力で、サービス立ち上げのスピードはすごく早いと思います。
設定より規約という点で、レールに乗っかっているとメッチャ早いというか、勝手にやってくれるので、そのスピード感はすごいと思いますね。
清野:まさにRailsのコンセプト、ルールに従って書いているだけであればすごく書きやすいというか、設定をする必要もない点は魅力的ですよね。チャットに「良くも悪くもなんでもよしなに処理してくれる」と来ています。まさにRailsのよさであり、困ることでもある。
櫻庭:でも、初学者がつまずく悪いポイントでもあるのかもしれませんね。「ここはどう動いているんだろう」という。
清野:確かに。逆に初学者の成長を妨げてしまっているかもしれませんね。なんでもよしなにやってくれちゃうせいで、深掘りしづらいというか。
赤沼:コードだけ見てもわかりませんからね。
清野:わかりませんね。
赤沼:知らないとわかりませんからね。
清野:いいところについて、ほかに「なんだかんだ楽、ってなります」ときています。Railsのいいところは、立ち上げるところなど、ルールに従って書いているとスピーディにどんどん作っていけることですよね。
続いて、つらいところにいきます。すでにいくつか来ているので紹介します。1つ目は「config配下に設定がメチャクチャあってつらい」。これは、Railsの枠からだんだん離れたり、いろいろなツールをどんどん入れていくと発生するんですよね。
櫻庭:そうですよね。gemもスタイルはさまざまですが、魔術的なタイプのgemだと中身もよくわからないし、configの書き方もよくわからなかったりするのかもしれません。
清野:READMEに書いてあるものをそのまま貼るとなぜか動くけどまったく理解できない謎の現象がありますよね。そのほかに「読むのがつらすぎる時ありませんか?」という質問も来ています。
櫻庭:これはトリッキーなコードを書いてしまった時ですか?
清野:そうですね。特にクラスの継承やモジュール、Model Concernを使っている時はしんどいですよね。
櫻庭:わかります。
赤沼:このあたりは、静的な型付け言語ならIDEでよしなにしてくれるけど、Railsだとそうはいかないから自分で理解して追っていかないといけない。それがつらいところなのかな。
清野:まさに。型があれば、逆にそれがメリットになることもあると思いますが。
赤沼:そうですね。
櫻庭:Rubyは、「YARD」などのドキュメントで書けるっちゃ書けるけど、オブジェクトの中に何が入っているのかはコードを読むだけでは判断できないこともあるので、そのあたりはつらいですね。
清野:しかもYARDも途中からだとYARDもやりづらいというか、「これ全部書くの?」みたいになっちゃいますよね。
赤沼:確かに。途中からやり方を変えようとすると、だいぶつらいですよね。
清野:どんどん来ます。「カッコよく書きすぎてほかの人が読めないコード、ありがち」。いわゆるメタプロでしょうか。誰でもDSL(Domain-Specific Language)っぽい書き方ができてしまうというのはありますよね。
櫻庭:みんな一度はハマる道のような気がします。「Rubyでなんでも作れるじゃん」って思って、オレオレ構文作りを始めるという。
清野:感動してメタプロにハマって、カッコ使わなくなって読めなくなるみたいなことありますよね。
赤沼:元のクラスになんでも追加できちゃうから、どこで何をやられているかわからなくなることもありそうですよね。
清野:ありますね。続いて「良くも悪くもよしなにやってくれない言語を書く時に、逆にそこがわかんなくなる」。Railsがなんでもやってくれすぎちゃうからという。
櫻庭:これはあるかもしれません。いわゆる「Webってどう動いているの?」という点、つまり、きちんと基礎を押さえていないと、先ほど言ったように暗黙の部分に想像が働かなくて、デバッグ自体できないということがあるかもしれません。
清野:ありますよね。続いて、ちょうど僕も質問したいと思っていたんですが、「Railでドメイン駆動設計をやるとつらくないですか?」。Railsのつらみとして、アーキテクチャがMVC(Model-View-Controller)から離脱しようとすると難しいというか、しんどくなることが多いと思っています。それに関してどう向き合えばいいとかありますか?
櫻庭:僕は、Railsでは無理にDDD(Domain-Driven Design)でやる必要はない。あまりメリットがないと思っている。DDDではなく、例えばServiceクラスやFormオブジェクトなど、いわゆるRailsが標準で用意していない概念を入れることはあると思いますが。設計能力とそれを運用し続けるチームのスキルが揃っていないと破綻しやすいので、ファットモデル上等というか、むしろ太らせて素直に作っていったほうがいいとずっと思っていました。
清野:なるほど。赤沼さんはいかがですか? 社内で設計やアーキテクチャを変えている事例はありますか?
赤沼:今話に出たServiceクラスは弊社も使っているので、そのあたりは各プロダクトのチームに任せています。こっちのプロダクトではServiceクラスをこういう使い方しているけど、こっちのプロダクトではこう使っていて、こっちのプロダクトではそもそもServiceクラスを使っていなかったりする。正直、あまり整理できていませんね。
また、DDDに限らず、「どこまでやるべきか」とか、「Railsでそれをやるのが正しいのか」とか、手法にこだわりたいのなら、それに向いたフレームワーク(言語)を使ったほうがいいのではないかという気がします。
清野:そもそもRailsならそういうことを考えないというか、変えるのが筋としてよくない。逆に、弱みというか柔軟性があまりないという言い方も、仮に言うとしたらできるのでしょうか。
赤沼:Railsは良くも悪くもすごく割り切っているフレームワークというか、もともとのクラス、オーソドックスなものならきちんとレイヤーを分けるところをギュッとしちゃっていると思う。それを活かしてやっていくのならすごくいいと思いますが、無理矢理違う構造に当てはめようとすると結局レールから外れないといけないので、そうするとつらみばかりになりそうな気がしますね。
清野:もう1つ、僕から聞きたいと思っていた質問があります。先ほど「最近は環境の変化で、フロントがリッチになってきているとかインフラが複雑になってきている」という話がありましたが、リッチなUIなどに対するRailsの相性はどうですか?
櫻庭:悪いと思います(笑)。パーシャルがよく使われているところは、悪さがプンプン出ているなと。パーシャルはもともとコンポーネント指向で作られているものではないので、お門違いかもしれませんが。フロント周りで細かくコンポーネントを作りたいとか、デザインシステムと連携してやっていきたいという時に、とにかくパーシャルが使いにくい。それが逸脱しているというか、つらいと思うところです。
清野:それは僕もすごく思います。パーシャル、コンポーネントっぽいインターフェースを提供してくれるようで、挙動は実はどちらかというとマクロっぽいというか、渡したものをそのまま展開されるところがあると思います。
櫻庭:スコープもグローバルで完全に開いちゃっているし、「これはどうすればいいんだ?」という。
清野:それは、Railsを書いている方みんなのあるあるなのではないかと思います。赤沼さんはいかがですか? ユニファの事例だと、Railsとフロントエンドはどうなんでしょう?
赤沼:先ほど話したように、弊社も最初はRailsの中だけで十分やっていたんですが、やはりそれもつらくなってきて、リニューアルしたプロダクトからVue.jsを組み合わせてやっています。弊社が提供するフロントエンドはすごくシンプルなので、Railsで十分やっていけていると思いますが、フロントにすごくこだわるようなプロダクトならRailsである必要はないのかなという気がします。
向き不向きという点では、フロントエンドリッチなものに向いているわけではないと思う。私自身がフロントエンド弱者だからでもありますが、「Sprockets」や「Webpacker」周りは黒魔術という印象があって、なんでそこがそう動くのかわかりづらいのではないかな。
清野:最近のRailsのトレンドでいうとがんばっている印象はありますが、それでもまだまだというか、全ページReactで書くレベルまでは行っていない感じですよね。
赤沼:フロント(エンド)なら本当に向いているものを選んだほうがいいのではないかな。
清野:「Vueにロジックゴリゴリ書いてあるとつらい」というコメントもきています。Vueもそうですね。Railsは境界が規約くらいでしかないから、どこにでも書けちゃいますけど。
赤沼:こうなるとつらいですよね。
清野:「Railsの設計をする時に参考にするプロダクトってありますか?」という質問がきています。「『GitLab』や『Redmine』を見たりしますが、規模が大きすぎて参考にするには難しい」。なるほど。
櫻庭:最近は見ていませんが、少し前はよく「マストドン」を見ていました。そんなに大きすぎず、中規模くらい。Serviceクラスはがっつり使っていましたが、参考にはなったかなと。ほかにはShopifyがよくブログで出しているものを参考にしますが、Shopifyはデカすぎて逆に参考にならないと思った。
清野:ちなみにRailsの設計の時は、各アプリケーションにどのくらい差分があるものなんですか? Railsのコンセプト自体はシンプルで、規約にのっとっているとは思いますが。
櫻庭:“俺が考えた最強のRailsアーキテクチャ”は、人の数だけある気がします。Qiitaの記事でいろいろな主張が並べられていることでもわかると思う。もし会社組織として取り組む場合には、目線合わせはすごく重要だと。
清野:ちなみに先ほどの話でいうと、ユニファもRailsの構成はシンプルでServiceクラスがある感じですよね。
赤沼:基本的にはそうで、すごく違うということはありませんが、各プロダクトのメンバーの好みが出る部分はある。例えばDBもRDB(Relational Database)、AWSなので、普通にやればRDS(Amazon Relational Database Service)やAuroraを使いますが、ものによってDynamoDBを使っていたりすると、クエリの投げ方が変わってくる。Railsの中でもジョブ、バッチ処理をどう構成するのかという点では、けっこうやり方が違ったりします。大枠のアーキテクチャとしては同じですが、世代というか、作られた時期によって個別の処理の仕方が違うことはありますね。
清野:確かに。gemも無限にあるし、何をミドルウェアとして使っていくかもいろいろあるので、そういうところに変化が生まれるということですね。
赤沼:きちんと考えてgemを取り入れないと(いけない)。適当なgemを取り込むと、後々メンテされなくなったりしてつらいことがあるので。
櫻庭:あるあるですね。
(次回につづく)
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
限られた時間で成果を上げるドイツ式仕事術
2025.01.21 - 2025.01.21
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29