カテゴリー別アーカイブ: プロジェクトマネージメント

プロジェクトマネージメントに関するカテゴリーです

①意思決定ができないことで悩んでないか

中間管理職の悩みがあります。
下からは「どうしたらいいんですか?」上からは「どうなっているんだ!どうするんだ!」時には「意思決定はどうなっているんだ!」と突き上げられることがあります。
でも、判断できないことも多いです。どうしていいかわからないから「こうしなさい」といえない、悩ましいです。

なぜ意思決定できないのでしょうか?
その事柄に詳しくないためどうしたらどうなるかがわからない。選択肢のデメリットを考えるとどちらがいいとは言えない。一生懸命考えようとしても頭が働かない。そもそも、何をしたらいいかも選択肢が思いつかない。解決すべき課題に対する問題点がそもそもわからない。
どれもよくあります。意思決定できる?人からは、管理者が悩んでいても「何でこんなことで悩んでいるんだ?さっさとすればいいのに」みたいに言われます。これもプレッシャーになります。(だってどうしたらいいかわからないんだもん)
非常に気持ちはわかるのですが、何等か行わないと、この事態から脱却できません。

(イ) 丁半博打で決めるのはNGです
(ロ) 情報が足りないなら聞けばいい
(ハ) コーチングのふりをして聞き出す
(ニ) 利益衡量をする
(ホ) 何等か自分が納得のいく理由をつける

(キ) 意思決定

管理職になりたてのとき、結構どうしていいかわからなかったりしました。

できる人は悩まないのでしょうが、意思決定はなかなかにストレスのかかる作業です。この決定が複数の人たちやPJを左右するからです。リーダーシップ研修などでは「これをすることがリーダーシップだ!」という感じでぐいぐい引っ張っていくことを無条件に要求しますが、では何が正しいのか?どう判断したら正解なのか誰も教えてくれません。「かっこいいのはズバリ判断することだ」といわれても困ります。

そんなに経験があるわけでもないのに、重要な判断について、「どうしたらいいか?」「どうするのか」「方針は?」など始終あらゆる人から詰められてしまいます。

私が実践してきた方法を紹介します。

① 意思決定ができないことで悩んでないか
② 腹をくくれ
③ 自分で手におえないと判断したら

(ウ) 原理原則(決められたプロセスを実施する)

原理原則を守ることは重要です。ここでいう原則はプロジェクトマネージメントにおける当たり前にやらなければならないことです。プロジェクトマネジメント知識体系ガイド(PMBOK)等に書かれている事柄はすごく大仰なことが書かれています、真面目にやろうとしてもできそうにありません。
無視してなし崩し的にPJを進めていく、というのも方法としてはあります。
能力のあるPMが小規模PJにおいて、すべての人に自分自身で指示を出してすべてを把握している場合は、好きに自分のやり方で進めるのもいいでしょう。

PJが大きくなった場合、規模が小さくてもPMがスーパーマンでない場合はその方法は絶対にダメです。
一例をあげると小規模開発者から、上がっていった人にありがちですが、PJ推進において必要な、プロジェクト計画書の作成、プロジェクトキックオフの実施、規定類の整備などを軽視して、不要なものと判断して、作らないことがあります。
これはよくありません。要員が自分の手足ならばよいですが、少なくとも自律的に動くことを期待するならば、PJが行く先を共有することは必須です。
PJ計画書というと大げさですが、中身は何かというと、いろいろありますがおもなものは、PJがどんなものかの「概要」、何のためにやるかの「目的」、いつまでにどのやり方でどの順番でやるのかの「スケジュール」、だれが何をやるか誰と絡めばいいかの「体制」、どこで何をつかってやるかの「環境」や、推進するための会議をどうするかの「コミュニケーション計画」。などが書かれたもので、各機能を持った人が集まってできるのがPJだとするならば、あらかじめ伝えておかなければならないことが書かれたものなのです。
「プロジェクト計画書」などとかっこいい冊子になっていなくても場合によっては紙一枚でも構わないのです。実はいらないと言っている人も作っているか、ばらばらでも作る羽目になっていることでしょう。

案件によっては調達仕様書に必要事項が書かれている場合や、客先PMOから求められる場合があります。

このようなPJ計画書に限らず、PJ推進プロセスにおいて必要とされていることは実態としても必要で組織にPJ推進に関するガイドライン等が設定されているならば、その存在意義、意図を踏まえて実効的に実施すべきでしょう。(形だけ意味のないものを作るなら時間の無駄なので)
ちなみに、物事の存在意義、意図を読み取り、理解する力も能力として必須です。(斜に構えるだけでは何にもならないという意味ですね)

形だけの作業を省く件については、きちんと本来的な意味を理解して、その作業の存在した理由を理解し、それがほかの方法で担保されているときに限り省くことが可能であろうと考えます。
くれぐれも勝手に無駄と聞けつけてやるべきことをやらないことはしないでください。

(イ) 強い意志

これは頑固であれという意味ではありません。強い意志とはやりきる意思といってもいいかもしれません。

途中で投げ出さない、へこたれないということです

一度決めたら曲げないということもありますが、曲げないのは基本方針「やりきる」というところにすべきで、方法に関しては、「やりきるために」柔軟に変えながら進めていくべきです。(「改善)、「イノベーション)ともいう)
実行レベルに近い決定事項を守り、状況を無視してかたくなにやり続けると、組織がおかしくなってしまうこともままありますので、「やりきる」ことを重視し、「そのためには何でもする」という強い意志が必要です。

プロジェクトには絶対に何らかのトラブルが発生します。発生しない物はありません。キーマンの病気や事故といったどうにもならないと思えるような外的要因が発生するかもしれません。突然の無理な仕様変更要求が来るかもしれません。虚偽報告によるサービスイン前の受入試験での実はプログラムが何もできていない事件が発生するかもしれません。

その時にくじけることなくやりきる能力が一番最初に、絶対に必要なのです。

身に付けるべき基本的なスキル

自分自身のパーソナルスキルの側面と管理技術的な面があります。両方重要で、特にパーソナルスキルの部分は、下手をすると、ひたすらコンピューターに向かってプログラミングしてきた我々にとっては苦手とする部分かも知れません。わかっていることと実践できることは違いますが、それが顕著に出る部分でもあります。とにかく勇気を持って頑張る必要があります。
一方管理技術はというと、管理されることはあっても管理側としての意図意味が分かっていないため、相当に意識しながら勉強する必要があるかもしれません。

今までの経験があるから何とかなるだろうという甘い考えではだめです。

間違いなくこれらの技術の勉強は必要です。ここではどんなものであるかの紹介をします。
とはいえ具体的な方法論もNaOHKI説での展開を時間があるときに追加で述べさせていただきたいと思います。

他のものの本にあるパーソナルスキルという用語とは少し違う解釈になっていることはご容赦いただきたいのですが「(イ)強い意志」から「(キ)意思決定」までがパーソナルスキルでそれ以降が勉強と経験で身につく管理スキルです。

(イ)強い意志
(ウ)原則論(決められたプロセスを実施する)
(エ)コミュニケーション能力
(オ)交渉力
(カ)方針決定
(キ)意思決定
~ここで別れる~
(ク)リスク管理
(ケ)品質管理
(コ)要員育成
(サ)課題・問題管理
(シ)レビュー
(ス)必要な知識

こうしてみるとわかるように精神論的なものが最初に多いように感じるかも知れませんが、これが意外に重要です。
これらのパーソナルスキルがないと知識だけあっても人を率いていけませんし、圧力に負けて心が折れてしまうことも多いです。

まずは一般的な話から。

5マネージメントスキル

SEの気分のまま、経験だけでそのままPMにあろうとすると、いわゆる顧客のためにシステムインテクレーションを行うプロジェクトで、管理を徹底することを要求される場合は通用しないことがあります。

どのようなスキルが必要で、自分が開発するのとはどう違うのか簡単に触れる

実際のPM技術に関しては、それ専用のものの本(PMBOKとか)を参照してください。

――(ア)身に付けるべき基本的なスキル
――(イ)強い意志
――(ウ)原則論(決められたプロセスを実施する)
――(エ)コミュニケーション能力
――(オ)交渉力
――(カ)方針決定
――(キ)意思決定
――(ク)リスク管理
――(ケ)品質管理
――(コ)要員育成
――(サ)課題・問題管理
――(シ)レビュー
――(ス)必要な知識

について書きます
例によって時間があるときに書きますのでのんびりお待ちください

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

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

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

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

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

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

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

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

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

プロジェクトマネージャのいろいろ

ここでいう「いろいろ」はいろいろな管理手法のことではなく、いろんな役割を持つPMがいることを話します。
これらのマネージャは組織やどんなプロジェクトであるかによってあったりなかったりします。どれが偉いとかというものはありません。規模に応じて組織や役割を分割統合して責任を果たせるようにするものです。つまり広くすべてを行うか分割して少しづつ担当するかの違いになります。

① 与えられたプロジェクトの遂行のみをするマネージャ
案件が持ち上がったらその都度ごとにプロジェクトマネージャを選定しそのプロジェクト全体を遂行してもらうタイプのマネージャです。大抵の場合、営業部門か上司が仕事をとってきて、それを人に割り当てていく感じで進めていくタイプです。
ある意味イベントドリブンで、PJの遂行に責任を持ち、与えられた範囲内で成功させていきます。
ソリューションベースの特定のノウハウや技術を元にそれに関するプロジェクトを遂行していくマネージャにこのタイプが多いですね。
ここでイメージしているタイプは1PJ1マネージャ程度の規模のものを想定しています。技術者上がりのマネージャはこのようなタイプの仕事が向いているかもしれませんね。

② パークを与えられ、営業戦略を含め策定していくマネージャ
特定のお客様や業界を自分のパークとしてその中での様々なお客様の課題を解決していくタイプのマネージャです。あるパーク(市場)を担当として与えられていますから、その行う範囲は各PJの成功のみならず、そのパークでの事業の拡大が入ります。大抵の場合範囲を与えられると一PJではありえませんから、複数のPJを並行してみていくことになります。
そうなってくると部門の管理的なもので、複数のリーダを使って複数のプロジェクトを管理することになります。規模によって、マネージャと呼ぶのか部門規模であれば部門責任者ということになるのでしょう。
複数プロジェクトを並行して管理していく技術が必要になります。組織作りの技術が強く要求される立ち位置ですね。
ここではパーク(市場)を範囲として与えられるものとして書きましたが、ソリューション(技術・製品)という範囲もあり得ます。同じように、そのソリューションを利用する複数のお客様のPJを管理する必要がある場合もあります。あたえられている「範囲」の概念が違うだけで同じ話です。

③ 巨大プロジェクトの一部を担い責任を果たしていくマネージャ
大きなプロジェクトとなると一人では管理しきれなくなることがあります。その場合、複数のマネージャに役割を分割して管理させることがあります。
開発と基盤と運用とQCD管理に分けて、それぞれマネージャが付き、その上にさらにプロジェクト統括責任者(これは部長だったり・マネージャだったり)が付くことが多いです。
それぞれマネージャはメンバーを持って行動しますが、実態はプロジェクトマネージメントチームとして行動することになることが多いです。
サブシステム事態が巨大である場合、サブシステムを管理職が管理することもあります。この場合は、そのサブシステムの専門家であると同時に、サブシステムをPJと同じにとらえ、その中のQCDをはじめとして、人材育成・人事管理等も範疇として行っていく場合もあります。

あなたはどれになりたいですか?

ほかにもPJタイプでの分類もあります。

用語説明:パークとソリューション

私はどういう経緯でなったか(2/2)

・サブシステムを任される
システムにはサイクルがあって、定期的にリプレースが必要になります。(HWやソフトウエアの保守期間が切れたり、業務が時代に合わせて高度化するから)
そんなリプレースのときに一つのサブシステムを任されてサブシステムリーダになりました。
この時はメンバーを3人にして私入れて4人でチームを作りました。運の良いことに優秀なプログラマが一人入っていたのであとの2人は2年目程度の人でもなんとかなるだろうとふんでいました。そのサブシステムはメンテナンスをしてきたところであったので、中の構造はすべて把握しています。最初に作られていたのがぐちゃぐちゃだったので、リファクタリングしたのです。
ほとんどの設計は私がすべて実行し、共通部分、難しい部分のコーディングを優秀なプログラマ(設計とかのドキュメンテーションは不得意)にひたすら作らせます。
その作られたフレームワーク上で2年目たちに機能を作りこませたのです。概要設計までは私で行い詳細設計以降を任せる感じです。
後から聞いたところでは、初回とは比べ物にならない生産性だったそうです。
今から思うと普通の開発ではできない手法でした。(一般化できないという意味)

・管理をサポートする
そのかいもあって管理サポートをするようになり、管理チームに参加する様になります。見積もりの精査や品質管理、課題管理などの技術面を中心にサポートをしたのです。見積もり精査は、見積もりに対して、勘違いしているところはないか見落としているところはないか、妥当性を欠くところはないかを見ました。品質管理はバグが入り込む原因を分析して対策したり、直らないバグに対して助言を与えたりしました。課題管理は、課題に対して複数の解決方法がある中で最適なものを提案したり選択したり技術面の裏付けをとったりしました。

・専門家として参画する
別の案件では技術の専門家としてPMをサポートする立場(ITアーキテクト)で、システムの全体設計を行いました。基本設計までは私が行い、みんなに伝えて、サブシステムごとに概要設計から実施していただくという方法をとりました。
マネージメントをするマネージャーがいたので、その部分は任せて、システムアーキテクチャの策定、技術問題の解決に専念できたのでした。

・PMとして参加する
その後のプロジェクトではマネージャとなってシステム全体の開発構築を行いました。

何となくきれいな段階を追ってPMになっていったように見えますね。当然細かいところは省いていますから、真実ここまできれいではありませんが大きな流れとして、参考にしていただけたらと思います。

私はどういう経緯でなったか(1/2)

実際にはいろいろ紆余曲折はあるものの美しく並べるならば以下の通りです

・サポート要員としてまずはPJに
サービスインしたプロジェクトの残件対応としてこの業界に入りました。サービスインしたといっても問題は多く、バグも大量に残っていましたのでそれらを何とかするのが役割でした。

・いくつかの問題を解決
当時は派遣社員でしたから1月以内に成果を上げないと切られてしまいます。
最初の2週間は仕様書設計をひたすら読みました、早く何らかの成果を出さなければならないのに1000P以上あるあるサブシステムの設計書を渡されたのです。読み終わったことを報告して、障害一覧の中からプライオリティーの高いものから支持を受けて修正しました。
何とか1月以内に1つの修正物件をリリースすることができました。そこからは片端から修正です。

・他のサブシステムの問題を解決
サービスインしていますから使っているときのバグは重大障害として問題になります。大きなものになると担当者全員を集めて緊急対応することになるのです。
そんなことで客先に集められたのですが、たまたま私のいた作業場が近くであったため、先について、その時の責任者から簡単なサブシステムの説明を受けた後、障害調査をしたのですが、運よくすぐに原因が分かったのです。その時はまだ担当者が来ていなかったため、修正内容の案とその影響調査しながら待っていたのです。運が良かっただけなのですが結果的には担当者より早く対応したという結果だけが残りお客様の印象に残る実績となったのです。

・改修案件をやる
システムが安定してくると、今度はシステム変更案件なども入ってくるようになります。変更ですから、見積もり(どれだけ時間がかかるかを言うだけ)をして、受注できたら、それを実行する。というものです。

・大きな改修案件をやる
それらの改修案件をこなしていると、大きな改修が入ってくることもあります。そうなってくると一人ではできませんから、人を入れてやることになります。自分だったら何時間かかるというものはありましたが、ほかの人がそれだけの実力があるのかわかりません。同じくらいだろうと見積もって、ちょっと安全をみてまったくみんなが使えず自分が一人でやっても何とかなる期間と人数を報告してやりました。
当時は資格試験の受験生でしたのでパートタイマーのチームリーダーだったのです。2人いれて3人でやったのですが、私よりは経験が長い人たちでしたが生産性は半分程度であったと記憶しています。困ったら相談してくれと言ってあったのに一つのバグで丸一日悩んでいて、声を掛けたら相談してくれたのですが、単純な話であったためにすぐに直ったのです。悩まずに相談してくれたら1日(8時間)は無駄にせずに済んだはずです。といようなことがあるということを学びました。

ここまではシステム保守段階の話です。
ここからリプレース開発の受注後の開発を担当する話になります。