情報技術の発展

最近、世の中の情報機器が急速に進化していると実感しています。自動車業界のETC・カーナビといった技術、携帯電話業界のスマートフォンの普及、書籍業界では、電子書籍の普及も見込まれています。IT業界のPCやデジタルカメラの高性能化は言うまでもないでしょう。

それでは、IT業界の中でも業務システムを構築するシステムエンジニアの仕事はどうでしょうか？

開発環境が整備されたことにより、過去に比べて格段と簡単に開発ができるようにはなりました。それでも、開発生産性はこの10年間で、大幅には改善されていないのが筆者の実感です。

今回は、新しいシステム開発技法への取り組みについて考えてみたいと思います。

お客様が理解できるもの

システムエンジニアの主な仕事は、お客様とシステム要件の刷り合せを行っていくことです。

お客様は画面や帳票といった具体的なものから、どんな機能になるのかを確認します。そのため、現在でも、ウォータフォール・モデルのシステム開発が主流であることは間違いありません。

業務システム開発にオブジェクト指向を適用し、「⁠ユースケース図」「⁠クラス図」「⁠シーケンス図」といったUML[1]を設計書としてお客様に理解していただくのは、とても難易度が高いからです。

実際、正しい書き方や使い方を理解するには、システムエンジニアでも訓練が必要なため、お客様にはとても難解なものになります。

オブジェクト指向開発への挑戦

筆者は数年前、１０人程度のプロジェクトでオブジェクト指向開発に関連する仕事を行いました。取り組んだ背景は、お客様のシステム部門から「保守性の高いシステム構築を行いたい。そのためには、オブジェクト指向の活用を検討して欲しい」という依頼を受けたからでした。「⁠オブジェクト指向って言葉は聞いたことがある」という程度の知識でしたが、いずれは避けては通れない内容なので、良い機会をいただいたと前向きに捉えました。

プロジェクト開始にあたり、UML、デザインパターン、アジャイル開発[2]等を猛勉強する中で、将来はモデリングチームを作りたいと思うまで、のめり込みました。

オブジェクト指向っぽい設計

プロジェクトを立ち上げ、システム設計を行なっていく中で、壁にぶつかりました。筆者を始めとしたプロジェクトメンバが作成したUMLの仕様書では、お客様が理解できないと言うのです。

UMLそのものが理解できないのか、UMLの書き方の問題なのかすら判断できず、打ち合わせ用として作成した設計資料で仕様確認を行い、後からUMLでオブジェクト指向っぽく書き直しを行うような対応を行ない解決するしかありませんでした。しかも設計アプローチが本来と違うUMLで作成されたドキュメントはあまり有効に活用されず、無駄な工数を費やしたことは、とても苦い経験です。

また、当初、アジャイル開発を取り入れたスケジュールとしていましたが、すぐにウォータフォール型のスケジュールに見直しを行いました。初めてのオブジェクト指向プロジェクトは、「⁠真似事」で終ってしまったのです。

システム開発の実態

筆者は、今でもオブジェクト指向やアジャイル開発を業務システムに適用することについては、否定的な考えです。

どうやってお客様から承認をいただくのか、システム仕様をどうやって確定するのかが理解できないためです。また、開発したプログラムに仕様変更が発生した場合、仕様変更の影響度が分かりにくいという点もあげられます。

実際、筆者の周りでは、業務システム開発において、オブジェクト指向やアジャイル開発を適用する事例は少ないように思います。

しかし、ウォータフォール型のシステム開発を適用し、お客様から承認をいただいたとしても、仕様変更で手戻りが多発するのも事実です。ウォータフォール型のシステム開発では、早い段階で「お客様が実現したいことに気付いてあげるスキル」が求められるため、仕様変更の発生する確率はエンジニアの力量に大きく左右されます。新しい開発技法が求めらながら、実務に合った解決策がないというのが、実態ではないでしょうか。

新しいシステム開発技法の研究

システム開発技法について、筆者の先輩エンジニアや同僚エンジニアと議論したことが何度もありますが、なかなか良い結論が得られていません。多くのシステム開発会社で悩んでいることと思います。

筆者も試行錯誤をしながら、プロトタイピング技法など、少しづつ良いものを取り入れながら活用しています。また、例えば「外部システム連携処理をシーケンス図で設計することは、とても有効である」等のノウハウも蓄積してきています。みなさんがシステム開発に参画する際に、例えば「アジャイル開発が適用できないか？」といつもと違うやり方も検討し、少しづつでも新しい開発技法を研究することをおすすめします。