suVeneのアレ » 仕事関連

相手ができないことわかってるのに受注してあとからグチグチいう人が多いとか

suVene — Tue, 31 Jan 2012 14:25:41 +0000

特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐－ Publickey

を読んで。

内容を要約すると、発注側がIT技術の生かし方が分からず、そのため業務フロー設計も無用な産物で大量に作成しつつ、開発ベンダーに丸投げという体制が続く限りだめになる、って感じだ。

実際これは、開発現場に於いてよくあるパターンであり、よくある愚痴である。
「この客、全然要求が整理されてねぇ！」
「自分たちの業務が整理できてねぇ！」
「詳細が見え始めてからの要件変更が多すぎる！」
などなど。

確かに、上記は発注側として解決していくべき問題・課題ではあるかもしれない。
ただ、個人的には「発注側の責任」をグチグチ言う前に、開発側で他に取るべき手段があるのではないか？と思う。

というのも、発注側のプロジェクトの人間は、そのような業務全体を設計するような経験もなければ、それをできるだけのスキルも持ちあわせていないことが多いという現状なのは、最初から開発側は理解しているはずだ。発注側にも、数は少ないが全体を見据えて話をする人間はたま〜に見かけるが、ステークホルダーが多すぎて調整に時間がかかり過ぎるという問題もあったりする。
つまり、発注側は自分たちのビジネスに於いてはプロなのかもしれないが、IT資産を活用し設計することにおいては、ほんとに素人の人間がほとんどだ。

それがわかっていて受注しているのに、さんざん言いたい放題の客の言うことを聞いてきて、無理な期間と金額で受注をし、後から「要件変更が多すぎる」って、「うけるー」としかいいようがない。そんなの最初からわかってることだろ。何回同じ事繰り返すんだって話である。

あくまで恒久的には(長く付き合う取引先の)発注側自身が新しい業務モデルを設計し、IT資産をどのように活用すればよいか考えることができ、要求・要件を整理し、きちんとした RFP を作成した後に発注できるようになってくれるのが理想なのかもしれないが、それも含めてコンサル業務として、要件定義前の新業務フロー構築の手順やノウハウを伝達し、先々のリスクをヘッジするのが、開発側へのニーズではなかろうか。

「すみません。言われたことしか作れません」
でもよいが、それはそれではずかしー話だなぁ、とよく思う。

※ あくまで、自分の周りの経験上の話。他の開発会社のスキルはもっと高いかもしれない。俺が「はずかしー」ところにいるだけかもしれない！

[書評]「要領がいいいね!」と言われたい人の仕事術

suVene — Sat, 07 Jan 2012 11:02:49 +0000

「要領がいいね！」と言われたい人の仕事の習慣 (アスカビジネス)

石谷　慎悟明日香出版社 2011-07-12
売り上げランキング : 74399

当たり前のことばかりが書かれている。普通の社会人にとって目新しい情報も、具体的な解決方法も見つけにくいだろう。どちらかと言えば、新入社員にお薦めかもしれない。(といっても、学生でもこれくらいは把握していそうだが)

ただまぁ、「基本を見直す」という意味ではサラっと読むのもよいかも。

目的意識を持つこと

この本で最も主張されているのは、「仕事に目的意識を持つこと」だ。常にゴールを見据えることで、「必要なことはなにか」「この手段で達成できるのか」「無駄なことはないか」を意識することができる。

目的意識は、常に問われる。作業を始めるとき、作業を初めて少ししてから、作業を終えたあと。そうやって全体を俯瞰して自分の作業で作り出した成果物が、目的に沿ったものになっているか確認するのだ。

全体像を見ること

全体を俯瞰することも重要視される。
一つ一つを完璧に作業しようとする人は多い。また、目先の細かい作業に気を取られて全体像を考えようとしない人も多い。そのような人に、作業を記憶するのではなく、何かに書き出すことを勧めている。

実は、抜けていた作業や気がついたことなどをその場で書き足すようにすることで、自然にその書き出したものを見るようになります。そして、それを見ればその先の作業も目に入るため、ひとつの作業に没頭してしまったり、必要以上に時間をかけてしまったりすることを抑止することができるのです。
「要領がいいね！」と言われたい人の仕事の習慣 (アスカビジネス) P44

全体を俯瞰し、客観視し、自分の軌道を修正することは、目的を達成するための基本中の基本だが、いざそれが実践できているかといえば、先に書いたようにそうでないことも多々ある。

まとめ

あとは作業の「優先度」「重要度」で仕事順を決め、そしてそれを見直すという事にページがさかれている。
「仕事とはなんぞや？」
ということを見直したい人、コーチングしたい人にとっては有効な一冊かもしれない。

リンク

「要領がいいね！」と言われたい人の仕事の習慣 (アスカビジネス)

石谷　慎悟明日香出版社 2011-07-12
売り上げランキング : 74399

スケジュールが遅れる理由について

suVene — Sun, 28 Feb 2010 04:01:10 +0000

プロジェクト管理の中のひとつ、スケジュール管理、或いは進捗管理についての考え方。
その中でも特に、「納期」について。

はじめに

プロジェクトを遂行していると、必ずといっていいほど「遅れ」が出てくるものである。それは何故なのか。どうすればよいのか。を、個人的な観点で、今の考えを整理。主にソフトウェア開発。

スケジュール管理について

スケジュールは遅れるものである

まず、スケジュールが遅れるのはなぜか。

納期・計画がそもそも無理
度重なる仕様変更が抑えきれない
立ち上げが遅く、各フェーズ開始時には、既に○ヶ月遅れだった

などなど。

このなかで、一番最初の「納期・計画がそもそも無理」は、個人の努力ではなかなか改善しようがない部分が多いが、「ある程度バッファがある」と思っていたプロジェクトですら、いつの間にか「遅れ」が出てくるものである。

これは何故なのか。

それは、従属関係にあるタスクというのは、そのタスクごとの繋がりが密であればあるほど、予定通り開始することが可能な可能性は少なくなっていくからではないか。

例えば、ここに 10個のタスクがあるとする。このタスクはそれぞれ、バッファを見ており、予定通り終わる可能性は 90% ほどだとする。そしてこの 10個のタスクがそれぞれ「must Finish task to Start task」の関係にあるとするならば、10個のタスクが予定通り終わる可能性は、

90% * 90% * 90% * 90% * 90% * 90% * 90% * 90% * 90% * 90% ≒ 34%

ほどである。

つまり、途中で何も手を打たなければ、7割弱の可能性で予定通り全てのタスクは完了できない。

「遅れ」は伝播し、「進み」は伝播しないものである

従属関係にあるタスクは、従属してることにより「遅れ」は必ず後ろの工程に伝わる。しかし「進み」は後ろの工程に伝わることは少ない。それは何故か。

先行着手できるタスクがない(ウォーターフォールなど)
10日の期日が設定されていれば、最初から 10日の期日で終わらせる為の段取りを考える
「早く」終わったとしても、すぐに報告しない可能性が高い
「早く」終わって余裕ができた時間は、普段溜め込んでいる「スケジュール以外」の時間に割り当てる

などなど。

特に、仕事量に関係なく与えられる報酬が一定であったり、減点方式の評価あったりすれば、「期日どおり」終わっていさえいれば減点されるリスクは少なく、またそれ以上仕事が増やされることもないので、期日前に完了を報告するインセンティブが少ない。

「リスク」の報告は遅れるものである

一つ一つのタスクに「余裕」を見ていると、最初に想定していなかった問題や、予測以上に時間がかかりそうな問題が発生した場合でも、「「個人の裁量」によって何とかできる」と判断してしまい、報告が遅れることがある。これは、当人に悪気や傲慢なところがあるという理由ばかりではなく、「周りに迷惑をかけまい」と気を使う結果であることもある。そういう仕組みになっていることが多い。

「進捗率」は曖昧なものである

経験している人は多いが「90%完了」という報告の後に、なかなか終わらないタスクというものが存在する。これは、何に対する率が曖昧なためである。「機能は 90% 完了している(が、例外処理はまだ完成していない)」、「90%の実績(予定に対しての消化率」など、報告の基準が曖昧だと、個人のレベルによる進捗率の報告がなされる。どちらも 90% の意味は正しいが、欲しい報告ではない。