タグ別アーカイブ: 前提条件

コラム:怒りポイント

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

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

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

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

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

考慮:リスク

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

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

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

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

考慮:スケジュール

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

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

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

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

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

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

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

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

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

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