チームで設計するときに必要な、共同設計ツールの機能とは

• 基本設計は一人でやるべきか、チームで分担するべきか

「基本設計はできるだけ少人数で、やるべきだ」と言う意見がある。私も基本的にはそう思う。「いや理想的には、1人だけでやるのがいい」とおっしゃる方さえいる。理由はシンプルだ。その方が基本設計の整合性が高くなり、一体成形の鋳物のように堅牢になるからだ。これを大人数でバラバラにやると、あちこちに隙間やら歪みが生じやすい。設計思想に一貫性が欠けてくる。

とは言え、大規模な構築物の設計となると、すべてを1人でやるのは現実的ではない。期限の制約もあって、複数人で分担せざるを得なくなる。つまり、平行作業である。プラモデルを手足や胴体や頭の部分に分けて、それぞれ作り上げてから、最後につなぎ合わせるようなことになる。

ところで、設計業務はプラモデル作りとは違って、最初から作るべきものの青写真が決まっているわけではない。むしろその青写真を作るのが仕事なのである(「青写真」なんて言っても死語だよなぁ…今どき実物を見たことのあるエンジニアは、ほとんどいないに違いない）。

ただし、わたしは複数人での基本設計が、良くない面ばかりだ、とは必ずしも思っていない。異なる視点から、多面的に設計を検討できるからだ。わたし達はスーパーマンではない。どうしても一人の視点はある程度、固定されてしまう。だからこそ設計レビューには第三者も呼ぶのだし、レビュー前の作り込みの段階から複眼的な見方ができれば、大きなメリットになる。

• データ共有は必要条件だが、十分条件ではない

まして、基本設計と詳細設計の全体をカバーするとなると、やはりチームでの取組みになるのは必然だ（基本設計と詳細設計の区別の問題は、今は深入りせずにおく）。もちろん、同じ設計といっても、土木の鉄骨を設計するのと、ITプログラムを設計するのでは、全くその内容が異なる。とは言え、どんな設計業務にも共通する要素がある。それはアウトプットとして、何らかの設計書、図面類、設計データ、などを生み出す点だ。

土木・機械・電気設計などはいずれも分野固有の図面をつくるし、IT設計だってE-R図やCRUD図などをつくるだろう。工学系ならば3D Modelといったデータ（のセット）も、しばしばつくる。そして図面やモデルだけでは不十分なので、ナラティブな文章による仕様書やテスト計画書なども必要になる。こうした図面・書類・データ類をまとめて、（あまり適切な呼び名ではないが）「設計情報」と呼ぶことにする。

チームで設計する時には、こうした設計情報を共有するツールが必要である。その最も単純なあり方は、ファイルサーバだとか、BOX.comなどのクラウドサービスだ。そこに、作成した設計情報のファイルを保存し共有する。

しかし、やってみると分かるが、これだけではあまり便利ではない。一つは、ファイル名と作成者だけを頼りに、内容を推測するのが難しいことだ。ファイル名の命名ルールなどを設定しても、それなりに限界がある。

このため、「このファイルは、どんな設計情報を記述しているのか」を別途、何らかの形で登録・検索できるようにする機能が望ましくなる。具体的には、タイトルや、図面種別・作成者・作成部署・作成日・・などである。これらを「データに関するデータ」という意味で、『メタデータ』と呼ぶ。共同設計のためのツールには、メタデータの管理機能が必要なのだ。そして、設計情報は「メタデータ」と「実体ファイル」の二本立てになっていく。

• 共同設計ツールに必要な機能と、運用のためのルール

さて、設計情報は改訂がつきものである。ファイルサーバ上の、同じ名前のファイルが、中身だけ急に最新版に変わったりすると、他の設計者は驚いてしまう。前はどうだったのか、参照したくなるときもある。かくして、バージョンと履歴の機能も欲しくなる。もっといえば、変更箇所の表示もあるとうれしい。

それも、たとえば設計情報の作成者がそのファイルを改訂中の時には、周囲の人間には旧版だけが見えて、改訂を完了したら新版が見えるようになると、うれしい。これを「チェックイン・チェックアウト機能」という。

さらに言うと、ファイル共有サービスはふつう、同一のファイルを複数人で同時に追記・更新できる。これは一元化したリストを共同で登録保守したりするには便利だ。だが、逆に問題となるのは、他人が勝手に設計情報の内容を書き換えたりできることだ。だから共同設計ツールには当然ながら、排他的アクセス・コントロールの機能も必要だ。

とはいえ、設計にはレビューや承認という行為も伴う。だから内容は書き換えないが、「コメントを付ける」機能だけは使えるとうれしい（WordやExcelなどの標準コメント機能では実現は難しい）。承認ワークフロー機能なども、あったら便利だろう。だが同時に、アクセス権や承認に関する、運用ルールも整備が必要になってくる。

• 設計業務には必ず変更とループが生じる

それでも、ここまでは最近のPDM/PLMツールなどでも、多くは実現できている機能かもしれない。そこでもう少しだけ、設計マネジメントの領域に踏み込んでみよう。チームで取組む設計で、ある程度の規模の仕事では、必ず設計変更の問題が生じる。上流側（基本設計）で作成した設計情報をもとに、下流側（詳細設計）で利用して設計を続けている間に、上流側に変更が起きると、それに対応して下流側も再設計し、変更しなければならない。これをどうコントロールするか。

この設計変更は、もちろん外部要因（顧客の仕様変更要望）でも起こるし、内部要因（上流側の設計ミス発覚）でも起きる。しかしやっかいなのは、設計業務に内在するループで起きる可能性があることだ。内在するループとは何か。それは「全体制約のチェック」である。

設計は部分部分で分担して進めるが、にもかかわらず、設計対象物全体にかかる制約条件がふつう存在する。それは物理的実体なら、たとえば接地面の総荷重かもしれない。必要電力の総量かもしれない。ITシステムなら、たとえばレスポンスタイムかもしれない。こうした重要な負荷量ないし性能値は、全体がそろって初めて計算・チェック可能になる。だからこそ、ここで制約条件を満たせないと、部分に立ち返って設計を見直さざるを得なくなるのだ。

設計変更をコントロールするためには、少なくとも、設計変更の通知発信機能と、そのトラッキング機能が必要だ。関連する全てのメンバー・部署に通知が届いたのか。それも形式的な開封確認ではダメだ。開いてちゃんと内容を理解したことの確認がいる。そして、その変更のインパクト（作業工数やコストやスケジュール影響）の評価、変更作業のステータス、などのトラッキングがいる。

しかも、プロジェクトが変更通知の洪水にならないよう、通知をある程度、制御する（言いかえれば「ためておく」）ことも、時には必要になる。どれくらい、ためるのか。ためれば、遅れる。だが逐次流すと、煩雑になる。それを、重要な負荷量や性能値のトレンドを予測しながら、さばかなければならない。これこそが、設計マネジメントの重要な判断だ。

そして共同設計ツールとは、この設計マネジメントの判断をこそ、サポートできなければならないのである。わたしの知る限り、CADをはじめとする設計用システムベンダーの多くは、設計という業務が、ウォーターフォールのように、きれいに順に流れていくように思っているらしい。いえいえ、とんでもない。「総合エンジニアリング」を標榜する会社に長年勤めているが、設計マネジメントの本質は、変更とループの濁流を、なんとか清流にしようともがき続ける営為なのである。

＜関連エントリ＞

「エンジニアリングとは統合力（インテグレーション能力）である」 (2020-01-12)