基本的にプロジェクトはSTAIRS UPによる着実な積み上げによって進んでいきますが、前例のない新規開発などでは、未確定要素が多すぎて「論理や数字だけでは打破できない膠着(こうちゃく)状態」が必ず訪れます。
そのとき、私たちは限定的に、完璧な要件定義を待たず、取りあえずの仮説を形にして必要な情報を引き出します。こうした「仮説を先に置き、そこから必要な情報を探る」アプローチ(アブダクション=仮説的推論)を活用するのです。直感でアイデアを一気に未来の姿へと飛躍させ、具体的な形として展開するこのアプローチを、当社では「JUMP(ジャンプ)」と呼んでいます。
このJUMPは、制約を無視した「絵に描いた餅」ではありません。「もしビジネスと技術の要件を極端に振ったとしたら、こういう姿や構造になるはずだ」という、論理のギャップを埋めるための意図的な跳躍です。
足りない情報がそろうのを待つのではなく、直感(JUMP)で飛躍させた具体像を投下し、そこから得た事実を基に再び論理(STAIRS UP)で構造化するのです。この一連の動作が、議論の収束と手戻り削減という強力なメリットを現場にもたらします。
言葉だけの議論では、参加者一人一人の頭の中に異なる「解釈」が生まれます。しかし、そこに1つ、制約を加味した「形」があるだけで状況は一変します。形という「共通の基準(レファレンス)」が目の前に提示されることで、チーム全体の認識がそろい、「このサイズだとバッテリーが入らない」「この位置なら配置できる」という、具体的かつ建設的な「ツッコミ」が引き出せるようになるのです。
「取りあえず形にしてみよう」といっても、ハイクオリティーなイメージ画像を作るべきか、メモ帳にパパっと描いた簡易スケッチで十分なのか、それとも模型にして触れるようにしなければいけないのか――。「何をどう確かめるべきか分からない」と悩む方は多いでしょう。
プロトタイプは「完成予想図」ではなく、あくまで「会議でのコミュニケーションを成立させ、仮説を検証するためのツール」です。従って、その解像度は「論点を説明するのに必要な解像度」と「対話する相手の解釈力(想像力)」に合わせて柔軟に調整する必要があります。
最も大切なのは、形を提示する前に、「今回は、この論点(例:装着感)を確認するためのツールであり、それ以外(例:色やロゴ)は未定である」という前提を言葉やテキストで事前に合意しておくことです。この「翻訳機としての設定」を怠ると、プロトタイプはかえって混乱を招く原因になりかねません。
Copyright © ITmedia, Inc. All Rights Reserved.
メカ設計の記事ランキング