最近、The GOALを読んでからちょっとだけ、TOCを勉強してみようかなと思いかじっているうちに、ITプロジェクトの管理に関しては本格的に勉強する価値があるのではないか?という気がしてきた。つまり、自分で経験的に知っているというレベルから、人に説明するうえで体系的な知識として使えるのでは?という意味です。

The GOALを知りたい方はこちらもどうぞ。

現場でITプロジェクト管理をやっていると、まず、政治的関係者は、PMBOKなどの言葉や、また、工学的な理論などよりも、マーケティングやら販売手法やらを考えている人たちの言葉に近いほうを形式的に学んだほうがいいような気がする。

というのも、PMBOKなどをかじる機会があったが、あまりに規模がでかすぎるという気がした。
何々、何々をするべき・・・
ってあるが、ITプロジェクトでは数百万から2,3千万程度の案件では、実際の実働部隊は二人くらいで、それ以外すべて管理者なんてことだってあり得る。ほとんどは、管理者の管理に翻弄され、実動する人たちに何も伝えられないって場合があるのではないだろうか?
で、実際には、実動する二人が勝手につくってしまってある程度できてから、やっとまともな話ができる状態になる。

そんなのが普通というときに、だいそれた「PMBOK」やら高度情報処理試験での「プロジェクトマネージャ」の理屈・知識は本当に通用するのだろうか?
あまりに、正論すぎる気がする。
(知らないより、知っていたほうがいいのはよくわかるし、それに、よく理解していれば使えるのもよくわかる。でも、小さい(予算が少ない)案件ほど、かなりの変則的応用を求められると思うので、小さい案件で基本を学び、徐々におおきくってプロジェクト管理の手法の学習としては無理があるのではないだろうか?関係者の調整力を学んでいくっては有効だが・・・
それに、学問が正論じゃなきゃ意味がないだろ!っていう気もする。)

それよりも、ほとんどうまくいかなく、問題と間違いだらけという前提から始めることができる「制約理論」ってのは、かなり現実にフィットしている気がする。
たとえば、「スケジュールというのを意思として決める」というより、制約として上から落ちてくるってのが普通だと思うし、使う技術・環境なんかも、選択するっていうよりも、今いるメンバーやハードで何が、どこまでできるか?っていう制約って考えるということになる。
たとえば、何かを変更したときに、カッコよく言えば「変更管理」っていうが、要は間違いに気付いただけだったりする。しかし、それを知る手法がわからないとか・・・

それに、たいてい失敗しているプロジェクトをみると、崇高な感じのドキュメントやら、過剰に投資した環境が多々見られる。なんでこんなになってるんだー。ってみると、コンサルタントなどを通して形式的には正しい方法をとっていたり・・・

という意味では、こんな時代に必要なのは、「失敗しないためのプロジェクト管理」ではなく、失敗の中から「成功させる」を生み出す理論のほうが大切なのではないだろうか?

そう考えれば、人は自由な選択と意思から計画的に生み出すものよりも、多々ある制約から生み出すものの方がよりいいものが生まれると思ってしまうのは私だけだろうか?

私も過去、自分がある制約からやりたいことができず、んー「まあ、これで今のところはいいか!?時間があるときにきちんと作りなおそう」と言って割り切って機能を実装したものが、ほかの会社ではその機能をみて、どうやってそれを実装しようかと試行錯誤していたということを聞いた。
それは、まさに制約から偶然生まれた「そういう事」だったのかも知れない。

次回は、「制約理論」と「サーバ管理」の関係を書いてみたと思う。

お仕事のご依頼・相談を承ります
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら

Leave a Reply

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2010年1月
« 12月   2月 »
 123
45678910
11121314151617
18192021222324
25262728293031

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ