今回は、トラブルに備えた開発と設計について、いくつかの“気付き”を挙げる。まず、システム開発段階における開発ツールや開発方式に関して、いくつかのトラブルやその対応を挙げた。
 |
IT業界では、次々と新しいツールや新しい仕掛けが開発・提案されている。しかし、新方式が効果を出すためには設計者が慣れる必要があるし、ツール自体も成熟する必要があるので、多くのプロジェクトで効果を出せるまでには数年はかかるとみたほうが現実的であろう。新しい開発手法をいきなり大規模に活用することは危険で、早めに訓練するとともに、部分活用すべきだ。
2006年ソフトウエア開発環境展のセミナーにおいて、ある企業のトップが、Javaを使った開発では同一のフレームワークを継続使用すれば生産性は確実に向上するが、初物の場合は極端に生産性が低下するので、「新しいフレームワークの適用には万全の技術確認と事前教育が必須」と発表していた。
また、『ソフトウエア開発55の真実と10のウソ』は、「新しいツールや技法を学習すると、最初は生産性や品質が下がる。実際に効果が出るのは、ツールや技法が完全に身に付いてからだ」と指摘している。
 |
ソフトの世界では、新しいツールが開発されると、それがどんな対象にも役立つ“万能薬”であるかのように感じる人が多い。研究者が試作結果を発表したり、ベンダーが製品を発表したりするときは、ツールの優れた効果は強調するが、弱点に言及することは少ない。ツールの適用範囲や限界、副作用について、もっときちんと説明し、質問する習慣をつけないと、使ってみたときの失望感が強くなり、かえって大きく展開しないことになってしまう。他分野に比べソフトの研究には、評価研究が少ないことが、その原因ではないかといわれているようだ。
新しい言語や開発手法、ツールは、ソフト開発の効率化に非常に優れたところがある半面、慣れるまでは効果が出ないことと、副作用が必ずあることを認識し、積極的かつ段階的に活用を推進したいものである。
 |
規模の小さいシステムでは、どんどん新しい試みをすべきである。だが、システムが巨大だったり、経験がない業務で納期も厳しかったりするシステムでは、未経験の開発技法を使うのはリスクが大きすぎる。むしろ、プロジェクト・リーダーが成功経験を持っている手法を採用し、自信を持って開発に当たるべきだし、その経験の延長線上で自分の得意技に磨きをかけ、実績以上の成果を求めるべきである。
ただ、顧客側の責任者が強い信念を持って新方式を取り入れようとし、必要な時間と予算をかけてもらえるなら、運命を託し、挑戦すべきであろう。
 |
全体最適を考えて、共通化できるところは共通化し、ムダのないシステム構築を目指すことは大事である。しかし、チーム・メンバーがよく理解できないような難しい共通化は失敗する危険性がある。共通化というものは大仕事で、技術力だけでなく、その部隊の業務遂行力が問われるからである。最適解の追求も大事だが、その時点の納期、コスト、技術、メンバーの力量とのバランスで妥協することも大切だ。
開発規模が予定以上に大幅に増えてしまい、周りからの批判に耐えられず、コスト削減を図ろうとする無理な共通化はもっとも始末が悪い。
共通化するなら、最初に共通化方針と共通部分の仕様をしっかりとまとめ、きちんと設計しておくべきだ。消化不良のまま共通化を進めようとすると、プロジェクトは必ず混乱し、原価はさらに増えてしまう。
