Helper119

「成果を出したのに評価されない」「市場相場より低い気がする」・・・という違和感は、多くの場合、日々の仕事に真剣に向き合っているからこそ生まれることだと思います。 「給与・評価」をあげる方法は色々とあるかもしれませんが、重要なことは「感情のまま動かないこと」です。その上で「人、環境に応じて最適な方法を考えること」を整理し、行動する形が良いと考えます。 ここでは、 ② 転職活動を始め、オファー額を突きつけたケース と ④ 副業で稼ぎ、心の平穏を保ったケース に絞って記載します。 ② 転職活動を始め、オファー額を突きつけた 特に正社員でスキルには自信があるものの、現在の給与や評価に不満を感じたとき、転職活動に踏み出したい人の多くは、「今すぐ辞めたい」というよりも、「自分の市場価値を正確に知りたい」という気持ちになると思います。 少し補足すると社内評価は、会社の業績や評価制度、上司の裁量といった要素に大きく左右されます。一方で、転職市場のオファーは、より直接的に「今のスキルや経験に、いくら払えるか」を示してくれます。 実際に転職活動する際は、最初から強気な交渉材料を集めるというより、複数社の選考を並行して受け、「年収レンジ」や「求められる役割」を把握することが重要であると考えます。この過程で、「思っていたより評価される」「やはり今の年収は低めだった」といった事実も見えてきます。 もしオファーを得たあとに社内交渉をする場合は、オファー額を“脅し”として使うようなことは絶対にしません。「他社ではこれだけ提示された。上げないなら辞退する」という伝え方は、たとえ給与が上がったとしても、その後の信頼関係を構築する上で、何かしら問題が生じると思います。 比較的うまくいったケースでは、「今の仕事自体にはやりがいを感じているが、今までのこういった経験を活かして上位のポジションで活躍していきたい」というように、あくまで冷静に具体的なビジョンを提示することです。 結果として転職を選ぶにせよ、残留するにせよ、このプロセスを通じて得られることは「自分の値段を外の世界で確認できた」という事実そのものです。それだけでも、モヤモヤはかなり整理されるのではないかと考えます。 ④ 副業で稼ぎ、心の平穏を保った もう一つ、比較的穏やかに不満と向き合ったのが、副業を始めたケースです。 副業で収入が生まれると、たとえ月に数万円であっても、心理的な余裕が大きく変わりストレスが軽減されると考えます。 また、副業は市場からのダイレクトなフィードバックでもあります。例えば社内では評価されにくかったスキルが、社外では対価を払って求められることも珍しくありませんし、社外から評価され役に立ったと感じたときに心のゆとりが生まれる事もあると考えます。 こういった経験は、「評価されない自分」という思い込みを壊し、「場所が違えば価値も変わる」という良い視点を与えてくれるのではないでしょうか。 これら２つの選択肢に共通しているのは、「会社の評価＝自分の価値」という構図から一歩距離を離しているという点です。また給与や評価に違和感を覚えたときは、自分を責めるのではなく、環境や選択肢を見直すサインだと捉える方が、心理的に楽になるコツなのかもしれません。

チーム開発における勤務体系の議論は、もはや「フルリモートか、出社か」という二者択一ではありません。「ハイブリッド勤務」こそが最適解であると考えます。 なぜハイブリッド勤務が最適解となり得るのかを整理して、そして成功するハイブリッド勤務の条件はどのようなものなのか記載していきます。 1. 個人の生産性は「リモート」を軸にする エンジニアリングや知的労働作業において、集中できる時間の質と量は成果に直結すると考えます。リモートワークは、 ・通勤時間の削減 ・自宅など自身に最適化された作業環境の存在 ・他社の割り込みの少なさ といった点から、個人の生産性を高めやすい働き方であることは多くの現場で実証されている認識です。 ハイブリッド勤務では、この利点を捨てない。日常的な実装作業や調査、ドキュメント作成などはリモートを基本とすることで、個々のアウトプットを最大化することが重要です。 2. 高速な合意形成はオンラインでも可能だが、質に差が出る 近年では、ZoomやTeamsなどのオンライン会議ツールの成熟により、出社しなくても高速な合意形成は十分に可能になっています。例えば画面共有を用いた設計議論、即時のフィードバック、録画機能により記録に残る意思決定など、オンラインならではの利点も多いです。 特に、 ・議題が明確に定義されている ・参加者の前提知識が揃っている ・判断基準や権限が明文化されている といった条件が整っている場合、オンライン会議は対面と同等、あるいはそれ以上のスピードで結論に到達することも珍しくないと考えます。 一方で、オンラインの合意形成には限界も存在すると考えます。例えば発言の裏にある迷いや違和感、温度感のズレといった非言語的な情報は拾いにくく、結果として「決まったが腹落ちしていない」状態が生まれやすいです。 ハイブリッド勤務における出社の価値は、単に合意形成を速めることではなく、相手の表情を確認し、認識の微妙なズレを事前に潰し、合意の質を高めることにあります。重要度が高く、長期的な影響を持つ意思決定ほど、対面での議論が有効に機能すると考えます。 3. 新人教育においてハイブリッドは最も強い 新人育成は、勤務体系の影響を最も強く受けると考えます。フルリモートでは、 ・質問の心理的ハードルが高い ・困っていることに周囲が気づきにくい ・暗黙的な判断基準が伝わりにくい といった課題が顕在化しやすいです。 ハイブリッド勤務では、オンボーディング初期や成長の節目に意図的に出社機会を設けることで、これらの課題を解消できると考えます。 横で仕事を見る、雑談の中で価値観を共有する、といった体験は、短時間で大きな学習効果を生む可能性もあると考えます。 4. バーチャルオフィスという第三の選択肢 ハイブリッド勤務の質を高める手段として、バーチャルオフィスの導入も有効な選択肢の１つになります。これはフルリモートの弱点である「気配の欠如」や「声をかけづらさ」を補完する存在になります。 バーチャルオフィスでは、 ・常時接続された仮想空間にアバターで滞在する ・話しかける・雑談する行為が物理オフィスに近い感覚で行える ・「今話しかけて良さそうか」という空気感をステータスで可視化できる といった特徴があり、リモート環境でも偶発的なコミュニケーションを生みやすいと考えます。 特に、 ・新人の質問ハードル低減 ・チームの心理的距離の縮小 ・フル出社が難しい期間における代替手段 として効果を発揮すると考えます。 ここで重要なのは、バーチャルオフィスを「常時強制参加の場」にしないことです。集中作業は従来通りリモートで行い、人とつながるための選択肢の一つとして位置付けることで、負荷をかけずにメリットを享受できるのではないかと考えます。 5. 成功するハイブリッド勤務の条件 「ハイブリッド勤務」という定義だけでは足りないことがあります。成功させるためには、明確な思想が必要です。 例えば、 ・出社の目的を明確にする（何のために集まるのか） ・情報共有はリモート前提で行う（ドキュメント・議事録は徹底する） ・出社日は原則関係者全員が揃う（情報格差を生まない） ・バーチャルオフィスは補助線として使う（常設だが任意参加OKな場面も必要） これらを曖昧にしたまま併用すると、様々な問題を招く可能性があります。 まとめると 「ハイブリッド勤務」における勤務条件を明確にし、チーム・個人の状況やフェーズに応じて運用を更新し続けることで、様々なメリットを受けられるので、これが成功のカギになると考えます。 最後に勤務体系は「固定された制度」ではなく、チーム成果を最大化するための「１つの手段」と検討していくのも良いと考えます。

「まずは動くものを」で作ったコードと、技術的負債の向き合い方について 個人開発や少人数チームで、「まずは動くものを作る」というのは、 要件は固まっておらず、正解も分からない段階では、「最初から綺麗なコードを目指す」ことは現実的ではありません。 仮コードの役割は、正しさや見栄えの良さではなく、 ・要件を確かめるため、モックアップを作成する ・ユースケースを理解する ・今後、仮コードを捨てるか育てるかを判断する ための材料になると思います。 したがって、この段階でリファクタリングを始めるのは誤りです。 要件が揺れている間、仕様変更が頻発している間、捨てる可能性が残っている間は、改善に時間を使うべきではないと考えます。 では、いつ返済するのか。 仮コードが返済対象に変わるのは、「明確な合図が出たとき」だけです。 例として２つ記載します。 １つ目は、仮コード捨てられなくなったときです。 ユーザーが使い始めた、データが本番に溜まり始めた、 あるいは別の機能がそのコードを前提に作られた。 この時点で初めて、そのコードは「返済すべき技術的負債」に変わります。 ２つ目は、仮コードの内容で要件の合意ができたときです。 厳密に言うと仮コードは、要件合意をもって役割を終えます。 返済は、合意内容を前提にしたコードの拡張・運用が始まった時点で行います。 また返済に入る際の考え方も重要です。 ここで重要なのは「綺麗に作り直す」ことではありません。 まず行うべきは、「境界を固定すること」です。 外部インターフェース、API、DBスキーマなど、 外から見える部分だけを安定させることです。 このとき、内部の実装はまだ汚くても全く問題ありません。 そして個人・少人数開発においては、 「返済するか」「捨てて作り直すか」 この選択肢を常に残しておくことも重要です。 プロトタイプ用のブランチや明示的なコメントによって、 そのコードが仮設であることを示すのも１つの方法であると考えます。 まとめると、「まずは動くものを」で作ったコードは、 返済前提の借金ではありません。 それは「返すか、捨てるか」を判断するための借金です。 返済は急がず、 しかし仮コードを作る目的に応じて、 返済開始の合図を決めておくことが重要です。