たばりばりスタイル

「100話で心折れるスタートアップ」を読んだ

界隈 (?) で話題になっていた Twitter 連載マンガが電子書籍としてまとめられていたので、読んでみました。

4 コマ漫画形式の本で、タイトル通り 100 話で心が折れるスタートアップの話なのですが、内容がすごくリアルな感じで面白く、テンポも良くて読みやすく、好みの話でした。

絵柄はかわいらしくポップな雰囲気ですが、内容はかなりリアルな感じがします。界隈の雰囲気を知れた気分です。

実際にスタートアップを起こす、または働くことになった場合に読み物としてどこまで参考にしていいものか判断できませんでしたが、ピボットの流れ、市場調査、資金調達、メンバー集め、に関しての漠然なイメージ感を持てて楽しめました。

スタートアップ、もし自分が実際に当事者になると胃がキリキリして毎晩眠れなくなりそうと思う反面、スリルがあって楽しそうだなと憧れも湧きました。 僕は今年で社会人 6 年目、仕事に慣れ始め、結婚もして、生活基盤が安定してきた "今" から全振りでこういったチャレンジへは踏み出せませんが、小さい時間からチャレンジしてみたいなと思いました。

RailsでControllerに標準のCRUDなアクション以外生やしたくない

ここでいう標準な CRUD とは下記のアクション群 (scaffold で生成されるアクション)

  • index
  • show
  • new
  • edit
  • create
  • update
  • destroy

標準のCRUDなアクション以外生やし始めると、徐々にコントローラがカオス化する気がしませんか?

生やしたい派の意見としては共通ロジックをコントローラで使いまわせる、ルーティングからコードの配置がわかりやすい (?)、などなど

でも生やした結果、最終的にコントローラがカオス化してるケースを何件も見てきました。。。 (アクションが数十個、全体で数百行に成長したコントローラ。。。

個人的には、よくある検索用の search や完了ページ的な finish (complite) みたいなアクションでさえ別コントローラに切り出すでよくないかと思ってしまう。それくらい強いルールがあったほうが秩序が保たれるんじゃないかと。。。

実際のイメージですが、Tweet (つぶやき) 用のコントローラを用意したい場合で考えてみます。

class TweetsController
  # GET /tweets
  def index # 一覧ページ
  end

  # GET /tweets/new
  def new #  投稿ページ
  end

  # POST /tweets
  def create # 投稿処理
  end

  # GET /tweets/search
  def search # 検索用ページ
  end

  # GET /tweets/finish
  def  finish # 投稿完了用ページ
  end
end

このコントローラを

class TweetsController
  # GET /tweets
  def index # 一覧ページ
  end

  # GET /tweets/new
  def new #  投稿ページ
  end

  # POST /tweets
  def create # 投稿処理
  end
end

class Tweet::SearchesController
  # GET /tweet/search
  def show # show なのは単一ルーティングで表現を想定しているため
  end
end

class Tweet::FinishesController
  # GET /tweet/finish or /tweets/:id/finish
  def show # show なのは単一ルーティングで表現を想定しているため
  end
end

# routes.rb
Rails.application.routes.draw do
  resources :tweets, only: [:index, :new, :create] do
    scope module: :tweet do
      resource :finish, only: :show
    end
  end

  namespace :tweet do
    resource :search, only: :show
  end
end

このような形で実装する。 上記 routes.rb の記述で作成されるルーティングは下記。

Helper Path Controller#Action
tweet_finish_path GET /tweets/:tweet_id/finish(.:format) tweet/finishes#show
tweets_path GET /tweets(.:format) tweets#index
POST /tweets(.:format) tweets#create
new_tweet_path GET /tweets/new(.:format) tweets#new
tweet_search_path GET /tweet/search(.:format) tweet/searches#show

こういう感じで routes.rb で resource(s) ベースでコントローラを作ることをルール化すれば、標準 CRUD なアクションのみ対応でき、実装に統一感もでます。標準 CRUD なアクションのみになるので、7 つ以上のルーティングをひとつのコントローラで制御することがなくなり、シンプルになると思います。

また、コントローラを分割することで、分割されたコントローラ間で利用したい共通ロジックが出てくる場合もあると思います。そうなると、外 (例えば Concern など) に切り出す必要がでるため、コントローラのコード量が減りさらに薄くなります。

外に切り出しやコントローラの分割でファイル数自体は増えるでしょうが、ルーティングの生成されるパスからファイルも推測しやすいですし、大きな問題ではないと思います。

正直コントローラは薄ければ薄いほど嬉しいと思っていて、アクションが数十個、全体で数百行あるようなコントローラは読んでられません。ただでさえ Fat 化させやすいレイヤーだと思うので、個人的には厳しいルールで縛ってなるべく全体の見通しがよくしたいなと思っています。

Rubocop でそういう cop は現時点で存在しないようなので、時間があるときにカスタム cop を作れたらいいなと思っています。

以上です。

Redux Toolkitでグローバルで状態管理できるLoadingを用意する

個人開発で Redux Toolkit を導入したのでそのメモ。

redux-toolkit.js.org

これまで Redux を使った開発経験はあるものの、直近だとあまり触る機会がありませんでした。
しばらく触らない期間があると実装についてど忘れしてしまい、その度にググって試行錯誤しちゃうので、今回はそうならないよう、シンプルに実装できる Loading の管理するコードを残し、未来の自分のための備忘録として残したいと思います。

Slice

まずは Action Creator、Reducer 関数をエクスポートするために loading 用の Slice を用意する。

// features/loading/loadingSlice.ts

import { createSlice } from "@reduxjs/toolkit";
import type { PayloadAction } from "@reduxjs/toolkit";

type LoadingState = {
  shown: boolean;
  message: string;
};

const initialState: LoadingState = {
  message: "",
  shown: false,
};

export const loadingSlice = createSlice({
  name: "loading",
  initialState,
  reducers: {
    setLoading: (state, action: PayloadAction<{ message: string }>) => {
      state.shown = true;
      state.message = action.payload.message;
    },
    resetLoading: (state) => {
      state.shown = false;
      state.message = "";
    },
  },
});

export const { setLoading, resetLoading } = loadingSlice.actions;
export default loadingSlice.reducer;
Store

reducer をまとめる store のコード。
Basic Reducer Structure | Redux を参考に ui に関する reducer をまとめる。

import { configureStore, combineReducers } from "@reduxjs/toolkit";
import loadingReducer from "@/features/loading/loadingSlice";

const store = configureStore({
  reducer: {
    ui: combineReducers({
      loading: loadingReducer,
    }),
  },
});

export type RootState = ReturnType<typeof store.getState>;

状態をコンポーネント間で管理できるように、store でラップするコード (Next.js 例)

import React from "react";
import { Provider } from "react-redux";
import { store } from "@/store";

function MyApp({ Component, pageProps }) {
  return (
    <Provider store={store}>
      <Component {...pageProps} />
    </Provider>
  );
}
Component

Loading のコンポーネント。(TailwindCSS を利用した例).

Tailwind CSS Spinner - Flowbite

// features/loading/Loading.tsx

import React from "react";
import { useSelector } from "react-redux";
import type { RootState } from "../../pages/_app";

const Loading = () => {
  const { shown, message } = useSelector((state: RootState) => state.ui.loading);

  if (!shown) {
    return <></>;
  }

  return (
    <div role="status">
      <svg aria-hidden="true" className="mr-2 w-8 h-8 text-gray-200 animate-spin dark:text-gray-600 fill-blue-600" viewBox="0 0 100 101" fill="none" xmlns="http://www.w3.org/2000/svg">
        <path d="M100 50.5908C100 78.2051 77.6142 100.591 50 100.591C22.3858 100.591 0 78.2051 0 50.5908C0 22.9766 22.3858 0.59082 50 0.59082C77.6142 0.59082 100 22.9766 100 50.5908ZM9.08144 50.5908C9.08144 73.1895 27.4013 91.5094 50 91.5094C72.5987 91.5094 90.9186 73.1895 90.9186 50.5908C90.9186 27.9921 72.5987 9.67226 50 9.67226C27.4013 9.67226 9.08144 27.9921 9.08144 50.5908Z" fill="currentColor"/>
        <path d="M93.9676 39.0409C96.393 38.4038 97.8624 35.9116 97.0079 33.5539C95.2932 28.8227 92.871 24.3692 89.8167 20.348C85.8452 15.1192 80.8826 10.7238 75.2124 7.41289C69.5422 4.10194 63.2754 1.94025 56.7698 1.05124C51.7666 0.367541 46.6976 0.446843 41.7345 1.27873C39.2613 1.69328 37.813 4.19778 38.4501 6.62326C39.0873 9.04874 41.5694 10.4717 44.0505 10.1071C47.8511 9.54855 51.7191 9.52689 55.5402 10.0491C60.8642 10.7766 65.9928 12.5457 70.6331 15.2552C75.2735 17.9648 79.3347 21.5619 82.5849 25.841C84.9175 28.9121 86.7997 32.2913 88.1811 35.8758C89.083 38.2158 91.5421 39.6781 93.9676 39.0409Z" fill="currentFill"/>
      </svg>
      <span className="sr-only">{message}</span>
    </div>
  );
};

export default Loading;

コンポーネントで表示制御できるように、コードを追加 (Next.js 例)

import Loading from "@/features/loading/Loading";

function MyApp({ Component, pageProps }: any) {
  return (
    <Provider store={store}>
      <Component {...pageProps} />

      <Loading />
    </Provider>
  );
}

実際に Loading を表示制御を行う呼び出し元コンポーネントからは dispatch で呼び出す。

import React, { useEffect } from "react";
import { useDispatch } from "react-redux";
import { setLoading, resetLoading } from "@/features/loading/loadingSlice";

// 省略
const MyComponent = (props: { text: string }) => {
  const dispatch = useDispatch();

  useEffect(() => {
    // Loading を表示
    dispatch(setLoading({ message: "読み込んでいます。" }));

    setTimeout(() => {  // 何か処理がある想定
      // Loading を非表示
      dispatch(resetLoading());
    }, 1000);
  }, []);

  return <h1>Hello MyComponent !</h1>;
};

export default MyComponent;
以上

これだけでグローバルで状態管理できる Loading を用意できます。
Redux Toolkit を使うとコアになるコードを Slice にまとめられるのでコードの見通しが良くなります。

このシンプルな実装でも応用も効きやすく、よく使えそうな事例だと思うので、今後も Redux Toolkit を使うタイミングで見返したいと思います。

以上です。

フリーランスエンジニア(準委任)の直契約時の単価アップ交渉方法について

僕はここ2年弱、エージェントを使わずに (仲介を挟まずに) 案件を探し、直接商談・契約を結んできました。

その案件獲得方法については以前書いているのでこちらを見ていただけたらと思います。

実際に案件に参画していると、単価を上げたくなるシーンがあると思います。おそらく正社員だと決まった期間で査定のイベントがあり、自ら動かなくても昇給が検討されるケースが多いでしょう。フリーランスはそういったイベントがないため、基本的には自らアクションを起こす必要があります。

もしエージェントを使っているならエージェントに話すことで契約先企業と調整してくれるものだと思いますが、エージェントを使っていない場合は自分で契約先企業へアクションを起こし、その調整を行う必要があります。

今回は僕がどのようにして単価アップ交渉を行っているかをかんたんにまとめたいと思います。

単価アップ交渉をする方法

おそらくメールを使って行うのが一般的なのではないかと思っています。*1

かんたんな流れとしては下記のようになるのではないでしょうか。

  1. 新しい希望単価を考える
  2. 単価をあげてもらう材料を揃える
  3. メールで単価アップを希望する旨を伝える (材料と新しい希望単価も提示)
  4. 契約先企業がその単価で問題なければ、新しい条件で更新する

新しい希望単価については自由な部分ではあると思いますが、相手企業への誠意も持ちつつ考えるのがいいのかと思います。例えば一般的な単価感からかなり逸脱した希望単価を求めるなど、関係性が悪くなりそうなことは当たり前ですが避けた方がいいと思います。

単価をあげてもらう材料について、僕の場合は実際のエピソードなどの具体例をもとに、チームへ貢献できている話、業務に活きる新しい知見が増えた話、を揃えます。 個人的には、新規プロジェクトや機能をリリースしたり、業務内外で新しく技術やドメイン知識を得られたタイミングは、単価交渉の材料が探しやすいタイミングだと思います。逆に参画して浅く何もできていない、特に新しい知見が身につかない状況だと材料探しには困難しそうです。

単価交渉の材料、希望単価が決まれば、いよいよメールで単価アップを希望する旨を伝えます。 文面については各自の案件の内容によって大きく左右される部分だと思うので、具体的な例は避けたいと思います。内容については簡潔にまとめつつ、申し訳ないがお願いしたいと言ったニュアンスで送っています。

メールをもとに契約先企業は確認を行い、問題がなければ新しい条件で更新することになるでしょう。 ただ、条件の更新が難しいケースもあります。または単価は上げるが、他の条件を変えたいというようなケースもあります。思うような条件で更新できなくとも、既存の条件で参画を続けることもありますし、ここで次回から更新しないという方もいるでしょう。ただどのようなケースでも誠意だけは持って対応すべきだと思います。*2

今回は駆け足ですが、単価アップ交渉方法についてまとめてみました。同じくエージェントを使っていない誰かの役に立てると嬉しいです。

以上です。

*1:やりとりが文面で残っている方がなにかと便利ですよね

*2:業界は狭いので回り回ってどこかで関わることもあるはず

「創業の手引」を読んだ

起業の科学という本を読んでいて、スモールビジネスとスタートアップの違いについて知りました。

今僕がやっているクライアントワーク (業務委託) はスモールビジネスに入りますが、漠然といつかやりたいなぁと思っている事業内容はスタートアップ寄りでした。恥ずかしなら知らずに起業してました。

改めて今後どうしたいかを考える上で、創業の手引を読みました。
日本政策金融公庫が公表している有難いガイドブック。

創業の手引

起業前の話も多いですが、創業計画やビジネスプランの作り方の話は参考になりました。

最近は行政手続きも終えて落ち着いてきたので、時間をとって事業内容を考えてみたいと思います。

合わせて読みたいと思ってる書籍。

会社で営業やっていき!

4/1 に会社を設立して約3ヶ月が経ちましたが、特に会社名義での営業活動はしていませんでした。というのも法人成りで特に事業内容が変わらないため、個人名義で契約した現案件を引き継ぐために、契約満了を待っていたからです。

そしていよいよ個人名義の契約が今月で切れるため、来月から法人名義で営業開始できることになりました👏

再契約みたいな形だったと思うのですが、僕自身は特にやることはなく、契約先に委託関連の契約書類を再度用意してもらい、僕はそれに署名・合意しただけです。*1

顧問税理士との契約の話も進んでいるので、いよいよ会社での営業をやっていき!の気持ちでいます! とはいっても、まずは個人事業の延長といったゆるい感じですが。。

ゆくゆくは経理処理の完全外注、業務委託以外でのビジネスモデル確立を目標に進めていきたいと思います。

(最近ブログ書く気力がない。。。)

以上です。

*1:押印が自社名なのは少し恥ずかしい...まあ押印といっても電子なので印鑑押したわけじゃないですが...

オライリーEbook Storeで買った電子版をKindle iOSアプリに送る方法

オライリー Ebook Store で買った電子版を Kindle iOS アプリに送る方法。備忘録。

事前準備

Kindle Previewer をインストール

$ brew install --cask kindle-previewer
Kindle iOS アプリに送る
  1. オライリーのマイページ から対象書籍の ePub をダウンロード
  2. Kindle Previewer で ePub ファイルを開く (D&D する)
  3. Kindle Previewer のメニューから、ファイル >> エクスポート >> mobi でエクスポートを選択
  4. mobi ファイルが作成される
  5. Amazon から Send-to-Kindle Eメールアドレスを確認
  6. コンテンツと端末の管理 >> 設定 >> パーソナル・ドキュメント設定 >> Send-to-Kindle Eメールアドレスの設定
  7. E-Mail が複数ある場合は Kindle iOS アプリの設定から、対象の SEND-TO-KINDLE Eメールアドレスが確認できる
  8. Send-to-Kindle Eメールアドレスのアドレスを宛先としてメールを作成し、mobi ファイルを添付して送信