2010年04月12日(月)

むやみに頑張らないこと

テーマ:見積
 

誰かに仕事をお願いするときに、「頑張ります」という返事をされるのは好きではない。頑張らないとできないのかと思うと、不安だからだ。できれば、頑張らずに涼しい顔で遂行してくれる人を探したい。


頑張るための余力は何かトラブルがあったときなど、いざという時にとっておいて欲しいのである。もし、依頼した「100 の仕事」に対して、110、120 の結果を出すために頑張ってくれるというのなら嬉しいが、それなら黙って頑張って欲しい。


「頑張ります」という言葉を使うとしたら、「100 の仕事は無理ですが、なるべく 100 に近づけるように頑張ります」といった文脈になるだろう。「95 までの完了は約束しますが、98 を目標に頑張ります」など、具体的な達成内容まで明確にできれば理想的だ。



「あいつはいつも頑張っている」という言葉は、「100以上」を目指して頑張っているのなら褒め言葉である(「仲間の仕事まで手伝っている」とか「自己のスキルアップに取り組んでいる」とか)。しかし、常に 100 を目指していつも頑張っているのだとすると、その人は常にトラブルを抱えているか、スケジュールの立て方がおかしいのだろう。


いつも頑張っていると、「頑張っている状態」を基準にしてスケジュールを立てるようになってしまう。普通は1週間かかる仕事でも、3日でできると自分自身が勘違いしてしまっている。実際、残業などして頑張ってやるので、何事もなければ3日でできるのだろう。しかし、そのような「もともと頑張る前提」のスケジュールでは、それ以上頑張れる余地がないため、トラブルが起きるとどうにもならなくなる。


これは個人だけでなく、組織でも同じだ。スタッフがいつも残業したり休日出勤したりして「慢性的に頑張っている組織」は、無理な仕事をどんどん受けてしまう危険性がある。そのうちのいくつかはトラブルが原因で、納期が守れなかったり、品質を落としたりしてしまうだろう。



悪いことに、いつも頑張っている人が、頑張らなくなると、手を抜いているように思われやすい(普通の状態に戻っただけなのに)。それが嫌で、ずっと頑張り続けることになるという悪循環。


そんなことにならないためには、「とりあえず頑張ろう」と考えるのではなく、「頑張らずに仕事をするにはどうすればよいか」、「頑張らずにできる範囲はどこまでか」といったことを考える方がよい。


もちろん、トラブルが起こったときなど、本当に頑張るべき時に頑張るのは当然である。そのためにも、「頑張るための余力」を残したスケジュールを立てるようにしたいものである。





■関連記事
できること、できないこと
どうして仕事を断らないのだろうか
どのくらいでできる?
簡単に見える時ほど注意せよ
たとえトラックにはねられても




ストーリーで考える「見積り」の勘所 (開発の現場セレクション)
中村 秀剛
翔泳社
売り上げランキング: 363251
おすすめ度の平均: 4.0
4 内容がわかりやすい
5 非常に判り易い
4 経験談は説得力がある
4 ストーリー仕立てはわかりやすい

がんばらないで成果を出す37の法則ーアライアンス人間関係術ー
平野敦士カール
ビジネス社
売り上げランキング: 30918
おすすめ度の平均: 5.0
4 著者の考え方の柱がさらりと書かれている
5 見開き102ページだから、読みやすかったです
5 日々、職場やセミナーで教わっている大事な事が満載
5 大事なことがさくっとわかります
5 デキル社員になりたかったら……
AD
いいね!した人  |  コメント(10)  |  リブログ(0)
2008年10月26日(日)

できること、できないこと

テーマ:見積

「こういうことができるか?」といった質問を受けることがある。質問する方は簡単なのだが、答えるのは難しい。何かが「できる」ためには、いろんな要因があるからだ。


・理論的にできる/できない
・技術的にできる/できない
・時間的にできる/できない
・費用的にできる/できない
・感情的にできる/できない


など。


ソフトウェア開発者の中には、理論的・技術的な可能性にしか注目しない人がいる。例えば、「既存のシステムにこんな機能を追加したいが、可能か?」という質問があったとする。それが、システムの仕様として矛盾がなく、実装方法が頭に浮かぶようなら、「できます」と答えてしまう。


しかし、ほとんどの仕事には「いつまでに(納期)」「いくらで(予算)」など、他の条件があるはずだ。質問者と回答者の間で、そうしたことが全く話題にならなかったとしたら、誤解が生じている可能性がある。回答者は多忙で寝る時間もない状態なのに、質問者は「頼んだらすぐやってくれるのだろう」と思ってしまうかもしれない。



ついでに書いておくと、「できるか?」という質問の答えは「はい」か「いいえ」である。上記のように「条件」によって答えが変わる場合があっても、結局は「はい」か「いいえ」だ。


ところが、「できるか?」と聞かれて「がんばります」と答える人がいる。それは、できるの、できないの? がんばったらできるの? できないけどがんばるの?


いずれにせよ、できない可能性があるということなので、リスクを考えると、「がんばります」=「できない」と見なすしかない。


しかし、これを「できる」とみなす人もいて、困ってしまう。できる前提でスケジュールを立てて、結局は遅れてしまう。


その仕事の成果として最低限必要な部分を 100% とすると、「できるか?」という質問に対しては、その 100% の仕事ができるかできないかを明確に答えるべきである。「がんばる」という言葉を使うとしたら、更にそれ以上の成果、110%、120% を目指す場合にしか使うべきでない。



プロジェクトでスケジュールを立てる場合、どの仕事を誰がどの期間で行うのか、ということを組み合わせていく。リーダーから各作業者に「できるか?」という質問がなされる場合も多いだろう。この際、各人の「見積能力」が重要なことは言うまでもないのだが、コミュニケーションについても注意が必要、という話である。







■関連記事
どうして仕事を断らないのだろうか
意気込みは分かったから...
話が通じない話
感情の行き違い




本当に使える見積もり技術―ソフトウエア開発を成功に導く
初田 賢司
日経BP社
売り上げランキング: 20625
おすすめ度の平均: 5.0
4 FP法を詳説した良書
5 ズバリ良書だと思います
5 見積りの全体構造
5 ファンクションポイント法の使いこなし方

速効!SEのためのコミュニケーション実践塾 (日経ITプロフェッショナルBOOKS)
田中 淳子
日経BP社
売り上げランキング: 17930
おすすめ度の平均: 4.5
5 もっと早く、この本のことを知っていれば・・・
5 コミュニケーションの大切さを実感!
5 SE以外の人にもお勧め!
3 速効性は高いですが…
5 図解・企業論文の書き方の著者の読後感想

AD
いいね!した人  |  コメント(0)  |  リブログ(0)
2007年03月21日(水)

簡単に見える時ほど注意せよ

テーマ:見積
最初は簡単そうに見えた仕事だったが、やってみると意外と難しかった、ということがある。

例えば、「CSV ファイルを読み込むプログラムを作ってくれ」という依頼があったとしよう。初心者プログラマにありがちなことだが、CSV なんて読み込んだ文字列をカンマで分割するだけだ、などと簡単に考えてしまうことがある。

しかし、実際にプログラムを作って動かしてみると、うまく動かない。いくつかの考慮が欠けていたのだ。例えば、

・値の中にカンマを含む場合はどうするか。
・値の中に改行を含む場合はどうするか。
・カンマの前後の空白は値に含むか。

といったことである。

よくあるルールに従う(例えば、Excel が出力するような)場合には、既存のライブラリ等を利用して簡単に実装できるかもしれない。しかし、独自のルールが必要だとしたら、ちょっとした手間がかかる。


あるいは、「文字列検索機能を作ってほしい」という依頼を受けたしよう。単純な完全一致検索や部分一致検索を想定して、安請け合いしてしまうかもしれない。

しかし、依頼者の頭の中にあったのは、日本語の単語単位できちんと検索してくれるプログラムかもしれない。つまり、「京都」で検索して「東京都」が出てきては困るというわけだ。こうした要望に対応するには、形態素解析のような高度な技術や適切な辞書データが必要になってくる。


ここに挙げたような例は、ある程度の経験を積んだプログラマや SE であれば、すぐに頭に浮かぶような話である。彼らは、仕事が依頼された時に、その場で質問し、上記のような問題はクリアにするだろう。

「安請け合い」しないために肝心なのは、仕事を依頼されたその時に、どこまで踏み込んだ質問ができるか、ということだ。経験が浅い人には難しいかもしれないが、そういう意識を持っていれば、そのうちできるようになるだろう。


一方、ベテランの技術者でも難しいのは、依頼者しか知らないような独自の要件(業務ロジック)に関することである。

特に、顧客から「ここのデータは、単に××コードで引っ張ってくるだけですよ」なんていう、いかにも「簡単でしょう?」といった感じの説明があった場合は注意したほうがよい。意識的であるかどうかは別として、必要な情報が隠されていることがあるのだ。プロジェクトの後の方になって、「いや、通常のケースはそれでいいんですけど、こういった場合はこうなって、ああいった場合はああなって・・・」などと「例外」がどんどん増やされたりする。

依頼者からすれば、細かい例外的な条件などは、大したことではないと思っているのかもしれない。システムにとっては、「通常」だろうが「例外」だろうが、処理が必要なのであれば同等なのだが。

何か仕事を頼まれたときには、簡単そうに見えることほど警戒したほうがよい。安請け合いをする前に、なるべく多くの情報を聞き出すことである。





■関連記事
やってみなきゃわからないという現実
どのくらいでできる?
・タブ区切りのCSV?



ソフトウェア見積り―人月の暗黙知を解き明かす
スティーブ マコネル Steve McConnell 田沢 恵 溝口 真理子 久手堅 憲之
日経BPソフトプレス (2006/10)
売り上げランキング: 2407
おすすめ度の平均: 5.0
5 アートとしての見積もり


成功する要求仕様 失敗する要求仕様
アラン・M・デービス 萩本 順三 安井 昌男 高嶋 優子
日経BP社 (2006/11/02)
売り上げランキング: 49741
おすすめ度の平均: 5.0
5 要求マネジメントの良書

AD
いいね!した人  |  コメント(9)  |  リブログ(0)
2006年02月26日(日)

システム開発費を値切る理由

テーマ:見積
ThinkIT の記事「だからあなたの会社のシステムは動かない ~システム発注担当者の悩みを解決します~ (第4回:見積もりについて)」より引用(太字は引用者)。

 予算の関係で、開発会社から出された見積もりに対して値引きを交渉することもあるでしょう。値引き交渉についてはそれぞれ事情もあるでしょうから、是非について一概にはなんとも言えませんが、よく聞く話であり、実際に私も多く経験しているのが、発注側の企業体質として「見積額からいくら値引きさせたか」が、発注担当者の社内評価になるというものです。

 その値引きへの根拠もなく、とりあえず値引きしたかどうかを上司は尋ねます。こうなると、開発会社も値引きされることを前提に見積額を算出するようになります。「値引きありき」のような考え方はなるべく避けたほうがいいでしょう。思い当たる企業の方も多いのではないでしょうか。


見積が高いと言われることは慣れていたが、正直なところ、その裏側をここまで想像したことはなかった。見積をするのがますます嫌になるような話である。

「安かろう悪かろう」という言葉は、システム開発のためにあるようなものだ(※)。システム開発を「値切る」ということは、自ら品質を下げるのと同じである。こんな発注者、本当になんとかしてほしい・・・。



※といっても、オープンソースなどは違うのだが・・・。



← このブログを誰かに読ませたいと思った方は、クリックを


■関連記事
建築屋は鉄を、システム屋はテストを削る
やってみなきゃわからないという現実
システム開発費の削減方法教えます




システム発注の基礎知識―システム担当者が知っておきたい
藤広 哲也
すばる舎 (2003/05)
売り上げランキング: 58,905
おすすめ度の平均: 4.5
4 システム担当者として最低限の知識
5 目的が明確で○


失敗のないファンクションポイント法
アレア
日経BP社 (2002/09)
売り上げランキング: 14,360
おすすめ度の平均: 4.5
4 私はこれでFP法を覚えました
4 ファンクションポイント初心者でも
5 このような入門書を待っていた!

いいね!した人  |  コメント(12)  |  リブログ(0)
2005年07月07日(木)

どのくらいでできる?

テーマ:見積
システム開発のプロジェクトでは、プログラマの「時間」は、きっちりと管理されるのが普通である。

例えば、「○○機能は3日でプログラミングする」というように、細かいスケジュールが引かれるだろう。

そういった状況の中、自分に与えられた作業がどのくらいの期間で出来るのか、ということを判断することは非常に重要である。

○○機能のプログラミングを任されたプログラマは、まず、自分がそれを3日でできそうかどうかを見積らなければならない。そして、できそうになければ、最初にそのように主張すべきである。3日後に「できませんでした」と言っていたのでは遅い。

リーダーが3日で出来るというのだから、がんばれば出来るのだろう、などと考えないほうがよい。自分がやる仕事は、最終的には自分が見積り、自分がスケジューリングするのだ。それも「プログラミングという仕事」の一部なのである。


スケジューリングが必要なのは、作業を与えられた時だけではない。1日目のプログラミングが終わった時点で、残り2日で全ての作業が出来るかどうかを判断することも大切である。このように、常に残作業を見積りながら仕事を進めなければならない。

そして、予定から遅れそうであれば、すぐにリーダーに報告する。これは絶対に躊躇してはならない。責任を感じて言い出しにくいという人もいるかもしれないが、開発作業の遅れなんて日常茶飯事だ。気にすることはない。

まともなリーダーなら、遅れを報告をしなかったことを責めることはあっても、遅れたこと自体を責めることはないだろう(※1)。

とにかく、遅れの報告は、早ければ早いほど良い。早く報告したほうが、再スケジュールなどの対策が取れる余地が多いからだ。


経験が少ないプログラマにとって、作業のスケジューリングは難しいものである。しかし、それをやらなければ、その場その場の思いつきで作業を行うような状態になってしまうだろう。そんなことでは、いつまでに作業が完了するのかわかったものではない。プロのプログラマとしては失格である。

どうしたらよいか分からない人は、まず、与えられた作業について、具体的にはどんなことをするのか、想像してみよう。作業をもっと細かいまとまりに分割して考えるといいだろう。次に、その細かい作業のひとつひとつについて、必要な時間を見積もる。そして、それを時間軸(カレンダー)上に配置するといいだろう。

こういった作業の見積は、プログラマという職種に特別に要求されるものではない。期限付きの仕事をする場合には、当たり前のことだ。しかし、意外と出来ない人も多いのである(※2)。




※1
もちろん、まともでないリーダーもいるので、困るのだが。それどころか、自ら顧客に遅れを隠し続け、納期直前に発表するようなプロジェクトマネージャもいたり...

※2
客先の担当者にも...



生産管理ができる事典
生産管理ができる事典
posted with amazlet on 06.06.24
田中 一成 黒須 誠治
日本実業出版社 (2004/03/25)
売り上げランキング: 25,963
おすすめ度の平均: 5
5 生産管理の入門書として最適


革新的生産スケジューリング入門―“時間の悩み”を解く手法
佐藤 知一
日本能率協会マネジメントセンター (2000/04)
売り上げランキング: 8,995
おすすめ度の平均: 4
4 スケジューリングについて最も分かりやすく書いた本


いいね!した人  |  コメント(3)  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。