最近は寒暖差が激しい日が続いていますが、
皆さん体調はいかがお過ごしでしょうか。

朝晩は冷え込むのに、日中は少し暖かかったりと、
自律神経が乱れやすく、体調管理が難しい季節ですよね。

そんなこの時期に大活躍してくれるのが「鍋料理」です！！

鍋料理は、調理時間や下処理が比較的少なく、
忙しい日でも手軽に作れるのが大きな魅力。
食材を切って煮込むだけなので、
料理が苦手な方でも挑戦しやすいメニューです。

また、野菜・肉・魚・きのこ類などをたっぷり入れることで、
一度の食事で多くの栄養素をバランスよく摂取できます。
ビタミンやミネラル、たんぱく質もしっかり補給でき、
体を内側から温めてくれるのも嬉しいポイントです。

「しっかり栄養をとりたい」
「体を温めたい」
「風邪予防をしたい」
「免疫力を高めたい」

そんな今の季節の悩みを、鍋料理は一気に叶えてくれます。

さらに、味付けや具材を変えることでレパートリーも無限大！？
飽きずに続けられるのも、鍋料理ならではのメリットですね。

ちなみに、鍋料理については、
X（ミールタイム小西）でも紹介していますので、
ぜひそちらもチェックしてみてください！

今日は何を作ろうか迷ったら、
ぜひ手軽で栄養満点な鍋料理を選んでみてはいかがでしょうか。
心も体も温まる鍋料理で、元気にこの季節を乗り切りましょう！！
ぜひそちらもチェックしてみてください！

——————————————————————————————

ファンデリーでは、一緒にお客様の在宅食をサポートしてくれる
栄養士仲間を募集しています。エントリーはこちら【第二新卒歓迎♪】

＜2027新卒　栄養士・管理栄養士職＞
エントリースタート！2026年3月会社説明会参加必須
募集要項　詳細は☟
https://www.fundely.co.jp/recruitment

下記ブログもご覧くださいませ。
大阪で働く栄養士の医療機関紹介ブログ
神奈川で働く栄養士の医療機関紹介ブログ
AKABANE TECH BLOG
——————————————————————————————

2月13日、14日にパシフィコ横浜で「第41回日本栄養治療学会学術集会
（JSPEN2026」が開催されました。

医師・看護師・薬剤師・管理栄養士・その他コメディカルの方が
たくさん来場されました。

ミールタイムも企業展示で参加致しました。
1日目は「あいこちゃん青の鯖水煮 食塩不使用」、
「ラカント」、「サプリ米」、「便利なお酢　糖質ゼロ」、
「マンナンヒカリ」のサンプルをご紹介しました。

管理栄養士さんにも、たくさんブースにお越しいただき、
嬉しいことにほとんどの方が
「ミールタイム（カタログいつも届いています。」と
おっしゃっていただきました。

また、主に看護師さんや薬剤師さんにもミールタイムのことを
ご紹介させていただきました。

かわさき記念病院　佐藤様

今回はマンナンヒカリのパック「マンナンごはん」の試食も
行いました。
「噛めば噛むほど美味しいですね」
「普通のごはんと変わらない美味しさ」などの感想をいただきました。

次回もJSPEN2026の様子をお伝えいたします。

——————————————————————–
下記ブログもよろしくお願い申し上げます。
赤羽ではたらく栄養士たちの日記
大阪で働く栄養士の医療機関紹介ブログ
AKABANE TECH BLOG
————————————————————————

1月30日（金）～2月1日（日）まで京都国際会館にて
開催された日本病態栄養学会に参加しました。
今年も企業展示ブースにて医療従事者の皆さまに
『ミールタイム』をご紹介しました。
参加者は特に管理栄養士が多く、
ほとんどの方がミールタイムをご存知でとても嬉しかったです。

今年は大塚食品様と一緒にマンナンヒカリの試食も行いました。
マンナンヒカリには炊飯タイプとレンチンできるパックごはんタイプが
あることをご存知でしょうか？
今回はパックごはんタイプをご試食いただきました。
ミールタイムコラボ弁当☞ヘルシー食ごはん付き：牛肉の甘辛炒め

普段お会いしている大阪の栄養士様がブースに来てくださり
とても嬉しかったです。また、今年も他県の栄養士様との
新たな出会いがたくさんありました🌼
※医療機関名50音順
🌼愛川つつじ糖尿病内科　鈴木先生

🌼東住吉森本病院　南鶴先生、立石先生

🌼福岡和白病院　大山先生、藤嶋先生

🌼明徳病院　高田先生

次回は2月13日（金）からパシフィコ横浜にて開催される
JSPENに参加予定です。こちらも試食やサンプル配布を
予定しておりますので、ご参加の皆様はぜひファンデリーブースに
お立ち寄りください♪

——————————————————————————————-
ファンデリーでは、一緒にお客様の在宅食をサポートしてくれる
栄養士仲間を募集しています。エントリーはこちら【第二新卒歓迎♪】

＜2027新卒　栄養士・管理栄養士職＞
エントリースタート！2026年3月会社説明会　参加必須
募集要項　詳細は☟
https://www.fundely.co.jp/recruitment

下記ブログもご覧くださいませ。
赤羽ではたらく栄養士たちの日記
神奈川で働く栄養士の医療機関紹介ブログ
AKABANE TECH BLOG
——————————————————————————————-

こんにちは。
デザイン・システム室の以後です。
私はプログラミングスクールを経て、未経験でエンジニアになりました。

未経験者向けのスクールではRubyはよくある言語の一つだと思います。
私もRubyをスクールで学んでから入社しました。
そんな私が入社してから実務に携わり始めて感じたことを共有します。

特に現在Rubyを学習されていて、これから未経験でエンジニアを目指している方の参考になればと思います。

前提としまして、私は４ヶ月間のスクールでRuby on Railsのポートフォリオ作成まで行えるスクールに通っていました。

スクールでは、主にRuby on RailsのMVCフレームワークを使ってアプリを作る学習をしていました。
基本的な構造や条件分岐の方法などは感覚的にわかりやすく、Railsの文法に慣れることやアプリ作成の流れを学ぶことにはとても適していると感じます。

ですが、実務ではアプリを「作って終わり」ではありません。

• 維持
• 管理
• 改修

これらを必要とします。

１番の違いは、完成がゴールではないということです。
未来を考えた設計をしなければならないということが、私が初めて実務を行う中で感じた未経験での学習時との違いです。

そのためにスクールで学んだ知識を前提として、スタンスを変える必要があると感じました。

FATコントローラーとは？

もちろんスクールと実務の違いはたくさんありますが、最初に感じたのはこの「FATコントローラー」の問題でした。

「FATコントローラー」とは、コントローラーに処理が集中しすぎて長く複雑になった状態を指します。
初学者がMVCで学ぶ段階では気づきにくい（私はそもそもFATコントローラーという概念すらスクール学習時には知りませんでした）ですが、実務においてコードが成長すると以下の問題が出ます。

• 
  テストがしにくい
  コントローラーはHTTPリクエスト・レスポンスを扱うため、テストを書くと複雑になりやすい。
• 
  再利用性が低い
  同じ処理を別の箇所でも使いたくても、コントローラー内のコードでは呼び出せない。
• 
  変更に弱い
  複数の処理が1箇所に混ざると、変更の影響範囲が大きくなる。

FATコントローラーの例

class OrdersController < ApplicationController

  def create

    # 注文作成

    @order = Order.new(order_params.merge(user: current_user))

    if @order.save

      # 在庫を減らす

      @order.items.each do |item|

        Inventory.decrease(item)

      end


      # ポイント付与

      RewardPoint.add_for_order(current_user, @order)

      # メール送信

      OrderMailer.confirmation_email(@order).deliver_later

      # 外部API連携

      ShippingService.create_shipment(@order)

      # 成功時リダイレクト

      redirect_to @order

    else

      # 失敗時は再表示

      render :new

    end

  rescue StandardError => e

    Rails.logger.error("注文作成に失敗しました: #{e.message}")

    redirect_to new_order_path, alert: "注文処理中にエラーが発生しました"

  end

  private

  def order_params

    params.require(:order).permit(:address, items_attributes: [:product_id, :quantity])

  end

end

上記コードは上から順に追っていくには読みやすいものだと思います。ですが、

• 「注文作成」「在庫減少」「ポイント付与」「メール送信」「外部API連携」など、複数の処理が混ざっている
• コントローラーが長く、読むだけでも大変

幾つものifが重なったコードの中の１部分を改修したいとなった時、

if X

　①

elsif xxx

　②

elsif xxxx

　③

elsif xxxxx

　④

else xxxxxx

　⑤

end

上記のような分岐のコードが出来上がったとして、③だけ内容を変えたいとなった際にXを呼んでいる影響範囲が大きくなり改修難易度が格段にあがります。

また、１つのアクションでこれぐらいのボリュームになってしまいますが、これが１つのコントローラーにいくつも定義され、そのようなファイルが数十も格納された状態から、特定の動きを編集、修正することは容易ではありません。

ではどうすればいいのか。

サービスとは何か？

Railsでは「Service」という専用のフォルダを作って、コントローラーでもモデルでもない、ビジネスロジックをまとめる場所として使うことが多いです。

• コントローラーは「受け取る・返す」だけ
• モデルは「データの管理やバリデーション」だけ
• 複雑な処理や複数モデルをまたぐ操作はサービスにまとめる

サービスに切り出すことで、テストしやすく、メソッドの再利用が簡単になります。

モデル・サービス・コントローラーの使い分け

要するに、MVCのCに書きがちなものを、MとS（サービス）フォルダにも分けて書けるということです。

層役割書く内容の例コントローラーリクエストを受け取ってレスポンスを返すパラメータ取得、サービス呼び出し、レンダリングモデルデータやそのルールを扱うバリデーション、関連付け、単純な集計や計算サービスビジネスロジック、複数モデルをまたぐ処理注文作成フロー、メール送信、外部API連携、トランザクション管理

FATコントローラーをモデルとサービスに切り分けた例

モデルに切り出す処理

class Order < ApplicationRecord

  has_many :items


  def decrease_inventory

    items.each { |item| Inventory.decrease(item) }

  end

end

サービスに切り出す処理

class CreateOrderService

  def initialize(user, order_params)

    @user = user

    @order_params = order_params

  end


  def call

    ActiveRecord::Base.transaction do

      order = Order.create!(@order_params.merge(user: @user))

      order.decrease_inventory

      RewardPointService.new(@user, order).apply_points

      OrderMailer.confirmation_email(order).deliver_later

      ShippingService.new(order).create_shipment

      order

    end

  end

end

コントローラーは呼ぶだけ

class OrdersController < ApplicationController

  def create

    @order = CreateOrderService.new(current_user, order_params).call

    if @order

      redirect_to @order

    else

      render :new, alert: "注文処理中にエラーが発生しました"

    end

  end


  private

  def order_params

    params.require(:order).permit(:address, items_attributes: [:product_id, :quantity])

  end

end

どうでしょう。内容は同じですが、３つのファイルに分けて記述できました。

先ほど簡易的に書いたコードで言うと、①〜⑤それぞれを別のメソッドX1、X2、X3、X4、X5のように名前をつけてバラバラにして保存しておけば良いということです。

こうすることで、ロジックに変更があった際の影響範囲がわかりやすくなったりと、維持・管理性が上がります。

しかし、これは一概に細かくすればいいというわけでもなく、正解はありません。
企業ごと、プロジェクトごとにそれぞれにあった粒度での記述が求められます。

答えがない以上、私も何が最適かを考える力を鍛え続けていく必要があると感じています。

まとめ

• スクールと実務ではスタンスが違う
• MVCだけで完結する作り方は、初学者にとって学びやすく、RubyやRailsの理解に役立つ
• しかし、実務では維持・管理・改修を考えるとFATコントローラーは避けるべき
• モデルとサービスに責務を切り分けることで、テストしやすく、再利用性も高い、見通しの将来性の高いコードになる
• 答えがない問題である以上、思考力の鍛錬は続いていく

さいごに

現在デザイン・システム室では、新しいメンバーを募集しています。少しでも興味を持たれた方は、ぜひご応募ください✨💻
皆様からのご応募、心よりお待ちしております。