RailsでのService Objectの上手な使い方 ―Service Objectアンチパターン説の検討―

業務のRailsアプリのリファクタ対応の一環でService Objectを入れてみたところ、なかなか快適に使えている感触なので、RailsでのService Objectについて私なりに調べたことをまとめてみたい。アンチパターンとして批判されることも多いService Objectについて、どういった使い方をするとマズいのかも掘り下げてみる。

Service Objectが欲しくなるとき

Rails標準のMVCで業務アプリケーションを実装して行くと、ビジネスロジックが複雑になるにつれて、ControllerまたはModelの処理が肥大化してつらい状態になりやすい。具体的には、

• 可読性が悪い
• テストが書きづらい
• Modelにメソッドが乱立し、そのModelがビジネス上どういう振る舞いを持つ概念なのか読み取りづらい

これらの観点が挙げられるだろう。この問題を解決する手段の一つとして、 Service Objectを導入する設計手法がある。

Service Objectとは

Service Objectは、Patterns of Enterprise Application Architecture（PofEAA）やドメイン駆動設計（DDD）におけるサービスレイヤを実装に落とし込む設計手法と言える。

上のPofEAAの図のように、ユーザーインターフェースとドメインモデルの中間でビジネスプロセスを処理するのがサービスレイヤの役割だ。

Service objects are Plain Old Ruby Objects (POROs) which encapsulate a whole business process/user interaction.

サービスオブジェクトは、ビジネスプロセスやユーザーとの対話の全体をカプセル化するプレーンなRuby Object（PORO）。

Forem*1の開発者向けドキュメントの上の定義もシンプルで分かりやすい。

オープンソースのRailsアプリケーションに見るService Objectの具体例

Servie Objectは、オープンソースのRailsアプリケーションに理想的な活用例を見出すことができる。

Servie Objectを活用しているオープンソースのRailsアプリケーションの例

MastodonのBlockServiceを読む

Service Objectの具体的な使い方は、上のリンク先のMastodon*2のBlockServiceを見ると分かりやすい。UnfollowServiceでお互いにフォローを外して、RejectFollowServiceでフォローリクエストをリジェクトし、その後ブロックする処理の様子をぱっと見で読み解くことができる。その後に呼ばれている非同期処理のBlockWorkerを辿ると、BlockWorkerの中でAfterBlockServiceが呼ばれていて、ブロックしたユーザーに関わる各種履歴データを削除していることが分かる。

Service Objectの実装方針

オープンソースの実装例や、Webの記事で紹介されている手法を読み解くと、Service Objectには、ベストプラクティスと呼べるような実装方針が一定確立されていることが分かる。それは下記のようなものだ。

• Object名を見て処理の概要が理解できるように命名する
• callやexecuteのような、1つだけ定義されたpublicメソッドを呼び出して利用する
• privateメソッドを細かく切って処理の概要を理解しやすくする
• 単一責任の原則を意識してService Objectを分割し、Service Objectの中で他のService Objectを呼び出す
• Rubyのプレーンなclass（PORO）で実装する

以下、詳細を補足したい。

Objectの命名

• 動詞 + (名詞) + Service
  • FollowService
  • RemoveStatusService
• namespaceを分けるパターン
  • Commits::CreateService

Object名がビジネスプロセスの実態を呼び出し先で表現するように命名することが大事だろう。namespaceは分けておいた方が予期せぬ要件の拡張があっても秩序を保ちやすい印象がある。

publicメソッド名の選択肢

call, execute, run, performなど、特定の文脈を想起させないメソッド名を採用する。個人的には、callがカプセル化されたビジネスプロセスを呼び出すニュアンスを最も良く表している気がして好み。

publicメソッドの定義方法

publicメソッドの定義方法は上に挙げた3つのRailsアプリにおいてもバラバラで、特にどれかが決定的に優れているとも言えないので、方式を統一しようとすると悩ましい部分になるだろう。以下に代表的な例と、各パターンについての私見を書く。

publicメソッドをインスタンスメソッドとし、newに引数を渡す

これが最も素直な書き方という感じがする。

publicメソッドをインスタンスメソッドとし、publicメソッドに引数を渡す

Mastodonが採用している方式。正直上の方式でなくこの方式を採用したい動機が私にはいまひとつ理解できないけれど、initializeメソッドがない分スッキリして見えるというのはあるかも知れない。

publicメソッドをクラスメソッドとする

クラスメソッドとして定義すると呼び出し方がスッキリするし、RSpecでテストを書く際にService Objectのmockを1行で書けるのも嬉しく*3、個人的にはこの方式を採用したい気持ちがある。引数指定が重複しているのが玉に瑕だけれど、

Ruby2.7で追加された3点ドットのarguments forwarding記法を用いると、上のようにスッキリお洒落に書ける。

Rubyのプレーンなclass（PORO）で実装する

プレーンなclassを使うことで、開発チームメンバーのスキル感を問わず分かりやすく、ライブラリの実装に依存する想定外の動作も起きない。

ActiveModel::Modelをincludeしてvalidation周りの機能を活用する手法もあるようだけれど、業務でService Objectを運用してみた感触でも、POROで見通し良く実装するのがService Objectの持ち味を活かせる気がしている。

理想的に活用できた場合のService Objectのメリット

上のような方針に従ってService Objectを活用した場合には、以下のようなメリットがあると感じている。

• ビジネスプロセスに細かい粒度で名前が与えられ、コードの可読性が向上する
• 再利用性のある形で設計することも可能
• チームメンバーのスキル感によらず、設計方針を理解して従うことができる
• ControllerとModelの中間層として、RailsのMVCに後からでも導入しやすい
• 引数と返り値の仕様が定まったclassになるので、テストを書きやすい

簡単*4で便利に使えてRailsとの相性も良いということで、非常に優れた設計手法という感じだ。

その一方で、Service Objectは決して銀の弾丸ではなく、間違った使い方をすると悲惨な事態を招きかねない側面もある。以下、Service Objectの誤った運用とその改善方法を見ていきたい。

Service Objectアンチパターン説

Service Objectはアンチパターンとして批判されることも多い。しかしこれらの批判をよく読むと、Service Objectがアンチパターンというよりは、その他の設計上の観点を考慮することなく作られたService Objectがアンチパターンであるように読める。

まずドメインモデルを考慮してからService Objectを作る

多くのOOエキスパートたちが、処理を行うレイヤをドメインモデルの一番上に置いて、サービスレイヤを作るよう推奨していることが、混乱のそもそもの原因です。 ただしこれは、振る舞いのないドメインモデルを作るということではありません。 そうではなくて、サービスレイヤの支持者は、振る舞いをたくさん含んだドメインモデルと一緒に使っています。

サービスの中に振る舞いを見つければ見つけるほど、ドメインモデルのメリットを奪っていくでしょう。サービスの中にすべてのロジックを埋めてしまうと、何も見えなくなってしまいます。

PofEAAのFowlerさんが「ドメインモデル貧血症」と呼ぶような、ModelのメソッドとしてModelに対応するビジネス上の概念の振る舞いが十分に定義されていない状態で、Service Objectを活用してしまうと、それはただの手続き型設計になってしまい、オブジェクト指向設計のメリットをまったく活かせなくなってしまう。

以下のような観点で、まずはドメインモデル側の設計を良く検討してみることが大事だろう。

• DBのテーブル構成と各Modelはビジネスの実態に対応しているか
• DBのテーブルに1対1に対応しないModelを作って見通しを良くできないか
  • Railsの場合、ActiveModel::Modelをincludeする手法が有効
• Modelの汎用的な振る舞いをModel側のメソッドとして定義できているか

RailsでModelを分割する手法について論じている記事

おわりに

Service Objectを切り口に色々と考えて行くと、ドメインモデルを重視するPofEAAやDDDの設計思想のコアも見えてきた気がする。プロダクトもチームも各現場で多様な中、オブジェクト指向設計に正解はなく、プロダクトが扱う実世界の概念をどのようにソースコードに落とし込めば、見通しが良くメンテナンス性が高い状態になるかということを良く考えて設計する必要があるということになるだろう。

その他参考にした記事

*1:コミュニティサイト構築OSS。爆速で有名な技術情報交換サイトdev.toはForemで構築されている。

*2:TwitterライクなSNS構築サービス。

*3:インスタンスメソッドでも2行で作れるので大差はないが。

*4:様々なスキル感のメンバーが集う日本の開発の現場においては、優れた設計手法でも理解が難しいと開発チームとしてメンテできないリスクがあると思う。

オフショアの開発リソース管理を半年間やってみて分かったオフショア開発のアンチパターンとその対処法

私が今所属している新規事業の部署で、日本の開発会社経由でベトナム人メンバー（開発エンジニア2名、QAエンジニア1名）に働いてもらっているのだけれど、私が転職してジョインした頃は随分といい加減な管理をしていて、成果物のクオリティも非常に残念な感じになっていたので、昨年の12月頃から私がチケット起票からコードレビューまでほぼ一人で担当する体制でテコ入れをすることになった。色々と苦労しつつ、今では一定以上のクオリティで効率良く開発できるところまで改善することができたので、オフショア開発の典型的なアンチパターンと思われる例や、オフショア開発の向き不向きについて感じたことを書きたい。

オフショア開発のアンチパターン

最低限の働きができないメンバーを放置してしまう

オフショアの開発会社は、中堅レベルのエンジニアから、明らかにド素人なエンジニアまで、多様なスキル感のメンバーを抱えていて、各現場の温度感に合わせてメンバーのやりくりをしているようだ。そのため、機能していないメンバーがいる場合に開発会社にフィードバックを上げずに放置してしまうと、「この現場はエンジニアのスキルレベルを判断できない」とみなされて、メンバー交代でレベルの低いエンジニアで固められてしまうことになりかねない。明らかに働きが悪いメンバーがいる場合は、開発会社にフィードバックしてメンバー交代してもらう必要があるだろう。

では、具体的にどのような基準で判断するかと言うと、下記の基準はすべて満たしていることが望ましいと感じている。

• 開発要件の不明点について自発的に質問ができる
• テストコードが書ける
• 開発環境で動作確認ができる
• 既存処理への影響について自発的に調査して対応できる
• 露骨にサボったりしない程度には勤勉な性格をしている

以下、各観点の詳細について書く。

開発要件の不明点について自発的に質問ができる

これは「報・連・相」ができるということで、オフショア開発に限らない社会人の基本スキルだ。これがどの程度適切にできるかで、仕事の精度と効率が大きく変わってくる。逆に言うと、一切自発的なコミュニケーションを行わないタイプのメンバーとまともに仕事をするのは難しい。

テストコードが書ける

日本語プロダクトのビジネス上の性質を共有しづらいオフショア開発では、テストコードをちゃんと書くことの重要性がより高まる。テストコードを書く開発が習慣化していて、特に指示しなくてもテストコードを書いてくれるメンバーが望ましい。逆に言うと、テストコードを書きやすい開発環境が準備されていたり、既存テストコードが充実しているかどうか、というのは受け容れ側のメンバーがちゃんとやっておくべきことになるだろう。

開発環境で動作確認ができる

開発環境でアプリを動かして動作確認するのはやはりやってもらいたい。私の場合は、GitHubのPRのテンプレートに動作確認用のセクションを設けてそこに書いてもらうようにした。当初やってくれない場合でも、何度かお願いすると自発的にやってくれるようになることもあった。

既存処理への影響について自発的に調査して対応できる

例えばあるメソッドを削除した場合の既存の影響範囲などを、チケット起票とコードレビューですべてカバーするには工数がかかるので、そういった部分については自発的に調査して対応してくれると助かる。

露骨にサボったりしない程度には勤勉な性格をしている

明らかにテキトーに遊んでいるとしか思えないアウトプット量で稼働するメンバーが割とよくいたりするので、勤勉な性格かどうかも重要な気がする。

チケット起票、コードレビューの精度が悪い

上に述べた観点でちゃんと働いてくれるメンバーが揃った上で、チケット起票、コードレビューは実装の知識があるメンバーが精度高く行う必要がある。機能要件レベルでフワッと渡していい感じに開発するには、プログラムの設計能力とプロダクトへの高度な理解が両方必要で、日本語のプロダクトについてオフショアのメンバーにそれを求めるのは難しい。設計、コードレビューがいい加減な状態でオフショア開発すると、コードの信頼性と可読性とメンテナンス性が恐ろしいスピードで悪化し、目もあてられない悲惨な状態のプロダクトがあっという間に出来上がってしまう。

精度の高いチケット起票、コードレビューについて具体的に言うと、チケット起票では、実装方針がクリアに理解でき、判断に迷うような設定値や命名について具体的に記載されているような内容になっていると、手戻りが少なくなる。コードレビューでは一行ずつ見落としなく読み、自分が書いた場合と同程度の品質になるまで、細かく指摘して変更してもらう必要がある。

コミュニケーションをサポートするメンバーの契約をしない場合は、これらのことを直接英語でやりとりする必要がある点にも注意が必要だ。

経営的な観点で言うと、設計やコードレビューができるメンバーの工数を大きくオフショア開発リソースの管理に割くということになるので、全体のバランスを考えたときに本当にオフショア開発の費用対効果が優れているのかは良く考えるべきだろう。

オフショア開発に向いていること、向いていないこと

以上のような観点もあり、オフショア開発に向いている開発とそうでない開発は明確に分かれると感じている。向いている開発としては、仕様が明確な機能開発や、コードの各種リファクタリング、ライブラリのアップデートなどがあり、向いていない開発としては、プロダクトに関する高度な理解が求められる開発や、機能要件だけ渡して設計からやって貰うような開発だ。なので、一人いると助かるけれど、大規模に活用する場合はデメリットも色々と大きくなると感じている。

副業は儲かるけれどやっぱりキツいよねという話

昨年の9月からやっていた副業を4月で終えることになったので、本業が正社員のWeb系エンジニアが行う業務委託の副業について、メリットとデメリットに感じたことを書きたい。

副業のメリット

儲かる

Web系エンジニアは現在大変な売り手市場で、業務委託契約の場合、中堅以上のスキルが有れば時間単価5000円以上の好条件で契約することができる。ちょっと副業をするだけで毎月10万円以上の副収入が得られる訳だ。実際にやってみて、貯金は見違えた勢いでグイグイ貯まるし、ちょっとした外食などの贅沢もやりたい放題で、お金には随分と余裕がある感じがした。

人間関係・仕事の経験の幅が広がる

副業先のエンジニアと色々話したり、本業とは違う現場で仕事をするのはなかなか面白かった。Web系ベンチャーの現場には悲喜こもごもがあり、現場を重ねるとそれぞれに味わい深い体験ができる。エンジニア的には未経験の技術構成に触れてスキルセットが増えるのも嬉しいところだろう。

副業のデメリット

普通にしんどい

転職直後で、本業の業務量に比較的余裕がある時期に副業を始めたけれど、その後本業で開発チームリーダー的な役回りが期待されるようになり、本業が尋常でなく忙しくなって副業との両立が難しくなった。平日の仕事後にやるにしても、休日にやるにしても、フルタイムの仕事とは別に更に働くというのは無茶な話で、ましてや本業がWeb系ベンチャーのフルコミット労働だとしたらなおさらだ。

仕事中心の生活になり、文化的な活動ができなくなる

定期的に更新していたこのブログの直近の更新が副業を始めた際の記事であることに象徴的なように、副業までやっていると生活が仕事中心になって、その他の文化的なことを行う余裕がまったくなくなる。せっかく昨年奈良に移住して来たのに休日の散策なども十分にできていなかったのも残念に感じていた。

Web系ベンチャー正社員フルコミット労働のコスパの悪さとやりがいについて

このような事情があり、当面は副業はやらないでおこうと思っているけれど、金儲けの観点で言うと、本業と副業を上手く程々にやりくりするのが圧倒的にコスパが良い印象がある。今やっているWeb系ベンチャーのフルコミット労働は、死ぬほど頑張ってショボい昇給を得るものなので、どう考えても労力に対してリターンが薄い。とは言えベンチャーに勤めている以上はフルコミットでやるのが醍醐味という部分もあり、働き方における理想とは何なのだろうと、改めて思ったりもしている。

フリーランスの副業を始めてから初回請求までにやったこと

9月から副業を始めたので、初回請求までにやったことを書いておきたい。知人のフリーランスエンジニアから得た情報を元に対応した内容で、ネットで検索してもフリーランスの副業を始めるのに必要なことは分かりにくい印象もあるかと思うので、参考になれば幸いだ。

私の副業の概要

• 職種はWebエンジニア（バックエンド、フロントエンド）
• 前職の同僚の紹介で都内のスタートアップ企業で副業
  • エージェントを挟まない直契約
• 副業の稼働は平日の18:00〜20:00辺りで1日2時間前後
  • 定められた時間単価を元に実動時間分請求できる契約
• 本業はフルタイム正社員

65万円の控除が受けられる青色申告をするために必要なこと

我が国の所得税は、納税者が自ら税法に従って所得金額と税額を正しく計算し納税するという申告納税制度を採っています。

1年間に生じた所得金額を正しく計算し申告するためには、収入金額や必要経費に関する日々の取引の状況を記帳し、また、取引に伴い作成したり受け取ったりした書類を保存しておく必要があります。

ところで、一定水準の記帳をし、その記帳に基づいて正しい申告をする人については、所得金額の計算などについて有利な取扱いが受けられる青色申告の制度があります。

確定申告の際に最大65万円の控除を受けられる「青色申告」と呼ばれる制度があり、この青色申告を行うためには、

• 開業届と青色申告承認申請書の提出
• 複式簿記による取引の記帳

が必要になる。字面を見るとかなり難解な印象だけれど、freeeやマネーフォワードのような会計ソフトの助けを借りればかなり容易にこれらには対応可能なようで、そのための具体的な準備は次のようになる。

開業届と青色申告承認申請書の提出

freee開業のサービスを使って、必要情報をWebフォームに入力したら開業届と青色申告承認申請書のPDFファイルがサクッとできた。マイナンバーカードを持っている場合はネットでの提出も可能とのこと。私の場合はマイナンバーカードを持っていなかった（今まで通知カードがあれば事足りると思ってサボっていたけれど、個人事業をやる上では必須のようなので、慌てて交付を申請した）ので、PDFファイルを印刷して最寄りの税務署に提出しに行ったけれど、担当者にポンポンと判子を押されるだけで拍子抜けするくらい一瞬で手続きが終わったのでかなりお手軽な印象だ。

事業用口座の開設

青色申告に必要な複式簿記形式の記帳は、専門知識がなくても事業用口座を作って事業関連の取引を集約した上でその口座と会計ソフトを連携させると容易に作成できるらしい。

住信SBIネット銀行で口座開設を申し込んだら簡単な審査でスピーディに開設できた。

稼働時間の記録

時間単価で契約しているので、実動時間の根拠を明示するために、副業先のSlackに「分報」や「times」と呼ばれる個人用チャンネルを開設して貰って、業務開始時に「始めます」終了時に「終わります」とポストして、その時刻を元に稼働時間を計算している。

日々の開始時刻と終了時刻を元にした月の稼働時間数については、Googleスプレッドシートの関数を使って上掲記事のような方法で簡単に計算することができた。

請求書の提出

業務委託契約の場合、正社員と違って毎月契約先に請求書を提出して報酬を得る必要がある。請求書は会計freeeのサービスを使ってPDFで作成できた。

請求書の書き方については、上のマネーフォワードの記事を参考にした。

消費税の請求とインボイス制度

私の場合税別の時間単価で契約しているので、消費税を請求できる。

消費税では、その課税期間の基準期間における課税売上高が1,000万円以下の事業者は、その課税期間における課税資産の譲渡等について、納税義務が免除されます。

また、私の場合免税事業者に該当するので、その消費税申告分をまるまる貰ってしまって良いらしい。月々の請求単価が10%上乗せされるのは相当大きい。

しかし、2023年の10月から始まる「インボイス」制度で、この免税事業者が消費税分を収入にすることがやりづらくなるらしい。かなりややこしい制度で始まってみないと各企業の運用がどうなるか分からない部分もあるけれど、基本的には課税事業者になる以外の対策がないような印象で、現状免税されている事業者からすると10%の収入減になる可能性が高い恐るべき制度だ。インボイス制度については2019年あたりに大変な議論になっていたのを何だかよく分からない話題として横目で見ていたけれど、今になって論点が理解できた。

『ポケモンユナイト』でマスターになるコツ

7月に配信された『ポケモンユナイト』に最近ハマっていて、ソロを中心に600戦以上プレイして最上位のマスターランクでレート1300以上、世界ランク3000位以内になるまでやり込んだ。

ポケモンユナイトの魅力

私はこれまでスプラトゥーンでエイムができず、スマブラで小ジャンプが安定しなかったりして初心者帯で負けまくって挫折するくらいアクシャン操作が下手なのだけれど、ポケモンユナイトはボタン操作が簡単な上に、攻略情報の理解度や状況判断の方がよりクリティカルなので、アクション操作が下手でも結果を出すことができた。この手の大規模な対人対戦ゲームで上位層でプレイできた経験がないのでなかなかの達成感がある。

私はポケモンユナイトの派生元の『League of Legends』も数年前に遊んでいてかなり楽しめたけれど、

• 1ゲームの時間が長い
• チャットで英語で罵倒される

これらの要素がしんどいなと思って挫折してしまった。ポケモンユナイトはゲーム時間が短く、任意のテキストを打てるチャット機能も存在しないので、気軽に遊べる印象だ。

マスターになるまでにやったこと

このゲーム、「アクティブポイント」というランクが上がる方向に補正がかかる仕組みがあるのと、ランクマッチで一定数連敗すると「Bot戦」と呼ばれるCPU相手の試合が挟まりほぼ確実に勝たせて貰えるという謎の仕様があるので、最上位のマスターランクになるのはそこまで難しくない。

ただ、私は元々アクション操作が不得手なこともあって、ハイパーランクからエリートランクにかけて全然勝てなくなって相当苦しんだ中、下記のポイントを意識して試合数をこなしたらどんどん上手くなってマスターになることができた。

YouTubeで攻略情報を研究する

ポケモンユナイトは比較的高頻度にアップデートがあり、ゲームバランスが大きく変化するので、最新の攻略情報にキャッチアップするにはYouTubeを観るのがお手軽だ。

私はこの方たちの動画を観ている。

複数ポケモンを使えるようにする

このゲームのポケモンにはそれぞれレーンアタッカーやジャングラー、ディフェンス、サポートなどの得意な役割があり、この役割のバランスが良くなるようにチームを組むのが勝率を上げるために非常に重要になって来る。例えば記事執筆時点での環境で言うと

• 上レーン：カビゴン、アローラキュウコン
• 中央：ゲッコウガ
• 下レーン：プクリン、ルカリオ

このようなチーム構成が非常に強く、ソロでこれに近い構成で組めた時点で勝率がかなり高くなる。現環境のソロで言うと

• ディフェンス／サポートのポケモンが2枚欲しい
• ルカリオやアローラキュウコンのように、最序盤から強いポケモンが勝ちやすい

この辺りの傾向があるかと思う。

ソロだとランダムに集まった味方が各々好きなポケモンを選んでチーム構成が崩壊することが多いので、自分が2〜3キャラ使えるようにして状況に応じて選ぶポケモンを変えるのが勝率を上げる近道だろう。キャラ選択画面ではまず一番自信のあるポケモンにカーソルを合わせて、チーム構成が悪そうだったら別役割のサブのポケモンに切り替えると良いだろう。私の体感だと、一定以上の試合数をこなして勝率を55％以上出せるポケモンについてはかなり得意と言って良い気がする。

自分の行動の良かった点、悪かった点を意識して振り返る

ゲームの理解度が上がってくると、自分の今の行動は勝ちに貢献したなとか、逆に負けを引き寄せたなということが分かるようになって来る。チーム全体への貢献を意識しつつ、自分の行動を客観的に振り返って次戦以降の立ち回りの改善につなげると上達が早くなる。

通信環境を見直す

Nintendo Switch本体専用 有線LANアダプター【ドック不要】

私は当初普通にWiFiでプレイしていて通信が安定せず、操作不能になる時間帯があったりしてつらかったけれど、有線LANアダプターを購入して有線接続するようにして、フレームレートの設定を「高」に変えたら快適にプレイできるようになった。

フレンドマッチやってくれる方、募集してます！

このゲーム、一人でやるより友達とチームを組んで遊んだ方がやっぱり楽しい。Twitterのフォロワーなどでユナイトをやっている方がかなり少ない印象があるけれど、もし音声通話しながら私とユナイトやっても良いよっていう方がいたらぜひお声がけいただきたい。

私の使用キャラは自信がある順番にワタシラガ、ウッウ、アローラキュウコン、ゲッコウガなので、どのポジションでも入れると思う。特に勝ち負けにはこだわっていないので、上手くても上手くなくても大丈夫で、ランクマッチとスタンダードバトルもどちらでも歓迎だ。

コーディング不要で決済を導入できるStripe Payment Linksを使って個人サービスに寄付機能を追加してみた

赤字を垂れ流し続けるUtakata

3年間運用している個人サービスの短歌投稿サイトUtakataの運用費が毎月約2000円（Heroku毎月16$*1 + お名前.comドメイン維持費毎年約3000円）発生しているのだけれど、収益化の目処がまったく立っていない。

去年の12月から運用していたバナー広告を廃止しました。最低引き落とし金額に達せず、広告で発生した収益は0円という結果になります😂試運用の結果バナー広告はまったく無意味に利便性を下げるだけと判断し、廃止としました。

— Utakata (@utakatanka) 2021年6月1日

一時期試験導入していたnendのバナー広告はほとんどクリックされず最低引き落とし可能額の3000円に到達できなかった。

Stripe Payment Linksのリリースを知る

そんな中、コーディング不要で決済機能を導入できるStripe Payment Linksが最近リリースされていたことを知り、これを使って寄付機能を追加してみることにした。

Stripeアカウント登録

必要情報と本人確認書類を写真でアップして簡単にアカウント登録が完了した。

Payment Links作成

こちらのドキュメントに記載の方法で簡単に支払い用リンクを作ることができた。

ブランディング設定

ブランディング設定でアイコンや色の調整も可能で、サービスのサイトから遷移しても違和感の少ないリンクを作ることができた。

Utakataへの寄付のお願い

こちらのページに寄付のお願いの詳細を記載したので、ぜひご支援いただきたい。

*1:Hobby Dyno 7$ + PostgreSQL Hobby Basic 9$

『ENDER LILIES』 ―骨のある難易度だがアクション操作が苦手でも楽しめるシンプルなアクションRPG―

最近Switchで発売されたアクションRPG（メトロイドヴァニア）の『ENDER LILIES』をCエンドまでクリアして非常に楽しめたのでレビューを書きたい。

グラフィックと音楽の没入感がすごい

『ENDER LILIES』はTrailerのグラフィックが魅力的でやってみたくなったのだけれど、実際にプレイしてみてもグラフィックが美麗で敵キャラ含めたキャラデザも秀逸で世界観に浸れる作りだった。

また、Miliが制作しているゲーム内音楽も非常に完成度が高く、作品の世界観にもマッチしている。特にボス戦ではピアノを基調とした臨場感のある音楽が流れて来て手に汗握る戦いの緊張感を高めてくれる。

骨のある難易度だがアクションゲーム初心者にも優しい工夫がある

私は普段はSLGをメインにプレイしていてアクションゲームはあまりやらず、特に反射神経を活かした操作が苦手で、スマブラやスプラトゥーンで全然上手くならずに挫折したりとかアクションゲーム全般に苦手意識もあるくらいだ。そんな私でも『ENDER LILIES』は下記のような工夫もあって問題なく楽しむことができ、かつヌルゲーという訳ではなく困難な戦闘を試行錯誤して攻略する達成感も味わえた。

シンプルで快適な操作性

2段ジャンプと無敵付与で回避できるダッシュ、ジャストディフェンス（パリィ）の基本操作に加えて1ボタンで発動する各攻撃スキルがあるシンプルな操作性で、キャンセルや先行入力などもゆるく設計されているので、ボタンを押すタイミングとか複雑なコマンド操作でキャラクターが思うように動かないということがなく、やりたいことと実際のキャラクターの動きを一致させるのが容易だった。

プレイスタイルに合わせて選べる多彩な攻撃スキル

ボスを倒すと増えて最終的に26種類にも及ぶ攻撃スキルを、3種類ずつ切替可能な2セット最大6種類セーブポイントで選択して進行するシステムになっている。この攻撃スキルが近接、対空、遠距離、突進、設置、ジャストディフェンスからの反撃やオート攻撃の使い魔など多彩に揃っていて、各自のプレイスタイルやステージとの相性に合わせて選べるようになっている。また、主人公のリリィは攻撃せず、ジョジョのスタンドのように倒したボスが味方となって攻撃するモーションが格好良い。

他の人のプレイ動画を見ると、アクション操作が得意な人は近接やジャストディフェンス系のスキルを好む傾向がありそうだけれど、私は遠距離や使い魔系のスキルをメインに攻略していた。どのスキルも高性能なので、便利な使い途を発見する楽しみもある。

デスペナなしで安心して死に覚えできる

難易度は高めだけれど、死んでもデスペナなくセーブポイントに戻るだけなので安心してトライ&エラーできる。また、セーブポイントで休まなければマップで倒した敵が再度出現することはないので、敵を全部倒してから落ち着いてマップ探索をすることもできる作りになっている。

ボスの行動には一定の規則性があり高度な反射神経は要求されない

各ボスはド派手な攻撃モーションを持っていて、初見での難易度は非常に高く感じられるけれど、何度もトライしていると行動の法則性が見えて、安全に攻撃できるタイミングがつかめるようになっている。

通常の雑魚敵も非常に攻撃力が高い設計になっているので、各敵キャラの攻撃パターンをつかむのがこのゲームの醍醐味の一つだ。

シナリオが更に良ければ…

このように素晴らしいゲーム体験だったけれど、シナリオについては若干の不満点があった。Cエンドまでクリアして達成感と余韻のあるシナリオで、決して完成度は低くないのだけれど、キャラクターが皆「アンニュイな良い人」的なノリで、キャラクターごとの個性付けが十分でないように感じた。グラフィックや音楽に加えてシナリオの完成度が更に高ければより圧倒的な感動を味わえたのではと、贅沢な要求ではあるけれど感じてしまうところがあった。

参考になる攻略サイト

メトロイドヴァニアなのでマップ探索も主要な要素だけれど、この手のゲームに慣れていないとなかなか難しくサクサク進めない印象があったので、私は攻略サイトを積極的に見ながらプレイした。

この2つのサイトを参考にすればマップ要素をコンプリートできるだろう。

おすすめスキル

最後に私の個人的なおすすめスキルを書きたい。

黒衣の騎士

初期スキルながら強力な近接スキル。隙が少なく小回りが利き、2撃目以降上方向にも攻撃判定があり使い勝手が良い。こだわりがなければ近接はこれだけでまったく問題ない。

専用強化アイテムの「古き魂の残滓」の入手方法は上のページを見ればバッチリだ。

黒の魔女イレイェン

射程の長い飛び道具でホーミング効果もあり使用可能回数も多めと非常に使い勝手の良いスキル。敵の攻撃範囲外から一方的に攻撃できるシーンが非常に多い。私の場合このスキルで倒した敵の数が圧倒的に多いと思う。

花の魔女

上方向の判定が強く対空として使え、吹き飛ばしてスタンさせる効果もあり強力。ラスボスとの相性も良いので、最後まで強化しても活用できる。

西の商人

使い魔のカラスで、発動すればずっとリリィの近くを飛んで自動で遠距離攻撃してくれるので、回避操作に専念しながら攻撃できる。特にシビアな回避操作を要求されるボス戦では助かる。

城下の娘

使い魔の犬で、遠距離のカラスと対照的に近接で攻撃する。足場の下に敵がいる場合に、犬だけ降ろして一方的に攻撃する使い方もできる。また、スキルを2枠使ってしまうけれど、カラスと同時に発動しても強い。