おはようございます！ zenncast、MCのマイクです。10月26日、月曜日、朝7時になりました。新しい1週間の始まりですね。今日もZennでトレンドになっている記事から、開発のヒントになる話題をお届けします。
今日は、開発ツールの移行から、イベントを支えたアプリ、SwiftUIの状態管理、AI時代のレビュー、そしてデータベース設計まで、5本の記事をご紹介します！
....
まず1本目は、OxlintとOxfmtへの移行についてです。
開発ツールを乗り換えるとき、チェックが速くなるのはうれしいですよね。でも、この記事で確認しているのは、速度だけではありません。これまでのコードの整形結果を、そのまま保てるかどうかも大事なポイントです。
記事の検証では、importの並び順や、Tailwind CSSの独自クラスの並び順を維持しながら、チェック時間を約9.3秒から約3秒に短縮できたそうです。既存の書き方を大きく崩さずに速くできるなら、移行を考えやすくなりますね。
そして、ツール選びとあわせて大切なのが、開発の規約を、機械で守れる形にすることです。自動で直せるものはformatterに、違反を検出できるものはlinterに任せる。そのうえで、人の判断が必要な内容だけを文書に残す、という整理ですね。
lintのエラーにも工夫があります。ただ「禁止です」と伝えるのではなく、なぜ禁止しているのか、代わりにどう書けばいいのかまで示します。そうすれば、人間もAIも、別の文書を探し回らずに修正できます。
移行を進めるときは、整形による変更とlintの修正を別々のコミットに分け、ルールも少しずつ追加していきます。既存ルールが移行先で対応しているかだけでなく、実際に有効になっているかも確認が必要です。
そして、忘れたくないのが、自動修正でも処理の意味が変わる場合があること。修正後は差分を確認し、型チェックだけで安心せず、テストも実行する。速さと安全性をセットで考える、実践的なお話でした。
....
続いて2本目は、専門学校生が1人で開発したインカムアプリ、「inkam」のお話です。
このアプリは、600人規模のイベントで、60人以上のスタッフの連絡を支えました。1人で作ったものが、これだけの現場で使われたというのは、すごいですよね。
使い方は、ボタンを押して話すだけ。ただ、それだけではなく、音声を字幕に変換したり、文字を音声に変換したりできます。声を出しにくい静かな場所でも、あるいは連絡を聞き逃した場面でも、情報を共有できるようにしているんです。
画面を消した状態でも受信できるよう、スマホアプリとして開発し、音声の配信にはWebSocketを使うシンプルな構成を採用しています。
開発が最初から一直線に進んだわけではありません。途中で、最低限の通話機能から作り直し、必要な機能を順番に追加する進め方へ切り替えたそうです。
その結果、本番では大きな不具合なく、1,493回の発話を支えました。しかも、費用は約1,100円に収まったとのことです。
現場で必要なことを見極めて、まず動く土台を作る。そこから機能を積み上げる大切さも伝わってきますね。字幕と音声の両方で連絡できるところにも、使う人への気配りを感じます。
....
ここから3本目。Xcode 27での、SwiftUIの@Stateのマクロ化についてです。
今回の変更は、Viewを作り直すたびに、初期値を計算してしまう無駄を減らすものです。ポイントは、@Stateをprivateで宣言し、その宣言時に初期値を書くこと。この条件では、同じViewとして扱われている間、初期値の評価が1回だけになります。
ただし、この遅延評価を利用するには、対応OSの下限をiOS 17、macOS 14以降にする必要があります。また、fileprivateの宣言も対象ですが、internalの宣言や、イニシャライザの中で代入する場合は対象外です。書き方によって動きが違うので、ここは注意したいですね。
初期化エラーへの対処にも落とし穴があります。代入の順番を変えるだけでエラーを直そうとすると、代入した値が警告なく捨てられる場合があるそうです。一方、宣言時の初期値を外して、イニシャライザで初期化する方法では、遅延評価が失われます。エラーが消えたからといって、意図どおりとは限らないわけですね。
では、親から渡された値をどう扱えばいいのか。親の値に追従するならlet、子から変更するなら@Bindingを使う、という整理が紹介されています。
筆者がおすすめしているのは、モデル自体は宣言時に作っておき、taskのid付きの仕組みで、その中身だけを更新する方法です。
なお、@StateObjectでは、外部の値を使って初期化する場合でも、生成を1回にできますが、@Stateも同じように動くわけではありません。また、内部用のLazyStateを直接使うことも推奨されていません。
似たような書き方でも、初期化のタイミングは違う。状態管理を見直す際に、押さえておきたい内容でした。
....
続いて4本目は、AI時代に、人間は何をレビューすべきなのか、というお話です。
筆者のチームでは、人間によるコードレビューを半年ほどやめてみたそうです。その間もリリース数は落ちず、レビュー待ちの時間は減りました。
ただし、代わりに導入した、実装前の方針確認には課題がありました。AIが書いた文章を人間が承認するだけになってしまい、十分には機能しなかったんですね。
この経験から筆者は、人間が確認すべきなのは、コードそのものやAIが書いた文章ではなく、人間が下した判断の妥当性ではないか、と考えています。
今後の方針は、AIが決めきれない点を人間に質問し、その回答を記録すること。そして、その人間の判断に絞って、チームで確認するというものです。文章全体をなんとなく承認するのではなく、「何を、なぜ選んだのか」を確認する方向ですね。
さらに、AIが自動で改善を繰り返す場合についても提案しています。人間が、どこまで任せるのか、いつまで任せるのかを先に決めておき、結果を定期的に確認する仕組みが必要だということです。
これは、単にレビューをなくせばいい、という話ではありません。AIに任せる仕事が増えるからこそ、人間が責任を持って判断する場所を、はっきりさせようというお話なんですね。
....
最後の5本目は、AIにとっても読みやすいデータベース設計についてです。
AIに実装を任せるとき、データベースの意味が分かりにくいと、確認する手間が増えたり、推測によるミスが起きたりします。そこで筆者は、Claude Codeを使って、同じ集計処理を条件ごとに5回ずつ実装させる実験を行いました。
その結果、読みにくいデータベースでは、平均コストが約1.9倍、所要時間が約1.8倍になりました。さらに、日時の解釈を間違えるケースも1回起きたそうです。
もちろん、小規模な実験なので、この数字がどんな開発にもそのまま当てはまる、と一般化するには注意が必要です。それでも、データの意味を読み解く負担が、AIの作業にも影響することを考えさせられますね。
筆者が挙げているのは、分かりやすい命名、意味を補うコメント、そしてテーブル同士の関係を明記することです。人間にとって読みやすい設計は、AIにも効く、というわけです。
AI向けの特別な工夫を考える前に、まずは、人間が見ても意味を理解できる状態にしておく。それが、確認の手間や推測によるミスを減らすことにもつながるんですね。
....
さて、今日のzenncastは、5本の記事をお届けしました。
OxlintとOxfmtへの移行では、速さだけでなく整形結果と安全性も確認すること。インカムアプリのinkamでは、現場の連絡を支えた機能と、段階的な開発の工夫。Xcode 27の@Stateでは、遅延評価の条件と初期化の注意点。そして、AI時代に人間の判断をどうレビューするか、読みやすいデータベース設計がAIにも役立つ、というお話でした。
詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてくださいね。
番組への感想もお待ちしています。「この話題が気になった」「自分のチームではこうしています」など、気軽に聞かせてください。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回も皆さんにお会いできるのを楽しみにしています。お相手はマイクでした。今日も、いい1日をお過ごしください！