プログレス・テクノロジーズが手掛ける「PT DBS」とは？【前編】 〜 属人的な設計ノウハウを可視化しDXへ転換する〜

DX化の波や技術伝承、技術力向上……設計部門を取り巻くさまざまな課題は、ものづくりを手がける企業なら多かれ少なかれ悩みの種となっていることだろう。問題は複雑に絡み合い、「どこから手をつけていいかわからない」状態に陥っているケースも珍しくない。

そんな設計部門が抱える課題を現場に入り込んでソリューションしていくサービスがある。プログレス・テクノロジーズ株式会社の「PT DBS」だ。

すでに製造業では名だたる企業と取引しており、建設・土木業界からの引き合いも増えてきているという。果たしてどのような手法で業務改革へと導いているのだろうか？

そこで今回、プログレス・テクノロジーズ株式会社の取締役CTO 長友一郎氏、取締役兼経営企画室長 小林正隆氏、ブランディンググループ グループ長の牧田 恵理子氏（以下、敬称略）の3名に話をうかがった。

インタビュー前編では製造業の事例を参考にPTDBSのソリューション手法について解説していただく。

テクノロジーを愛する人と共にイノベーションを生み出し続ける

――「PT DBS」は設計部門が抱えるさまざまな課題のソリューションになるとのことですが、具体的にはどのようなものなのですか？

長友：PT DBSは「Progress Technologies Design Basis Solution」の頭文字を並べたものです。“System”という単語を使っているので何かのツールのように思われるかもしれませんが、設計根拠にポイントを置いたソリューションのパッケージサービスです。


設計根拠とは、何かモノやコトを作り出すための設計ストーリーのこと。設計の根拠、つまり「なぜこの形にしたのか？」が明確になっていないと、ちゃんと設計したことにはなりません。製造業においてこの部分がブラックボックスになっているケースは珍しくなく、ハンドリングも難しい領域と言えます。


それをなぜ私たちができるのかというと、創業以来ずっと製造業の設計開発に特化しており、ほぼ全員が技術者なので「設計をどうしたらいいか」と常に考えているのです。設計者がコンサルのノウハウを身に付け、お客様と共に血の汗を流しながら数多くの業務改革に取り組んできました。これまでの経験から各社に共通する悩みを抽出し、このソリューションパッケージを生み出すことができたのです。

――社員のほぼ全員が技術者！どのような会社なのか詳しく教えていただけますか？

牧田：プログレス・テクノロジーズは2005年に創業、社員の9割がエンジニアという組織です。私たちの事業をひとことで表すと「ものづくりをより良くするためのサービス提供」。

実際にはコンサルティングサービス、システム開発、ソフトウェアの販売およびサポート、アウトソーシング・運用サポート、新技術調査・研究開発・共同研究といったことを行っています。また、3D CADの「CATIA」をはじめ解析ソフトやシミュレーションツールを手がけるダッソー・システムズのパートナーを務めており、同社の各種ツールの導入もお手伝いしています。


当社が掲げるビジョンは「テクノロジーを愛する人と共にイノベーションを生みだし続けることにより、社会問題の解決に寄与しています」というものなのですが、皆ものづくりが大好きで、イノベーションにワクワクするエンジニアリング集団。そういう人たちが集まってものづくりをより良くするサービスやものづくりそのものを行っています。


ものづくりのやり方を考えて、実際に現場に定着させて、ものづくり自体もワンストップでやっていることが強みです。また、最先端技術への柔軟性が高く、新しい技術が出てくると積極的に挑戦し、お客様と共に技術開発に取り組んでいく点もご好評いただいています。

新しい技術をどんどん取り入れ、日本のものづくりの代表格とも言える自動車関連企業や車載製品中心とした幅広い企業様にサービスを提供しています。
――「ものづくりを愛する人と共に」とビジョンにもありますが、取引先はどのような業種が多いのでしょうか？

小林：現状では自動車業界が中心となっていますが、そこに絞っているわけではありません。“ものづくりを愛する人”とはつまり、ものづくりやテクノロジーに興味を持たれている人たちのこと。ものづくりに取り組むお客様と共にイノベーションを生み出していきたいという考えです。


当社は設計開発分野に特化したエンジニアリングプロフェッショナルファームです。ものづくりにおいて最初の起点が設計開発の分野と考えており、この最も上流部分に対してコンサルティングやソリューションを提供したり、あるいはプロジェクトをまるごと引き受けさせていただいたりするケースもありますし、当社のエンジニアがお客様先に常駐して一緒に設計開発をお手伝いしているケースもあります。

特定の業界やジャンルに傾注しないことで、A社とのお付き合いで経験したことや得たノウハウを別ジャンルのB社へのソリューションに活かせることがあります。業種も企業規模もさまざまなお客様とお取引させていただいている状況を活かしてサービスの拡充に励んでいます。

属人的になりがちな設計部門のノウハウ・ナレッジを可視化

――多種多様なクライアントと取引されており、多く経験からものづくり企業が抱える課題を抽象化していったものが御社のノウハウになっているのですね。

長友：そうです。新しいツールを導入すれば何か良くなる、業務改革になるのではないかと考えている企業はよくあります。しかし、実はその手前が非常に重要なんです。課題を解決するのを阻んでいるもの、お客様自身も手を突っ込むのが嫌な領域に私たちはあえてメスを入れ、真の設計の改革に取り組んでいます。

――メスを入れるとは、どのように？

長友：たとえばここにボイスレコーダーがありますね。このボイスレコーダーは意図があってこの形をしているはずなんです。


ボタンの大きさや配置などですね。設計者に「その理由は何ですか？」と尋ねたとき、設計者ならその理由を答えられないといけない。設計根拠があって設計されたはずなので。それが、「よくわかりません」「前からそうなっていたので」という返答がかえってくることがあります。

――設計根拠が把握できていない状態のメーカーが少なくないということですか。

長友：さまざまなお客様を見てきて、日本の製造業は苦境に立たされているなと感じます。それは業種を問わず、土木・建設業界にも同じことが言えるのではないでしょうか？

――設計が属人的になっているといった課題は共通しているでしょうね。それを御社がどのように解決しているのか気になるところです。

長友：あまり具体的な例は出せないのですが、似たような事例は少なくありません。たとえば、社内で情報がどこにあるか。情報は人にくっついているんですよね。物理的にはファイルサーバーにあるとかシステムに入ってる、紙ファイルにとじてあるのですが、その情報は人がつないでいるんです。


――担当者がいなくなったら情報がどこにあるかわからなくなるような事態はよくありますね。

長友：そうなんです。つまり都度対応をしているので情報が溜まらず、技術伝承どころか現状維持で精いっぱいになっている。「過去にこういう経験をした」という話が設計部門の中で伝わっていくことがいわば技術伝承なのですが、それができていない。


過去にした失敗を知っていれば、次に設計する時に最初に気を付けるはずですよね。それができていないと設計の手戻りなど同じことを毎回繰り返してしまいます。

設計工程の中だけの話ならまだよくて、ものを作った後にお客様のところで壊れてしまったりクレームやトラブルになったりすることもあります。そうなると緊急対応が必要になり、日常業務を後回しにして火消しに回らなければならない。

――目の前のお客様に対応するのにリソースが割かれてしまい、本来やるべきことにまで手が回らないとか…。

長友：そういうことにもなりますね。他には、DX化を謳っている企業に「どんなところがDXなんですか？」とおたずねすると、回答が漠然としている。実際はそれほどDXを推進できていないということも少なくありません。

――ツールを導入して終わっているような状態なのでしょうか。

長友：本来のDXの手前で止まってしまっているんです。ユーザーエクスペリエンスを変えようとか、ICTを使って新しい情報など何か付加価値を付けてハードとセットでコトを売るようなことも残念ながら十分にできていないケースが多い。

それはなぜかというと、結局、部分的にはツールが入っていたり改善に取り組んでいたりしていたとしても、全体的にはまだシステム化が不十分だからです。

全体がつながらないと、先ほどのボイスレコーダーのボタンの例のように、これを変えると何がユーザー体験に効いてくるかというのが分からないのです。


設計根拠の要点となる要求・要件（Requirement）、機能（Function）、ロジック（Logic）、設計パラメータ（Physical）をまとめてRFLPと呼んでいますが、これらのつながりが本来はとても大事で、設計者はこれを意識しながら設計しなければならないのです。

ツールでごまかさず、まずは設計プロセスを整理する

――設計根拠においてPFLPのつながりが大切とのことですが、問題のある状態ではどうなっているのでしょうか？

長友：製造業の一連の流れは、企画から仕様決定、構想設計、基本設計、詳細設計、評価検証、図面化というふうになっていて、要求～機構～設計パラメータというつながりがわかった上で形状を作らないといけません。

それが、前のものがあるからそれをとりあえずコピーして、ちょっと変えて、とりあえずできているからこれでいいでしょうという状態になっている。本来は性能を作らないといけないはず。ユーザー体験を変えるためにどこを変えるのがいいかを検討すべきなんですが、そこが抜けている。それなのにコピーすれば3Dデータはできてしまうので…。



――容易に3Dデータが作成できることで、なんとなく「できた」と感じられてしまうんですね。

長友：そうなんです。昔は地道に手描きで線を引いていたので、1本の線を引く手前でさまざまな検討が重ねられていました。もちろん今も2Dで設計されているところはあるでしょうが、3D CADで過去の図面をサクッとコピーしてからスタートするというやり方では根拠があいまいになり、ノウハウやロジックが点在化してしまいます。

その結果、担当者に「このボタンはなぜこの大きさで、なぜここにあるのですか？」と質問すると「よくわかりません」という返答が出てきてしまうんですね。


いろんなところから探して、寄せ集めて、情報をくっつけて、こねくり回して根拠っぽいものを作り、言い訳しながら次に進む。少々乱暴な言い方かもしれませんが、このようなことが現場では起きています。

本当はいろいろ検証したいとは思いつつも時間がなくて、せいぜい数パターンしか試せない。もっといい形状とかユーザーエクスペリエンス的にいいものとか、本当はもっといい解があるのではないかと思いつつも模索する時間が取れない、と。

図面を出した後にこれで本当に良かったのかと後追いで検証するとか、そもそも適切な解析のやり方がよくわからない、シミュレーションってどうやったらいいかわからないというケースもあります。


ユーザーエクスペリエンス（UX）を変えるためには、どのパラメータをどれくらい変えればいいのかというところを最初に分析する必要があるんですね。さらには、「そもそもユーザーエクスペリエンスって何？」という定義から検討する必要があり、かなり大変な作業です。

現状、多くのメーカーでは勘と経験で商品を作り込んでいるような状態。土木の世界でいえば、図面を受け取った施工会社が工事を始めてみたら干渉するところがあったので、現場の判断で穴を開け直した、とかですね。

よくある話ですよね？この情報は設計工程のところへ伝わらないといけないんですけど、それができていない。これではいけない。商品性を最初に作り込むまでは形状を作らないというやり方に変えていきましょうと提案させていただいています。

もちろん言うは易し行うは難しではありますが、結局、ユーザーが何を望んでいるか、それが製品のどこに紐づいているかが重要。つまり、要求と機能と構成ロジック（設計パラメータを含む）の関係です。


図面作成には設計パラメータが必要で、ボタンの大きさや押し心地は仕様のような形で測れるものに変えなければ設計できません。ユーザーが心地いいボタンの押し心地は何ニュートンですといった風に感覚を数値に変換する工程があるべきなんですけども、そこがうやむやなまま「何ニュートン」という数字だけが設計データに記されいることがあります。

――数字だけ出てきて、その数字の根拠がぬけ落ちているということですね。

長友：そうです。ボタンになった何らかのロジックがあったとしても、根拠によってはボタンではない別の手段でもいいということになります。機能を満たすためならボタンでなくても、液晶を使ってタッチスクリーンにしてもいいのではないかとか、他の手段の選択肢が出てきますよね？この選択がユーザー体験を変えることになるんです。

「ボタンのままでいいのか？」という問いが無いままボタンを選択している。とはいえ「なぜこのパラメータなのか」というのは物理形状の検討においては無限に出てきます。では何が判断のカギになっているのかというと、ナレッジで判断されているのです。全部をイチから検討していると選択肢は膨大になるので「今回はここだけいじればいいよ」という話になっているのですが、そういった判断はノウハウをもったベテランしかできません。

これまでクレームが出ないユーザー体験を提供できる製品が作れていたのはベテランが頭の中で情報をつないでいたから。それが、ベテランが徐々に定年退職していくと、後輩は大きく変えるのが怖いので過去のものをコピーしてちょっと変えるくらいしかできないという展開になっていくわけです。

ベテランの頭の中にあるナレッジ・設計プロセスを取り出して、設計部みんなで活用できる方が効率的になるのではないかと私たちは考えます。

ちりぢりになっている設計情報やエビデンスを整理

――ノウハウを技術伝承してきたベテランがいるうちはいいけれど、そうでなくなる時に備えてということですね。

長友：そうです。特定の人のところに情報が集まっているとか、根拠がない中で設計をしていくというのはDXに逆行しています。

イメージを掴みやすいように、こちらに椅子の設計プロセスを示しています。まず、要求は「人が座っても壊れないこと」とありますが、椅子って本当に座るだけでしょうか？ユーザーはそこに立つかもしれない。しかも荷物を持っているかもしれない。椅子を脚立のような使い方をすることがあるかもしれない…というふうに考えていかないと、要求が正しく定義されたことにならず、根拠がひも付かないのです。


なぜこの形にするのかとか、この形で大丈夫と言えるのかというところを検証する工程も必要なのですが、根拠が紐づいておらず抜け漏れたり、不十分になったりしているケースもあります。お客さんが使って1年ほどで壊れてしまった。そうするとクレームという形で手戻りしてしまいます。

これが単発のものならまだいいですが、次の設計にこの経緯が伝わらなければ同じことを繰り返してしまうでしょう。こういった負のスパイラルが、現場を疲弊させているという側面もあるのではないかと思います。


また別のケースとして、ICTを使って座った人の腰痛を改善するようなユーザー体験を足せという指示があったとします。それなら座ったときに腰が疲れているかを識別して、整体師を呼ぶといった機能を付けようという展開になっている現場があるとします。

それでいいのでしょうか？もし腰痛に関係している椅子の物理形状が明確になっているとしたら、椅子側で別の改善手段を提供するためにICTを使おうとなるかもしれません。

最近はICTのためにとりあえずセンサーを付けようという案が散見されますが、それでは本当のユーザー体験を変えることはできません。「何か足せばいい」というような発想では勝負できない時代になってきていると感じています。

――なるほど、付加価値を付けるにしても情報の整理が大切ということですね。

長友：そもそも設計に必要な情報は何かを整理する必要があります。それが情報はもちろんツールやシステムまでもバラバラになっているケースは多いですね。

これは建設・土木業界にも同じことが言えるのではないでしょうか？上流で必要な情報は何かとか、必要なデータの種類や内容をあらかじめ検討しておく必要があるのにそこが抜けたままBIMのツールだけ購入しているとか…。

――そういうことはあるでしょうね。

長友：そのような状況でお困りのお客様にPTDBSメソドロジーを使って設計プロセスの整理を行い、ノウハウやナレッジを可視化していきます。

――ベテランなど特定の人だけがノウハウやナレッジを持っていてそれを可視化したい場合や、情報が点在しているのを整理してDX化したい場合にPT BDSは有効ということですね。


【編集部 後記】
アナログからデジタルへの移行や開発期間の短縮化といった時代の移り変わりによって設計部門の立場はますます過酷になっている。今後、DXへの大転換に適応するためには、プログレス・テクノロジーズが示すように情報の整理を軸にした設計プロセスの改革が迫られるのではないか。

後編では、「PT BDS」でのソリューションの流れを解説いただくと共に、建設・土木業界での事例についてご紹介いただく。


プログレス・テクノロジーズ株式会社
東京都江東区青海1-1-20
HP：https://progresstech.jp/