私は、昨年度、工業標準化事業に対する貢献により経済産業大臣から表彰を受けました。編集委員会から私に与えられたテーマは、それについて解説せよというものです。しかし、その技術的な内容については既に本ニュースの2004年6月号において「宇宙開発における標準化と情報化」という題名で執筆しています。そこで、今回は、私が標準規格などの文書の作成に力を入れている理由についてお話ししたいと思います。なぜならば、その理由をお話しすることは、「人工衛星のような複雑なシステムをいかに効率的に開発するか」という私のシステム工学的な研究の成果を解説することになるからです。
人工衛星のような複雑なシステムの開発は、必然的に大人数のチームで行うことになるのですが、効率的に開発を行うための一つの原則は、「チーム構成員の誰もが何かしら具体的な作業を担当し、その作業結果を文書などにまとめ、プロジェクトの中で機能させること」だと思います。ここで、具体的な作業には、計画立案、要求定義、設計、製造、試験、運用などが含まれます。チーム構成員の各人がこれらの作業の一つあるいは複数を担当し、それぞれの作業の結果をプロジェクトの中で実際に利用できるような形で文書などにまとめることが効率的な開発には重要です(図1参照)。チーム内での意思統一や情報共有のためには、文書だけでなく会議やメールの交換も必要になりますが、そのような場合でも何らかの文書に基づいて行うと、議論から結論に至るまでの道筋を統一的に管理することができ、結果的には効率的になるからです。以下では、その仕組みについて実例も交えて解説していきます。
図1 開発過程と文書(例)
まず、何かを開発するときには、開発すべきものを具体的に定義する必要があります。その次には、チームで分担して開発を行えるように、開発の仕事をどのように分割すべきかを考えます。これは、Work Breakdown Structure(WBS)と言われているものを作ることに相当します。WBS内の各々の仕事は、時間軸に沿って定義された複数のフェーズに展開されます。WBSが作成できたら、WBSの各々の項目に対してその項目を担当する個人を割り当てます。この段階に至ったら、開発すべきものの定義、WBS、開発体制(担当者の割り当て)、その他の開発全体にとって重要な事項をまとめた開発計画書(プロジェクトの場合はプロジェクト計画書)を作成します。この文書は開発全体の責任者が自ら書くべきです。
ここからは各論に入るのですが、例えば、あるプロジェクトのあるフェーズにおいて、衛星に搭載される複数の計算機間のインタフェース(接続方式)の開発を私が担当することになったとします。そのインタフェースが満たすべき要求条件は、それ以前のフェーズで既に規定されているはずですから、その要求条件を満たすインタフェースを既存のインタフェースも参考にしながら設計します。最終的にインタフェースが確定したら、その結果を「搭載計算機間インタフェース仕様書」などの文書として発行します。
この作業は私が一人で行うのではなく、そのインタフェースを使用する人たち(すなわち、搭載計算機の開発担当者)やプロジェクト内部の他の関係者と調整しながら行うのですが、そのような作業が効率的に行えるように、私は開発が始まったらすぐにインタフェース仕様書の目次を作るようにしています。関係者と調整を行いながら決定した事項があれば、それをインタフェース仕様書の該当部分に記述し、関係者間で回覧し確認してもらいます。関係者が問題を指摘する場合は「インタフェース仕様書のこの部分にこのような問題がある」という形で指摘してもらいます。調整の上で解決策が決まれば、それを文書の該当部分に記入します。このようなサイクルを何度か回せば、調整は完了し、それと同時にインタフェース仕様書も完成します(図2参照)。
図2 文書を基礎とした開発(TBDは未決定という意味)
プロジェクトの節目ごとに設計審査などの審査が実施されますが、これは、作成した文書を、上で述べたようなプロジェクト内の関係者よりも広い範囲の人たち(例えば、他のプロジェクトで同様の開発を行ったことがある人など)も含めて確認してもらうという作業です。従って、審査だからといって特別な作業を行う必要はなく、それまで日常的に行っていた確認作業を広い範囲の人達と行う、というだけのことです。
「搭載計算機間インタフェース仕様書」が完成したら、プロジェクトとしての次の作業は、このインタフェース仕様書に適合するように各々の搭載計算機を設計し、製造することです。その次は、製造された搭載計算機がインタフェース仕様に従って正しく接続できるかどうかを試験することですが、この試験も私が担当するとします。インタフェース仕様書の場合と同様に、私はまずインタフェース試験計画書の目次を作ります。そして、関係者と調整を行いながら、試験計画書の内容を作成していきます。それが完成したら、次はインタフェース試験手順書を作成します。試験手順書が完成したら、それに従って試験を実施し、インタフェース試験報告書を作成します。
図3 文書の効用
簡単な実例を用いて開発の方法を文書整備の観点から説明してきましたが、文書整備を重視するのには幾つかの理由があります(図3参照)。第1の理由は、作業の効率化です。日本では欧米と比べて、その場限りの使い捨ての資料を調整用に作成する場合が多いように思いますが、作業の初めから文書を書いていれば、その文書を抜粋することによって調整用資料を作ることができます。また、調整の結果も、同一の文書の該当部分に書き加え、それを確認するようにすれば、最小限の資料で作業が進みます。
第2の理由は、作業の明確化です。上で述べたように、開発途中の議論において「この文書のここをこうすべきだ」と議論することによって、何を議論しているのかが明確になります。また、議論の結果を文書の内容に反映させることによって、議論の結果も明確に示せます。
第3の理由は、各担当者の書くべき文書を指定することによって各担当者の責任範囲を明確に示せることです。例えば、インタフェース担当者は、インタフェース設計がその仕事の中心であったとしても、インタフェース仕様書を完成させることによってその責任を果たしたことが示されることになるのです。
文書整備を重視する最後の理由は、文書を蓄積することによって知識を蓄積することができることです。技術の一般論に関しては、教科書や論文を読んで勉強することもできますが、具体的な設計の方法(計画立案の方法なども含めて)を勉強するには、仕様書(計画書なども含めて)を読むのが最も有効な方法です。私自身、インタフェース設計の方法や試験計画立案の方法は、様々なインタフェース仕様書や試験計画書を読んで学んできました。ただし、文書にも出来の良いものとそうでないものとがあり、「どのような文書が良い文書であるか」をよく考えながら読む必要があります。
ところで、開発フェーズによっては、開発の結果は文書ではなく、図面であったり、ハードウェアであったり、コンピュータのプログラムであったりします。本稿で私が「文書」と呼んでいるものは、正確に言えば「明確な形があり、プロジェクトの中で機能するアウトプット」となります。プロジェクトにとって重要なことは、各担当者が(文書であれハードウェアであれ)明確な形のあるアウトプットを作成し、それがプロジェクトの中で機能することです。ハードウェアよりも文書の方が重要であると考えているわけではありません。従って、本稿の題名の「設計しよう、仕様書を書こう」は、必ずしも正確な表現ではありませんが、上記の考えを象徴的に表したものであるとお考えください。
さて、これからは応用編です。日本政府が制定した宇宙基本計画では、太陽系探査をプログラム的に行うべきということが書かれています。ここで、プログラムとは、複数の関連したプロジェクトを体系的に実行することを意味しています。個々のプロジェクトについては、プロジェクト計画書を書くべきということを本稿の初めの方で述べましたが、プログラムについてもプログラム全体の計画を規定するために「太陽系探査プログラム計画書」のような文書を作成すべきです。また、プログラム全体の責任者(プログラムマネージャ)も定め、プログラム計画書は、プログラムマネージャが執筆すべきです。
しかし、現時点では太陽系探査プログラムの内容は定まっていませんので、プログラム計画書はまだ書けません。となると、プログラムの内容を決めるための活動を行う必要があります。まずは、プログラムの内容を決めるための計画を立案しなければなりません。例えば、(1) プログラム全体の目標の候補をいくつか定める、(2)それぞれの候補について科学的意義や技術的難易度などについて評価を行う、(3)その評価の結果に基づいて一つの目標を決定する、(4)その目標を達成するためのプログラムの内容を詳細化する、などのステップを定義します。次に、各々のステップを誰がいつからいつまで行い、どのようなアウトプットを出力すべきかを定めます。このようなプロセスについても「太陽系探査プログラム策定計画書」とでもいうような文書を作成して明文化すべきですし、そのプロセスの責任者も任命すべきです。
結構たいへんですが、このようなことを行わなければ、太陽系探査プログラムを実現することは不可能です。もちろん文書だけで太陽系探査プログラムが実現するわけではありませんが、個々のプロジェクトあるいはプログラムの実施と並行して「どのようにすれば複雑なプロジェクトを効率的に実現できるか」についても様々な観点からの研究を行う必要があると思います。本稿でお話ししたことは、そのような研究の一つの成果です。
文書を基礎とした開発の方法論について述べてきましたが、ここで書いてきたことは、私が実際に様々なプロジェクトで実践してきたことに基づいています。しかし、誰が読んでも正しく理解してもらえるような文書を書くことは容易ではありません。なぜならば、一つの意味を表現する方法には複数のものがあり、また、一つの表現が複数の意味に解釈される可能性もあるからです。意味と表現を1対1に対応させることができれば、文書の作成や理解は楽になりますし、機械によって文書を処理することも可能になるでしょう。現在の私の最大の研究テーマは、文書の前提となっている知識を陽に表現することによって機械でも処理できるような文書を作成する方法についてですが、これについても、いずれどこかでお話ししたいと思います。
【 ISASニュース 2018年11月号(No.452) 掲載】