2022.02.01
はじめに
システム開発を成功させるためには、「制約」をうまく扱うことが大切です。前話に引き続き、システム開発において、なぜ「制約」を扱う必要があり、何が難しく、どう扱えば、うまく扱えるのかについて解説します。
「制約」をうまく扱う上で着目したい分断
第一回では、「制約に対する認識の分断」について述べました。制約の有無や重大度について、ステークホルダと開発者との間で認識齟齬が生じると、ステークホルダの期待をシステム要求に正しく反映できないという問題を引き起こします。
第二回では、設計解を試行錯誤しながら見出す過程で、開発者間同士で生じる分断を扱います。それぞれが思い描いている「あるべき姿」に齟齬があると、ニーズや制約を正しくシステムに反映できません。認識のズレを解消せずに開発を進めると、機能検証や妥当性確認の際に、想定していた振る舞いをシステムが行わず、設計を見直すことにつながります。
特に制約は、オーナーシップを持つメンバーが少ないため、抽象度が高いまま扱われやすく、「あるべき姿」に齟齬を生む原因になります。
本稿では、具体例を交えながら、制約によってシステムの「あるべき姿」にどのような認識齟齬が生じるのか？どうすればそれを解決できるのか？について、レヴィ流のアプローチを紹介します。
- 小型人工衛星開発における「あるべき姿」
- 「あるべき姿」をチームのものにする
- 制約を意識した上で、あるべき姿の認識を揃える
- おわりに
小型人工衛星開発における「あるべき姿」
小型人工衛星は小型といえど宇宙で自律して動くシステムです。通信や電源といったバスシステム、運用を司るコントロールやミッション部など様々なサブシステムが存在しそれぞれに専門性を持った担当が必要です。他方これらのサブシステムが相互作用することではじめて全体のシステムが動くため、全体を見る担当者も必要になります。制約も多く抽象度も高いためそれぞれの視点からみたあるべき姿に齟齬が生まれやすく、私が衛星開発していた際もいろいろな分断が生まれました。
衛星システムの「あるべき姿」に対する分断
特によく分断が起きていたのは、システムの安全性を担当する = 安全に関する制約をとりまとめる開発者と、バスシステムを担当する開発者の間です。システム安全の担当者は、役割上、衛星の電子回路や構造、ソフトウェアの詳細までは理解することが難しいのですが、制約のことはよく理解していました。一方バスシステムの担当者は、個々の領域についてはよく理解していますが、システム全体として課せられる制約や満たしたいニーズについては、深く理解することが難しい状況でした。
制約から導出される要求はたくさんあり、それらを複合的にシステムに反映しないといけません。ミッションから導出される要求も同様ですが、チーム全員がミッションの成功に向けてコミットする意識を持っている上、ミッションの責任者やシステム/サブシステムの各責任者がオーナーシップを持って要求を詳細化していきます。それに対して、制約については、意識している人間やオーナーシップを持つ人間が限られています。
私たちのプロジェクトでは、制約に関する要求や設計方針の抽象度が高いままという状況で開発が進んでいきました。そのため、「衛星のバスシステムがどうなっていたら良いのか」ということに対して、担当者の自己判断で設計を進めていく必要がありました。
しかし、困ったことに、制約の姿は、担当者によって異なって見えます。見え方が異なれば、当然、「あるべき姿」は、ずれてきます。要求の抽象度の高かった結果、「あるべき姿」のずれが誤った設計解の選択を引き起こしてしまいました。
システム安全性担当者とバスシステム担当者の間の分断
ひとつ例を挙げると、小型人工衛星には、「ロケット打ち上げ時に電波放出してはいけない」という制約が課せられます。ロケットは、打ち上げ花火のように一度点火したら宇宙までただ飛んでいくわけではなく、ロケットの状態（どこをどれくらいの速度で飛んでいるのか、機器は正常かなど）を地上に送ったり、地上からの命令を受け取ったりしながら飛んでいきます。もし、なんらかの異常が起きた場合には、地上から破壊司令コマンドを送り、ロケットを自爆させることもあります（例えば、H-IIAロケット6号機は、補助ロケットブースターに異常が生じて、太平洋上で自爆しました）。そんなわけで小型衛星が放出する電波が、ロケットと地上局との通信に悪影響を及ぼすと困るので、電波放出をするなという制約が課せられます。
この制約を満たすには、ロケット打ち上げ中に衛星の電源が入らないようにするというのが、最もシンプルな解決策です。これをコールドロンチと言います。コールドロンチを実現するには、バッテリと機器との間にインヒビット（接続を妨げる機能）を設けます。衛星がロケットに搭載されている時にOFF状態となるスイッチをバッテリと機器の間に挟むことで、コールドロンチを確かなものにしようとするわけです。
システム安全の担当者は、「コールドロンチの実現」という上位の要求をブレークダウンしていき、「バッテリと機器の間にインヒビットを設けること」や「短絡を防ぐために、バッテリから最初のインヒビット回路までを二重絶縁とすること」などの要求を導出していきます。この作業は、NASAやJAXAなどの外部のステークホルダと合意を形成しながら進めていきます。
こうして具体化された要求を元に、バスシステムの担当者は、システムの「あるべき姿」を描きます。
ところが、これらの要求は、大本の制約である「ロケット打ち上げ時に電波放出してはいけない」からは随分と距離のある要求になっています。
バスシステムの担当者から見れば、具体化された要求そのものが制約に見えます。
一方で、システム安全の担当者からみれば、「コールドロンチによって、電波放出を防ぐこと」が制約です。
見えている範囲に大きな隔たりが生じた結果、我々の衛星では両者で描く「あるべき姿」に齟齬が生じることになりました。
結果、私達が開発した衛星では、出来上がった電子回路基板が制約を満たせず、一から作り直すこととなりました。一体どうしてこうなってしまったのでしょうか？
バスシステムの担当者は、二重絶縁などの要求を満たすように回路設計を行ったので、制約を満たしていると考えていました。
しかし、出来上がった電子回路基板は、二重絶縁できているかを明確に示すことのできない設計となっていました。また、絶縁の範囲も微妙にステークホルダの期待とずれている部分がありました。
システム安全の観点からは、システムが「意図せぬ電波放出をコールドロンチ方式によって防ぐこと」という制約を満たしていると、ステークホルダに納得してもらうことが必要です。そのため、「短絡によってインヒビットの機能が損なわれる可能性が十分に低い設計となっていること」を示すことが重要であり、二重絶縁というのは、そのための手段のひとつです。二重絶縁という要求の裏に、言語化されきれていないコンテキストがあったのです。
バスシステムの担当者には、そこのつながりが見えておらず、目の前の要求だけを見て、電子回路の設計をしてしまいました。それぞれが描いていた「あるべき姿」が異なっていたにも関わらず、それに気が付かずに実装に進んだため、手痛い手戻りに直面することとなったのです。
「あるべき姿」をチームのものにする
システムの「あるべき姿」の認識齟齬が生じる原因は、制約に対する見え方が人によって異なるからです。見え方が異なるため、描かれるシステムの姿も変わり、そこから導出される設計解も異なってきます。
ひとりの人間が、すべての要求をチェックし、上位要求と下位要求に齟齬がないかをチェックし、「あるべき姿」の認識齟齬をつぶしていくというのも一つの方法です。しかし、システムが複雑になればなるほど、その作業は大変になります。また、新規開発の製品では、技術的な不確実性も多く、要求の確定が難しくなります。そのため、度々要求変更が起こります。要求変更ごとにチェックを行おうとすると膨大な時間が必要となります。
私たちが推奨しているのは、システムの「あるべき姿」を可視化し、制約について対話できるようにすることです。そのために大切になることは、ほどよい抽象度で全体像を描き、関係者全員が共通認識を持てるようにすることです。ある程度抽象度を高くし、全体観をもって、制約の構造を捉えにいくことが重要です。
上述の衛星の失敗を活かし、次の衛星開発では、機能フローモデルや回路ブロックモデルを使って、制約について徹底的に議論するようにしました。回路図では、具体的すぎて全体像が把握しにくく、また回路設計の経験がある人しか理解できないので、対話になりません。より抽象度の高いモデルで、「あるべき姿」を描き、制約を満たしているかどうかを議論することで、認識齟齬を解消していきました。
全体観をもって制約や要求を捉えるということでは、運用のシナリオを描くことも効果的です。時として、制約を満たすための機能が、ミッション成功の足枷になることもあります。例えば、上述のインヒビットは、電源を入れないようにする機能であり、意図せず電源が入るという事象が極力起こらないようになっています。一方で、電源が入らなければ、衛星は、軌道上のデブリです。文鎮にもなりません。ミッション成功と制約を満たすことは、トレードオフになることも多くあります。運用シナリオを描くことで、ミッションにとってクリティカルポイントを見出し、制約を満たしつつ、成功の確率を下げないような適切な設計解を探します。これは、一人で黙々と作業してできることではなく、異なる視点を持ったメンバーと共に、モデルを描きながら対話をすることで見出せるものです。
衛星の状態遷移モデル
衛星の運用シナリオ
制約を意識した上で、あるべき姿の認識を揃える
制約に対しては、オーナーシップを持つ人が相対的に少なく、高過ぎる抽象度での議論になる傾向があります。その結果、制約の見え方の差異が、そのまま「あるべき姿」の認識の齟齬につながります。
これを防ぐためには、ほどよい抽象度の構造をつくり、制約条件について議論できるようにすることが必要です。「ほどよさ」というのは、はじめから分かるわけではありません。制約と「あるべき姿」の間を行き来しながら、対話を重ねていくことで、ほどよい抽象度が見えてきます。それが見えてくると、自ずと「あるべき姿」に対する認識も揃っていきます。
ほどよい抽象度で何かを表現するというのは、意外と難しいものです。抽象度が高過ぎると特徴がつかめず、細部にこだわると全体を見失います。また、複数名で認識を合わせるためには、抽象度に加えて、視点の組み合わせも重要になります。
どのような視点で、どのような抽象度でシステムを可視化すべきかは、対象とするシステムによって変わります。レヴィでは、システムを作る際には、どのような視点に分割してシステムを捉えるかを表現したビューモデルを最初に作ります。ビューモデルにはベストプラクティスがあり、ソフトウェアの上流設計ならこのビューモデル、DX上流設計ならこのビューモデルといった具合に、目的に応じて適切な視点の組み合わせを選択します。
ある程度、形式知化されたフレームがあることで、制約を意識した上での「あるべき姿」の認識合わせのハードルを格段に下げることができます。
DX上流設計で有効なビューモデルの例
おわりに
第二回では、「あるべき姿に関する分断」というテーマで、開発者間の認識齟齬について述べました。それぞれが思い描いている「あるべき姿」が異なるにもかかわらず、そのまま開発を進めてしまうと、スケジュールとコストの超過につながります。なぜなら、出来上がったシステムがニーズや制約を満たしていなかったということが開発終盤で発覚し、大きな手戻りを引き起こすからです。
業務要件と比べて、制約は、抽象度が高かったり、意図していることが分かりにくかったりすることが多いため、「あるべき姿」の認識もずれやすい傾向にあります。
システムモデルを使って、抽象度の高いところに構造をつくり、制約について議論をできるようにすることで、いち早く分断を見つけることができます。また対話を通じて分断を解消することができます。この時、大切なことは、ほどよい抽象度でモデルを描き対話することと、複数の視点からシステムを観察することです。
レヴィでは、こうした考え方を「システミング」というフレームワークにまとめています。さらに、モデルを活用してコミュニケーションを行うためのプラットフォーム「Balus」を開発・提供しています。
私達の活動が皆様のシステム設計の一助になれば、幸いです。
