[RIA]BrazeDSがリリースされました

BlazeDS Beta Released on Labs
http://weblogs.macromedia.com/labs/archives/2007/12/blazeds_beta_re.cfm

おおざっくり概要を書こうと思ったらこちらで解説済み。

BlaseDSの範囲CommentsAdd Star
http://d.hatena.ne.jp/sato-shi/20071213/p9

FxUGでは。
http://www.fxug.net/modules/xhnewbb/viewtopic.php?topic_id=1434

そしてオープンソース。LGPL。
私の理解の範囲では利用、再配布、改版は自由。ただし教えてね。というもの。

今までお客さんから相談されてたことで
「プッシュの機能は使いたい。でもFDSは高価だから導入しづらい」
という声をよく聞きました。
さらに
「パッケージとして配布したい場合、FDSではどうにもならない」
とも聞きました。

これらの課題は今回のBrazeDSを上手く利用することでクリアになるはずです。

またBrazeDSのリリースによって、クライアント側の構築だけでとまっていたRIAに対する興味が喚起されるのではないでしょうか。
それはFDSの「高価格」というイメージがネックとなって、Adobe社のサーバー製品に対する興味が薄くなっていたところへある種のきっかけになるはずです。そして有償で提供されるLCDS(旧FDS)はPDFのソリューション、DMS機能をより強化していくと思います。オープンソースとして提供されるBrazeDSを通じてLCDS自体の品質が向上するはずです。

RIA導入がより一層推進されるといいですね♪

[RIA]Adobeの動きが激しい予感

AMFってなんだ？CommentsAdd Star
http://d.hatena.ne.jp/sato-shi/20071207/p2

AIR Beta 3 の"うわさ"
http://shigeru-nakagaki.com/index.cfm/2007/12/12/20071212-AIR-Beta-3-rumor

NEWS: Adobe Gifts Arriving Early >>> WED 9PM PST
http://www.onflex.org/ted/2007/12/news-adobe-gifts-arriving-early-wed-9pm.php


ドキドキしますね。

[RIA]Flash Media Serverが値下げらしい

「アドビ、「Flash Media Server」の新版で値下げへ--「Flash Player 9」正式版も公開」
http://japan.cnet.com/news/ent/story/0,2000056022,20362457,00.htm

桁が違いすぎて。。。
本当！？

※　ここから追記

tedさんのblogにも情報が載ってた
" The Streaming Revolution"
http://www.onflex.org/ted/2007/12/streaming-revolution.php

うう。英語が分からないのがもどかしい。

> viva la revolution!

とりあえずめでたい事はわかった



「米Adobe、Flash Media Server 3 - H.264のストリーミング配信に対応」
http://journal.mycom.co.jp/news/2007/12/05/003/index.html

日本語の情報。

[Microsoft Office Project]メモやらテキストを使う

先日のこと、同僚から
「MSPでメモを使いたいんだけどどうすればいいの？」
という質問をされました。

Microsoft Office Projectのメモは下の手順でできます。
　「挿入」→「列」→「フィールド名」でメモを選択。
　あるいはヘッダー部分で右クリックをして「列の挿入」を選んでも大丈夫です。
　表示位置はマウスでドラッグアンドドロップすることで好きな場所に配置できます。

さて、このメモですが使い方次第でMicrosoft Office Projectが非常に便利になります。
というか使ってください。使う前提です。

よくある話ですが「全体スケジュールはProject、詳細な課題一覧はExcelで。」というスケジュール管理を見かけますが、これは管理資料の一元化に反するのでお勧めできません。だいたい詳細な課題一覧はスケジュールにひもづくので、１つの資料で管理できるのであれば分ける必要はないはずです。

そこでメモを有効活用しましょう。
もしタスクにひもづく詳細な課題がたくさんあるのであれば、行を増やして管理すればいいだけです。邪魔なら格納してください。
またメモだけで足りないのであれば「テキスト」フィールドを使うことも可能です。使い方はメモと一緒です。ただしテキストフィールドにデータが入っていても状況説明のフィールドにメモのしるしは出ませんが、、、、、、。

メモを有効活用して、スケジュールのあいまいな点を減らす、未確認事項をはっきりさせると、プロジェクトの進捗が少しスムーズになります。

AIRのアプリ「FLO:Q」

スゴイのでリンク貼っときます。

http://floq.jp/desktops/top

“リッチクライアント”に至るまでの軌跡と現在（いま）

“リッチクライアント”に至るまでの軌跡と現在（いま）
http://www.atmarkit.co.jp/fwcr/rensai/imasara06/imasara06_1.html

知らないのもあるなー。と。
ところで「リッチクライアント」と「RIA」の意味はどれくらい違うのかな？　と思ってちょっとだけぐぐってみましたが、
Wikipediaの「リッチインターネットアプリケーション」の説明に違和感を持ちました。

• RIAはJavaScriptやFlashなど搭載した高機能なウェブブラウザ上でのみ利用できるが、環境が整っていないものではまったく利用できない

間違ってないけど、なんかヘンですよね。この説明。

他のサイトの説明
「利用者の使い勝手を中心に考えればRIAが見えてくる」
http://web-tan.forum.impressrd.jp/e/2007/05/10/1252

RIA開発に関するポイントについて

RIA開発に関するポイントとかTipsとかを自社主催のセミナーで話すことになりました。
といっても2回目ですが。。。

前回は「ユーザーエクスペリエンスを問われるRIAについて、どのような開発プロセスが適切なのか」といったテーマで話しました。今度もほとんど同じかと思います。加筆補正くらい。

「ユーザーエクスペリエンス」って、どういう意味でしょう？
私もよくわかっていません。
ただし開発において間違いなく言えることは下記かと思います。

・エクスペリエンス＝体験というからには見て触らないと分からない
・ということはシーケンシャルで手戻りを考慮しないウォーターフォールだといろいろむりぽ

解決策はいろいろあると思います。
どれも世にあるものです。
それらを上手く組み合わせて適用するだけです。
そのためにIT雑用係りとしては、記憶媒体としては信頼性の低い私の脳みそに少しずつそういったネタを仕入れて考えるんだと思うです。
それは楽しいことだし。

SilverLightを採用したGyaoに対する素朴な疑問

GyaOがMS「Silverlight」採用――Flash Video落選のわけは？
http://www.atmarkit.co.jp/news/200711/19/silverlight.html

IE以外のブラウザのユーザはどうでもいい、ということ？
それともSilverLightはクロスブラウザ対応できるようになったんでしたっけ？

マイクロソフト、「Office Project 2007」資格の日本語教育プログラム提供へ

マイクロソフト、「Office Project 2007」資格の日本語教育プログラム提供へ
http://journal.mycom.co.jp/news/2007/11/20/042/index.html
http://www.atmarkit.co.jp/news/200711/20/pm.html

これは朗報。
MSPは悲しいくらい参考図書が少なく、操作マニュアル以上の情報を得るのがとても難しい。
試験範囲にもよると思いますが、対策のための書籍は発売されるから教材が増えますね。

実務で活かせる内容であるといいですね。

プロジェクトの震度

PPT作るのに煮詰まったので書いてみました。

【レベル0】
無感。作業者は感じないで進捗管理表に記録される程度。

【レベル1】
微遅れ。スケジュール管理している人や特にデスマーチに注意深い人だけに感ずる程度の遅延。

【レベル2】
軽遅れ。大ぜいの人に感ずる程度のもので、担当タスクがわずかに動くのがわかる程度の遅延。

【レベル3】
弱遅れ。メンバーがゆれ、顧客がガタガタと言い始め、プロジェクト管理者は相当ゆれ、計画時のスコープが動き、「がんばれば取り戻せる」が常套句になる程度の遅延。

【レベル4】
中遅れ。ステークホルダーの動揺が激しく、体力のないプログラマなどは倒れ、作業タスクは計画時よりあふれ出る。また、他プロジェクトの関係者にも感じられ、多くの人々はプロジェクトに関わらないように遠巻きに眺める程度の遅延。

【レベル5】
強遅れ。スコープ管理表に「非対応」をあらわす取り消し線が入り、「次期フェーズ」、「Ver1.1」、「余裕があれば」といった言葉が飛び交い、ステークホルダーの人間関係が破損する程度の遅延。

【レベル6】
烈遅れ。スコープの倒壊は30％以下で、メンバーから「そもそも論」が起き、品質が考慮されなくなり、多くの人が「やってられない。このプロジェクトが終わったら転職」などを考える程度の遅延。

【レベル7】
激遅れ。プロジェクトの倒壊が30％以上に及び、土日出勤、徹夜、土下座などを生じる。
ものが飛ぶこともある。

RIA-UPという言葉を思いついてみた

統一プロセス(UP)をRIA開発向けに特化して、より具体的に作業や成果物を定義する開発プロセスを考えてみました。

酒飲んだ頭でｗ

帰宅途中の電車とバスの中でノートになぐり書き。

いま読みなおす。

書いているときはスゴイ革新的なことを考えている気がしていたものの、一夜明けて読み直すとチョー普通。ぜんぜん普通。それどころか粒度が粗すぎて全然具体的じゃないし。

学生のとき、初めて舞台に立った芝居の脚本に
「真夜中のラブレター現象」
というセリフがあったのを思い出しました。
翌朝読み直すとこっぱずかしい、というやつ。

さてさて。
RIA-UP(仮)に要求開発をミックスして、、、とか更に考える。
理想としては「方向づけ」「推敲」のフェーズが完了したときは何を作るのかがステークホルダー間で合意を得ていて、あとは可能な限りのリソースを「作成」フェーズに投入。短期間で一気に作る。
逆に言うと「方向づけ」と「推敲」に時間と工数をしっかりかける。合意にいたるまで反復をする。
ユーザーに丸投げさせないで、めいっぱい巻き込む。
・何を作る？　←要求開発
・どうやって作る？　←開発プロセスとアーキテクチャ
この二つがちゃんとしてれば作成開始。というかちゃんとするまで作成しない。

なんかイマイチ。現実的じゃない気もするし。

[Microsoft Office Project]リソースシートに起因するエラー

MSPの謎のエラー。
リソースを編集すると、もれなく強制終了……。

なんで？
仕事になりません。。。。。。

これはちょっとしたtipsの可能性が高いです。
おそらく「リソースシート」上で空の行があると、「ガントチャート」のリソース欄に編集を加えると落ちるようです。
それもデータ量が増えると可能性が高くなる？

MSPは謎が多いです。。。。。。

Flex Best Practices

Flex Best Practices

http://www.onflex.org/ted/2007/11/flex-best-practices-slides-and-code.php

高橋メソッド満載なPPTを読むだけでも賢くなった気がする、今日この頃。

"Release early,　Release Often"

このフレーズ好きです。

Microsoft REMIX '07の所感

2007年9月19日に開催されたMicrosoft REMIX '07に参加してきました。

仕事ではFlex/Javaのプロジェクトが多いのですが、個人的には.NETに興味津々なのでとても愉しい(?)一日を過ごしました。
キーノートセッション、ジェネラルセッション、テクニカルセッション×４のこんなにどっぷりイベントに参加したのは初めてです。

では私なりの感想を手短に、忘れないうちに。。。。。
（もう結構、忘れがち）


【キーノートセッション・ジェネラルセッション】
印象的だったのはMicrosoft社の鈴木さんと竹内さんのセッション。
プログラマはVisualStudio、デザイナはExpressionBrendというように別のツールを用いて同じアプリを構築する開発手法の実演。
ツールからして切り分けられる、というのはどうだろう。
すっきりしている気もするし、ちょっとツールに振り回されるような気もするし。
結局、プログラマもデザイナも両方のツールを使うことになっちゃうのではないだろうか。。。
それをいったらFlexアプリ開発もそうなんだけどさ。

でも個人的にすごく面白そうだと感じた。

あとTBSの女子アナがきた。
そういうのは早くいってよ！　知ってたらもっと前の方に座ったのに！！


【バランスの良いエクスペリエンス提供について】
セカンドファクトリーの東さんのセッション。
なぜか同じ列で知人に会う。あれ？　Flex/Javaだけじゃないんだ。アンテナはってますね♪

さてさて。
東さんのセッションは機会があれば結構、参加してますね。いつも勉強になるんです。本当に。

今回、非常に興味深かったのはエクスペリエンスのフォーカス領域とエクスペリエンスチームモデルのところ。私の頭の中で曖昧だったところがスッキリしました。上手くいっているプロジェクトは自然とそれに近い役割分担になっていたりするし。
pdfがダウンロードできるので興味のある人はチェックするべき。
(http://www.syncrare.com/?p=161)

これは是非、私が所属する会社バージョン、Flex/Javaバージョンを考えてみよう♪


【デザインパターンによるUI設計と標準化】
ソシオメディアの上野さんのセッション。ちなみにお会いしたことはございません。
清々しいくらいWPFとSilverlightが登場しないセッションでした。

あと床に座るくらい混んでた。一緒にいった同僚があきらめてPHPのセッションに行っちゃうくらい混んでた＾＾；
けど勉強になった。
とにかく勉強になったとしか言いようがないです。
ソシオメディアさんのサイトでUIのデザインパターンが紹介されているようなのでそちらもチェックするべし、ですね。
あと紹介されていた本も読みたくなったし。

UIについては使い勝手を「意識して作る」のと「意識しないで作る」のではできるものは大違いだと思います。さらに使い勝手だけでなく、それを使うユーザを想定することも大事。

【Silverlight Development Part1】
Part2は不参加…。

アークウェイの森屋さんのセッションは去年のREMIXもでました。
XAMLの読みは「ザムル」じゃなくて「ザメル」なんです。
これを思い出した僕はガンダム大好きっ子です。
（http://ja.wikipedia.org/wiki/%E3%82%B6%E3%83%A1%E3%83%AB）

森屋さんがセッションで言われていたのですがSilverLightはまだまだ「夢いっぱい」な技術なんだと思います。そう、これからなんです。まだαという位置づけなんです。
Flex2だって2年近く前はαだったわけだし。

まだ時間かかるかなぁー、と思います。
でもMicrosoftだしなぁー。一年後はわかんないなぁー。
すごいことになってそうだなぁー。


【WPF/Silverlight Case Studies】
酔いが回ってきた…。
これを書いている今は「よなよなエール」3本目…。

・WPFは結構よくできている
・Silverlightはまだちょっと…

そういう印象をうけました。


【最後に】
REMIXの後、仕事で.NETをやっている友人とその会社の人たちと飲みに行きました。
一瞬、.NET対Flashみたいなことにもなりましたが、彼らがWPF/Silverlightに対して並々ならぬ期待を持っていることはよくわかりました。

かなり.NETエンジニアが考える.NETvsFlashという話が聞けた。新鮮♪

【メモ】はやい やすい うまい

思うところがあったのでメモ。

QCD(品質、コスト、納期)はプロジェクト計画し進めていく上で絶対必要。
リスク管理をする上でもQCDに影響を及ぼすようなら即、対策を講じる必要があります。

お客さんとプロジェクト前の打ち合わせをすることが多いのですが、その際、必ず伝えることがあります。

「システム開発においてはやい、やすい、うまいはできません。できても二つまでです。」

はやい(納期)、やすい(コスト)、うまい(品質)の一つを達成するのは比較的簡単。
納期を早めたければ、計画段階から要員を多く投入しればいいし、安くしたければテスト作業を絞るなどがある。品質高めたければその逆、テストをしっかりやればいいし、UIデザイナ投入したりアーキテクチャ設計をやったり構築前の準備をしっかりやればいいわけです。

二つを達成するのは結構、難しい。できなくないけど。
納期とコストを優先するなら品質は犠牲になります。
他の項目も一緒。かならず何かが犠牲になります。
納期と品質優先の場合の難易度はかなり高いと思いますが。
(人がいっぱいいればいいってもんじゃありません)

要はバランスです。

コストは何よりも優先されてしまうのでこの制約を覆すことは非常に困難。
納期もマーケティングなどが関連する以上、制約はかなり強いはずです。
これらを優先するのなら品質が必ず犠牲になります。機能を削ることも必要でしょう。

もし三つ全てを優先するのなら……。

それは開発に関する技術や手法に革新的なことがなければ無理でしょう。
努力と根性でできることはたかがしれてますから。

[Microsoft Office Project]計画と実績の比較には基準計画

プロジェクトの予実管理、、、つまり計画と実際の差異がどの程度あったのかをMSPで計測するには基準計画とガントチャート(進捗管理)ビューを使います。

スケジュール作成の流れに沿って説明。

①タスク、期間、先行タスクを利用してスケジュールを作成。
　この時、開始日と終了日はマイルストーンに相当するタスク以外では極力触らないこと。
　触るとExcelで作ったのと大差のないスケジュールになります。

②リソースをわかる限り入力。

③リソースシートビュー、リソース配分状況ビューで重複をチェック。
　作業者を1日に16時間とか働かせないこと。そのまま使うとコスト計算が壊れます。

④基準計画の登場！　基準期間、基準開始日、基準終了日の列を挿入しましょう。
　(した方がわかりやすい)
　この時、見た目は「０？」だとか「N/A？」とかになってます。

⑤ツール→進捗管理→基準計画の設定を実行。
　期間、開始日、終了日などの情報が基準計画にコピーされます。
　このコピーは手動でコピペしても一緒。

⑥運用開始。進捗管理はガントチャート(進捗管理ビュー)を使いましょう。
　ガントバーが予実の二本立てになってわかりやすくなります。

基準計画は全部で10段階くらいまで保管可能。選択したタスクだけにも適用可能。
つまりプロジェクトの進捗にあわせてフェーズごとに保管とかの使い方ができます。
運用ルールを決める必要がありますが、MSPいじってる人なんて同じプロジェクトに何人もいるわけないので、自分で決めてさっさと適用しましょう。

[Microsot Office Project]コツやらショートカット

MSP使いのコツやらショートカット
(思い出したら追記修正)

<タスクのレベルの上げ下げ>
　「Alt」+「Shift」+「→」
　「Alt」+「Shift」+「←」
※　操作上、必須のショートカット。作業効率全然違う。
　　「＋」「－」のサブタスク表示、非表示も便利だけど私がノートPCを使っているためか効かない。。。

<ガントチャートの表示位置移動>
「Alt」＋「→」
「Alt」＋「←」
※　意外と役立つ。PgUp、PgDn、Home、Endも効きます。

<ビューバーについて>
たいていのMSP本にて紹介されているけど、必須！
「表示」→「ビューバー」にチェックをいれるだけ。
スケジュールを作っているときは「ガントチャート」。進捗管理をしているときは「ガントチャート(進捗管理)」。その際は基準計画は上手く使うべき(予実の差分をとること)

今思いだしたコツをいくつか。。。やり直したいプロジェクトがいくつかあるなぁ。。。

【読書】ソフトウェアエンジニアリング講座1 ソフトウェア工学の基礎

某巨大ECサイトにてあまりに不当な評価(☆1つって…)をされていたので、私なりの意見を。

ソフトウェアエンジニアリング講座は1~4まで刊行されています。

1 ソフトウェア工学の基礎
2 システム開発プロジェクト
3 プログラミング
4 オープンシステム技術

1はソフトウェア工学の基礎というサブタイトル通り、ソフトウェア開発にまつわる基礎的な知識を実務を強く意識して書かれています。
2まで購入しました。3は私がプログラミングすることはほぼないのでとりあえずパス。4は今度立ち読みして面白そうなら買う。
私がこの書籍について思うことはこんなかんじ。
・範囲がひろく各分野によっていろいろな解釈のなされるソフトウェア開発(エンジニアリング)の知識を簡潔に、体系的にしっかりまとめている。
・たとえばソフトウェアテストの項目なども実際にプロジェクトに携わっていて、テスト計画などを検討していればでてくる用語などがしっかりおさえられている。
・あくまで簡潔に、体系的にまとめている書籍なので、各項目については専門書を2,3冊は読むことをお勧めする。
・実務経験がある程度あるのなら、おさらいという意味で読むのは有意義。

私の場合はスケジュール作成および見積もり作成のときに、漏れがないかチェックするときに役立っています。
唯一おしい点は参考図書のページなどが一切ないこと。
あとこれからITについて勉強を始める方は避けた方がいいかもしれません。ある程度、実務経験か他の書籍での知識がないとただの単語の羅列に見えてしまうでしょう。

【メモ】RIAへの注目

要求開発アライアンスの納涼会に参加してきました。

納涼会なのでセッションはなかったのですがRIAの注目度に関して感想をメモります。

・1年前の納涼会の時より「Flex」という単語とその中身を知っている方が増えた。
・それって必要なの？　というよりもどのように使ってみようか、作ってみようかという話が増えた。
・RIA、リッチクライアントならうちに声かけてください、という方がいた。
・Adobe系、Microsoft系、Ajaxの成り行きについて皆さんいろんな意見をもっていらっしゃった。
・それでもアライアンス全体の中でもRIAについて熱をもっていかれている人は少数な気がする。

じわじわ広がってきている感じはしますが、導入に対してまだまだ課題が多いのかなという気がします。とくにビジネス上でどのようなメリットがあるのか、という説明がきちんとできていないこと。もしくはユーザーにメリットを感じ取っていただけないことがあるのかな、と。

プロジェクト管理の面でも課題があります。

たとえばFlex2でクライアントアプリを構築する場合、標準で提供されているコンポーネントを適用するのと、ほぼゼロからつくるカスタムコンポーネントを作るのでは工数が全然違います。

もしカスタムコンポーネントを作れるActionScriptのエンジニアの数が限られているにもかかわらず、カスタムコンポーネントで実現する機能がそれなりの量があるようだと、そのエンジニアのタスクがボトルネックやクリティカルチェーンになります。

このカスタムコンポーネントの必要、不要についてはFlex2をしっかり経験しているエンジニアの判断が必要であり、未経験のベンダーが「VBを参考にして」見積もりをだすと直ちに痛い目にあいます。

未経験であること自体は仕方のないことです。その場合は月並みですが下記参考。

・カスタムコンポーネントによって工数が大幅に増加するリスクが潜在していること
・要件定義～外部設計のフェーズで技術調査をしっかり行うこと。UPなら推敲フェーズまでです。
・これらをしっかり発注者と共有すること。
・発覚した場合、業務要件を満たせればOKなど回避策をとることも共有すること。
　(エフェクトが効かない、等のレベルなら許容していただく方がいいです)

カスタムコンポーネント作成に強いベンダーと連携することも視野にいれると良いでしょう。
機能を切りだしてしまえば、スケジュールへの影響を最小限にとどめられます。

【メモ】スケジュール作成のはじめの一歩

仕事柄、プロジェクトのスケジュールと見積もりを作成する機会がちょくちょくあります。

「二つとして同じものはないからプロジェクトである。」

というのは正しい。確かにその通り。
でも組織、個人などなどでプロジェクトの進め方に共通するものがあるはず。。。
ちょっと前まではバカ正直に要求仕様書やら打ち合わせやらの情報からフルスクラッチしていたスケジュールですが「共通するもの」をきちっと押さえておけば、作業時間はごそっと減る。。。。はず。

たとえば開発プロセスがUPなら
・方向づけ
・推敲
・作成
・移行
にざっくり別れてその中で何をやるかは本読めばちゃんと書いてあります。成果物もちゃんと載ってるし。（ウォーターフォールでももちろん同じ）
これはどんなシステムを作るとしてもだいたい共通してやることがある。

そのあたりを押さえてテンプレートを作っとくと楽ですね。
それかちゃんとノウハウとして自分が覚える→周りに伝える。

MicrosoftProjectのスケジュール作成は結構、時間がかかります。
作業効率を上げるためにも楽できるところは楽しましょう。

take_logはじめました

take_logはじめました。

ソフトウェアの見積もりとかプロジェクト管理とかそういう小ネタを書きたいと思います。

今後とも何卒よろしくお願いいたします。