[学習] IBM Engineering Lifecycle Management　IBMのエンジニアリング・ライフサイクル管理（ELM）

はじめに

書棚を整理していると基礎から再学習した MBSE （モデルベースドシステムズエンジニアリング）ノートを見つけた。日頃からシステム開発 V字モデル, スクラムを伴う CI/CD パイプライン企画からサービス継続化までのプリセールス活動に専念していますが、改めて現代のシステム・エンジニアリングのソフトウェアとソリューションについて学習を深めました。

IBM ELM 学習経験

昨夏より ML/AI エンジニアリング (MLOps) 案件が急増しており、IBM ならばどのようなアプローチでエンジニアリングモデルを管理するのか興味があり学習を始めました。私はどこかのベンダーに傾倒せず、良い考え方は貪欲に採り入れ実務に活用する学習スタイルです。

学習証明となる知識証明バッジ
2023年1月14日 IBM Engineering Lifecycle Management Sales Foundation V2 （有効期間 2024年1月14日まで）合格。
エビデンス：IBM Engineering Lifecycle Management Sales Foundation V2 – Credly

今回の学びを通じ新たな知識証明バッジを取得しました。
2023年4月11日 IBM Engineering Lifecycle Management Technical Sales Intermediate (有効期限 2024年4月11日まで）
エビデンス：IBM Engineering Lifecycle Management Technical Sales Intermediate – Credly

基礎知識の資料

高度情報処理技術者として役割推進していれば自ずと継続学習に向かい、リファレンスとするのは IPA が基本になるのではないでしょうか。すぐに資料の在り処が思いつくのは何度も繰り返し活用してきたからです。特にベンダー傾倒しないためにも我が国のアプローチを理解することが肝要と考えます。

非ウォーターフォール型開発 WG活動報告書, SEC, 平成 24 (2012) 年 3 月 26 日改訂, IPA
https://www.ipa.go.jp/archive/files/000004613.pdf

モデルベースシステムズエンジニアリング導入の手引き, 2013 年 8 月, IPA
https://www.ipa.go.jp/archive/files/000033609.pdf

上流品質技術強化　MBSE 導入の手引き, SEC journal Vol.9 No.2 Jul. 2013, IPA
https://www.ipa.go.jp/archive/files/000066524.pdf

システムズエンジニアリングの上流設計プロセスについて, SEC journal Vol.12 No.4 Mar. 2017, IPA
https://www.ipa.go.jp/archive/files/000057568.pdf

IBM ELM 特徴

主要機能については次のブログをご覧ください。
IBMのエンジニアリング・ライフサイクル管理（ELM）主要機能 | IBM ソリューションブログ

このブログを取り上げたのは次の理由からです。
・System of Systems を念頭にしている。
・要求・要件管理を Watson による品質向上の概要説明がある。
・MBSE 手法を採り入れた自動車開発向けラプソディ (Rhapsody) に触れている。
・テスト管理・品質管理の説明が極めてシンプルで分かりやすい
・プロジェクト管理・トレーサビリティをプロセス管理とレポート・ダッシュボードを効果的に使う説明がある。

チーム生産性向上

ELM に限定することなく、あらゆる業種、職種においてチーム生産性向上に寄与するのは人間が基本ですが、分散した複数のチーム（名刺上のチームに限らず、プロジェクト毎のチーム。海外拠点を含むこともある）を繋げ、リアルタイムで同じ情報を共有し、自動化できるプロセスと状況はもとより開発ライフサイクル全体で品質管理をするのは IBM ELM などの管理基盤が必要不可欠です。基盤導入は目的ではなく、管理基盤を全員が利用することで、チーム全員がリーダーシップを自ずと発揮する作用が生まれます。その結果としてチーム生産性を高められると考えます。
Excel など二次元テーブルによるプロセス管理はメンテナンスを含め非現実的ですよね。こうした管理が不十分な状況が続くと何が生まれるのか。メンバーの活動意欲低下はもとより…。

※チームワークや組織開発（組織科学）について、私は日頃から福祉現場を含め学際的研究として継続している領域のため今回は気持ち少し抑え気味の内容です。

「プロジェクトが失敗する原因の47%は、要求管理が不十分だったことに依存する」＝リスク管理

これは今さらながらですが、PMBOK, BABOK などの知識体系を持っているだけでは無意味。だからこそ、要求・要件管理は常に行う必要があります。縦割りでしか業務遂行できない組織は残念ながら山ほどあり、慢性的に Project Manager を SES が募集しているのが日本の ICT 業界の異常さではないでしょうか。

Manager といっても権限は無いのが当然で、組織科学を活用できる方が立場を抜きにして推進し続けること（壁はぶち壊して関係構築を積極的に図れる環境）が成功するプロジェクトに多いと実感します。手戻りを想定していないウォーターフォールモデルでしか活動できないチームが破綻するのは20世紀から目にしています。だけど、ウォーターフォールモデルだから破綻したのではなく、要求管理（リスク管理）が不十分だったことに起因することが科学的研究から明らかとなっており、権限と管理を混同する方が多いのも専門職教育が弱い我が国の特徴であるとも個人的に憂うところです。

参考資料：
紛争事例に学ぶ、IT導入講座, 17.Jan 2019, 経済産業省 CIO補佐官細川義洋氏
https://www.meti.go.jp/policy/digital_transformation/asset/meti-dx/20190131/course05.pdf