|
平成20年度 ソフトウェアに関する調査報告書U(IS-09-情シ-2)概要 組込み系ソフトウェア開発の課題分析と提言 |
1. | 調査検討方法 | |
ソフトウェア事業基盤専門委員会では、2008 年度から「開発スピードアップ」という新た
な視点から組込み系ソフトウェア開発の課題解決に取組むこととした。2008 年8 月に「組
込み系開発スピードアップ・ワークショップ2008」を開催し、開発スピードアップに関す
る事例報告と意見交換の場を設けるとともに、開発スピードアップの阻害要因、促進要因
に関して参加申込み者への事前アンケートも実施した。10 月にはCEATEC JAPAN 2008 に
おいて開発スピードアップに関する当専門委員会の取組みについて講演を行った。 そして、12 月に、組込み系ソフトウェアの開発スピードアップの阻害要因について、当 協会および関西経済連合会「組込みソフト産業推進会議」の参加企業等を対象にアンケー ト調査を実施し、43 社・89 名から回答を得た。この回答をもとに、開発スピードアップの 阻害要因の実態分析を行い報告書としてまとめた。 | ||
2. | 組込み系ソフトウェア開発のスピードアップ阻害要因 | |
2.1 | エンジニアリング・プロセスにおける開発スピードアップ阻害要因 | |
2.1.1 | 各アクティビティにおける阻害要因 | |
エンジニアリング・プロセスを構成する主なアクティビティにおける開発スピードアッ
プの主要な阻害要因は、以下のようになっている。 | ||
(1) 戦略 | ||
・ | 技術・製品の中長期的なロードマップが描けていない。 | |
・ | 戦略策定が十分に機能していない。 | |
(2) 企画 | ||
・ | 顧客ニーズが汲み取られていないことと開発の現状を把握しないまま企画が進行。 | |
・ | 顧客ニーズの観点からは、機能的に過剰な作り込み傾向が見られる。 | |
・ | 要求が整理されないまま開発に渡すなど、企画部門と開発部門の連携がうまく取れ ていない。 | |
(3) 要求分析 | ||
・ | 顧要求仕様が決まらない/決まるのが遅い。 | |
・ | 顧客からの要求仕様が固まらないことや、要求仕様の妥当性評価の手法が確立され ていない。 | |
(4) 設計 | ||
・ | 実装主体の設計になっているなど、アーキテクチャ設計ができていない。 | |
・ | 設計書のメンテナンスができていない。 | |
(5) コーディング/実装 | ||
・ | 方針がないままの実装やスキルがないまま実装が進められる。 | |
・ | 実装方針がないため擦り合わせに時間が掛かる。 | |
・ | スキルがないためタイミング関係のトラブルやメモリリークに関する問題が出る。 | |
・ | 人材不足が開発の各工程での検討不足・品質低下を招き、不具合の誘発、手戻りに 繋がり、開発工数の増大、人材不足の原因となる。 | |
(6) テスト | ||
・ | モジュールテストが不足している。 | |
・ | ハードとの同時開発・同時テストのため不具合解析に時間を要する。 | |
(7) 保守 | ||
・ | 保守に関してどう取組むべきか方針が明確でないまま、 場当たり的な不具合対応やカスタマイズが行われていることが大きな阻害要因である。 | |
・ | また設計でも保守に関することが考慮されていないことが挙げられていた。 | |
(8) 開発環境 | ||
・ | 開発環境に関する阻害要因としては、
ツールなど開発環境の検討に十分にリソースが避けないことがある。 | |
2.1.2 | 阻害要因の影響度 | |
阻害要因の中で影響度の大きいものとして一番多く回答があったのは「要求分析」であ
り、ほとんど差がなかったが、次に多いのが「企画」であった。その次に「戦略」が続く
回答であった。この3 つが全体のほぼ9 割を占め、阻害要因として大きな影響を与えてい
ることが分かる。これと比較して「設計」や「コーディング」、「テスト」などの工程は影
響度としては小さいという結果となった。 | ||
2.1.3 | 全体考察 | |
「戦略」や「企画」が阻害要因として大きな影響を与えるのは、それが開発の方針であり、
出発点でもあるからである。例えば、製品や技術の中長期的なロードマップが描けていな
いことや企画部門と開発部門の連携が取れていないことが、開発スピードアップの大きな
阻害要因になっている。このように「戦略」や「企画」は開発スピードアップに大きな影響を
与えるが、同時に解決しにくい部分でもある。回答者の多くを占める開発者側の目線から
見れば、この「戦略」や「企画」は、自らのミッションである「要求分析」や「設計」へのビジネ
スレベルからの入力として捉えることができる。今後、「要求分析」や「設計」といった主に
開発者が携わる業務からみた「戦略」や「企画」への提言など、ビジネス目標との関係を見て
いく必要がある。 そして実際には、要求仕様が決まるのが遅いなど、要求分析がスピードアップの阻害要 因として大きく影響を与えている。これは逆に言えば要求分析の困難さをうかがわせるも のである。この「要求分析」での阻害要因の解決に向けた深堀が求められる。 一方、「設計」から「テスト」、「保守」までは、阻害要因としては大きく影響を与えるもの としての回答が少ない。しかし、「設計」から「保守」までの工程で阻害要因があるとした回 答で半数以上の回答が多くあった。例えば、設計書を常にメンテナンスできていないとい う阻害要因は7 割以上の回答があった。このように全体の阻害要因としての影響度は「戦 略」や「企画」、「要求分析」と比較すると小さいが、多くの共通の阻害要因が見受けられる。 これらについても、共通課題として解決していく必要があるであろう。 | ||
2.2 | サポート・プロセスにおける開発スピードアップ阻害要因 | |
2.2.1 | 各アクティビティにおける阻害要因 | |
サポート・プロセスを構成する主なアクティビティにおける開発スピードアップの主要
な阻害要因は、以下のようになっている。 | ||
(1) プロジェクトマネジメント | ||
・ | 適切なプロジェクト計画ができていない。 | |
- 見積もり精度が悪い。 | ||
- リスクの特定や、その対応計画ができていない。 | ||
- プロジェクト間を配慮した全体最適でのプロジェクト計画が できていない。 | ||
・ | プロジェクトを運営する上で、 あらゆるところでコミュニケーションを円滑に進める仕組みができていない。 | |
(2) 文書化と文書管理 | ||
・ | 文書のフォーマットが規定されておらず、 仕様書として十分な情報が記述されていない。共同作業において、他人に自分の考えを理解してもらうこと、限られた時間 で論理的に物事を考えて文書を書き、それを相手に伝えるといった、基本的な部分の訓練がされていない。 | |
・ | ドキュメント作成手順は確立しているものの、ドキュメントのフォーマットが画一 的で、プロジェクトに合わせてカスタマイズすることができていない。 | |
・ | 短納期化のなか、どうしてもコード開発が優先となってしまい、その後もドキュメ ントが整備されない。 | |
・ | 作成された文書の品質は属人的である。 | |
(3) 問題解決管理 | ||
・ | そもそもどうしてそのような課題・障害が発生したかの分析にまで立ち戻ることが ない。 | |
・ | 障害内容の記載の質が低く、再現方法の確認に時間を要してしまう。 | |
・ | 課題・障害管理票は作成しているが、それを誰が責任を持っていつまでに対処する かが明確にされないままになっている。 | |
(4) 会議とレビュー | ||
・ | 適切な(スキルを持った)レビューアの選定がなされていない。 | |
・ | レビューを受ける側、レビューする側双方の事前準備がなされていない。 | |
・ | 目的やゴールを明確にした会議の進行がなされていない。 | |
(5) 外部委託 | ||
・ | アーキテクチャが、委託部分を切り出すのに適した構造となっていない。 | |
・ | 外部パートナーとの信頼関係やリスク管理に課題がある。 | |
・ | 委託(請負)管理上のコンプライアンスに対応するための工数が課題。 | |
(6) 開発プロセス | ||
・ | 開発状況の把握方法と開発手順が確立されていない。 | |
・ | 意思決定について、明確な方法が定まっていない。 | |
・ | それぞれの現場にマッチした適切な開発プロセスの定義ができていない。 | |
(7) 人材面 | ||
・ | 開発が人に依存しているため、個々の人がやっていることが他の人から見えない。 | |
・ | 定常的に忙しい組織の中で、各人が開発完遂への目標共有ができていない。 | |
・ | 技術者個人において基本的な行動特性に問題がある。 | |
・ | 技術的スキルに加え、コミュニケーションスキルが低い。 | |
・ | アーキテクト育成の実践的な取組みがうまくいっていない。 | |
・ | 組織に教育ノウハウが乏しく、風土として根付かない。 | |
2.2.2 | 阻害要因の影響度 | |
影響度に関する順位付けの回答において、1 位だけで比較すると「プロジェクトマネジメ
ント」、「人材面」の影響度が高いと認識されており、「開発プロセス」が続いている。3 位ま
でを総合してみると、この3 つのアクティビティは、ほぼ同列に並ぶことがわかり、更に
4 位までを総合してみると、「人材面」が、最も影響度が高いと認識されているアクティビ
ティとなる。 「文書化と文書管理」、「会議とレビュー」では、1 位や7 位とする回答が少なく、中間で ある3 位〜5 位とする回答が多い。これは、意識として最重要とまでは思っていないが、 軽視はしていない状況がうかがえる。 「外部委託」については7 位とする回答が非常に多く、特に影響度が低いという認識であ ることがわかった。 | ||
2.2.3 | 全体考察 | |
サポート・プロセスとしての共通の阻害要因としては、 ● やるべきことが決まっていない。 ● やるべきことは決まってはいるが、そのプロセスが決まっていない。 ● やるべきことやプロセスは決まってはいるが、きちんと遂行されていない という点が挙げられる。 アクティビティの重要度から見ると、「プロジェクトマネジメント」、「人材面」、「開発 プロセス」が上位にあがるが、日常の作業効率の積み重ねという意味では、「文書化と文書 管理」、「会議とレビュー」なども重要な要素と成りえて、軽視はできないと言えるであろう。 | ||
3. | 開発スピードアップの阻害要因に対する今後の取組みのポイント | |
今回の結果を鑑みると、エンジニアリング・プロセスもサポート・プロセスも、本来、
やるべきプロセス、やらなければならないプロセスをやっていないが故に、そのプロセス
が産み出すアウトプット品質が非常に悪くなり、それを修復しようとして、かえって無駄
な時間が発生し、スピードアップを阻害するという負のループへ陥っている状況にあると
言える。 手戻りが発生する理由として、最も重要と考えられるのは、エンジニアリング・プロセ スでは戦略、企画、要求分析といった上流工程で適切な決定が行われない、ということ、 サポート・プロセスではプロジェクトマネジメントにおけるプロジェクト計画がきちんと 行われていないということであり、どのようなプロセスの実態になっているのかを、プロ セスを分解し、分解した作業や工程のアウトプットを得るためのインプット情報を具体的 に調査し、何が足りないのか、何をしていけばよいのかを、明らかにしていきたい。また、 開発者のスキル不足といった人材面においても深堀した調査が必要と考える。 これまでの当委員会の報告書では、欧米の方法論を取り込んで我が国の物づくり文化に 合わせていくことを提言してきたが、今回の調査でわかったことを基に改めてソフトウェ ア開発の実態を浮き彫りにし、なぜ阻害要因になっているのか、どうし |