職を変えるべきかを決定するフレームワーク

転職を決定するときはどんなときだろうか。兼ねてから待遇や環境に不満があり、あなたの仕事の批判をする上司や取引先の彼(皮肉屋で一言多い)が発した言葉を引き金に、退職を決意するのではないだろうか。

あの上司に退職メールを送信するのはちょっとだけ待ってほしい。その意思決定はどんな考え方に基づくものだろうか。

あなたが優秀な開発者なら(きっとそうだと思う)、次の雇い主も何なく見つけられるだろう。だが、選択肢を整理してより賢い選択ができるならその方がよい。

転職してあなたの時給を上げる

転職して時給があがるのはとても魅力的だ。時給が3000円から5000円にあがれば、月あたりの報酬507,000円から845,000円に跳ね上がる。年あたりならプラス400万円され1000万を超える。

年あたりプラス400万円の収入増加があれば、あなたの不動産投資はより加速できるし、あなたの愛車や家もより大きなものに変わるかもしれない。

まるで宝くじにあたったような感じだ。

もちろん転職するだけであなたの時給が1.5倍増することはない。下がってしまうこともありうるだろう。あなたの時給を1.5倍にする魔法はない。

しかし、あなたの時給が大きくあがるケースもある。それはあなたとあなたの仕事に対して、今いる企業が出せる予算と次の企業の予算が異なる場合だ。

これはあなたに対する”評価”の仕事ではない(つまり、あなたへの評価が時給を決めているわけではない)。企業にとってあなたの給与は利益を得るための投資で、その投資効率が最もよい地点に金を投じたい。あなたが新しいラップトップや、ランニングシューズを買うときと同じように、企業もあなたに対するコストパフォーマンスを見ているのだ。

ちょっと待ってほしい、時給をあげることが転職の目的か？

元の議論に戻ろう。あなたが転職によって時給をあげたいと考えているが、職を変えるのと時給をあげることは分けて考えた方が良い。

時給はあなたの不満の一つかもしれないが、決定的な不満ではないはずだ。もし時給が決定的な不満なら、条件提示されたときにあなたは断っているか、既に退職をしている。

そしてこの問題は、あなたにとって今の時給以上に向き合って考えた方がよい問題だ。何故ならば、これは未来の時給(もしくは未来の収入源)に関わってくる問題なのだから。

どんな不満がある？

あなたはどんな今の職に不満があるのか。紙いっぱいに書き出してみよう。

• 私が果たしている責任と役割の大きさを上司が理解しない
• 取引先の彼の態度が気にくわない
• 使用している開発言語が旧時代のもの
• 定型的な業務が多い
• 報告書や文書化を多く求められる
• 他部署との折衝に奔走している
• 試験業務ばかりでコードを書かせてもらえない
• 仕事の時間が長すぎる

そして

• 時給が低い

この工程ではとにかくたくさん不満を出した方がよい。同じような不満でも構わない(ここには批判者は誰もいないのだから)。

不満が出揃ったら整理をしよう

不満はあなたに属するか、外部に属するか、またはどちらともに属するか。

例えば、この不満はあなたの外部に属する。あなたの時給やあなたの組織で利用する開発言語は、多くの場合あなたがきめられるものではない。

• 使用している開発言語が前時代のもの
• 時給が低い

またこれ以外にも組織の決まりごとや文化に起因する不満に対して、あなたの力は及びにくいだろう。

一方これらの不満はあなたか、あなたと外部両方に属する。

• 私が果たしている責任と役割の大きさを上司が理解しない
• 取引先の彼の態度が気にくわない
• 定型的な業務が多い
• 試験業務ばかりでコードを書かせてもらえない

あの上司があなたの重要さを理解しないのも、あの取引先の彼があなたの成果や報告を難癖をつけるのも、あなたが指示された業務も、何故あなたにも属する不満なのだろうか。

あなたを責めるつもりは全く無いので落ち着いて聞いてほしい。これらの不満はあなたにも責任があるなどいうつもりも全くない。これらはあなたの働きかけによって、よい方向に進むかもしれない項目、つまり操縦可能な不満だ。

これは操縦可能か？

分類の仕方はあくまで一例だ。例えば、あなたが社長と数名しかいない組織なら、時給額の交渉の余地は大きいだろう。あなたがその組織で力のある開発者なら、開発言語やライブラリの選択に影響を与えることができるだろう。

一方で、上司があなたの職務の専門家でない場合(またはとんでもない分からず屋の場合)、あなたの果たしている責任や成果を理解するのは難しいかもしれない。取引先との関係はとてもあなたが関与できるものでなく、あなたは嫌味を言われながら業務を遂行するしかないかもしれない。

とてもシンプルに、不満にどれだけ関与可能かで分類すればよい。

不満を操縦してみよう

不満を分類することで、思ったより操縦可能な要素が多いことに気づいただろうか。操縦できる要素が多いほど、あなたは不満を解消しやすい立ち位置にいる。

どう操縦すればよいか？あなたの不満を解決しつつ、そして相手にとっても得する(あるいは損しない)提案をすればよい。

あなたの取引先の彼がイライラしている理由は、契約通りに作業が進捗していないせいかもしれないが、彼もまた彼の上司から同じように詰められているせいかもしれない。彼に、彼の上司が納得する理由や情報を明らかにすることで、彼のイライラは収まるかもしれない。

あなたの仕事が締め切りギリギリになって、あなたの手元に来るとき、前工程の担当者は別の仕事であなたの仕事のことを忘れているかもしれない。あなたは缶コーヒー(彼が甘党ならエナジードリンク)を持っていき、調子を聞いてみよう。そしてそろそろあの仕事を寄越してくれないか、と聞いてみよう。遅れている理由があなたの仕事の優先順位が低いだけなら、たびたびコーヒーを持参することで解消されるだろう。もしどこかの部署でメールが止まっていることなら、あなたはどこかの部署(本当に困ったものだ)と、あなたの上司にメールをすれば、短い納期で仕事をしなくてもよくなるかもしれない。

経歴の棚卸し

不満の操縦を試みても、なおどんな不満が残るだろうか。それはあなたの未来と関連していることが残るはずだ。

時給はあなたの未来の資産に関連するし、あなたの使用する言語は次の仕事探しに影響する。試験業務ばかりやっていて、素晴らしいコードを書く才能が去っていってしまうかもしれない(もちろんそんなことはないので安心してほしい)。

七色に光り輝く経歴を持つ開発者、分野の第一人者として研究を披露している開発者……現実味がわかないか。製品提供企業の主任開発者、あるいはその開発言語の頻繁な登壇者……まだ遠い。ある製品やサイトの開発者、企業のソフトウェア技術担当者、その他。

素晴らしい経歴の開発者とあなたの経歴を比較したり、揶揄したりするつもりはない(そもそも私自身、そんなことはできないのだ。何故なら、そんなことをすればあなたと同じくらい私もショックを受ける)。

技術力やあるいは才能というものは大きく異なっているが、全員1週間のうち引き受けられる仕事の上限は同じだ(意欲的に働くハードワーカーもいるだろうが、与えられた時間は同じだ)。

どんな経歴を持っていても、彼らは無限に仕事を引き受けられないし、同時に一つの仕事しか進められない(もしかしたら分身するニンジャもいるかもしれないが)、つまり私たちはたった一つの専門分野を持てば、彼らが引き受けきれない仕事を引き受けることができる。

• あなたの経験の中でもっともたくさんの時間を使ったものは何だろうか。

仕事の専門分野を操縦しよう

あなたの経験の中での専門分野はある開発言語だろうか。
その開発言語を用いて、誰のどんな課題を解決したり、価値を提供しているだろうか。

例えばあなたが商品販売サイトのソフトウェア開発者なら商品購入時のデータベーストランザクションに精通している。消費者に対して正しくて確実な取引を提供している。

もし経験をしているのに、専門分野と言えないならそれは勉強不足だ。だが安心してほしい。私はあなたのマネージャでないので、あなたにもっと仕事をしてもらいたいとは思っていない。あなたが関わった仕事全体の提供している価値を見直し、あなたが果たした役割を明確にしよう。

• あなたの関わった仕事は何を解決してきたか？あなた自身は何を提供したか？

もしかして: 自分の仕事の小ささに嘆いていないだろうか。私が担当したのはほんの一区画で、他は誰かの担当だから、自分が与えた価値はほとんどないと思ってないだろうか。そんなことは決してない。ディズニーランドのキャスト(テーマパーク従業員)は、一人一人の仕事は道の清掃、来訪者の整列、レジの会計だが、彼らは夢の王国を実現する重要な一人だ。あなたもまた、”あなたの”製品やサイトを実現する重要な一人だ。

需要と出会おう

あなたがどんな価値を提供できるか明確になったら、需要を探そう。需要は課題として現れる。何を解決してきたかを事前に整理していれば、需要が課題を姿をしているときに、あなたはすぐに解決法を提案できる。

何故需要を探すのか。一つ目の理由は、専門分野の深掘りに繋がるからだ。あなたはその課題を解決することで、より専門家として力を付ける。

二つ目の理由は、交渉できるからだ。あなたは課題の解決法を持っていて、相手はその解決法を欲しがっている。あなたは相手の予算が許す限り、大きな契約金を要求できる。

これは別の企業に移らなくてもよい。同じ企業の他のチームに移動してもよいし、もしあなたのチームが許すなら、解決法を他チームに提供してもよい。大事なことはあなたの上司にしっかり認識してもらうことだ。

そして交渉しよう

あなたは自分の解決策、またはあなた自身に値段を付ける必要がある。良くないのは無償やほとんど無償くらいの値段で提供することだ。無償であることは、解決法を提案するあなただけでなく、それを求める人からも熱意を失わせる。熱意を失った計画は殆ど成功しない。

同じ企業内やチーム内であっても、無償の提供は望ましくない。しっかり交換条件を付けることだ。あなたが解決法を同じ組織の誰かに教えるとき、すごく簡単に、そして前向きに有償化するなら、相手からも同様に何かの解決法を教えてもらうことだ。そして、あなたは上司にしっかりと話そう。私は他のチームのこういう課題を解決しました、と。

昇格か転籍、または独立か

あなたはこれまでの経歴から、何かしらの専門家になっていて、それを求める人と交渉することができるようになった。改めて昇格か転籍かについて考えよう。

今の企業内にあなたの専門分野をもって解決できる課題が沢山あり、その課題解決に需要があるなら、昇格を目指した方がよい。あなたの専門分野も成長するし、あなたは組織と交渉ができる。

もし企業内に課題解決の需要がないのであれば、課題解決により高い値段を付ける企業がないか探してみよう。

悩むのは、あなたの専門分野ではないが今より少し多い時給を払ってくれる企業だ。私の考えだが、この誘いは受けない方が良い。また1年後か2年後あるいは半年後に、今と同じ悩みを抱える可能性があるからだ。

最後にこの節では、独立についても触れておこう。独立には2種類ある。誰かにコードを書くことでお金を得る方法と、もう一つがソフトウェアやノウハウを販売してお金を得る方法だ。つまり独立系開発者になるか、起業家になるかということだ。

これらの職はソフトウェア開発の専門分野を持つだけでは不十分で、より多くの知識と行動が必要になる。

独立系開発者なら、あなたは顧客を得るために奔走し、請求書を送り、毎日帳簿を付け、年にいっかい国に収める税金を計算しなければならない。

起業家なら、あなたは素晴らしい製品のアイディアと、あなた自身の魅力を持って、世間、顧客、銀行員、投資家、従業員から、彼らがお金や時間、投資枠を使ってくれるように、彼らの興味と尊敬あるいは畏怖を得なくてはならない(これに加えて独立系開発者の仕事もしなければならない)。

これらの仕事はとても高揚的で楽しいことだ。しかし、同時に多くのことを学ばねばならない。独立はまた別の章で考え方の解決法を考えよう。