寒さが続くこの時期は、体調管理が特に大切になります。
そんな季節におすすめなのが、
栄養価の高い旬の食材を取り入れた食事です。

冬が旬の大根・白菜・ほうれん草・小松菜などの野菜は、
寒さの中で育つことで甘みが増し、
ビタミンCや鉄分、食物繊維を効率よく摂ることができます。
免疫力の維持や腸内環境を整えるために、
ぜひ積極的に取り入れたい食材です。

そんな季節に、
旬の美味しさをお届けする「旬をすぐに」から、
白菜を使ったおすすめの一品をご紹介いたします。

『蒸して煮込んで出汁が染み込む豚こま肉と白菜のトロトロ旨煮』

芯の部分はシャキッと、葉の部分は柔らかく
味がしっかりと染みている白菜がいっぱい入っています。

また、ブリ・タラといった冬が旬の魚介類は、
良質なたんぱく質に加え、EPA・DHA、亜鉛など、
体調を支える栄養素が豊富に含まれています。
脂がのった魚は、焼く・煮るなどシンプルな調理でも
栄養を活かしやすいのが特徴です。

ここで「旬をすぐに」から、
鱈を使ったおススメの一品を紹介いたします。

『柚子香るみぞれ餡で口福に浸るもち麦入り鱈と豆腐の揚げだし』

鱈のふんわりやわらかな身とカラッと揚げた国産大豆の豆腐が
みぞれ餡に絡んでおり、優しい味わいとなっています。

旬の食材には、寒い季節を乗り切るための栄養が詰まっています。
日々の食事に上手に取り入れて、
無理なく、健康的な毎日を目指しましょう。

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

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

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

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

今回は、三浦郡葉山町にある葉山ハートセンターの
管理栄養士　池田　雄介様をご紹介します。

１.管理栄養士を目指したきっかけ
　高校時代から目指していた調理師として働きましたが、
　交通事故で続けられなくなり、その後ケーキ屋、バイク屋で働きました。
　母に「食べることが好きだから、栄養士をやってみたら？」と勧められて
　栄養士となり、老人ホームで働きながら管理栄養士国家試験に合格しました。
　ずっと好きなことを仕事にしています。

2.やりがいを感じる時
　ICUで経管栄養の患者様に対して、自分と医師のアセスメントが合致して
　血液検査結果が改善したときにやりがいを感じます。
　
　栄養指導では、「それならできそう、ありがとう」などと言われる時も
　嬉しく思います。

3.管理栄養士として今後やりたいこと
　ここは生まれ育った地域なので、自治体と一緒に地域の方の健康に携わる
　活動がしたいと思っています。
　認知症や嚥下機能が低下している方に、食べ方や調理方法などを
　提案するなどして地域貢献をしていきたいです。　

池田様、ありがとうございました。

葉山ハートセンター様から見える絶景にも感動致しました。
一流のホテルのようなオーシャンビューで、
「モナコ」がイメージされているとのこと。
江の島も見えましたし、天気が良いと富士山も見えるそうです。
これほど素晴らしい景色の病院は初めて訪れました。
思いがけず、新しい発見となりました。

——————————————————————–
下記ブログもよろしくお願い申し上げます。
赤羽ではたらく栄養士たちの日記
大阪で働く栄養士の医療機関紹介ブログ
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コントローラーは避けるべき
• モデルとサービスに責務を切り分けることで、テストしやすく、再利用性も高い、見通しの将来性の高いコードになる
• 答えがない問題である以上、思考力の鍛錬は続いていく

さいごに

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