生活習慣病は、日々の食事や運動、
休養などの積み重ねによって発症・進行する病気です。
糖尿病、脂質異常症、高血圧症に加え、
それらが進行した糖尿病性腎症や慢性腎臓病（CKD）、
さらには痛風なども深く関係しています。

【脂質異常症と脂の選び方】
脂質異常症は、血液中のLDL（悪玉）コレステロールや
中性脂肪が増えすぎた状態です。
動脈硬化を進め、心筋梗塞や脳卒中のリスクを高めます。
対策では、脂の「量」だけでなく「質」にも注目しましょう。
バターや脂身の多い肉、揚げ物などに多く含まれる飽和脂肪酸は控えめに。
一方で、青魚に含まれるEPA・DHAなどの不飽和脂肪酸は、
中性脂肪の低下に役立つとされています。
肉中心になりがちな食事を見直し、魚料理を取り入れるなど、
脂の選び方を意識することが重要です。

【高血圧症と減塩】
高血圧は、血管に強い圧がかかり続ける状態です。
自覚症状が少ないまま進行し、脳卒中や心筋梗塞のリスクを高めます。
主な原因のひとつが塩分のとり過ぎ。
塩分を多く摂ると体内に水分がたまり、血圧が上昇します。
減塩のコツは、
・だしや香辛料、酢・柑橘類で風味をつける
・汁物は飲み干さない
・加工食品を控える
といった日々の工夫です。
また、カリウムを多く含む野菜・果物の摂取も役立ちます。

【痛風とプリン体】
痛風は、血液中の尿酸値が高い状態が続き、
関節に尿酸の結晶がたまることで炎症を起こす病気です。
プリン体を多く含む食品（レバー、魚の干物、ビールなど）のとり過ぎや、
アルコールの過剰摂取が関係します。
対策としては、
・プリン体の多い食品を控える
・アルコールを飲み過ぎない
・水分をしっかりとる
・野菜や海藻類を積極的に取り入れる
ことが大切です。

【糖尿病と腎機能低下】
糖尿病は血糖値が高い状態が続く病気です。
高血糖が続くと、腎臓の糸球体というフィルターが傷つき、
老廃物を十分にろ過できなくなります。
これが「糖尿病性腎症」です。
初期は自覚症状がほとんどありませんが、
進行するとたんぱく尿が増え、腎機能が低下し、
将来的には透析が必要になることもあります。
予防・進行抑制には、血糖コントロールと適正なエネルギー摂取が重要です。
食べ過ぎを避け、主食・主菜・副菜をそろえたバランスのよい食事を心がけましょう。

【慢性腎臓病（CKD）の食事管理】
腎臓は、老廃物の排出、水分・電解質バランスの調整、
ホルモン分泌など重要な働きを担っています。
腎機能が低下すると、体内に老廃物（尿毒素）が蓄積し、
さまざまな不調の原因になります。
食事では
・塩分は1日6.0g未満
・たんぱく質のとり過ぎを避ける
・適正なエネルギー量を確保する
ことが基本です。
特に塩分過多は血圧上昇や腎機能悪化につながるため注意が必要です。

これらに共通するのは、
「エネルギーのとり過ぎを防ぐ」
「塩分を控える」
「栄養バランスを整える」
という基本です。
特別な制限ではなく、日々の小さな見直しが将来の健康につながります。

カタログP4～9では、各疾患のメカニズムや食事の具体例を図解で紹介しています。
ご自身やご家族の健康管理に、ぜひお役立てください！

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

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

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

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

前回に引き続き、JSPENの様子を紹介致します。

今回、ミールタイムブースの目玉は、「ミールタイム肉まん」の試食です。

（日本食品成分表2020年版と比較して）
塩分50％カット、タンパク質35％カットで「低たんぱく食」。
1個当たり168kcal、たんぱく質4.5g、塩分0.4ｇの美味しい肉まんです。
昨年１０月にリニューアルをして再登場した人気商品です。
鮮度の高い国産食材を使用しています。

電子レンジで温めて、提供しました。

「普通の肉まんと変わらない美味しさ」と大好評でした。

アレンジレシピはこちら↓
https://www.mealtime.jp/arrange/nikuman

今回の学会での素敵な出会いをご紹介致します。

※医療機関名50音順

聖マリアンナ医科大学病院　清水様

中田病院　永島様

東戸塚記念病院　濁川様

ブースにお越しいただいた皆様、
写真にご協力いただいた皆様、本当にありがとうございました。

今回は各メーカー様から提供いただいた商品を紹介したり、
自社製品である「肉まん」の試食を行うことができました。

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

2月13日（金）・14日（土）にパシフィコ横浜にて開催された
JSPEN（日本栄養治療学会）に参加しました。
ファンデリーは企業展示ブースにてミールタイムや
栄養指導で使える商品サンプルのご紹介を行いました。
昨年より30社ほど出展企業が増えており、会場も広く
豪華な装飾が目立っていました↓

先日参加した病態栄養学会では来場者のほとんどが
栄養士様でしたが、JSPENでは医師や看護師、薬剤師の方々が
多く来場されていました。ミールタイムをご存知でない方も
いらっしゃりましたが、食事の大切さについて一緒に考え、
宅配食に求めることを直接伺うことができました。

また、今回は昨年販売開始したミールタイム肉まんを
ブース来場者にご試食いただきました。
1個あたり塩分0.4gですが「全然減塩しているように感じない」、
「コンビニの肉まんと同じように美味しい」、「子供のおやつに採用したい」
など満足度の高い感想をいただきました。

病態栄養学会に続き、一緒にお写真を撮っていただいた
栄養士様をご紹介します♪※医療機関名50音順
🌼東川口病院　小松様

🌼南和歌山医療センター　近西様、黄瀬様

～～～～～～～～～～～～～～～～～～～～～～～
たくさんのご来場ありがとうございました。
次回は5月下旬に大阪にて開催される糖尿病学会に参加予定です。
参加される方はぜひファンデリーブースにお立ち寄りください。
お待ちしています！

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

＜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コントローラーは避けるべき
• モデルとサービスに責務を切り分けることで、テストしやすく、再利用性も高い、見通しの将来性の高いコードになる
• 答えがない問題である以上、思考力の鍛錬は続いていく

さいごに

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