読書体験：ラテラルリーダーシップ

最近読んだいくつかの本は、仕事場でのソフトスキルに関するものでした。エンジニアは時にはコミュニケーションや調整、協力などのことをするのが面倒くさいです。フリーランスで働き続けるつもりでない限り、これらのスキルを学ぶことは将来のキャリアをより楽にすることができます。

この「横向きのリーダーシップ」という本は、英語では「Getting It Done - How to lead when you're not in charge」と呼ばれており、あなたがリーダーではない立場で、チーム全体を正しい方向に導く方法について説明しています。

これは少し神秘的に聞こえるかもしれません。なぜ主管ではないのにリーダーシップを学ばなければならないのかということですが、主管ではないからこそ、このプロジェクトやチームの運営方法を理解しているのです。なぜなら、あなたが実際にその仕事をしているからです。

この本の内容を要約するために、裏表紙に書かれている説明を使います：

パートシパティブリーダーシップ：問題を提起する → アイデアを提供する → 行動を示す
作業要素：目標を設定する → システム思考 → プランの修正 → モチベーションマネジメント → フィードバックを求める

いくつか重要だと思われるポイントを抜粋します。

作業が詰まった場合はどうすればいいですか？

本に書かれている手順に従えば、非常に明確だと思います：情報を収集する → 可能な原因を分析する → 方法を選択する → 行動計画を立てる → 行動を開始する → 問題を記録する → 原因を分析する → 方法を調整する。

他人の考え方を考えるのは難しいです

非難や指摘をすることは、事態を悪化させる始まりになることが多いです。なぜなら、人々は自分の間違いを認めるのが難しいからです。特に役職や地位が同等の場合、「あなたはこうすべきではない」という言葉は相手を敵対視させるだけでなく、問題をより困難にすることになります。

このような状況では、いくつかの方法で突破することができます：

質問の形式でアプローチする。例えば、「この方法で問題が起こる可能性はありますか？」
裏付けや協力を求める。例えば、「あなたは先ほど、この月のアクティブユーザーが減少したと言いましたが、関連するデータを見せてもらえますか？」
仮説を提示し、相手に質問をさせる。「これをやった場合、どうなりますか？」

これらの方法は平凡に見えるかもしれませんが、直接相手を非難するよりも効果的であり、相手にあなたが彼個人を攻撃しているのではなく、問題に対して取り組んでいることを伝えることができます。~~ただし、あなたは彼個人を攻撃しているのですが~~

問題を記録する

私は以前、会社で問題に直面したことがありました。静的なアセットを更新する必要があったのですが、ドキュメントに書かれている通りにアップロードしても更新が成功しないことに気付きました。この問題には2週間かかりましたが、結局、iOSとAndroidの設定方法が異なること、および権限の違いによって一部の更新が表示されないことが原因でした。

このような問題は記録して会社の共有ファイルに保存する価値があります。次回同じ問題に遭遇した場合に備えて、覚えておくことは容易ではありませんが、少なくとも自分自身と他の人の問題を解決することができます。

命令しないでください

他の人に助言を提供する際は、明確に伝えてください。あなたが彼らに命令しているのではなく、選択肢を提供しているのだと。誰もが批判されたり説教されたりするのは好きではありません。自分の考えがある場合は、命令的な口調ではなく、様々な方法で自分の考えを伝えることが重要です。社内の共有会議、ブログ記事、ドキュメントなどを活用して具体的な計画を同僚たちに説明し、一緒に議論することができます。

特にこのような問題について議論することが重要であり、議論すること自体が重要なのです。

反省する

スクラムでは、リトロスペクティブと呼ばれる会議があります。この会議では、スプリント中に良かった点や悪かった点を挙げます。しかし、これは批判や非難の場になりがちで、みんなが改善すべき点を書き出しても、最終的に何も変わらないことがあります。

これは非常に悪いことです。何度も同じことを繰り返すと、不満を心に抱えたまま仕事をすることになります。

目標を定義する

会社や製品の目標がわからないと、同僚との間で衝突が起こりやすくなります。例えば、相手が製品を早くリリースしたいと考えているのに対して、あなたはバグ修正やリファクタリングに時間をかけたいと考えている場合、双方の製品に対する認識の違いにより、すぐに混乱に陥ることになります。相手のコードが乱雑になり、あなたは締め切りを守ることを恐れて相手に書き直しを要求することができません。

この問題を解決するためには、最も迅速な方法は目標を定義することです。もし短期間で新機能をリリースすることが目標であるならば、コード品質と開発時間の間で選択をする必要があります。

まとめ

自分のキャリアについて真剣に考えているのであれば、または仕事について真剣に考えているのであれば、上記のことは多かれ少なかれ習慣になっているはずです。経験豊富な労働者と比較して、これらは普段行っていることを復習し、より体系的に整理したものです。

しかし、現実と理想は常に違いがあります。上記のことを努力しても、相手と対立し、自分の意見を主張し、一意孤行する仲間が現れる可能性があります。その場合は、「Driving Technical Change」という本を強くおすすめします。この本では、仲間をいくつかのタイプに分類し、それぞれのタイプの仲間にどのように対処するかを教えてくれます。