(イ) 規模生産性

ステップ数、ライン数、機能数から工数を割り出す手法です。これらの方法をとるためには、統計的にたとえば1000ステップ(1KStep)や1000ライン(1KL)作成するのに大体何時間の工数がかかるかを知っている必要があります。この1KStepあたりの時間が生産性などと呼ぶ組織もあります。単位時間当たりの標準生産量からの比率を生産性という場合もあります。ここでは文字数が少ないので1KLを例に話します。キロライン当たりの時間を基準にする場合「H/KL」という単位で記載します。規模のKLが計算できればこの「**H/KL」を掛ければ何時間の工数が必要か計算できるわけです。求められる工数の単位が「人月」(一人が一月間必要)であるならば一月の時間数(一月は4週間、一週間は5日間、一日は8時間とすると160時間)で割れば計算できます。

ここで気を付けなければならないのは、「生産性は案件によって変わる」ということです。難しければ生産性が落ちますし、開発言語によっても、もとめられる品質などによっても変わりますので、適切に生産性を過去の事例や自分の経験からいじる必要があります。

ここまで規模がわかっている前提で話しましたが、規模の妥当性に関しても精度を上げていく必要があります。これらは(ロ)~(ニ)の見積もりを用いて求めていくことになります。

 

開発工数見積もり手法

見積もり手法は無限に存在します。インターネットで検索してもいろんな名前の付いた見積もり手法が複数出てきます。これらはどんな性質があるか知っておくのは大事かもしれません。インターネットに出てくる手法はその記述だけでは利用することができません。使い方に工夫や、範囲の限定(前提)が必要だったり、統計的な分析に基づく係数の設定が必須であったりするからです。

ご自身の組織の中で使われている手法を分析して、必要な精度が出せるように工夫をする必要があると思います。それぞれの性質と注意すべき事項がありますからそれらに注意して、考慮すべきところを足したり引いたりしながら見積もり精度を上げていきましょう。

IPAなどで見積もり手法の紹介を行っています。そちらも参照ください。

私が思う代表的な見積もり手法を紹介します。

開発工数見積もり手法

規模からの生産性 規模を見積もってから工数にする
経験に基づく機能類推見積もり この機能だったらこのくらいという勘
類似見積もり 同じような開発の工数を参考にする
FP法 データ・入力等の数から工数を計算する
相見積もりをとる 他人に見積もりをお願いして比較する
タスク積み上げ 作業を列挙してそれぞれの工数を積上げる

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

開発見積もり

見積もりは重要な仕事の一つです。これはすべての計画に関わる問題になりますので正確にできる必要があります。
かかった工数だけあとから清算してよいという契約であれば、無駄がないことを証明するだけでよいのですが、通常は実現する機能に対して見積もりを行い、その金額がいくらになるかを提示したうえでその金額で契約となります。見積もりに誤りがあったとしても、お客様の責任でない限り費用の増加は認められません。
ここでいうチームリーダに求められる見積もりは「作業工数見積」です。見積もりには物の原価・管理費・リスク費・作業工数・経費・運用工数・機能外作業・外部委託作業などを積み上げた原価積算による原価見積などもありますが、PMになる段階で学べばよいでしょう。まずは工数見積もりです。工数見積もりには大体、開発見積もりと構築作業見積もりがあります。(ほかにも管理や運用がありますがそれは別途)
工数見積もりの場合「まーこのくらいだろう!」という感じで見積もることも多いと思います。最終的にはそれでいいのかもしれませんが、だめです。
チームリーダとしての見積もりは、実現する機能単位の詳細な積み上げによる見積もりになります。個別見積もりの積み上げですね。
前提条件として、何を作るかわかっていることが必要です。ここに関してはお客様業務をわかっていること、お客様の言葉が理解できること、仕様の行間が読めることが重要です。これらができて初めて見積もることができます。「そんなこと言ったら初めての案件は何も取れないじゃないか!」とおっしゃるかもしれませんが、わからない案件はとらないでください。お互いに不幸になります。
業界の人をPJに入れるとか、類似システムを作ってきた人で構成するなどできないのであればやめるべきです。と!このレベルはマネージャレベルのはなしでしたね。(その案件をとるかの営業戦略だからです。)

開発見積もり手法を紹介していきます。どこぞのマネージメント本やコンサルの言うかっこいい書き方ではありません。
実態としてどう見積もるのかを書いています。わかりにくかったら解説しますので詳細は質問してください。こうあるべきだというあるべき論はあまり書かれていないのであしからず。(個人の見解です)

開発工数見積もり手法
(イ)規模生産性からの見積もり
(ロ)機能分割による見積もり
(ハ)類似類推による見積もり
(ニ)FP法
(ホ)相見積
(ヘ)タスク積みあげによる見積もり

その他見積もりをするうえで考慮すべきこと
スキルレベルの考慮
スケジュール
リスク
見積もり検証

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

職業的PM、たたき上げPM

<職業的PM>

大手のソフトウエアベンダー、SIerにいがちなのが、ソフトウエア開発経験が少ないにもかかわらず、開発プロジェクトの管理をしなければならなくなる人たちです。

悪いことではありません。たくさんの管理経験から開発者上がりにはわからないいろいろな管理手法を実践したり、推進したりできます。今回はそういう人たちとPG上がりでPMを経験する人たちを対比して、経験を生かしたPM像を表現したいと考えています。

中には経験がある人もいらっしゃるでしょうが、大型プロジェクトをやっていると元受(SIerや開発ベンダー)の若い人たちが開発の大変さもわからずに管理をしてきて勝手なことをいうことがあります。
もちろん知らなくても正しく管理はできます。彼らは様々な方法論を学んできており、先輩方や過去プロジェクトの失敗などから分析されたノウハウを身につけています。
しかし、実際に経験したものではありませんから、重要度や真意について理解できていないかもしれません。現場を知っている人間は実態を知っていますから、それ自体が知っていると自信になり、他に対しても説得力が生まれることになります。
とはいえ優秀な人はその点も正しく理解していて、なかなかにすごい管理をしてきます。侮れません。
技術力が不足しているという理由で自ら問題解決等をしなくて、問題点を技術者に投げて解決させるのも良いです、誰にどのような観点で調査をすればよいかなど、経験を生かしたアドバイスや調査、作業の方向性を示すのもマネージメントだからです。
管理慣れしている人はその手の技術も優れています。

<たたき上げPM>

技術力をバックグランドにして上がっていった人達です。こういった技術者からちょっとづつ上がっていった人はたまに、多くは技術に偏りがちで、同じ職位でも役職としてプロジェクトマネージメントよりも専門家としての役割が向いている人も多いです。
そのためにプロジェクトマネージメント技術を学ばなければなりません。
開発だけではわからない管理技術も多いですから、ここでじっくりと、ある程度網羅的に述べて行きたいと思います。

でもプロジェクトを統括するPMに向いていないのではなく、むしろ形だけの方法論にとらわれることなく知識・経験を生かしてプロジェクトを成功へ導くことができる人材になりえるのです。

どうすればいいのか「プログラマ経験を生かしたマネージメントスタイル」を見てください。
まだ書かれていないかもしれませんが気長にお待ちを・・・

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

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

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

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

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

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

料理でストレス発散

仕事が立て込んで来たり、面倒な事柄が持ち込まれたり、わがままを言うお客様や、同僚がいるとストレスたまりますよね。

どのようにストレス発散していますか?
私の場合は手軽に料理をします。
よしながふみ先生の漫画ではありませんが料理をすると結構ストレス発散になります。そういえばNHKで「本棚食堂」というドラマもありましたね。現実逃避を料理に求めるという。すごくよくわかります。

夕飯を作る頻度が高いですが、もっぱらストレス発散で作るのはパンが多いです。いろいろ試行錯誤しながら、自分のレシピを作ったりします。
普通の食パンなどは、選ばれた道具と粉で比較的簡単にできたのですが、ハード系のフランスパンなどはなかなかうまくいきませんでした。
調べてみると、フランスパン等は普通のパンと考え方を変えなくてはならないくらい作り方が違います。別物といっていいでしょう。普通のパンは生地をたたきつけたり(「ダーン!ダーン!!」これがストレス発散に)よくこねたりして、グルテンをつなぐのですが、フランスパンはつなぎません。普通のパンでは私は打ち粉をしないのですが、フランスパンでは大量に打ち粉をします。中身も違いますね。フランスパンでは特殊なのでしょうか?アスコルビン酸(ビタミンC)やモルトパウダーを入れます。
実はまだまだフランスパンは望む領域にたどり着いていません。まだまだ先は長いです。

元はスーパーで生鮮をやっていたので、商品説明のための料理もしてました。肉料理中心です、じっくり時間をかけて調理しておいしくするのが好きです。そういえばパンもそうですが時間のかかる料理が多いですね。

今後いろいろ作りかたも紹介します。IMAG0012

私は婦女子ではありませんが(女子ですらありませんが)よしながふみ先生の「西洋骨董洋菓子店」や「きのう何食べた?」等は好きです。この中には料理で生き生きしたり、夕飯を作ることでスとれる発散になったりする人が描かれています。
漫画の中でも料理物は好きです。今度紹介します。


経験を生かしてプロジェクトマネージャになろう!

経験を生かしてプロジェクトマネージャになろう!

ここでいうプロジェクトマネージャは役割なので、実際の社会ではいろいろな呼ばれ方をすると思います。一例をあげると。マネージャ・エキスパート・プロジェクトマネージャ・アシスタントマネージャ・シニアマネージャ・シニアエキスパート・リーダ・主任・課長・部長などと呼ばれたりします。役職と役割の呼び方は組織によっていろいろだと言うことですね。

< なぜPGからPMになるか>

最近は昇進したくないとか、現場がすきとかでPGのままがいいという人も多いです。それはそれでいいでしょう。個人のキャリアを考えるとき、10年後の自分を想像してみて今、30歳としたとき「40歳になったら自分は何をしているだろうか?」「40才だったら何をしていたいだろうか?」と考えます。今の立ち位置での自分を想像できて、満足であるならば問題ないでしょう。

PMを目指してみるかと思うきっかけはいろいろあろうかと思います。「結婚した」とか、「子供ができた」という事情であったり、「今の仕事に飽きたな」とか、「プログラマをやっているがそろそろステップアップしたいな」とか、「プロジェクト管理の仕事も面白そう」とかそんなのでもよいかもしれませんね。
目指していなかったとしても、やるはめになってしまうこともあるでしょう。「チームリーダをやってくれ」あるいは「このサブシステムをあなたにお願いしたいんだけど」と言われたとか。

・自分にとっての利点
責任と収入は原則として随伴します。したがって、責任が重くなれば、給料も多くなります。

プログラマを経験していることはある意味強みです。開発経験のあるPMは管理において経験がない人とは違う観点世界を持ちえます。それによってきめ細かかったり、「よくわかった」管理をすることができるのです。
今までのように手を動かすよりも頭を使うことが多くなります。進捗が遅れたから人を増やすような作業ではなく、あなたがやらなければ何も進まなくなるという類の役割に変わることになります。

言ってみれば自分をただの工数(人工(にんく))からの脱却です

1)職業的PM、たたき上げPM
コラム:隣の芝は青い?転職する?
2)プログラミングと同じでセンスが必要
3)私はどういう経緯でなったか
4)せっかくなので、戦略的ステップアップをしよう
についての書きます
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

次のカテゴリー
昇進までの流れ

要員の意識を管理する

①モチベーション維持

端的にやる気、のことですが、どのように要員のやる気を維持すればよいでしょうか?これは自分だったらどうするとやる気をなくすのかということを思い返してみてそうならないようにすればよいかもしれません。

人それぞれでしょうが私は、たとえば、「○○をやれ」といわれると、多少無理でもやってやろうじゃないかとおもって士気は上がります。逆に制約事項が多い場合、「あれはやるな」「これはやるな」、「こうするな」というネガティブな行動指示はがっくり来ます。

スーパー時代に一番嫌だったのは「残業するな」でしたが・・・法律上どうしようもないんですけどね・・・

動機づけ

要員のモチベーションの維持で一番利用するのは動機づけです。いやなことをさせる場合、それに関する別のミッションを与える方法です。

「○○PJの手伝いに行ってほしい」という場合、「このPJでは○○が起きているので、このように支援が必要になっている、その原因はここらへんにあると思っているが実のところどうであるか、どうすればそのようにPJがならないようにできるか学んできてほしい。」といって送り出したり。人事異動においても「この組織ではこのようなPJが立ち上がろうとしていて、こういう人材が足りなくなっているから、君を選定した、このPJはこういう性質があるからこのようなPJの場合の○○を学んでほしい」などといいます。

あるいは、状況を説明して自分が何をやらなければならないか全体の中のどの役割を果たすのかを説明して、納得して遂行してもらう方法があります。

「君にはこういう期待をしているのでこういう役割をしてほしい」「あの組織は何がいけないと思う?どうしたらいいと思う?フムフム、それを実践してみないか?」「いまこの分野の事業状況がこう、これからここは伸びると予想されているので、こういうアプローチで伸ばしていきたい、その役割を担ってくれないか」
など、いろいろ考えてみてください。

②モラールの維持

人によって意味は違うようにとらえるでしょうが、私はモラールをその会社・組織に対する満足度・忠誠心?をベースとした勤労意欲のことととらえています。短期的なモチベーションと違う意味で話します。

これには、組織上の仕組みが不可欠です。コンプライアンスをないがしろにする組織ではモラールが低くなることは避けられません。

③コンプライアンス意識の維持

永遠の課題とも言えますが、これらはそういう職場の雰囲気と考えるとよいと思います。つまり、個人の問題ではなく組織の問題です。
誰も最初から「不正をしよう」等とは思っていません。そのうえで不正をしたり、法令違反をするのはその組織の風潮が違法行為をせよ、と言っているからなのです。

コンプライアンスについては別章をたててじっくり語る必要がありますが、ここでは簡単に話します。

不正を語る上ではそれぞれ、心理が違うことを理解する必要があります。

個人の利益のための不正・組織のための不正
法令違反・内規違反・迷惑行為

などです。組織のための不正が一番厄介で、自分の利益のためにやっているわけではありませんから、自分を許しがちですし、組織も見逃しがちです。
管理職として一番注意すべきは、組織のための、法令違反・内規違反です。

普段から会社全体で、やりにくい雰囲気、しない雰囲気を作り出すことが重要で、間違いなく、管理層、経営層の責任であります。

個人の利益のための不正、迷惑行為などは誰が見ても悪いことですから、ある意味管理しやすいです。それこそ、教育、雰囲気作りが最も効果を発揮する分野です。

リーダーシップ:強引にぐいぐい引っ張る型

組織作りをして、人に領域を任せるが、気になるところやトラブルとなると指揮権をとり、自分中心に推進していくタイプ。
うるさ型であれこれ言うため、自分なりに進めたい部下とは合わないことが多いです。何となく部下全員からは慕われている場合は、いざという時に頼りになることが多く、困ったときには大変助かることが多いです。
一方、トラブルがなく問題なく進めようとしているときであると、小さいことも大ごとにしてしまうこともあり、面倒くさい上司という風になることも多いです。
問題ない段階ではあまり能力が発揮できません。大きなトラブルがあると途端に生き生きしだします。トラブルのときは往々にして、現場はどうしていいかわからず、目の前のトラブルをモグラたたきでつぶしていくことに忙殺されます。そんな中でこの手のリーダは細かいところは見れませんが、大局的に現象を把握して強い決断力を持って対策を打っていきます。トラブルのときは時に無理と思われるようなことでもしなければならないことがあります。空気を読まずにバシバシ支持することは事態終息に向けての最短距離であることも多いのです。(冷静なタイプから見ると「勘弁してほしい」と思うことも多いのですが・・)
個性が強いリーダは上位上司がうまく適材適所に割り当てていくことが重要ですね。

似たようなタイプで、威張りたがり屋型がいます。このタイプはだめな感じの人でただ威張りたがっていて、指示はするが、内容おかしかったり、一貫性が無かったりします。うまくいかないと言い逃れをし始めるのもこのタイプです。
見分けるポイントは周りから本当に慕われているか否かが一番です

責任取るから好きにやりなさい

 責任を負うことは、任せきることではない

「わたしが責任をとるから好きにやってみなさい」という発言がドラマなどでよく聞きますが、どうなのでしょうか?

部下にしてみればうるさいことを言われず好きにさせてくれる人は理想でしょうが、権限を越える調整もあるでしょうし、権限内の遂行でもうまくいかないことがあったら困ります。

責任とは何かあった時に謝罪することではなく、結果を成功に導くこと。成功に導けなければプロジェクト管理における責任を果たしていないということです。形上の責任しか問われない組織であれば、だれが謝罪するかという話になるでしょうが、実質的には本人が何をしたかが責任を果たしたかの判断の要素になります。

そう考えると「わたしが責任をとるから好きにやってみなさい」という発言は、丸投げのことではなく、方法論ということになります。

「わたしが責任をとるから好きにやってみなさい」の方法論として、私は2つあると考えます。

①本当に任せる?

場合によっては無条件に好きにさせることがあります。これは任せる相手が自分の責任範囲を理解して行動することができ、その権限を利用して問題なく業務が遂行できると判断された場合です。その場合も報告と相談は常に受けて上司は掌握をする必要があります。これができる人物はかなり優秀で次に自分の代わりに任せることができる人であることが多いです。

②実はコントロール?

単にうるさいことを言われずに好き勝手やりたいだけで報告も上げない者にはここまでは好きにさせることができません。ある程度どのようなことをやるのか計画を詳細にレビューして修正し、合意した内容を遂行させる範囲で好きにさせる場合があります。

その場合は上司としては、本当はいろいろ口出して計画を修正させているが、本人が自ら修正して問題ない計画を作ったように感じさせて、任せるというのが理想です。

気づきを与える質問等で誘導します。

この場合は十分なコントロールの下で行動させることが重要です。

いずれの場合も任せるといっても常に報告を受けて十分に内容を把握しておくことが重要です。責任を負うということは最終的な成果物や行動においては自分が判断したという事実上のハンコを押すことなのです。

まー私は「わたしが責任をとるから好きにやってみなさい」などとはめったに言わないですけどね。