カテゴリー別アーカイブ: PMあるある

プロジェクトをやっているうえでのあるあるネタ

4リーダーシップ, PMあるある, プロジェクトマネージメント

潰れて行くマネージャーその１　【能力不足昇進】

コメントをどうぞ

こころを病んだりして潰れて行くマネージャは多いと思います。

いろんなパターンがるとおもいますが、今回は能力不足が原因でつぶれるパターンです。

技術を中心にやってきてプログラミングが得意で技術的にはお客様の信頼も厚く、業務も理解しています。
農業科学分野でIT化という観点でそうそうある業界ではないため、ほとんど専門家の領域です。

「ここは彼の能力に期待して管理職であるマネージャー(課長)にしてがんばってもらおう！」と思ってマネージャにしました。

管理職になってその農業科学分野だけでなく広く研究所を顧客として扱っているプロジェクトを見る必要が出てきます。
なれない分野も戸惑いながらも何とかやっているように見えました。

ところが、しばらくすると会社を休みがちになり、とうとう出勤できなくなってしまったのです。

何が起こったのでしょうか？

面談をすると、こんなことをいいます。
「物事が決められなくなってしまって、これじゃだめだと思って、一生懸命やろうと思うのですが、頭が回らないのです。
自分でも甘えだと思うのですが、どうしてもうまくいきません。」

管理職としていろいろな判断をしなくてはならないのだが、どう判断していい川からない中で、下から「どうしましょう？」「どうしたいいですか」「方針を示してください。」としたこともない判断を迫られます。

今までは自分の得意分野で、研究開発の支援を仕事として信頼できる仲間とやってきています。いきなり、知らない分野(物理等)で、性格もわからない部下やお客様と話をして社としての方針を決めなければなりません。ITを使った研究だと生物系は少なく、工学・理学・物理系が多いです。
科学の専門用語の多い分野ですから畑が違うとはっきりいってお客様と部下が話している内容も理解できません。「まさかお客さまに何を言っているか聞くわけにもいかず・・・」と悩んでいるうちに体が動かなくなっていったそうです。

かく言う私も、管理職になりたてのころというか、いきなり管理職採用であったため、新しい会社で課長です。
管理職になると専門だけでなく、人事管理、業績管理、PJ管理等いろいろやらされます。
もともと人事関係を専門としようとしていたため人事管理は問題なかったのですが、部下からのディシジョン要求には参りました。業界をまたがった転職であったために、業界の常識や慣習がわかりません。幸いなことに相談できるほかの管理職の方が複数いてくれたため、ある程度は問題なかったのですがやはり細かい判断で迷うところもあり、自分には向かないのかと悩む場面もありました。そんなこともあり、方法として「意思決定」の項目を詳細に書かせていただきました。

意思決定
① 意思決定ができないことで悩んでないか
　　(イ)丁半博打で決めるのはNGです
(ロ)情報が足りないなら聞けばいい
　　(ハ) コーチングのふりをして聞き出す
　　(ニ)利益衡量をする
　　(ホ)何等か自分が納得のいく理由をつける
② 腹をくくれ
③ 自分で手におえないと判断したら

例によって、まだ書いていないところもありますが気長にお待ちを・・・

※全体を通じて分野や起こったこと等実際の例を書いているわけではありません。

3プロジェクトマネージャとは, PMあるある, プロジェクトマネージメント, 用語

用語：パークとソリューション

コメントをどうぞ

業態やその組織の性質によってパークベースなのかソリューションベースなのか違うと思います。

ソリューションベース
特定のよく使われる技術があってどこでも同じような業務がある場合、ソリューションベースで事業を展開していくことが多いように感じます。この場合でも使われる技術によっては業界が限定されることもしばしばであろうかと思います。
「人事給与ソリューション部」「財務・経理ソリューション部」「BWHソリューション部」「防災ソリューション部」等のような名前になることが多いと思います。

パークベース
官公庁系ではどこもオリジナルの業務を行っており、ソリューションとしての使いまわしができないことが多いです。縦割り行政の影響でしょうか、似たようなシステムであっても中身は大きく違っていることがほとんどです。
その場合はどうしても特定のお客様につくパークベースの仕事の進め方になります。お客様の指定する進め方や、納品物などに対応することが重要だからです。
「○○社担当部」「○○省事業部」「○○県庁営業部」等特定のお客様のお仕事であればとりあえず引き受けるタイプです。

どっちを採用するか
民需の作業では業務遂行ができてプログラムが動けば納品物はあまり言われないのかもしれませんが、官公庁の場合、前例踏襲主義や会計検査院の検査対応、無謬性の証明の証拠、各種ガイドライン等へのプロジェクト遂行の順守の必要から、プログラム以外の納品物が大変多いです。
そのために、慣れないと失敗することが多く、パークごとに担当者がつくパークベースのプロジェクトが多いように感じます。

どちらが良いというものではありません。適切な切り口でプロジェクト遂行をするのが良いと考えます。
どちらかを選ば根ければならないということもないでしょう。縦糸と横糸の関係ですから、立野役割をもつ縦糸と横糸の役割を持つ組織が両方あっても構いません。
うまく連携できるような仕組みつくりは必須ですが、共存可能です。事業幹部はじっくりとよく考えて組織を構成してみましょう。

混ぜる必要がある場合も
構造としては営業部門などの顧客と密接なところはパークベース、開発部門などは技術で分けるソリューションベースがよいように感じます。とはいえ、営業ではない技術者も顧客の業務に詳しい必要があり、中間的な立場としての組織として両方の仲立ちをしつつパークを見る技術者も必要になって、きれいにすっきりした組織にできないことがあります。(技術者なのにパーク付き・・・)

皆さんの組織はどうですか？

パーク：対象とする市場、顧客
ソリューション：対象とする要素技術、システム製品、業務分類

PMあるある, プロジェクトマネージメント

コラム：怒りポイント

コメントをどうぞ

人それぞれ怒りポイントというものがあります。
上司のそれを押さえて触れないようにするのがサラリーマンの技術ですが、皆さんはどうですか？

わたしも上司のポイントを押さえられているのでしょうか？
私の怒りポイントは・・・
考えてみるに私の場合は騙されたときでしょうか？

例えば、何か見解を求められたとき、前提条件付きでOK出したりします。
この前提条件が無視されたときが怒りポイントです。
前提条件は無視してよいものではなく、前提なので、それがなくてもOKなのではなくNGなのです。

以前、１０年くらい前の話ですがある省庁PJの権利関係で契約上プログラムの一部分の権利が守られるかの見解を求められたことがあり、この時は日本版バイ・ドール条項（産業技術力強化法（平成12年法律第44号））の所定の書式を提出すれば大丈夫との見解を出しました。
それで権利関係については大丈夫だろうということになったのですが。
この前提が無視されて担当者がこの所定の書式を提出しなかったのです。理由はあります。現課に提出を打診したところ、「前例がない」とのことで提出ができなかったということなのです。契約で提出すればOKと書いてあるのに、提出された前例がないから提出できないということでした。お客様との関係がありますから無理なことはできません。
当時はお客様が開発ベンダーしか改造をしたり保守したりできないことに問題を感じていて、自分たちに権利を持ってきてどのベンダーにも保守や改造ができるようにする目的でこの法律を利用していたのです。
この産業技術力強化法（平成12年法律第44号）の趣旨は「政府資金による研究開発から生じた特許権等を民間企業等に帰属させることを骨子とした」ものであって民間企業に権利を残すことで産業の発展に寄与しようというものです。けして、所定の書式を出させないで、権利を政府側に持たせようというものではありません。
この時は怒りました。その後、他のお客様にプロダクト展開をしようとする時も権利が会社に残っていませんから、政府側と権利関係の交渉をいちいちする必要になってしまったのです。
当時はお客様との関係から営業判断で提出できないとしたのです、それはそれで仕方のないことかもしれません。
正しく解釈している部門などではこの日本版バイ・ドール条項があると自社に権利帰属するので再販可能と判断するとのことでした。
ちなみに今は９９．９％以上の政府調達はこの条項が入っています。(つまり全部)

つい熱くなって話はそれましたが(怒りポイントなので・・・)
前提条件付きでのOKは前提条件が守られない限りNG(例外付NG)と理解をしてもらった方がいいかもしれませんね。わかるように話すことも必須です。
前提条件に見えるけれども努力目標である場合もあります。ディシジョン会議等では前提条件を努力目標と勘違いされないように努力目標と前提条件を分けて考えることが必要です。
管理職になりますと前記のような事例の他にも前提条件が破られる例は多いので注意が必要です。(人は自分の都合の良いように悪気なく事実を曲げて解釈する傾向にあります。)

4リーダーシップ, PMあるある, プロジェクトマネージメント

コラム：気づきを与える質問

コメントをどうぞ

メンタルコーチング等を習ったことがある人はわかると思いますが、質問によって相手に気づきを与えて能力を引き出すことをします。
こうすることで、相手は考えます。自ら気づくことでその考えや行動のモチベーションが違います。

具体的には質問のみによって行い自分の意見は言いません。でも質問内容で誘導することは可能です。妥当であるかまたは正しい結論に至るように、適切な質問を繰り返していって相手に考えさせるのです。私は純粋に引き出すだけでなく、ガンガン誘導します。

とあるPJでリーダが疲れた顔をしていたので、マネージャが声をかけました
マネージャ：以下　マ
リーダ：以下　リ
マネージャの心の声：(　)

マ「どした？」
リ「人が足りなくて疲れましたよ」
マ「なぜ人が足りなくなるのだろう」
リ「仕事が多いからじゃないですかね」
マ「なぜ多くなってしまうのだろう？」
リ「お客様の要望が多く、その対応に追われるからです」(そうきたか？ほかにもあるがまーいいか)
マ「お客様の要望はすべて聞かなければならないのですか」(優先順位を決めてやればいいじゃん)
リ「意外とくだらないものもあって困っています」
マ「くだらないと思われる要望はどうしたらよいと思いますか」
リ「できればそういうものは対応しないのが良いと考えますが、言われてしまった手前対応せざるを得ません」
マ「要望はどのように管理していますか？」(いや、くだらないとお客様も思っている可能性があって、その場合は、対応をする必要がないか、よほど余力があったらしてくれればよいと思っていることが多い←経験からの意見)
リ「え？課題管理票で一覧管理しています」
マ「対応するものとしないものはどのように区別していますか」
リ「特に区別していませんが、重要度の項目があるといいかもしれませんね、それをもとにお客様と交渉できるかもしれません。でも、すべての課題項目にも重要度を今からつけるのは大変です」(お！項目追加、お客様交渉、それでよいよい)
マ「それはほかの課題には不要なものですか？」(課題管理表に重要度が今までないのはまずいじゃん！入れないつもりか？)
リ「う！確かに必要ですね、項目を追加します」←ちょっと失敗指示された雰囲気になった。

などと話していきます。
この後もながながリーダが納得するまでいろいろ話が続くでしょう。
自分が得意分野じゃなくてリーダのほうが詳しいときなどにもこの方法は有効です。ぜひ使ってみてください。
コーチングや気づきを与える質問の仕方についてもぜひ学習することを勧めます。人事担当者は会社の研修カリキュラムにも入れてください。

5プロジェクトマネージメント技術, PMあるある, プロジェクトマネージメント

コラム：怒る、叱る

コメントをどうぞ

「怒ることと叱ることは違う」、よく言われることですが、整理してみましょう。
怒る場合典型的なのは「ぷりぷり」という感じでしょうか？つまり、怒るのはその人個人の感情の状態で、その行動は、その人の思いや感情状態を解決したいときあるいは、相手に伝えたいときに出る直接的な行動になります。
叱る場合も相手に何かを伝えるという点では一緒ですが、伝えたい事柄が「自分の感情状態」ではなく、「間違いに対する回復」である点で大きく違います。
叱る手順としては、「気づかせる⇒理解させる⇒反省させる⇒行動の促し」となろうかと思います。空き地で野球をして、窓を割った時に出てくるかみなりオヤジ的にやるならば、

①気づかせる「こらー！！」
②理解させる「こんなところで野球をやってはいかーん、窓を割ってしまっただろう！」
③反省させる「何をしたから窓が割れたかわかるな、ごめんなさいは？！」
④行動の促し「もうやるなよ、気を付けるんだぞ」

という感じでしょうか。
叱るときは、何を伝えたいのか、具体的には、どういう気づきをさせるべきと考えるのかを整理して、自分でわかったうえでしかるべきです。
部下に失敗をさせてしまった上司を叱る場合、管理せずに放置していたことを叱るのか、その部下が失敗しないように事前にチェックすべきであったことを叱るのか、失敗したときにその傷口が大きくならないように行動しなかったことを叱るのか、それぞれその管理者が何を怠ったかによってポイントを絞ってしかるべきです。
だいたいの叱るポイントを押さえたら、今度は叱り方ですが、①のところで直接てきにこちらから言うという方法もあります。ほかにも、何が悪かったと思うかコーチングの傾聴手法で引き出す手もあります。自分で引き出した場合、そこには理解もついてきているとよいでしょう、注釈を加えてたとえば「そうだなそこのところが足りなかったな、別な観点でこう見ると、そのことがよくわかると思う。過去にもこういう例があった」などと、理解を深まらせる話をするのもよいでしょう。そのうえで期待する行動をさせるのが良いと考えます。
やってはいけないのは、複数の事柄を抱き合わせで叱ることです、何をしていいのかぼんやりしてしまいます。子供や犬をしつける時のやり方です。人間は大人になったとしても本質的には変わりませんから、やはり、叱るときにはポイントを絞ってもっとも理解させたいことのみをしかるべきです。

「大人なんだから」と思うかもしれませんが意外と重要ですよ。

3プロジェクトマネージャとは, PMあるある, プロジェクトマネージメント

コラム：官公庁・公共系と民需では要件定義の立場上の考え方が逆

コメントをどうぞ

かならずしもあてはまるものではありませんが、官公庁と民間では要件定義の持っていきたい方向が逆になります。
何が逆かというと、要件定義において、ベンダー側のアプローチとして民需ではどんどん機能を入れるようにアプローチをします。しかし、官公庁では機能を減らしていく方向にドライブしなければなりません。
なぜかというと、調達方法の違いに原因があります。
私は民需系のシステム開発経験はないのですが民需では多く、先のコンサルや要件を確認する中でやることを決定していき、やることが明確になった段階で再度見積もりを提出し、協議していく形になります。この時、良い機能やほしい機能がたくさん盛り込まれていれば、要件を削るのではなく、予算を増やしてもらえるかもしれません。
官公庁系の場合、調達は入札になります。完璧に作った仕様書に基づき、それを実現するのにいくらでやってくれるかを入札します。要件定義でこの仕様書項目で具体的になにをどこまでやるのかを協議しますが、やることが増えても費用は増えません。入札で金額が決まっているからです。
官公庁側担当者は、これはこういう解釈だこういうものだと言いながらできる限りの要件を盛り込もうとします。ベンダー側は仕様書からはそのようなことは読み取れない、書いてないと主張して、やることを予算に収まるように極力少なくしようとします。なかなかにお互いに苦しい交渉です。官公庁側もわざとそうしているのではありません。仕様書では書ききれなかったり、その時には決まっていないことも多いのです。官公庁系の場合要件の齟齬で大赤字プロジェクトになることもしばしばです。お客様に合わせた仕様書の読み取り方など慣れていないと危険ですね。

経営者としては無駄な失敗をしないためにも官庁・公共の案件では慣れた人を当てることが重要です。







イギリスの経済学者が役人の考え方や予算のかけ方を解説！本当かウソか、こんな風に国家予算は膨れていく。
政府の働きなど、間違えない政府の考え方を述べています。

PMあるある

隣の芝は青い？転職する？

コメントをどうぞ

「SEは徹夜も多いし、お客様からは無理難題言われる、大変だから客商売でもやろうかな」という話をデスマーチPJで疲れてくるとよく聞きます。どうなんでしょう、ほかの業界に行けば楽になるのでしょうか？
私はあまり変わらないと考えています。忙しい人はどの業界に行っても忙しいですし、それなりにストレスがたまります。

業界を変わる意味合いというか利点は、その業界で受けるストレスが自分に耐えられるストレスであるか？であると考えます。
どの業界にも忙しくない人や忙しい人がいます。忙しい人は多分ですが、ほかの業界に行っても忙しいと思います。いろいろ要因はあると思いますが、まずはその人がいろいろ任されるタイプの人ですと、頼りにされて仕事が増えていきます。仕事の仕方が忙しくなる仕事の仕方である場合もあるとおもいます。あいている時間があると何かをしてしまう人がこれに当たります。どんなことでも一度始めてしまうとやめられなくなってしまうのです。大企業病の「業務ややることがどんどん増えるが、業績下がってもなぜか減らない現象」の原因の一つです。
スーパーに勤めていた時は生鮮食品だったこともあり朝は６～７：００くらいから仕込みを始めて夜１０：００の閉店後片づけをして、次の売り出しの準備(売り場変え)をして帰ると、睡眠時間が４時間とか２時間であることもおおかったです
つまり「忙しい」は転職の理由にはならないかもしれませんね。

PMあるある, ＴＬ－技術力, その他

そういえば：開発技術以外の技術も磨こう

コメントをどうぞ

技術者は開発技術力に頼りがちで、技術者上がりの管理者も開発技術力を重視しがちですが、スキルとしては開発技術だけではだめです。時々、開発技術力のみを根拠としてチームリーダを任せたために、なかなかプロジェクトが完遂しないということがあります。お客様要望を技術力で実現しようとするか、お客様と用語会話が合わず要件定義ができないか、あるいは理想的なコーディングをすることに時間をかけて作業が終わらないことがあるからです。

そういう人は他がまかせられませんから、開発工程から抜け出せず、場合によっては開発工程のみであちこちのPJを渡り歩くことになります。

技術のみ職人にならないように注意しましょう。