「人に頼れる」技術者の話

先輩社員が突然やってきて、「Java のソースをくれ」と言う。なんでも、VB.NET から Excel のマクロ（VBA）を呼び出したいが、やりかたがわからないのだそうだ。どこかで、私が Java で似たようなことをやったことがある、という話を聞きつけてきたのだろう。

確かに、私は彼が求めるソースコードを持っていた。しかし、それが VB.NET での参考になるとは思えなかった。同じことを実現するとはいうものの、Java での書き方と VB.NET での書き方は全く違うからである（※１）。もし、彼に Java のコードを渡しても混乱するだけだろう。かといって、私にも VB.NET での開発経験はない。結局、ネットやヘルプなどで、VB.NET の例を探すのが一番早いだろうと思った。

私はそのことを彼に伝えた。しかし、彼はとにかく Java のソースコードをくれの一点張り。しかたがないので、私は、彼の目の前でネットを検索し、彼の求める答えを見つけ出し、印刷して、注釈まで書き込んで彼に渡した。ほんの数分の作業である。

意外と親切なやつだって？　とんでもない。彼に、私が検索しているところを見せたのは、「あんたは、どうしてこの程度のことができないんだ」という皮肉のつもりだったのだ。しかし、彼はそんな私の気持ちには全く気づかない様子で、満足げに自分の席に帰っていった。

★

どうも腑に落ちない。

彼はどうして自分で情報を探そうとしないのか？　もちろん、誰かに聞いた方が早いという事柄もあるだろう。しかし、今回の場合、聞いた相手が「探した方が早い」といっているのに、なぜそうしないのか（※２）？

もっとおかしいのは、質問の仕方である。彼はなぜ単刀直入に「VB.NET で Excel マクロを呼び出す方法を教えてくれ」と言わないのか。「Java でも VB.NET でもおなじようなものだろう」という勝手な思い込みのせいだろうか？　それにしても、Java のコードが参考にならないことを伝えたにもかかわらず、それに固執するのはどういうわけだろう？

★

しばらく不思議だったが、やがて気がついた。

彼には、質問をするための口実が必要だったのだ。「私が Java で同じようなことをしたことがある」ということを、私に質問する口実にしていたのである。もし、「VB.NET による Excel 制御」について、私と彼が同じ程度の知識量だということになると、彼は私に質問する理由を失ってしまう。単刀直入に質問したとしても、「知りません。自分で調べてください」と言われたらおしまいである。

私が「Java は参考にならない」と言っても、決してそれを認めようとしなかったのは、そういうことなのだろう。質問する理由がなくなって追い返されるのは困るから、食い下がったのだ。

もしかすると、そうしていれば、私が彼の代わりに答えを探すということまで知っていたのかもしれない。だとすれば、私はまんまと利用されたことになる。どうりで彼が満足げに帰っていくはずだ・・・。

人に頼ることに慣れた人は、なるほど、そのための技術を持っているということだろう。

応援のクリックお願いします →

※１
「オートメーション」という仕組み（ActiveX 技術のひとつ）を使っていた。Java では標準的にオートメーションを扱う機能を持たないため、Windows API を直接使用するか、それをライブラリ化したものを利用することになる。私のソースでは後者だったが、当然、そのライブラリ独特の記述になっていた。一方、VB.NET には、オートメーション利用のための機能が標準で用意されており、もっと簡単にコードを記述することが出来る。（オートメーション自体が、VB ファミリで使いやすいように設計されているのだから当然なのだが）。

※２
確かに、彼は、私が使った検索キーワード（「CreateObject」のような）は知らなかったかもしれない。しかし、彼が知っている言葉（「Excel」や「VB.NET」のような）から、そのキーワードにたどり着くまでには時間はかからないはずだ。検索した結果のページから言葉を拾い、それをキーワードにして次の検索を行う。これを繰り返しすことで、答えに到着する、という方法は誰もがやっているはずだ。

■関連記事
・頭を使って探せ

何でも見つかる検索の極意

posted with amazlet on 06.02.11

笠井登志男
技術評論社 (2005/12/10)

Amazon.co.jp で詳細を見る

質問力―話し上手はここがちがう

posted with amazlet on 06.02.11

齋藤孝
筑摩書房 (2003/03)
売り上げランキング: 3,756

Amazon.co.jp で詳細を見る

聴いた話、見た話～目の疲れには

NEC が 5800 RADIO SHOW というポッドキャスティングサービスを始めた。「サーバ管理者や情報システム管理者である名付けて“サバレンジャー”なアナタに向けたスペシャルプログラム！」だとか。要するにラジオ番組である。DJ は赤坂泰彦。

マニアックな番組をやるものだと思い、聴いてみた。といっても、技術的な難しい話をするわけでもないようだ。今週は、「サバレンジャーの職業病 BEST5」というのをやっていた。内容的には、プログラマやＳＥにも共感する人は多いものだと思う。

私の場合、特に目の疲れ、視力の低下には以前から悩まされている。一日中コンピュータに向かっていると、どうしても、遠くを見る機会が少なくなる。近くばかりを見ていると毛様体（目の筋肉）を酷使し、目は疲れるし、悪くなる。

ある先輩社員は、ディスプレイを CRT から液晶に替えて、なるべく遠くに置いて作業するようにしたら、目が良くなったと言っていた。そこで、私も同じようにしてみた。しかし、私の場合、だんだん「前のめり」になって、気がつくと、ディスプレイのすぐ前まで顔が近づいているのである。これでは姿勢まで悪くなってしまう。

★

実は、近くを見ながら、毛様体を弛緩させる方法がある。昔流行った「立体視」である。横に並べた２枚の絵を自力で重ね合わせるようにして見れば、立体に見えるというやつだ（繰り返しパターンやランダムドットの中に隠すことで、１枚の絵のように見せかけたものもある）。

ソースネクストの「目がホリデー」は、パソコンのディスプレイでこの立体視をするためのソフトである。

基本的な機能は、立体視用の写真の連続表示である。あくまでも、ユーザーは自分の力で立体視を行う。簡単に出来る人も多いが、練習が必要な人もいるだろう。

上級者向けには、画像を自動的に拡大縮小する機能もある（立体視していると、近づいたり離れたりするように見える）。また、リラックスのための BGM、定期的に利用するためのタイマー起動機能などもついている。欲を言えば、使用する画像やBGMを追加、変更する機能が欲しいところである。

さて、実際に立体視をやってみると、確かにその直後は目がよく見えるようになったような気がする。逆に目が疲れたような気もしないではないが、慣れていないせいかもしれない。なんにせよ、続けてやらなければ効果があるかどうかはわからない。いつまで続くか分からないが、しばらく続けてみようか・・・。

← このブログを誰かに読ませたいと思った方は、クリックを

■関連記事
・良い机と良い椅子で良い仕事を

[PR] ダウンロード購入なら「目がホリデー」をすぐに使えます。

嬉しいこと

プログラマという仕事をやっていて、嬉しいことは何だろう。

「仕事が楽になりました」といった、ユーザーからの感謝の声を聞いたとき。もちろん、そういったことも嬉しいことではある。

しかし、私がもっと嬉しいと思うのは、気の利いたクラスが作れたとき、リファクタリング（※）してソースコードが綺麗になったとき、チューニングしてプログラムの実行が速くなったとき・・・。

やはり、自分は根っからのプログラマだな、と思う。

クリックお願いします →

※機能をそのままに、ソースコードを綺麗に書き直すこと。

■関連記事
・リファクタリング～動いているプログラムを触る
・SE が嫌い

ITで創る感動経営―顧客満足=従業員満足の仕組み

posted with amazlet on 06.05.21

青木悠子
商業界 (2004/02)
売り上げランキング: 104,514

おすすめ度の平均:

ＩＴは人のためにある

Amazon.co.jp で詳細を見る

プログラミングの心理学―または、ハイテクノロジーの人間学 25周年記念版

posted with amazlet on 06.05.21

ジェラルド・M. ワインバーグ木村泉久野靖角田博保白浜律雄
毎日コミュニケーションズ (2005/02)
売り上げランキング: 80,297

おすすめ度の平均:

多少期待はずれ

「人月の神話」の神話に並ぶ名著

Amazon.co.jp で詳細を見る

意味のないことを知る

新人プログラマにコーディングをお願いしたときの話。

　「じゃぁ、この機能は、この Data クラスを継承して作ってね。」
　「どういうことですか？」
　「だから、こんな風に MyData というクラスを作ってだな・・・。」

私は、そのへんにあった紙に簡単なコードを殴り書きして、彼に渡した。

さて、しばらくして、彼が出来ましたと言って戻ってきた。コードを見ると、確かに出来上がっている。「MyData」という名前のクラスが。いや、「MyData」というのは、説明に使っただけで、本物はちゃんとした名前にして欲しかったんだけど・・・。

よく、提出書類やなにかの記入例には、氏名欄に「日本太郎」とか、「東京花子」といった名前が書いてある。しかし、だからといって、自分が提出する書類に「日本太郎」と書く人はいないだろう。もちろん、その人が本当に日本太郎であるなら別だが。

プログラミングの例（サンプルソース）では、クラス名や関数名、変数名などに、「my なんとか」という名前が使われることがある（※１）。そうした名前は、何か意味があってつけられたものではない。ただ、「既存のものではなく、このサンプルの作者が作ったものだよ」ということを示すために、「my」がつけられているだけである。それを、そのまま本物の（つまり練習用ではない）プログラムに採用してはいけない。きちんとした適切な名前を考えるべきである。

★

サンプルソースには、他にも、「foo（フー）」とか「bar（バー）」、「hoge（ホゲ）」といった言葉がよく登場する。また、プログラムのテストのためにデータなどを入力する場合にも、「foobar」とか「ほげほげ」などと入れたりする。こうした言葉には、特に意味という意味はない。

というよりも、わざと意味のない言葉を使いたいときや、意味がある言葉を使っても仕方がないときに、こうしたものを使うのである。それなら「abc」でも「いろは」でも何でもいいじゃないかと思うかもしれない。しかし、意味がないことを明示するためにも、こうした言葉を使うほうが好ましい（※２）。

あらためて思えば、これらの言葉は世間一般には、あまり使われていないようである（「foo!」と叫ぶ芸人はいるが）。一種の隠語だろう。「foo」、「bar」をあえて普通の日本語でいえば「なんとか」、「かんとか」に相当するだろうか。「foobar」とつなげても「なんとかかんとか」に対応して都合が良い。あとは、「某（なにがし）」とか。人名に限れば、上記の「太郎」や「花子」。他にも「ほにゃらら（by 久米宏）」とか、「ちょめちょめ（by 山城新伍）」というのもあるが、どっちも死語か？

意味のない言葉ではあっても、知っておかないと、無駄に意味を調べてしまったり、妙なところで恥をかくこともある。初心者プログラマの方には、覚えておいて欲しいところである。

← このブログを誰かに読ませたいと思った方は、クリックを

※１
VB.NET では、MyBase、MyClass という予約語があるが、それはここの話とは関係ない。

※２
メタ構文変数（Metasyntactic variable）というらしい（下記リンクも参照）。他にも、「baz」、「quux」、「piyo」、「huga」など、色々ある。これらの言葉は語源が不明な場合も多いようである。調べてみると面白いだろう。

■リンク

・メタ構文変数（Wikipedia）
・hoge （はてなダイアリー）
・foo （通信用語の基礎知識）

■関連記事

・曖昧言葉
・「バグ」の使い方

ハッカーズ大辞典

posted with amazlet on 06.01.22

エリックレイモンド Eric S. Raymond 福崎俊博 Guy L.,Jr. Steele
アスキー (2002/05)
売り上げランキング: 40,307

おすすめ度の平均:

タイトルだけで退かないで

Ｌｉｎｕｘの世界に入ったら

Amazon.co.jp で詳細を見る

レイザーラモンHG

posted with amazlet on 06.01.21

レイザーラモンHG
竹書房 (2005/11)

おすすめ度の平均:

HGの魅力が満載です！

ファン必見！

レイザーラモンHG本とってもおすすめです

Amazon.co.jp で詳細を見る

建築屋は鉄を、システム屋はテストを削る

昨年から話題の耐震偽装問題。簡単にいえば、建物に使う鉄筋の量を減らすことで、材料費を安くして儲けようというわけだ。

ソフトウェアの開発プロセスは、時折、建築のプロセスに例えられる。しかし、決定的な違いがある。ソフトウェアには物質的な「材料」がないのだ。だから、材料費を削ろうにも削れないので、安心・・・なんてことは全くない。

ソフトウェアは、ほとんど「人力」で出来ている。削れるものがあるとすれば、人間の作業時間、つまり開発工数なのである。費用面でも、人月（にんげつ）ベースの価格設定をしているような受託開発では、開発工数（期間×人数）が少ないほうが、安くなる。

★

もちろん、普通のシステム開発会社が、悪意のある「偽装」をすることはないだろう（と思いたい）。問題は、顧客から無理な納期を設定された場合である。金額面での要求なら、営業的な対応もできる。しかし、開発期間が十分に確保できないにもかかわらず、納期を延ばしてもらえず、要件も削ってもらえない、といった状況は、どうしようもない（※１）。

当然、開発者は、出来ないものは出来ないと主張するだろう。見積精度云々の問題もあろうが、その道のプロが出来ないと言うのだから、出来ないとみなすのが正しい判断だ。しかし、顧客は「なんとかしてくれ」という。そして、商売上の理由だとか会社の力関係だとか、技術者には理解できない暗黒の力が働いて、結局は開発がスタートしてしまうのである。

開発者が、無理な納期を守るために、まずできることは、残業や休日出勤による作業量の確保である。この業界では、徹夜続きでおかしくなってしまった人の話は珍しくない。鉄筋を削る前に自分の命を削るあたり、耐震偽装の連中とは違うのである。

もちろん、開発手法の工夫や技術的な工夫によって、効率化できることもあるだろう。しかし、それにも限界がある。

★

もともと出来る見込みのないことが出来るはずはない。やってみたら出来ました、なんて都合のいい話は期待しないほうがよい（※２）。結局、「出来たように見せかける」ための偽装が始まる。

システム開発で削られる「鉄筋」は、「テスト工数」だろう（※３）。結果としてモノが出来る工程ではないため、削りやすいのだ。もちろん、品質を確保する上で、最も重要といってもよい工程のはずなのだが・・・。

ひどいときには、発注者の側から「テスト工数は減らしてもいいから、納期内に納めてくれ」といった要求が出されることすらある。建築業者に「鉄筋を減らしてもいいから、安くしろ」と言うのと全く同じではないか。

品質はどうあれモノが出来ればよい、という考え方が、耐震偽装問題と同じなのである。しかし、こうして納期内に納められたモノは、実は全く「出来ていない」のだ。

品質の悪いシステムを使うことは、システム化をしない場合よりも悪い結果になることも多い。それなら、最初から納期を延ばしておけばよかった、ということになるのである。

★

もちろん、開発側の問題で、納期に間に合わなくなることもある。しかし、私の経験からいえば、顧客側の無理なスケジューリングや、無理な仕様変更、要件提示の遅れなどが原因となることのほうが多いように思う。

納品を「する側」と「される側」とでは、どうしても納期というものを受け止める重さが違う。そのことが、スケジュールに対する姿勢の違いに現れるのだろう。

納期が動かせないようなプロジェクトなら、どうしてもっと早く取り組まないのか、と言いたくなることがよくある。開始が１ヶ月早かったら、無事に開発できただろうに、というケースもよくあるのだ。

システム開発を発注しようという人には、「納期厳守」という言葉がどういう意味を持つか、よく考えてもらいたいものである。

応援のクリックお願いします →

※１
単純に作業者の数を増やせばよいという問題ではない。１人で100日掛かる仕事が、100人いれば１日でできるか、といえば、そんなことはない。システム開発は「袋貼り」のような単純作業ではないのだから。そんな簡単なことも分からない人は多いのだが・・・（→ 関連記事: 続・プログラマは誰でも同じ？）

※２
この業界は見積の精度が低いので、十分ありうることではある（→ 関連記事: やってみなきゃわからないという現実）。しかし、それを期待すべきではない。

※３
「悪魔に心を売っても納期を守る！裏技術（@IT）」を読めば、システム屋は共感し、そうでない人は驚愕するだろう。これが現実である。

■リンク

・悪魔に心を売っても納期を守る！裏技術（@IT）
・耐震強度の偽装問題（Yahoo!ニュース）