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

悪態のプログラマ

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

職業プログラマや SE は、他の会社へ出向(派遣)させられることが多い。私自身もひとつの会社に属していながら、これまで色々な職場で働いてきた。

自分にとって、出向には良い面も悪い面もあった。色々な人に出会ったり、色々な会社の内側を見たりすることは、よい人生経験になったと思う。しかし、自宅から通えないような遠隔地へ長期的に出向させられた場合など、個人生活に大きな影響が出ることもあった。

会社によっても違うとは思うが、この業界に就職を考えている人は、そのあたりの事情もよく知っておいたほうがいいだろう。


社員を出向させれば簡単に儲けが出せるから、会社としては「おいしい」のだろうと言う人もいる。しかし、必ずしもそうではない。人材派遣業としてやっているのなら別だが、システム開発を主とする会社にとって、技術者を他社に出向させることは、あまり良いことではない。

まず、社内のプロジェクトで要員が不足したときに困る。社内に人がいなければ、結局、別の会社から人を派遣してもらうことになるだろう。つまり、他社に人を派遣しておきながら、自社も別の会社から人を派遣してもらう、という不自然な状態になってしまうのである。

また、自社が以前に開発したシステムについて、トラブルが発生したり、バージョンアップの依頼が来たときにも困ることがある。そのシステムについて詳しい人が、全員社内に残っていないということがあるのだ。

他にも、社内で働く人と社外で働く人の条件の違いが不公平感を生むようなこともあるし、社員の教育・育成の面でも、情報セキュリティの面でもよくないだろう。


では、なぜシステム開発会社は社員を出向させるのだろうか。

システムの受託開発では、仕事の受注に応じて、プロジェクトがいくつも立ち上がっては、終わっていく。このため、良く言えば「柔軟」に、悪く言えば「場当たり的」に技術者を異動することになる。

こうした要員の異動は部署内、会社内にとどめるのが理想だ。しかし、実際には会社全体の仕事の量が過不足になるようなことも多いのだ。営業力の弱い中小企業ではよくある話だろう。また、大手は大手で、大規模なプロジェクトを動かすため、やはり要員過不足の波は大きい。

人が足りない場合は、システムの一部の機能や一部の工程を下請けに出す方法もあるし、フリーの技術者や人材派遣会社から集めるという方法もある(スキルが要求されるので、アルバイトでは難しいのだが)。

しかし、人が余っているという場合にできることは案外少ない。そこで、人手不足の同業他社に出向させるわけだ。受け入れる側としても、他社の技術者を入れる方がフリーの技術者を集めるよりも簡単だし、契約面や能力面での安心感もあるだろう。

要するに、出向の大きな原因は、個々の会社が受注する仕事の量が安定しないということなのである。巨視的にみれば、システム開発業界全体が、出向という手段を使って要員調整を行っているとも言えるだろう。


このように、プログラマという職業も、意外と人との出会い(そして別れ)が多いのだ。たまに、「人と接することが苦手だから」という理由でプログラマを志望するような人がいるが、それはあまり正しい判断とは言えないだろう。

クリックお願いします →



■関連記事
プログラマとして歓迎したい人とは



ザ・ベスト 有能な人材をいかに確保するか IT Architects’Archive ソフトウェア開発の課題
ジョハンナ・ロスマン 滝沢 徹 鈴木 憲子
翔泳社 (2005/08/30)
売り上げランキング: 10,236


正社員時代の終焉-多様な働き手のマネジメント手法を求めて
大久保 幸夫 リクルートワークス研究所
日経BP社 (2006/02/16)

Web アプリケーションを開発していながら、「SQLインジェクション」や「OS コマンド・インジェクション」について何も知らないようなプログラマがいる。怖いことだ。

プログラムは処理が正しく動けばそれでよいというものではない。業務ロジックのような処理仕様の他にも、実行速度やメモリの消費量など、プログラマが気にしなければならないことはたくさんある。そうした中でも重要なのは「安全性」だろう。特に、Web アプリのように不特定のユーザーに利用されるプログラムの開発では、セキュリティへの配慮は不可欠だ。


独立行政法人 情報処理推進機構のセキュリティセンター には、コンピュータのセキュリティに関する様々な情報が公開されている。

システム開発者向けのコンテンツとしては、このページの右の列の下のほうにある「対策実践情報」の「ソフトウェア開発者の方へ」からリンクされている、「セキュリティエンジニアリング」がある。プログラマなら、まずは「セキュア・プログラミング講座」に目を通すと良いだろう(IPA の利用条件上、直リンクできないのでこんな紹介しかできない。"IPA ISEC セキュア・プログラミング講座" を検索 したほうが早いだろう)。

IPA ISEC セキュア・プログラミング講座このサイトでは、安全なプログラムの書き方が具体的にまとめられている。プログラミング言語や OS ごとに章立てされているので、該当する条件で初めて開発を行うようなときには、その章だけでも読んでおきたい。条件にぴったり合わない場合でも、近い条件の章を読めば参考になるだろう。

また、全ての記事が PDF でも用意されているのもありがたい。印刷して手元に置いておけば何かにつけて参照できるし、研修資料などとしても使いやすい。


「セキュリティホール」という言葉は、プログラムの「作り方」の問題も、「使い方」の問題も一括りにしてしまう。しかし、プログラミング的に対策が可能な既知の問題について、その対策が行われなかった場合、それはプログラマの責任であり、「バグ」と呼ぶべきである。決して、「知らなかった」で済まされるようなものではない。せっかくこうした情報が公開されているのだから、大いに活用し、勉強していきたいものである。


クリックお願いします →



■関連記事
セキュリティを確保せよ
Webラーニングプラザで学ぶ



■関連リンク
独立行政法人 情報処理推進機構のセキュリティセンター
Webアプリケーションに潜むセキュリティホール(@IT)



Writing Secure Code第2版〈上〉プログラマのためのセキュリティ対策テクニック
マイケル ハワード デイビッド ルブラン
日経BPソフトプレス (2004/12)
売り上げランキング: 82,530
おすすめ度の平均: 4
4 Windowsプログラマ以外にもおすすめ


情報セキュリティ プロフェッショナル総合教科書
特定非営利活動法人日本ネットワークセキュリティ協会教育部会
スキルマップ作成ワーキンググループ 佐々木 良一
秀和システム (2005/05)
売り上げランキング: 5,182
おすすめ度の平均: 4
3 網羅的に・端的に
5 内容豊富・執筆陣豪華・お買い得


プログラミングの現場では、「書き直したほうが早い!」という悪態をよく耳にする。既存のプログラムに機能を追加したり変更したりするときに、ソースコードがあまりに「汚い」と、思わず口から出てしまうのだ。しかし、実際にコードを書き直すか、そうしないで追加・変更していくかは、十分に検討する必要がある。


システム開発業界には、「動いているプログラムは触るな」という標語のようなものがある。ソースコードを変更すれば、間違って壊してしまうというリスクがあるからだ。しかし、この主張も絶対的に正しいというわけでもない。

この「触るな」の原則に従ってプログラムを改変しようとすれば、どうしても「無理な増築」をせざるをえない。そうすると、ソースコードはどんどん不自然で複雑なものになってしまう。そして、そのような汚いコードは、非常にバグを生みやすいのだ。

つまり、短期的には不具合を避けられるかもしれないが、長期的には不具合を誘いこんでしまうという皮肉な結果になりかねないのである。


リファクタリングとは、この「触るな」の原則に対するアンチテーゼである。などというと難しそうに聞こえるが、要するに「汚いソースコードは綺麗に書き直しましょう」という、あたりまえの話である。プログラムの機能が同じなら、コードは綺麗な方がいいに決まっている。

では、プログラムを壊してしまうリスクはどうするのか? その答えもあたりまえに考えればよい。テストを完璧に行えばよいだけのことだ。完成して動いているものをもう一度テストしなおすなんて、面倒だって? だったら、テストを自動化すればよいではないか。


「テストファースト」とか「テスト駆動」と呼ばれるような開発手法では、テストは自動的かつ完璧に行える。

テストが自動化できるのは、プログラムをテストするためのプログラムを作るからだ(多くの場合、xUnit という仕組みを使って効率的に作成する)。

では、そのテストがどうして完璧だといえるのか。それは、テスト用のプログラムを製品のプログラムよりも先に作るからである。ある機能を作りたいとき、まず、その機能をテストするプログラムを作り、後からそのテストを通過するような機能を作る。

ここで、「必ずテストを先に作る」ということが重要だ。そのルールを破らない限り、テストケースが漏れることはない(もちろん、テストと機能の両方を作り忘れることはあるが、それは別の問題である)。


こうした開発手法によって、完璧な自動テストが作られていれば、以後のリファクタリングは安心して行える。ソースを修正しても、テストプログラムを実行するだけで、プログラムが壊れていないかかどうかがすぐに確認できるからだ。

問題は、既存のプログラムにそのようなテストが存在しない場合だ。自分でテストを作成してからリファクタリングしてもよいのだが、作ったテストに漏れがないと言い切れるだろうか。特に、複雑怪奇なコードに直面したときには、自信が持てないことも多いだろう。悩んだ挙句、結局は「動いているプログラムは触るな」という原則に立ち戻ることも多い。

テスト駆動開発が普及すれば、そのようなことも少なくなるだろう。しかし、現実には、まだまだといった感じだ。「触るな」の原則をとるか、リファクタリングするか、状況に応じた適切な判断が求められるところである。


クリックお願いします →



■関連記事
テストを簡単にし、品質もアップする方法
プログラムは二度書け
怖いこと
嬉しいこと



■関連リンク
リファクタリング (Wikipedia)
KeywordListRefactoring (bliki_ja)



リファクタリング―プログラムの体質改善テクニック
マーチン ファウラー
ピアソンエデュケーション (2000/05)
売り上げランキング: 8,941
おすすめ度の平均: 4.73
5 ソフトウェアの改善に関する良書です。
5 プログラマーにとって必須アイテム
5 いい本です


テスト駆動開発入門
テスト駆動開発入門
posted with amazlet on 06.05.13
ケント ベック
ピアソンエデュケーション (2003/09)
売り上げランキング: 126,549
おすすめ度の平均: 3.22
3 何のプログラムを作っているのかがキー
1 翻訳がひどい
3 表現と翻訳に問題

科学技術振興機構が Webラーニングプラザ というサイトをやっている。様々な技術分野の知識を動画や音声で学習することができる、いわゆる「Eラーニング」のサイトである。IT関連の教材もあるので、プログラマの方々も利用してみてはどうだろうか。利用は無料(というか、税金が投入されているはずなので、使わないと損)で、会員登録しなくても、教材自体は利用できる。

Webラーニングプラザ

リンク先(トップページ)の右上の方にある「教材を選ぶ!」から、「分野・映像から選ぶ」→「情報通信」と進むと、現在、以下のような項目が選べる(※)。

 ・コンピュータアーキテクチャコース
 ・データ構造とアルゴリズムコース
 ・移動通信の基本技術コース
 ・ソフトウェア工学コース
 ・情報セキュリティコース
 ・情報ネットワークコース

プログラマなら、「コンピュータアーキテクチャコース」、「データ構造とアルゴリズムコース」、「ソフトウェア工学コース」あたりから学ぶといいだろうか。

ただし、技術者としての知識や経験があまりに少ないと、解説の速度についていけないことがあるかもしれない。アルゴリズムのようなややこしい内容も、さらっと説明されてしまうからだ。また、解説中に出てくる専門用語が理解できないという場合もあるかもしれない。教材にはリピート機能や用語集が付いているので、ある程度はカバーできるとは思う。しかし、全くの初心者は、やはり書籍等の教材も併用する必要があるように思う。

ある程度の経験があるプログラマであれば、そのようなことは少ないだろう。現場で働きながら「体で覚えてきた」というタイプの技術者には、こうした知識を体系的に学んでいないという人も少なくない。今更あらためて入門書を読むという気にはなれないという人も、こうした教材なら、手軽に学ぶことができるので、一度試してみてはどうだろうか。

クリックお願いします →



※直リンクできないため、このような紹介しかできない。このサイトでは様々な技術分野を幅広く扱っているが、ほとんどの利用者は、自分に関係のある一部の分野やコースを利用するだけだろうと思うのだが。せめて各分野への直リンクができるようにして欲しいと思う。



失敗から学ぶeラーニング
和田 公人
オーム社 (2004/05)
売り上げランキング: 32,202
おすすめ度の平均: 4.5
5 通学で当たり前の事を、ネットでも当たり前にやる
4 ユーザーの視点で書かれていて好感が持てました


『Java(1) 改訂版』-小さなプログラムをつくって理解するJavaの基本【CD-ROM付】
矢沢 久雄
翔泳社 (2003/07/12)
売り上げランキング: 140,702
おすすめ度の平均: 5
5 目から鱗!!わかりやすい!!
子供の頃、習字や図画の時間には、「下手でもいいから丁寧に書(描)け」とよく言われたものだ。

「丁寧に」という言葉は、仕事の正確性や確実性を求めるものではあるが、それだけではない。むしろ、人間の精神面を重要視しているといってもいいだろう。つまり、「心を込めているかどうか」ということである。

と言うと、コンピュータ業界には似合わない言葉のように思われるかもしれない。実際、開発現場で「丁寧なプログラミングを」といった言葉はあまり聞かないようだ。しかし、ソフトウェアの開発はほとんど手作りと言ってよい。プログラミングという仕事ほど、丁寧さが求められるものはないのではないだろうか。


「美しいコードを書け」という言葉は聞くし、私もよく使う。しかし、考えてみれば、「美しいコード」とはどういうことかが分からない人には、意味が分かるはずもない。全くの初心者プログラマには伝わりにくい言葉だろう。

しかし、「丁寧に書け」と言われれば、少しは分かるだろうし、実践することもできると思う。冒頭の言葉からも分かるように、「丁寧さ」は技術力とは無関係だからだ。

例えば、変数や関数にきちんとした名前をつけることは初心者でもすぐにできる。このブログのエントリで言えば、「あなたにもできること」、「もっとコメント論」、「インデントについて考える」などに書いたこともそうだ。

つまり、それを読む人に懇切丁寧に内容を説明するつもりでコードを書くことである。「心を込めているかどうか」というのは、ソースコードを読む人のことを考えているか、ということと言ってもいいだろう。


もちろん、構造化やクラス設計が上手く出来なければ、美しいプログラミングはできない。しかし、書き方に丁寧さが欠けていても、やはり美しくないのである。初心者プログラマには、まず、意識して丁寧なプログラミングを書くことから始めて欲しいと思う。


クリックお願いします →



■関連記事
誰のためのコード?
インデントについて考える 前編
インデントについて考える 後編
あなたにもできること
省略してはいけないものもある
コメント論
もっとコメント論 ~その1~ コメントとは何か
もっとコメント論 ~その2~ 見出しとしてのコメント
もっとコメント論 ~その3~ 注釈としてのコメント
もっとコメント論 ~その4~ システムの開発や保守のために
もっとコメント論 ~その5~ コードが求めるコメント



職人学
職人学
posted with amazlet on 06.04.30
小関 智弘
講談社 (2003/11)
売り上げランキング: 29,032
おすすめ度の平均: 5
5 職人の世界っておもしろい
5 本物が語る本物
5 ふわふわ浮いていたい夢想家は読むべきではない


美しいC++プログラミング見本帖
柏原 正三
翔泳社 (2004/10/09)
売り上げランキング: 64,672
おすすめ度の平均: 5
5 2冊目に読む本