スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
[--/--/-- --:--] | スポンサー広告 | page top
品質を良くするには?
品質について日ごろから思っていることを書きます。

以下の2点を自分はもちろんのこと、他の人にも守ってほしいです。

1.後工程で品質のよいものは作れない。
品質管理の世界では有名な言葉ですが、「品質は工程で作りこむ」というものがあります。
1960年頃にトヨタ自動車で生まれた言葉だそうです。

自動車やソフトウェアは完成してから、問題点が見つかっても直すのが非常に大変です。
初期段階で問題を発見した時に比べ、数十倍ものコストがかかるとの統計情報もあります。

いかに早めの工程で問題を発見/修正することが大事だということです。
具体的には、フレームワークやデザインパターン的なものの活用や、
静的解析ソフトなどの活用が有効ではないでしょうか。

2.修正後に必ずチェックをする。
当たり前だと思うような気がしますが、以外と出来ていないようです。
現職でも、いまだに時々発生する問題です。

修正したら、必ず差分比較ツールなどを使って思わぬところを修正していないかどうかの、確認が必要です。
また、一通りの機能を使ってみることも非常に大事です。

ちなみに、差分比較ツールは、Beyond Compareがおすすめです。
WinDiffなどのフリーソフトに比べ、はるかに精度がよいです。
スポンサーサイト
[2012/10/12 21:29] | プロジェクトマネージメント | トラックバック(0) | コメント(0) | page top
WBS的なものは必須!失敗フラグが立ちますよ。
システム開発に限った話ではありませんが、
WBSというか、最低限作業項目の洗い出しは必須だと思います。

PMBOKでいうようなプロジェクト(過去に似ている案件はあっても全く同じものは存在しない)において、
計画フェーズでの作業項目の洗い出しは絶対必要だと感じています。

自分は、約2年前までSIerで開発をし、今は非IT企業で社内SEみたいなことをしています。
いわゆる社内SE(情報システム部)とちなうのは、業務部門で実案件でのプロジェクト支援をすることです。

2年の経験で気づいたことは、PMBOKは業種に関わらず適用かのうと言っていることは、
ある程度は正しいということです。
ある程度というのはIT+1業種(ニッチすぎるので出せませんが)では統計的に正しいとは言い切れないからです。


ですが、案件ごとに個別対応を求められる仕事では、WBS的なもの+リスクマネージメントは、
必要不可欠だとの結論を持論として持ちました。

最低限、受注後(受注が確実な時点)で、以下のことはプロジェクトマネージャとして、必要ではないでしょうか。
①いつから、
②いつまで、
③誰が、
④どのように、
⑤何を、
⑥いくらで、
するか。
を計画し、作業者に伝えることです。

要は、5W + 2H(どこでは必要に応じて)だと思います。

WBSというと難しく感じるかもしれませんし、業種によってはそんな余裕などないかもしれません。
ですけれど、最低限のことをするだけでも、失敗フラグが立つ(赤字になる可能性が高い)ことは減ると思います。
[2012/10/12 00:49] | プロジェクトマネージメント | トラックバック(0) | コメント(0) | page top
日経Systems10月号を読みました。
定期購読している日経Systems 10月号が届きました。
特集の「助け合いを生む プロジェクト情報基盤」が良かったです。

プロジェクト情報基盤の役割
(1)タスク管理
(2)情報共有

RedmineTracで構築可能。

タスク(作業内容、進捗、担当者など)管理と、情報共有(作業手順書や案件ごとの注意事項)ができるので、
メンバー同士で助け合える。

ただ、導入するだけでは効果はない。
登録・更新や情報を見てもらう仕組みが必要。

続きを読む

テーマ:システム開発 - ジャンル:コンピュータ

[2012/09/22 22:42] | プロジェクトマネージメント | トラックバック(0) | コメント(0) | page top
なれる!SE4巻読みました。
なれる!SE 4 誰でもできる?プロジェクト管理 (電撃文庫 な)なれる!SE 4 誰でもできる?プロジェクト管理 (電撃文庫 な)
(2011/05/10)
夏海 公司

商品詳細を見る


新卒のネットワークエンジニアが、
社長の陰謀により、突然破たんプロジェクトのPMになるお話しです。

しかも、クライアントの引っ越しプロジェクトで、
ファシリティ・LANなど数社が絡み合うプロジェクト。
自分はネットワークは知りませんが、考えるだけで大変そう。

いくつか、読んで思ったことがあります。
①PMBOKで使用するドキュメントについて
プロジェクトマネージメントを全く知らない主人公と上司であるヒロイン。
本やネットでPMBOKを勉強しますが、
PMBOKのほぼ全てのドキュメントを使おうとします。
当然、メンバーからは猛反対。

やはり、ドキュメントの取捨選択は必須。
作品の中では、以下の4種類が挙げられていました。
 ・プロジェクト計画書
 ・WBS
 ・スケジュール
 ・課題管理表

私も同意します。
特に、WBSを作らない・知らないPMの案件で、納品の直前に作業を振られたことが何度かあります。
(内容的には受注後の準備段階で必要だと分かっているはず。)

②相手のタイプに合わせたコミュニケーション
作品の中ではメンバーには、3種類の人がいると言っています。
<サーバ>タイプ
自主的に動く人。基本的に任せる。
<ツール>タイプ
指示されたことを忠実に実行する人。細かなことまで指示を出す。
<クライアント>タイプ
責任感はあるが、PM(会社)に環境を整えることを求める。
要望を聞いて、業務の妨げになる要因をつぶす。

この考え方の、元ネタは分かりませんが、なるほどと思いました。

なお、作者は元SEだそうです。
小説なので多少誇張はされていますが、ありそうな話しが多いです。

テーマ:雑記 - ジャンル:コンピュータ

[2012/09/02 15:50] | プロジェクトマネージメント | トラックバック(0) | コメント(0) | page top
| ホーム |
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。