前回のコラムでは、ニーズ対応の“もぐらたたき”を減らすためにプラットフォーム化が重要であることを説明しました。数多くのニーズに対応しているうちに、製品群の共通部分が見えにくくなっているかもしれません。その際には『システム図』が大変有効になることを紹介しました。
この下書きとも言えるシステム図を描くことで、いくつかの重要なポイントが明確になります。
（1）製品群のアーキテクチャ
- システム図は製品構造の概要を表します。複数製品を一つの図に描き表わすことで、製品群に共通する構造を可視化することにつながります。
- これにより、エレキ・メカ・ソフトなど、部門間の共通言語として製品構造の共有が可能になります。
（2）構想設計の粒度
- 「詳細設計」に対して、「構想設計」という言葉は定着しつつありますが、どこまでが「構想」で、どこからが「詳細」なのかはとても曖昧です。上流フェーズにおいて、どこまで製品を具体化しておくべきなのかは誰もが悩むところです。そこで、例にあるように、共通項（プラットフォーム）と個別対応する部分（オプション）とが切り分けできている粒度でシステム図を記述するのです。これ以上粗いと、必要な役割分担ができず、これ以上細かいと一覧性が低下します。
- 各要素間のやりとりが可視化できている共通言語となっていることで、その後の詳細設計に対するインプットとして有効です。
（3）プラットフォーム化すべき（共通化すべき）要素
- 一つの図に描き表わす過程で、製品群のアーキテクチャ同様に共通要素も可視化できます。
（4）製品ラインナップ
- 因数分解した共通項（プラットフォーム）と各オプションの組み合わせの展開が製品ラインナップとなります。
- 製品ラインナップを点検することで、製品群全体が製品戦略と合致するかどうかを検証します。
（5）インタフェース
- システム図には各要素間のやりとりが可視化されています。このやりとりというのは、一つひとつの要素が何を受け取り、何を次の要素に渡すかを示します。これがインタフェースであり、役割分担を決める基準となります。
下書きというと、描く必要がないと思われるかもしれません。製品の下書きである「図面」に喩えて考えてみましょう。一人で製品全体をつくり上げるのであれば、図面は必要ないかも知れません。しかし、設計は設計の専門家、生産は生産の専門家が担当するとしたら、そういう訳にはいきません。設計と生産とはそれぞれ「図面」を介してコミュニケーションをとることで、スムーズに分業ができるのです。同じように、プラットフォーム化の構想には「システム図」が不可欠となります。プラットフォームとオプションとを分割・分担するには「システム図」のような下書きをしっかり描くことがポイントになります。
しかし、このように重要性を訴えただけでは、システム図を描くことが定着しないことがあります。システム図を初めて描くときには、描き手も読み手も不慣れで意図が伝わりにくいものです。あるいは、「第7回・インタフェースに足りないもの」で説明したような記述モレがあるために、このような下書きが重要視されず、描かれないまま設計が進んだり、描かれたとしても読まれなかったりということがあります。
このような事態を防ぎ、意味のあるシステム図にするには、システム図を「構想設計書」の一部とするのがいいでしょう。元々、多くの企業では「構想設計書」を書き、レビューするプロセスがあります。「構想設計書」には製品の用途やターゲット・ユーザー、事業面の狙いを実現するための方策が一般に書かれています。同様に、プラットフォームの“下書き”である設計書には、製品群の狙いを実現するための方策として「システム図」および「インタフェース定義」を書き、レビューしていくことが重要となります。
この度の震災に遭われた方々には、心からお見舞いならびに、一日も早い復興をお祈り申し上げます。これを機にイノベーションを起こし、元気な日本を一緒につくりましょう！
※ 本連載に関連するプロセス改革施策にご興味のある方はこちらも合わせてご覧ください。
