2007年8月18日土曜日

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

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

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

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

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

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

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

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

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

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

2007年8月17日金曜日

[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について勉強を始める方は避けた方がいいかもしれません。ある程度、実務経験か他の書籍での知識がないとただの単語の羅列に見えてしまうでしょう。

2007年8月16日木曜日

【メモ】RIAへの注目

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

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

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

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

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

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

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

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

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

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

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

2007年8月15日水曜日

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

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

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

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

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

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

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

2007年8月14日火曜日

take_logはじめました

take_logはじめました。

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

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