🐕
インポスター症候群を乗り越えるために申し訳ないよりありがとうなエンジニアリングを
概要
想定読者：
- たとえ成果を出したとしても、どこか自分に自信が持てず不安な気持ちで取り組んでいるエンジニアの方々の気落ちが10^-18mmでも軽くなれば🙏
想定読者ではないかもです😭：
- インポスター症候群に関する深い調査・文献見解をお求めの方：あくまでこの記事記載のきっかけなので症候群自体に対しては引用中心とさせていただくためでございます🙇
結論：
経緯
- すごく話題になりました以下の本「スタッフエンジニア マネジメントを超えるリーダーシップ」を読んでいる際に、以下のようなフレーズがあり、「インポスター症候群」なるものが気になった。
- 気になったと同時に、ふと自分の中で意識する機会があった「申し訳ないよりありがとうなエンジニアリングを」という心構えがインポスター症候群を克服するきっかけになるのではないかと思い記事を書こうと思った。
誰もがインポスター症候群に苦しんでいると気づいたことも、自信につながりました。私がこれまでいっしょに働いたなかで最も自信のあるエンジニアだと思う人が、そう気づかせてくれたのです。 (中略)
そもそも
- インポスター症候群とは
- 自分の能力や実績を正当に評価できず、成功しても「運が良かっただけ」「周りの人が助けてくれただけ」と思い込んでしまう心理傾向
インポスター症候群とは、自分の能力や実績を正当に評価できず、成功しても「運が良かっただけ」「周りの人が助けてくれただけ」と思い込んでしまう心理傾向のことです。まるで詐欺師のように、周囲を欺いているような感覚に陥るため、「詐欺師症候群」や「ペテン師症候群」と呼ばれることもあります。
エンジニアにおけるインポスター症候群の仮説
- エンジニアのみではない症候群ではありますが、エンジニアが該当するパターンを考えてみました。
エンジニアリングという行為自体が不確実性と向き合う行為であるから
- そもそも、エンジニアリング自体が不確実性と向き合いながら課題解決をすることで顧客価値を生み出す行為。
- 不確実性に悪戦苦闘している自分と、世の中の華やかな結果を出している他の方とのギャップから、時には不確実性に呑み込まれ「まだ何も成し遂げてない」と感じる方は多いのではないか
「不確実性」という言葉を乱発しているのは大好きな以下の本の影響から。
「正常にコードを動かすという具体的で完璧な状態」から「不確実で抽象的な課題解決」に自らのミッションがシフトする構造になっており、時系列でのギャップを感じやすいから
- 最初は誰しもがおそらく「正常に動いた！」という感動が初期衝動なのではないか
- それが年月を重ね責任領域が増えるにつれ、プロフェッショナルだとしてもマネジメントだとしても抽象的な課題を具体的なtodoに落とし込むまでの課題解決力と意思決定がミッションになるケースが多く、実施難易度は上がっているのに「正常に稼働するコードをいっぱい書いていた前の方が成果出していたのでは...?」と感じてしまう方もいるのではないか
- もちろん難易度が上がるにつれ、正常なコードを記載するという行為自体に不確実性が加速度的に発生するので、あくまで初期衝動とキャリアアップした際の比較である。
どうしたってシステムの中に自分の関与外の領域が生まれるから
- 大抵、自分一人で全てのコードを記載することはできない
- そうすると完璧主義であればあるほど自分の関与していないコードがある状態で動くシステムに違和感を感じる
- 違和感はやがて自分自身の責任領域の狭さ・技能不足による物だと認知を歪めてしまい「ほんのxxxしか書いてないしAさんの方が広いドメインカバーしてるよ」という発想に陥りやすいのではないか
技術の発展スピードが急速で、常に学べていない技術範囲が発生してしまうから
- IT技術は常にキャッチアップが必要
- 大抵がキャッチアップが好きだから続けていることが予想されるが、好きだからこそ自分の全く知らない領域が存在するという状態がむず痒い
- ただ、全てを把握するなんて無理な状態に対して常に走り続けなければいけないこの構造から、「まだまだ技術知らないから今回もたまたまうまく行っただけ」と過度な謙遜が習慣化してしまうのではないか
没頭できるが故に、仕事と生活の境目がなくなり中毒状態に陥りやすいから
- 半分趣味のような方が多い業界の印象
- だからこそ仕事と生活の境目が他の業界よりも薄いと感じる
- そうなると、生活全てを捧げることのできていない自分を鍛錬不足と感じるような脳構造になってしまうのではないか
仮説に対して少し変わったアプローチ：「申し訳ないよりありがとうなエンジニアリングを」
- もちろん、環境を整備する・ジョブ定義を明確にする・ミッションを定量目標に分割して計測する etc...等の具体的なアプローチが存在すると思う。
- ただ、本記事ではスコープ外とし、「申し訳ないよりありがとうなエンジニアリングを」という少し変わったアプローチを提案させていただく。
- 感謝し、感謝されることの習慣化は認知を正常に戻すトリガーになると感じたから。
アプローチ経緯
- 少し前に自分が何を実施したかを考えさせられる機会があった。
- その際に具体的なコードを記載して出した顧客価値は確実に減ったよなという実感だけはあった。
- では自分は何をやってたのかをnotionテーブルの実績ログをもとにあれよこれよと考えてた。
- ログから追っているという行動から着想を得て、ふと「slackで感謝されている場面とか追っていったら良いのではないか」と探索開始
- またまた派生して、自らの謝罪「申し訳...」と自らの他者への感謝「ありがとう」の数を比較・中身のメッセージを見てみた。
- その時の結果がこちら。
| 期間 | 申し訳 | ありがとう | 合計 |
|---|---|---|---|
| 20221121 ~ 20250814 slackでの数値を確認 |
439 | 1261 | 1700 |
探索した時に感じた恥ずかしさと達成感
[恥ずかしさ]
- まず、申し訳ブロックを読んで「いや、謝りすぎやろ！」と感じた
- 「確かにこれはやらかしたよな...」と読み返してて感じたのはほんの一部で、その他は手癖で謝ってしまっている内容が多数
- slackが故にスタンプで謝っているのもあるため、実状はもっと謝っているのではないか
[達成感]
- シンプルに、ありがとうと発言している回数が申し訳ないと謝罪している回数の3倍近く多いことが嬉しかった。
- そして、大体ありがとうブロックに記載されている内容は自らで何かを実施しようとしている際に発生している他者への感謝のコミュニケーションだと感じた。
- チャレンジの回数が謝罪の回数を大幅に越していることは達成感を与えてくれた
- また、ありがとうブロックのところは「これ別に感謝せんでええやろ」とかは感じなかったのも特徴だと感じた
ありがとうから得られる達成感が自らにポジティブな自信をもたらす
この「ありがとうから得られる達成感」は非常に重要であると感じた。
というのも上記に記載した課題解決へのアプローチとも言えるから。
- 抽象的な課題解決に奔走する日々で浮き足立っていた足元を、目の前のチームメンバーに感謝して、感謝されているという具体性の高く確実な事実が地に足をつけることを手助けしてくれる
- 過去から現在で時系列で「ありがとう」を追うことで自らのスキルアップを確実に感じることができる
- slackコミュニケーションでいうと言語化能力とかは特に感じやすい部分
- 逆に申し訳ないという言葉で始まる課題解決は、自己の卑下と隣接しており、いつどこでインポスター症候群になってもおかしくない状態。使うべき場所は確実に存在するが、限定されると思う。
自らのポジティブな自信がチーム及び組織のエンジニアリングを加速させる
- 限界まで申し訳ないをありがとうに言い換えると決めると副次的に気づくことがある
- 「申し訳ない」という謝罪で、本質を明確にしないまま議論を終わらせていた場面があるのではないか
- 自分の「申し訳ない」は他者に不要な気遣いをさせる要因・コミュニケーションを歪ませる愉悦を発生させる要因になりかねないのではないか
- 常にありがとうの姿勢を忘れない姿勢は、エンジニアに限らない人としての姿勢としてかっこいい姿勢ではないか
- ありがとうで広がるコミュニケーションは、申し訳ないで萎縮しながら窮屈に伸びるコミュニケーションより柔軟で、活発で開放的ではないか
- 活発で開放的なコミュニケーションはコミュニケーションにおける不確実性を削減し、エンジニアリングにおける「心理的安全性」につながるのではないか
これから
- 完全にポエムみたいになってしまいましたが、「申し訳ない」と打とうとしているあなた、「ありがとう」に言い換えれるかまず一考する方が健全なエンジニアリングです！ということだけは間違いなく言えると思う(PRコメントもそうだし、slackコミュニケーションもそうだし、mtgもそうだし ...)
- もし自分自身を卑下している時に生まれる感謝なら申し訳ないが先に来るだろうし、乗り越えた際に生まれる感謝ならありがとうが先に来るだろうと信じている。
- というか、ここまで読んでくれた皆さん本当にありがとうございます！！！(嬉しい)
Discussion