人工衛星の開発に学ぶ!システムに対する「制約」の取り扱い方

最終更新日時:2021.09.13 (公開日:2021.09.13)
人工衛星の開発に学ぶ!システムに対する「制約」の取り扱い方

はじめに

システム開発を成功させるためには、「制約」をうまく扱うことが大切です。「制約」は、システムを作る際には必ず考慮しないといけないものである一方で、しばしば認識のズレを生み、時として大きな手戻りを引き起こすことがあります。著者らも、超小型衛星の開発やWEBシステムの開発において、様々な制約に直面してきました。

本シリーズでは、システム開発において、なぜ「制約」を扱う必要があり、何が難しく、どう扱えば、うまく扱えるのかについて、3回に渡り解説します。

執筆者紹介

image2.png
南部 陽介

株式会社レヴィ 共同創業者兼代表取締役

JAXA宇宙科学研究所で宇宙工学研究を行い博士号を取得後、大阪府立大学で専門分野である宇宙構造物の研究に従事すると共に、超小型衛星開発プロジェクトの責任者を務める。3機の人工衛星開発に携わる中で、モデルベースシステムズエンジニアリングの実践に関する研究を進める。2016年より株式会社レヴィの代表取締役となる。主にハードウェア企業向けにシステムデザインのコンサルティングやトレーニングを行っている。東京大学大学院工学系研究科航空宇宙工学専攻修了(博士)。

image5.png
萩原 利士成

株式会社レヴィ 共同創業者

JAXA宇宙科学研究所で宇宙物理学の研究を行い博士号を取得後、サイボウズ株式会社に入社。cybozu.comのインフラ開発に従事し、データ分析基盤の構築やNecoプロジェクトのオーガナイザーを行いながら副部長を務める。2016年8月より株式会社レヴィにて自社のサービス・研修開発や事業戦略、組織設計などを行いながら、株式会社スタディスト・株式会社PRECS・Quadcept株式会社の技術顧問として顧客企業のアーキテクチャ設計、チームビルディング、マネージャー支援なども行う。2019年よりプリンシプルズ株式会社のCTOとしてクラウド・ラーニング・システム「BizObi」の開発をリードしつつ、システム設計領域のトレーニング開発も行う。東京大学大学院理学系研究科物理学専攻修了(博士)。

「制約」とはなにか

システムは様々な要求を満たさないといけません。この中には顧客やユーザーへの価値提供に直結する = いわゆるニーズから来る要求だけでなく、様々な「制約」から来る要求が存在しています。ニーズの出どころが明確なのに対して(とはいえそれを捉えるのが難しいのですが)、「制約」はそもそも出どころを把握していないと気づくことさえできません。気づかぬまま開発を進めてしまうと、思わぬ手戻りにつながったり 、深刻な事故を起こすことにつながりかねません。
「制約」の扱いは、「要求工学」の世界でもホットトピックです。

例えば、工業分野についてサーモグラフィなどで対象物の温度を測定する技術を持っている企業が、この技術を転用して医療分野に進出するとします。「体温測定の手間を減らしたい」というニーズに対して、「1秒以内に非接触で体温を測ることができる」体温計を開発しようとしている、といった想定だと分かりやすいでしょうか。モノの温度を非接触で測定する技術と製品(放射型温度計)があるので、ニーズから出発すれば体温計を作るのはそれほど難しくないと思われます。しかし、ここで「制約」の落とし穴が出てきます。体温計は、医療機器であるため、薬機法に従う必要があり、人に危害を加えないか、などいろいろな項目について認可を受ける必要があるのです。近しい技術を活用した装置であればニーズは満たせるのですが、「制約」が異なるため、システムが満たさないといけない要求が異なってくるわけですね。このような「制約」に気づかずに、開発を進めてしまうと、取得すべきデータが不足しており認証が取れず、市場に出すことができなかったり、投入時期が遅れてビジネスチャンスを逃すといった事態につながります。

ところで、「ニーズ」と「制約」をあえて区別する理由は何でしょうか?「システムが正しく作れているか?」という観点では、システム要求が満たされていればよく、顧客やユーザーのニーズ由来のシステム要求と制約由来のシステム要求に違いはありません。
一方で、「正しいシステムが作れているか?」という観点では、「なぜ、そのような要求が存在しているのか?」や「見落としている要求がないか?」を考え続けることが大切です。ニーズと制約とでは、それ自体の見つけ方、システム要求への落とし込みの方法、妥当性の確認方法が異なります。そのため、両者を区別して扱った方が良いと考えています。

ニーズと制約とシステム要求の関係性

ニーズと制約とシステム要求の関係性


「制約をどう扱うか」

ニーズも制約も最終的には、ベースラインとなるシステム要求に落ちますが、取り扱いの方法や洗い出し方が変わってきます。
ニーズから来る機能要求は要求の階層性を意識し、抽象度の高いレイヤーのニーズをどのように引き出していくかが鍵となります。以前のセミナーで取り扱っているので興味のある方はぜひご覧ください。

一方この記事では「制約」に着目してどのようなアプローチで取り扱う必要があるのかをご紹介しようと思います。

鍵になるのは「認識のズレ」=「分断」を見つけ出してコントロールすることです。システムが複雑になると、経験・知識・関心事の異なる多くの人が関わるようになります。視点が異なることが良い方向に働くこともありますが、多くの場合、整合性が取れずに「分断」が生じ、プロジェクトの遅延や失敗につながります。

特に制約はこの分断が生じやすく、以下の 3 つのポイントで分断を発見・コントロールする必要があります。

  • どのような制約があるかに対する認識の分断
  • 制約とシステム・開発メンバーの間の分断
  • リスクやコストに対する認識の分断

今回の記事では「どのような制約があるかに対する認識の分断」に焦点を当てていきましょう。

小型人工衛星開発における制約

著者の一人は、大阪府立大学の教員を勤めていた頃に3機の人工衛星(OPUSAT、OPUSAT-KIT、HIROGARI)の開発に携わりました。うち2機は、すでに宇宙へ飛び立ちました。

image3.png

超小型衛星「HIROGARI」 (2021年3月14日に国際宇宙ステーションより放出)

小型人工衛星にとってのニーズは科学や工学的なミッションです。例えば HIROGARI は、板ミウラ折りという新しい手法を活用した展開構造物と、軌道上で構造物の形状を計測するシステムの宇宙空間における実証実験のための衛星でした。ミッションを達成するにニーズを理解してどんな機能や性能が必要なのかを考えるのは一般的なシステム開発と何ら変わりませんが、小型人工衛星特有の様々な制約も満たさないといけません。

制約に対する認識の分断

制約を話す前提として小型人工衛星がどのように宇宙に行くのかを説明しておかねばなりません。私達は大学として衛星開発をしているため自前でロケットを調達して衛星を宇宙に送るだけの予算がありません。そのため、数百億円かけて開発された別の衛星と相乗りでロケットに搭載されて宇宙に運んでもらったり、宇宙ステーション(これまた数兆円の開発費。。)への輸送機に乗せてもらい、放出してもらったりします。ですので当然ながら他のシステムや宇宙飛行士にダメージを与えるわけにはいきませんし、相乗りさせる側もそこをきちんと検証することを求めてきます。

というわけで「HIROGARIが、十分に安全であり、他のシステムや宇宙飛行士などに損害を与えないことを保証せよ」という重たい制約をなんとかして満たさないといけないわけです。
ここで、制約に対する認識が大きく分断する余地が生まれます。
「安全である」とはなんでしょうか?
この制約をシステムが満たすべき言葉に落とそうとすると、実にいろいろな解釈が発生しそうだということはわかって頂けると思います。
実際、ステークホルダによって、この安全という制約に対する認識がバラバラであったため、非常に苦労しました。
例えば、電波の誤放射やアンテナの誤展開などが地上のシステムで起きても、せいぜい軽い怪我をする程度の不具合だと考えると思います。しかしロケットや宇宙ステーションにおけるそういった不具合はかなり重篤な問題を引き起こしかねず、NASAからシステムの設計に対して様々な要求を課せられました。
NASAは、安全のためには、「電波の誤放射を防ぐこと」や「アンテナの誤展開を防ぐこと」という制約は、極めて重要であると考え、「人工衛星のシステムに2箇所で故障があったとしても、まだ健全性を保つこと」(三重冗長)というシステム要求が導出されることを期待します。一方で、衛星開発経験のない学生は、そこまで重要な制約であるとは考えず、ちゃんと試験で動いたなら、誤放射や誤展開を防ぐ対策をあえて加える必要なないだろうと考えます。「電波の誤放射を防ぐこと」や「アンテナの誤展開を防ぐこと」という制約に対する認識の分断から、その後導出されてくるシステム要求が異なってくるわけです。この要求は、最終的には、ソフトウェアの機能要求(「放出後にアンテナ展開の指示を出すまでの待機時間を300 秒以上確保すること」など)や、プリント基板の配線への要求(「バッテリラインの配線の周囲には 1 mm 以上の空間を設けること」など)に落ちるため、ここで認識ギャップがあるまま、詳細設計に移ると後で大きな手戻りにつながります。上位にある「制約」の理解ができていないまま、勝手な解釈で設計を進めてしまうことは、意外と多くあり、HIROGARIの開発では、何度も作り直しを行うことになりました。

image6.jpg

制約に対する認識をチームのものにする

大学衛星の場合、開発の主力は学生です。例えば HIROGARI の場合は、総勢 40人以上の大学生が数年間かけて衛星を開発していきましたし人の入れ替わりも発生します。数百に上る制約を滝のように落とされても、理解できるものではなく、そのままでは制約に対する認識に分断が発生することは必定です。そうなると結果は明白で、NASAの審査を通過することはできず、衛星を宇宙へ送ることはできません。

ドキュメントに制約を羅列するだけでは分断が解消できない、ではどうすればよいのか?我々が採用したのはシステムモデルでした。GSN (Goal Structuring Notation)という手法を使ってツリー上に制約とそれをどのように満たすか、を分解していき、ステークホルダーや学生同士が齟齬なく理解できるようにしていきました。具体的には「人工衛星が安全であることを保証する」をトップゴールに、「どんな事故が起きるリスクを最小化すべきか」という観点でサブゴールに分解していき、「リスク最小化のためにシステムはどういう設計であるべきで、それをどのように検証するか」をツリー上に整理しました。システム要求仕様書と図面などの具体的な設計情報と一緒に、このモデルを使って、設計の意図のすり合わせを行うことで「制約に対する認識」を揃えることができたおかげで、NASAの審査も通過することができたと考えています。

image1.png

ゴール指向表記よる「超小型人工衛星の制約」の論理分解モデルの一部

制約の認識を揃えることは難しい

制約を見つけ出す作業は、属人的になることが多いため、重要な制約を漏れなく見つけ出せるかどうかは、その作業を進める人の経験やスキルに依存してします。さらに、誰かが制約を見つけたとしても、その制約に対する認識を揃えることがまた難しく、開発の後半になって、認識の齟齬が発覚し、手戻るということが、開発現場では度々起こります。

制約の見つけ方については、ハザード解析や非機能要求グレードなど、ドメインごとに様々な手法が提案されています。一方で、制約に対する認識の合わせ方については、解説記事等も少ないのではないでしょうか。

認識を合わせるために、レヴィが提案している手法は、モデルを活用したコミュニケーションです。人工衛星開発では、ハザードレポートのように定型化された文書を使って、制約を管理しますが、文書があれば開発者が制約を正しく理解できるかというとそうではありません。また、制約に関してのミーティングという場を設けて、ホワイトボードなどを使って、話し合いをしても、その場では分かった感覚になるのですが、いざ設計に落とそうとすると、手が止まってしまったり、その場にいなかった人への共有に困ったりします。

ほどよく定式化されており、認識を合わせる場があることが、システム開発には重要であると私達は考えています。そのための手法が、衛星開発の例でも紹介した、モデルを活用したコミュニケーションです。

モデルを活用してシステム設計を進める方法は、MBSE(Modle-based Systems Engineering)が有名ですが、成果を出すにはMBSEのエキスパートが必要となります。一方で、レヴィでは、エキスパートがいなくても適切な視点の分解とコミュニケーションができれば、モデリングの恩恵を受けることができることができると考えており、その考え方を「システミング」というフレームワークでまとめています。

ソフトウェア開発における制約の扱い

ソフトウェア開発でも、制約に対する認識齟齬は起きやすく、後で問題になるのは同様です。

多くの場合、特に難しいのが、顧客との間で認識を揃えることです。アジャイル的なソフトウェア開発では、ユーザーニーズを満たせるかを検証しながら、段階的に開発を進めることが多いと思います。一方で、セキュリティや性能などの非機能要件からくる制約、システムの限界を決めてしまうために、最初に考えておく必要があるものもあります。

顧客/ベンダー間で非機能要件に対する共通認識がないと、「想定外、あるいは極限状態での運用」といったシステム運用上のリスクや、「システム基盤の変更、下流工程での問題発覚」といったプロジェクト上のリスクが高くなります。

可用性や性能などのような非機能要求に関する制約に対する認識の分断を解消するには、顧客との間で、システムの社会的影響度や使われ方などに対する認識を合わせることが大切です。そのためには、顧客と対話しながら、コンテキストや業務フローをモデルで表し、システムのあるべき姿を把握していくことが有効となります。これらのモデルの描き方については、レヴィのサイトでも紹介していますので、詳しくはこちらをご覧ください。

おわりに

「制約」は、しばしば認識のズレを生み、時として大きな手戻りを引き起こすことがあります。だからこそ、システム開発を成功させるためには、「制約」をうまく扱うことが大切です。今回は、「どのような制約があるかに対する認識の分断」について、著者の経験も交えて解説しました。ほどよく定式化されており、認識を合わせる場を用意することで、こうした分断を解消することができます。レヴィでは、こうした考え方を「システミング」というフレームワークにまとめ、モデルを活用してコミュニケーションを行うためのプラットフォーム「Balus」を開発・提供しています。

第2話と第3話では、それぞれ「制約とシステム・開発メンバーの間の分断」と「リスクやコストに対する認識の分断」を扱います。

執筆者:株式会社レヴィ

株式会社レヴィ

株式会社レヴィは、JAXA宇宙科学研究所で研究していた仲間たちが集まって創業したベンチャー企業です。宇宙開発の考え方をベースにして構築した独自のデザインフレームワークを使い、価値あるシステムの実現に取...