« こんなのが特許になるんだ:アップル社のインターフェース特許 | トップページ | 現場を知らない大手企業の若造:シブすぎ技術に男泣き!3より »

2011年12月 1日 (木)

小規模プロジェクトの開発の現場から:開発管理手法と時間と工数

 開発の現場を長年やっていると、開発プロセスの重要性がよくわかる。どんなに忙しくても、手抜きをしてはいけないプロセスがあるからだ。たとえば、複数の開発者がからむ部分のI/F仕様なんかは、どんなに自明と思っても必ずFace-to-Faceでレビューしなければいけない。回覧レビューだけですますとえらいめにあう。レビューしないなんてもってのほかである。どんなに自明のことでも、人が異なるとやはり違う解釈をするのである。仕様が自然言語で書かれる以上しかたのないことである。
 一方、開発管理手法によっては、教科書的なことを本当に全て実行しようとすると余計うまくいかない場合がある。私には経験がないが、大規模プロジェクトでは教科書的なことを本当に全て実行することが重要なのかもしれない。でも、小規模プロジェクトでは無理だ。
 たとえば、トレーサビリティマトリクスである。これは、教科書を読む限り素晴らしい手法である。仕様変更による後戻りに悩んだことのない開発者はいないので、これで管理できれば素晴らしいと誰もが思うだろう。大規模開発で、この、トレーサビリティマトリクスのメンテに先任者をアサインできれば教科書通りの効果があるのだと思う。しかし、私のやってきた小規模プロジェクトでは、専任にできない。専任にできない管理的な仕事は、開発業務におされて時間を割けなくなる。すると、最初のころはきっちりと更新されていたトレーサビリティマトリクスが、だんだんと更新されなくなる。開発後期のピーク時での土壇場での仕様変更とかいうトレーサビリティマトリクスがあれば大活躍しそうな場面では、開発の現場にあるトレーサビリティマトリクスは更新されていないため実態とはかけはなれた使えないものになっている。そんなものである(威張ることではないが)。
 開発の現場では、時間と工数をどう割り当てるかが問題である。小規模プロジェクトでは、それが難しい。教科書通りにはいかないのだ。RAM表、WBS、課題管理表の帳票を用意し、レビューはスキップしない、バグ管理とバージョン管理だけはきっちりやる、というくらいでプロジェクトを乗り切る、というのが私のやり方だった。まあ、最低限のことしかやっていない。が、この最低限のことを現場で実行するというのが実は大変なんだよなあ。

« こんなのが特許になるんだ:アップル社のインターフェース特許 | トップページ | 現場を知らない大手企業の若造:シブすぎ技術に男泣き!3より »

技術」カテゴリの記事

開発業務」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

« こんなのが特許になるんだ:アップル社のインターフェース特許 | トップページ | 現場を知らない大手企業の若造:シブすぎ技術に男泣き!3より »

2020年6月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

公告

  • Google Adsense
無料ブログはココログ