保守性の向上を狙う再構築プロジェクトでは、いくつかの立場の関係者がそれぞれ、役割を果たさない点に問題が潜んでいる。図1に示した関係者の発言を見ていただきたい。一見悪いところは何もなさそうだが、保守性を下げてしまう要素が含まれている。保守性の向上のために、誰が何をすればよいのか、実は無意識のうちに足を引っ張っている状況を見て行こう。

図1●保守性を下げてしまうプロジェクト関係者の発言
図1●保守性を下げてしまうプロジェクト関係者の発言
[画像のクリックで拡大表示]

プロジェクトオーナーの責任は重い

 まず、プロジェクトオーナーは、プロジェクトに目標を設定し、それをプロジェクトの意思にする役割を持つ。しかし、保守性に関しては、しばしば目標の設定に失敗し、保守性の実現をプロジェクトの意思にできていない。

 ありがちな失敗は、目標があいまいだったり、控えめすぎたり、コスト削減に偏ったりしているケースである。あいまいな目標は無視され、控えめな目標であれば「その程度か」と見くびられる。目標がコスト削減では、真の保守性に逆行する動きを誘発する。

 うまく進めるには、具体的で高めの目標を設定することだ。例えば「現行では、案件Aでのシステムの改変に1年かかったけど、それを3カ月でできるようにする」といったものである。

 目標さえ設定すればよいのかというと、そうではない。保守性への関心を継続的に示さず、言いっぱなしだったり、進捗ばかり気にしたり、技術者の保守性向上の努力や成果を取り上げなかったりすると、プロジェクトメンバーに、保守性の実現については本気でないと思われる。

 つまり、プロジェクトの意思になり切らないのである。保守性向上の工夫をしたチームを賞賛し、保守性を犠牲にしようとするチームには「ちょっと待て」とたしなめるようでなければならない。保守性の最後の砦はプロジェクトオーナーなのである。

 保守性について「ベンダーを十分巻き込んでいない」という失敗もありがちだ。保守性向上の目標をRFP(提案依頼書)に書かなかったり、保守性向上の実現方法の提案をRFPで要求していなかったり、ベンダーがコストやスケジュールなどを理由に抵抗すると妥協してしまったりする。

 ベンダーが本気にならないと保守性向上の取り組みをプロジェクト全体に浸透させられず、真の保守性に逆行する動きを止められない。RFPに保守性の目標を明記し、ベンダーに保守性向上の実現方法を提案させ、投資に見合う保守性向上が得られるよう要求しなければならない。

要件を決める側の責任は「許容可能な数字」

 システムの使い手の要求を決めている側も、無意識のうちに、保守性を下げるようなことをしてしまう。それは「必要な応答時間」などの情報を出さないことだ。

 「応答時間が早いに越したことはないので、できるだけ早く」というのでは、保守性を向上できない。性能を優先させてしまうと保守性は維持できなくなるからだ。そうではなく、「許容可能な数字」を出す必要がある。

 また、その性能を維持できないとどのような影響があるのか、「業務がさばけなくなる」のか、「お客様が怒るから困る」のか、どのようにどのくらい困るかを伝える必要がある。性能が重要なものと異なるものを識別して伝えることも重要だ。