Fitzpatrik と Collins-Sussman「Team Geek」を読んだ。体系化された方法論として書かれているわけではないので、内容をそのまま紹介することが難しい。この本で問題であると指摘されていることのうち、自分がやってきたこと、どう対処しようとしているかを書いておく。
※ 誤字脱字、分かりにくい表現、スタイルをリライト。ロジックはそのまま。-- 2014/04/24 8時半ごろ
で、でたーw 天才じゃないのがばれるのが嫌だから、途中の成果を隠奴〜w
Most programmers are afraid to share work they've just started, because it means peers will see the mistakes and know the author of the code is not a genius.
これは自分に当てはまる。そのとおりだ。だって天才じゃないって知られるの嫌じゃん。（うすっぺらい）プライドの高さと、器の小ささにかけては、世界トップレベルの自称天才にとって苦痛でしかない。
一方で、ソフトウェア開発における成果にフォーカスするとき、障害になりうる考え方だ。私の場合、確実に障害になる。妥当性のチェックを自分ひとりでできないため、間違いが組み込まれることが必至である。コードレビューでは遅すぎることもある。要件定義のミスがテストまで残ってると、修正コストが跳ね上がるという有名な話だ。つまり、早い段階から、レビューしてもらうのもっともコストが低いのに、その手段を放棄しているということだ。
もうひとつ。自分しか分からないコードやプロセスが存在すると、自分が SPOF （Single Point of Failure; 単一障害点）になってしまう。よっぽど職場で立場が危うくて、どうしても仕事を守る必要があるなら別だけど。
最近は、プロジェクトの初期段階で自分がやろうとしていること、やっていることを共有するようにしている。
で、でたーw 謙虚・尊敬・信頼の欠如でギスギスす奴〜ww
Almost every social conflict can ultimately be traced back to a lack of humility, respect, or trust.
尊敬というか、敬意を払うってことだと解釈している。
かならず最後に自分のコメントを付け足したがる病についても、触れられている。見ててだるいし、無理に何か言おうとするから、みんながす指摘してないけど瑣末なこと言ったりとかになりがち。つまり、なんの付加価値もない音声のやりとりを待つ時間が増えるということだ。気をつけよう。最近、多い気がする。
以前から気をつけているのは「バグを憎んで人を憎まず」である。悪意や極端な怠慢でないかぎり、バグについて人を責めたりしない。ひとつは、自分が責められたくないから。もうひとつは、さっさとバグを修正することに集中して欲しいからだ。
で、出ーw べき論だけ語って、イライラ奴〜www
If you focus on the way thing should be in your organization, you'll find nothing but frustration and disappointment.
現状把握、問題解決、具体的なアクションを考えろ、ということなのだ。
そして自己アピールや昇進は悪ではないことを、受け入れるときなのかも知れない。組織上の上位のポジションであるが故に実現しやすいこと、というのは確実に存在する。発言力だって大きくなる。もちろん責任は増えるだろうし、非合理的な人間の相手をする必要もある。
ソフトウェア開発者にはひとつ有利な点がある。自動化や成果の複製が容易なのだ。やったことを/作ったことを複製するというオプションが存在する。システム化してしまおう（Excel のフォームを綺麗にするんじゃなくて、マクロで自動送信するとか）、部署間での口頭での調整にしようというような、意思決定と運用は、広い意味でエンジニアリングだ。
数年前、マーケティングをやっていたとき「儲かるしくみをエンジニアリングする」というのが部署の役割だった。要件定義、開発、運用をふくめて回るようにする。そのための広告、ウェブサイト、プレゼン、他部署との調整、値付けだった。
エンジニアリングを実践する技能は、きっと組織の成果を向上させることにも使えるだろうな、と思い始めている。
