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

悪態のプログラマ

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

@IT の「サーバ管理をコマンドプロンプトでするのはなぜ? 」という記事を読んだ。サーバをリモートで操作する際に、GUI より CUI の方が通信データ量が少ないから、管理者はコマンドプロンプトを使うのだという。

しかし、この答えは本質を突いていない。それどころか、まるで転送量を減らすために仕方なく CUI を使っているかのようではないか(まぁ、中にはそんな人もいるのかもしれないが)。実際には、コンピュータの達人ほど、CUI を好んで使う。それもベテランの懐古主義などではなく、単に、便利だから使うのである。

とっつきやすさと便利さは必ずしも比例しない。GUI しか知らない人は CUI は不便だと思っているようだが、全くそんなことはない。用途にもよるが、むしろ便利であることも多いのだ。そのメリットをまとめれば、

 ・見えないものを操作できる
 ・操作を自動化できる
 ・処理を柔軟に組み合わせることができる

といったところだろう。


見えないものを操作できる


GUI(Graphical User Interface)では、その名の通り、ウインドウやボタン、アイコンなど、目に見えるものをマウス等で操作する。このため、見えないものを操作しようと思うと、とたんに面倒なことになる。邪魔なウインドウをかき分けたり、深いメニュー階層を辿っていったり、フォルダをどんどん開いたり、目を凝らしながらスクロールしたり・・・。とにかく目的のものを見えるようにするために、多くの労力を使わなければならない(※1)。

一方、CUI では、そのような労力は必要ない。プログラム(コマンド)はその名前をタイプするだけで動く。コマンドを「呪文」に例える人もいるが、まさに言いえて妙だ。ディレクトリの奥深くにあるファイルも、名前を指定することでコピーでも削除でも自在にできる(※2)。

つまり、自分でキッチンまで行って急須を探し回らなくても「おい、お茶」と言うだけでお茶が出てくるというわけだ。


操作を自動化できる


CUI では、キーボードからコマンドを打ち込むことで、色々な処理を実行する。このコマンドは文字列なので、テキストファイルに保存することができる。そして、ありがたいことに、そのテキストファイルは、それ自体がコマンドとして実行できる。つまり、打ち込むのが面倒くさいような長いコマンドも、テキストファイルに書いておけば、そのファイル名をタイプするだけで、実行できるわけだ。

更に、テキストファイルの中にコマンドを2以上書いておけば、異なる処理を連続して実行することができる。つまり、

 1. 薬缶で水を沸かす
 2. 急須に茶葉を入れる
 3. 薬缶の湯を急須に入れる
 4. 急須のお茶を湯呑みに入れる

といった一連の仕事が、「おい、お茶」の一言でできるというわけだ。

しかも、単にコマンドを順番に実行するだけではなく、条件分岐や繰り返しなどの制御もできる。「もしポットにお湯があれば、薬缶は使わず、ポットから急須にお湯を入れる」ということもできるのだ。もちろん、「おい、お茶」という一言だけで。

こうしたコマンドを書いたテキストファイルは、バッチファイルとかシェルスクリプトなどと呼ばれる。簡易的なプログラミング言語だと言ってもいいだろう。


処理を柔軟に組み合わせることができる


このように、CUI では、複数の小さなコマンドを組み合わせて大きなコマンドを作ることができる。ひとつひとつのコマンドは GUI アプリケーションのように多機能ではないが、自分の目的に合わせた柔軟な処理を行うことができる。

食堂の給茶機なら、ボタンひとつでお茶が出てくるが、濃さも量もお決まりである。しかし、薬缶や急須を使えば濃さも量も自由自在なのだ。

ここで重要なのは、「標準入出力」という考え方である。標準入出力の「パイプ 」というテクニックを使えば、コマンドの処理結果を、別のコマンドに渡すことができる(※3)。

お茶の例で言えば、薬缶もポットも急須も、上から液体を受け入れて、注ぎ口から次へ渡す。そうやってシンプルな道具を連携してお茶を作る過程は、まさに「パイプ」のイメージである。道具の組み合わせも柔軟で、冷めたお茶を温めたければ、急須の中身を薬缶に移すこともできる。更に、薬缶やポットは、紅茶にもカップラーメンにも湯たんぽにも使える。このように、「小さなコマンド」は多くの場合、汎用的なのだ。


CUI では、ソフトを「使うこと」と「作ること」との境界が非常に曖昧だ。まさにプログラミングの入り口であるといってもいいだろう。プログラミングを目指す人には、是非とも使いこなして欲しいと思う。

クリックお願いします →



※1
GUI の代表である Windows のエクスプローラでは、フォルダをダブルクリックしなくても「アドレス」欄にディレクトリ名を入力することで、深い階層のフォルダもすぐに開くことができる。しかし、これは、「エクスプローラという GUI の一部に、アドレス欄という CUI が付いている」と解釈すべきだろう。

※2
もちろん、「名前を知っている」ということが前提である。その点が初心者にとってのハードルではあるのだが、実際にやってみると、それほど高いハードルではないはずだ。

※3
データファイルを作らずに、データファイルの中身を受け渡す仕組みとでも言ったらいいだろうか。「標準」の名に恥じず、テキストデータを扱うコマンドのほとんどがサポートしているので、コマンド同士の柔軟な組み合わせが可能だ。



■関連記事
ファイラのすすめ
キーボードを使おう その1 ~ ホームポジション ~
キーボードを使おう その2 ~ ショートカットキー ~
キーボードを使おう その3 ~ 鉄鼠 ~



■関連リンク
コマンドで操るWindows XP - CUIのアドバンテージを堪能しよう(MYCOM PC WEB)
再入門 体で覚えるLinuxの基本(ITpro)
Windowsユーザーへ贈るUnixへの架け橋 - Cygwinを使いこなそう(MYCOM PC WEB)
次世代WindowsシェルMSH(コード名:Monad)を試す(@IT)



WindowsXP/2000コマンドプロンプトポケットリファレンス
天野 司
技術評論社 (2003/02)
売り上げランキング: 78,382
おすすめ度の平均: 5
5 良書です。
5 内容は充実


Cygwin環境構築ガイド
Cygwin環境構築ガイド
posted with amazlet on 06.04.23
伊藤 幸夫
秀和システム (2003/12)
売り上げランキング: 241,968
おすすめ度の平均: 5
5 Cygwin環境構築ガイド


Windows でディレクトリやファイルのパス(場所)を表す場合、

 C:¥Hoge¥Foo.txt

のように、「¥記号」で区切って書く。プログラミングでも、改行記号「\n」のように特殊な文字(エスケープシーケンス)を表現することがある。

しかし、なぜ通貨の単位である「円」なのか? 普通に考えると、とても不自然である。


ご存知の方も多いだろうが、この「\」は、本当は(英語圏では)半角のバックスラッシュ「\」である。つまり、上記のパスは本来、

 C:\Hoge\Foo.txt

のように表現されるべきものなのだ(※1)。

想像だが、ASCII コード(いわゆる半角文字)を日本に輸入する際、「\」を割り当てたくなって、あまり使われなさそうなバックスラッシュに置き換えたということだろう。しかし、その後、バックスラッシュがエスケープシーケンスに採用されたり、MS-DOS のパスの区切りに採用されたりと、予想以上に頻繁に使われるようになってしまったのである(※2)。


こうした「不自然さ」も、コンピュータを使っているうちに当り前のことになってしまい、全く気にならなくなる。そんなことをいちいち気にしていては、仕事にならない。

しかし、ふとしたときに「普通の人の感覚」で考え直してみると、その不自然さを再発見するのである。

これは「¥記号」の問題に限らない。この業界で長年働いていると、コンピュータを使い始めた頃に不思議に思っていたこと、不便に思ったこと、難しく感じていたことがどんなことだったのか、だんだん分からなくなってくる。

しかし、システム開発をしていると、コンピュータに詳しくないエンドユーザーの視点に立つべき時がある。また、新人プログラマを指導するなら、初心者の気持ちを理解しならなければならない。そのよう場合に「普通の人の感覚」がなければ、上手くいかないだろう。


専門的な知識を得ることで、代わりに失うものがある。初心忘るべからずと言うが、それは心がまえのことだけではないだろう。難しいことだとは思うが、なるべく「普通の人の感覚」を失わないようにしたいものである。


この記事を誰かに読ませたいという方、クリックお願いします →



※1
UNIX系の OS では、ディレクトリの区切りは「/」だが、Windows のような DOS 系の OS ではなぜ「\」なのか。「/ as the option character in CP/M (John Elliott's homepage)」 によると、まず、最初のバージョンの DOS にはディレクトリの概念がなかった。そして、コマンドラインのオプション指定に「/」が使われていた(CP/M という OS のやり方を踏襲)。そういった背景があったため、その後、Ver.2 でディレクトリの概念を導入したとき、「\」を採用したらしい。

※2
昔から金額を表示するシステムは多かっただろうから、「\」という文字は必要だっただろう。かといって、「$」のコードに割り当てると混乱するのは間違いない。ちなみに、「\」を規定した「JIS C 6220」は 1969 年にできている。C言語は 1972 年の誕生(前身のB言語は 1970年)、DOS にディレクトリが導入されたのは 1983 年である。

2006/2/44 追記
「\」や「\」の割り当ての経緯については、安岡孝一さんから情報をいただきました。下のコメント欄の「$の上に¥」を参照してください。




■関連記事
普通の言葉
文字の選び方



■関連リンク
¥記号(Wikipedia)
JIS X 0201 (Wikipedia)
文字コードで世界に出る(キャリアラボ)
DOSの歴史セミナ(Altair☆'s Page)
C言語の歴史(BohYoh.com)



文字符号の歴史―欧米と日本編
安岡 孝一 安岡 素子
共立出版 (2006/02)


Windows DOS/コマンドプロンプト辞典
飯島 弘文
翔泳社 (2003/08/23)
売り上げランキング: 3,286
おすすめ度の平均: 5
5 DOSを使う方、興味のある方には最良の書だと思います
5 Windowsでコマンドプロンプトを使う時に役に立ちました。


気が付けば、Windows 95 の発売から10年以上経っている。パソコンやインターネット環境は一般家庭にもずいぶん普及した。物心ついたときからパソコンに触れているという子供達も増えていることだろう。学校でもコンピュータに関する知識も教えるようになってきている。

私も含め、現在プログラマという仕事をしている世代は、そのような環境では育っていない。だから、今の子供は恵まれていると思うし、羨ましく思う。そして、今後は若いプログラマのスキルはどんどん上がってくだろうと期待したりもする。

しかし、本当にそうなるのだろうか?


考えてみれば、家電にしろ自動車にしろ、製品が世間に普及したからといって、その製品の開発技術が一般の人にまで普及するわけではない。

むしろ、ユーザーが増えるということは、その裏側にある技術が隠され、仕組みを知らなくても簡単に使えるようなったということだろう。例えば、AT車が普及してドライバー人口は増えたかもしれないが、「ギア」の仕組みを理解している人はむしろ少なくなったのではないだろうか。

ソフトウェアも同じだ。ソフトウェアの種類が増え、上手く使いこなせるユーザーが増えたからといって、プログラミングできる人が増えるというわけではないだろう。


また、学校教育についても、必ずしも期待できるものではない。中学校から英語を習っていても、実用的に使える人がいかに少ないことか。

これではダメだということで、小学校から英語を教えようという動きもあるようだが、私はたいして変わらないと思う。語学の習得には、豊富な実践経験が必要だが、学校の限られた時間割の中にそれを求めるのは無理な話ではないか。

経験が必要だという点では、プログラミングも同じである。学校でプログラミングが教えられるようになったとしても、それだけで実用的なプログラムが作れるようになるとは思えない(※)。


コンピュータの普及や情報教育によって、多くの人がソフトウェアに触れるようになったことは確かである。プログラマが何をする仕事か、ということを理解する人も増えているだろう。

しかし、それと同時に、必要とされるプログラマの数も増えているのだ。いかにして優れたプログラマを育てて行くか、ということは、この業界にとって依然として大きな課題のままである。


このブログの順位は? ・・・



※yasuhoの隠れ家さん『「情報」を学習する前に 』によると、情報学習はプログラミングを重要視していないということだから、なおさらである(専門学校なら話は別だろうが)。



■関連記事
プログラミングは体で覚えろ
続・プログラマは誰でも同じ?



先生に教えてほしかったこと
三好 康之
アイテック (2006/02/24)




私がプログラマという職業を勧めてもいいと思うのは、仕事でも趣味でもプログラミングがしたいというくぐらいプログラミングが好きな人である。

もちろん、プログラミングが好きなだけでは駄目で、それなりの能力も必要である。職業プログラマに必要なスキルを、

A. 社会人としてのスキル(一般常識、コミュニケーション能力など)
B. プログラマとしてのスキル(プログラミングの専門的な知識や技術)

に大別してみよう。


Bのスキルは持っているが Aのスキルが欠けている人は、プログラミングは趣味にしておくほうがよい。多くの場合、職場はそういう人を求めていない。

ソフトウェア開発には、他の技術職に比べても、Aが要求されるウエイトが大きいと思う。ソフトウェアは仕様もソフト(あいまい)なので、コミュニケーションによって詰めていったり、一般知識によって補っていったりする必要があるからだ。それは SE だけでなく、プログラマでも同様である。


Aのスキルはあるが、Bのスキルが欠けている人も、他の職種を選ぶべきだ。そのほうが、きっと幸せだろう。本人にとっても周りの人にとっても。プログラミングが好きなら、趣味でやればよい。他人に迷惑をかけない限り。


AとBの両方が欠けている人のことは、あまり考えたくない。


結局のところ、三度の飯よりプログラミングが好きで、社会人としての能力と技術者としての能力を兼ね備えた人を、プログラマとして歓迎したい。

難しいのは、就職する前に、自分のスキルがどれほどのものなのかを把握することだろう。

特に、Aについては、学生には分かりにくいものだ。これは就職後に徐々に身についていく場合も多いので、それほど心配することもないかもしれない(中には何年働いても身に付かない人もいるが・・・)。あるいは、上記の「スキル」や「能力」を「自信」に置き換えて読んでみると良いかもしれない。

Bについては、プログラミングの経験があれば、いくらか自覚できるようになるだろう。たまに、経験がないのにプログラマを志望する人もいるが、自分でプログラミングをしてみようと思わないようなら、職業にはしないほうがいいだろう。

以上、「プログラミングは職業にすべきか、趣味がいいのか? (yasuhoの隠れ家さん) 」を読んで考えたことである。


このブログの順位は? ・・・



■関連記事
プログラミングが好きですか?
恥ずかしいこと
コンピュータに興味がないプログラマ



ソフトウエア開発の必修スキル―プロジェクトを成功に導く
日経ITプロフェッショナル
日経BP社 (2005/05)
売り上げランキング: 12,676
おすすめ度の平均: 5
5 「一冊要領よくまとまったものを」という方にオススメ


SEのためのヒューマン・スキル入門―35のコーチング事例で学ぶ
芦屋 広太
日経BP社 (2004/03)
売り上げランキング: 119,239
おすすめ度の平均: 5
5 スキルアップできそうです
5 壁を乗り越えるためのヒントがここにある

世間の人々は、コンピュータシステムがどのように動くかということは、きちんと文書にまとめられているものと思っているかもしれない。プログラムは、仕様書を元に寸分違わず作り上げられるものだろうと。「コンピュータ」とか「プログラム」という言葉には、そのようなキッチリとしたイメージがある。

しかし、実際には全くそんなことはない。仕様書(設計書)が全く書かれない場合もあるし、書かれていても「嘘」であることも多い。プログラマに設計書とソースコードを渡して、そのプログラムがどのような動作をするか尋ねてみるといい。そのとき、「確実な答えが欲しい」と念を押せば、彼は必ずソースコードを読むだろう。


もちろん、設計書に最初から嘘が書かれているわけではない。システムを作っているうちに、実際のプログラムと一致しなくなってしまうのである。システム開発では、設計後に仕様変更が発生したり、想定外の問題に直面して実装方法を変更したりすることは日常茶飯事だが、そのときに設計書を修正しないからだ。

なぜ修正しないかって? そのための時間が足りないからである(つまり費用や納期の問題である)。以前に、「システム屋はテストを削る 」と書いたが、「ドキュメントの修正」も削られることは多い。

プログラムが出来たら設計書は捨ててしまえばよいと思われるかもしれない。ロケット打ち上げ時のエンジンのように、開発が軌道に乗ったら切り離してしまうわけである。それなら修正する必要もない。

しかし、設計書はシステムの開発に使われるだけではなく、ユーザーの受け入れテストや、その後の保守や改訂にも利用される。「納品物」になっていれば、捨ててしまうわけにもいかない。

そんなわけで、システム開発工程の最後に「ドキュメント整理」などというフェーズを作って、後から設計書を直すようなこともある。


仕様をドキュメントに書けば、ソースコードとの「二重メンテ」は避けられない。ドキュメントの量に比例して、メンテナンスの工数は増え、書かれていることが「嘘」になる危険性も増大する。余計なドキュメントは書かないに越したことはない。「ドキュメントの修正工数を削る」くらいなら、「ドキュメント自体を作らない」ほうが安全である。

もちろん、ドキュメントが全く不要というわけではない。顧客との意思統一のために必要なものや、他システムとのインターフェース仕様など、削れないものはある。しかし、「誰が読むの?」というようなドキュメントを大量に書かせるプロジェクトも少なくないのには困ったものだ。

「ドキュメントはとにかく多いほうがよい」と信じている人、「いつも書いているお決まりの設計書を書いておけばいいだろう」程度に考えている人は、自分の思考停止に気づくべきである。何が必要で何が必要でないか。そして、どのように書くのが良いのか、きちんと考えることが大切だ。


このブログの順位は? ・・・


■関連記事
どこまで書くか設計書



実践!コミュニケーションドキュメント徹底活用
中村 一世 清水 秀樹
翔泳社 (2004/06/09)
売り上げランキング: 46,423
おすすめ度の平均: 5
5 よい! 顧客とのコミュニケーションを高めるドキュメントを書く力が身につく


思考停止企業
思考停止企業
posted with amazlet on 06.03.25
ジャストシステム・エンタープライズソリューション協議会/JECS
ダイヤモンド社 (2005/04/14)
売り上げランキング: 7,307
おすすめ度の平均: 4.39
5 思わず頷きながら読んでしまいます。
5 さらに一段階進んだケース・スタディとして続編を期待
4 さり気ない分かりやすさ!