マクロで、OutLookの中身を操作して、内容や表題、添付ファイルを取得する

　Windowsで、一度OutLookでメールを受信して、その受信したデータを処理したいという場合がありますよね。
　そういうときのための、ExcelからマクロでOutlookのデータにアクセスするときのメモメモ

ExcelでOutLookVBAを使う場合
・マクロで、VBE画面をだしたら、そこのツール→参照設定で、
Microsoft Office 9.0(等、違うバージョンでもＯＫ） Object Liblary
　　　にチェックが入っていることを確認
Microsoft Outlook 9.0(等、違うバージョンでもＯＫ） Object Liblary
　　　にチェックを入れる

OutlookのＶＢＡについては
http://www2s.biglobe.ne.jp/~SATSYS/outlookvba.htm

たとえば。。。

受信トレイにあるメールの表題を１行目、内容をそれ以降にメッセージボックスに出し、添付ファイルを保存します。

Sub ボタン1_Click()
    Dim obj As Object
    Dim outlook As Object
    Dim i As Integer
    
    Set obj = CreateObject("Outlook.Application")
    Set outlook = obj.GetNamespace("MAPI") ' Namespace オブジェクト
   
    For i = 1 To outlook.Folders(1).Folders("受信トレイ").Items.Count
        MsgBox outlook.Folders(1).Folders("受信トレイ").Items(i).Subject _
            & vbCrLf & outlook.Folders(1).Folders("受信トレイ").Items(i).Body
            
                        ' 　ここから先、添付については、確認してないので
                        '   間違ってるかも？？
        For j = 1 To outlook.Folders(1).Folders("受信トレイ").Items(i).Attachments.Count
            outlook.Folders(1).Folders("受信トレイ").Items(i).Attachments.Item(j).SaveAsFile "test" & CStr(i) & "の" & CStr(j) & ".txt"
        Next
    Next
End Sub

---

参考になるかどうかわかんないけど、それらしき本
http://www.amazon.co.jp/exec/obidos/ASIN/4839916055/249-6507807-2961155#product-details
http://www.amazon.co.jp/exec/obidos/ASIN/4839916055/249-6507807-2961155

アジャイルの開発って、マネージャーさんの力量が相当必要ってことが、あんまり言われてない気が

　あんまり、そういうこと言ってる人が、少ないと思うんだけど、アジャイルとしてあげられてる開発って、本当に、きっちりやろうとすると、ものすごーいマネージメントの力量が必要だと思うのよ。。。

---

　ＸＰとか、ペアプログラミングとかいって、２人でプログラムさせるのよ！
　２人で議論し始めたら、議論だけでおわっちゃうよ！
　実際やったほうが早いようなことでも。。。

　テストファーストの場合、テストしてるだけで、進んだ気になっちゃうし、そういう報告があがってくるよ。肝心な部分は、先送りして。。。
　その問題を、マネージャーが見抜いて、肝心な問題を、早めにやらせるように仕向けなきゃいけない（つーか、肝心な問題が見抜けないと話にならない）

　スクラムに近い開発形態は、よくとられるよね。

　デイリースクラムっていうから、わかんなくなるのよ。
　ほら、よく言うでしょ、朝会（「あさかい」と読んでね）、昼会（これ、「ちゅうかい」っていう、それとも、「ひるかい」？）、夕会（ゆうかい）とか、あれっす。
　あれって、結局、無駄な時間になっちゃうんだよね。
　実務担当は、忙しくて出れないし。。。会議をへらしたいんだけどね。。。って、いうことになっちゃう。
　けっこう、みんなに、気持ちよく、定期会に出てもらうのって大変なのよ。。。
　「さあ、朝会いこー！」みたいなかんじで、モチベーションあげるのって。
　みんないやいやっぽくって、あつまんないしさあ。。。でしょ！

　意外と、アジャイルとか言ってるやつが、「うちの会議は、意味がない」とかいいだすのよ。そうだ！そういうやつのために、朝会の呼び方を、「デイリースクラム朝」に変えたら？ズームイン朝っぽくっていいじゃん！？

　後、この手のタイプって、スプリントゴールとスプリントバックログが、うまく決まらない。この関係って、結局ＷＢＳ分解とおんなじような感じになると思うけど、この分解ができないと、ぼろぼろになるだろうし。。。
　
　てなわけで、アジャイルの真似事はできるんだけど、それをきっちりやるのって、結構、力量がいるのよ。

---

　で、たとえば、スクラムでマネージメントできるやつであれば、普通、一般的に今やられてる開発方法論（各大手企業で標準化されてる手法）でやっても、管理できると思うよ（マネージャーの仕事としては、そのほうが楽な気がする。。）。
　ＸＰで管理できるっていうのだったら、多分、コンピューター以外のマネージメントやったほうが、金になる気がする。。。（議論しちゃうやつを押さえ込むのは、大変なのよ）　
　
　ところが、今のアジャイル開発って、プログラマの視点について、書かれたものや意見が多いような気がするのよ。。。

「こうすれば、みんな、定時会議、やる気をもって、参加できる！」

とか、

「失敗しない仕事の分割方法」

　とか、あんまり、聞かない気がするのね（開発以外では、こんなような話、よくビジネス書でみるけど）。

---

　で、ちょっと気になるのが、今、各大手企業で標準化されてる開発手法のほうが、マネージメントは、しやすいと思うのよ（ものを作る手間や、効率の話は別よ、マネージメント「だけ」にかぎって言うと）。

　なんで、今の標準化されてる体系に、ただ文句をつけて、だから、「あたらしいアジャイルとかをやりたい」っていうのは、もっと、うまくいかないと思うよ。
　マネージメントの技量として、もっと高度なものが求められてくるから。。。
（人間がからんでくるほうが、マネージメントはしにくい。標準がないと、もう、壊滅的に苦しい）

　だれかがいってたけど（めざましテレビの広人苑）、
　その開発方法なりの「地獄っていうのがあるから」。
　（広人苑は、開発方法でなく、その「人」なりのといっていたが。。）

　逆に、ある一定の技量があれば、開発方法って、あんまり問わないっていう気もするけどね。。

ウォーターフローモデル以外のハード・ネットワーク選定で、起きそうな問題

　このまえ、ちょっと、ハードウェアとネットワーク選定の話をしていて、気づいたこと。

　ネットワーク選定をするとき、ＭＡＸのトラフィック量を聞かれたりするけど、これって、ウォーターフローなら問題ないけど、インクリメンタルモデルとか、アジャイルなんかだと、困らない？？

　だって、ハード選定時点で、どうなるか、わかんないもん。全体のＭＡＸ量って。。。
　そんな、将来のことを聞かれても。。。ねえ。。。

　ウォーターフローならいいですよ、はじめに業務仕様がきまるので、そこから割り出せる。でも、インクリメンタルだと、はじめのサブシステム開発時点でハードを想定しなけりゃなんないけど、その時点で、最後に開発するサブシステムなんて、まだぜんぜん見えてないこともある。そんなとき、全体のＭＡＸといわれてもねえ。。。？？

---

　結局、こういうときって、柔軟なハード、ネットワーク構成っていうことでごまかすんだろうな。。。

　でも、最近気づいた。

　これも、簡単に決められる「ことがある」（必ずしもではない）。
　なぜなら、たいてい、予算はきまってる。
　予算の範囲で、出来ることって考えると。。。そんなに選択の余地はないかも？？

　予算青天井とか言われると、困るけどね、

　いや、困らないか(^^;)

ブラウザの「Opera」日本語版の販売で、Operaとライブドアが訴えられたらしい。

　ニュース元は、ここ

会社の組織図から、失注の危険性は、わかる気がするのですが、意見の落としどころもわかるのかも？？

　開発で、資料として、よく、ユーザー会社の組織図って、入ってきますよね。
　（入ってきませんか？）

　これ、最近まで、ヒアリングを聞く範囲に利用するもんだと思ってました
　（上位の職位の人に概要をきき、下位の職位の人で、詳細を確認する）。

　でも、最近、空気をよむっていう話から、気がついたのですが、組織図と、プロジェクト担当のずれというか、そんなもんから、「結局、このプロジェクトのこの意見は、ここに落ち着くな？」とかが、わかるんじゃないかという気がしてきてます。
（いや、なんとなく、そんな勘がするっていうだけなんですけどね）

　組織図から、なんとなく、プロジェクトの権力構造が見えてくると、そこに流れる空気も「こんな感じになるな」とよめて、そうすると、「ここに落ち着くな」というのが、わかる気がするのです。
　これが、あらかじめ、わかってしまえば、それを予測して仕事をすればいいので、下請けのウィリアムのいたずらは、仕事上、メリットがあります。
　今度、研究して見ようと思います。

---

　ただ、それ以前から、失注に関しては、わかる気がしてきてます。

　会社の組織図上、主力になっていない人が、システム案件担当になってる場合、失注の可能性が高いです。

　主力になってない人は、「システム化によって、新しくして、主力部隊へ返り咲く」と思ってるみたいなのですが、たいてい、うまくいかないです。
　二世経営者などでも、親を抜くため？情報化に力を入れる人もいますが、これも、そういう考えでは、うまく行かない気がします。

　で、不思議なことに、こういう案件を拾ってくる営業って、同じ人だったりします。

　結果として、「ある営業の案件は、失注ばかり！」ということって、結構ある気がするのは、ウィリアムのいたずらだけ？？

次の業務を開始するタイミングと、実現方法のまとめ

　昨日のブログの最後「この場合は、ワークフロー制御を行うかんじでつくります。」について、その話の前に前提になる話。

　いくつかの業務がまとまってひとつの業務になっている場合、

　ある業務が終わったあと、次の業務を、いつ、どのように始めるかに関しては、大きく３つ考えられます（もっと、考えられるかもしれないけど、とりあえず）。

　・ある業務が終わったあとすぐに、次の業務を始める
　　→３つぐらい業務があったとき、最後の業務が終わったらすぐにというのも含めます。
　　　つまり、自動的に次の業務が起動されるというものです

　・ある一定時間が経過した後に、おこなう
　　→夜間にまとめて、今日の業務をどこかに転記するなどというケース
　　　通常、一定時間ごとに、バッチが動いて処理する形になる

　・業務の起動は、手動で行う
　　→業務の開始を行うための画面を作成し、そこから起動したり、
　　　該当のレコードを表示し、レコード中、選択したものに対して、実行する形などがある
　　　ＧＵＩまたはコマンドラインから、起動する

メールを暗号化して送る・受け取るプログラム作成法（Java編）

メールの暗号化（Java編）メモ（まだ未完成）

・http://www.jguru.com/faq/view.jsp?EID=29831にこんな風に書いてあった。
　If you are an US/Canadian you can use the JCE (Java Cryptographic Extension),
　アメリカ人でも、カナダ人でもないので、パス

・Ｓ／ＭＩＭＥを使う。
　JavaMailとのＡＰＩは、ここにあった ちなみに、JCSIは、ここやここに詳しく書いてある。


・WindowsのCryptoAPIを、JNIで呼び出して利用する方法で暗号化
　CryptoAPIの利用方法は、ここ
　でも、そこまでするなら、別にJavaにしなくても、C++で書いてもいいなあ。。。

音楽の検索と、音楽認識のためのＳＤＫに関するメモ

音楽の検索に関して気になって調べたことのメモ

・音楽のイントロ、サビ部分を聞かせて、楽曲名をあてるＢＲＥＷサービスがある
　　サービス名：「聴かせて検索」
　　→米国 Gracenote社と、株式会社メディアソケットが提供
これについての記事はここ

・これは、 Gracenote社の音楽情報データベースCDDBと、サウンド波形認識テクノロジー Waveform recognitionを採用したGracenote MusicIDを使ってできている。

このＳＤＫに関しては、Gracenoteで出している。内容や問合せ先は、ここ

・「Yahoo! Music Engine」に、 Gracenote MusicID 、 Gracenote Linkが採用されている

ユーザーのヒアリングから、一連の業務手順を表現する方法

　動詞句からメソッドを切り出し、名詞句でクラスとアトリビュートを切り出し、それをメソッドに入れるところまで、今日書いたので、ついでに、ユーザーのヒアリングで、この先にやる、クラス間にまたがる処理を適切な順番で処理する、つまり、一連の業務手順を表現する方法についても書いておきましょう。

　一連の業務（受注など）は、いくつかの業務から構成されているのが、ふつう（在庫確認、受注票記載、受注票送付など）。

　この業務の関連は、アクティビティ図やシーケンス図に表現される（たしか、コラボレーション図って、シーケンス図に変換可能じゃなかったっけ？なんで省略。ステートチャート図では、どのイベントが起きたとき、どのクラスを起動するのかわからないので、ここで言ってるものとは違う）。

　で、ＵＭＬの本は、おわりになっちゃうのよ、

　問題は、これの実装だよね。

---

　一連の業務手順が固定的な場合は、ハードコーディングしてしまう。
　つまり、シーケンス図に表現されるように、呼び出し元のクラスから、対象クラスを呼び出す（引数設定して、どーんとよぶ）ようにコーディングする。

　なお、ＲＤＢ上で、イベント系のエンティティ（最終的にテーブルで表現される）内に、業務手順を表現したい場合がある。
　たとえば、出荷するとき、対応する受注と結び付けたい場合がある。

　このとき、一般には、
　・２つの業務を対応したものを１テーブルで表現する
　　　→佐藤氏は、対応表だっけ？対照表だっけ？といっている。
　　出荷受注テーブルというのをつくって、出荷番号と受注番号を対応ずける

　・後の業務のテーブル内に、前のテーブルの番号を入力する
　　→出荷テーブルの中に、受注番号を入力する

　　　この場合、以下の条件を満たすことが必要である
　　　　　業務の前後が、かならずはっきりしていること
　　　　　前の業務が１に対し、後の業務が０、１またはＮ
　　　　　逆でないこと。
　　　今回の場合、１受注を分割して複数出荷にするのならＯＫ
　　　でも、複数の受注をまとめて、１つの出荷で済ませる場合、出荷テーブルの
　　　受注番号に、なにをいれればいいかわからないので、出来ない。

---

　ここまでは、ＯＫ
　でも、実務上、行う業務が、進捗状況により、大幅に異なり、変わる場合や、そもそも、業務手順が決まっていない、稼動後、変更になる可能性がある場合っていうのもあるよね。
　そういうときは、どうするか？

　ハードコーディングできない。納品後、変わるんだから。

　ベンチャー系の仕事などであります（頻繁に社員が辞めるので、業務フローがちょくちょく変わるとき）。あと、複雑な事務処理（お客さんの入金方法によって、やり方が変わり、さらに、進捗状況によって、つぎやることが変わる）

　この場合は、ワークフロー制御を行うかんじでつくります。

　もう、今日は時間がないので、今度、続きをかきますね。

ユーザーのヒアリングからクラスと属性を自動的に切り出すときの目安（名詞句の扱い方）

　昨日のブログ（今日訂正したやつ）を書いていたとき、実は、勘違いしてて、名詞句のやり方、日経バイトの２００４年５月号の「羽生田栄一のオブジェクト論」に書いてあると思ってた。

　なんで、読み直したら、なななんと、この記事では、クラスを切り出すのに、（７９ページ）「縦軸に機能、データを横軸」（実際には、A桁にメーカー名など、データ項目名が、１行目に入荷するなどの機能が書いてある。縦軸に機能？？、ま、いいか）にして、その組み合わせ（対角としている）としていた。

　そいで、ユーザーのヒアリングから、データをどういう操作をして切り出し、機能をどういう操作をして切り出すかについては、書いていなかった。この後の６月号で、ものの話が多かったんで、名詞句で切り出す方法とごっちゃになってしまったと。。

　つまり、羽生田さんと、本位田さんを、ごっちゃにしてしまったという、本人に対してははなはだ失礼なんだけど、きっと、みんな、わかってくれそうな（かあ？？）混乱をしておったわけです。

---

　つーことで、前の記事で、勘違いについて書いたわけ。
　それはそれでいいんです。

　でも、さっき「記事を読み直した」と書きました。

　で、気づいちゃったのよ！！

　この記事、属性とクラスの分け方について、書いてない。。。
　なんで、ここにでてくるマトリックス、わけわかんないことになっている！？

　たとえば、「在庫を引き当てる」というとき、メーカーコードと商品コードと商品名を参照することになっているけど、もし、なぜ、商品コードと商品名を参照するのに、メーカに関しては、メーカーコードは参照して、メーカー名は、参照しないんだ？？

　その上、メーカー名という細かい単位（属性）も、売り上げという大きな抽象的なサ変名詞も入っちゃってるし。。。

---

　このように、機能とデータでマトリックスを作ることは、ないとはいわないけど、そのときは、普通、データのほうを、リソースとぶつけるのがふつうっす。

　リソース＝エンティティで、イベントでないもの
　エンティティ＝クラスとなりえるもの
　名詞句＝クラスとなりえるもの＋属性

なんで、
１．名詞句をひろってきて、
２．名詞句をクラスとなりえるものと、属性となりえるものにわけ
３．クラスとなりえるものをリソースとイベントにわける
という操作が必要になる。

　２の操作によって、ＥＲ図がでてくる。これが、動詞句によって操作してできたユースケースないしはＤＦＤと矛盾なければ（ユースケース図やＤＦＤの入出力がＥＲ図に出てくるもので説明可能となる）ＯＫとなる。

　３の操作（リソースとイベント）は、企業の情報コンサル上、あるいはデータベース作成上、必要となる。
　そして、２から３の操作は、佐藤正美氏のセミナーなどで触れるから有名でしょう。

　問題は、１から２って、わかりきってると思うので、いつも、説明してなかった。。。

　けど、ひょっとして、そんなに知られていない方法なのかもかも。。。
　羽生田さんが、そのことに触れないで、こんなわけもわからない表を書くくらいだから（エンティティの話は、その前に出てきているのに）。。。

---

　つーことで、意識あわせ、

　ユーザーのヒアリングで、名詞句から、クラスと属性に分ける方法

１．ヒアリング中、動詞を修飾している名詞句を取り出す
　　　メーカー名、メーカーコード、商品名、商品コード、販売価格、注文番号。。。

２．その名詞句を意味がわかる程度にまで分解する
　　　例：メーカーコード　＝　メーカー　＋　コード
　　　　　商品名＝商品＋名（名前）
　　　　　販売価格＝販売＋価格

３．こうやってわけると、名詞は、以下の３つに、たいてい分けられる
　　あ．本当は動詞、サ変名詞　（例：販売）
　　い．名詞なんだけど、それだけでは、実体がない、実体を修飾する名詞
　　　　　　例：コード、名前、価格、番号、明細、合計など
　　う．ものとして存在する（抽象概念や触れないこともあるけど）
　　　　　　例：メーカー、商品

　このとき、

（あ）は、機能であるか、または、イベント系のクラス
　
（い）の場合、もとの名詞句の中に、（う）が存在すれば、そのクラス
　　　例：名＝＞商品＋名の名＝＞商品名は、商品クラスの属性
　　　
　　　存在しなければ、なにか、隠れている、隠れている物を探す。
　　　例：＝＞開始・時間＝＞なにかの開始時間、なにかのクラスの中の属性

　　　（あ）の場合、イベント系のクラスの場合は、隠れているか、（あ）のクラス
　　　　機能なら、隠れている
　　　例：販売価格＝＞商品が隠れていて、商品販売価格の可能性もある
　　　　　しかし、販売価格が時価（気分しだい）の場合、販売クラスの中に入る

（う）は、たいていリソース系のクラス

一概には、いいきれないが、このパターンであることがおおい

---

　このような操作で、一応、クラスはひける。あとは、動詞句の機能であるメソッドをクラスの中に適当にいれる。
　その際、このマトリックスを使うことがある（使わなくてもいいけどね）
　って、感じかな。。。

ＵＭＬも、動詞句から分析だね。昨日の訂正！と、ヒアリングからユースケース図の作り方

　昨日のブログ、訂正っす！！

ＵＭＬでは、名詞句に注目し、名詞をクラスまたはアトリビュートとして抽出するところから入ってしまう方法論もある。

　うそ！
　ＵＭＬでは、一番初めに、ユースケース図や、アトリビュート図からつくる野が普通だと思う。
　これらは、機能をもとに、（ユースケースなどを）だすため、動詞句からでないと分析できない。

　なにを、勘違いしたのかというと、「オブジェクト指向システム開発」という本に書いてあるやりかたと、勘違いした。こいつは、はじめ、名詞句を分析し、クラスを出していっている。
　なので、「ＵＭＬでは」、でなく、「オブジェクト指向の一部では」に文を訂正するべきですね。訂正です。ちなみに、その本で出ている方法は、コード＆ヨードン法をもとに、そのやりかたでやっているとおもった。

　たしか、ＯＭＴでのやり方は、トッパンの本にあった気がする（いま、引越し中で、手元に無いので確認できないけど）

---

　なお、一応、動詞句から抽出するっていう方法について、書いておくと

＜根拠＞
　ユースケース図のユースケースや、ＤＯＡのプロセスは、「機能」や、「業務」にあたるわけですよね。機能や業務は、一般的に言うと、「なにかを、する」こと。するっていうのは、するーーーう、伸ばすと「う」で終わるから動詞。つまり、機能や業務は、基本的に動詞。
　なので、ヒアリングなどできいた、動詞をもとにユースケースを作る。

＜つくりかた＞
１．ヒアリングのときに、どんな動作をするのかをきき、動詞をチェックする

例：受注のとき

　在庫をチェックし、在庫があったら、受注伝票に、受注内容を書き、出庫担当に渡す。

動詞は、
・チェックする（在庫を）
・ある（在庫が）
・書く（受注伝票に）
・渡す

２．このとき、動作を伴わない動詞（状態動詞）は、いらないので、動作のものだけをまとめ、機能とする。動詞だけだとわけわかめなので、ことばを補い、「する」をとるか、サ変名詞っぽくする

・在庫チェック
・受注伝票書き込み
・受注伝票送付（出庫担当）

３．あとは、図にまとめる。動作主体（その動作をする人）がアクターにたいていなる。

---

ＤＯＡの場合、３をアレンジして、ＤＦＤに変えればＯＫ
ただ、オブジェクト指向でも、クラス図から入っちゃう人も（つーか聞いたとたんにプログラム書き出す人も）たしかにいるわけで、そういう場合、あとで、誤解っていうケースもよくある
（っていうか、程度問題で、動詞から入っていっても、誤解はあるよ）

で、こういう作業って、結局、「言葉を規定していく技術」だよね（動詞をさがすとか、状態動詞だからはぶくとか、かっこよい言葉に置き換えて機能にするとか）。

　うーん、どのへんが、理系（工学部）なんだ？？
　めっちゃ、文系（文学部？教育学部？法学部？）っぽい気がするんですけど。。。？？

　きのせい？？

「ＩＴ技術者の育成急げ」って、１０年前とおんなじ口調だよね！

　「高度なＩＴ技術者の育成急げ　経団連が危機感抱き提言」という記事が、結構話題になっているみたいなんで、ウィリアムのいたずらも、取り上げてみましょう。
　ちなみに、記事はここ

---

　ウィリアムのいたずらみたいに、何年も、この業界にいると、この手の記事、「またかよ！」っていう感じです。

　１０年位前にも、ＳＥが足りないというような話がでて、「情報」とつく学校や学部がいっぱいできました。でも、あの当時は、ちょっと信じましたが、今回の記事は、あの当時の記事よりも、はるかに疑わしい！

---

　まず、「ゲームソフトなど一部のソフトウエアを除くと」（中略）「「国際競争力は極めて低位にあり」

　って、おいおい、それって、日本のコンテンツ輸出の主力産業だろ！
　それ抜いて集計してどうする。
　そんなら、アメリカの集計するとき、ＯＳとＤＢは、抜いてくれよ！

　そもそも、日本のソフトウエアの輸出入額は大幅な輸入超過だから国際競争力を身につけなければ、日本の情報サービス産業の未来はないって、そういうもんじゃーないだろー

　ソフトウエア産業のすべてが、輸出・輸入品であり、それが輸入超過なら、その論理は成り立つ。だけど、ソフトウエア産業における輸出品は、パッケージソフトと特許、コンテンツぐらいでしょ。

　しかし、パッケージソフトや特許は危険が大きく、多くのソフトハウスは、内需の仕事である、コンサルや業務系システム開発を受託や派遣でやっている。
　このほうが、利益率が高く、安全にお金が抜けるから。

　だから、１０年前くらいの"あおり"のように、「作らなきゃいけないプログラムに対して、人が少ない」っていうならわかるけど、「非常に危険なパッケージソフトや特許関連に力を入れていない」って言われても、「そりゃーそうだろうね、派遣が一番お金儲かるもんね」としか、答えようがない。

---

　さらに、わけわかんないのは、「日本の場合、ソフトウエア業界に就職する学生の中には文科系の卒業生も多いほか、工学系の卒業生でも開発に役立つ技術や知識が不足しているという。」

　おいおいおい、そんじゃあ、ソフトウエア業界に必要な知識っていうのは、工学部で教えるのかい。。。？？？

　いいかい、オブジェクト指向で考えたとき、ユースケースから、クラス導出、メソッドの引数までの作成は、（ＭＤＡで示されるとおりの道筋であり）ほぼ、決まっているよねえ。
　そんなもん（ＭＤＡでやるような、通り一遍の設計と分析をさす）を教えるために、大学の４年間を費やしてるのかい。。おいおいおい、日本の大学って何百万（授業料＋浪人時代の費用＋その他もろもろ）も払って、その程度しか教えてないのか？違うだろう。。。いくらなんでも、大学に失礼だぞ！

　システム開発で、一番問題になるのは、
　　仕様をぶれないで、きること。
　　仕様の範囲を確定させること、
　　みんなの意識が合うようにまとめること
　になる。

　従来のＤＯＡやＯＭＴにおいては、仕様の文章から、動詞（サ変動詞もふくむ）を抽出し、それに対する目的、主格関係にあたる名詞句をエンティティとして捕らえ、システム設計をしていた。この場合、言葉は、動詞中心になるので、ぶれにくい。
　とくに、この動詞を限定してしまう（前に出した、ビジネスパターンの話）と、もっと意思疎通がしやすい。

　しかし、ＵＭＬでは、名詞句に注目し、名詞をクラスまたはアトリビュートとして抽出するところから入ってしまう方法論もある。この場合、名詞の判断は、人によってちがい、ぶれやすい（「ご飯を食べる」といったとき、動詞の「食べる」で想像するものはあんまり差がないけど、「ご飯」っていわれても、白米のことなのか、お昼、夕食のことなのか、わけわかんないでしょ）。

　そこで、言葉を規定していく技術が昔以上に必要になってきたわけよ。
　このへんの言葉を規定していく技術って、まさに文系でしょ。法律作ってるのと一緒だから（業務の標準化なんて、刑罰のない法律作ってるようなもんだもんね。え、罰あるって ^^;)

　逆に、今のソフト業界って、電気の知識、たとえば、フリップフロップがどうのこうのとか、そういう知識は、ほとんど必要ない。つまり、もはや、実務では、文系と工学部の知識の差で争っているようなレベルではないのよ。
　その程度の知識は、会社に入ってからでも間に合うのよ。

　もっと、総合的な、実体を切り刻む切り口を争う部分なわけね。

---

　さらにもっというと、今、情報業界は、通信（ネットワーク）やコンサルのほうがトレンドで、給料も断然よくなっている。したがって、いくら工学部に力を入れても、みんなそっちに流れて、ソフト業界には、来ないんじゃないかなあ。。。

　この前、ちょっと知り合いとはなしていたら、彼は、ネットワーク系なんだけど、年収７００万（３０歳）なんだって。ウィリアムのいたずらは、彼より年上だし、業界もながいけど、３００万いかないぞ！なんと、（約）３倍だよ！３倍！

　学歴で言えば、彼は中卒だし。。。

　だから、学校とか、ましてや学部なんて、もう、関係なくなってきてるのよ。
　で、情報ソフト産業が振興しないのは、待遇が、通信やコンサル系にくらべてわるいから。

　そいと、日本は技術力がないからではなく、売れない時のリスクが大きいから、そこまでしてまで輸出できるような製品を作ろうと思わないわけよ。

　たとえば、ワープロ作れ！っていわれたら、その設計ぐらい、「文系」の大学を卒業した！ウィリアムのいたずらでもできるわけよ。でも、ウィリアムのいたずらをふくめ、だれもいまどき、新しいワープロ作ろうと思わないでしょ。一太郎ですら、いまいちな昨今なのに。。

---

　その後の「新卒者のうち、ＩＴ技術者として即戦力となれるのは１割」の数字は、もはや「はあ？」という感じ。

　おいおいおい、就職して、研修も受けず、大学卒業してすぐ、（たとえ１割の人間だとしても）仕事につけるって、そんなにこの業界、参入障壁が低いのか？たとえば、税理士でも、２年間、他の税理士につくし、ふつう、どんな業界でも、２、３年は、見習いでしょう。。。。この業界は、すぐに即戦力なの？？その程度なわけ？？

　。。。かもしんない(^^;)

９０年代から今までのコンピューターの営業的キーワードは、いろいろ変わったが、同じこと言ってないか？

　前のブログで、情報化の効果として、「情報共有を密にできるようになった」というのが結構高い位置に来ている。

　で、考えてみると、ここ１０年間くらいのコンピューターの営業は、この情報の共有化という話題を、名前を変えただけで、いろいろいっている気がする。

　ということで、ものはためし、「９０年代から今までのコンピューターの営業的キーワードをならべ」てみましょう。

---

９０年代以前
　商業関係：汎用コンピューターによる処理（第三次オンなど）
　製造関係：ＦＡ

９０年代：オープンシステムという概念が始まる
　　→いまの日経システム構築が、日経オープンシステムという名前で創刊
　商業：ＳＩＳ
　製造：ＣＩＭ

その後
　商業：ＢＰＲ（ビジネスプロセスリエンジニアリング）
　　　　　↓
　　　　ＥＲＰ

２０００年ごろ
　いろいろ、細かいネタが出だす。ＣＲＭ、ＳＦＡ
　データ接続としてのＥＡＩ

最近
　ＥＡへ（ＩＴＩＬという話題もあるが）

もともとは技術なのに、こういうはやり文句の文脈でとらえられつつあるのが
　ＳＯＡ

---

　結局、手を変え品を変え、やろうとしていることは、情報の共有化。
　（ＳＯＡはちがうかもしんないけど）
　それを、（営業で売るためか）キーワードをつけて、はやり文句として、売っているのが現状かな？

Jarの使い方を知らないと、構成管理のミスのとき、こまるかも。。

以前のブログで、書くといって、書いていないことについて。。。

以前のブログで「テストは、コマンドライン。。となると、困る問題がある。」と書いた困る問題について

　IDEで開発しても、たいてい、ユーザーで動かす環境は、コマンドラインからなので（ＩＤＥからというのは、少ないと思います）、コマンドラインでテストする必要があります。
　このとき、コマンドラインでクラスパスを指定し、（javaの-classpathまたは-cpで指定するか、起動するシェル内で環境変数でCLASSPATHを設定する）起動するわけですが、ＩＤＥでは動いていたのに、コマンドラインで動かなくなることがあります。

　これは、javaで、起動するとき、jarで指定されたクラスの中にも、public static void main(String args[])を持つクラスがあると、そちらに反応してしまう（見つかったと思って、それを実行しようとする）ときなどにおこります。

　また、構成管理で失敗すると、同じクラスを２つ以上のjarで含んでしまったり、逆になたらなっかりなどなど、さまざまな問題が起こってしまったりします。

　こういった状態を対応するには、やっぱり、コマンドラインでのjarの操作くらいは知らないといけないかもしれません。

---

　つまり、jar -xvf ＪＡＲファイル名　で、解凍、
jar -cvf　作成するファイル名　jarにするクラス　で作成
ということを知った上で、おかしくなったら、

（１）まず、jarをxvfで解凍してしまおう
（２）解凍したものを、起動するmainクラスとおなじフォルダにおき、
（３）解凍したjarをクラスパスからはずす

そうすると、必要なクラスがあれば、（２）でおかれたフォルダの中から見てくれる。
（jarの中のクラスにmainがあっても、そいつが、関係なければ、それに反応することはない）

　あと、jar xvfとやれば、jarの中に入っているクラスも表示するので、構成管理のまちかいで、クラスが２つはいっちゃったり、逆に入ってないときわかる。

　そんなかんじなので、結構jarは使います。
　なので、ＩＤＥだけでなく、余力があったら、コマンドラインをやる必要もあるかも？？

調査結果によると、システム開発による、業務プロセスの標準化や新規ビジネス創出は期待薄のようだ

日経コンピューターんの２００５年６月１３日号の特集は「IT Doesn't Matterは本当か？」という題で、IT Doesn't Matterというアメリカの論文（日本では、この論文を訳した 「ITにお金を使うのは、もうおやめなさい」という本が出ているそうです）についてと、経営者へのアンケートに付いて載っています。

　それについて、書こうと思いつつ、時間がなくて、かけない状態が続いているので、とりあえず、大事な部分のメモをとりあえず抜き出し。

---

（４１ページ）

質問１：情報システムが役に立っているという答え（複数回答）

業務の効率化　５８．２％
情報共有の促進　５４．６％
（顧客サービス向上３１．５％、業務改革の推進３６．３％）

質問２：経営戦略を遂行する上で、情報システムは、欠かせない存在である　７８．９％

（４６ページ）

質問３：経営戦略を遂行する上で、情報システムをどのように位置付けているか

１万人以上　欠かせない存在　９６．３％
２９９人以下　欠かせない存在　６２．５％

質問４：情報システムの活用によって、企業の活力が増すと思うか
　強くそう思う　１９．５％　そう思う　６１．０％

質問５：情報システムを利用することで、活力を生み出しているか
　生み出せている１５．１％　まあ生み出している　５６．６％

質問６：具体的にどのような効果が出ているか
定型的な業務やその他の雑務の自動化、効率化　　８２．８％
情報共有を密にできるようになった　７５．０％
業務環境をリアルタイムに把握　４１．７％
業務プロセスの標準化　２３．９％
新規ビジネス創出（しつつある）１．７％

（４９ページ）
質問７：今後、活力を生み出すために情報システムを活用する方策を立てる予定があるか
具体的な方策を策定済み　３９．８％
方策を立てる予定　３９．０％

（５０ページ）
質問８：どのような効果に期待するか
定型的な業務やその他の雑務の自動化、効率化　　６１．４％
情報共有を密にできるようになった　５６．９％
業務環境をリアルタイムに把握　６０．９％
業務プロセスの標準化　１９．８％
新規ビジネス創出（しつつある）１１．７％

---

　具体的に目を引くのは、質問６と質問８。
　期待していることは、「定型的な業務やその他の雑務の自動化、効率化」と「情報共有を密にできるようになった」であり、「業務プロセスの標準化」は効果がさほど出ていない。そして問題なのは、「新規ビジネス創出（しつつある）」は、１．７％なので、「まずない」といっていいだろう。しかし、期待だけは１１．７％もある（期待しすぎ）。

　この調査結果から、いえそうなのは、システム開発により、業務プロセスの標準化は期待できないし、新規ビジネス創出に関しては、期待されているけど、効果は出ていないといえる。

---

　この結果は、業界的に見ると、しごくあたりまえ（そのように、この業界が動いているから）である。というと、「なぜ、業務の標準化や、新規ビジネスを創出できないように、業界が進んでいるといえるのか？」と、思われるであろう。
　これを説明するのに、稚北大学の宣伝文を引用しようとおもった。

　そのメモは、別の機会で。。。