絶対に役立つ
プロジェクト管理
のノウハウ
ソフトウエア開発だけでなく、
あらゆるプロジェクトの計画・推進に 役立つノウハウがギッシリ!

シンボル プロジェクト管理サイクル シンボル

Mng_cycle

シンボル Meeting シンボル

Meeting

シンボル イントロ シンボル


はじめに

”プロジェクト管理は”人間管理”、”経営管理”で基本が重要である

コンピュータとコミュニケーションの融合、IT化の進展によるインターネット技術の高度化やサービスの普及は日進月歩であり、目覚ましいものがある。
それに伴い、IT機器に搭載するソフトウエアや、アプリケーションサービス、WEBデザインを実現するソフトウエアなど、 多くのソフトウエアの開発のニーズが高まっている。
一方、ソフトウエア開発の開発環境、プログラミング言語、開発手法などはソフトウエア工学の一部として進展しつつあるが、残念ながらプロジェクト管理手法は、 必ずしも十分とは言えない。
また、内容がいたずらにAcademicになり過ぎて、実務上は余り役に立たない場合も多い。
運輸業界、金融業界など大規模システムになるほど、社会的に大きな影響が出るトラブルが多発して来たのも記憶に新しい。 これもプロジェクト管理上の失敗と言っても過言ではない。
何故、多くのソフトウエア開発プロジェクトは失敗するのであろうか?それは、プロジェクト管理は、詰るところ、人間の管理であり、経営管理に他ならないが、 実態としては開発時間に追われ、ただひたすらソフトウエア(プログラム)を作る事だけに目が向き、重要な技術課題の見落としや、 品質管理の甘さなど人間に関わる管理が十分でないため、問題が続出し、それをリカバーするために予想以上の時間や工数、費用が出てしまうのである。
しかし、プロジェクト管理は決して難しいものではない。プロジェクト管理の要点は経営管理の要点と同じであり、プロジェクトリーダーが基本をしっかり理解し、計画を立案し、 それを地道に実行し、計画と実行状態の差分を補正しながら遂行する事こそ王道である。
管理の基本の基本が最も重要である。そこに秘策や奇策など無い。

本ホームページでは、ホームページのサイト管理者(私)が約40年間、大手電機メーカで各種のシステム開発に従事し、そのシステムを顧客に納入し、 運用するまでの一連の実際の作業から得た知識や経験、ノウハウを記述するもので、いくばくか後進の参考になれば幸いである。
専門書と思わず、単なるメルマガと思って気楽に読んで実務に活用していただきたい。

ソフトウエア開発プロジェクトは大きく、“計画の整合”(計画の作成)と“実行”の2つのフェーズに分けられる。
更に、“計画の整合”は、“仕様固め”、“日程作成”、“体制作り”に分けられ、“実行”では、“進捗管理”、“品質管理”、“技術管理”、“費用管理”に分けられる。
これらの項目を順々に説明して行く。
なお、プロジェクト管理やそれを構成する課題には、多くの参考資料や文献がある。 理解を深めるための参考資料は“Reference”欄に掲げたので、興味のある方はひも解いて欲しい。
ただし、前述したように管理手法の内容が複雑になり過ぎたり、Academicになり過ぎると、管理のための作業が増えすぎ、返って実際のプロジェクト管理では実用的で無くなる きらいがあることは私自身の経験の一つでもある。

また、私はプロジェクト業務遂行上、一般的な業務ノウハウも多々、学習し経験した。簡単に説明出来るものは、“ワンポイントノウハウ”欄に記述し、 少し説明を要するものは、"SEMINAR"ページから、”LESSON”として項目ごとに展開し順次、記載して行く。 業務推進上、これらも是非参考にし活用していただけたらと思います。

シンボル ワンポイントノウハウ シンボル


2012年12月28日

“議事録は、会議の前に作っておけ!”
プロジェクトリーダーは、自分の主催する会議の進行方法、結論は事前に決めておく位の 強いリーダーシップが必要。会議をやる時は、どんな目的でやるか、どう話しを進めるか? その結論は?等を事前に計画しておくようにと言うこと。
そうしないと、会議はいたずらに、無駄な議論や四方山話に終始したり、小田原評定になり 時間の無駄になる。また、プロジェクトの進め方もかえって不明確になってしまう。


2012年12月15日

“ビジョンを描け! 旗を掲げろ!”
プロジェクトリーダーは、明確なビジネスビジョン、プロジェクトの目標を掲げ、メンバーに はっきり示す必要がある。プロジェクトメンバーは、常にそのビジネスビジョンやプロジェクトの 目標を意識して行動する事により、始めてプロジェクトチームが一丸と成れる。


2012年11月15日

“落ち着いて慌てろ!”
業務遂行中、色々な問題が発生する。顧客からクレームを付けられる問題などは、 社内問題より優先して解決しなければならない。しかし、人間である以上、問題が大きい ほど慌ててしまい、問題の全体把握や原因分析が甘くなり、真の原因を掴み、対策を施す 事が難しくなる。そして結果的に問題を更に拡大させてしまうこともあり得る。 問題発生時は、まず、気持ちをしっかり持ち泰然自若に構え、動作は適確かつ機敏に行う ことが重要である。


2012年10月31日

"改善活動の成果は、いきなり“100点”を追わない(SEMINAR あり)"
仕事の改善活動は、しばしば、“売上を2倍にしろ!”“コストは半分にしろ!” など、威勢の良いスローガンが掲げられる。その事自体は、問題ではなく関係者を鼓舞する 目的には良いかもしれない。しかし、そのような高い目標が容易に実現できるなら、 すでにやっていたはずである。コストを半分にする事を例にとるなら、まず第一段階で 30%削減策を検討し、その施策を実行する。それが出来たら第二段階として更に30%削減策を 検討し、その策を実行する。二段階で実現出来れば、0.7×0.7=0.49≒0.5となり、当初の 半分にする目標が達成出来る。“山上、山あり、山、幾層!”と言って、まずは第一段階を 達成しないと、次の問題や改善策は見えて来ない。


2012年10月14日

"究極の仕事の効率化は、その仕事をやらないで済むようにすること。"
仕事の効率化は1時間要した仕事を50分で完了できるようにするなどで、事業推進が厳しく なるほど提唱され、施策が検討される。 しかし、ある作業の効率化を検討する前に、本来、その作業の必要性をしっかり見直す事が 重要である。その作業は、“今までやっていたから”、“この作業がないと心配だから”と 言う業務が多々ある。品質向上のための、“検査作業”も、あらゆる品質問題が洗いだされ、 それに改善策が施されたなら、無用な作業と言える。


2012年9月30日

”他人(他グループ)と関わりあう業務をスムーズに行うには?”
他人(他のグループ)にお願いする業務は、頼まれた方の業務の優先順位で作業が 行われる。従って、他人(他グループ)にお願いする業務は、自分自身が行う業務より 先に準備し依頼することが重要である。自分の担当分は終了したが、他人に依頼した ものが出来ていないので、全体的には、未だ業務が完了しないということにならない ように注意すべきである。


2012年9月14日

”上司の仕事の一つは部下のやり方にケチを付けること。”
上司が、すべて部下の言うなりになっていたのでは上司としての存在感はない。 本来上司は部下より知見があり、部下の意見を越えるものを持たねばならない。 しかし、上司が仮に部下の意見ややり方が良いと思ってもケチを付ける事がある。 部下はそれを、“上司の立場はそんなモノ!”と承知し、ある程度以上の無用な議論は 避ける方がスムーズ に事が運ぶ。


2012年8月30日

”社員が仕事の遅れに慣れっこにならないように!”
社員には仕事の完了日程を絶対に守るよう、指導すること。完了日程をキープ 出来なくても上司が何も言わなければ、社員は、それで良いものと思って完了日程を 守る気持ちが薄くなる。


シンボル Sign-In シンボル

 Eメールアドレス

 パスワード



会員に登録されると毎週1回、無料で
メールマガジンが送付されます。


シンボル ブレークタイム シンボル

このページのコンテンツには、Adobe Flash Player の最新バージョンが必要です。

Adobe Flash Player を取得

シンボル アクセス シンボル


〒000-000
千葉県柏市
旭町1-2-3
アディックコーポレーション

TEL:04-0000-0000

会社の地図



大きな地図で見る
inserted by FC2 system