IT系の最新情報のキャッチアップには「はてなブックマーク」を使うと便利

はてな

Web系エンジニアとして働いていて、基礎的な部分の技術理解度が何よりも大事と感じているけれど、その一方で、最新の動向に詳しいのも一定強みになる印象だ。というのも、日常的に最新の技術動向をチェックするということをやっていないエンジニアの方が多く、毎日少しずつチェックするということをやっているだけでトレンドに対する理解度に差が出て来る。

この最新情報にキャッチアップするためのツールとして、私ははてなブックマークが圧倒的にお手軽かつ、目的に応じて柔軟に活用できると感じているため、その活用方法を紹介したい。

はてなブックマークでの情報収集方法

その方法は非常にシンプルで、ただ「タグ検索」をするだけだ。例えば上のリンク先では「JavaScript」のタグ検索で、50ブクマ以上されているエントリが、新着順に表示される。JavaScriptやフロントエンドについて、有益なエントリが表示されていることが分かるだろう。

この検索パラメーター付きのURLをブラウザのブックマークに登録しておいて、毎日朝にチェックして、未クリックの色になっているリンクをクリックして未読記事を読むだけで良い。

私はこれらのタグをチェックしている。自分の興味に応じて、ウォッチするタグを任意に調整すると捗る。

ブックマークコメントがあることのありがたさ

はてブコメントと言うと、一般には、人様の記事にワラワラと集まって来てタイトルだけ読んで罵倒するという、有害なイメージがあるけれど、ことITに関しては本職のユーザーが多いため、ソーシャルブックマーク本来の集合知として、現在でも真っ当に機能している。

技術情報の記事を全部ちゃんと読むのはなかなかにしんどいけれど、ブックマークコメントがあることによって、まずコメントを読んで概要をつかんでから、興味のある記事だけ精読するということができるようになる。また、コメント自体に有益な視点や情報が書かれていることも多い。

おわりに

昔ははてなブックマークのトレンドに上がっている技術記事が何のことを書いているのかサッパリ分からないことが多かったけれど、実務経験を積むにつれて、内容を理解できる記事が多くなって来るのは嬉しい。

主にユーザーの治安の悪さについて、残念な部分も多いはてなブックマークだけれど、無料で使える完成度の高いソーシャルブックマークサービスという側面については、他にない特別な価値があると、日々使っていて感じている。

ライスさんの「からかい」批判を読んだ感想

雑記

ライスさんの記事を読んで、真っ当な批判で、支持できると思った。

その一方で、一般論として、こういった不誠実な議論を展開する論客や、その支持者に抗議することはなかなか難しいものがある。

まず、記事中でライスさんがされているような、特定界隈の攻撃のターゲットになることは、なかなかに耐え難いストレスを生むだろう。

また、このライスさんの記事に関するTwitterの反応を見れば分かるように、このレベルの事象についても、「どっちもどっち」的な相対化や、「からかい」や「いじめ」などの用語について、記事と無関係な文脈での一点突破の「論破」を試みる人間が多く、このような論客に言及すると、論客本人だけでなく、好き勝手に小理屈を展開する有象無象のユーザーの出現に苛立たしい思いをすることになりそうだ。

そのような中で、

というか、御田寺の行っているような「からかい」行為を許容しないというくらいの良心は、わたしに限らず、誰にでも持っていてほしいものだ。御田寺やその取り巻きの「からかい」行為を見て見ぬ振りをしながら、「御田寺の言論にも耳を傾けるべきところがある」としたり顔で言っている人々に対しては、いじめに参加している人に対して抱くのと同じような軽蔑の気持ちをわたしは抱いている。

ライスさんの記事が、敢えてどうとでも小理屈で反論できそうな、隙のある道徳的言及で締められているのは面白いと思った。こういう言いっぱなしの価値観の表明で実際十分なのだろうなと思う。

RailsでシンプルなREST APIを設計する

Rails

業務のRailsサーバーサイドのAPIリファクタ対応を通して得られた知見について、前回はService Objectについて書いたけれど、今回はREST API周りの手法について書きたい。

全体的にRails wayに沿って、実装者の恣意性による方針のブレを極力排した、見通しの良いリソースベースの設計を実現することを意識している。

REST APIのエンドポイント設計

CRUDの基本アクションの使用を優先し、適宜リソースを分割する

コントローラが元々持っているRESTアクションやデフォルトの5つの機能にはないメソッドを付け加えたいと思ったら、いつだって新しいコントローラを作る。それだけでいいのです。

上の記事でDHHが述べているように、index、show、new、edit、create、update、destroyの基本アクションの利用を優先し、独自アクションの定義を避けることは、リソースベースのエンドポイント設計の方針を明確化し、controllerの処理の見通しを良くする。

その一方で、DBのテーブルと1対1でcontrollerのリソースを定義している場合は、基本アクションのみで現実のビジネス要件に応えることはすぐに難しくなるだろう。DHHは、DBのテーブルとの対応にこだわらずにcontrollerのリソースを分割することで、基本アクションのみで実装できるとしている。

個人的には、厳密に基本アクションだけ使うのがベストかどうかは何とも言えない気がするけれど、DBのテーブルとの1対1にこだわらずにcontrollerのリソース分割を考えて良い、という考え方については、リソース設計の柔軟性がグッと増して視界が開けるような感覚があった。

resourcesメソッドの利用

上の基本アクションの利用と関連して、ルーティングの設定にresourcesメソッドを利用するとroutes.rbの記述がシンプルで見通しが良くなり、かつ実装者の恣意性によってエンドポイント定義のルールの一貫性が損なわれることがない。

resourcesメソッドをネストしてcontrollerを別立てする手法も便利だ。簡単な例で言うと、

このようにroutingを書くと、

Prefix Verb URI Pattern Controller#Action
posts GET /posts(.:format) posts#index
user_posts GET /users/:user_id/posts(.:format) users/posts#index

rails routesで出力される定義がこうなり、

このように、投稿の一覧APIとユーザーに紐づく投稿の一覧のAPIを別のcontrollerで定義できるようになる。

namespaceの分離

上のresourcesメソッドをネストするテクニックと併せて、namespaceメソッドを利用することでも、同じリソースについて完全に分離された複数のエンドポイント定義、controllerの実装を持つことができる。

例えばユーザーアプリケーション向けのAPIと管理画面向けのAPIが同じコードベースで実装されている場合に、管理画面向けのAPIに dashboard namespaceを割り振って、影響範囲を分離した上で別の体系のAPIとして実装する、というような使い方ができる。

Mastodonのroutes.rbを見ると、Railsのroutingの様々な手法が博覧会的に用いられていて参考になる。

総じて、業務でのREST APIの活用を考えると、多重実装的な考え方を許容してでも、文脈ごとにリソースを分けて影響範囲を分離し、個別の要件に柔軟に応えていくような考え方が持続可能な開発につながると感じている。

JSONレスポンスのフォーマットを統一する

業務のリファクタ対象がJSONを返すタイプのAPI（フロントエンドはReact）だったため、JSONレスポンスのフォーマットが実装者依存で無秩序にならないようにするため、下記のような手法を導入してみた。

ActiveModelSerializersを利用する

リファクタ前に使われていたjbuilderのレスポンス定義が規則性のない無秩序状態でつらすぎたので、ActiveModelSerializersを導入してみたところ、当初の予想以上に快適に使えて驚いた。

ActiveModelSerializersは上のサンプル実装例のように、Railsのmodelに対応するserializerを用意して、Railsのmodelと同じようにhas_manyやbelongs_toでアソシエーションを定義できる。このserializerをcontrollerで指定するだけで、モデル間のアソシエーションを含むレスポンスについても、ActiveModelSerializers側で決まったフォーマットで返すことができるようになる。

基本的なユースケースが如何にもスマートに見える一方で、複雑なビジネス要件に対する柔軟性が低いのではないかと気になっていたけれど、実際には

  • 1つのRails modelに対して、複数のserializer classを定義して、任意に使い分けることができる
    • 例えばnamespaceごとに別のserializerにするなど
  • controllerでincludeオプションを指定することで、定義されたアソシエーションのうち、どの範囲をレスポンスに含めるか、エンドポイントごとに任意に指定できる
  • 任意のオプションを作成して、controllerから渡した値を元にプロパティの出し分けを制御したりもできる

など、痒いところに手が届く機能が実装されていて、非常に柔軟に活用できるライブラリだった。

逆に苦手なユースケースとしては、ActiveModelSerializersを使った場合には配列形式のJSONレスポンスの件数が多くなるほどパフォーマンスが悪くなるので、大規模なデータを返す必要がある場合には他の方法を検討した方が良さそうだ。

エラーハンドリングの方式とJSONフォーマットの統一

リファクタ前のプロダクトはサーバーサイドのエラーハンドリングとレスポンスフォーマットの方式がバラバラで、その結果としてフロントエンドでもまともにエラーメッセージの出し分けができていないなど、悲惨な状態だったので、上のような形で、エラーメッセージと、class名を変換したエラーコードを返すシンプルなフォーマットでまずは統一させてみた。

世の中のWebアプリケーションの実装を見ると、Railsでのエラーハンドリングの方法とJSONのエラーレスポンスの返し方には様々な手法がある印象で、別のアプリの設計に携わる機会があればまた改めて深く考えてみたいと感じている。

おわりに

  • リソースを文脈ごとに分割して、見通しの良いエンドポイントを設計する
  • レスポンスフォーマットの決定について、実装者の恣意性によるバラつきを排除できる仕組みを導入する

全体を通して、これらの観点が見えて来たように思う。

リファクタ業務を通じて、RailsでのREST API設計については一定知見のようなものができてきたけれど、REST APIはビジネス要件に柔軟に応えるために、リソースとエンドポイントを分割して個別対応するという、多重実装を許容するようなアプローチを取らざるを得ない点に融通の利かなさを感じる部分はあり、この点でGraphQLの活用が近年注目されているのかなと思ったりもした。GraphQLでのAPI設計にも機会があればぜひ関わってみたいと感じている。

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

Rails

業務の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）におけるサービスレイヤを実装に落とし込む設計手法と言える。

https://www.martinfowler.com/eaaCatalog/ServiceLayerSketch.gif

上の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年あたりに大変な議論になっていたのを何だかよく分からない話題として横目で見ていたけれど、今になって論点が理解できた。