プロジェクト管理していると、避けては通れないのが品質管理。
特に、ソフトウェアは「見えない」から問題が見つけづらいということで、
あの手この手でなんとか品質をよくしていこうという試みがされています。
日本人はKAIZEN好きですし。
今回のシンポジウムでは、いくつかの興味深い事例を聞くことができました。
トラブルプロジェクトの対応中でも、たまには外に出かけるのは大事ですね。
今後のプロジェクトのヒントも見つけたし。
IT系の人って外に出かけたがらない人が多いみたいなのですが、
もっと出かけたらいいのになーって思います。
気分転換にもなるし、新しい気づきや発見もあるのにな。
あ、それで、品質管理に話を戻すのですが、
色んな話を戻す聞いたり、勉強にしたりして思ったのですが、
結局、いろんな研究が目指してるのって、
・人がやるとバグが入るので、人がやらない方法は無いか
・後でバグを見つけるのは大変なので、なんとか早く見つける方法は無いか
のふたつかなって思いました。
人がやらない方法は無いかというのも大事なのですが、
私が関わるようなプロジェクトはまだまだ人が要件定義して設計してプログラムを書く。
ということは、人がやってることだし間違うじゃないですか。
ですから「いかに早く見つけるか」の方に興味があります。
もちろん、複雑なやり方をすると間違いやすいからシンプルにしよう、とか、そういうのは大事だし、シンプルな方法を考えるのも好きなんですが、それも結局「早く見つける」ってことにつながるんじゃないかなって思います。
ドキュメントの読み間違いをしないように、フォーマットを決めてしまう、とか復文で書かずに単文にする、とか、どこを修正したか忘れないために記録しとくとか、そういうのは間違いを早く見つけるための工夫だって思います。
品質管理では、記録が大事なのですが、あとから思い出して記録するのって、すごく大変。
だから最初から分析の仕方とか、どんな管理をしたいか考えておいて、仕事してたら自然と記録が残るような方法を作っておいた方が楽。
最初はちょっとしんどいけど、後から手を入れるよりずっとマシ。
大掃除って面倒だし、すっごく大変だけど、
日頃のちょっとした掃除ってそれほど大変でもない。
でも、そのちょっとしたことを続けておくと大掃除しなくても大丈夫だったりする。
それと同じかなーなんて思います。
私は面倒臭がりなので、一回作ったものを後から修正するとか、できればやりたくない。
なので、どうやったら作るものを最小にして最大の効果が出ないかとか、できればやらずにすむ方法がないかなって考えるのが好きなんです。
設計書の改訂履歴とレビュー記録を関連させておくとか、
Excelでレビュー記録を作っておいて集計を楽にするとか。
やってるチームも多いと思います。
でも、もし、見直しができるなら、「もっと楽になる方法は無いかな」って
考えてみてもいいのではないでしょうか。
プロジェクマネジメントも、アグレッシブに攻めていきたいな、と思うのです。