悪態のプログラマ -14ページ目

悪態のプログラマ

とある職業プログラマの悪態を綴る。
入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。

新人プログラマの書いたソースコードのレビューをしていた時の話。

 「ここんとこ、複雑な書き方になっているけど、大丈夫?」
 「はい」

おかしなもので、何の迷いも無く大丈夫だと言われると、逆に不安になる。特に、彼が実務としてプログラミングを行うのは初めてだったから、なおさらだ。

 「本当に大丈夫なの?」
 「大丈夫です」

ますます不安になってしまう。どうして断言できるのか? その自信はどこからくるのか?

なぜ、「このような動作確認をしているので大丈夫です」と言ってくれないのだろう。むしろ「自信がないのでよく見てください」とか言ってくれればいいのに・・・。

もちろん、「たぶん大丈夫です」などと言われても不安ではある。しかし、それよりも「絶対大丈夫です」と言われたほうがもっと不安だ。前者の方が、「人間はミスをするものだ」ということを分かっていると思えるからだろうか。


新人プログラマには、既存のコードを参考にして書けるような、簡単な仕事をさせることが多い。そうした場合、既存のコードをきちんと理解しないまま「出来ました」といって来る人が結構いる。彼らは「既存のコードと同じようにしたので大丈夫です」と言うのだが、そのコードが何をしているのか、説明できない。そういった時、バグは生まれやすい。

また、「動いているコードをコピーしてきたので大丈夫です」という発言も多い。コピーすること自体の危険性を彼らは知らないのだ。心臓の移植手術をした医者が「動いている心臓を移植したので大丈夫です」と言ったとして、安心できるだろうか? 

彼らは何をもって大丈夫と思っているのか、分かったものではない。だから、私が「大丈夫か?」と聞くのは、彼らの「自信」が知りたいのではない。大丈夫かどうかを自分で判断したいのである。納得できるだけの理由を説明してもらいたいものだ。


・・・いや、そもそも冒頭の質問の意図はそんなことではなかった。「大丈夫?」という部分よりも、「複雑な書き方になっている」という部分の方が重要なのである。

彼が「大丈夫?」という最後の言葉にだけに反応するものだから、話がずれてしまったではないか。私が「本当に大丈夫なの?」と返した時点でコミュニケーションがおかしくなってしまっているのだ。

つまり、元々期待していたのは、例えば、「こういった理由で、やむを得ずこのような複雑な書き方になっています」といった答えである。あるいは、「どう書けばもっとよくなりますか?」と逆に質問してくれてもいい。

私の質問の仕方が悪かったのだろうか? 確かに字面どおりに受け止めれば「Yes」か「No」かの回答になるだろう。しかし、日本人なら、この程度の曖昧な意思伝達は、日常的にやっていると思うのだが。

それとも、彼が私をからかって言葉遊びをしているだけなのだろうか・・・。





■関連記事
簡単コピー・プログラミングの罠
普通の言葉



「関係の空気」 「場の空気」
冷泉 彰彦
講談社 (2006/06/21)


オフィスの日本語
オフィスの日本語
posted with amazlet on 06.08.06
高見沢 孟
アルク (1991/01)
売り上げランキング: 142,129
おすすめ度の平均: 4
4 外国人が練習するオフィスの日本語

書いていてあまり気分のいい話ではないのだが、「いない方が仕事が進む」という人がいる。仕事を任せてもミスばかりするので、結局、他の人がその何倍もの時間を割いてフォローすることになる。彼らは「マイナスの生産能力」を持っていると言ってもいいだろう(関連記事「続・プログラマは誰でも同じ? 」も参照)。

新入社員のように、教育が不十分である場合は仕方がない。OJT(現場教育)のための時間をスケジュールに織り込んでおけば済む話だ。しかし、そうでない場合も多く、困ったことだ。


かつて、私のプロジェクトにもそういうプログラマがいた。技術力が低いばかりか、欠勤、遅刻、居眠りの常習犯。おまけにコミュニケーションも苦手だった。

彼(仮にAさんとしよう)は、他社から派遣してもらった、いわゆる外注プログラマだった。全く戦力にならないので、解約してもらえないか、上司に相談した。しかし、彼の派遣元の会社が「1人分の料金で、もう1人サポートを付けます」と言って来たらしい。おそらく、その会社は人材が余って困っていたのだろう(関連記事「プログラマの出向事情 」を参照)。私の上司も、それならということで、彼の残留を決めた。

しかし、サポートのために来たはずのBさんは、素人同然の人材だった。簡単な仕事を頼んでも、彼は「Aさんの助けがなければできない」と、平然と主張するのである。しかも、そのAさんは、ほとんど出社していない状態だった。


ただでさえ無理のあるスケジュール。即戦力が必要だからこそ外注要員を入れているのに、「マイナス」をいくら加えても逆効果である。一時的に投入しているだけの他社の社員を教育してやるような余裕(工数)もない。

プロジェクトのことを考えると、彼らにはいわゆる「窓際族」になってもらうしかなかった。とはいえ、全く仕事を与えないというのも可愛そうだ(※)。2人には、誰にでもできそうな無難な仕事を見つけてやらなければならなかった。


システム開発はプロフェッショナルの仕事である。その中で、「誰にでもできる作業」を見つけることは難しい。テストデータの作成や機械的なテストの実施など、そういった作業が全く無いわけではない。しかし、そんなのは開発工程のごく一部だ。結局、バグがあっても致命傷にはならないような機能をどうにか見繕って、プログラミングしてもらうことにした。もちろん、後で作り直す覚悟の上である。

「簡単な仕事を探す」という難題。そんな本質的ではないことに頭を悩ませているプロジェクト管理者は、意外と多いかもしれない。

・・・そう思わせるほど、「マイナスの生産能力」を持つ人材が多いのも困ったものである。

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



※本当に可愛そうなのは、彼らが働かない分、余分に働かされる他のメンバーなのだが・・・。このプロジェクトは結局「デスマーチ」になってしまった。



■関連記事
プログラマは誰でも同じ?
続・プログラマは誰でも同じ?
プログラマの出向事情
たとえトラックにはねられても



プロジェクトを成功させる 現場リーダーの「技術」
岡島 幸男
ソフトバンククリエイティブ (2006/03/24)


窓際のウィンドウズ
窓際のウィンドウズ
posted with amazlet on 06.07.30
桂 文珍
PHP研究所 (2003/01)
売り上げランキング: 262,488



先日、Excel の文書ファイルを開いたら、複数のワークシートが選択された状態になっていた。このファイルはワークシートごとに月単位のデータを管理しているものだ。嫌な予感がして、2つ目のシートを見てみたら、案の定、先月のデータが今月のデータに上書きされてしまっていた。

Excel では、複数のシートを選択したまま編集すると、ちょうど複写紙のように、選択された全てのシートを "串刺し" で更新できる。いわゆる「作業グループ」という機能である(※1)。それはそれで便利なのだが、複数シートを選択していることを忘れて編集してしまうと、意図せずに別のシートの内容を破壊してしまう。

今回の場合は、以前に編集した人が、複数シートを印刷するために作業グループを設定し、そのまま保存してしまったらしい。これをやってしまうと、次にファイルが開かれたときに誤って "串刺し" で編集される危険性が高くなる。「編集 → 印刷 → 保存」ではなく、「編集 → 保存 → 印刷」という手順で操作すべきだろう。といっても、印刷した後に更に「念入りな保存」をしてしまうと、意味がなくなってしまうのだが・・・。

幸い、このファイルは、VSS (Microsoft Visual Source Safe)でファイルの編集履歴を管理していたので、さかのぼって修復することが出来た。しかし、こうしたバックアップがなかったら、大きな問題になっていただろう。「こまめなバックアップ」が功を奏した形だ。


Excel の「作業グループ」については、私自身も失敗経験がある。「作業グループ」を設定して複数のシートの文字列を置換した後、そのことを忘れて、そのまま編集をしてしまったのだ(※2)。

はっと気づいたが、もう遅かった。既に、無意識のうちに Ctrl + S キーを押してしまっていたのである。このショートカットキーは多くのソフトで「上書き保存」に割り当てられているものだ。Excel はファイルを保存する前なら「アンドゥ機能」によってデータを元に戻すことができるが、いったん保存してしまうと、それもできない(※3)。

ヘビーなコンピュータ・ユーザーには、共感される方もあると思うが、私の手は、私の意思とは関係なく、何かのタイミングで勝手に Ctrl + S を押してしまうのだ。「こまめに保存する」という習慣が、この時ばかりは仇になったわけである。この時はファイルの修正履歴も残っておらず、結局、自分の記憶を頼りに復元することになってしまった。


私はこのような失敗を幾度か経験しているため、Excel の「作業グループ」には「敏感」になっている。だからこそ、タイミングこそ遅かったが、「はっと気づいた」わけである。しかし、初心者ではそうはいかないだろう。そのまま気がつかずにファイルを保存して終わってしまっていたかもしれない。

ファイルを編集するときは、とにかく「保存すれば安心」と考えがちだ。確かに、ほとんどの場合、それは間違いではないだろう。しかし、上述のようなことを考えると、いつもそれだけでよいというわけでもないのである。


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



※1
例えば、3つのシートを選択し、1シート目のセルに「ほげ」と入力すれば、2シート目や3シート目の同じ位置のセルにも「ほげ」と入力される。また、本文中にもあるように、「作業グループ」だけを対象とした印刷や検索もできる。「作業グループ」の設定方法については、「複数シートへの一括操作-作業グループ(インストラクターのネタ帳さん) をどうぞ(TBさせてもらっています)。

※2
続けて作業していればこんなことはないのだろうが、途中で電話が掛かってきたりすると、そんなこともある。

※3
Excel の機能として、「作業グループ」の編集時に警告を出すように設定できるとか、ファイルを保存する前までアンドゥできるのであれば、この問題はある程度解消される。もしかすると、私が知らないだけで、できるのかもしれない。使っているのは未だに Excel 2000 だし・・・。



■関連記事
キーボードを使おう その2 ~ ショートカットキー ~
チームへの公開



Excel Hacks―プロが教える究極のテクニック100選
David Hawley Raina Hawley 羽山 博 日向 あおい
オライリージャパン (2004/10)
売り上げランキング: 3,859
おすすめ度の平均: 4.33
3 上級ユーザーへの入り口
5 もっと便利に使えないのかと思ったことはありませんか?
5 上級者向けのハウツー本


エクセルの基本から関数「できないこと」ができる本―エクセルの基本から関数まで読んで納得の本!

アスキー (2005/07)
売り上げランキング: 113,636
おすすめ度の平均: 5
5 待ってました


プログラミングを行う際に、既存のソースコードを流用することは多い。自分が過去に書いたコード、周囲の仲間が持っているコード、ヘルプや書籍に掲載されているコード。ネットで探せば、最新技術やマイナーな技術のものでも、何かしら発見できることだろう。

Yahoo! や Google のような一般的な検索エンジンでも、適切なキーワードを指定すれば、ソースコードを検索することができる。コードによく出てくる文字列(例えば、C言語なら「include」や「void」など)を含めて検索すればよいだろう。


こうした一般のページ検索では、コードの解説や関連情報なども見つかるので有意義だ。しかし、一方で、目的とは違った「ノイズ」を拾うことも多い。純粋にソースコードだけを検索したいような場合には、専用のサイトを使うとよい。

例えば、

 ・Koders
 ・Krugle
 ・Codase
 ・CPAN code search by gonzui
 ・codefetch{

など(※1)。こうしたサイトでは、色々なプログラミング言語のオープンソースなどから、キーワードに一致するコードを検索できる。他にも、特定の言語に特化したものもあるし、Code SnippetsSnipplr のように、コードをユーザーが登録する形のものもある(※2)。いろいろ調べてみるといいだろう。


既存のコードを流用した場合、そのプログラムの動作については、流用した人に責任がある。コードがそのまま使えるかどうかきちんと吟味し、必要なら修正しなければならない(もちろん、ライセンスの問題についても注意が必要だ)。当り前のことだと思うかもしれないが、それが出来ていない人もいる。ネットで見つけたものを安直に自分のコードに貼り付けて、不具合を出してしまうのだ。

ネットに限らず、一般に公開されているコードが正しく動くという保証はない。バグがあるかもしれないし、コンパイラのバージョンが違えば動作が変わるかもしれない。あるいは、本質的ではない部分の動作(例えば例外処理のような)が不十分だったり、自分のシステムのポリシーと合わないようなこともあるだろう。

ネットの普及により、以前に比べて簡単にソースコードを入手できるようになった。また、プログラミングの技術が多様化し、変化も速くなってきている中、コードを流用しなければならない状況もますます増えていきそうだ。であるからこそ、安易に扱うことのないように注意したいところである。

--- 2006/10/9 追記 ---
Google も Google Code Search を開始した。詳しくはこちら(MYCOMジャーナル)

--- 2007/7/31 追記 ---
Web Development Toolbox: 120+ Web Development Resources の「Code Snippets, Search Engines and Repositories」という所にリンク集あり。

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



※1
Koders では、ブラウザ(FireFox)や統合開発環境(eclipse/VS.NET)用のプラグインが公開されていて便利だ。また、Krugle については、こちら(WIRED NEWS) を参照されたい。

※2
いわゆる CGM (Consumer Generated Media) 的なサービスなので、利用者が増えるほど、使えるものになっていくだろう。



■関連記事
頭を使って探せ
簡単コピー・プログラミングの罠
簡単フレームワーク・プログラミングの罠
誰のコード?



ソースコードの反逆―Linux開発の軌跡とオープンソース革命
グリン ムーディ Glyn Moody 小山 裕司
アスキー (2002/06)
売り上げランキング: 99,535
おすすめ度の平均: 3.38
4 来しかた、行くすえを考えさせる本
4 オープンソースという概念への前提
1 訳が最悪


パクる技術
パクる技術
posted with amazlet on 06.07.16
斎藤 広達
ゴマブックス (2005/10/21)
おすすめ度の平均: 4
2 「あとがき」のメッセージが全てか?
4 ポップ且つ骨太
5 悪くない、いい書

何か作業を行う際には、ミスや漏れがないように、あらかじめ「手順書」を用意する。その作業を繰り返し行うような場合や、多くの人が行うような場合には、特に重要である。

私の職場でも手順書を作成する機会は多い。プログラマが開発環境を構築する手順、リリース時にサーバー等にセットアップを行う手順など。また、ソフトウェアのテスト項目を書いた「テスト仕様書」も手順書の一種といってもいいだろう。

手順書には、ただ作業の手順(WHAT/HOW)を書けばよいというものではない。何のためにその作業をするのかという目的(WHY)も書くべきだと思う。例えば、テスト仕様書であれば、テストの「方法」だけでなく、何を確認しようとしているかという「観点」も書くべきだ。


「目的」を書くことのメリットの一つは、作業中のトラブルに対応しやすくなることである。なぜその作業をするのか、ということが分かっていれば、作業中に予期しなかった事態が発生しても、作業者自身が対処方法を考えることができる。

例えば、

(1) C:\data を C:\databack にコピーする。
(2) foo.exe を実行


と書かれた手順書があったとしよう。(1) の作業中にディスクが一杯になって、コピーできなかったらどうするか? 不要なファイルを削除して空き容量を増やせばいいが、それが困難な場合もあるだろう。(1) の処理の目的が何か分からない以上、これ以上作業を続けるのは危険だ。(2) の foo.exe が C:\databack というディレクトリにアクセスするのであれば、続行することは出来ない。

もし、これが、

(1) データディレクトリのバックアップ
  万一に備え、C:\data を C:\databack にコピーしておく。
(2) foo.exe を実行


となっていれば、C:\data をコピーする目的は明確だ。念のためにバックアップしているだけなら、「C:」ドライブの空き容量が不足していれば、「D:」でも「E:」でもいいだろうという判断ができる(※1)。


「目的」を明確化することのもう一つのメリットは、手順の記述ミスを検出しやすくなることである。目的を満たせないような手順が書かれていれば、読む人が気づくからだ。そして、一般的には、「目的」自体を書き間違えることは、「手順」を書き間違えることよりも少ないだろう(※2)


「プログラム」が何らかの手順を示すものだとすれば、こうした作業用の手順書は、人間を制御するためのプログラムであると言えるかもしれない。手順書がプログラムなら、バグが混入することもある(※3)。手順書を書く時にも、プログラミングを行うときと同じくらいの力や情熱を注ぐべきだろう。

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



※1
もっとも、この場合はコピー先を「C:\databack」と明示する必要は無いので、あまり良い例ではないのだが・・・。

※2
もっとコメント論 」では言及していなかったことだが、同様の効果はソースコードのコメントにも期待できるだろう。つまり、ソースコードに処理の「目的」をコメントとして書いておけば、処理の実装がそれと一致していない場合に、バグとして検出することができるというわけである。

※3
昨年11月の東証の障害もそうだったのではなかったか。



■関連記事
足跡の作り方(前編)
プログラムに操られた男
もっとコメント論 ~その1~ コメントとは何か
誰のためのコード?
どこまで書くか設計書




現場の仕事がバリバリ進む ソフトウェアテスト手法
高橋 寿一 湯本 剛
技術評論社 (2006/05/10)