資料６(16-SEWG-1)
システム開発の課題例
2016年8月23日
独立行政法人 情報処理推進機構（IPA)
技術本部 ソフトウェア高信頼化センター（SEC)
© 2016 IPA
Software Reliability Enhancement Center
本資料の目的
コンセプトシートでは、システム開発上の課題類型ごとに解
決手法をマッチングさせることを予定しており、ヒアリング
事例に即して適切な課題類型を構成する。
ご議論いただきたい事項：
• 課題の分類(類型化)法
•
解決方法への対応付け容易性等の観点で
• 追加すべき課題領域
• 課題の重要度
• 課題抽出の粒度
• 課題内容の詳細度、明確性
© 2016 IPA
等
Software Reliability Enhancement Center
2
本資料で取り上げた事例の収集方法
環境変化などにより既存のシステム開発からの転換が求められ
ると当方で想定した業種(下記)の企業等を主な対象とし、国内
のシステム開発における新たな課題認識についてヒアリング結
果をまとめた。一部は課題解決法も含んでいる。
運輸・鉄道
自動車
重工業、電気・電機
医療・ヘルスケア
新ビジネス（フィンテック等）
エンタープライズ（金融等） 計12社(8月現在)
※今後予定（電力・ガス、通信、ロボット、建築、農林水産、
アミューズメント、 ITコンサル、
防衛、航空・宇宙）
© 2016 IPA
Software Reliability Enhancement Center
3
課題例 (1.1) 従来にない新たな要求
#
業種
課題認識
1
交通
(鉄道)
お客様に提供する新しい価値の創造と顧客サー
ビスの向上 (安全性に加えて利便性、快適性等
の追求)
今はスパイラル状の継続的な発展（技
術改良）。
2
交通
(鉄道)
特定の駅間での混雑が恒常的であることへの対
応
新しいシステムの開発：デジタル式自
動列車制御方式
3
自動車
OEM
車とくるまの外とのつながりが増えていく →
従来にないインターフェース統合ニーズに対応
4
自動車
OEM
{従来にない要求}
自動運転、ネットワーク化への対応
スコープ設定が甘い→検討漏れ→大き
な手戻り
5
自動車
TEAR1
単品デバイスの技術向上では勝てない時代に
なってきている
→単品デバイスをつなげた(システム)ソリュー
ションに持って行きたい
単品開発をやってきた人材ばかり
上位レイヤーで考えられる人材が不足
している
すり合わせ開発に慣らされて時代に遅
れている
6
自動車
TEAR1
要求開発は重要でやりたい
→シミュレータを使った合意形成
7
電機
{製品・サービスの}SoS化への対応
今までのやり方ではうまくいかない。
全体を俯瞰できる人材が不足している。
8
ヘルス
ケア
個別のBtoBで要件の厳しいものが出てきた際の
対応
測定結果を時系列でクラウド蓄積だけ
なら重いSLA(注)は不要
散発的にBtoB案件があり個別に苦労
9
SI
単純なシステム開発にとどまらないケース (ス
テークホルダの多様化・増加、SoS、IoT、
IT/OT融合など)への対応
※{ } で囲んだ記述はIPA/SECによる推察
© 2016 IPA
左記に関連する補足事項
事業者の取組み方針(案)
(非連続的な)飛び越える技術革
新（イノベーション）を行う。
対応路線拡大中
必要な人材の確保
抽象化能力の育成
IoTやOpen-Systemでは密で
なく疎に作るセンスが必要。
(組込み系とWeb系のような育
ちの違い？)
{IoT, SoSなどに対応できる
開発標準等の強化拡充}
(注) SLA(Service Level Agreement)
Software Reliability Enhancement Center
4
課題例 (1.2) 要求の複雑化
#
業種
課題認識
左記に関連する補足事項
事業者の取組み方針(案)
1
交通
(鉄道)
安全性を追求しつつ、社会の要請である相互乗
り入れや新しい路線開発など規模拡大、複雑化
への対応
死傷事故ゼロ(責任追及から原因追求へ
考え方の変化)
輸送品質の向上（遅延時分の短縮）
お客様にやさしい鉄道サービス
これまでにもＩＣＴ化による
複雑な業務改革を実践してき
ている。(輸送管理システム、
旅客販売総合システムなど）
2
自動車
OEM
{サブシステム間連携が必要な機能の益々の増
加} 開発効率を向上したい。特に上流での合
意形成の時間を短縮したい。
クロスファンクション開発の益々の増
加
→合意形成に時間がかかる
共通理解のためのモデリング
3
自動車
OEM
要求開発が不十分なことによる失敗を無くした
い。{きちんと作っても使えない}
4
ヘルス
ケア
測定器はハード中心だったが、ソフトウェア比
重の高まりへの対応が必要
ハードウェア開発を主眼とした開発標
準や人材
開発標準の拡張、内製以外の
アプローチ
5
SI
大組織の情報システム対応
合意形成が難しい
合意形成プロセス
6
SI
IoT、社会インフラに注力していく→ステーク
ホルダーの多様化、増加
→標準的な用語体系が必要
ISO/IEC 15288は見ており、参考にし
ている。12207と15288のハーモナイ
ゼーションの動きも追っている。
社内標準の改定
※{ } で囲んだ記述はIPA/SECによる推察
© 2016 IPA
Software Reliability Enhancement Center
5
課題例 (1.3) 要求の多様化
#
業種
課題認識
左記に関連する補足事項
事業者の取組み方針(案)
1
重工業
FA
お客様の工場における個別課題を解決するビジ
ネスに転換中 (形態：センサ等→工場ビッグ
データ→分析→アクション) → 提案の品質向上
自社既存ソリューションの押し売り的
提案を出しがち (ハードウェアを売っ
ていた時代の社員マインドが残存)
スペック発想からサービス発
想への転換
課題解決トレーニングを実施
2
SI
親会社向けシステム開発から外販への転換にお
ける対応
{→顧客毎の要求に対応?}
お客様と一緒に作っていく
(究極の要求開発)
3
SI
新たな事業やサービスをお客さまとともに「協
創」するタイプの案件増加への対応
開発標準等の強化 (経験価値
(experience)の視点に着目)
4
SI
ビッグデータ分析活用型案件の増加への対応
{開発標準等の強化}
5
金融
銀行
グローバル化に伴う各国規制の違いへの対応
個別対処 {効率的とは言えない}
※{ } で囲んだ記述はIPA/SECによる推察
© 2016 IPA
Software Reliability Enhancement Center
6
課題例 (1.4) 要求の高度化に伴う新たな品質要求
#
業種
課題認識
左記に関連する補足事項
事業者の取組み方針(案)
1
重工業
FA
製造業のインダストリークラウドを統一的にサポー
トしたい
→サイバーセキュリティリスク (特に既存設備回り)
従来の安全設計の知見にサイバー
セキュリティの技術を総合したリ
スク対策
2
SI
IoTによる工場管理を推進する上で、工場の情報セ
キュリティの確保が課題
ステークホルダ(本社、工場、顧
客等)間でルール、ネットワーク
を構築中
3
金融
銀行
様々な外部連携、海外との連携などが増えてきて
徐々に複合化が進み、責任元が不明というようなこ
とにもなりかねない。
→上記の環境でも、常に責任元を明確にした上での
サービス品質向上の取組みを行うことが課題
4
金融
FinTech
金融サービスとしての意識をもって、安心安全な
サービスを提供したい
FISC(金融情報システムセン
ター)の安全対策基準を参照して
いる
※{ } で囲んだ記述はIPA/SECによる推察
© 2016 IPA
Software Reliability Enhancement Center
7
課題例 (1.5)機能高度化によるコスト・工期への影響
#
業種
課題認識
左記に関連する補足事項
1
自動車
OEM
ECU開発に関するコストダウンの対応
2
自動車
TEAR1
モデルから仕様書にする活動ができていない
現状の改善
3
電機
{下流で欠陥が顕在化すると大きな手戻りが
発生することのリスク低減?}
4
SI
親会社向けシステム開発から外販へ→開発効
率化の向上が課題
ウォーターフォール、多重下請け
5
SI
IoT化を推進する案件が増えてきており、開
発を効率化したい。
共通PF構想→すぐ個別最適になってし
まう。
(新規部分が多いと品質が不安：痛い目
にあったこともあり)
6
金融
銀行
グローバル展開に伴い、各国の規制の違いへ
の対応という状況も生じている。
対応のための開発効率を向上したい。
個別対処 {効率的とは言えない}
7
金融
FinTech
当社においては、より重要なサービスであっ
たり、成功パターンが見えてくるフェーズに
なるにつれて、スピードから、品質にだんだ
んシフトしていくという転換の対応が課題。
社内の体制、プロダクトの機能、開発
運用人数の強化観点においてのスケー
ルに弱い。個別最適化による成果の最
大化があるとしたら、規模のスケール
とともにそれは難しくなる。
コストダウンの圧力が強い。{ECU数増
大、ECU仕様複雑化に伴う?}
事業者の取組み方針(案)
{仮想開発等による効率化?}
仮想開発(上流でシミュレー
ション検証)の推進
ソリューション共有 (重複開
発削減)、アジャイルプロセス
※{ } で囲んだ記述はIPA/SECによる推察
© 2016 IPA
Software Reliability Enhancement Center
8
課題例 (1.6) 要求に関する早期合意形成
#
業種
課題認識
1
金融
銀行
ビジネス戦略に基づく企画に関する早期合意形
成。
2
金融
銀行
柔軟なビジネス対応の方法と体制の確立。（ス
ピード）
（昨今のビジネス環境の中では、今のようにシ
ステム化の手順が重過ぎて、ビジネス機会を逃
すリスクがある。）
3
金融
保険
ビジネス戦略に基づく企画に関する早期合意形
成。
左記に関連する補足事項
事業者の取組み方針(案)
比較的新ビジネスの部門とは
ビジネス戦略から情報共有し、
ロードマップを一緒に作って
いる。市場系、規制の多い分
野も同様。
今のシステム部門の手順のような手堅
さだけでなく、柔軟に対応できるよう
にすることも考える必要がある。
従来：企画についてはメイン
で本社の企画部門が行い、具
体化した段階でＩＴ部門が関
わる。
最近：企画の早期からＩＴ部
門が実現性や方式の検討に加
わることでより良いものして
いく。
※{ } で囲んだ記述はIPA/SECによる推察
© 2016 IPA
Software Reliability Enhancement Center
9
課題例 (2.1) 人材育成
#
業種
課題認識
左記に関連する補足事項
事業者の取組み方針(案)
1
自動車
OEM
業務繁忙化で要員(新規スキル)育成の余裕が
ない (MBSE、制御MBDスキル)→必要スキル
（人材）の確保が課題。
2
自動車
TEAR1
頻繁な要員シフト→教育が現場任せになって
しまっている。→適正な教育の実施による人
材育成が課題。
3
重工業
正しいプロジェクト管理者不足
{エンジニアからPM昇格、設計等も兼ねる
PM}
→{プロジェクト管理活動に抜け漏れ}、
コミュニケーション問題
→プロジェクト管理者の育成が課題
適切なPM育成法
4
SI
専門家の育成
認定技術者制度
5
金融
保険
様々な専門分野を交えて仕事をする必要があ
る。法務的な専門家、セキュリティの専門家
など。→人材の確保、育成が課題。
（※単に知見があるだけではなく、判断基準
のあいまいな中で自ら解決策を探り調整力を
発揮してスピード感をもって進める人材。な
かなかいない。）
※{ } で囲んだ記述はIPA/SECによる推察
© 2016 IPA
Software Reliability Enhancement Center
10
課題例 (2.2) 社内標準化、知識管理
#
業種
課題認識
左記に関連する補足事項
事業者の取組み方針(案)
1
自動車
OEM
データや情報の管理が不十分：属人化、ドメイン
毎、工程毎 →データ管理の改善が課題。
2
自動車
OEM
部門毎の開発標準がばらばら、(OEM毎のローカル
ルールもある) {社内標準の見直しが課題}
3
電機
ツール、手法が標準化できておらず、開発効率の
向上に十分な効果が出ていない。
(多様なモデリングツール、シミュレータ)
→開発効率の向上が課題。
{開発効率を上げるための最適
なツール、手法選定}
4
SI
知見の共有化
スペシャリストのコミュニ
ティ作り
各人が実案件で培ったノウハ
ウを抽出整理して全社のノウ
ハウにする取り組み
5
金融
保険
全社の情報、知見の集約と共有が課題。
（様々なコネクションがあり、様々な情報が入っ
てくる。全社で集められていない。
これまでは担当部門が考えればよかった。これか
らはつながったほうが良い結果につながる。）
知見の集約、共有
※{ } で囲んだ記述はIPA/SECによる推察
© 2016 IPA
Software Reliability Enhancement Center
11
課題例 (2.3)ビジネスのグローバル化、ビジネスの可視化、
組織構造、ルール、風土
1. ビジネスのグローバル化
#
1
業種
SI
課題認識
左記に関連する補足事項
買収する{海外}会社の開発標準をどうする
か？
→開発標準に関する方針策定が課題。
事業者の取組み方針(案)
国際標準の活用
ERP活用型やアジャイル等の
開発標準強化
2. ビジネスの可視化
#
業種
1
自動車
OEM
課題認識
左記に関連する補足事項
事業者の取組み方針(案)
左記に関連する補足事項
事業者の取組み方針(案)
ハード／ソフト原価構造の定量的な把握が不
十分 {開発コスト?}
→原価構造の把握が課題。
3. 組織構造、ルール、風土
#
業種
課題認識
1
自動車
OEM
プロセスと組織構造がマッチしていない現状
の改善が課題。
2
自動車
TIER1
必要以上に内製化→致命的ではないが非効率
→開発効率の向上が課題
3
重工業
全体を見ている・まとめている人がいない
{或いはスキルの問題?}→単体では機能するが
システム全体で動かないことあり→全体品質
マネジメントが課題
4
SI
直接成果の無い活動の予算確保が難しい。→
プロジェクト管理活動に抜け漏れ防止が課題
(組織横断的、機動的チーム)
{これは暫定解?}
※{ } で囲んだ記述はIPA/SECによる推察
© 2016 IPA
Software Reliability Enhancement Center
12
課題の分類軸案
前述の国内調査結果から、以下の分類にて今後の整理を行って
いくのが妥当と思われる。今後、これに海外の調査結果を踏ま
えた上で分類項目を補っていく。
#
1 要求事項の変化
#
分類
1.1 従来にない新たな要求
1.2 要求の複雑化
1.3 要求の多様化
1.4 要求高度化に伴う新たな品質要求
1.5 機能高度化によるコスト・工期への影響
1.6 要求に関する早期合意形成
2 その他
2.1 人材育成
2.2 社内標準化、知識管理
2.3 ビジネスのグローバル化、ビジネスの可視化、組織構造、
ルール、風土
© 2016 IPA
Software Reliability Enhancement Center
13
【参考】他の分類軸案(再掲)
問題点が
顕在化している
問題点は
あるが顕在化していない
問題点が
そもそもわからない
課題解決型
体系化型
新たな分野への挑戦型
・大量の不具合・リコールの流
出防止策
・自動車・鉄道分野の機能安全
体系（ISO 26262やRAMS等
対応）におけるセキュリティ考
慮要求
・生活製品の多品種開発におけ
るCI確立
・開発技術の承継
（グローバル環境での人材育
成・グローバル教育センター）
・エンジニアのモチベーション
確保
・自動運転車開発
・こうのとり開発
・IoTの新ビジネス創出
ソフトウェアエンジニアリング
やモノ作りがこれまで有効に機
能していたが、新たな課題解決
のため開発手法の見直しが必要
になった事例の類型。
システム開発成功が、特定の人 まったく新規のプロジェクトや事
材に体系化されたノウハウ・ス 業分野への進出が求められ、問題
キルに起因していたことから、 点がそもそも把握できない中、シ
その思考背景や対応を体系化す ステム設計を求められた事例の類
ることが求められた事例の類型。 型。
例
出典：慶応義塾大学SDM相談事例より
© 2016 IPA
Software Reliability Enhancement Center
14
© Copyright 2024 ExpyDoc
