Avoid Whack-a-Mole Development
モグラたたき開発から逃げろ
開発する早さの評価に関するエッセイ。
日本のSIerではバーニーさんの方が評価される傾向にありますね。
ものづくり日本という標語が盛んに叫ばれたりしています。
でも、なんか年末になるといらない工事とかがあったりして、
作りっぱなし日本という標語が適切な気がしなくもないです。
だからこそ、読んでほしい一節です。
ちなみに、前回と同じく、翻訳の詳しいところはいい加減です。
翻訳はノリが大事です。
多分怪しいところは満載なので、ツッコミ歓迎です。
それと、オレには突っ込まないけど、オレだけ知ってウッシッシな人はGoogle 翻訳にでもかけてください。
SOFTWARE PROJECT MANAGERS faces a lot of pressure to deliver fast. Time is of the essence. How can you get things done fast?
ソフトウェア開発プロジェクトマネージャーは早く提供するというプレッシャーに晒されるものである。時間が重要なのである。どうやれば早くできるのか？
Imagine you have two programmers on your team, Bernie and Rob. Both are capable, have the same amount of domain knowledge, and have equal language skills. During development, you find that Bernie finishes his feature implementations much faster than Rob.
プロジェクトに二人のプログラマーがいるとしよう。バーニーとロブだ。ふたりとも才能があり、業務知識も同等であり、開発言語のスキルも同等であるとしよう。開発の途上、機能の実装がバーニーのほうがロブよりも早いことがわかってきた。
While Bernie focuses on getting the code completed quickly, Rob spends time writing code and then refactoring it. He names the variables and methods better. Once he gets things working, he breaks the code into smaller pieces. Now he writes tests to make sure each piece of his code does what he meant it to do. When he's reasonably satisfied, he declares the coding of that functionality done.
バーニーがコードを早く完成させるのに集中しているのに対して、ロブは彼の時間の多くをコードを書いてすぐリファクタリングすることに当てている。彼ロブは変数やメソッドがより妥当なものがないか探る。彼はプログラムが動くようになったら、すぐにそのコードを小さな単位に分解する。次にはテストコードを書いて、コードが彼が想定していたとおりに動いているかどうかを確認する。彼はそれで納得した時点でやっと、機能の実装がなされたと報告するのである。
But assume you don't know these details. If you only look at the speed with which the functionalities are declared done, clearly Bernie is the better man, right?
さて、詳細を知らないプロジェクトマネージャーである君が、機能が実現されたという報告だけをもとにしたら、バーニーのほうが優れていると考えるのではないかな？
A few weeks go by, and you demonstrate the features to your customer. As usual, the customer loves your completed features, but now wants you to change and improve them. You ask your developers to make those code alterations. When you take the new and improved functionality back to your customer, they try out the features that Rob implemented and are pleased with the changes.
何週間後、とうとうお客さんにお披露目するときがやってきた。たいてい、お客さんは完成された機能に満足するんだけど、あれあれ、今回はそうでもないみたいです。ここ変えてとか、いい感じにしてって要望を出しているようです。仕方ない、君はプログラマーさんに修正をお願いすることにします。機能を改修した後にお客さんのところに持って行きました。お客さんはロブが実装した方の機能を試してみています。非常に満足しているようです。
Unfortunately, they discover something odd with the features that Bernie implemented. While Bernie has programmed in the new functions fine, now a few things that worked before don't work anymore. The customer marks these as defects, and you ask Bernie to fix them. The customer tests the features again. Now even newer, stranger things seem to be broken. What's going on here?
ただ、残念なことに、お客さんはバーニーが開発した機能におかしなところがあるのを見つけたようです。バーニーは新しい機能をいい感じにプログラムしたのですが、いくつかの機能が前と同じように動かなくなったのです。お客さんはこれを欠陥と考えたので、君はバーニーに治すようにお願いします。お客さんは機能を再びテストする。おや、なんだかあたらしい不具合が出てきたようだ。何が起こっているんだ？
If you have a child, you know what is happening. Bernie has created a Whack-A-Mole application. Whack-A-Mole is a toy. Kids are given a wooden hammer to strike moles that pop up at random. It's fun for them to be surprised by which mole pops up next. However, fixing applications with broken code popping up at random places is not fun. It is frustrating, unpredictable, and it slows your product development. Bernie was sprinting initially, but he was running in the wrong direction.
お子様をお持ちの方なら何が起こっているかわかるだろう。バーニーはモグラたたきを自分で作って、遊んでいるのだ。面白いだろう、モグラがどこから出てくるのかわからないんだから。でも、アプリケーションの修正でモグラが出てくるのは面白いことではないね。ムカつくし、迷うし、そんでもって開発のスピードを遅くしちまう。バーニーは滑り出しはうまく行ったが、とんでもねぇ方向に走ってたんだ。
While Rob appeared slower at the outset, he was actually creating superior code. His pace proved sustainable. The better quality of his initial code helped him make workable changes quickly. Plus, the test he wrote in the beginning gave him instant feedback regarding whether or not his new code was compatible with other parts of the application where the code was used.
一方、ロブの方は見かけは遅いんだけど、優れたコードを実際につくっていたのだ。彼のペースは一定であった。最初からよりよい品質のコードを記述していたので、変更にも柔軟に対応できた。それどころか、彼が最初から書いたテストコードは、新しく追加したコードが他の部分に影響するかどうかを素早く検知してくれたのだ。
When measuring time for a feature implementation, do not consider only the time it takes to write it in the first place. Add the time it takes to enhance, fix, and improve the code. Writing good quality code and tests takes time. It appears to be a short-term loss. However, it comes with a long-term gain.
Ask yourself if you want speed, or if you want to savor sustainable progress.
実装の速度を計測するときに、機能の実現に要する時間だけを測ってはイカンのだ。変更の反映、修正、コードの改善といった時間も含めて計測するべきなのだ。よいコードを書くこととテストを書くことは時間がかかる。それは一瞬時間を無駄にしているように思われる。しかしながら、長い目で見れば時間の節約になるのだ。
一瞬のスピードが欲しいのか、持続可能な進捗が欲しいのか、どっちが欲しいのか言ってごらん
ま、このブログを読む人なんて、えらいプロジェクトマネージャーなんかいないだろうけどね。
それと、お客さんに同じ機能のテストをさせるなんて、どう考えたってムダでしかない。
ソフトウェアを作りっぱなしで、お客さんになんども同じことをさせるのはどうかと思う。
