頭を使って探せ

客先にプログラムを納品したときのこと。顧客側で用意しているサーバーの環境設定に問題があって、動作確認ができないという。仕方なく、その日はプログラムのセットアップだけして帰った。

それから一週間たって電話してみると、まだ同じ問題が解決していないとのこと。このまま待っていてもどうにもならない。私は詳しく状況を聞きだした後、Google に２つの単語を入力し、検索ボタンをクリックした。そして、検索結果の先頭に出てきたページを開いた。解決策を見つけたような気がして、そのページを印刷した。

客先に行って、そのページの記述通りに設定ファイルを更新したところ、あっさり問題解決。これで一週間悩んでたの？

この顧客もネットで検索していたようだが、どうして答えにたどり着けなかったのだろう？

★

情報の検索スキルが、仕事の効率を大きく左右することがある。確かに、検索エンジンを上手く使うコツというのはあるだろう。

私が検索キーワードを選ぶときには、「見つけたい情報がどのように記述されているのか」ということをイメージするようにしている。例えば、Ｃ言語のサンプルソースを見つけたいなら、「Ｃ言語」という言葉で検索するよりは「include」とか「int」のようなキーワードを使う。

最近では、ネットの検索術に関する書籍をよく目にするようになったので、一度は目を通しておくのもよいかもしれない。

★

しかし、検索テクニックを身に着けること以上に重要なことは、問題を解決するための洞察力を身に着けることではないだろうか。

多くの場合、「検索」は問題解決のプロセスの一部でしかない。検索キーワードを選ぶ前に、答えをある程度想定し、狙いを定めなければ、答えにたどり着くまでに時間が掛かってしまう（※）。

洞察力を身につけるためには、知識や経験が必要だろうし、想像力も必要だろう。「ネットで検索」すれば誰でもすぐに答えにたどり着ける、というわけではないのだ。コンピュータが普及して便利になったというが、やはり人間には日々の精進が必要なのである。

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

※もちろん、狙いを定めるために「検索」を繰り返すことはよくある。

■関連記事
・ソースコードの盗み方
・「人に頼れる」技術者の話

とっておきの秘技 Google絶妙な検索の秘伝書

posted with amazlet on 06.07.17

持丸浩二郎蒲生睦男
シーアンドアール研究所 (2006/01)

Amazon.co.jp で詳細を見る

グーグル完全活用本

posted with amazlet on 06.07.17

創藝舎
三笠書房 (2006/02)

Amazon.co.jp で詳細を見る

誰のコード？

ソースコードを見ていると、コメントに「作者名」として自分の名前が書かれたコードがある。でも、これ、自分が書いたコードじゃないんだけど・・・。

誰かが、私のコードをコピーして作ったのだろう。必要があればコピーするのも結構だが、せめて作者名ぐらいは自分の名前にして欲しい。

★

しかし、あらためて考えてみると、組織で開発しているソースコードに、プログラマの個人名を記入する必要などあるだろうか？

そもそも、私のプロジェクトでは、ソースコードは、誰が直してもかまわない。いわゆるコードの共同所有（Collective Ownership）というやつだ。

実際、最初にファイルを作った人が書いたコードの量よりも、その後に別の人が追加・修正した量の方が多くなるようなこともある。最初の人の名前を書いておいても意味がないのだ。

★

確かに、私のプロジェクトには、「ソースコードに作者名を記入しなければならない」というルールはない。しかし、「記入してはならないと」いうルールもなかったのである。

そして、開発ツール（eclipse）は、自動的にユーザー名を "author" としてコードに記入してしまう。私も、特に気にせずに、そのまま「署名」を残してしまっていたのだ。

しかし、余計な情報は余計な誤解を生むものである。プロジェクトの開始時、コードに名前を記入しないというルールを決めておくべきだったかもしれない。

もちろん、コードを編集した人が誰なのか知りたい、ということもあるのだが、そのような場合には、ソース管理ツールの履歴を参照すればよいことだろう。

■関連記事
・簡単コピー・プログラミングの罠
・誰のためのコード？

[PR] ソース管理といえばVSS - うちではドキュメントもこれで管理してます

[PR] XPエクストリーム・プログラミング入門 - コードの共同所有について考えよう

お出口はこちら →

豆腐とウィジウィグと私

日本のプログラマが、何かというと悩まされる文字化け問題。文字化けとは、文章を書いた人と読む人で、コンピュータ環境（文字コード）が違った場合などに、文字の表示がおかしくなってしまうことだ。

プログラムとしては、文字コードが違う場合には可能な限り変換して、正しく表示しようとするわけだが、どうしても変換できない文字が出てくる。

そうした文字は、「?」だとか「・」といった文字に置き換えて表示することが多い。「■」に置き換える場合もある。

この「■」のことを「豆腐」と呼（読）んだりする。

★

「四角は豆腐、豆腐は白い」などというぐらいだから、「■」より「□」のほうが豆腐と呼ぶにふさわしいのではないかと思われるかもしれない。

近頃のコンピュータでは、白地に黒い文字で表示するのが普通だから、「■」は黒く見える。しかし、ちょっと前までは、黒地に白い文字で表示するのが普通だったのだ。当然、「■」は白い四角で表示されていた。

思えば、「WYSIWYG（ウィジウィグ）」だとか、「DTP」などという言葉が流行りはじめたころから、白と黒の逆転が進んでいったのではないかと思う。WYSIWYG とは、「What You See Is What You Get （見たままのものが得られる）」の略だ。コンピュータの画面を、白い紙に印刷した状態に近づけようということでもある。

★

しかし、私は、実は黒字に白い文字で表示されるほうが好きだ。根拠はないが、目が疲れないような気もする。

というわけで、メーラも、エディタも、Visual Studio も Eclipse も、設定で変更できるなものはなんでも黒地に白に変更して使っている。

そんな私は、黒い紙に白いインクで書いたってかまわないはずなのに、なぜ紙は白いのだろう、などとくだらないことを考えるのである。

■関連記事
・文字の選び方
・「バグ」の使い方

[PR] 文字コード超研究
[PR] 豆腐小僧双六道中ふりだし

たとえトラックにはねられても

プロジェクトリーダーのＡさんが明日死んでしまったら、このプロジェクトはどうなるのだろう？　ユーザー要件を一番把握しているＢ先輩が入院したら？　複雑な運用を１人で任されているＣ君が突然会社を辞めてしまったら？

そんな妄想をしてヒヤリとしたことはないだろうか？

システム開発に限らず、プロジェクトのチームでは、多かれ少なかれ、各メンバーで役割を分担しながら仕事を進めるものだろう。

しかし、仕事を完全な分業にしてしまうと、誰か１人でも欠けてしまったら、プロジェクトが止まってしまう。納期ギリギリにスケジュールされているような場合は致命的である。

★

そのプロジェクトから、何人のメンバーが欠けたらプロジェクトが止まってしまうか、という数字を「トラックナンバー」という。もしも、メンバーがトラックに轢かれていなくなったら・・・という例えである。

例えば、キーとなる１人のメンバーがいて、彼が抜けるとプロジェクトが止まってしまうようなら、トラックナンバーは１である。つまり、トラックナンバーは大きいほうがよい。言い換えれば、メンバーの欠落にどこまで耐えられるかということだ。

「トラックに轢かれたら」などとは物騒な話だが、要員の欠落というリスクを想定せよ、という警告を端的に表す気の利いた言葉として、しばしば使われる（※１）。

★

プロジェクトから特定のメンバーがいなくなって困るのは、「その人にしか出来ないこと」があるからだ。それは多くの場合、「その人しか知らない情報」があるせいである（※２）。

そういった意味では、トラックナンバーは、プロジェクト内の「情報共有の度合い」を表していると言ってもいいだろう。

プログラマがプロジェクトの一員としてできることは、自分がトラックに轢かれた時のことを考えることだ。つまり、「自分だけしか知らない情報」を作らないことである。仕様面にせよ、技術面にせよ、とにかく、自分が得た情報は、なんでも他のメンバーと共有するようにするのである（メーリングリストや Wiki などの仕組みを積極的に使うとよいだろう）。

もっとも、それ以前に、「お前がトラックに轢かれたら、プロジェクトがもっと円滑に進むのに」などと言われないようにしなければならないのだが・・・。

※１
あくまでも文学的表現であって、実際に算出することを想定したものではない（と思う）。
※２
それ以外にも、例えば、その人のスキルが非常に高いというときにもそういった状況になることがある。

■関連記事
・足跡の作り方（前編）
・足跡の作り方（後編）

[PR] XPエクストリーム・プログラミング入門 - ペアプログラミングでトラックナンバーを増やす
[PR] 結城浩のWiki入門 - 「Wikiって何？」という方に
[PR] Wiki Way - Wiki の生みの親が解説！

セキュリティを確保せよ

システムの開発や運用をしている会社での話。

あるシステムを利用する全てのユーザーに、新しくアカウント（ユーザIDとパスワード）を発行しようということになった。

それまでは、そのシステムを開発やテストで使う場合には、共通のアカウントが使われていた。誰もが同じユーザーIDとパスワードを使って、システムを使っていたわけだ。しかし、それではセキュリティ的に問題がある。これからはユーザーごとにアクセスを制御し、利用状況もログに記録しよう、ということになったのである。

★
しかし、発行されたユーザーIDとパスワードの一覧を見て驚いた（もちろん、一覧が閲覧できるのは限られた人間である）。ユーザーID は数字の連番、パスワードは、全員が同じ "guest" なのである。

例えば、私の ID が "005" なら、隣の席のＮさんは "006" だ。Ｎさんのパスワードも "guest" だから、私はＮさんのフリをして、そのシステムを使うことができる。ID を適当な数字にすれば、誰か知らない人になりすましてログインすることもできるだろう。

全てのユーザーが、発行後すぐに自分のパスワード変更するという前提なら、このような運用でも、問題はないのかもしれない。しかし、実際にはそんなことは望めない。しかも、このシステムでは、自分のパスワードを変更することができない（管理者に申請するしかない）のだから、なおさらである。

★
言うまでもないことだが、セキュリティはシステム（仕組み）だけでは確保できない。人間がその仕組みをどう使うかが肝心なのである。

クリックお願いします →

■関連記事
・安全なプログラムを作ろう