News and Views 2014 Autumn / Vol. 11: Info Topics

探し物は何ですか?見つけにくいものですか?

先日、発売が大きな話題となったiPhone 6を購入しました。iPhone 4Sからの買い替えだったので、テザリングもできるようになったし、また楽しみが増えたなと新しいオモチャにワクワクしていました。しかし購入早々、不注意でiPhoneを紛失させてしまいました…

図1. iPhoneを探す図1. iPhoneを探す

出先で何かを紛失してしまった場合、その回収を試みる際にはさまざまな選択肢があります。またその実行プロセスの順番には決まりがなく、一切が任意の状態にあります。交番に紛失届を提出する、その場に同席していた人間に確認する、外出中に立ち寄っただろう施設のすべてに問い合わせる、その際の経路を再度辿ってみる…そして、万策尽くしても見つからなかった場合には、失ったものを乗り越えていくしかありません。

しかし、iPhoneを紛失してしまった場合の対応方法は、上記とは全く異なります。同機種のデバイスをお持ちの方ならお分かりの通り、最初に行うべきことは、「iPhoneを探す」のGPS機能を使用し所在が分からなくなってしまったデバイスの位置を確認することです。記憶している限り、最後にデバイスに触れたのは横浜でした。プロトコル通りに「iPhoneを探す」アプリケーションを起動させてデバイスの位置を確認すると、驚くべきことに、横浜で紛失したはずのiPhoneが、なぜか池袋に移動していました。誰かが拾って持ち去ったと考えるのが妥当でしょう。

次に行うべきは、同じアプリケーションからデバイスを紛失モードに設定し、その表示画面上に拾得者に対して連絡を呼びかけるメッセージを表示させることです。この紛失モードに設定することにより、デバイス内のデータアクセスが制限されることから個人情報やその他のデータの安全は守られますが、それでも悪意のある人の手に渡る危険性を考慮し紛失したデバイスの回収が不可能と判断した場合には、デバイス内の全データを削除し出荷時の設定に戻します。その後は忘れずに最寄りの交番で紛失届を提出します。幸いなことに、今回の場合は拾得者から連絡が入り、無事手元にiPhoneが戻ってきました。

さて、紛失物を見つけ出すには、今までは文字通り手さぐりですべての可能性を確認していく必要がありましたが、その紛失物がiPhoneである限り、「iPhoneを探す」を活用して系統立てた無駄のない最良の方法で探し出すことができます。このアプリケーションは、ものを紛失した際にどうすれば一番見つけやすく、また紛失の被害を最小限に抑えられるか検討し尽くした結果を、厳密に要件として定義して開発されたのではないでしょうか。

このような仕様の実現は、アプリケーションソフトウェアだけでなく、ミドルウェア、IC、プリント基板やディスクリート部品、表示デバイス、センサなど、実に数多くのドメインと工程から成り立っています。ある工程から次の工程へと移るとき、次の工程に余分な負荷を押し付けないことは非常に重要です。前工程から後工程へと累計的に加算される負荷は時として、製品開発スケジュール自体を脅かす「手戻り」として跳ね返ってくる恐れがあるからです。これは単に開発チーム内だけの問題にとどまらず、モノづくりを担うエコシステム全体について言えることではないでしょうか。例えば、自動車業界におけるサプライヤからOEMへの流れ、ICやPCBの設計から製造への流れについても当てはまると思います。

図2. モノづくりにはさまざまなドメインが相関図2. モノづくりにはさまざまなドメインが相関

ところで、メンター・グラフィックスが推奨している設計手法として「Correct by Construction」が挙げられます。これは、「構築しながら正しい結果が得られる」設計および開発のアプローチであり、逆に言えば「間違ったモノを作り出してしまうことがない」手法、つまり次の工程に余分な負荷を押し付けない手法です。要求仕様を要件として定義する工程であれば、機能、構造、振舞いなどを形式手法でモデル化し、そのモデルを使って厳しく検証、分析する必要があります。機能安全やセキュリティが求められるアプリケーションであれば、この工程は特に重要です。そして次の工程であるICやソフトウェアの実装に向けて合成することにより、「Correct by Construction」手法により裏打ちされたコードが得られます。また、自動車のワイヤ・ハーネス設計支援では、機械設計の情報、システム論理接続、装備仕様や制約などを元に、ワイヤの配線図やハーネス図、サービスドキュメントを自動合成します。これも「Correct by Construction」手法が適用されている一例です。

ある工程から次の工程への流れを考えることも重要ですが、ある工程から手前の工程にフィードバックすることも大切です。それは工程によってはバックアノテーションと呼ばれるものであり、また別の工程によっては遵守すべきルールや制約項目として表現されます。例えば、ICの歩留まりを向上させるためのビア追加を始めとするレイアウト改善もその1つです。PCBの実装上問題となる部品の高さや特定部品下の配線、シルクと部品スペースなどを実装ルールや制約として設計工程にフィードバックし、制約駆動でレイアウト作業することも「Correct by Construction」手法に則っていると言えるでしょう。複数の工程をまたがる相互理解には、人によるコミュニケーションよりも、ツールやデータベースによるコミュニケーションが有効です。

メンター・グラフィックスは、設計自動化を支援するツール群はもちろん、複数のドメインや工程に渡ってコミュニケーションすることが可能な仕組みを提供しています。ワイヤ・ハーネス設計における要件定義、設計、製造、保守整備の連携を緊密にするCapitalとその一元化されたデータベース、形式モデル化の言語UMLに対して実行かつ合成が可能なBridgePointとxtUMLサブセットの定義、PCBの設計と実装、製造をインタフェースするODB++などはその良い例証です。

モノづくりの際に「Correct by Construction」手法を意識してみると、より効率的な開発が実現できるのではないでしょうか。そして日々の行動時にそれを意識すると、もしかしたら、不注意なものの紛失も防げるかもしれませんね!

乱筆にて。

(ゆり)