開発プロセス
画像認識
アンチパターン
ソフトウェア開発

仮説の上に仮説を重ねてはならない - 画像認識を例に -

新しい技術を開発する際には、仮説の上に仮説を重ねてはならない。
仮説の上に仮説を重ねて、計画を立案すると、無理な計画を立ててしまうことにつながる。

仮説に仮説を重ねると、その上の議論はとても崩れやすいものになる。
最近、深層学習がハイエンドの状況でとても良好な結果をだしてきている。しかし、実際に自分が実装すべき状況においては、「ハイエンドの状況をそのままトレースすればいい」とはならないことが、開発のほとんどの状況だろう。ある技術はAということを達成した。別の技術はBということを達成した。
「じゃあ、あとは2つを組わせるだけだね。」

期待するのは勝手だが、そうなる保証はない

Aを可能にしたある技術とBを可能にしたとを組み合わせてうまくいくのかどうかは、やってみなければわからない部分がある。
Aを可能にしたある技術の範囲と、Bを可能にした別の技術は、相容れない前提をもっているかもしれない。
AとBとを同時に達成することができるとはかぎらない。組み合わせることでAとBとを同時に実現できると考えることは仮説にすぎない。
ビジネスとして開発している場合には、失敗したときの影響を考えたアプローチをしなければならない。
(失敗しても影響が小さく、新しい可能性を試してみないことの損失の方が大きいときは、この限りではない。アンダー・ザ・テーブルや、10%ルールとかで個人の裁量が認められている場合は、このかぎりではない。)

仕事として開発していてその開発の成否が組織の運営に大きく影響を与える場合、そのことを考えぬかればならないというあたりまえのことしか言っていない。

だから言う。
「新しい技術を開発する際には、仮説の上に仮説を重ねてはならない。」
仮説に仮説を積み重ねると、いろんな落とし穴が待ち受けることになる。

待ち受ける落とし穴1

CPUの処理量が追いつかない。

こういった状況のうち、CPUの性能を上げれば済む場合にはまだ扱いがいいほうだ。原価の見積りをやり直して、CPUボードの基板の設計をしなおせば解決するのだから。(それでも、原価の上昇と発売の延期という経営上へのインパクトは無視できない。)

待ち受ける落とし穴2

計算精度がでない。

センサの能力が足りない。

想定したセンサとライブラリの組み合わせで、期待する精度がでないということが起こりうる。
例:  
ステレオ計測の場合
 ステレオ計測に使用するライブラリは、視差を1pixel単位で求めるものなのか、0.1pixel 単位で求めるものなのか?
 ステレオ計測に使用するカメラの画素数はいくらで、1度あたりのpixel数はいくらなのか?
 ステレオ計測に使用するカメラのカメラキャリブレーションは、どの程度の残差で行える手法を用いているのか?
 ステレオ計測に使用するカメラのカメラキャリブレーションは、どの程度の残差で行えたのか?

例:
 駐車場に入る車のナンバープレートの認識の場合

 撮影に用いるカメラの画素数、レンズの画角、レンズの特性、カメラの明るさ
 などが影響する項目として頭に浮かびます。

 静止している車のナンバープレートを各距離でどのように見えて、どのようにナンバープレートの認識ができるかを実験して
 装置の設計をしたとします。
 
 それでも、センサの能力が足りないという状況になりうるのです。

 静止している車のナンバープレートの撮影画像と、走行している車のナンバープレートでは見え方が違います。
 走行している車を撮影すると被写体(この場合は車)の動きによるブレを生じます。
 そのため、露出時間を短くして、ブレの影響を低下させようとします。
 そうすると、画像のノイズレベルがあがります。
 
 ノイズレベルがあがると、ナンバープレートの認識が失敗しやすくなります。

 そのため、対策としては、ライトの光量を増やすことや、より光量の得やすいレンズに変更するなどのハードウェアの変更になるかもしれません。
 
 ナンバープレートの認識では、実は次のような罠があります。

図柄入りご当地ナンバープレート全41地域一覧&最新情報!取得・登録方法も
 図柄が入っていて、ナンバー部分を切り出すのをじゃましやすくなっているのです。

設置条件も、ナンバープレートが正面になるような位置にカメラを設置できるとは限りません。
斜めの方向からみたナンバープレートを認識しなくてはならないかもしれません。

このように、既存の技術であっても、安易に考えると罠にはまってしまいます。

  • あるシーンではうまくいくのに、別のシーンではまったくうまくいかない。  特にステレオ計測の場合には、ある被写体の場合には奥行きがうまく求まっても、別の被写体では奥行きの精度がでないことがあります。  テクスチャーが乏しい被写体・光沢のある被写体、暗い被写体などの場合にステレオ計測がうまくいかない場合があります。

 ステレオ計測の場合には視差が何pixelあるのかということが大事です。そのためには、同じ画角のカメラでも、カメラのpixel 数が多いほうが、視差が出やすくなります。目的の計測がうまくかどうかは、実験で確かなければなりません。 

 実験で確かめてみた結果、使用するセンサの能力が足りなくて、入れ替えなければならないことが発覚するかもしれません。
 製品として成立させるための前提が満たされていないということが起こりうるのです。

ここにある落とし穴を解決しても次の落とし穴が待ち受けています。
1台についてうまく動作しても、多数の機器をしかも長期間にわたって動作させることができるとは限りません。

待ち受ける落とし穴3

  • 再現性が確保できない。
  • 機体ごとに特性がばらついてしまって、性能が確保できない。
  • 特性が経年変化をしてしまって、性能が維持できなくなる。

実験室レベルでは見えないこと

数台の機体で実験室レベルと動作させているうちはまだ楽な状況だ。開発中の機体に合わせてチューニングしているから、機体ごとの特性のばらつきに対して無自覚で済む。組み立てから間もない機体であれば、経年劣化の影響がでにくい状況のなかで特性を見ている。しかし、開発者の手を離れたところで用いられる状況では、設置される状況や使われ方が開発者の思い描いていたものとは違ってくる。しかも特性が経年変化してしまっては、ただでさえ性能の確保がしにくい技術の場合だと、対策を打たない限り実用水準を維持できない。

新しい技術を開発する際には、仮説の上に仮説を重ねてはならない。

技術のつなぎ目でおきること。

  • 未知の要素があるもののどうしのつなぎ目の部分では、果たしてこれで性能が確保されるのかがわかりにくい。 開発者にとって未知の要素がある技術は、組み合わせる程に、未知の要素の要因は増えるし、未知の要因のばらつく範囲も増えていく。たちまち、未知の領域が発散してしまうようになる。  未知の領域が増えることで、開発時に期待した性能が実現するのがとても難しくなってしまう。

問題が組織の誰にでも明確になるころには、経営のインパクトが大きくなっている。

縦割りの組織運営をしていると、それらの問題点についての状況を知りうる人の数が限られる。
組織を束ねる立場になればなるほど、自分の得意な技術範囲を超えてくる。そのため適切な判断をするのは難しい。
現場の技術者に問い詰めるマネジメントは、現場の技術者の負担を高めるだけで問題の解決にはつながらない。
現場の技術者が問題点を指摘していても、「それほど深刻ではあるまい」と楽観的に考える人もいる。

マネジャーを任された人によっては、自分自身の評価を良くするために、「うまくいっている」というように見せたい欲求がはたらくかもしれない。成果主義とはやっかいなものだ。「決算を水増しして、配当を増やしていい顔をしたい」という欲求は、起こりうることだと最近の事例は伝えている。
 そのため、現場の技術者が早くから発信しているリスクのメッセージは無視され、問題が組織の誰にでも明確になるころには、経営のインパクトが大きくなっている。

 開発完了の期日を遅らせ、開発計画を仕切りなおすことになる。それらは、経営に対するインパクトとして大きな影響を与える。

--

対策

そういう状況におちいらないためには、次のような点を心がけたい。

  • 購入して確かめられることは、購入して確かめること
    • ベストの選択は難しい。ベストでなくてもそれなりに良い物を使い始めてみること。
    • 使ってみていると問題点がみえてくる。
    • その状況でより良い物を探せば良い。
    • 最終的な製品には用いないものであっても、現状のよいものを使って、現状のできることを知ることは、開発者自身の判断力を高めることにつながる。
  • 専門家に聞いて確かめられることは、聞いて確かめること

    • 自分がある分野にそれなりに詳しい場合でも、その道の専門家はもっと詳しいものです。2年も状況が変われば、使用すべきアルゴリズムだって変わってきます。
    • CPUやGPUのリソースをガンガンに使っていい状況と、限られたリソースの中で対応しなければならない状況では、考え方がまったく違って、到達する結論も変わります。
  • ワーストケース、ありそうな状況、期待する効率的な状況など複数の場合を念頭において考察すること

    • 「起こりうるどんなワーストケースでもうまくいく」ことを期待しすぎてはいけません。ワーストケースにおいては、なんらかの妥協が必要になることがあります。
    • 実際に「ありそうな状況」は、ワーストケースほど厄介ではないかもしれません。ワーストケースでも使えるだけの性能を求めているうちに、大多数の「ありそうな状況」に使えることを見逃してしまうかもしれません。
    • 「期待する効率的な状況」では、そのようなありそうな状況に対して何らかの工夫を加えていくことで、効率的な処理が可能になることがあるかもしれません。
  • 複数の技術のつなぎ目がある場合には、一方は安定な技術を使おう。

    • 極力、一方は未知の要素が少ない安定な技術を使って組み合わせよう。そうすれば、安定な技術のカバーしてくれる範囲がわかるので、相手先の技術がどこまでカバーしてくれればよいのかががわかってくるようになる。
  • 不確実な要因を減らしていく実験を継続的にしていくこと

追記:自分の思い込みという落とし穴

自分の思い込みという落とし穴は大きい。
何かを立案して実際に作業を進めていると、「それは無理があった」と判明することがある。
そのような思い込みが、自分を苦しめることは得てして起こる。
だから、その自分の思っていることが本当なのかを早い段階で検証して、
思い込みの引き起こすリスクを減らすことが必要です。