ソフトウェアエンジニアリングを再起動

2023年7月13日 12:04

新しい職場では、ソフトウェアエンジニアリングも担当というか、日本のソフトウェアの一大拠点であったソフトウェアエンジニアリングセンターの後継の仕事をすることとなりました。

みんなから、データばかりやっていると思われがちですが、実は昔からソフトウェアエンジニアリングに取り組んできていて、このnoteの写真は自宅の本棚の一部であり、見ての通りかなりマニアな本が並んでいます。日本情報システムユーザー協会（JUAS）のデータ品質研修や経済産業省のCIO研修の中で品質の講義もしていました。今、ソフトウェアエンジニアリングの知識をアップデート中なので、考え方や最近の動きを整理してみました。

なぜソフトウェアエンジニアリングに着目したのか。そして、どんな変遷だったのか。

大学を卒業して国内最大手のSIerに入り、システムエンジニアとしてシステム開発を行っていましたが、すごく大きな疑問がありました。

大学で学んでいた機械工学は、エンジニアリング、つまりは「一意に記述できる」「広く可読性がある」「再現が可能である」「シミュレーションができる」という特性がありますが、ソフトウェア開発ではその特性が全く当てはまらないことに気が付きました。エンジニアリングとしての特性が確保されていないために、意思疎通に誤解があったり、検討に抜け漏れが生じるということが頻発していました。

その後、コンサルティング子会社に移動しBPRをする機会がありましが、そこで衝撃的な出来事がありました。モデリング技法がないなりに現状とシンプル化した改善案のフロー図と効果仮説を書いてみたのですが、チームリーダーから「こんなにシンプル化したら人が減ってしまうではないか、もっと仕事が減らないように書き直せ」と指示を受けたのです。まったくBP”R”のリエンジニアリングではないと反論したのですが、まったくエンジニアリング的な議論ができず憤慨したものです。

そうこうするうちに、1990年前後に米国国防省が進めたCALSといわれる製造業の抜本的改革プロジェクトに出会うこととなりました。製造データの共有を中核に調達や運用も含むロジスティックスをサポートするプロジェクトです。
(日本の建設におけるCALS/ECは米国CALSを参考に派生したもので、もともとのCALSから大幅に変更されている)

CALSにおいては製品データの交換にSTEP（Standard for the Exchange of Product model data）を推進していましたが、この製品データを取り扱う業務やロジスティックス全体の業務の記述にIDEFというモデリング手法が使われていました。IDEFはIntegrated DEFinitionの略で、複数のモデリング手法で構成されています。その中でも特に重要なのは、機能モデルのIDEF０、情報モデルのIDEF1X、プロセスモデルのIDEF３です。IDEFは政府調達標準のFIPSにも指定され、IDEF0がFIPS183、IDEF１XがFIPS184となり、政府内のガイドラインやドキュメントの記述に用いられました。IDEF３は当時最先端の技術で、FIPSになりませんでしたが、業務フローをもとに業務シミュレーションを行うなど、まさにエンジニアリングを目指したものでした。

日本にも
1994年位に日本に入ってきたCALSプロジェクトを通じて、ソフトウェアエンジニアリングは、「エンジニアリング」を目指さなければならないと強く意識しました。

もう一つ、エンジニアリングには重要な要素があります。エンジニアリングをサポートするツールがあるということです。機械の分野では、ものさしや分度器もそうですが、製図用ドラフタ－、CAD等のツールが広く使われていきました。

しかし、当時の日本のソフトウェア開発の現場では、お絵かきツールで機能やプロセスのモデルを書き、表でデータの設計をするなど、エンジニアリングツールなしでソフトウェア開発をしていました。
システムのソフトウェア開発はKKD(勘・経験・度胸)といわれていた時代です。

まずはモデリングから始めてみた

机上で進めていてもしょうがないので試行してみることにしました。試行版のソフトを入手しいろいろ試すのですが、大きなプロジェクトの分析をすることができません。

そこで、組織として取り組もうと提案した時の議論で分かったことがあります。モデリングを導入しないことの理由１は、専門家であるほど開発手法に疑問に感じて一度は試した経験があるのですが、その時の失敗経験をもとに「できない」と決めつけている人が多いことでした。当時のモデリングツールは英語のソフトが主流であり、日本語が表記できなかったりすることも大きな理由でした。さらに、モデリングツールの機能制約について指摘する意見も多かったです。モデリング手法は、誰でも共通の理解ができるように記述方法や内容にルールがありますが、そこに、きめ細かくメモとかを書き加えたい日本のエンジニアには、現場で使えないツールに見えたようです。しかし、あまりに自由に記述方法を改変できてしまうと、関係者の共通理解が得られないでミスを誘発する可能性があります。そういう点でモデリングとは何かという理解が不足していた面があるのかもしれません。

また、当時は業務フローを記述するプロセスモデリングが主流だったのですが、そこでモデリングツールの設計思想とと日本の設計思想の差がありました。日本のシステム設計はベンダーがシステムを作ることを目的に行うので、システムのレーンが必ずあります。業務ヒアリングでも、「あなたがここで使っているシステムは何ですか」というシステム中心の情報収集になります。海外の設計では、システムのレーンがないプロセスをよく見かけます。業務ヒアリングでも「あなたの役割は何で、そのために何の情報をもとに何をしているのですか」と質問をします。業務現場では、システムなんて関係なくて画面だけですので、担当者にわかりやすく、本質をとらえやすい質問をしています。
そういう設計思想というのは、ツールに組み込まれますので、日本の従来のシステムエンジニアには使いにくかった面もあったのではないでしょうか。

次は、調達管理における定量管理に直面

モデリングと並んで重要なのが定量管理です。エンジニアリングは数学と自然科学を基礎としているので定量的に管理されることは当然です。しかし、ＩＴの世界はモデリングがしっかりしていないので、そもそも設計対象のサイズや開発期間を見積もるのが大変でした。そこで先ほども書いたＫＫＤ（勘、経験、度胸）という考え方が出てきます。また、2000年頃は公共調達を中心に低価格入札というものが広がっていました。初期費用を赤字まで下げて、その後の開発や運用で継続契約し資金を回収する方法です。モデリング手法が確立していないので、初年度以降に他社が受注しようとしてもできないベンダーロックイン問題とセットで大きな問題でした。

この取り組みを始めた2000年台は、システム開発手法はウォーターフォールが中心でシンプルでしたので、多くのデータを集めることで規模やコスト、期間、品質などの目安を作ることが容易でした。そのためソフトウェア開発や運用のデータを集めて業界全体で共有する取り組みが行われました。IPAでのソフトウェア開発分析データ集、JUASのソフトウェアメトリックス調査・IT運用コストメトリックス調査、経済調査会のソフトウェアの調査研究が有名です.

このように定量的な分析ができる環境が揃って、政府調達なども定量的に行われ、米国では製造面でなくシステムの成果に着目したパフォーマンスベース契約なども導入されています。

EAの登場

調達改革と並び、米国政府が政府のシステム改革として力を入れていたのがエンタプライズ・アーキテクチャ（EA）です。日本もその取り組みを参考にして推進するために2002年にITアソシエイト協議会をつくり日本版EAの整備を始めました。2003年に「EA策定ガイドライン」として取りまとめられています。この中にシステム構築に必要なモデリング記法が書かれていましたが、調達の課題解決という視点から検討が始まっているので可視化や監査の視点が強く、生産性などソフトウェア・エンジニアリングとしては不十分なものでした。それを踏襲して2004年に「業務・システム最適化計画策定指針（ガイドライン）」が制定され、政府全体でガイドラインに示された日本政府独自のモデリング方法でシステム設計が行われました。モデリング手法が独自なのでモデリング・ツールを活用することができず、設計者は作図ソフトや表計算ソフトを使ってモデルを作成し非常に苦労しました。一方、人月で商売するIT業界は、生産性の低い手法を批判することもなく、2014年12月にガイドラインの見直しになり廃止になるまでの約10年間使われました。
現在は、プロジェクト管理にフォーカスしたデジタル・ガバメント推進標準ガイドラインに置き換わっており、モデリングに関する標準はなくなっています。

ソフトウェア開発の抜本的革新に挑戦

一方、2000年から2007年まで毎年、米国の電子政府の展示会FOSE(Federal Online System Exhibition)に行っていたのですが、2011年に久しぶりに米国の電子政府の展示会に行ってみました。そこで目を見張ったのが世界最大のイントラネットであるAKO(Army Knowledge Online)です。AKOにはAppianのBPM(Business Process Management) suiteが搭載されており、BPMNで記述した業務プロセスをBPM suitで動かせるようになっていました。プロセス記述のための1週間のトレーニング、利用者がプロセス記述を理解するための3日間の研修が提供されていて、世界のどこでもプロセスを公開すれば世界中で使えるようになるという画期的な仕組みでした。

やはり、モデリングだと確信し、2011年にBPMN検証プロジェクトを立ち上げることとしました。
そこで、入札説明会に大手システム会社やITコンサルに来てもらい「BPMNを使っていない会社はないと思いますが、普段使っているBPMNのノウハウを使って検証をしてもらいたいと考えています。」と入札の参加条件に社外向けプロジェクトでのBPMN使用実績を求めたてみました。予想通り各社は、他社はもうBPMNに取り組んでいるのかと焦り、ある会社は「社内で研究しているのだが、戦略的に全力で取り組むから参加できないか」と問い合わせてきたり、海外の部門を組み入れた提案をしてきました。
このプロジェクト自体も有効でしたが、調達を通じて各社のBPMNに対する意識を高めることができ、翌年には対応製品なども公表されるなどの効果をあげました。

このプロジェクトで画期的だったのは、法律をBPMNで記述するという、現在、世界各国で取り組まれているLegalTechに世界に先駆けいち早く取り組んでいる点です。法律、省令、手引書、実業務の機能を分析したり、手続きのモジュール化の検討をしています。

これらのノウハウをもとに、政府の業務モデリング手法であった業務最適化ガイドラインをBPMNやクラス図をベースに見直したかったのですが、並行して進められていた業務最適化ガイドラインの改定に間に合わず採用にに至りませんでした。2012年にガイドラインが変わっていれば、日本のIT業界ももっとモデリングに注力したかもしれません。そうはいっても、このような検討結果は民間や特許庁など一部府省では活かされており、少しづつですが改革が進み始めました。

さらに現場からモデリングを攻める

モデリングをガイドラインから普及を図るのも一つの方法ですが、現場で実績を積むとともに、現場の人にわかってもらうことが重要です。
そこで、採用でモデリングの話をするとともに、日常の情報整理にモデリングを積極活用するようにしました。経験者採用をするときに面談で「どのようなモデリング手法を使っていましたか」「モデリング手法についてどのように考えていますか」と具体的な活用事例も交えて聞くと、その人の実力が見えてきますし、採用に至らなくても応募してくれた方によい刺激を提供することができます。
また、会議するときにこちらの資料がモデリングで書いてあると相手が驚くことがよくあります。うちのチームはグローバルを意識しているので、アーキテクチャ記述にarchimate、プロセス記述にはBPMN、データ記述にはUMLクラス図を使っていますが、こうやって具体的に示していくことが重要ではないでしょうか。

国内の取り組みはどうなっているのか

環境変化

最近はソフトウェア開発にも大きな変化が来ており、開発方法や分析方法の見直しの必要性が指摘されています。

ソフトウェアエンジニアリングは専門性が高く、ベンダー中心の検討になりがちでした。しかし、ユーザーから見たときには、デジタルサービスを作る時のコストと開発期間をどう考えればよいのかという問題があります。人事サービスを考えたとき、「人事サービスをアウトソースする」、「ネットワーク上のサービスをカスタマイズして使う」、「ネットワーク上のサービスをノンカスタマイズでつかう」、「ノーコード・ローコードツールで作る」、「サービスモジュールを組み合わせて作る」、「プログラミングして作る」等の様々な選択肢があります。
価格設定についても合理的な説明が求められています。車を買うときにはその車で移動することで得られる価値を考え300万円とか払うのに、ソフトウェア開発では、人月でこれだけ人が稼働するので○○円くださいと製造コストベースで言われることが腑に落ちないという人もいます。
パッケージソフトやネットワークサービスは、その必要性の価値をベースに購入や契約するのですが、大規模システムになると決め手に欠けるのが現状です。

このように、ユーザーの視点が変わってきているとともに、ベンダーもサービス開発するときに、ウォーターフォールでの開発、アジャイルでの開発、ソフトウェアファクトリでの開発、AIとのペアプログラミングなど様々な方法が出てきています。その時の見積もりや品質管理、要員計画が難しくなってきています。

IT産業界での取り組み

国内の実務の定量管理という点では、前述のようにIPA、JUAS、経済調査会などが取り組みをしていますが、それ以外も含め全体がどう取り組んでいるのかを整理する必要があります。

まず全体像として、情報サービス産業協会(JISA)が情報技術マップとしてソフトウェアエンジニアリングも含む関連技術のマップ化をしています。

また、電子情報産業協会技術(JEITA)もモデル契約や組み込みソフトなど調査研究をしており毎年ソフトウェアエンジニアリング技術ワークショップを開催しています。プロダクト脆弱性などに関してソフトウェア協会（SAJ）、組み込みソフトに関して組込みシステム技術協会（JASA）　ソフトウェア品質に関して日本科学技術連盟(JUSA)が毎年ソフトウェア品質シンポジウムを開催する等、様々な団体が取り組みを進めています。
これらを俯瞰することで、なんとなく全体の姿が見えてきます。

一方、ベンダーにとっての最大の課題は、ソフトウェアエンジニアリングで頑張るインセンティブがないことです。人月でビジネスしている中で生産性向上したら売り上げが減るだけですし、品質もほどほどにすることで保守、運用費が稼げます。
以前、「このベンダのシステムは安定的に稼働しているから運用コストを削減しよう」と、あるITコンサルが提案し大幅コストカットを実現したことがあります。この時は、品質の高いシステムはコストカットされ、品質の低いシステムに厚く払うというのではモラルハザードを引き起こすと大きな問題になりました。

このように生産性や品質の向上の検討が難しい業界構造になっています。

アカデミックの取り組み

学会では、情報処理学会の中にソフトウェア工学研究会があり、毎年ソフトウェアエンジニアリングシンポジウムを開催しています。以下の分野の論文を募集しています。

要求工学
分析・設計技法
テスト技法
ソフトウェア保守と進化
システム評価・管理技術
開発支援環境
ソフトウェアプロセス
ソフトウェア開発マネジメント
形式的手法
ソフトウェアセキュリティ
ソフトウェアシステムの安全性
ソフトウェア工学教育
実証的ソフトウェア工学
リポジトリマイニング
ソフトウェア開発の科学（ソフトウェアサイエンス）
プログラミング言語
オブジェクト指向技術
AIと知識ベースのソフトウェア工学
クラウドコンピューティング
IoT時代のソフトウェア工学
帰納的に定義されたソフトウェアシステムの開発方法論
量子計算などの新しい計算パラダイムに対するソフトウェア工学
ソフトウェア工学に関するメタ研究
その他ソフトウェア工学に関するテーマ全般

また、日本ソフトウェア科学会も毎年ソフトウェア工学の基礎ワークショップを開催しています。

このように脈々とソフトウェア工学の検討は行われています

ITユーザーの取り組み

以前から日本情報システムユーザー協会（JUAS）がユーザーの視点からソフトウェアエンジニアリングに積極的に取り組んできました。最近はユーザーもデジタル時代のサービスをどう実現するかのDXの重要性に着目し、その一環で様々な検討が進んでいます。一方で、従来のような定量管理の仕組みが通用しなくなってきており、システム導入にコマあっているユーザーも多く見られます。
ソフトウェアエンジニアリングもユーザーの視点をもっと強化して未来の姿を考える時期にきているのではないでしょうか。

そしてモデリング分野はどうなったか

全ての関係者に影響するモデリング手法は日本でなかなか普及しないのですが、さすがにデジタル時代になってそれでは成り立たなくなってきています。サイバー空間と現実空間の一体化の取り組みが進む中でモデリングを無視して物事を進めることが難しくなってきています。

もともと日本はモデリング思想が弱く、おもてなしというかカスタマイズ思想が強い国民性なのではないでしょうか。モデルやマニュアルではなく、「間」を埋めるのが強みという人もいます。

そのため、ソフトウェアだけではなく各分野のモデリングツールで苦戦をしています。世界の主なモデリングツールを見ると以下の通りです。
　　文書：word
　　表　：Excell
　　業務モデル：Enterprise Architect等
　　　　　　（記述手法が標準化されており多くのツールがある）
　　図面：Autodesk、CATIA
　　地図：ESRI
文書？と思われるかもしれません。しかし、文書もスタイルなども使ってテンプレート化し情報を構造化するモデリングをしています。表も一種のモデリングととらえることができます。

CATIAは３Dモデリングツールとして有名ですが、もともとはフランスのダッソー社が自社の航空機を作るために作っていたモデリングツールを販売したものです。
実はモデリングツールはユーザーサイドのニーズから生まれるものが多くあります。ERP、BPMSなど、業務分析を極めるうちにモデリング手法が独自に進化しているものがあります。日本は、製造、部品、アニメなどの各分野において最先端のユーザーを持ちながら、それを汎用化できないうちに気が付いたら海外製のモデリングツールを使っているのではないでしょうか。

モデリングツールのバージョンアップが世界に半年遅れたら自社の製品開発の競争力に影響が出るのではないか。そのような観点から考えていくことも重要になります。

また、オープンソースのモデリングツールにも注目が集まっています。機能レベルは様々ですが入門編としていじってみたらどうでしょうか。

今後はモデル＆シミュレーションが重視され、デジタルツインを実現する上でもキーとなる技術です。自動車をはじめとした製造業、金融、医療、都市計画とあらゆるところでシミュレーションが使われています。
モデリングを単にツールの問題ととらえずシステムや社会改革を図るための重要な要素として考えていくことが重要です。

国外が何をしているか見てみよう

Carnegie Mellon University Software Engineering Institute

ソフトウェアエンジニアリングと言えば、誰もが思いつくのがCMUのSEIです。世界のソフトウェアエンジニアリングを引っ張ってきており、昔、IPAにソフトウェアエンジニアセンターを作った時にも参考にした組織です。最近はAIやセキュリティに特に力を入れていますが、ソフトウェアエンジニアリング全体を見ていて、以下の分野をテーマとして整理しています。

さらに、2019年にArchitecting the the Future of Software Engineeringというレポートを発表しています。

SoftwareEngineeringResearchRoadmapwithFocusAreasandResearchObjectives(10–15YearHorizon)

この外縁になる6つのリサーチ重点エリアは以下になります。

AI-Augmented Software Development
Assuring Continuously Evolving Software Systems
Software Construction through Compositional Correctness
Engineering AI-Enabled Software Systems
Engineering Socio-Technical Systems
Engineering Quantum Computing Software Systems.

また、今後に向けて以下の8つのリコメンデーションをしています。

Enable AI as a reliable system capability enhancer. The software
Develop a theory and practice for software evolution and re-assurance at scale.
Develop formal semantics for composition technology
Mature the engineering of societal-scale socio-technical systems
Catalyze increased attention on engineering for new computational models, with a focus on quantum-enabled software systems
Ensure investment priority reflects the importance of software engineering as a critical national capability
Institutionalize ongoing advancement of software engineering research
Develop a strategy for ensuring an effective workforce for the future of software engineering

IEEE STC（Software Technology Conference）

ソフトウェアエンジニアリングを扱う会議として有名なIEEEのSTCの2023年の論文募集テーマを見ることで最近の主な技術動向を見ることができます。

Fraunhofer ISST(Fraunhofer Institute for Software and Systems Engineering)

ドイツの研究、標準機間であり、ソフトウェアエンジニアリングを扱ってきています。最近は、データスペース等のデータに関連した取り組みに注力しています。
以下が、ISSTの専門領域です。

各専門領域の詳細は以下になります。

Software engineering

Technical conception and architecture development
Development of system components
Consulting services in the software development process

Cloud Transformation

Dimensionen und Charakteristika von Cloud Computing (in Anlehnung an Rosian et al. 2021)

Strategic data management

Data Science

Data quality control in data lake architectures

Data spaces and data ecosystems

Eclipse Dataspace Components
Business models for ecosystems

Free and Open-Source Software (FOSS)

Development of FOSS
Strategic use of FOSS

inria

フランス国立情報学自動制御研究所で、ソフトウェアエンジニアリングを長年研究してきています。最近はAI等の利用面の強化をしてきました。
以下がinriaの研究領域です。

2023年6月に、ソフトウェア・パブリッシャのBerger-Levrauntと協力してソフトウェアエンジニアリングの新しいチームEVREF（Reflexive Evolution of Ever-Running Software Systems）を立ち上げました。旧来型のソフトウェアをモダナイズしてリエンジニアリングすることを目指しています。
このチームでは、ソフトウェアモダナイゼーション、開発ツール、仮想マシーンの3つを柱に据えていきます。また、従来からのソフトウェアの分析やプログラミング言語の設計をしていたRMoDの取り組みも含みます。
このチームが作ったツールは、オープンソースやデータの分析プラットフォームのMooseに統合していく予定です。

DoD software modernization strategy

米国のソフトウェアエンジニアリングは、研究機関の取り組みだけでなく国防省（DoD）の取り組みも見ていく必要があります。CMUのSEIの予算もDoDの予算がかなりの割合で入っていますし、IEEE STCも昔はDISA（Defence Information System Agency）の発表がかなりありました。

現在は、DoD software modinization strategyを推進しており、以下のゴールに向け取り組みを進めています。

Goal 1: Accelerate the DoD Enterprise Cloud Environment
Goal 2: Establish Department-wide Software Factory Ecosystem
Goal 3: Transform Processes to Enable Resilience and Speed

SWEBOK（Software Engineering Body of Knowledge）

ソフトウェアエンジニアリングを体系的に学ぶためにSWEBOKという知識体系があります。現在、第4版のレビューが行われているところです。
ソフトウェアエンジニアリングを18の分野で体系化しています。

1. Software Requirements
2. Software Architecture
3. Software Design
4. Software Construction
5. Software Testing
6. Software Engineering Operations
7. Software Maintenance
8. Software Configuration Management
9. Software Engineering Management
10. Software Engineering Models and Methods
11. Software Engineering Process
12. Software Quality
13. Software Security
14. Software Engineering Economics
15. Software Engineering Professional Practice
16. Computing Foundations
17. Mathematical Foundations
18. Engineering Foundations

また、7つの関連分野を定義しています。

1. Computer engineering
2. Computer science
3. General management
4. Mathematics
5. Project management
6. Quality management
7. Systems engineering

次世代のソフトウェアエンジニアリングに向けて考えること

ソフトウェアをめぐる環境が大きく変化してきています。利用者にとっては、素早く環境変化に追随したサービスを実現することが求められ。ソフトウェア開発者には、そのサービスを提供するための変化に強いソフトウェアや素早くサービスづくりができる環境整備が求められます。この2つの視点から考えていくことが必要ではないでしょうか。

サービス利用者に向けたエンジニアリング

デジタル化にあたり、業務の要求が実現していることはもちろんのこと、なんといっても利用者の関心はコストや納期そしてセキュリティ含めた安定稼働です。さらに、中長期に活用できる柔軟性や拡張性が求められます。
システムやサービス構築の選択肢が増えてくる中で、ユーザーが適切なソリューションを選べるような判断の方法とかがあればよいなという声はよく聞きます。またシステムやソフトウェア以前に、要求定義、要求管理の方法、パフォーマンスもしくはバリューベースで考える投資額決定の方法、モデルベースで可視化し、柔軟性、移行性が高い仕組みを作る方法を示していくことが求められているのではないでしょうか。

ソフトウェア開発者向けのエンジニアリング

社会や技術の変化により産業構造が変わっている中で、単体ソフトウェアやシステムではなく全体を幅広く考えていくというスコープ拡大の視点、AIとのペアプログラミングやデータベース構造の変化等の技術変化の視点を反映していく必要があるのではないでしょうか。特に設計工程において、Security by Design、Interoperabirity by Designなど、最終アウトプットを見据えた取り組みが求められています。さらに、クラウドやエッジの扱いをどうするべきも全体像の中で考えていく必要があります。
この辺りは海外の動向を見ながら深く掘っていく領域なのかなと思っています。

対象によってもアプローチが違う

エンタプライズ系のソフトウェアエンジニアリングを中心に書いてきましたが、ソフトウェアは家電製品や自動車などあらゆるところに組み込まれています。センサーネットでもエッジのデバイスの中にソフトウェアが入っていることがあります。
また、設計時のSecurity by Designや運用時のDevSecOpsを考えるとともに、高度なセキュリティが必要なシステムでは相応の管理方法が必要になってきます。
このような様々な対象に対して検討を進めていく必要があります。

ソフトウェアエンジニアエンジニアリングとシステムズエンジニアリング

そもそもソフトウェアエンジニアリングの外縁がどこなのかという議論があります。ソフトウェアエンジニアリングの体系であるSWEBOKではソフトウェア要求から入っておりプロダクトベースの取り組みに見えます。

しかし、社会全体が複雑化していることから、ソフトウェアエンジニアリングの世界でもソフトウェア間、システム間の連携が増えてきており、当然、活用する姿をイメージしてサービス全体としてのシステムズエンジニアリング的視点から設計をしています。
システムズエンジニアリングは、具体的に推進するときにアーキテクチャやUMLを拡張したSysMLが使われますが、アーキテクチャはソフトウェアエンジニアリングでも使われる手法です。

システムズエンジニアリングがあって、それを具体化するためにソフトウェアエンジニアリングがあるという人もいますが、2分せずに全体をとらえ、うまく手法を組み合わせて推進していけばよいのではないでしょうか。

具体化に向けて

この10年間、ソフトウェアエンジニアリングはあまり着目されてきませんでしたが、2025年の崖まであと2年です。レガシーシステムの刷新、人材不足への対応としても、ソフトウェアエンジニアリングに正面から向き合っていきたいと思います。

この記事が気に入ったらサポートをしてみませんか？