「携帯電話のバグをネット経由で更新」らしい。（auのＷＩＮ）

ものものさん経由で知ったニュース

携帯電話のバグをネット経由で更新，KDDIが6月下旬開始

これって、ユーザーが更新ファイルを手動でダウンロードする方法の場合はいいけど、KDDIから端末に更新ファイルを自動で配信する方法の場合、
別に、更新しなくても差しさわりのないようなもんまで、更新されちゃう（ダウンロードされちゃう＝パケット代を払わせられる）んじゃないだろうか。。？
　それが、むこうの戦略？？

　で、もし、自動更新されたものに、さらにバグがあって、ケータイが動かなくなっちゃったりしたら。。。なんてことはない？？

　手動ダウンロードのほうが、安全かもかも？？

業務が大幅に変わる場合などのとき、ワークフロー制御を行う感じで作る場合の作り方

　以前のブログの最後「この場合は、ワークフロー制御を行うかんじでつくります。」について、実現方法のまとめです。

　これ以外の方法でも、もちろん実現可能です。
　っていうか、あんまりかっこよくない、どたばたっぽい感じの例。

■■　方法

【あらかじめやること】

１．一連の処理に番号をつける
　例：商品購入サイト
　　１．受注受付
　　２．在庫引当
　　３－１．入金確認－クレジットカード
　　３－２．入金確認－銀行振込
　　３－３．入金確認－有分極振込み
　　４．出荷指示書（ピッキングリスト）作成
　　５．宛名ラベル作成
　　６．出荷
　　７．返金
　　８．キャンセル処理

２．ＤＢでも、プロパティファイルでもどこでもいいんだけど、
　　どういう状況のとき、どういう順番で、しごとを行うか
　　つまり、「仕事の雛形（標準的ワークフロー）」を登録する
　　→一般的に作る場合、こういうものがきたら、こうという仕事の手順の雛形を登録する
　　　別に、一般的にやらないのであれば、ここを省略し、ハードコーディングでもかまわない

３．ＤＢに、一連の作業指示を入れられるテーブルを作成する
　　＜項目＞
　　　　ジョブ番号：一連の仕事を表すＩＤ
　　　　明細番号：一連の仕事中、現在の仕事は、何番目の仕事を表すか
　　　　直前の明細番号：一番初めの仕事は０
　　　　　　　　　それ以外のとき、現在の仕事の前に行った仕事を記述する
　　　　　　　　　（複数ある場合、任意の１個でよい）
　　　　ステータス：起動済み、次に起動、起動まち
　　　　起動条件：いくつかの仕事があるとき、すべて終了してから起動する場合
　　　　　　　　　同期-1,2 のように、終了待ちする明細番号を書くなど
　　　　　　　　　起動するための条件を書く
　　→ＤＢでなくても、ＸＭＬなんかのファイルで作業指示でもいい。
　　　その場合、この作業は、省略
　　　項目は、一例であり、これ以外の方法ももちろんある
　　　（直後の仕事を入れるもの、直前と直後を入れるもの、
　　　　複数の仕事をジョブグループとして表現するものなど）

---

【プログラムの動作】
（こんなふうな動きのするプログラムを作成します）

４．一連の作業の開始時において、
　　・仕事の雛形をアクセスし、該当する仕事の雛形（ワークフロー）を、見つけてきて
　　・この一連の仕事をあらわすＩＤ（ジョブ番号）を取得し
　　・そのＩＤとワークフローを一連の作業指示を入れられるテーブルに登録し
　　・一番初めの仕事を終了とします

５．ワークフローにおいて、次の仕事が、
　　・前の仕事が終わったらすぐに起動する場合は、次の仕事をすぐに起動する。４へ
　　・バッチや、手作業での起動の場合、ステータスを「次の起動」にする

---

【プログラムの動作-バッチなど編】

（前のところで
　　・バッチや、手作業での起動の場合、ステータスを「次の起動」にする
　とかきましたが、そのバッチや、手作業での起動が動かされた場合）

＊バッチのとき
６．バッチプログラムの場合は、まず、そのバッチプログラムが、処理対象とするものを、一連の作業指示を入れられるテーブルを参照してとりだす
　→「次の起動」になっていてかつ、起動条件を満たすもの

７．処理を行う

８．５へ行く


＊手作業のとき
６だっしゅ．手作業の場合は、処理対象とするものを、一連の作業指示を入れられるテーブルを参照してとりだす
　→「次の起動」になっていてかつ、起動条件を満たすもの

７．６だっしゅで取り出したデータを表示し、作業するものを選択してもらう

８．選択されたものの処理を行う

９．５へ行く

---

うーん、言葉で書くと、やたらわかりにくくなってしまった。

マクロで、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

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

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

---

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

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

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

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

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

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

---

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

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

とか、

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

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

---

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

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

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

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