UTI UML教育研究所
読み物
OCUPブログ
OCRESブログ
UMLコラムから学ぶ
スキル・キャリアコラム
プロジェクト導入事例
エキスパートインタビュー
資格取得までのステップ
FAQ
教育コンテンツ
キャンペーン
ブックプラス
パートナープログラム
認定ユーザープログラム
メールマガジン登録
お問合わせ
組込み開発に携わる方のためのOCRESブログ 第1回

俊敏さ(アジリティ)をいかに維持し、高めるかは大きな課題
今月になって、アメリカ次期大統領選がヒートアップして来て、アメリカ人たちはかなり盛り上がっております。傍目には、非常に楽しそうであり、知り合いのアメリカ人に、ストレートに、「楽しそうだな?」と聞いてみた所、ちょっと渋い表情になり、「楽しいんではなく、これ以外にアメリカの将来に期待できる事がないからだ」と呻いていました。
この発言に、果たして、日本人として同情すべきか、あるいは、羨むべきかは意見の分かれる所でしょうが、1つ言える事は、アメリカの組織は、それが政府や会社であろうと、あるいは、もっと小さなセクションであろうと、トップが変わると、がらりと内容も変わる事ができる点です。

この前段の続きは、株式会社ストラタジーナムのプロマネBlogでご覧いただけます。

では、本題に移りましょう。

アジリティと組込み系開発

組込み系開発は、要求される品質水準も高い上に、頻繁な更改を必要とする局面が多く、メンテナンスの品質と言う問題は、多くの企業にとり、非常に頭の痛い問題です。
組織によっては、大部分のエンジニアが、メンテナンス作業に張り付き、新しい技術の研究開発が全く行えなくなったり、また、ソースコードを担当別に分けた結果、担当者以外には誰も分からないものになってしまっているといった事態は、けっして珍しいことではありません。
また、変更を直接ソースコードに行う事も、それほど珍しくありません。

設計図を用いたメンテナンス

あえてオブジェクト指向とかUMLとか言う言葉出さなくても、歴史的には、こういった問題は設計図を用いたアプローチ、つまりモデルを用いた方法で、かなり状況が改善される事が知られていました。
オブジェクト指向という言葉がない時代から、ソフトウエア・アーキテクチャという言葉は存在し、その頃から、設計者たちは、図形や表を用いてソフトウエアの構造を設計していました。そして、メンテナンスの際も、設計図にあたりながら、問題が、設計上のバグなのか、コーディング上のバグなのかを峻別し、前者であれば、設計変更を行う形で問題をフィックスして行きました。一見、回りくどいやり方ですが、最終的には、この方法が品質的にもコスト的にも最前である事が、知られてきています。
そして、フィックスしたコードのテストも、設計図を元に行います。今はやりの、モデル・ドリブン・テストの原型が、オブジェクト指向以前からありました。設計図を利用しないテストでは、テストそのものがブラックボックス型になりやすく、テスト・カバレッジが悪い傾向があります。
また、リリースアップ等の場合も、直接ソースをいじるのではなく、設計図を書いて行う方が、最終的には、素早く安全に行える事が知られていました。

オブジェクト指向/UML化

オブジェクト指向以前のソフトウエア設計図を用いた方法でも、いきなりソースコードのみをメンテナンスするよりは、一定の効果が得られますが、問題も残っています。
一つは、設計者ごとに書き方がバラバラで、他の人が非常に読みにくい事で、これはメンテナンスをチームで行う上での大きな障害となっていました。また、2つ目は、設計方法にばらつきがあり、ソフトウエアの強度の水準の維持が難しい事です。また、書き方がバラバラなために、設計ツールがなく、必要なら自分で作らなければなりませんでした。

90年代以降、欧米の開発現場で、オブジェクト指向が急速に受け入れられてきた背景には、この種の問題に解決策を提供する事が明白になってきた事が、挙げられます。
UMLを使う事により、モデリングおよび表記法が統一され、また、自分で開発ツールを作らなくても、市販のツールを利用する事ができます。そして、オブジェクト指向設計のアプローチにより、モジュラー構造やコンポーネント構造が半ば自然にとられ、ソフトウエア強度が上がり、品質も格段にあがる事が、明白になってきました。
そして、企業の生命線であるアジリティも、品質を確保した上で、向上する事が、広く認められるようになってきました。