私は先日ジョブローテーションで経営企画室に配属されました。
数日間ではありましたが、いつもの業務とは異なり新しい景色を見ることができました。
その中でも印象的だったのが日本アクセス様主催の展示会へ
「旬をすぐに」のブースを出展したことです。

牛すじカレーとバターチキンカレー、マッサマンカレーなどの試食を作り、
宣伝をしました。
試食をしてくださった皆様からは「美味しい」という言葉をたくさんいただき、
チラシをお渡ししたり、おすすめポイントなども合わせてお伝えいたしました。

電話で対応するミールタイムと違い対面での提案になりますが、
まずは自分が良いと思ったポイントをストレートに伝えることで
共感をしていただけることも多く、そこは同じ点だと感じました。
展示会はその場ではビジネスにすぐ繋げることはないと思いますが、
こうした一つ一つの宣伝が皆さんに知っていただく、そしてビジネスに
繋がるきっかけだと感じました。
今はまた日々MFD事業部に戻って日々仕事をしておりますが、
自分の想いをしっかり言葉にすることは変わらず大切にしていきたいです。
——————————————————————————————

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

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

さいごに

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