2006-05-31

ハンケチ

出向というか常駐というか派遣というか、とにかくよその会社のオフィスで仕事をしています。トイレの洗面台にペーパータオルがついていません。乾燥機もついているのですが、これの風量が著しく弱いときています。所有しているのですが、習慣になっていないので、つい忘れてしまうのです。



蛇口を手回しする洗面所であれば「他人が触った蛇口よりも、自分のちんちんのほうがキレイである」という言い逃れができます。が、非接触センサーで水が出る蛇口なのです。



しょうがないので、乾燥機でなんとなく乾かして、ワイシャツで拭いたり、階段の踊り場で、こっそり靴下の足首のあたりで拭いたりしています。



2006-05-28

ジェフリー・ムーア / キャズム



初期市場とメインストリーム市場の決定的な違いは、前者がホールプロダクトを自分で作って競争力を高めようとするのに対して、後者はそういうことをしない点にある。(p.185)

ベンダーが顧客に提供したものが一〇〇パーセント以下であるということは、残りの部分を顧客が自分で調達したか、あるいは、その分だまされたと思っているかのいずれかである。(p.188)


技術サポート業務の対象が初期市場であるという前提で組織を作っていると、メインストリーム市場の顧客からの問い合わせに対して「それは、うちの仕事ではない」と反応してしまいがちです。一方、顧客は商品として不完全であると思うかも知れません。



ホールプロダクト R&D が目指すところは、新しいものを一から作り出すことではなく、既存のテクノロジーと製品をもとにして新たな製品を作ることである。(p.338)

インテグレーションっぽいこともする、と。インテグレーションをやってこなかった組織には、こういうノウハウを持った人材がほとんどいないのが、悩ましいところです。



「ライフサイクル・イノベーション」も読まねば。



2006-05-21

トム・デマルコ / デッドライン ソフト開発を成功に導く101の法則



プレッシャーをかけても思考は速くはならない。(p.200)

やはり登場。数年前に一瞬だけ、言葉を交わしたときに「たぶん真実だと思うけれど、受け入れるのは難しい」と言うと「私もだ」と答えられました。



残業時間を増やすのは、生産性を落とす方法である。(p.200)

これも、難しそうな気がします。スプリントと慢性的残業は違うらしいです。



仕様書があいまいなのは、システムの利害関係者の間で対立が解決されていないしるしである。
入出力の完全なリストのない仕様書は、見込みなしである。仕様を明確にする最初の一歩にもならない。
(p.216)

要求仕様で悩んでいるので、これはもしかしたらヒントになるかも。ならないかも。けれど、これまでに「対立」など考えたこともなかったので、一考の価値あり。



Robert L. Glass / Facts and Fallacies of Software Engineering



Fact 9 Most software estimates are perfomed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time. (p.31)


Why are missing requirements hard to detect and correct? Because the most basic portion of the error removal process in software is requirements-driven. (p.74)


要求がはっきりしないなんていうのは、テクノロジーに疎い人たちが「伝票整理を楽にしたい」みたいことを言う場合だけだと思っていました。ですが、要求を明確にするというのは、思ったよりも難しいことを、最近知りました。サンプリングレート 1000Hz で電圧を取りたいという要求があって、CPU サイクルを節約するために DMA でまとめて転送しましょうと提案します。ところが、後になって、いやフィードバックをしたいので1 サンプルごとに値を確認したい、と言われたり。



Fact 21 For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That's not a condition to try to change (even though reducing complexity is always desirable thing to do); that's just the way it is.""" (p.58)


数字の妥当性はともかく、問題の複雑さの増加よりも、解決ソフトウェアの複雑さが大きくなることは、なんとなく同意できます。特に、ハードウェアに強く依存するようなシステムの場合には。うまく問題を抽象化すれば、ある程度簡単になりそうな気はしますが、それでもシステム側の複雑さは大きくなりそうです。使用するハードウェアの制約が問題を複雑にするのではないでしょうか。



2006-05-15

Andrew Hunt, David Thomas / The Pragmatic Progrmmer



通勤に片道2時間かかるので、読書が進んで仕方ありません。積読状態だった本を読みました。こういう機会に、英語の本も読まないと。



So the first question you have to ask yourself when someone asks you for an estimate is the context in which your answer will be taken. (p.64)

今、オンサイトでサポート業務をしていて、よく質問を受けます。このとき私の回答が、次期バージョンの設計に「そのまま」盛り込まれるのか、プロトタイプの対象になるのかは大きな違いです。



Once you think you know what is going on, it's time to find out what the program thinks is going on. (p.93)

急いでトラブルシューティングにあたるときに、このフレーズを思い出せるかが問題です。急かされて、焦って出した解決策は、往々にして後でより大きな問題になります。



Attempting to build an application you don't fully understand, or to use a technology you aren't familiar with, is an invitaiton to be misled by coincidences. (p.175)

偶然に任せた開発をしてはならぬ、と。ということは、クリティカルな業務外で、新技術や知らない技術の勉強をしなければならないということです。SICP の本も、ずーっと積読です、そういえば。



2006-05-12

計画と進捗管理と成果

上司にあたる人から特に指摘されなかったので、長期的な計画を立てずに、短期的な課題だけに注目して仕事を片付けてきました。が、上司の上司の人が、それではいかん、と。



上司(あるいは顧客、同僚等など)に文句を言われないからといって、問題がないことにはなりません。長期的な計画や問題解決が必要であることは、最初から分かっていたのですから、言われなくても自分でやるべきです。



フリーエージェントのような立場で仕事ができるので、これまで「こうやればいいのに」と思ってきたことを、実践していこうと思います。まずは、成果のあがる現実的な計画を立て、進捗管理するところから。



2006-05-11

求めよ、されば与えられん

仕事に必要なことであっても、作業中の人に声をかけるのを躊躇します。まともに仕事をしている人なら、何かしら作業しているでしょうから、こちらから声をかけないと、仕事が進まないことは分かっているのですが、躊躇します。恥ずかしがり屋というのは、自己中心的な態度なので改めるべきでしょう。そもそも生産性が落ちては本末転倒です。




  • 他人の仕事を中断してでも、最優先タスクを実行する(これができれば苦労しない)

  • 前もって時間を予約しておく

  • メールで会議予約する(でも、隣の席の人なのです)



好子(こうし)や嫌子をうまく使えないかと、考え中です。



2006-05-09

出向がはじまります

今週から出向で、他社のオフィスで勤務、のはずでした。職場に行ってみたら、今日まで休暇だったようで、誰もいませんでした。がっかり。出勤日に休むよりマシなので、結果的には問題は起こりませんでした。これからはカレンダーをしっかり確認しようと思います。



2006-05-07

年の差カップルについてどう思うか

銀座を歩いていたらテレビの人にインタビューを受けました。小泉今日子のように、年上の女性と年下の男性のカップルについて、どう思うか。と。いえ、別になんとも思いません。



そんなことより、小泉今日子のほうが気になります。



2006-05-06

Visual C++ 6.0 に挑戦

仕事で Visual C++ 6.0 を使うことになりました。共同で仕事するので、自分だけ Visual Studio 2005 を使うわけにはいきません。



書籍がほとんど売られていないので、Visual C++ 6.0 環境の効果的な使い方が分かりません。いらいらしてきたので、xyzzy でコードを書いて、cl.exe や cygwin の g++ でコンパイルしてみました。Windows API を呼ぶだけなら、ライブラリなんぞに気を使わなくてもいいようです。




#include <windows.h>
#include <iostream>
using namespace std;

DWORD WINAPI hello(LPVOID data) {

for(;;) {

cout << "hello" << endl;

Sleep(1);

}

return 0;

}



DWORD WINAPI bye(LPVOID data)

{

for (;;) {

cout << "bye" << endl;

Sleep(1);

}

return 0;

}



int main() {

HANDLE h = CreateThread(NULL, 0, hello, 0, 0, NULL);

HANDLE b = CreateThread(NULL, 0, bye, 0, 0, NULL);

Sleep(100);

return 0;

}



「g++ foo.cpp」「cl foo.cpp」のいずれでもコンパイルできます。これのほうが簡単だ。と思ったのも束の間、Visual C++ 6.0 のプロジェクトファイルが必要なのでした。