第一四半期バタバタしていた。テレビの収録、リハーサル、放送の日程は残念ながら given な条件なので変えられないのだけれど、そうじゃないときは休みを取りやすい。代休も、もちろんちゃんと取れる。部署の上司が取らせようとしてくれるのと、周りが寛容だからだろう。自分ばっかり休んでる気がするけど、気づかないふりして、代休で5日ほど休んでいる。
休んでいると、いろいろ余計なことを見るし、考える。以下は、その考えの吐露である。
きっかけはTDDである。が、TDDの話はいい。よくわからないことはあるし、テストの重要性は分かっていつつも、スキルがー、とかでまだあるべき姿に追いついていないところだ。
そこで、あるべき姿とは何か、である。かーらーの、問題の発見/定義と解決である。たとえば（さまざまな紆余曲折を経て）ちょっとしたDBがあり、Webブラウザで閲覧/更新をしたいとしよう。解決策として Django の管理画面を使うことになったとしよう。たぶんテストファーストでユニットテストを書く必要はないだろう。フレームワークのデフォルト機能使うだけなのだから、そんなものテストする工数のほうが多くなりそうだ。
一方で、そのDBに外部からアクセスできるようにし、ロールごとに細かく権限が異なるようなAPIとして提供し、課金までするとなると話が一気に変わる。おそらくは、リリース後に「ACL間違ってました、てへ」は通用しないだろうから、テストファーストかどうか知らないが、何らかの形で自動テストをしたくなるだろう。
この2つは極端だしわかりやすいんだけど、製品やサービスの機能要件、非機能要件、組織のあり方、開発サイクルなどによって、テストの位置づけは全く違うと思う。コンテクスト抜きで問題定義できないし、解決策候補の評価もできない。
ちょっと長いけれど、引用する。
たとえば、エクストリームプログラミング(XP)の方法論でよく知られている
格言のひとつに、「失敗する可能性のあるものすべてをテストせよ」があります。 初心者にとっては、これはレシピとなってしまいます。初心者は何をテストすればよいのでしょうか？オブジェクトの属性値を設定する「セッターメソッド」と属性値を取得する「ゲッターメソッド」のすべてをテストすればよいのでしょうか？プリント文をテストすればよいのでしょうか？見当違いなものをテストするのが関の山でしょう。
熟練者なら、何か失敗するか ― 正確にいえば、何か失敗する可能性が高いか ― を知っています。経験と判断力を備えているので、この格言が特定の状況（コンテキスト）において何を意味するかわかっています。
（Hunt「リファクタリング・ウェットウェア」）
あなたが置かれている状況と、私が置かれている状況が異なり、コンテクストが違うなら、TDD の意味が違う。TDDの解釈に揺れがない、としてもだ。テスト、devops の意味や位置づけもだろう。なんなら、「開発」とか「製品」とかの意味だって違う。「いやいや、テストとは〇〇だ」と言いたいかも知れないけれど、全く残念なことに、そんなことはない。比較的近いと思っている仕事の人達と話しても、違うことあるんじゃないすか？そんなことないすか？ そんなことないと、ここまでドヤ顔で書いてきた私は、ちょっと困るんですけどね。
というわけで、もうちょっと前提条件やコンテクスト明らかにしたほうが、意味のある議論や意見交換ができるんじゃないかな、と思う。私は自分のコンテクストを鑑みて、次のビールを飲む。
放置していたことを片付けた。
トライアスロン中島大会に申し込む
スイム1.5km、バイク40km、ラン10km。5年くらい毎年参加している。紙に書き込んで郵送するか、Excel のファイルをダウンロードして記入してメールするの二択。Excel ファイルが地味にチェックボックスとかになっていて、Mac にプリインストールされていた Number.app では編集できない。Office for mac の DVD を探し出したが、マウントできない。いろいろやってUSBケーブルがダメだと気付き、インストール。記入して、出場許可がでることを祈りつつ申し込んだ。
https://www.city.matsuyama.ehime.jp/shisei/shiminkatsudo/sports/triathlon.html
CDをiTunesに取り込む
Office for Mac の DVD を探していたら、音楽CDが出てきた。音楽を聞いていた時期が私にもありました。ってわけで、iTunes に取り込んでいなかったCDを取り込んだ。
- Incognito 「Beneath The Surface」
- 岡村靖幸「OH!ベスト」
- C-C-B「GOLDEN BEST」
- Dave Grusin「Now Playing」
- Thomas Hardin Trio「Satie & Debussy」
- Dave Grusin「Two For The Road: The Music of Henry Mancini」
- 渡辺美里「Sweet 15th Diamond」
- 上原ひろみ「Spiral」
- 「JET STREAM ニューヨーク/サクセスストリート」
- David Benoit 「Remembering Christmas」
- 「Now Jazz 4」
イーモバイルのsim交換
なんかよくわからないけど、機種変更した時にemチャージなるプランに変更になっていたらしいので、sim を入れ替えて、チャージや自動更新の設定をし... ようと思ったら、この sim カードはでかすぎて、pocket wifi に入らない。放置。
東京・江戸前トライアスロン
10月のレースなのだけれど、早めに申し込む。どうせぎりぎりまで粘っても、年に何回はレースをキャンセルする羽目になる。スイム0.5km、バイク12km、ラン5km。会場が、自転車で軽く自走できるくらい近いし、距離も短いので気軽に参加できる。
その他
- 先週のランニングレースの結果入力
- 昔の上司からメールに返事をかく。軽く返事を書いたんだけど、改めて丁寧に。
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 のフォームを綺麗にするんじゃなくて、マクロで自動送信するとか）、部署間での口頭での調整にしようというような、意思決定と運用は、広い意味でエンジニアリングだ。
数年前、マーケティングをやっていたとき「儲かるしくみをエンジニアリングする」というのが部署の役割だった。要件定義、開発、運用をふくめて回るようにする。そのための広告、ウェブサイト、プレゼン、他部署との調整、値付けだった。
エンジニアリングを実践する技能は、きっと組織の成果を向上させることにも使えるだろうな、と思い始めている。
