システムズエンジニアリング雑感
僕はそれらしい場に行くと「〇〇(それなりに知名度のある企業)の〇〇(それなりに関心が高い分野)でシステムズエンジニアリングを推進する立場です」と自己紹介しています。
そもそもシステムズエンジニアリングの推進ってなんだよ。
システムズエンジニアリング(広義) vs システムズエンジニアリング(狭義) vs 「それって普通のシステム開発ができていないだけじゃない?わざわざシステムズエンジニアリングってやる必要あるの?」の宗教戦争
現在現実に宗教間で戦争が行われているので宗教戦争という言葉を使うのは不謹慎かも知れませんが、これは宗教戦争と言っても差し支えないのではないかと思っています。というか見飽きた。まずシステムズエンジニアリング推進派とか反対派がいる時点でおかしい。皆さんがお持ちの聖書から引用すると、
です。こんなのもうみんな10000回くらい唱えていると思うのに、ふた言目には要求定義だのアーキテクチャ定義だのが始まる。
システムズエンジニアリングやるべきかやらないべきか。
システムを成功裏に実現する = 大きな失敗なく開発する、とざっくり置き変えてさっきの一節を口語訳すれば、
となると、「システムズエンジニアリング反対派」の意見はつまり、
というナンセンスな意見になってしまうわけ。
システムズエンジニアリングは15288に従うとか従わないとかではなく、システム開発成功のためにみんなで頑張ることなんだよ。だから今御社で行われている謎の儀式も禍々しいマクロもハンコ3兄弟もひろーい意味で言えば御社にテーラリングされたシステムズエンジニアリングなわけ。
システムズエンジニアリングやるとかやらないとかは的ハズレな話で、みんな多かれ少なかれシステムズエンジニアリングをやってるわけですよ。それが国際的に標準化された方法に近いとか遠いとかは別の話。
困っているのか困っていないのか
じゃあここでシステムズエンジニアリング大好きっ子の我々が胸に手を当てて考えるべきは「今我が社は困難に直面しているか?」である。
これにバカでかい声でYES!と答える勇気がないのであれば試験室に行って振動試験無限編とかやった方が100倍いい。困ってもいないのに始まる改善活動ほど悲惨で迷惑なものはない。
とはいえ深夜にPCに向かってバカでかい声でYESと叫ぶ人のためにも続きを書く。
「困りごとは会社で知見が属人化してしまっていること?」
たぶんそう/部分的にそう
・
・
・
なんで知見の属人化の対策がSE/MBSEなんなんだよ。
2ヶ月くらい問答部屋にぶち込んで10000枚くらい仕様書書かせる方が早くて楽では?
システムの設計検討がザルでまともなレビューも行われていない組織に所属しているラッキーなあなたへ
システムズエンジニアリングハンドブックを開いてみましょう。ほにゃほにゃ定義プロセスだとかみょんみょん定義プロセスだとか書いてあります。これに従って成果物を作っていくとあら不思議。システムが成功裏にどうのこうのです。
そんなわけあるかーい。ってかあんなの全部やり切れるかーい。
結論:この辺の議論を会社でするのはムダ
おぢ(62)「それって普通のシステム開発ができていないだけじゃない?わざわざシステムズエンジニアリングってやる必要あるの?」
これが正しいです。日本企業のそこそこちゃんと頑張ってきたベテランエンジニア(62)の言うことが一番正しい。3匹の子豚もそう。
というかこういうエンジニアは野良で15288の御社テーラリングバージョンみたいなものを編み出している可能性が高いので長いものに巻かれてゴマ擦ってにゃんにゃんごろーんした方が早くて楽です。
でも舶来武器を持った倒幕派が勝ったじゃん
それもそう。おぢ(62)の野良システムズエンジニアリングプロセスは現代だと無理が生じることが多い。大体がそんな検討工数ねえよ、だとか、そんな検討に他の部署が工数割いてくれねえよ、だとかいう話。
その辺の現実的でしょーもない困り事を解決するのがシステムズエンジニアリング推進グループの皆さんの仕事です。その時にISO/IEC/IEEE 15288をチラ見すると役に立つ可能性が微レ存。まあ役に立たないかな。
残念でした。アームストロング砲撃ちたかったねえ。
はい、ここまでぜーんぶ嘘です。うそうそ。
MBSEはSysMLだしワクチンは政府の陰謀です。
みんながハッピーな世界で生きようね。
次回予告
MBSEはMBDの親戚
ウォーターフォール型を半分に折るとVモデル型開発になる
コンサルだいすき
平日ど真ん中の深夜に書くもんじゃねえな。ネットで買えるおいしい中国茶の情報待っています。蜜蘭香飲みたい。