転職活動を始めようとしたとき、最初に詰まったのは「何を基準に選ぶか」でした。
「フルリモートがいい」「スキルが積み上がる仕事をしたい」「年収も気になる」——条件はいくつかあるけど、どれが一番大事なのか、最初はちゃんと整理できていなかった。そのまま動き始めると、軸のない応募を繰り返すことになります。
転職エージェントや動画を参考にしながら、まず条件を全部書き出して、優先順位をつけることにしました。そこで使ったのが、MoSCoW法という整理の枠組みでした。
MoSCoW法とは
MoSCoW法は、本来ソフトウェア開発の要件整理に使われる手法です。要件を4つに分類します。
- Must（絶対に必要）: これがないと機能しない
- Should（あった方がいい）: 重要だが、なくても成立する
- Could（あれば嬉しい）: 余裕があれば対応したい
- Won't（今回はやらない）: 今回のスコープ外
これを転職条件に当てはめました。
私のMoSCoW整理
Must（絶対に譲れない）
フルリモート・フレックス・副業OK・残業10時間以下、この4つがMustです。
一番の理由はワークライフバランスでした。猫の凜ちゃんとそばにいたい、何かあったときに両親のそばにすぐ行ける状態でいたい。そのためにフルリモートは外せない。フレックスはコアタイムなしか最小限。副業OKはブログや個人開発を続けるために必須。残業10時間以下は、プライベートの時間を守るための上限として決めていました。
この4つを満たさない会社には、どんなに他の条件が良くても応募しないと決めました。ここがブレると、軸が意味をなさなくなります。
Should（あった方がいい）
フルスタックで関われる環境、モダンな技術スタック、スキルが積み上がる仕事内容。
前職ではバックエンド専任で、フロントエンドは別会社が担当していました。サービス全体に関われない、顧客から遠いという感覚がずっとあった。バックエンドからフロントエンド・インフラまで、設計から運用まで自分たちで回せる環境が理想でした。
この条件はMustに近い優先度でしたが、フルリモートほど絶対ではないと判断してShouldに置きました。
年収は3番目の優先項目でした。「フルリモートが実現できるなら、多少下がってもいい」という感覚で、積極的に上げたいというより、大きく下がらなければOKという位置づけです。現状維持が目安でしたが、MustのWLB条件が揃うなら許容ラインは広めに設定していました。
Could（あれば嬉しい）
職場の雰囲気が悪くない、やりがいを感じられる仕事内容。
職場の雰囲気は悪いより良い方がいいに決まっているので一応入れましたが、ここで選ぶことはほぼありませんでした。やりがいも同様で、プリンタには全然興味がなかったけれど、「使う人の何かに貢献できるなら」という程度。Must・Shouldが揃っていればCould以下は後からついてくると思っていました。
Won't（今回はやらない）
業界知名度・ブランド名、大企業・上場企業かどうか、役職・マネジメントへの昇進機会。
これらは「捨てる条件」です。有名な会社に行きたいとか、マネジャーになりたいという気持ちは特になかった。業界もウェブ開発ができればどこでもいいと思っていたので、ここは最初から気にしないと決めました。
「避けたい未来」も書いた
軸を固めるためにもう一つやったこととして、「10年後になっていたら嫌な状態」を書き出しました。
- 凜ちゃんが高齢で病気がちなのに、会社に行かなければいけなくてそばにいられない
- スキルが無成長のまま（まだRubyだけやってる、など）
- 毎日通勤している
- 無駄な会議や特許申請に追われている
- 興味のないプリンタ業界にいる
この「嫌な未来リスト」を書くと、Mustで外せないものが自然と浮かび上がってきます。「避けたいこと」から逆算するのは、「欲しいもの」を直接考えるより整理しやすかったです。
数値化してNGラインを決める
MoSCoWで分類した後、条件を数値で表せるものは数値化しました。
- 残業: 月12時間以下（NGライン）
- 出張: 少なめ・転勤なし
- 副業: OK必須
- 年収: 現状維持を目安、大幅ダウンはNG
評価は会社ごとに二重丸・丸・三角・バツで表にして並べていきました。数値が出せるものは数値で、そうでないものは印で揃えると、複数社を並べて比較しやすくなります。
曖昧な「なんとなくいい会社」ではなく、比較可能な評価にする。これで、複数内定が出たときに感情だけで選ばないようにできました。
実際に最終盤で作った比較表はこんな感じです。
| 比較項目 | A社（内定・第一志望） | B社（内定・対抗候補） | 前職 |
|---|---|---|---|
| ① WLB（MUST） | ◎ フルリモ・フルフレ | ◎（実態確認によりほぼ差なし） | ○（実態は◎寄り） |
| 勤務時間・中抜け | コアタイムなし・柔軟性◎ | コアタイムあり・周知で中抜け◎ | 通常勤務（フルフレックス） |
| 残業実態 | 少なめ（要確認） | 月8〜10h程度 | ほぼ0時間 |
| ② スキル成長（SHOULD） | ◎ 基盤の深さ＋フルサイクル | ◎ プロダクト全体のフルサイクル | △ 守り・改善中心 |
| 担当領域 | 共通基盤・API開発 | バックエンド〜フロント連携 | バックエンド〜インフラ |
| フロントエンド機会 | ありうるが比重は低めの可能性 | 明確にある | 限定的 |
| フルサイクル性 | ○〜◎ QA・運用含め一気通貫 | ◎ 顧客体験の設計から運用まで | △ 顧客距離は遠い |
| 技術スタック | サーバーサイド中心、SaaS横断 | モダンなフルスタック構成 | Ruby/Rails/TS/AWS |
| ③ 年収（SHOULD） | 現状より低め | 現状より大幅に高め | 現状 |
WLBとスキル成長の2軸はA社・B社でほぼ互角でした。最後まで迷ったのは年収の差で、これがIF-THENルールを厳密に決めておけばよかったと感じた部分です。
IF-THENルールを作っておく
もう一つ有効だったのは、事前にIF-THENルールを決めておくことです。
- 「もし出社が月1回以上なら → 見送る」
- 「もし副業禁止なら → Mustを満たさないので落とす」
- 「もし年収が現状より大幅に下がるなら → Should評価でカバーできるかを確認する」
実際、最後まで2社で悩んだとき（HR SaaSか医療系SaaSか）、年収差が想定より大きくて迷いました。IF-THENルールをもっと厳密に作っておけば、もう少し早く決断できたかもしれません。それだけ、事前ルールは意思決定時に効いてきます。
面接中や内定後に感情が動いたときでも、このルールがあると「いや、ここは外せない」と立ち返れます。
軸を整理してから動いた方がよかった理由
転職活動を始めてから軸を考えるのではなく、最初に整理しておく方が圧倒的に効率がいいです。
理由は3つあります。
- 応募先を絞れる: Must未満の会社に時間を使わなくなる。エージェントに「このリストにない求人は出さなくていい」と言える
- エージェントへの説明が簡単になる: 「フルリモート必須・副業OKが必須です」と言えば、合う求人だけ紹介してもらえる
- 内定後に迷いにくくなる: 基準があるので、感情ではなく条件で比較できる
エージェントに「どんな会社を探していますか？」と聞かれたとき、MoSCoWで整理した内容をそのまま話したら「それだけ明確なら絞りやすい」と言われました。軸がある人の方が、エージェントも動きやすいようです。
転職軸の整理まとめ
転職軸をMoSCoW法で整理する手順をまとめると、こうです。
- 転職に求める条件を全部書き出す（付箋感覚でOK）
- 「避けたい未来」も書き出して、外せない条件を逆算する
- Must・Should・Could・Won'tに分類する
- 数値化できるものはNGラインを数値で決める
- IF-THENの意思決定ルールを作っておく
軸を言語化してから動くと、応募・面接・内定後の意思決定、全部が楽になります。「何が大事か分からない」という状態で始めると、選考が進むほど迷子になります。
まず15分、「絶対に譲れないもの」と「なっていたら嫌な未来」を3つずつ書いてみてください。そこから全部始まります。
この記事は2026年4月時点の情報を元に執筆しています。