プログラマは誰でも同じ？

「プログラミングなんて誰でも出来ると思ってましたが、そうではないことがわかりました」

新人教育の中で、ある「生徒」から聞いた感想だ。彼はある程度コンピュータを経験している人物だったので、私は少しショックを受けた。世間では、プログラミングは誰でもできるという認識なのだろうか。

誰かが設計した設計書をそのままソースコードに変換するのが、プログラマの仕事だと思っている人もいるかもしれない。設計書があれば誰がやっても同じものができるだろうと。また、そうであるべきだという考え方もある。

しかし、設計書には、プログラムを作るのに必要な全ての情報が記述されているわけではない。そのような詳細な設計書を作る時間があるのなら、直接プログラミングしたほうが早いからだ。

システムのほんの一部のごく小さな機能を作るだけでも、プログラムとして実装する方法はいくらでもある。どのような方法をとるかはプログラマの判断に任されるのだ。そのため、同じ設計書からでも、高品質のプログラムができたり、粗悪品ができたりする。どちらに転ぶかは、プログラマの腕次第ということだ。

プログラミングとは、与えられた設計書を見ながら、更に細かいレベルの設計を行う作業であるといってもよい。つまり、プログラマが書いているソースコードとは、プログラムを作るために必要な全ての仕様が記載された、最終的な設計書なのである。

そして、その設計書を「そのまま変換してプログラムを作る」のは、プログラマではなく、コンパイラの仕事である。

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

■関連記事
・続・プログラマは誰でも同じ？

プログラマ主役型プロジェクトのススメ
～ソフトウェア開発現場で本来の力を発揮するために～

posted with amazlet on 06.04.09

細貝俊夫
翔泳社 (2004/08/07)
売り上げランキング: 191,482

おすすめ度の平均:

プログラマの役割を再認識

IT業界の本当の話

清く正しくプログラマになるには？

Amazon.co.jp で詳細を見る

達人プログラマー―システム開発の職人から名匠への道

posted with amazlet on 06.04.09

アンドリューハントデビッドトーマス Andrew Hunt David Thomas 村上雅章
ピアソンエデュケーション (2000/11)
売り上げランキング: 6,120

おすすめ度の平均:

初級PGから上級PGになるための本

SEの基本が書かれてます

達人エンジニアになる方法

Amazon.co.jp で詳細を見る

文字の選び方

システムの設計書を見ていると、同じものが違った表現で書かれていることがある。例えば、「ユーザーID」、「ユーザーＩＤ」、「ユーザＩＤ」など。更には、「利用者ID」とか、「利用者番号」、「顧客番号」などの全く違う言葉も、よく確認してみると、全て同じものを意味していたりする。

そのシステムに精通したコミュニティの中では、それでも十分通用するのかもしれないが、客観性が要求されるはず設計書としては、よろしくない。

プログラムの実装レベルでは、このようなあいまいな表記はバグに直結する。例えば、データベースのテーブルに「USERID」という項目があったとしよう。その項目のデータを参照するためには、「USERID」以外の名前、例えば「USRID」や「USER_ID」を指定しても、動かない。

★
最近のデータベースでは、項目名などに日本語（いわゆる全角文字）を使うことも出来るので、積極的に日本語を使うべきだという意見もあるが、上記のような問題を考えると、手放しでは賛成できない（他にもいわゆる「文字化け」の問題もあるし）。

受託開発では、自社でダミーのテーブルを作成し、それを使って開発することもある。そのテーブル定義が、本物と違っていたとしても、見た目が似ている場合は、なかなか気付かないだろう。そうすると、最終的に他社で開発していた本物のデータベースと結合したとたんに動かなくなる、ということもありうる。

★
もちろん、英数字にも、ゼロ「0」とオー「O」、イチ「1」とエル「l」のように、紛らわしい文字がある。しかし、そこに日本語（全角文字）が加わると、文字の種類は桁違いに増加し、その分、紛らわしい文字も増える。使う人によって表現が違ったり、似た文字と間違えたりする確率も高くなるのである。

例えば、「エロ」という２文字。１文字目は、カタカナの「エ」か、「工事」の「工」か？　２文字目は、カタカナの「ロ」なのか、喋る「口」なのか、記号の四角「□」なのか？　見た目にはわかりにくい ※１

もっと実害がありそうな例では、上に書いた「ID」と「ＩＤ」のような全角英数字と半角英数字のどちらを使うか、という問題がある。また、全角文字同士でも、例えば、アルファベット大文字のアイ「Ｉ」とローマ数字大文字の「Ⅰ」は、区別が付かないだろう。

「ー」のような「長音」の記号、これを全角のマイナス記号「－」で代用する人も以外に多い。「ユーザー」を「ユ－ザ－」と書くわけである。これが普通だと思っている人であれば、テーブル項目を定義するときにも、当然マイナス記号を使うだろう。

★
こうした文字の混乱の問題は、それぞれの開発プ口ジェクトで、ルールを明確にすることで、ある程度は回避できる。例えば、「ユーザー」ではなく「ユーザ」と３文字で書きましょうとか、「ID」には半角を使いましょう、といったことを、あらかじめ決めてしまうのである。

用語辞書を作るのもよい。日本語名だけでなく、英語表記も併記しておくと、ドキュメント作成にも、プログラミング（変数名の命名など）にも使える。Wiki などを利用して簡単に作成・参照できるようにするといいだろう。

もちろん、こうして決めたルールは、守らないと意味がない。

プ□グラマとしては、たとえ、ルールがなかったとしても、文字の選び方には日頃から気をつけていたいものである ※２

※１
「ロコミ」という言葉を Web 検索してみよう。「くちこみ」ではなく、「ろこみ」である。予想以上にヒットしたのではないだろうか？　これらは、おそらく、OCR ソフトの認識ミスだろう。

※２
ここまでの文章の中に、カタカナで「ロ」とすべき文字が、「くち」や「四角」になっているものがある。人間はそれでも読めてしまう。

文字コード超研究

posted with amazlet on 06.04.09

深沢千尋
ラトルズ (2003/07)
売り上げランキング: 25,713

おすすめ度の平均:

面白いです。

Perlの勉強になる

Amazon.co.jp で詳細を見る

Unicode標準入門

posted with amazlet on 06.04.09

トニーグラハム Tony Graham 乾和志海老塚徹関口正裕
翔泳社 (2001/05)
売り上げランキング: 80,348

おすすめ度の平均:

Localization、Internationalizationの虎の巻です

Amazon.co.jp で詳細を見る

お前がウイルスだろ！

ユーザーの意思に関わらず、他のプログラムをコンピュータから削除してしまうようなプログラムは、ウイルスだと言ってしまってもいいだろう。

あるウイルス対策ソフトを、インストールしたときの話である。

そのとき、私は常駐先の会社に、自前のノートパソコンを持ち込んで作業していた。その会社では、有名なＡ社製のウイルス対策ソフトのインストールを義務付けていた。私のノートパソコンには、既に個人的に購入したＢ社製のウイルス対策ソフトが入っていたが、その会社のネットワークを利用するには、そのＡ社製のソフトをインストールしなければならなかった。

Ａ社製のそのソフトは、企業などで大量導入するための製品で、設定などをサーバーで一括して制御するようなタイプのものだ。当然のごとく、ネットワークからインストールできるようになっていた。

指示されたまま、そのソフトインストールすると、なんと、私が入れていたＢ社製のソフトが勝手にアンインストールされてしまった。

★
競合する他社の製品とはいえ、自動的に削除してしまうとは、あきれたものである。

もしかしたら、何らかの確認メッセージが表示されたのかもしれないが、少なくとも、私は気が付かなかった。あるいは、インストール・マニュアルに書いてあったのかもしれないが、企業での大量導入を前提とするソフトのインストール・マニュアルを、ユーザーの何割が読むだろうか？

確かに、ウイルス対策ソフトというものの特徴を考えれば、Ａ社のソフトとＢ社のソフトを同時に動かすと機能的に不都合が出るようなこともあるのかもしれない。しかし、それは他社製品を自動的にアンインストールしてよい、という理由にはならない。

常識的な設計者であれば、インストール中に他社のソフトを検出したら、ユーザーに手動でアンインストールするようにメッセージを表示し、処理を中断させるところだ。

★
Ａ社のこのソフトは、ウイルスを検出・削除することを目的とした、安心感を売るソフトのはずだ。その意味では、ウイルスよりも性質が悪い。

「Microsoft Word」をインストールしたら「一太郎」が削除された、などという状況を考えてほしい。それと同じことをやっているのだ。普通なら裁判沙汰である。

ただ、私も、逆にＡ社のソフトを入れた状態でＢ社のソフトをインストールしたことは無いので、もしかしたら、お互い様なのかもしれないが。。。

それとも、ユーザー（管理者）の設定により、手動削除を促すように変更できるのだろうか？　今から考えると、そう信じたいような気もするが、とにかく、その時の私は、「今後Ａ社の製品は購入すまい」と心に決めたのである。

コンピュータウイルスの謎

posted with amazlet on 06.04.09

水野貴明
ソーテック社 (2004/11)
売り上げランキング: 535,929

おすすめ度の平均:

ウイルスの仕組み半分、コンピュータを守る方法半分

Windows初心者向け教科書!

Amazon.co.jp で詳細を見る

セキュリティウォリア―敵を知り己を知れば百戦危うからず

posted with amazlet on 06.04.09

サイレスパイカリアントンチュバキン Cyrus Peikari Anton Chuvakin
オライリージャパン (2004/10)
売り上げランキング: 29,064

おすすめ度の平均:

セキュリティ本のバランス感覚

Amazon.co.jp で詳細を見る

Javaは知っていることにしている

一概にプログラマといっても、その知識はジャンル的にもレベル的にもバラバラである。同じ仕事を頼むにしても、頼む相手によっては、一言で済む場合もあれば、何時間掛けて説明しても全く話が通じないこともある。

例えば、誰かにオブジェクト指向でのプログラミングを依頼する時に、「クラスの継承やインターフェースはわかってるよね？」というような確認をしたとする。相手が「わかってます」と答えると、こちらはそのつもりで話をする。

しかし、実際に出来上がったプログラムを見ると、実は何にも分かってなかった、といったことがある。私と彼とでは「わかっている」というレベルが違うのかもしれないが。それにしても、あまりに違いすぎだ。

★

こうした、「知ってるつもり」プログラマは、まだいい。勉強してくれというだけだ。もっと酷いのがある。「知っていることにしている」プログラマである。

プログラマの要員採用の際には、例えば「Java による開発経験者求む」といった、スキル指定の求人をよくやる。それに対して、他の会社が、経験者と偽って未経験者を売り込んでくることがあるのだ。立派な犯罪だと思うが、結構ある話だ。スキルシート（職務履歴書）が偽造される場合すらあるらしい。

個人的には、プログラム言語などの経験の有無というのは大きな問題ではないと思っている。プログラミングのセンスがある人なら、開始時点では未経験でも、すぐに経験者以上の働きを見せてくれるからだ。しかし、そういう人たちは、絶対的に少ない。ましてや、会社が嘘をついてまで売り込まなければならない人材ではないはずだ。

結局、役に立たないプログラマが、即戦力となる人材のような顔をして投入されることになるのである。

★

その会社の営業的には、それでも捻じ込めればＯＫなのかもしれない。しかし、実作業に入ればすぐにボロが出る。

捻じ込まれたプログラマも不幸である。彼はどんなにボロが出ようと、自社の信用のために「知ってるフリ」を続けなければならない。

この業界に限らないのだろうが、「スキルが低い」ということ自体が咎められることはほとんどない。彼が「知ってるフリ」を最後まで続けることができれば、「彼は Java 経験者ではあるが、スキルが低かった」という評価になる。結局、彼を派遣した会社にお咎めがいくことはないのである。

彼のプロジェクトに参加している他のメンバー達は、まるでカッコウを育てるモズのように、貴重な開発工数を割いて彼を教育し、彼が仕込んだ大量のバグを直してやるだろう。そして、次からは彼も堂々と「経験者」を自称することができるようになるというわけだ。実に巧妙である。

★

システム開発は時間と人材が命だ。限りのある工数の中でこんなことをしていると、結局、納期に間に合わないか、品質を落とすことになるだろう。そして、信用を落とすのは、求人をした方の会社なのである。

真面目くさって書くのも情けないような話だが、このような悪質な営業はやめていただきたい。人間として。それとも人間やめますか？

雇う側の人間も、そんなのに騙されないでいただきたいのである。

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

ずばりわかる! Java Javaの良いコード、悪いコード

posted with amazlet on 06.04.09

石原直樹河村嘉之丸の内とら米持幸寿日経ソフトウエア
日経BP社 (2006/03/09)

Amazon.co.jp で詳細を見る

プログラミングの宝箱アルゴリズムとデータ構造

posted with amazlet on 06.04.09

紀平拓男春日伸弥
ソフトバンククリエイティブ (2003/06/14)
売り上げランキング: 42,095

おすすめ度の平均:

考えて読むと全く問題ない。理解しにくいだけ

初級者が中上級者になるためのよいガイド

初心者にやさしいプログラミング解説本

Amazon.co.jp で詳細を見る

誰のためのコード？

プログラマたるもの、毎日、黙々とソースコードを書いていることだろう。しかし、いったい何のために書いているのかということを考えたことがあるだろうか？　「カネのため」とかいうのは無しだ。

「プログラムを作るため」というのが一般的な答えだとは思う。しかし、プログラムは単なる０と１の連続である。ソースコードを書かなければ作れないというものでもない。

プログラムが０と１で出来ているのであれば、直接０と１を入力して作ればよさそうなものだ。では、なぜそうしないのか。０と１の羅列では、人間には何が書かれているか分からないからだ。

★

質問を変えよう。ソースコードは誰のために書いているのか？　「家族のためと」かいうのは無しだ。

「ユーザーのため」という答えはありそうだ。しかし、ユーザーがほしいのは利用可能なプログラムであって、ソースコードではない。では、「コンピュータのため」かというと、そうでもない。繰り返しになるが、コンピュータは０と１の連続しか理解できないからだ。それならば、コンパイラやインタープリタのためか？　しかし、それは本末転倒というものだろう（※）。

ソースコードは、それを読む人のために書くのである。

プログラミング言語は、０と１からなるプログラムを、人間が理解できる表現で記述するために生み出されたものだからだ。つまり、何のためにソースコードを書くのか、という質問に戻ると、「読者に読んでもらうため」なのある。もちろん、ここで言う読者には、そのプログラマ本人を含む。

★

言い換えれば、ソースコードを書く場合に最も重要なことは、「読者に分かりやすく書くこと」である。

いやいや、「処理速度が速いこと」や「メモリ効率が良いこと」のほうが重要だ、という人がいるかもしれない。しかし、それは「プログラムの価値」であって、「ソースコードの価値」ではない。ただ、両者には、直接的かつ一方的な関係があって、ソースコードの書き方次第で、プログラムの価値が決まるというだけである。

それでは、どうやったら、ソースコードの価値とプログラムの価値の両方を高めることができるのか？　そのような模索こそが、今もなお新しいプログラミング言語が作られている背景にあるのではないだろうか。

★

ソースコードが読者に理解してもらうことを目的としている以上、読者に理解してもらえないソースコードは、存在価値が無い。

しかし、実際には、それに近いソースコードが、ごろごろしている。ともすれば、世の中のソースコードの大半がそういった価値の低いソースなのではないかと不安になるくらいである。

プログラミングの目的は、正常に動くプログラムを作ることではある。しかし、ソースコードを書くというときは、常に「読者の眼」というものを意識し、分かりやすい記述を心がけてもらいたいのである。

※コンパイラもインタープリタも、ソースコードをプログラム（コンピュータの言葉）に変換するもの。コンパイラは翻訳し、インタープリタは通訳する。

■関連記事
・あなたにもできること
・真夜中のコード
・誰のコード？