道具箱シリーズの第2弾は「同情プログラミング」の話です。
プロジェクト運営（プロジェクト「管理」ではなく）の視点から言えば、プロジェクトやチームがうまく動く方法は「うまくいかない部分」を切り去っていくことです。「切り去っていく」ということは、冷徹な感じがするような気がしますが、人を切り去るのではありません（チーム崩壊を招く「マイナス生産者」に対しては、切り捨ての手法をとりますが）、その人が何かをやるときに、うまくいかなくてマイナスになってしまう部分を切り落として捨て去ります。人なのだから、何かの間違いもするし、勘違いもするし、運が悪いときもあるし、体調が悪かったときもあるし、状況によりうまくいかない場合もあるでしょう。だから、トータルで考えるわけですが、チームとして（それは人として「成長」なのかもしれません）今よりもうまくいくためには、今、ダメである部分を少しずつ切り取っていくのが着実な方法なのです。なので、何らか状況でうまくいかなかったとき（能力が低かったというのも含めて）は、再び同じ状況に陥ったときには回避できるようにしておきます。完全に同じ状況というのはないのですが、今後も似たようなことはおきますよね。ISO9000の「是正処置」という考え方ですが、これを流用します。勿論、なんでも是正処置が必要なわけでなく、レアな場合（今後は1度も起こらないようなこと）は是正する必要はありません。苦くて忘れたい経験は、忘れ去ってしまうのがベターです。
さて、プログラミングにおいて、プログラムコードを書くということは、それなりの時間をかけて、それなりのかの人の努力の結果が示されているわけです。なにがしかに時間は、会社の給与のうちかもしれないし、自主的に家に帰って考えた結果かもしれないし、どこかの講習でお金を払って覚えた技かもしれません。1,2日のコードであれば、捨て去る勇気もあるのですが、1週間も掛かって苦労して作りあげたコードを、人情的に捨てるに忍びないですよね。ちょっとぐらいまずくても、何らかのいいところを拾うとか、かの人の心情を害さないような手段を取りたいものですよね。
ですが、残念。それらは捨て去ってしまうほうがベターなのです。
プログラムコードが、アジャイル開発的に動くものを達成するのであれば（場合によっては、「動かない飾りのコード」というものもありますから）、動かないまずいコードは、そのままゴミでしかありませんし。何の価値もありません。そこに「同情」をしてしまうと、先行き負債を抱えてしまうのは明らかなことです。いや、コード自体の負債以前に、かの人の成長機会を失ってしまうのです。
ベストな方法、かの人に書き直して貰う事です。仕事として。
うまくいかない原因は、まずい設計かもしれないし、時間がなかったのかもしれないし、予想よりも時間が掛かったかもしれない、能力が足りなかったのかもしれない、いろいろな原因があります。でも、2度めにコードを書くときは、設計の見直しや、時間をしっかりとったり、計画を立て直したり、かの人の能力だけでなく他の人の助けを求めたりすることが可能であり、それは「経験」として生きてきます。それを、本人に伝えずにこっそり直してしまったり、直すべきところを指摘して勝手にピンポイントで直してしまったりというような、かの人の「成長機会」を奪うような方法は、結果的にチームやプロジェクトにとって損失でしかありません。そう、いわゆるかの人の生産性が変わらないままになってしまうのですから。
この「同情プログラミング」をやめるのは、かの人にシビアすぎるような感じがするでしょうし、無意味につらくあたるような気がしますよね。いいえ。「同情プログラミング」をやめるためには、
- 失敗を前提として、コーディング期間の計画を立てる
- やり直しの時間を確保する
- 失敗しても問題が少ないところを新人に配置する
というプロジェクト運営/計画が必要です。それがなければ、単なる無法地帯で、プロジェクトの成否は偶然によって左右されているだけですよね。
