有能なプロジェクトマネージャを育てるには(1)
2006/10/21
システム開発方法論がプロジェクトマネジメントの前提
- - PR -
マネジメントの対象となる開発方法や作業のやり方が明確でなければ、そのマネジメントの方法や仕組みは具体的にはできない。システム開発のプロジェクトマネジメントの前提条件はシステム開発方法論(注4)にある。
プロジェクトマネジメントの知識を仕事に生かせるレベルのものとして身に付けるためには、情報システム開発の方法論とマネジメントの仕組みが一体のものとして、頭の中に整理できていることが必要である。プロジェクトマネージャの立場に立てば、システム構成方法(ソフトウェア工学)は、情報システム開発方法論を具体的に裏付けるPDCAの“D”の内容に相当する。
(注4)
|
なお、マネージャも1人のITのプロとして、1〜2の代表的な開発方法論をマスターしておくことが必要だ。キチッとマスターしておけば、問題や使う技術に合わせた応用・修正(モディフィケーション)は比較的容易にできると思うがどんなものであろうか。
10年〜15年使う可能性の高い基幹システム(注5)に対しては、マネジメント問題として、確立されて久しいフェイズ管理方式(結果的に一種のウォーターフォール型)とデータ中心設計に代わる実用的な方法は、いまあるのだろうか。データベースの構成とプログラムロジックを実体の写像としておくことは、どのような方法を取るにせよ必要であるし、適切なサブシステム分割、プログラム分割やプログラムの再利用は昔からある課題だ。こんなことが実施段階でキチっとやれていないことに起因する問題を、開発方法論の問題ということにしてしまっていないだろうか。
また、IT屋は無意識のうちに技術指向になりがちだ。経営陣から見ると枝葉にすぎない新技術を、技術への思い入れから幹と見間違えないような注意が常に必要だ。
(注5)
|
なお、オブジェクト指向とこれをベースとする仕組みが、ソフト問題の救世主という意見があるが、頭の固くなったオールドタイマーの筆者には、十分理解・評価ができていない点をお断りしておきたい。1ユーザー企業にとってではなく、多数の顧客を対象に同種のシステム開発や保守を念頭に置くシステムインテグレータには魅力のある方法かもしれない。しかし、これはマネジメントというより、開発方法論を具体化する技術レベルの問題のように思う。
マネジメント力の習得に大切な“場”の設定
プロジェクトマネジメント能力の育成には、適切な“場”が必要になる。最も有効な場は、適切な指導やアドバイスが受けられる実際のプロジェクト−OJT(On the Job Training)だ。
しかし、実際の現場では時間に追われ、トレーニングの面からはもう一歩突っ込んでおきたいことがあってもなかなかできないという現実もあるし、適時に能力向上のためのアドバイスが得られる環境にあるとは限らない。
Off the Job Trainingでは、同じ問題意識を持つ人たちの間で、共通の課題を設定して行う共同作業と討論が有効だと思う。鍵は心の「集中の度合い」、つまり、どこまで打ち込んで一生懸命になれるかにある。しかし、ここでできるのは判断のための知識やノウハウの向上であって、マネジメントの大切な要素である決断力や徹底的な実行力は、やはり実際の修羅場をくぐらないと身に付きにくいようだ。
■次回予告
プロジェクトマネジメント能力育成の第2回目となる次回は、システム開発のプロジェクトマネジメントをPMBOK(the Project Management Body Of Knowledge)を参考にして考えてみる。
情報システムコンサルタント(日本情報システム・ユーザー協会:JUAS)、情報処理技術者(特種)
元武田薬品情報システム部長、1999年12月定年退職後、ITSSP事業(経済産業省)、沖縄型産業振興プロジェクト(内閣府沖縄総合事務局経済産業部)、コンサルティング活動などを通じて中小企業のIT課題にかかわる。
今回から3回にわたって、企業を去りつつある団塊の世代のシステム開発におけるプロジェクトマネジメント能力を、いかに若い世代が受け継いで、自らを育てていくかという問題を考える。
日本の多くの企業におけるマネージャの役割は、「仕事を見たり聞いたうえで、それを判断し、部下に伝えること」と、「仕事に必要な環境・条件を整えること」の2つに尽きるだろう。PDCAサイクル上でいえば、P(計画)とC(チェック)、A(アクション)の指示がマネジメント機能だ。
システム開発のプロジェクトマネジメントの前提条件はシステム開発方法論にある。プロジェクトマネジメントの知識を、仕事に生かせるレベルとして身に付けるには、情報システム開発の方法論とマネジメントの仕組みが頭の中に整理できていることが必要だ。
さらに、プロジェクトマネジメント能力の育成には、適切な“場”が必要だ。最も有効な場は、適切な指導やアドバイスが受けられる実際のプロジェクトOJT(On the Job Training)ではあるが、現実問題としては、自ら学ぶために同じ問題意識を持つ人たちの間での真剣な討論を行える“Off-JTの場”作りが必要だ。
| Page 1 問題とその背景 |
|
| Page2 マネジメント能力とは何か―マネジメントの問題を抽出してみる |
|
| Page3 システム開発方法論がプロジェクトマネジメントの前提 マネジメント力の習得に大切な“場”の設定 |
何かがおかしいIT化の進め方 バックナンバー 連載インデックスへ»
- 第1回 世評やベンダの意見に踊らされていませんか?
- 第2回 IT化に対する関係者の不安や不満を取り除くには
- 第3回 プロジェクト・チームの編成で失敗していませんか
- 第4回 IT部門の存在価値は“全社最適”にあり
- 第5回 全社IT最適化のカギは「データ体系の統一」
- 第6回 優秀なスタッフを育てる職場環境とは
- 第7回 仕事への取り組み方は最初の数カ月で決まる!
- 第8回 ブレークタイムに“設計思想”を語り合おう
- 第9回 “誰にでもやさしい”ITは良いことなのか?
- 第10回 ブレークタイムでの話題−製品と情報化のコンセプト
- 第11回 IT化と投資の“正しい”関係とは?(前編)
- 第12回 IT化と投資の“正しい”関係とは?(中編)
- 第13回 IT化と投資の“正しい”関係とは?(後編)
- 第14回 ITの動向や他社の状況を、気にし過ぎていませんか?
- 第15回 いまのIT組織でいつまでやっていきますか?
- 第16回 続・いまのIT組織でいつまでやっていきますか?
- 第17回 理想的な上司と部下の関係とは――部下の育成方法
- 第18回 IT徒然草――コストと利便性を追い求めて失うもの
- 第19回 羽田空港の管制はなぜ止まったのか?
- 第20回 JR脱線事故からマネジメントを学ぶ
- 第21回 “気付き”のコミュニケーション
- 第22回 阪神大震災10年目に考えること、するべきこと(前編)
- 第23回 阪神大震災10年目に考えること、するべきこと(後編)
- 第24回 情報システム部は、もう役割を終えてしまったのか?
- 第25回 リーダーシップを発揮するにはどうすれば?(前編)
- 第26回 リーダーシップを発揮するにはどうすれば?(後編)
- 第27回 SOX法とコンプライアンスとIT
- 第28回 有能なプロジェクトマネージャを育てるには(1)
- 第29回 有能なプロジェクトマネージャを育てるには(2)
- 第30回 有能なプロジェクトマネージャを育てるには(3)
- 第31回 ディスカッションテーマのおもちゃ箱(1)
- 第32回 ディスカッションテーマのおもちゃ箱(2)
- 第33回 ゆでガエルになる前に情報子会社は経営の見直しを
- 第34回 “シックオフィス”で健康を損なっていませんか?
- 第35回 コンプライアンスを語る前に考えてみること
- 第36回 適材適所の人材育成をしよう
- 第37回 事の本質を見極めよう
- 第38回 その考え、本当にあなた自身のものですか?
- 第39回 “変化”は外からやってくる(前編)
- 第40回 “変化”は外からやってくる(後編)
- 第41回 “変化”を模索する世界(前編)
- 第42回 “変化”を模索する世界(後編)
- 第43回 変化の中で、自らを制御できるものが生き残る
- 第44回 新型インフルエンザ対策に学ぶ組織の在り方
- 第45回 持続可能社会とITシステムはどう在るべきか(前編)
- 第46回 持続可能社会とITシステムはどう在るべきか(後編)
- 第47回 いまあらためて確認したい、情シスのイロハ(前編)
- 第48回 いまあらためて確認したい、情シスのイロハ(後編)
- 第49回 失敗は成功のもと、成功は失敗のもと
- 第50回 「想定外」から脱却できる、真の対策を
- 第51回 他山の石――政治を顧みて学ぶマネジメントの在り方
- 第52回 “影”から目を背けてきた原発とIT
- 第53回 優れたシステムを作るための“思考力、人間力”とは?
- 第54回 IT関係者は、原発事故から何を学ぶべきか
ホワイトペーパー(TechTargetジャパン)
|
|


