|
|
1968年、NATOで「ソフトウェアの危機とソフトウェア工学」をめぐる議論がされて以来30年以上経過した今日においても、ソフトウェア開発をめぐる危機的な状況は至るところで語られている。その一方で、こうした状況を解消すべくさまざまな方法論やモデルが提唱され、エンジニアの注目を集めている。では現在のソフトウェア開発者はどのような危機に面し、またどういう方法でそれを乗り越えようとしているのだろうか？ Java Solutionフォーラムが実施した第4回読者アンケートから、その主な結果を紹介しよう。
 |
現代におけるソフトウェアの危機とは？ |
まずは読者が日ごろどのようにソフトウェアを開発しているのか、その現状から見ていこう。図1は、読者が現在最も多く手掛ける案件の種類を聞いた結果である。従来の「勘定系／基幹系ソフトウェア」とともに、ｅビジネス時代にふさわしく「Webを用いた情報発信や電子商取引に関わるソフトウェア」開発に関与している読者が全体の3割を占めた。
 |
| 図1 関与する主なソフトウェア開発案件の種類（N=250） |
次に上記のようなソフトウェアを開発する際、採用されることが多い開発モデル（工程）を聞いた結果が図2である。ご覧のとおり伝統的な「ウオーターフォール・モデル*1」の採用率が43％でトップとなる一方、「スパイラルモデルなどの段階的／反復型開発モデル」の採用率は28％であった。図1の案件内容と合わせて見ると、Webアプリケーションのような新しい分野の開発案件においても、工程手順として従来のウオーターフォール・モデルが採用されるケースはまだ多いと思われる。
*1：ウオーターフォール・モデル：要求定義→外部設計→内部設計→プログラミング→テストなどの開発工程を1つずつ順番に実施するモデル
 |
| 図2 ソフトウェア開発モデルの採用状況 （N=250） |
では上記のようなソフトウェア開発を行う過程で、読者はどのような課題を感じているのだろうか？ 3つまでの複数回答で尋ねた結果、最も多くの回答が集まったのは「開発期間の短期化」であり、以下「オブジェクト指向に基づいた分析／設計ができるコア・エンジニアの不足」「開発規模や工数の適正な見積もり」「開発途中での仕様変更が頻繁」と続く結果となった（図3）。
 |
| 図3 ソフトウェア開発の課題（3つまでの複数回答 N=250） |
図3の上位項目を眺めると、個々の課題は互いに関係しているように思える。前述の開発案件で多かったWebアプリケーション開発で考えると、発注元はスピードが速く変化が激しいビジネスを展開する（でないと生き残れない）顧客が多いと思われる。そうした顧客案件の“開発期間が短期化”し、“仕様変更が頻発する”のも当然であろう。そういう意味で短期化／仕様変更は、課題というよりｅビジネス時代に伴う必然的な環境変化と呼べそうだ。
しかし従来の開発モデルでは、この環境変化に適合できない。「スピードと変化の要求に弱いウオーターフォール・モデルから、オブジェクト指向による反復型開発へ」というのがその一般解であるが、そこでプロジェクトをリードすべき“コア・エンジニアが不足している”のが実態というわけだ。現在のソフトウェア開発における最大の課題は、新しい開発環境に即したプロジェクトを率いる人材の育成にあるのかもしれない。
|
RUP／XPなどの開発プロセス 技術者に高まる意欲と孤立感？ |
さて後半では、上述したソフトウェア開発の課題を解消する試みとして注目される開発プロセスおよびUMLの利用状況について見ていこう。
オブジェクト指向による反復型の開発プロセスとしては、近年RUP（Rational Unified Process）やXP（eXtream Programming）が注目されている。まずこれら開発プロセスの現在の実践状況および今後の導入意向を聞いた結果が図4である。現在のところ何がしかの開発プロセスを実践している読者はまだ数少ないもようだが、今後の学習／実践意向でRUPを挙げる人は50％、またXPでは68％にも上っており、より良い開発プロセスを学ぼうとするエンジニアの強い意志を感じさせる。
 |
| 図4 ソフトウェア開発プロセス実践状況（複数回答 N=250） |
ではRUP／XPなどの開発プロセスは、読者ニーズを反映して速やかに普及していくのだろうか？ 例えばXP導入について巷では、“大規模開発には向いていない”“オンサイトカスタマー（ユーザー顧客を開発チームに同席させる）などのプラクティスが日本の習慣に合わない”といった批判を耳にすることも多い。
そこで読者が開発プロセスを導入する際の課題を聞いたところ、もっと根源的なところにハードルがあることが分かった（図5）。その第1は「社内的な認知が進んでいない」ことであり、次いで「新しいプロセスを学習する機会や時間がない」「自社の企業文化や既存プロセスとのギャップが大きい」といった点だ。読者の置かれている状況をまとめると、“自分が有用と感じているプロセスの必要性が所属する組織内で共有されず、また個人として学習する契機も見つからない”という孤立した姿が見えてくる。時代の要請にこたえる開発プロセスが普及するためには、現在離散／点在する意欲的なエンジニアがネットワークし、学び合うことのできる"場"が必要なのではないだろうか。
 |
| 図5 開発プロセス導入の課題（3つまでの複数回答 N=250） |
|
UML：コードとモデルの連携機能中心に普及進む |
スピードと変化の時代のソフトウェア開発において、開発プロセスとともに注目されているのがUML（Unified Modeling Language）によるモデリングだ。では顧客の要求分析／設計を行ううえで、UMLによる抽象化と整理はどの程度普遍的なものなのだろうか？ 読者がかかわる開発プロジェクトでのUML利用状況を聞いた結果を見ると、現在UMLを利用しているのは全体の42％であった（「おおむねすべての案件で利用」「案件の内容によってUMLとほかの方法を使い分けている」「最近UMLを使い始めた」の合計）（図6）。“最近使い始めた”層が20％を占めていることからも、UML普及が急速に進んでいることが分かる。また現在利用していない読者もその大半は「勉強中／興味はある」と答えており、ソフトウェア開発者におけるUMLの普遍的魅力が明らかになった。
 |
| 図6 UML利用状況（N=250） |
ではUMLを利用するに当たり、読者はどのようなツールを活用しているのだろうか？ 現在および今後利用したいツールを尋ねた結果が図7だ。まず現在の利用状況を見ると、「Visio*2」「ドローソフトやプレゼンテーションソフト」「紙とペン」（！）といった汎用的なツールの利用が多い中、UML専用ツールでは「Rational Rose」の利用者が全体の2割弱となった。また今後の利用希望では「Rational Rose」を挙げる読者が4割に上っており、UML作成ツールを代表するマインドシェアの高さが明らかになった。
*2： VisioにはコードからUMLクラス図にリバースエンジニアリングする機能などもあるが、歴史的にチャートやネットワーク図作成として使われることが多いと思われるため、ここでは「汎用ツール」と表現した
 |
| 図7 UMLツール利用状況／利用意向（複数回答 N=250） |
最後に読者がUML作成ツールに望む機能／特徴について聞いた結果を紹介しておこう（図8）。最も期待されている機能は、設計とコーディングを素早く柔軟に連携する「モデル図とソースコードを相互に自動生成／出力できること」であった。スピードと変化への対応が前提のソフトウェア開発環境において、UMLツールが必要となる理由はまさにこの点にあるといえるだろう。
 |
| 図8 UMLツールに望むこと（3つまでの複数回答 N=250） |
■調査概要
- 調査方法：Java Solution サイトからリンクした Webアンケート
- 調査期間：2001年10月9日〜11月5日
- 回答数：272件。内ソフトウェア開発者250件を集計対象とした。
| 関連記事 |
| 連載：いまなぜ開発プロセスを注目するのか（Development Style） |
 |
読者調査記事一覧 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
