下っ端でも何かを成し遂げる方法 from 「Joel on Software」

今年にはいってから Joel on Softwareを読んで
先日書いたエントリーで、今年は射撃しながら前進 (15章に書かれている)を
引用しましたが、あと 1つ、とても心に残った章があったので
メモに残しておこうと思います。

たとえチームの中でたいした権限が与えられてない状況にあったとしても
自分のチームを下から改善する戦略、ということで
5つの戦略について書かれています。

個人が実行するだけでプロジェクトをずっと改善できることはたくさんある。
デイリービルドするサーバがないって？作ればいい。

「この仕組みがなくて効率悪いなぁ」とか思ってることがあるなら
どんどん自分で仕組みを作って改善していこう、ということです。
自分でやれることはやる、ですね。

たとえば、あなたのチームでは誰もバグデータベースを使おうとしなかったとする。
そんなことは気にしないことだ。
あなた自身のバグトラッキングをただ続けていればいい。
（中略）
いつかは彼らもバグトラッキングの価値を理解し、
それを使い始めるだろう。

じわじわと、というところがポイントなんでしょうね。
良さを押し付けるのではなく、良さに気づかせる。
使おうと思わせる。

できるようになりたいと思っていて、
なおかつその能力がある人々を見付け、
彼らをあなたの味方に付けるのだ。
（中略）
彼らを助けてやること。
彼らが学べるようにしてやること。

味方を見つけよう。そして支援しよう。

まずいコードを書く人への対処は
その人のコードをスクラッチから書き直そうとするのではなく
ただバグを報告し続けることで、動きを封じること、とのこと。
動きを封じられないように心がけないと、ですね＞＜

残念ながら、作業環境の変更は、どんな会社でもほとんど不可能だ。
長期リースであるために、CEOでさえ、それについては何もできないかもしれない。
（中略）
そのような環境から逃れる方法を探すこと。

人と作業時間をずらしたり、静かな場所を探したり。
自分もまわりがうるさくてどうにもならない、というときは
空いてる会議室を探して逃げ込む、とかの手は使ってますね。
避難できる場所を見つけておくとよいですね。

あなたが本当に優れた貢献者でなければ、
これらの戦略はどれも機能しない。

きちんと自分の成果を出しながらも
チームの改善につながることをせっせとやる、ということのよう。

それから最後に、

あなたは管理する立場にいなくとも、物事を改善することはできる。
しかしあなたは、シーザーの妻である必要がある。
疑惑を抱いてはならない。
そうでなければ敵を作るだけだろう。

で締めくくられています。
敵を作るだけに終わっては損ですよね。

チームがよくない、まったくやってらんねーよ、という場合でも
腐らず、まずは自分のできるところから実践して
チームを変えていけばよいのだと思います。
とにかく半径 1メートルから改善していけばよいのですね。
（本当に危険な状況で逃げたほうがいい、という場合は、逃げる必要がありますけどね）