「ピープルウェア」を読んだ

　この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。

　この本はソフトウェアのプロジェクトが失敗する時は、原因が単なる技術的問題だけである場合は少なく、その前段階の人とのコミュニケーションレベルにも問題があるときが多いという話をしている。それでプロジェクトを進める上での人に関する問題をテーマにしている。

　最近は個人で作業をするというよりも、チームで仕事を進めるということが多くなりつつあるので、非常に参考になる事が多かった。印象に残った点を書いていく。

早くヤレとせかされると

早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない

　耳が痛い。でも自分自身が言われても直感的にはそうなりそうという感じだと思った。

　またこの本の関連する内容に「目標設定と生産性の関係」について書かれたところがある。こちらも非常に興味深い内容だった。
　簡単に説明する。目標をプロジェクトに関係する様々な職種の人に決めてもらい、その後そのプロジェクトの平均的な生産性がどの程度になるのか、という実験を行ったということだった。するとマネージャが決めるより、プログラマーが決めたほうが生産性が高く、さらにシステムアナリストのような見積りに特化した職業だとプログラマーが決めた時より生産性が高くなるらしい。
　しかし更に驚くことは、目標を誰も決めないということをしたプロジェクトではそのシステムアナリストが決めた時よりさらに生産性が上がったという話だった。

　この辺りの話は非常に興味深いものの、バランスが非常に難しいと思う。例えばこの話を聞いただけで単純に考えると、納期を決める必要がないものに関しては目標なしにしたほうが良いという話になる。しかし例えば以下の様な側面もあると思う。

そもそも受託で最終締め切りが決まってしまっている
自社でサービスを作っている場合に、そもそも納期を決めないといつまでも作り続けてしまう
- 生産性が高くてもやる量が増えてしまう
- このへんの話はアジャイルサムライとかにも関連する内容が書かれていたように思う

　早くヤレと言ったら良くないとか、目標設定が決まってないほうが生産性が上がるとかそういう側面もありつつ、他にも別の側面がいろいろ結びついてプロジェクトの問題になるので、チームのやり方によって結局は柔軟に考えていくしか無いんだろうなと思った。

設備警察

　第7章に設備警察という章があってこの章も非常に面白い内容が書かれている。自分なりの解釈を書く。

　オフィス環境と生産性には相関性があるらしい。そのため、環境や設備によって生産性を損なうことがあるときに、環境とかを整えるグループが出来ることがある。しかし、そのグループが実際には机はきれいにしなければならないとか、部屋は区切らなければならないとか、そのような警察のような制限をかける振る舞いをすることで、最終的に生産性は上がらないという状態になってしまうことがよくある、という話だった。

　この話もなかなか難しい。最近ではWebサービスを作る時は直感に頼りすぎず、きちんと計測しましょうという話も上がっているが、このような社内の調整とかをする時も、うまく計測やフィードバックを受けながら決めつけでやらないようにしないのといけないのかなと思った。

フロー状態

　こういう本を読んでいると必ずフロー状態という言葉が出てきている気がする。プログラマーとかしてるとこういう状態に入ることはよくあるので非常に分かりやすい。

　この部分を読んで

自分のフロー状態を作る
相手のフロー状態を邪魔しない

の両方を考えないとと思った。

　自分自身がフロー状態を作ることを考えると、例えばいま集中してる時はIRCでnickにpostfix付けるとか*1、机に集中してることを示すマークを置いておくとか、そういうやり方も考えられると思う。その辺りはまとまった集中時間を確保するために - yaotti's diaryも参考になる。

　相手のフロー状態を邪魔しない考えると、人に助言を求める時Githubで聞くとか、IRCで聞くとか、直接聞くとかを、助言をもらった時の自分へのメリットと相手のフロー状態の阻害具合をある程度考えながら行動したほうが良いなと感じた。とはいえそれを気にしすぎて新しく入った人が黙々とハマり続けるとモチベーションも時間も無駄なので、どんどんコミュニケーションを取ることは前提ではあると思う。
　あと逆に誰かがフロー状態を阻害するものを引き受けるという手もあると思う。一人がうまく引き受けることで他の人のフロー状態を阻害しないように守るという役割。こういうのを自然に出来る方が良いなと思った。