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

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

PM:プログラミングと同じでセンスが必要

プログラマー経験があるとわかりますが、プログラミングってズバリセンスですよね。
センスが良ければ時間をかけずにそこそこのコードが書けるようになります。経験を積むと、人に迷惑をかけないソースが書けるようになって、さらに経験を積むと人のソースをみて、相手の考えていることがわかるようになりますよね。
PMも同じです。かなりセンスが要求されます。同じように経験を積むことでいろいろな管理方法論が確立されていって、怪しいところが犬のように臭いでわかるようになります。

いろんなPJをいろんな立場で経験していると、「その時どう考えていたかな?」「こういうことはありがちだな」などと思ったところは必ず記憶しておいて役に立てます。PG経験があるとPGの気持ちや落とし穴をよく知っていますから、管理するときでも「実はこういうことなのではないか?」という話ができてPJの真のもん亜ぢ店を明らかにして対策を打ったり、課題管理においても「この問題の解決策としてはこんなことがある」あるいは「この観点で調べるといいかも」などとアドバイスができたりします。(問題解決自体はマネージメントの仕事ではないのですが・・・)

たたき上げの嗅覚で対策した例を示します。
良い例かどうかはあれなんですが・・・

①必死のバグつぶし、バグは直っていくが・・・
②データの受け渡しの無駄
③バグを隠しているのではないか

これらについて述べていきます。
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

コラム:怒りポイント

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

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

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

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

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

3プロジェクトマネージャとは

サブシステムリーダまでで語られた技術などを身に着けるとプロジェクトマネージャーになれるのでしょうか?
いえいえ、「ただのプログラマー」を脱出しただけです。「では、どうしたら!」まずはプロジェクトマネージャーってどんなものなのかを知りましょう。

ここでいうプロジェクトマネージャは一人かもしれないし複数の人で構成されるかもしれません。
大きなPJになるとプロジェクトマネージメントチームというのを作ってプロジェクトマネージャとしての役割を果たしていくことになります。
その場合でも統括責任者としてのプロジェクトマネージャは存在しており、全体の意思決定を担っていくことになります。

(ア) 顧客と直接対峙してプロジェクトを推進していく
(イ) プロジェクトマネージャのいろいろ
(ウ) 上位からマネージャに期待すること
(エ) 自立鼓動と、適切な報告
(オ) 商売!(我々はアスリートでもボランティアでもない)
(カ) 使えないマネージャとは
(キ) マネージャは「たいへん」か

についての書きます
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

考慮:見積もり検証

必ず行ってください、間違ったら取り返しがつきません。自分で何度も見直すことも重要ですが、ほかの人と比べる、ほかの手法と比べることをしてください。

見積もりが違ったら、その原因を探る、難しさの見積もり誤りがあったり、見積もり漏れがあるかも知れません。

できれば、主観的見積もりと客観的見積もりをくらべ食い違いがあった場合に規模、生産性、見比べて差の原因を探ってください。何等か見落としや前提条件の思い込みなどがあるかもしれません。

不安がある場合は、その分をリスク費として原価に追加しておくことも必要です。

ただし、不安だからと言って見積もりを膨らませるとそもそも受注できなくなります。

連休なのでこの辺で・・・

考慮:リスク

見積もりにはすべて前提条件があります。それらが崩れるとき見積もりはずれます。お客様が予想に反してわがままだったり、行間にものすごい仕様が隠れていたり。この不測の事態に対しても見積もりは必要です。リスク管理です。

チームリーダレベルでは権限範囲の①想定リスクをあげて②何等か対応をしておき③リザーブを確保しておくことが必要です。

  1. リスクには想定できるものと想定できないものがありますが、想定できるものについては、リストアップしてどうなった場合に何が発生してどれほどの確率で発生するのか、どの程度の影響が考えられるのかを列挙しておきます。
  2. 対応としては、許容する場合を除き、何等か対処をして発生確率を減らしたり、危険をなくしたり、発生してもいいようにします。
  3. 発生をしてもいいようにとは、何かあった時のための費用を確保しておくということです。プロジェクトマネージメントリザーブなどとも言います。

リスクを上げると、それを回避するために何をするのか決めなければならない風潮があったりしますが、リスク対策は「リスクファイナンス(お金を確保する)」と「リスク予防対応(起きないように何かする)」「許容(リスクが発生してもあきらめる)」などがあり、明らかにしたうえで分析をし、リスクを許容することも対応の一つです。

考慮:スケジュール

スケジュールは見積もりを左右する重要な要素です。実際にはやることがスケジュールに反映されますから、それらを行う工数が見積もりから漏れていないか、それらのスケジュールの前提となる条件整備の工数が見積もられているか。

無理のない長さのスケジュールになっているか。最適な生産性を生む期間から短くする場合はその分のオーバーヘッドを考慮した見積もりになっているか。期間に人を割り当て、その人をその期間に確保できるのか。などを考慮します。

そのためのいろいろなツールもあります。WBSや人積表などがそれに当たります。

結果的には妥当性のある見積もりには妥当性のあるスケジュールも一緒についていないと意味をなさないのが一般的です。計算で出す工数は限定的な作業しか入っていないうえに最適な生産性を出す期間がいただけることが前提になっているからです。

最適な生産性が出せる期間(この期間は開発内容チームの実力によって変わります)より短く期間が設定される場合目に見える形で工数を増やす必要があります。

考慮:スキルレベル

スキルレベルの考慮

(イ) 自分だったら
常に自分だったらどれくらいの工数でできるだろうという感覚を持つといいかもしれません。「この仕様だったらこれくらいかな?」とか見積もりは必ずします。記録に残し最終的にどうであったかを検証し、自分の見積もり感覚を磨いてください。勘を養うのです。

(ロ) 人のスキルレベル(生産性)
自分だったらこれくらいというのがわかれば、今度は自分以外の人がやったらどれくらいになるかという話です。そのためには要員スキルと仕様内容を正しく理解する必要があります。そのうえで、その人だったらどれくらいになるだろうかで見積もります。見積もる上でその人にヒアリングしてもいいと思います。ただし、その内容は原則信用しないし、採用しません。あくまでも自分で見積もります。
その人に見積もり等を聞いた場合でも自分の言動に対する責任を持ってもらう範囲でその結果を利用します。

見積もりをするうえで考慮すべきこと

以上の見積もり手法を駆使して見積もりをするわけですが、同じような見積もりでも業界やお客様によって見積もりの結果が変わります。
たとえば官庁系見積もりなどではサーバを一台構築して立てる場合(開発なしで構築のみ)でも結構かかります。納品物、試験等がたくさんあるためです。
一方、研究所などのスーパーコンピュータの構築、たとえばLinuxサーバを1000台単位で入れるわけ(1000ノード)ですが、1台当たりの構築はその1/100程度の工数で行います。構築手法が違うからなのですが、それでも納品物、要件的義とかの客先対応などの文化(前提条件)の違いからくるものが多分にあります。それぞれ人を入れ替えて見積もりさせるととんでもないことになります。莫大な工数になり受注できなかったり、過少見積もりになり、客先要件を満たさず納品が完了しないなどがおきます。

また、開発方法の工夫や、ミドルウエアの利用で生産性を上げることができます。共通チームのようなものを作り、いろんなところで使われるモジュールはライブラリ化してそれぞれで開発しなくていいようにしたり、仕様を単純化して難しくない実現方法に誘導したり、フレームワークやミドルウエアの利用は普段から行っていると思います。皆さんもこの点はいろいろな工夫を持っていると思います。それらを駆使して工数を減らします。

その他、考慮すべきこととして
スキルレベルの考慮
スケジュール
リスク
見積もり検証

があります。リンクを参照ください。

(ヘ)タスク積み上げ(WBS積み上げ)

作業を細かく分解してそれぞれ単純に何をするかイメージがわくレベルにして、そのするのに必要な工数を積算していきます。
ここで重要なのは「実際に何をするかイメージできるレベルまで作業を分解する」ということです。
この方法は開発外作業(研修教育など)・構築作業などの見積もりで使います。根気のいる作業ですが地道に行っていきます。

WBSを作るという作業は例の変な表を作ることではないことを知っておいてください。「作業を分割してイメージがわくレベルにすること」です。
細かく分解すればするほど工数が大きくなる場合があります。これは作業の分割単位と見積もり単位があっていない場合におきます。

単位が「月」であった場合最少は1M(月)になってしまいます。1W(週間)でできるタスクに分解した場合に最少の1を入れてしまうと3W(週間)分120H(時間)のずれが生じることになります。
作業単位が「D(日)」単位で終わるようなものであればH(時間)にすべきです。一つ下の単位を設定して見積もってもらいます。
単位をM(月)のままで0.1とかやめてください。0.1M(月)は2D(日)です(160時間前提)当該作業が2日間=16時間かかるのかの考慮をするのが嫌になり、妥協することがあるからです。
見積もり精度、分解粒度に合わせて単位を適切に設定してください。
見積もり妥当性を見る場合は、単位に応じた見積もり精度を前提にレビューすることになります。(つまり細かくすればよいものではないということ、余計な突っ込みを受けます。)
部分見積もりの妥当性が無ければそれ以降も見積もり検証をする意味がないと判断され、再見積もりになりますから注意が必要です。

(ホ)相見積

自分が見積もったものと、自分以外のチームメンバの見積もり、あるいは別手法で見積もった内容を比べます。
できれば、主観的な見積もり(勘など)と客観的見積もり(FP法など)を出すのがいいかもしれません。同僚とか、社内のほかのチームとかに頼む手があります。協力会社の方(下請けさん)に開発をお願いする場合は自分の見積もりと協力会社の方の見積もりを使うのがよいでしょう。

協力会社の方にお願いするとき、注意すべきなのが発注する気がない場合、相見積であることを協力会社の方に伝えてください。彼らは見積もりをお願いすると場合によっては受注できるものと思い込んで人を増やしたり準備を始める場合があります。そもそも発注する気がないのに見積もりをお願いすることはナンセンスなのですが・・・
コンペの形式をとってもよいと思います。もし、他社より条件が合えばお願いすることを前提にお願いするべきです。

協力会社の方に損をさせたり損害を与えたり、信頼関係を壊すようなことが無いように慎重に行動してください。