作成者: Kobayashi

（この記事は、2019年5月22日にメルマガで配信されました。）
第19回目は東芝デバイス＆ストレージ（株）の岡野さんです。では、岡野さんよろしくお願いします。

令和新年明けましておめでとうございます。東芝デバイス＆ストレージ（株）の岡野です。

普段はいつも酔い潰れ、あまりLPBに対して真面目に語ったことがなかったので、せっかくの機会ですし、私とLPBについて少し
真面目に書きたいと思います。最後あたりはLPB-SC(*1)メンバー向けの内容となっておりますがお付き合い下さい。

　現在私は、東芝の半導体事業部に所属しておりますが、LPB-SCに参画した当初（2009年）はノートPCを中心とするデジタル
プロダクツ事業部に在籍していました。
当時はまだパソコン事業が好調で、会社も非常に活況でした。社内は売上高が重視され、キャッシュフローを如何に速く回し、
質より量で稼ぐかが問われ、海外の工場を積極的に使い始めた時代でもありました。
私の業務は、入社当初(2000年頃)から3名で細々と電気シミュレーションをしていたのですが、なかなか日の目を見ず、海外の
工場活用が盛んになるにつれ、次第に海外生産拠点を結ぶPDM/PLM(*2)のシステム構築業務へと変わっていきました。効率的
なBOM(*3)の在り方や設計変更管理の改善などに携わり、これはこれで生産に直結するため非常に面白い業務でしたが、一方で
電子工学を学んできた自分としては技術的な物足らなさを感じていたため、会社に問題視されない範囲でシミュレーション業務も
続けていました。
　そのようなPDM/PLM業務とシミュレーション業務の掛け持ちが何年か続くと、自然とこれら2つの業務をどうにか関連付けれ
ないかと考えるようになり、シミュレーションでBOMコストを改善したいという発想に変わっていきました。それまで自分はシミュ
レーションの精度ばかりに目がいき、結果が出た頃には試作が終わることもしばしばあったのですが、それがシミュレーション業務
の日の目を見ない原因の一つであることに気付いた時でもありました。
　当時当社ではノートPCを年間約1000万台出荷していました。もしシミュレーションで1基板あたりBOMコストを10円安くでき
れば、単純計算で1億円のコストダウンに繋がります。これまでシミュレーションは設計の後戻り防止に有効であると謳ってきた
ので、この発想は少なくとも私の中で斬新なものでした。ただノートPCはインテルの設計ガイドをベースに設計されているため、
そこからBOMコストを下げるとなると、設計ガイドを逸脱することになります。ここをシミュレーションで担保できないかと考えました。
設計ガイドは必ずマージンを持っています。そのため、設計ガイドの根拠を我々なりに理解し、再現させ、その上でマージンを削
れば、品質を維持したままコストダウンできるのではないか。ただ、それを実現するためにはどうしてもLSIをモデル化する必要
がありました。
　そこでようやくLPBに繋がってくる訳ですが、当時から当社の半導体事業部でEDA活動をされていた福場さん、冨島さん、青木
さんと知り合い、LSIのモデル化活動を始めました。その後の詳細は割愛しますが、その成果（裏付け）もあり、ノイズ対策部品の
デカップリングコンデンサを削減し、当時1基板あたり約20円ほどBOMコストを下げることに成功しました。
　当然この技術を当社の半導体事業にも生かせないかと考える訳ですが、半導体部門はさまざまなお客様を相手とするため、
これらの考えを一般化させる必要があります。そこで業界標準化活動を始めた福場さんから、セット側として参加して欲しいとお誘い
を受けJEITAのLPB-SCへ参加したのが、私のLPBとの関わりの始まりです。参画した当時、メンバーは半導体ベンダーの
方々が殆どで、単語を含め主張したいことの殆どが理解できませんでした。聞こえてくるのは、“これはノウハウ”、“あれもノウハウ”。
これではいつまでたっても標準化なぞできる訳ないと絶望したものです。おそらく当時のメンバー全員がそれぞれの立場で同じ
ように感じていたのではないかと思います。
それでも1年あまり議論を続け、単語の意味や何がノウハウなのかを紐解いていくと、まさにこの紐解いたところに標準化の
必要性があることに気づいたのです。すなわち、LSI、PKG、PCBの各設計自体はこれまで通りノウハウとして競争領域とし、
今回紐解いたノウハウとノウハウの繋ぎ、言い換えれば、各設計前後の入出力を協調領域として標準化するというものでした。
これにより意思伝達の解釈ミスがなくなり、情報の流通性を上げつつ、各設計情報をブラックボックス化することができる、こうして
生まれたのがLPBフォーマット(*4)です。その後は普及活動の成果もあり、様々なCAD/CAEツールが本フォーマットに対応して
頂くようになりました。また当社では社内の内製ツールも本フォーマットに対応させ、社内外のツールのシームレス化を進めており
ます。
　上のノートPC事例でも書いた通り、LPB相互設計は、相手方の意図を理解しその上でマージンを削れば、工期・品質を維持した
ままコストを下げることが可能です。そのお互いの意図を理解する手段としてLPBフォーマットの活用が広がれば良いなと思って
おります。そういう意味で、LPBフォーマットを単なるCAD/CAEツールを繋ぐインターフェイスと考えると、本来の意義を見誤ります。
また範囲もLPBだけと視野が狭くなってしまいます。これまで議論した相互設計というのは何もLPBの世界に限ったものではあり
ません。今トレンドのシステム・製品全体を対象としたMBD(*5)でも同じです。
　現在、様々なところでMBDの実用化に向けた取り組みが行われており、LPB-SCも“モデルベース・システム設計ワーキング
グループ“を立ち上げようとしていますが、これまで我々がLPBフォーマットを作成する過程で習得したアプローチを応用すれば、
きっと意義のあるものができると思っております。
　LPBフォーマットというのは、Cで枠を決め、Nで枠と枠の関係を定義し、GでCとNを具現化するというアプローチです。この考え
は別にCを部品単位で考えなくてもいいわけです。モジュールやプラントをCにして、それらをNで繋げばMBDの考えになるわけ
です。すなわち、MBDはLPBの考え方そのものだと思っています。どちらかというとLPBはMBSEの方が近いかも知れませんが。
その意義をしっかり皆さんと共有し発展させていければ、LPBはまた新しい世界が待っているものと確信しております。
一緒に盛り上げていきましょう。

*1　LPB-SC　　　　　　：　JEITA半導体＆システム設計技術委員会の中、LSI-Package-Board(LPB)相互設計の在り方を議論するコミッティ
*2　PDM/PLM　　　　　：　Product Data Management/Product Lifecycle Managementの略。製品の設計・開発・製造・保守など、製品のライフサイクル全体を通して、製品関連情報を一元管理する考え方とそのシステム
*3　BOM　　　　　　　　：　Bills of materialsの略。製品を構成する部品表。それに付随するドキュメントやコスト・品質情報が紐づけられている。
*4　LPBフォーマット　：　LPB-SCで策定した、設計に必要な情報や設計結果を流通させる為の国際標準規格（IEC 63055/IEEE2401-2015）。M、N、C、R、Gの5つのフォーマットから構成されている。
　　　　　　　　　　　　　　　詳細はhttp://jeita-sdtc.com/committee-activity/lpbintrface-wg/jeita-lpb-stdformat/を参照。
*5　MBD　　　　　　　　：　モデルベース開発（Model Based Development）の略。モデルをベースに、システム・製品全体を俯瞰した設計を具現化し、設計上流段階から適用可能な考え方・手法。

（この記事は、2019年4月3日にメルマガで配信されました。）
第18回目は東芝デバイス＆ストレージ（株）の福場さんです。では、福場さんよろしくお願いします。

出会いは必然
平成がまもなく令和になります。JEITAのLPB活動が平成21年7月に発足したので今年
平成31年で10年が経ちます。元号が変わるのと10年という節目が重なるのは感慨深く
感じます。もちろん元号とLPBは関係はありませんが、これを節目にLPBは変わってい
く予感がします。思い返せばLPBの活動はこれまで多くの「出会い」があり、それが
活動の転機を導いてきました。「出会い」は偶然だったわけではなく、それまでの布
石があり、新たな行動を起こしたときに新たな「出会いが」があったように思いま
す。

出会い≪その１≫：JEITA活動を始める前
2006年ころからいくつか私的な研究会を立ち上げました。代表的なものにCPM(Chip
Power Model）コミュニティーというのがあり半導体とボードの協調設計を議論し始
めました。EDA、ボード、半導体いろいろな人が興味を持ってくれて思想が固まって
いきました。この話がJEITAのEDA技術専門委員会（当時）のメンバーの耳にはいり、
EDSフェアでのパネル討議のテーマに取り上げられ、JEITAにLPBワークグループを作
るきっかけになりました。

出会い≪その２≫：JEITAでの活動、LPBの誕生
JEITAでLPBワーキンググループを始めた際に意識の高い優秀なメンバーが集まってく
れました。いろいろなところでLPBの必要性（出会い１の成果）を発表していました
が、それを聞いてくれてた人たちが参加してくれました。いろいろな企業の方が立場
を超えて非常に有益な議論をし、必要なことは足を運んで調査し、オープンな討議の
場を作って広く業界の意見を吸い上げてくれました。これにより発足1年半の超短期
間でLPB標準フォーマットを作り上げるという大変大きな成果を成し遂げました。

出会い≪その３≫：LPBを世界のあたりまえにする
日本の中だけで盛り上がっていても発展・普及はしていきません。設計素材や設計環
境を手に入れるには日本ローカルな動きでは世界は見向きもしてくれません。LPB標
準フォーマット（出会い２の成果）に対しての世界での反応を見たくてアメリカの
DAC（Design Automation Conference)2013に出展しました。海外での展示というのは
ボランタリー活動で行うには大変な苦労がありました。しかし、そこでIEEE標準化
団体の目に留まり、とんとん拍子に国際標準化の話がまとまり、わずか2年でIEEE
2401-2015を発行することが出来てIEC 63055:2016の国際標準となりました。LPBが国
際標準になるとEDAやユーザー、部品メーカーへの普及が一気に加速しました。

次の出会いを仕掛ける：
令和元年はものつくり（開発手法）の大変革が起こりそうな予感がします。昨年あた
りからMBD（モデルベースデベロップメント）が盛り上がりを見せ、これからの製品
開発は仮想上の試作品をベースにすり合わせ・性能評価・認証が行われる時代が到来
しようとしています。世界標準のLPB（出会い３の成果）を使ってこの革命に貢献し
なければなりません。

出会いによってコトが始まり、コトに対してまた人が集まり、人の集まりの中から仕
組みが生まれる、この連鎖を作るのが私たちの仕事だと思います。「出会い」は必
然。これからも皆さんで外に出てアクションを起こしましょう。また必ず新たな出会
いがあることでしょう。

（この記事は、2019年2月6日にメルマガで配信されました。）
第17回目は東芝デバイス＆ストレージ（株）の青木さんです。では、青木さんよろしくお願いします。

今回のコラムを担当させて頂きます東芝デバイス＆ストレージ（株）の青木です。

LPBの活動の内容に関しては、既に何人かの方々が紹介されていますので、今回は
青木個人とLPBの関わりについて書いてみたいと思います。

私は2009年の準備ワーキングから参加していますが、初めは前任者からの交代要員(※1)でした。
事前情報の無い(※2)まま連れて行かれた会議室には、今まで経験の無い雰囲気が広がっていました。

(※1：こんなに長く参加するとは思ってもいなかった。正直、２～３回顔を出せば終わりと思ってた）
(※2：説明されたのかもしれないが、当時は、それを理解できるバックグラウンドもなかった)

私は元々、半導体のレイアウトCADのプログラマーです。LPBに参加した時期は、丁度、半導体から
パッケージやPCBに仕事を移していた時期でした(※3)。ラジオ・アマチュア無線と言ったベタな
ラジオ少年の成れの果てにとって仕事自体に違和感は無かった（※4）ものの、知識も経験も無く
四苦八苦していた時期でもありました。

(※3：要するに半導体系の仕事がなくなった…ということです)
(※4：今に思えば恐ろしい限りなのですが、直接目に見えるので半導体より簡単だよなぁ、と
考えていました。すぐに打ち砕かれましたが…）

LPBには、その分野のエキスパートの方々が集まっており、新参者の私にとって非常に勉強に
なりました。しかし半導体のレイアウトのCADという分野で働いていた身にとって、ワーキング
での話はカルチャーショックの連続でした。

レイアウトのCAD屋にとってテープアウトまでの設計期間の短縮が全てです。しかしLPBに参加して、
それまで私が関わっていた世界は非常に狭いものであったと思い知らされました。
営業から始まり、引き合い、企画、設計と進み、量産に至ってようやく利益が出る。
その期間全体を効率化し、如何に素早く利益を出すかが問題の本質。
恥ずかしながらLPBに参加するまで、そのような感覚が希薄でした(※5)。そのような中、このまま
参加してやっていけるか不安に思ったものです(※6)。

(※5：バックエンド設計に一年かかる、となれば、それはそれは、大騒ぎ。大プロジェクト扱い
です。しかし実際には、営業活動から数えると利益が出るまで何年もかかったという製品は沢山あり
ますよね）
(※6：しかし、勉強になるので厚かましくも何食わ顔で参加してました）

準備ワーキングから本ワーキングになり議論も徐々に深まっていったのですが、この分野の新参者の
私にとって、どうすればワーキングに貢献できるか悩みどころでした。幸いなことにプログラマーに
とってマニュアルや仕様書を書くという作業は日常的にやっていること(※7)なので、LPBフォーマット
の仕様作成に辛うじて参加でき(※8)、ホッとしました。

(※7：得意という意味ではない。むしろ、できればやりたくない部類の業務。プログラマーま皆、
そう思っていると、思うのですが、私だけですかねぇ…)
(※8：しかし、他の方のコラムにも書いていますが、これで地獄をみるハメになろうとは…)

今、2020年にIEEEに認定されることを目標にLPBフォーマットのversion3の改定作業を進めています。
2010年の本ワーキング発足から数えると10年目です。私もずいぶん長い間、関わってきました。
非常に有意義なワーキングに参加させて頂けていると思っていますが、後悔していることが一つ
あります。それは、もっと若い時期に参加したかったということです。

LPBには若く、優秀な方々が多く参加しています。皆、非常に勉強されており、いつも教えてもらうこと
ばかりです。そのような方々を見るたびに羨ましく、妬ましくさえ思ってしまいます。もっと早くから
LPBのようなワーキングに参加していれば、色々違った世界が見えていたかも…と残念に思ってしまいます。

このコラムをお読みの方々の多くは、LPBやJEITAの他のワーキングには参加されていないと思います。
しかし、ぜひ参加して、異なる業種、異なる文化の方々と、年齢や地位に囚われない自由・活発な
議論に参加して頂きたいと思います。

LPBでは毎年、9月には泊まり込みのワークショップ、3月には半日のフォーラムを開催しています。
LPB/JEITAへの正式参加が難しいということでしたら、ワークショップやフォーラムに参加して見
てください。それもチョット....という方は、17時から開催している非公式なフォーラムもありま
す。覗いてみたいという方は、メルマガやHPの「お問い合わせ先」からお気軽にお問い合わせくだ
さい。

最後までお付き合いただきありがとうございました。

（この記事は、2019年1月9日にメルマガで配信されました。）
第16回目は（株）村田製作所の五嶋さんです。では、五嶋さんよろしくお願いします。

　わたしがLPB-SCの会合に顔を出すようになったのは、2017年、株式会社村田製作所(以下、当社）にLPB Formatの整備、普及するための協力要請をいただいたことがきっかけです。作業負担をかけないように当社のWEBサイトから自動的に部品情報を抽出するプログラムをご準備いただいたのがとても印象に残っています。新参者のためLPBについての思いではなく、LPB Formatに期待することを、担当しているライブラリ作成の仕事にからめて書かせていただきます。

　当社が提供している部品ライブラリは、測定値から得られるSパラメータやSPICEモデルを基本とし、個別のシミュレーションソフトについては必要に応じて回路シンボルや部品の仕様情報を追加しています。ライブラリの掲載品番は設計支援ツールSimSurfing( https://ds.murata.co.jp/simsurfing )のデータと連動しています。積層セラミックコンデンサについて公開履歴を見ますと、2011年4月、1,188品番のデータ公開からスタートして2018年12月時点で21,705品番になっています。単純計算で一年あたり2,700品番弱のデータを追加してきたことになります。この間、測定、等価回路抽出、ライブラリのパッケージング、動作確認、使用マニュアルの作成、データのWEB掲載の業務を複数の部門・担当者がマンパワーをかけて実施してきました。

　ところで、電子部品を製造・販売している会社として、このような部品モデルをお客様にご提供することは重要な仕事と位置付けられていますが、売り上げに対する貢献度を客観的な数字にして評価することはとても難しいです。このため、お客様からのフィードバックやリクエストを拠り所にして、市場の要求に沿ったアクションとすることが多いです。それは、おそらく他の部品ベンダ様も同じかと思います。

　LPB Formatの普及には、当社だけでなく多数の部品ベンダ様がこのデータをサポートされることが不可欠と考えていますが、それとともにその部品データが取り扱える各種ソフトウェアも必要です。LPB-SCには各メーカー様をはじめ、CADソフトウェア、シミュレーションソフト、そしてEDA関連のエンジニアリングを事業とされる方が多数参加しておられます。LPB-SCの活動が進展した結果、皆様の開発プロセスの中にLPB Formatが浸透して必要性が高まり、その声がそれぞれの立場の業務にフィードバックされることでデータのサポートと普及が促進されると思います。一部品ベンダの担当者として、LPB Formatの発展とともにお客様のモノづくりに貢献できることを願っています。

（この記事は、2018年12月5日にメルマガで配信されました。）

第15回目はアンシス・ジャパン（株）の渡辺さんです。では、渡辺さんよろしくお願いします。

こんにちは。アンシス・ジャパンの渡辺です。
私とLPBの係わりについてお話ししたいと思います。
LPB-SC/WGがJEITAの組織として正式に発足する以前に「CPM Committee」と称して半導体メーカー、セットメーカー、EDAベンダーの数社が集まり、Chip-Package-Boardの協調設計について何度か話し合っておりました。2009年頃と記憶しています。私も現LPB-SC主査の福場様からお声がけ頂き、１回目の打ち合わせから参加させて頂きました。私にとって現在のLPB-SCとの関わり合いはその黎明期から、と言えるかもしれません。
当時、Apache Design Solutions社の商標であったCPM（現在はApache社の買収により弊社の商標）を用いてChip-Aware PIシミュレーションの検証を行った記憶があります。弊社はPackage & Boardの解析のみを荷っておりましたので、Chip-Package-Boardが揃ったシミュレーションを体験できたことは新鮮な経験でした。
その後、JEITAにおいてLPB-WGが正式に発足した後1年間は参加させて頂きましたが、諸事情によりその後は暫く参加できずにおりました。昨年より特別委員として改めて参加させて頂くことになりましたが、私が離れている間にLPB-フォーマットが制定され、更にはIEEE/IEC標準として承認されるなど、ほんの数年の間に目覚ましい成果があがっていました。メンバーの皆様には並々ならぬご努力があったことは容易に想像できます。これまで複数のJEITAの組織に参加させて頂きましたが、これ程までに目覚しい成果を短期間に上げられた組織は無いのではないでしょうか？
一方で、LPB-SCは協調設計の推進を目指しておりますが人と人とを繋ぐ機会でもあります。半導体メーカー、セットメーカー、部品メーカー、EDAベンダーが垣根を越えて設計環境向上の為に議論ができる雰囲気にあり、若手の方からも貴重な提案がなされています。設計環境が整っても作業を行う人が協調できなければ・・・その点で人と人との協調は大いに進んでいるのかもしれません。
L-P-Bの協調解析は弊社がフォーカスしている重要なソリューションの一つであり、G-Formatは弊社がDonationしているXFLフォーマットが基になっています。まだ弊社としては十分に対応出来ているとは言い難いですが、今後とも可能な限り協力させて頂きたいと考えております。

（この記事は、2018年11月8日にメルマガで配信されました。）

第14回目は（株）デンソーの市川さんです。では、市川さんよろしくお願いします。

「LPB」とは何なのか？フォーマット、プラットフォーム？．．．
私は思想だと思っています。

電子機器には多くの性能要件、制約条件などがあり、
それらが満足できないと製品を世に出すことができません。
一方で昨今の企業環境は、垂直統合の開発が少なくなり
一つの製品の設計、製造に多くの企業が関係しています。
その多くの企業が協力し仕様/制約条件を満足する製品を効率よく開発するためには
関係する企業間における設計思想の共有は大事であり、
その実現のために必要な設計情報は共有しなくてはなりません。
これを実現するのが「LPB」であると考えています。

今後迎える社会、つまりロボット、AI、自動運転が浸透していく社会では
信頼性の高い製品が増々求められます。
変革の中に置かれている製造業は「LPB」という設計思想を持ち
活用することが今後さらに必要になるのではないでしょうか？
また「LPB」にシステムの視点を加えた「sLPB」、「S-LPB」、「LPBS」とかに
発展させる必要もあると思っています。

（この記事は、2018年10月17日にメルマガで配信されました。）

第13回目は（株）ジェム・デザイン・テクノロジーズの村田さんです。では、村田さんよろしくお願いします。

　こんにちは。ジェム・デザイン・テクノロジーズの村田です。
　私は2012年にJEITA/LPBに参加しました。
　仕事では2002年末からICパッケージのフィージビリティスタディ用EDAツールの開発を始め、2005年ごろから半導体メーカーで使われはじめるようになりました。SiPやPoPも扱えたので基板にも使えるじゃないかということになり、2011年ごろから機器メーカーで基板の構想設計にも使われるようになりました。結果、基板～ICパッケージ～チップIO配置という範囲で使う初期プランナー、という立ち位置が定まってきました。前後して、私のツールで検討した結果をCADに接続することが求められるようになりました。お客さんが一緒に頼んでくれると、多くの場合は大手の同業者も協力してくれて、私は接続コマンドを開発することができました。しかし、時には競合するからと断られる場合もあり、CAD設計への移行が手作業になってしまう場合もありました。そんなタイミングでJEITA/LPBに誘われたのでした。
　聞けば、構想設計情報の交換フォーマットをEDA機種非依存で作る、とのこと。なんと！それが完成すれば、私のソフトではLPBフォーマットの入出力さえ作っておけば、接続CAD機種ごとの変換は不要になる！と期待して、一も二もなく、もろ手を挙げて賛成し、参加したのでした。
　半導体ベンダーや電子機器メーカーが集まって議論していると聞き、JEITAに参加するのが初めてだった私が想像したことは、メンバーの皆さんは、会社の看板を背負って激しく火花を散らし腕組みをして三角の目をしてにらみ合っている、のではないか、と思いました。しかしこれはまるで逆でした。皆さんで、机に乗り出して丸い目をして楽しそうに活発に建設的に議論しているではありませんか。とても驚きました。これは日本のV字回復まちがいなし！
　私が参加した2012年、JEITA/LPBでは後に国際標準となった版の国内版にあたるLPBフォーマットVer2 を一から作り始めるところでした。フォーマットはどんどん決まっていきました。この手のデータベースをEDA目線で開発すると、細かい事情を捨てきれず、つい盛り沢山の重いものになってしまうことが多いのですが、JEITA/LPBでの議論では「そんなところはツールに任せればよい」と枝葉末節をズバズバ切り捨てることができていました。他方、仕様情報やフロー情報といった側面については、EDA目線では情報収集が不足がちになることが多いのですが、JEITA/LPBでは「これは実務上必要でしょう！」とバシバシ取り込むことができていました。業務を熟知しEDAにも通じたユーザーならではの即決です。大いに感心しました。特にルネサス永野さん、東芝青木さん、富士通（現ソシオネクスト）中川さんの熱い積極発言が印象的でした。ツールへの実装を考えると若干粗削りの側面もありましたが、EDAベンダーからの参加メンバーのアドバイスに貸す耳ももっていて、カドが取れていきました。
　結果、LPBフォーマット Ver2はたった1年で、構想設計にフォーカスしEDA機種非依存、という、2重にユニークなEDAフォーマットに仕上がりました。早速私は、自社製ツールに入出力コマンドを搭載し、フォーマットと一緒に配布するサンプルデータのデバッグに使いました。
　技術的には良くても、進め方の問題で国際標準化がうまくいかない場合もあるでしょう。そのあたりについては、JEITA/LPBでは、効果検証・活用法検討・ユーザフォーラム形成などの普及広報活動や、他標準との連携、国際標準を目指したロビー活動、などが実にぬかりなく、しかもチームワークで、行われました。そしてついに2015年、LPBフォーマットVer2は、国際標準IEEE2401/IEC63055となりました。日本がリードした国際標準はEDA分野では初めてでした。
　LPBフォーマットVer2がJEITAとして完成したころから、JEITA/LPBの参加各企業はフォーマットを自社に持ち帰って実務に生かす取り組みを始めました。約1年後の2016年の第8回ユーザフォーラムでは事例発表が相次ぎました。その発表のほとんどに私のツールの名前が記載されていて、隣で聴講していた青木さんに「まるでジェム祭りですね」と言われました。大変うれしかったです！
　この手の標準はダメ押しの改善を経て普及版に至るのが普通です。LPBフォーマットの場合、Ver3 がそれにあたりそうです。Ver3の検討は、Ver2が国際標準化になった直後から始まりましたが、1年で形にしたVer2とは進め方が大きく異なり、他標準との調整や広く要望を聞く活動が3年をかけて丁寧に行われました。機器メーカーにおいて半導体を担当されているメンバーの意見が大きく貢献し、Ver2からの互換性を保ちながら、3次元情報追加・仕様情報充実・シミュレーションモデル包み込みなど、かゆいところに手が届く改善が施され、実用性がぐっと上がりました。LPBフォーマットVer3は、今年2018年の春にJEITAとして完成し、2020年の国際標準化に向けてIEEE/IECとしての検討プロセスに入りました。
　私としては、ユニークな国際標準の誕生と成長に立ち会うことができ、ここまで大変幸せでした。この先は、可能な限りひきつづき参加して日本発のEDA標準の行く先を見届けたいと思っています。今、世間では、良い製品を早く作るために製品開発プロセスの「フロントローディング」がキーワードとなっており、プロセス最初の段階である構想設計に注目が集まっています。構想設計はこれまでベテランの独り舞台であることが多かったと思いますが、今後は異分野の専門家の知恵を集めることも必要になり、そのための共通言語としてLPBフォーマットがピタリとハマります。日本企業にはLPBフォーマットの活用ノウハウについて一日の長がありますから、その強みを生かしてユニークな製品が今後どんどん生まれてきて、それを元にNHKが「電子立国日本～シリーズ2～」を作ってくれて、それを見たら見届けたことにしようかな。

（この記事は、2018年8月1日にメルマガで配信されました。）

第12回目は富士通アドバンストテクノロジ株式会社の大塚さんです。では、大塚さんよろしくお願いします。

　こんにちは、富士通アドバンストテクノロジの大塚です。
　ＬＰＢには２０１２年度から正式参加させていただいています。それ以前は半年ほどオブザーバ参加させていただいていました。
チップ積層実装やシリコンインターポーザが話題だった頃の話です。当時は富士通グループも半導体ベンダーでしたが、今はＥＤＡベンダーやシステム設計の立場で参加しています。
　富士通アドバンストテクノロジは、電気系及び構造系のＣＡＤツール、ＰＣＢ設計のコンサルサービスを提供しているエンジニアリング会社です。
私は、元はＬＳＩやＰＣＢの配線エンジンを開発していて、現在はＰＣＢの設計(回路・実装)を扱うＣＡＤシステム開発部隊に所属しています。

　ＬＰＢの活動グループの中では、私は主にフォーマットを策定するグループに参加しています。
個人的な見解ですが、通常の業務では、既に存在するデファクトスタンダードな仕様に従うか、
自分たちで仕様を決めてプログラムを書くことに専念しがちで、標準を作ることはあまり意識しません。ですから参加当初は国際標準化どころか国内の標準さえも何処で作られているのか全くイメージできないという感覚でした。
　ＩＥＥＥ標準を狙います、という方針が示されたときは、テクニカルライターを雇うと４０万/月と聞いて、「無理でしょ。。。」と思いました。
しかしいつの間にか自分たちでやっちゃえという流れになって本当にやってしまった。リーダーの方々の導きとメンバーの真摯な対応の賜物だったと思います。
　今年度はＩＥＥＥ２４０１－２０２０に向けてドラフト作成が始まっています。５月にそのキックオフをしたかと思ったら、「ＤＡＣの時にＩＥＥＥメンバーにドラフト案を説明する機会を持てそうだから１か月前倒しで準備できる？」というリーダーの一声にみなさん嬉しそうに^^反応して速攻で対応した結果、またまたドラフト第１版案ができてしまいました。ちょっとＭ体質なのか、業界のために頑張る気概がそうさせるのか。

　ＬＰＢに参加して、良かったと思うことはいろいろありますが、業界のために真摯に頑張る方々の姿を目の当たりにすることができたことをまず挙げたいです。志というやつでしょうか。見習わねばと思うことが多いです。
　２つめは自然と仕事の幅が広がっていくこと。レイアウトのツール開発が主務だったりすると、
それ以外のツールを操作する機会は多くありませんでしたが、ＬＰＢに参加しているとシミュレーションツールを使って実証をする必要性が生じて、実はあまり使い込んでいなかった電気シミュレーションのやり方を勉強する機会を得た感がありました。ＬＰＢフォーマットはカバーする範囲が広いので、話題についていくために情報収集の間口が広がったかな、とも感じています。
更に、みなさんおっしゃいますが、会議後に親睦を深める機会が多いので、メンバーの打ち解けた関係性を築けている事が財産だと思っています。スーパーユーザーやＥＤＡベンダのエンジニア間で仕様の検討ができる、解釈で疑問が生じたらすぐに本来の意図を確認できるという風通しの良さは仕様の適切さを保つのに欠かせない事だと思っています。

　普及に向けて、村田製作所様のＬＰＢフォーマット版部品ライブラリが着々と準備されていたり、環境は徐々に充実してきていますが、今年はＩＥＥＥ２４０１－２０２０のドラフト策定が計画通り(前のめり気味に？)進むよう、微力ながら貢献できればと思っています。
拙文にお付き合いいただきありがとうございました。

（この記事は、2018年7月4日にメルマガで配信されました。）

第11回目はメンターグラフィックス・ジャパン株式会社の門田さんです。では、門田さんよろしくお願いします。

こんにちは。メンターグラフィックス・ジャパンの門田です。

私とLPB。。。。長い付き合いになります。
現在もLPB-SCの中核を担っていらっしゃるみなさんとは、私がA○○○T社に在籍中からのお付き合いとなります。
歳も取ります(^_^.)
LPB Formatの標準化がJEITAでの活動となった際、会社都合で一時期遠ざかっていたのですが、
私がNimbic社の電磁界ツールの取り扱いを始めたのがきっかけでJEITAでの活動に参加させて頂きました。
結果的にNimbic社がメンターグラフィックスに買収され、現在メンターグラフィックスとして参加している次第です。

これまでの私の活動としては、自社開発部門へのフォーマットサポート提案をしつつ、実際にフォーマットを活用した事例を作成して、
毎年恒例のLPBフォーラムなどでご紹介してきました。
開発へのフォーマットサポート提案については、鶏と卵の世界で、簡単にはいきません。
ユーザーがいなければサポートしない。EDAがサポートしてなければ使えない。。。といった具合です。。。
そこで現在の対応としてScriptを使用してLPB Formatを活用する方法を提案しています。まずは使ってもらわないと始まらないということです。

フォーマットを標準化することは大変なことですし、国際標準化を成し遂げたことはすごいことだと思います。
ただし、ここからが本番です。いかにこのフォーマットを活用して日本の電子機器設計の効率化を図って国際競争力とするか。大事なところです。
私は広報活動を担うタスクグループに所属していますし、EDAベンダーとしてもユーザーが増えることは重要です。
より良いフォーマットに改版していく活動とともに、今後多くのユーザーに活用してもらえるよう活動していければと思っています。
今後もはりきって活動していきたいと思います！いい流れは途切れさせないように！

（この記事は、2018年5月9日にメルマガで配信されました。）

第10回目は株式会社図研の古賀さんです。では、古賀さんよろしくお願いします。

こんにちは、図研の古賀です。
２０１０年からＬＰＢに参加し、主にＥＤＡベンダーの視点でＬＰＢフォーマットの作成に協力させて頂いております。

会社での業務は、２００６年頃からＬＳＩ／ＰＫＧ／ＰＣＢ協調設計環境の課題について取り組み始めました。
数年後、いくつかのソリューションを出し始めたころ、主査の福場さんから声を掛けて頂き、ＬＰＢに参加する事になりました。

ＥＤＡベンダーとして、これから作成するＬＰＢフォーマットの内容を考えてゆく必要があったと思いますが、
私は図研に入社して最初の配属は回路図エディタのアプリケーション開発だった為、
ＬＰＢに入った当初はレイアウトツールのデータベース構造も良く理解しておらず、
貢献するというよりも、勉強することの方が多かったと記憶しています。

お陰様で、色々と勉強させて頂き、ＬＳＩ／ＰＫＧ／ＰＣＢそれぞれの領域で異なる設計文化があり、
同じＣＡＤでも各社各様でツール毎に様々なデータ構造があるという事が分かりました。

半導体業界では標準化が進んでおり、ツール間のインターフェースも比較的スムーズにできている一方、
ＰＫＧ／ＰＣＢのＣＡＤでは標準化が進んでいませんでしたが、
ＬＰＢフォーマットが生まれたことで、部品情報（受動部品など）が
ＰＫＧ／ＰＣＢ設計、解析までつながり、大きな効果が見えてきました。
また、相互変換できないＣＡＤデータを意識せず、構想設計段階で一気通貫に
やりとりができるようにもなりました。

恐らくＥＤＡベンダーだけが集まって、標準フォーマットを作ろうとしても収拾が付かなかったと思いますが、
ユーザー様が中立的な立場で、現場で必要とされる情報だけを纏めたお陰でＬＰＢフォーマットが完成し、
国際標準まで持って行くことが出来たのだと思います。

ここまではＬＰＢでの活動内容に関する話しでしたが、私は図研の中でも２つやる事がありました。

１つ目は、ＥＤＡベンダーとして最も期待されていた、インターフェースの開発です。
フォーマットが作られてもツールが対応しないと多くの人に使ってもらうようなフォーマットに広げていくのは難しいですが、
ユーザー様がいない中での開発の着手は簡単ではありませんでした。
それでもＬＰＢメンバーの熱い思いを社内にも伝え、何とか開発に漕ぎつけ、
ＥＤＡベンダーとしては先駆けてＬＰＢフォーマットを対応させて頂きました。
今では様々なＥＤＡツールがＬＰＢに対応し、アンシスの渡辺さんが先日のＬＰＢフォーラムで仰られていたように
卵と鶏の議論からヒヨコが生まれてきた状況になってきたと思います。

２つ目は、自社のＬＳＩ／ＰＫＧ／ＰＣＢ設計環境の構築です。

ＬＰＢでは様々な業界にいる様々な立場の人たちがいらっしゃって、その中で議論される内容は大変貴重なものでした。
ＬＰＢに参加させて頂いた事で、半導体からシステムまでのモノづくりの流れやサプライチェーンの仕組みを知ることができたと思います。

議論の中では、フォーマットで解決される課題もありましたが、手作業でのインターフェースは
ヒューマンエラーの原因となり、ＥＤＡツール側でも出来る事も色々ある事が分かり、
ここで得られた貴重な情報を参考に、自社の設計ツールの開発に役立てて行くことができました。
今はその設計環境をお客様に提供できるようにましたので、少しでも恩返しが出来ていれば良いなと思います。
最後に最近のＬＰＢの課題について。
前述したとおり、各社ＥＤＡツールのデータの持ち方は様々で、フォーマットとの差によって、多少解釈に違いが出てきてしまいます。

今いくつかの会社でＬＰＢを使ったベンチマークが行われ始めており、
解釈の違いで問題が出てきていますが、ＬＰＢのワーキンググループでは、それらを吸収するＨＵＢも用意されているようで、出てきた課題に対して、すぐに対応するところもＬＰＢの良いところだと思います。

解釈の違いを完全に是正していくのは難しい問題ですが、ひとつひとつきちんと取り組み解決していくことでＬＰＢが成長し良くなっていくものだと信じておりますので、
日本初の世界標準フォーマットをお客様の設計環境の中でもどんどん使って頂ければ、と思います。

最後までお付き合い頂き、ありがとうございました。