• プロジェクト管理はマラソンではない

    プロジェクト管理は、マラソンとはちがう。

    競技としてのマラソンは、42.195kmをいかに早く走るかだが、

    プロジェクトの達成にそれほど厳密なルールはない。

    車を使ってもいいし、

    レンタカーを借りてもいいし、

    ドーピング(投資家から大規模な資金を調達)してもいいし、

    ルートを変更してもいい。

    ビジネスの理念やビジョンやコンセプトから、はずれなければ、
    あらゆる可能性をつかって、プロジェクトをゴールへ導けばいい。

    サービスを提供する/受ける人が満足できて、
    不当に不利益を被る人がいなければ、どんな方法でゴールしてもいい。

    マラソンだと、今までの記録が2時間だったものが、急に1時間で走れるということもないが。

    プロジェクトは、バイクで30分後でゴールしたっていい。

    ぎゃくに、3日かけて休みながらゴールしてもいい。

    そういう意味では、

    プロジェクト管理の柔軟性は、

    経営者の経験やスキルやアイデアと社員の経験、スキル、アイデアが総合的に関係している。

    経験やスキルが足りなければ、アイデアで補うこともできるし、

    アイデアを出すのが面倒なら、たくさん失敗して経験やスキルを磨けばいい。

    ナビを使って、標準的な状態でプロジェクトをゴールに導くこともできる。

    つまり、先人の知恵を勉強して、そのとおりに実践してみることで、それなりの達成ができる。

    いろんな側面からプロジェクト達成をとらえられれば、
    プロジェクトの失敗も激減する。

    Top

  • プロジェクトリーダーとエンジニア

    これからのビジネスにITは不可欠。

    だから、端的にいって

    今後、ITの知識がないプロジェクトリーダーや経営者は、成立しなくなる。

    いまさらの発言で、言うのも恥ずかしいくらいだけど。

    Webサイトもなし、

    顧客管理も紙ベース、

    連絡も電話か手紙、

    なんて状況は、

    なんらかの意志と戦略がないかぎり、ありえない。

    伝統工芸や古典芸能などの分野でさえも、

    よくできたWebサイトを運営しているのが通常といえる。

    そう考えると、すべてのビジネスパーソンは、
    ITとかかわらなければならない。

    そこで、

    「経営者がエンジニアについて理解している必要はない
     経営者がプログラミングするわけではないのだから・・・」みたいな

    声も聞こえてくるが、

    どことなく寒い発言のような気がしてならない。

    エンジニアリングについてなにも知識がなくて、

    エンジニアに働きやすい環境を経営者は提供できない。

    実際、

    技術的な知識ゼロでエンジニアに企画を投げることで、

    無駄なコスト、ディスコミュニケーションが多発している。

    考えてみよう。

    子どもが急に、

    「クリスマスにロケットをください」

    と言ったらどうするだろうか?

    理由を聞いたら

    「かっこいいから」

    くらいの理由で。

    ロケットがいかに高額なもので、

    買ったとしても、置き場所に困るし、

    使い道にも困る、

    おそらく認可も必要だろう

    など、判断できるほどの知識がないのだ。

    これでは、お話にならない。

    文字通り、話し合いが成立しない。

    プログラミングの難易度、システム構築の難易度すらわかっていない

    経営者やプロジェクトリーダーは、この子どもとおなじことをやってしまう。

    重要なポイントは、

    経営者は、エンジニアに求めるものの困難さと重要さを理解していなければならない

    ということ。

    ロケットを手に入れることの困難さをわかっていて、

    かつ、

    それを手に入れることがいかに重要であるかを理解していれば、

    話し合いと実現の余地が十分にある。

    子どもが「超薄いラップトップPCが欲しい」というのと

    スティーブ・ジョブズさんが「茶封筒に入るラップトップを開発しよう」というのでは、

    まったく次元も実現度もがちがってくるのだ。

    Top

  • 中途半端で終わらせる

    投稿 13 2011年12月 by 暫定CEO in プロジェクトについて with 0 comments

    富士山(投稿とは関係ないけど)

    しごとは、やりきったところで終わらせないこと。

    1日単位のしごと、1週間単位のしごと、1ヶ月単位のしごと、
    あるいは、四半期、年間、いろんな単位があるけど、
    かならず中途半端なところで終わらせること。

    米国の人気ドラマは、5年、6年とつづくものもあって、
    シーズンの最後は、かならず、中途半端な状態で終わる。

    映画や小説のように、
    見終わったあとの満足感がつよいと、
    つぎのシーズンを見る欲求が減る。

    しごとも、
    やりきった感のあるところで終わりにすると、
    しごとをしたくなくなる。

    腹八分目ということばがあるように、
    通常は、「残りは明日やろう」くらいにしておくのがベスト。

    余裕がないときは、
    しごとをやりきって、プラス1のしごとをしておく。

    つまり、
    せっぱつまっていないときは、
    腹八分目で少し残しておく。

    せっぱつまっていて余裕がないときは、
    やりきって、かつ、つぎのしごとにちょっとだけとりかかっておく。

    ちょっと残すのがつづくと、
    どんどんしごとがたまっていきそうな気がするけど。。。

    結果的に、
    しごとに集中できるので、やりきるよりも
    効率は格段にあがる。

    Top

  • 皆既月食

    スケジュール管理をなんのためにするのか?

    ほとんどの本には、
    「遅延しないスケジュール管理」
    みたいに、
    スケジュール管理は、遅延を防止して
    計画どおりにプロジェクトを達成するため
    というのが前提で書かれている。

    じゃぁ、
    遅延したら、なにが問題なのか?

    コストがかかるとか
    クライアントに迷惑がかかるとか
    そういうことに行き着く。

    実際のところ、
    遅延そのものを懸念しているわけではないということ。

    働く1人ひとりが充実して、
    着実にプロジェクトが進行していれば、
    原則的に、プロジェクトが遅延しても問題ない。

    別のいいかたをすると、
    人間はすべからく、「遅延したってべつにいい」
    と考えている。

    だから、
    遅延しないためのスケジュール管理なんてのは、
    建前でしかない。

    それよりも、人間は、
    信頼し合いたい
    楽しくいきたい
    充実感がほしい
    という欲求のほうが根源的につよい。

    だから、
    遅延しないという建前の欲求を満たすのは難しく、
    信頼し合いたいという欲求を引き出してあげるほうがよほど建設的といえる。

    クライアントに気持ちよくすごしてほしいから遅刻しないように行く
    のであって、
    マナーとして遅れないようにするのは、説得力に欠ける。

    京都のある宗派のお坊さんは、
    みんながそろってから読経できるように、
    かならず遅れて登場する。

    ここは、1つ、逆の見方をしたほうがいい。

    スケジュール管理は、
    働く1人ひとりが充実しているかどうかのバロメータである。

    バロメータってことばが古いか。。。

    プロジェクトリーダーたるもの、
    遅延しないか必死で監視・・・なんてせず、
    充実感を感じられる環境を提供できているか顧みよう。

    Top