雨です。。。

今日から京都は雨です。

なんか久々にちゃんと降ってるんちゃうかな？

でもあんまり雨って好きじゃないのよね。
蒸し暑くなるし、スーツが濡れるし、洗濯物も乾かんし

まぁ、天気に文句を言ってもしかたないんで、雨の日も楽しみましょ。

そんなこんなで、今日は久々にコーディングしました。
ちゃんと(そんなちゃんとしてないけど)したのは、数ヶ月振りぐらいちゃうかな？

しかも、久々にJavaScriptを触りました。

よくalert()ってして、コードの確認とかするんやけど、それがassert()って書いてて、何で動かないのか数十分真剣に悩んでました。。。

ユニットテストのコードと完全に混がらがってましたね。

でも、これって意外と重要なことですよね。
alert()とassert()を間違えたことではないですよ！！

自分がバグと思っていないところにバグがあるということです。
本人がバグだと思わなかったらそれはバグではないことになります。
(これは完全に動いてなかったけど・・・)

そうした先入観を持って開発したり、テストしてたりしたら、さらにそれが同じ人だったら危ないですよね？

よく「レビューを強化する」とか「チェックシート」を作成するとか言いますけど、それをしたからって根本的な解決にはなってないような気がします。

アジャイルなんかでペアプロとかあるけど、あれって実はメチャメチャ大事なことなんじゃないかなって思います。
実際にコードを複数人で見たり、触ったりするから一人でやるより確実にバグが見つかります。
しかも、レビューやチェックシートに比べて効果的ですし、何より知識の共有化が行われるのがすばらしい！！

こういうのって「リーナスの法則」とか言われたりするけど、オープンソースの品質が高いのは、こういうことがあるからなのかなと感じます。

ただ、絶対的な根拠はないし、ちゃんとしたっていうエビデンスもないから組織としては管理しにくいんだと思います。
それに、複数人でやるから時間の無駄だったり、それぞれのスケジュールが合わなかったりと運用が難しい面があるかもしれません。
現場レベルで嫌われたりもしますよね。

大事だとは思うけど、導入するにはハードルが高いし、反対意見も少なくない。このことだけではないけど、組織のプロセスを変えるのは簡単なことではないです。

自分もこの手のことについては、いろいろと苦労してきました。
そして、何も変えることはできませんでした(爆)

でも、
現場を良くしたいですよね？
イイものをお客さんに提供したいですよね？
そして、みんなが笑顔で仕事ができるようにしたいですよね？
もちろんお客さんも含めて！！

僕はそう思ってます。

人は簡単には分かり合えないし、理解し合えない、変えられることに抵抗してしまう生き物です。
でもそれでも僕は伝えたいです・・・