ソフトウェアメーカーA社 激化する“短納期”要求で、開発現場は限界に・・・。品質向上に向けて、「偏ったテスト工程」と「個人に依存した開発ナレッジ」を見直せるか─。

背景

仮想化やクラウドといった先進技術の登場で企業のシステム依存度が強まる昨今、ソフトウェア開発をめぐる環境はますますシビアになっている。明確な「ソフトウェア品質基準」が定められていない日本においては、品質向上に対する顧客要求は留まるところを知らず、一方で開発猶予期間は短縮傾向にある。本番稼働までわずか数ヶ月という例も珍しくない。

しかし、“ヒト、モノ、カネ”といった開発リソースには限りがある。過酷さを増す顧客要求に対し、多くの開発現場では苦心惨憺の体は否めず、従来の開発・検証プロセスは徐々に限界に近づきつつある・・・。

課題・問題

激化する「納期短縮」の影響で不具合が頻発!-テスト工程見直しが急務に・・・

画像新興のITベンチャーであるA社は、パッケージソフトウェア/クラウドアプリケーションの企画・開発に加え、SIerや大手システム会社と連携して、企業独自の業務用アプリケーションの受託開発などを行っています。
近年、基幹系業務をオープン系システムに移行する需要が増えていることもあり、A社の開発期間は急激に短縮路線を辿っていました。通常案件でも3〜6ヵ月、ひどいときには1ヵ月という案件もあり、開発現場は常に時間との戦い。A社にとって、“開発期間短縮”はまさに喫緊の課題といえるものでしたが、一方で品質面とのバランス維持が限界点に達していました。

A社では、設計段階で仕様を固めた後、その仕様をもとに開発工程へ、そして単体/結合テスト工程へと至る従来の開発プロセス(ウォーターフォール型)を採用していました。しかし、受託開発における顧客の要求は流動的で不明確。このプロセスでは開発途中での仕様変更に柔軟に対応することができません。こうなると、そのしわ寄せを多く受けるプログラマは納期までに要求された機能を満たすことに精一杯で、拡張性や保守性、不具合を考慮したチューニングまで頭が回らない状況でした。

また、テスト工程もプログラマが担当するため、テストケースが偏ったり評価が疎かになる、といった課題も生まれていたようです。A社技術・開発部マネージャーのO氏はこう語ります。
「システム実装後やリリース後の不具合発覚が度々発生しており、休日出勤や徹夜残業はもちろん、プロジェクト遅延や修正パッチの増殖など、クレームにつながることもしばしばでした。テスト工程の早急な見直しが必要でした」

無秩序に増殖するExcelファイル・・・「過去のナレッジ」は忘れ去られた遺産に?

限界を感じたA社は、品質向上のために、早期のリスク回避に有効な「段階的開発プロセス(反復型)」の部分的な採用を検討します。しかし、ここで大きな壁となったのが、“開発者個人のノウハウや記憶”に依存した開発体制でした。
「反復型」は、過去の設計・開発・検証ナレッジを生かして利用可能なシステムを段階的にリリースしていき、設計の修正を繰り返していく開発プロセス。ゆえに、全社でナレッジを共有できる仕組みがあれば有効ですが、そうでないとかえって効率を悪化させかねません。

A社では、フレームワークの再利用性を高めるために案件情報の履歴管理こそ義務づけていましたが、統一された管理ツールがなかったため、「設計書」や「仕様書」、「不具合管理」などは、すべて個別の担当者がバラバラにExcelベースで管理していました。そのため、異なる案件は言うに及ばず、同じ案件であっても担当者ごとに無数のファイルが作成され、案件情報は無秩序に増えていく一方。

「案件情報はファイルサーバ上で共有していましたが、形だけというのが実際のところでした。あれだけ大量のExcelファイルですと、過去の情報を参照しようと思っても、嫌気がさしてアクセスしなくなるのも頷けます。結局、自分の作成したファイルしか参照しないようになりますので、いつまでたってもナレッジは共有されず、担当者が辞めてしまえば、その情報は“忘れ去られた遺産”状態でしたね」(前出O氏)

A社ではこうした問題を解決しようと専用の構成管理ツールの導入を検討しましたが、高価な上に操作性が複雑なことから、現場の反対意見を考慮すると、解決策にはなり得ませんでした。

課題・問題のポイント

  • 高まる短納期要求でプログラミングやテスト評価が疎かになり、不具合による手戻りが頻発

  • Excelベースでの煩雑な案件管理が原因でナレッジ共有が図れず、個人に依存した開発体制に

  • ナレッジ共有に向けた構成管理ツールの導入を検討するも、高価かつ煩雑な操作性から断念

12