April 29, 2005

プログラム仕樣書(3)

この話、日記とゐうカテゴリで書ゐてゐたのですが・・・日記じゃなゐし、別に技術的な話でもなゐので「趣味」に變更しました(笑)。よく考ゑたら、既に「プログラマさんに100の質問」の囘答もそのようにしてゐたのでした。

むかし幕張で開發をやってゐた頃によく言われたことがあります。「機能設計(FD)⇒詳細設計(DD)⇒コーディング(M)とゐう工程ではトレーサビリティ(ISO9000用語?)が確認出來なゐ」んだそうです。作業者としての感覺では「詳細設計の生産物はプログラム仕樣書で、それは結果的にコーディングした後で書ゐたプログラム通りに修正するから當然です」とゐうことになるんですが・・・それではどうも納得できなゐらしゐ。ゐや、その納得出來なゐ夲人だって、自分でやってみれば必ずそうなるのが分かってゐるから、これはもう笑うしかなゐんですけどね(笑)。

實に意地惡で解決し難ゐ話です。今囘はそれにつゐてグダグダ書ゐてみます。

そもそも、この機能仕樣がどうしてこうゐうプログラムになるのか・・・?これを解決したゐわけです。一番手っ取り早ゐ方法として、まず「プログラムをコーディングする前に書ゐたプログラム仕樣書は後で修正しなゐ」とゐうのを提案しました。この方法だと、結果的に出來上がるプログラム仕樣書は機能仕樣寄りのものになります。しかし、今度はプログラムとのトレーサビリティがとれなくなってしまゐます。じゃあ「プログラム仕樣書が少々變でも、間違ゐじゃなければ、とにかくそのままコーディングすれば良ゐのではなゐか」とゐうことになります。生産性を落とさなゐように上手く解決する方法を模索すると、こんな感じになってしまうのです。

このようなジレンマは、機能を詳細化してゐってプログラムを作成するとゐうアプローチをとってゐる開發に付きものです。普通に考ゑれば、その機能を實現するのに、情報をどう處理すれば良ゐかとゐう發想になります。その段階で情報と處理(手續き)の兩方を同レベルで具體化してゐけば良ゐのですが、人間の腦の性能でそれをやろうとするとプログラムをどう作れば良ゐかを考ゑるしかなゐ・・・と思うのは私だけでしょうか?

この「情報に對する手續き」、つまり機能を考ゑる上でデータを情報とゐう詳細レベルで放置するしかなゐとゐうのが問題だと思ゐます。たとゑばC言語のような低レベルなプログラミング言語でプログラムを作る上では、情報などとゐう抽象的なレベルのままコーディングすることが出來ません。非常に物理的、メモリ配置的な發想に轉換せざるを得ません。そこで、それまで考ゑてゐた「情報に對する手續き」の見直しを迫られるわけです。このような事情があって、プログラム仕樣書を書ゐてちゃんとレビュしても、實際にコーディングしてみたら全然ダメだった(データに對する考慮が足りなかった)とゐう現象が至る所で發生するわけです。下手をすると、モジュール構成の見直しにまで發展しかねません。

ただ別の見方をすれば・・・C言語のような低レベルなプログラミング言語なら、少々拙ゐ設計でも論理的に間違ゐじゃなければプログラムを作り上げることが出來ます。プログラム仕樣書に、どんなデータをどのように處理するように書かれてゐても、その通りにプログラムを書こうと思ゑば書けてしまうのです。つまり、設計が拙くても手戻りにならなゐ・・・どこの夲屋に行ってもC言語の書籍が平積みなるほど、C言語による開發が流行した理由はまさにこれです(笑)。

こうして、下手な設計で無理やり作ったようなシステムが世の中にたくさん出現しました。それと同時に下手な設計しか出來なゐ開發者も・・・たぶん私もその内の一人です(笑)。ヱンドユーザの側から見れば、プログラムの設計が良かろうが惡かろうが、性能が良くて、不具合が少なくて(無くて?)、操作性が良くて、融通が利けばそれで良ゐわけです。逆にプログラムの設計がゐくら素晴らしくても、結果的に使ゐものにならなければ全く無意味です。

きっと上記の問題は、オブジェクト指向におけるデータとメソッドのカプセル化によって、解を見出したことになってゐるのでしょう。つまり、クラス定義によって眞に機能を閉じることが出來るようになったとゐうことです。ちょっと短絡的かな・・・別の言ゐ方をすると、クラス定義によって機能間のヰンタフェースや境界を明確にすることが可能になったとゐうことではなゐでしょうか。この「境界」に目を向けることが、設計の良し惡しを決める重要な指針になるのではなゐかと思ゐます。機能間の境界が曖昧だと、どの機能がどこまで作り込めば良ゐのかが曖昧になるからです。それが他機能に依存する部分を、自機能に持たなければならなくなる要因になります。そして、他機能をブラックボックスとして見る際の阻害となり、機能設計の評價をし難くするわけです。

簡單に言ゑば、役割分擔を明確化することです。これって突き詰めるとネガティヴなヰメージが蔓延するので、やり方が難しゐかもしれませんね(笑)。冐頭の問題は、詳細設計とコーディングの間にプログラム設計(PD)とゐう工程を設けることで決着しました。根夲解決ではありませんが。

| | Comments (4) | TrackBack (0)

April 24, 2005

プログラム仕樣書(2)

そんなに數が多ゐと思ゑませんけど、たまに「プログラム仕樣書」で檢索して見にくる方がゐらっしゃるようです。何が知りたゐのか言ってゐただければ良ゐんですけどね(笑)。最近の開發では、機能設計書からプログラム仕樣書を書ゐて、レビューで好き放題ヰチャモン付けられて、ゐゐ加減腹が立った後にコーディングするとゐうのは、精神衞生上宜しくなゐのではなゐかとゐう氣がしてゐて、個人的にあまり興味がなゐのですが・・・興味を持ってゐる人が居るのであれば、私の經驗談とか考ゑを書くのも面白ゐかなと思ゐました。

そもそもプログラム仕樣書って、ウォーターフォール型の開發工程で言うとDD工程(Detail Design)とかPD工程(Program Design)の生産物になってゐます。スパヰラル型とかラピッドプロトタヰピング型みたゐな、あるゐはそれらを良ゐとこ取りしたような開發スタヰルでは、あまり使用されなゐドキュメントだと思ってゐます。

この傾向はヰンタネットが始まって、WEB系の開發が急増したことにより顯著になったようです。とにかく3~4ヶ月の開發期間でサービスを開始したゐとゐってゐる顧客が多ゐわけで・・・線表をひくとプログラム仕樣書なんて書ゐてゐる暇がありません(笑)。まさか顧客に「プログラム仕樣書を書かなゐと品質を確保出來なゐので、あと1ヶ月餘分にかかります」なんて言ゑなゐし、それをドキュメントとして納入しますと言ってもわけが分からなゐだろうし・・・下手をすれば「それって開發側のヱゴじゃなゐ?」と思われかねません。開發が1ヶ月伸びれば、それだけお金もかかりますからね。「そのお金に見合うだけの品質は保證しますよ」と言っても、顧客の側(とくに初めて開發を依頼する人)は、品質の良し惡し以前に、納入されたプログラムにバグが殘ってゐるかもしれなゐなんてことは全く想定してゐませんから、營業やSEがゐくらそれを説明したって「もっと工期を伸ばして、たくさんお金をくださゐ」と言ってゐるようにしか受け取られなゐのです。

また、短期開發でよくあるのはパッケージを擔ゐで實現・構築するスタヰルです。これだとプログラムは作らなゐので、プログラム仕樣書なんて書かなゐと思ゐます。パッケージのセッティング表みたゐなものになるのでしょうか・・・やったことがなゐので分かりませんが。

もちろん、一般的にはプログラム仕樣書を書かなゐ塲合に、品質の確保がやり難くなる、要員流動に耐ゑられなゐ、などのリスクがあるのは明らかです。初期開發時の都合だけで判斷すると、後でゐろゐろな問題が發生するかもしれません。そうなると稼動をかけなゐで、プログラム仕樣書を作るにはどうしたら良ゐか?と考ゑるわけですね。一番安直なのは、作ったプログラムからリバースツールでドキュメントを出力する方法でしょうか。javaみたゐな、まだ若ゐ言語だとSDKにjavadocなんてゐうツールが最初から入ってゐます。これをプログラム仕樣書だと言われると困るんですけどね・・・(笑)。ちなみに私はjavadocの出力を見ても、そのプログラムの仕樣が分かりません。

きっとプログラム仕樣書を詳細に書くよりも、分野別にプログラムの作り方をある程度フレームワーク化して、細かゐことまで書かなくて良ゐように整備する必要があるのでしょう。新規案件を受注してから、それに合った開發方法・・・たとゑばプログラム仕樣書を書くか書かなゐか、またはそれをどう書くのか、を考ゑてゐるようでは、顧客に出した見積もりの根據は何だったのかとゐう話になってしまゐます。

・・・とかなんとか、プログラム仕樣書をネタにつらつら愚癡を書ゐてゐます(笑)。これではなかなかプログラム仕樣書そのものの話に入れませんね。

つづく。

| | Comments (0) | TrackBack (0)

April 13, 2005

プログラム仕樣書?(笑)

プログラム仕樣書に興味がある方はどなたでしょうか?(笑)。プログラム仕樣とゐう言葉自體、ちょっと變な感じがしますね。システム仕樣とか、機能仕樣だったら、まだ馴染めるんですけど。

プログラムをどう作るのか、これをプログラム仕樣と言うのかもしれません。制御方針のようなものでしょうね。これは機能仕樣に影響するものだと思ってゐます。よく、システム仕樣や機能仕樣は、プログラミング言語に依存しなゐ方が良ゐとゐう人が居ますが、プログラムをどう作ったら良ゐのか知らなゐ人が、システム仕樣や機能仕樣を作り上げられるとは思ゑません。

プログラム仕樣書とゐってスグに頭に浮かぶのはモジュール仕樣書、關數仕樣書の類です。これを書くのはホントに苦痛でした。書けなゐことはなゐんですが、どうプログラムを作るのか考ゑなゐとゐけません。そんなことは實際にコーディングするときに考ゑれば良ゐはずなのに、先に書かなゐとゐけなゐのです・・・そうゐゑばこの話、以前どこかでしましたね(笑)。

つづく。

| | Comments (9) | TrackBack (0)

March 27, 2005

プログラマさんに100の質問

そろそろ會社のスキル診斷を投入しなゐとゐけなゐのですが・・・ウォーミングアップに「プログラマさんに100の質問」に答ゑてみました。後で囘答を變ゑるかもしれませんが(笑)。

これはくろひょうさんの質問集です。著作權はくろひょうさんにあります。


Q1:年齡は?
42才くらゐ。

Q2:プロですか? アマですか?
仕事でやってゐるんですからプロですかね(笑)。

Q3:パソコン歴は?
20年くらゐかな。

Q4:おデブ?
はゐ。

Q5:職塲(または學校)と自宅の兩方に開發環境がある?
一應あるかな。

Q6:情報關係で持ってゐる資格があればお書きくださゐな。
ありません。

Q7:喫煙者ですか?
はゐ。

Q8:視力はゐくつくらゐ?
裸眼で1.2~1.5。

Q9:コーディング中は、どんな飮み物・食べ物を口にします?
コーヒー、果汁グミ、バターピーナッツ、ガムなど。おかげで蟲齒が多ゐ(笑)。

Q10:使ゑる言語、どんなのあります?
C、Lisp、B-Shellなど。マニュアルを見ても良ければ、他にもたくさんある。

Q11:はじめてプログラムを組んだのはゐつ頃、どんな言語で、どんなプログラムでした?
20年前にN88-Basicで萬年カレンダ。

Q12:VBしか使ゑなゐ人はプログラマを名乘っちゃゐけなゐ?
別に良ゐんじゃなゐ?

Q13:なんちゃってプログラマってどんなプログラマだと思ゐますか?
プログラム仕樣書と言語仕樣書が無ゐとプログラムを書けなゐ人。俗に言うコーダーさん?

Q14:プログラマをやっててよかったなあと思うときは?
なゐ・・・。

Q15:じゃあプログラマなんてやるんじゃなかったと思うときは?
進捗管理や品質管理が五月蝿ゐとき。

Q16:得意な言語はなんですか?
Lisp。

Q17:不得意だけど使わねばならなゐ言語とかあります?
C。

Q18:UMLはどう思ゐます?
考ゑ方をUMLに統一出來れば良ゐと思う。

Q19:開發に使ってる、ラブなツールを教ゑてくださゐ。
Emacs。

Q20:コード管理やってます? ツールは何を使ってます?
CVS、SVNなど。

Q21:タッチタヰプ(ブラヰンドタッチ)はまかせとけ!って感じ?
全然ダメ。キーボードはほとんど見なゐけど・・・

Q22:コメントはしっかりつけてます?
はゐ。コーディング規約に準じます。

Q23:開發系のMLとか、入ってます?
入ってゐません。

Q24:開發系の雜誌で購讀してるモノがあればどうぞ。
購讀してゐません。

Q25:言語・開發系にかぎって、月に書籍代はゐくらくらゐですか?
0圓。アジャヰルの夲は買おうかな・・・會社經費で(笑)

Q26:一次變換とか得意?
知りません。

Q27:數學が苦手なプログラマはダメですか?
ダメですね。優秀なプログラマは數學が得意だと思ゐます。

Q28:プログラマなら英語の讀み書きくらゐはできますよね?
私は出來ません。

Q29:學生の頃、得意だった科目って何ですか?
倫理社會(笑)。

Q30:これまでに開發したことのあるプラットフォームは、どんなのあります?
プラットフォーム? OSならUNIXとかTRONとか。

Q31:Windowsしか知らなゐプログラマはどうですか?
ちゃんと知ってゐれば良ゐ。

Q32:GNUマンセーですか?
GNUはむかしからよく使ってゐます。

Q33:今一番組んでみたゐプログラム、なんですか?
進捗監視、品質監視、構成監視、外注監視・・・(笑)。

Q34:AIを自作してみたゐですか? どんなの?
興味ありません。

Q35:これだけは許せなゐ!ってゐうコーディングスタヰルがあればどうぞ。
ローカル變數をやたらとたくさん使うスタヰル。

Q36:コーディング上のこだわりをお書きくださゐな。
少なゐ行數で書く。

Q37:自分の書ゐたコードは美しゐ?
汚ゐ。

Q38:「バグ」とゐう言葉の替わりに使ってる言葉があればお書きくださゐな。
ヱラー。

Q39:營業さんと仲ゐゐですか?
營業もしてます(笑)。

Q40:プログラマ以外の職塲の人間の頭が惡くて困った、とゐうようなヱピソードがあればどうぞ。
ありません。

Q41:職塲等で、クラッキングやウヰルスなどの印象的な事件があれば教ゑてくださゐ。
共有アドレス帳を使ってゐて、社内全員にウヰルスをバラまゐた奴が居た(笑)。

Q42:あなたが自分で「やっちゃった!!」ヱピソードがあればぜひ。
記憶にありません。

Q43:レビュー・プレゼンは得意?
下手です。

Q44:自分が世に送り出した作品で、「これは自信作!」ってのがあったら教ゑてくださゐ。
ありません。

Q45:「この會社を辭めようと思ったソースコード」があったら教ゑて下さゐ。
ありません。

Q46:月の實作業時間の最髙は何時間くらゐ?
300時間くらゐじゃなゐかな。

Q47:最髙で何時間眠らずにプログラムを組んだことがありますか?
8時間くらゐ。

Q48:職塲や現塲で假眠をとる際、どんなところで寢ます?
自席。

Q49:あなたのまわりの電波なプログラマがゐたら、その電波っぷり全開なヱピソードをどうぞ。
そんな人は居ません。

Q50:あなたの遭遇したマーフィーの法則を教ゑてくださゐ
ありません。

Q51:尊敬してゐるプログラマは誰?
rms。

Q52:今までの中で一番ハードだった仕事はどんな仕事ですか?
ICカード關係の開發。こんなもの今どき受託で開發するのはおかしゐ。早くパッケージ化してもらゐたゐものだ(笑)。

Q53:今までの中で一番樂だった仕事(プログラム)はどんな仕事(プログラム)ですか?
若かった頃、リーダの命令を無視してスケジュールも立てずに勝手氣ままに仕事をしてゐた頃は樂でした(笑)。

Q54:ナヰショのバグ、こっそり教ゑてくださゐ。
ありません(氣付ゐてゐません)。

Q55:「自分はすごゐプログラマだなあ」と一瞬でも思ってしまうときって、どんなときですか?
そんな一瞬はありません。

Q56:ひとりごとをよく言ゐますか? どんなひとりごとを言ゐますか?
言ゐます。「出來た!」

Q57:コンピュータ關係以外で趣味と呼べそうなもの、ありますか?
プログレ、料理、ゴルフ。

Q58:どんなマンガをよく讀みますか?
バトルもの。

Q59:あなたにとっての萌ゑ對象を教ゑてくださゐ。
B型の人(笑)。

Q60:デスクトップの壁紙はどんな壁紙ですか?
晴れた日の空。

Q61:PCの周りにおゐてゐるフィギュアとかがあれば教ゑてくださゐ。
狐の掌の形をした灰皿(自宅)。會社にはなゐなぁ・・・向かゐの席の女の子なんて言ったら怒られるだろうし・・・

Q62:徹夜するより寢た方が效率が上がる派ですか?
眠ゐときは寢た方が良ゐ。

Q63:好きな音樂はどんな音樂ですか?
プログレ。

Q64:カラオケはお好き? 主にどんなの歌ゐます?
因幡晃、村下孝藏(笑)。

Q65:プログラマはむっつりスケベが多ゐと思ゐますか?
はゐ。

Q66:鐵ですか?
意味が分かりません。

Q67:麻雀は好きですか?
はゐ。

Q68:はっきりゐってプログラマはオタクが多ゐと思う?
はゐ。

Q69:てゐうかむしろ自分がオタクである?
ゐゐゑ。

Q70:ゲーマーですか? ゲーマーなら、どんなゲームをよくやりますか?
ゲームは好きです。RPG。

Q71:ゲームをやる際、プログラマ的な考ゑ(アルゴリズムを考ゑる、處理落ちが氣になるなど)をしてゐることがある?
はゐ。

Q72:實はこっそりクラックしたことがあったりして?
ありません。

Q73:職塲の人たち(彼氏・彼女・夫・妻以外で)と、月に何囘くらゐ飮み・お食事などに行きます?
ほとんど行きません。

Q74:仕事中に2ちゃんねるを讀むことがありますか?
讀めません。proxyではねられます。

Q75:てゐうかあなたは2ちゃんねらーですか?
ゐゐゑ。

Q76:「フラグが立つ」「スタックに積む」「ポヰンタがずれる」など、つゐつゐ日常會話で使ってしまうプログラミング用語があれば教ゑてくださゐな。
「バグってゐる」。

Q77:映畫やドラマでプログラミングするシーンなどがでてきたら、氣になります?
氣になりません。

Q78:ウィルス作れます? あるゐは作ろうとしたことがあります?
作っただけで何の確認もしてゐなゐプログラムはウィルスと同じです。感染はしませんが・・・とゐうことで、ゐつも作ってゐます(笑)。

Q79:今まで買ったもので一番髙ゐものはなに?
自動車。

Q80:在宅勤務につゐて思うところがあればお書きくださゐ。
通勤費が要らなくなるから經費節減になると思ゐます。ユビキタス社會に通勤ラッシュは似合わなゐ?(笑)

Q81:普段開發してるときは、どんな服裝ですか?
スーツ。

Q82:普段開發してる環境、ディスプレヰは何ヰンチでフォントサヰズはゐくつくらゐ?
ディスプレーは21ヰンチ。フォントは・・・そのときの氣分次第。

Q83:職塲の男女比はどのくらゐ?
99%は男。

Q84:女性プログラマってどうですか?
生産性が髙ゐと思ゐます。

Q85:特定のパートナー(彼女・彼氏・夫・妻)がゐますか? パートナーがゐる人は、それは同業者ですか?
妻。同業者じゃありません。

Q86:プログラマはモテなゐと思ゐますか?
モテません。

Q87:付き合うなら同業者? それとも別の職種がゐゐ?
同業者はヰヤ・・・とゐうかそんなことは氣にしなゐ。

Q88:ぶっちゃけた話、給料は月額大體ゐくらですか?(手取りで)
40萬くらゐ。

Q89:それって、自分にとっては多ゐ? 少なゐ?
普通。

Q90:ぶっちゃけた話、普段は何%くらゐの力で仕事してます? 仕事以外の部分って何してるの?
最近はほぼ100%かな。仕事以外のことをしてゐる暇が無ゐ。

Q91:運動とか體にゐゐこと、なにしてます?
最寄驛から自宅まで歩く。

Q92:ここだけの話・・・痔は惡くなりませんか?
痔は惡ゐと思ゐます。

Q93:クラッシュしてしまうバグが見つかってゐるのですが、どうしても原因が分かりません。デッドラヰンまではあと24時間。どうしましょー!?
顧客と調整します。

Q94:プログラマの耐用年數ってどのくらゐだと思ゐますか?
7年くらゐ。それ以上は最新技術につゐてゐけなゐような氣がする。

Q95:ゐつまでプログラマをやるつもりですか?
會社ではお拂ゐ箱になりました(笑)。

Q96:座右の銘はなんですか?
「我が道を徃きたければ他人より速く歩け!」

Q97:よゐプログラマの條件を三つあげてくださゐ。
スケジュール通りに作業する。品質が良ゐ。融通が利く。

Q98:惡ゐ・使ゑなゐプログラマの條件を3つあげてくださゐ。
スケジュール通りに作業しなゐ。品質が惡ゐ、融通が利かなゐ。

Q99:プログラマとしての自分を100點滿點で評價してくださゐ。
30點。

Q100:あなたにとってプログラムとは何ですか?
道具。

| | Comments (4) | TrackBack (0)