仮に採用されたとして、たまに会って好き勝手に話していた飲み会もできなくなるんじゃないかとか思うと誘えない。関わりが深い人ほど適切な距離感を保ちたかったりする
あるいは、リファラルのインセンティブ制度があると逆に相手を利用しているような気がしてしまうという人もいるかもしれない。これは候補者にもインセンティブのある制度設計になっていたとしても関係なくて、気持ちの問題と言える

6. 美学に反する

前職の同僚を現職に誘うのは不義理に感じるといった感じで、誘うこと自体が美学に反するということもある
この感覚は自分もわかる。特に、前職でマネジメントロールをやっていた場合には前職も現職も成長してほしいと考えるのは自然だし悩ましい
完全に現職にコミットするのでそういう感覚は持たないというのも正しいと思う。一方で自分はこういう誘わない美学みたいなのを持っている人は好きだったりする

もっといろいろありそう。自分の知り合いを誘うのってお互いに色々リスクが大きいと感じるというか、関係性が深いほどむずかしいし、よい人ほど本当に誘ってよいのかとためらってしまうよね。

書き出してみると、リファラル制度と採用プロセスの設計と周知で一定は改善できると思う。いちばんの肝は何と言っても 1. 誘える組織ではないと思っている で、ここがクリアできているのが一番大事。自分の中の "誘ってもよい閾値" を超えていなければ話にならない。結局、まずは今の組織や事業に向き合ってベースを作っておく必要がある。

というのはもちろん皆わかっているものの、誘える組織というのは求めだすとキリがない。自信満々に誰でも誘える状態ではないことを認識した上で、誘える部分を見極めてリファラルをワークさせ、より誘えるような組織を作っていくという"にわとりたまご"的な側面がある。「誘えない」とだけ高らかに叫んでいても何も始まらないので、一定の組織への信用と自身の覚悟をもってやっていくしかないのだと思う。

ちなみに自分は 5. 関係性が変わりそうで嫌だ を気にしてしまって誘えないことが今でもある。吉祥寺の飲み屋に定期的に飲みに行くソフトウェアエンジニアが3人いて、彼らはみな素晴らしいのだけれどあまり誘いたくないなと思ってしまう。このためらう理由を超える方法はまだ思いついていない。

2024-11-29

じわじわMPを削っている"毒"は何か

仕事終わりどころか朝起きた瞬間からなんだか疲れてしまっていることがある。

そういう時は体力的には元気でもポンコツになる。RPGゲームで言うとMPがじわじわ削られているような感覚で、注意力や集中力も落ちて生産性ががくんと下がってくる。自分はこれを "毒状態" と呼んでいる。毒効果はたいていHPを削るものだが、そこはあまり気にしないでほしい。

自身が毒状態にあることを認識したら、原因を明確にするところから始めなければならない。

たとえば、他チームの◯◯さんとのやりとりに苦労してるとか、ミーティングで人と話す時間が増えて気疲れしてるとか。何か期限があるタスクを誰にも相談できずに抱え込んじゃってるとかもよくある。あるいはプライベートの心配事なども関係しているかもしれない。

経験上、毒状態には2つの傾向がある。ひとつは「単一ではなく複数が積み重なっていること」、もうひとつは「人の顔がチラついてしまっていること」である。

本来タフで馬力もある人がなんだかしんどそうにしている時は、何をするにも誰かの顔が頭にチラついて離れないみたいな状態になっていることが多い。シャワーを浴びながらため息をついたり、朝からつらいと呟いてしまったりするやつである。

そうなった時は、何が毒になっているかを書き出して把握してみるとそれだけで少し楽になる。しかし、毒状態の時に自分で釜の蓋を開けるのはしんどい。できるなら誰かに手伝ってもらった方がいい。

たとえば、1on1で「最近MP削られてるから"毒消し"手伝ってください」みたいな感じで話してみるといいかもしれない。逆に聞く側の立場なら「最近脳内を占めていることトップ3は何ですか」といった話から聞いていくとよさそう。

そもそも毒状態にならないように鍛えとけというのはそのとおりなんだけれど、まあ実際いろいろあってそうなることはあるし仕方ない。自分のまわりを見ると、真面目でがんばり屋な人ほど陥りがちな気もする。

まずは毒状態であることを認識するのが大事。あるいは、毒状態っぽい人がいたら「あなたの毒はどこから？」みたいな感じで接してみるといいかもしれない。毒消しの第一歩はパーティーメンバーへの共有からなのだ。

2024-11-28

お膳立てされずに勝手にやる

あくまで個人の好みの話なのだけれど、自分は成果を出すために "お膳立て" されている状態があんまり好きではない。そういう話を雑に吐き出してみる。

たとえば、ブログ記事の執筆やイベント登壇資料の準備を業務時間中にやってよいみたいな話が明文化されていると、業務調整はしやすい一方でなんだかちょっと"やっていき"感やワクワク感が自分の中で小さくなってしまう。そんな決まりがなくても適当に調整してやるし、「全部できたらすごい」みたいなプラスアルファの要素が薄れてしまうような感覚がある。

丁寧な研修なんかも同じ。一定規模以上の組織では仕組み化すべきなのはわかっているのだけれど、個人的には乱戦みたいな状態で個の力でガッとやっていく方が好みだったりする。

80点以上の成果を出すためのレールが整備されていると、当然期待も上がってしまうのが嫌なのかもしれない。常に120点を目指していても、やってやった感が少ないというか。300点を目指すようにすればよいのかもしれないが、それもなかなか難しい。

20%ルールなんかもそうなんだけど、ルール化されて公式に時間を使ってよいというお墨付きをもらうよりも自分で調整して勝手にやっちゃいましたみたいな動き方が好みなのかもしれない。開発プロジェクトでも、十分すぎるバッファを積んだスケジュールを確保してもらうと逆にやりづらいしつまらないなと感じたりもする。

なんというか、成果を出すためのお膳立てがされていると「これ勝手にやったらすごいよな/面白いよな」みたいな感じでニヤニヤ企みながらガッとやっちゃう動きをしにくいと感じるのだと思う。時間を確保してもらって正式に取り組める状態に整えてもらうと、普通の仕事のタスクみたいで途端につまらなくなってしまう。

必要なのは勝手にやってしまえる余裕であって、ルールでもお膳立てでもないのかもしれない。その上で「ここまでやっちゃいました」、「こういうの作ってみました」って感じでステルスでドーンしてドヤみたいなのが好き。

もちろん仕組みがあった方が全体の成果を上げやすいし、組織としては一定整備したほうがよいのは間違いない。あくまで個人の好みの話である。

2024-11-27

チャットDMへの拒否反応

チャットツールのDMで連絡がくることを嫌う人は一定いる。DMじゃなくてもよさそうな話がくると、「これってなんでDMなんですか？」とか、「この内容なら◯◯チャネルで話しませんか？」とかみたいな感じで公開チャネルでのやりとりに誘導している人もいると思う。

こういうDMへの "拒否反応" のような感覚は自分も少し持っているが、なぜなのかよくわかっていないので雑にまとめてみる。

考えてみると、この拒否反応は次の懸念からきていると思う。

1. 限定された人しか見れない場所で何かが進んだり決まったりしていくこと

頭出しでちょっと話すくらいなら問題ないんだけれど、なんとなく流れで色々話して実際にそこで結論が出てしまったりするのが嫌みたいな気持ちがあるのだと思う。

密室で物事が決まってもどこかで共有されれば何の問題もないんだけれど、共有が漏れることも往々にしてあるし、神経質になる気持ちもわかる。ある種の "高潔さ" と言ってもいいかもしれない。

2. 結局あとで必要な人に同じ話をする時に二度手間になってしまうこと

どうせ同じこと話したり他の人にも聞いたりするんだから、最初から公開された場所で話せばいいじゃんみたいな感覚があるのだと思う。何か補足や間違いがあったら指摘もしてもらえる。

正直たいした手間ではないんだけれど、無駄を嫌うみたいな感じ。同じような話ができるチャネルがあるのにDMでも話すと、どこで何を話すべきかわかりづらくなるというのもある。

3. DMのやりとりが蔓延すると組織全体として情報の透明性が失われていくように感じること

一度DMで話すようになると、ちょっとしたこともちょいちょいDMで話すようになりがち。

"あまり乱用しない" くらいのゆるいルールだとあっという間にDMだらけになって、色々なことがDMの中で決められて情報が見えにくくなるみたいな不安が湧いてくるという側面もある。

あるいは、そういうことを考えずにどんどんDMしてくる人のスキルレベルやマインドセットに対して少し怒ってしまうという人もいるかもしれない。

書き出してみると、乱用せずどこかで適切に共有されるのであれば DM 自体を過度に拒否する必要もない。

何でもかんでも「DMはダメ」と言って選択肢を減らすのもよくない。むしろシュッと話してすばやく物事を進められるのであればDMを使ってもいい。チャット全体のDM比率をトラッキングするみたいなのも本質的にはあまり意味はない。

これは個々人の話というよりも、組織全体のスタンスの話でもある。たとえばバリューに "オープンネス" みたいな話が明記してあるなら、全体として DM は非推奨にしてもいいと思う。

実はある程度のテキストコミュニケーションスキルがないと、公開チャネルで話すのは難しいという事情もある。内容によっては "不特定多数に見られても曲解されないように伝えるスキル" が要求されるからである。もし DM を非推奨にするのであれば、こういったスキルのフォローアップもセットで考えた方がいいと思う。

また、何かを固めていくプロセスに対する考え方の違いも関係してそう。DM ではなく公開でのやりとりを好む人は、初期段階から皆でブラッシュアップしていく意識がつよいのかもしれない。たとえばエンジニアだと、仕様策定段階から関わった方が手戻りも少なくよいものを作りやすかったりする。それと同じように、何かの頭出しや相談も他の人が関われる状態にしておくべきという意識が少しあるのかもしれない。

逆に DM が使えないせいで相談されなかったりタイミングが遅れたりするとしたら元も子もない。拒否反応を示してもいいとは思うけれど、相手への伝え方には気をつけよう。 "DM警察" のような取り締まり方でピシャリと冷水を浴びせると、それはそれで結果として情報の透明性が失われていく要因になってしまう。

2024-11-26

強みを2つ以上持つ

強みを2つ以上持つことを意識しておくほうがいいと思っていて、雑に書きなぐっておきたい。

1つの領域で圧倒的な強みを作るのは大変。「チョットデキル」、「完全に理解した」を何度繰り返しても、やればやるほど上が見えてくる。

2つ以上の強みを持つというのもそれはそれで大変なのだけれど、パレートの法則に照らせば80点くらいまでは高めやすい。ある程度自分の強みを作ったらそれをより極めていくのもよいが、他の領域も30%くらいやってみるというのがいいかもしれない。

プロダクトマネジメントが強みだとすると、他領域をやっている中で "プロダクトマネジメント的" な発想を転用できることが多いことに気づくと思う。営業が強みだとすると、相手の求めることを突き詰めて考えるといったエッセンスが採用など人事領域にも活かせるかもしれない。

デザイナーがモバイルアプリやWebフロントエンドの実装をやってみるのもとてもいいと思う。実際にコードを書いてみると、デザインする時に考慮したほうがいい観点なども理解できてエンジニアともやりとりしやすくなる。サーバーサイドエンジニアがモバイルの開発をやってみたり、AndroidエンジニアがiOSをやってみたりするのも同じで、もともとの強みにもいい影響が出る。2つと言わず、3つ4つやるのもいい。

器用貧乏になるのが怖いという人もいるかもしれない。気持ちはわかるが、まあそういう不安になる人はたぶん大丈夫な気もするし、いったん「最強の器用貧乏になるんや」みたいな気持ちで他領域をやってみてもいいと思う。

一方で、「これが自分の一番の強み」と言える領域は持っておいた方がいいと思う。全部平均的にやっていってもいいんだけれど、アイデンティティと言える何かがないとなんとなく不安になりやすい気がする。自分の場合、一番の強みは今も Android アプリの開発で、他領域としてマネジメントや雑な発信がある感じだろうか。常にポートフォリオは変わっていっているし、今も80点レベルかというと自信はないのだけれど、明確に自信がある/あったと言える何かがあるとだいぶ違う。

「エンジニアリングのわかるCS」とか、「マネジメントを経験したプレイヤー」とか、「経理の発想を持ってるエンジニア」みたいな "◯◯のわかる△△" というのはかなり強い。計画的偶発性でそうなったという人も多いけれど、掛け合わせで唯一無二の強みになっている感じがする。

ナンバーワンにならなくてもいい。
(が、人間が承認欲求とうまく付き合うのは難しいので "オンリーワン" という自己認識だけでは焦燥感で辛くなることもある。結果的にナンバーワンを目指した方が楽なことも多いが、ひとつの領域でテッペンを取るのは大変。そういう時は3つくらいの領域で70〜80点くらいを目指していくといいかもしれない。ただ、それでもたまにしんどくなる時はあると思う。そういう時はこう考えて少し休んでもいい。)
もともと特別なオンリーワン。

Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

中毒性のあるラーメン・つけ麺

三田二郎 - 三田

椿 - 王子

小むろ - 行徳

えいちつー - 西葛西

卍力 - 秋葉原

しら石 - 銀座

自分の在籍エントリまとめ

Quipper 3ヶ月 / Androidエンジニア / 30歳

Kyash 6ヶ月 / Androidエンジニア / 32歳

Kyash 2年 / Androidエンジニア / 33歳

Kyash 3年 / Engineering Manager / 34歳

Kyash 4年 / Engineering Manager, QAエンジニア / 35歳

Kyash 5年 / VP of Engineering / 36歳

Kyash 6年 / VP of Engineering / 37歳

Kyash 7年 / 執行役員VP of Engineering / 38歳

リファラルで人を誘うのをためらう理由

1. 誘える組織ではないと思っている

2. 誰にどう声をかけたらいいのかわからない

3. マッチするかわからなくて不安

4. 採用プロセスが見えなくて不安

5. 関係性が変わりそうで嫌だ