ライブドア、「社内の連絡は、専用の電子メールで」、さすがだ！こういう需要増えるかも？

　ＮＨＫニュースオンラインの

　このニュース
本社がメールで不正を協議か
http://www3.nhk.or.jp/news/2006/01/17/d20060117000156.html
によると（以下、斜体は上記ニュースより引用）


調べによりますと、およそ５０社に上るライブドアグループでは、会社どうしや社内の連絡はほとんど紙に残さず、専用の電子メールで行っていました。


　おお、さすがだ！きっと、専用の電子メールソフトには、バリバリに暗号がかけられていて、見られないとか。。。

　いや、００７のように、「このメールは、自動的に消滅する」とか（＾＾；）

　専用のメールソフトなら、いろいろできますね。。

　今後、企業でも、こういう需要、つまり、暗号バリバリにかけて見られなくするとか、一定期間が過ぎたら、自動的にメールが消滅するというのが、はやるかもしれない。。

　いや、盗難のときの、個人情報保護とか、そういうためにですよ！

　べつに、悪いことをするからはやるといういみでは。。。？？


　

inputのtextに、表示幅より長い文字列を入れたときのBREWとIEの違い

　昨日のINPUTタグのパソコンと、ケータイＨＴＭＬの違い。

　これ、他のケータイでなるのかは確認してないんだけど、少なくともBREWのIHTMLVIEWERで、入力項目にフォーカスがあたったとき、そのテキストボックスの大きさより、文字列のほうが長かった場合、マーキーという、文字が動くモードになります。
　（なので、全体が見えます）

<marquee behavior="scroll">ＩＥの人だけ、これが、マーキーの例
</marquee>

個人的には、これ、好きなので、パソコンでも、「INPUTタグの中で」、できるのかな？
とおもって（ふつうにやったら、できるのは知っている。つーか、上にやってるし）、ちょっとしらべてみた。

まあ、IEだと、マーキーのタグがあり、ねすけの場合、JavaScriptでとか書いてあるのが多いけど、これは、inputのところではなく、純粋に文字を動かす場合の話。

　inputタグで、マーキーさせようとしているところを見つけました。

　このサイト　http://www.red.oit-net.jp/tatsuya/java/Fmarquee.htm

　でも、ここのサイトを見ると
「あいうえおカキクケコさしすせそ」という文字列を

　　INPUT type="text" size="10"

で表示させると。。

（以下、斜体は、そこからの引用）


＜INPUT＞タグのsize属性の大きさによって、またスクリプトでのテキストのセットタイミングによって、
[クケコさしすせそ] の時もあれば
[さしすせそ□□□] の時もあれば（□は空白)
[ケコさしす]のようにもなるようです。


うーん、たいへんそう。。

こーいうてん、ケータイのほうが。。。いいのかなあ？？

Ｐ．Ｓ　にたような話題で、テーブルのスクロールって言う話があるよね。
　　　　リストが選択するとマーキーになるけど、それじゃーやだっていう人のために、
　　　　どーしようか、スクロールさせる？？という話題

　で、それに関連してなのかなあ、テーブル折り返し技術つーのが書いてあるサイトを見つけた。っていっても、BREWじゃないみたい。
　

外部仕様書の構成について、確認してみる。

　唐突ですが（理由は最後に書きます）、一度書いた気もするけど、
　外部仕様書に必要な仕様書の構成について。
　　まあ、外部仕様書でなくても、プログラミング、あるいは詳細設計に入る手前に必要な仕様書とそのドキュメント構成とかんがえてもらっていいです。

---

で、その外部設計書の構成は、こんな感じだと思う。

●表紙（なくても支障はないが）
●はじめに（ないときもある）
●目次（なくてもいいけど、ふつう、付けよう）

●修正記録（なくてもいいけど、付けろといわれることも）

●システム概要
　→要求仕様で出てくる、大項目レベルの機能要件に関して、
　　体系的に文章でまとめる。これが、ちょー短い場合は、
　　はじめにに書いてしまって、ここはない。

●ハードウェア構成

●ソフトウェア構成・環境
　　本システムの位置づけ（というのを指摘する場合も）
　　→フレームワークなども使う場合には、ここに書いておく

●ネットワーク・通信について（必要あれば）

●機能概要
　要求仕様に出てくる大項目から展開し、以下の外部入出力の関連が
　わかり、システムができそうと思えるくらいブレークダウンする。
　→これは、状況により、レベルが変わる

●画面定義
　画面遷移
　各画面の詳細

●ファイル定義
　ファイル名一覧
　ファイル内容（固定長等：レコードレイアウト
　　　　　　　　ＸＭＬ：タグと属性）

●ＤＢ定義

●通信等
　その他、入出力インターフェースの内容

（なお、このほかに、用語集や、要素技術やフレームワークの説明がはいったりなどもある）
（管理情報も、このあとに入れることもある（スケジュールなど））

---

　機能概要で、各プログラムのインターフェースまで落とし込んでしまう場合もあります。
　順番はこのとおりとは限りませんし、名称は違うと思います。
　機能概要のところがＵＭＬだと、クラス図と、シーケンス図になったり、
　ＤＢ定義をＥＲ図にしたり、などなど。。さまざま。　

　で、問題は、なぜ、こういう構成をとっているか、なぜ、これが、外部仕様書なのかというところですよね。

　外部＝システム外部に対する仕様なので、本来、外部との境界線（バウンダリつーのかな）となる、ファイル定義と、画面定義、ネットワークなんかあるとき、通信などを示せばいい。
　このとき、あくまでも、外部に対する仕様なので、ファイル定義でも、内部で利用する作業ファイルはかかなくてもいい。
　（ただし、ＤＢ定義に関しては、完全に内部にとじることが明白でない限り、ＤＢの特徴に、「共用性」（ほかのシステムも利用できる）があるため、一般にはＤＢ定義もいれる）

　なので、画面定義以降が必要なことは、分かっていただけると思う。

　その上は、この画面定義などの、妥当性を示すのに使う。
　ある入出力があったとき、その入出力をつかって、処理を本当に行うことができるのか、その処理は、要求を満たしているのか？ということで、後に書かれる、画面定義、ファイル定義のことばを使い、要求仕様書の該当する要求を明示し、そのつながりを書くのが、機能仕様になる。
　これで、要求仕様書と、画面入出力がつながる。

　しかし、その要求は、コンピューター上で実現できるのか？というのを示さないといけない。それが、ハードウエア、ソフトウエア、通信の仕様書になる。機能仕様に書かれている処理は、その環境で実現できるかどうかを確認する。

　そして、はじめに、そもそも、このドキュメントは、要件仕様書のどこを受け、どの範囲に書かれているかというのを示すために、「はじめに」と「システム概要」がある。

　目次については、あるとべんり。
　
　表紙や修正情報は、ドキュメント管理上、必要な項目が書かれる。

　ということで、こんだけは必要。あとは、お好みで付け加えることになる。

---

　って、思ってて、いままで、だいたいその路線で間違いなかったんですよ。

　でも、今お仕事やっている、外部仕様書みて、びっくり！

　画面の様子しか、書いてないんですけどお。。

　これで、ファイルになにを落とせというの（＾＾；）

　つーか、トップ画面って、どれ？？

　お客さんがいったことを、まとめてるだけのよーな気がー

　念のためにいっておきます。

　そのような、お客さんの言ったことをまとめたものを、「メモ」といいます。
　そのうち、要求部分をまとめ、ある形式化したのを、要求仕様、要件定義書といいます。

　でも、じゃあ、おなじように、お客さんからの外部部分をまとめ、形式化したのを、外部仕様書というかというと、違います。
　たぶん、こう勘違いしたんだとおもうけど。。。
　お客さんに見える外部は、画面なので、お客さんからのメモをまとめて書いたら、画面だけです。さらに、自分に関心があるのしか書かないので、トップ画面は分からなかったりします。
（いま手元にある仕様書はそうだ、部分部分しかない）

　だけどね、他のシステムとのインターフェース、たとえばね、他のシステムにファイル転送する場合（今回、それが中心なんですけど）
　そのファイルも、外部なのですよ。他のシステムですから。
　つまり、そのファイルフォーマットも、外部仕様書に入れないといけません。
　そーしないと、プログラムが作れません。

　でも、お客さんは、そんなの知んないわけよ。自分が知らないうちに転送してるんだから。
　だから、外部設計書には、お客さんの知らないこともまとめないといけないんだけど。。
　。。。わかってんのかなあ。。。

　。。。わかってないのかなあ。。

　最近の世の中は、こんな感じになってきてしまったのかなあ。。