未来のいつか/hyoshiokの日記

hyoshiokの日々思うことをあれやこれや

Do not convince your boss but do it. (上司を説得しようとするくらいなら、とっととやれ)

今日の読書会は、ちょっと雑務でごたごたしていて、遅れぎみだったら早瀬さんから電話がかかってきて、「ビール足りないすよ」ということなので、近所のコンビニによって、ビールとつまみを調達して参加した。いつのまにかに、参加者が8人になっていて、毎回会を重ねるごとに徐々に増えてきて喜ばしい。


「ビールです」(どや顔)。「お〜〜〜」(一同)。

今日は第4章「Implementing a Test Strategy(テスト戦略の実装)」。るかさんが綺麗なプレゼン資料を用意していて、それをもとに皆であーだこーだと議論を深めた。

テストの類型でBusiness-Facing vs Technology Facingという軸とDevelopment Process vs Critique the Projectの軸というBrian Marickが提唱した4象限のものを使いながら説明して、自動化できるもの手動でやるものなどをあれやこれや話した。

わたしなんかは、テストなんかはほとんど自動化できるのだから手動でやるなんて意味がわからない程度の立場で過激なことを言いまくったのだけど、もちろん様々な大人の事情でそうもいかないということは、頭の上では理解しているつもりである。納得はしていないけど。

若いエンジニアが、Continuous Deliveryに影響され、やっぱ自動化テストですよね、CIですよねー、なんて言ったりするのだけど、「上司にどうやって説明して、CIを導入するのがいいんですか」というような質問を投げかけてきた。

そのわたしの回答が「Do not convince your boss but do it(上司を説得しようとするくらいならとっとやれ)」だ。

ちなみに、この読書会は、英語の本を読んで、英語で議論するというとんでもない読書会である。いやまさかと思うかもしれないが、Jonathanというシニアな人が参加してくれているおかげで、英語の勉強にもなって一石二鳥なのである。

非機能要件のテスト、例えばCapacity Test, Availability Test, Security Testなんかを自動化するにはどうしたらいいんだ、あーだこーだ。ここでCapacity testは性能とかスケーラビリティとか試験することとすると、production systemと同様の構成で同様の負荷をかけないとできないので、実施は難しい、それをどうやって、実施するのか、などということを議論した。

一番素朴な方法は本番環境と同じ環境をもう一セット用意して、それで検証するというものだが、プロプラエタリな高価なハードウェアと高価なソフトウェアを利用したシステムだとそれも簡単にはいかない。インターネット時代のベストプラクティスは、そのような高価なハードとソフトを利用するのではなく、コモディティのハードと、オープンソースを利用して、構築する。それによって、本番と同様なシステムを廉価に準備できて検証が行えるというものである。金がうなるようにあるんだったら高価なハードとソフトを使ってもいいんだけどね、みたいな議論をした。

まあ、極度に単純化しているけど、そのようなことである。

でもって、上司の話である。

君が本当にそれが正しいと信じているのならやればいい。それだけである。

上司を説得するのに貴重な時間を費やして双方消耗するくらいなら、Do the Right Thingである。もちろん、間違う場合もあるだろうけど、その場合はやり直せばいい。

許可を求めるな謝罪せよ。*1 *2

そのような価値観である。

今週のヨタ話ということで、自称プロのよっぱらいとして、publickeyで紹介されていた、ハッカー中心の企業文化とは何かについて、お話を続けた。*3

Kent BeckがXPでCIという言葉を初めて使ったのが1999年だそうだが、それよりはるか以前にわたしの日記でもあきらかのようにCIという名前ではないが、同様なプラクティスは大規模ソフトウェア開発の現場では日々普通に行われていた。

Release Early, Release Often(素早くリリース、しょっちゅうリリース)のような標語(?)は標語になる前から、現場では共有される価値観であった。

その価値観は、暗黙知として口伝で伝承されていて、外部に伝わるには民族誌で共有される以外にはほとんどなかったし、それが形式知になって、教科書に記述されるまで何年もかかる。今、この教科書を読んでいるそのエッセンスはわたしが、20数年前に新人としてエンジニアを生きてきた現場にあったがそれが記述されるまでにはそのくらいの時間が必要だということである。

IT産業で生き残る(笑)サバイバルガイドとしての民族誌を書くとすれば、まさにそのような暗黙知を丹念に記述したものにならざるを得ない。

上司を説得しようとするくらいならとっととやれ。
というのは、そのような価値観かと思う。

その方が、環境の変化に素早く対応できるし、失敗したときの痛手も小さい。常に微調整しながら最適化していく方法論であり、環境に適応していく。

上司の役割は、そのようなことを部下にやらせることなんだと思う。言うのは簡単だけど行うのは難しい。

Jenkins実践入門を、技術評論社の傳さんからいただいたのだが、若手の迷えるエンジニアには、四の五の言わず、とりあえずこれでも読んでJenkinsをインストールしてCIしちゃえ、話はそれからだ、というようなことをそそのかしておいた。

*1:許可を求めるな謝罪せよ。 http://d.hatena.ne.jp/hyoshiok/20110205#p1

*2:インターネットなんつーものはね、許可なんか求めていないクレージーな人たちによって作られてきたんだよ。それによって社会はすごくよくなったんだ。もし彼らが許可を求めていたら何も起こらなかった。そんな社会を我々は求めているのか。そーゆーことだと思う。許可を求めるな。謝罪せよ。 http://twitter.com/#!/hyoshiok/status/33183999060873216

*3:開発現場のノウハウをもっと共有して、ハッカー文化を企業に根付かせよう http://www.publickey1.jp/blog/11/post_190.html