[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"

このフレーズ好きです。