MTIジャーナル

MTI Journal.18

自動運航船プロジェクトと
モデルベースアプローチ

栁原 智哉


船舶物流技術グループ 主任研究員

2022年6月15日掲載

※職名は2022年6月15日時点

 

2020年1月からMTIへ出向し、自動運航システムに関する研究に従事しています。出向元では、船舶の通信ネットワークの構築や航海系機器のデータ収集装置、陸上からの船舶監視システムといった情報通信技術を活用したシステムの開発に携わってきましたが、海運業界そのものや船舶の運航・操船に関する知見が乏しく、本当に顧客の要求を満たすシステムやサービスを提供できているのか、自信がありませんでした。MTIでは、自動運航システムの開発をテーマとして自身のこれまでのシステム開発経験を活かしながら、船舶の運航・操船に関する知見を背景とした「システムに対する様々な要求」を体系的に整理する技術を身につけることで、システムの本質的な価値を捉えた適切な設計ができるエンジニアを目指しています。

自動運航船の具現化

「人々が欲しいのは1/4インチ・ドリルではない。彼らは1/4インチの穴が欲しいのだ*1

この言葉を聞いたことがある方は多いのではないでしょうか。これはマーケティングについて語られた有名な言葉で、「商品を売るためには、顧客にとっての『価値』から考えよ」ということを表現しています。
プロジェクトが失敗する原因は様々ですが、近年ますます複雑・高度化するシステムの開発では、システムの利用・運用の概念を表現するConOps(Concept of Operations)の策定や要件定義のように、システム開発の上流工程で正しく要求を把握・分析することが必要です。これらが不十分なために、システムの価値を見誤り、システムに対する正しい要求が獲得できず、間違った要求や過剰な要求に基づいてプロジェクトを進めるケースが多くあります。プロジェクトやシステムの規模が大きくなればなるほど、この上流工程、すなわちシステムの本質的な価値を明らかにすることが極めて重要となります。

MTIでは2020年2月から2022年5月にかけて、日本財団の無人運航船プロジェクト「MEGURI2040」に国内30社とDFFASコンソーシアム*2を組んで参画し、自動運航システムを含む、無人運航船の開発と実証に取り組みました。誰もが異なるイメージを持っているであろう無人運航船の実現プロジェクトにおいて、コンソーシアムにおけるMTIの役割はまさにこのシステム開発の上流工程において、具体的な無人運航船像を描くことでした。

無人運航船の実証実験に用いられた内航コンテナ船「すざく」

無人運航船のフリートオペレーションセンター

自動運航システムに関しては従来研究で培ってきた知見はあったものの、無人運航船となると、システムの監視や異常時の対応手段、船陸間の通信経路の確立、機関プラントの動作状況の把握など、ケアすべき課題がたくさん出てきます。また、コンソーシアムを組成する各社の技術やプロジェクトへの参加目的、参加者個々人のバックグラウンドは多様であり、無人運航船に対するイメージや価値観も異なります。このようにシステムの全体像や必要な機能について参加者の共通認識がない中、本プロジェクトで無人航行船を実現させるのみならず、数年後に実用可能となる技術を確立するために、開発初期段階において細部にまで具体的な無人運航船像を規定する必要がありました。

要求の正しい把握と管理

一般的に、プロジェクトのあらゆる関係者(ステークホルダー)の利害が最も交錯するところは、システムに対する要求に他なりません。要求は階層構造を持っており、ConOpsをトップとして、システムの概要レベルの要求(システム要求)やシステム全体の振る舞いに関する要求、システムの構成に関する要求、個別の機能に対する要求(機能要求・非機能要求)、それを実現するためのハードウェア要求・ソフトウェア要求、…と粒度が細かくなっていきます。このうち、ConOpsならびに上位の要求群はシステム開発とプロジェクトマネジメントの基盤となるため、プロジェクトの上流工程でしっかり定義するとともに、プロジェクトの進行とともにその妥当性を検証し、必要に応じて変更することが重要となります。

このような「要求を定義し管理する」というタスクは非常に高度であり、必ずうまくいくという魔法のような方法はありませんが、一方でこのタスクに適用可能なフレームワークや手法は世の中にたくさん存在します。MTIでは、モデルベースアプローチという考え方をベースに、システム開発の現場で実践されている思考のフレームワークやシステム分析手法、システム表現技法を取り入れながら、本プロジェクトに取り組みました。

階層構造である要求を正しく捉える

モデルベースアプローチとは

「MEGURI2040」での我々のDFFASコンソーシアムには多くの企業が参画していました。そのため、システムに対する要求やそれに対応するシステムの構成・振る舞いを整理するにあたっての大きな課題は、「プロジェクトのステークホルダーが共通の認識を持って議論を実施すること」でした。これをモデルを用いて解決しようというものが「モデルベースアプローチ」です。

モデルとは、物事をある側面(観点)から見て単純化したものです。物事を分かりやすく説明するため、あるいは物事について共通の認識や論点を持って議論を行うため、というように、モデルは特定の目的を持って作られます。MTIでは、日本郵船グループで開発した自律船フレームワークAPExS-atuo*3や、STAMP/STPA*4やGSN*5など既存のシステム分析手法、思考のフレームワークを用いて多数のモデルを作成し、ステークホルダーと議論を重ね、合意形成を進めました。言葉にすると非常に分かりにくく、時に曖昧になってしまうことも、モデルを作成し、それを確認することで情報をはっきりと、効率的に伝えることができます。まさに百聞は一見に如かず、です。

作成したモデルの一例

プロジェクト進行時の拠り所

モデルベースアプローチによって効率的に合意形成を実施することができましたが、無人運航船のように大規模なシステムの開発では、当然のことながら、プロジェクトの進行に伴って、合意形成した内容に修正が必要となる場面が出てきます。その際、問題となっている要求(仕様)がどの上位要求/下位要求とつながっているのか(要求の階層構造・トレーサビリティ)を、関係者で共通認識を持っているモデルに立ち返って思考し、議論ができたことで、その要求の影響範囲やシステムの本質的な価値に与えるインパクトの大きさを測ることができました。そのため、システムに対する要求の変更として、必要な作業は実施しそうでない部分はシステムの運用でカバーする、というように効率的にシステム開発を進めることができ、開発期間に制限のある中で手戻りの影響を最小限に抑えることができました。これは、システムの検証・評価段階で発覚した要求の不備や実装上の不具合についても同様です。常にモデルに立ち返って議論できるということが、これほど強いのかと身をもって感じることができました。

このように、モデルベースアプローチでシステムの開発・検証・評価を進めることで、2年間のプロジェクトは計画通りに進捗していきました。そして2022年2月26日から3月1日にかけ、無人運航船の実証実験として東京港と津松阪港(三重県 松阪市)間の約790kmの航行を、システムによる自動運航で実現することができたのです。

実証実験成功後、「すざく」の前にて(前列、中央が本人)

自動運航船の実現に向けて

モデルベースアプローチの礎は、論理的な思考と階層構造化(抽象度のコントロール)によって対象を俯瞰的に、多視点で見ることで、対象の本質を捉えることです。今回は無人運航船の開発、というテーマで本アプローチを実践しましたが、この礎の部分はシステム開発やプロジェクトマネジメントだけでなく、ビジネス企画や調達、組織マネジメント、あるいは経営そのものなど、意思決定や問題解決・分析・戦略立案が関わるすべての業務に適用することが可能であり、また時代の流れによって変わるものではありません。そのため、無人運航船プロジェクトを通してモデルベースアプローチを実践できたことは、自身の今後の業務への取り組み方を考えるうえで非常に大きな経験となりました。

自動運航船、あるいはその先の無人運航船の実現に向けては、システムの高度化はもちろん、運用方法の検討や法律の整備、国際的な基準(規則)の策定、各船級の認証など課題がたくさんありますが、いずれの課題についても多くの関係者と議論・合意形成を実施していかなければなりません。その際、本プロジェクトで得た知見を活かしてそれらを力強く推し進めていくとともに、自身がエンジニアとして自動運航システムの開発に携わっていきたいと考えています。また自動運航システムのみならず、これからの海運業界に対して真に価値のあるシステムやサービスを提供できるよう、精いっぱい業務に取り組んでいきます。

 

*1 原文: ”People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.” – By Harvard Business School Professor Theodore Levitt

*2 DFFAS: Designing the Future of Full Autonomous Ship

*3 2022年3月15日付プレスリリース:国内初、完全自律船フレームワークの船級認証を取得 ~無人運航船実現のためのコンセプト~

*4 STAMP/STPA: System Theoretic Accident Model and Processes/System Theoretic Process Analysisの略。システム理論に基づく新しい安全解析方法論とそれに基づく安全解析手法

*5 GSN: Goal Structuring Notationの略。システムが達成すべき目的や性質について、その達成を導く方法・思考を可視化する際に用いる記法