どのくらいでできる？

システム開発のプロジェクトでは、プログラマの「時間」は、きっちりと管理されるのが普通である。

例えば、「○○機能は３日でプログラミングする」というように、細かいスケジュールが引かれるだろう。

そういった状況の中、自分に与えられた作業がどのくらいの期間で出来るのか、ということを判断することは非常に重要である。

○○機能のプログラミングを任されたプログラマは、まず、自分がそれを３日でできそうかどうかを見積らなければならない。そして、できそうになければ、最初にそのように主張すべきである。３日後に「できませんでした」と言っていたのでは遅い。

リーダーが３日で出来るというのだから、がんばれば出来るのだろう、などと考えないほうがよい。自分がやる仕事は、最終的には自分が見積り、自分がスケジューリングするのだ。それも「プログラミングという仕事」の一部なのである。

★

スケジューリングが必要なのは、作業を与えられた時だけではない。１日目のプログラミングが終わった時点で、残り２日で全ての作業が出来るかどうかを判断することも大切である。このように、常に残作業を見積りながら仕事を進めなければならない。

そして、予定から遅れそうであれば、すぐにリーダーに報告する。これは絶対に躊躇してはならない。責任を感じて言い出しにくいという人もいるかもしれないが、開発作業の遅れなんて日常茶飯事だ。気にすることはない。

まともなリーダーなら、遅れを報告をしなかったことを責めることはあっても、遅れたこと自体を責めることはないだろう（※１）。

とにかく、遅れの報告は、早ければ早いほど良い。早く報告したほうが、再スケジュールなどの対策が取れる余地が多いからだ。

★

経験が少ないプログラマにとって、作業のスケジューリングは難しいものである。しかし、それをやらなければ、その場その場の思いつきで作業を行うような状態になってしまうだろう。そんなことでは、いつまでに作業が完了するのかわかったものではない。プロのプログラマとしては失格である。

どうしたらよいか分からない人は、まず、与えられた作業について、具体的にはどんなことをするのか、想像してみよう。作業をもっと細かいまとまりに分割して考えるといいだろう。次に、その細かい作業のひとつひとつについて、必要な時間を見積もる。そして、それを時間軸（カレンダー）上に配置するといいだろう。

こういった作業の見積は、プログラマという職種に特別に要求されるものではない。期限付きの仕事をする場合には、当たり前のことだ。しかし、意外と出来ない人も多いのである（※２）。

---

※１
もちろん、まともでないリーダーもいるので、困るのだが。それどころか、自ら顧客に遅れを隠し続け、納期直前に発表するようなプロジェクトマネージャもいたり...

※２
客先の担当者にも...

---

生産管理ができる事典

posted with amazlet on 06.06.24

田中 一成 黒須 誠治
日本実業出版社 (2004/03/25)
売り上げランキング: 25,963

おすすめ度の平均:

生産管理の入門書として最適

Amazon.co.jp で詳細を見る

革新的生産スケジューリング入門―“時間の悩み”を解く手法

posted with amazlet on 06.06.24

佐藤 知一
日本能率協会マネジメントセンター (2000/04)
売り上げランキング: 8,995

おすすめ度の平均:

スケジューリングについて最も分かりやすく書いた本

Amazon.co.jp で詳細を見る

情報求む

宅配ピザ屋の電話番が、注文してきたお客に住所を聞いたら、「なんでお前に俺の住所を教えないといけないんだ」と言われた、という笑い話がある。

★

システムの受託開発では、顧客の業務内容を詳しく知っておく必要がある。顧客の業務をシステム化するわけだから、これは当然のことである。

そもそも、何かをオーダーメイドする時には、多かれ少なかれ、情報を提供しなければならないものである。どんなに優秀な仕立て屋でも、体のサイズを測らずして、その人にぴったりの洋服は作れないのだ。

★

しかし、実際にシステム受託開発をしていると、顧客から十分な情報が与えられないこともある。

例えば、機密保持上の問題である。最近は、個人情報保護などの観点から、得られる情報が少なくなる傾向がある。セキュリティ意識が高くなることは良いことだが、一方で、開発がやりにくくなってきているのも確かである。

また、顧客側の担当者の問題もある。担当者が「コンピュータのことを何も知らない人」で、コミュニケーションに難儀することもある。あるいは、それ以前に「まったく仕事が出来ない人」で、とにかく難儀することもある。

まぁ、そんなのはまだいい方だ。根気強く付き合っていけばなんとかなるだろう。

本当にやっかいなのは、担当者がシステム化に乗り気でないというケースである。もちろん、その会社の経営者はシステムが作りたくて開発を依頼してくるわけだが、開発者と直接やりとりする窓口の担当者が、必ずしも同じ気持ちであるとは限らないのである。

特に、担当者が顧客側の現場で働いている人である場合、システム導入の目的が「現場の人員削減」だったりすると、目も当てられない。自分や自分の仲間達の「リストラ」のために、喜んで協力するような人がいるだろうか？

★

顧客から情報を得るということは、システムの受託開発にとって最も重要であるといってもいいだろう。しかし、このように、開発会社の側からはどうにもならない問題もある。

というわけで、開発を発注する側の会社にも、このあたりの配慮が是非とも欲しいのである。システムは、開発会社に頼んで放っておけば出来るというものではない。「一緒に作る」という気持ちが大切だろう。

---

■関連記事
・システム開発費の削減方法教えます
・うちの社員は信用できません

---

システム発注の基礎知識―システム担当者が知っておきたい

posted with amazlet on 06.02.26

藤広 哲也
すばる舎 (2003/05)
売り上げランキング: 58,905

おすすめ度の平均:

システム担当者として最低限の知識
目的が明確で○

Amazon.co.jp で詳細を見る

やりすぎが会社を滅ぼす! 間違いだらけの個人情報保護

posted with amazlet on 06.06.24

牧野 二郎
インプレス (2006/02/06)

Amazon.co.jp で詳細を見る

「環境不足」はマルチブートで解消せよ

2005年の今でも、Windows 95 で動くようなシステムを作ってくれ、と言われることがある。10年も前の OS を使うユーザーがどれほどいるのかは知らないが、不特定多数のユーザに利用してもらうシステムの場合、サポートする OS は多いほうが良いということだろうか。

しかし、これは、開発者にとっては大きな問題である。

というのも、同じ「Windows プログラム」を作るといっても、どのバージョンの Windows をターゲットにするかということによって、作り方が違ってくることがあるからだ。例えば、同じ機能でも、XP 専用のプログラムとして作るのは簡単だが、95 でも XP でも動くように作るには何倍もの時間と労力が掛かる場合もある。

技術的な難易度が高くなるというだけではない。サポートする OS のそれぞれで、ある意味重複した動作確認を行わなければならない。テストのために、パソコンを何台も用意して、色々な OS をインストールした、という経験のある人も多いだろう。

しかし、小規模な開発会社では、用意できるパソコンの数にも限界がある。作業スペースの問題もあるだろう。かといって、１台のパソコンに何度も OS をインストールしなおすのは、非常に手間が掛かる。

★

そんなときに便利なのが「マルチブート」である。１台のパソコンに複数の OS をインストールして、起動時にどの OS を利用するかを切り替えるのである。

Windows 以外の OS を切り替えて使うこともできるので、普段使っている Windows パソコンに、Linux 環境を追加するようなこともできる。

ただし、実際にマルチブート環境を構築するには、それなりの知識が必要である。特に、既に利用しているパソコンの環境を残したまま、別の OS を追加したいような場合には、リスクが伴う。

しかし、上記のような「環境不足」の問題でお悩みの方には、リスクに見合うだけのリターンはある。しっかりと勉強した上で、チャレンジしてみてはどうだろうか。

---

マルチブートの具体的な実現方法については、ネットで検索 すれば色々と情報が得られるだろう。「ブートマネージャ」と呼ばれるソフトが必要となるが、無料で入手できるものでも十分だと思う。私もMBM というフリーソフトを使っているが、高機能なのでお薦めだ。他に、「パーティショニングツール」と呼ばれるソフトが必要となる場合もあるが、その場合は、市販のパッケージを用意したほうがいいかもしれない。

---

	みき ゆうき, チームエムツー 著 いろんなOSを1台のパソコンで使うための本
	Partition Magic研究会 著 がんがん使おうPartition Magic
	ネットジャパン ノートン・パーティションマジック 8.0J
	ライフボート システムコマンダー 8
	ソースネクスト Acronis PartitionExpert Personal

省略してはいけないものもある

プログラミングでは、省略できるにしても、省略してはいけないものがある。

Ｃ言語の「const 修飾子」について考えてみよう。

「職業としてのプログラミング 」さんにも書かれているように、関数のポインタ引数に const の指定が無ければ、「この関数は、受け取った引数の示す値を変更しますよ」と明示しているということである。同記事では、

　よくコメントで、INPUTのみでしか使いませんと書いてあるのもありますが、const指定の方が親切です。

と、柔らかい表現で結ばれている。しかし、私は「親切かどうか」といったレベルの話ではないように思う。

「const ポインタ」の引数には、「const でないポインタ」を渡すことは出来る。しかし、その逆はできないのである。つまり、その関数を使いたくても、渡したいデータを「const ポインタ」で持っている場合は使えないのだ。使いたければ、わざわざ貴重なメモリを消費して、別の領域にコピーしてから渡してやらなければならない。

たしかに、コメントに「INPUT のみ」と書いてあれば、内部で値が変更される心配はないということが分かる。それならば、呼び出し元で const ポインタを無理やりキャスト（const でないポインタに変換）することで、その関数を利用することは出来るだろう。

しかし、そのようなキャストはプログラミングの外道である。「const みたいな面倒なものをつけなくてもキャストすりゃ呼び出せるんだからいいだろう」などと考える人には、他人が使うような関数を作らせてはいけない。

もちろん、「const って何ですか？」とか「キャストはしないほうがいいんですか？」なんていうレベルは問題外である。

★

以前、あるプロジェクトで、大手企業（そのシステムの元請会社）の作った共通的ライブラリを使用させられたのだが、その関数群に、上記の問題があった。const 修飾子をつけるべきところに、全く付いていなかったのである。

大規模なプロジェクトだったので、このライブラリの利用者はかなり多かったはずである。皆、不本意ながらもキャストして呼び出していたのだろうか（※）？

こんなことで怒るのはおかしいと思われるかもしれないが、思い出しても腹が立つ。私の中で、ライブラリを作ったその有名な企業のイメージが下がったのは言うまでもない。

---

※私は、ただキャストして共通関数を呼び出すだけの関数（いわゆる「ラッパー」）を作って、せめて自分のサブプロジェクト内に無用なキャストが拡散しないようにしていたように思う。

---

C言語体当たり学習 徹底入門

posted with amazlet on 06.04.30

前橋 和弥
技術評論社 (2001/05)
売り上げランキング: 101,577

おすすめ度の平均:

もどかしいけれど、身に着いてくる内容
無題
次につながる良書

Amazon.co.jp で詳細を見る

C言語のポインタがゼッタイにわかる本―最初からそう教えてくれればいいのに!

posted with amazlet on 06.04.30

立山 秀利
秀和システム (2005/12)

Amazon.co.jp で詳細を見る

普通の言葉

プログラマは、いつもシステム内部の仕組みを考えている。そのためか、誰と話をするにも、システム内部の言葉で話をしてしまう人がいるようだ。

小さなシステム開発会社では、プログラマが、直接ユーザーと話をしたり、文書をやりとりすることがある。そういうときに、「プログラマの言葉」を使ってしまう人がいるのだ。

例えば、

「この画面の商品名ラベルには、商品IDをキーにして商品テーブルを検索し、発見したレコードから商品名を取得して表示しています。」

といった具合である。

いわゆるエンドユーザー（つまり、普通の人）には、このようなプログラマの言葉は理解できないだろう。

「商品テーブル」がデータベースの「表」のひとつであることは、プログラマであれば容易に察しがつく。しかし、普通の人にとって、「テーブル」といえば、「食卓」だ。

「商品ID」のような言葉も、画面などに全く表示されないのであれば、ユーザーには通じないと考えるべきだろう（※）。

ユーザーがシステムについて、見たり触ったりするのは、画面や印刷物である。エンドユーザーに語るときは、そうしたシステムの外面（外部設計）に現れる言葉だけを使うようにしたい。

例えば、上記の文章は、

「この画面の商品名の欄には、商品管理画面で登録しておいた商品名が表示されます。」

のような表現になるだろう（もちろん、ここでは、「商品テーブル」が「商品管理画面」でメンテナンスされるという前提である）。

当たり前のことではあるが、ユーザーと話をする時は、ユーザーが理解できる言葉で語るようにしよう。

---

※「商品ID」が、システムを作る前から業務で使われていた言葉なのであれば、ユーザーにも理解できる。しかし、それがシステム化のために便宜的に作った「内部的な」コードである場合は、ユーザーには理解できない。

---

■関連記事
・「￥」について普通の感覚で考えてみる
・どこまで書くか設計書

---

ネットコミュニケーション&ライティングの技術

posted with amazlet on 06.04.16

藤田 幸江 平野 栄
明日香出版社 (2005/02/02)
売り上げランキング: 14,527

おすすめ度の平均:

ネット文章術としては過去最高
真面目な良い本
直球型ライティング技術の登場

Amazon.co.jp で詳細を見る

速効!SEのためのコミュニケーション実践塾

posted with amazlet on 06.04.16

田中 淳子
日経BP社 (2004/04)
売り上げランキング: 27,356

おすすめ度の平均:

コミュニケーションの大切さを実感！
SE以外の人にもお勧め！
速効性は高いですが…

Amazon.co.jp で詳細を見る