糖尿病の主な治療方法は、食事療法・運動療法・薬物療法の3つです

特に、食事療法は最も大切な治療方法で、食事療法により
摂取エネルギー量が適正に保たれ体重をコントロールすると、
インスリン分泌やインスリンの効果が改善します。

そのため、食事療法だけで良好な血糖コントロールが出来たり
経口薬や注射薬を使用している場合には薬の量を減らすことができます。

また、食事療法は継続していくことがとても大切です。
ただ、日常生活と常に隣り合わせとなるため、過度に頑張りすぎるとストレスがたまり
途中でやめてしまう方も中にはいるかと思います。


ミールタイムでは、食事療法が初めての方や、慣れてきて続けるのことが
少し辛くなってきた方など、いろいろな悩みを抱える方に寄り添いながら、
食事サポートをさせていただきます。
お食事でお悩み事や聞いてほしいお話しなどがあれば、お気軽にご相談ください。




一方、薬物療法は、基本の食事療法と運動療法だけでは十分な血糖管理が
得られない場合に補助的な役割を担います。
薬が処方された後も、基本の食事療法と運動療法は必ず継続します。
これらを続けることで、薬の効果が期待できます。

糖尿病のタイプや症状、血糖管理の状態などを見たうえで、どんな薬を使うかが
決められます。
最近では、薬の種類が増えて、より効果的でより副作用の少ない治療が
できるようになりました。

自分が使う薬はどういう働きをするのか、どんな注意が必要か
など分からないことや気になることがあったら、主治医や薬剤師に相談しましょう。


薬物療法は、薬のことをよく理解して正しく使い、自己中断せずに指示通りに
続けることが大切です。



その他、お食事ごとなどでお困りごとがございましたら、お気軽に
ミールタイムまでご連絡ください♪


https://www.mealtime.jp/service

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

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

＜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
————————————————————————

先日は吹田市にある皐月病院様に訪問しました。
こちらの病院様は高齢者の方が多いことが特徴で、
内科、呼吸器科、消化器科、循環器科、放射線科、
リハビリテーション科があり、訪問診療も行われています。

今回は管理栄養士の土井様にお話を伺いました。

土井様は以前特養にお勤めされていらっしゃいましたので、
それぞれのやりがいについてインタビューさせていただきました。

〈 病院勤務のやりがい 〉
給食は委託給食会社が入っているため栄養マネジメントに
注力することができています。当院は医師や看護師と連携が取りやすく、
経管栄養の患者さんの栄養剤の種類を変えることで下痢を減らせたり、
患者さんの食事摂取量が増え退院が決まった時には
スタッフ同士喜び合い、やりがいを感じます。
また、他職種から患者さんの食事や栄養に関する質問をもらうことも多く、
その際に管理栄養士としてのやりがいを感じています。

〈 特養勤務のやりがい 〉
毎月のように行事食の提供があり費用や準備は大変でしたが、
食べられなかった利用者さんが少しずつ食べられるようになるなど
食事のサポートができた際にはやりがいを感じました。おやつの
提供があるため、利用者さんによって希望を調査したり、
選択肢を用意することで楽しみを作ったりもしていました。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
土井様、貴重なお話をありがとうございました。
土井様は栄養士資格を取得後、実務経験を積まれてから管理栄養士の
資格を取得されたそうです。以前お勤めされていた施設では、
その挑戦を応援・評価してくださった上司の方がいらっしゃったことや、
栄養士として勤務する上で調理経験の大切さについても教えていただきました🌷

土井様、皐月病院様の益々のご発展を心よりお祈り申し上げます。

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

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

さいごに

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