ソフトウェア開発の複雑性増大を受け
MBSE、プロダクトライン開発の導入へ

　1921年5月に石川県小松市で設立した小松製作所（コマツ⁠）⁠。建設機械、鉱山機械、産業機械の開発、生産、販売、サービスにかかわるビジネスの展開で知られる同社は、グローバルな市場で大きな躍進を遂げてきており、世界各国の拠点で生産からサービスの提供までをまかなえる体制を整えている。最近では、自動化、自律化、遠隔操作などにかかわる先進の機能を搭載した未来建機の開発、安全・生産性および環境負荷低減に貢献するプラットフォームやソリューションの整備、そしてICTを駆使した農林業のスマート化の推進を3つの重点領域に定めて取り組みを強化しているところだ。

　コマツが、その提供する建設機械などの制御ソフトウェアの設計に取り組み始めたのが1983年のこと。当時は自動車業界でも、エンジンユニットに続いてトランスミッションへの電子制御の導入が始まった頃で、それと時を同じくしてコマツでは、ポンプやHSTモーターの電子制御によるブルドーザの量産化を開始している。そうした意味でコマツは、その頃から一貫して進取の精神に富んだ企業だったことが伺える。

　「⁠当時は、建設機械に搭載される制御コントローラは1つだけで、システム開発部門の人員もあまり多くなかったこともあって、1人のエンジニアがハードやソフトも含めて1つの機種全体にかかわる設計・開発を担当。いわゆる職人と呼ばれるような人たちが活躍していた、そんな時代でした」とコマツの上義樹氏は語る。

　その後、1990年代には、カーエレクトロニクスの分野では多くのサプライヤの参入が進んで急激に進展していくことになるが、これに対し建設機械の業界はというと、自動車に比べて生産台数が少ないということもあり、サプライヤの参入が思うほど進まず、コマツでは引き続き職人がハードウェアもソフトウェアも1人で面倒を見るという状態が続いたという。

　そして2000年代に入るとコマツでは、近年、IoT（Internet of Things）やデジタルトランスフォーメーション（DX）に関する話題の中で頻繁に取り上げられている、建設機械の情報を遠隔で確認するためのシステム「KOMTRAX」を開発。その一方で、建設機械の制御におけるソフトウェアの占める比重が急速に増大し始めた。それを受けてコマツでも、ソフトウェアの設計・開発を行う組織を拡大。「⁠それまでの、複数人の職人が個々に設計・開発を手掛けるという時代から、チーム開発の時代へと進むことになりました。それに伴い、オブジェクト指向やV字プロセスといったものも導入しながら、チームメンバーが同様の手法、同様の品質で仕事ができるようにするための取り組みを推進していく運びとなりました」と上氏は説明する。

　そうした取り組みが進み、設計・開発の標準化されたプロセスが確立されていく中で、複数のコントローラを使ったシステムの構築も可能となり、例えばハイブリッドショベルやICTショベルのような複雑な制御を必要とするような分野にも挑戦していける体制が整うことになる。「⁠その当然の帰結として、システムプロジェクトの規模はさらに大きくなり、全体の設計・開発を自社のみで完結することが困難になり、社外のリソースも積極的に活用していく必要があります。そうしたことを念頭に当社では、MBSE（Model Based Systems Engineering⁠）⁠、プロダクトライン開発の導入が不可欠であると考えました」と上氏は語る。

製品のコンセプトや設計意図を整理し
適正に機能検討を進める体制が必要

　こうした取り組みに向けコマツでは、2006年に「Enterprise Architect」のライセンスを初めて購入。以降、その本格的な活用を進めていくことになる。EA利用開始当初は、クラス図やアクティビティ図といった設計ダイアグラムの作成に利用。「⁠もっとも、ソースコードベースでの設計・開発に馴れ親しんできた人たちに、世の中で流行っているからモデルを書きましょうといっても、なかなか耳を貸してはくれません。そこで、作ったモデルに基づいてコードの雛形や単体テスト用のスタブを自動生成できるようなアドインを作成。そうしたこともモチベーションとしてもらうことで、モデルベースによる設計が文化として根付いていくよう工夫を行いました」と上氏は紹介する。

　その後、2013年にはSysMLのアドインを導入。Enterprise Architect上で要求図やブロック定義図、内部ブロック図の作成できる環境を整備。これにより、V字プロセスの左上から左下まで、すなわち要求分析から要求定義、基本設計、詳細設計、コーディグに至る各フェーズをシームレスに実践していける体制を整えることができた。

　そもそも同社が、Enterprise Architectの活用によるMBSEやプロダクトライン開発に取り組み始めたそもそもの経緯については、コマツという会社の特徴についても言及する必要がある。1つには同社が徹底した自前主義を貫いているということ。すでに述べたように、同社では建設機器に搭載するコントローラのハードウェアやソフトウェアの設計から実装・テストまでを自社で実施しているわけだが、そのほかにもエンジンや油圧機器など、車両のキーとなるコンポーネントについてもすべて自社で開発・生産している。もう1つは、広範な顧客のニーズに対応した製品をラインナップしているということ。具体的には、個々の製品については、利用する地域や顧客の用途に合わせた様々な亜種が存在している。そのため、どうしても多品種少量生産にならざるを得ない。

　「⁠ソフトウェア開発においても設計技術の社内標準化などを行い、繰り返しブラッシュアップしてきたわけですが、そうした自前主義や多品種少量生産に起因して、どうしても開発時間が逼迫してしまい、その場しのぎの対応が多くなってしまうという課題を抱えていました」と上氏。結果、その機能が生まれた背景や設計意図が明文化されなかったり、ソフトウェアの構造や部品の共通化も不十分にならざるを得ないという問題が生じていた。「⁠いままでのやり方の延長ではうまくいかないという危機感があり、ますます複雑化する製品のコンセプトや設計意図をきちんと整理し、検討していくという『堅実さ』と『素早さ』を兼ね備えた新たな開発体制を構築していくことが必要だと考えました」と上氏は続ける。

　そして、そうした複雑化する製品のコンセプトや設計意図をきちんと整理し、それに沿った機能検討を進めていくための施策としてコマツが選んだのが、MBSEを導入して要求と機能のつながりを見える化することだった。それにより、一人ひとりの設計・開発者の頭の中にある知識を組織の財産として共有していく。それが全体のレベルアップを目指すうえでのカギになると考えたわけだ。

　また、開発が複雑化し、実務人数の規模が大きくなれば、どうしても統率が取りにくくなる。そうした中で、他機種で同じような機能のバリエーションがあることを知らず、機種固有のソフト部品として作ってしまうという問題もある。例えば、よく考えれば既存の機能と同じなのに、改めて作成してしまうというケースだ。これにより工数がムダに膨らんでしまうわけだ。

　「⁠それには明示的に機能の共通化を図り、バリエーションを適切に管理することが必要です。もちろんそれは、単に設計図が存在していれば済むという問題ではありません。こうした問題を解消するために我々が導入したのが、プロダクトライン開発だったわけです」と上氏は説明する。

　プロダクトライン開発とは、同じ系列のソフトウェアを効率的に開発するため、再利用可能なソフトウェア資産を整理して、そこから個別のプロダクトを生み出していくというスタイルを言う。場当たり的に再利用を行うのではなく、対象とするプロダクト群を最初に明確に定義し、そうした対象を網羅するかたちで、再利用のためのコア資産の基盤を構築していくというかたちだ。「⁠機能のバリエーションとバリエーションポイントを適切に管理して、似て非なる機能を作らせないようし、共通機能として統一的に管理されたソフトウェア部品を安心して使い回せるような仕組みの構築を目指しました」と上氏は語る。

ソフト部品のコア資産を構築すれば
全機種を網羅する設計・開発が可能

　では、コマツがEnterprise Architectの活用により実践する、MBSEに基づくプロダクトライン開発のアプローチとは具体的にどのようなものか。これに関し同社では、MBSEにより「要求」から「論理構造」「⁠振る舞い」までを一気通貫で結びつけ、シミュレーションモデル（MBD）と連携して、妥当性を素早く検証できるようにすることを念頭に取り組みを進めている。

　開発するソフトウェアが制御の対象とする建設機械には、ショベル、ローダ、ブル、ダンプ、グレーダといった様々な種類がある。その種類自体は異なるが、実際にそれらがこなす仕事という観点で捉えると、「⁠掘る」「⁠運ぶ」「⁠積み込む」「⁠押す」「⁠持ち上げる」「⁠均す」といったかたちで集約できる。さらに、それらの仕事を実現するための動作としては「走る」「⁠向きを変える」「⁠作業機を動かす」の3つに整理できる。こうしたかたちで、仕事と動作が決まれば、エンジンや油圧機器などの構成要素がおよそ決定される。

　このように動作が決まれば、必要な制御が決まり、構成要素が決まれば、構成要素を動かす制御も決まることになる。そして、構成要素の形や大きさが、機械の動作する現場環境や対象物により変わり、それによって各種のパラメータが変化することになるわけだ。「⁠こうしたことを踏まえると、機能のバリエーションというのは、構成要素や機械の大きさなどによって生じることになり、動作の制御、モノの制御を統合したソフトウェア部品のコア資産を適切に構築できれば、すべての機種を網羅するソフトウェアの設計・開発がこの基盤をベースに行えるということになるわけです」と上氏。つまりこれが、コマツにおけるプロダクトライン開発の礎となる考え方だ。

すべてのバリエーションを網羅する
「150%」クラス、アクティビティ図

　こうした考え方に依拠してコマツでは、コア資産を構築する作業である「ドメイン開発」を進め、ドメイン開発の結果できたコア資産から個々の機種ごとのソフトウェアを導出していく「アプリケーション開発」のための環境整備に取り組んだ。

　ドメイン開発について、既に存在している機能をコア資産化していくというアプローチを紹介した。具体的には、既存資産の振る舞いの分析を行い、どのような入出力があるのか、どんな処理を行っているかをアクティビティ図に書き出す。「⁠こうした作業は、既存ソフトウェアの中身を十分に知っている人からすると、ともすればムダな作業と捉えられることもありますが、知識の共有と整理のためにはぜひとも必要な作業だと考えます」と上氏は語る。

　振る舞いの分析が完了したら、今度は分割の検討である。アクティビティ図の処理部分に注目すると、特定の意味を持つ処理群にまとめることができる。これを分類して、論理的なブロック定義図を作る。またこの時点で、機種横断でどのようなバリエーションが存在し、そのバリエーションポイントは何かということも情報として残している。

　続く要求分析のフェーズでは、先ほどのブロック定義図で作成したブロックを要求図の一番下にもっていって、処理から上位の要求、さらに上位の車体レベルの要求というところまでつないでいくかたちで要求図を作成。「⁠どんな処理をしているかということがわかっていても、理由がわからないケースもあり、またハードと組み合わせることではじめて機能が実現されているという隠れた要求もあります。そうした点については、抜けや漏れを回避するために有識者を交えてしっかりと確認しています」と上氏は言う。

　そして、要求図が作成できたら、今度はバリエーションの分析と統合を行い、要求図をベースに可変性図を導出し、機能ごとのバリエーションとバリエーションポイントを示し、バリエーションごとの処理の違いを明らかにする。また可能ならば、このタイミングでバリエーションを統合して管理すべき数を減らすといったことも行っている。

　そうした後、フィーチャーモデルを作成する。具体的には、Enterprise Architect上でまとめた可変性図を、プロダクトライン開発の支援ツールとして広く用いられているpure::variantsに展開することになる。「⁠pure::variants自体、設計に利用するツールではなく、あくまでも可変性図で設計したものをそのまま展開。バリエーションやバリエーションポイントを見やすく可視化できます」と上氏は説明する。

　続いて「150%クラス図」を作成する。150%クラス図とは、対象とする機能のすべてのバリエーションを網羅するクラス図を言う。同様にアクティビティ図についても「150%アクティビティ図」を作成。そして、このアクティビティ図を基に、これもすべてのバリエーションを網羅した「150%ソースコード」作成する。このとき、アクティビティ図で表現した制約、つまりバリエーションの紐付け情報をコード内に埋め込んでおり、どの処理がどのバリエーション固有のものか、どの処理が全バリエーションで共通かを踏まえたかたちでコードを作成している。

派生機種の開発にかかる工数低減
バリエーション管理コストの削減を見込む

　以上のような手順によるドメイン開発で準備したコア資産をもとに、アプリケーション開発を進めていくことになる。「⁠やり方としては、コア資産開発チームが作成したフィーチャーモデルで、どの機能を利用するか、機能ごとのバリエーションがあれば、そのうちどれを利用するか、どういう構成要素をとっているかという選択を行い、pure::variantsを実行すると、150%のものから不要な部分を消した『100%クラス図』『⁠100%アクティビティ図⁠』⁠、そして『100%ソースコード』がそれぞれ抽出されます」と上氏は説明する。各アプリケーションの開発担当者は、これら100%のクラス図・アクティビティ図を設計図として手に入れて、100％ソースコードを結合してソフトウェアを作成する、という流れとなるわけだ。

　コマツではここで紹介した開発プロセスを次期機種の開発から実践していくことにしているという。「⁠未実施の現状では、その効果は未知数ですが、派生機種の開発にかかる工数の低減、不要なバリエーションの削減による管理コストの低減という効果は確実に得られるものと見込んでいます」と上氏は胸を張る。そして、こうしたソフトウェアの設計・開発における「堅実さ」と「素早さ」の実現は、単に個々の機械を提供するだけではなく、現場の課題解決や使いこなしなども含めたトータルなサポート、ソリューションの提供を目指すコマツの取り組みに、大きな貢献を果たしていくことになるものと期待されている。

　なお今回のセミナーでは、以上のコマツ 上氏の講演のほかにも、2つのセッションが執り行われた。1つは宇宙航空研究開発機構（JAXA）によるのもので、人工衛星の運用を主体とする論理設計部分の可視化や、関係者間の円滑な情報共有による開発品質の向上を目指したMBSEの活用事例が紹介された。またもう1つは、伊藤忠テクノソリューションズによるセッションで、同社が参画したチケット予約サイトの構築プロジェクトにおけるモデリングを中心としたシステム開発の事例が語られた。

　今日、ソフトウェア開発をめぐる生産性や品質向上にかかわる要求がますます高まる中、今回の「Enterprise Architect 事例紹介セミナー」で解説された、Enterprise Architectの活用を中心にMBSEがもたらすメリットを最大化するための取り組み事例の数々は、参加者に様々な“⁠気づき⁠”を提供することにつながったはずだ。