コードファインのTさんと雑談していて、ふと実行可能な仕様書についての話になりました。ひとくちに実行可能な仕様書といっても、各社バラバラのアプローチをしているねぇ・・・と。

なんだか頭が混乱してきた事もあり、私なりにまとめてみる事にします。

ちなみに実行可能な仕様書とは、「日本語の仕様書は曖昧だからダメだ。でも、Simulinkモデルで仕様書を書けば、曖昧な点がなくなるじゃないか！」というアイデアです。

まず、「誰が、実行可能な仕様書を書くのか？」という観点で分類すると２種類のアプローチが得られます。

• 発注者（OEM）が書く
• 受注者（サプライヤ)が書く

まずこれらについてご説明します。次に、これらのアプローチをいくつかの切り口で分析してみます。

トップダウン形式

トップダウン形式では、OEMが実行可能な仕様書を書いて、サプライヤーに渡します。

OEM側の主な関心事は、品質のコントロールです。（品質はすごく重要なので、サプライヤーに依存するわけにはいかない！）

比較的単純な部品であれば、実行可能な仕様書を書くのも手間ではありません。決まりきった処理を、誤解なく伝えたいだけであれば、こういったアプローチが有効でしょう。

ボトムアップ形式

ボトムアップ形式では、サプライヤーが実行可能な仕様書を書いて、OEMに動いている所を見せます。

OEM側、サプライヤー側ともに、「意志の疎通をスムーズにしたい」という点が最重要視されます。

OEM側は、単に思い通りの仕様になっているかを確認するだけではなく、「どうしたら、もっと安全で快適なドライブを提供できるかな？」とサプライヤーに相談をもちかけたりもします。

共同で仕様を固めつつ、その成果を（自動コード生成にて）実装まで持って行きたいのであれば、こういったアプローチが有効でしょう。

サプライヤー側からすれば、ある程度実装も意識しつつ実行可能な仕様書を書くことができます。仕様書を書いているというより、フライングで実装を始めちゃっている、というイメージのほうが強いように思います。

（分析）技術的な視点から

前提条件

まずは話を簡単にするため、ありえない仮定を置きましょう。

• OEMもサプライヤも、全体最適にのみ興味がある （ビジネス上の駆け引きには興味が無い）
• OEMもサプライヤも同等の生産性を持っており、同一労働であれば同一コストとなる

完璧さのレベル調整

完璧な仕様書というものがあれば、そりゃ嬉しい限りです。しかし・・・本当の意味で完璧な仕様書を作るのは、実はかなり大変です。たとえば、あなたが書いた実行可能な仕様書。その仕様書が、本当の本当に正しいと、どうして言い切れますか？

本当の本当に正しいという証拠を見せるには、厳密なテストをするしかありません。ざっくりじゃダメです。そう、本当の意味で完璧さを追い求めようとすると、それなりの工数が掛かってしまうのです。

一方で、完璧であればあるほど手戻りの工数は減っていきます。かならず誤解というものは入り込みますので、仕様書が１００％完璧でも手戻りはなくなりはしません。しかし、やはり完璧さが上がれば手戻りは減っていく事でしょう。

「仕様書を完璧にする工数」と「手戻りにかかる工数」

さてここで、全体最適の視点で考えてみましょう。誰が仕様書を書くとか、誰が実装やテストをするとか、そういう事は忘れます。とにかく、人類が費やす工数を最小限にしたいと考えるのであれば・・・「仕様書を完璧にする工数」＋「手戻りにかかる工数」を最小化する必要があります。

そうなると、「絶対に絶対に完璧とよべる仕様書」が最適解ではなくなる事でしょう。マイコンのソフトを変えるだけで済むような、手戻りの痛みが少ない領域であれば、仕様書はざっくりして、あとで手直しするのもアリです。一方、ASICみたいに手戻り＝数億円の損失となるような領域では、もっともっと慎重にやりたくなる事でしょう。ハードの手直しが入るか否か、という点が重要なポイントになるかと思います。

とにかく、完璧であればあるほど良いというのは間違いです。そうではなく、心地よい完璧さ（心地よい不完璧さ）というレベルがあり、そこを目指すことで全体としての工数は減っていきます。

（分析）ビジネスの視点から

前提条件

もうちょっと現実に即した話にするため、仮定を変えてみましょう。

• OEMもサプライヤも、自社の利益を最大化する事に興味がある  （自社の利益の次に、グループとしての最適化に興味がある）
• 実装に近い領域においては、OEMよりもサプライヤのほうが得手である。よって、同一労働であればサプライヤで実施した方が低コストとなる

サプライヤ担当の付加価値が減る？

ざっくりとしたコンセプトから、具体的な要求項目に落し込み、それを各種仕様に落とし込む。それらから設計をし、実装をし、テストをする。この一連の流れを、OEMとサプライヤーに別れて担当しています。

実行可能な仕様書を作らないのであれば、そこそこの設計を元にサプライヤー側の作業が始まります。従って、それなりの付加価値をつけることができていました。

しかし、トップダウン形式に従い、実行可能な仕様書がOEMから出てきたらどうでしょう。従来であればサプライヤー側で担当していたような詳細レベルの検討まで、OEM側に奪われてしまいました。とにかくサプライヤーは、この実行可能な仕様書の通りに物を作ればいいんだよ！という話になります。これでは、サプライヤーは単なる実装屋になってしまいます。

一方、ボトムアップ形式であれば、そのような心配はありません。実行可能な仕様書をブラッシュアップするという作業がサプライヤーに残されているため、サプライヤーは単なる実装屋という事にはなりません。

サプライヤの利益が０に向かう？

トップダウン形式に従い、実行可能な仕様書がOEMから出てきたとしましょう。サプライヤーからすれば詳細検討の分の仕事を奪われてガッカリという所ですが・・・実はもっと恐ろしい事が待っています。

次の条件がそろったとしましょう。

• 実行可能な仕様書により、部品の振る舞いはどのサプライヤーでも変わらない
• AUTOSARなどの規格に準拠する事により、部品を簡単に交換できる

そうすると、OEM側から見て一番いい部品を採用する事が出来るようになります。サプライヤーからすれば、新規に参入するチャンスとも捉えられるわけですが・・・この状態は危険です。

「どのメーカーの部品でもいっしょだよ」「だからまぁ、安いやつ買えばいいよなー」というような状態を、コモディティ化と呼びます。陳腐化しちゃったんですね。

コモディティ化により、競争はより自由になります。しかし、差別化による競争は出来ないため、どうしても価格競争になってしまいます。自由競争の行き着く先は、各社の利益が限りなく０に近づいていくという結末です。

OEMにしてみれば、実行可能な仕様書づくりを自社にかかえこむことはコストアップになります。サプライヤーで作った方が安く出来るはずな上に、「仕様書を完璧にする工数」＋「手戻りにかかる工数」を最小化する事にもなりません。でも、余計な工数が掛かったとしても、いいんです。部品をコモディティ化させちゃって、サプライヤーの利益をがしがし削ってしまえば、安く部品を調達する事ができます。その結果、（OEMから見れば）トータルでコストを抑えることができるようになります。

注：あくまで一般論です。OEMの方が具体的に上記のような発言をしたという事実はありません。私としても、サプライヤーに大切なお客様がたくさん見えますので、このようなシナリオは望んでいません。願わくば、真の全体最適によって、真の共存共栄を実現していただきたく思います。（サプライヤー様の開発予算が無くなったら、わたしも失業してしまいます！）

ちょっと言い過ぎかも？

なんかすごく悲観的な事を書きましたが、ちょっとオーバーでした。まず、自動車部品のすべてがコモディティ化するなんてありえません。実行可能な仕様書なりAUTOSARなりによって、コモディティ化する部品がちらほら出てくる程度だと思います。ですから、ほんとうにサプライヤーの利益が０になってしまう事はないと思います。

あと、安けりゃいいからということで部品選定をしてみたものの、あとからあとから不具合が出てきてひどい目にあった、なんていう話も聞きます。機能は同一でも、信頼性という面では既存サプライヤーにおおきなアドバンテージがあります。（OEMがそれを評価してさえくれれば・・・）

もう１つの希望は、部品による競争がやりやすくなるという点です。価格競争するしかないような部品で利益をだすのは確かに難しいです。しかし一方で、「この部品の出来がクルマの競争力を左右する」というような部品を持っていれば、とんでもない競争力を持つことになります。

ぱっと思いつくのはバッテリーでしょうか。「他社より２割も効率のよいバッテリー」なんて作ることが出来れば、すごく競争優位に立てます。それこそ、OEMの利益をぜんぶサプライヤーが食ってしまう、なんて事も可能になります。なにしろ、そのサプライヤーから部品を買わない限り、クルマそのものの競争力が得られないわけですから。

ただし・・・そういう競争力の源泉になりそうなところは、OEMさんがガッチリ押さえちゃってるんですよね。OEMさんはお金もってる上に、私なんかより１００倍も頭のいい人達がゴロゴロしてるわけです。私がここで書いているような事は１００も承知で、ヤバイ部品はガッチリ押さえられています。具体的な事を書くわけにはいきませんが、OEMさんがこういう領域にこういう投資してるよ、という話を聞く度に、さすがだなーと感心する事しきりです。うーむ。

結局、実行可能な仕様書ってどうなの？

トップダウンは、ちょっと大変

日本語で書いた仕様書から、実行可能な仕様書が自動生成できるのであれば、こんなに有難いことはありません。しかし、現実にそんな事はありえません。

「実行可能な仕様書を書け？おいおい、それがどれだけ大変な事かわかってるのか？やってらんないぞ！」という声も聞きます。さもありなん。ソフトを実装しはじめちゃうようなものですから、そりゃあもう大変な作業だと思います。ざっくりなら簡単なんですが、信頼性のある仕様書を作るのは、本当に大変です。（仕様書じたいにバグがあったら・・・OEMの責任になっちゃいます！）

ですから、理想としてはたしかに素晴らしいんですけれども、これを運用してはたしてコストダウンにつながるのか？というと、ちょっと微妙な気がします。

ソフトウェアの規模が大きくなると、従来プロセスでは対応できなくなる・・・という話も聞きます。でも、銀行系のシステムだって結局は人海戦術でやってるわけですし、人間その気になればなんとでもなると思います。要は慣れの問題ではないかと。

但し、サプライヤーの技術力に大変不安を覚えていて、微に入り細を穿った指示をしてあげないと、まともな物が出来てこないというのであれば話は別です。

あるいは、いっぺん作ってしまえば以後は何度でも使い回しが出来る、という場合も、初期投資と思って最初だけ頑張るのはアリかと思います。

また、１つの改良点として、実行可能な仕様書をテストするためのテストケースを、サプライヤーから納品された物に対する検品にも流用する、というアイデアもあります。どうせ検品はやらないといけないわけで、そのためのテストケースはいずれにせよ作らないといけません。そうであれば、そのテストケースを実行可能な仕様書づくりにも使ってしまえば一石二鳥です！

ボトムアップは、便利になる余地が多々あり

ボトムアップは、要するにプロトタイピングの意味合いが強いものです。ECUを使ったプロトタイピングは少々面倒ですが、それはハードの調整をしたり、ドライバー部分を用意したりしないといけないからです。（派生開発で、制御ロジックを入れ替えるだけであれば、バイパスなりNo-Hooksなりで簡単にプロトタイピングできますけどね）

一方、実行可能な仕様書であれば、制御ロジック部分だけをSimulinkで書けばOKです。実装に流用することを念頭に置きつつ書くのであれば、その作業は決して無駄にはなりません。

そうして書いた実行可能な仕様書を、OEMから提供されたプラントモデルと組み合わせて「ほら、ちゃんと求める性能が出てるでしょ？」という説明をする事ができれば、仕様の詰めをより楽に行うことができます。

ただし、現状では、まだまだ仕様記述がやりにくい部分があるように思います。もうちょっとそのあたりがツールとして改善されてくると、これはなかなか便利な方法になるのではないかと思います。

トップダウン vs ボトムアップ

じゃあ、トップダウンとボトムアップ、どちらがいいの？というと、これはもう領域によるのだと思います。

「ある程度決まりきった動作を、とにかく間違いなく実現してほしい」というような領域であれば、トップダウンの方が有利だと思います。サプライヤー側で下手な工夫をしてほしくは無いわけで、とにかく言われたことをきちんと守って欲しい、というような領域です。

「何が正解なのか分かりきってはいない。常に正解を模索しつづけている」というような領域であれば、ボトムアップの方が有利だと思います。何が正解か、いろいろ試しながら模索していかないといけないわけで、それにはサプライヤー側の積極的な提案が不可欠です。

私自身の仕事のやり方は、完全にボトムアップです。というのは、決まりきったプログラムをただ作ってくれればいいよ、という商売ではないからです。そのため、どうしてもボトムアップに肩入れしてしまいがちです。今回の記事にも、なんだかトップダウン形式をけなすような話を色々と書いてしまいました・・・ですが本来は、どちらかが一方的に優位というような事はなく、ケースバイケースで使い分けるべきだと思っています。

まとめ

• 「実行可能な仕様書さえ書けば、無条件でコストダウンにつながる」わけでは無い
• 技術的な面だけではなく、ビジネス的な面での綱引きが、より事態を複雑にしている
• まだまだ改良の余地があるため、将来的には素晴らしい方法と言われるようになるかも