オブジェクトの気持ち

誰だって、自分の担当とは関係ない仕事を押し付けられたら嫌だろう。「本当はあいつがやるべきなのに」とか、「別に担当を立てるべきだ」と思うようなこともあるのではないだろうか。

プログラムだって同じである。

ひとつの「オブジェクト」に、何でもかんでもやらせようとすると、オブジェクトだって怒りだす。やがてはバグとなって噴出するだろう。

★

オブジェクト指向は、擬人化という観点で語られることがある。オブジェクトを人に見立てて、その役割、仕事を考えようというわけだ。オブジェクト指向の「クラス」は、データと手続きをまとめてモノ（オブジェクト）になぞらえたものだ。その結果、非常に擬人化しやすくなっている。

「現実世界をそのままクラスで表現することは出来ない」というのと同じような意味で、クラスの擬人化に限界を感じる人もいる。しかし、擬人化というのは、「モノを人に見立てる」ということだけではない。むしろ、「自分がモノになりきる」ことである。

人間は、色々なものに感情移入することができる。犬猫はもちろん昆虫や宇宙生物、雑草や石ころに至るまで。もちろん、「クラス」に対しても可能だろう。さらに言えば、関数や変数ですら擬人化することができるはずだ。

★

自分の経験的から言っても、クラス設計の際に「オブジェクトの気持ちを考える」というのは有効なことだと思う。

クラスにどのようなデータや機能を持たせるか、インターフェースはどうするか、といったことを考えるとき、そのクラスの「立場に立つ」と、自然と決まっていくことは多い。また、できたクラスは、自己完結した汎用な設計になりやすいのだ。

それは、システム全体の機能などにはとらわれず、クラスの「個」としてのありかたを意識しやすいからかもしれない。

クリックお願いします →

■関連記事
・バグの気持ち

オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識―

posted with amazlet on 06.05.03

平澤章
日経BP社 (2004/06/03)
売り上げランキング: 8,743

おすすめ度の平均:

読んで損はない１冊だと思います！

基礎がしっかりしているベテランエンジニアにこそ。

レガシーからオブジェクトへの入門書

Amazon.co.jp で詳細を見る

Javaプログラマガ知ツテオクベキコト

posted with amazlet on 06.05.03

えんどうやすゆき
毎日コミュニケーションズ (2005/08)
売り上げランキング: 35,391

おすすめ度の平均:

一風変った良書

「何故プログラミングをするのか？」を思い出させてくれる本

何のためにこの本を読むかが分かりやすい

Amazon.co.jp で詳細を見る

どこまで書くか設計書

先の東証のシステム障害の原因は、富士通が作成した資料の記載漏れだという。しかし、東証側も安易に賠償請求するのではなく、自らの体制をも含めた改善策を検討しており、好感が持てた。システムの開発・運用は、開発側と受け入れ側の協力なくしては、不可能だからだ。

ところで、資料の抜け漏れを無くすということは、案外難しいものである。

客観的にみて、当然書くべき情報が書かれていない場合、それを見つけるのは比較的簡単である。しかし、書く必要があるかどうか、はっきりしない情報というのもある。そのような情報が漏れているかどうかは、ただ資料を見ただけでは、判断できない。

例えば、資料の書き手が当り前のこととして省略した情報が、読み手にとって当り前でなかったということがある。書き手が完全だと思っている資料でも、読み手にとっては不完全ということになってしまうのだ。

しかも、そのようなケースでは、読み手がその不完全性に気づかないようなこともあって、始末が悪い。

システムの受託開発では、発注元の顧客の会社や業界にとっては「常識的」な知識でも、開発者が全く知らないということはよくある。そして、顧客側が作った要件書にそうした情報が記載されなかったために、トラブルが起こることも少なくない。

★

プログラムの設計書（仕様書）でも同じことがいえる。特に、設計書から異常系処理の記載が省略されるようなことは多いようだ。設計書に「明らかに必要な処理」の記述が欠けている場合、プログラマが適宜判断して（気を利かせて）、実装することになる。（※）

しかし、プログラマが気の利いた仕事をしなかったらどうか。異常系の処理が実装されず、異常終了したり、データファイルを壊してしまうようなプログラムが出来てしまうだろう。場合によっては、セキュリティホールにつながるかもしれない。

プログラマからすれば、設計書に書かれていないのだから、それでも正しいプログラムだと主張したいところだ。しかし、現実はそれほど甘くない。

★

設計書をどこまで細かく書くか、という判断は難しい。設計者が実装すべき全てのことを書くのは効率的ではない（それはコーディングを行うに等しい）。しかし、プログラマが適切に設計を補完するためには、ある程度の経験が必要なのである。

最も重要なことは、書く側が読者層をきちんと想定できるかどうかだろう。それができていれば、どの程度の情報を盛り込むべきか、自ずと決まってくる。情報を省略するにしても、適切な補足資料を用意するなどの工夫もできるだろう。

また、設計書の読者であるプログラマの側も、ただ書かれていることをソースコードに翻訳するというのではなく、設計書の「行間」を埋めて、自分が設計を完成させるのだという意識をもつべきだろう。

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

※＠ＩＴ情報マネジメント「いいかげんにして！日本企業─中国に嫌われる理由」によると、異常系処理の約７割は、プログラマが独断で決定するという。

■リンク
・東京証券取引所「株式・ＣＢ売買システムの障害発生に関する再発防止措置等について」

SEを極める仕事に役立つ文章作成術
百戦錬磨のプロマネが伝授するドキュメント作成の極意

posted with amazlet on 06.03.25

福田修日本情報システムユーザー協会
日経BP社 (2005/11)

Amazon.co.jp で詳細を見る

SEのための図解技術

posted with amazlet on 06.03.25

開米瑞浩
翔泳社 (2003/07/16)
売り上げランキング: 39,037

Amazon.co.jp で詳細を見る

良い机と良い椅子で良い仕事を

今週の「IT」の TB テーマは「PC作業に必携のアイテム」。といっても、「PCワークをしていても肩や腰が凝らないようにする秘訣」だそうだ。

この点で重要なのは、なんといっても「机と椅子」だろう。

ぴったりと隣り合わせて並べられた机にパソコンとモニタを載せ、不自然に手前に置いたキーボードを、背中を丸めて一日中打っていれば、肩が凝るのも当然である。

★

思えば、私の会社の社員は、机と椅子に関しては恵まれている。

机は、普通の片袖の事務机だが、それに加えて、同じくらいの大きさのサイドデスクも支給されている。サイドデスクの上にパソコンとモニタを置いても余りあるので、キーボードは自由な位置に置くことが出来る。

また、通常の机の間にサイドデスクを挟むので、隣の席の人とも距離が空いていて、伸びをしても手が当たるようなこともない。

椅子も、かなり大きな部類のもので、座る部分と背もたれが連続したタイプ。背もたれは背中を十分に覆うぐらいの大きさがあって、もちろん、リクライニングする。

★

田舎の中小企業ならではの贅沢か。

そんなことを考えながら、そこらへ座っているプログラマを見れば、その椅子にふさわしい仕事をしてくれよ、と思うのである。

[PR] エレコム　天然木マルチPCデスク

[PR] サンワサプライ OAチェア - 大きな背もたれで包み込まれるような座り心地

TMTOWTDI ～人生色々、プログラミングも色々

IT 用語には、妙に耳に残る言葉がある。「WYSIWYG（ウィジウィグ）」とか、「ユビキタス」とか。プログラミング関係では「ポリモフィズム」とか。

「GNU」などは、人によって発音の仕方がバラバラである。「グヌ」とか「ニュー」と読まれることもあるが、「GNU OS のサイト」によると「グニュー」が正しいようだ（※１）。

略称を無理に発音させていたり、馴染みの薄い言語（ラテン語とか）に語源を持っているものなどは、日本人にとって変に聞こえるものが多いのではないだろうか。

そういった「変な言葉」に出会うと、ちょっと意味を調べたくなったりするものだ。

★

「TMTOWTDI（ティムトゥディ）」という言葉も、妙に耳に残った言葉のひとつだ。「There's More Than One Way To Do It.」の略で、「やり方はひとつではない」という意味である。

同じ機能のプログラムを作るにも、コードの書き方は色々ある。また、そうであるべきだという考え方だ。もともとは、Perl というプログラミング言語のスローガン（設計思想）である（※２）。

これは、コーディングの話だけではないだろう。例えば、サーバーの OS を選ぶとき、プログラミング言語を選ぶとき、「どれを選んでも同じことが出来ます」という状態は TMTOWTDI であるといってよい。例えば、.NET の世界の「クラス」は、C# で書こうが、VB で書こうが、C++ で書こうが、区別なく利用できるが、これも TMTOWTDI だろう。

★

IT の普及に伴ない、システム開発における選択肢の幅もかなり広くなった。開発者にとっては、自分が得意な方法を選ぶことが出来るのだから、嬉しいことではある。

しかし、喜んでばかりはいられない。職業プログラマは、自分の得意とするやり方だけで仕事が出来るというわけではないからだ。

例えば、他人のソースを読むときに、「このような書き方は知らないので、ここの処理が何をやっているのか分かりません」なんてのは通用しない。「VB しか知らないので、C# のクラスは直せません」なんてのも、通用しないのである。

技術者には、技術についての「好き嫌い」がある。それは当然のことだし、むしろ技術者としての情熱があるということで、好ましいことでもあるだろう。しかし、「嫌いな技術も使える」ということも大事なことなのである。

※１
「GNU」は「GNU's Not Unix」の略。再帰しているところにセンスを感じる。

※２
最近では、Perl は CGI のための言語だと思っている人もいるようだが、その歴史は WWW よりも古い。長年の人気を保っている秘訣のひとつが TMTOWTDI という設計思想だろう。

■関連記事
・デザイナーの屈辱
・豆腐とウィジウィグと私

[PR] Amazon で探す Perl の本
[PR] オレ流パソコン・IT 用語納得事典 2006年・2007年版

デザイナーの屈辱

Web デザインに関するページを読んでいて、目に留まった言葉がある。

WEBデザイナーなのに「アーティスト」と言われることはなんとも屈辱的なことです。

　（WEBデザイナー辞典さんより）

これを書いた人は、Web デザインという仕事をよく理解しているのは当然だが、その仕事に対して誇りを持っているということがうかがえる。

もちろん、「アーティスト」を蔑視しているわけではない。機能性を無視した「かっこいいだけ」の Web デザインを戒めているのである。

★

素人の感覚では、美しいページ＝芸術的なページと考えてしまいがちだ。しかし、Web ページは鑑賞するものではなく、使うものである。芸術性を追求するのではなく、機能美を追求するのが、Web デザインだということだろう。

もともと「デザイン」という言葉には、「設計」という意味がある。プログラミングの世界で「デザインパターン」というときの「デザイン」である。

つまり、まず始めにやりたいこと（機能要件）があり、それをどのような形で具現化（実装）するかを考えるのが「デザイン」なのである。そういった意味では、Web デザイナーとシステムエンジニア（SE）は同じことをやっているといってもよいだろう。

システム開発では、設計したものを実装する作業を「コーディング」と言う。Webデザインの世界でも、デザインしたものを実装する（HTML を書く作業など）を「コーディング」と呼ぶようだ。これも面白い符合だと思う。

★

冒頭で引用した言葉は、デザイナーが「自己満足」に陥っていないか、という警告でもあるだろう。これは、システム開発者も考えておかなければならないことではないだろうか。

システム開発では、同じ機能を実現するにしても、色々なやり方がある。例えば、開発言語を何にするのか、データベースやフレームワークに何を選ぶのかといったことから、どのようなアルゴリズムでプログラミングするのか、といったことまで。そこに、開発者個人の「好み」が入り込んでしまう。

もちろん、技術者の得意・不得意が開発効率に影響を与えることもある。技術者の好みを考慮することが一概に悪いわけではないだろう。しかし、ただそれだけで判断すべきものでもない。

実際、システムに不必要な技術を、ただ「やってみたいから」とか、「流行っているから」などといった理由で導入し、プロジェクトを失敗させるようなケースもある。

私自身もそんなプロジェクトに参加した経験がある。誰が見ても C/C++ や VB を選択すべきであるにもかかわらず、マネージャの趣味で Java を採用した開発だった。案の定、必要以上に工数を消費し、品質的にも悪影響が出た失敗プロジェクトとなった（もっとも、失敗の原因は他にも色々あったのだが・・・）。

熱心で自信をもった技術者ほど、こうした自己満足的な判断をしてしまいがちだ。常に気をつけておきたいものである。

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