はじめに
自分がIT業界に携わって5年ほどが経過しました。
この5年間、SIerからフリーランスエンジニアに転身し、様々なプロジェクトに参加する中で、数々の失敗と成功を経験しました。特に心構えやマインドの部分で多くを学ぶことができました。
未熟だった自分を振り返って、今では改善できた点が多くあると思います。同じ失敗を繰り返さないように、自分の経験が少しでも役立てば幸いです。
また、気付きを与えてくれた方々にこの場を借りて感謝します。
感謝を忘れない
進捗報告やコードレビュー、質問対応など、感謝の気持ちを忘れないようにしています。感謝は、コミュニケーションを円滑にし、相手の意欲を引き出す力があると思います。
たとえば、昔の自分はバグ報告を受けるとろくに文章も読まず「影響範囲は？ 再現する条件は？ 原因は？ 解決策は？」などと質問攻めにしてしまっていました。
報告しただけなのに色んなことを聞かれて答えなきゃいけないなんて、もう次からはバグ報告するのやめようと思わせてしまっていたかもしれません。
今では「バグを見つけていただきありがとうございます。影響範囲を特定したいので、まず再現する条件を教えていただけませんか？」と感謝から始めるよう心がけています。感謝は、コミュニケーションのクッションになることもあるので重宝します。
感謝はきっと、自分にとっては過剰なくらいがちょうど良いんだろうなと感じています。
否定は柔らかく表現する
自分の意見が聞き入れてもらえないというのは、誰しもある程度悲しいことかなと思います。
そこで、自分は相手の意見を却下しなければならない時、以下に気をつけています。
- 一旦意見を受け入れる
- 相手の意見に反対する理由を伝える
- 代案を提示する
- 柔らかい言葉遣い
「なるほど、提案していただいた案も良いかもしれないですね」と相手の意見を一旦受け止め、「ですが、従量料金がかなり嵩むことになり、月当たりの予算をオーバーしてしまいそうです」と、どうして意見を通せないのか相手が納得できる理由を伝えます。
「代わりに、類似サービスであるXXXはどうでしょう？ パフォーマンスは少し落ちますが、コストは枠内に収まります」と代案をつけます。
理由や代案がないままだと、感情的な拒絶に近しいものになってしまうと思います。相手からしたら、なぜ自分の意見が通らないのか納得しかねる結果になってしまう気がしています。
相手を萎縮させてしまうことになるので、ダメだよ、ありえない、絶対ないね、などの強い否定言葉は使わないようにしています。
他人も物事も知った気にならない
- 自分より10年長く社会人やってるのに全然技術のこと分かってないじゃん、何してきたんだこの人
- あの先輩、仕事の進め方の反りが合わなさすぎる
- あのライブラリ、バージョンアップしたらめちゃくちゃ使いにくくなったけど誰が嬉しいの？
- こんな複雑な仕様にしたの誰だよ、保守できるわけないじゃん
当時の自分の考えを振り返ると、もっと多様な視点を持つべきだったと感じます。
相手の立場や現状に至るまでの経緯をろくに想像もせず、ただ目の前の現状を自分にとっての都合で解釈するという最低の考え方をしてしまっていました。
きっと人には人の事情がありますし、自分が知らないところでたくさんの人たちは頑張ってるわけで。
成果が求められる場面でもないのに、プロセスも知らないままに文句を言えるほど自分は偉くないということに気づくまで時間がかかってしまいました。
ネガティブなこともポジティブに捉える
人間は周り5人の平均になる、というのはアメリカの起業家であるジム・ローン氏の語った内容らしいです。
いつも前向きで元気な人、愚痴ばかりで偏屈な人、どっちの近くにいたいかなんて明白です。自分は誰かにとって側にいても良いと思われる人間でありたいなあと思うようになりました。
他人の失敗やスパゲッティ状態のソースコードなど、悪態をつきたくなることは日常的にあります。
ですが、Fail Fastだったねとか、改善してもっと内部品質上げるチャンスだねだとか、ポジティブに捉えることだってできるはずです。
悪い面ばかりを取り沙汰するのではなく、良い面を見つけられる人になりたいです。
呼ばれてないのに飛び出さない
悪意のないおせっかいを頻繁にしてしまっていたなあと反省することがよくあります。
timesでのぼやきに速攻で飛び付いて頓珍漢な返信をしたり、特定メンションがついてる質問スレッドに割って入ったり。
役に立てたこともあるかもしれませんが、それ以上に邪魔くさかったことの方が多かったのではないかなと想像しています。
相手からすると善意たっぷりにアクションしてくる自分に対し、ないがしろにもできないし一応感謝しておくか......と余計な気を遣わせてしまったかなと思います。
自己主張の前に一瞬考える
自己主張することは大切です。思っているだけでは伝わらないのが人間です。
ですが、以前の自分は自己主張のやり方に問題があったと今は思います。
- 相手の話を遮って自分の意見を喋り出す
- 叱責に近い会話を当事者以外の第三者がいる場で行う
- 強い言葉で誇張する
自己主張する際に、上記のようなことをする必要は一切ありませんでした。
「自分には自分の意見を言う権利がある。だから今言おう」といったように、自分の意見を大切にしてほしい気持ちから行き過ぎた自己主張をしがちだったんじゃないかなと今は思います。
しかし、意見を大切にしてほしいと思っているのはきっと相手だって同じはずです。
自分の主張によって、もしくは主張しないという自己表現をすることで、相手がどう思うかを一瞬考えてからでもコミュニケーションは問題なく成立すると気付くまで長い時間がかかりました。
アサーティブなコミュニケーションという考え方に出会えたことで、自己表現に対する考え方が大きく変わりました。まだまだ上手くできないことが多いですが、少しずつできることを増やしていきたいです。
定期的に内省する
ビジネスシーンでは、設定した目標に近づけているか、次にとるべきアクションは何か、仕事を最適化していくために振り返りは重要とされています。それは自分の振る舞いに関しても当てはまると思います。
スクラムのレトロスペクティヴでよく使われるKPTなどを参考にして、自分の良かったところ、良くなかったところを振り返り言語化します。ジョハリの窓で言う「盲点の窓」や「未知の窓」に位置していることに少しでも気付けるようにします。つまりは自己理解です。
- 【開放の窓】自分も、相手もよく知っている領域
- 【秘密の窓】自分は知っているが、相手には隠している領域
- 【盲点の窓】相手は知っているが、自分は気付いていない領域
- 【未知の窓】自分も、相手も知らない領域
そして大事なのは、気付きを得てどうするかです。
自分の良いところは継続していきます。悪いところを見つけたら、どうして良くないのか、自分はそれを改善したいのか、改善したいならどうやってアクションするかを考えていきます。
大人になると、誰も当たり前のことを注意してくれなくなります。相手に不快な思いをさせてしまったら謝ろうねだとか、言葉遣いに気をつけようね、なんて言ってくれる人はよっぽどいません。
自分は社交的な振る舞いや気遣いが上手くできないまま大人になってしまいました。だから自分で気付いて、直していかないといけないのだと感じています。
イライラしても言葉に出さない
怒ってる人が周りにいるのは辛いものですよね。心理的安全性も一気に損なわれてしまいます。
過去の自分は、タスク量が多く残業が嵩んでいることや、リーダーポジションにいたため会議準備や問い合わせへの回答を全て自分でこなさなければいけないことに憤慨していました。態度にもかなり出ていたと思います。
今思うと、自分に原因があることばかりでしたし、仮に理不尽な状況に立たされても苛立ちを他の方に向けるのは迷惑極まりない行為だなと反省してます。
自分にとって多すぎるタスクだって、会議準備や問い合わせだって、上司に相談したり、メンバーに依頼したりできたはずです。「他の人はできないから自分がやらなければならない。だから自分はこんなにも辛い。なんで自分だけがこんなに大変な思いをしなくちゃいけない。こんなに大変なのに、労いは少ないし見合う報酬だってない」と言ったように、他責思考のループが止まらなくなり抜け出すのが大変でした。自分の性格的に、イライラの原因が自分自身にあることが多いと気付けたのは大きかったです。
苛立ちを覚えても、まずは表に出さずに自分の気持ちと向き合うようにしています。（これがなかなか難しいんです）
いったんその気持ちの原因を探り、自分自身の考え方や行動を変えれば済む話ならさっさと変わってしまいます。（これも難しいですが）
相手の振る舞いが原因なら、一度改善をお願いしてみます。しかし他人をコントロールすることはできないので、無理な時は無理とさっさと諦めてしまうことを心がけています。（もちろんこれも簡単ではありません）
全部自分でやらない
何もかも自分でやりたい/やらなければいけないと思っていた時がありました。新しいツールを導入したり、会議で提案するための資料を作ったり、バグを見つけたら原因調査して修正したりすることなど。
確かに新たなことに挑戦して経験を積むのは良いことですが、デメリットも2点ありました。
1つは、ひとりができることなんてたかが知れているということです。
会社の事業として進めていかなければならないプロジェクトに関して、提案・設計・開発・テスト・保守に至るまでひとりでやり切るなんて、かなり難しいことがほとんどだと思います。自分が全部やろう、全部レビューしようと思っていると、自分がブロックになって必ず遅延を招きます。
2つめは、経験値泥棒になってしまうということです。
GitHub Actions でCI/CDパイプラインを作るときはどうすれば良いかとか、提案するときにどんなやり方をしたら通りやすいかなど、自分の中にノウハウと呼べるものがいくつかあると思います。そして、それは経験したからできるようになっていることが多いと思います。
それを全部自分ひとりがやってしまうということは、他人が成長するチャンスを奪ってしまうことになります。
たとえば、他人がやった仕事を横取りして自分の成果にすることに対しては、とんでもなく悪いことだなと感じます。けれど成長の機会を横取りしてしまうことに関しては、あまり悪い意識を持てていませんでした。
こころとからだの健康が何よりも大切
大人になってくると健康の大切さは身に沁みて感じます。
どんなに技術的な知見が深くても、怪我や病気で働けないならお金を稼ぐことはできません。
心が満たされていると、今まで書いてきたようなことを実践する余裕が生まれます。
自分にとっては、ポジティブに考えたり、感謝を忘れず他者を気遣ったりするためには、まず自分に精神的な余裕が必要でした。
マイナス思考に捉われ気分が沈んでる時も、ぐっすり寝て、好きなことしてリフレッシュしたら意外と大丈夫になることが多いので人間って不思議です。
人の話をちゃんと聞く
傾聴するってとても難しいなと感じています。
ミーティング中にslackの通知が鳴ったらそちらを確認したり、コーディングの続きを始めたり。
話が終わった後に全然内容を深く理解できてなかったことばかりでした。
この話は自分に関係ないな〜と思うとつい他ごとをしてしまいがちですが、話も聞いて手も動かしてなんて器用なことはほとんどの人ができないものだと思います。実際に自分に関係ある話が始まっても気づくことができませんでした。
関係ない話ばかりだったとすれば、そのミーティングはそもそも出席する必要がないものなのかもしれません。
ひとつのことだけに集中する
〜ある日の朝〜
席についてさあ仕事を始めるぞ。まずは昨日のslackの確認だな。それから今日のやることリストを作ろう。
あ、timesでAさんが共有してる記事が勉強になりそうだな。ちょっと読んでみるか。......なるほどー。記事に出てくる「リスコフの置換原則」ってどんなのだっけ。具体例探すか。
ん、slack通知来たな。先週Joinされた方が環境構築で詰まってるみたいだ。内容はどんなのだろ。
あーこれ前に自分も遭遇したことある気がするなー。ちょっとその時のメモ探してみるか。
......見つけた！けど、自己解決してたみたい。よかった。じゃあ仕事に戻るか。
あれ、そういえば何してたんだっけ？
ほとんどのことが中途半端になってしまっているのに、時間だけはしっかりかかってしまっています。
バグの原因調査をしてる時にも、資料作成をしてる時にも、集中を阻害する何かはやってくるものです。常套手段ですが、ポモドーロタイマーを使ってひとつのことに集中できる環境を作るようにしています。
継続できる学び方を見つける
自分にとってしっくりくる学び方を見つけることが大切だなと今は感じます。
日々技術が進化し、新たなサービスやツールが発表されるIT業界ですから、エンジニアというのは勉強し続けなければならない職業だと思います。そこで大事になってくるのは「継続して学び続けられる」ようになることだと思います。
学習の時間効率最大化・金銭コスト削減を追い求めるならば、世に山ほどプラクティスが溢れていると思います。自分もそういったノウハウを探してあれこれ試していました。
そうしているうちに、効率はあまり良くないけど楽しいと感じられて、お金は少しかかるけど身になると感じられる学習方法がなんとなく見えてくるようになりました。
自分にとって、世間で言われてる高コスパなやり方はカロリーが高すぎて続かなかったのです。
今はこの学び方が自分にとってやりやすいと感じています。ちょうど良いやり方というのは人によって、または時期によってバラバラだと思います。
- 本を読んで体系的な知識を自分の中に構築する
- QiitaやZenn、GoogleDiscoverでIT業界のトレンドを知る
- 調べ物をする際は公式ドキュメントを代表とする一次情報をまず参照する
- 学んだことや調べたことはNotionにアウトプットする
- 一度学んだくらいでは全ては理解できてなんかないし、そのうち覚えた情報は古くなると言い聞かせる
おわりに
読んでいただきありがとうございました。
エンジニアとしてというか、人間として大切だと思うことばかりでした。
きっと今の自分も5年後から振り返ってみたら、ダメダメな所ばかりなんだと思います。
それでも、少しでも良い人間になれるように頑張っていきたいと思います。