« 今週は4連休 | トップページ | 今週は4連休なので…。 »

2008年3月17日 (月)

無駄を省く事について考えました。(その1)

日常業務に隠されたムダをとことん洗い出す

上記の記事は設計段階での話なので基本設計、詳細設計などの経験が少ないので
どうしても実装、テストでの無駄を省くと言う話になりますが…。

プロジェクトが終わった後になら大体思いつく「今思えば、あんな事しなくても良かったね…」的な事が
良くあると思いますが、全てが見えた後だから言えることはたくさんあるような気がします。
では、また次に新しいプロジェクトでそういう無駄というものが省けるかどうか考えてみると…。

多分、そんなに思うほど無駄って省けないんだろうなと思います。
逆にしっかりと時間が削減できる可能性もあるかもしれません。

私の場合は、つい昨年「苦い思い」をしました。それによりわかった事は、「いかに無駄な作業を省くか。」
ではなく、「いかに、手戻りの作業量を減らすか」では無いかと考えます。
やはり、システムを開発している時に、「動きが気に入らない」「ちょっとした仕様変更」
「不具合」なんていうのが多々発生すると思います。
と言うよりは、実際には設計段階では開発経験者でなければ、なかなかどういうものか
想像できると思えません。具体的な物が見えてきて初めて理解でき、意思を伝える事ができるように
なるのではないでしょうか。
家とか車の設計とは違うものですから、絵で見せることもできない。
(※画面設計書と言うものが存在するが、それを見せられてもやっぱりぱっとしないのが
私の経験です。全てが動いてから初めて話が始まるような気がします。)

そこで、仕様変更やら、不具合などは受け止める事を前提として考えたなら、
アジャイル開発は理に適っているのではないかと思います。
アジャイルで失敗する場合とは評価段階に入っても要望を受け入れたり、
ソースプログラムに変更コメントを入れたり…という事をするからコードの難読化が進んでしまうのかも
しれませんね。(昔はそれをしないと変更した場所がわからなかったから仕方が無いとして、
現時点ではいろんなバージョン管理システムが存在しているため、一気に作り直してしまえば
良いのです。変更点はいつでも取れるのですから)

さて、本題から逸れてしまいました。
では、どうやって手戻りの作業量を減らすか。
一番は「手戻りを作らない」これなら、0です。
それが無理だという事を前提にしたならば、処理の共通化。
メンバー間の意思疎通をしっかり取っておく事。

処理が共通化されていれば、修正部分が減ります。また、メンバー間の意思疎通をしっかり
取って、コードの理解も共有化しておけば、コピペでコードが分身していく可能性も減ります。
(私は昨年これで死にました:-))
それに加えて、「同じ処理を追加する時は共通関数化する。」といったルールを定めておく事。

あとは、コードレビューをしっかりする事。(これもコードの知識を共有化できるため
分身を防ぐ事が出来ます。)

これまでの内容からまとめると結局は「チーム内でしっかりコミュニケーションを取れ」
これに尽きるような気がします。

上記の事をしっかりしていれば、作業がかなり減るのではないかと推測します。
それを全くやっていなかったために失敗したのかも知れません。

これは(その1)としておきます。続きはまた次回へ…。

|

« 今週は4連休 | トップページ | 今週は4連休なので…。 »

プロジェクト管理」カテゴリの記事

コメント

コメントを書く



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




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/50625/40539569

この記事へのトラックバック一覧です: 無駄を省く事について考えました。(その1):

« 今週は4連休 | トップページ | 今週は4連休なので…。 »