読書感想：横からのリーダーシップ（Getting It Done）

最近読んだ何冊かの本は、いずれも職場でのソフトスキルに関するものだ。エンジニアは往々にしてコミュニケーションや調整、協力といったことを面倒くさがりがちだが、定年までフリーランスで受託を続けるつもりでもない限り、こうしたスキルを身につけておけば今後のキャリアがずっと楽になるはずだ。

この『横からのリーダーシップ』（原題：Getting It Done - How to lead when you’re not in charge）は、自分がマネージャー（上司）の立場でなくても、いかにチーム全体をリードして正しい方向へと進めていくかを説いた一冊だ。

立場が上司でもないのに、なぜリーダーシップを学ばなければならないのか、不思議に思えるかもしれない。だが、上司ではないからこそ、プロジェクトやチームの実際の動きを正確に把握できているのだ。なぜなら、実際に手を動かして実装しているのは自分自身だからだ。

本書の内容は、裏表紙に書かれている要約を読めばほぼその全体像が掴める。

• 参加型リーダーシップ：問いを立てる → アイデアを出す → 自ら行動で示す
• 仕事の要素：目標設定 → システム思考 → 計画の修正 → モチベーション管理 → フィードバックを求める

僕自身が特に重要だと感じたポイントをいくつか抜粋したい。

仕事でボトルネックにぶつかったらどうするか？

本書で述べられているステップは非常に明確だと感じる： 情報収集 → 考えられる原因の分析 → 手法の選択 → 行動計画 → 行動の開始 → 問題の記録 → 原因の分析 → 手法の調整。

人に自分の思考パターンそのものを省みさせるのは難しい

相手を非難したり正そうとしたりすることは、多くの場合、事態を悪化させる始まりになる。人は自分の間違いを素直に認めるのが難しい生き物だし、特にお互いの役職や立場が対等である場合はなおさらだ。「そんなやり方をするべきじゃない」といった言葉は、相手に個人攻撃をされていると感じさせ、問題をより一層こじらせてしまうだけだ。

こういった状況を打破するには、いくつかのアプローチがある：

• 質問の形で投げかける。例えば、「それだと、もしかして○○のような問題が起きる可能性はないかな？」
• 根拠や協力を求める。相手に根拠を提示してもらう。例えば、「今月のアクティブユーザーが減ったと言っていたけれど、参考にしたデータを見せてもらえる？」
• 仮説を立てて、相手に答えさせる。「もしこうした場合、何か不都合はあるかな？」

これらの手法は一見ありふれているように思えるが、相手を直接非難するよりもはるかに効率的だ。相手に対しても、個人を攻撃しているのではなく、課題そのものに焦点を当てているのだと伝えられる。実際には相手を突いているのだとしても。

問題を記録に残す

僕はあるとき社内で、静的アセットを更新する際にドキュメントの手順どおりにアップロードしたにもかかわらず、正常に更新が反映されないという問題に直面したことがある。この問題の解決には2週間もかかってしまい、最終的にiOSとAndroidで設定方法が異なっていることや、権限の違いによって一部の更新が表示されないことが原因だと判明した。

こういった知見は、社内の共有ドキュメントなどにしっかり記録しておく価値が十分にある。同じ轍を踏む人が出ないようにするためだ。誰かに感謝されたり目立ったりすることは少ないかもしれないが、少なくとも自分自身と他のメンバーの問題を解決することにつながる。

命令してはならない

他人にアドバイスをするときは、決して命令しているわけではなく、選択肢として提案しているのだという姿勢を明確にしなければならない。誰だって批判されたり、説教されたりするのは嫌なものだ。何かアイデアがあるときは、命令口調ではなく、社内勉強会やブログ記事、ドキュメントなど様々な手段を通じて自分の考えを伝えるべきだ。そうして具体的な計画を同僚に説明し、みんなで一緒に議論するのだ。

特に議論においては、議論そのもの以上に「議論の場を自ら立ち上げたかどうか」が重要になる。

ふりかえり

ScrumにはRetrospective（レトロスペクティブ）と呼ばれるミーティングがある。このスプリントの中で良かった点や悪かった点をメンバー全員で出し合う場だ。しかし、この場は往々にして単なる傷の舐め合いや吊し上げの場へと形骸化しやすい。みんなで改善点を熱心に書き出すものの、結局のところ何一つ変わらない、という事態に陥りがちだ。

これは非常にまずい状況だ。何度も状況が変わらないままだと、次第に不満を心の中に溜め込むようになり、働くモチベーションは下がる一方になる。

目標を定義する

会社やプロダクトの目標が何なのかが曖昧なままだと、同僚同士の衝突も起きやすくなる。例えば、相手はプロダクトを早くリリースしたいと考えている一方で、自分はしっかりリファクタリングしてバグを潰したいと考えているようなケースだ。プロダクトに対する共通認識が揃っていないと、あっという間に混乱に陥る。相手の書いたコードは散らかり放題になり、こちらはデッドラインに遅れるのを恐れて書き直しを要求できない、といった状況になる。

この問題を解決する一番の近道は、目標を明確に定義することだ。もし短期的に新機能をリリースすることが目標なのであれば、コード品質と開発スピードのあいだでトレードオフの決断を下さなければならない。

まとめ

自分のキャリアについて真剣に考え、日々の仕事に真摯に向き合っている人なら、上述の事柄はある程度すでに習慣化しているのではないかと思う。経験のあるビジネスパーソンにとっては、普段から行っていることを復習し、より体系的に整理するための本と言えるだろう。

とはいえ、理想と現実には常にギャップがある。自分がいくら上記のことを徹底しようと努力しても、真っ向から対立してきたり、頑なに自分の意見を曲げなかったり、独断専行する困ったチームメイト（いわゆる「地雷メンバー」）が現れる可能性はある。そんなときは、Driving Technical Changeという本を強くおすすめしたい。この本ではそうした困ったメンバーをいくつかのタイプに分類し、それぞれのタイプにどう対処すべきかを具体的に教えてくれている。