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

悪態のプログラマ

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

「こういうことができるか?」といった質問を受けることがある。質問する方は簡単なのだが、答えるのは難しい。何かが「できる」ためには、いろんな要因があるからだ。


・理論的にできる/できない
・技術的にできる/できない
・時間的にできる/できない
・費用的にできる/できない
・感情的にできる/できない


など。


ソフトウェア開発者の中には、理論的・技術的な可能性にしか注目しない人がいる。例えば、「既存のシステムにこんな機能を追加したいが、可能か?」という質問があったとする。それが、システムの仕様として矛盾がなく、実装方法が頭に浮かぶようなら、「できます」と答えてしまう。


しかし、ほとんどの仕事には「いつまでに(納期)」「いくらで(予算)」など、他の条件があるはずだ。質問者と回答者の間で、そうしたことが全く話題にならなかったとしたら、誤解が生じている可能性がある。回答者は多忙で寝る時間もない状態なのに、質問者は「頼んだらすぐやってくれるのだろう」と思ってしまうかもしれない。



ついでに書いておくと、「できるか?」という質問の答えは「はい」か「いいえ」である。上記のように「条件」によって答えが変わる場合があっても、結局は「はい」か「いいえ」だ。


ところが、「できるか?」と聞かれて「がんばります」と答える人がいる。それは、できるの、できないの? がんばったらできるの? できないけどがんばるの?


いずれにせよ、できない可能性があるということなので、リスクを考えると、「がんばります」=「できない」と見なすしかない。


しかし、これを「できる」とみなす人もいて、困ってしまう。できる前提でスケジュールを立てて、結局は遅れてしまう。


その仕事の成果として最低限必要な部分を 100% とすると、「できるか?」という質問に対しては、その 100% の仕事ができるかできないかを明確に答えるべきである。「がんばる」という言葉を使うとしたら、更にそれ以上の成果、110%、120% を目指す場合にしか使うべきでない。



プロジェクトでスケジュールを立てる場合、どの仕事を誰がどの期間で行うのか、ということを組み合わせていく。リーダーから各作業者に「できるか?」という質問がなされる場合も多いだろう。この際、各人の「見積能力」が重要なことは言うまでもないのだが、コミュニケーションについても注意が必要、という話である。







■関連記事
どうして仕事を断らないのだろうか
意気込みは分かったから...
話が通じない話
感情の行き違い




本当に使える見積もり技術―ソフトウエア開発を成功に導く
初田 賢司
日経BP社
売り上げランキング: 20625
おすすめ度の平均: 5.0
4 FP法を詳説した良書
5 ズバリ良書だと思います
5 見積りの全体構造
5 ファンクションポイント法の使いこなし方

速効!SEのためのコミュニケーション実践塾 (日経ITプロフェッショナルBOOKS)
田中 淳子
日経BP社
売り上げランキング: 17930
おすすめ度の平均: 4.5
5 もっと早く、この本のことを知っていれば・・・
5 コミュニケーションの大切さを実感!
5 SE以外の人にもお勧め!
3 速効性は高いですが…
5 図解・企業論文の書き方の著者の読後感想

以前、「簡単コピー・プログラミングの罠 」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。


そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。


アプリケーションに固有の「業務ロジック(ビジネスロジック)」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想である。これには、開発期間の不足や業務面・技術面でのスキル不足など、多くの問題があるが、最もやっかいなのは、多くのプログラマがコピー・プログラミングを好むということである。


あるプロジェクトで共通機能(基底クラス)を作ったら、そのソースを部分的にコピーして使う人がいて、更にそれをコピーして作る人が出てきて、結局コピーだらけになったという例もある。これには「プログラマの管理がうまくいっていない」という指摘もできる。しかし、それ以前に、プログラマに「コピー・プログラミングへの抵抗感がない」ということが問題なのである。


実際、多くの職業プログラマを自由にしておくと、むしろ好んでコピー・プログラミングを行うようである。みんなコピー・プログラミングが大好きなのだ。



たしかに、チーム開発で共通化をしようと思うと、他のメンバーと相談して仕様を決めたり、あるいは他のメンバーの作った複数のソースを変更したりと面倒なことは多い。そういう役割の人(「共通チーム」などと呼ばれる)ならともかく、単なる「一機能の担当者」であるプログラマが、共通化のためにそこまでの労力を払うことは、まずないだろう。


コピー・プログラミングなら、誰にも気兼ねすることなく、自分の担当機能を作ることができる。多くの職業プログラマにとっての最優先課題は「自分の担当機能を動くものに仕上げること」であって、「ソースコードが美しいかどうか」などは二の次なのである。



私はこれまでコピー・プログラムには何度も痛い目にあってきたので、自分のプロジェクトでは、いかにして共通化を徹底するか(コピーさせないか)、ということに頭を悩ませてきた。しかし、多くのプログラマがコピーが大好きなのだとすれば、それを前提とした開発方法を考えるのも一興である。たとえば、以下のようなことだ。



あらかじめ完成度の高い「コピー元」を用意する

コピー元を品質の高いコードに集中させることで、「バグのコピー」や「似て非なるバージョンの散在」を防ぐ。



「コピーされたもの」が分かるようにする

例えば、コピー元のコードに特殊なコメントを埋め込む(もちろん、コピー先でも消さないでおく)などして、後からコピー先を検索しやすくする。これは、不具合修正や仕様変更などの際に、影響範囲(全てのコピー先)を特定しやすくするためである。



コピーしたコードは可能な限り変更しない

まず、コピー元はなるべく変更しなくてすむように作る。例えば、コピー先で関数名などがぶつからないように、ネーミングルールを作る。また、コピー先で無駄に変更することも禁止する。動作に影響のないからといってコーディングスタイルを自分流に変えたりしない。コピー先の記述の変更量が少なければ、コピー先の特定がしやすくなるし、記述の統一による可読性の向上にも繋がる。


あるいは、開発ツールの助けにより、コピー・プログラミングの品質向上が見込めるかもしれない。既存のツールでも、例えば、Visual Studio 等の統合開発環境で、アプリケーションの雛形を作ってくれる「ウィザード」や、「よくあるコード」を挿入してくれる「コードスニペット」は、「コピー指向」であると言ってもいいだろう。ソースコードを現在のようなテキスト形式のみで保存することに拘らなければ、他にも色々な対策はできそうだ。例えば、どのコードがどこへコピーされたか、ということをエディタが記録してくれれば、後から追跡することが容易になるだろう。



私も「同じことを何度も書くべきではない」という考え方を変える気はない。しかし、同じプログラマといっても、プログラミングについて誰もが同じように考えているわけではない。むしろ自分のようなプログラマは少数派なのかもしれない。そう考えると、日々の「悪態」も少なくなってくるのである。







■関連記事
簡単コピー・プログラミングの罠
簡単フレームワーク・プログラミングの罠
スキルアップのためにラップを剥がしてみる




アスペクト指向入門 -Java ・ オブジェクト指向から AspectJプログラミングへ
千葉 滋
技術評論社
売り上げランキング: 158663
おすすめ度の平均: 4.0
4 入門書として良く出来てます


初めてでもカンタン コピーするだけですぐに使えるJavaScript
立山 秀利
ローカス
売り上げランキング: 115209
おすすめ度の平均: 4.0
4 「とにかく今すぐ使いたい」と言う人向きです。

受託開発プロジェクトの終盤、ユーザーテスト(受け入れテスト)などと呼ばれる検証が始まると、当初の要件を覆すような「仕様変更」が発生するものだ。


システムの要件定義(要求分析)は依頼者(顧客)と開発者が共同で行うものであり、漏れがあったとしても、どちらが悪いとも言い難い場合も多い。例えば、開発者の考慮不足とも言えるが、顧客側の情報提供が不足とも言えるというようなことだ。しかし、顧客は「金を払って依頼している」という意識が強いためか、開発会社の責任で修正させようすることも多い。


開発会社もある程度は折り込み済で、「手戻り」の時間を確保しているものだ。しかし、なにしろリリースまでの時間が残り少ない時のことである。「手戻り」の規模によっては間に合わないケースも多く、顧客との関係が悪化することもある。


開発者が「しかし、当初のお話では・・・」などと反論しようものなら、「こっちは客だぞてめえ」ぐらいのことは平気で言う人も。ビジネスの世界では金を払う人が偉いのである。



いわゆる「Vモデル 」に従って進めているとされるプロジェクトでは、こうしたトラブルがよくある。Vモデルの図をよく見ていると分かるのだが、開発の終盤に「当初のお話」が間違っていることに気がつくというのは、自然なことである。


V字の後半の右上がりの部分は、テスト工程を表している。この部分は、意地の悪い言い方をすれば、「先にプログラムの細かい枝葉を確認し、システムの拠り所である要件が正しいかどうかは最後に確認しましょう」ということになっているのである。最後に要件上の問題が見つかるのは当然である。しかも、顧客が要件を出したのは遙か昔のことなので、今更「当初のお話」をしたところで、「そんなこと言いましたっけ?」となるのも当然である。



もちろん、ここでのテストとは、あくまでも動作確認(動的テスト)の話である。要件定義自体のチェック(静的テスト)は、V字の「書き出し」に定義した時点で行われているはずであり 100% 問題ない、という前提(というか建前)で進んできているわけである。基本設計(外部設計)以降も同様だ。


しかし、この静的テストは、主に要件定義書や設計書などを作って「机上」で行われる。開発の当初、まだ影も形もない新しいシステムを 100% イメージできる人がいるだろうか? もちろん、システムだけでなく、それを使った業務全体の運用イメージも必要なのだ。しかも、誰か1人が分かっていればよいというわけではない。そのイメージは、システムの素人である顧客と、業務の素人である開発者の間で、完全に共有しなければならない(出会って間がないにもかかわらず)。


実際のところ、そんなことはできないのである。結局、システム要件というものは、結局は開発期間の最初から最後までかけて、ああでもない、こうでもないと言いながら決めていくことになる。


いや、開発が終わってもそれは続く。完成した後で「ここはこうした方が良かった」と思わないようなシステムは、まずないだろう。ソフトウェアに限らず、実際に使ってみて初めて気がつくことがあるというのは、当然のことだ。


このように、仕様変更があるというのは自然なことであり、開発プロジェクトでは、変更があったときにどうするか、ということをあらかじめ決めておくということも重要である。



とはいえ、Vモデル(ウォーターフォール)での開発では、後半に発生する変更を少なくすることが最重要課題である。開発が終盤に近づくほど、残り期間が少なくなるし、同じ変更であっても手戻りの作業量も難易度も大きいからだ(既に作っている部分を直すため)。


このため、一番最初の要件定義の段階でいかにして精度の高い「完成図」をイメージするか、ということが非常に重要なのである。これは、開発側の視点でいえば、顧客に「どこまで本気で考えてもらえるか」ということにかかっている。


プロジェクトも始まったばかりのこの頃、顧客はのんきに構えているのが普通である。そして困ったことに、開発者にもそんな人は多い。会議を開いても、結論も出さずにあいまいな状態で終わったり、雑談ばかりしていたりする。「時間があるのだから、今考えなくてもいいでしょう?」などと思っているようだが、実はこの時が最も重要なのだ。Vモデルでは、最初はバリバリ、最後は淡々と仕事すべきなのである。







■関連記事
怖いこと
情報求む
捨てるべきときには潔く
簡単に見える時ほど注意せよ
ちょっとしたプログラム




はじめての上流工程をやり抜くための本 (エンジニア道場)
三輪 一郎
翔泳社
売り上げランキング: 6219
おすすめ度の平均: 5.0
5 上流経験者にもぜひ
5 濃い本です


成功する要求仕様 失敗する要求仕様
アラン・M・デービス
日経BP社
売り上げランキング: 16586
おすすめ度の平均: 5.0
5 要求マネジメントの良書

中学生の頃だったろうか、「サボる」という言葉を漢字で書こうとして辞書を引き、はじめて「サボタージュする」の略だということに気がついた。ずっと純粋な日本語だと思っていたので驚いた記憶がある。日常的に使っている言葉は、昔からあったかのように思ってしまうものだが、意外に新しいということがある。



この業界では「ひもつく」という言葉がよく使われる。個人的には「ひもづく」と言う方が多いのだが、同じものだろう。データ構造に関する文脈などで、「繋がっている」、「関連している」といった意味でよく使う。たとえば、「従業員のデータは部門コードで部署マスターにひもづいている」という具合である。


しかし、この言葉、メールに書こうとすると漢字変換できない。辞書で調べても出てこない。実は、最近生まれたいわゆる「オトナ語」なのである。仕方がないので「繋がっている」とか「リンクしている」などに置き換えてみるが、文脈によってはしっくりこないこともあり、ちょっと困る。


まぁ、どのみち受託システムに関する文章は専門用語のオンパレードである。関係者が読んで理解できる言葉であれば、メールで使うくらいは構わないだろう。とはいえ、平仮名では格好が付かないので、「紐付く」と表記することにした。



逆に、きちんと定義された「正しい」言葉であっても、それを読む人が理解できないものを使うのはよくない。先日も、あるシステムの画面に、


 20バイト以内で入力してください。


というエラーメッセージが出てきて、エンドユーザーが「意味が分からない」と言っていた。システムを作る側は、「バイト」という単位にあまりに馴染んでしまっているので、思わず使ってしまったのだろう。しかし、一般には、「バイト」といえば「アルバイト」の略である。


ここは、ユーザー層を考えて「バイト数」ではなく、「文字数」で表現すべきところだった(細かいことをいえば、文字数とバイト数との関係は文字コードセットによって違うので、単にバイト数を示すだけでは、いずれにせよ不十分である)。



バイトといえば、「バイト敬語」が日本語の乱れとして問題視されている。「1万円からでよろしかったでしょうか?」のような、コンビニやファミレスの店員などが話す独特の言葉である。


私もこうした「乱れた」とされる言葉には違和感を感じる方である。しかし、言葉が本来「変化する」という特徴を持っていることを思い出すと、あまりこだわることもないか、と思い直す。何を基準に「乱れている」というべきか分からないからだ。


特に、そう思わせるのが「全然」の誤用問題である。私はずっと「全然」という言葉がその後に否定的な意味を伴わずに使用されるのは誤用だと信じていた。つまり、「全然良くない」は正しいが、「全然良い」のような肯定的な表現は最近の「日本語の乱れ」だと思っていた。しかし、調べてみると実はそうでもない。「全然」の肯定的な表現は昔からあり、漱石や鴎外も使っているというのである。


結局、言葉が「正しい」かどうかというのは、それを使う人同士が持っている「基準」に合っているかどうか、という程度でしかないのだろう。つまり、うまくコミュニケーションするには、「相手が正しいと思う言葉を使え」ということである。相手によっては、自分より「基準」が厳しい場合だってあるだろう。そう考えると、「ひもつく」などという辞書にない言葉に違和感を感じる人もいるかもしれない。とりあえず、設計書などの正式な文書には、「紐付く」などと書かないようにしようと思う。







■関連記事
普通の言葉
曖昧言葉
えいやぁと眉を引く話
エンドユーザーとは




問題な日本語―どこがおかしい?何がおかしい?
北原 保雄
大修館書店
売り上げランキング: 56754
おすすめ度の平均: 4.0
3 文法的な解析や過去の吟味とあわせて、現在の生きた用法をしっかりと見据える事が大事
5 「問題な日本語」は問題ではないでしょうか?
5 ってゆ0か、わたし的にはおもしろい、ってかんじ?
5 柔軟な思想
5 言葉は生きている!


問題だ!そのバイト語―その言葉は耳障り!直すべし、その言い方!
浦野 啓子
東洋経済新報社
売り上げランキング: 72839
おすすめ度の平均: 5.0
5 普段何気なく使っているけど

ちょっとした仕事(タスク)を忘れてしまう人が意外に多い。ToDo リストのようなものを作って、管理すればいいだけのことなのだが。


上司から ToDoリストを作るように言われ、数日の間、「今日のタスクは ToDo リストを作ることであります」などと言っていたが、結局できなかったという人もいた。やるべきことが発生したら追加するというだけのもののはずなのに、このように気合いを入れて作ろうとするのもおかしな話である(最初に作る時は、抱えているタスクを列挙するのに時間が必要かもしれないが、それでも何日もかからないだろう・・・)。



ToDo リストを作るといっても、色々な方法がある。この業界では、PC や携帯端末など電子的なツールを使う人も多いかもしれないが、私の場合は「紙とペン」である(しかも、今のお気に入りはルーズリーフと万年筆という懐かしい組み合わせだ)。


基本的には普通に「やるべきタスク」を書いては潰していくだけなのだが、ちょっとした工夫をしている。優先が高いいくつかのタスクについては、以前紹介した フリクションボール(最近はビジネスモデル もある)を使って、赤いラインを入れるのである。フリクションボールのように消せるペンであれば、終わったタスクのラインを消すことができる。このため、常に「次にやるべきタスク」だけが赤くなっているというわけだ。


また、タスクの進行状況等のコメントを、他の色のフリクションボールで記入することもある。「次のアクション」は青、「お客様回答待ち」は緑など。やはり、状況が変わったら消して書き直すことができるので便利だ。もちろん、元のタスク自体は、普通の消えないペンで書くので、「行」を上から大胆に擦っても大丈夫である。



プログラマならではの ToDo 管理としては、「ToDo コメント」がある。


プログラミング中、細かい処理まで逐一実装しながら進めていると、思考の流れが止まってしまいそうなことがある。そのような場合、枝葉末節は後回しにして、主要な処理だけ先に書いてしまいたい、と思うだろう。


あるいは、一部の処理の仕様が確定しないまま、プログラミングを進めることもある。そういう場合は、そこだけ「仮」の実装にしておいて、他の部分を先に書いていくことになるだろう。


いずれも、後から一部の処理を書かなければならないのだが、ともすれば忘れてしまいがちである。そういう場合は、ソースコードの該当箇所に「ToDo コメント」を書くとよい。


後から実装すべき部分に、例えば「TODO:」という文字列を付けたコメントを書いておき、これを定期的に検索するのである。当然、実装が終わったらこのコメントは削除する。最終的に検索結果がゼロにならなければ、プログラムは完成しないというわけだ(「もっとコメント論 ~その4~ システムの開発や保守のために 」も参照)。



やるべきことを忘れないこと、というのは、スケジュール管理(遅れないでやる)以前の問題である。仕事をする上での最低限の条件と言ってもいいだろう。忘れないためには、忘れる前に記録すること、そしてそれを常に参照することである。方法自体は難しくない。習慣化できるかどうかが鍵だろう。







■関連記事
書き込まれる資料作り
もっとコメント論 ~その4~ システムの開発や保守のために




開発の現場 vol.006
開発の現場 vol.006
posted with amazlet at 08.06.09

翔泳社
売り上げランキング: 64211