894587 ランダム
 HOME | DIARY | PROFILE 【フォローする】 【ログイン】

鶏が口だけでも飛び立ちます

鶏が口だけでも飛び立ちます

【毎日開催】
15記事にいいね!で1ポイント
10秒滞在
いいね! --/--
おめでとうございます!
ミッションを達成しました。
※「ポイントを獲得する」ボタンを押すと広告が表示されます。
x

PR

Keyword Search

▼キーワード検索

Profile

Solis

Solis

Calendar

Comments

effelpist@ kilovermek.es effelpist <a href="https://kilovermek.es/…
http://buycialisky.com/@ Re:TinyURLのようなRedirectionの仕組み(06/30) viagra cialis predamdiferencias entre e…
http://viagraiy.com/@ Re:TinyURLのようなRedirectionの仕組み(06/30) cialis viagra ou levita <a href=&qu…
ジャピーノ@ フィリピンペソなど興味無し 日本でビジネスの手腕が発揮できない者は…
KJN@ MagpieRSSでRSSをHTMLに展開する方法を教えてください。 こんにちは! 最近はwordpressを使って、…
とおりすがり@ たしかに・・・。 この会社の社長さんはすばらしいかたです…
どぴゅ@ みんなホントにオナ鑑だけなの? 相互オナって約束だったけど、いざとなる…
お猿@ やっちまったなぁ! http://feti.findeath.net/rue-oo1/ ちょ…
もじゃもじゃ君@ 短小ち○こに興奮しすぎ(ワラ 優子ちゃんたら急に人気無い所で車を停め…
リナ@ 今日は苺ぱんちゅ http://kuri.backblack.net/ps82ouo/ 今…

Recent Posts

Archives

2024.10
2024.09
2024.08
2024.07
2024.06
2024.05
2024.04
2024.03
2024.02
2024.01

Category

Favorite Blog

歳とりすぎて、、 にわとりのあたまさん

遍路と農業とFXの… おばか社長さん
田舎で!情報起業 … 田舎っぽ こと 関根雅泰さん
パンラヤー(妻)は… samo1965さん
アサワ(妻)はフィ… マハルナさん
     さ.ゆ.り.… さゆり1995さん
2008.02.13
XML
カテゴリ:カテゴリ未分類

ここ数日いくつかの設計文書を作成している。

少し前はプログラムばかり作っていたが、文書としてまとめる必要があるので設計書を作成している。違う種類の仕事だなぁ。もともとはプログラマーではなくて、コンサルティング業から入ったので設計書もどちらかというと自分流のものだ。

最初に入った会社はMETHOD/1と呼ばれる数百種類の形式からなる膨大なシステム設計書類による開発論があったので、それを学んだ。まあたしかに共通言語として役に立つし、お互いのコミュニケーションの手助けになる。だけどオブジェクト指向の考え方が導入されるとバージョンアップして、さらにスパイラル方式の開発やアジャイルの開発手法が入ってどうなったのだろうか、それ以後は知らない。

たぶん設計文書っていうのは、作ったものの決して読まれない性格のようなものの気がする。お役所だと設計書の枚数や綴じたバインダーの重さでお金をもらうようなものだからね。誰も読まない設計書はその量に圧倒されて値段が決まる。量が質に勝る。

このところのスクリプト言語は、前提条件が少ないので同じことをするにもプログラムの量は少ない。オープンソースなどでライブラリを使うことができればさらに量が減る。量を減らすことが品質につながる。下手なプログラムを書くよりは、ライブラリをそのまま使ったほうが安定していてバグが少ない。

そうすると設計書そのものが、かなりソースプログラムに近くなる。意味のある変数やメソッド名を使っていれば、プログラムの意味するところは設計書がなくてもソースプログラムを読めばわかる。そもそもソースの変更が頻繁に行われれば、それを設計書に反映するのも大変だ。

だから要件定義(要求定義)や外部設計書(システムの大枠)は方針を決めるために必要だが、内部設計書(プログラムやデータ定義など)は開発後がいいのかもしれない。多人数でプログラムを作るときはお互いにコミュニケーションをとるために、内部設計で決まりつつあるもの仕掛かっているものを話し合うことが必要だろう。ただ、簡単な紙切れ1枚と話しあいでいいのではないか?

 

さてコミュニケーションをとるために必要な文書であって、設計文書を作るための仕事のための文書ではないので、どうやってつくろうか?

今は新しい仕事になるかどうかわからないがシステムの設計に関するもの3~4種類。そして終了しつつある仕事の設計書1種類を作っている。

まず何を伝えるべきかを考えるところから始まる。
自分の主張するところ、必ず伝えなくてはいけないところ、そういうものをマインドマップで列挙していく。集中して考えが出てくる場合もあれば、後でコーヒーを飲んでぼぉっとしているときに思いつくこともある。

マインドマップは、FreeMindを使っている。Javaで作られているが今のパソコンでは十分早く動作する。大昔はActaのようなアウトラインプロセッサを使っていたが、アウトラインは1次元だがマインドマップは2次元なのがよい。最近マインドマップは廃れてきたなぁ。私自身は実は高校生のときからマインドマップを使っていて25年くらいになる。高校や大学のノートで友人や先生から、「何?これ?」と言われてきたがいい時代だ。ただマインドマップの使い方としては正統派でないかもしれない。

マインドマップに書き出していると、「ここはここにつなげたほうがいい。ここが足りないので足そう。」と、だんだんと考えがまとまっていく。論理の推敲にはうってつけだと思う。それで文書として提出できれば一番いいのだが、いまのところそういうわけにはいかないので、それをワープロなどに書き出す。自動的に書き出すのは市販のMindManagerでもまだまだだと思うので、ほとんど手作業だ。このマインドマップから、テキスト、HTML、PDF、JPEG、XMLなどどんな形にでも書き出せるのだが、人が読む文書には程遠い。

そこでワープロに移すのだが、時間があればわかりやすい図にする。図を書く時間がなければ表にする。その時間もなければ文にする。まあ文にすると、正直自分でも読みたくないようなものになるのだけれどね。文にする場合にしても、なるべく箇条書きで文の長さを短くする。情報に向き不向きがあるので、全部そうするわけにはいかないものね。

図>表>箇条書き>文

これはコンサルティング時代に上司が教えてくれたものだ。図は凝った画像などを使って見た目がきれいであればあるほど、情報がまとめられていることが多い。情報をそぎ落としているからであるが、ただ末節の大切なデータが落ちている場合もあるので注意が必要だ。

UMLはシステム開発の設計図として使われるんだけれど、、、これもMETHOD/1の欠点を踏襲しているような気がして、、なんか現状にそぐわないんだよな。というか使えるのがクラス図とシーケンス図を必要な個所で使うぐらいのような気がしてならない。

プログラムからJavaDoc(RDoc)のように仕様書を取り出せるんだから、 あまり必要と感じないのは小規模の開発ばかりしているからだろうか?

そして、マインドマップやアウトラインプロセッサはまとめることはできるんだが、新しいアイディアは意外にも出てこないんだよね。帰納的推論はできるんだけど、演繹的な創発ということが難しい。 






お気に入りの記事を「いいね!」で応援しよう

Last updated  2008.02.14 17:26:40
コメント(2) | コメントを書く



© Rakuten Group, Inc.
X