悪いとは？/ セントラルファイナンス
[ 650] @nifty：デイリーポータルZ： 態度の悪い店員さんの怒り方
[引用サイト] http://portal.nifty.com/2007/08/16/a/
|
外で食事をしていると、たまに態度の悪い店員さんに当たってしまったりする。プライベートで嫌な事があったのかもしれない。たまたま虫の居所が悪かったのかもしれない。それでもこっちはお金を払って食事をしているのだ。最低限のサービスを受ける権利がある。少なくとも嫌な思いなんてしたくない。 都内某所、歓楽街の片隅にそのお店はあった。仮に名前を「S」としておこう。大人たちが静かにグラスを傾ける。そんな風情が漂うお洒落なバーといった雰囲気である。 店内は薄暗く、所々、間接照明で彩られている。４人掛けのテーブル席が4つあり、あとはカウンター席が10席ほど。初めて入る店なので、いきなりカウンター席に座る勇気はない。友人と向かい合う形で一番奥のテーブル席に座った。僕たちの他にお客は2組。いずれもテーブル席でお酒を酌み交わしている。 カウンターの中にはバーテンダーが2名。そのうちの一人が僕たちのテーブルにおしぼりとメニューを持って来てくれた。 僕たちはメニューには目を通さず、とりあえずビールを注文した。とにかく喉が渇いていたのだ。しかし、店員さんは僕たちの注文を聞いていない。声が小さくて聞こえなかったのかもしれない。もう一度、今度はさっきより大きい声でビールを頼んだ。すると店員さんは無言でメニューの一部を指差した。 なんでそんな態度なのか。僕たちは静かにお店に入って来て、大人しく席に座って、ビールを頼んだだけだ。他のお客さんの迷惑になるような行為は一切していない。格好か？ Tシャツ姿で来るような店じゃなかったのか？ 抗議したい気持ちは山々であったが、僕も大人だ。グッとこらえて「エビスを2つください」と行儀良く伝えた。店員さんは返事もなく頷きもしない。そういうスタンスの店なのだから仕方ない、と自分に言い聞かせてビールを待った。 店員さんの態度は悪かったが、ビールはとてもおいしかった。おつまみのミックスナッツもおいしい。 大きな声で何度も呼んだのだ。気付かない訳がない。あの店員さんはお客よりも氷の方が大切なのだ。今砕かないと溶けてしまうからだろう。しかし、それはそっちの事情である。こっちは何か強めのお酒を飲みたいのだ。 いや、何とかしてあの店員さんをギャフンと言わせたい。ギャフンと言った後に今までの態度を悔い改めてもらいたい。 これから紹介する作戦は僕の友人から教えてもらったものである。彼は実際に態度の悪い店員がいるファミレスでこの攻撃を試した事があるという。題して、「お冷やが下げられなくて困っちゃう」作戦だ。 事務所で再現してみたが、本当に片付けられなくて困ってしまった。テーブルの縁までゆっくりとグラスを滑らせていき、用意しておいたバケツに水を一気に！と思ってやってみたが、全く水をこぼさずに処理する事は出来なかった。 とはいえ、いつまでたっても店員さんはやって来ない。やはり、「お冷やが下げられなくて困っちゃう」作戦を繰り出すしかないのか。いや、ダメだ。作戦を決行するにはまずお冷やを頼まないといけない。オーダーすら聞いてくれないのだから、お冷やなんて頼めるはずがない。 テーブルにあるものを使って僕の怒りを表現してみた。僕が帰った後、テーブルを片付ける際にこの怒りに気付いてもらえれば幸いである。 毎日毎日、猛暑続きで大変です。暑くて暑くて気持ちが苛立ちがちでしょうが、出来ればイライラする事なく日々を過ごしていきたいものですね。僕も「人に優しく」を心がけて、暑い夏を乗り越えていきたいと思っています。皆さまもご自愛下さいますよう、お祈り申し上げます。 |
[ 651] 技術者の評価を下げる「悪い」コメントに注意しよう
[引用サイト] http://www.aerith.net/design/comment-j.html
|
ソフトウェアの受託開発や、オープンソースのプロジェクトでは、ソースコードが他の技術者の目に触れる。そのため、ソースコードから開発者の技術力が評価されやすい。 ソフトウェアの開発者は、モジュール分割やクラス設計には全力を傾ける。最近では、設計の完成度を高めるために、実装の後でリファクタリングを行うことも珍しくない。 だが、設計の善し悪しにこだわる開発者でも、ソースコードに書くコメントの品質までは、配慮が及ばないことが多い。コメントは本質的なものではないので、つい気を緩めてしまうのである。 ところが、開発者の希望に反して、ソースコードの読み手が印象を受けやすいのは、コメントの品質である。ソースコードから設計を読み解くのは容易ではないが、日本語や英語で書かれているコメントは目に付きやすい。 優秀な技術者の書いたソースコードでも、驚くほど「悪い」コメントが書かれていることがある。そのようなソースコードを世に出せば、開発者の技術力にも疑問を抱かせることになりかねない。 貴方がこれまでにリリースしたソースコードに、このようなコメントが残っていたとしたら、リリース前にコメントのレビューを行うことも、考えた方が良いかもしれない。 見れば分かることは、わざわざコメントとして書く必要はない。だが、自明なコメントは、実際のソースコードでは良く見かけるものだ。例えば、次のようなものである。 自明なコメントは、無駄ではあるが、特に害をもたらすものではない。だが、あまりにも多いと、初心者が書いていると思われ、顧客を不安にすることがありそうだ。 日本人の書いたソースコードには、ソースコードをそのまま日本語に訳しただけのコメントが書かれていることが非常に多い。例えば、次のようなものである。 ソフトウェアの技術力と英語力は無関係だが、日本語訳のコメントが多く見られるのは、たいてい経験の浅い開発者のソースコードである。 日本語訳のコメントも、特に害をもたらすものではないが、あまりにも多いと、初心者が書いていると思われ、顧客を不安にすることがありそうだ。 ソフトウェアの受託開発では、ファイルや関数のヘッダを、定型フォーマットで記述することが多い。だが、実装が終わったリリース前のソースコードを見ると、ヘッダに書くべき内容がきちんと記入されていることは稀である。 記入漏れは、ソースコードのリリースの前にレビューを行えば防ぐことができる。逆に言えば、ヘッダに記入漏れがあると、きちんとレビューをしていない、と思われてしまうことになる。 ソースコードの可読性を高めるために、クラスや関数、変数の名前は分かりやすいものにすることが重要である。しかし、稀に暗号のような名前を付けるプログラマーがいる。 不適切な名前のままでは本人も読めなくなるためか、暗号のような名前の意味をコメントで補っていることがある。例えば、次のようなものである。 このような事例は、設計を行わずにやみくもにコーディングを行った場合に多く見られる。逆に、設計を重視するオブジェクト指向プログラミングでは、設計フェーズできちんとした名前が付けられるため、このような問題は発生しない。 ソースコードに、不適切な名前を補足するコメントが書かれていると、ソフトウェアの設計を行う技量がないと思われてしまうことになる。 ソースコードの誤りはコンパイルエラーやテストで検出できるが、コメントの誤りは気づかれにくい。そのため、たいていのソースコードには、誤った内容が書かれた嘘のコメントが少なからず存在する。 意識してコメントに嘘を書く開発者はいない。それでも嘘のコメントができてしまうのには、いくつか理由がある。 似たような関数をまとめて作っている時や、新しいクラスを作る時など、ゼロから書くのではなく、既存のソースコードをコピー＆ペーストした上で、それを修正することもある。その時、コメントだけを修正し忘れることが多い。 仕様変更や機能改善によって、ライブラリやコンポーネントの利用方法が変更になった時、変更したライブラリやコンポーネントのソースコードだけでなく、それらを利用している箇所についても、コメントを書き直す必要が生じることがある。例えば、次のようなものである。 嘘のコメントがあると、読み手はソースコードとコメントのどちらが正しいのか分からないことがある。コメントの方が正しいように見える場合は、ソースコードが誤っていると判断され、ソフトウェアの品質にも疑問を持たれることになる。 開発期間の長い大規模システムでは、実装に着手した時点でも、ソフトウェアの一部については、仕様がまだ未確定だったり、将来的に変更される予定になっていることがある。特に、最近主流となりつつある反復型の開発手法では、このようなケースも珍しくなくなった。 未確定な部分を実装する際、将来的に変更されることを、ソースコードにコメントとして書いておく開発者が意外に多い。例えば、次のようなものである。 ところが、最終的にリリースされる時点になっても、こうした作業予定のコメントがそのまま残っていることが少なくない。 このようなコメントが残っているのは、何らかの処理を組み込むべきなのに、すっかり忘れられてしまったことが原因であれば、重大な問題である。逆に言えば、作業予定のコメントが残っているのを見つけた顧客は、そのソフトウェアのプロジェクト管理に、重大な問題があるのではないか、という疑いを抱く。 実際には、仕様や設計が変更になって、コメントに書かれていたような作業が不要になった、というケースが多い。だが、作業が不要になった時点では、作業予定のコメントを書いた開発者がすでに担当を外れていることもある。そのため、作業予定のコメントをきちんと削除することは難しい。 プロジェクト管理に疑問を抱かせないためには、リリース前にコメントのレビューを行うか、もしくは、作業予定のコメントは記入しないように注意する必要がある。 ソフトウェア開発者としての責任感を疑われることは、技術力を低く評価されることよりも、深刻な問題である。ところが、いい加減な仕事をしているような印象を与えかねない致命的なコメントが、リリースされるソースコードに残っていることがある。例えば、次のようなものである。 ソースコードを書いている最中に、この通りで良いかどうか、疑問が生じることは良くある。いくつかの方法を試したり、設計を見直す必要があるかもしれない。時には、処理が正しいかどうかを、テストしないと確かめられないこともある。 本来であれば、そのような問題点は、開発者自身の作業項目リストに追加し、開発者自身が責任を持って検証やテストを行わなければならない。もし、検証やテストを行わずに、コメントを書いただけで終わりになっていたのであれば、本当に無責任だった、ということになる。 実際には、検証やテストを行った後で、コメントを修正するのを忘れているだけのことが多い。だが、こうした無責任なコメントは、顧客との信頼関係に重大な問題を引き起こす。開発者は、このようなコメントは最初からソースコードには書かないことが望ましい。 いかにオブジェクト指向に造詣が深く、デザインパターンを巧みに駆使したとしても、下手なコメントを書いてしまうと、せっかくの美しい設計が台無しになってしまう。 ソフトウェア開発者としての技術力を正しく評価してもらうためにも、コメントには最低限の注意は払うべきである。 |
