NaOH-KI のすべての投稿

チームリーダー, プロジェクトマネージメント, 開発工数見積

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

コメントをどうぞ

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

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

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

チームリーダー, 開発工数見積

(ホ)相見積

コメントをどうぞ

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

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

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

チームリーダー, 開発工数見積

(ニ)ＦＰ法

コメントをどうぞ

ファンクションポイント法といわれる手法です。おもに、WEB画面系のDBを使った単純な業務画面の作成を見積もるのに適しています。
係数が多く、ご自身の組織で使われており、ツールがあり、統計情報が集まっていないのであればちょっとハードルが高いかもしれません。
使う場合はご自身の組織のマニュアルを参照されることをお勧めしますのでここではあまり説明しません。

いろいろＷＥＢ等から探すと概略がわかるのですが、ちょっと使えないと思います。なぜか。
FP法はたくさんの係数を持っています。これらの係数は各PJに応じていじられるものです、わからないからとデフォルトで使うのはやめてください。つかいかたがわからないのであれば、必要な精度で見積もりを成功させている経験者の指導を仰ぎながらやってください。安全方向に倒しながら見積もりをすると、このFP法は最終的な工数が莫大なものになります。小さな係数の影響が最終的に大きなものになる可能性があります。(イ)機能見積もりと比較して莫大な工数になることもしばしばです。ご注意を。

チームリーダー, プロジェクトマネージメント, 開発工数見積

(ハ)類似類推による見積もり

コメントをどうぞ

前に似たようなものを作ったことがあって要求内容やレベルが同じであるならば、おなじ規模や工数でできるはずです。
これに違う部分を考慮して増減させたり、別手法で計算した規模を足すことで見積もることができます。

過去に同じような開発をやったことがあることが前提ですが、これは自分でなくてもよく、ほかのよく知っている人や組織で行った頃があるのでも良いです。
ただし、この参考にする元見積もりは、よく理解することが必要です。ヒアリングをして、実態はどうであったのか、今回の例と違うところはあるのかないのか、お客様の性質はどうか？全体が使えなかった場合部分で参考にできるところはあるかなど冷静によく考えます。

この例で失敗するのは前提条件やお客様の性質が違い、本来参考にならないのに参考にした場合や、実態が報告と違い、うらで相当苦労をしていたり、裏ワザを使っていた場合などがあります。
自分の経験でない場合は詳細なヒアリングを実施して参考にするようにしてください。
不確定要素は必ずリスクへ・・・

チームリーダー, プロジェクトマネージメント, 開発工数見積

(ロ)機能分割による見積もり

コメントをどうぞ

この機能だったらこのくらいという勘です。経験がものをいう見積もり方法ですから、このお客様でこのような開発をしたことがあって十分な経験があり、信用できる人がすべきです。お客様を経験したことが無かったりこのようなシステムを開発したことがなければ、求められる内容が違ったり、余計なことをさせられたり、いつもはこれでよかったはずだったり、うまく実現できなかったり、必要な機能が基盤になかったりして、見積もりが大きくぶれることになります。

正直言うと、個人的には、何を作るか正確にわかっており、このお客様でこのような開発をしたことがある信用できる人がいるならばもっとも正確な見積もりであろうと思っています。

実態はベテランによる勘です

これはチームリーダのときに絶対にできるようになってください。将来、PMになった時に見積もり妥当性を見極めるスキルにつながります。

この勘を経験により養うことは非常に重要です。偉くなればなるほど、大きな、あるいはたくさんの広い範囲を見る必要が出てきますので細かく見る時間はなくなります。
この時重要なのが勘です。勘は　ヤマ勘ではなく、経験(統計)に基づくレベル意識です。「このような案件のこのような要件であればこのくらいだろう。」という感覚です。何度も書きますが、この段階でこれを養うべく、経験を積んで絶対に何となくわかるようになっておいてください。

チームリーダー, 開発工数見積

(イ) 規模生産性

コメントをどうぞ

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

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

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

 

チームリーダー, 開発工数見積

開発工数見積もり手法

コメントをどうぞ

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

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

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

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

開発工数見積もり手法

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

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

チームリーダー, プロジェクトマネージメント, 開発工数見積

開発見積もり

コメントをどうぞ

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

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

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

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

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

1技術者からマネージメントへ, プロジェクトマネージメント

職業的PM、たたき上げPM

コメントをどうぞ

＜職業的PM＞

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

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

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

＜たたき上げPM＞

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

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

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

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

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

コメントをどうぞ

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

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

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

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

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