図 4-3 ログイン画面(ログインせずにログインが必要な画面にアクセスした時)
コーチが，管理者しか見ることのできないページにアクセスしようとした場合，図 4-4に 示すようにアクセス制限を示すメッセージを表示し，元々表示していた画面に遷移する．
図 4-4 週カレンダー画面（アクセス制限のあるページにアクセスした時）
4.1.3 ログイン状態の保存
システム利便性向上のため，ログインフォームの「ログイン状態を維持する」チェックボ ックスがチェックされた状態でログインが行われた場合には，明示的にログアウトしない限 り，ブラウザを閉じた後，再度システムにアクセスした際に，ログイン状態でシステムにア クセスすることができる機能を実装した．図 4-5にログイン状態を保存する場合のログイン 画面を示す以下にシステム内での処理について示す
A) アカウント生成時にアカウント毎にランダムに生成したtokenをDBに保存する．
B) メールアドレスとパスワードを利用してアカウント認証を行う．「ログイン状態を維持す る」チェックboxがチェック済みの状態でログインが行われた場合にはそのアカウント
のtokenを永続的cookieに保存する．チェックされていない状態でログインが行われた
場合はtokenを通常のcookieに保存する．
C) 永続的cookie はブラウザを閉じても保存されたままであるため，永続的 cookie に保存
されたtokenとDBに保存されているユーザのtokenが一致しているかを確認すること
でログイン判定を行う．これによりブラウザを閉じた後，再度システムにアクセスした 際にログイン状態でシステムにアクセスすることができる．
図 4-5 ログイン画面(ログイン状態を保存する場合)
4.2 メール送信機能
本システムはシステム上の情報の更新をユーザにメールで知らせるため，メール送信機能 が重要な機能として位置づけられている．システムがメールを送信する条件と処理の流れ図 を以下に示す．
4.2.1 コーチが代行依頼を行う場合
コーチが代行申請を行う場合の処理の流れを図 4-6に示す．下図ではコーチAがレッスン を休むことを決めて事務員に連絡を取り，その後システムを利用して代行依頼を行う．シス テム上で代行依頼手続きを行うと，代行依頼を行ったコーチを含むコーチ全員と事務員にメ ールが送信される．このメールには，コーチがシステムにログインせずに立候補するための リンクが記載されておりこのリンクをクリックすることで携帯端末上からでも代行への立候 補が可能である．
図 4-6 代行申請時
図 4-7 代行立候補時
4.2.3 管理者が代行コーチの選定を行う場合
経営者が代行コーチ選定を行う際の処理の流れを図 4-8に示す．下図ではコーチBとコー チのCの2人が代行立候補を行なっている状態で，管理者が代行コーチをコーチBに決定し た場合である．この場合，コーチBには代行コーチに決まったことを伝えるメールが送信さ れ，コーチCには代行コーチに決まらなかったことを伝えるメールが送信される．
図 4-8 代行コーチ選定時
4.3 メール送信のための環境構築
メール機能を実現するためには，SMTP サーバを利用する必要がある．しかし，Heroku はPaaSであるため，Heroku上にSMTPサーバを設置することはできない．そのためSMTP
サーバはHeroku外に設置されたものを利用しなければならない．私たちはレンタルサーバ
などを別途利用して，SMTPサーバを設置することを考えたが，顧客は可能な限り無料でシ ステムを運用することを希望していたため，別の方法を考えた．上記の顧客の要望を満たし た上で，メール機能を実現するためのSMTPサーバ設置に関して以下の2つの案を実際に構 築することで検証した
① GMailのSMTPサーバをメール送信のサーバとして利用
② 外部メール送受信サービスであるMailgunの無料プランを利用 次項から詳細を述べる．
4.3.1 GMail の SMTP サーバ
図 4-9にGmailのアカウントをSMTPサーバとして利用した場合の運用環境構成図を示 す．
図 4-9 運用環境(GmailのSMTPサーバを利用)
ローカル開発環境ではGmailアカウントを SMTPサーバとして問題なく利用できた．し かし，Heroku上で動いてるT1システムと SMTPサーバを連携させた場合，メールが送信 できなくなる問題が発生した．
その理由として，本システムの稼働環境であるHerokuはAmazon Web Service[11](以下，
AWS)上で動いているため，本システムからGmailアカウントのSMTPサーバに対してメー
証を手動で行わない限りメール送信不可能な状態になるため，メールが送信できなくなって しまったということが判明した．
対応策としてAWSのIPアドレスを固定する必要がある．しかし，この対応策ではHeroku の有料プラン契約を行わなければならないため，顧客の要望から考えるとコスト面での実現 が難しい．また，Gmail アカウントを SMTP サーバとして利用した際に，低速なレスポン ス(一通あたり約1.5～4.5sec)が問題となった．上記の理由から，案①は不採用とした．
4.3.2 Mailgun
図 4-10にメールの送受信を担う外部サービスであるMailgunを利用した場合の運用環境 構成図を示す．
図 4-10 運用環境(Mailgunを利用)
メール送受信サービスであるMailgunとHerokuを連携して利用することにした．
Mailgunの特徴は
・1日300通まで無料
・高速なレスポンス（一通あたり約0.1sec)
である．顧客と相談の結果，現状は1日300通の無料枠で十分運用可能であり，コーチが 増加した場合には有料プランへの移行を行うということで合意を得たため，本システムでは 案②を採用した．