質問やフィードバックがありましたら、フォームからお願いします
本文は台湾華語で、ChatGPT で翻訳している記事なので、不確かな部分や間違いがあるかもしれません。ご了承ください
最近読んだ数冊の本は、職場でのソフトスキルに関するものでした。エンジニアは時にコミュニケーション、調整、協力といったことをやるのが面倒に感じることがあります。しかし、もしフリーランスで定年まで働くつもりでないなら、これらのスキルを学ぶことで将来のキャリアをより楽にすることができます。
この本「横のリーダーシップ」英語では Getting It Done - How to lead when you're not in charge と呼ばれており、あなたが上司でない時に、どうやってチーム全体を導いて正しい方向に進めるかについて述べています。
このことは一見不思議に思えるかもしれませんが、上司でないからこそ、このプロジェクトやチームの運営方法を理解しているのです。なぜなら、あなた自身が実際にその作業を行っているからです。
この本は、表紙に書かれている内容だけでも全体を要約できます:
- 参加型リーダーシップ:質問を提起 → アイデアを提供 → 行動の模範
- 仕事の要素:目標設定 → システム思考 → 計画の修正 → モチベーション管理 → フィードバックの追求
いくつかの重要なポイントを抜粋してみました。
仕事でボトルネックが発生したらどうする?
書籍に書かれていた手順は非常に明確でした:データを収集 → 可能性のある原因を分析 → 方法を選択 → 行動計画を立てる → 実行開始 → 問題を記録 → 原因を分析 → 方法を調整。
他人の考え方を考えさせるのは難しい
非難や指摘をすることは、物事を悪化させる始まりになることが多いです。なぜなら、人々は自分の間違いを認めるのが難しいからです。特に、お互いの地位や役職が同じである場合、「あなたはそうすべきではない…」という言葉は、相手に対抗心を抱かせ、事態をより厄介にします。
このような状況下では、いくつかの方法で打破することができます:
- 質問形式で提起する:例えば、「このやり方は xxx の問題があるのでは?」
- 補証と協力を求める:相手に証拠を提示させる、「あなたが言った今月のアクティブユーザーが減少した件について、関連する資料はありますか?」
- 仮定を提起し、相手に答えさせる。「もしこうした場合、何が問題になる?」
これらの方法は平凡に見えますが、相手を直接非難するよりもずっと効果的で、相手にあなたがその人に対してではなく、事に対してアプローチしていることを理解させることができます。実際には、あなたはその人をターゲットにしているのですが
問題を記録する
以前、会社で静的アセットを更新しようとした際に問題に直面しました。ドキュメントに従ってアップロードしたのに、更新が成功しないことが判明しました。この問題を解決するのに2週間かかり、iOSとAndroidの設定方法が異なるため、権限の違いによって特定の更新が表示されないことが原因であるとわかりました。
このような事柄は記録しておく価値があります。会社の共有ファイルに保存して、次回同じ人が同じ過ちを犯さないようにするためです。覚えておくのは難しいですが、少なくとも自分自身と他人の問題を解決しました。
指示を出さない
他の人にアドバイスをする際には、必ず明確に伝えなければなりません。あなたは彼らに指示を出しているのではなく、選択肢を提供しているのです。誰も批判されたり、教えられたりするのは好まないため、自分のアイデアを伝える時は命令口調を使わず、社内の共有会やブログ記事、ドキュメントなどを通じて、具体的な計画を同僚に説明し、みんなで討論することが重要です。
特にこの討論が重要なのは、討論そのものよりも、討論を起こすこと自体です。
反省
スクラムの中にはレトロスペクティブという会議があります。この会議では、スプリント中に何がうまくいったか、何がうまくいかなかったかを皆が提案します。しかし、これが単なる拍手や批判の場になってしまうことは簡単です。皆が改善点を書き出しても、結局何も変わらないことが多いです。
これが非常に問題です。何度も変化がないと、不満を心の中に溜め込み、仕事がどんどん楽しくなくなってしまいます。
目標の定義
会社や製品の目標が何か分からないと、同僚の間で衝突が起きやすくなります。例えば、ある人は製品を早くリリースしたいと思っているのに、あなたはバグをしっかりと修正したいと考えていると、お互いの製品に対する認識が異なれば、すぐに混乱に陥ります。相手のコードが乱雑で、あなたはデッドラインを心配し、リライトを要求できなくなります。
この問題を解決する最も早い方法は、目標を定義することです。もし目標が短期間で新機能をリリースすることであれば、コードの品質と開発時間の間で選択をしなければなりません。
小結
自分のキャリアを真剣に考えているのであれば、または仕事に関することをしっかりと考えているのであれば、上述のことは多少なりとも習慣になっているはずです。比較的経験のある仕事者にとっては、復習や普段の業務をより体系的に整理した内容とも言えます。
しかし、現実と理想には常に差があります。たとえ上記のことを一生懸命に行っても、意見が対立し、自分の意見を貫こうとする「豚の仲間」が現れることもあります。その際には、ぜひ「Driving Technical Change」という本をお勧めします。この本では、豚の仲間をいくつかのタイプに分け、それぞれのタイプに対処する方法を教えてくれます。
この記事が役に立ったと思ったら、下のリンクからコーヒーを奢ってくれると嬉しいです ☕ 私の普通の一日が輝かしいものになります ✨
☕Buy me a coffee